Agent Client Protocol(ACP)とは──コーディングエージェントを「LSPのように」つなぐ標準規格
AI開発ツールZed Industries発の「Agent Client Protocol」公式ドキュメントによると、ACPはエディタとコーディングエージェント間の通信をJSON-RPCで標準化する規格。Claude Agent SDK・Codex CLI・Gemini CLI・GitHub Copilot CLIなどがエージェント側として、JetBrains・Neovim・VS CodeなどがクライアントとしてACPに対応している。

コーディングエージェントを使うエディタ・IDEが増えるほど、「このエディタはこのエージェントに対応していない」という組み合わせ問題が起きる。Agent Client Protocol(ACP)は、この組み合わせ問題をLanguage Server Protocol(LSP)と同じ発想で解決しようとする規格だ。公式ドキュメントの原文をもとに、何を標準化しているのか、どのツールが対応しているのかを整理する。
3行まとめ
- ACPはZed Industries発の規格で、エディタ↔エージェント間の通信をJSON-RPC 2.0で標準化する。LSPが言語サーバーの統合を標準化したのと同じ発想
- v1(安定版)とv2(Draft)が並行して存在し、v2では
fs/read_text_file・terminal/createなどクライアント側のファイル/実行系メソッドが丸ごと廃止され、同等の機能はMCPサーバー経由で提供する設計に統一される- 公式の「Agents」「Clients」一覧ページには非常に多くの実装が列挙されているが、公式ドキュメント自身が個々のプロジェクトの成熟度を保証していない
LSPと同じ発想
ACP公式ドキュメントは、この規格が生まれた背景を次のように説明している。AIコーディングエージェントとエディタは密結合になりがちだが、相互運用性はデフォルトでは存在しない。エディタごとに、対応したいエージェントの数だけカスタム統合を作る必要があり、エージェント側もエディタごとに独自のAPIを実装しなければならない。これは次の3つの問題を生む。
- 統合コストの増大:新しいエージェント×エディタの組み合わせのたびにカスタム作業が必要
- 互換性の限定:エージェントは対応済みの一部エディタでしか動かない
- 開発者のロックイン:あるエージェントを選ぶことが、事実上そのエージェントが対応するインターフェースの選択にもなる
ACPは、Language Server Protocolが言語サーバーの統合を標準化したのと同じように、エディタ↔エージェント間の通信を標準化することでこれを解決しようとしている。ACPを実装したエージェントは、対応する任意のエディタで動き、ACPに対応したエディタはACP対応エージェントのエコシステム全体にアクセスできる、というのが公式の説明だ。
技術的な仕組み
公式ドキュメントによると、ACPは次の設計を採用している。
- 想定シナリオ:ユーザーは主にエディタ側におり、特定タスクの支援にエージェントを呼び出す、という構図を前提にしている
- ローカルエージェント:エディタのサブプロセスとして動作し、stdio経由のJSON-RPCで通信
- リモートエージェント:クラウドや別インフラでホストされ、HTTPまたはWebSocket経由で通信(リモートエージェントの完全なサポートは開発中と明記されている)
- データ形式:可能な場合はMCPと同じJSON表現を再利用しつつ、diffの表示など、エージェント型コーディングUX向けの独自型も含む
- テキスト形式:ユーザー向けテキストの既定フォーマットはMarkdown。エディタがHTMLを描画できなくても十分な表現力を確保するための選択、とされている
通信の仕組み:JSON-RPC 2.0とセッションの流れ
ACP公式ドキュメントの「Overview」ページによると、プロトコルの通信モデルはJSON-RPC 2.0仕様に従い、2種類のメッセージを使う。
- Methods:結果またはエラーを期待するリクエスト・レスポンスのペア
- Notifications:応答を期待しない一方向のメッセージ
典型的なやり取りの流れは、現行の安定版(v1・Latest)の公式ドキュメントで次のように整理されている。
- 初期化フェーズ:クライアントがエージェントに
initializeを送って接続を確立し、必要であればauthenticateで認証する - セッション設定:
session/newで新規セッションを作るか、対応していればsession/loadで既存セッションを再開する - プロンプトターン:クライアントが
session/promptでユーザーメッセージを送信し、エージェントは進捗更新をsession/update通知で返す。ファイル操作や権限確認が必要ならその都度リクエストし、処理を中断したい場合はクライアントがsession/cancelを送る。ターンが終わると、エージェントは停止理由(stop reason)付きでsession/promptのレスポンスを返す
公式ドキュメントは、エージェントを「生成AIを使ってコードを自律的に変更するプログラムで、通常はクライアントのサブプロセスとして動作する」と定義している。エージェント側が実装しなければならない「ベースラインメソッド」としてinitialize・session/new・session/promptなどが挙げられている。
なお、プロトコルにはv1(現行のLatest/安定版)に加えてv2(Draft/開発中)が用意されており、公式ドキュメントの「Migrating from v1」ページを実際に読むと、複数の破壊的変更(breaking changes)が予定されていることが分かる。主なものを表にまとめる。
| v1のメソッド | v2での扱い |
|---|---|
authenticate |
auth/loginに改名(プロトコル駆動の認証方式向け) |
logout(capability marker必須) |
auth/logoutに改名。authMethodsが空でなければ常に必須、capability markerは廃止 |
session/load |
廃止。session/resumeにreplayFrom: {type: "start"}を渡す形に統合 |
session/set_mode |
廃止。session/set_config_optionに統合 |
fs/read_text_file・fs/write_text_file |
廃止 |
terminal/create・terminal/output・terminal/release・terminal/wait_for_exit・terminal/kill |
廃止 |
session/prompt |
メソッド名・パラメータ形状は変わらないが、レスポンスの意味づけが再設計される |
特に目を引くのは、クライアント側が提供する「ファイル読み書き」「ターミナル実行」の一連のメソッド群が、v2で丸ごと廃止される点だ。移行ガイドは廃止の理由をこう説明している。
In practice this surface was inconsistently implemented outside of a few IDEs, and agents already needed their own file and execution handling for clients that didn't offer it.
(実際にはこの領域は一部のIDEを除いて実装がまちまちで、そもそもクライアントがこれらを提供しない場合に備えて、エージェント側は独自のファイル・実行処理を既に持たざるを得なかった。どのIDEを指すかは移行ガイドに明記されていない)代わりにv2では、ファイルアクセスや未保存のエディタ状態、コマンド実行をクライアント側から提供したい場合は、MCPサーバーとしてセッションに渡す(session/new/session/resumeのmcpServers経由)ことで、エージェントが使う他のツールと同じ扱いに統一する設計になっている。つまりv2は「ACP独自のファイル/実行の仕組み」を捨てて「MCPに一本化する」方向への転換だと読める。本記事の説明は現行の安定版であるv1に基づく。
誰が作っているか、誰が対応しているか
ACPはコードエディタ「Zed」を開発するZed Industriesが起点になっている規格で、GitHub上で公開されている。プロトコルにはv1(Latest)とv2(Draft)があり、公式ドキュメントには両バージョンの仕様・移行ガイドが用意されている。
公式の「Agents」一覧ページで確認できる、ACPに対応する主なエージェント(一部抜粋):
- Claude Agent(ZedのSDKアダプタ経由)
- Codex CLI(同じくZedのアダプタ経由)
- Gemini CLI
- GitHub Copilot CLI(パブリックプレビュー、2026年1月28日付のGitHub Changelogが出典)
- Cursor
- Qwen Code
- Kimi CLI
- OpenClaw
公式の「Clients」一覧ページで確認できる、ACPに対応するエディタ・IDE(一部抜粋):
- Zed(自社製品)
- JetBrains(公式のClients一覧に掲載。どの製品・機能を経由するかは同ページに記載が無い)
- Visual Studio Code(複数のサードパーティ拡張経由)
- Neovim(CodeCompanionなど複数プラグイン経由)
- Emacs(agent-shell.el経由)
- Obsidian(複数プラグイン経由)
このほかCLI/TUIクライアント、デスクトップ・Webクライアント、モバイルクライアント、メッセージングブリッジ(Slack・Discord・Telegramなど)、LangChain・LlamaIndex・Mastraといったフレームワーク統合まで、公式ページには非常に幅広い実装が列挙されている。
リモート運用とプロジェクト成熟度はまだ確認していない
限界を先に書く。
v1とv2の差分は、主要な破壊的変更に限って表にまとめた。 ただし「Migrating from v1」ページ全体は750行近くあり、session/updateの各バリアント変更・診断ブロックの細部・スラッシュコマンドの扱いなど、この記事で拾いきれていない変更点はまだ残っている。
リモートエージェントの実運用状況。 公式ドキュメントは「Full support for remote agents is a work in progress」と明記しており、クラウドホスト型エージェントでの実運用がどこまで進んでいるかは確認していない。
一覧に載っている個々のプロジェクトの成熟度。 Agents/Clientsページに列挙されたプロジェクトの多くはコミュニティ実装であり、公式ドキュメントはリンク集を提供しているだけで、個別プロジェクトの品質・メンテナンス状況までは保証していない。当サイトの別記事では、この「Agents」一覧(40件)と、認証対応済みエージェントだけを集めた「ACP Registry」(39件)を突き合わせ、Agents一覧のうち17件がRegistry側には含まれていないことを確認している(ACP Registryの記事)。つまり「Agents一覧に載っている」ことと「認証まで含めてACPに対応している」ことは同じ基準ではなく、一覧に載っていること自体が成熟度の証明にはならない。
関連記事
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか?
AIについて聞きたいことはありますか?
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。