Skip to Content
Docs03. 実装エージェント間連携プロトコル
上級a2ainteroperabilityagent-cardmcp更新: 2026-08-18この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

エージェント間連携プロトコル

最終確認日: 2026-08-18。 本記事はエージェント間連携の標準が動いている領域を扱います。標準の仕様バージョン・ガバナンス・採用状況は変化が速いため、具体の仕様値や版数は本文に固定せず、公式仕様とリポジトリの research/infra/agent-protocols.md(調査メモ)の最新を確認してください。ここでは構造と判断軸に重心を置きます。

この記事の目的

組織・システムの境界を越えてエージェント同士が連携する際の、発見・認証・委譲・信頼の設計を判断できるようになります。ツール接続との非対称・プロトコルが定める要素の構造・組織間の信頼の扱い・信頼の段階設計・新しい攻撃面・標準の現在地を、実装以前の設計判断として持ち帰れる状態を目指します。

対象読者

前提知識

本文

概要: 「部品を呼ぶ」と「相手に任せる」は違う

エージェントの連携には、性質の異なる 2 つがあります。1 つはツールを呼ぶ——データベースや API といった部品を、決まった入出力で使います。もう 1 つは他のエージェントに任せる——自律的に考え・計画し・状態を持つ相手に、タスクを委ねます。前者を担うのがツール接続の標準(MCP)、後者を担うのがエージェント間連携の標準です。

この 2 つは対立ではなく相補的です。あるエージェントが他のエージェントに連携で任せつつ、各エージェントは内部でツール接続を使って自分の道具を操る、という重ね方が標準の公式な位置づけです。本記事は「相手に任せる」側の設計を扱います。核心は、相手を「部品」ではなく「自律した主体」として扱うことで、渡す情報・受け取る結果の形・信頼モデルが変わる、という点です。標準の具体(A2A・MCP・関連提案の版数やガバナンス)は変化が速いため、本文は構造に絞り、詳細は調査メモと公式に委ねます。

ツール接続と連携の非対称

「ツールを呼ぶ」と「エージェントに任せる」は、責任と会話の形が非対称です。

  • ツール = 部品(多くは状態を持たない): 決まった入力に決まった出力を返す機能です。呼ぶ側が主導権を持ち、結果の解釈も呼ぶ側の責任です
  • エージェント = 自律した主体: 自分で考え・計画し・複数の道具を使い、長いやり取りにわたって状態を保ち、多ターンの対話をします。任せる以上、中身のやり方は相手に委ねます
  • 相手の内部を共有しない(不透明さ): 連携の標準は、エージェントを「中身の見えない相手(opaque)」として扱うのが原則です。互いのメモリAgent が「覚えている」ように見えるデータの総称。短期記憶(コンテキスト)・作業状態・長期記憶(外部ストレージ)の 3 層に分けて設計する。・ツール・コンテキストを共有せず、外部インターフェースだけでやり取りします。これは「相手を tool に閉じ込めない」という設計思想の表れです
  • 非対称が信頼モデルを変える: 部品なら「正しく動くか」を気にすれば済みますが、自律した相手には「何を開示するか」「結果を信頼してよいか」という、より重い判断が加わります

プロトコルが定める 5 要素の構造

エージェント間連携のプロトコルが定めるものは、5 つの要素に整理できます。この枠は「プロトコルが何を決めるか」の骨格として使えます。

要素何を定めるか代表的な形(A2A の例)
発見(discovery)相手をどう見つけるかエージェントカード(機械可読メタデータ)を既知の場所で公開
能力広告相手が何をできるかできることの一覧(スキル・入出力の形式)を宣言
委譲(delegation)タスクをどう渡すかメッセージを送り、非同期作業はタスクとして扱う
進捗/結果長い処理の途中と結果をどう受け取るかポーリング/ストリーミングLLM の応答を生成と同時に逐次受信・表示する方式。Agent の体感品質を左右する基本技術。/通知 + タスク状態 + 成果物
認証・認可誰と・どこまで対応する認証方式を広告し、標準ヘッダで搬送
  • 発見: 相手のエージェントカード(何者で・何ができ・どう認証するかを書いた機械可読の名刺)を公開・取得します。これにより、連携相手を機械的に見つけ・選べます
  • 能力広告: 相手が提供する能力(スキル)と、その入出力の形式を宣言します。任せる側は、これを見てタスクに合う相手を選びます
  • 委譲: タスクを渡します。即答できるものはその場で、時間のかかるものは「タスク」として非同期に扱い、会話の文脈を紐づけて継続します
  • 進捗/結果(長時間タスク): 連携タスクは、数秒で終わるものから数時間・数日に及ぶ調査まで幅があります。途中経過をポーリング・ストリーミング・通知で受け取り、タスクの状態(実行中・要入力・完了・失敗など)と成果物を扱います。長時間タスクを前提とした状態管理が、単発の API 呼び出しとの大きな違いです
  • 認証・認可: 誰からの委譲かを確かめ、何を許すかを決めます(次節)

組織間の信頼(認証・認可)

