【徹底解説】MCPの上位互換？AIエージェントの新標準「ACP」とは？仕組みから使い方まで

目　次

【徹底解説】MCPの上位互換？AIエージェントの新標準「ACP」とは？仕組みから使い方までのPodcast
ストーリーブック
導入：AIエージェントの「バベルの塔」問題と協調の時代の幕明け
ACPとは何か？AIエージェントのための「世界共通語」
ACP vs. MCP：単なる上位互換ではない、補完し合う関係性の解明
ACPの心臓部：技術アーキテクチャを解剖する
初心者でも分かる！ACPを支える5つの主要機能
実践ガイド：初めてのACP準拠エージェントを構築する
広がるエコシステム：他のプロトコルの中でのACPの位置付け
未来は協調する：ACPが拓くユースケースと今後の展望
結論：孤立したツールから、相互接続されたエージェント社会へ
参考資料

【徹底解説】MCPの上位互換？AIエージェントの新標準「ACP」とは？仕組みから使い方までのPodcast

下記のPodcastは、Geminiで作成しました。

ストーリーブック

導入：AIエージェントの「バベルの塔」問題と協調の時代の幕明け

AIエージェント技術は、自律的にタスクを計画し実行する能力によって、多くの産業に変革をもたらす可能性を秘めています。しかし、その発展の裏側で、深刻な「断片化」という課題が浮上しています。LangChain、CrewAI、AutoGenといった多様なフレームワーク上で開発されたエージェントたちは、それぞれが独自の言語と思考様式を持つ「サイロ」の中に孤立しており、互いにコミュニケーションを取ることができません。

この状況は、旧約聖書に登場する「バベルの塔」を彷彿とさせます。塔の建設者たちが異なる言語を話し始めたことで協力できなくなったように、現代のAIエージェントも相互運用性の欠如により、そのポテンシャルを最大限に発揮できずにいます。開発者はエージェントを連携させるたびに、一点もののカスタム統合を強いられ、多大な労力と時間を浪費しています。この非効率なM×N問題（M個のエージェントとN個のツールを連携させるのにM×N通りの実装が必要になる問題）は、単なる技術的な不便さを超え、AI分野全体のイノベーションを阻害する根本的なボトルネックとなっています。開発者が本来注力すべき高度な知能や協調ロジックの設計ではなく、低レベルな「配管工事」に追われているのが現状です。

この課題を解決し、AIエージェントたちが協調してより複雑で高度なタスクを遂行する新時代を切り拓くために、「Agent Communication Protocol (ACP)」が提唱されました。ACPは、エージェント間のコミュニケーションにおける「HTTP」のような普遍的な標準となることを目指しており、断片化したエコシステムを相互接続されたネットワークへと変革する可能性を秘めています。

ACPとは何か？AIエージェントのための「世界共通語」

Agent Communication Protocol (ACP)は、AIエージェントが使用するフレームワーク、プログラミング言語、実行環境に関わらず、シームレスな通信を可能にするために設計されたオープンスタンダードです。IBMのBeeAIプロジェクトから生まれ、現在は中立的な非営利団体であるLinux Foundationの管理下で、オープンなガバナンスと透明性を確保しながら開発が進められています。

ACPの核心は、ベンダーニュートラルな思想にあります。特定の企業やプラットフォームへのロックインを避け、AIエコシステム全体の公共財として機能することを目指しています。この目的を達成するため、ACPは特定のフレームワークに依存しない、軽量で導入しやすいRESTful APIとして標準化されています。

このオープンなガバナンスモデルは、ACPが広く受け入れられるための戦略的な基盤です。競合するフレームワークや企業は、特定の競合他社が管理するプロトコルよりも、Linux Foundationのような中立的な組織が監督する標準を採用する可能性がはるかに高くなります。この中立性こそが、ACPが乱立する標準の中から抜け出し、真に普遍的な「世界共通語」となるための鍵となります。

