A2Aゲートウェイなしで20エージェントのシステムではポイントツーポイント接続が何本発生するか？

中央調整なしでは、20エージェントが最大190の直接接続を必要とする可能性がある（公式N×(N−1)/2）。資格情報が分散し、カスタムルーティングが必要になるため、運用上維持不可能になる。

ゲートウェイは正確な名前を知らずにどうやって正しいエージェントを見つけるか？

エージェントの説明はAmazon S3 VectorsにBedrock Titan Text Embeddingsベクトルでインデックスされており、クライアントは自然言語でクエリを送り、セマンティック検索で適切なエージェントを見つけられる。

ゲートウェイを使うクライアントにとってゼロシークレットモデルとはどういう意味か？

クライアントはスコープ付きJWTトークンのみを受け取り、すべてのバックエンドOAuth資格情報はAWS Secrets Managerが保持する。クライアントは個々のエージェントのパスワードを見たり管理したりすることはない。

AWSサーバーレスA2Aゲートウェイ：AIエージェントのディスカバリとアクセス制御

Amazon Web ServicesはAIエージェント間のディスカバリ、ルーティング、アクセス制御を集中化するサーバーレスA2Aゲートウェイのリファレンスアーキテクチャを公開した。20のエージェントが連携なしに動作すると最大190の接続が発生するが、ゲートウェイはそれを1つの入口ポイントに集約する。

企業内のAIエージェント数が増えるにつれ、中央調整なしでは運用上の混乱も増大する。Amazon Web Servicesはこの問題をインフラレベルで解決するサーバーレスA2Aゲートウェイのオープンリファレンスアーキテクチャを公開した。

エージェント数の増加はなぜ接続問題を生むか？

問題はシンプルに説明できるが、実際には深刻だ。2つのエージェント間の直接接続には、それぞれ独自の認証、独自のルーティングロジック、独自のアクセス制御が必要だ。Nエージェントがある場合、ポイントツーポイント接続の最大数はN×(N−1)/2となる。

10エージェントなら45接続。20エージェント——エンタープライズデプロイメントでは珍しくない状況——ではシステムが最大190の直接接続を必要とする可能性がある。それぞれが独自のローテーションが必要な資格情報、独自のエラー処理ロジック、独自の認可コードを持つ。分断がそれほど複雑になると、新しいエージェントを追加するだけでプロジェクトになってしまう。

A2Aゲートウェイはこれを1つの入口ポイントに集約する。

3層アーキテクチャ

管理レイヤー

管理レイヤーはエージェントの中央レジストリを保持し、ディスカバリを可能にする。各エージェントは1度登録されると、ゲートウェイが標準パスGET /agents/{agentId}/.well-known/agent-card.jsonで利用可能なagent-card.jsonを自動生成してキャッシュする。カードのURLはゲートウェイドメインに書き換えられるため、クライアントはバックエンドと直接通信することがない。

エージェントのディスカバリは2つの方法で機能する。名前の完全一致、または自然言語によるセマンティック検索だ。エージェントの説明はAmazon Bedrock Titan Text Embeddingsを使ってインデックスされ、Amazon S3 Vectorsに保存される。クライアントは正確な名前を知らなくても、「日本語の契約書を分析するエージェント」というようなクエリを送って意味的に関連するエージェントのリストを受け取れる。

制御レイヤー

制御レイヤーは認可とレート制限を管理する。認証はAmazon Cognitoを通じたOAuth 2.0クライアント資格情報フローに基づく。クライアントはアクセスを許可された特定のエージェントに結びついたスコープを含むJWTトークンを受け取る。

Lambda認可者は各リクエスト時にJWTスコープを評価する。レート制限はユーザーとエージェントの組み合わせごとに適用され、Amazon DynamoDBのアトミックカウンターで実装されている——並列リクエストでもDynamoDBのアトミック操作によりレート制限を回避できない。

実行レイヤー

実行レイヤーは認可されたリクエストを受け取り、AWS Secrets Managerからバックエンド資格情報を取得し、ターゲットエージェントに対して認証を行い、レスポンスをクライアントに転送するプロキシだ。Lambda Web Adapterを通じたServer-Sent Eventsストリーミングもサポートされており、クライアントはブロッキングなしにリアルタイムで部分的なレスポンスを受け取れる。

クライアント側のゼロシークレットモデル

セキュリティ設計はクライアントがバックエンドへのパスワードやOAuthシークレットにアクセスしてはならないという原則から出発する。すべてのバックエンド資格情報はSecrets Managerのみが保持し、クライアントは限られた有効期限のスコープ付きJWTトークンでゲートウェイとのみ通信する。

オプションのプライベートVPCデプロイメント（ゲートウェイとすべてのAWSサービスがプライベートネットワーク内でのみ利用可能、パブリックインターネットなし）およびオンプレミスエージェント向けのAWS Direct Connect接続と組み合わせることで、高いセキュリティ要件を持つエンタープライズ環境の要求を満たすアーキテクチャになる。

実装がオープンA2Aプロトコルをサポート

ゲートウェイはA2A（Agent-to-Agent）プロトコル——異なるベンダーのAIエージェント間の相互運用性のためのオープン標準——を明示的に実装している。JSON-RPCとHTTP+RESTバインディングの両方がサポートされており、異なるプラットフォーム上に構築されたエージェントがクライアント側の変更なしに同じゲートウェイを通じて通信できる。

インフラコード全体はTerraform設定（バージョン1.5.0以降）として利用可能だ。TerraformがDynamoDBテーブル（エージェントレジストリ、パーミッション、レート制限カウンター用）、Cognitoユーザープール、すべての操作のためのLambda関数、API Gateway、IAMロールを自動プロビジョニングする。Lambda コンテナのDockerビルドプロキシはterraform applyプロセスの一部として自動的に実行される。

実際のコンテキスト

リファレンスアーキテクチャは本番対応のサービスではなく、チームが適用できる文書化されたパターンだ。AWSはゲートウェイが組織が独自のセキュリティレイヤー、モニタリング、ドメイン固有のロギングを追加する基盤として意図されていることを強調している。バックエンド自体はプロンプトインジェクション攻撃に対する防御を実装する必要がある——ゲートウェイはエージェントへのアクセスを誰に許可するかを保証するが、メッセージの内容は分析しない。

AWSが190のポイントツーポイント接続を中央レジストリに置き換えるサーバーレスA2Aゲートウェイを発表