本記事は 2026 年 8 月 17 日 に公開された「 Amazon Aurora DSQL observability concepts and usage with Amazon CloudWatch 」を翻訳したものです。 Amazon Aurora DSQL は Amazon CloudWatch Database Insights による可観測性の強化に対応しました。実際に体感するパフォーマンスや支払うコストに直結する、時間ベースのパフォーマンス診断が利用できます。 Amazon Aurora DSQL の可観測性は、DSQL クラスターの動作について具体的な改善につながる洞察を提供することを目指しています。本記事では、可観測性モデルとそのパフォーマンス・コストとの関係、そして CloudWatch Database Insights、PromQL、DSQL システム診断 AI スキルを実際に使う方法を解説します。 なぜ時間ベースの可観測性なのか Aurora DSQL は、リクエストの処理に費やした時間とリソースを反映する DPU (Distributed Processing Units) に基づいたオンデマンド料金モデルを採用しています。そのため DSQL では、データベースがユーザーのために処理を行っているときにのみ DPU が発生します。この課金モデルにより、セッションがどこで時間を費やしているかを把握することが極めて重要になります。DSQL の可観測性モデルは、まさにこの点を示してくれます。 DSQL の可観測性は、すべての開発者が気にするであろう「時間はどこで費やされているのか」に明確に答える、直接的なシグナルを提供することに重点を置いています。その大部分は時間という概念を軸に構築されており、観測する内容と体感する内容を直接結びつけます。時間はパフォーマンスにおいて最も重要な単位です。さらに、DSQL のオンデマンド料金モデル、つまり使った分だけ支払うという仕組みとも直接相関します。これは完全に意図されたもので、この相関により、観測可能なパフォーマンスと歩調を合わせてコストを管理できます。クエリが速いほど、消費する DPU は少なくなります。 DSQL は実績のあるアプローチを基盤としています。時間ベースの可観測性は、商用データベース、PostgreSQL、MySQL など、数年にわたり多くのデータベースで成果を上げてきました。DSQL はこの実績あるモデルを、分散 SQL 環境にネイティブに持ち込み、数百ものカウンターによる混乱を招くこともありません。 DASH の紹介 DSQL Active Session History (DASH) は、クラスター内のセッションのアクティビティを監視することで、可観測性メトリクスを支えています。DASH はクラスター内のすべてのアクティブなセッションを 1 秒ごとにサンプリングし、1 分間隔で集計したデータポイントを CloudWatch OTel メトリクスとして発行します。次のいずれかに該当する場合、セッションはアクティブとみなされます。 セッションが CPU を実際に消費している セッションが待機イベント (ストレージ待機やコミット待機など) でブロックされている セッションがトランザクション内にあるが、アプリケーションからのリクエストを待っている これらの状態はいずれもトランザクションのレイテンシーと DPU に影響します。DPU は DSQL の課金単位であり、その大部分はクエリの処理に費やした時間を反映します。DPU はアクティブなセッション時間に比例するため、クエリが待機に費やす時間 (または非効率な処理に費やす時間) を減らすことが、そのままコスト削減につながります。 各サンプルには追加のコンテキストが含まれ、特に重要なのはサンプル取得時点で実行されていた SQL テキストの先頭 256 文字です。これにより、サンプル取得時に何が実行され、何を待っていたかがわかります。 DASH は 1 秒に 1 回サンプリングします。一見すると粗く感じるかもしれません。しかし実際には、この頻度で「クラスター内で時間はどこに費やされているのか」という基本的な問いに答えられます。DASHはサンプリングによる統計的な全体像を提供することで、診断のオーバーヘッドを最小限に抑えつつ、ほとんどのパフォーマンス診断シナリオで根本原因を確実に浮き彫りにします。本記事の後半で示す PromQL の例が、これを実際に示しています。 DASH はデフォルトですべての Aurora DSQL クラスターで有効化されており、追加コストはかかりません。クラスターを作成した瞬間から可観測性データが得られます。 CloudWatch Database Insights Amazon CloudWatch Database Insights は、DASH データを直感的に扱う手段を提供します。2 つの重要な問い、つまり「セッションが最も多くの時間を費やしているのはどこか」「最もアクティブな SQL 文はどれか」に答えます。 図 1: 待機イベント別のデータベース負荷と最もアクティブな SQL 文を表示する CloudWatch Database Insights AWS は Aurora DSQL 向けに 1 分間隔メトリクスの CloudWatch Database Insights Standard Mode を追加料金なしで提供し、すべてのクラスターでデフォルトで有効化します。DSQL は DASH データを 15 か月間保持します。これにより、トレンド分析、キャパシティプランニング、そして長期間でしか表面化しない散発的な問題の調査に十分な履歴を確保できます。 CloudWatch Database Insights は、Amazon Relational Database Service (Amazon RDS) や Amazon Aurora (非 DSQL) のデータベースと同じ、使い慣れたビューを表示します。上部のペインには、その期間中にサンプリングされた待機イベントについて、Average Active Sessions (AAS) を使った DBLoad のタイムラインが表示されます。 RDS や Aurora (非 DSQL) のデータベースとの顕著な違いは、 Max vCPU のラインがない点です。DSQL は弾力的にスケールするため、キャパシティの上限が固定されていません。そのため、システムの健全性は本記事の後半で説明する別の方法で判断します。 下部のペインには、その期間中に最もアクティブだった SQL が表示されます。これは、サンプル取得時にその SQL 文を実行していた Average Active Sessions の数で定義されます。RDS や Aurora とは異なり、DSQL のビューには現在、累積 SQL 統計や実行計画情報へのドリルダウンは含まれていません。 待機イベント DSQL の待機イベントは、コミュニティ版 PostgreSQL と比べて数が少ないです。待機イベントのリストは、より細かい粒度を実現するために今後増える可能性はありますが、たとえば PostgreSQL 18 で現在定義されている 273 個に近づくことはまずないでしょう。これは、DSQL のクエリプロセッサ (QP) がラッチ ( LWLock )、データロック、IPC を管理する必要がないためです。これらはコミュニティ版 PostgreSQL で定義されている待機イベントの大半を占めています。次の表に、現在の DSQL の待機イベント一覧を示します。 待機名 説明 OnCpu セッションは外部からの入力を待っておらず、CPU 上で実際に実行しています。これには解析、プランニング、式の評価、結果の処理が含まれます。 ClientRead セッションはオープンなトランザクション内でアイドル状態にあり、アプリケーションが次の SQL 文またはコミット / ロールバックコマンドを送信するのを待っています。 ClientRead 待機が頻繁または長時間にわたる場合、アプリケーションの過剰なラウンドトリップや、必要以上に長く開いたままのトランザクションを示していることがよくあります。 ClientWrite 結果がネットワーク経由でデータベースからアプリケーションへ送信されています。 ClientWrite が高い場合、大きな結果セットや、アプリケーションとデータベース間のネットワークレイテンシーを示していることがあります。 Commit セッションはコミットを開始し、コミットサービスからの確認応答を待っています。応答は成功か、アボート (シリアライゼーションエラー) のいずれかです。どちらの結果も Commit 待機を経て発生します。 FkExistenceCheck セッションは参照先の外部キーの行が存在するかを検証しています。この検証には、関係を確認するための読み取りが必要です。 PgSleep アプリケーションが明示的に pg_sleep() を呼び出したため、セッションがスリープしています。これはアプリケーション起因の待機であり、データベースが課す待機ではありません。 ScatteredBatchRead セッションはストレージからのバッチ読み取りを実行し、連続していない複数のキーを 1 回のストレージ呼び出しで取得しています。 SequentialScanRead セッションはストレージから連続した範囲のキーを読み取っています。これは必ずしもフルテーブルスキャンを意味しません。比較的小さな連続キー範囲を対象とする場合もあります。 SingleRead セッションはストレージから単一のタプル (ポイントルックアップ) を読み取っています。このイベントは、バッチサイズ 1 の ScatteredBatchRead にほぼ置き換えられており、現在の DSQL バージョンではまれです。 StartTransaction セッションは分散トランザクションを開始する準備をしています。 UniqueConstraintCheck セッションは一意キー制約を検証しており、重複をチェックするためにストレージの読み取りが必要です。これは、主キー以外の列に対する一意制約と、新しい行の挿入時の主キー制約の両方に適用されます。 表 1: DSQL の待機イベント SQL 文 DSQL は SQL 文を Query ID で参照します。Query ID は、QP が SQL テキストに基づいて生成する一意のクエリ ID を base32 でエンコードしたものです。DSQL は DASH データ内のすべての SQL に Query ID を割り当てます。SQL テキストは正規化された形式で記録され、リテラル値を $ プレフィックス付きの数値識別子に置き換えられます。 PromQL による直接クエリ PromQL は、Database Insights を使う代わりに、基盤となる DASH データを直接クエリする手段です。DSQL は DASH データを CloudWatch OTel メトリクスとして公開しており、Amazon CloudWatch Query Studio で PromQL を使ってクエリできます。これにより Database Insights と同じ情報に加え、カスタム分析用の追加ディメンションが得られます。 次の PromQL の例では、3 つの一般的なユースケースを扱います。1 つ目は、どの待機イベントが最も多くの時間を蓄積しているかの特定です。2 つ目は、待機に最も多くの時間を費やしているクエリの発見です。3 つ目は、ストレージ待機で最も長く待っているクエリの特定です。Query Studio でこれらのクエリを試す前に、必ず my_cluster_id を実際のクラスター ID に置き換えてください。 Average Active Sessions によるデータベース負荷 avg by("db.wait.event") ({"db.active_sessions.avg", "@resource.aws.auroradsql.cluster_id"="my_cluster_id"}) 図 2: 待機イベント別にグループ化した Average Active Sessions によるデータベース負荷 Average Active Sessions 上位 5 クエリ topk(5, avg by("db.query.normalized_text") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 3: Average Active Sessions 別の上位 5 クエリ Average Active Sessions と待機イベント別の上位 5 クエリ topk(5, avg by("db.query.normalized_text", "db.wait.event") ({"db.active_sessions.avg","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 4: Average Active Sessions と待機イベント別の上位 5 クエリ Average Active Sessions とストレージ待機別の上位 5 クエリ topk(5, sum by("db.query.normalized_text") ({"db.active_sessions.avg","db.wait.event"=~"S.*Read|.*Check","@resource.aws.auroradsql.cluster_id"="my_cluster_id"})) 図 5: Average Active Sessions とストレージ待機別の上位 5 クエリ アプリケーションの健全性 他の AWS リレーショナルデータベースサービスでは、インスタンス内の vCPU 数と同じだけのセッションが CPU 上にある状態は、健全ではない兆候です。アプリケーションからの要求が利用可能なコンピューティングを上回ると、レイテンシーが悪化します。前述のとおり、DSQL にはクラスターが需要に合わせて弾力的にスケールするため Max vCPU という概念がありません。そのため、アプリケーションの健全性を判断する別の方法が必要です。 まず、AAS の観点で健全なシステムがどのようなものかを考えてみましょう。これに唯一の答えはありません。アプリケーションごと、そしてそのアプリケーションの負荷ごとに異なります。あるアプリケーションは、5 つのセッションが同時にアクティブでストレージ読み取りを待っているときは正常に動作し、10 のセッションがストレージ読み取りを待っているときは動作が悪化するかもしれません。別のアプリケーションは、500 のセッションがストレージ読み取りを待っていても完璧に動作するかもしれません。重要な考え方は、アプリケーションごとに正常動作時の AAS プロファイルが異なるということです。待機セッションの具体的な数だけでは、健全性の低さを示すことにはなりません。 DSQL の弾力的なスケーリングの性質からも、ある日は 100、翌日は 1,000 の待機セッションがあったとしても、必ずしも健全性の低下を示すわけではありません。単にシステムが 10 倍のトランザクションを処理していることを意味するだけかもしれません。では、どうやって健全性を判断すればよいのでしょうか。 答えは、絶対的な数値ではなく、時間の経過に伴う待機イベントの割合を比較しなければならないということです。たとえば、健全なアプリケーションが次の表のような待機プロファイルを示すと仮定します。 待機イベント 待機セッション数 SequentialScanRead 40 Commit 10 OnCpu 50 表 2: 正常時の待機イベントの割合 忙しい日にはこれらの数値がそれぞれ 80、20、100 に増えるかもしれません。相対的な割合は同じままで、システムの負荷が 2 倍になっても健全であることを示しています。DSQL は追加の負荷に対応して自動的にスケールします。しかし、待機プロファイルが次の表のようになる日があれば、何かがおかしくなったとわかります。 待機イベント 待機セッション数 SequentialScanRead 90 Commit 3 OnCpu 7 表 3: 異常時の待機イベントの割合 このケースでは、アプリケーションの変更や SQL プランの変更によって、セッションが変更の処理やコミットよりもデータのスキャンに多くの時間を費やすようになった可能性が高いです。待機イベントの割合が期待される分布から大きく外れているため、これは健全でない状態です。 複雑に思えるかもしれませんが、実際には Database Insights を使えば視覚的に素早く把握できます。一貫した色の割り当てにより、通常の動作がどのようなものかをすぐに見分けられるようになります。もちろん、本番システムを適切に管理するには目視での確認だけでは不十分なため、自動アラームの設定をお勧めします。これらのアラームは、待機イベントごとの AAS の上限 / 下限のしきい値として CloudWatch で設定できます。より詳細な分析を行うには、生データに対してトレンドクエリを実行し、待機の分布を時系列で確認してください。 DSQL システム診断 AI スキル Agent Plugins for AWS の一部である databases-on-aws プラグインを使うと、DSQL システム診断のヘルスチェックが簡単になります。設定後は、さまざまな期間にわたって DSQL クラスターのパフォーマンスチェックをリクエストできます。これにより、CloudWatch MCP サーバーを使って選択した複数の期間の DASH データを分析するワークフローが起動します。エージェントにインストールすると、次のようなプロンプトを発行できます。 「us-east-1 の DSQL クラスターのパフォーマンスをチェックして、markdown レポートを作成して」 スキルはその後、履歴のベースラインと比較します。デフォルトでは、直近 1 時間、昨日の同じ時間帯、先週の同じ時間帯が対象ですが、次のようなプロンプトで変更できます。 「直近 4 時間のパフォーマンスをチェックして、先週の月曜日と比較して」 Markdown レポートの例は次のとおりです。 図 6: DSQL システム診断 AI スキルが生成した Markdown パフォーマンスレポートの例 このレポートの例では、さらに先の部分で、特定のクエリを実行計画が不適切な候補として指摘しています。 図 7: 実行計画が不適切な候補となるクエリを指摘するレポート 特定のクエリに問題がありそうな場合、スキルは SQL に特化した詳細な診断ワークフローを自動的に開始し、その SQL 文に関する診断情報を報告します。 まとめ DSQL の時間ベースの可観測性アプローチは、セッションがどこで時間を費やしているかを直感的に把握でき、観測結果をパフォーマンスの体感やコストに直接結びつけることができます。CloudWatch Database Insights による視覚的な概要把握、PromQL による DASH データの直接クエリ、DSQL スキルによる自動分析のいずれを使っても、ボトルネックのすばやい特定からクエリの最適化、DSQL クラスターの安定運用まで対応できるツールが揃っています。ぜひこれらのツールを活用して、DSQL クラスターのパフォーマンス改善に役立ててください。 著者について James Morle AWS のプリンシパルエンジニアで、Amazon Aurora DSQL に取り組んでいます。データベースのパフォーマンスとスケーラビリティに関する数十年の経験を持ち、世界最大級で最も要求の厳しいトランザクションデータベースシステムをいくつも構築してきました。開発者と運用者の双方にとってデータベースの可観測性を直感的で実用的なものにすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

本ブログは 2026 年 7 月 8 日に公開された AWS Blog “ The CISO’s guide to post-quantum mandates and migrations ” を翻訳したものです。 現在、十数の主要国・地域がポスト量子暗号 (PQC) の導入ガイダンスを公開しています。CISO であれば、既に移行計画をかなり進めており、最も難しい部分はアルゴリズムの変更そのものではないとご存じでしょう。リーダーシップにおける本当の課題は、大規模で複雑な組織全体で協調的な変革を推進することです。非対称暗号は、あらゆるプロトコル、あらゆるベンダー依存関係、そして目立たないところで鍵交換やデジタル署名を担っているあらゆるレガシーシステムに組み込まれているからです。このガイドでは、コンプライアンス期限を守りながら組織のセキュリティガバナンスをモダナイズするプログラムを実現する必要がある CISO、CTO、その他のシニアリーダー向けに、規制の背景と戦略的プレイブックを提供します。 多忙な経営層向けの概要 本記事の重要なポイントは次の 5 つです。 トップから始める。 暗号のモダナイゼーションを、明確なタイムラインと測定可能なマイルストーンを持つエンタープライズリスクの低減として位置づけ、取締役会レベルのスポンサーシップを確保します。この取り組みの責任を担い、優先順位付けの基準を設定し、事業部門横断でデリバリーを調整する中央集約型のプログラムオフィスを立ち上げます。 すべてをインベントリ化するのではなく、依存関係を分類する。 ワークロードレベルで理解すべきことは 3 つです。プロバイダーが代わりにアップグレードしてくれるもの、期限内にアップグレードされず置き換えが必要なもの、そして自組織が所有し直接対応しなければならないものです。移行範囲を削減する最速の方法は、可能な限り暗号の責任を最初のカテゴリ (プロバイダーが代わりにアップグレードしてくれるもの) に移すことです。 暗号テレメトリに投資する。 移行作業と並行して可視化の仕組みとモニタリングを整備します。この能力は不可欠ですが、移行の勢いを犠牲にしてはいけません。アルゴリズムの使用状況、PQC カバレッジ率、移行速度をワークロードレベルで追跡します。テレメトリは複数年にわたるプログラムを通じて取締役会のスポンサーシップを維持し、中央チームが優先順位を設定するためのフィードバックループを提供します。 一度きりのコンプライアンスではなく、俊敏性のために構築する。 目標は PQC を一度デプロイすることにとどまるべきではありません。暗号の移行は繰り返し発生する運用上の要件になるため、標準の進化に合わせてプロトコル、アルゴリズム、鍵長を切り替えられる組織的な体制を築きます。 セキュリティとガバナンスのモダナイゼーションとして扱う。 徹底したパッチ適用の規律、信頼性の高い 継続的インテグレーションと継続的デリバリー (CI/CD) 、自動化されたライフサイクル管理は、PQC 移行の後も長く活用できる能力です。これらは、脆弱性が発見されるまでの期間が数週間から数時間へと短縮される、AI によって加速された脅威に対応するために必要な能力と同じです。アルゴリズムをオンデマンドで切り替えられる組織は、AI 主導の新たなエクスプロイトに対するパッチ適用も可能です。 以下、プレイブックの全容を説明します。 グローバルな規制動向 2024 年 8 月、 NIST は、鍵カプセル化 (ML-KEM)、格子ベースのデジタル署名 (ML-DSA)、ハッシュベースの代替署名方式 (SLH-DSA) をカバーする最初の 3 つのポスト量子標準を公開しました。これらの標準は、ほとんどの国・地域が移行期限を設定する際に参照するベースラインとなっています。米国、欧州連合、英国、ドイツ、フランス、オーストラリア、カナダ、日本、韓国、インド、シンガポール、UAE はいずれも正式なガイダンスを公開しています。金融サービス業界の FS-ISAC や通信業界の GSMA のような業界団体も、独自の追加タイムラインを設けています。 これらのタイムラインは国・地域によって異なりますが、いずれも同じ方向を向いています。ほとんどの地域では、2027 年までに新規調達において PQC への対応準備を求めており、完全な移行の期限は業界や地域に応じて 2030～2035 年に設定されています。国境を越えて事業を展開する組織にとって、事業を行う各国・地域の具体的な要件に対応することは、コンプライアンスと競争上のポジショニングの両面で不可欠です。 Amazon Web Services (AWS) は、「 Migration to quantum-resistant cryptography 」ページの FAQ セクションで、地域ごとの規制と期限を詳しく整理して公開しています。 移行のスコープ設定 歴史的に見ると、暗号の移行は予想よりはるかに長い時間がかかってきました。SHA-1 の廃止は、最初に脆弱性が公表されてから主要なブラウザが最終的に拒否するまで、約 20 年を要しました。MD5、3DES、RC4 も、移行が急務であるという明確な技術的コンセンサスがあったにもかかわらず、組織の対応が遅いという同じパターンをたどりました。また、これらの移行は、現在利用できるモダンなクラウドインフラストラクチャ、自動化されたオーケストレーション、リアルタイムのテレメトリがない時代に行われました。これらの能力を活用する組織は、より速く移行しながら、同時に将来に備えたセキュリティ基盤を構築できます。 移行のスコープ設定という課題は、明確に 2 つの系統に分かれます。1 つ目は、TLS、IPsec、SSH のような有効期間の短い認証プロトコルまたは暗号化プロトコルの一部としてアルゴリズムをネゴシエートするソフトウェアシステムです。これらのワークロードについては、クラウド中心のライフサイクル管理、自動パッチ適用、集中化されたライブラリのアップグレードにより、過去の暗号移行よりも容易になっています。マネージドサービスは透過的にアップグレードを処理でき、テレメトリツールによってエンドポイント全体のアルゴリズム使用状況をリアルタイムで可視化できます。CI/CD パイプラインを使用すれば、確実なロールバック経路を確保しながら段階的なロールアウトが可能です。モダンなクラウドインフラストラクチャを持つ組織にとって、暗号移行のこの側面を高速に実行できる環境は、かつてないほど整っています。 移行対象の 2 つ目の系統は、長期間使用される組み込みシステムです。これは、鍵とアルゴリズムのコードを含むファームウェアが書き込まれ、その場でのアップデートができないデバイスです。この対象範囲を削減する最速の方法は、暗号ワークロードをマネージドサービスにオフロードすることです。これにより、プロバイダーがハードウェアの更新サイクルを引き受け、移行したワークロードの分だけ計画対象のデバイスが減ります。専用ハードウェア上に残るものについては、年次の設備投資 (capex) レビューに量子への備えを組み込みます。量子技術の進歩は決まったスケジュールで訪れるわけではないため、量子ハードウェアの進展に照らして、組み込みの暗号資産を毎年評価してください。運用上問題なく何年も使えるデバイスもあれば、脅威が現実化するまでの期間が短くなるにつれて置き換えの前倒しが必要になるデバイスもあります。年次評価を行うことで、早期の廃止は予算外の緊急事態ではなく、計画されたビジネス上の意思決定になります。 戦略的プレイブック 以下のプレイブックは、組織の状況に合わせて適用できる PQC 移行への戦略的アプローチの概要です。各ステップは、企業全体の足並みをそろえ、不明確な点を実行可能なフレームワークで解消し、プログラムへの予算確保と計画どおりの進行を維持するための測定可能な進捗を実現するように設計されています。 取締役会レベルのコミットメントを確保する CISO は、格子ベースのアルゴリズムに関する技術説明としてではなく、規制コンプライアンスと競争上のリスクに紐づくビジネスリスクの議論として、PQC を取締役会に提起する必要があります。その際には、誤解を正すことが重要です。取締役会レベルでよくある誤解の 1 つは、PQC 移行には保管中のすべてのデータの再暗号化が必要だというものです。これは事実ではありません。標準の 256 ビット対称暗号で暗号化された保管中のデータは、量子コンピュータに対して脆弱ではありません。この区別は実際の変更範囲を大幅に絞り込むものであり、スコープを過大に設定することを防ぐため、早い段階で伝えるべきです。 規制のタイムラインは具体的に提示してください。例えば、 CNSA 2.0 が 2027 年 1 月までに新製品での PQC 採用を義務付けていること、そしてこれらのタイムラインが金融サービス、ヘルスケア、政府、防衛といった規制対象の業種では調達の関門として機能することを説明します。また、規制対象の業種に属する売上とワークロードをマッピングすることで、組織のリスクエクスポージャーを定量化できます。例えば、公共部門の顧客との既存契約や進行中の商談を、リスクにさらされているビジネスの定量的なデータとして活用できます。 これを実践するとどのようになるか、例を示します。1 つ目に、規制対象の業種において、PQC コンプライアンスの文言が既に含まれている、または更新時に含まれる見込みの既存契約を特定します。それに紐づく売上を計算し、18 か月以内の更新日をコンプライアンスクリフ (期限切迫リスク) として洗い出します。2 つ目に、進行中のパイプラインを確認します。PQC への対応準備を既に参照している RFP、ベンダーアンケート、調達要件はありますか? 自組織がコンプライアンスを実証できず、競合他社が実証できる場合、そのパイプラインの価値は、選定対象から除外されるリスクにさらされます。3 つ目に、規制が発効しつつある業種における獲得可能な市場機会の総額を算定し、準備ができていなければどの程度の市場を取り逃すことになるかを示します。顧客がベンダー契約に PQC への対応準備要件を盛り込むようになっている中、コンプライアンスを実証できない組織は、将来のビジネスで選定対象から除外されるリスクがあります。 最後に、取締役会レベルのスポンサーシップのもとで、専任の人員とベンダー予算を要求します。これは既存のセキュリティ運用に吸収されるサイドプロジェクトであってはなりません。四半期ごとに定量的な成果をリーダーシップレベルで追跡する経営層レビューを優先してください。 専任の移行リーダーを任命する セキュリティ、エンジニアリング、コンプライアンス、調達にまたがる部門横断的な責任範囲を持つ暗号のセンターオブエクセレンス (CoE) を立ち上げます。プログラム全体をエンドツーエンドで所有し、経営層に直接報告する移行リーダーを任命します。PQC はネットワーキング、アイデンティティ、アプリケーション開発、ベンダー管理、コンプライアンスのすべてに同時に影響するため、これらの領域から代表者を集めてチームを構成してください。 このチームに、暗号ポリシー、ライブラリの使用、移行タイムラインに関する組織標準を設定する権限を与えます。また、同チームにベンダーやサプライヤーとの連携機能を持たせ、PQC への対応準備に関するクラウドプロバイダーやサードパーティベンダーとの関係を、責任を持つ 1 つのチームが推進できるようにします。 このチームに資金を投じ、各事業部門がゼロから作り直すのではなく再利用できる、中央集約型の対応パターンの整備を推進する役割を持たせてください。同チームが、リファレンス実装、承認済みのライブラリバージョン、テストフレームワーク、ロールアウトプレイブックを所有します。あるチームが特定のワークロードタイプの移行パターンを解決したら、中央チームがそのソリューションをパッケージ化し、組織内のすべての類似ワークロードに展開します。 依存関係を分類し、移行対象範囲を削減する 明示的に義務付けられている国・地域を除き、ボトムアップの包括的な暗号インベントリを推奨するガイダンスには注意してください。その作業は数か月を費やし、実際の移行を遅らせる可能性があります。代わりに、依存関係を 3 つのカテゴリに分類します。 他者が代わりにアップグレードしてくれるワークロード。マネージドクラウドサービス、 Software as a Service (SaaS) プロバイダー、および PQC ロードマップを積極的に進めているインフラストラクチャベンダーがここに該当します。自組織の役割は、プロバイダーのタイムラインを検証し、確実に履行されるようにすることです。 他者がスタックを所有しているが、期限内にアップグレードされないワークロード。これらは置き換えが必要なベンダー依存関係であり、計画上の耐用年数が終わる前に置き換える可能性もあります。置き換えの意思決定を調達や設備投資のサイクルに早期に組み込めるよう、今すぐ洗い出してください。 自組織が所有し、自らアップグレードしなければならないワークロード。これらについては、その場でアップグレードするか、暗号レイヤーがマネージドになるクラウドへモダナイズするかを判断します。 最初の 2 つのカテゴリはベンダーリスク評価プログラムの範疇です。3 つ目のカテゴリが、自組織内で管理し、逆算スケジュールで完了まで推進すべきワークストリームです。どの依存関係が検証済みか、どの置き換えが進行中か、自己管理のスタックのうちどれにアップグレード計画があるかを追跡します。この 3 カテゴリモデルは、際限のない棚卸し作業に陥ることなく、中央チームに明確な意思決定フレームワークを提供します。 オブザーバビリティを構築し、進捗を継続的にモニタリングする 暗号の状況を可視化することは、計画、実行、そして監査人へのコンプライアンス実証に不可欠です。ただし、オブザーバビリティをワークロード移行の前提条件にすべきではなく、移行の勢いを犠牲にしないよう、並行するワークストリームとして捉えるべきです。可視化ツールが整備された後は、それまでに完了したすべての作業を遡って示すとともに、組織レベルの進捗をリアルタイムで把握できるようになります。 多くの組織は TLS から着手します。TLS は通常、最も広範に展開された暗号であり、ウェブアプリケーション、API、マイクロサービス全体で転送中の機密データを保護する主要なメカニズムだからです。サービスログのメタデータフィールドを使ってポスト量子と従来型の TLS トラフィックを区別し、すべてのエンドポイントにわたるアルゴリズム使用状況を示す TLS メトリクスダッシュボードの構築を推進してください。「 AWS Config を使用したポスト量子暗号 (PQC) 対応の自動化 」で紹介している PQC Readiness Scanner は、この種の可視化ツールを構築・デプロイする方法の一例です。時間の経過とともに、同じオブザーバビリティを IPsec、SFTP、SSH などの他のトランスポートプロトコルにも拡張します。 全社共通の KPI を設定した継続的な評価プログラムを確立し、その結果を経営層レビューに反映できるようにしてください。テレメトリは棚卸しに役立つだけでなく、複数年にわたるプログラムを通じて取締役会のスポンサーシップを維持するための、経営層レベルの進捗メトリクスも提供します。いくつかの例を挙げます。 TLS 1.3 と ML-KEM 鍵交換を使用している TLS 接続の割合 定義したカテゴリ全体での PQC カバレッジ率 検証済みのベンダータイムラインと未確認のものの比率 新しい依存関係が非準拠として検出されてから修復までの時間 PQC カバレッジ率をワークロードレベルおよび組織レベルで追跡してください。これらのメトリクスにより、PQC 移行は一度きりのプロジェクトから継続的なガバナンス機能へと変わります。パッチ適用サイクル、脆弱性 SLA、コンプライアンス状況を既に管理しているのと同じ形です。目標は、将来の暗号移行を、そのたびに新しいプログラムを立ち上げるのではなく、日常的な運用作業として吸収できる恒常的な能力を育てることです。 ベンダー、規制当局、業界団体と連携する PQC 移行は組織の境界を越えるものであり、サプライチェーン全体での協調した動きが必要です。クラウドプロバイダーと PQC ロードマップについて対話し、どのサービスが既に PQ-TLS をサポートしているか、どれがロードマップにあるか、いつサポートが見込まれるかを把握してください。サードパーティのソフトウェアベンダーや SaaS プロバイダーに対しては、PQC サポートのタイムラインについて明確な質問を投げかけ、今後は調達要件やベンダー契約に PQC への対応準備を盛り込んでください。 自組織が属する国・地域の規制当局や標準化団体と連携し、自組織の業界に適用される具体的なタイムライン、コンプライアンスの仕組み、監査の期待事項を把握してください。金融サービス、通信、ヘルスケア、重要インフラにはそれぞれセクター固有の PQC ワーキンググループがあり、同業組織がアプローチや教訓を共有しているため、業界フォーラムにも参加してください。この協調的なアプローチは、社内に消極的なステークホルダーがいる場合に、移行に必要な投資を獲得する助けにもなります。 所有するワークロードの優先順位を付けてロードマップを策定する すべてを一度に移行しようとするのではなく、段階的なアプローチを採用してください。リスクとユースケースに基づいてワークロードの優先順位を付けます。「 AWS ポスト量子暗号への移行計画 」ブログ記事に、この優先順位付けの例が紹介されています。ロードマップの実行にあたっては、あらゆる段階で信頼性の高いリリースとロールバックの仕組みを構築してください。PQC アルゴリズムはパフォーマンスやサイズの特性が異なるため、本番環境の負荷下で予期しない挙動が現れる可能性があります。レガシーな依存関係が移行の障害になる前に特定してください。カスタム TLS ライブラリやハードコードされた暗号スイートを使用しているシステムは、プロセスの早い段階で洗い出しておく必要があります。 PQC の対象範囲を削減する最速の方法は、カスタムの暗号スタックを完全に排除することです。マネージドサービスに移行したワークロードの分だけ、チームが手動でアップグレードしなければならないワークロードが減ります。AWS は既に、パフォーマンスへの影響を体感できないほど抑えつつ、複数のサービスエンドポイントでポスト量子鍵交換を提供しており、 AWS Key Management Service (AWS KMS) と AWS Private Certificate Authority を通じてポスト量子署名も提供しています。クラウドのコンピューティング環境やオンプレミス環境の独自コードについては、 AWS-LC のようなオープンソースの暗号ライブラリが、本番利用可能で FIPS 140-3 検証済みの PQC 実装を提供しており、チームは今すぐ採用できます。 クリプトアジリティを備えた企業へ移行する クリプトアジリティ (暗号の俊敏性) とは、アルゴリズムの切り替え、プロトコルの更新、暗号の変更を、専用プログラムとしてではなく通常業務として吸収できる運用能力です。暗号標準は今後も進化し続けます。アルゴリズムは廃止され、置き換えられていきます。この能力を今のうちに構築した組織は、次回の移行時に新たなプログラムを必要としません。 クリプトアジリティには、4 つの分野での卓越性が求められます。 パッチ適用とアップグレードの規律: 現在、フリート全体で一貫したパッチ適用サイクルを維持できていない場合、PQC 移行はそのギャップをエンタープライズ規模で顕在化させます。成熟した脆弱性管理プログラムは、既存の運用の自然な延長として PQC を取り入れます。 確実なロールバックを伴う段階的リリース: PQ アルゴリズムは署名と鍵のサイズが大きく、パフォーマンスプロファイルも異なります。変更を段階的にデプロイし、本番環境で挙動を検証し、想定どおりに動作しない場合に確実にロールバックできる必要があります。 一貫した CI/CD パイプライン: 非対称暗号に触れるすべてのアプリケーションは評価が必要で、場合によっては更新されたアルゴリズムやライブラリで再構築・再デプロイが必要になります。不安定なデプロイプロセスや手動のデプロイプロセスは、移行全体の妨げになります。 自動化されたセキュリティライフサイクル管理: 証明書のライフサイクル、鍵のローテーション、シークレットの保管、署名操作、コンプライアンス検証は、すべてマシンスピードで動作しなければなりません。現在は機能している手動プロセスも、セキュリティ要件が進化するにつれて破綻します。 これらは必ずしも PQC 固有の投資ではありません。適切に運営されているセキュリティ組織の基盤となる能力です。AI によって脆弱性の発見と悪用の速度が加速する中、クリプトアジリティを運用体制に組み込んでいる組織は、AI によって加速された脅威への対応において有利な立場にあります。優れたセキュリティリーダーは、脅威の状況が進化する中で組織に必要な運用上のレジリエンスを構築する契機として、PQC を活用できます。 まとめ PQC 移行は、次世代のエンタープライズセキュリティプログラムがどのように構築され、測定されるかを決定づけるものになります。過去のどの暗号移行よりも速くこの移行を実行するための技術ツールは既に存在します。今行動する組織は調達要件を形作り、業界の競争基準を設定することになります。先送りする組織は、タイムラインの圧縮、コストの増加、選択肢の減少に直面することになります。 AWS は、PQC 移行のプロセスを進めるお客様を支援します。最新のガイダンスと資料は「 Migration to quantum-resistant cryptography 」でご覧いただけます。 AWS Security Assurance Services と AWS プロフェッショナルサービス は、お客様自身のアプリケーションとワークロードのアップグレードを支援する専門的なガイダンスと、検証済みの実装アプローチを提供します。まずは、無料の Post-Quantum Readiness Accelerator の紹介ミーティング をリクエストできます。 Rushir Patel Rushir は AWS でワールドワイドのデータ保護ビジネス開発を率いており、AWS の暗号、アイデンティティ、データ保護サービスの市場開拓戦略を推進しています。サイバーセキュリティ、クラウド、AI で 15 年以上の経験を持ち、コーポレートファイナンスと電気工学のバックグラウンドがあります。仕事以外では、ガーデニング、スキー、ワイン、旅行を楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 11 日に公開された AWS Blog “ Accelerate cyber defense with OpenAI and AWS: Daybreak Red & Daybreak Blue now available to eligible customers on Amazon Bedrock ” を翻訳したものです。 サイバー防御者がこれほど多くの能力を手にしたことはありません。そして、その能力がこれほど必要とされたこともありません。フロンティアモデルは、コードベース全体にわたって推論を行い、脆弱性を根本原因まで追跡し、数分で修正案を提案できるようになりました。しかし、同じ能力は攻撃者も利用できます。そのため、脆弱性が開示されてから悪用されるまでの期間はますます短くなっています。防御者は、広範囲に及ぶ不慣れなコードベースでも後れを取らずに対応し、どの検出結果が重要かを検証し、確実に機能するパッチをリリースすることが求められます。しかもこれらすべてを、機密性の高いコードや脆弱性データを自らが管理・監査できる環境内に保持したまま行わなければなりません。もはや課題は潜在的な問題を見つけることではなく、どれが本当の問題かを見極めて修正し、その対応を攻撃者に悪用される前の限られた時間内に完了させることにあります。 AWS は、セキュリティを最初から組み込むという原則に基づいて一貫して事業を行ってきました。これは AI についても同様です。お客様は、推論から完全自律型のエージェントまで、さまざまなワークロードを Amazon Bedrock で実行しています。そこに適用されるインフラストラクチャ、コントロール、ガバナンスは、お客様が AWS 全体で信頼して利用しているものと同じです。本日 (2026 年 8 月 11 日)、AWS と OpenAI は、この基盤をサイバー防御にも広げます。OpenAI の Daybreak Red と Daybreak Blue を、対象のお客様向けに Amazon Bedrock で提供開始しました。Daybreak Red は、サイバーセキュリティ専用にトレーニングされたモデルである GPT-5.6 Cyber へのアクセスを提供します。Daybreak Blue は、安全対策を防御的なサイバーセキュリティ業務向けに調整した GPT-5.6 Sol へのアクセスを提供します (訳注: 一般提供されている GPT-5.6 Sol とは提供形態が異なり、利用には後述の Trusted Access for Cyber への登録が必要です)。どちらも、OpenAI のサイバー防御イニシアチブである Daybreak の一部であり、防御者にフロンティア AI への統制されたアクセスを提供します。Daybreak には、エージェント型ツール、アプリケーションのレッドチーム演習、検出結果から検証済みの修正へと進むための支援サービスが含まれます。 「AWS と OpenAI は、防御者が優位に立つべきだという考えを共有しています。この提携により、OpenAI の Daybreak Red と Daybreak Blue を Amazon Bedrock で提供します。AWS のセキュリティチームは現在、両方のモデルを使用してソースコードの分析、脆弱性の発見、レッドチームの調査を行っています。Amazon Bedrock 上でのこの作業は、AWS が他のすべての重要なワークロードに適用しているのと同じインフラストラクチャコントロールのもとで実行されます。これらのモデルが進化を続けるにつれて、防御者が Amazon Bedrock 上でこれらのモデルを使ってできることも進化していくでしょう」 — AWS Security Vice President John Sheehan 許可を得た高度なサイバーセキュリティ業務向けの専用モデル 脆弱性の発見から修正までの道のりは長いものです。悪用可能性の確認、脆弱なコンポーネントへの到達経路の追跡、リグレッションを引き起こさずに根本原因に対応する修正の開発、現実的な条件下でその修正が機能することの検証、そして開示後の限られた期間内でのパッチのリリースが必要です。防御者には、これらすべてのステップを加速できるモデルが必要です。しかし、サイバーセキュリティは本質的にデュアルユース (防御にも攻撃にも利用可能) です。脆弱性の再現やエクスプロイトチェーンのリバースエンジニアリングを求めるリクエストは、意図の善悪にかかわらず同じように見えるため、汎用モデルはリクエストを拒否することでこの曖昧さを解消します。Daybreak Red と Daybreak Blue は、誰がモデルを使用しているのか、作業がどこで行われるのか、そのアクセスをどのような安全対策が管理しているのか、というコンテキストによってこの問題を解決します。 ほとんどのセキュリティチームにとって、Daybreak Blue が適切な出発点になります。Daybreak Blue は、脆弱性の発見、検出エンジニアリング、インシデント対応をサポートします。Daybreak Red は、脆弱性調査、エクスプロイトの再現、対策の開発といった高度なタスク向けに設計されています。これらのタスクでは、拒否しきい値 (モデルがリクエストを拒否する基準) を下げつつ、それに見合った強力な本人確認、モニタリング、アクセスコントロールを組み合わせることで、調査のスピードと深さを高められます。 OpenAI によると、セキュリティ研究者は Daybreak Red を通じて GPT-5.6 Cyber を使用し、Chrome で使用されている JavaScript エンジンである V8 において、これまで知られていなかった 2 つの脆弱性を特定しました。これらを連鎖させると、メモリ破壊とヒープサンドボックスエスケープを引き起こす可能性がありました。最初の脆弱性は修正され、CVE-2026-15903 として公開されました。これは、2026 年に V8 CTF で成功したわずか 4 件のゼロデイエントリのうちの 1 つです。 すでに信頼している基盤の上で実行 サイバーセキュリティのワークロードでは、独自のソースコード、未修正の脆弱性の詳細、本番システムからのライブテレメトリといった、最も機密性の高い情報をモデルに入力します。これらの情報がモデルを通過する前に、それがどこに送られ、誰が見ることができるのかを確実に把握しておく必要があります。 両モデルは、高いパフォーマンス、セキュリティ、信頼性を実現するために構築された Amazon Bedrock の次世代推論エンジン上で動作します。ゼロオペレーターアクセス (ZOA) はチップレベルで強制されるため、AWS のオペレーターであっても推論中のプロンプトや出力にアクセスすることはできません。データは転送中および保管中に暗号化されます。アクセスは AWS Identity and Access Management (IAM) ポリシーによって管理され、AWS CloudTrail に記録され、仮想プライベートクラウド (VPC) エンドポイントを経由します。組織レベルでデータ境界ポリシーを設定することで、アカウントやネットワークの境界を越えたデータの流出を防ぐことができます。 推論データはモデルトレーニングに使用されず、どちらのモデルでも OpenAI とのデータ共有にオプトインする必要はありません。 自動不正使用検出 のために、分類器によってフラグが付けられたトラフィックは AWS によって最大 30 日間保持され、プログラムによって処理されます。これらのモデルでゼロデータ保持を必要とする場合は、AWS アカウントチームを通じてリクエストできます。詳細については データ保持 を参照してください。 利用開始方法 Daybreak Red: GPT-5.6 Cyber と Daybreak Blue: GPT-5.6 Sol を、次の AWS リージョン の Amazon Bedrock で、対象のお客様向けに提供開始しました: 米国東部 (オハイオ)。これらのモデルを利用するには、OpenAI の Trusted Access for Cyber への登録が必要です。登録するには、OpenAI にご連絡いただくか、対象条件については AWS アカウントチームにお問い合わせください。承認された後は、AWS アカウントチームと連携して AWS 側でアクセスをリクエストしてください。詳細については、 ドキュメント を参照してください。 Amazon Bedrock 上の GPT-5.6 ファミリー全体の詳細については、「 Get started with OpenAI GPT-5.6 Sol, Terra, and Luna on Amazon Bedrock 」を参照してください。 Amazon Bedrock がお客様をどのように支援できるかにご興味がある方は、 お問い合わせ ください。 著者について Tanvi Girinath Tanvi は Amazon Web Services (AWS) で Amazon Bedrock を担当するプロダクトマーケティングマネージャーです。お客様が Amazon Bedrock を使用して AI アプリケーションやエージェントを導入し、スケールするための支援を行っています。 Saurabh Trikande Saurabh は Amazon Web Services (AWS) で Amazon Bedrock を担当するシニアプロダクトマネージャーです。主要プロバイダーのフロンティアモデルによる推論を、あらゆる規模のお客様にとってパフォーマンス、セキュリティ、コスト効率に優れたものにする取り組みを主導しています。 Chris Dickens Chris は OpenAI の Member of Product Staff として OpenAI API を担当しています。Amazon Bedrock における AWS との連携にも取り組んでおり、OpenAI のフロンティアモデルを開発者が広く利用できるようにする活動を行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS では、AI を活用した新しいソフトウェア開発手法「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。AI-DLC は、AI を単なる補助ツールとしてではなく、要件定義から設計・実装・テストまでの開発ライフサイクル全体に組み込みながら、人間が主導権を握る（Human-in-the-Loop）ことを前提とした開発手法です。この AI-DLC を短期間で体験・実践いただくワークショップが「AI-DLC Unicorn Gym（以下 UG）」です。 2026 年 6 月 11 日〜12 日、株式会社サンリオ デジタル事業開発部の皆様と 2 日間の「サンリオ AI-DLC UG」を開催しました。本記事では、開催レポートと、参加メンバーの皆様に体験を語っていただいた座談会の様子をお届けします。 1. サンリオ AI-DLC Unicorn Gym 開催レポート サンリオ AI-DLC Unicorn Gym 参加メンバー サンリオのデジタル事業開発部は、「キャラフォリオ」（公式とファンがつながる創作プラットフォーム）や「オモイデバッジ」（イベント参加記録・ユーザー交流 SNS）など、デジタルプロダクトの企画・開発を担っています。2025 年から開発の内製化に舵を切り、少数精鋭のチームで Claude Code を中心とした AI 活用開発を実践してきました。個人の生産性向上の先にある「チームとして、上流工程からどう AI を組み込むか」という課題への答えを求めて AI-DLC に着目されたことが、今回の開催のきっかけです。 当日はデジタル事業開発部 プロダクト開発課 シニアマネージャー 倉井 龍太郎 氏をはじめとする 2 チーム 6 名のエンジニアとプロダクトマネージャーが参加し、実際のプロダクトを題材に AI-DLC の全フェーズを体験しました。ツールには Kiro を利用し、AI エージェントを中心に据えた開発ワークフローを実践しています。AWS 側はアカウントマネージャーの荻原 賢大、ソリューションアーキテクトの山澤 良介・瀧田 直斗が各チームに伴走しました。 チーム テーマ 技術構成 成果 チーム A （オモイデバッジ） オモイデバッジ 管理機能拡張 — パッケージ詳細への URL リンク設置 TypeScript / Kiro inception から本番マージまで 約 5 時間 で完了。デプロイ済み。 チーム B （新規アプリ） 新規アプリの立ち上げ TypeScript / Kiro 管理者向け管理画面まで構築完了 チーム A の成果 — 「作らない」判断と、約 5 時間での本番マージ チーム A では 2 つのユーザーストーリーを検討しました。1 つ目は、AI と一緒に価値と実現方法を掘り下げた結果「機能を実装しなくても運用でカバーできる」と判断し、あえて実装しないことを選択。AI で実装が速くなるほど「何を作らないか」の判断に価値が生まれることを示す成果となりました。 2 つ目のストーリー「パッケージ詳細への URL リンク設置」では、AI-DLC の全フェーズを一気通貫で体験しました。 時刻 フェーズ 内容 Day 2 10:59 Inception インタビュー型の add-inception スキルを作成 Day 2 13:59 Inception AI のインタビューを受けて inception ドキュメントを作成・マージ Day 2 15:03 Construction 既存の設計スキルで設計書を作成し、自律実装へ Day 2 15:58 マージ backend / API / 管理画面 / アプリの実装をマージ inception 開始から本番マージまで 約 5 時間 2. 座談会 — 参加メンバーに聞く 荻原（AWS） 今回の AI-DLC UG が実現した経緯を教えてください。 倉井氏（サンリオ） 日頃から Claude Code を使って開発していましたが、個人の生産性は上がっても「チームとして、上流工程からどう AI を組み込むか」がずっと課題でした。AWS の AI-DLC のブログを見つけたとき、まさにこれだと思って、すぐにミーティングで相談しました。 荻原（AWS） AI にインタビューされながらユーザーストーリーを作るプロセスはどうでしたか。 チーム A メンバー（サンリオ） 「何を・誰に・どんな価値を・どう検証するか」を AI が順番に聞いてくれるので、抜け漏れを防げました。価値のコンフリクトや成功指標など、一人では飛ばしがちな観点を確実に通過できたのが大きいです。またインタビューをスキル化し、改善ステップも組み込んだので、誰がやっても同じ品質のインセプションプロセスを踏めるようになりました。 荻原（AWS） AI-DLC を体験したことで、今後の開発にどう活かしていきたいですか。 倉井氏（サンリオ） 大きく 2 つあります。1 つ目は、インセプションプロセスで言語化することで、企画側の目的をしっかり理解した上で開発が進められ、手戻りを大幅に減らせること。2 つ目は、ユーザーストーリーを書くことでプロジェクトメンバー全員が同じ情報を持った上で開発が進むことです。非常にスムーズでした。 チーム A メンバー（サンリオ） 今後は実際の開発フローに PM の作業も組み込みたいと考えています。PM・エンジニアの「作業」をエージェントに任せて、人間は設計とレビューに専念する — それが目指す姿です。 倉井氏（サンリオ） 内製化を進める中で「少人数でいかに大きな価値を届けるか」が常に課題です。AI-DLC はそのための方法論として非常に手応えを感じました。AI-DLC の旅はまだ始まったばかりです。 3. 今後の展開と AWS の支援 サンリオ デジタル事業開発部では、今回の UG で得た知見を実プロダクト開発に本格導入していく予定です。 Inception の標準化 — 今回作成したインタビュー型スキルをチーム標準プロセスとして運用開始 「人間は設計とレビュー」モデルの実践 — AI が実行し、人間が監視・判断する AI-DLC の本質を日常の開発に浸透させる ワークショップを運営して感じたのは、AI-DLC の Inception フェーズが Amazon の Working Backwards （お客様の体験から逆算して考える手法）と本質を同じくする、ということです。「誰に・どんな価値を・なぜ届けるのか」を AI のインタビューに答えながら言語化し、チーム全員で合意する。AI が「問い」を投げかけることで議論の抜け漏れが構造的に防げるため、経験の浅いチームでも質の高い要件定義ができるようになります。 AWS は、サンリオの AI 活用パートナーとして、UG で作成したスキルの実プロダクトへの適用と AI 駆動開発の定着を引き続き支援してまいります。倉井氏をはじめ、ご参加いただいた皆様、ありがとうございました。 本記事は、2026 年 6 月 11 日〜12 日に開催した「サンリオ AI-DLC Unicorn Gym」および参加メンバーの皆様との座談会をもとに構成しました。 著者プロフィール 荻原 賢大 アマゾン ウェブ サービス ジャパン合同会社 営業部 広域事業部門。株式会社サンリオを担当するアカウントマネージャー。お客様のビジネス変革を技術で支援することに情熱を注いでいます。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への展開にも取り組んでいます。 山澤 良介 AWS のソリューションアーキテクトとして、製造業を中心にエンタープライズ企業の支援をしています。その活動の傍ら、最近は Claude Code / Cowork の国内展開に向けた技術支援やコンテンツ作成に取り組んでいます。

本記事は 2026 年 8 月 20 日 に公開された「 Long-term system tables retention in Amazon Redshift with Amazon S3 Tables 」を翻訳したものです。 Amazon Redshift のシステムテーブルは、実行されたすべてのクエリ、確立されたすべての接続といった運用シグナルを継続的に記録します。収集したデータは、データウェアハウス全体の可観測性、パフォーマンス分析、コンプライアンス監査を支えます。しかしこれまで、システムテーブルがこの重要なデータを保持できる期間はわずか 7 日間で、独自の回避策なしに長期的なコンプライアンス対応や監査を行うのは困難でした。 Amazon Simple Storage Service ( Amazon S3 ) の機能である Amazon S3 Tables と Amazon Redshift システムテーブル の統合により、システムテーブルのログデータが自動的に Amazon S3 Tables に配信され、 Apache Iceberg 形式で保存されます。Amazon Redshift システムテーブルの保持期間を現在の 7 日間の上限を超えて設定でき、独自の ETL パイプラインやクラスターリソースを消費することなく、コンプライアンス対応、監査、ウェアハウス横断の可観測性を長期にわたって実現できます。データはオープンかつ堅牢で、Amazon Redshift、 Amazon Athena 、 AWS Glue 、 Amazon EMR 、その他の Apache Iceberg 対応エンジンからクエリできます。 本記事では、Amazon Redshift システムテーブルの統合がどのようにログデータを Amazon S3 Tables に配信するのかを解説します。本機能は、RA3 および RG のプロビジョンドクラスターと Amazon Redshift Serverless ワークグループでサポートされています。 課題 Amazon Redshift を運用していると、システムテーブルの保持期間が 7 日間に制限されていることに起因する運用上の課題によく直面します。 クエリの傾向が把握しにくい: 同じクエリの 30 日前と現在のパフォーマンスを比較したいことがあります。パフォーマンスが徐々に変化する場合、長期的なベースラインがあれば、場当たり的なトラブルシューティングではなく、データに基づいた根本原因分析が可能になります。 変更前後の比較: 新しいワークロードの追加、インスタンスタイプの変更、 Workload Management (WLM) キューの調整を行う際には、その影響を正確に測定したくなります。保持期間を延長すれば、必要なベースラインデータを残しておけます。 季節性を考慮したキャパシティプランニング: 月末のスパイク、四半期末の急増、年間のピークを把握して計画するには、数か月分の履歴データが必要です。保持期間を延長すると、数か月から数年にわたる季節的なパターンが見えてきます。 独自 ETL パイプラインの負荷: 保持期間の制限を回避するため、システムテーブルのデータを 1 時間ごとまたは 1 日ごとに Amazon Redshift マネージドストレージ内の永続テーブルにコピーする独自パイプラインを構築するチームもあります。こうしたパイプラインはクラスターリソースを消費し、本番ワークロードと競合し、継続的なエンジニアリング保守を必要とします。Amazon Redshift がシステムテーブルのスキーマやデータ共有の設定を更新すると、パイプラインには手作業での対応が必要になり、記録に欠落が生じます。 コンプライアンス要件: 規制対象の業界では、数か月から数年に及ぶ監査証跡の保持が求められます。7 日間の上限のもとでこの要件を満たすには、独自のインフラが必要でした。Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、この課題が解決されます。 仕組み Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、Amazon Redshift システムテーブルのデータを Apache Iceberg 形式で自動的に Amazon S3 テーブルに書き込むフルマネージド機能です。パーティショニング、圧縮、保持期間の管理は AWS が自動的に処理します。ログの書き込み処理は独立したバックグラウンドプロセスで実行され、本番ワークロードとのリソース競合を抑えます。パイプラインの管理は AWS が代行します。 本機能はリリース時点で 25 を超えるシステムビューをサポートしています。サポート対象のシステムビューについては ドキュメント を参照してください。 セットアップ Amazon Redshift コンソールから Amazon S3 Tables とのシステムテーブル統合を有効にするには、次の手順に従います。 Amazon Redshift コンソールを開き、[System table integrations] ページに移動します。プロビジョンドクラスターまたは Serverless ワークグループの詳細ページからもアクセスできます。 Create System table integration を選択します。設定ウィザードが起動します。 本機能を有効にする Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループを選択します。   図 1: システムテーブル統合ウィザードでの Amazon Redshift データウェアハウスの選択 Available system tables リストから公開するシステムビューを選択します。個々の SYS_* ビューを選ぶか、 Select all supported system tables を選択して、現在および将来サポートされるすべてのビューを公開します。すべてを選択した場合、将来追加される新しいビューは設定を変更しなくても自動的に含まれます。   図 2: [Available system tables] リストから公開するシステムビューを選択 デプロイモデルを選択します。Amazon S3 Tables でのデータの整理方法を選びます。 データウェアハウスごと・システムテーブルごとに個別の S3 テーブル : 各ウェアハウスのデータを専用のテーブル群に保持します。 データウェアハウス横断でシステムテーブルごとに共有の S3 テーブル : アカウント内の複数のウェアハウスのデータを共有のテーブル群に集約します。 必要に応じて、AWS Key Management Service (AWS KMS) のカスタマーマネージドキーで暗号化を設定します。デフォルトでは、データは Amazon S3 マネージドキー (SSE-S3) で暗号化されます。 変更を保存します。Amazon Redshift は選択したビューの Amazon S3 Tables への公開を開始し、一定の間隔で新しいレコードを追加し続けます。 統合が有効になっているかを確認するには、次のようにします。 クラスターまたはワークグループの詳細ページに移動します。 統合のステータスと、各ビューの最終取り込み時刻を確認します。 公開されたデータは Amazon S3 Tables コンソールからも確認できます。 有効化すると、Amazon Redshift は本番ワークロードとは別の独立したバックグラウンドプロセスを通じて、定期的にログデータを Amazon S3 テーブルに書き込みます。保持されたログのクエリを開始するには、AWS Glue Catalog を介して Amazon Redshift 環境と Amazon S3 Tables のデータを接続する初回セットアップが必要です。次の手順を実行します。 AWS Glue Data Catalog と Amazon S3 Tables へのアクセスに必要な権限を持つ AWS Identity and Access Management (IAM) ロールを作成し、Amazon Redshift クラスターまたは Amazon Redshift サーバーレスネームスペースに関連付けます。 AWS Glue Data Catalog で、ログが格納されている Amazon S3 Tables データベースを指すリソースリンクを作成します。 Amazon Redshift で、リソースリンクを参照する外部スキーマを作成します。 CREATE EXTERNAL SCHEMA <schema_name> FROM DATA CATALOG DATABASE '<resource_link_database>' IAM_ROLE '<iam_role_arn>'; 設定が完了すると、使い慣れた 2 部構成の表記法で過去のシステムテーブルデータをクエリできます。 SELECT * FROM <schema_name>.<table_name>; Amazon S3 Tables へのアクセスは読み取り専用のため、監査証跡の整合性は本質的に保たれます。 IAM ポリシーの例を含む詳細なセットアップ手順については、 S3 Tables と Data Catalog の統合の有効化 を参照してください。 データは Apache Iceberg 形式で保存される システムテーブルのデータは、オープンテーブル形式である Apache Iceberg で保存されるため、互換性のあるクエリエンジンを自由に選べます。可観測性や監査のデータを、すでに使っているツールでそのまま扱えます。 運用データは次のサービスで分析できます。 Amazon Redshift: S3 テーブルバケットを AWS Glue Data Catalog と統合したうえで、Amazon Redshift でリソースリンクを指す外部スキーマを作成し、保持されたテーブルをクエリします。 Amazon Athena: インフラのプロビジョニングなしで、過去のログに対してサーバーレスの SQL クエリを実行します。 AWS Glue: 運用データを基盤に、自動化されたデータ処理・変換ジョブを構築します。 Amazon EMR: 複雑なウェアハウス横断分析のために、Spark ベースの分析を大規模に実行します。 データは Amazon S3 Tables にオープンな Apache Iceberg 形式で保存されるため、Amazon Redshift、Amazon Athena、自然言語クエリ用の AI エージェントスキル、 Amazon SageMaker Unified Studio 、Iceberg 対応エンジン、ビジネスインテリジェンス (BI) ツール、可観測性システムなど、さまざまな手段でクエリできます。 コスト効率 Amazon Redshift から Amazon S3 Tables へのログ配信に追加費用はかかりません。料金が発生するのは、Amazon S3 Tables のストレージ、メンテナンス、および選択したエンジンでのデータのクエリに対してのみです。 ソリューションの概要 以下のシナリオでは、Amazon Redshift システムテーブルと Amazon S3 Tables の統合が、Amazon Redshift 環境全体でよくある運用・コンプライアンス・可観測性の課題をどのように解決するかを紹介します。また、本機能のために専用のスキル querying-aws-redshift を用意し、AWS MCP Server に組み込みました。これにより、Amazon S3 Tables から Amazon Redshift システムテーブルをクエリできます。 シナリオ 1: クエリの傾向を長期的に追跡する 数か月から数年分の SYS_QUERY_HISTORY データを保持しておけば、個々のクエリのパフォーマンスを長期間にわたって追跡できます。あるクエリの実行時間、キュー時間、リソース消費量を、日単位・週単位・月単位で比較できます。 パフォーマンスが劣化し始めた時期を正確に特定し、新しいスキーマ、データ量の急増、同時実行ワークロードの追加といった変更と関連付けられます。保持期間を延長することで、トラブルシューティングは事後対応から、先を見据えたデータドリブンな根本原因分析へと変わります。 シナリオ 2: 変更前後のワークロードへの影響を評価する 新しい ETL パイプライン、インスタンスタイプの変更、Workload Management (WLM) キューの調整、アドホッククエリを実行するアナリストチームの追加など、ワークロードの変更はいずれもシステムに影響します。問われるのはいつも、その変更がパフォーマンスにどう影響したかです。 Amazon Redshift システムテーブルと Amazon S3 Tables の統合により、自信を持ってデータに基づいた意思決定ができます。 SYS_QUERY_HISTORY をクエリして、変更前の数週間と変更後の数週間で、実行時間、キューでの待機時間、同時実行スケーリングのイベントを比較します。2 週間前に新しいレポートワークロードを導入し、既存のクエリへの影響を把握したい場合、それを確認するためのデータはすでに揃っており、独自パイプラインは一切不要です。 シナリオ 3: 可観測性ダッシュボードを構築する システムテーブルのデータは Apache Iceberg で保存され、AWS Glue でカタログ化されます。つまり、Apache Iceberg を読み取れる可観測性ツールやビジネスインテリジェンス (BI) ツールから直接接続できます。経営層向けのレポートとして、ワークロードの分散傾向を Amazon Quick Sight で可視化できます。より深い分析や、運用データからの AI 主導のインサイト生成には、Amazon SageMaker Unified Studio を利用します。AWS のサービスにとどまらず、使い慣れたサードパーティの可観測性システムや BI ツールを接続して、クエリ量の追跡、接続パターンの監視、異常検知のアラート設定、あるいは Amazon Redshift の運用データとアプリケーションレベルのログの相関分析も行えます。 可観測性や監査のデータを、すでに使っているツールでそのまま活用できます。堅牢で構造化された運用データに、好みのツールから直接アクセスできます。 シナリオ 4: 季節性を踏まえてキャパシティを計画する ワークロードの需要は 1 年を通じて変動します。月次決算、四半期末のレポート、年間の計画サイクル、プロモーションイベントはいずれも予測可能な使用量のスパイクを生みますが、それはパターンを見て取れるだけの履歴データがあってこそです。 保持期間を延長すれば、複数のビジネスサイクルにまたがる使用状況の傾向を分析できます。キャパシティの上限に常に近づくのはいつかを特定し、需要が四半期ごとにどう変化するかを測定し、プロビジョニング済みのリソースが実際の使用量と見合っているかを検証できます。 シナリオ 5: コンプライアンスの監査証跡を維持する 規制対象の業界にとって、保持期間の延長は、整合性を標準で備えたフルマネージドの監査証跡をもたらします。 SYS_CONNECTION_LOG はすべての認証試行を記録します。 SYS_USERLOG はユーザーアカウントの変更を記録します。 SYS_QUERY_HISTORY はウェアハウスに対して実行されたすべてのクエリを記録します。 保持期間は、90 日、1 年、あるいは数年など、組織のデータ保持ポリシーに合わせて設定します。読み取り専用のアクセスポリシーにより、書き込み後のレコードが管理者を含む誰かによって改変されるのを防げます。 シナリオ 6: ウェアハウス群全体で運用の可観測性を一元化する 複数の Amazon Redshift ウェアハウスを運用している場合、運用データを統合的に把握できるメリットがあります。本機能は、組織構造に合わせて 2 つのデプロイパターンをサポートします。 ウェアハウスごとの個別テーブル: 各ウェアハウスが専用の Amazon S3 テーブルに書き込むため、コンプライアンス上の配慮が必要な環境向けに完全なデータ分離を実現します。複数のウェアハウスをまとめてクエリするには、 UNION 操作が必要です。 共有テーブル: 同じアカウント・同じ AWS リージョン内のウェアハウスが、共有された 1 組の Amazon S3 テーブルに書き込み、データは warehouse_name 列で区別されます。ウェアハウスで絞り込めば、クラスター横断の分析をすぐに行えます。 ベストプラクティス プライバシー上の理由でログの分離が必要なウェアハウスを特定し、それらには ウェアハウスごとの個別テーブル オプションを選択します。残りのウェアハウスには、管理を簡素化するために 共有テーブル (集約) オプションを使用します。 保持期間はコンプライアンス要件に合わせます。ストレージコストを抑えるため、コンプライアンス要件を満たす最小限の保持期間を設定します。 保持されたシステムテーブルをクエリする際は、 warehouse_account_id 、 warehouse_region_name 、 warehouse_namespace_arn 、 warehouse_name 、 s3_tables_ingestion_time などのメタデータ列で絞り込み、スキャン範囲を減らしてパフォーマンスを高めます。複数のウェアハウスにまたがる大量の履歴データをクエリする場合は、特に重要です。 監査証跡の整合性は、標準で備わる読み取り専用アクセスに任せます。保持期間や暗号化の設定は、Amazon S3 Tables の設定 API で管理します。 暗号化の方針は早い段階で計画します。設定後の変更には統合の再作成が必要になるため、暗号化キーはセットアップ時に慎重に選びます。将来的にウェアハウスを集約する見込みがあるなら、最初から共有の AWS KMS キーを選んでおきます。 まとめ Amazon Redshift システムテーブルと Amazon S3 Tables の統合は、独自の ETL パイプラインをフルマネージドのソリューションに置き換え、Amazon Redshift の運用データを保持します。Apache Iceberg ベースのストレージへの自動保存、オープン形式でのクエリ、標準で備わる監査整合性により、数か月から数年分の可観測性データをフルマネージドで得られます。 AWS Management Console 、 AWS Command Line Interface (AWS CLI) 、 AWS SDK から有効にできます。 詳しくは、 Amazon Redshift システムテーブルのドキュメント を参照してください。 著者について Nidhi Nayak Nidhi は、AWS のシニアテクニカルアカウントマネージャーです。エンタープライズのお客様がスケーラブルで高性能なクラウドアプリケーションを構築し、クラウド運用を最適化できるよう支援しています。データ分析の分野で 10 年以上の経験を持ち、現在は Amazon Redshift と、Redshift への生成 AI の統合に注力しています。 Raza Hafeez Raza は、Amazon Redshift のシニアプロダクトマネージャー (テクニカル) です。エンタープライズのデータウェアハウスの構築と最適化に 15 年以上携わり、あらゆる規模のお客様にとってクラウド分析を使いやすく、コスト効率の高いものにすることに情熱を注いでいます。 Shubham Purwar Shubham は、AWS の Analytics スペシャリストソリューションアーキテクトです。AWS プラットフォーム上でスケーラブルかつ安全で高性能な分析ソリューションを設計・実装し、お客様がデータの潜在能力を最大限に引き出せるよう支援しています。AWS の分析サービスに関する深い専門知識を活かし、お客様と協力して個別のビジネス要件を明らかにし、具体的なインサイトをもたらしてビジネスの成長を促すカスタマイズされたソリューションを構築しています。プライベートでは、家族と過ごしたり世界中を旅行したりするのが好きです。 Amrita Singh Amrita は、米国ソルトレイクシティを拠点とする AWS のシニアテクニカルアカウントマネージャーです。Amazon Redshift を専門とし、エンタープライズのお客様がデータウェアハウス環境をパフォーマンス、スケーラビリティ、コスト効率の面で最適化できるよう支援しています。お客様と直接連携してクラウド活用のガイダンスや技術支援を提供し、AWS のサービスによって柔軟性、スケール、耐障害性を高められるよう手助けしています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 6 月 4 日 に .NET on AWS Blog で公開された「 AWS Transform SQL Server to PostgreSQL Schema Validation in .NET Application Modernization 」を翻訳したものです。 本記事の執筆には Sayan Ghosh、Yuhao Zhang、Uday Kiran Erukulla、Srinivasa Varadan Saragur Madabhushi、Koushik Rajagopal、Khurram Khawaja、Vikas Babu Gali、Luke Huan が協力しました。 Microsoft SQL Server から Amazon Aurora PostgreSQL – Compatible Edition へのデータベース移行は、ライセンスコストの削減、スケーラビリティの向上、オープンソースデータベース技術の活用を目指す組織にとって一般的なモダナイゼーション戦略です。ただし、SQL Server データベースを Aurora PostgreSQL に移行する際、スキーマ変換はあくまで出発点に過ぎません。真の課題は、すべてのテーブル、制約、ストアドプロシージャ、トリガーが正しく移行され、移行先の PostgreSQL 環境でも同一の動作をすることを検証する点にあります。小数精度の変更をひとつ見落としたり、ストアドプロシージャの変換に誤りがあったりするだけで、本番環境でデータ破損やアプリケーション障害、ビジネスロジックの誤動作を招くおそれがあります。 手動でのスポットチェック、スモークテスト、単純な行数比較に頼る従来の移行テストでは、こうした微妙な意味の違いを捉えられません。オブジェクトが存在するかどうかだけでなく、機能的に等価であるかまで検証する体系的なアプローチが必要です。 この記事では、 AWS Transform が構造分析、意味検証、動作テストを組み合わせた 3 層の検証モデルによって、SQL Server から PostgreSQL への移行に対する包括的なスキーマ検証を実現する仕組みを紹介します。あわせて、 Amazon Bedrock を活用した AI エージェントが検証結果を分析し、根本原因ごとに問題をまとめ、重大度を判定して修正の優先順位付けを支援する流れも解説します。 ソリューション概要 AWS Transform のスキーマ検証は、移行元と移行先の両方を稼働中のデータベースエンジンにデプロイし、そこに対して直接チェックを実行することで、移行済みデータベーススキーマの検証をエンドツーエンドで自動化します。この検証は移行先スキーマの作り方に依存しません。ルールベースのツール、エージェンティックなソリューション、独自に構築した生成 AI (GenAI) 変換パイプラインのいずれで生成したスキーマにも適用できます。図 1 は、移行元と移行先のスキーマが検証ワークフローをどのように流れるかを示しています。 図 1. エンドツーエンドのスキーマ検証ワークフロー 図 1 のとおり、検証は以下の流れで進みます。 移行元の SQL Server スキーマと移行先の PostgreSQL スキーマを、それぞれ専用の Amazon Elastic Container Service (Amazon ECS) コンテナに読み込む 両方のスキーマが Tier 1 (構造的検証) に入り、検証ワークフローが各オブジェクトが移行先に存在するかをプログラムでチェックする 構造チェックを通過したオブジェクトが Tier 2 に進み、意味的な等価性を比較する 意味チェックを通過したストアドプロシージャが Tier 3 (動作検証) に進み、ランタイムでテストする 各 Tier がオブジェクトごとの判定 (PASS、FAIL、または WARNING) を出力し、スコアリング層に集約される エキスパートアセスメントエージェントがすべての判定を確認し、両方の稼働中データベースにクエリを発行してフラグの立った問題を裏付ける。その後、検出内容を根本原因ごとにまとめ、重大度を判定し、最終的な本番移行準備レポートを生成する ウォークスルー このワークフローは、内部的には以下の 5 つのステップとして実行されます。 移行元 SQL Server と PostgreSQL の検証コンテナを Amazon ECS 上で起動する 移行元と移行先のスキーマを、対応する検証用データベースに読み込む 両方のデータベースにクエリを発行してルールベースのチェックを実行する Amazon Strands Agents を使って AI エキスパートによる分析を実行する 最終的な検証レポートを生成する この検証は 2 つの原則に基づいています。 正規表現による解析ではなく、稼働中のデータベースを使う 。バリデーターは稼働中の各データベースに直接クエリを発行します。生の SQL ファイルの記述内容ではなく、エンジンが実際に解釈した内容を報告します。 決定論的な処理を先に、LLM は後に 。ルールベースのチェックを大規模言語モデル (LLM) 層より前に実行し、LLM にはフィルタリング済みの入力を渡します。これにより LLM は決定論的なシグナルを置き換えるのではなく、補強する役割を担います。 これらの原則のもと、ルールベースのチェックと AI 分析は以下のように動作します。 1. 構造的検証 (Tier-1) 目的 : 移行元スキーマのすべてのデータベースオブジェクトが移行先スキーマに存在することを検証する この Tier では、移行元と移行先の両方のデータベースに直接クエリを発行し、すべてのスキーマオブジェクトに対してルールベースの存在チェックを並行して実行します。以下の表に例を示します。 オブジェクトタイプ チェック内容 テーブル 各テーブルが移行先に存在し、列と NULL 許可のルールが一致することを確認する 制約 主キー、外部キー (カスケードルールを含む)、一意制約、CHECK 制約を検証する 構造の照合で見落としやすい課題が、名前の正規化です。SQL Server は既定で大文字小文字を区別しませんが、PostgreSQL は引用符で囲まない識別子を小文字に折りたたみ、大文字小文字を区別して扱います。さらに PostgreSQL は識別子を 63 バイトで切り詰めます。そのため、SQL Server 上では別名だった 2 つのプロシージャが PostgreSQL 上では同じ名前に統合されることがあり、正しく移行できたテーブルが単純なバイト単位の比較では不一致と判定されてしまいます。これを避けるため、構造の照合では大文字小文字の折りたたみ、切り詰め、引用符の除去という段階を踏んで名前を正規化し、各段階でレコードの正規化を適用します。 2. 意味的検証 (Tier-2) 目的 : 移行したオブジェクトが構造として存在するだけでなく、意味的に等価であることを検証する Tier 1 がオブジェクトの存在を確認するのに対し、Tier 2 はその定義が意味的に等価かどうかをチェックします。チェックはルールベースで、SQL Server と PostgreSQL の型システム間の型マッピングと精度のルールを組み込んでいます。以下に例を示します。 チェック 例 型マッピング nvarchar(100) から character varying(100) への変換は有効。integer への変換は無効 数値精度 decimal(18,2) は numeric(18,2) のままである必要があり、numeric(10,0) では不可 意味チェックが等価性を捏造することはありません。正規化できない場合 (既定値に互換性がないなど) は、黙って修正を適用するのではなく WARNING を出します。これにより、不要なアラートを増やさずに本番環境での問題を防げます。 3. 動作検証 (Tier-3) 目的 : ランタイムの動作が期待どおりであることを確認する Tier 2 で定義を検証したうえで、Tier 3 では実際のランタイム動作をテストします。2 つのルーチンが構造チェックと意味チェックの両方を通過しても、スタブ、分岐処理のバグ、変換で失われる方言固有の機能などが原因で、異なる結果を返すことがあります。こうした問題を洗い出すため、動作検証は次の 3 ステップで段階的に踏み込みます。 ステップ 1: スタブの検出 バリデーターは、PostgreSQL 側のルーチン本体が意味のある実装になっているか、それとも BEGIN RETURN 0; END のようなプレースホルダーのロジックだけかを調べます。スタブの生成は自動変換で最も起こりやすい失敗パターンのひとつなので、最初に検出しておくことで後続ステップの無駄な作業を防げます。 以下は、変換時に AI エージェントが SQL Server プロシージャから生成した PostgreSQL のスタブの例です。 SQL Server プロシージャ : --SQL Server procedure CREATE PROCEDURE BabelFish.bf_collationproperty @collation_name SYSNAME = 'Traditional_Spanish_CS_AS_KS_WS', @prop_name VARCHAR(255) = 'CodePage' AS BEGIN SELECT COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'CodePage') AS 'CodePage' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'LCID') AS 'LCID' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'ComparisonStyle') AS 'ComparisonStyle' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'Version') AS 'Version'; END; PostgreSQL のスタブプロシージャ : --PostgreSQL stub procedure CREATE OR REPLACE PROCEDURE babelfish.bf_collationproperty(IN collation_name varchar(128) DEFAULT 'Traditional_Spanish_CS_AS_KS_WS', IN prop_name varchar(255) DEFAULT 'CodePage') LANGUAGE plpgsql AS $body$ BEGIN RAISE NOTICE 'Stub: babelfish.bf_collationproperty - needs manual T-SQL to PL/pgSQL conversion'; END; $body$; ステップ 2: 構造の検証 バリデーターは両側のルーチンのシグネチャ、入出力パラメータ、戻り値の型を検査し、移行後のアプリケーションで呼び出しエラーを引き起こす構造の不一致を特定します。 ステップ 3: ミューテーションテストと LLM による評価 バリデーターはテスト入力を生成し、両方のデータベースに対して実行して結果を比較します。行レベルで 1 件でも差異があれば、それが 2 つのルーチンが等価でないことを示す具体的な反例になります。ミューテーションテストで判断がつかない場合は、Amazon Bedrock を通じた LLM による評価で機能的な等価性を判定し、最終的な結論を出します。 4. スコアリング 各チェックは、オブジェクトごとに PASS/FAIL または WARNING を出力します。レポートには 決定論的な 2 つの主要スコア が示され、同じ入力であれば実行ごとに同じ値になります。 Storage Score – データを保持するオブジェクト (テーブル、インデックス) 全体でのスキーマの一貫性を測る Code Score – 実行可能なオブジェクト (ビュー、ストアドプロシージャ、関数、トリガー) 全体での機能カバレッジを測る この 2 つの数値で移行のカバレッジを素早く把握できますが、最終的な評価を決めるのはこれらではありません。それを担うのが AI ジャッジ ( LLM-as-a-Judge )です。これは、エキスパートレビュワーとして振る舞う Amazon Strands Agents です。ルールベースのチェックが答えるのは「何が違うのか」です。これに対して AI ジャッジが答えるのは「それは重要なのか、どう直すべきか」です。 この AI ジャッジは両方の稼働中データベースに読み取り専用でアクセスでき、フラグの立った問題を裏付けたり否定したりするために自ら検証クエリを発行できます。そのうえで、この Strands Agents が検出内容を根本原因ごとのクラスターにまとめます。たとえば、スキーマがひとつ欠けていることが原因で 29 個のトリガーが欠落している場合、29 件ではなく 1 件のクラスターとして扱われます。各クラスターには次の重大度が割り当てられます。 重大度 基準 CRITICAL ユーザーデータの損失または破損 HIGH 将来的に気づきにくい障害が起きる、またはアプリケーションからの呼び出しが失敗する MEDIUM アプリケーションが意図どおりに動作しない可能性がある LOW 表示上の問題で、動作を妨げない 根本原因ごとにまとめるこのアプローチでは、影響を受けたオブジェクトを個別に列挙するのではなく、大元の問題に対処するためノイズが減ります。共通の原因を修正すれば、そこから派生したすべての症状が一度に解消します。 本番移行準備の判定ルール Critical の検出があれば、他のスコアに関わらず本番デプロイをブロックする High のクラスターがあれば条件付きの準備完了となる (追加の検証が必要) Medium と Low の問題は、Critical や High のブロッカーを上書きしない まとめ SQL Server から PostgreSQL への移行は影響範囲の大きい変更であり、テストに合格したというだけでは正しさの証明にはなりません。AWS Transform の 3 層検証ワークフローは、その主張を監査可能な成果物に変えます。Tier 1 ですべてのオブジェクトが移行できたことを確認し、Tier 2 で個々のオブジェクトが意味的に等価であることを確認し、Tier 3 でルーチンが同じ結果を返すことを実際に検証します。さらに AI ジャッジである Amazon Strands エージェントが検出内容を根本原因ごとにまとめ、重大度にもとづいた評価を出すため、主要スコアが高いだけで重大なデータ損失の問題が見過ごされることはありません。 まずは最初のスキーマ移行の検証を AWS Transform で試してみてください。詳細は以下のリソースをご覧ください。 AWS Transform Amazon Aurora PostgreSQL Amazon Bedrock Amazon Strands Agents 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Amit Kachroo Dr. Amit は、Amazon Agentic AI Science チームのシニアアプライドサイエンティストとして、コード変換のための生成 AI および LLM システムを構築しています。さまざまなプログラミング言語やデータベースに対応した変換機能を開発するサイエンスチームを率いています。詳しくは https://amitkac.github.io/ をご覧ください。 Vijay Mandadi Vijay は、AWS Migrations and Modernizations グループのエンジニアリングリーダーです。分散システム、クラウドコンピューティング、仮想化、ワークロード変換、ヘルスケアの分野で 16 年以上の経験を持ちます。AWS では、生成 AI とエージェンティック AI を活用して、お客様のアプリケーションワークロードのモダナイゼーションとクラウドネイティブ化を加速することに取り組んでいます。 Nits Jeganathan Nits は、AWS Transform のプロダクトリーダーです。IT 業界で 15 年の経験を持ち、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションの分野で 12 件の特許と 2 件の論文があります。複雑な課題の解決とカスタマーエクスペリエンスの向上に情熱を注いでおり、現在は生成 AI を使ったレガシーアプリケーションのモダナイゼーション加速に注力しています。