そのリファレンス実装（主要な実装例）としてBeeAIプラットフォームがあり、開発者はACPに準拠したエージェントを発見、テスト、デプロイ、共有することができます。

ACP vs. MCP：単なる上位互換ではない、補完し合う関係性の解明

ACPを「MCP (Model Context Protocol) の上位互換」と捉える見方がありますが、これは初期の経緯から生じた誤解です。両者は解決しようとする課題が異なり、互いに補完し合う関係にあります。

MCPは、Anthropic社によって提唱され、「単一のエージェント」が外部のツールやデータソースといった「コンテキスト」にアクセスするための標準です。これは、エージェントに高性能な計算機や専門書を与えるようなもので、「個」の能力を強化することに主眼を置いています。そのアーキテクチャは、エージェントがツールを「包含」するような関係性であり、USB-Cポートのように様々な周辺機器（ツール）を接続するための統一規格と例えられます。

一方、ACPは「複数のエージェント間」でのコミュニケーション、つまり「協調」を目的としています。これは、異なる専門性を持つ人々がチームを組み、対話を通じて共同作業を進めることに似ています。ACPは、エージェント同士がメッセージを送り合う「メッセージパッシング」のモデルを採用しています。

この混乱の一因は、ACPの初期バージョンがMCPを拡張し、同じJSON-RPC形式を採用していたことにあります。しかし、ACPはその後、よりウェブとの親和性が高く、汎用的なツールで扱いやすいRESTベースのアーキテクチャへと大きく舵を切りました。このRESTへの移行は、特定のライブラリを必要とせず、より多くの開発者が容易に参加できるオープンなエコシステムを構築するための意図的な設計判断でした。これにより、ACPはツール呼び出しプロトコルの延長線上から、真に普遍的なコミュニケーションプロトコルへと進化を遂げたのです。

以下の表は、両プロトコルの違いを明確に示しています。

表1: MCPとACPの目的と設計思想の比較

項目	MCP (Model Context Protocol)	ACP (Agent Communication Protocol)
主な目的	単一エージェントへのコンテキスト提供（ツール・データ連携）	複数エージェント間の協調・対話
対話モデル	エージェント ↔ ツール/データソース	エージェント ↔ エージェント
通信方式	JSON-RPC	REST (HTTP)
典型的なユースケース	エージェントがデータベースを検索する、APIを呼び出す	調査エージェントが要約エージェントに結果を渡し、レポートを作成させる
例えるなら	AIのための「USB-Cポート」	AIチームのための「Slack」や「共通言語」

このように、MCPがエージェントの「能力」を拡張するのに対し、ACPはエージェントたちが「チーム」として機能するための基盤を提供します。両者は競合するのではなく、組み合わせて使用することで、より高度なAIシステムを構築することが可能です。例えば、MCPを使って各エージェントが専門ツールにアクセスし、ACPを使ってその結果を共有・統合するといった連携が考えられます。

ACPの心臓部：技術アーキテクチャを解剖する

ACPは、シンプルかつ堅牢なクライアントサーバーアーキテクチャを採用しています。

ACPサーバー: 1つまたは複数のAIエージェントをホストし、外部からのリクエストを受け付ける役割を担います。サーバーは、各エージェントを標準化されたRESTインターフェースを通じて公開します。
ACPクライアント: 別のエージェントやアプリケーション、あるいは人間が、ACPサーバー上のエージェントと対話するために使用します。クライアントは、標準的なHTTPリクエストを送信することでエージェントの機能を呼び出します。

このアーキテクチャの中心となるのが、以下の3つのコアコンセプトです。

エージェントマニフェスト (Agent Manifest)

エージェントマニフェストは、エージェントの「身分証明書」や「能力仕様書」に相当するJSON形式のデータです。これには、エージェントの名前、説明、処理可能な入力/出力のデータ形式（MIMEタイプ）、ライセンス、作成者情報といったメタデータが含まれます。

