ACP (Agent Client Protocol): エージェントとIDEを繋ぐオープンな標準規格

AIコーディングエージェントが開発現場に浸透しつつある。Claude Code、GitHub Copilot、Gemini CLI――次々と登場する多様なエージェントを、自分のエディタや IDE で快適に使いたい。しかし現実は厳しかった。

かつてエディタ拡張は、言語ごとに専用プラグインを実装する「M×N の地獄」に陥っていた。それを解決したのが LSP (Language Server Protocol) だ。言語サーバとエディタの通信を標準化することで、「一度作れば、どこでも動く」を実現した。

いま、同じ問題がエージェントの世界で起きている。あるエージェントは VS Code 専用、別のエージェントは JetBrains IDE だけ、というサイロ化が進んでいる。エージェント開発者は各エディタへの個別統合を強いられ、ユーザーはエージェントとエディタをセットで選ばなければならない。

この問題を解決するために登場したのが、 ACP (Agent Client Protocol) だ。ZedとJetBrainsが共同で策定するオープンプロトコルで、コーディングエージェントとエディタ間の通信を標準化する。その設計思想は明快だ――「LSPがやったことをエージェントでも再現する」¹。

ACPとは何か

LSPとの類似性

ACP の思想を理解する上で、LSP との比較は非常に有益だ。LSP が登場する以前、プログラミング言語のサポートはエディタごとに独自実装する必要があった。Python の自動補完が欲しければ、VS Code 用・Vim 用・Emacs 用と個別に開発しなければならない。

LSP はこのアーキテクチャを根本から変えた。言語サーバとエディタのやりとりを標準化することで、「言語サーバを一度実装すれば、LSP 対応のすべてのエディタで動く」仕組みを確立した¹。

ACP はこの設計哲学を継承する。エージェント開発者が ACP に準拠した実装を一度行えば、ACP 対応のすべてのエディタで動作する。エディタ側も、ACP に一度対応すれば、ACP エコシステム全体のエージェントにアクセスできる。エージェントとエディタの組み合わせ爆発が、一気に解消される¹。

技術的な概要

ACP の技術仕様は比較的シンプルだ。通信方式は JSON-RPC over stdio を採用しており、エージェントはエディタのサブプロセスとして動作する。特筆すべきは、Anthropic の MCP (Model Context Protocol) の JSON 表現を再利用しつつ、エージェント-クライアント間に特化した独自の型定義も追加している点だ¹。

ユーザーへのメッセージ表示はデフォルトで Markdown 形式を採用。すでに Rust・Kotlin・Python・TypeScript の公式 SDK が公開されており、GitHub の agentclientprotocol 組織でオープンソース開発が進められている。

ACPが解決する3つの課題

ACP 公式サイトは、プロトコルが解決する問題を 3 つに整理している¹²。

Integration Overhead（統合のオーバーヘッド）

現状では、エージェント開発者は新たなエディタをサポートするたびに、ゼロから統合コードを書き直す必要がある。1 つのエージェントを 5 つのエディタで動かすには、5 種類の統合実装が必要だ。

ACP はこの状況を根本から変える。エージェント開発者は ACP に準拠した実装を一度だけ行えばよい。あとは ACP 対応エディタであれば、追加実装なしで動作する。開発リソースを本来の機能改善に集中できる¹。

Limited Compatibility（互換性の限界）

ACP 以前の世界では、エージェントは特定のエディタとの組み合わせでしか動作しない。Claude Code は VS Code でのみ、あるいは JetBrains IDEs でのみ、というサイロが生まれやすい。

エディタ側も同じ問題を抱える。あるエージェントが特定エディタに深く統合されると、他のエディタユーザーはそのエージェントを利用できない。ACP 対応エディタはエコシステム全体のエージェントへアクセスできるようになり、選択肢の幅が大きく広がる¹。

Developer Lock-in（ベンダーロックイン）

最も深刻な問題がこれだ。あるエージェントを選ぶと、そのエージェントが対応するエディタに縛られる。逆に言えば、好きなエディタを使い続けようとすると、使えるエージェントが限定される。

ACP は開発者に選択の自由を取り戻す。ユーザーは「どのエージェントで」「どのエディタで」コーディングするかを、完全に独立して選べる。好きなエージェントを、慣れ親しんだエディタで使う――当たり前に見えて、今はまだ実現できていないことが可能になる²。

MCPなど他のプロトコルとの比較

2025〜2026 年は AI エージェント関連のプロトコルが乱立している。ここでは特に混同されやすい MCP との違いを整理する。

