エージェント通信プロトコル（ACP）とは何ですか？

執筆者

Sandi Besen

AI Research Engineer and Ecosystem Lead

IBM

AI Engineer, Developer Advocate

IBM

エージェント通信プロトコル（ACP）は、エージェント間の通信を実現するオープン・スタンダードですこのプロトコルにより、分断された現在のエージェントのランドスケープを、統合と連携が容易になる相互運用可能なエージェント・システムへと変革できます。

IBMニュースレター

The DX Leaders

AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。登録の際はIBMプライバシー・ステートメントをご覧ください。

概要

IBMのBeeAIによって最初に導入されたACPを使用することで、AIエージェントはチーム、フレームワーク、テクノロジー、組織の枠を越えて自由に連携できます。これは、今日のAIエージェントの分断されたランドスケープを相互接続されたチームへと変えるユニバーサル・プロトコルであり、新たなレベルの相互運用性、再利用性、拡張性を実現するオープン・スタンダードです。ツールやデータへのアクセスを実現するオープン・スタンダードであるモデル・コンテキスト・プロトコル（MCP）に続く次のステップとして、ACP はエージェントの動作と通信方法を定義します。¹

補足として、AIエージェントとは、ユーザーや別のシステムに代わってタスクを自律的に実行するシステムまたはプログラムを指します。自身でワークフローを設計し、利用可能なツールを使って実行します。マルチエージェント・システムは、ユーザーまたは別のシステムに代わってタスクを実行するために協調して動作する複数のAIエージェントで構成されます。

オープンガバナンスを備えたAIエージェント通信標準であるACPにより、AIエージェントはさまざまなフレームワークやテクノロジースタック間で通信できるようになります。AIエージェントは、自然言語の形式でユーザーの問い合わせを受け取ったり、一連のアクションを実行したりするとき、通信プロトコルによりパフォーマンスが向上します。これらのプロトコルは、ツールや他のエージェント間、そして最終的にユーザーへ情報を中継します。

AIエージェント通信とは、人工知能エージェントが互いに、人間や外部システムと対話して情報を交換し、意思決定を行い、タスクを完了する方法を指します。この通信は、複数のAIエージェントが連携して動作するマルチエージェント・システムや、人間とAIの相互作用において、特に重要な役割を果たします。

ACPは、BeeAIを含む成長するエコシステムの一部です。以下は主な特徴の概要です。コアコンセプトと詳細については、公式ドキュメントをご覧ください。

異なるフレームワークのACPクライアントとACPエージェントが通信する例。

ACPの主要な機能

RESTベースの通信：ACPは通信に標準的なHTTP規則を採用しているため、本番環境への統合が容易です。一方、MCPはJSON-RPC形式を使用するため、はるかに複雑な通信方法が必要になります。
SDKは不要： ACPでは専用のライブラリを必要としません。cURL、Postman、さらにはブラウザーなどのツールを使用してインテリジェント・エージェントと対話できます。また、利便性を高めるため、SDKも用意されています。
オフライン検出：ACPエージェントは、配布パッケージにメタデータを直接埋め込むことができます。これにより、エージェントが非アクティブな状態でも検出が可能になります。また、リソースが動的に割り当てられ、常にオンラインであるとは限らないスケール・トゥ・ゼロ環境もサポートされます。
非同期優先、同期対応：ACPは非同期通信をデフォルトとして設計されています。この方法は、実行時間の長いタスクや複雑なタスクに最適です。同期リクエストもサポートされています。

注：ACPは、あらゆるエージェント・アーキテクチャーのオーケストレーションを可能にしますが、エージェント間のワークフロー、デプロイ、調整を管理するものではありません。代わりに、通信方法を標準化することで、多様なエージェント間のオーケストレーションを実現します。IBM Researchは、通信層としてACPを使用し、エージェントのオーケストレーション、デプロイ、共有を行うためのオープンソース・システム「BeeAI」を構築しました。

AIエージェント

AIエージェントの5つのタイプ：自律機能と実世界アプリケーション

目標主導型でユーティリティーベースのAIがワークフローや複雑な環境にどのように適応するかをご覧ください。

AIエージェントを構築、展開、監視

ACPが必要な理由

ACPを使用してさまざまなエージェント・アーキテクチャーが有効化。

エージェント型AIがの活用が進むにつれ、特定のベンダーに縛られることなく、ユースケースに応じて独立した各種テクノロジーから最適な成果を引き出すための判断や調整が、ますます複雑になっています。各フレームワーク、プラットフォーム、ツールキットには独自の利点がありますが、それらをすべて1つのエージェント型システムに統合するのは容易ではありません。