このマニフェストは、単なるメタデータ以上の重要な役割を果たします。それは、エージェントの「インターフェース」とその「実装」を完全に分離することです。これにより、他のエージェントや開発者は、そのエージェントが内部的にどのようなフレームワークやロジックで構築されているかを知ることなく、マニフェストを読むだけで「何ができるか」を理解し、連携を決定できます。この仕組みが、後述するオフラインでのエージェント発見や、柔軟なエージェントの入れ替え（コンポーザビリティ）を実現する技術的な基盤となっています。

メッセージ構造 (Message & MessagePart)

ACPにおける通信の基本単位は「メッセージ (Message)」です。メッセージは、一連の「メッセージパート (MessagePart)」で構成され、これによりテキスト、画像、コード、JSONデータといった多様な形式の情報を組み合わせた「マルチモーダル」なコミュニケーションが可能になります。

Message: コミュニケーションの完全な一単位を表します。誰からのメッセージかを示すrole（例: user, agent/echo）と、複数のMessagePartのリスト（parts）を持ちます。
MessagePart: メッセージの個々の構成要素です。実際の情報を含むcontent、その情報の種類を示すcontent_type（例: text/plain, image/png）などのフィールドを持ちます。

この構造化されたメッセージ形式により、エージェントは複雑な情報を曖昧さなく交換することができます。

実行 (Run) とセッション (Session)

Run: 特定の入力に対するエージェントの単一の実行プロセスを指します。各Runは一意のIDを持ち、その状態（実行中、完了、エラーなど）を追跡できます。
Session: 複数のRunをまたいで状態や対話履歴を維持するための仕組みです。これにより、エージェントは長期的な文脈を記憶し、より人間らしい対話を実現できます。

初心者でも分かる！ACPを支える5つの主要機能

ACPのアーキテクチャは、以下の5つの強力な機能によって支えられています。

RESTベースの通信 (REST-based Communication) ACPは、ウェブで広く使われているRESTの原則と標準的なHTTPメソッド（POST, GETなど）に基づいています。これにより、特別なライブラリやツールを必要とせず、多くの開発者が慣れ親しんだ方法で簡単にエージェントと対話できます。
非同期・同期待ち受け (Async-first, Sync Supported) ACPは、デフォルトで非同期通信をサポートするように設計されています。これは、完了までに数分あるいは数時間かかるような複雑な調査や分析タスクに最適です。もちろん、チャットボットのような即時応答が求められるユースケースのために、同期通信もサポートしています。
マルチモーダル対応 (Multimodal Message Support) メッセージパートの仕組みにより、テキストだけでなく、画像、音声、動画、PDFファイル、構造化データなど、あらゆる種類のデータを送受信できます。これにより、例えば「この製品画像に関するレポートを作成して」といった、よりリッチで複雑なワークフローが実現可能になります。
SDK不要なアーキテクチャ (SDK-Optional Architecture) ACPの大きな特徴は、SDKが必須ではない点です。
curlのような基本的なコマンドラインツールや、Postman、あるいはウェブブラウザからでも直接エージェントを呼び出せます。これにより、プロトタイプの作成や異なるシステムとの統合が非常に容易になります。もちろん、より効率的な開発のためにPythonやTypeScriptの公式SDKも提供されています。
オフラインでのエージェント発見 (Offline Discovery) これはACPの最も革新的な機能の一つです。エージェントマニフェストをコンテナイメージのラベルなどの配布パッケージに直接埋め込むことで、エージェントが実際に起動していなくても、その存在と能力を発見できます。この仕組みは、リソースを動的に割り当てる「スケール・トゥ・ゼロ」環境に最適です。例えば、企業は何千もの専門エージェントをカタログに登録しておき、特定のタスクが必要になった瞬間にのみ該当するエージェントを起動して利用するといった、非常にコスト効率の高い運用が可能になります。

実践ガイド：初めてのACP準拠エージェントを構築する