組織をまたぐ連携で最も難しいのが、相手を信頼してよいかです。標準の設計は「認証はプロトコルに埋め込まず、既存の標準に委ねる」方向です。

  • アイデンティティは搬送層で確立する: 連携の標準は、プロトコルの中身(ペイロード)に利用者やクライアントの ID を載せず、通信(HTTP)の層で身元を確立します。対応する認証方式を広告し、標準的なヘッダで認証情報を運びます
  • 認可は実装固有: 「誰に何を許すか」は、プロトコルではなく各エージェントの実装・扱うデータ・組織のポリシーが決めます。エージェント固有の認可標準は、2026 年時点でまだ確立していません。既存の認可基盤(エージェントの認証・認可)で吸収します
  • 最小権限・能力単位で許す: 相手に許す範囲を、能力(スキル)単位で最小限に絞ります。「連携できる」ことと「何でも任せてよい」ことは別です
  • 決済のような重い委譲は証跡を暗号的に: 金銭のように失敗コストの高い委譲では、署名付きの同意記録と検証可能なクレデンシャルで、認可・真正性・説明責任を暗号的に担保する上位の仕組み(決済プロトコル)が現れ始めています。「エージェントに重要なことを委ねる」領域は、最初から証跡と同意の検証を前提に設計されつつあります

信頼の段階設計(社内 → パートナー → 公開)

すべての相手を同じ信頼度で扱うのは危険です。信頼を段階で設計します。

  • 段階を分ける: 社内のエージェント・契約したパートナーのエージェント・公開の未知のエージェントで、許す委譲の範囲を変えます。社内には広く、公開には狭く、が基本です
  • 委譲してよいタスクを分類する: どんなタスクなら委ねてよいか(読み取りのみ・低リスク・可逆)を、相手の信頼段階ごとに分類します。高リスクな委譲は、信頼できる相手にのみ許します
  • 動的発見に賭けない: 「未知の相手を動的に発見して任せる」設計は、まだ時期尚早です。発見のうちレジストリの仕組みは標準化が進んでおらず、当面は既知の相手か、自前のカタログに閉じるのが安全です

相手エージェントという新しい攻撃面

連携相手は、新しい攻撃面です。標準の公式ガイダンスも「相手を信頼できない外部アプリとして扱う」ことを基本にしています。

標準の現在地と「まだ標準に賭けない」設計

エージェント間連携の標準は、骨格は固まりつつあるが周辺は流動的です。この現在地を踏まえて設計します。

  • 安定している部分: 発見・能力広告・メッセージとタスクの構造は、比較的固まってきています。ガバナンスも、中立な標準化団体への移管と、乱立していた提案の収斂が進んでおり、2026-08 時点ではツール層(MCP)・エージェント層(A2A)の主要標準が同一の財団(AAIF)傘下に揃っています
  • まだ動く部分: 認可・組織間 ID・決済・レジストリの仕組みは活発に動いています。土台となる認証の標準自体もまだ草案段階のものがあります
  • 「まだ標準に賭けきらない」設計: 中核(発見・委譲・タスク)は使いつつ、動きの速い部分(認可・ID・レジストリ)は実装固有の層で吸収し、標準の変化に引きずられない逃げ道を残します。特定の標準・版に密結合せず、抽象化層を挟んで最小結合にします
  • ツール接続と混同しない: 「ツールを呼ぶ(MCP)」と「エージェントに任せる(連携)」は層が違います。両者を混同せず、それぞれの標準を役割で使い分けます

実務での注意点

アンチパターン

  • 連携相手を「部品」と同じ感覚で扱う → 内部を共有させる・結果を無検証で信頼するなど信頼モデルを誤る → 相手を自律した不透明な主体として扱い、開示と信頼を設計する
  • 認可をプロトコルが決めてくれると期待する → エージェント固有の認可標準はまだない → 認可は既存の認可基盤で、能力単位・最小権限で自前に設計する
  • すべての相手を同じ信頼度で扱う → 公開の未知の相手に広い委譲を許して事故 → 社内/パートナー/公開で信頼を段階化し、委譲してよいタスクを分類する
  • 未知の相手を動的に発見して任せる設計に賭ける → レジストリの仕組みは未標準で時期尚早 → 既知の相手・自前カタログに閉じる
  • 連携相手の応答を無条件に信頼する → 悪意ある応答・過剰開示・インジェクションの経路 → 相手を信頼できない外部アプリとして扱い、応答を検証し開示を最小化する
  • 特定の標準・版に密結合する → 動きの速い周辺仕様の変化に引きずられる → 中核だけ使い、認可・ID・レジストリは抽象化層で吸収する
  • ツール接続と連携を混同する → 層の違う標準を取り違える → 「呼ぶ(MCP)」と「任せる(連携)」を役割で使い分ける

チェックリスト

  • 連携相手を、部品でなく自律した不透明な主体として扱う設計になっているか
  • 発見・能力広告・委譲・進捗/結果・認証の 5 要素を、どう満たすか整理したか
  • 認可を、既存の認可基盤で・能力単位・最小権限で設計したか(標準任せにしていないか)
  • 信頼を段階化(社内/パートナー/公開)し、委譲してよいタスクを分類したか
  • 動的発見に賭けず、既知の相手・自前カタログに閉じているか
  • 通信を暗号化し、情報開示を最小化し、相手の応答を検証しているか
  • 動きの速い部分(認可・ID・レジストリ・決済)を抽象化層で吸収し、標準に密結合していないか

関連トピック

参考資料

  • Agent2Agent(A2A)Protocol 公式仕様  — 発見・委譲・タスク・認証の仕様(アクセス日: 2026-08-18)
  • A2A と MCP の関係(公式)  — 「ツールを呼ぶ」と「エージェントに任せる」の線引きと相補関係(アクセス日: 2026-07-09)
  • リポジトリの調査メモ research/infra/agent-protocols.md — A2A/MCP/AP2 の構造・ガバナンス・成熟度を確度付きで整理(アクセス日: 2026-07-09)

TODO・未確認事項

コード実行サンドボックスの実装オープンソース AI エコシステム