MCPとA2A：モデル・プロトコルは2025年にどう使われるか

MCP（Model Context Protocol）とA2A（Agent-to-Agent）は、ソフトウェア・アーキテクチャに関する従来の前提を急速に変えつつあります。あなたが戦略をリードしているのか、ソリューションを構築しているのかにかかわらず、新しいテクノロジーを統合する際に陥りがちな間違いを避けるために、それらを明確に説明します。

この作品が終わる頃には、あなたも理解できるだろう：

• MCPとは何か？
• A2Aとは何か？
• 各プロトコルの使用時期
• 将来的に両方を使う可能性が高い理由

MCPとA2Aとは何か？

私たちは今、現代史上最大のパラダイム・シフトの最前線にいる。人工知能は実際に、ほとんどすべての人が何らかの文脈で日常的に使用している。ワークフローやアーキテクチャでは、タスクを達成するために使用されるモデルを「エージェント」と呼ぶ。

あなたが現在使っているほとんどの中心は、モデル・コンテキスト・プロトコル（MCP）です。Agent-to-Agent (A2A)は、明確に定義されたプロトコルというよりも、新たな機能のセットです。

• MCP: これはコンテキストとモデルの内部状態の両方を管理するために使われる。おそらく毎日MCPとやり取りしていることでしょう。Grok、ChatGPT、CoPilotのようなモデルはすべて、一般的な目的でコンテキストとタスクを管理するためにMCPを使用します。独自のエージェントを作成する場合、カスタム MCP を書くことになるでしょう。
• A2A: 2つ以上のモデルが互いに会話する場合、これはエージェント間のプロセスです。各エージェントは独自のMCPに従います。そのコミュニケーションプロセスはA2Aと呼ばれます。人間同士の話し言葉や書き言葉のように考えることができます。

モデル・コンテキスト・プロトコル-脳

MCPはマシンの “頭脳 “のようなものだと考えることができる。MCPは言語の解釈からタスクの完了に至るまで、タスクの内部プロセスのすべてを包含している。

Xでは、ユーザーが”@grok “と返信し、その後に質問や発言を続ける投稿が延々と続く。Grokは、ユーザーのプロンプトを解釈し、スレッドに関連する投稿を返信する。これは教科書的なMCPであり、実際のユースケースを満たしている。

1.クエリ・ルーティング

最初のステップは「クエリ・ルーティング」です。あなたが「@grok、この投稿をファクトチェックしてくれないか」と言うと、Grokは検索を実行し、関連するテキストを読み込む。もし「@grok、この投稿を画像で説明してください」と言うと、Grokはリクエストを別のAuroraにルーティングします。Auroraについての詳細はこちらをご覧ください。

• 最初に問い合わせをするのはあなただ。
• エージェントはクエリを解釈し、クエリを処理するモデルを選択する。

2.ツールピッキング

タスクが特定のAIモデルに渡されると、そのモデルは与えられたタスクを完了するためのツールを選択する。棚を吊るす必要があれば、ハンマーと釘、あるいはドリルとネジを手にするだろう。

これらのツールは、検索エンジン、計算機、Pythonインタプリタなど、文字通り何でもあり得る。もしGrokがファクトチェックを依頼されたら、おそらく2つのツールを選ぶだろう。

• 検索エンジン：このモデルは検索を実行し、「信頼できる」結果を評価する。私はここでGrokの信頼できる結果を支持しているわけではない。
• 計算機：投稿が誇張されすぎたり、過小評価されすぎたりするような場合、おそらくCOVIDの統計であろうが、Grokは計算機を使って検索とユーザーの投稿の両方から数字を足すべきである。

3.サーバーハンドオフ

モデルがタスクを構造化し、ツールを選択したら、タスクを引き渡す必要がある。まず、検索エンジンに実行すべきクエリを指示する。数字がわかったら、計算機に一連の計算を送る。

ここでの「サーバー」という用語は緩く使われている。モデルとセットアップによっては、この “サーバー “はデータセンター内で稼働しているものかもしれないし、http://localhost:6000-or、他のポートで稼働しているものかもしれない。ポイントは単純である。ツールはジョブをリッスンし、モデルはそれらのジョブをツールに送信する。