理論を学んだところで、実際に簡単なACP準拠エージェントを作成してみましょう。ここでは、受け取ったメッセージをそのまま返す「Echo Agent」をPythonで構築します。

ステップ1: 環境のセットアップ

まず、プロジェクト用のディレクトリを作成し、Pythonパッケージマネージャーuvを使って仮想環境を初期化します。

Bash
uv init --python '>=3.11' my_acp_project
cd my_acp_project

次に、ACPのPython SDKをインストールします。

Bash
uv add acp-sdk

ステップ2: エージェントの作成

agent.pyという名前のファイルを作成し、以下のコードを記述します。

Python
import asyncio
from collections.abc import AsyncGenerator
from acp_sdk.models import Message
from acp_sdk.server import Context, RunYield, RunYieldResume, Server

# ACPサーバーのインスタンスを作成
server = Server()

# @server.agent() デコレータで関数をエージェントとして登録
@server.agent()
async def echo(
    input: list[Message],
    context: Context
) -> AsyncGenerator:
    """Echoes everything"""
    for message in input:
        await asyncio.sleep(0.5)
        # エージェントの思考プロセスをyieldで返すことができる
        yield {"thought": "I should echo everything"}
        await asyncio.sleep(0.5)
        # 受け取ったメッセージをそのまま返す
        yield message

# サーバーを起動
server.run()
このコードの核心は@server.agent()デコレータです。この一行を追加するだけで、echoという非同期関数が、ACPの仕様に準拠したREST APIエンドポイントを持つエージェントとして公開されます。HTTPリクエストの解析やレスポンスの整形といった複雑な処理はすべてSDKが裏側で担ってくれるため、開発者はエージェントのコアロジックに集中できます。これは、既存の機能を驚くほど簡単にACPエコシステムに統合できることを意味します。

ステップ3: サーバーの起動と確認

ターミナルで以下のコマンドを実行し、ACPサーバーを起動します。

Bash
uv run agent.py

サーバーがhttp://localhost:8000で起動します。別のターミナルを開き、curlコマンドでエージェントが利用可能か確認します。

Bash
curl http://localhost:8000/agents

以下のようなJSONレスポンスが返ってくれば成功です。

JSON
{
  "agents": [
    {
      "name": "echo",
      "description": "Echoes everything",
      "metadata": {}
    }
  ]
}

ステップ4: エージェントの実行

最後に、curlを使ってエージェントにメッセージを送り、実行してみましょう。

Bash
curl -X POST http://localhost:8000/runs \
-H "Content-Type: application/json" \
-d '{
  "agent_name": "echo",
  "input": [
    {
      "role": "user",
      "parts": [
        {
          "content": "Howdy!",
          "content_type": "text/plain"
        }
      ]
    }
  ]
}'

レスポンスとして、送ったメッセージがoutputに含まれて返ってきます。

JSON
{
  "run_id": "...",
  "agent_name": "echo",
  "status": "completed",
  "output": [
    {
      "role": "agent/echo",
      "parts": [
        {
          "content_type": "text/plain",
          "content": "Howdy!"
        }
      ]
    }
  ],
 ...
}

これで、最初のACP準拠エージェントの構築と実行が完了しました。

広がるエコシステム：他のプロトコルの中でのACPの位置付け

ACPはAIエージェント通信プロトコルのエコシステムにおける唯一の存在ではありません。Googleが主導する「A2A (Agent-to-Agent)」や、より分散型を目指す「ANP (Agent Network Protocol)」など、複数の標準化の動きが同時に進行しています。これらのプロトコルとの比較を通じて、ACPの立ち位置をより明確に理解することができます。

表2: 主要なAIエージェント通信プロトコルの比較

