AWSが、複数のAIエージェントの発見・振り分け・アクセス制御を単一窓口に集約するサーバーレス型「A2Aゲートウェイ」の構築方法を公式ブログで公開し、Terraformで自動構築できるサンプルコードも提供した。
AWSが2026年7月2日、公式ブログで複数のAIエージェントを単一窓口に集約するサーバーレス型A2Aゲートウェイの構築方法を公開した。20体のエージェントを直接つなぐと最大190本の接続が必要になる問題を、単一ドメインの背後でパスベースの振り分け（/agents/{agentId}）に畳む設計だ。標準的なA2Aクライアントを改造なしで使える。
設計は管理層（登録・検索）・制御層（権限管理）・実行層（振り分け）の3層構造。到達可否はAmazon Cognitoの認証トークン（JWT）内の権限範囲で判定し、自然文でのエージェント発見にはAmazon Titan Text Embeddingsの意味検索を使う。実行基盤はコンテナ・AWS Lambda・Amazon Bedrock・他社クラウドを問わない。
さらに利用者ごと・エージェントごとに毎分の呼び出し回数を制限する仕組みを備え、Terraformで自動構築できるサンプルコードも提供される。エージェント本番運用で膨らむ接続数と認証ポリシーの分散を、一箇所で制御できる点が実務上の価値になる。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
企業がチームやベンダーをまたいで多数のAIエージェントを導入すると、エージェント同士の通信を管理する負担が急増する。中央の管理層がないと、新しいエージェントを追加するたびに個別接続や認証情報、独自の振り分け処理が積み重なる。例えば20個のエージェントを直接つなぐと最大190本もの接続が必要になり、増加のたびに手間が急激に膨らむ。今回の設計はエージェント同士の通信規格「A2A（Agent-to-Agent）プロトコル」を土台に、単一の窓口でこれを解決する。
AIエージェントを本番運用する企業が増える中、接続数の爆発と認証ポリシーの分散はセキュリティ上の弱点になりやすい。このゲートウェイ設計は、実行基盤（コンテナ・AWS Lambda・Amazon Bedrock・他社クラウドなど）を問わず単一の窓口に集約し、権限管理と振り分けを一箇所で制御できる点が実務上の価値になる。標準的なA2Aクライアントを改造なしで使える点も導入の障壁を下げる。
エージェントを増やすほど接続が指数的に膨らむ。AWSの公式ブログは、20体のエージェントを直接つなぐと最大190本の接続が必要になる問題を出発点に置く。この設計は、それらを単一ドメインの背後に集め、パス（アドレスの階層。/agents/{agentId} の形）でどのエージェントに渡すかを振り分ける。
In this post, you will learn how to build a serverless A2A gateway on AWS that hosts multiple agents behind a single domain using path-based routing (/agents/{agentId}). Standard A2A clients work without modification.
ここで言う「A2A」は、AIエージェント同士が通信するための共通規格（Agent-to-Agent プロトコル）を指す。標準のA2Aクライアント（規格に沿った呼び出しプログラム）を改造なしで使える点が、既存構成からの移行障壁を下げる。
設計は役割の異なる3層に分かれる。登録と検索を担う管理層、権限を判定する制御層、実際に呼び出しを渡す実行層だ。層を分けることで、新しいエージェントを足すたびに認証や振り分けを個別に作り込む手間を避ける。
さらに、利用者ごと・エージェントごとに毎分の呼び出し回数を制限する仕組みを備え、一部の利用が全体を圧迫するのを防ぐ。
得をするのは、多数のエージェントを本番で動かすAWS利用企業だ。接続数の爆発と認証ポリシーの分散を単一窓口に吸収でき、Terraformで自動構築できるサンプルコードで基盤の初期構築を縮められる。
標準A2Aクライアントを使う開発者は、クライアントを改造せずゲートウェイ経由へ切り替えられる。セキュリティ・ガバナンス担当は、到達可否の判定をAmazon Cognitoの認証トークンに集約でき、権限を一箇所で握れる。
一方で、これまでエージェントを点対点で直結してきた運用チームは、既存の接続と独自の認証・振り分けをゲートウェイ経由へ移す設計変更と検証を迫られる。認証にAmazon Cognito、意味検索にAmazon Titanを前提とするため、AWS外の基盤に閉じたい組織はこの設計をそのまま適用しにくい。
立場別、明日から動ける一手。
3層構造（管理・制御・実行）のうち権限判定がAmazon Cognitoの認証トークンのどの範囲で行われるかを、公式ブログとサンプルコードで確認する。
現状のエージェント直結運用の接続数・認証情報管理コストと、単一窓口へ集約した場合の運用負荷を比較する。
Terraformのサンプルコードで最小構成を立て、標準A2Aクライアントが改造なしでパスベースの振り分け経由で到達するかを試す。
本記事の主題であるA2Aゲートウェイ設計そのものに直接言及したX投稿は確認できなかった。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「agentic enterprise」
周辺では、エージェント推論基盤を大規模本番運用する話題（トリリオントークン規模の推論エンジン等）や、Snowflakeの「agentic enterprise」やTrust and Governanceといったエージェントのガバナンス・権限管理をめぐる議論が並行して見られる。エージェント間接続の増加に伴う認証ポリシーの分散とセキュリティ、実行基盤を問わない単一窓口での集中制御という実務的な関心が、業界共通の論点として浮かび上がっている。
※トレンド検出時刻付近の人気投稿を表示