このブログは、2026 年 8 月 3 日に公開された「  Modernize SQL Server databases to Aurora PostgreSQL using AWS Transform  」を翻訳したものです。 はじめに SQL Server データベースの Aurora PostgreSQL へのモダナイゼーションは、始める前から停滞することがよくあります。インフラストラクチャーのセットアップ、ネットワーク構成、資格情報の共有、セキュリティレビューといった準備作業に何週間もかかり、移行の中身を評価する段階にすらたどり着けないのです。 AWS Transform フルスタック Windows モダナイゼーション  の Offline Source を使用すると、こうした障壁を飛び越えて、SQL Server データベースのスキーマファイルをアップロードするだけで Microsoft SQL Server データベースの  Amazon Aurora PostgreSQL-Compatible Edition  (Aurora PostgreSQL) へのモダナイゼーションを開始できます。 SQL Server 環境を管理していて、始めるまでの複雑さからモダナイゼーションを先送りにしてきた方に、ぜひ読んでいただきたい記事です。Offline Source がインフラストラクチャーの事前準備をどのように不要にするか、.NET アプリケーションコードのアセスメントを含む変換ワークフローがエンドツーエンドでどのように動くか、そして SQL Server スキーマの DDL エクスポートから、変換済みアプリケーションコードを伴う検証済み Aurora PostgreSQL スキーマに至るまでの流れを解説します。 課題: アセスメント前のインフラストラクチャー要件 SQL Server データベースのモダナイゼーションアセスメントには従来、以下が必要でした : ソースデータベースと変換ツール間のネットワーク接続 ソースサーバーへの資格情報の共有またはエージェントのインストール スキーマ分析のための中間環境のプロビジョニング 厳格なセキュリティポリシー、規制環境、または企業ファイアウォールの背後にあるデータベースを持つ組織にとって、アセスメント作業を始める前の段階でこれらの前提条件だけでモダナイゼーションプロジェクトが数週間から数か月遅れることもありました。 ソリューション概要 AWS Transform  の Offline Source を使用すると、標準的な Data Definition Language (DDL) エクスポートファイルからソースデータベースの構造を再現できます。稼働中の SQL Server インスタンスに接続する必要はなく、 DDL をアップロードするだけで AWS Transform がアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行します。インフラストラクチャーの事前準備は一切不要です。 図 1: AWS Transform Offline Source ワークフロー ワークフローは 5 つのステージで構成されます : データベースアセスメント : データベースオブジェクトの複雑さ、依存関係、作業量レベルを分析 スキーマ変換 : SQL Server オブジェクトの PostgreSQL への LLM ベースの変換 検証 : 3 層の検証 (構造的、意味的、機能的) デプロイ : 検証済みスキーマを Aurora PostgreSQL クラスターに適用 アプリケーションのアセスメントと変換 : .NET ソースコードを接続し、スキーマと並行してデータベース依存のアプリケーションコードをアセスメントおよび変換 前提条件 開始する前に、以下を確認してください : AWS Transform console へのアクセスを持つ AWS アカウント DDL を抽出するための SQL Server に接続する資格情報 Aurora PostgreSQL クラスターを作成する権限を持つ AWS アカウント (AWS Transform はデプロイステップの一部としてターゲットクラスターをプロビジョニングします) オプション : .NET アプリケーションアセスメント用の、 AWS CodeConnections 経由でアクセス可能な、または Amazon S3 や Personal Access Token (PAT) 経由でアップロードされたソースコードリポジトリ (GitHub、GitLab、または Bitbucket) AWS Transform for SQL Server は US East (N. Virginia) us-east-1 でのみ利用可能です。他のリージョンのデータベースの場合、変換のために us-east-1 にクローンしてください。 AWS アカウントで IAM Identity Center が有効化されていること Microsoft SQL Server バージョン 2008 R2 から 2022 (すべてのエディションがサポートされています)。SQL Server は AWS 上または AWS 外でホストできます。 オプション (.NET アセスメント用): .NET Core 6、7、8、または 10 アプリケーション。レガシーな .NET Framework 4.x 以前はサポートされていません。 ウォークスルー 以下のセクションでは、Offline Source ワークフローの各ステージを説明します。 ステップ 1: SQL Server DDL を抽出してアップロード AWS Transform は DDL を抽出するための 2 つの方法を提供します : オプション 1 (推奨): 変換ジョブを作成すると、AWS Transform は SQL Server に対して実行する抽出スクリプト ( ExtractDatabaseMetadata.ps1 ) を提供します。このスクリプトはデータベースごとに SQL Server オブジェクトタイプ (テーブル、ストアドプロシージャ、関数、トリガーなど) の DDL 定義を抽出し、複数の機能領域 (SSIS、SSRS、Service Broker、Agent Jobs など) を検出するため、アセスメントに最も完全な情報を提供します。 オプション 2 (手動): SSMS または sqlpackage を使用して SQL DDL ファイル ( CREATE TABLE 、 CREATE PROCEDURE  などのステートメント) を手動でエクスポートし、zip にしてアップロードします。各 SQL ファイルには 1 つのデータベースのステートメントのみを含める必要があります。 結果の DDL ファイル (または zip) を AWS Transform にアップロードして Offline Source を作成します。 ステップ 2: アセスメントの確認 AWS Transform はすべてのデータベースオブジェクトの複雑さと依存関係を分析します。アセスメントレポートには以下が含まれます : オブジェクト間の関連性を可視化する依存関係マップ 各オブジェクトの複雑さスコア (Simple、Moderate、Complex) 手動変換と自動変換の作業量 (LOE) の見積もり エージェントによる自動化で削減できる工数と、人的レビューが必要な部分の内訳 アセスメントでは、PostgreSQL のイベントトリガーへの置き換えが必要な DDL トリガーや、例外ブロック内でのみ有効な構文を使用している関数など、手動レビューが必要になる可能性のある項目も識別されます。これらの情報をもとに、変換開始前にチームの作業計画を立てることができます。 ステップ 3: 変換をカスタマイズ アセスメントを確認した後、AWS Transform は変換の実行方法を定義する変換プランを生成します。プランは実行戦略、フェーズの順序付け、変換ルール、インフラストラクチャー構成を単一のレビュー可能なアーティファクトに統合します。デフォルトを受け入れて進めることも、変換開始前に任意の側面をカスタマイズすることもできます。 変換プランは 4 つの領域をカバーします : 実行ウェーブ – データベースはウェーブ順に変換され、各ウェーブ内で最大 5 つのデータベースが並行して実行されます。次のウェーブは現在のウェーブのすべてのデータベースが完了した後にのみ開始されます。ウェーブ間でデータベースの順序を変更したり、完全に除外したりできます。 ジョブプラン – 変換ジョブのフェーズの順序 (スキーマ変換、ターゲットプロビジョニング、スキーマデプロイ、コード変換、およびオプションの合成テストデータ生成)。必要に応じてオプションフェーズをスキップできます。 変換およびカスタムルール – 型マッピング (例: SQL Server の MONEY から PostgreSQL の DECIMAL(19,4) )、スキーマ名マッピング (例: 単一データベース移行での dbo から public )、関数マッピング (例: GETDATE から CURRENT_TIMESTAMP )、IDENTITY 列戦略 ( GENERATED BY DEFAULT または GENERATED ALWAYS )、およびプロシージャ結果のハンドリング (refcursor または関数リターンスタイル)。適切なデフォルトが自動的に適用されるため、ユースケースに合わないものだけを変更するだけで済みます。 ターゲットプロビジョニング構成 – 新しい Aurora PostgreSQL クラスターを作成するか既存のものに接続するか、およびインスタンスクラス、ネットワーク設定、資格情報管理。 これらの設定は、コンソールでプランを直接編集するか、自然言語でプリファレンスを記述するか、JSON 構成ファイルを提供することでカスタマイズできます。例えば、「MONEY を DECIMAL(19,4) にマッピングし、dbo に public を使用し、GENERATED ALWAYS で IDENTITY 列を生成する」とリクエストすると、AWS Transform が該当するルールを適用します。 ステップ 4: LLM ベースのスキーマ変換の実行 AWS Transform では、大規模言語モデル (LLM) を使用して SQL Server スキーマオブジェクトを PostgreSQL に変換します。変換はコンテキストを考慮し、構文だけでなくビジネスロジックの意図を保持します。 変換はステージごとに進行します: 基盤オブジェクト (スキーマ、シーケンス、シノニム、ユーザー定義型) テーブルと主キー 制約とインデックス プログラマブルオブジェクト (ストアドプロシージャ、関数、ビュー、トリガー) LLM ベースのアプローチは、ルールベースのツールでは通常手動変換が必要な複雑な T-SQL パターンやプロプライエタリな SQL Server 構文を処理します。これにより、自動変換率が向上し、手動介入が減少します。 ステップ 5: 変換済みオブジェクトの検証 変換されたオブジェクトは、以下の 3 層の自動検証を通過します : 構造的検証 は、変換された PostgreSQL スキーマが構文的に正しくデプロイ可能であることを確認します。 意味的検証 は、変換されたオブジェクトがソースの論理的な意味と動作を保持していることを検証します。 機能的検証 は、ソースとターゲット間のクエリ動作を比較し、本番環境に影響する前に差異を検出します。 各検証パスでは分離されたサンドボックスが起動し、ソースとターゲット両方のスキーマをロードした上で、型マッピング、制約、ルーチンを検査する AI エキスパートレビュワーが実行されます。AWS Transform はストレージオブジェクトの変換後とコードオブジェクトの変換後にそれぞれ検証レポートを生成します。各レポートでは、カテゴリごと (テーブル、列、制約、インデックス、ビュー、プロシージャ、関数) に Pass、Warning、Fail の結果が示されます。 検証完了後、エキスパートアセスメントが全体の変換を評価します : Ready: オブジェクトが完全に変換および検証済み Conditional: オブジェクトが変換済みで、レビュー用にマイナーな問題がフラグ付けされている Not Ready: 手動介入が必要なオブジェクト ステップ 6: 残りの問題への対応 Conditional または Not Ready と評価されたオブジェクトについて、AWS Transform は具体的な次のステップを含む Schema Conversion Report を提供します。2 つのオプションがあります : 組み込みの AWS Transform Web コンソールを使用して、ローカル IDE のインストールなしにブラウザで直接変換の問題を確認して修正する。 または、Kiro や他のローカル AI コーディングアシスタントと  AWS Transform MCP Server  を使用して、好みの IDE にアーティファクトを取得する。 修正を加えた後に検証を再実行し、スキーマ全体が検証に合格するまで繰り返しデプロイできます。 Web コンソールでは、変換レポートの確認、SQL の編集、検証の再実行、変更のデプロイまでをブラウザ上で一貫して行えます。ローカル開発を好むチームには、MCP Server を使って IDE から AWS Transform ワークスペースに接続して普段の開発ワークフローのまま、同じアーティファクトとデプロイ機能を利用できます。 ステップ 7: Aurora PostgreSQL にデプロイ 検証が完了したら、AWS Transform に AWS アカウントへのアクセスを付与するデータベースコネクタを設定します。AWS Transform はターゲットの Aurora PostgreSQL クラスターをプロビジョニングし、変換済みスキーマをデプロイします : 既存のクラスターを選択するか、AWS Transform に新しいクラスターを作成させます。 AWS Transform が変換済みオブジェクトをターゲットに適用します。 データベース資格情報が生成され、AWS Secrets Manager に保存されます。 問題がないかデプロイレポートを確認します。 デプロイ後、継続的な運用に不要な場合は、オプションで RDS Data API を無効にできます。 ステップ 8: .NET アプリケーションコードのアセスメントおよび変換 スキーマのデプロイが完了すると、コード変換が実行可能になります。アプリケーションのアセスメントと変換を行うために、.NET Core (6、7、8、または 10) のソースコードリポジトリを接続します。アプリケーションのデータベースアクセスには ADO.NET または Entity Framework (6.3-6.5、または EF Core 1.0-8.0) を使用している必要があります。なお、アセスメントはスキーマデプロイ前でも開始できますが、コード変換にはスキーマが先にデプロイされている必要があります。 ソースコードへの接続には、以下を使用できます :   AWS CodeConnections (GitHub、GitLab、または Bitbucket リポジトリ用) ソースコードの直接アップロード用の Amazon S3 AWS Secrets Manager  に保存する Personal Access Token (PAT) 接続すると、AWS Transform は : コネクタを通じて利用可能なリポジトリを検出します。 ソースコードをダウンロードして分析し、データベース参照、Entity Framework モデル、接続文字列、SQL クエリパターンを識別します。 モダナイゼーションの複雑さ (Low、Medium、High) と具体的な変換レコメンデーションを含むアプリケーションアセスメントレポートを生成します。 アセスメント完了後、コード変換を開始して .NET アプリケーションコードを Aurora PostgreSQL をターゲットとするように更新できます。コード変換はスキーマ変換の結果を使用して、アプリケーション内の接続文字列、ORM マッピング、インライン SQL クエリを更新します。 ステップ 9: テストデータで検証する (オプション) AWS Transform は本番データを公開することなく、ターゲットクラスターに検証用のテストデータを生成できます。テストデータ生成レポートには何が作成されたかが記載され、代表的なデータボリュームに対してストアドプロシージャ、ビュー、アプリケーションクエリの徹底的なテストが可能になります。 クリーンアップ このウォークスルー中にテスト目的で新しい Aurora PostgreSQL クラスターを作成した場合 : Amazon RDS console に移動します。 作成したクラスターを選択します。 Actions > Delete を選択します。 削除を確認します。 AWS Transform ワークスペースは追加料金なしでそのまま残しておけるため、後から参照することができます。 まとめ AWS Transform for SQL Server の Offline Source を使うことで、SQL Server モダナイゼーションにおける 2 つの大きな障害、すなわち「始めるまでのハードル」と「スキーマ変換の精度・検証」を解消できます。稼働中のデータベースへの接続設定は不要で、DDL ファイルをアップロードするだけで始められます。インフラストラクチャーのプロビジョニングなしに、スキーマのアセスメントから変換、検証、Aurora PostgreSQL へのデプロイまでを実行できます。さらに .NET ソースコードリポジトリを接続すれば、データベースと合わせてアプリケーションコードの変換も可能です。これらすべてが単一の統合ワークフローで完結します。 Offline Source を開始するには、 AWS Transform console  を開いて最初の変換ワークスペースを作成してください。詳細については、 AWS Transform ドキュメント を参照してください。モダナイゼーションターゲットとしての Aurora PostgreSQL の詳細については、 Amazon Aurora PostgreSQL-Compatible Edition  を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 Vikas Babu Gali Vikas Babu Gali は Amazon Web Services のシニアスペシャリストソリューションアーキテクトで、SQL Server の移行、モダナイゼーション、クラウドデータベース変換を専門としています。Vikas は Fortune 500 企業の多くのお客様を大規模なミッションクリティカルなクラウド変換でガイドしてきました。 Nits Jeganathan Nits Jeganathan は AWS Transform のプロダクトリーダーで、15 年の IT 業界経験、12 件の特許、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションに関する 2 件の出版物を持っています。Nits は複雑な課題の解決とカスタマーエクスペリエンスの改善に情熱を注いでいます。現在は生成 AI を使用したレガシーアプリケーションのモダナイゼーション加速に注力しています。 Shashank Kalki Shashank Kalki は Amazon Web Services のデータベース移行スペシャリストソリューションアーキテクトです。お客様と連携して最も困難なデータ移行の課題を解決し、Amazon Aurora と Amazon RDS への移行の計画、実行、最適化を支援しています。専門分野は大規模な異種データベース変換と移行のベストプラクティスです。