項目	ACP (IBM/BeeAI)	A2A (Google)	ANP
主な焦点	ローカル/企業内での協調、実装の容易さ	プラットフォーム横断での相互運用性	オープンなWeb上での分散型協調
アーキテクチャ	クライアントサーバー（ローカルファースト）	クライアントサーバー（クラウド指向）	P2P（分散型）
通信方式	REST/HTTP	JSON-RPC, gRPC, REST	HTTP, JSON-LD
発見メカニズム	マニフェスト（オフライン対応）	エージェントカード（オンライン）	DID, JSON-LDグラフ（分散型）
理想的なユースケース	企業内の自動化、エッジコンピューティング、IoT	複数ベンダーのサービスを連携させるワークフロー	分散型AIマーケットプレイス、トラストが不要なP2P連携

ACP vs. A2A: ACPが軽量なREST APIを採用し、企業内やローカル環境での迅速な連携を重視するのに対し、A2Aはより厳密な仕様（エージェントカード）を持ち、異なる企業やプラットフォーム間の大規模な連携を視野に入れています。
ACP vs. ANP: ANPは最も野心的なプロトコルで、W3Cの分散型ID（DID）などを活用し、中央集権的な管理者を必要としないオープンな「エージェントのインターネット」の構築を目指しています。これに対し、ACPはより現実的で、管理された企業環境内での統制とセキュリティを重視したアプローチを取ります。

将来的には、これらのプロトコルが階層的に組み合わさって利用される可能性があります。例えば、個々のエージェントはMCPでツールにアクセスし、企業内のエージェントチームはACPで密に連携し、外部組織のエージェントとはA2AやANPを通じて協調するといった、複合的なアーキテクチャが考えられます。

未来は協調する：ACPが拓くユースケースと今後の展望

ACPのような標準化された通信プロトコルは、これまでは不可能だった、あるいは非現実的だった高度なマルチエージェントシステムの構築を可能にします。

専門家チームによる協調作業: 調査担当エージェント、データ可視化エージェント、財務モデリングエージェントがACPを通じてリアルタイムに連携し、一つの総合的な市場分析レポートを自動生成する。
クロスドメイン・ワークフローの自動化: 製造業の在庫管理エージェントが、物流企業の輸送最適化エージェントにACPで発注データと配送先を送信し、リアルタイムで最適な輸送オプションと到着予定時刻を取得する。
柔軟なエージェントの交換とアップグレード: システム全体を停止・再設計することなく、特定のタスクを担当するエージェントを、より高性能な新しいモデルにシームレスに入れ替える。

これらのユースケースに共通するのは、AI開発のパラダイムシフトです。ACPは、一つの巨大な万能エージェントを開発する「モノリシック」なアプローチから、特定の機能に特化した小型で再利用可能な「マイクロエージェント」を組み合わせてシステムを構築する「マイクロサービス」的なアプローチへの移行を促進します。これは、ソフトウェア工学の世界で実証されてきたモジュール性、スケーラビリティ、保守性の向上といった恩恵を、AIエージェント開発の世界にもたらすものです。

結論：孤立したツールから、相互接続されたエージェント社会へ

AIエージェント開発は、個々のエージェントがサイロの中で孤立する「断片化の時代」から、相互に連携し合う「協調の時代」へと移行しつつあります。Agent Communication Protocol (ACP)は、この移行を加速させるための極めて重要な基盤技術です。

ACPは、MCPの単なる上位互換ではなく、異なる目的を持つ補完的なプロトコルです。RESTベースのシンプルな設計、SDK不要の導入しやすさ、そしてオフライン発見というユニークな機能により、開発者が直面する相互運用性の障壁を劇的に低減させます。

このプロトコルがもたらすのは、単なる技術的な利便性だけではありません。それは、AIエージェントを個別の「ツール」から、協調して価値を創造する「社会」へと昇華させるための道筋です。ACPのような標準化された「共通言語」が普及することで、開発者は低レベルな接続の問題から解放され、より高度な知能の探求に集中できるようになります。ACPは、次世代の真にインテリジェントで協調的なAIシステムの構築に不可欠な、まさに「配管」となるプロトコルなのです。