現在、ほとんどのエージェント・システムはサイロ化された状態で運用されています。これらのシステムは互換性のないフレームワーク上に構築され、カスタムAPIやエンドポイントを公開しています。また、通信用の共有プロトコルを持ちません。それらを接続するには、コストがかかるうえに脆弱で再利用が困難な統合が必要になります。

ACPは、断片化されたアドホックなエコシステムから、相互接続されたエージェントのネットワークへの根本的な転換を意味します。つまり、誰が構築したか、どのスタックで動作しているかに関係なく、各エージェントが他のエージェントを発見し、理解し、連携できるようになります。ACPを使用すると、開発者はさまざまなエージェントの集合知を利用して、単一のシステムだけでは実現できないより強力なワークフローを構築できます。

現在の課題

エージェントの能力が急速に進化しているにもかかわらず、実環境への統合は依然として大きなボトルネックとなっています。共通の通信プロトコルが存在しない場合、組織は繰り返し発生するいくつかの課題に直面します。

フレームワークの多様性：多くの組織では、LangChain、crewAI、AutoGen、あるいはカスタムスタックなど、さまざまなフレームワークを用いて構築された数百から数千のエージェントを運用しています。
カスタム統合：標準的なプロトコルが存在しない場合、開発者はエージェント同士のやり取りごとにカスタムコネクターを作成する必要があります。
指数的な開発負荷：エージェントが n 個ある場合、最大で n(n-1)/2 個の異なる統合ポイントが必要になる可能性があり、大規模なエージェント・エコシステムの維持を困難にします。
組織間連携における考慮事項：セキュリティ・モデル、認証システム、データ形式が組織ごとに異なるため、企業間の統合は複雑になります。

実際の例

エージェント間通信の実環境での必要性を示す例として、次の2つの組織を考えてみましょう。

1つ目は、自律型エージェントを活用して、社内の在庫状況や顧客の需要に基づいて生産スケジュールや受注処理を管理する製造会社です。
2つ目は、リアルタイムの配送見積もり、キャリアの空き状況、ルート最適化を提供するエージェントを運用する物流事業者です。

ACPを利用し、組織間で相互に通信を行う2つのエージェント（製造と物流）のユースケース例。

ここで、製造会社のシステムが顧客に見積もりを伝えるために、大規模なカスタム設備の注文の納期を見積もる必要があると想像してください。

ACPなし：このアプローチでは、メーカーの計画ソフトウェアと物流プロバイダーのAPIの間に専用の統合を構築する必要があります。これには認証処理、データ形式の不一致対応、サービスの可用性管理などを手動で行う必要があり、統合は費用がかかり、脆弱で、パートナーが増えるほど拡張が困難になります。

ACP使用時： 各組織は自社のエージェントにACPインターフェースを実装します。製造エージェントは注文内容と配送先の詳細を物流エージェントに送信し、物流エージェントはリアルタイムの配送オプションと到着予定時刻（ETA）を応答します。両システムは内部構造を公開したり、カスタム統合を作成したりすることなく、エージェント間の協調作業を実現します。ACPを導入することで、新たな物流パートナーの追加も容易になります。AIエージェントとACPを組み合わせた自動化により、データ交換の拡張性と効率化が実現します。

開始方法

シンプルさはACPの中核的な設計原則です。ACPでエージェントをラップする作業は、わずか数行のコードで完了します。PythonのSDKを使用すれば、関数にデコレーターを付けるだけでACP準拠のエージェントを定義できます。

この最小限の実装により、次のことが可能になります。

ACP サーバーインスタンスを作成する。
@server.agent() デコレーターを使用してエージェント関数を定義する。
大規模言語モデル（LLM）バックエンドと、コンテキスト永続化用のメモリを備えたLangChainフレームワークを使用してエージェントを実装する。
ACPのメッセージ形式とフレームワークのネイティブ形式の間の変換を行い、構造化された応答を返す。
サーバーを起動し、エージェントを HTTP 経由で利用できるようにする。

コード例：

from typing import Annotated
import os
from typing_extensions import TypedDict
from dotenv import load_dotenv
#ACP SDK
from acp_sdk.models import Message
from acp_sdk.models.models import MessagePart
from acp_sdk.server import RunYield, RunYieldResume, Server
from collections.abc import AsyncGenerator
#Langchain SDK
from langgraph.graph.message import add_messages
from langchain_anthropic import ChatAnthropic 

load_dotenv() 

class State(TypedDict):
    messages: Annotated[list, add_messages]

#Set up the AI model of your choice
llm = ChatAnthropic(model="claude-3-5-sonnet-latest", 
api_key=os.environ.get("ANTHROPIC_API_KEY")) 

