7月2日、CircleCIが「ACP vs MCP: What's the difference for agentic coding?」と題した記事を公開した。この記事では、AIコーディングエージェント開発で使われる2つのオープンプロトコル「ACP」と「MCP」の役割の違いと使い分けについて詳しく紹介されている。
「vs」ではなく「and」で使う2つのプロトコル
エージェント開発の現場で「ACP vs MCP、どちらを使うべきか？」という問いが生まれやすい。結論から言えば、両者は競合しない。同じスタックの異なる層に属する。
- ACP（Agent Client Protocol）: コードエディタとAIコーディングエージェントをつなぐ
- MCP（Model Context Protocol）: AIエージェントとツール・データをつなぐ
エージェントは両プロトコルの間に位置する。ACPではエディタがエージェントに問いかけ、MCPではエージェントがツール（サーバー）に問いかける。方向が逆だ。
ACPとは何か
ACP（Agent Client Protocol） はZedとJetBrainsが共同でガバナンスするオープン標準で、ライセンスはApache 2.0だ。なお、「ACP」という略称は元記事が使用するものであり、正式名称「Agent Client Protocol」は公式サイトでも確認できる。
ACPが解決する問題は「N×Mのグルーコード問題」である。共通プロトコルがなければ、エディタごとにエージェント連携を実装し、エージェントごとにエディタのAPIを実装する必要がある。エディタやエージェントが増えるたびに実装コストが爆発する。ACPはその構造を、「双方が1つのプロトコルを実装すれば、どのACPエージェントもどのACPエディタで動く」に変える。
この発想はLanguage Server Protocol（LSP）と同じだ。LSPが1つの言語サーバーをあらゆるエディタで動かせるようにしたのと同様に、ACPはエージェントに同じ仕組みを適用する。
開発者にとっての実益
エージェントの選択とエディタの選択が切り離される。ZedでGemini CLIを使っていたが、翌日Gooseを試したい——そのままエディタもキーバインドも変えずに乗り換えられる。逆にエディタをZedからNeovimに変えても、チューニングしたエージェントを持ち込める。
ターミナルエージェントにもメリットがある。スクロールバックでdiffを目で追う代わりに、エディタのネイティブなdiffビューで変更をレビューできる。
仕組み
エディタがエージェントをサブプロセスとして起動し、stdio経由でJSON-RPCメッセージをやり取りする。LSPと同じパターンだ。
通信はセッション単位で管理される。エディタがセッションを開き、開発者のプロンプトを「ターン」として送る。エージェントは処理中に進捗をストリームで返すため、エディタはリアルタイムで状況を表示できる。
ACPが単なるチャット貼り付けより優れている核心は双方向通信にある。エージェントはエディタの未保存バッファを読める（ディスク上の古いコピーではなく、実際に見ているコードで動作する）。編集前には必ず許可を求める。エディタが管理するターミナルでコマンドを実行できる。エディタが権限の範囲を決め、エージェントはより豊かなコンテキストを得る。
対応状況
公式エージェントディレクトリにはGemini CLI、OpenAI Codex CLI、Block製Goose、CursorのCLIエージェント、GitHub Copilot CLIなど多数が掲載されている。クライアントはZed、JetBrains IDE、Neovim、Emacsに及ぶ。VS CodeはネイティブACP対応なし（元記事公開時点）。コミュニティ拡張機能がその穴を埋めている。
「ACP」という名前の衝突問題
「ACP」を検索すると3つの無関係なプロトコルがヒットする点は注意が必要だ。
| プロトコル | 接続対象 |
|---|---|
| Agent Client Protocol（Zed/JetBrains） | エディタとコーディングエージェント（この記事の主題） |
| Agent Communication Protocol（IBM/BeeAI） | エージェント同士（現在はA2Aに統合） |
| Agentic Commerce Protocol（OpenAI/Stripe） | AIチェックアウトとマーチャント |
MCPとは何か
MCP（Model Context Protocol） はAnthropicが作成し、現在はLinux Foundation傘下のAgentic AI Foundationがガバナンスを担う。
MCPサーバーはエージェントがアクセスすべき対象（CIシステム、データベース、イシュートラッカーなど）をラップする。各サーバーが公開するのは3つのプリミティブだ。
- Tools: モデルが呼び出せるアクション
- Resources: 読み取れるデータ
- Prompts: 再利用可能なテンプレート
ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、VS CodeがすべてMCP対応を実装済みだ。公式レジストリには数千のサーバーが登録されている。
具体例としてCircleCI MCPサーバーがある。これを接続すると、エージェントは「最新ビルドがなぜ失敗したか？」という問いに対してget_build_failure_logsツールを呼び出し、実際のログを読んで回答できる。フレイキーテストの検出、.circleci/config.ymlの検証、ワークフローの再実行も同サーバーで可能だ。
どちらを使うべきか：環境別の整理
| 環境 | ACP | MCP |
|---|---|---|
| ターミナルのエージェント（Claude Code、Codex CLI） | 不要 | 適用される |
| ZedまたはJetBrains IDE内のエージェント | 適用される | 適用される |
| VS CodeまたはCursor | ネイティブ非対応（元記事公開時点） | フル対応 |
ターミナルで動かすだけならMCPのみ。エディタに持ち込んだ瞬間に両プロトコルが揃う。
両者を組み合わせて使う
Claude Codeなどのエージェントハーネス内でMCPサーバーを設定していれば、そのエージェントをACPエディタに接続したときにMCPの設定はそのまま引き継がれる。エディタ側も独自のMCPサーバーをセッション開始時にsession/newのmcpServersパラメータでエージェントに渡せる。
セキュリティの観点では、MCPツールはエージェントが実行できるコードだ。ローカルサーバーは環境変数で認証するため、org-adminトークンよりスコープを絞ったトークンが望ましい。ACPのパーミッションプロンプトがその最終的なガードレールになる。
LSPとの関係：パターンの継承
ACPもMCPも、根底にある発想はLSPから来ている。MCP仕様書はLSPから着想を得たと明記しており、ZedもACPについて同様のことを述べている。3つを並べると同じパターンが見える。
- LSP: エディタに言語インテリジェンス（補完、診断、定義ジャンプ）を与える
- ACP: そのエディタにコーディングエージェントを置く
- MCP: エージェントにツールとデータを渡す
LSPはエージェントスタックでも現役だ。テキストのgrepではなくコンパイラレベルのコードインテリジェンスをエージェントに提供する役割を担う。
詳細はACP vs MCP: What's the difference for agentic coding?を参照していただきたい。