なお、「ACP」という略称は複数の異なるプロトコルに使われているため注意が必要だ³。IBM Research の「Agent Communication Protocol」や Agntcy Collective の「Agent Connect Protocol」なども同じ略称を使用している。本記事では一貫して Zed + JetBrains の Agent Client Protocol を指す。

MCP (Model Context Protocol)

MCP は Anthropic が 2024 年に発表したオープンプロトコルで、AI モデルと外部ツール・データソースの接続を標準化する。ファイルシステムへのアクセス、データベースの参照、Web 検索の実行など、「モデルがツールを使う」ためのインターフェースだ⁴。

通信方式は JSON-RPC（stdio/SSE）を採用。コミュニティの広がりは目覚ましく、数千の MCP サーバーが公開されている。

ACP vs MCP: 何が違うのか

両者の違いは 解決する問題の層 にある。

端的に言えば、MCP は「エージェントが何を知り、何をできるか」を拡張するプロトコルで、ACP は「エージェントとエディタがどう会話するか」を標準化するプロトコルだ。

両者は競合するのではなく、異なるレイヤーの問題を解決する補完的な関係にある。実際、ACP は MCP の JSON 表現を再利用しており、相互補完を意識した設計になっている¹。

ACP Registry: エコシステムの加速

ワンクリックでエージェントを導入

2026 年 1 月 28 日、 ACP Registry のベータ版 が公開された⁵。ACP 対応エージェントのオープンディレクトリとして、エコシステムを大きく前進させる存在だ。

ACP Registry の核心はユーザー体験の改善にある。従来、新しいエージェントを使うには設定ファイルを手動で編集し、パスや認証情報を手書きする必要があった。ACP Registry は、エディタ内から直接エージェントを検索・インストール・更新できる仕組みを提供する。設定は自動で完結し、バージョンアップも簡単だ⁵。

登録方法もオープンだ。GitHub 上の ACP Registry リポジトリをフォークし、agent.json とアイコンファイルを追加してプルリクエストを送るだけで、自作エージェントの掲載申請ができる。

対応エージェントの広がり

ベータ版公開時点で、主要なコーディングエージェントが既に対応を表明している⁵:

• Claude Code (Anthropic)
• Codex CLI (OpenAI)
• Gemini CLI (Google)
• GitHub Copilot (Microsoft)
• Mistral Vibe (Mistral AI)
• Qwen Code (Alibaba)

主要 AI プロバイダーが横断的に参加していることは、ACP が単一ベンダーの取り組みではなく、業界横断の標準として機能しつつあることを示している。

今後のロードマップと課題

ZedとJetBrainsの共同推進

ACP の推進体制は 2025 年 10 月の JetBrains 参加で大きく変わった²。エディタ市場では Zed は新興勢力だが、JetBrains は IntelliJ IDEA・PyCharm・WebStorm など多くの開発者が日常的に使用する IDE を擁する大手だ。

JetBrains の参加は ACP の信頼性と普及を一気に高めた。JetBrains の全製品への ACP 統合が予定されており、実現すれば ACP 対応エディタのシェアは一気に拡大する。Zed（新興の高速エディタ）と JetBrains（既存のエンタープライズ IDE）というこの組み合わせは、ACP の幅広い普及を後押しするだろう。

現在の対応クライアントには、Zed・JetBrains IDEs に加えて、Neovim・Emacs（agent-shell plugin 経由）、Python Notebook の marimo も名を連ねており、着実にエコシステムが広がっている⁶。

標準化 vs イノベーション

一方で、懸念の声もある。Sourcegraph（AI コーディングエージェント「AMP」の開発元）の CEO は、「ACP の採用が早すぎると、急速に変化する分野でのイノベーションを制限する可能性がある」と指摘した⁷。

この懸念はもっともだ。標準プロトコルは相互運用性を高める一方で、プロトコルの変更コストが生じるため、急速な進化を制約するトレードオフがある。LSP も初期は批判を受けたが、長期的にはエコシステム全体の発展に貢献した。ACP がそのような歴史を繰り返せるかは、今後の標準化プロセスの透明性とコミュニティの関与にかかっている。

おわりに

ACP は LSP と同じ設計哲学で、エージェントとエディタの「疎結合」を実現しようとしている。エージェント開発者はエディタの心配をせずに機能開発に集中でき、ユーザーはベンダーロックインなしに好きなエージェントと好きなエディタを組み合わせられる。

まだベータフェーズにあり、実績と改善の余地は残るが、Zed・JetBrains という異なる背景を持つ開発元の協力と、主要 AI プロバイダーの参加は、ACP がインフラとして成熟していく確かな兆しだ。コーディングエージェントが当たり前になる世界で、ACP は「見えないインフラ」として開発者の選択の自由を守る存在になるかもしれない。

参考文献