本記事は 2026 年 8 月 11 日 に公開された「 Natural language queries on Oracle Database 26ai: Getting started with Select AI on Amazon RDS for Oracle with Amazon Bedrock 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Oracle で Oracle Database 26ai が利用可能になりました。Amazon RDS における Oracle 初の AI ネイティブなデータベースリリースで、生成 AI、ベクトル検索、機械学習がエンジンに直接組み込まれています。バックアップ、パッチ適用、マルチ AZ による高可用性、リードレプリカは Amazon RDS が処理するため、インフラストラクチャの管理ではなく AI アプリケーションの構築に集中できます。 本記事では、新機能のなかでも特に効果の大きい Select AI を紹介します。Select AI では、Amazon Bedrock の基盤モデル (FM) を使い、自然言語のプロンプトでリレーショナルデータを照会できます。「今四半期の売上上位 5 社の顧客は?」とデータベースに尋ねれば、コードを 1 行も書かずに、正しい SQL とその実行結果が返ってきます。内部では、Oracle の DBMS_CLOUD_AI パッケージがテーブルのスキーマを含むプロンプトを組み立て、選択した基盤モデルに送信します。生成された SQL を実データに対して実行し、結果を返すまでのすべてが同一のデータベースセッション内で完結します。 このアーキテクチャなら、AI インフラストラクチャを自前で構築する運用負荷がなくなります。Amazon Bedrock はフルマネージドかつサーバーレスです。プロビジョニングする GPU も、ホストするモデルも、維持する推論エンドポイントもありません。Anthropic、Meta、Amazon といったプロバイダーの基盤モデルに単一の API でアクセスでき、 DBMS_CLOUD_AI プロファイルの属性を 1 つ変えるだけでモデルを切り替えられます。セキュリティは、すでに使い慣れた Amazon RDS のモデルに従います。Select AI のリクエストは Virtual Private Cloud (VPC) インターフェイスエンドポイントを経由するため、データは VPC 内に留まり、パブリックインターネットを通りません。 DBMS_CLOUD_AI はネイティブな PL/SQL なので、すでに持っている SQL のスキルで生成 AI 機能を構築できます。別途 AI スタックを学んだり維持したりする必要はありません。 本記事は、Amazon RDS 上の Oracle Database 26ai の AI 機能を扱う 3 回シリーズの第 1 回です。今回は、Amazon Bedrock の認証情報の設定から自然言語クエリの実行まで、Select AI を一通り解説します。第 2 回では Oracle AI Vector Search による Retrieval Augmented Generation (RAG) を、第 3 回では SQL プロパティグラフを使った GraphRAG を取り上げ、グラフ探索、ベクトル検索、リレーショナルなフィルタリングを 1 つの SQL クエリで組み合わせる方法を紹介します。 Amazon RDS 上の Oracle Database 26ai の AI 機能 Amazon RDS 上の Oracle Database 26ai と Amazon Bedrock を組み合わせると、次の機能が使えます。 機能 内容 ユースケースの例 Select AI (NL2SQL) 自然言語のプロンプトを SQL に変換し、クエリを実行して、単一の SQL セッション内で結果を返す ビジネスアナリストが SQL を書かずに売上データを照会する。経営層がダッシュボードから即座に答えを得る DBMS_CLOUD_AI.GENERATE PL/SQL から基盤モデルを呼び出し、チャット、要約、翻訳、合成データ生成を行う CLOB 列に格納されたサポートチケットを要約する。開発/QA 環境向けに現実的なテストデータを生成する。製品説明を翻訳する Oracle AI Vector Search 標準的な SQL でベクトル埋め込みをリレーショナルデータと並べて保存、インデックス化、検索する 製品カタログのセマンティック検索。類似する顧客プロファイルの検索。レコメンデーションエンジンの実現 Retrieval Augmented Generation (RAG) ベクトル検索と大規模言語モデル (LLM) の生成を組み合わせ、AI の回答を実際のビジネスデータに基づかせる 社内文書やデータベースのレコードを使って質問に答える AI アシスタント データベース内 ONNX 推論 埋め込み、分類、回帰などの ML モデルを、外部 API を呼び出さずに Oracle 内部で実行する 挿入時に埋め込みを生成する。不正な取引をリアルタイムで分類する。ラウンドトリップなしでリードをスコアリングする プロパティグラフでの Select AI SQL プロパティグラフに対して、自然言語のプロンプトでグラフの関係を照会する 「サプライヤー X と顧客 Y の間の最短サプライチェーン経路を見せて」 ソリューションの概要 この手順を終えると、次のことができるようになります。 AWS Identity and Access Management (IAM) の認証情報を作成し、 DBMS_CLOUD.CREATE_CREDENTIAL で Oracle 内に格納する。 VPC インターフェイスエンドポイントを設定し、プライベートな Amazon RDS インスタンスからインターネットを経由せずに Amazon Bedrock に到達できるようにする。 Claude Sonnet や Amazon Nova などの Amazon Bedrock の基盤モデルを指す DBMS_CLOUD_AI プロファイルを作成、管理する。 LLM から Oracle のテーブルに合成テストデータを直接生成する。 SELECT AI の SQL 構文を使い、自分のテーブルに対して自然言語クエリを実行する。 DBMS_CLOUD_AI.GENERATE() をチャット、SQL の説明、要約に使う。 次の図は全体のアーキテクチャです。 図 1: Amazon RDS for Oracle 26ai と Amazon Bedrock による Select AI 主なコンポーネントは次のとおりです。 コンポーネント 役割 Amazon RDS for Oracle Database 26ai DBMS_CLOUD_AI を含み、Select AI のクエリを実行する Amazon Bedrock 基盤モデル (Claude、Nova) へのマネージドなアクセスを提供する VPC インターフェイスエンドポイント ( bedrock-runtime ) プライベートな Amazon RDS のサブネットからの Amazon Bedrock API 呼び出しを、インターネットを経由せずにルーティングする IAM 認証情報 DBMS_CLOUD.CREATE_CREDENTIAL で Oracle に格納したアクセスキー ID とシークレット。Oracle がすべての Amazon Bedrock 呼び出しを SigV4 で署名するために使う 動作の流れ: ユーザーが SQL クライアントで自然言語の質問を入力します。Oracle が SELECT AI ステートメントを受け取り、質問と対象テーブルのスキーマメタデータを含むプロンプトを構築します。そして IAM ユーザーのアクセスキーで署名したリクエストを、VPC インターフェイスエンドポイント経由で HTTPS により Amazon Bedrock に送信します。LLM が返した SQL を Oracle が実データに対して実行し、結果セットを返します。ここまでのすべてが同一の SQL セッション内で行われます。 前提条件 始める前に、次を確認してください。 プライベートな VPC サブネットにデプロイした Amazon RDS for Oracle Database 26ai インスタンス。本記事では、データベースインスタンスとして一般的なパターンかつ推奨構成である、プライベートな Amazon RDS for Oracle インスタンスを前提とします。テスト目的であれば、インスタンスをパブリックに公開することもできます。 DBMS_CLOUD パッケージと DBMS_CLOUD_AI パッケージがインストールされていること (確認方法はステップ 1 で説明します)。 IAM ユーザーと VPC エンドポイントを作成する権限を持つ AWS アカウント。 対象の AWS リージョンで Amazon Bedrock が利用できること。Amazon Bedrock ではほとんどの基盤モデルがデフォルトで利用可能です。必要に応じて Amazon Bedrock コンソールの モデルアクセス で確認してください。 踏み台ホストまたは AWS Systems Manager Session Manager のポートフォワーディング経由で Amazon RDS インスタンスに接続した SQL Developer、SQLcl、その他の Oracle SQL クライアント。 Amazon RDS インスタンスに関連付けられた VPC ID、サブネット ID、セキュリティグループ ID。 DBMS_CLOUD と DBMS_CLOUD_AI の両方に EXECUTE 権限を持つデータベースユーザー (例: AIUSER)。必要なら、先に作成しておきます。 GRANT EXECUTE ON DBMS_CLOUD TO AIUSER; GRANT EXECUTE ON DBMS_CLOUD_AI TO AIUSER; ステップ 1: DBMS_CLOUD_AI が利用可能か確認する 設定を始める前に、必要なパッケージがインストールされていることを確認します。Amazon RDS for Oracle 26ai では、インスタンス作成時に DBMS_CLOUD と DBMS_CLOUD_AI がデフォルトでインストールされます。 SELECT object_name, object_type, status FROM dba_objects WHERE object_name IN ('DBMS_CLOUD', 'DBMS_CLOUD_AI') AND object_type IN ('PACKAGE', 'PACKAGE BODY') ORDER BY 1, 2; 4 行が返るはずです。 DBMS_CLOUD と DBMS_CLOUD_AI のそれぞれについて PACKAGE と PACKAGE BODY です。パッケージが見つからない場合は、Amazon RDS インスタンスが Oracle Database 26ai で動作しているか確認してください。 ステップ 2: Amazon Bedrock ランタイム用の VPC インターフェイスエンドポイントを作成する Amazon RDS for Oracle DB インスタンスは、ポート 443 (HTTPS) で Amazon Bedrock ランタイムのエンドポイント ( bedrock-runtime.<region>.amazonaws.com ) に到達できる必要があります。この通信を AWS ネットワーク内のプライベートな経路に留め、インターネットアクセスを不要にするには、Amazon Bedrock ランタイムサービス用の VPC インターフェイスエンドポイントを作成します。Amazon RDS インスタンスをプライベートに保てるため、VPC インターフェイスエンドポイントの利用が推奨されます。本記事の例でも VPC インターフェイスエンドポイントを使います。 もう 1 つの選択肢は NAT ゲートウェイです。NAT ゲートウェイを使う場合、DB インスタンスのサブネットに NAT ゲートウェイ経由でインターネットへ向かうルートが必要です。NAT ゲートウェイの設定は、 ドキュメント の「Amazon VPC network requirements」セクションのオプション 2 を参照してください。 エンドポイントを作成する AWS マネジメントコンソールで VPC 、 エンドポイント 、 エンドポイントを作成 の順に移動します。 サービスカテゴリ で AWS サービス を選択します。 サービス名 の検索で bedrock-runtime と入力し、 com.amazonaws.<your-region>.bedrock-runtime を選択します。 VPC では、Amazon RDS インスタンスがある VPC を選択します。 サブネット では、Amazon RDS の DB サブネットグループが使っているサブネットと同じものを選択します。 セキュリティグループ では、Amazon RDS インスタンスのセキュリティグループからの インバウンド TCP ポート 443 を許可するセキュリティグループをアタッチします。 ポリシー では フルアクセス を選択します。 プライベート DNS 名 を有効にします。ここが重要です。有効にすることで Oracle が bedrock-runtime.<region>.amazonaws.com をプライベート IP に解決し、通信が VPC 内でルーティングされます。 エンドポイントを作成 を選択し、状態が 利用可能 になるまで待ちます。 ステップ 3: Amazon Bedrock エンドポイントへのネットワーク ACL アクセスを許可する Oracle はアクセスコントロールリスト (ACL) でアウトバウンドのネットワークアクセスを制御します。AIUSER ユーザーに、 bedrock-runtime.<your-region>.amazonaws.com への HTTP/HTTPS のアウトバウンド接続を許可します。 BEGIN DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE( host => 'bedrock-runtime.<your-region>.amazonaws.com', ace => xs$ace_type( privilege_list => xs$name_list('connect', 'resolve', 'http'), principal_name => 'AIUSER', principal_type => xs_acl.ptype_db ) ); END; / DNS 解決を確認する エンドポイントが有効になったら、Oracle が Amazon Bedrock のホスト名をプライベート IP に解決することを確認します。 -- Should return a private IP, not a public AWS IP SELECT UTL_INADDR.GET_HOST_ADDRESS( 'bedrock-runtime.<your-region>.amazonaws.com' ) AS resolved_ip FROM dual; 出力例: RESOLVED_IP --------------- 172.31.17.236 ステップ 4: AWS の認証情報を作成し Oracle Database に格納する DBMS_CLOUD_AI は IAM のアクセスキー ID とシークレットアクセスキーで Amazon Bedrock に認証します。設定手順としては、Amazon Bedrock の基盤モデル呼び出しに必要な最小限の権限だけを付与した専用の IAM ユーザーを作成し、そのユーザーのアクセスキーを発行します。認証情報を取得したら、 DBMS_CLOUD.CREATE_CREDENTIAL を呼び出して Oracle データベース内に格納します。Oracle はキーを保存時に暗号化し、 DBMS_CLOUD_AI がアウトバウンドの Amazon Bedrock API リクエストの署名に自動的に使用します。 ステップ 4a: Amazon Bedrock アクセス用の IAM ユーザーを作成する 次のポリシーを持つ IAM ユーザーまたはロールを作成します (既存の ID にアタッチしても構いません)。 { "Version": "2012-10-17", "Statement": [{ "Sid": "BedrockInvoke", "Effect": "Allow", "Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"], "Resource": ["arn:aws:bedrock:region::foundation-model/*"] }] } 特定のモデルだけにアクセスを制限するには、ワイルドカードを次のように個別のモデル ARN に置き換えます。 arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-4-5-20250929-v1:0 ステップ 4b: アクセスキーを発行する 作成したユーザーを開き、 セキュリティ認証情報 タブに移動します。 アクセスキー で アクセスキーを作成 を選択します。 ユースケースを選択し、 アクセスキーを作成 を選択します。 アクセスキー ID とシークレットアクセスキーをコピーまたはダウンロードします。 セキュリティに関する注意: アクセスキーは長期的な認証情報です。本番環境では、IAM コンソールで定期的にローテーションすることを検討してください。この IAM ユーザーにはコンソールアクセス (パスワード) を与えないようにします。 ステップ 4c: IAM ユーザーのアクセスキーを Oracle に格納する Amazon Bedrock のモデルアクセス: 2025 年時点で、Amazon Bedrock のほとんどの基盤モデルはデフォルトで利用可能で、明示的な有効化は不要です。アカウントとリージョンでのモデルの利用可否は、 Amazon Bedrock コンソール の モデルアクセス で確認または変更できます。Amazon RDS for Oracle 26ai の DBMS_CLOUD_AI で動作を検証済みのモデルは次のとおりです。 モデル名 モデル ID 備考 Anthropic Claude Sonnet 4.6 us.anthropic.claude-sonnet-4-6 NL2SQL の精度が最も高い (推奨) Anthropic Claude Haiku 4.5 us.anthropic.claude-haiku-4-5-20251001-v1:0 最速 / 最低コスト Amazon Nova Pro us.amazon.nova-pro-v1:0 高性能な AWS ネイティブモデル Amazon Nova Lite amazon.nova-lite-v1:0 単純なクエリ向けの超高速モデル 重要: クロスリージョン推論のプレフィックス: Anthropic Claude と Amazon Nova Pro のモデル ID には us. プレフィックスが必要です。このプレフィックスによってリクエストがクロスリージョン推論プロファイル経由でルーティングされ、可用性が高まります。プレフィックスのないベースモデル ID を使うと ORA-20400: HTTP 400 が返ります。 DBMS_CLOUD.CREATE_CREDENTIAL を使い、ステップ 4a で取得したアクセスキーとシークレットキーを Oracle の認証情報ストアに格納します。Oracle は認証情報を暗号化し、所有ユーザーだけがアクセスできるようにします。 BEGIN DBMS_CLOUD.CREATE_CREDENTIAL( credential_name => 'AWS', username => '<your-access-key-id>', password => '<your-secret-access-key>' ); END; / 認証情報が正しく作成されたか確認します。 SELECT credential_name, username, enabled FROM all_credentials WHERE credential_name = 'AWS'; username 列には指定したアクセスキー ID が表示されます。シークレットキーは暗号化されて格納され、クエリでは返りません。 ステップ 5: サンプルテーブルを作成する Select AI のデモには E コマースのスキーマを使います。既存のテーブルがある場合は、ステップ 6 に進んでプロファイルの object_list で自分のテーブルを指定してください。 CREATE TABLE customers ( customer_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, first_name VARCHAR2(50), last_name VARCHAR2(50), email VARCHAR2(100), city VARCHAR2(50), country VARCHAR2(50), signup_date DATE, segment VARCHAR2(20) -- 'PREMIUM', 'STANDARD', 'NEW' ); CREATE TABLE products ( product_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, product_name VARCHAR2(100), category VARCHAR2(50), unit_price NUMBER(10,2), stock_qty NUMBER ); CREATE TABLE orders ( order_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, customer_id NUMBER REFERENCES customers(customer_id), order_date DATE, status VARCHAR2(20), -- 'COMPLETED', 'PENDING', 'CANCELLED' total_amount NUMBER(10,2) ); CREATE TABLE order_items ( item_id NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, order_id NUMBER REFERENCES orders(order_id), product_id NUMBER REFERENCES products(product_id), quantity NUMBER, unit_price NUMBER(10,2) ); ステップ 6: DBMS_CLOUD_AI プロファイルを作成する プロファイル は Select AI の中心となる設定オブジェクトです。AI プロバイダー、認証情報、呼び出す Amazon Bedrock のモデル、そしてプロンプトのコンテキストにスキーマを含めるデータベーステーブルを指定します。 DBMS_CLOUD_AI はデフォルトで bedrock-runtime.us-east-1.amazonaws.com に接続します。us-east-1 以外のリージョンの Amazon Bedrock ランタイムエンドポイントを使う場合は、プロファイル属性の JSON に region 属性と target_language 属性を含めます。 region には Amazon Bedrock ランタイムエンドポイントがあるリージョン (例: us-west-2) を設定します。 region を設定する場合は、 target_language (または source_language ) も含める必要があります。 chat や runsql のように翻訳を使わないアクションでも、この 2 つの属性は必ずセットで設定してください。 target_language の値が影響するのは translate アクションだけです。セットで指定しなければならないのは、Oracle の DBMS_CLOUD_AI パッケージに既知の制限があるためです。 region なしで target_language だけを指定した場合、プロファイルは bedrock-runtime.us-east-1.amazonaws.com を使い続けます。VPC インターフェイスエンドポイントが別のリージョンにあると、Oracle はエンドポイントが存在しないリージョンへパブリックインターネット経由で接続を試み、ネットワーク構成でパブリックアクセスを許可していない限り、すべての呼び出しが ORA-30699 でタイムアウトします。 次の例では、Amazon Bedrock のクロスリージョン推論 (CRIS) 経由で Anthropic Claude Sonnet 4.6 を使うプロファイルを作成します。 BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'CLAUDE_SONNET', attributes => '{"provider": "aws", "credential_name": "AWS", "region": "<your-bedrock-region>", "model": "us.anthropic.claude-sonnet-4-6", "target_language": "en", "object_list": [ {"owner": "AIUSER", "name": "CUSTOMERS"}, {"owner": "AIUSER", "name": "PRODUCTS"}, {"owner": "AIUSER", "name": "ORDERS"}, {"owner": "AIUSER", "name": "ORDER_ITEMS"} ] }' ); END; / object_list は、LLM 向けのスキーマコンテキストを構築するときに含めるテーブルとビューを Oracle に伝えます。Oracle はデータディクショナリから列名、データ型、列コメントを自動的に読み取り、プロンプトに組み込みます。スキーマを手作業で記述する必要はありません。 異なるモデルを指すプロファイルを複数作成し、セッションごとに切り替えることもできます。 -- Amazon Nova Pro profile BEGIN DBMS_CLOUD_AI.CREATE_PROFILE( profile_name => 'NOVA_PRO', attributes => '{"provider": "aws", "credential_name": "AWS", "region": "<your-bedrock-region>", "model": "us.amazon.nova-pro-v1:0", "target_language": "en", "object_list": [ {"owner": "AIUSER", "name": "CUSTOMERS"}, {"owner": "AIUSER", "name": "PRODUCTS"}, {"owner": "AIUSER", "name": "ORDERS"}, {"owner": "AIUSER", "name": "ORDER_ITEMS"} ] }' ); END; / セッションでプロファイルを有効化し、確認します。 EXECUTE DBMS_CLOUD_AI.SET_PROFILE('CLAUDE_SONNET'); -- Confirm active profile SELECT DBMS_CLOUD_AI.GET_PROFILE() FROM dual; -- List all profiles SELECT profile_name, status FROM user_cloud_ai_profiles; ステップ 7: 合成データを生成する Amazon Bedrock にアクセスできる AI プロファイルを設定したら、 DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA でテーブルに現実的なテストデータを自動投入できます。 GENERATE_SYNTHETIC_DATA は、指定した AI プロファイル経由で LLM を使い、文脈に沿ったレコードを生成します。 object_list パラメータには、対象テーブルとそれぞれの生成レコード数を指定する JSON 配列を渡します。 次の PL/SQL ブロックを実行して、4 つのテーブルに合成データを生成します。 BEGIN DBMS_CLOUD_AI.GENERATE_SYNTHETIC_DATA( profile_name => 'CLAUDE_SONNET', object_list => '[ {"owner": "AIUSER", "name": "CUSTOMERS", "record_count": 50}, {"owner": "AIUSER", "name": "PRODUCTS", "record_count": 250}, {"owner": "AIUSER", "name": "ORDERS", "record_count": 500}, {"owner": "AIUSER", "name": "ORDER_ITEMS", "record_count": 1000} ]' ); END; / 実行すると、顧客 50 件、製品 250 件、注文 500 件、注文明細 1,000 件が生成されます。テストデータを手作業で作り込まなくても、クエリ、レポート、アプリケーションロジックの検証に使える現実的なデータセットが手に入ります。 内部では、Oracle が対象テーブルの DDL、制約、メタデータを読み取り、データ型と外部キーを満たす現実的な行を生成するよう LLM にプロンプトを出します。生成方法は次の要素でカスタマイズできます。 sample_rows : 既存のレコードを例として渡し、生成されるデータを実データのスタイルに合わせます。 user_prompt : 「英国の郵便番号のみ」「2009 年公開の映画」といったルールを指定します。 テーブル統計 (デフォルトで有効): 列の最大値・最小値と個別値のリストを使って出力範囲を制限します。 列コメント: 列にヒント (例: 許可される Status の値) を付けると、LLM は生成時にヒントに従います。 一意制約: LLM のレスポンスから重複行を自動的に破棄します。 ステップ 8: Select AI で自然言語クエリを実行する プロファイルを設定してデータを投入したら、 SELECT AI の SQL 構文で平易な英語のままリレーショナルデータを照会できます。Oracle はステートメントを受け取り、質問と object_list のテーブルスキーマメタデータを組み合わせたプロンプトを構築し、Amazon Bedrock のモデルを呼び出して結果を返します。 実行前に生成された SQL を確認する showsql を使うと、LLM が生成した SQL を実行せずに確認できます。精度の検証や信頼性の確認に役立ちます。 SELECT AI showsql how many customers do we have per country; 出力例: SELECT country, COUNT(*) AS customer_count FROM customers GROUP BY country ORDER BY customer_count DESC 実行して結果を返す runsql に切り替えると、生成された SQL を実行して結果を返します。 SELECT AI runsql how many customers do we have per country; SELECT AI runsql what is the total revenue by product category; SELECT AI runsql who are the top 3 customers by total spend; SELECT AI runsql how many orders were cancelled; SELECT AI runsql show me all pending orders with customer name and amount; 結果を自然言語の文章で返す narrate アクションは、クエリ結果を平易な英語で要約して返します。ビジネスレポートやダッシュボードに適しています。 SELECT AI narrate give me a sales summary for 2024; SELECT AI narrate who are our best customers and what do they buy; 1 つ目のクエリの出力例: Based on the 2024 sales data, total completed revenue is $14,299.98 across six completed orders. Frank Wilson is the top-spending customer at $7,000.00, followed by Alice Johnson at $6,099.99. The Software category leads all product categories in revenue. Two orders remain in Pending status with a combined value of $2,500.00. 既存の SQL を平易な英語で説明する explainsql アクションは、既存の SQL クエリを受け取って平易な英語の説明を返します。ドキュメント作成やオンボーディングに役立ちます。 SELECT AI explainsql SELECT c.first_name, c.last_name, SUM(o.total_amount) AS total FROM customers c JOIN orders o ON c.customer_id = o.customer_id WHERE o.status = 'COMPLETED' GROUP BY c.first_name, c.last_name ORDER BY total DESC; 出力例: Query Analysis & Oracle SQL Conversion Original Query Issues: - Missing schema names - Missing double quotes around case-sensitive identifiers - 'COMPLETED' is not in double quotes in the question; must use UPPER() for case-insensitive comparison Converted Oracle SQL: SELECT c."FIRST_NAME" AS first_name, c."LAST_NAME" AS last_name, SUM(o."TOTAL_AMOUNT") AS total FROM "AI_TEST"."CUSTOMERS" c JOIN "AI_TEST"."ORDERS" o ON c."CUSTOMER_ID" = o."CUSTOMER_ID" WHERE UPPER(o."STATUS") = UPPER('COMPLETED') GROUP BY c."FIRST_NAME", c."LAST_NAME" ORDER BY total DESC; ステップ 9: DBMS_CLOUD_AI.GENERATE() を他の AI タスクに使う SELECT AI 構文に加えて、 DBMS_CLOUD_AI.GENERATE() を使うと Amazon Bedrock のモデルに直接アクセスできます。自由形式のチャット、要約、プロンプトからの SQL 生成のように、データベースのスキーマコンテキストを必要としないタスクに使えます。 テキストを要約する SELECT DBMS_CLOUD_AI.GENERATE( prompt => 'Oracle Database 26ai introduces AI Vector Search, hybrid BM25 and semantic search, an embedded ONNX inference runtime, SQL/PGQ property graph queries, JSON-Relational Duality Views, native BOOLEAN type, and lock-free reservations for high-concurrency workloads.', profile_name => 'CLAUDE_SONNET', action => 'summarize' ) AS summary FROM dual; インラインのテキストを要約するだけでなく、 DBMS_CLOUD_AI.GENERATE を Amazon Simple Storage Service (Amazon S3) バケットに保存された文書を直接処理することもできます。次のクエリは Amazon S3 から PDF を取得し、 DBMS_VECTOR_CHAIN.UTL_TO_TEXT でテキストに変換します。そのうえで内容を LLM に渡して要約させます。ここまでを 1 つの SQL ステートメントで実行します。 SELECT DBMS_CLOUD_AI.GENERATE( prompt => DBMS_VECTOR_CHAIN.UTL_TO_TEXT( DBMS_CLOUD.GET_OBJECT( credential_name => 'AWS', object_uri => 'https://s3.us-west-2.amazonaws.com/<Bucket Name>/<File Name>')), profile_name => 'CLAUDE_SONNET', action => 'SUMMARIZE') FROM DUAL; / 内部では、3 つの関数が 1 つの SQL ステートメント内で連鎖します。 DBMS_CLOUD.GET_OBJECT が指定した認証情報を使って Amazon S3 バケットから PDF 文書を取得します。 DBMS_VECTOR_CHAIN.UTL_TO_TEXT がバイナリの内容を LLM が処理できるプレーンテキストに変換します。 DBMS_CLOUD_AI.GENERATE が抽出したテキストを AI プロファイル経由で Amazon Bedrock に送信し、要約を返します。Amazon RDS for Oracle インスタンスから Amazon S3 に到達できるようにするには、前提条件が 2 つ追加で必要です。1 つは Amazon S3 用の VPC ゲートウェイエンドポイントで、Amazon RDS のサブネットに関連付けられたルートテーブルに追加し、通信をパブリックインターネットから切り離します。もう 1 つは対象バケットへの s3:GetObject と s3:ListBucket の権限を付与する IAM ポリシーで、ステップ 4a で作成したユーザーにアタッチします。 トラブルシューティング 次の表に、遭遇しやすいエラーと根本原因、対処方法をまとめます。 エラー 根本原因 対処 ORA-30699: network connection failed: connection timed out bedrock-runtime の VPC エンドポイントがない、またはプロファイルの "region" が未指定か誤っている 正しいリージョンに bedrock-runtime の VPC インターフェイスエンドポイントを作成する。すべてのプロファイルに "region": "<your-region>" を追加する DNS がパブリック IP に解決される VPC エンドポイントでプライベート DNS 名が有効になっていない エンドポイントを編集してプライベート DNS 名を有効にする ORA-20400: HTTP 400 モデル ID が単一リージョン / オンデマンドの形式 (旧形式) になっている モデル ID にクロスリージョン推論の us. プレフィックスを追加する ORA-20404: HTTP 404 そのリージョンでモデルが利用できない、またはアクセスが有効になっていない Amazon Bedrock → モデルアクセスでリージョンでのモデルの利用可否を確認する。モデル ID が正しいことを確認する ORA-20400: HTTP 403 IAM ユーザーに bedrock:InvokeModel の権限がない BedrockInvokeModelPolicy が IAM ユーザーにアタッチされているか確認する ORA-20001: profile not found プロファイルが作成されていない、または名前が間違っている SELECT profile_name FROM user_cloud_ai_profiles を実行する ORA-29024: Certificate validation failure Oracle ウォレットに Amazon Bedrock の CA 証明書がない Amazon RDS では file:/rdsdbdata/rds-metadata/dbms_cloud_wallet にプリインストールされたウォレットに必要な CA が含まれているため、対応は不要 クリーンアップ この手順で作成したリソースを削除するには、次を実行します。 -- Drop AI profiles EXECUTE DBMS_CLOUD_AI.DROP_PROFILE('CLAUDE_SONNET'); EXECUTE DBMS_CLOUD_AI.DROP_PROFILE('NOVA_PRO'); -- Drop the Bedrock credential EXECUTE DBMS_CLOUD.DROP_CREDENTIAL('AWS'); -- Drop sample tables (if created for this walkthrough) DROP TABLE order_items; DROP TABLE orders; DROP TABLE products; DROP TABLE customers; AWS マネジメントコンソールでは、次の手順を実行します。 IAM → ユーザー で、ステップ 4a で作成した IAM ユーザーを削除します。 VPC → エンドポイント で、 bedrock-runtime の VPC インターフェイスエンドポイントを削除します。 まとめ 本記事では、AI プロバイダーとして Amazon Bedrock を使い、Amazon RDS for Oracle Database 26ai で Select AI を設定する一連の手順を説明しました。IAM コンソールでの AWS 認証情報の作成、Oracle への認証情報の格納、VPC エンドポイントのセットアップ、自然言語クエリの実行までを、パブリックインターネットアクセスのないプライベートな Amazon RDS インスタンスで行いました。 Select AI を使えば、データを活用する人に SQL のスキルは不要になり、AI のロジックは信頼できる Oracle 環境の内側に留まります。ビジネスアナリストは SQL Developer や Oracle に接続したツールから、平易な英語で本番データを直接照会できます。データベース管理者は、モデルに公開するテーブル、有効にする基盤モデル、使用する IAM 認証情報を完全に制御し続けられます。いずれも Oracle 標準のプロファイルと認証情報の仕組みで管理できます。 本記事は Oracle Database 26ai と Amazon Bedrock を扱う 3 回シリーズの第 1 回です。 第 1 回 (本記事): Amazon RDS での Select AI と DBMS_CLOUD_AI による自然言語クエリ。 第 2 回: Oracle 26ai のネイティブなベクトル検索と Amazon Bedrock による RAG パイプラインの構築。 第 3 回: Amazon RDS 上の Oracle Database 26ai と Amazon Bedrock によるデータベース内 GraphRAG。 著者について Yamuna Palasamudram Yamuna は AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。AWS のリレーショナルデータベースチームで、Oracle などの商用データベースエンジンを担当しています。お客様と協力して AWS 上のリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援し、技術的なガイダンスを提供することにやりがいを感じています。 Ibrahim Emara Ibrahim は Amazon Web Services のデータベーススペシャリストソリューションアーキテクトで、AWS のお客様向けにデータベースソリューションの設計と実装を担当しています。Oracle、PostgreSQL、Amazon Aurora、AWS Database Migration Service に関する専門知識を活かし、クラウド移行の推進とデータベースパフォーマンスの改善に取り組んでいます。 Minu Hong Minu は AWS の Amazon RDS for Oracle のシニアプロダクトマネージャーです。クラウドネイティブかつ AI を活用したソリューションで、お客様がデータの可能性を最大限に引き出せるよう支援することに情熱を注いでいます。仕事以外では、旅行、テニス、スキー、料理を楽しんでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

