エージェントクライアントプロトコル (ACP)

概要

Agent Client Protocol (ACP) は、エディタとAIコーディングエージェント間の通信を標準化エージェントとエディタの 相互運用性向上 を目的 統一プロトコル による開発効率化とロックイン回避 JSON-RPC と Markdown ベースの柔軟な設計現時点で Zed や neovim 等をサポート

Agent Client Protocol (ACP)とは

ACP は、 コードエディタ （IDE、テキストエディタ等）と AIコーディングエージェント （自律的にコードを修正する生成AIプログラム）間の通信標準化プロトコル
開発中 だが、既に実用的なユーザー体験の構築が可能な仕様
エディタ と エージェント の結合度低減

ACPが必要な理由

現状：各エディタは、サポートしたいエージェントごとに 個別の連携実装 が必要
エージェント側 も、ユーザーに届けるために エディタ固有API の実装が必要
問題点 ：
- 統合コスト増大 ：新しいエージェント・エディタの組み合わせごとに カスタム開発 が発生
- 互換性制限 ：エージェントが利用できるエディタが限定される
- 開発者ロックイン ：エージェント選択が 利用可能なインターフェース に依存

ACPによる解決

標準化プロトコル の提供により、 LSP（Language Server Protocol） と同様のエコシステム構築
ACP対応エージェント は、 すべてのACP対応エディタ と連携可能
ACP対応エディタ は、 全ACPエージェント の利用が可能
エディタ と エージェント の 独立したイノベーション 促進
開発者 が 最適なツール選択 を実現

ACPの設計概要

ユーザー は主にエディタ内で作業、必要に応じてエージェントにタスク依頼
エージェント はエディタの サブプロセス として起動
通信方式 は JSON-RPC、 stdio 経由
MCP で使われるJSON表現を再利用、エージェント特有のUX要素（例：diff表示）にはカスタム型を使用
ユーザー向けテキスト は Markdown 形式で送信
- HTMLレンダリング 非対応のエディタでもリッチな表現が可能

サポートされるエディタ・エージェント

サポートエディタ
- Zed
- neovim （CodeCompanionプラグイン経由）
サポートエージェント
- Gemini
- 今後追加予定

Hackerたちの意見

これ、うまくいくといいな。Zedが「原点回帰」して、コラボレーションに力を入れてる感じがする。これでエージェントIDEカテゴリをぶっ壊そうとしてるのかな？競争に時間を使わなくて済むように。CLIエージェントの採用状況がどうなるか気になるな。Gemini CLIがもう入ってるのは嬉しい。LLMやコーディングアシスタント市場の競争が活発なのはいいね。これでサービス間の切り替えコストもさらに小さくなるし。

└

Zedには完全に心を奪われてる。何年も欲しかったエディタの全てが揃ってるし、想像もしてなかった素晴らしい機能も追加されてる。これまで現状に不満でいくつかのエディタをプロトタイプしてきたけど、良いエディタを作るには相当な努力が必要なんだよね。Zedはその努力をしっかりやってる。オープンにコラボレーションしてくれるのを歓迎するよ。

└

ほんとに。これでクソみたいなVS Codeのフォークが終わって、Zedがちゃんと評価されるようになるといいな。これらのAIエディタが本当に空気を吸い取ってる感じ。

すでに https://agentcommunicationprotocol.dev (ACP) って同じ名前があるから、ちょっと混乱するね。違いはあるけど。

└

IBMは2025年3月にエージェント通信プロトコル（ACP）を発表したけど、今はその名前を捨てて、ACPの取り組みをGoogleのAgent2Agent（A2A）プロトコルとLinux Foundationで統合することにしたみたい。ACPチームは縮小中で、業界はLinux Foundationのもとでオープンでコミュニティ主導のAIエージェントの相互運用性のためにA2Aを支持してる。この動きはプロトコルを統一して、AIエージェントの基準の分裂を避けることを目指してるんだ。

大きな疑問は、これが単なるLSPサーバーやLSPプロトコルの拡張で済むのかってことだね。LLMに必要なものを全て提供できるのに。

Claude、AIエージェントとIDE/エディタ間の通信プロトコルを考えてくれ。Node、Python、Rustのライブラリを作って、ランディングページ付きのウェブサイトも作って。

└

笑。ほんとに享楽的だね。

└

正直、Geminiがこのプロトコルを実装したSublime Textプラグインを書けるか試してみたい気分。VSCodeにシフトしてる感じがするから、そっちにツール投資が集中してるんだよね。新しいツールがサポートをやめるせいでSublimeから追い出されるのは嫌だな。あれは素晴らしいエディタだし、大企業にスポンサーされてないのがいいところなんだ。

└

…そして、Geminiを唯一のサポートエージェントにして足跡を隠すんだね…

MCPも最初はJSON-RPCをstdio経由で始めたんだ。GitHub Codespacesやdevcontainers、あるいは「バックグラウンドエージェント」のようなソリューションがある中で、JSON over SSEの開発が進むのか気になるな。今は、私の環境は裸の金属上でClaude Codeを使っていて、アプリケーションはコンテナ内で動いてる。エージェントは「docker compose exec backend」を制限なしで実行できるし（YOLO）。git worktreeを使ったワークフローを採用する上での最大の障害は、データベースエンジンを共有する必要があること（ローカルリソースの制約）と、初期の移行時間なんだ。クラウドにオフロードするのは面白いかも。

AnthropicがこれをClaude Codeに採用してくれるといいな。せめてVS Codeとの統合くらいは提供してほしい。エディタからの診断情報にはアクセスできると嬉しいな。

このアイデア大好き！広まるといいな。ただ、ファイル検索と未保存ファイルの扱いがちょっと不明なんだよね。エージェントがファイルシステムを検索するためにripgrepを使うのは一般的だけど、通信プロトコルが未保存ファイルへの読み書きアクセスを含むなら、正確性にズレが生じるんだよね。rgは未保存ファイルを検索できないから。

Claude Codeの実装が始まってるのが面白いね、ここにあるよ: https://github.com/zed-industries/zed/blob/main/crates%2Fage... https://www.npmjs.com/package/@zed-industries/claude-code-ac... まだサイトには載ってないみたいだけど。

このスレッドにはネガティブな意見が多いね。最近、Zedで動いてるGemini CLIのデモを見た後、実はこの分野の標準化に期待してるんだ。Helixは使い始めてからずっとお気に入りのエディタだけど、最近はAI機能が統合されてないのがちょっと厳しくなってきた。メンテナがそれに対して構築するのに躊躇してる理由もわかるけど、標準化されたプロトコルがなかったからね。ACPがそれを変えてくれるといいな。

Claude CodeがACPを使えるようにするツールを書いてるんだけど（CCとZedをよく使うから）、今のところ結構うまくいってるよ（Claude Code SDKとACPクライアントライブラリを使ってる）。ちょっと手直しして、明日には公開するつもり。

ハクソク