こんにちは、LIFULLでUXリサーチャーをしている小川です。 LIFULLは「RESEARCH Conference」の初回から継続してスポンサーを務めておりますが、今年はありがたいことに、スポンサー枠とは別にポスターセッションへの発表機会もいただくことができました。 2026年6月28日に開催された「 RESEARCH Conference 2026 」のテーマは「WEAVING」。このカンファレンスのテーマに合わせ、私たちは 「『眠れる資産』を『生きたユーザー』として呼び覚ます」 というタイトルで発表を行いました。当日使用したポスターの全体像は、こちらからご覧ください。 今回発表したのは、過去の調査データを眠らせたままにせず、日々の業務に活かすための「ユーザーライブラリ」という取り組みです。 インタビューデータと既存ユーザーセグメントを組み合わせ、生成AIを活用することで、開発現場のメンバーがいつでも手軽にリサーチデータを引き出せる仕組みをつくりました。 この記事では、限られた時間の中ではお伝えしきれなかった背景や、当日よくいただいたご質問について、少し深掘りして補足させてください。 当日話しきれなかったポスターの補足 補足1. なぜ「ユーザーライブラリ」に取り組んだのか？ 私が所属するユーザーファースト推進グループは、全社横断でUXリサーチを行っている組織です。普段は開発チームからの依頼を受けて調査やレポート作成を行っています。 これまで数多くのインタビュー調査を行ってきましたが、集めた内容のすべてが調査レポートに活用されるわけではありません。しかし、それらは決して無駄なデータではなく、別の視点で見れば、新規調査が不要になるほど価値あるデータであるケースも多くあります。 このような 「今回の調査目的には不要でも、別の文脈では価値があるデータ」 を、担当リサーチャーしか辿り着けない状態のまま埋もれさせてしまうのは非常にもったいないと感じていました。 これらを個人の手元で眠らせるのではなく「開発メンバーが活用できる資産」へ生き返らせる。そんな組織のデータ活用に変化を起こすために、今回のプロジェクトを立ち上げました。 補足2. 定性データ管理のとりくみ 現在、定性データを以下の3つのデータソースとして整理し、役割を分けて運用しています。 調査レポートソース（NotebookLM） ：過去の調査結果そのものを蓄積するデータソース。 インタビュー個票ソース（NotebookLM） ：発話などの生データをそのまま参照するためのデータソース。 セグメント別対話AI（Gemini） ：今回のポスターセッションで焦点を当てた、ユーザーセグメントにフォーカスを絞ったデータソース。 今回の試行錯誤のなかで「今の目的には合わないが、将来的に別の目的で活きる」と判断したデータソースもできました。そのデータソースは今も管理を続けています。 補足3. なぜ「Gemini」を選んだのか 当日「なぜ数ある生成AIの中からGeminiを選んだのですか？」というご質問も多くいただきました。 結論から言うと、ツールの純粋な性能云々というよりも、 「私たちの社内環境において最適解」 と判断したからです。ツールの選定にあたっては、以下の3つの観点を重視しました。 社内アクセス性 ：開発メンバーやリサーチャーが日常業務で使いやすいツールであること。 カスタム指示の柔軟性 ：チームの知見やプロンプトをAIに学習させやすいこと。 知識データの指定 ：Googleドライブ等と連携し、既存のインプット資産を活用しやすいこと。 重要なのは特定のツールに依存することではなく、 「どうすれば社内のリサーチデータが活きた資産になるか」 という目的そのものです。どんなに優れたAIツールであっても、利用するために複雑な設定や申請が必要なものは最初に除外しました。 現在、私たちはGeminiで運用をしておりますが、同じようなアプローチはNotebookLMでも実現可能ですし、環境さえ整えば他のLLMツールでも同様の仕組みは十分に構築可能です。 補足4. 「確証バイアス」への対策 今回の発表において、参加者の方々から特に多くの共感の声をいただいたのが、解決策のなかでも『「都合の良いデータだけを見る」リスクの防止』に関する取り組みでした。 人はどうしても自分の仮説を後押ししてくれる「都合の良いデータ」ばかりに目が向いてしまいがちです（確証バイアス）。そうした思い込みや視野狭窄に陥るのを防ぐため、今回の仕組みでは、 あえて相反するファクトや関連するデータを一緒に提示する工夫 を入れました。 「一方向からの情報だけで満足せず、多面的に仮説をブラッシュアップしてもらいたい」という、私自身の強い気持ちから生まれた対策です。 おわりに まずは、当日のタイトなスケジュールのなか、私たちのポスターブースに足を運んでくださった皆さま、本当にありがとうございました！ コアタイム以外でも熱心に議論が続き、多角的な視点でフィードバックをいただけたことは、私自身とても大きな学びとなりました。温かいコメントや鋭いご指摘のすべてが、今後の励みになります。皆さまからいただいたヒントを胸に、今後も取り組みをブラッシュアップしてまいります。 今回の発表を通じ、多くのチームが私たちと同じように「リサーチデータの活用」に頭を悩ませているのだと強く実感しました。またどこかのカンファレンスでお会いした際は、ぜひ情報交換をさせてください！ 運営スタッフの皆さまにも心より感謝申し上げます。引き続き、リサーチデータを「眠らせない」ための工夫を現場で続けていきたいと思います。 LIFULLでは共に成長できるような仲間を募っています。よろしければこちらのページもご覧ください。 hrmos.co

はじめに こんにちは、NTTデータグループAI技術部の太田です。 先日サンフランシスコで開催されたDatabricksのイベント「Data + AI Summit 2026」に現地参加してきました。 本カンファレンスでの注目トピックの一つとして「Genie」が大きく進化しました。これまでGenieというと「自然言語でデータに質問できるAI/BIアシスタント」という印象が強かったと思います。今回の発表では、Genieが単なる分析アシスタントから、ビジネスユーザから開発者まで幅広いユーザと共に業務を遂行するAI Coworkerなサービス群へと再定義されました。 本記事では、Data +

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