Gilead (訳注: 米国バイオ製薬企業) 傘下の企業である Kite (訳注: がん治療に特化した米国医薬品企業)は、細胞治療によって治癒を実現することに注力しており、現代の研究が求める規模と複雑さに対応するため、バイオインフォマティクス基盤を進化させてきました。断片化されたプロジェクト固有のワークフローから、標準化されたクラウド対応のアプローチへ移行することで、Kite は一貫性を高め、運用負荷を軽減し、研究チーム全体で計算ツールへのアクセスを拡大しました。 この取り組みは、複雑な生物学的データを、細胞治療候補の開発に資する知見へと変換する Kite の能力を支えています。これらの変化は、プログラム横断での再現性とスケーラビリティを支えると同時に、科学者がますます複雑化するデータセットから知見を生み出すことにより集中できるようにします。この移行には、レガシーな SaaS プラットフォームから、バイオインフォマティクスのワークフローを高速化するマネージドサービスである AWS HealthOmics への移行が含まれています。 この移行により、バイオインフォマティクスの科学者にとっての効率とコスト管理が改善されると同時に、既存のラボシステムを通じて、より広範なセルフサービス型の計算ワークフローへのアクセスが可能になりました。 課題: 細胞治療のR&Dに向けたバイオインフォマティクスのスケール Kite のバイオインフォマティクス・ゲノミクス部門は、自社ラボで生成した高次元オミクスデータと、公共リポジトリのデータの双方を活用し、治療標的の特定と新規細胞治療の設計を行っています。しかし、このミッションを支える基盤は、科学の進展に合わせて進化させる必要がありました。 プロジェクトごとに、バイオインフォマティシャンはインデックス作成、アライメント、定量化にどのツールを使うかをゼロから判断する必要がありました。スクリプトはローカルマシン、専用サーバー、 AWS Batch 環境などに散在し、プロジェクト間で一貫性がありませんでした。ロギング、実行（ラン）の追跡、成果物の登録に関する標準的なプロセスも存在しませんでした。プロジェクトが完了した際、そのメタデータを誰が所有し、どこに記録すべきかが不明確でした。 「複数のサンプルやプロジェクトにわたって、ワークフローとデータ管理に一貫性をもたらしつつ、チーム横断での再現性とアクセス性を改善できる仕組みが必要でした」と、Kite Pharma のバイオインフォマティクス ディレクターである Alexander Falk 氏は述べています。「HealthOmics 導入以前は、バイオインフォマティクスのパイプラインを実行するには、個々のバイオインフォマティシャンがそれぞれ独自のツールや手法を用いて対応する必要があり、その結果、ワークフローの不統一、高い調整コスト、コミュニケーションのサイロ化が生じていました。また、出力の保存方法や再現性のための結果の文書化についても標準化されたアプローチがありませんでした。私たちの目標は、既存の LIMS と統合された標準化パイプラインを実装し、より広範で一元化されたアクセスを可能にすることでした」 — Alexander Falk 氏、Kite Pharma バイオインフォマティクス ディレクター これらの課題に加えて、サードパーティ製の SaaS ワークフロープラットフォームに対して多額のライセンス料を支払っていましたが、チームは十分に活用しきれていませんでした。この固定費型のライセンスモデルは、断続的・散発的にバッチ処理が発生する製薬 R&D のパターンとかみ合っていませんでした。また、科学者たちは、検体の受け入れ（アクセッショニング）や実験の追跡において、既存の電子実験ノート（ELN：Electronic Laboratory Notebook）を唯一の信頼できる情報源として使用していました。そのため、新たなコンピューティング基盤は、このシステムを置き換えるのではなく、連携できることが求められました。 Kite で最も計算負荷の高いワークロードの 1 つであるシングルセル・トランスクリプトーム解析は、スケーリングの課題を一層深刻なものにしていました。臨床試験プログラムの拡大に伴って全体の検体数が増加する中、ローカル環境での計算処理はもはや現実的な選択肢ではありませんでした。チームには、事前にキャパシティを確保することなく利用できる、柔軟に拡張できる（エラスティック）基盤が必要でした。 目標は、その場しのぎのスクリプト作成から脱却し、ELN と完全に統合された、より標準化・再現可能なアプローチへ移行し、運用の複雑さを軽減しつつ、データから知見を生み出す効率を高めることでした。 スケーラブルなクラウド型バイオインフォマティクスアプローチの実装 AWS Professional Services との協業により、Kite はオンプレミスのシーケンシング基盤とクラウドベースのバイオインフォマティクス ワークフローを接続する、完全自動化・イベント駆動型のゲノミクス パイプラインを設計・展開しました。これらはすべて、科学者が使い慣れた ELN インターフェースを通じてオーケストレーションされます。 イベント駆動アーキテクチャ 全体像として、このソリューションはシーケンサーから科学者までを結ぶ自動化されたデータフローを実行します。 バイオインフォマティシャンがシーケンシングの実行をトリガーし、データセンター内でデマルチプレックスを行って FASTQ データを生成します。 AWS DataSync が、Kite のオンプレミスのファイル共有から Amazon S3 へ、自動スケジュールで FASTQ ファイルをコピーし、手動でのファイル転送を不要にします。 FASTQ ファイルが S3 に到着すると、 AWS Lambda 関数がファイルヘッダーを解析してシーケンシングのメタデータ（機器 ID、ラン ID、フローセル ID、サンプル識別子）を抽出し、REST API を介して ELN に構造化されたレコードを作成します。 ELN インターフェースから、バイオインフォマティシャンが FASTQ エントリ（レコード）を特定の HealthOmics ワークフローに関連付け、パラメータを設定します。 この操作により、ELN が持つ Amazon EventBridge とのネイティブ統合を通じてイベントが発行されます。これが前処理用の Lambda 関数をトリガーし、入力ペイロードを構築して、AWS HealthOmics のプライベート ワークフロー実行を開始します。 次に AWS HealthOmics が、コンテナ化された Nextflow パイプラインを、フルマネージドかつエラスティックな計算リソース上で実行します。プロビジョニングや保守が必要なインフラはありません。ワークフロー出力は、処理済みデータ用のAmazon S3 バケットに生成されます。 ワークフローが完了すると、HealthOmics はステータスイベントを EventBridge に発行します。これが後処理用の Lambda をトリガーし、結果、品質メトリクス、出力ファイルの場所を ELN に書き戻します。 障害処理専用のLambda 関数が Amazon SQS のデッドレターキューをポーリングし、失敗したトランザクションを再処理することで、データの損失がないようにします。 図：Kite Pharma のイベント駆動型アーキテクチャ。Kite のオンプレミスストレージ、Kite の ELN、および AWS サービスの統合を示しています。AWS への自動データ転送を実現し、エンドユーザーからはインフラを抽象化して、ELN をインターフェースとして AWS 上でオミクスデータを処理できるようにします。 研究者の体験 研究者から見ると、クラウド基盤は目に見えません。バイオインフォマティシャンは、自分のワークフロー用にあらかじめ用意された ELN テンプレート（例：「nf-core による scRNA-seq」）を開き、サンプルのエンティティや、参照ゲノム・コア数といったパラメータを入力し、ワークフロー実行を登録します。登録すると、CLI やコンソールへのアクセス、インフラの知識を一切必要とせずに、自動的に実行が開始されます。実行ステータスは進行に応じて ELN 上で動的に更新され、完了すると出力ファイルは親のワークフロー実行に自動的にリンクされ、完全な来歴（プロベナンス）と追跡可能性（トレーサビリティ）が維持されます。 「残された課題の 1 つは、チーム横断で標準化されたワークフローとパラメータについて足並みをそろえることです。これは逆に言えば、技術的な複雑さの多くが日常利用から切り離されて意識されていないことを物語っています。」と、Kite Pharma のバイオインフォマティクス エンジニアリング担当アソシエイト サイエンティストである Tanner MacPhee 氏は述べています。「このプロジェクトの目標は、スケーラブルなバイオインフォマティクス ワークフローを実行する手段を提供することだけでなく、Kite の広範な科学コミュニティ全体でメタデータの取得、モニタリング、アクセス性を改善することでもありました。ELN を入口とすることで、ユーザーは基盤となるインフラを直接管理することなく、自身の ELN エントリとワークフローを直接統合できます。」 — Tanner MacPhee 氏、Kite Pharma バイオインフォマティクス エンジニアリング担当アソシエイト サイエンティスト 主要な設計上の判断 この設計は、Kite の研究および運用上のニーズに沿ったいくつかの優先事項を反映しています。呼び出しごとに課金の Lambda 関数とワークフローの実行ごとに課金される HealthOmics を用いた「サーバーレス ファースト」のアプローチは、アイドル状態のインフラコストを削減するのに役立ちます。双方向の ELN 統合により、メタデータは REST API を介して ELN に書き込まれ、一方で ELN は EventBridge を介して AWS 上のワークフローをトリガーします。プライベート ワークフローにより、Kite はコンテナ化された Nextflow パイプライン、ツールのバージョン、パラメータを完全に制御できます。ソリューション全体は再現性のために Terraform でデプロイされ、すべての Lambda 関数はネットワークレベルのセキュリティ分離のために Kite の VPC 内で実行されます。 成果: 効率化とスケーラブルなアクセス 本番稼働以降、このソリューションはコスト効率、ワークフロー実行、科学者のエクスペリエンスにわたって運用面での改善をもたらしてきました。ソリューションは 18 か月以上にわたり本番環境で稼働しており、AWS HealthOmics 上に 20 種類のバイオインフォマティクス ワークフローが展開され、シングルセル RNA シーケンシング（scRNA-seq）、バルク RNA-seq、全エクソームシーケンシング、タンパク質構造予測、その他の次世代シーケンシング ワークロードを処理しています。 このアプローチはまた、研究ニーズに沿った計算リソースの効率的な利用を可能にし、従来のワークフローにあった非効率を排除しました。「この統合により、解析を実行するために必要だった手作業のステップと依存関係の数が削減され、効率が向上し、チームがデータから知見へとより速く進めるようになりました」と Falk 氏は述べています。 バイオインフォマティクスの科学者たちは、その場しのぎの解析に費やす時間が大幅に減ったと報告しています。インフラのプロビジョニングからメタデータの登録に至るまでの手作業のステップを削減したことで、チームは新規の開発や科学的な業務により多くの時間を割けるようになりました。 現在、100 名を超える研究者が ELN 統合を通じてバイオインフォマティクス ワークフローにアクセスできるようになっています。ワークフローテンプレートに Wiki のような補足情報が付与されているため、たとえば分子生物学者が「タンパク質構造予測（protein structure prediction）」を検索すると、利用可能な AlphaFold Multimer ワークフローを直接発見でき、バイオインフォマティクス担当者を介さずにチーム間の壁（サイロ）を解消につながります。展開済みの 20 種類のワークフローのうち 5 種類は、セルフサービスでの実行のために ELN と完全に統合されており、さらに継続的に追加が進められています。 シーケンサーから直接取得されるデータから、前処理、ELN への登録、そしてクラウドベースのワークフロー内での解析実行に至るまでのフロー全体が、バイオインフォマティクス担当者の介在なしに動作します。このエンドツーエンドの自動化は、18 か月以上にわたって継続的に本番稼働しています。 今後の展開 Kite は AWS HealthOmics を含むクラウド活用型バイオインフォマティクスツールの利用をさらに広げています。デプロイ済みの 20 個のワークフローすべてを ELN からセルフサービスで実行できるようにし、管理されたオントロジーやバリデーション要件との整合も図る計画です。パイプラインの数が増えるのに合わせて、継続的インテグレーションとデプロイの仕組みも強化し、ワークフローのバージョン管理にかかる手作業を減らしています。 さらに先を見て、パイプラインの作成、バリデーション、更新を速めるための AI ベースのツールやエージェントも検討しています。汎用コンピューティング、データカタログ、マルチモーダルな研究データセットでのチーム間コラボレーションに向けた追加ツールの評価も進めています。 「Kite のバイオインフォマティクス＆データサイエンスの領域では、AI によって、バイオインフォマティクスのパイプラインをより迅速かつ一貫して構築、反復、テスト、デプロイできるようになっています。運用のオーバーヘッドを削減し、開発者にかかる時間とコストの負担を軽減しつつ、ワークフロー全体の標準化と検証プロセスを改善しています。HealthOmics により、トランスクリプトミクスからタンパク質・RNA のフォールディングや構造予測に至るまで、計算負荷の高いオミクス解析を、インフラの深い専門知識を必要とせずに実行できます。バイオインフォマティクス データの生成と取り込みが増え続ける中で、効果的なメタデータの取得、登録、検索性の重要性が一層高まっています」と MacPhee 氏は述べています。 — Tanner MacPhee 氏、Kite Pharma まとめ Kite の経験は、同様の課題に直面する製薬・バイオテクノロジー企業に向けた、バイオインフォマティクス基盤の近代化に関するより広範なアプローチを映し出しています。すなわち、科学者のワークフローを妨げることなく、いかにしてバイオインフォマティクス基盤をモダナイズするか、という課題です。既存のラボシステムとの緊密な統合を維持しながら、効率性、標準化、ワークフローへのアクセス性を改善することで、Kite は患者に細胞治療を届けるというミッションに、より多くのリソースを集中できます。 「私たちは、HealthOmics と AWS のサービス群を引き続き活用し、研究者が次世代の治癒的細胞治療を患者のために構築できるよう、革新的な方法を開発していけることに大きな期待を寄せています」と Falk 氏は述べています。 — Alexander Falk 氏、Kite Pharma AWS HealthOmics をはじめよう バイオインフォマティクスのワークフローをモダナイズする準備はできましたか？ AWS HealthOmics のページ で、マネージド基盤によって、あなたのチームがサーバーではなくサイエンスに集中できる方法をご確認ください。無料利用枠でのパイロットから始める、すぐに実行可能な (Ready2Run) ワークフローを試す、あるいは AWS のゲノミクスチーム にユースケースをご相談いただけます。 参考資料 AWS HealthOmics の機能と料金 AWS for Health and Life Sciences AWS HealthOmics と Amazon EventBridge を使ったバイオインフォマティクスワークフローのイベント駆動アーキテクチャ設計 Kite は Gilead 傘下の企業で、CAR T 細胞療法における世界的なリーダーです。詳しくは kitepharma.com をご覧ください。 原文は こちら です。 著者について Nadeem Bulsara AWS のプリンシパル Solutions Architect で、ゲノミクスとライフサイエンスを専門としています。バイオインフォマティクス、ソフトウェアエンジニアリング、クラウド開発で 13 年以上の経験と、研究および臨床のゲノミクス・マルチオミクスの知見を活かし、世界中のヘルスケア・ライフサイエンス企業を支援しています。人々が長く健康な人生を送れるようにするという業界のミッションが原動力です。 Naveen Garg Amazon Web Services のプロフェッショナルサービスチームに所属するシニアクラウドアーキテクトです。Fortune 500 企業のクラウド変革・移行の取り組みを支援しています。 Ryan Greene Amazon Web Services のグローバルヘルスケア・ライフサイエンスチームでシニアプロダクトマーケティングマネージャーを務めています。ビルダーとしての視点と、チームの働き方を変えることへの情熱を持ち、大規模で複雑な課題に取り組むのが好きです。2 人の幼い子どもから刺激を受けており、世界で最も規模の大きな顧客課題やワークロードに新しいアプローチで挑むことに関心を持っています。 Tanner MacPhee Kite Research Bioinformatics のバイオインフォマティクスエンジニアで、大規模オミクスデータを処理・解析するパイプラインの設計を専門としています。次世代の細胞治療の開発に取り組む科学者を支えることを目標に活動しています。バイオインフォマティクスの修士号を持ち、過去 8 年間、腫瘍領域で計算生物学チームと IT チームの両方と仕事をしてきました。 この記事は Solutions Architect の Masahiro Imai が翻訳を担当しました。

