← 概念辨析に戻る

Concept Contrast Fable

モデルコンテキストプロトコルと Agent 通信プロトコル。一端はモデルとツールに、他端は Agent と Agent につながる

先に結論:モデルコンテキストプロトコルは、モデルが外部ツールやデータソースを発見・接続・使用する方法を標準化したインターフェースを定義する——これは「モデルがどうツールに接続するか」を解決する。Agent 通信プロトコルは、複数の Agent 間でメッセージを交換し、タスクを協議し、状態を同期する方法を定義する——これは「Agent 同士がどう対話するか」を解決する。MCP はモデルがリソースに向き合う入出力チャネルであり、Agent 通信プロトコルはマルチエージェント協調の対話経路だ。両者を混同することは、電話線を会議規則と取り違えることに等しい。

モデルコンテキストプロトコルは、モデルが外部ツールやデータソースを発見・接続・使用する方法を標準化したインターフェースを定義する——これは「モデルがどうツールに接続するか」を解決する。Agent 通信プロトコルは、複数の Agent 間でメッセージを交換し、タスクを協議し、状態を同期する方法を定義する——これは「Agent 同士がどう対話するか」を解決する。MCP はモデルがリソースに向き合う入出力チャネルであり、Agent 通信プロトコルはマルチエージェント協調の対話経路だ。両者を混同することは、電話線を会議規則と取り違えることに等しい。

寓話

朝廷には二本の駅道があり、一本は補給を送り、一本は軍令を伝える

辺境の前線には三つの大軍が駐屯し、指揮中枢は後方五百里の元帥府に置かれていた。後勤システムは毎日三つのことを知る必要があった。各営の糧秣在庫、馬匹の状態、矢の備蓄である。そこで元帥府は「給養駅道」を設けた——沿道八十里ごとに中継所を建て、補給車が中継所に着くと、令牌で物資を引き出し、受領証に署名し、在庫帳簿を更新する。この駅道の核心機能は、資源の需要側(各営)と供給側(中継所)の間に標準化されたやり取りの通路を確保することだった。

同時に元帥府には、まったく異なる通信体系があった。「軍令鳩道」である。元帥府と三人の将軍の間で命令を伝えるのは伝書鳩の暗号筒で、将軍同士の協同移動も同じ鳩道を使う。鳩道には独自のプロトコルがある。命令内容は緊急度で等級分けされ、受信側は必ず受領証を返し、一つの軍令は同時に複数経路に写しの送付できる。この体系の核心機能は、複数の意思決定ユニット間で効率的に情報を交換し、協同行動できるようにすることである。

開戦後3か月目に、組織の混乱が生じた。兵站を担う糧秣官は重要な任務を受けた。第三営の糧秣優先度を調整し、第一営の口糧を先に隘口を攻めている第三営へ回すというものだ。糧秣官は調整令を書いたが、どの経路を通すべきか分からなかった。糧秣中継所なら物資を調整すればよいが、三つの営の間の協調と駆け引きは将軍レベルで状態を同期する必要がある。

元帥府が振り返ったとき、糧食官の誤りは「将領間の協同決定」を「資源チャネルの調整操作」として扱ったことにあった。糧食を再分配するという動作は補給駅道だけで完全に実行できるが、三人の将軍の間で「なぜこう分配するのか、いつ正常な分配に戻すのか」という情報同期は鳩道を通らなければならない。一つは正しい道を歩み、一つは間違った道を歩み、その結果、第一営の将軍は情報欠如のために誤った判断を下した。

後に元帥府は駅伝管理規程に一つの鉄則を加えた。複数の営の調整に関わる情報は鳩道を通し、単一の資源と器械のやり取りは補給駅道を通し、両者を混用してはならない。同時に、糧食官は兵力協同に関わる調整命令を単独で発信できないと定めた。この種の命令はまず将軍参謀署を通し、各営の確認受領書を得てからでなければ執行できない。

この鉄則はすぐに一度の急を救った。第三営が夜に矢を欠いたとき、補給駅道はすぐに矢を調達できる。しかし第一営に弓手を譲らせるなら、鳩道を通り、二人の将軍が同時にリスク、時間、補償の取り決めを知る必要がある。前者は物を取ること、後者は協同であり、道は異なる。

元帥は後に二枚の経路図を本営の入口に掛けた。左は補給路で、倉庫、車、通行札、受領確認が描かれている。右は軍令を伝える伝書鳩の経路で、将軍、受領通知、関係者への写しの送付、共同承認が描かれている。補給担当官はもはや「どうせどちらも伝令だ」とは言えなくなった。物資を送ることと人々の意思を調整することは、決して同じことではないからだ。

モデルコンテキストプロトコル

モデルと外部ツールおよびデータソース間の標準化された対話方式を定義する。クライアントはサーバー側が提供するツールリストを発見し、リクエストを送り、レスポンスを受け取る。解決するのは単一モデルの能力拡張問題で、本質は client-server アーキテクチャである。

Agent 通信プロトコル

複数の Agent 間でメッセージを交換し、タスクを交渉し、状態を同期するルールの集合を定義する。マルチエージェント協働の通信と調整の問題を解決し、通常はメッセージルーティング、セッション管理、コンセンサスメカニズムが必要である。

物語の対応

  • 補給駅道:MCP——モデルとツール/リソース間の標準化された対話チャネル
  • 飛鳩暗号筒:Agent 通信プロトコル——複数の意思決定ユニットの協調メッセージシステム
  • 中継所はトークンで物資を受け取る:MCP の client-server 呼び出しモデル
  • 鳩の道による伝令、等級分け、受領証:Agent 通信におけるメッセージルーティングと確認メカニズム
  • 糧食官が誤った経路を選んだ:Agent 間の協調要件を資源操作と誤認した
  • 第一営将軍が知らずに弾劾文書を書く:情報欠如が誤判断を招く——Agent 間同期の欠如
  • 元帥府の鉄則:二種類のチャネルは混用不可——単一資源呼び出しと多主体調整を区別する

マルチ Agent システムのアーキテクチャ設計に落とし込む

複数の Agent を含むシステムを設計する際は、まず通信トポロジー図を描き、二種類の線を区別する。実線は MCP 接続——単一の Agent からそれが必要なツールとデータソースへ。破線は Agent 通信プロトコル——Agent から Agent、Agent からオーケストレーター、Agent から共有状態へ。自分のアーキテクチャ図に MCP 接続しかなく Agent 間の破線がないなら、Agent 間の調整は共有ファイルやグローバル変数に頼るしかない——これは高並行の場面では遅かれ早かれ破綻する。Agent 通信プロトコルを選定する際は、メッセージキューシステムや既存のマルチ Agent フレームワークが提供する通信層を優先し、MCP のリクエスト応答モデルの上に手動で調整ロジックを加えようとしないこと。

京ICP备2026014272号