双方向エージェント間通信（A2A）
EKB は、オープンな Agent2Agent（A2A） プロトコルを双方向でサポートします：
| 方向 | 意味 | 設定場所 |
|---|---|---|
| アウトバウンド | 内側の EKB エージェントが HTTPS 経由で外部 A2A エージェントを呼び出す | エージェント → Toolkits → Agent Communication → ターゲットタイプ External（A2A） |
| インバウンド | EKB 外のシステムが認証済み A2A エンドポイント経由で自分のエージェントを呼び出す | エージェント → External Access タブ（エージェントカード URL + アクセスキー） |
タスクは会話全体にわたって保持され、エージェントを所有するプロジェクトに分離されます。
これは EKB 内側の別のエージェントを呼ぶこと（同じツールキット、ターゲットタイプ In EKB）とは別のものです。内部のマルチエージェントパターンについては Agent Communication Toolkit をご覧ください。
前提条件
| 方向 | 必要なもの |
|---|---|
| アウトバウンド | エージェントの編集権限；Agent Communication ツールキットの有効化；パートナーの HTTPS A2A ベース URL（必要に応じてベアラートークン） |
| インバウンド | エージェントの編集権限；External Access キーの発行能力；パートナーがベアラートークンで HTTPS 経由で自分の API ホストを呼び出せる環境 |
アウトバウンド：外部 A2A エージェントの呼び出し
パートナーやサードパーティシステムが、自分の EKB エージェントに委譲したい A2A 互換エージェントを公開しているときに使用します。
設定
- エージェントを開きます → Toolkits → Agent Communication を有効にします。
- ヘルパーエージェント構成を追加します（UI ではこれをヘルパーまたはターゲットエージェントカードと呼ぶ場合があります）。
- Where this agent lives で **External（A2A）**を選択します（In EKB ではありません）。
- 外部エージェントのベース URL を入力します。HTTPS が必須です。
- ベース URL または
/.well-known/agent-card.jsonで終わる完全なエージェントカード URL を貼り付けられます — どちらも許容されます。
- ベース URL または
- 必要に応じてパートナーの API キー / ベアラートークン を提供します。共有構成にリテラルを貼り付ける代わりに Vault への保存を推奨します。
- Verify Connection をクリックして、保存前に EKB がエージェントカードを取得し、名前、説明、スキル、到達性を検証できるようにします。
- エージェント構成を保存します。
ランタイムで、自分のエージェントはプロジェクト内のヘルパーに渡すのと同じやり方でその外部エージェントにタスクを渡せます — コンテキストは A2A 経由で渡されます。
アウトバウンドのフィールドチェックリスト
| 設定 | 備考 |
|---|---|
| ターゲットタイプ | **External（A2A）**であること |
| URL | HTTPS のみ；http:// は拒否 |
| 認証 | パートナーに応じて任意のベアラー / API キー |
| Verify Connection | 保存前に使用；失敗は多くの場合 DNS、TLS、SSRF ブロック、または非 A2A URL を意味 |
要件と制限
- 外部ターゲットは HTTPS を使用する必要があります。
- ディスカバリと呼び出しは EKB バックエンドを経由します（SSRF 保護を含む）。検証済みの URL はバックエンドが実際に到達できる URL です — ノートブック上でのみホストされているホスト名は本番では動きません。
- パートナーのトークンは他のシークレットと同様に扱ってください：貼り付けたリテラルより Vault 参照を推奨します。
インバウンド：他のシステムに自分の EKB エージェントを呼ばせる
別の製品、パートナーのエージェント、カスタム A2A クライアントが、自分の EKB エージェントのいずれかを呼び出す必要があるときに使用します。
エージェントカード URL
エージェントの External Access タブから次のような形の Agent Card URL を取得します：
https://<your-api-host>/a2a/agents/<agent_id>/.well-known/agent-card.json
これを相手に渡してください。彼らの A2A クライアントがカードを読み、エージェントが何ができて、リクエストをどこに送るべきかを把握します。
カード URL を共有するだけではアクセスは付与されません — 呼び出し側は依然として発行したキーを必要とします。
カードには、エージェントの名前、説明、スキル（デフォルトのチャットスキル）、JSON-RPC エンドポイントが記載されます。このエンドポイントのストリーミングはアドバタイズされません。
アクセスキー
- エージェントを開きます → External Access。
- 後でキーを区別できるようにラベルを付けます（例：
Acme partner integration）。 - キーを生成し、トークンをすぐにコピーしてください — ハッシュのみが保存され、シークレットは一度しか表示されません。
- パートナーに渡します：
- Agent Card URL
- ベアラートークン
- 不要になったキーは失効させます。シークレットを失った場合は失効させて新しいキーを発行します（元の平文は検索できません）。
キーはそのエージェントに限定されます。エージェント A 用の有効なトークンをエージェント B で使用することはできません。
外部呼び出し側から見えるもの
| リソース | メソッド / パス | 目的 |
|---|---|---|
| エージェントカード | GET /a2a/agents/{agent_id}/.well-known/agent-card.json | ディスカバリ（認証済み） |
| JSON-RPC | POST /a2a/agents/{agent_id}/rpc | message/send と関連する A2A メソッド |
以下で認証します：
Authorization: Bearer <access-key>
パートナー向けチェックリスト（インバウンド）
- ベアラートークンでエージェントカードを取得します。
- カードからアドバタイズされた JSON-RPC エンドポイントを読みます。
- 同じベアラートークンで A2A JSON-RPC リクエストを送信します。
- タスクがエージェントの所有プロジェクトに引き続き接続されることを想定します（下記参照）。
プロジェクトの分離
インバウンド A2A の実行はエージェントを所有するプロジェクトで実行されます。複数のプロジェクトに存在するテンプレートエージェントが呼び出し側間で共有されることはありません：各呼び出しは正しいプロジェクトコンテキストに固定され、1テナントの会話が他のテナントに漏れません。
典型的な設定
| 目標 | 方向 | 設定 |
|---|---|---|
| EKB の「マネージャー」エージェントがパートナーの専門エージェントに質問 | アウトバウンド | Agent Communication → External（A2A） + Verify Connection |
| パートナー製品が自分のサポートエージェントとチャット | インバウンド | External Access キー + カード URL |
| 自分の EKB エージェント2体が協働 | 内部（A2A ではない） | Agent Communication → In EKB |
トラブルシューティング
| 症状 | 確認すること |
|---|---|
| Verify Connection が失敗 | HTTPS URL；パートナーのカードパス；EKB バックエンドからのネットワーク経路；必要に応じてベアラートークン |
http:// が拒否 | HTTPS を使用 |
| パートナーが 401 を受信 | ベアラーの欠落/誤り；失効したキー；別のエージェント用に発行されたキー |
| パートナーがブラウザではカード URL を読めるが呼び出せない | カードだけでは不十分 — Authorization: Bearer … を送信する必要 |
| インバウンド呼び出しの誤ったプロジェクトデータ | エージェントの所有プロジェクトを確認；分離は所有プロジェクト単位 |
| Public Chatbot / Interfaces との混同 | A2A はエージェント間プロトコル統合であり、Web サイトウィジェットや公開インターフェース URL ではない |
関連ドキュメント
- Agent Communication Toolkit — EKB 内部のマルチエージェント委譲（およびアウトバウンド A2A ターゲット）
- エージェント概要