本ブログは 株式会社 PKUTECH と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。 機密データを扱う SaaS を AWS 上で構築する際、どのサービスを組み合わせ、どのような設計判断を下せばよいのでしょうか。特に、お客様のコンプライアンス文書や監査指摘事項といった機微な情報を AI に処理させる製品では、データ保護、顧客環境への最小権限アクセスなど、考慮すべき論点がいくつも重なります。この記事では、PKUTECH が Amazon Bedrock をはじめとする AWS サービスを組み合わせて開発した純国産 AI-CSPM ソリューション「Egeria-Security」を題材に、機密文書を扱うセキュリティ SaaS の設計判断とその背景をご紹介します。クラウドセキュリティ（CSPM）運用に課題を抱える方々にとっても、その解決アプローチとして参考になる内容です。 セキュリティ SaaS が直面する 2 つの設計課題 Egeria-Security は、Cloud Security Posture Management（CSPM）の機能を提供する SaaS 製品です。CSPM とはクラウド環境のセキュリティ設定を継続的に監視・評価するソリューションを指します。課題を 2 つの視点から整理します。 まず、利用者側（CSPM を導入する企業）の課題です。多くの CSPM ツールには CIS Benchmark や NIST などの膨大な標準ポリシーセットがあらかじめ搭載されていますが、大量のアラートの中から「なぜその項目が自社のシステムに必要なのか」を理解するには高度な専門知識が求められます。また、自社のセキュリティ規程や監査法人からの独自指摘に合わせてカスタムルールを作成するには、ポリシー言語の深い理解が必要であり、技術的なハードルが高い状況でした。結果としてチェックの根拠がブラックボックス化し、「設定の逸脱を検知しても、どう直すべきか判断できない」「監査の際にチェックの正当性を説明できない」という状況に陥りがちです。 次に、提供者側（セキュリティ SaaS を開発する企業）の課題です。顧客のコンプライアンス文書や監査指摘事項は機密性の高い情報であり、SaaS のバックエンドで安全に処理する必要があります。加えて、LLM を活用する場合、入力データが学習に利用されないこと、推論トラフィックが閉域を通ること、顧客のクラウド環境へのアクセスが最小権限で制御されていること、これらをすべて同時に満たすことが望ましいです。 コンプライアンス文書を起点としたポリシー自動生成 PKUTECH は、2002 年の創業以来、NTT データグループをはじめとする大手企業向けのシステムインテグレーション事業を展開してきました。近年は自社プロダクトの開発にも注力しており、生成 AI を活用した Egeria シリーズを展開しています。 同社が着目したのは、自社のコンプライアンス文書そのものをスキャンポリシーの源泉にするというアプローチでした。既存の CSPM ツールは CIS Benchmark や NIST など汎用的な標準ポリシーセットを起点とするため、自社環境に関係のないアラートが混入しやすく、「なぜそのチェックが必要か」の根拠が読み手に伝わりにくいという課題がありました。Egeria-Security はこの順序を逆転させ、自社のコンプライアンス文書から出発して、そこに記載された推奨事項をそのままスキャンポリシーに変換する仕組みを採用しました。生成された各チェック項目には、推奨事項 ID・準拠フレームワーク・カテゴリ・重要度といった文書由来の根拠メタデータが紐づくため、スキャン結果の根拠をたどりやすくなります。 AWS を基盤として選択した理由 Egeria-Security の基盤として AWS を選択した理由は、主に以下の 3 点です。個別のサービス機能だけを比較すると類似の選択肢は他のクラウドベンダーにも存在しますが、機密データを扱うセキュリティ SaaS の全要件をバランスよく満たす組み合わせとして AWS を選択しました。 第一に、LLM 推論におけるデータ保護です。 Egeria-Security が処理するコンプライアンス文書には、組織のセキュリティポリシーや監査指摘事項など機密性の高い情報が含まれます。Amazon Bedrock では、ユーザーのデータがモデルのトレーニングに使用されないため、機密文書を LLM に投入する前提条件を満たします。 第二に、機密データを扱う AI SaaS に必要な要素が単一プラットフォーム内で統合されている点です。 生成 AI 推論（Amazon Bedrock）、RAG のベクトルストア（ Amazon OpenSearch Service ）、閉域ネットワーク（ Amazon Virtual Private Cloud (Amazon VPC) 、 AWS PrivateLink ）、認証・鍵管理（ AWS Identity and Access Management (IAM) 、 AWS Key Management Service (AWS KMS) ）、コンテナレジストリ（ Amazon Elastic Container Registry (Amazon ECR) ）、ロードバランシング（ Elastic Load Balancing ）、DNS（ Amazon Route 53 ）、証明書管理（ AWS Certificate Manager ）。これらの個々の機能は類似のものが他のクラウドにも存在しますが、同一のプラットフォーム・同一の認証基盤の上で統合的に運用・監査できることが、セキュリティ SaaS の説明責任の観点で重要でした。複数クラウドをまたぐ構成では、認証・ログ・監査の連携が複雑化し、セキュリティ製品としての信頼性確保に追加コストがかかります。 第三に、顧客 AWS 環境とのシームレスな接続です。 CSPM の主要な利用シーンは顧客の AWS アカウントをスキャンすることです。SaaS 基盤も AWS 上にあれば、 AWS Security Token Service （AWS STS）によるクロスアカウントアクセスなど、AWS ネイティブな統制で顧客環境との連携を実現できます。 こうした設計判断の結果として、GPU 推論基盤の構築・運用といった非差別化領域を AWS マネージドサービスに委ね、インフラ層のコンプライアンス証跡には AWS が提供する認証・レポートを活用できるようになりました。責任共有モデルのもとアプリケーション層の統制は同社が引き続き担いますが、開発リソースをコア差別化領域であるコンプライアンス文書の RAG 処理と Cloud Custodian DSL の自動生成ロジックに集中投下できました。PKUTECH の試算では、自前で LLM 推論基盤を構築した場合と比較して、GPU 調達・運用で 2〜3 人月、LLM ホスティング・スケーリングの開発で 3〜6 人月の工数が不要となり、SaaS の立ち上げリードタイムは約 12〜18 ヶ月の想定に対し約 4〜6 ヶ月で MVP 完成に至りました。 ソリューションの概要：コンプライアンス文書からスキャンポリシーを自動生成 Egeria-Security は、SaaS 型で提供される純国産の AI-CSPM ソリューションです。ユーザーはまず CIS Benchmark、NIST SP 800-53 などの標準フレームワークや、自社の社内規程、委託先管理基準などのコンプライアンス文書を PDF でアップロードします。次に、取り込んだ文書をもとに Amazon Bedrock を活用した AI チャットで対話しながら、自社に必要な「推奨事項」を抽出します。抽出した推奨事項から AI の支援を受けながら Cloud Custodian ポリシー（YAML 形式）を自動生成し、生成されたポリシーを用いて実際のクラウド環境（AWS や Azure）をスキャンします。スキャン結果は複数回にわたる違反の発生・解消の推移をタイムラインで追跡でき、改善状況を可視化します。 3 つの設計判断 Egeria-Security のアーキテクチャは、前述の AWS 選択理由と連動した 3 つの設計判断で構成されています。 図1: Egeria-Security の AWS アーキテクチャ 設計判断 1：コンプライアンス文書 → DSL 変換のためのエージェント設計 非定型な PDF（コンプライアンス文書）を、Cloud Custodian が解釈可能な YAML という厳格な DSL に変換する必要がありました。 開発初期は PDF ファイル全体をそのままプロンプトに投入し、1 ステップで YAML ポリシーを生成する方式を試みました。しかし、数十ページ規模の文書では存在しない AWS リソース名や属性の生成などハルシネーションが頻発し、「適切なアクセス制御を実施する」のような抽象的記述に対して具体的なチェックロジックに落とし込めない、同じ文書を再投入しても生成結果のばらつきが大きく再現性が確保できないといった問題が顕在化しました。 図2: 2 つのエージェント（前段 = 取り込み／後段 = ポリシー作成）と内部 4 ステップ これらの課題を解決するため、最終的に役割を 2 つのエージェントに分離し、Amazon OpenSearch Service 上の構造化ドキュメントを介して疎結合に繋ぐ構成としました。前段の PDF 取り込みエージェントが文書から「推奨事項タイトル」「論理的根拠」「監査手順」「修正手順」「重要度」「準拠フレームワーク」等の構造化データを抽出して Amazon OpenSearch Service に格納します。後段のポリシー作成エージェントは、まず Cloud Custodian の公式スキーマ（ custodian schema コマンド）から取得した有効リソースタイプ一覧を選択肢として推奨事項に対応するリソースを特定し、次に Amazon OpenSearch Service に格納された Cloud Custodian リファレンスのコード例を RAG で参照しながら YAML ポリシーを生成します。生成結果がリスト内に存在するかを厳格に検証することで、ハルシネーションを抑制しています。図2 は、この 2 つのエージェントが内部で実行する処理を 4 つのステップ（Step1 PDF 解析/構造化、Step2 対話、Step3 ポリシー生成、Step4 構文チェック/修正）として示したものです。Step1〜2 を前段の PDF 取り込みエージェントが、Step3〜4 を後段のポリシー作成エージェントが担います。後段は、スキーマ参照・自動修正・最終レビューを含む複数のノードで構成されます。 この設計の技術的なポイントは、「自由に書かせる」から「決められた選択肢から選ばせる」への発想転換です。Cloud Custodian の公式スキーマを選択肢の制約として用いることで、存在しないリソースタイプや属性の生成を抑制し、独自辞書を手作業で保守する範囲を減らしています。なお、この制約が担保するのは構文上の妥当性であり、生成されたポリシーが文書の意図に合致しているかは生成後のレビューで確認します。また、PDF 取り込みエージェントに構造化抽出の責任を集中させたことで、ポリシー作成エージェントが文書原文を直接扱う必要がなくなり、再現性の向上にも寄与しました。 設計判断 2：機密データの LLM 推論を閉域で完結させる コンプライアンス文書は SaaS のバックエンドから LLM に渡されますが、この経路がインターネットを通過しない設計としています。ユーザーがブラウザからコンプライアンス文書をアップロードする区間は HTTPS（TLS 暗号化）によるインターネット経由の通信ですが、SaaS バックエンドが受信した文書を LLM 推論に渡す経路は Amazon VPC 内で完結します。バックエンドは VPC 内に配置され、アプリケーション間の通信は VPC 内で閉じています。Amazon Bedrock への LLM 推論アクセスは VPC Interface Endpoint（AWS PrivateLink）を経由するため、バックエンドから Bedrock への経路は AWS バックボーンネットワーク内で処理が完結し、この通信にパブリックインターネットへの egress は発生しません。つまり、機密文書が LLM 推論に渡される区間を閉域で保護する構成です。 この閉域設計により、機密文書を扱う通信のうち外部に公開される経路を減らし、データ経路の制御と監査可能性を確保しています。設計にあたっては、AWS Well-Architected Framework のセキュリティの柱における「転送中のデータの暗号化とネットワーク経路の制限」のベストプラクティスを参照しています。 設計判断 3：顧客 AWS 環境への最小権限・最小干渉のアクセス CSPM として顧客環境をスキャンするには一定の権限が必要ですが、セキュリティ製品である以上、顧客環境への干渉は最小限でなければなりません。PKUTECH は当初、アクセスキー直接入力方式（長期キーの管理リスクが高い）、AWS Organizations 連携方式（運用負荷が大きい）、オンプレエージェント方式（SaaS としての即時性を損なう）といった代替案を検討しましたが、いずれも金融領域の厳格なセキュリティ要件や SaaS としての導入容易性と両立できないと判断し、最終的に AWS CloudFormation テンプレート + STS AssumeRole + ExternalID の組み合わせに至りました。 具体的には、お客様が自社の AWS マネジメントコンソールで CloudFormation の Deep Link を開くだけで Egeria-Security 専用の IAM ロールが作成されます。付与される権限は既定で AWS 公式の SecurityAudit マネージドポリシー（読み取り専用）であり、変更・削除権限は含まれません。スキャン実行時には、テナント ID とランダム値の複合キーを ExternalID として指定した STS AssumeRole により、有効期限 1 時間の一時認証情報を都度取得します。ExternalID の照合は、顧客側 IAM ロールの信頼ポリシーに設定された sts:ExternalId 条件によって行われます。AssumeRole 呼び出し時にはセッションタグでテナント ID を付与しており、顧客側の AWS CloudTrail で監査ログの追跡が可能です。SaaS 側で保存するのは Role ARN や ExternalID などの連携情報で、これらは AES-256-GCM により暗号化しています。AssumeRole で取得した一時認証情報は、スキャン実行環境で永続化せず使用後に破棄します。 この構成は金融領域に関わる IT 企業での PoC におけるセキュリティレビューを経て改修を重ねたものです。具体的には、IAM ロールテンプレートの用途別分離（顧客側がマネージドポリシー ARN を選択可能化）、ExternalID のテナント分離強化、セッションタグによる監査追跡の追加が、PoC 評価者のレビューを経て実装されました。 導入効果：PoC での実証 金融領域に関わる IT 企業での PoC 検証を経て、以下の効果が確認されました。 導入の初期障壁の低さ PoC では、コンプライアンス文書の登録からポリシー生成、スキャン実行までの一連の流れが問題なく実行できることが確認されました。エージェントレスかつ文書ベースのポリシー自動生成のため、SaaS 型で提供する場合、デプロイから文書登録、スキャン実行までは 1 営業日以内に完了できる見込みです（PKUTECH の試算）。また、PoC 評価者からは「AWS や Azure の専門知識がなくてもスキャンに必要なポリシーを容易に設定可能」との評価をいただいており、Cloud Custodian の YAML 構文を意識することなくポリシーを策定できることが確認されました。 ポリシー網羅率 PoC で取り込んだコンプライアンス文書から自動生成された有効ポリシーは、取り込み観点の約 50〜60% をカバーしました（この数値は取り込んだ観点のうち実行可能なポリシーとして生成できた範囲を示すもので、生成結果の修正不要率や検知精度を表すものではありません）。残りの 40〜50% は「適切なアクセス制御を実施する」のような抽象的記述や、Cloud Custodian が直接扱えない人手プロセス（ドキュメンタリ統制等）で、別途人手での運用設計が必要です。PoC 評価者からは「文書ベースで半分のポリシーが自動生成できるだけでも、実装工数の短縮になる」とのご評価をいただいています。 CNAPP 化に向けた今後の展開 PKUTECH は、Egeria-Security の CSPM 機能を起点として、AI を活用した CNAPP（Cloud Native Application Protection Platform）の実現を目指しています。今後、クラウドユーザーのアクセス権・特権を自動チェックする AI-CIEM、クラウド環境内の脅威やポリシー違反を検出する AI-CWPP、Infrastructure as Code で記述されたインフラ構成を自動チェックする AI-IaC スキャンを順次追加する予定です。 お客様の声 本プロジェクトを主導した PKUTECH クラウド＆セキュリティ事業部長の渡部寿春氏は、次のようにコメントしています。 「Amazon Bedrock を PrivateLink 経由で利用する閉域設計により、機密文書の AI 推論をインターネットに出すことなく実行でき、セキュアなセキュリティガバナンスを実現できました。金融領域に関わる IT 企業での PoC でも実証された通り、コンプライアンス文書を取り込む独自の AI アプローチにより、Cloud Custodian の専門知識がなくても自社基準に即したクラウドセキュリティ運用が可能となり、セキュリティ人材不足に悩む多くの企業のご支援に繋がると確信しています。」 また、PoC に参加された金融領域に関わる IT 企業のシステム部門ご担当者様からは、利用者側の視点でコメントをいただいています。 「従来の CSPM では、自社独自のセキュリティポリシーに合わせてルールをカスタマイズすることに高い技術的ハードルがありました。今回の PoC で Egeria-Security に自社のコンプライアンス文書を読み込ませたところ、ドキュメントの『構造化』精度が非常に高く、具体的な運用文書から自動的にシステムチェック観点へ落とし込める点に大きな可能性を感じました。既存の CSPM とは一線を画す明確な差別化ポイントがあります。今後のさらなる機能の成熟と安定性の向上により、エンタープライズのクラウドガバナンス運用において価値を発揮するソリューションになるものと期待しています。」 まとめ PKUTECH が開発した Egeria-Security は、自社のコンプライアンス文書を起点としてスキャンポリシーを自動生成するアプローチにより、CSPM 運用における監査説明性とカスタムポリシー作成のハードルを同時に下げるソリューションです。 本記事では、この製品を題材に、機密データを扱うセキュリティ SaaS を AWS 上で構築する際の設計判断を 3 つの視点から整理しました。コンプライアンス文書から DSL への変換では 1 ステップ生成の失敗から 2 エージェント分離に至った経緯、閉域設計では PrivateLink を活用した機密データ経路の制御、顧客環境連携では PoC のセキュリティレビューを経て改修を重ねた実践についてです。個々の AWS サービスの機能比較ではなく、機密データを扱う AI SaaS に必要な要素が単一プラットフォーム上で統合的に利用できることが、本事例における AWS 選択の決め手でした。 同様の課題を抱える SaaS ベンダーや、生成 AI を自社製品に組み込もうとする企業にとって、設計の参考になれば幸いです。クラウドセキュリティの運用に課題を感じている方は、 Egeria-Security の製品ページ をご覧ください。Amazon Bedrock を活用した生成 AI ソリューションの構築に興味がある方は、 Amazon Bedrock の詳細ページ もあわせてご参照ください。本記事で取り上げた AWS サービスの詳細は、 Amazon OpenSearch Service 、 AWS PrivateLink 、 AWS CloudFormation の各ページをご覧ください。 左より PKUTECH：セキュリティエンジニア 遠藤 操希 氏 Amazon Web Services Japan：アカウントマネージャー 今井 彩渚 PKUTECH：デザイナー＆スクラムマスター 坂野 茉夢 氏 PKUTECH：AWS アーキテクト 杜 利民 氏 PKUTECH：クラウド＆セキュリティ事業部長 渡部 寿春 氏 PKUTECH：技術リーダー 釜石 智史 氏 PKUTECH：Python エンジニア 及川 大地 氏 Amazon Web Services Japan：ソリューションアーキテクト 伊勢田 氷琴 ソリューションアーキテクト 伊勢田氷琴

クラウドコンピューティングの初期の頃、AWS は世界中の都市で AWS Pop-up Lofts と呼ばれる物理的なスペースで建設業者を対象とした集中学習をサポートしていました。これらのスペースは、スタートアップ起業家、開発者、およびイベント、ミーティング、共同作業で AWS についてもっと知りたいと考えている人が利用できました。最近の生成 AI の登場により、 AWS Gen AI Lofts は世界中でポップアップスタイルのコラボレーションスペースを提供し、スタートアップや開発者に没入型の体験を提供しました。 私たちは、実践的な体験、コミュニティ主導の共有、技術的なコラボレーションを通じて、学生や開発者が学び、つながり、貢献できる常設のコミュニティスペースが必要であることに気づきました。2025 年 7 月にサンフランシスコでオープンして以来、最初の AWS Builder Loft は 22,500 人以上の開発者を迎え、地元の技術コミュニティが一堂に会するハッカソン、ワークショップ、デモナイト、コミュニティ主導のイベントを開催してきました。 2026 年 8 月 18 日、ベルリン、ハイデラバード、サンパウロに新しいビルダーロフトをオープンする計画を発表しました。各場所は、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ制作スペース、コラボレーション/コワーキングエリア、イベント主催を提供する常設コミュニティスペースとなり、ドアを通り抜けたい開発者、学生、技術専門家向けに、無料のワークショップ、ネットワーキングイベント、ピッチナイト、コンテンツ作成スペース、コラボレーション/コワーキングエリア、イベントの開催が可能になります。 そこでは引き続き AWS の専門家に会うことができますが、それ以上に、 AWS User Groups や AWS Student Builder Groups 、すでに参加している独立した開発者グループまで、地域の技術コミュニティの本拠地を作りたいと考えています。テクノロジーコミュニティのリーダーとして、ミートアップを開催するためのスペースの予約を無料でリクエストしていただけます。 なぜ 3 都市なのか この拡張は、各地域の重要な人材とイノベーションの拠点である開発都市が急成長していることを反映しています。 ベルリン : AWS European Sovereign Cloud を立ち上げた後、私たちはヨーロッパの開発者コミュニティへの取り組みを深めています。ベルリンの Builder Loft は、デジタル主権に関する教育セッション、ハッカソン、セキュリティ対策ワークショップ、コミュニティミートアップを開催し、ドイツの成長を続けるスタートアップエコシステムと、より広範なヨーロッパおよび世界のテクノロジー環境をつなぐコミュニティミートアップを開催します。 ハイデラバード : Hyderabad Builder Loft は、インドの開発者に AI のスキルアップ、クラウドネイティブアーキテクチャの探求、次世代アプリケーションを構築する仲間との交流のための専用スペースを提供します。 サンパウロ : ブラジルのクラウド市場は毎年 30 % の成長を遂げており、サンパウロはラテンアメリカのテクノロジーブームの中心に位置しています。Builder Loft は、地域の開発者のハブとして機能し、地域社会、大学、スタートアップネットワークと連携して無料のプログラミングを提供します。 ビルダーロフトでの典型的な一週間 サンフランシスコの Builder Loft では、生成 AI に関する技術的なディープダイブからスタートアップのピッチナイト、学生向けのコーディングワークショップから地域全体の開発者が集まるネットワーキングセッションまで、毎週 4 〜 8 件のコミュニティイベントを開催しています。 スペースは柔軟に設計されています。火曜日の朝、トレーニングルームは 50 人以上の学生でいっぱいになります。夕方になると、スタートアップが潜在的なコラボレーターの部屋に最新のプロトタイプを披露するデモステージに変わります。週末には、コミュニティグループが独自のミートアップを開催します。 このモデルが機能する理由は、コミュニティ自体によって推進されているということです。地元の開発者、ミートアップ主催者、技術リーダーがプログラミングを形作ります。AWS はスペース、インフラストラクチャ、サポートを提供しますが、エネルギーは参加するビルダーから得られます。 今後のイベント を検索するか、サンフランシスコの Builder Loft での 独自のイベントの開催 をリクエストしてください。 ご期待ください Builder Loft は、今後のブログ記事で 3 都市でのオープンについて発表しますので、最新情報にご期待ください！ Builder Lofts の詳細を確認したり、最新情報を入手したりするには、 Rick のブログ投稿 と AWS Builder Loft のページ をご覧ください。 – Channy 原文は こちら です。

2026 年8 月 10 日週、 OpenSearch と Valkey のチームはソウルを訪問し、 Open Source Summit Korea 2026 と MCP DevSummit Seoul 2026 でオープンソース開発者とコントリビューターに会いました。4 日間のイベントでは、オープンソースプロジェクトと新興エージェント AI のコミュニティリーダーとユーザーが集まり、知識を共有し、ソリューションについて協力し、プロジェクトを推進しました。 韓国の OpenSearch コミュニティのリーダーたちがブースにボランティアとして参加し、 ユーザーグループのミートアップ でネットワークを作り、交流する時間もありました。 OpenSearch は、大規模な非構造化データに秩序をもたらすオープンソースのエンタープライズグレードの検索およびオブザーバビリティスイートです。2026 年 6 月 9 日、 OpenSearch 3.7 では、ログ、トレース、メトリックにわたる SLO のクエリ、アラート、追跡を単一のインターフェースから行い、ベクトルの取得を最大 5.5 倍高速化して検索パフォーマンスを向上させるように設計された新しいツールが導入されました。2026 年 7 月 30 日以降、 Amazon OpenSearch Service で OpenSearch バージョン 3.7 を実行できるようになりました。これにより、ベクトル検索のパフォーマンス、検索の関連性、クエリインサイトが向上します。 Valkey はオープンソースの高性能キー/値データストアで、キャッシュ、メッセージキューなどのさまざまなワークロードをサポートし、プライマリデータベースとしても機能します。2026 年 5 月 19 日、 Valkey 9.1 は再設計されたI/Oスレッドモデルを導入しました。これにより、スループットが最大 17％ 向上し、128 バイト未満の文字列のメモリ使用量が最大 20％ 削減されます。2026 年 6 月 23 日以降、ノードベースのクラスター用に Amazon ElastiCache で Valkey 9.1 を実行できるようになりました。これにより、マルチテナントワークロードのスループットが向上し、メモリ効率が向上し、アクセス制御が強化されます。 今後開催される OpenSearch と  Valkey のイベント で、当社のオープンソースチームに会うことができます。 8 月 10 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon EC2 アプリケーションステータスチェック : Amazon EC2 では、EC2 インスタンスのアプリケーションレベルの問題を検出して対応するのに役立つ新しいステータスチェックが導入されました。アプリケーションステータスチェックにより、EC2 はアプリケーションを監視して、リクエストの受け付けを停止したウェブサーバー、実行中の Docker デーモン、不適切なネットワーク構成、トラフィックを渡さなくなったネットワークインターフェイスなどの問題を検出します。詳細については、 アプリケーションステータスチェックのドキュメント をご覧ください。 AWS IAM ロールマネージャーによる IAM ロールの自動セットアップ: AWS サービスに必要な IAM ロールを自動的にセットアップする新しいロールマネージャーを使用できます。コンソールでサポートされているサービスを設定すると、ロールマネージャーはユーザーに代わってデフォルトのロールを作成するか、必要な権限と一致する場合はアカウントにすでに存在するロールを再利用します。ロールマネージャーは、起動時に 6 つの AWS サービスコンソールをサポートします。詳細については、「 AWS IAM ロールマネージャーが IAM ロールの開始点を再考する方法 」を参照してください。 OpenAI Daybreak は、Amazon Bedrock の対象となるお客様が利用できます : Daybreak は OpenAI のサイバー防衛イニシアチブで、防御側がサイバーセキュリティ業務のためにフロンティア AI にガバナンスを利用できるようにします。ほとんどのセキュリティチームにとって、GPT-5.6 Sol を搭載した Daybreak Blue は、脆弱性の発見、検出エンジニアリング、インシデント対応などの防御ワークフローの出発点となります。新しい GPT-5.6 Cyber を搭載した Daybreak Red は、脆弱性調査、エクスプロイトの複製、緩和策の開発など、承認された高度なタスク向けに設計されています。登録するには、OpenAI に連絡するか、AWS アカウントチームに連絡して資格に関するガイダンスを受けてください。詳細については、 AI ブログ記事 をお読みください。 Amazon SageMaker JumpStart の新しいファンデーションモデル : AWS のお客様が利用できるファンデーションモデルのポートフォリオを拡大しています。これらのモデルは、さまざまなエンタープライズ AI の課題に特化した機能で対処します。 NVIDIA の Nemotron 3.5 Lightning モデル NVIDIA の Nemotron-Nano-12b-V2、Z.ai の GLM-5.2 FP8、GLM-OCR モデル NVIDIA の LocateAnying-3B、QWEN-AgentWorld-35B-A3B、Qwen 3.5-122B-A10B モデル Black Forest Labsの FLUX.2-small-decoder と Google の gemma-4-12B-it モデル Redis の langcache-embed-v3-small、JetBrains の Mellum2-12B-A2.5B-Thinking、LightOn の LightOnOCR-2-1B モデル AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクトやニュース項目をいくつかご紹介いたします。 AWS Certificate Manager (ACM) におけるメール認証の廃止 : ACM は、2027 年 9 月 30 日をもって、メール認証による公開証明書のサポートを終了します。ACM パブリック証明書に E メール検証を使用する場合は、その日までに DNS 検証に移行する必要があります。Amazon CloudFront ディストリビューションでは、HTTP 検証も利用できます。 CLI サポートと管理コントロールを備えた次世代 AWS VPN クライアント : OpenVPN3 上に構築された新しい AWS VPN クライアントを使用できます。新しいクライアントでは、既存の AWS Client VPN エンドポイントとの完全な下位互換性を実現すると同時に、エンタープライズネットワーキングチームが求めていた自動化機能とセキュリティ体制を実現できます。 Oracle AI データベース用 Exascale 上の Oracle Exadata @AWS : Exadb-XS は、消費ベースのモデルを通じて Exadata クラスのパフォーマンスと可用性を実現します。ExADB-xS を使用すると、コンピューティングとストレージを個別に少しずつ拡張でき、支払いは使用した分だけです。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 8 月 17 日週のニュースは以上です。8 月 24 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

