使いたいエージェントがそのエディタに対応していない。逆に、気に入ったエディタに移りたいのに、慣れたエージェントがそこでは動かない。AIコーディングエージェントが増えるほど、この「組み合わせ」の問題は面倒になっていきます。エージェント側は対応エディタごとに拡張機能を書き、エディタ側はエージェントごとに接続コードを書く。どちらにとっても本質的でない作業です。
Agent Client Protocol（ACP）は、この接続部分そのものを規格にしてしまおうという試みです。エディタとエージェントの会話の仕方を決めておけば、あとはどちらも「ACPを喋る」だけで組み合わせが成立します。かつてLanguage Server Protocol（LSP）が、エディタと言語サーバーの掛け算をやめさせたのと同じ発想です。
本記事では、ACPが具体的に何を決めているのか、MCPとはどう役割が違うのか、そして今の実装状況で本当に使えるのかを、公式ドキュメントとリポジトリの記述をもとに整理します（公式サイト: https://agentclientprotocol.com ）。
- この記事でわかること：ACPが標準化している範囲と、LSPになぞらえられる理由。
- JSON-RPCベースの通信モデルと、ファイルやターミナルの鍵をエディタ側が握る設計の意図。
- MCPとの違い。競合ではなく、担当している区間が違うということ。
- ACPレジストリを使った導入手順と、v1／v2の状況・ガバナンスなど導入前の判断材料。
ACPとは？エディタとエージェントの通信を標準化するオープンな規格
ACPは、コードエディタやIDEと、コーディングエージェントのあいだの通信を標準化するプロトコルです。公式ドキュメントは目的を「ACPはコードエディタ／IDEとコーディングエージェント間の通信を標準化し、ローカルとリモートの双方のシナリオに適している」と説明しています。リポジトリの一文はもっと端的で、「あらゆるエディタをあらゆるエージェントにつなぐためのプロトコル」。ライセンスはApache License 2.0で、GitHubで公開されています（リポジトリ: https://github.com/agentclientprotocol/agent-client-protocol ）。2026年8月時点で4千を超えるスターが付いています。
出発点は2025年8月27日、Zed IndustriesのNathan Sobo氏による発表でした。当初の狙いは「エディタを乗り換えずに複数のエージェントを切り替えられるようにすること」で、最初の実装対象はGoogleのGemini CLI、翌9月3日にClaude Codeのベータ対応が加わっています。
引き合いに出されるのは常にLSPです。LSPが登場する前、言語サポートはエディタごとに書き直されていました。ACPが解こうとしているのも同じ形の問題で、違うのは掛け合わされるものが「言語」ではなく「エージェント」だという点です。JetBrainsは自社ブログで、ACPを「IDEやエディタがコーディングエージェントと直接会話するための、オープンで中立な方法」と表現し、「エージェントは1つのIDEやクラウドに閉じ込められるべきではない」と述べています。
運営体制も押さえておく価値があります。ACPは現在、ZedとJetBrainsの共同ガバナンスで運営されており、リードメンテナはZedのBen Brandt氏とJetBrainsのSergey Ignatov氏の2名です。仕様変更はRFD（Request for Discussion）というプロセスを経て、コアメンテナが隔週の会議で議論・投票します。ただし公式のガバナンス文書は、この体制をあくまで暫定（interim）と位置づけ、独立した財団への移行に向けて動いていると明記しています。
仕組み：JSON-RPCで会話し、環境の鍵はエディタが握る
通信にはJSON-RPC 2.0を使い、メッセージはMethods（応答を伴う要求）とNotifications（一方向の通知）の2種類だけです。ローカル構成では、エディタがエージェントをサブプロセスとして起動し、標準入出力でやり取りします。リモート構成はHTTPやWebSocketが想定されていますが、公式ドキュメントは「リモートエージェントの完全なサポートは進行中」と明記しており、現時点ではローカル前提で考えるのが安全です。
やり取りは3つの段階に分かれます。まずinitializeで接続を確立し、ここでプロトコルバージョンとcapability（対応機能）を交換します。次にsession/newでセッションを作り、最後にsession/promptでプロンプトターンが始まります。capabilityの扱いには明確なルールがあり、initializeリクエストで省略された機能は、すべて未対応として扱わなければならない（MUST）と定められています。新しい機能の追加が破壊的変更にならないのはこのためです。
プロンプトターンの中では、エージェントがsession/update通知で進捗を流し続けます。作業計画、agent_message_chunkとしてのテキスト応答、tool_callの状態変化などです。ツールを実行する前には、session/request_permissionでクライアント側に承認を求めることができます。ターンはStopReason（end_turn、max_tokens、max_turn_requests、refusal、cancelled）を返して終わり、ユーザーが途中で止めたい場合はsession/cancelを送ります。
設計として面白いのは、ファイルとターミナルの扱いです。エージェントは自分でファイルを読み書きせず、fs/read_text_fileとfs/write_text_fileでクライアントに依頼します。理由は明快で、こうすればディスクにまだ書かれていない編集中のバッファの内容まで読めるからです。ターミナルも同様に、terminal/createで起動を依頼し、terminal/outputやterminal/wait_for_exitで結果を受け取ります。つまりACPでは、環境に触れる鍵はエディタ側が握っています。
細かい規約もいくつか決まっています。プロトコル上のファイルパスはすべて絶対パスでなければならず、行番号は1始まり。ユーザーに見せるテキストの既定フォーマットはMarkdownで、これは「エディタ側にHTMLをレンダリングできることを要求せずに、十分な表現力を持たせるため」と説明されています。
| 場面 | 主なメソッド | どちらが呼ぶか |
|---|---|---|
| 接続とバージョン／機能の交渉 | initialize、authenticate | クライアント → エージェント |
| セッションの作成・読み込み | session/new、session/load | クライアント → エージェント |
| プロンプトの送信と進捗の受信 | session/prompt、session/update | 双方向 |
| ツール実行前の承認 | session/request_permission | エージェント → クライアント |
| ファイルの読み書き（未保存分を含む） | fs/read_text_file、fs/write_text_file | エージェント → クライアント |
| コマンド実行と出力の取得 | terminal/create、terminal/output、terminal/wait_for_exit | エージェント → クライアント |
MCPとの違い：競合ではなく、担当する区間が違う
ACPの説明でいちばん混同されやすいのがMCP（Model Context Protocol）との関係です。両者は競合していません。MCPがつなぐのはエージェントと外部のツールやデータソース、ACPがつなぐのはエディタとエージェントです。同じ図の中の、別の辺を担当していると考えると整理しやすくなります。
実装レベルでも、ACPはMCPを敵視していません。公式ドキュメントは「可能な限りMCPで使われているJSON表現を再利用しつつ、差分表示のようなエージェント的コーディング体験に有用な独自の型を含めている」と述べています。ゼロから型を定義し直すのではなく、既存の語彙を借りているわけです。
運用上の連携も設計に組み込まれています。エディタはプロンプトを送るときにMCPサーバーの設定をエージェントへ渡し、エージェントはそのMCPサーバーへ直接つなぎます。エディタ自身が持つツールをエージェントに使わせたい場合は、エディタが自分自身をMCPサーバーとして設定に含めればよく、エディタ側が2つのプロトコルを同時に喋る必要はありません。標準入出力経由のMCPにしか対応していないエージェント向けには、エディタが小さなプロキシを立てて、リクエストを自分自身へトンネルする方法が案内されています。
境界そのものも動いています。RFDには「MCP-over-ACP」という提案が上がっており、両プロトコルの重なり方は今も議論の途中です。今の時点では「エディタとの接続はACP、外部ツールとの接続はMCP」と押さえておけば実務上は困りません。
導入：ACPレジストリからエージェントを入れる
規格ができても、エージェントを配る仕組みがなければ結局はエディタごとの拡張機能に逆戻りします。そこで2026年1月28日、ZedがACPレジストリを発表しました。エージェント作者が一度登録すれば、すべてのACP対応クライアントから利用できるようになる仕組みで、公式ドキュメントは「ACP対応エージェントを見つけて導入するいちばん簡単な方法」と位置づけています。
収録には条件があります。掲載されるのは「認証をサポートするエージェントのみ」で、実際にACPのハンドシェイクで有効なauthMethodsを返すかどうかがCIで検証されます。クライアント側は https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json を取得するだけで、全エージェントのメタデータと配布情報が手に入ります。配布形式はバイナリ、npx、uvxの3種類で、バージョンは毎時実行されるcronがnpm・PyPI・GitHubリリースを見て自動更新します。
利用側の手順はエディタによりますが、Zedの場合はコマンドパレットで zed: acp registry を実行するか、Agent Settings の External Agents から Add Agent → Install from Registry を選ぶだけです。既定で並ぶ顔ぶれには Claude、Codex、OpenCode、Copilot、Cursor、Gemini CLI などが含まれます。レジストリに載っていないエージェントを使いたい場合は、設定ファイルの agent_servers にコマンドと引数を書いてカスタム登録できます。
対応クライアントの温度差は把握しておくべきです。公式ドキュメントが公式実装として挙げているのはZed、JetBrains IDE、Qt Creatorで、Visual Studio Code、Neovim、Emacs、Obsidian、Visual Studio、Unity、Chromeなどはコミュニティ製のプラグインによる対応です。同じ「ACP対応」でも、保守体制や実装の網羅度は同じではありません。
- クライアントとして使う：エディタのレジストリ機能からエージェントを選んで導入する（Zedなら zed: acp registry ）。
- レジストリ外のエージェントを使う：設定の agent_servers に type / command / args / env を書いて登録する。
- 自作エージェントを載せる：registryリポジトリをフォークし、agent.json（と任意でSVGアイコン）を置いてプルリクエストを送る。
- 自作クライアントを書く：Rust、TypeScript、Python、Java、Kotlinの公式SDKが用意されている。
- スキーマを参照する：GitHubの最新リリースからschema.jsonを直接ダウンロードできる。
導入前に確認すべき制約
まず押さえるべきは、プロトコルが今まさに動いている最中だという点です。安定版はバージョン1ですが、2026年7月20日にv2のドラフトが公開されました。公式アナウンスは「v2はドラフトである。さまざまな部分が安定化前に変わりうるし、実際に変わる」と明言し、実装はバージョンネゴシエーションとフィーチャーフラグの両方で囲ったうえで、本番環境の既定にはしないよう求めています。v1のみに対応したピアがしばらく残るため、当面は両バージョンへの対応が推奨されています。
v2の変更内容も、単なる小改訂ではありません。ユーザー起点のターンに閉じていたsession/update通知をセッション中いつでも送れるようにし、メッセージやツール呼び出し、ターミナル出力を安定IDによる一様なパッチ適用へ統一し、ファイル差分の表現をoldText／newTextの組から add・delete・modify・move・copy という操作ベースへ置き換えます。権限要求にもtitleが必須になります。ACPクライアントやエージェントを自作するなら、この移行コストは見込んでおく必要があります。
セキュリティ面の前提も明示されています。ACPの設計ではエディタがエージェントにローカルファイルとMCPサーバーへのアクセスを与えるため、公式のアーキテクチャ文書は「ACPは、信頼できるモデルとコードエディタ越しに話す場面で機能する」と、信頼できる相手であることを前提条件として書いています。実質的な防御線はツール呼び出しごとの承認（session/request_permission）なので、承認をすべて自動許可する運用にすると、この前提が崩れます。
- プロトコルv2はドラフト段階。安定化前に仕様が変わるため、本番既定にはしない。
- リモートエージェントの完全対応は進行中。現状はローカルのサブプロセス構成が前提。
- 機能はcapabilityベース。ファイル読み書きやターミナルに未対応のクライアントでは、同じエージェントでも挙動が変わる。
- 公式実装はZed・JetBrains IDE・Qt Creatorのみ。VS CodeやNeovimなどはコミュニティ製プラグインで、保守状況の確認が必要。
- レジストリの収録条件は認証対応の有無であり、エージェント自体の安全性や品質を保証するものではない。
- ガバナンスはZedとJetBrainsによる暫定体制で、独立財団への移行はまだ途上。
まとめ：エディタとエージェントの乗り換えコストを切り離す試み
ACPは、エディタとエージェントのあいだにLSP的な共通言語を置く規格です。JSON-RPCで会話し、ファイルとターミナルという環境の鍵はエディタ側が握り、外部ツールとの接続はMCPに任せる。役割分担がはっきりしているぶん、仕様そのものは驚くほど素直です。
実務的な意味は、エディタを変えるコストとエージェントを変えるコストが分離されることにあります。新しいエージェントが出るたびに拡張機能の対応を待つ必要はなくなり、逆にエディタを乗り換えても手に馴染んだエージェントを持っていけます。ZedとJetBrainsが公式対応し、レジストリに主要なCLIエージェントが並んだことで、その前提はかなり現実的になりました。
一方で、v2がドラフトであること、リモート対応が未完成であること、公式実装がまだ3つに限られることは無視できません。まずは普段使いのエディタでACP経由のエージェントを1つ動かし、capabilityの違いで何ができなくなるかを確かめるところから始めるのが現実的です。自作ツールをエージェントから使わせたいだけなら、ACPクライアントを書くより先にMCPサーバー化を検討したほうが早く済みます。仕様は活発に動いているため、判断の前に下記の一次情報で最新の状況を確認してください。
参考リンク
- Agent Client Protocol 公式サイト
- https://agentclientprotocol.com
- イントロダクション（プロトコルの目的とMCPとの関係）
- https://agentclientprotocol.com/get-started/introduction
- アーキテクチャ（役割分担とMCPサーバーの扱い）
- https://agentclientprotocol.com/get-started/architecture
- プロトコル概要（JSON-RPCとライフサイクル）
- https://agentclientprotocol.com/protocol/overview
- ACPレジストリ
- https://agentclientprotocol.com/get-started/registry
- ガバナンス（リードメンテナと財団移行の方針）
- https://agentclientprotocol.com/community/governance
- ACP v2 ドラフトのアナウンス
- https://agentclientprotocol.com/announcements/acp-v2-draft
- GitHub リポジトリ（ライセンス・SDK一覧）
- https://github.com/agentclientprotocol/agent-client-protocol
- レジストリのリポジトリ（収録条件と自動更新）
- https://github.com/agentclientprotocol/registry
- Zed によるACP発表記事（2025年8月27日）
- https://zed.dev/blog/bring-your-own-agent-to-zed
- Zed によるACPレジストリ発表記事（2026年1月28日）
- https://zed.dev/blog/acp-registry
- JetBrains によるACPに関する見解
- https://blog.jetbrains.com/ai/2025/12/agents-protocols-and-why-we-re-not-playing-favorites/