• ツールはポートをリッスンする：このモデルは、ジョブを適切なツール “サーバー “に渡す。サーバーにHTTPリクエストを行い、応答を待つ。基本的に、Grokはサーバーに “1+1=? “を送信する。
• サーバーが応答を送る：サーバーは完了したジョブ・データで応答する。サーバーは「1+1=2」と言うかもしれない。Grokはその答えを受け取り、正しい文脈で使用することができます。

4.チェックポイント（オプションで人間もあり）

レスポンスをエージェントに送り返して出力させる前に、モデルの出力をチェックする必要がある。あなたは気づいていないかもしれませんが、バイアスや悪い出力は今日でもモデルに存在します。1+1=3 “や “1+1=ragebait “のような不正解を防ぐために、出力は1つ以上のチェックポイントを通過します。

タスクのコンテキストによっては、これらのチェックポイントは人間かもしれないし、同じジョブを実行しているモデルかもしれない。ここでのポイントは単純で、悪いアウトプットをユーザーに渡してはいけないということだ。

• チェックポイント：人間かモデルがタスクからの出力をダブルチェックする。これにより、間抜けで恥ずかしい出力がユーザーに届くのを防ぐことができる。
• 修正：同じモデルを使うかもしれないし、別のモデルにジョブを渡すかもしれない。
• 実際の出力：出力が確認されると、Grokは”@grok “を使用した人への返信としてそれを投稿する。

エージェント間プロトコル-脳間のコミュニケーション

MCPがエージェントの全体的な脳機能だとすれば、A2Aは複数の脳が互いに会話する方法である。現実の状況では、複数のエージェントがすでにお互いに会話しています。ChatGPTと会話しているところを想像してみてください。

あなたとChatGPTは猫について話しています。それは長文の会話で、あちこちに行きます。小さな猫、大きな猫、知的な猫…そして、あなたは自分の猫についてChatGPTに話すことにしました。あなたは自分の猫が世界征服を目指しているばかげた写真が欲しいのでしょう（猫はみんな心の底ではこれを望んでいるのですから）。

ChatGPT自身はイメージを作成できません。ChatGPTは、GrokがAuroraを使うように、DALL-Eにこれをファームアウトします。ChatGPTを実行しているエージェントは、タスクを達成するためにDALL-Eを実行しているエージェントと話します。

エージェントカードエージェントのREADME

エージェントカードは、あなたのAIエージェントが何ができるかを他の人に示すために使用されます。これは、どのようにAIエージェントに接続し、どのような出力を期待できるかを示すものです。ここでは、深入りする必要はありません。あなたのコードを通してユーザーを歩かせるのではなく、超基本的な使用例と期待される出力で説明するのだ。APIドキュメントを読んだことがある人なら、ここで何が適切で何が適切でないかわかるだろう。

• 接続：エージェントに安全に接続する方法を正確に示してください。REST API をデモしている場合、ローカルホスト上の HTTP ではなく、実際のドメインで HTTPS の例を使用してください。エージェントが SDK を介して管理されている場合、SDK を使用して接続する方法を示します。
• シンプルな使い方：REST APIの場合、これはかなり標準的なエンドポイントと出力です。SDKを使用する場合は、基本的なクラスとメソッドを示します。
• 出力例：各使用法のスニペットの下に、出力例を示す別のスニペットを表示する必要があります。

A2A アプリケーションを作成する場合、複数のエージェントを接続するためにエージェントカードを使用します。自分自身のエージェントを作成する場合、他の人はエージェントカードを介してエージェントを使用します。

自分がされたいように人と接する。

タスクシステム：タスクはどのように作られ、達成されるか

タスクシステムは基本的にシンプルなCRUD（Create, Read, Update, Delete）アプリです。ユーザーはタスクを作成できます。ユーザはそのステータスを読むことができなければなりません。ユーザとエージェントの両方がタスクを更新する必要があります。この場合、削除はむしろベストプラクティスの方法です-もし、増え続けるTodoアプリを作ったら、それは無駄です。

