LangChainとStrandsのAgentを別AWSアカウントで連携します。Agent Cardによる発見と双方向のOAuth認証を使う構成です。 相手の実装を共有せず機能を接続できる可能性があります。相互認証だけでなく、渡す業務情報と呼び戻し先の信頼境界を管理します。 組織をまたぐ連携を共通の通信形式で作る AWSは11月12日、Agent-to-AgentのA2Aを使う参考構成を公開しました。企業のAgentと外部サービスのAgentが、異なる開発基盤でも仕事をやり取りする例です。企業側はLangChain、サービス提供者側はStrands Agentsを使い、別々のAWSアカウントで動きます。A2AはAgentの発見やタスクの受け渡しを標準化するプロトコルで、Linux Foundationのプロジェクトです。相手側と同じSDKを採用する必要はありません。接続時には公開された認証基盤のURLや接続先、利用範囲などを交換します。両者で秘密情報を共有しない設計を示しました。 依頼先から社内情報を取りに戻る経路も守る 参考構成は企業側の統括Agent、社内情報を提供するAgent、外部の確認用Agentから成ります。統括AgentがAgent Cardから利用できる機能を読み、モデルが質問に応じて呼び出し先を選びます。外部Agentは必要に応じて企業側の情報提供Agentへ問い合わせます。認証はそれぞれのCognitoを使い、呼び出しと呼び戻しの両方向にOAuthを適用します。企業内のAgentは非公開のネットワークで動作し、API Gatewayを経由して接続します。この構成は外部サービスを提供する企業に加え、社内で異なる開発基盤を持つ部門間にも関係します。機能を足す際に既存Agentをすべて改修する負担を減らせる可能性があります。ただし、通信形式が共通でも、業務上の意味や相手へ渡せる情報まで自動的に一致するわけではありません。 公開する能力と実際に許す操作を照合する 採用時には、Agent Cardに書かれた能力をどこまで信用するかが論点です。接続先の登録、更新、利用範囲の変更を担当する体制が必要と見られます。相手が認証されていても、内部のあらゆる資料を返してよいとは限りません。要求ごとに情報の範囲を絞り、外部へ依頼したタスクと内部への問い合わせを追跡できる記録が重要になります。モデルが機能を選ぶ構成では、説明文の変更が呼び出し判断に与える影響も評価します。複数アカウントの認証設定や経路の運用には追加の負担が伴います。参考例の動作をそのまま実サービスの保証とせず、期限切れ、相手の停止、誤った応答でも業務を止められるかを確認します。組織ごとの責任範囲を保ったまま連携できることが、導入判断の焦点です。接続相手の追加や解除を、通常の取引先管理と対応させることも検討事項になります。