- Agent Client Protocol(ACP) は、コードエディタとAIコーディングエージェント間の通信を標準化するためのプロトコル
- 従来は、各エディタが特定のエージェントと接続するために個別のカスタム統合作業が必要であり、これは互換性の制限と開発者ロックインの問題を引き起こしていた
- ACPはLanguage Server Protocol(LSP) のように標準化された通信方式を提供し、一度実装すれば、すべての互換エディタ・エージェント間で自由に接続できるようにする
- エディタでエージェントをサブプロセスとして実行し、JSON-RPC over stdioで通信し、UI要素ではdiff表示とMarkdownベースの出力をサポートする
- 現在、Zed、Neovim(CodeCompanionプラグイン) などがACPをサポートしており、エージェント側ではGemini CLIが互換で、今後さらに対応範囲が広がる予定
紹介
- Agent Client Protocol(ACP) は、リモート開発、ポートフォワーディング、コマンド実行などのサーバー・クライアント間インタラクションを標準化することを目的として設計されたオープンプロトコル
- 既存の問題点: AIコーディングエージェントとエディタは密接に結び付いているが、相互運用性は本質的に保証されていない
- 各エディタは、対応したいエージェントごとにカスタム統合を構築する必要がある
- エージェントは、ユーザーに届くために特定のエディタAPIを実装しなければならない
- これは統合オーバーヘッド、限定的な互換性、開発者依存の問題を招く
- ACPの解決策: ACPは、エージェントとエディタ間の標準化されたプロトコルを提供する
- ACPを実装したエージェントは、すべての互換エディタで動作する
- ACPをサポートするエディタは、ACP互換エージェントのエコシステム全体にアクセスできる
- 独立したイノベーションを可能にし、開発者がワークフローに最適化されたツールを選べるようにする
ACP概要
- 動作方式: ユーザーは主にコードエディタで作業し、特定のタスクのためにエージェントを呼び出す
- エージェントはエディタのサブプロセスとして実行される
- JSON-RPCをstdio経由で使用して通信する
- データ形式: MCPのJSON形式を再利用し、diff表示のようなエージェントコーディングUX要素のためのカスタム型を含む
- テキスト形式: ユーザーの可読性のため、Markdown形式をデフォルトで使用する
- HTMLレンダリングなしでもリッチなフォーマットが可能
- 現在プロトコルは開発中だが、興味深いユーザー体験を構築するには十分な完成度を備えている
現在の対応状況
結論
- ACPはLSPの成功事例にならい、AIコーディングエージェントとエディタ間の相互運用性を革新的に改善する
- 開発者は特定のエージェントやエディタに縛られることなく、最適なツールの組み合わせを自由に選べる
- プロトコルの拡張はエコシステムの拡張性を高め、開発者ワークフローの効率性と柔軟性を向上させる可能性がある
1件のコメント
Hacker Newsの意見
Claudeに、AIエージェントとIDE/エディタ間の通信プロトコルを作ってくれと頼み、Node、Python、Rustのライブラリも開発し、ランディングページ付きのWebサイトまで構築してもらう、という発想をしてみた
正直、Geminiがこのプロトコルを実装したSublime Textプラグインを使えるか試してみたい誘惑がある。最近は大半のユーザーがVSCodeに流れていて、新しいツールもそこだけをサポートする傾向が出てきている。Sublimeのサポート終了で強制的に移行させられるのは避けたい。Sublimeは本当に良いエディタだし、大企業の支援を受けているわけでもない
それに、痕跡を隠すためにGemini専用のエージェントにしてしまうこともできそうだ
笑える、あまりにも自己中心的な願望だ
このプロジェクトが本当にうまくいってほしい。Zedはコラボレーションの本質に立ち返っていて、この流れがagentic IDEカテゴリにも変化をもたらしそうだ。そうなればZedは直接競争に時間を費やさずに済み、差別化もできる。CLIエージェントの間でどれほど採用されるのか気になる（すでにGemini CLIが連携しているのも良い）。LLMとコーディングアシスタント市場の激しい競争はいつでも歓迎で、こうした変化が相互の乗り換えコストを継続的に下げてくれると思う
自分もほとんどZedに乗り換えかけている。ここ数年ほしかったエディタ機能がほぼ全部入っていて、自分が想像もしていなかった素晴らしい機能も多い。現状に失望して自分でエディタのプロトタイプを作ってみたこともあるが、良いエディタを1つ作るには本当に多くの努力が必要だ。Zedはその努力を積み重ねてきた。オープンに協業しようとする彼らの動きを歓迎したい
本気で、今回の変化が粗悪なVS Codeフォークを消し去るきっかけになってほしい。Zedにもふさわしい評価が与えられてほしい。AIエディタが本当に業界の酸素を全部奪ってしまったように感じる
Claude CodeがACPを使えるようにするツールを作っている（自分がCCとZedをよく使うので）。これまではClaude Code SDKとACP Clientライブラリでかなりうまく進められている。まだ少し磨くべき部分があるが、明日あたりもう少し整えて公開する予定だ
すでに agentcommunicationprotocol.dev というACPが存在するので、名前が混乱を招くかもしれない。2つのプロジェクトには違いがあるが、こういう点は気になる
いちばん気になるのは、なぜLSPサーバーやLSPプロトコルの拡張ではLLMに必要な内容をカバーできないのか、という点だ
自分はAIを実際の人間の開発者のように扱うほうがしっくりくる。たとえばAIに機能実装やバグ修正、リファクタリングを依頼し、その結果のコミットを読む。コミットが気に入らなければ
git reset --hardして、プロンプトを改善してまたAIにやらせる。このやり方を「prompt coding」と呼んでいる。自分のコーディング環境とAIとの直接的な相互作用は必要ない。人間の開発者のように、私のエディタを触ることなく作業すればよい。関連説明最近はプロンプトを書くほうが良いと言われるが、その点には少し懐疑的だ。AIはごく特定の作業には役立つが、いまだにでたらめを多く出す。特にAPIのような存在しない話を作り出すのは許容しがたい
自分はAIにコミットまではさせない。ほとんどの場合、AIの出力は複数箇所を修正しなければならない。再プロンプトを何度も繰り返す時間がもったいないので、最初に望む答えが出なければそのまま自分で直すことが多い。最初から自分の意図を理解したコードを返してくれたときは、そのぶんAIへの信頼感が高まる
このアイデアがもっと広がってほしい。1つ気になるのは、ファイル検索と未保存ファイルの違いだ。実際、エージェントはファイルシステム検索にripgrepのようなものをよく使うが、プロトコルで未保存ファイルまで読み書きできるようにすると正確性に問題が出る。ripgrepは未保存ファイルを検索できない
AnthropicがこのプロトコルをClaude Codeに導入してくれることを本当に願っている。少なくともVSCodeで提供されているレベルの統合は期待したいし、少なくともエディタの診断情報にアクセスできるようにはなってほしい
MCPも最初はstdio上のJSON-RPCとして始まった。GitHub Codespaces、devcontainers、「background agents」のような環境が出てきたことで、JSON over SSEのような発展があるのかも気になる。今の自分の開発環境ではローカルでClaude Codeを使っていて、アプリはコンテナ内で動いている。エージェントが
docker compose exec backendを自律的に実行できる。git worktree運用を導入する際の障害は、データベースエンジンの共有（ローカル資源不足）と初期マイグレーションにかかる時間だ。こうした負荷をクラウドへオフロードするのも興味深いシナリオだこういうプロトコルが広がって、いつも既存の1つのIDEに縛られずに済むようになってほしい