• 作成する：ユーザ（この場合は他のエージェント）は新しいタスクを作成できるはずです。ChatGPTのエージェントはDALL-Eに、世界を支配しようと決意した邪悪な猫が必要だと伝えます。
• 読む：ユーザ（または他のエージェント）はタスクのステータスを確認できる必要があります。ChatGPT が “Creating Image” と表示した場合、ステータスは “in progress” です。エージェントは常に与えられたタスクのステータスを読み、送信できる必要があります。
• 更新：ChatGPTに猫に蝶ネクタイをつけることを伝え忘れています。より良い写真を得るためにプロンプトを更新することができるはずです。さらに、DALL-EはChatGPTがそれを待っている間、タスクのステータスを更新する必要があります。
• 削除：企業はこの基本的な機能をますます無視し、効率性よりもデータレイクを重視している。エージェントはタスクを削除することができるはずだ。キャンセルされたタスクをそのままにしておくことは無意味なだけでなく、意味もなくストレージを浪費することになる。

セキュア・メッセージング

エージェント間のメッセージは安全である必要があります。一般的なコンピュータサイエンスに戻り、SSL と HTTPS 接続について考えてみましょう。HTTPS/SSL 経由でリクエストを送信すると、リクエスト本文は暗号化されます。サーバーだけがそれを読むことができます。サーバーがレスポンスを送信するとき、そのレスポンスは暗号化され、ブラウザだけが読むことができます。

エージェントはこれと同じ原則に従うべきである。複数のAIエージェント（完全に人間のタスクを代替する可能性が高い）を扱う場合、時には機密情報が関与する可能性がある。これらのエージェントも暗号化プロトコルを使用すべきである。

• 暗号化：エージェントが通信するときは、エンドツーエンドで暗号化されるべきである。メッセージを傍受する者は、ごちゃごちゃしたゴミしか見ることができないはずだ。
• 認証：デジタル署名のような適切な認証技術により、エージェントは誰と話しているかを知ることができる。特定のフィンガープリントに結びつけば、タスク情報は適切なアクセス権を持つ者に限定される。

長時間ジョブのサポート

すぐに終わらない仕事もある。数時間、あるいは数日かかることもある！このような場合、エージェントはコミュニケーションをとる必要があります。特に複数のエージェントが関わる仕事の場合、ユーザはエージェントからステータスのアップデートを受け取る必要があります。

• リアルタイム更新：エージェントはリアルタイムでステータスを更新する必要があります。これにより、ユーザーは自分の都合の良い時にステータスを確認することができます。
• 通知とEメール：エージェントは、ステータスの更新を段階的に送信する必要があります。タスクが完了したら、メールやプッシュ通知を送信しましょう。

エージェントは、ユーザーに迷惑をかけることなく、常に最新の情報を提供する必要があります。ユーザーは利便性を求めてA2Aを利用しています。

マルチモーダル・コミュニケーション

多くの場合、A2Aプロセスはマルチモーダルなタスクを扱う。ChatGPTとDALL-Eの例を思い出してください。ChatGPTは実際のテキストチャットを処理し、DALL-Eは画像作成を処理します。

• フリーテキストとロジック：自然言語処理を専門とするLLMが担当することが多い。
• 画像とビデオの生成：これらのタスクは、DALL-EやSoraのような他の専門モデルが担当する。

タスクはしばしばマルチモーダルなデータ形式を必要とする。このようなマルチモーダルなタスクに対応する場合、A2Aプロトコルは、これらのタスクを適切なモデル間で分割する必要がある。

各プロトコルはいつ使うべきか？

これらのプロトコルはそれぞれ異なるシナリオに対応するように作られている。MCPはエージェントの内部、つまり頭脳を扱う。A2Aは、複数のエージェントが互いに通信するために使われる。

結論将来は両方使うことになるだろう

MCPとA2Aは競合する規格ではなく、補完するシステムだ。MCPはエージェントの内部プロセスの総和である。A2Aはエージェント間のコミュニケーションを規定する。

• MCPによって、エージェントはインテリジェントに振る舞うことができます。
• A2Aは、インテリジェント・エージェント同士を対話させる。

独自のAIモデルをトレーニングする場合、Bright Dataは過去のデータを含むカスタムデータセットを提供し、エージェントが傾向を把握できるようにします。リアルタイムのデータが必要ですか？Scraper APIをご覧ください。エージェントが必要なときにいつでもデータを取得できます。エージェントブラウザを使用すると、エージェントは、プロキシ統合とCAPTCHA解決により、人間と同じようにウェブを閲覧することができます。