はじめに 金融IT本部 3年目の坂江 克斗です。 re:Invent 2025 で公開されたFrontier Agentの1つとして AWS Security Agent が発表され、3月には AWS Security Agentのペネトレーションテストが一般公開 されました。 AWS Security Agentは、開発フローにセキュリティを統合する DevSecOps において、その「Sec（セキュリティ）」を担うようなサービスです。 本記事では、AWS Security Agent 全体の使用感を、コンソール操作とCICDへの組み込みイメージも含めて紹介します。 ※本記事は2026年6月時点の情報です。 本記事執筆時の2026年6月17日に、 AWS Continuum が発表され、AWS Security Agent のペネトレーションテスト・コードスキャン機能は「Continuum for penetration testing」「Continuum for code scanning」（プレビュー）として Continuum の一部にもなりました。本記事の操作内容は引き続き参考になりますが、AWS Security Agent の名称や提供形態は今後変わっていく可能性があります。 はじめに Frontier Agent とは AWS Security Agent の概要 全体像 コスト クォータ データ保護 テスト・レビュー コンソール画面 実際に試してみる 管理者側の設定手順 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 セキュリティエージェントを使用可能な開発者の登録 ターゲットドメインの登録 リポジトリの統合 セキュリティ要件 コードレビューの有効化 ペネトレーションテストの有効化 開発者用コンソールの確認 開発側の実行手順 設計レビューの実行 コードレビューの実行 脅威モデルの実行 ペネトレーションテストの実行 レポートの確認 デザインレビュー 脅威モデル コードレビュー・ペネトレーションテスト CI/CDへの組み込み CLIコマンドの基本構造 共通： AWS 認証（OIDC） develop マージ時： コードレビュー stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） リリース時 / 定期： フルスコープのペネトレーションテスト 設計ドキュメント更新時： デザインレビュー（脅威モデリング） まとめ おわりに Frontier Agent とは 少し前になりますが、2025年のre:Inventにて「フロンティアエージェント（Frontier Agent）」という新しいカテゴリのAIエージェントが発表されました。 フロンティアエージェント とは、 自律的に動作する開発チームの拡張機能 として位置づけられたAIエージェントです。 個々のタスクをサポートする従来の AI アシスタントとは異なり、フロンティアエージェントはチームの拡張機能として機能し、多様なユースケースにわたって包括的な成果をもたらします。 AWSが定義するフロンティアエージェントには、以下の3つの特徴があります。 自律的 — 人間が常に介入しなくても、独立して動作します スケーラブル — 大規模なスケーリングにより、複数タスクを同時実行します 長時間実行 — 24時間365日、継続的に動作できます 2025年re:Inventで発表されたフロンティアエージェントは以下の3種類です。 エージェント 役割 AWS Security Agent 仮想セキュリティエンジニア。設計・コード・稼働中アプリを横断してセキュリティを担保する AWS DevOps Agent 仮想SREメンバー。インシデントのトリアージや根本原因分析、復旧を自律的に行う Kiro autonomous agent 仮想開発者。仕様書からコード生成・テスト・デプロイまでを担う 中でも今回は、インフラ構築の文脈で特に気になった AWS Security Agent を調査しましたので、その仕組みをまとめます。 去年のre:Invent直後に宮崎さんが AWS re: Invent2025で登場した3つのFrontier Agentsの1つである「AWS DevOps Agent」を触りつつ、概要について整理してみる。 という記事を書いていますので、気になる方はぜひご覧ください。 AWS Security Agent の概要 全体像 AWS Security Agentは機能としては、 SAST（Static Application Security Testing）・ DAST（Dynamic Application Security Testing） ・ペネトレーションテスト を単一のエージェントに統合し、 設計ドキュメントからソースコード・IaC・脅威モデルまでを取り込んでアプリの全体像（コンテキスト）を把握 することで、個々の脆弱性の連鎖まで含めた精度の高い検出と実用的な修復提案を実現するサービスです。 Security Hub/GuardDuty/Inspector などによる従来の事後的なセキュリティ調査では、本番デプロイ後に問題が見つかるため、設計やコードに起因する脆弱性ほど手戻りが大きくなりがちです。こうした背景から、 開発からデプロイまでのフローの早い段階にセキュリティのチェックを寄せる「シフトレフト」や、それを開発プロセスに組み込む「 DevSecOps 」 が重視されるようになってきました。AWS Security Agentは、この考え方を踏まえたサービスとなります。 DevOpsによって開発サイクルが高速かつ高頻度で回るようになった一方、セキュリティが従来どおりの体制のままでは開発スピードに追いつけません。この課題に対して生まれたのが DevSecOps で、開発初期からセキュリティを考慮するシフトレフトの動きを取りつつ、DevOpsの効率性を損なわないようにセキュリティレビュー等を自動化に組み込むことが重視されます。 AWS Security Agentは、大まかに以下の構成となっています。 設計レビュー（デザインレビュー） ・ コードレビュー ・ 脅威モデリング ・ ペネトレーションテスト という4つの作業を行うことができ、各レビュー・テストにおいては、管理側・開発側でコンソールを切り替えることができます。 そのため、開発側は作業中に管理側を意識する必要がなく、不要に管理設定を変更してしまうことを防げます。 コスト コストについては、現在のところ ペネトレーションテストの料金 のみが公開されており、1タスク時間あたり50ドル、かつ初回は2か月間・最大200タスク時間分が無料となっています。 AWS 公式ドキュメントによると、 平均的なアプリケーションテストには約 24 タスク時間かかり、包括的な侵入テストと修復にかかる費用は通常 1,200 ドル の見込みとのことです。 このタスク時間は、ペネトレーションテスト実行中にタスクごとに独立してエージェントが稼働していた場合、それぞれのエージェントの稼働時間を合算したものがそのままタスク時間に換算されます。 クォータ Service Quotas より、各レビューやテスト、連携可能なリソース数などに上限が設定されています。ただし、AWSサポート経由で申請することで上限を変更できます。 データ保護 アップロードするドキュメントなどのデータは、既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能です。 S3・CloudWatch Logs・Secrets Managerを連携する際も、CMKで暗号化したものを渡して使用できます （各リソースのKMSキーポリシーと、サービスロールへの復号権限の設定が必要）。 ただし、 CMKを指定できるのはリソース（エージェントスペースや統合）の作成時のみで、既存リソースへの後付けや鍵の差し替えはできない点に注意が必要です （CMKで運用する場合はリソースの再作成が必要）。 テスト・レビュー 各テスト・レビューの内容を紹介します。詳細な設定方法や実際の動作については次の章をご参照ください。 なお、ポイントについてはドキュメントの内容に加えて私の解釈も含むため、セキュリティエンジニアの方のご意見もぜひ伺いたいです。 項目 概要 ポイント（普通のAI・既存ツールとの差分） 設計レビュー 設計書などのドキュメントを、組織で定義したセキュリティ要件（AWSマネージド／カスタムのガイドライン）に照らして自動レビューし、コードを書く前の段階で指摘。数分～数十分程度で完了。 セキュリティチームが基準を一元的に定義し、開発者側は変更・迂回できない（責務の分離）。組織横断で同じ基準を強制でき、結果が監査ログ・レポートとして残る。従来のSASTと異なり、（アプリ実行時のコンテキストを含まない）パターンマッチングではなく、 アプリの実際の動作・コンテキストを推論して脆弱性を検出 。 コードレビュー 連携したリポジトリやS3のコードを、セキュリティ要件に照らしてレビュー。フルリポジトリ／差分を選択でき、PRへのレビューコメントや自動修正PRまで対応。数分～数十分程度で完了。 設計レビューと同様。Gitにも統合でき、差分レビューなど使いやすい構成。 脅威モデル 攻撃者視点で潜在的な脅威を洗い出して分析。コード以外の信頼境界・権限設計・外部連携なども含め、広範な攻撃経路を整理。数分～数十分程度で完了。 実装上の問題を中心に見るコードレビューと異なり、アーキテクチャ全体のリスクを俯瞰。 ペネトレーションテスト （ 副作用を考慮し、検証環境での実施を推奨 ）稼働中のアプリに対し、ソースコードやドキュメントソースをもとにした多段階の攻撃シナリオで脆弱性を検出。再現手順・PoC・CVSS・修正PRまで提示。数時間～数十時間程度で完了。 従来の DAST と異なり、ブラックボックス的なアプローチではなく、 ソースコードやAPI仕様、設計書をもとにアプリの詳細なコンテキストを構築して検証 。テスト項目の設定によりスコープ調整も可能。 コンソール画面 操作するインターフェースは2層に分かれています。テストのスコープ・セキュリティ要件・リポジトリ統合などを設定する管理者コンソール（AWSマネジメントコンソール内）と、実際にレビューやテストを実行する開発者向けのWebアプリです。 開発者向けのWebアプリは、明示的にアクセス権限を設定でき、運用しやすい構成となっています。 実際に試してみる 本記事では、管理者側・開発者側それぞれの操作方法を紹介しながら、基本的な使用方法について共有します。 その他の詳細な設定について参照が必要な場合は、 AWS Security Agent ： User Guide をご参照ください。 前提として以下のリソースを準備します。 ドキュメント 設計書やAPI仕様（OpenAPIまたはSwagger）等 コードソース GitHub リポジトリ（今回はこちらで検証） S3バケット内のZIPファイル セキュリティ要件 上記のドキュメントやコードソースに対して準拠させたいガイドラインやポリシー ペネトレーションテスト用のエンドポイント情報（ 本番ではなくステージング環境を推奨 ） ターゲット情報（ 外部APIや決済処理、データの削除・更新等の副作用を伴うエンドポイントは除外 ） ドメイン パス VPC内のプライベートなアプリケーションの場合（Security Agent自身がENIを使用してアクセス） VPC ID サブネット ID セキュリティグループ ID アプリケーション接続時に認証情報が必要な場合 静的な認証情報（平文 or Secrets Managerシークレット） 動的な認証情報の生成方法をまとめたプロンプト Security Agent自体の運用管理 CloudWatch ロググループ（コンソールから作成する場合は自動作成されるため任意） IAM サービスロール（コンソールから作成する場合は自動作成されるため任意） KMSキー（デフォルトはAWSマネージドキーで管理されるため任意） 開発者に対応する IAM Identity Center のユーザ（Security Agentを使用可能なユーザを明示的に指定） 管理者側の設定手順 AWSコンソールのAWS Security Agentの画面より、管理者側の設定を行います。 AWS Security Agent アプリケーションの作成・エージェントスペースの作成 各レビュー設定に入る前に、AWSコンソールから全体で必要な設定をしておきます。 Security Agentのコンソール画面に遷移したら、「AWS Security Agentをセットアップ」ボタンを押下します。 AgentSpaceの設定を入力しつつ、AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 タグについては、エージェントスペースタグがエージェントスペースに付与されるタグ、アプリケーションタグがAWS Security Agentアプリケーション自体に付与されるタグとなります。 また、 IAM Identity Centerもここで紐づくため、インスタンスを再作成すると連携が切れてしまう点に注意が必要です。（コンソールやCLI経由での更新不可です） 完了後、AWS Security Agent アプリケーションとエージェントスペースが作成されます。 【AWS Security Agent アプリケーションが既に存在する場合】エージェントスペースだけの作成 既にAWS Security Agentアプリケーションを作成済みの状態で、エージェントスペースのみ作成する場合は以下のように作成します。 Security Agentのコンソール画面に遷移したら、「最初のエージェントスペースを作成」ボタンを押下します。 AWSマネージドキーではなく、CMK（カスタマーマネージドキー）でデータを保護したい場合には、「Customize encryption settings (advanced)」チェックボックスにチェックを入れ、任意のCMKを紐付けてください。 作成画面の入力後、「作成」ボタンを押下します。 セキュリティエージェントを使用可能な開発者の登録 作成したエージェントスペース画面のウェブアプリタブにおいて、「ユーザの追加」を押下します。 IAM Identity Centerで設定したユーザーを選択し、「ユーザーを追加」ボタンを押します。 画面遷移後、ユーザーが追加されていることを確認できます。 ターゲットドメインの登録 サイドバーの「ターゲットドメイン」を押下し、ターゲットドメインのページから「ドメインを追加」ボタンを押下します。 ペネトレーションテストの対象となるドメイン・検証方法を選択し、「ドメインを追加」ボタンを押下します。 今回は検証方法としてDNS TXTレコードを指定しました。その他のHTTPルートやプライベートVPCの検証については「 Managed target domains used for penetration testing」 をご参照ください。 ターゲットドメインの追加完了後、「ワンクリック検証」を押下します。レコードの追加も含めマネージドに対応してくれるので、そのまま進めます。 検証が完了すると、ステータスが検証済みになります。 リポジトリの統合 サイドバーの「統合」から、「統合の追加」ボタンを押下します。今回はGitHubを選択して進めていきます。 設定画面に遷移したら、ステップ1より順に設定します。 ステップ2の「GitHubでAWS Security Agentを開く」を押下すると、GitHubアプリのインストール画面に遷移するのでインストールします。 この際、連携するリポジトリをアカウント内すべてにするか、特定のリポジトリに限定するかを選択できます。 インストールの完了後、ステップ3で認証するボタンを押下します。「認証が成功しました」という表示が出ることを確認します。 最後にステップ4で、登録名・アカウントタイプ・CMKによる暗号化を設定したら、「接続」ボタンを押下して完了です。 セキュリティ要件 コンソールサイドバーのセキュリティ要件より、マネージドまたはカスタムのセキュリティ要件を設定することができます。 セキュリティ要件は、設計レビューやコードレビューの際のガイドラインとなる設定であり、各セキュリティ要件項目と、それをまとめたパックの単位で管理を行います。 マネージドセキュリティ要件パックについては、 AWS managed security requirement packs またはコンソールから各設定値をご参照ください。 デフォルトではASA Base Packのみ有効化されています。 カスタム設定については、「Create security requirements pack」ボタンを押下してパックを作成した後に、パック内でセキュリティ要件を個々に設定します。 セキュリティ要件パックの作成後、セキュリティ要件の追加時には、手動での入力またはドキュメントを読み込ませて自動生成する方法を選ぶことができます。 マニュアル設定 の場合は、以下に示すように、条件を適用するシナリオ、具体的な違反内容、修正方法の提示について入力が必要となります。 ドキュメントをアップロードして自動生成する場合は、ファイルサイズにもよりますが、60KB程度のmdファイルを読み込ませて、数分程度で20個のセキュリティ要件が生成されました。 ただし、注意点として、 https://docs.aws.amazon.com/ja_jp/securityagent/latest/userguide/security-requirements.html にあるとおり、既存の要件を置き換えることになる点に注意が必要です。 Uploading new source documents regenerates all requirements for the pack. Any existing requirements, including ones you added manually, are replaced. コードレビューの有効化 コードレビューを有効にするボタンを押下して進めます。 接続された統合項目の追加ボタンを押下し、先ほど連携したGitHubアカウントを選択します。 今回は使用しませんが、S3バケットもコードの保存先として参照可能です。 アカウント内のリポジトリを選択し、「次へ」ボタンを押下します。 以下の設定を確認し、「接続」を押下します。 コードレビューコメント：PR作成時にレビューコメントを追加してくれる許可 PR修正：レビューやテスト後に脆弱性の箇所を自動でPR作成する許可 完了すると、コードレビューの設定画面に戻り、統合が追加されたことが確認できます。 その他の項目も確認し、「次へ」ボタンを押下します。 オプション設定画面に遷移したら、CloudWatchログとサービスロールを設定します。これらは事前に準備したもの、もしくは入力を更新せずにマネージドに作成されるものも使用可能です。設定ができたら、保存を押下します。 エージェントスペース画面に戻ると、脅威モデルについてもセットで有効化されていることが確認できます。 ペネトレーションテストの有効化 最後にペネトレーションテストの有効化ボタンを押下します。 先ほど設定したターゲットドメインを選択し、「次へ」ボタンを押下します。 ターゲットドメインが検証済みであることを確認し、「次へ」ボタンを押下します。 以下の設定項目について確認し、入力が完了したら保存を押下します。 VPC：VPC内でプライベートなエンドポイントを叩く場合など、Security AgentがVPC内のENIからターゲットにアクセスする際の設定 VPC、サブネット、セキュリティグループ CloudWatchログ：ログの出力先、任意 シークレット：テスト打鍵時にログインなどの認証情報を保存しておくために使用 Lambda関数：動的な認証情報生成用に独自デプロイしたものがあれば指定 Lambdaがない場合でも、テスト実行時のプロンプトでカバー可能かどうかは要検討 S3バケット：ペネトレーションテスト実行時にアプリケーションの構成などを学習するためのリソースとして使用可能 全項目が準備完了のステータスであることを確認して完了です。 開発者用コンソールの確認 エージェントスペース画面において、ウェブアプリケーションの項目から開発者用のコンソール（レビューやテストを実行する場所）を開くことができます。 管理者アクセスの場合は「管理者アクセス」ボタンを押下し、直接エージェントスペースに対応するコンソールに移動します。 エージェントウェブアプリのURLよりアクセスする場合は、紐付けたIAM Identity Centerユーザでログインしたのちに、そのユーザが使用可能なエージェントスペースの一覧が表示され、そこから指定のエージェントスペースに遷移する形となります。 以上で管理者側の設定は完了です。次に、実際にテストを実行します。 開発側の実行手順 開発者用のコンソール画面より、開発者側の操作（レビュー・テスト）を行います。 設計レビューの実行 ホーム画面から「設計レビューを作成する」を押下し、レビュー対象のファイルをアップロードして、「開始する」ボタンを押下します。 デザインレビューが進行中となります。 完了すると、コンソールからそのまま実施結果を確認することができます。 「レポートをダウンロード」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 コードレビューの実行 ホーム画面から「コードレビューを作成する」を押下し、以下の項目を設定して、「作成する」ボタンを押下します。 ソース：コードソースを選択。今回は先ほど設定したGitHubリポジトリを設定 サービスロール：管理者画面で設定したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 自動コード修正：有効にするとレビュー結果に応じてPRを自動作成します 作成したコードレビューを押下します。 「レビューを開始する」ボタンを押下し、コードレビューを開始します。 ただし、プルダウンから差分コードレビューも選択可能です。2回目以降、頻繁に回す場合は差分レビューが推奨されると考えられます。（毎回フルリポジトリレビューを実行するとコストに響いていく想定） コンソールから結果を確認することができます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 脅威モデルの実行 ホーム画面から「脅威モデルを作成する」を押下し、以下の項目を設定して、「脅威モデルを作成する」ボタンを押下します。 リポジトリ：先ほど設定したコードソースを選択 機能仕様書：ドキュメントをアップロード サービスロール：管理者画面で作成したサービスロールを選択 CloudWatchロググループ：未入力で自動生成されます 設定完了後、「実行を開始する」ボタンを押下します。 実行結果についてはコンソールから取得できます。 「レポートを生成」ボタンを押下するとレポートが出力されます。レポートの詳細については、後の章でまとめて紹介いたします。 ペネトレーションテストの実行 ホーム画面から「ペネトレーションテストを作成する」を押下し、以下の項目を設定して、「次へ」ボタンを押下します。 ターゲットや除外対象を調整することで、テストスコープを大まかに調整することができます。 ターゲットURL：検証済みのドメインをもとにURLを入力 リスクタイプを除外する：テストで検証しなくてもよい項目を選択し除外可能 範囲外のURL：テストでアクセスしてほしくないURLを入力（外部APIや決済処理、データの削除・更新などの副作用を伴うエンドポイント等） アクセス可能なURL：テスト中に攻撃対象ではないが、アクセスを許可するURLを入力 カスタムHTTPヘッダ：静的なヘッダのキーと値を設定（動的な設定がしたい場合は、以降の手順で対応） サービスロール CloudWatchロググループ VPCリソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 管理者画面で設定していた場合は、VPC、サブネット、セキュリティグループを設定可能です。 認証リソースの設定画面に遷移しますが、今回は設定項目がないため「次へ」ボタンを押してスキップします。 認証情報についてはシークレットまたは平文での静的情報が入力可能なほか、エージェントスペースのログインプロンプトに動的な認証方法に関する記載をすることで、動的な認証にも対応できます。 実際に、動的にトークンを生成してカスタムヘッダに載せる必要があるアプリで動作を確認できました。 その他の設定画面において、以下を設定し、「ペネトレーションテストモデルを作成する」ボタンを押下します。 リソース：コードソースなどを設定 自動コード修正：有効化するとペネトレーションテストの結果に応じてPRを自動作成 検出結果のパーソナライゼーション（ オンオフでの差分未確認 ） リソースを可能な限りクリーンアップ（ オンオフでの差分未確認 ） 作成後、「実行を開始する」ボタンを押します。 実行結果についてはコンソールから取得できます。 テストの取得結果数が少ないのは、実行中に裏側で呼び出しているBedrockの存在に気づき、コスト懸念のため途中で中止したためです。 レポートの確認 デザインレビュー デザインレビューについては、「レポートをダウンロード」からCSV形式でレポートを取得できます。 デザインレビューは手動でファイルを読み込ませる形式で自動修正等もないため、このCSVを手元のAIエージェントに読み込ませて修正することを想定しています。 脅威モデル 脅威モデルの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Introduction 脅威モデルの対象、実施日、検出された脅威件数、重大度の内訳 System Overview 対象システムの目的、機能、アーキテクチャ、主要コンポーネントの説明 Configuration 脅威モデルに使用したスコープ文書、連携リポジトリ、S3ソース、ドキュメントなどの設定情報 Threats 実際に検出された脅威シナリオの一覧 Detailed Threats 各脅威シナリオに対する攻撃者、攻撃が成立するための前提条件、具体的な攻撃方法、攻撃成功時の影響、脅威の根拠、脅威の判断に紐づく構成箇所 System Overview章では設計書やコードから、アプリの構成に関する洞察がかなり細かく記載されており、セキュリティ上のリスクを多角的に把握する上で非常に有用であると感じます。 コードレビュー・ペネトレーションテスト 同様に、コードレビューやペネトレーションテストの場合は、「レポートを生成」ボタンを押下すると、レポートをPDF形式で取得することができます。 体裁（抜粋） 構成 Report Filters Applied このレポートに含めるリスクレベル、信頼度、ステータスなどの抽出条件 Executive Summary テスト対象、実施日、検出された脆弱性件数、重大度の内訳 Scope ペネトレーションテスト：対象URL、対象外URL、利用した認証情報 コードレビュー：対象リポジトリ、S3バケット Methodology AWS Security Agent がどのような流れ・観点でテストを実施したかの説明 ペネトレーションテストの場合は、表形式でXSS、SQL Injection、SSRF、Path Traversalなど、実際に実施されたテスト項目の一覧を記載 Findings 実際に検出されたセキュリティ指摘の一覧 Detailed Findings 各セキュリティ指摘に対する、概要、再現手順、 CVSS（Common Vulnerability Scoring System）評価 の根拠、推奨修正方針、修正対応PR ペネトレーションテストの結果におけるMethodology章では、例えば私のサービスではバックエンドにDynamoDBやSQLを使用している点から、それらの要素を突くような攻撃を実施した旨が記載されていました。これは、学習リソースとしてGitHubリポジトリを与えたために、IaCで管理しているリソースやアプリケーションロジックを総合して攻撃方法を検討していることが確認できました。 まさに、 AWS Security Agent のオンデマンドペネトレーションテストの一般提供を開始 で紹介されていたような、 アプリケーションコンテキストを追加して精度と検出の深度を向上 させるという面が見られたのではないかと感じます。 また、今回はコードレビューとペネトレーションテストの際にリポジトリへの修正PRを許可していることから、自動でPRを立てていました。 実施理由から変更内容、サマリまでが簡潔にまとめられていることがわかります。コードの質に関しては、今回はそこまで複雑なアプリではないこともあり、特に気になる点はなかったと感じますが、ぜひ皆さんの使用時に確認していただければと思います。 CI/CDへの組み込み AWS Security Agent は、CodePipeline 等の CI/CD や定期的な管理タスクとして実行させることが可能で、 AWS CLI / API 経由でジョブを起動できます。 今回は、GitHub Actions での使用イメージを記載します。以下は、デザインレビュー・コードレビュー・ペネトレーションテストを、大まかに GitHub Actions に組み込んだ場合のイメージです。 タイミング 実行するもの 性質 develop マージ リポジトリ全体のコードレビュー 軽量・低コスト・高頻度 main マージ stg へ反映（テストは伴わないデプロイトリガー） — stg デプロイ完了後 軽量ペンテスト（対象を絞る） 中コスト・中頻度 リリース時 / 定期 フルスコープのペンテスト 高コスト・低頻度 設計ドキュメント更新時 デザインレビュー 随時 CLIコマンドの基本構造 AWS Security Agent の各機能は、以下の流れで実行します。AWS Security Agent 関連リソースはあらかじめコンソールまたは create コマンドで定義しておき、CI/CD からは名前を基に list-* コマンドでIDを取得し start-*-job で起動するのが基本です。 機能 起動コマンド 主な必須引数 コードレビュー aws securityagent start-code-review-job --agent-space-id / --code-review-id ペネトレーションテスト aws securityagent start-pentest-job --agent-space-id / --pentest-id デザインレビュー（脅威モデリング） aws securityagent start-threat-model-job --agent-space-id / --threat-model-id 例えばペネトレーションテストの起動は、コンソールから設定した場合は名前を元に以下のようになります。Agent Space やペンテスト定義の実IDは list-* 系コマンドで name / title を条件に取得し、 start-pentest-job に渡します。 $ AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text \ --region ap-northeast-1) $ PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text \ --region ap-northeast-1) $ aws securityagent start-pentest-job \ --agent-space-id "$AGENT_SPACE_ID" \ --pentest-id "$PENTEST_ID" \ --region ap-northeast-1 start-pentest-job は pentestJobId と status （ IN_PROGRESS / COMPLETED / FAILED など）を返します。短時間で完了するコードレビューやデザインレビューは、この status をポーリングして完了を待つ構成にできます。一方、数時間〜数十時間かかるペネトレーションテストは、GitHub Actions の実行時間制限（後述）の都合から、起動のみ行う非同期キック構成とします。 以下では、各フェーズで実行する workflow の YAML ファイル例を示します。なお、いずれの例も Agent Space 名や各リソース名（ title ）、AWS 認証情報（OIDC ロール等）を GitHub の Secrets / Variables に登録している前提です。リソース ID は workflow 内で list-* から動的に解決するため、ID 自体は Variables に持ちません（コンソール側で再作成された場合の追従が楽になります）。 共通： AWS 認証（OIDC） 各 workflow で共通して使う、OIDC による AWS 認証部分の例です。長期のアクセスキーを GitHub に保存せず、フェデレーションでロールを引き受ける構成にしています。 permissions : id-token : write contents : read steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ap-northeast-1 develop マージ時： コードレビュー develop への push（マージ）をトリガーに、リポジトリ全体のコードレビューを起動します。高頻度で回すため、軽量・低コストなレビューを想定しています。 # .github/workflows/code-review.yml name : security-agent-code-review on : push : branches : [ develop ] permissions : id-token : write contents : read jobs : code-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} CODE_REVIEW_NAME : ${{ vars.CODE_REVIEW_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) CODE_REVIEW_ID=$(aws securityagent list-code-reviews \ --agent-space-id "$AGENT_SPACE_ID" \ --query "codeReviewSummaries[?title=='$CODE_REVIEW_NAME'].codeReviewId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$CODE_REVIEW_ID" ] || [ "$CODE_REVIEW_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID CODE_REVIEW_ID=$CODE_REVIEW_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "code_review_id=$CODE_REVIEW_ID" >> "$GITHUB_OUTPUT" - name : Start code review job id : start run : | JOB_ID=$(aws securityagent start-code-review-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --code-review-id "${{ steps.resolve.outputs.code_review_id }}" \ --query 'codeReviewJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" echo "Started code review job: $JOB_ID" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-code-review-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --code-review-job-ids "$JOB_ID" \ --query 'codeReviewJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) echo "Code review completed" ; exit 0 ;; FAILED|STOPPED) echo "Code review did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out waiting for code review" ; exit 1 stg デプロイ完了後： 軽量ペンテスト（DAST・対象を絞る） main マージ後の stg デプロイ完了を受けて、対象を絞った軽量なペネトレーションテストを実行します。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-light.yml name : security-agent-pentest-light on : workflow_run : workflows : [ "deploy-stg" ] # stg デプロイ workflow 名 types : [ completed ] permissions : id-token : write contents : read jobs : pentest-light : # デプロイが成功したときだけ実行 if : ${{ github.event.workflow_run.conclusion == 'success' }} runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_LIGHT }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start light pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started light pentest job: $JOB_ID" echo "進捗・結果はコンソールまたは EventBridge 通知で確認してください。" リリース時 / 定期： フルスコープのペネトレーションテスト リリースタグの push、または定期実行でフルスコープのペネトレーションテストを起動します。高コスト・低頻度の枠です。 ペネトレーションテストは数時間〜数十時間かかる場合があり、GitHub ホストランナーの 1 ジョブ最大 6 時間という実行時間制限を超える恐れがあります。そのため、ここでは 起動のみを行い、完了は待たない（非同期キック） 構成とします。テストの進捗・結果は、コンソールや EventBridge 通知などジョブの外で確認する想定です。 # .github/workflows/pentest-full.yml name : security-agent-pentest-full on : push : tags : [ "v*" ] # リリースタグ schedule : - cron : "0 18 * * 0" # 毎週日曜 18:00 UTC（=月曜 3:00 JST）に定期実行 permissions : id-token : write contents : read jobs : pentest-full : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} PENTEST_NAME : ${{ vars.PENTEST_NAME_FULL }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) PENTEST_ID=$(aws securityagent list-pentests \ --agent-space-id "$AGENT_SPACE_ID" \ --query "pentestSummaries[?title=='$PENTEST_NAME'].pentestId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$PENTEST_ID" ] || [ "$PENTEST_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID PENTEST_ID=$PENTEST_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "pentest_id=$PENTEST_ID" >> "$GITHUB_OUTPUT" - name : Start full pentest job (fire-and-forget) run : | JOB_ID=$(aws securityagent start-pentest-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --pentest-id "${{ steps.resolve.outputs.pentest_id }}" \ --query 'pentestJobId' --output text) echo "Started full pentest job: $JOB_ID" echo "長時間ジョブのため、結果はコンソールまたは EventBridge 通知で確認してください。" 設計ドキュメント更新時： デザインレビュー（脅威モデリング） 設計ドキュメント（ docs/design/ 配下など）の更新をトリガーに、デザインレビュー（脅威モデリング）を起動します。STRIDE 形式での脅威モデル生成を想定しています。 # .github/workflows/design-review.yml name : security-agent-design-review on : push : paths : - "docs/design/**" # 設計ドキュメントの更新時のみ permissions : id-token : write contents : read jobs : design-review : runs-on : ubuntu-latest env : AWS_REGION : ap-northeast-1 AGENT_SPACE_NAME : ${{ vars.AGENT_SPACE_NAME }} THREAT_MODEL_NAME : ${{ vars.THREAT_MODEL_NAME }} steps : - name : Configure AWS credentials (OIDC) uses : aws-actions/configure-aws-credentials@v4 with : role-to-assume : ${{ secrets.AWS_SECURITY_AGENT_ROLE_ARN }} aws-region : ${{ env.AWS_REGION }} - name : Resolve resource IDs id : resolve run : | AGENT_SPACE_ID=$(aws securityagent list-agent-spaces \ --query "agentSpaceSummaries[?name=='$AGENT_SPACE_NAME'].agentSpaceId | [0]" \ --output text) THREAT_MODEL_ID=$(aws securityagent list-threat-models \ --agent-space-id "$AGENT_SPACE_ID" \ --query "threatModelSummaries[?title=='$THREAT_MODEL_NAME'].threatModelId | [0]" \ --output text) if [ -z "$AGENT_SPACE_ID" ] || [ "$AGENT_SPACE_ID" = "None" ] \ || [ -z "$THREAT_MODEL_ID" ] || [ "$THREAT_MODEL_ID" = "None" ] ; then echo "Failed to resolve IDs: AGENT_SPACE_ID=$AGENT_SPACE_ID THREAT_MODEL_ID=$THREAT_MODEL_ID" exit 1 fi echo "agent_space_id=$AGENT_SPACE_ID" >> "$GITHUB_OUTPUT" echo "threat_model_id=$THREAT_MODEL_ID" >> "$GITHUB_OUTPUT" - name : Start threat model job id : start run : | JOB_ID=$(aws securityagent start-threat-model-job \ --agent-space-id "${{ steps.resolve.outputs.agent_space_id }}" \ --threat-model-id "${{ steps.resolve.outputs.threat_model_id }}" \ --query 'threatModelJobId' --output text) echo "job_id=$JOB_ID" >> "$GITHUB_OUTPUT" - name : Wait for completion run : | JOB_ID="${{ steps.start.outputs.job_id }} " AGENT_SPACE_ID=" ${{ steps.resolve.outputs.agent_space_id }} " for i in $(seq 1 60); do STATUS=$(aws securityagent batch-get-threat-model-jobs \ --agent-space-id "$AGENT_SPACE_ID" \ --threat-model-job-ids "$JOB_ID" \ --query 'threatModelJobs[0].status' --output text) echo "status=$STATUS" case "$STATUS" in COMPLETED) exit 0 ;; FAILED|STOPPED) echo "Threat model did not succeed: $STATUS" ; exit 1 ;; esac sleep 30 done echo "Timed out" ; exit 1 まとめ 最近よく話題に挙がるDevOpsにセキュリティを加えた概念、 DevSecOps に沿ったモダンなサービスだと感じました。 今回のAWS Security Agentでは、 コンソール操作だけでなくAPI経由でCICDに取り込める点 、 レビューから修正までをAIで一括管理できる点 、さらに コードレビューやペネトレーションテストにおいて差分レビューやターゲットURL・除外項目の設定などでスコープを調整できる点 から、このDevSecOpsのコンセプトを強く反映しています。 また、単なる効率化にとどまらず、ドキュメントとして人向けに残す成果物まで整備されている点も充実しています。 一方で、懸念点としては以下の3点が挙げられます。 コスト ：プレビュー中の機能もありますが、実際にCI/CDへ組み込んだ際の料金イメージが読みにくい点。エージェントを個別に構築する場合と比較した、運用コスト・性能とのバランス。 秘匿ドキュメントの管理 ：社内の機密情報や個人情報を含むドキュメントをクラウド上にアップロードすることになるため、要件によっては慎重な判断が必要。 データは既定でAWSマネージドキーにより暗号化され、任意でカスタマーマネージドキー（CMK）を指定して自社で鍵を管理することも可能であり、保護の仕組みは用意されている。そのため、最終的には自社のセキュリティ要件に照らして判断することになる想定。 レビューやテストの性能 ：現在の検出性能や今後の伸びしろについて、セキュリティエンジニアの視点でのご意見をぜひお聞きしたいと感じています。 おわりに 本記事では、AWS Security Agentの概要を紹介しました。今後も、機能の追加や検出性能そのもののアップグレードが期待されます。 ただし、偽陽性が多いのではないかという声も聞いたため、検出性能については別途、評価・比較してみたいと考えています。 ご精読いただき、ありがとうございました。 余談になりますが、先輩と話した際に挙がった、「ペネトレーションテストを主軸に開発を進める中で、アプリケーションのコンテキストを理解させるために、結局は設計レビュー・コードレビュー・脅威モデリングが必要になり、機能として統合されていったのではないか」という見方には、かなり納得できました。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @sakae.katsuto レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

