Phodal Huang が中国語で書いたこの記事は、彼が企業の開発現場に見ている問題から始まる。複数の AI コーディングアシスタント（記事は Cursor、Copilot、Augment、Claude Code を挙げている）が同じ企業内に併存するようになっており、プラットフォームチームは、効率、協働、ガバナンスを犠牲にすることなく、それらを異なるエディタ間で共存させなければならない。彼の答えは Agent Client Protocol（ACP）（ACP）であり、彼のチームは最近、自分たちが開発している AI コーディングツール AutoDev にそれを統合した。
彼によれば、ACP への関心は、社内ネットワーク上で顧客に統一された AI コーディングエージェントのサービスを提供したいと考えたことに始まった。彼は企業での仕事をバイブコーディングのデモと対比する。企業では人が自分のコードに責任を持ち続け、AI は補助的なツールにすぎないため、AI が書いたコードにもそれをレビューするためのツールが依然として必要になる。Claude Code の IDEA プラグインがこの用途ではうまく機能しないとわかった後、チームは JetBrains が推進する ACP に目を向けた。
要点
- ACP は IDE やエディタと AI コーディングアシスタントの間の標準プロトコルとして示されており、著者はそれを「AI エージェントのための LSP」と考えるよう勧めている。彼の言い方では、その中核となる原則は、ツール呼び出しを第一級のものとして IDE から見えるようにすることで、エージェントが踏むすべてのステップを IDE が完全に制御できるようにすることである。
- 著者はその動作モデルを次のように説明している。IDE がクライアントとして、エージェントがサーバーのサブプロセスとして振る舞い、stdio 上の JSON-RPC 2.0 で通信する。起動時にケイパビリティのネゴシエーションを行い、セッション中は計画とツール呼び出しについてリアルタイムで更新を送り、ファイルの編集やコマンドの実行といった機微な操作についてはパーミッションを要求する。
- AutoDev の統合は、統一されたレンダリングアーキテクチャを軸に AutoDev 3.0（Xiuper）を構築する中で行われ、双方向のものだった。つまり AutoDev は ACP サーバーとしても ACP クライアントとしても動作できる。公式の Kotlin と TypeScript の SDK を使い、ACP のイベントが複数のプラットフォームで描画されるよう共通のレンダラーインターフェースを中心に構築された。Claude Code のように ACP を話さないエージェントは、それぞれのストリーミング出力を解析することで適応させている。
- 著者が ACP の主要な推進者の 1 つとする JetBrains は、ワンクリックでのインストールと実行時の管理のための公式 ACP Agent Registry、
acp.jsonファイルによるカスタム設定、そして ACP の下で動作するエージェントのための MCP 統合を提供している。 - 彼は 2 つのプロトコルの関係を、ACP がエージェントと IDE の間のやり取りを担い、Model Context Protocol がエージェントの能力を外部システムへと拡張するもの、とまとめている。
- ACP によって構築しやすくなるマルチエージェントのワークスペースとして、彼が招待されて使っていた Augment Intent（コーディネーターエージェントがタスクを、別々のワークツリーで作業する専門エージェントに分割する）と、エディタビューとエージェントマネージャーの画面を備えた Google Antigravity を紹介している。
- 企業向け AI プラットフォームのための 3 層のガバナンスモデルを提案している。再利用可能な企業の能力の担い手としての MCP と Skills、開発者とアシスタントの間のインタラクション層としての ACP、そしてエージェント間の協働ネットワークとしての Agent2Agent プロトコル（A2A） である。
背景
この記事は、自身のチームの統合作業についての実務家による報告と、ベンダー各社の製品の概観を組み合わせたものであり、測定結果は報告していない。今こそマルチエージェントの開発プラットフォームを構築する最適な時期だという企業向けの提言は、エコシステムの向かう先についての著者自身の見方に基づいている。