はじめに
AIコーディングエージェントが一気に広まったことにより、エンジニアは多数の選択肢を持つことになりました。
今や、さまざまなコードエディタなどでAIエージェントを使用できますが、各エディタごとに、各AIエージェント用のプラグインが開発されています。
どれも似たような機能・似たようなUIが各社から提供されていますが、その実装はバラバラとなっていて、エディタxAIエージェントの数だけプラグインが開発されていて、多くの組み合わせが起きています。
そうすると、AIエージェントプラグインの開発が追いつかず、一部のエディタでしか使用したいAIエージェントが提供されないといった「ロックイン」が起きてしまい、果てにはAIエージェント普及のボトルネックとなってしまう懸念があります。
そうした課題を解消するために生まれたプロトコルについて学習してみました。
Agent Client Protocol (ACP) の概要
ACPとは？
コードエディタとAIエージェントの組み合わせ問題への解決策として、コードエディタ（クライアント）とAIエージェント（サーバー）間の通信を標準化するために作られたプロトコルを作ると言うアプローチを取ったのが「ACP」です。
双方がACPに対応していれば、すぐにコードエティたとAIエージェントを繋ぐことができるようになります。
そうすることで、ボトルネックを解消し、利用者は好きなエディタとAIエージェントの組み合わせることができるようになります。
ACPの設計哲学
LSP (Language Server Protocol) が、プログラミング言語固有のインテリセンスをコードエディタから分離したのと同じアプローチを、AIエージェントの世界でも実現しようとしています。
ACPの仕組み
ACPの最小構成として、「クライアント」と「エージェント」から成り立ち、クライアントはサブプロセスとしてエージェントを立ち上げ、stdioで通信します。
通信プロトコルはJSON-RPCとなっていて、その上でエージェントはACPに準拠したインターフェースを提供します。
MCPについては、考え方が2つあります。
- ローカルマシンまたはリモートのMCPサーバの使用
クライアント側のMCP Configurationをエージェントに渡し、エージェントがMCPサーバと直接接続する方法です。 - エディタ内蔵のMCPサーバの使用
エディタ自身が、エディタを操作するためのMCPを提供している場合には、エージェントが提供するstdioを使い、クライアントのMCPと通信させることができます。
この場合、MCPをstdioで使用できるための MCP Proxy を使用します。
ACPで定義されている機能
ACPでは以下のような機能が定義されていて、これらの機能をエージェント側が実装することで、クライアント側から利用できるようになります。
- Prompt Turn
ユーザのメッセージ送信から、エージェントの最終的な応答を1ターンと捉えます。この1ターンの中で、エージェントはLLMとの複数回のやり取りや、後述するツール呼び出し（Tool Calls）を行います。 - Content
ACP上でやり取りされる情報ブロックのことで、テキスト・画像・音声や、ファイルの中身を直接埋め込んだ「Embedded Resource」が定義されています。 - Tool Calls
エージェントがツールを実行する前に、ユーザへの通知と、必要に応じてユーザに実行許可を求める機能です。 - File System
エージェントが、クライアントの環境内のテキストファイルを読み書きするための機能です。エディタ上の「まだ保存されていない変更」などにもアクセスできます。 - Terminals
エージェントがクライアントの環境でシェルコマンドを実行し、その標準出力をリアルタイムでストリーミングして受け取るための仕組みです。 - Agent Plan
複雑なタスクを行う際、エージェントが「どのような手順で進めるか」という実行計画をクライアントに共有する機能です。これにより、ユーザーはエージェントの思考プロセスを視覚的に把握できます。 - Session Config Options
エージェントが「利用可能なモデル」「推論レベル」「動作モード（Askモードなど）」などの設定オプションのリストを提示し、クライアント側のUI（プルダウンなど）からユーザーが柔軟にセッションの設定を変更できるようにする仕組みです。 - Slash Commands
エージェントがサポートしている特定のコマンドをクライアントに事前通知する機能です。ユーザーがプロンプト内でこれらを入力することで、特定のアクションやワークフローを素早く呼び出すことができます。
ACPのデメリット
ACPのデメリットについて調べてみたところも以下のような点がありました。
クライアントが終了すると、エージェントプロセスも終了する
エージェントプロセスはクライアントのサブプロスセスとして実行されるため、クライアントが終了してしまうと、エージェントプロセスも修了してしまいます。
一方、Claude CodeやCodexなどのCLIツールは、エディタと別プロセスで動かせるため、エディタが何らかの理由で終了してしまってもタスクを続行できます。
この点を比べてみると、エージェントがサブプロセスで立ち上がるACPのデメリットが見えてきました。
（ただし、この点は各IDEに提供されているCopilot プラグインにも同じことが言えると思います。）
エディタ特有の機能が使えない場合がある
VSCodeのCopilot Extensionは、VSCode内部のコマンドを実行する場合があり、こうした各エディタ固有の統合機能がACPでは使えません。ただし、理論的にはVSCodeを操作するためのMCPを使えば、似たような事はできるかもしれません。
さいごに
ACPでは、ドラフトの仕様が10個以上提出されています。内容を見てみると「既存セッションのフォーク」「既存のセッションの再開」「セッション使用状況とコンテキストのステータス」といったものとなっていて、これらが実装されればより実用度が高まりそうだと思いました。
おすすめ書籍