ゲノム研究は、変革の岐路に立っています。シーケンシングデータが指数関数的に増加するなか、それに見合う高度な解析能力が求められています。 1000 Genomes Project によれば、典型的なヒトゲノムは参照配列 (リファレンス) に対して 410 万〜500 万か所で異なり、そのほとんどは一塩基多型（SNP）と短い挿入・欠失（indel）です。これらのバリアントは、多くの人のデータを合わせると、ポリジェニックリスクスコア（PRS：Polygenic Risk Score）として捉えられる疾患のかかりやすさの違いに寄与します。しかし、ゲノム解析ワークフローは、こうした大規模なバリアントデータを実際に活用できる知見へと変換することに苦労しています。ワークフローは依然として断片化しており、研究者はバリアントアノテーション、品質フィルタリング、 ClinVar のような外部データベースとの統合といった複雑なパイプラインを、手作業で組み立てる必要があります。 AWS HealthOmics のワークフローは、 Amazon S3 Tables および Amazon Bedrock AgentCore と組み合わせることで、これらの課題に対する変革的なソリューションを提供します。HealthOmics のワークフローは、Variant Call Format（VCF）ファイルに有用なオントロジーを付与するアノテーション処理をシームレスに統合できます。続いて、Variant Effect Predictor (VEP) でアノテーションした VCF ファイルを構造化データセットへ変換し、最適化された S3 Tables に格納します。これにより、大規模なバリアントコホート全体でのクエリ性能を高めます。Amazon Bedrock AgentCore 上で動作する Strands Agents SDK は、セキュアでスケーラブルな AI エージェントアプリケーションを提供し、研究者は専門的なクエリの知識を持たずとも、複雑なゲノムデータセットを扱えるようになります。 本ブログ記事では、エージェント型 (agentic) ワークフローが、自然言語インターフェースによって、ゲノミクスパイプラインの処理と解釈を大規模に高速化する方法をご紹介します。ここでは、自動化されたデータ処理とインテリジェントな解析を組み合わせた、包括的なゲノムバリアント解釈エージェントをデモンストレーションします。このエージェントは、生の VCF ファイルの取り込みから対話型クエリインターフェースまで、ワークフロー全体に対応します。最も重要な点として、このソリューションは、従来はゲノム解析を専門のバイオインフォマティシャンに限定してきた技術的な障壁を取り除きます。これにより、臨床研究者は生の VCF ファイルをアップロードし、たとえば「BRCA1 に病原性バリアントを持つ患者は誰か？」や「このコホートにおける薬剤耐性バリアントを見せて」といった質問を、すぐに投げかけられるようになります。本ソリューションのコードは、AWS 上のライフサイエンス向けスターターエージェントを集めた オープンソースのツールキット リポジトリで公開されています。 ゲノム解析におけるバリアントアノテーションの理解 ゲノムバリアント解釈の土台は、生の遺伝的バリアントを生物学的・臨床的な文脈に結びつける包括的なアノテーションパイプラインです。Variant Effect Predictor（VEP）と ClinVar は、現代のゲノム解析ワークフローにおける 2 つの不可欠な構成要素であり、それぞれが相互に補完的な情報を提供します。研究者は、意味のある知見を得るために、これらを統合する必要があります。 この比較図は、ClinVar と VEP による、ゲノムバリアント解釈のための、相補的でありながら異なるアノテーション機能を示しています。左側の ClinVar アノテーションは、主に臨床的意義の評価に重点を置き、キュレーションされた病原性分類（CLNSIG）、エビデンスの品質を示す指標（CLNREVSTAT）、そして臨床判断に直接関わる疾患との関連（CLNDN）を提供します。右側の VEP アノテーションは、影響 (コンシークエンス) タイプ（missense_variant、synonymous_variant、intron_variant）、影響度分類（HIGH、MODERATE、LOW、MODIFIER）、遺伝子シンボル、位置情報を含むトランスクリプトごとの効果など、包括的な機能情報を提供します。 現在のアノテーションワークフローの課題 バリアントアノテーションのワークフローは、通常、次のようなシーケンシャルなプロセスをたどります。 初期の VCF 処理：シーケンシングシステムから出力される生の Variant Call Format（VCF）ファイルは、表記を正規化し、低品質なコールを除去するための前処理が必要です。 VEP アノテーション：Variant Effect Predictor ツールの実行には多くの計算リソースを要します。特に、サンプルあたり数百万のバリアントを含む全ゲノムシーケンシングデータでは、その傾向が顕著です。VEP 解析は、利用可能な計算リソースとアノテーションの深さに応じて、ゲノムあたり 2〜8 時間かかることがあります。 ClinVar 統合：臨床アノテーションは ClinVar から取得し、別の処理でバリアントと照合する必要があり、データベース検索やフォーマット変換が求められます。 マルチサンプル統合：コホートレベルの解析を行うには、サンプル間で複雑な結合（join）操作が必要になります。これは通常、専用ツールで行われますが、生成されるのは大きくフラットなファイルで、効率的なクエリが困難です。 解釈：さらに科学者は、さまざまなツールを使って、アノテーション済みデータのフィルタリング、ソート、解析を行う必要があります。これは多くの場合、独自のスクリプトと相応のバイオインフォマティクスの専門知識を要します。この技術的なボトルネックにより、臨床研究者は自らのゲノムデータを自力では探索できず、生物学的な問いを立ててから答えを得るまでに数日から数週間の遅延が生じます。 データセットの複雑さと規模 ゲノムバリアント解析の規模を象徴するのが、 1000 Genomes Phase 3 Reanalysis with DRAGEN のようなデータセットです。このデータセットには次のものが含まれます。 多様な集団に由来する 2,500 を超える個別サンプル 全サンプルにわたる、約 8,500 万件のユニークなバリアント 整合させる必要のある複数のアノテーションバージョン（DRAGEN 3.5、3.7、4.0、4.2） SNP や indel に加えて、複雑な構造変異（structural variant） こうした複雑さは、フラットファイルの処理や手作業での統合ステップに依存する従来型の解析パイプラインにおいて、大きなボトルネックを生み出します。 ソリューションの概要 ゲノムコホートの構築や、複数の患者にわたって PRS を計算したりするには、 Variant Effect Predictor （VEP）のようなツールを用いて、結合されたバリアントコールテーブルと包括的なアノテーションを生成する必要があり、多くの計算リソースを要します。最も重要なのは、これらのワークフローが、SQL の専門知識とバリアントファイル形式への深い理解を持つバイオインフォマティシャンだけが意味のある知見を引き出せる、という技術的障壁を生み出している点です。その結果、臨床研究者は基本的なゲノムクエリでさえ専門の技術チームに依存せざるを得ません。 私たちの AI を活用したアプローチの変革的な利点は、自然言語による対話を通じてゲノム解析を誰もが使えるものへと民主化することにあります。従来の VEP パイプラインでは、「薬剤耐性遺伝子に高影響度 (high-impact) のバリアントを持つ患者は誰か？」といった臨床的な問いに答えるのに数日の技術的作業を要しました。一方、私たちのソリューションを使えば、研究者はこうした質問を会話形式で問いかけ、数分で答えを得られます。これは、技術への依存から、セルフサービス型のゲノム解析への移行を意味します。臨床研究者、腫瘍ボード（tumor board）、ゲノミクスチームは、バイオインフォマティクスの支援を待つことなく、自らのデータを直接探索できるようになります。 本ソリューションは、自動化されたデータ処理と、インテリジェントな自然言語解析を組み合わせた、生成 AI 活用型のゲノムバリアント解釈エージェントをデモンストレーションします。このアーキテクチャは、生の VCF ファイルの取り込みから対話型クエリインターフェースまで、ゲノム解析ワークフロー全体に対応します。 本ソリューションは、生のゲノムデータを実際に活用できる知見へと変換する、6 つの主要ステップで構成されます。 生の VCF 処理：シーケンシングプロバイダーからの生の VCF ファイルが Amazon S3 ストレージにアップロードされ、S3 イベント通知を通じて AWS Lambda 関数をトリガーします。この Lambda 関数が AWS HealthOmics のワークフローをオーケストレーションします。 VEP アノテーション： AWS HealthOmics のワークフローが、Variant Effect Predictor（VEP）を使って生の VCF ファイルを自動的に処理し、機能予測と臨床アノテーションを並列で付与してバリアントを強化します。その後、アノテーション済みの結果を S3 に格納します。 イベント連携： Amazon EventBridge がワークフローの完了を監視し、Lambda 関数をトリガーして、 Amazon DynamoDB 内のジョブステータスを更新します。また、 AWS Batch の Fargate コンピューティング環境で、PyIceberg モジュールを用いて、VEP アノテーション済み VCF ファイルと ClinVar アノテーションを Iceberg 形式に変換します。 データの整理：PyIceberg ローダーは Amazon S3 Tables の Iceberg REST エンドポイントと連携します。Amazon S3 Tables は、テーブルのメタデータを AWS Glue Data Catalog に登録します。アノテーション済み VCF と ClinVar アノテーションについて、スキーマ情報（列、データ型、パーティション）がカタログ化されます。また、下流の分析のための分析コネクタも確立します。 SQL による分析： Amazon Athena が、列指向 (カラムナ) 型ストレージ形式を通じてゲノムデータに対する SQL ベースのクエリ機能を提供します。これにより、数百万のバリアントにわたる大規模解析を、最適なクエリ応答で実現します。 自然言語による対話：AgentCore Runtime 上の Amazon Bedrock LLM を活用した Strands オーケストレーターエージェントが、Athena クエリを実行する 5 つの専用ツールを通じて自然言語インターフェースを提供します。 query_variants_by_gene：特定の遺伝子に関連するバリアントを取得します query_variants_by_chromosome：染色体単位のバリアント解析を可能にします compare_sample_variants：患者サンプル間の比較ゲノミクスを可能にします analyze_allele_frequencies：集団遺伝学的な知見を提供します execute_dynamic_genomics_query：柔軟なアドホック解析のリクエストに対応します このアーキテクチャには、きめ細かなアクセス管理のための AWS IAM と、モニタリングのための Amazon CloudWatch による包括的なセキュリティ制御が組み込まれています。この自動化されたイベント駆動型のパイプラインは、VCF ファイルのスケーラブルな並列処理をサポートし、増え続けるゲノムデータセットに自動的に適応しながら、一貫したアノテーション品質と分析能力を維持します。 PyIceberg を用いたAmazon S3 Tables : VCF から構造化コホートへの変換 PyIceberg と Amazon S3 Tables を組み合わせることで、VEP アノテーション済みの VCF ファイルを、構造化されたコホート、つまり AI 駆動の分析に最適化されたクエリ可能なデータセットへと変換します。これにより、自然言語インターフェースが複雑なゲノムデータと効率的に対話するためのデータ基盤が生まれます。 PyIceberg は、S3 Tables 形式で Apache Iceberg テーブルを作成し、次のような利点をもたらします。 最適なクエリ：エージェントは、最適化された列指向 (カラムナ) 型ストレージを通じて、数百万のバリアントにわたる複雑なゲノムクエリを最小限のレイテンシで実行できます。従来は数時間の SQL 開発と実行を要した分析が、対話による即時応答へと変わります。 豊富なアノテーションへのアクセス：VEP と ClinVar のアノテーションは、Amazon Athena を介した SQL で直接クエリ可能になり、AI エージェントが特定のゲノム知見を抽出できるようになります。 コホートレベルの解析：構造化された Iceberg 形式（PyIceberg）は、自然言語を通じた集団レベルのクエリのために、患者コホート間の効率的な比較が可能になります。 S3 Tables においてバリアントデータとアノテーションデータを分離することで、AI を活用した分析に適したデータ基盤となります。ゲノムバリアントの S3 Tables はエージェントが高速にフィルタリングできる中核的な位置情報が含まれ、一方でアノテーション／臨床情報の S3 Tables にはバリアントの解釈に必要な豊富な機能的・臨床的コンテキストが格納します。 この構造により、Strands エージェントは AWS Glue Data Catalog コネクタを通じて、ユーザーの質問に的確に答える、対象を絞ったクエリを構築できます。 生の VCF ファイルから構造化テーブルへのこの変換こそが、研究者が Amazon Bedrock AgentCore 上の Strands オーケストレーターエージェントを通じて、複雑なゲノムデータセットを会話形式でクエリできるようにするものです。 Strands Agents と AgentCore Runtime によるインテリジェントなゲノム解析 この対話型インターフェースは、私たちのゲノミクス AI ソリューションの中核をなすイノベーションであり、Strands Agents SDK を用いて構築され、Amazon Bedrock AgentCore Runtime 上にデプロイされています。この高度な AI エージェントは、複雑なゲノミクスの概念を理解し、自然言語のクエリを、構造化されたゲノムデータセットに対する適切な分析操作へと変換します。 AgentCore Runtime は、動的な AI エージェントとツールのデプロイおよびスケーリングのために専用設計された、セキュアでサーバーレスなランタイムです。本ソリューションは、ゲノム分析において次のような主要な利点をもたらします。 モデルとフレームワークの柔軟性：AgentCore のサービスは組み合わせ可能 (コンポーザブル) であり、Amazon Bedrock の内外を問わず、オープンソースまたはカスタムのフレームワークおよびモデルと連携します。 数時間規模の エージェント型ワークロード：最長 8 時間の長時間実行ワークロードと、最大 100MB のペイロードをサポートします。 セキュリティ：ユーザーセッションごとに専用のマイクロ VM（microVM）を割り当て、完全に分離します。 エンタープライズグレードの統合：AgentCore Identity と AWS IAM による認証を標準で備えています。 オブザーバビリティ：エージェントの推論とツール呼び出しを包括的にトレースします。 プライベートリソースへのアクセス：Amazon Virtual Private Cloud (VPC) 内のデータベースや API への接続が可能です。 市場投入までの時間短縮：AI エージェントソリューションのデプロイと開発のサイクルを加速します。 Amazon Bedrock AgentCore の機能に関する詳細は、 Amazon Bedrock AgentCore のドキュメント を参照してください。 Strands Agents は、エージェンティックループ（agentic loop）の概念を用いてゲノム解析ツールをオーケストレーションする、モデル駆動のアプローチにより、専門的な機能を備えたドメイン特化型 AI エージェントを構築するための堅牢な基盤を提供します。この反復的な推論フレームワークにより、エージェントは解析要件に応じて適切なツールを動的に選択・実行できます。私たちのゲノムバリアント解釈エージェントは、Amazon S3 Tables が作成した構造化データを活用する、次の 5 つの主要ツールを実装しています。 バリアントのクエリ：遺伝子ベースの質問を、関連するバリアントを取得する的確な Athena SQL クエリへと変換します。 染色体解析：自然言語を通じて、特定のゲノム領域を対象とした問い合わせを可能にします。 サンプル比較：SQL の結合 (join) を必要とせずに、患者横断のゲノム解析を可能にします。 集団頻度解析：1000 Genomes のような参照データセットに照らして、結果所見を文脈づけます。 動的なクエリ生成：複雑な自然言語のリクエストを、最適化された SQL へと変換します。 自然言語によるクエリ このエージェントは、多様な種類のクエリを扱う際に卓越した能力を発揮します。従来のモデルでは、臨床研究者はバイオインフォマティクスチームが独自のスクリプトを書き、複雑な解析を実行するのを待たなければなりませんでした。しかし今では、SQL クエリの作成や VCF ファイル形式との格闘に数日を費やす代わりに、研究者はゲノミクスの専門家と会話するように自然に、自らのゲノムデータを探索できます。 コホートレベルの分析 ユーザー 「このコホートについて、患者ごとのバリアント総数と病原性を表形式でまとめてください」 このクエリでエージェントは次の処理を行います。 execute_dynamic_genomics_query ツールを使用します。 コホート内のサンプル全体のバリアントデータを解析します。 患者数とバリアントの統計を含むコホートのサマリーを生成します。 結果を表形式で整理して提示します。 コホートレベルの頻度分析 ユーザー 「このコホートと 1000 Genomes で共有される、病原性または病原性の可能性が高いバリアントのアレル頻度を教えてください」 エージェントはこれを次のようなクエリへと変換します。 execute_dynamic_genomics_query ツールと analyze_allele_frequencies ツールを実行し、その患者の病原性バリアントの一覧を取得します。 臨床的に重要な病原性バリアントを絞り込み（フィルタリング）ます。 ClinVar から疾患レベルの情報を、VEP からアレル頻度を抽出します。 関連するコンテキストとともに結果を提示します。 併存疾患（コモルビディティ）のリスク関連分析 ユーザー 「chr10:111079820 の ADRA2A 遺伝子にバリアントを持つ患者は誰か。また、これらの患者はスタチンやインスリン抵抗性に関連する、追加の高影響度のバリアントを持っているか？」 このクエリに対して、エージェントは次のように動作します。 特定の疾患コンテキストについて、薬剤耐性経路における追加のリスクバリアントを検索します。 併存疾患に関して、個々の患者レベルで臨床的意義と結びつけます。 臨床と薬剤耐性経路を統合した臨床的示唆を提供します。 この自然言語インターフェースにより、研究者が複雑な SQL 構文を習得したり、基盤となるデータ構造を理解したりする必要が最小限になり、技術的背景を問わず、臨床チームと研究チームがゲノム知見へアクセスしやすくなります。 高度な分析処理 クエリに加えて、このゲノムバリアント解釈エージェントは、基本的なバリアント同定を超える高度な分析能力を発揮します。研究者は、従来は数日の解析を要した複雑な問いを探索できます。 臨床意思決定支援 ユーザー 「患者 NA21144 について徹底的な解析を行い、この患者のリスク層別化を提示してください」 このクエリに対して、エージェントは次のように動作します。 疾患経路の遺伝子やファーマコゲノミクスにおけるバリアントを解析し、エビデンスに基づく推奨を提供します。 バリアントの影響予測と臨床的意義の分類を組み合わせて、リスク層別化を行います。 意義不明のバリアント（VUS：Variant of Uncertain Significance）を特定します。 臨床的に重要な遺伝子における高影響度のバリアントにフラグを立てます。 ファーマコゲノミクスに基づく投薬戦略 研究者は、次のようなクエリを通じて、大規模コホートにわたる高度なファーマコゲノミクス経路解析にエージェントを活用できます。 ユーザー 「この患者コホートで、遺伝的バリアントが有意に集積している主要な薬剤関連経路はどれか。最も影響の大きいファーマコゲノミクス経路と、関連する患者 ID を教えてください」 これにより、バリアント頻度の分布、影響 (コンシークエンス) タイプのパターン、集団ごとの遺伝子レベルのバリアント負荷を、複雑な SQL やバイオインフォマティクスパイプラインを介さず、会話型インターフェースを通じて探索できます。 利点と制限事項 本ソリューションは現在の課題を次のように解決します。 課題 解決策 初期の VCF 処理 – 低品質なコール エージェントがバリアント解釈の判断前に、コールの品質を自動でチェックします 大規模な VEP アノテーション 20 件単位のバッチで VCF のアノテーションを自動化し、適切な計算リソースを使って必要な性能を確保します。 ClinVar との統合 エージェントがクエリの文脈を評価し、ユーザーの関心に応じて結合クエリを動的に組み立てます。 複数サンプルの統合 Iceberg 形式の Amazon S3 Tables と統合することで、VCF ファイルのコホートに十分な性能でクエリできます。 ゲノムの解釈 エージェントが文脈とユーザーの関心を理解し、アノテーションや自社データの適切なエビデンスに基づいて慎重に推論し、根拠のある判断を示します。 本ソリューションには、次のような制限事項があります。 Lambda ランタイムの制約：現在の実装では、VCF／GVCF 処理に AWS Lambda を使用しており、最大実行時間は 15 分です。大きな VCF ファイル、特に非常に大きな GVCF ファイルを Iceberg の S3 Tables に読み込む場合、これらの操作は Lambda のタイムアウト制限を大幅に超えることがあるため、この制約では不十分な場合があります。大規模なゲノムデータセットを扱う本番ワークロードでは、データ読み込み処理を扱うために、より長い実行時間を持つ AWS HealthOmics ワークフロー、AWS Batch、ECS タスク、または EC2 インスタンスの利用を検討してください。 スキーマ最適化のトレードオフ：本スキーマ実装では、サンプルおよび染色体によるパーティショニングを使用しており、患者レベルの解析に最適化されています。しかし、コホートレベルの解析では通常、大規模で最適なパフォーマンスを得るために、異なるパーティショニング戦略とスキーマ設計が必要です。数百サンプルを超えてコホートサイズが拡大するにつれ、単一のスキーマ内で患者レベルとコホートレベルの両方の分析を高性能に保つことは、ますます困難になります。大規模なコホート研究（数千〜数万サンプル）では、特定の分析パターンに最適化された別個のスキーマやマテリアライズドビューの実装、あるいは集団レベルのクエリをより適切にサポートする非正規化構造の検討を推奨します。 今後の技術的な発展 本ソリューションのモジュール型アーキテクチャは、AI 活用型ゲノム解析における継続的なイノベーションの基盤を確立します。将来のバージョンでは、追加のアノテーションデータベースや外部 API を統合し、ゲノムデータと臨床記録・画像を組み合わせたマルチモーダル解析のサポートが考えられます。ゲノムデータでのドメイン特化型のファインチューニングは解釈精度をさらに高め、電子カルテ（EHR）との統合は、診療現場（point-of-care）でのゲノム知見の提供を可能にするでしょう。 とりわけ有望な方向性が、医薬品研究機関 R&D におけるマルチエージェント連携です。このゲノムバリアント解釈エージェントが、薬剤プロファイリング、標的同定、文献エビデンス、仮説生成を担う専門エージェントと協調して動作できます。この協調的なエージェントフレームワークは、バリアントレベルの知見を治療開発へと直接つなぎ、遺伝的発見から臨床応用への橋渡しを効率化することで、創薬パイプラインを劇的に加速できます。 まとめ この次世代のゲノミクス エージェント型 AI ソリューションは、研究者や臨床医がゲノムデータとどのように対話するかという点で、根本的な変革をもたらします。自動化されたバリアントアノテーションとデータ変換を担う AWS HealthOmics と、インテリジェントな解釈のための Amazon Bedrock AgentCore をシームレスに統合することで、ゲノム解析ワークフロー全体をカバーする包括的なソリューションを実現しました。 自動化された VEP アノテーションワークフロー、VCF データをクエリ可能な Iceberg テーブルへ変換する S3 Tables、そして自然言語での対話のための Amazon Bedrock AgentCore 上の Strands Agents。これらの組み合わせにより、バリアントアノテーション、データ処理、臨床的解釈の間にある従来の障壁を最小化するシステムが生まれます。複雑な技術的プロセスを自動化し、直感的な対話手段を提供することで、研究者は技術的な実装の詳細ではなく、生物学的な問いそのものに集中できるようになります。 ゲノムデータが指数関数的に増え続け、臨床応用がますます高度化する中で、このようなシステムは、精密医療（プレシジョンメディシン）を前進させ、科学的発見を加速するための不可欠なインフラとなるでしょう。1000 Genomes Phase 3 Reanalysis データセットで示したこのソリューションは、大規模なゲノムコホートでさえ、シンプルな会話型インターフェースを通じて解析でき、高度なゲノム知見へのアクセスを誰もが使えるよう民主化できることを示しています。 本ソリューションのコードは Life sciences agents toolkit で公開されています。ぜひこのテンプレートを試し、発展させてみてください。Amazon Bedrock AgentCore を使い始めるためのサンプルについては、 Amazon Bedrock AgentCore リポジトリ をご確認ください。 原文は こちら です。 著者について Edwin Sandanaraj AWS のゲノミクス Solutions Architect です。神経腫瘍学の博士号と、ヘルスケアゲノミクスのデータ管理・解析における 20 年以上の経験を持ち、アジアパシフィックおよび日本でのプレシジョンゲノミクスの取り組みを豊富な知識で支えています。クラウドを活用したプレシジョンケアの実現に向けて、臨床ゲノミクスとマルチオミクスに強い関心を持っています。 Hasan Poonawala AWS のシニア AI/ML Solutions Architect で、ヘルスケア・ライフサイエンス分野のお客様を担当しています。AWS 上での生成 AI および機械学習アプリケーションの設計、デプロイ、スケーリングを支援しています。機械学習、ソフトウェア開発、クラウドでのデータサイエンスを合わせて 15 年以上の実務経験があります。休日は自然を巡ったり、友人や家族と過ごしたりするのが好きです。 Charlie Lee AWS のアジアパシフィックおよび日本におけるゲノミクス業界リードで、バイオインフォマティクスを専門とするコンピューターサイエンスの博士号を持っています。バイオインフォマティクス、ゲノミクス、分子診断で 20 年以上の経験を持つ業界のリーダーとして、最先端のシーケンス技術とクラウドコンピューティングを用いたゲノミクスで、研究の加速とヘルスケアの向上に情熱を注いでいます。 この記事はSolutions Architect の Masahiro Imai が翻訳しました。