G-gen の杉村です。当記事では、Google Cloud の AI エージェント向けネットワークセキュリティ機能である Agent Gateway について解説し、仕様の把握や設計時の考慮事項の検討に役立つ情報を提供します。 概要 Agent Gateway とは アーキテクチャ メリット 通信制御 概要 通信制御の対象 Identity-Aware Proxy（IAP） Model Armor セマンティックガバナンスポリシー Service Extensions デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） エージェントへのルール適用（Agent Runtime） Agent Gateway の使用を強制 プロジェクト構成 ロギング ドライラン ゲートウェイ ゲートウェイとは 設定値 デプロイメントモード Identity-Aware Proxy（IAP） IAM ポリシーとは 設定値 設定イメージ セマンティックガバナンスポリシー 概要 ネットワーク要件 技術的な詳細 プロトコル 通信の暗号化と認証 概要 Agent Gateway とは Agent Gateway は、AI エージェントが行う通信についてセキュアな接続とガバナンスを提供する、Google Cloud のセキュリティ機能です。 なお Agent Gateway は、Google Cloud が提供する AI 開発・運用プラットフォームである Gemini Enterprise Agent Platform （以下、Agent Platform）のコンポーネントの1つです。 Agent Gateway は「ユーザーとエージェント」「エージェントとツール」「エージェントと他のエージェント」の間の通信など、エージェントが行うさまざまな通信の出入り口として機能します。 組織のセキュリティ管理者は Agent Gateway を使うことで、エージェントに対するセキュリティとガバナンスポリシーを強制することができます。具体的には、明示的に許可されていない外部の API や MCP サーバー、他のエージェント等に対するエージェントからのリクエストを一元的に防いだり、Model Armor によるトラフィックの検査を強制することができます。 参考 : Agent Gateway overview なお、Agent Gateway を含む、AI エージェント開発プラットフォームである Gemini Enterprise Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp アーキテクチャ Agent Gateway は、以下のようなイメージで、エージェントの通信を制御します。 Agent Gateway のアーキテクチャ Agent Gateway を使用することで、Google Cloud にホストされた AI エージェントの通信を一元的に統制できます。例として、リスクのある外部 API や MCP サーバーなどへのアクセスを拒否したり、不必要な AI エージェント間の通信を制限したりすることができます。 メリット Agent Gateway の導入により、AI 開発者とインフラ管理者（セキュリティ管理者）の双方に利点があります。 AI 開発者にとっての利点は、複雑なネットワーク管理やセキュリティのオーバーヘッドを意識することなく、エージェントの開発に集中できることです。mTLS ハンドシェイクの自動処理や、MCP、Agent-to-Agent（A2A）、REST、gRPC などによる通信の制御をプラットフォーム側でシームレスに行うことができます。また Agent Gateway は Cloud Monitoring や Cloud Logging と統合されているため、Agent Gateway を介することでオブザーバビリティが向上し、エージェントの動作の把握に役立ちます。 インフラ管理者（セキュリティ管理者）にとっては、エージェントの通信や外部システムへのアクセスに対して、一元的なガバナンスを効かせられるメリットがあります。また Identity and Access Management（以下、IAM）を用いた最小権限の原則の適用や、Model Armor を用いたプロンプトインジェクション保護などの AI セキュリティガードレールを実装できます。またエージェントと Agent Gateway の間では、Agent Identity や mTLS といった技術により自動的にセキュアな通信が確立されます。 通信制御 概要 Agent Gateway は、ゲートウェイを通過するトラフィックに対して、以下の仕組みを適用することでエージェントの通信を制御します。 名称 説明 適用可能なゲートウェイ Identity-Aware Proxy（IAP） エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を制御 egress モードのみ Model Armor LLM への入出力（プロンプトとレスポンス）を検査して危険なコンテンツをブロック egress / ingress モード セマンティックガバナンスポリシー（SGP） 自然言語でルールを記述してエージェントのツール呼び出しや Agent Skills 呼び出しを制御 egress モードのみ Service Extensions カスタム認可エンジンをゲートウェイに統合 egress / ingress モード 参考 : Agent Gateway overview - Access control policies Agent Gateway を適切に設定すると、制御対象のエージェントの外部への通信や LLM とのデータ入出力がゲートウェイによってインターセプト（傍受）されて、上記の仕組みにルーティングされて評価され、その結果としてブロックされたりロギングされたりします。 それぞれ、egress / ingress モードのどちらのゲートウェイに適用できるかが決まっています。ゲートウェイのデプロイモードについては後述します。 なお、トラフィックがゲートウェイによって検査されるようにするためには、Agent Gateway を展開するだけでなく、 エージェント側にも設定が必要 です。既存および新規にデプロイされるエージェントが Agent Gateway を必ず経由するようにするためには、後述する組織のポリシーを設定する必要がある点に注意してください。 通信制御の対象 Agent Gateway が通信制御の対象にできるのは、以下の環境で動作するエージェントのみです。 Agent Runtime （旧称 Vertex AI Agent Runtime） Gemini Enterprise app 上記以外の環境にホストされているエージェントは、Agent Gateway による制御の対象外です。 参考 : Agent Gateway overview - Agent runtimes Agent Runtime にホストするエージェントの場合、Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定している エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける Agent Runtime のエージェントについては、組織のポリシーを使うことで、必ず承認されたゲートウェイを指定しないとデプロイできないように統制可能です。 参考 : Route Agent Runtime traffic through Agent Gateway 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways Gemini Enterprise app のエージェントの場合、アプリの管理設定で、使用するゲートウェイを明示的に指定する必要があります。 参考 : Route Gemini Enterprise traffic through Agent Gateway Identity-Aware Proxy（IAP） Agent Gateway は Identity-Aware Proxy （以下、IAP）の仕組みを使って、エージェントから他のエージェント、MCP サーバー、API エンドポイントへの呼び出し可否を決定します。 IAP による通信制御が使用できるのは Agent-to-Anywhere（egress）モードのゲートウェイのみです。Client-to-Agent（ingress）、つまりエージェントに入ってくる通信を IAP で制御することはできません。よって、Agent Gateway を介さないエージェントの呼び出しについては、エージェント側の認証・認可やネットワーク制御で適切に担保する必要があります。 制御のルールは、 IAM ポリシー によって定義します。詳細は後述します。 Model Armor Model Armor は、Google Cloud が提供する LLM 用の保護機能であり、LLM へのインプット（プロンプト）と出力されるアウトプット（レスポンス）を検査するサービスです。ゲートウェイで Model Armor を有効化すると、ゲートウェイを通るプロンプトやレスポンスが検査されるようになります。 Model Armor についての詳細は以下の記事を参照してください。 blog.g-gen.co.jp セマンティックガバナンスポリシー セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時や Agent Skills の呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 SGP は自然言語で定義され、LLM によって評価されるため、動的にポリシーを適用できるのが特徴です。SGP についての詳細は後述します。 参考 : Configure semantic governance policies Service Extensions Service Extensions を使うことで、独自の認可エンジンやサードパーティのエンジンに認可を委任できます。日本語の Google Cloud コンソール上では「サービス拡張機能」などと表記されます。 Service Extensions はもともと、Cloud Load Balancing と Cloud CDN の機能拡張のためにリリースされた機能であり、軽量な処理を Rust、Go、C++ などの言語で記述してアドオンできるプラグイン機能です。そのうちの Authorization extensions と同じ基盤を用いているのが、Agent Gateway の Service Extensions 機能です。 参考 : Delegate authorization with Service Extensions 参考 : Cloud Load Balancing and Cloud CDN extensions overview なお Agent Gateway でゲートウェイを作成して IAP を有効化したり Model Armor を有効化すると、それぞれに対応した Service Extensions が自動的に作成されます。Agent Gateway のバックエンドでは、実質的にこの Service Extensions が動作していることがわかります。 ゲートウェイ詳細画面 デプロイと運用 エージェントへのルール適用（Gemini Enterprise app） Gemini Enterprise app のエージェントに Agent Gateway の統制を適用するには、アプリの管理設定において、明示的にゲートウェイを指定します。 使用するゲートウェイは、アプリの管理画面の「セキュリティ > 構成」画面から設定できます。 また、Discovery Engine サービスエージェントと呼ばれる特殊なサービスアカウントに、所定の権限を付与する必要がある点にも注意してください。詳細は公式ドキュメントを参照してください。 参考 : Route Gemini Enterprise traffic through Agent Gateway エージェントへのルール適用（Agent Runtime） Agent Runtime にホストするエージェントを Agent Gateway の制御対象とするには、以下の条件があります。 エージェントのデプロイ時にゲートウェイを明示的に指定する エージェントが Agent Identity を持っている 同一プロジェクトの同一リージョンでは同じ Agent Gateway（egress / ingress ごと）に紐づける なお、ゲートウェイを作成するより前に既にデプロイされていたエージェントについては、ゲートウェイを指定してデプロイし直す必要があります。 参考 : Route Agent Runtime traffic through Agent Gateway Agent Gateway の使用を強制 組織のポリシーのカスタム制約を使用すると、Agent Runtime にデプロイされるエージェントが特定のゲートウェイを必ず使用するように強制することができます。組織としての統制のため、全エージェントのトラフィックが必ず Agent Gateway を通過するようにするためには、以下のドキュメントを参考にして組織のポリシーのカスタム制約を設定してください。 参考 : Route Agent Runtime traffic through Agent Gateway - Restrict Agent Runtime to approved Agent Gateways これらにより、組織内で Agent Gateway の使用を強制し、エージェントの通信に統制を効かせることができます。 プロジェクト構成 Agent Gateway のゲートウェイと、制御対象の Agent Runtime エージェントは、 同一プロジェクト ・ 同一リージョン に存在している必要があります。Gemini Enterprise app を制御対象とする場合も同様に、Agent Gateway のゲートウェイと、Gemini Enterprise app のアプリは同じプロジェクト・対応するリージョンに存在している必要があります。 よって組織全体でエージェントに対する統一した統制ルールを設定し、それを単一チームで運用するには、例として以下のような構成が考えられます。 案1: エージェントは単一の Google Cloud プロジェクトにデプロイ（組織のポリシーで制御）する。このプロジェクトで管理チームによって Agent Gateway が管理されている。 案2: 開発者チームごとに Google Cloud プロジェクトを払い出す。エージェントはそれらのプロジェクト内に存在している。Agent Gateway は管理チームが IaC 等で管理し、各プロジェクトに展開する。 案1 の構成では、エージェントデプロイ用の権限を持ったサービスアカウントを開発者チームに借用させたり、あるいは開発者チームにデプロイ権限を付与する、または CI/CD パイプラインによる自動デプロイでゼロタッチな本番デプロイをさせる、などによって実現することが考えられます。 案1: ゲートウェイを中央管理 ロギング Agent Gateway を通過するトラフィックは、Cloud Logging によって記録されます。ログには以下のような情報が含まれます。 タイムスタンプ Agent Registry リソース名（呼び出し元エージェント、呼び出し先の MCP サーバーなど） MCP のメソッド名（tools/call など） アクセス制御を処理した Service Extensions 拡張機能の情報 このログは、設定ミス等のトラブルシューティングのほか、ドライランモードで動作させている場合のポリシー監査に役立ちます。 ログエントリは networkservices.googleapis.com/Gateway リソースタイプとして記録されます。ログエクスプローラで以下のようなクエリを実行することで、Agent Gateway が出力したログを抽出できます。 resource. type=" networkservices.googleapis.com/Gateway " 参考 : Monitor traffic through Agent Gateway ドライラン 既存のエージェント環境に Agent Gateway を適用する場合は、事前にドライランを行って設定が適切であることを確かめてから、ポリシーを実際に適用することが推奨されます。 ゲートウェイの「アクセス認可」設定を「監査のみ」に設定することで、ロギングのみが行われブロックは行われないように設定されます。トラフィックのログは、前述のとおり Cloud Logging で確認できます。 ゲートウェイ ゲートウェイとは ゲートウェイ （Gateway）は、Agent Gateway の管理単位です。Google Cloud プロジェクト内に作成します。ingress モードと egress モードがあり、プロジェクト内に複数作成できます。 参考 : Set up Agent Gateway 設定値 ゲートウェイの作成時には、以下のような設定値を指定します。 リージョン ゲートウェイを展開するリージョンを指定します。制御対象の Agent Runtime のエージェントと同じリージョンを指定する必要があります。制御対象が Gemini Enterprise app のエージェントであれば、Gemini Enterprise app のアプリを作成したリージョンに対応したリージョンを指定する必要があります。例として Gemini Enterprise app のアプリが global リージョンにあれば、ゲートウェイは us-central1 に配置する必要があります。 Agent Registry ゲートウェイが制御対象とする Agent Registry のレジストリを指定します。制御対象の Agent Runtime エージェントと同じリージョンのレジストリを指定します。対象レジストリはグローバルレジストリ、リージョンレジストリ、US マルチリージョンレジストリ、EU マルチリージョンレジストリのいずれかから選択する必要があり、 //agentregistry.googleapis.com/projects/my-project/locations/asia-northeast1 のようにプロジェクト ID とロケーションの組み合わせで表されます。 デプロイメントモード（管理対象アクセスパス） Google Cloud コンソール上は「管理対象アクセスパス」、公式ガイド上は「デプロイメントモード」と表記されています。Client-to-Agent（ingress）または Agent-to-Anywhere（egress）から選択します。作成するゲートウェイが、エージェントに入ってくる通信を制御するものなのか、エージェントから出ていく通信を制御するものなのか、を決定する設定値です。詳細は後述します。 アクセス認可 デプロイメントモードが「Agent-to-Anywhere（egress）」のときだけ指定可能です。「監査のみ」または「ポリシーを適用」から選択します。前者を指定した場合はドライランとなり、ログが記録されるのみで、実際のアクセス制御は適用されません。後者の場合は、実際に IAM を使用したアクセス制御が適用され、明示的な許可がされていない通信はブロックされます。まずは前者でテストを行い、ポリシーが適切であると確かめられたら後者に変更する運用が想定されます。 Model Armor Model Armor の使用有無と、使用するテンプレートを指定します。 デプロイメントモード Agent Gateway には2つの デプロイメントモード （Deployment modes）があります。デプロイメントモードは、ゲートウェイを作成するときに選択します。Google Cloud コンソール上では「管理対象アクセスパス」と表記されています。 Client-to-Agent（ingress） Agent-to-Anywhere（egress） なお Google Cloud コンソール上では、前者は 「クライアントからエージェントへ（内向き）」、後者は「エージェントから任意の宛先へ（外向き）」と表記されています。 図左寄りが ingress モード、右寄りが egress モード Client-to-Agent（ingress） Client-to-Agent（ingress）は、クライアント（Claude Code、Gemini CLI、Antigravity CLI など）からエージェントへの通信を保護するためのモードです。エージェントに入ってくる通信に対して Model Armor のルールなどを適用できます。 Agent-to-Anywhere（egress） Agent-to-Anywhere（egress）は、エージェントから外部のサーバー、他のエージェント、ツール、MCP サーバー、API などへの通信を保護するモードです。IAP と IAM ポリシーによる認可や、Model Armor による検査などが適用できます。 Identity-Aware Proxy（IAP） IAM ポリシーとは ゲートウェイを通るトラフィックは、Identity-Aware Proxy（IAP）により検査されます。このとき IAP は IAM ポリシー （IAM policies）を使ってトラフィックを評価します。デフォルトではすべてのトラフィックが拒否されますが、ポリシーで指定されたソースとターゲットに合致したトラフィックであれば、許可されます。 参考 : IAM policies overview 参考 : Create IAM agent policies Agent Gateway における IAM ポリシーの実体は、IAP リソースが持つ IAM 許可ポリシーです。この概念を正確に理解するには、Identity and Access Management（IAM）の基本的な仕組みと、許可ポリシーについての理解が必要です。以下の記事も参照してください。 参考 : Google CloudのIAMを徹底解説！ - G-gen Tech Blog 設定値 IAM ポリシーは「Google Cloud コンソールの Agent Platform > エージェント > Policies」画面や gcloud コマンドラインを使い、プロジェクト内に複数作成できます。IAM ポリシーには、以下のような設定値があります。 参考 : IAM policies overview ‐ Policy components 接続元エージェント（ソースエージェント） アクセスを許可する対象の、接続元エージェントです。ゲートウェイに紐づけられたすべてのエージェントを指定することもできますし、個々のエージェントを指定することもできます。 ターゲット ポリシーが認可する接続先（ターゲット）を定義する設定値です。ターゲットとしては、Agent Registry に登録されているエージェント、MCP サーバー、API エンドポイントを選択できます。また、特定の Agent Registry に所属するすべてのターゲットを許可することもできます。 条件（Condition） 通常の IAM 許可ポリシー同様、条件（Condition）を指定することもできます。ただし指定可能な条件には制限があります。詳細は公式ガイドを参照してください。 設定イメージ Google Cloud コンソールの設定画面では、以下のスクリーンショットの上部の赤枠がソースエージェント、下部の赤枠がターゲットを指します。 IAM エージェントポリシー作成画面 ターゲットの Agent Registry としては、 グローバルレジストリ とリージョンごとの リージョンレジストリ が選択できます。Agent Registry では、エージェントや MCP サーバー、API エンドポイントを登録する際に、登録先としてグローバルレジストリまたはリージョンレジストリが選択できるので、対象が登録されているレジストリを適切に選択する必要があります。 グローバルレジストリまたはリージョンレジストリ セマンティックガバナンスポリシー 概要 セマンティックガバナンスポリシー （Semantic Governance Policy、以下 SGP）は、自然言語を使って定義するセキュリティポリシーです。エージェントのツール呼び出し時に評価され、ユーザーの意図と組織のルールの両方に合致しているかどうかがチェックされます。 参考 : Configure semantic governance policies 例として、出張手配エージェントが、宿泊先の手配をするツールを呼び出すケースを考えます。ツールは宿泊先の予約 API を実行するものですが、呼び出しの際に SGP が評価され「2万円を超える金額の自動的な決裁は禁止する」というルールに抵触している場合は、事前の設定に応じてツールの呼び出しを中止するか、人間の承認を求めます。このように、内容によって動的にポリシーを適用できるのが SGP の特徴です。 また SGP は、Agent Skills のロードに関するエージェントの挙動も傍受して制御できます。エージェントが実行する list_skills 、 load_skill 、 run_skill_script ツールなどを傍受して、ポリシーを適用できます。 ネットワーク要件 SGP を Agent Gateway で有効化するには、VPC ネットワークやプロキシ専用サブネット、Cloud DNS のプライベート DNS ゾーン、Private Service Connect エンドポイントなど、追加のネットワークコンポーネントが必要です。 参考 : Configure semantic governance policies ‐ Configure SGP policies and the SGP engine 技術的な詳細 プロトコル Agent Gateway は、MCP、A2A プロトコル、REST、gRPC など、HTTP ベースのトラフィックをサポートします。通信のペイロードは暗号化されます。 なお、エージェントの開発に使用するフレームワークは問いません。Agent Development Kit（ADK）でも、LangChain など Google 以外から提供するフレームワークでも、Agent Gateway で制御できます。 参考 : Agent Gateway overview - Key benefits 通信の暗号化と認証 ゲートウェイとエージェントとの間の通信は、mTLS（相互 TLS）によって暗号化されており、また Agent Identity に基づいて Demonstrable Proof of Possession（DPoP）による所有権証明も行われます。 これにより、エージェントになりすましたリクエストが困難になり、セキュリティが確保されます。 参考 : Agent Gateway overview - Integration with the Agent Platform ecosystem 参考 : IAM policies overview - IAP and Context-Aware Access provide end-to-end security Agent Identity については以下の記事で詳細に解説されています。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは。メディア統括本部 Data Science Center（DSC）の山田(@___rya ...