#------ACP Requirement-------#
#START SERVER
server = Server()
#WRAP AGENT IN DECORACTOR
@server.agent()
async def chatbot(messages: list[Message])-> AsyncGenerator[RunYield, RunYieldResume]:
    "A simple chatbot enabled with memory"
    #formats ACP Message format to be compatible with what langchain expects
    query = " ".join(
        part.content
        for m in messages
        for part in m.parts             
    )
    #invokes llm
    llm_response = llm.invoke(query)    
    #formats langchain response to ACP compatible output
    assistant_message = Message(parts=[MessagePart(content=llm_response.content)])
    # Yield so add_messages merges it into state
    yield {"messages": [assistant_message]}  

server.run()
#---------------------------#

これで、完全にACPに準拠したエージェントが作成されました。このエージェントは、次のことが可能です。

他のエージェント（オンライン・オフライン問わず）から検出される。
同期的または非同期的にリクエストを処理する。
標準的なメッセージ形式で通信する。
他のACP対応システムと統合する

ACPとMCPおよびA2Aの比較

進化を続けるAIエコシステムにおけるACPの役割をより深く理解するには、他の新しいプロトコルと比較してみるとよいでしょう。こうしたプロトコルは、必ずしも競合するものではありません。それぞれがAIシステム統合スタックの異なるレイヤーを担っており、相互に補完し合うことも多くあります。

概要

モデル・コンテキスト・プロトコル（MCP）： ツール、メモリ、リソースを活用して単一モデルのコンテキストを拡張するために設計されています。Anthropicによって導入されました。
フォーカス：1つのモデル、多数のツール

エージェント通信プロトコル（ACP）： システムや組織をまたいで動作する独立したエージェント間の通信のために設計されています。IBMのBeeAIによって導入されました。
フォーカス：多数のエージェント、ピアとして安全に連携、ベンダー・ロックインなし、オープンなガバナンス

Agent2Agentプロトコル（A2A） ：システムや組織をまたいで動作する独立したエージェント間の通信のために設計されています。Google によって導入されました。

フォーカス：多数のエージェントがピアとして連携し、Googleのエコシステム向けに最適化されている

ACPとMCP

ACP チームは当初、モデル・コンテキスト・プロトコル（MCP）の活用を検討していました。モデルとコンテキストの相互作用に関して優れた基盤を提供していたためです。しかしすぐに、真のエージェント間通信には適さないアーキテクチャ上の制約があることが判明しました。

マルチエージェントシステムにおけるMCPの限界：

ストリーミング： MCPは、基本的なストリーミング（完全なメッセージである可能性が高い）をサポートしていますが、更新が発生するとすぐに送信される、よりきめ細かな「デルタ」スタイルのストリーミングには対応していません。トークンや軌道の更新などのデルタ・ストリームは、完全なデータ・ペイロードではなく増分更新で構成されるストリームです。この制限は、MCPが設計された当初、エージェント・スタイルのインタラクションを想定していなかったことに起因しています。

メモリ共有：MCPは、複数のエージェントをサーバー間で実行しながら共有メモリを維持する機能をサポートしていません。ACPもこの機能をまだ完全にはサポートしていませんが、現在活発に開発が進められています。

メッセージ構造：MCPは任意のJSONスキーマを受け付けますが、メッセージ本体の構造を定義していません。この柔軟性により、多様なメッセージ形式を解釈しなければならないエージェントの構築において、相互運用性の確保が困難になります。

プロトコルの複雑さ： MCPはJSON-RPCを採用しており、特定のSDKやランタイムが必要です。一方で、ACP は非同期・同期処理をネイティブでサポートする REST ベースの設計により、軽量で統合しやすくなっています。

MCPを、人が計算機や参考書などの優れたツールを使って自分の能力を高めるようなものと考えることができます。対照的に、ACPは、個々の人（エージェント）がチームとして協力しながら、AIアプリケーション内でそれぞれの機能を発揮できるようにすることを目的としています。ACPとMCPは互いに補完し合うことができます。

Google によってACPの直後に導入されたAgent2Agentプロトコル（A2A）も、AIエージェント間の通信を標準化することを目的としています。いずれのプロトコルもマルチエージェント・システムの実現を目指している点では共通していますが、その設計思想やガバナンスには違いがあります。

主な違い：

ACPは意図的に次のように設計されています。

一般的なHTTPツールとREST規則を使用することで簡単に統合できる。
幅広いエージェントタイプとワークロードに柔軟に対応する。
オープンなガバナンスと幅広いエコシステム連携により、ベンダーニュートラルな設計。

両方のプロトコルは共存可能。それぞれが環境に応じて異なるニーズに対応します。ACPは軽量で、オープンで拡張可能な設計になっているため、分散型システムや、組織的な境界を越えた現実世界の相互運用性に適しています。A2Aは自然な統合のため、Googleエコシステムを使用しているユーザーにとってより適した選択肢となる可能性があります。