本ブログは 2024 年 11 月 5 日に公開された AWS Blog「 Amazon Inspector suppression rules best practices for AWS Organizations 」を翻訳したものです。原文公開後のサービスアップデートを訳注として補足しています。 脆弱性管理は、ネットワーク、アプリケーション、インフラストラクチャのセキュリティに不可欠な要素であり、その目的は、機密データやインフラストラクチャが意図せずアクセスされたり露出したりすることから組織を保護することです。脆弱性管理の一環として、組織は通常、どの脆弱性が最大のリスクをもたらすかを判断するためのリスク評価を実施し、ビジネス目標や全体的な戦略への影響を評価し、関連する規制要件を精査します。 この記事では、 AWS Organizations 内のアカウント全体で脆弱性に適切な優先順位を付けるための仕組みの使い方を説明します。お客様の環境における Amazon Inspector の検出結果にリスクベースで優先順位を付けられるよう、リソースにタグを適用する方法を紹介します。また、重要度の低い検出結果を大規模に抑制するための、Amazon Inspector の抑制ルールの活用に関するベストプラクティスも解説します。さらに、継続的な脆弱性管理の文化を醸成するための取り組みについても取り上げます。 Amazon Inspector による脆弱性管理 Amazon Inspector は、 Amazon Web Services (AWS) のワークロードに対して、ソフトウェアの脆弱性や意図しないネットワークへの露出を継続的にスキャンする脆弱性管理サービスです。Amazon Inspector は、実行中の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Container Registry (Amazon ECR) 内のコンテナイメージ、および AWS Lambda 関数を自動的に検出してスキャンします。 Amazon Inspector は、ソフトウェアの脆弱性や意図しないネットワークへの露出を発見すると、 検出結果 を作成します。検出結果は、脆弱性を説明し、影響を受けるリソースを特定し、脆弱性の重要度を評価して、修復のガイダンスを提供します。Amazon Inspector で 抑制ルール を作成すると、重要度の低い検出結果を抑制し、優先度の高い検出結果に集中できます。 AWS Organizations における脆弱性管理のベストプラクティス AWS Organizations の組織内で数千件におよぶ脆弱性の検出結果に対処しやすくするために、このセクションで説明するベストプラクティスの活用をお勧めします。 ベストプラクティス 1: 委任管理者を設定する Amazon Inspector を使用すると、組織内の複数の AWS アカウントの脆弱性スキャンを管理できます。そのためには、AWS Organizations の管理アカウントが、いずれかのアカウントを Amazon Inspector の委任管理者アカウントとして指定する必要があります。委任管理者アカウントは、Amazon Inspector のデプロイを一元的に制御できるため、AWS Organizations 内の複数のアカウント全体で、セキュリティモニタリングタスクをより効率的かつ効果的に管理できます。これらのタスクには、メンバーアカウントのスキャンのアクティブ化や非アクティブ化、AWS リージョンごとの検出結果の集約、組織全体の集約された検出結果データの表示、抑制ルールの作成と管理が含まれます。 Amazon Inspector はリージョンごとのサービスであるため、Amazon Inspector を使用する各 AWS リージョンで、委任管理者の指定、メンバーアカウントの追加、スキャンタイプのアクティブ化を行う必要があります。委任管理者アカウントを設定する際は、以下の点に注意してください。 委任管理者は、組織内のアカウントの Center for Internet Security (CIS) スキャン設定を作成および管理できます。ただし、メンバーアカウントが作成したスキャン設定は対象外です。 マルチアカウント設定では、組織全体のスキャンモード設定を行えるのは委任管理者のみです。 Amazon Inspector を使用すると、組織全体の Amazon EC2 インスタンスに対して、OS レベルの CIS 設定ベンチマークに基づいたオンデマンドかつ対象を絞った評価を実行できます。 訳注: 2025 年 11 月より、AWS Organizations の Amazon Inspector ポリシーによる組織全体の管理がサポートされました。このポリシーを使用すると、組織内の全アカウント (新規追加アカウントを含む)、組織単位 (OU)、または個別のアカウントに対してスキャンタイプを自動的に有効化し、メンバーアカウントによる意図しない変更を防止できます。本文の委任管理者による管理と併用でき、ポリシーがスキャンタイプの有効化を制御し、委任管理者はスキャンモードなどの詳細設定を引き続き管理します。 ベストプラクティス 2: 抑制ルールで検出結果を大規模に管理する すべてのアカウントの検出結果には、個別の共通脆弱性識別子 (CVE) や Amazon リソースネーム (ARN) が数千件含まれている可能性があります。そのため、適切な抑制ルールを使ってこれらの検出結果を大規模に管理することが、脆弱性管理を成功させる鍵となります。 抑制ルール とは、フィルター属性と値のペアで構成される条件のセットで、指定した条件に一致する新しい検出結果を自動的にアーカイブすることで、検出結果をフィルタリングするために使用します。 抑制ルールを作成 して、対応する予定のない脆弱性を除外することで、最も重要な検出結果に優先順位を付けることができます。抑制ルールは検出結果自体に影響を与えず、Amazon Inspector による検出結果の生成を妨げることもありません。抑制ルールは検出結果のリストをフィルタリングするためだけに使用されます。これにより、検出結果の確認と優先順位付けが容易になります。 抑制ルールで使用できる便利なフィルターには、 [リソースタグ] 、 [リソースタイプ] 、 [重要度] 、 [脆弱性 ID] 、 [Amazon Inspector スコア] があります。例えば、重要度レベル (Critical、High、Medium、Low、Informational、Untriaged) に基づいて検出結果を分類できます。Amazon Inspector が各検出結果の重要度をどのように決定するかについては、「 Amazon Inspector の検出結果の重要度レベルについて 」を参照してください。 Amazon Inspector では、脆弱性、アカウント、インスタンスなどのさまざまなカテゴリで検出結果を絞り込んで確認できます。Amazon Inspector の [すべての検出結果] ページで CVE ID を選択すると、図 1 に示すように、影響を受けるリソースと個々の AWS アカウント ID の詳細を表示できます。これは、抑制ルールで使用するフィルター条件を選択する際に役立ちます。 図 1: Amazon Inspector の検出結果と重要度レベル 抑制ルールは組織レベルで管理します。設定したルールはすべてのメンバーアカウントに適用されます。Amazon Inspector が抑制ルールに一致する新しい検出結果を生成すると、その検出結果のステータスは自動的に [抑制済み] に設定されます。抑制ルールの条件に一致する検出結果は、デフォルトでは検出結果のリストに表示されません。そのため、抑制された検出結果はサービスクォータに影響しません。メンバーアカウントは、委任管理者から抑制ルールを継承します。委任管理者アカウントで作成できる抑制ルールはリージョンあたり 500 ルールで、これは引き上げられない上限 (ハードリミット) です。 組織内のメンバーアカウントは、抑制ルールを作成または管理できないことに注意してください。抑制ルールを作成および管理できるのは、スタンドアロンアカウントと Amazon Inspector の委任管理者のみです。したがって、組織内に自身の抑制ルールを個別に管理する必要があるメンバーアカウントがある場合は、そのアカウントの所有者が自分のアカウントで Amazon Inspector を個別にアクティブ化する必要があります。 ベストプラクティス 3: Amazon Inspector スコアに基づいて検出結果を抑制する 対応に割ける時間は限られており、特に大規模な組織ではセキュリティ脆弱性の検出結果の量が膨大になる可能性があります。そのため、組織に最大のリスクをもたらす脆弱性を迅速に特定して対応できる仕組みが必要です。 検出結果を抑制する手軽なアプローチの 1 つは、 Amazon Inspector スコア を使用することです。Amazon Inspector は、脆弱性に対する National Vulnerability Database (NVD) の共通脆弱性評価システム (CVSS) 基本スコアを構成するセキュリティメトリクスを検査し、お客様のコンピューティング環境に応じて調整したうえで、脆弱性の重要度を反映した 1～10 の数値スコアを生成します。 NVD/CVSS スコアは、攻撃の複雑さ、悪用コードの成熟度、必要な権限などのセキュリティメトリクスを組み合わせたものですが、リスクの尺度ではありません。 検出結果を過度に抑制しないよう注意してください。検出結果を過度に抑制すると、対策されていないセキュリティリスクにアプリケーションやシステムを意図せずさらしてしまう可能性があります。抑制ルールを適用する際は、慎重かつ節度あるアプローチを維持することが重要です。各検出結果の実際のリスクプロファイルを継続的に可視化しておくことは、プロアクティブで包括的な脆弱性管理に不可欠です。 ベストプラクティス 4: タグを使用してリスクベースの優先順位付けを可能にする スケーラブルな脆弱性管理ソリューションを実現するには、アカウント横断でリソースに適切にタグを付ける戦略を持つことが重要です。 脆弱性に優先順位を付けるには、まず各リソースのリスクレベルを理解して評価し、適切にタグを付けられるようにする必要があります。適切なタグ付けにより、 リスクベースの優先順位付け が可能になります。つまり、検出結果を評価する際に、リソースのリスクレベル、脆弱性の重要度、組織の環境に対する脆弱性の影響などの要素を考慮することで、重大な脆弱性に最初に集中できます。これは当たり前の推奨事項のように思えるかもしれませんが、その重要性は決して見過ごせません。クラウドでは、構築したすべてのものを把握し、保護する必要があります。潜在的なセキュリティイベントの影響とリスク経路を理解するために、資産のマッピングでは、資産間の関係性も併せて洗い出す必要があります。 クラウドリソースの問題を修復する際の優先度は、リソースの露出レベルによって決まります。一般的に、パブリックサブネット内のリソースはプライベートサブネット内のリソースよりも優先すべきです。同様に、本番環境で実行されているリソースは、開発環境やテスト環境のリソースよりも優先すべきです。 優先順位付けは、ファイアウォールルール、 AWS Identity and Access Management (IAM) ポリシー、サービスコントロールポリシー、セキュリティグループなどの要素にも左右されます。さまざまなポートやプロトコルを通じてインターネットに広く公開されているリソースは、厳格なアクセス制限があるリソースと比べて、サービス拒否 (DoS)、分散型サービス拒否 (DDoS)、スプーフィング、マルウェア、ランサムウェアなどの問題が発生する可能性が高くなります。 ベストプラクティス 5: 適切なリソースタグに基づいて抑制ルールを作成する 複雑なマルチアカウント環境では、リソース ID、サブネット ID、VPC ID を使用して抑制ルールを一元管理することは困難な場合があります。これらの値は個々のアカウントに固有であり、新しいデプロイや変更に伴って時間とともに変化するためです。その結果、抑制ルールを最新の状態に保つことが難しくなります。ここでは、タグに基づくリスクベースの優先順位付け (ベストプラクティス 4) と Amazon Inspector スコアを活用して、検出結果を効果的に管理し、優先順位を付け、追跡する方法を説明します。 以下は、脆弱性管理を目的として組織内の AWS クラウドリソース全体で使用できる、タグ付け戦略の推奨例です。 EnvironmentName, RiskExposureScore このタグ付け戦略により、環境全体で抑制ルールを通じた優先順位付けを行い、対応を後回しにする、あるいは対応対象外とすべき検出結果を除外し、優先度の高い検出結果に集中できます。また、リスク要因が異なる環境ごとに、個別のルールを作成することもできます。例えば、リスク露出レベルが低く、非本番環境にあり、重要度レベルが Informational、Untriaged、Low、または Medium であるリソースの検出結果を抑制するといったことが考えられます。さらに、レポートの作成やエクスポート時に [リソースタグ] フィールドを活用して、想定内の検出結果を除外することもできます。 以下の表では、Prod、Dev、Sandbox という 3 つの主要なアカウント区分を持つ AWS クラウド環境の例を示しています。想定されるリスク、露出レベル、ワークロードの重要性に基づいて、異なる重要度レベルの検出結果を抑制しています。この例では、RiskExposureScore の 1、2、3 をそれぞれ低、中、高に相当するものとして使用しています。つまり、RiskExposureScore 1 は、機密性が低い、またはインターネットへの露出がほとんどないワークロードに使用します。一方 RiskExposureScore 3 は、機密性が高い、または重要なワークロードのうち、インターネットに露出している、保護が不十分である、あるいは設定やサイバーハイジーン (cyber hygiene) の不備によりセキュリティリスクが高い可能性があるものに使用します。 EnvironmentName RiskExposureScore 重要度 抑制対象 Prod 1 Medium、Low、Informational、Untriaged はい Prod 2 Low、Informational、Untriaged はい Prod 3 Informational、Untriaged はい Dev 1、2 Medium、Low、Informational、Untriaged はい Dev 3 Low、Informational、Untriaged はい Sandbox 1、2 Critical、High、Medium、Low、Informational、Untriaged はい Sandbox 3 High、Medium、Low、Informational、Untriaged はい この例では、Prod および Dev アカウントのリソースについては重要度が High または Critical である脆弱性の検出結果を残す一方で、その他のリソースについてはリスク露出レベルに応じて異なる抑制ルールを定義しています。また、Sandbox アカウントには重要なワークロードがないため、脆弱性の検出結果の大部分を抑制するようにしています。この例をモデルとして、環境全体で抑制ルールを設定し、ニーズに応じて脆弱性の検出結果に優先順位を付けることができます。さらに、修復作業を進めながら抑制ルールを見直し、修正、再評価できることも覚えておいてください。これらを継続的なプロセスとして行うことがベストプラクティスです。 ベストプラクティス 6: Amazon Inspector を AWS Security Hub と統合する Amazon Inspector を AWS Security Hub と 統合 すると、Amazon Inspector から Security Hub に検出結果を送信できます。Security Hub は、これらの検出結果をお客様のセキュリティポスチャの分析に含めることができます。抑制ルールに一致する Amazon Inspector の検出結果は自動的に抑制され、Security Hub コンソールには表示されません。 訳注: 本記事の AWS Security Hub は、2025 年に AWS Security Hub CSPM (Cloud Security Posture Management) へ名称変更されたサービスを指します。現在「AWS Security Hub」は、リスクの優先順位付けなどの機能を備えた別の新サービスの名称として使われているため、コンソールやドキュメントを参照する際はご注意ください。 ベストプラクティス 7: 抑制ルールを定期的に再評価する セキュリティポスチャを最新に保ち、健全なクラウド環境を維持する鍵は、脅威の状況の変化に合わせて脆弱性管理のアプローチを見直し、適応させ続けることです。ここでは、重点的に取り組むべきプラクティスをいくつか紹介します。 脆弱性の検出結果を抑制しているルールを定期的に見直し、再評価してください。脆弱性と脅威は常に進化しているため、以前に抑制したものを再度有効にする必要が生じるかもしれません。 脆弱性管理を静的な手順ではなく、継続的で反復的なプロセスとして捉えてください。新たなリスクにリアルタイムで対処するために、セキュリティコントロールを定期的に評価し、更新し、適応させてください。 初期の修復だけでなく、継続的なモニタリングと対応も重視してください。脆弱性はライフサイクル全体を通じて包括的に対処する必要があります。 セキュリティを意識し、迅速に対応する文化を組織全体で醸成してください。全員が継続的に脆弱性の特定と軽減に取り組むことが求められます。 脆弱性管理プログラムが、関連するコンプライアンス要件や規制要件 (例えば PCI-DSS 、 HIPAA 、 NIST CSF ) に準拠していることを確認してください。 まとめ この記事では、抑制ルールを使用し、リスクベースの優先順位付けを適用することで、組織の AWS インフラストラクチャ全体で Amazon Inspector の検出結果に大規模かつ効果的に優先順位を付ける方法を紹介しました。また、Amazon Inspector の検出結果の修復に優先順位を付けるための効果的な戦略として、リソースのタグ付けを活用する方法についても説明しました。Amazon Inspector に関連するその他のブログ記事については、Amazon Web Services ブログの Amazon Inspector カテゴリ を参照してください。 Mojgan Toth Mojgan は AWS の Senior Technical Account Manager です。公共部門のお客様に対して、戦略的な技術ガイダンス、ソリューション、AWS クラウドのベストプラクティスを積極的に提供しています。Well-Architected Framework に基づいたソリューションを組み立てることが大好きです。仕事以外では、料理や絵画、そして家族、特に 3 人の幼い息子たちと過ごす時間を楽しんでいます。息子たちはサイクリングやハイキングなどのアウトドアアクティビティが大好きです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 1 月 26 日に公開された AWS Blog “ Export a Software Bill of Materials using Amazon Inspector ” を翻訳したものです。 Amazon Inspector は、 Amazon Web Services (AWS) ワークロードのソフトウェアの脆弱性と意図しないネットワークの露出を継続的にスキャンする、自動化された脆弱性管理サービスです。Amazon Inspector の機能が拡張され、 Windows EC2 インスタンス を除く、Amazon Inspector がモニタリングするサポート対象リソースの統合された ソフトウェア部品表 (SBOM) をエクスポートできるようになりました。 訳注: 本記事公開後の 2026 年 2 月 28 日より、エージェントレス方式でスキャンされる Windows EC2 インスタンスの SBOM エクスポートがサポートされました。エージェントベース方式の Windows EC2 インスタンスは引き続き対象外です。詳細は「 Amazon Inspector による SBOM のエクスポート 」を参照してください。 お客様からは、Amazon Inspector がモニタリングするリソースから収集したソフトウェアアプリケーションのインベントリを追加で提供してほしいというご要望をいただいていました。これにより、現在の Amazon Inspector の検出結果に関連する可能性のあるソフトウェアサプライチェーンやセキュリティ上の脅威を追跡できるようになります。SBOM を生成すると、最も頻繁に使用しているパッケージや、組織全体に影響を及ぼす可能性のある関連する脆弱性など、ソフトウェアサプライチェーンの詳細を可視化する重要なセキュリティ情報が得られます。 このブログ記事では、組織全体で Amazon Inspector がモニタリングするリソースの統合された SBOM を、 CycloneDx や SPDX といった業界標準形式でエクスポートする手順を紹介します。また、 Amazon Athena を使用して SBOM アーティファクトを分析するためのアプローチと、そこから得られる洞察についても共有します。 概要 SBOM は、ソフトウェアコンポーネントを構成する要素のリストを含む、ネストされたインベントリとして定義されます。セキュリティチームは、Amazon Inspector の AWS マネジメントコンソールにあるリソースカバレッジページから、組織全体の統合された SBOM を Amazon Simple Storage Service (Amazon S3) にエクスポートできます。 CycloneDx や SPDX の業界標準形式を使用することで、SBOM から得られる洞察をもとに、組織全体でどのソフトウェアパッケージを更新する必要があるか、他に選択肢がない場合はどのパッケージを廃止するかといった意思決定を行えます。個々のアプリケーションエンジニアやセキュリティエンジニアは、コンソールまたはアプリケーションプログラミングインターフェイス (API) の SBOM エクスポートワークフローの中で、特定のアカウント、リソースタイプ、リソース ID、タグ、またはこれらの組み合わせによるフィルターを適用して、単一のリソースやリソースグループの SBOM をエクスポートすることもできます。 SBOM のエクスポート Amazon Inspector の SBOM レポートを S3 バケットにエクスポートするには、SBOM レポートのエクスポート先となる AWS リージョンにバケットを作成して設定する必要があります。Amazon Inspector のみがバケットに新しいオブジェクトを配置できるように、 バケットのアクセス許可を設定 する必要があります。これにより、他の AWS サービスやユーザーがバケットにオブジェクトを追加できないようにします。 各 SBOM レポートは S3 バケットに保存され、指定したエクスポート形式に応じて Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) という名前が付けられます。また、 S3 イベント通知 を使用して、新しい SBOM レポートがエクスポートされたことを各運用チームに通知することもできます。 Amazon Inspector では、SBOM レポートの暗号化に AWS Key Management Service (AWS KMS) キーを使用する必要があります。このキーはカスタマーマネージドの対称暗号化 AWS KMS キーであり、SBOM レポートの保存用に設定した S3 バケットと同じリージョンにある必要があります。SBOM レポート用の新しい AWS KMS キーには、Amazon Inspector がキーを使用できるようアクセス許可を付与する キーポリシー を設定する必要があります (図 1 を参照)。 図 1: Amazon Inspector の SBOM エクスポート 訳注: 現在は、バージョン範囲指定などにより特定の名前・バージョンに解決できないパッケージ (未解決ハッシュ) も SBOM エクスポートに含まれるようになりました。これらのパッケージは脆弱性スキャンの対象にはなりませんが、ハッシュ値がエクスポートされたコンポーネント一覧に記録されます。 前提条件のデプロイ 提供されている AWS CloudFormation テンプレートは S3 バケットを作成し、Amazon Inspector が SBOM レポートオブジェクトをそのバケットにエクスポートできるようにするバケットポリシーを関連付けます。このテンプレートは、SBOM レポートのエクスポートに使用する新しい AWS KMS キーも作成し、Amazon Inspector サービスにキーを使用するアクセス許可を付与します。 エクスポートは、 Amazon Inspector の委任された管理者アカウント または Amazon Inspector の管理者アカウント自体から開始できます。これにより、S3 バケットには Amazon Inspector のメンバーアカウントのレポートが格納されます。同じリージョンにデプロイされた Amazon Inspector から SBOM レポートをエクスポートするには、CloudFormation テンプレートがその AWS アカウントとリージョン内にデプロイされていることを確認してください。複数のアカウントで Amazon Inspector を有効にしている場合は、Amazon Inspector が有効になっている各リージョンに CloudFormation スタックをデプロイする必要があります。 CloudFormation テンプレートをデプロイするには 次の Launch Stack ボタンを選択して、アカウントで CloudFormation スタックを起動します。 テンプレートのスタック名とパラメータ ( MyKMSKeyName と MyS3BucketName ) を確認します。S3 バケット名は一意である必要がある点に注意してください。 [次へ] を選択して、スタックのオプションを確認します。 次のページに進み、 [送信] を選択します。CloudFormation スタックのデプロイには 1～2 分かかります。 CloudFormation スタックのデプロイが正常に完了したら、スタックによって作成された S3 バケットと AWS KMS キーを使用して SBOM レポートをエクスポートできます。 SBOM レポートのエクスポート セットアップが完了したら、SBOM レポートを S3 バケットにエクスポートできます。 コンソールから SBOM レポートをエクスポートするには S3 バケットと AWS KMS キーを作成したのと同じリージョンの Amazon Inspector コンソールに移動します。 ナビゲーションペインから [SBOMs] を選択します。 フィルターを追加 して、リソースの特定のサブセットのレポートを作成します。フィルターを指定しない場合は、アクティブでサポート対象のすべてのリソースの SBOM がエクスポートされます。 希望するエクスポートファイルタイプを選択します。オプションは Cyclonedx_1_4 (Json) または Spdx_2_3-compatible (Json) です。 CloudFormation テンプレートの出力セクションにある S3 バケット URI を入力し、作成した AWS KMS キーを入力します。 [エクスポート] を選択します。エクスポートするアーティファクトの数に応じて、完了までに 3～5 分かかることがあります。 図 2: SBOM エクスポートの設定 エクスポートが完了すると、すべての SBOM アーティファクトが S3 バケットに格納されます。S3 バケットから SBOM アーティファクトをダウンロードすることも、 Amazon S3 Select を使用して標準 SQL クエリでオブジェクトからデータのサブセットを取得することもでき、柔軟に活用できます。 図 3: Amazon S3 Select 訳注: Amazon S3 Select は新規のお客様には提供されていません (すでにご利用のお客様は引き続き利用できます)。同等の処理には、本記事で後述する Amazon Athena の利用を検討してください。 また、 Amazon Athena を使用して高度なクエリを実行したり、 Amazon QuickSight を使用してダッシュボードを作成したりすることで、洞察を得たり傾向を把握したりすることもできます。 クエリと可視化 Athena を使用すると、S3 バケットに保存されている生データに対して SQL クエリを実行できます。Amazon Inspector のレポートは S3 バケットにエクスポートされます。「 AWS Glue クローラーの追加 」のチュートリアルに従って、テーブルを作成しデータをクエリできます。 AWS Glue が S3 データをクロールできるようにするには、AWS Glue クローラーのチュートリアルに記載されているロールを AWS KMS キーのアクセス許可に追加して、AWS Glue が S3 データを復号できるようにする必要があります。 以下は、ユースケースに合わせて更新できるポリシー JSON の例です。AWS アカウント ID の <111122223333> と S3 バケット名の <DOC-EXAMPLE-BUCKET-111122223333> は、必ずお客様自身の情報に置き換えてください。 { "Sid": "Allow the AWS Glue crawler usage of the KMS key", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: <111122223333> :role/service-role/AWSGlueServiceRole-S3InspectorSBOMReports" }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "arn:aws:s3::: <DOC-EXAMPLE-BUCKET-111122223333> " }, 注: AWS Glue 用に作成されたロールには、クローラーを作成するために、レポートのエクスポート先である S3 バケットを読み取るアクセス許可も必要です。AWS Glue の AWS Identity and Access Management (IAM) ロールによって、クローラーの実行と Amazon S3 データストアへのアクセスが許可されます。 AWS Glue データカタログを構築した後は、クローラーをスケジュール実行するように設定することで、S3 バケットにエクスポートされる最新の Amazon Inspector の SBOM マニフェストを常に反映した状態に保つことができます。 さらに、クローラーによって追加されたテーブルに移動し、Athena でデータを表示できます。Athena を使用すると、Amazon Inspector のレポートに対してクエリを実行し、環境に関連する出力データを生成できます。生成される SBOM レポートのスキーマは、レポート内の特定のリソース ( Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS Lambda 、 Amazon Elastic Container Registry (Amazon ECR) ) によって異なります。そのため、スキーマに応じて、レポートから情報を取得する Athena の SQL クエリを作成できます。 以下は、SBOM レポート内のリソースについて上位 10 件の脆弱性を特定する Athena クエリの例です。レポートに含まれる CVE (共通脆弱性識別子) を使用して、CVE の影響を受ける個々のコンポーネントを一覧表示できます。 SELECT account, vuln.id as vuln_id, count(*) as vuln_count FROM <Insert_table_name>, UNNEST(Inset_table_name.vulnerabilities)as t(vuln) GROUP BY account, vuln.id ORDER BY vuln_count DESC LIMIT 10; 以下の Athena クエリの例では、上位 10 件のオペレーティングシステム (OS) を、リソースタイプおよびその数とともに特定できます。 SELECT resource, metadata.component.name as os_name, count(*) as os_count FROM <Insert_table_name> WHERE resource = 'AWS_LAMBDA_FUNCTION' GROUP BY resource, metadata.component.name ORDER BY os_count DESC LIMIT 10; 重大な脆弱性を持つパッケージがあり、そのパッケージがプライマリパッケージとして使用されているのか、依存関係として追加されているのかを知りたい場合は、以下の Athena のサンプルクエリを使用して、アプリケーション内のパッケージを確認できます。この例では、Log4j パッケージを検索しています。結果として account ID 、 resource type 、 package_name 、 package_count が返されます。 SELECT account, resource, comp.name as package_name, count(*) as package_count FROM <Insert_Table _name>, UNNEST(<Insert_Table_name>.components) as t(comp) WHERE comp.name = 'Log4j' GROUP BY account, comp.name, resource ORDER BY package_count DESC LIMIT 10 ; 注: サンプルの Athena クエリは、SBOM エクスポートレポートのスキーマに応じてカスタマイズする必要があります。 このソリューションをさらに拡張するには、 Amazon QuickSight を使用して AWS Glue テーブルに接続し、データを可視化するダッシュボードを作成できます。 訳注: Amazon QuickSight は 2025 年 10 月に Amazon Quick Suite へ進化 し、現在は Amazon Quick として提供されています (BI 機能は Quick Sight コンポーネントとして存続し、既存の API や連携は変更なく動作します)。また、本記事の発展形として、Lambda と Amazon EventBridge によるエクスポートの自動化からダッシュボードでの可視化までを実装した「 Enhance container software supply chain visibility through SBOM export with Amazon Inspector and QuickSight 」も公開されています。 まとめ Amazon Inspector の新しい SBOM 生成機能は、複数レベルの依存関係にわたるソフトウェアパッケージのリストを提供することで、ソフトウェアサプライチェーンの可視性を向上させます。また、SBOM を使用して各ソフトウェアパッケージのライセンス情報をモニタリングし、組織内の潜在的なライセンス違反を特定することで、潜在的な法的リスクの回避にも役立ちます。 SBOM エクスポートの最も重要なメリットは、業界の規制や標準への準拠を支援できることです。業界標準の形式 (SPDX と CycloneDX) を提供し、他のツール、システム、サービス (Nexus IQ や WhiteSource など) との容易な統合を可能にすることで、インシデント対応プロセスの効率化、セキュリティ評価の正確性と速度の向上、規制要件へのコンプライアンスの維持を実現できます。 これらのメリットに加えて、SBOM エクスポート機能は、リソース内で検出された OS パッケージやソフトウェアライブラリの把握にも役立ち、業界の規制や標準への準拠をさらに強化します。   この記事で共有した情報に関するご質問がある場合は、 Amazon Inspector re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。 Varun Sharma Varun は、セキュリティのマントを誇らしげにまとう AWS クラウドセキュリティエンジニアです。Amazon Cognito と IAM の謎を解き明かす才能を持ち、これらのサービスの頼れる専門家です。クラウドのセキュリティ確保の手を休めているときは、セキュリティペネトレーションテストの世界に没頭しています。そして画面から離れているときは、気分を切り替えて、カメラのレンズを通して自然の美しさを捉えています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは、AWS ソリューションアーキテクトの秦です 現在、AI コーディングエージェントの活用が広がり、コーディングの生産性は大きく向上しています。 筆者がとある開発部門で、AI コーディングエージェントの導入を支援するプロジェクトに参加したところ、個人利用の段階では成果が出ていたものの、複数チームへの展開を始めたところでいくつかの課題に直面しました。 本記事では、そのチーム展開の際に直面した課題に対して私たちが実際に行ったアプローチと、そこから得られた学びを共有します。 なお、本記事は、特定のプロジェクトでの経験談であり、すべての組織にそのまま当てはまるとは考えていませんが、これから AI 駆動開発をチームに広げようとしている開発リーダーやアーキテクトの方の参考になれば幸いです。 チーム展開で直面した課題 まず、要点を整理すると、AI コーディングエージェントのチーム展開を始めるうえで見えてきた課題は次の 4 つに集約されました。 出力品質が個人のプロンプトの書き方に依存し、ばらつく 組織で決めた開発プロセス（分析 → 設計 → 実装 → テストなど）のステップに従わないケースがある うまく使えているメンバーの工夫が他のメンバーに共有されない レビューやセキュリティ検証が仕組みとして組み込まれていない 原因を追うと、いずれもエージェントが「チームのやり方」を知らないまま動いていることに行き着きました。 そのため、ルール・プロセス・品質基準をファイルとして整備してエージェントに読ませ、検証で得た学びをルールに還元する取り組みを段階的に進めました。 実装には Kiro を使いましたが、同種の機能があれば他のツールでも構成は再現できると考えています。 なお、ルールを書けばエージェントが必ず従うわけではなく、コンテキストが長いとルールが埋もれる、指示が矛盾すると挙動が不安定になる、といった課題が残ります。 ルール化できる範囲を仕組みで担保する、というのが今回のポイントです。 検討のステップ 検討時には、重要な前提があります。 一度に完成させることはできない ということです。全ルール・全プロセス・全ナレッジを最初から適用しようとすると、書く側も使う側も破綻します。 そこで、整備の進め方を以下のように考えてみました。 あくまで一例として捉えていただければと思います。また、各ステップを整備すると次の問題が見えてくるという構造になっています。 段階 内容 ステップ 1 ルールの明文化 ステップ 2 知識の分割と役割の分離 ステップ 3 ワークフローの構造化と棚卸し ステップ 4 品質ゲートの組み込み ステップ 5 学習ループと組織展開 ステップ 1: ルールの明文化 展開初期は、各メンバーがプロンプトで毎回規約を指示しており、書き忘れた項目はエージェントが自己流で埋めるということも多いかと思います。 そこで、毎回伝えていたルールを Steering のファイルに固定し、全セッションに読み込ませ、既存のコーディング規約から違反頻度の高い項目を抜粋し、技術スタック、禁止事項、完了の定義を加えた形を作ります。 完了の定義は重要で、基準を渡さないと、エージェントはコンパイルが通った時点で「完了しました」と報告し、テストを省略することがあります。 「ビルド成功、単体テスト全パス、Lint エラーゼロ」のように判定可能な形で書くようにすると指示が明確になります。 一方、ビルドコマンドの手順だけを並べただけでは、エージェントが基準を理解せずコマンドを実行するだけになる場合があるため、「何を実行するか」と「何をもって完了とするか」は両方定義しておくと安心です。 ステップ 2: 知識の分割と役割の分離 ルールが育つとコンテキストの肥大化が問題になります。ルールを足したのに守られないルールが増えるというケースがあるため、常時読ませるファイルは禁止・必須ルールだけに絞り、詳細なパターン解説やコード例は必要なときだけ読み込まれる Skills に移します。 もう一つは実装とレビューの分離です。同じエージェントに両方させると「問題なし」で返ってくることが多く、レビュー専用のサブエージェントを分けました。 ただし、ルールに書いてあっても AI レビューが見逃すことがあり、確実に検出したい項目はレビュー側のチェックリストにも重ねて載せています。 委譲はメインエージェントからの一方向のみとし、差し戻しは例えば同一タスク 2 回まで、超えたら人間に渡す運用にします。 ステップ 3: ワークフローの構造化と棚卸し タスク単位は安定しても、設計を飛ばして実装が始まる、テスト省略のまま完了になるというケースがあり、メインエージェントを「自分では実装しないオーケストレーター」とし、指示書にフェーズ順序と完了条件を明記して、満たさなければ次に進めない構成にしました。 セッションをまたぐ引き継ぎには、合否フラグ付きのフィーチャーリストと進捗ログをファイルで残し、開始時に読ませます。 棚卸しに使った 4 象限 この時点で、整備が場当たり的にならないように全体像の棚卸しするために、タイミング軸（事前/事後）× 読者軸（人間/AI）の 4 象限で成果物を分類してみました。 事前（やる前に決める） 事後（やった後に確認する） 人間が読む A. ガイドドキュメント ・方式設計書 ・テスト仕様書 ・リリース手順書　等 B. 記録・承認 ・テスト結果報告書 ・レビュー記録　等 AI が読む C. ルール・パターン定義 ・ steering ・ skills ・ agents 　等 D. 自動検証ツール ・静的解析 ・AI レビュー ・品質ゲート　等 分類してみると、ステップ 1〜2 で作ったものは C 象限（AI が事前に読むルール）に集中しがちで、A・B 象限は従来の開発プロセスの資産がそのまま残っている一方、D 象限（AI の出力を事後に機械検証する仕組み）は追加整備が必要な状況でした。 D はルールが守られたかを確認する整備になっていて、これが次の品質ゲートに取り組むきっかけになります。 また、A・B 象限の成果物は残り続けますが、人間がどの粒度で読むかは変わってきます。実際、テスト結果は AI が要約したものを人間が確認する形に移りつつあります。 変わらなかったのは、承認の責任がプロセスのどこにあるかであるため、この観点を整備の判断軸にしています。 ステップ 4: 品質ゲートの組み込み ステップ 1 が基準の「宣言」だとすると、ステップ 4 はその「守り」です。この二つが対になって初めてエージェントの環境整備が機能します。そのために品質ゲートを検討します。品質ゲートは次の 2 点がポイントです。 合否判定可能な完了条件 : 「ビルド成功」「静的解析の指摘ゼロ」など、機械的に Yes/No が決まる条件を事前に合意する 不合格なら進めない構造 : 条件を満たさない限り次フェーズに進めない関門を仕組みとして置く 実装は、ビルド・カバレッジ・静的解析・AI レビューを一括実行するゲート用サブエージェントを定義し、タスク完了時にオーケストレーターから呼び出す形にして、不合格ならタスクは未完了に戻ります。 既存の CI で検証できる項目は同じコマンドをゲートからローカルで実行して再利用し、ブラウザ操作での E2E テストや AWS リソースの検証など、CI に乗っていない検証だけを Model Context Protocol (MCP) による外部ツール連携で追加しました。ゲートを新規に作るというより、既存の検証資産を関門として組み込み直す作業が中心になるかと思います。 また、ゲートに入れる項目は機械判定できるものに限定しました。要件の妥当性のような項目まで入れると、判定が安定せず外す可能性があります。 UX の良し悪しなど熟練者の判断に依存する項目は人間レビューに残し、ゲートは「機械で落とせる不合格を先に落とし、人間のレビューを設計判断に集中させる前処理」と位置づけました。 4 象限でいえば、D 象限を埋めた上で、B 象限の人間の承認は残す、という分担です。 また、整備の効果測定には「評価セット」を用意しました。チームで頻出するタスクの指示文（既存画面への項目追加、API エンドポイントの新設など）を数個固定したテスト問題集のようなもので、同じ指示を複数回実行し、品質ゲートをすべて通過した割合を成功率として記録します。 AI の出力は同じ指示でも毎回変わるため、1 回の試行では整備の効果を判断できないからです。ルール変更の前後でこの成功率を比較することで、「なんとなく良くなった」ではなく数値で改善を確認できるようにしました。 ステップ 5: 学習ループと組織展開 また、環境整備する上で得た学びとして、レビューで繰り返し指摘されるパターンを記録し、汎用的なものは Steering や Skills に「昇格」させるという営みも重要です。 この記録と昇格のトリガーには Hooks を使い、セッション終了時に、開発者が入力した修正指示を自動的に学習候補として記録し、後から Steering / Skills への昇格を判断する運用です。 同時に、モデルの進化に応じて効きの薄くなったルールを削る「棚卸し」も行います。ルールは積み上げるだけでなく、不要になった補助輪を外す運用も含みます。できれば数か月に一度の再評価が目安です。 まとめ 本記事では、AI コーディングエージェントをチームに展開する際に直面した課題と、それに対して私たちが行った環境整備をご紹介しました。 チーム展開で見えてきた課題は、出力品質のばらつき、開発プロセスの不徹底、工夫の属人化、検証の仕組みの不在の 4 つでした。 いずれもエージェントが「チームのやり方」を知らないまま動いていることが原因であり、ルール・プロセス・品質基準をファイルとして整備してエージェントに読ませ、得られた学びをルールに還元する、という取り組みを段階的に進めました。 整備は一度に完成させるのではなく、ルールの明文化から始めて、知識の分割と役割の分離、ワークフローの構造化、品質ゲートの組み込み、学習ループの構築へと、各ステップで見えてきた課題に応じて進めています。本文で挙げた各ステップの症状は、チームの整備がどこまで進んでいるかを見極める手がかりにもなるかと思います。 特定のプロジェクトでの経験談ではありますが、これから AI 駆動開発をチームに広げようとしている方の参考になれば幸いです。 著者のプロフィール 秦 将之 ソリューションアーキテクトとして、お客様の AWS 導入と活用のご支援を担当しています。開発プロセスの改善や自動化が好きで、最近は Kiro Crew を使った開発ワークフローを試しています。 堀 貴裕 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業やシステムインテグレーターのお客様のご支援を中心に活動しています。最近は Kiro を使ったお客様の業務変革支援に邁進中です。 参考 Kiro Documentation: https://kiro.dev/docs/

本ブログは、コニカミノルタ株式会社と Amazon Web Services Japan が共同で執筆しました。 はじめに 2026 年 6 月 25 日、26 日に幕張メッセで開催された AWS Summit Japan 2026 で、コニカミノルタ株式会社 ( 以下、コニカミノルタ ) は「Amazon Bedrock による自然言語駆動型自律実験」を展示しました。自然言語の指示を AI が構造化し、カメラで実験台の状態を確認しながらロボットアームを動かし、結果を電子実験ノートへ戻すデモです。生成 AI、ロボティクス、記録基盤を一つの流れにつなぎ、Physical AI による「未来の実験室」の可能性を紹介しました（図 1）。 図 1 展示した実機デモ。 Amazon Bedrock  とロボティクスを組み合わせ、「未来の実験室」の可能性を示しました。 1. 研究開発と「未来の実験室」 コニカミノルタは、光学・画像・材料・微細加工の技術を幅広い事業で培ってきました。研究開発では、実験内容を次の判断へつなげる記録も重要です。電子実験ノートと社内ナレッジ共有基盤に、生成 AI の要約・通知を組み合わせ、記録を検索・再利用しやすくしています（図 2）。今回の展示は、この基盤を実験の指示と実行まで広げる試みです。 図 2 電子実験ノートの記録を生成 AI が要約・通知する仕組み。 2. Materials Informatics (MI) を支えるハイスループット実験 MI には十分な実験データが必要です。しかし材料開発は、高粘度材料や粉体、多段工程などを扱うため、既製の自動化設備を適用しにくい場合があります。 「未来の実験室」では、目的別に設計するハイスループット（HT）実験でデータを増やし、MI や生成 AI で次の判断を支援します。記録、実行、解析を循環させ、開発を加速します（図 3）。 図 3 「未来の実験室」の構想。生成 AI とロボットの連携により、発案、計画、実行を支援します。 3. 展示したデモ 来場者が電子実験ノートに「緑色を作ってください」などと入力すると、システムが複数のカラーフィルムから必要なものを選び、ロボットアームが重ね合わせて目標色へ近づけます。カメラが実験台を撮影し、Amazon Bedrock 上の基盤モデルが自然言語と画像からフィルムの種類と順番を判断します。ロボットアームは指定された操作を実行し、その結果を次の判断に利用します。 色づくりは短時間で仕組みを理解できる展示用タスクですが、人が目的を伝え、AI が状態を見て操作を選び、ロボットが実行する閉ループ実験の最小構成になっています。 発展例として、pH の値を見ながら溶液を加え、目標値まで調整する動画も紹介しました。将来は試薬調整、測定、分析、記録へ広げます。 図 4 システム構成。電子実験ノートの指示を Amazon Bedrock が解釈し、Worker PC を介してロボットアームを動かします。 4. 自然言語を安全に物理操作へつなぐ 安全性、再現性、監査性を確保するため、LLM が座標や動作列を直接生成せず、自然言語を構造化された中間表現へ変換します。例えば「緑色を作ってください」という指示を、目標色、利用可能なフィルム、操作候補、停止条件などに分解し、JSON 形式で出力します。座標制御やアクション列は、人が設計した決定論的な制御層が担います（図 5）。 図 5 自然言語から座標データまでの流れ。LLM は構造化と関数選択を担い、後段を検証可能な処理にしています。 存在しない対象や実現できない色を指定された場合は、無理に操作せず停止します。Physical AI では、動作性能だけでなく、止まるべき場面で確実に止まる設計が重要です。 5. 軽量モデルで動かせた理由 Amazon Bedrock 上の Claude Haiku 系モデルを使用しました。LLM の役割を自然言語と画像の解釈、中間表現への変換に絞り、物理制御を決定論的ロジックへ分けることで、軽量モデルでも速度とコストを両立しました。 6. 来場者の反応と開発 製造、化学、通信、商社、メディア、SIer など幅広い業界の方にご覧いただき、自然言語の指示でロボットが動く様子に関心が集まりました。 技術者から特に多かったのは、「LLM が生成した JSON を制御関数や座標へどう変換するか？」という質問です。AI の判断範囲と機器制御の境界に、実装上の本質があることを共有できました。座標を直接指定する試作から、Stack、Pick、Place、Remove などの操作をカプセル化。ここまでを 2 ヶ月ほどで実装し、開発には Kiro CLI をフル活用しました。 7. 研究開発基盤への展開 この展示を Physical AI と呼ぶのは、AI が現実の状態を観察し、目標との差を判断して物理操作を行うためです。ただし、目指すのは一過性のロボットデモではありません。 実験の指示、条件、操作、結果、ログを電子実験ノートへ戻し、検索・追跡できる形で残すことが重要です。再利用可能な記録が、次の仮説検証、品質確認、知財化や論文化を支えます。 自然言語の実験意図を Amazon Bedrock で構造化し、物理操作へつなぎ、結果を記録へ戻す。この循環により、実験室を知識、データ、実行が連携する研究開発基盤へ変えていきます。コニカミノルタには、産業機器のハードウェア技術、光学・画像・材料の知見、クラウド人財、研究開発現場があります。記録、再現性、品質、知財まで横断して設計できる点が強みです。 8. 今後の展望 今後は、複数のロボットアーム、搬送ロボット、電子天秤、ピペット、pH メーター、分注機、測定装置などとの連携を検討します。自動化自体を目的にせず、HT 化する実験と蓄積するデータの粒度を設計します。装置、材料、データサイエンス、クラウド、現場運用を横断し、実験をデータ駆動型へ変えます。 実運用では、判断と結果を検証できるログが不可欠です。安全性、品質、知財、監査性を考慮し、AI、ロボット、人が担う範囲と、記録する情報を明確にします。 まとめ 今回の展示は、自然言語で書かれた実験意図を生成 AI が構造化し、ロボットの物理操作へ変換し、結果を実験記録へ戻す最小構成を示したものです。 生成 AI の価値はチャット画面の中だけにとどまりません。記録、クラウド、AI、ロボティクスがつながることで、実験室は知識を蓄え、その知識から次のデータを生み出すシステムへ変わります。 コニカミノルタと AWS は、今後も対話と実装を重ね、生成 AI とクラウドが研究開発にもたらす可能性を探っていきます。 図 6 AWS Summit Japan 2026 で展示を担当したコニカミノルタメンバー。 執筆者 コニカミノルタ株式会社 技術開発本部 データサイエンスセンター データジェネレーション部 野場 考策 技術開発本部 データサイエンスセンター データジェネレーション部 室田 和敏 技術開発本部 デバイス技術開発センター マテリアルサイエンス部 成毛 章容 アマゾンウェブサービスジャパン合同会社 ハイテク&ヘルスケア事業本部 アカウントマネージャー 池田 拓生 ソリューションアーキテクト 森下 裕介

モノやサービスが生まれる現場では、開発から運用に至るさまざまなフェーズで、日々多くのデータが生まれています。かつてのモノづくりの現場では、「製品が世に出たら、お客様がどう使っているかは見えづらい」ことが当たり前でしたが、この前提は変化しつつあり、現在はモノやサービスがリリースされた後も、さまざまなシグナルを得られる時代になりました。顧客管理や売上の履歴、お客様からの問い合わせ、レビュー、デバイスが送信する稼働メトリクスなど…。これらのデータから得られるシグナルを速やかにキャッチして改善につなげていくことが、モノ・サービスの競争力を高め、企業価値を成長させる大きな要素になりうるでしょう。 しかし現実には、これらのデータを活用し、開発サイクルへシームレスにつなげられている組織は、まだ多くありません。データは集まっている、だがそれらを活用しきれていない、といったお声はよくいただきます。 本記事では、どうすればリリース後のデータを活用し、得られたインサイトを次の開発サイクルに適用できるのかを掘り下げ、誰もが体験可能なサンプルシナリオとともに紹介します。 なぜ運用データは次の開発につながらないのか 図 ：運用フェーズにおけるデータ活用イメージ リリース後に集まるデータを製品の改善に活かそうとするとき、多くの組織が共通して行き当たるのが、二つの「サイロ」に関する課題です。 一つ目は、 サイロ化されたデータに関する課題 です。納品実績は営業部門に、問い合わせ履歴はサポート部門に、稼働データは保守部門に、製品仕様は開発部門にと、データは複数のドメインに分散しています。製品の問題解決や顧客要望に応える必要性が顕在化したとしても、担当者は自部門のデータにしかアクセスできず、全体像を見渡せないまま、調査の方向性を定めることすら難しいのが実情です。 二つ目は、 サイロ化された人材に関する課題 です。意味のある分析を行うためには、データを扱う技術、製品の知識、現場の実情という複数領域の知識が必要とされることも多いでしょう。しかしながら、多くの組織において、横断的な知識を備えた人材が存在することは稀です。真の課題にたどり着くために、複数のステークホルダーを集めて議論を重ねるケースも多いと思います。もちろんそれは有益であるものの、どうしても結論にたどり着くまでに時間がかかってしまい、スピーディーな解決につながりづらいことも多いと考えられます。 これら 2 つのサイロを乗り越え、日々集まるデータを改善サイクルの起点に変えていくには、次のような仕組みが鍵になるはずです。 さまざまな場所に分散するデータを、仮想的に一つにまとめて扱える仕組み 構造化・非構造化を問わず、用途に応じて多様なデータを分析対象にできる仕組み データとその分析結果を、組織共通の資産として共有できる仕組み 分析の専門家でなくても自然言語で問いを立てられ、誰が使っても一定品質の調査結果を得られる仕組み 指示されたデータの加工や集計を行うだけでなく、自ら問題を分析し、仮説を立ててデータで検証を進められる仕組み 分析結果を、次のアクションにつながる形で他システムへ連携できる仕組み Agentic AI アシスタント Amazon Quick によるデータと人のサイロの解決 これらの仕組みは、Agentic AI アシスタント Amazon Quick で実現可能です。Amazon Quick は、タスクの自動化・データ分析・Web アプリ構築・リサーチといった作業を、専門知識なしで一元的に行うことができるサービスです。 本来、AI エージェントを自前で動かすには、設備・電源・ネットワーク・サーバーなどのインフラ管理に加えて、モデルの選定やエージェントの実装、ガードレールの整備まで多くの手間が伴います。Amazon Quick はこれらをフルマネージドで引き受け、利用者はコードを書くことなくエージェントを設計・活用でき、ガードレール機能も組み込みで利用できます。さらに、入力したデータは自社の管理下に保たれ、基盤モデルの学習に使われることもありません。AWS のインフラストラクチャー自体もセキュアに運用されており、利用者は安心して分析に集中できます。 以下に、Amazon Quick の全体像を示します。 図 ：Amazon Quick 全体像 Amazon Quick では、 Quick Spaces （以下 Spaces ）という仮想的なデータコンテナを作成できます。Spaces には、さまざまな場所（AWS 上のストレージサービスやデータベースサービスのほか、外部 SaaS、オンプレミスのデータベースやファイルサーバーなど）にある構造化データおよび非構造化データを仮想的にまとめます。これによって、データサイロを排除し情報探索を効率化することができます。 Amazon Quick の Quick Chat （以下 Chat ）は、データの探索、分析、アクションの実行を支援する対話型のアシスタントです。前述の Spaces と Chat は簡単な手順で接続でき、そうすると Chat は Spaces にあるリソースを使って回答、タスク遂行を行います。このとき Chat は、指示されたデータの加工や集計をこなすだけではありません。与えられたゴールに向けて、自ら分析の計画を立て、仮説の立案とデータによる検証を繰り返しながら、結論へと近づいていきます。Spaces にタスク遂行に必要なデータが集約されていれば、Chat の裏にある Agentic AI はタスクに関連するデータだけで結果を生成するため、ユーザーは関連性の高い回答を得られます。また、Chat にはエージェントの振る舞いを自然言語の指示としてあらかじめ定義できる機能（ カスタムチャットエージェント ）があります。ここに優秀なアナリストの思考手順を思考ルールとして仕込んでおくことで、誰が使っても一定以上の品質の調査やアクションを実行できるようになります。分析結果はチケット管理システムなどの外部ツールへ連携できます。このように、データを扱う技術・製品知識・現場の実情という複数領域の知識が一人に揃わなくても、Agentic AI がその隙間を埋めることで、人材のサイロを越えた分析が可能になります。 アニメーション ：Quick Chat を活用したデータの深堀り分析 製品改善サイクルのサンプルシナリオ 製造業の業務での活用イメージを明確にするために、一つの「モノ」の開発サイクルを例に、具体的なシナリオを辿ってみましょう。 あなたは、空調機器（HVAC）メーカーの品質マネージャーである、と想像してください。あなたは、製品の品質を向上することに責務を負っていますが、製品の内部仕様に熟知しているわけではありません。そのような状況で、「ある時点から『冷房が効かない』という問い合わせが急増している」という情報を得ました。あなたはこれに対処する必要があります。 あなたはまず、その事実を確認するために、Quick Chat を使って「問い合わせの傾向を分析してください」と依頼します。すると、Agentic AI は、裏で接続されたお問い合わせデータと顧客管理台帳を参照し、問い合わせ傾向の事実を確認します。 続いて、「なぜそれが起こったのでしょうか。仮説を立ててください」と依頼して、Agentic AI に根本原因の仮説を立てさせます。さらに、稼働データ、ソフトウェアのバージョン、製品仕様書…など、接続されたデータを行ったり来たりしながら仮説を検証させます。最終的に、あなたが Agentic AI の力を借りながら、複数の根拠を元にして問題の原因にたどり着くことができます。 特定した根本原因を解決する方法はいくつか考えられるはずです。それらを遂行するためには、これまでの分析の経緯と必要な対策を他部門に連携する必要があります。この連携のためのチケット情報を Agentic AI が生成し、他部門が利用するシステムへの連携を支援します。チーム間の情報連携は一般的に手間がかかりますが、カスタムチャットエージェントに情報連携のルールをあらかじめ定義しておけば、そのルールに沿って情報が受け渡されるため、開発チームはすぐに内容を確認し、改善に着手することが可能です。 このように、あなたは Amazon Quick 上の Agentic AI を活用して、モノに関わって生まれるさまざまなデータを製品価値の向上に活用し、製品の開発サイクル全体をシームレスに形成することができました。 ワークショップで体験する 本ブログでご紹介したとおり、Amazon Quick を活用して、製品・サービスの改善サイクルを作ることが可能です。これを擬似的に体験できるワークショップを用意しています。 Accelerating Smart Product SDLC with AI Agent Workshop このワークショップは、ソフトウェア開発における、計画、開発、テスト、リリース、運用、の各フェーズを体験できる合計 5 つの Lab で構成されています。本ブログで紹介した運用フェーズにおけるデータ活用は、Lab 5 で体験できます。Lab 1 から Lab 4 では、計画からリリースまでのいわゆる製品開発の工程を体験できます。こちらの内容の詳細については、 Accelerating Smart Product SDLC with AI Agent Workshop のご紹介 をぜひご覧ください。Lab 5 だけ体験することも、5 つの Lab のうちいくつかをピックアップして体験することも可能です。 まとめ モノやサービスはリリースして終わりではなく、運用の中で生まれるデータこそが次の開発の起点になります。しかし多くの組織では、データと人材の 2 つのサイロがその活用を阻んでいます。Amazon Quick を使えば、分散するデータを Spaces でひとつにまとめ、Chat によって誰もが自然言語で横断的な分析を行い、その結果を開発チームへのアクションにシームレスにつなげられます。まずはワークショップで、運用データが開発サイクルへとつながる体験をお試しください。 ご質問や、自社での適用に関するご相談は、担当のソリューションアーキテクトまたは AWS へのお問い合わせ までお寄せください。 関連ブログ Accelerating Smart Product SDLC with AI Agent Workshop のご紹介

本ブログは 2026 年 8 月 6 日に公開された AWS Blog “ Automate certificates with ACME support in AWS Certificate Manager ” を翻訳したものです。 大規模な TLS 証明書の管理は、運用上の最大の懸念事項の 1 つであるとお客様からお聞きしています。 Certification Authority Browser Forum (CA/Browser Forum) は、パブリック証明書の最大有効期間の段階的な短縮を義務付けました。2027 年 3 月までに、最大有効期間は 100 日に短縮されます。2029 年 3 月までには 47 日となります。証明書を 1,000 件管理している組織にとって、最終段階への移行は、毎日およそ 30 件の更新イベントが発生することを意味します。このペースでの証明書の更新と、更新された証明書のローテーションは、手作業やチケットベースのワークフローで大規模に維持できるものではありません。 AWS は先日、 AWS Certificate Manager (ACM) における Automated Certificate Management Environment (ACME) プロトコルのサポートを発表しました。今回のリリースにより、certbot、cert-manager、acme.sh、win-acme などの人気のあるオープンソースツールをはじめ、チームが既に使い慣れている ACME クライアントを使用して、インフラストラクチャのパブリック証明書の発行と更新を自動化できます。サードパーティの認証機関 (CA) を利用しているお客様は、最小限の設定変更で、既存の ACME 互換クライアントの接続先を現在の CA から ACM に切り替えることができます。これは、 Amazon Web Services (AWS) 上、オンプレミス、ハイブリッド環境のいずれで実行している場合でも同様です。ACME を通じて作成された証明書は ACM に登録されるため、証明書インベントリ全体を統合的に把握できます。 この記事では、この機能の仕組み、開始方法、そして証明書の発行を大規模に管理するためのコントロールとベストプラクティスについて説明します。 背景 ACME は、ドメイン所有権の検証と証明書の発行のプロセスを自動化するオープンソースプロトコルであり、証明書自動化の標準的な仕組みとなっています。ACM は、 Elastic Load Balancing (ELB) 、 Amazon CloudFront 、 Amazon API Gateway などの AWS 統合サービスに対して、マネージド型の証明書発行と更新を長らく提供してきました。しかし多くのお客様は、データセンター内で管理するサーバー、Kubernetes クラスター、モノのインターネット (IoT) フリート、ハイブリッド環境など、独自のインフラストラクチャの証明書も自動化する必要があります。これまで、そうしたお客様は外部プロバイダーに頼らざるを得ませんでした。今回のリリースにより、AWS が管理する証明書エンドポイントと標準の ACME プロトコルを使用して、ACM の自動化モデルをそうしたインフラストラクチャにも適用できるようになります。 仕組み この機能では、一元的にプロビジョニングおよび管理される新しいリソースタイプである ACME エンドポイントが導入されます。各エンドポイントは、一意の ACME ディレクトリ URL と AWS Identity and Access Management (IAM) ベースのアクセスコントロールを持つ AWS リソースです。ACM の API または AWS マネジメントコンソールを通じてエンドポイントを作成および管理し、既存の ACME クライアントの接続先をエンドポイント URL に設定します。エンドポイントを通じて発行された証明書は自動的に ACM に登録され、 RequestCertificate および ImportCertificate API コールで作成された証明書と並んで証明書インベントリに表示されます。 このアーキテクチャは 2 つのプレーンに分かれています。コントロールプレーンでは、PKI 管理者が ACM の API を使用して ACME エンドポイントを作成し、そのエンドポイントが証明書を発行できるドメインを事前承認し、外部アカウントバインディング (EAB) 認証情報を生成します。データプレーンでは、ACME クライアントが EAB 認証情報を使用してエンドポイントに登録し、管理者が既に検証済みのドメインに対して証明書をリクエストします。このアーキテクチャによって、お客様は証明書の発行をスケールできるようになります。各クライアントがリクエストのたびにドメイン所有権を証明するのではなく、適切な ACM アクセス許可を持つプリンシパル (通常は PKI 管理者) がエンドポイントレベルで一度だけドメインを検証するため、アプリケーション所有者は証明書を取得するために DNS の認証情報を必要としません。 データプレーンではさらに、EAB がエンドポイントへのクライアントアクセスを制御します。各 EAB は、ACME クライアントが実行できる証明書操作を制御する IAM ロールにバインドされており、ACM で生成した認証情報は認可された ACME クライアントに配布されます。あるエンドポイントに対して認可された ACME クライアントは、別のエンドポイントを使用できません。これにより、環境間にセキュリティ境界が作られます。例えば、開発用エンドポイントに対して認可されたクライアントは、本番用エンドポイントから証明書を取得できません。 図 1 は、ACM を通じた ACME リクエストのフローを示しています。ACME クライアントは、EAB 認証情報を使用して ACME エンドポイントに対して認証を行います。エンドポイントは、証明書のオーダーを発行のために Amazon Trust Services にルーティングします。発行された証明書は ACM インベントリに登録され、 Amazon EventBridge と AWS CloudTrail によって、有効期限のアラートと監査ログが提供されます。 図 1: ACME のアーキテクチャとワークフロー 開始方法 ACM の新しい ACME 機能は簡単に始められます。以下の手順に従って、ACME で発行する最初の証明書を作成してください。 前提条件 ACM リソースを作成および管理するアクセス許可を持つ AWS アカウント インフラストラクチャにインストール済みの ACME クライアント (Certbot、cert-manager、acme.sh など) デバイスにインストール済みの AWS コマンドラインインターフェイス (AWS CLI) (コンソールでの同等の手順については、こちらのブログ記事「 AWS Certificate Manager の ACME サポートを使用してパブリック TLS 証明書の発行を自動化 」を参照してください) 証明書を発行するドメインの Amazon Route 53 ホストゾーン、または DNS プロバイダーで CNAME レコードを作成できる環境 ステップ 1: ACME エンドポイントを作成する ACME クライアントを ACM で使用する前に、ACME エンドポイントを作成する必要があります。このエンドポイントは、ACME クライアントが証明書のリクエストに使用する URL を提供します。 AWS CLI から以下のコマンドを実行して、ACME エンドポイントを作成します。 aws acm create-acme-endpoint \ --authorization-behavior PRE_APPROVED \ --certificate-authority '{"PublicCertificateAuthority":{"AllowedKeyAlgorithms":["EC_prime256v1"]}}' レスポンスからエンドポイントの Amazon リソースネーム (ARN) をメモします。 {"AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555"} 以下のコマンドを実行してエンドポイント URL を取得します。ARN の部分は作成したエンドポイントの ARN に置き換えてください。 aws acm describe-acme-endpoint \ --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 出力される ACME の EndpointUrl を保存します。 { "AcmeEndpoint": { "AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555", "EndpointUrl": "https://acm-acme-enroll.<region>.api.aws/6666666-7777-8888-9999-000000000000/directory", "Status": "ACTIVE", "AuthorizationBehavior": "PRE_APPROVED", "Contact": "REQUIRED", "CertificateAuthority": { "PublicCertificateAuthority": { "AllowedKeyAlgorithms": [ "EC_prime256v1" ] } }, "CreatedAt": "2026-07-14T18:23:58.876000-04:00", "UpdatedAt": "2026-07-14T18:23:58.876000-04:00" } } ステップ 2: ドメインを事前承認する ACME クライアントが証明書をリクエストできるようにする前に、管理者がエンドポイントレベルで一度だけ DNS を使用してドメインを検証します。 DomainScope を使用して、許可する証明書パターンを正確に制御します。 ExactDomain のみを有効にすると、クライアントはその特定の名前に限定されます。 Subdomains を有効にすると、 api.example.com のような名前が許可されます。 Wildcards を有効にすると、 *.example.com が許可されます。 スコープを無効のままにしておくと、それ以外の点では有効な ACME リクエストがそのパターンを要求したとしても、完全にブロックされます。本番用エンドポイントでは、よりセキュリティを強化した構成とするために、 ExactDomain と Subdomains のみを有効にし、 Wildcards は無効のままにしておくことを検討してください。 aws acm create-acme-domain-validation \ --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 \ --domain-name example.com \ --prevalidation-options '{"DnsPrevalidation":{"DomainScope":{"ExactDomain":"ENABLED","Subdomains":"ENABLED","Wildcards":"DISABLED"},"HostedZoneId":"Z1234567890ABC"}}' ドメインが Route 53 でホストされている場合、 HostedZoneId を指定すると、ACM が必要な CNAME レコードを自動的に作成します。ドメインが他の場所でホストされている場合は、この指定を省略し、提供される CNAME レコードを DNS プロバイダーで手動で作成してください。レコードが作成されると、通常は数秒以内に検証が完了します。 以下のレスポンスが返されます。 { "AcmeDomainValidationArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/1111111-2222-3333-4444-555555555555/acme-domain-validation/6666666-8888-9999-0000-11111111111" } ステップ 3: EAB 認証情報を生成する EAB 認証情報は、ACME クライアントをエンドポイントに対して認証するために使用されます。セキュリティ境界を維持するため、クライアントまたは環境ごとに一意の認証情報を生成してください。 以下のコマンドを実行して EAB 認証情報を生成します。有効期限は組織のリスクプロファイルに合わせて調整してください。 aws acm create-acme-external-account-binding \ --acme-endpoint-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000 \ --role-arn arn:aws:iam::111122223333:role/AcmeIssuanceRole \ --expiration '{"Value": 7, "Type": "DAYS"}' コマンドが正常に実行された際のレスポンスをメモします。 { "ExternalAccountBinding": { "AcmeExternalAccountBindingArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/1234567-1234-1234-1234-123456789012", "AcmeEndpointArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000", "RoleArn": "arn:aws:iam::123456789012:role/service-role/AcmAcmeIssuanceRole-XXXXXXXX", "ExpiresAt": "2026-07-21T18:47:50.641000-04:00" } } 以下のコマンドを実行して認証情報を取得します。これらの値は、次のステップで ACME クライアントの設定に必要になります。 aws acm get-acme-external-account-binding-credentials \ --acme-external-account-binding-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/22222222-2222-2222-2222-222222222222 次のステップのために KeyId と MacKey を保存します。 { "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "MacKey": "xxxxxxxx-xxxxxxxxxx-xxxxxxxxxxxxxxx" } ステップ 4: ACME クライアントを設定する エンドポイント URL と EAB 認証情報が準備できたら、使用する ACME クライアントを設定できます。以下は、人気のある 2 つのクライアントの設定例です。なお、サーバー情報には、ステップ 1 の手順 4 で EndpointUrl として取得した値を使用します。 acme.sh: acme.sh --issue --server https://acm-acme-enroll.us-east-1.api.aws/123457-1234-1234-123456789012/directory \ --eab-kid <KeyId> --eab-hmac-key <MacKey> \ --email <EMAIL> \ -d <DOMAIN> \ --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please Certbot: certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/1234567-1234-1234-123456789012/directory \ --eab-kid <KeyId> \ --eab-hmac-key <MacKey> \ -d <DOMAIN> 最初の登録が完了すると、以降の更新は ACME クライアントが処理します。 エンタープライズ向けのコントロール ACME に対応した他のサービスでも証明書は取得できますが、証明書環境をスケールする必要があるお客様に対して、同等のコントロールとガバナンスは提供されません。組織全体のリスクを軽減するために、以下のコントロールが利用できます。 ドメイン検証 多数のドメインを管理しているお客様から、ドメイン空間全体にわたって不正な証明書の発行を防ぐ方法が必要だという声をいただいています。ドメイン検証によって、これを制御できるようになります。検証する各ドメインに対して、そのドメインで発行を許可する証明書パターンを、 ExactDomain 、 Subdomains 、 Wildcards の中から有効にします。例えば、 internal.example.com を検証して Wildcards のみを有効にした場合、ACME クライアントは *.internal.example.com をリクエストできますが、 internal.example.com 自体や api.internal.example.com のリクエストは拒否されます。この制御は、リクエストが ACM の認証機関に到達する前にエンドポイントレベルで適用されます。また、1 つのエンドポイントの下で複数のドメインを、それぞれ独自のスコープで検証できます。 証明書の一元的な可視化 ACME エンドポイントを通じて発行された証明書は ACM に登録されます。 aws acm list-certificates コマンドを使用して、発行されたすべての証明書を確認できます。 IAM による認可、CloudTrail による監査ログとオブザーバビリティ エンドポイントの管理操作は IAM を通じて認可され、CloudTrail に記録されます。IAM ポリシーを使用して、どのプリンシパルがエンドポイントの作成、EAB 認証情報の生成、ドメイン制約の管理を行えるかを制御できます。 ベストプラクティス ACME 証明書を初めて導入するお客様は、組織に合わせて以下のベストプラクティスを検討してください。 組織や環境の境界に合わせてエンドポイントを分割する エンドポイントは、大規模な組織にとって有用な分離の手段として機能します。大企業は、全社で 1 つのエンドポイントを共有するのではなく、組織の境界 (事業部門、子会社、環境) ごとに 1 つのエンドポイントを作成できます。各エンドポイントは独自の事前承認済みドメインと独自の EAB セットを持つため、ある事業部門で認証情報が侵害されても、それを使って別の事業部門の証明書を取得することはできません。 ただし、この分割方針は運用上のオーバーヘッドとのバランスも考慮して判断してください。妥当な出発点は、事業部門内で環境 (開発、ステージング、本番) ごとに 1 つのエンドポイントを作成し、コンプライアンスや組織上の要件がある場合にのみ、事業部門ごとのエンドポイントへ拡張することです。 EAB 認証情報を安全に管理する エンドポイントの有効な KeyId と MacKey を持っている人は誰でも、そのエンドポイントで事前承認済みの任意のドメインの証明書を取得できます。そのため、これらの認証情報はアクセスキーと同様に取り扱う必要があります。 可能な限り MacKey をハードコーディングせず、 AWS Secrets Manager などのシークレットストアを使用します。エンドポイントの使用を認可した ACME クライアントにのみ配布してください。 EAB の有効期限を許容できるレベルに設定します。EAB は長期間有効な認証情報をサポートしていますが、すべてのシナリオで有効期間が極端に長い EAB が必要なわけではありません。 各 EAB のロールを作成する際は、最小権限の考え方に従います。すべてのバインディングでロールを共有するのではなく、EAB ごとにロールを作成することで、AWS 環境におけるリスクの軽減に役立ちます。 CloudTrail で CreateAcmeExternalAccountBinding コールと GetAcmeExternalAccountBindingCredentials コールを個別に監査します。実際のキーマテリアルの取得は、バインディングの作成とは別の API コールであるため、取得イベントに対するアラートは、バインディング作成のみの場合よりも、実際の認証情報の配布を示す強いシグナルになります。 実行時に EAB をクライアントに関連付ける方法を自動化する 複数の ACME クライアントで 1 つのバインディングを共有するのではなく、クライアントまたは環境ごとに一意の EAB 認証情報を生成してください。複数のエンドポイントへとスケールする段階になったら、運用上の労力を軽減するために、以下のパターンから必要なものを取り入れてください。 各 EAB とそれにバインドされた IAM ロールに、所属するクライアント (チーム、アプリケーション、環境) にちなんだ名前を付けます。これにより、スプレッドシートと照合しなくても、 DescribeAcmeExternalAccountBinding の出力だけでバインディングの用途が明確になります。 各クライアントの KeyId と MacKey を、そのクライアントに限定されたシークレットパス (例えば、チームと環境ごとの Secrets Manager のパス) に保存し、クライアントのプロビジョニングパイプラインが自身の認証情報を取得できるようにします。 Kubernetes では、チーム間で 1 つの共有 issuer を使用するのではなく、EAB ごとに 1 つの ClusterIssuer または名前空間スコープの Issuer を使用します。これにより、クライアントと EAB の関連付けがクラスター設定で明示的になり、他のチームに影響を与えずに特定のチームのアクセスを取り消すことができます。 一時的なインフラストラクチャ (ビルドエージェント、オートスケールされるフリート) の場合、一度きりの手動での受け渡しではなく、Infrastructure as Code または継続的インテグレーションおよびデプロイ (CI/CD) パイプラインの一部として EAB 認証情報をプロビジョニングします。これにより、認証情報のライフサイクルがインフラストラクチャのライフサイクルに追従します。 ACME のデプロイをモニタリングする ACME の強みは自動化にあり、組織は ACME の使用状況に異常がないかモニタリングする必要があります。 成功だけでなく、発行の失敗に対してもアラームを設定します。証明書の有効期間が 47 日になると、更新が気付かないうちに失敗した場合に対応できる時間は、有効期間の長い証明書で得られていた数か月の猶予に比べて、はるかに短くなります。 更新の自動化に依存する前にテストします。CA/Browser Forum の短縮された有効期間により、更新失敗が組織の業務を中断させる事態になる前に、非本番のエンドポイントに対して手動更新を強制実行し、クライアント、モニタリング、オンコールのランブックが期待どおりに動作することを確認してください。 提供リージョンと料金 AWS Certificate Manager の ACME サポートは、本日 (2026 年 8 月 6 日) からすべての商用 AWS リージョンで利用可能です。また、AWS GovCloud (US)、中国リージョン、 AWS European Sovereign Cloud の各 パーティション でも後日利用可能になる予定です。ACME の料金の詳細については、「 ACM の料金ページ 」を参照してください。 まとめ 証明書の有効期間の段階的な短縮は、自動化なしに簡単に解決できるものではありません。ACM の ACME サポートは、標準プロトコルと標準ツールを通じてその自動化を提供しながら、セキュリティチームが ACM で頼りにしている可視性とガバナンスのコントロールを維持します。 開始するには、「 AWS Certificate Manager のドキュメント 」を参照するか、「 開始方法ガイド 」に沿って進めてください。 Anthony Harvey Anthony は、AWS のワールドワイド公共部門グループのシニアセキュリティスペシャリストソリューションアーキテクトです。AWS に入社する前は、地方自治体で 5 年間、最高情報セキュリティ責任者を務めていました。公共部門での経験から、少ないリソースでより多くを実現する方法を見出すことに情熱を持ち、その考え方を活かしてお客様のセキュリティの取り組みを支援しています。 Chandan Kundapur Chandan は、AWS Certificate Manager (ACM) チームのプリンシパルプロダクトマネージャーです。15 年以上のサイバーセキュリティの経験を持ち、PKI 製品戦略の推進に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 18 日に公開された AWS Blog “ Security Hub Extended adds Supply Chain Security as its tenth category ” を翻訳したものです。 今年 2 月以降、AWS は AWS Security Hub Extended を、9 カテゴリにわたる厳選された 14 パートナーから、10 カテゴリ 23 パートナーへと拡大してきました。今月の Black Hat では、そのうち 14 パートナーが Amazon Web Services (AWS) ブースでライブデモを実施しました。4 パートナーがシアタートークを行い、10 パートナーが SecurityLive のストリーミング配信で紹介されました。また、AWS のリーダーシップとパートナー企業の経営陣が一堂に会し、今後の計画を話し合うパートナーレセプションも開催しました。これらの企業は、AWS とともに、そして次第にパートナー同士でも、エンジニアリングと市場開拓 (GTM) に本格的に投資しています。このモデルが、パートナーが日々接しているお客様から支持されているからです。ブースで最も多く寄せられた質問は、サプライチェーンセキュリティはいつ提供されるのか、というものでした。 その提供が始まりました。サプライチェーンセキュリティはカテゴリとして最も多くのお問い合わせをいただいているため、今回はこの話題を中心にお伝えします。 サプライチェーンセキュリティ: お客様が求め続けてきたカテゴリ ソフトウェアサプライチェーンのリスクは、セキュリティチームの懸念事項から、取締役会レベルの議題へと変わりました。SolarWinds の事例は、ビルドシステムが侵害されると何が起きるかを明らかにしました。Log4j の事例は、たった 1 つの推移的依存関係の脆弱性が世界規模で何を引き起こすかを示しました。xz utils のバックドアの事例は、メンテナーを侵害する攻撃が何年もかけて実行される執拗さを浮き彫りにしました。それぞれが同じ問題の異なる側面を示しており、そのペースは加速しています。攻撃者は、企業が知らず知らずのうちに信頼しているオープンソースパッケージこそが、企業への近道であることを知っています。 Black Hat で話をしたすべてのお客様が、この問題をリスク登録簿に載せていました。しかし、その多くはまだ解決策を運用に落とし込めていませんでした。運用化には、個別のデプロイ、新しい契約、新しいコンソール、そしてセキュリティチームが優先順位を上げられない統合作業が必要だったからです。AWS が取り除こうとしているのは、まさにこうした導入の手間です。 Security Hub Extended では、厳選されたパートナーとして Chainguard と Socket によるサプライチェーンセキュリティの提供を開始しました。サプライチェーンセキュリティは、Extended の他のすべてと同じモデルを採用しています。すべてのオファリングが従量制料金で、請求は 1 つにまとまり、長期契約は必須ではありません。これまでどおりの調達プロセスを継続したい企業向けには、Security Hub Extended のプライベートオファーも利用できます。プライベートオファーは、一定期間の利用をコミットする契約で、より大きな割引が適用され、複数パートナーへの支出を単一の AWS 請求に集約でき、契約期間を通じて月払いと年払いのどちらの支払いオプションも選択できます。お客様の購買プロセスに合った方法を選択できます。 Chainguard の役割 Chainguard は、強化・検証されたビルドプロセスでソースから再ビルドしたオープンソースの依存関係を提供します。これにより、お客様の環境に入ってくるものは、マルウェアに強く、来歴 (プロベナンス) に裏付けられたものになります。 同社の調査 によると、ソースからの再ビルドを行っていれば、既知の悪意あるパッケージの 98% が本番環境に到達するのを防げたとされています。ソースを検証できないものは、Chainguard のリポジトリに一切登録されません。これが、パブリックレジストリと開発者の間のフィルターとなります。 Socket の役割 Socket は、オープンソースパッケージの実際の挙動を分析し、インストール時点で悪意ある依存関係をブロックします。数日から数週間後に CVE (Common Vulnerabilities and Exposures) が公開されるのを待つのではありません。パッケージがお客様の環境に入り込もうとしたその瞬間に、Socket はデータベースの情報ではなくパッケージの挙動そのものに基づいて検知します。さらに、到達可能性分析によって、どの脆弱性がお客様のコードから悪用可能かがわかるため、チームがノイズに埋もれることがありません。料金は、チェックする個別のパッケージ数に基づき、ビルドの実行回数には依存しません。 2 社が連携して機能する理由 Chainguard と Socket を組み合わせることで、重要な 2 つの問いに対応できます。 取り込むものを信頼できるか 悪意あるコンポーネントがアプリケーションに組み込まれる前に阻止できるか Chainguard はコードが構築される基盤の保護を支援し、Socket はそこに取り込むパッケージを保護します。両者は、クラウドでもオンプレミスでも、デプロイ先を問わずソフトウェアサプライチェーンの保護に役立ちます。Security Hub Extended を通じて両方を有効化すると、その検出結果は OCSF (Open Cybersecurity Schema Framework) 形式で他のすべての情報とともに Security Hub に流れ込みます。これにより、サプライチェーンのリスクは、エンドポイント、アイデンティティ、クラウドの各シグナルと並べて相関付けられ、優先順位付けされます。そこから、すでに統合済みの下流ツールへとルーティングされるため、開発者が現在使っているパイプラインにそのまま適合します。 23 パートナー、10 カテゴリ。お客様の要望に基づいて構築 Security Hub Extended のすべてのパートナーは、お客様がその機能を必要としていると伝えてくれたこと、そしてその特定のソリューションがすでにお客様のもとで機能していたことを理由に参加しています。脅威の状況が進化するためカテゴリを追加し、それらの問題をうまく解決している企業をお客様が教えてくれるためパートナーを追加しています。目標はシンプルです。すでにお持ちの AWS との取引関係を通じて、同業他社がすでに成果を上げているセキュリティソリューションの導入を簡素化することです。 現在の対象領域は、エンドポイント、アイデンティティ、E メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション、そして新たにサプライチェーンに及びます。23 の厳選されたパートナーは、7AI、Britive、Chainguard、CrowdStrike、Cyera、Island、LayerX、Native Security、Noma、Okta、Oligo、Opti、Palo Alto Networks、Proofpoint、SailPoint、SentinelOne、Socket、Splunk、Sublime、Upwind、Varonis、Zenity、Zscaler です。 AWS が現在注力しているのは、統合を深化させ、有効化にかかる手間を減らすことで、これらのソリューションが個別にではなく連携して機能するようにすることです。そこにこそ、価値が相乗的に高まっていきます。 今後の取り組み ここまで説明してきたことはすべて、販売モデルが機能していることの表れです。つまり、お客様が期待どおりの柔軟性のもとで、AWS との単一の取引関係を通じてベストオブブリードのセキュリティを購入しているということです。しかし、より大きなビジョンは、これらのツールを単に購入しやすくするだけでなく、組み合わせて使うことで実際に効果が高まる統合レイヤーです。 最も注力している統合は、クロスパートナーの相関付けです。エンドポイントソリューション、アイデンティティソリューション、クラウドソリューションからのシグナルを、相互に関連付けられていない 3 つのアラートではなく、1 つのエクスポージャーと 1 つの攻撃パスにまとめます。これと並行して、有効化、デプロイ、統合にかかる手間を大幅に減らし、お客様がサブスクライブしてから価値を実感するまでの時間を数週間ではなく数時間にすることに取り組んでいます。この 2 つの取り組みにより、お客様がすでに信頼している厳選されたソリューションは、個別に使うよりも連携させることで、より大きな成果をもたらします。 これが、AWS がパートナーとともに今まさに加速している取り組みです。re:Invent に向けて、さらに詳しい情報をお届けする予定です。 利用できるオファリングを確認する 本番環境でオープンソースソフトウェアを運用していて、まだサプライチェーンの可視性を確保できていない場合は、そこから始めてください。今すぐ Security Hub コンソールから Chainguard と Socket を有効化できます。複数のセキュリティベンダーとの関係を管理していて、Security Hub Extended による統合がどのようなものかを知りたい場合は、AWS アカウントチームにご相談ください。すべてのパートナーの料金は 料金ページ に公開されており、営業担当への問い合わせは不要です。また、すでにセキュリティ態勢管理と脅威検出に Security Hub を使用している場合、Extended プランは現在お使いのコンソールでそのまま利用できます。 これはまだ始まりにすぎません。 Michael Fuller Michael は AWS に 16 年間在籍し、11 年にわたって AWS セキュリティサービスのプロダクトを率いてきました。業界歴は 29 年で、IBM、Cisco、Amazon においてプロダクトマネジメント、事業開発、ソフトウェア開発のさまざまな役職を歴任してきました。アリゾナ大学でコンピュータ工学の理学士号を、ワシントン大学で MBA を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。