コーディングエージェント通信規格「ACP v2」ドラフト公開
本文の状態
日本語全文を表示中
詳細モードで約10分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
TLDR AI
ACP チームは Agent Client Protocol のバージョン 2 ドラフトを公開し、セッション状態の表現拡大やコア動作の変更を通じて、背景処理と長期間にわたるエージェントの実装を可能にする新基盤を整備した。
AI深層分析を開く2026年7月29日 04:42
AI深層分析
キーポイント
バージョン 2 のドラフト公開と目的
ACP チームは v1 の運用経験に基づき、v2 ドラフトを発表し、より複雑なセッション状態の表現や一貫性の向上を主眼に置いている。
ターン制からの脱却と背景処理
従来のユーザー発話に基づくターン制の制限を超え、エージェントが背景で長期間作業を行いながら新しい入力を受け付ける柔軟な動作を可能にする。
RFD プロセスによる段階的進化
一度に全ての変更を盛り込まず、RFD(Request for Discussion)プロセスを活用して v1 と v2 の双方で機能追加を行い、大規模な移行を回避する。
実装の自由度と一貫性の追求
エージェントとクライアントの実装に最大限の自由を与えつつ、必要な意味論的部分を合意することで、新たなクライアントパターンの実現を目指す。
プロンプトライフサイクルの拡張
ユーザー発動に限定されず、セッション全体で任意のタイミングにsession/update通知が可能になり、エージェントはアイドル状態を明示して背景作業を継続できる。
重要な引用
"v2 is all about making it possible to express more session states, consolidating on patterns we have found useful, and overall making everything more consistent."
"Our core design goal remains to provide as much freedom as possible to both agents and clients in their implementations..."
"An agent could be ready to receive new input while background events are happening"
If we want to allow for queueing, steering, or receiving updates from work that isn’t necessarily initiated by the user, we need to make it clearer that the prompt request/response doesn't own the entire lifecycle of work being done.
編集コメントを表示
編集コメント
ACP v2 ドラフトは、単なるバージョンアップではなく、AI エージェントが人間との対話だけでなく自律的な背景作業をどう扱うかという根本的な課題への回答を示している。実装者にとっては、従来のターン制の概念から脱却し、より柔軟なセッション管理を実装する指針となる重要な文書である。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
公開日: 2026年7月20日
ACP チームは数ヶ月にわたりこの日を待ち望んでおり、Agent Client Protocol(ACP)バージョン 2 の最初のドラフト版を発表できることを嬉しく思います。
v1 をリリースして以来、将来互換性のあるプロトコルの性質と、RFD プロセスを活用することで、15 以上の RFD と関連機能を順次実装することができました。これを実現してくれた皆様に心から感謝するとともに、数ヶ月ごとに大規模な移行が必要になることなく、プロトコルを迅速に進化させられることを証明できたことも喜ばしいことです。
しかし、v1 の運用を通じて明らかになったのは、現在の仕様では表現が難しい新しいユースケースや機能を可能にするには、いくつかの破壊的変更が必要だということです。v2 は、より多くのセッション状態を表現できるようにし、有用だと判明したパターンに統一を図り、全体として一貫性を高めることに注力しています。
v2 に無理やり多くの機能を詰め込んでリリースが遅れる事態は避けたいと考えました。そのため、v1 ですでに成功していた RFD プロセス を活用し、v1 と v2 の両方に新機能を実装する指針としつつ、今回のリリースでは数々のコアな動作変更のみに焦点を絞りました。もしここで紹介されていないがぜひ欲しい新機能があるとしても、それは将来的に追加されないという意味ではありません。単に、今後ともオプションまたは追加的な機能については、リリースサイクルを独立させることで柔軟性を確保したかったのです。
私たちの核心的な設計目標は、エージェントとクライアントの実装において可能な限り自由度を提供し、そのために必要な意味のある部分について合意することです。v2 では、セッション中のエージェントの動作に関する柔軟性がさらに向上し、新たなクライアントのパターンも可能にする道が開かれました。
v2 の大きなテーマ
ターンを超えて
ACP v1 をリリースした当時、ほとんどのエージェントはユーザーからのメッセージを待ってからイベントを発行し、生成が完了するとすぐに停止するものでした。しかし現在では、エージェントはより長時間稼働し、バックグラウンドで複雑な作業の調整も可能になっています。
ACP v1 の仕様では、ターン(対話の区切り)の外側からセッション通知や更新通知が届くことを「禁止」してはいませんでしたが、実装者にとっては混乱を招く要因となっていました。実装者は通常、「ユーザーが開始したターン」という概念に基づいた相互作用パターンを保証したいと考えている一方で、これを厳格に適用すると有益な動作が阻害されてしまうからです。
例えば、エージェントはバックグラウンドでイベントが発生している間も新しい入力を受け付ける準備ができているのに、それに対するリアルタイムの更新を提供したいと考える場合があります。プロンプトを「ターン中心」に固定したままでは、クライアント側にもエージェント側にも満足な解決策が得られません。
キューイングやステアリング、あるいはユーザーが直接開始しない作業からの更新を受け入れたいのであれば、「プロンプトによるリクエストとレスポンスが、実行されるすべての作業のライフサイクルを完全に支配している」という前提を見直す必要があります。ACP v2 では、セッションまたは更新通知はセッション内の任意の時点で自由に発行できるようになります。また、プロンプトへのレスポンスは「メッセージがエージェントによって認識された」ことを示すものであり、「ターンの終了」を意味するものではありません。
エージェントはユーザーメッセージを挿入した位置から再生成するため、この仕組みにより、メッセージの再送信や複数のクライアントが同じセッションを観測する場合の処理も容易になります。さらに、エージェント自身が「アイドル状態(新しい入力を受け付ける準備ができている)」であることを明示できるため、クライアント側もそのタイミングで応答の準備を整えることができます。これにより、エージェントはセッションの状態を随時更新し続けることも可能です。
この変更の詳細については、新しいプロンプトライフサイクルに関する RFD をご覧ください。
メッセージの更新とストリーミングツール呼び出し
ユーザーとエージェントからのメッセージ、ツール呼び出し、ターミナル出力は、すべて一貫した意味を持つ安定した ID でパッチ適用されます。具体的には、省略されたフィールドは変更されず、null はクリアを意味し、値が指定された場合は置換され、チャンクは追加されるというルールです。また、メッセージ ID の指定も必須となり、これによりメッセージのストリーミングだけでなく、削除やその他の要件に応じて更新・置換も可能になります。
このパターンは従来ツール呼び出しにのみ適用されていましたが、現在はセッションアイテムのすべてのタイプで統一して採用され、一貫性と柔軟性が向上しました。さらに、メッセージのストリーミングパターンをツール呼び出しの内容にも適用したため、コンテンツ全体をバッファリングして繰り返し送信する必要がなくなり、スムーズなストリーミングが可能になりました。
Diff(差分)機能の刷新
従来の旧テキスト/新テキストによる差分表示は、構造化されたファイル変更形式に置き換えられました。これにより、「追加」「削除」「修正」「移動」「コピー」に加え、バイナリや非テキストファイルの場合も表現できるようになりました。一部の操作は従来構造でも推測可能でしたが、すべてをカバーすることはできませんでした。今回の改修により、エージェントがファイルシステムに対して行ったすべての変更を正確に報告することが可能になっています。
また、エージェントは任意で git_patch を提供することもできます。これはそのまますぐに表示できるほか、テキスト変更に対するクライアント側の美しい差分レンダリングも可能なほど構造化されています。
より柔軟な権限リクエスト
権限プロンプトには、必須のタイトルと任意の説明が含まれ、ハードコードされたツール呼び出しではなく拡張可能な対象を指定できます。これにより、将来的にターミナルコマンドやその他のオブジェクトに対する特別な権限リクエストも提供可能になります。また、タイトルと説明をツール呼び出し自体のタイトルやコンテンツから切り離すことで、ユーザーが判断を下す際により多くの文脈を提供できつつ、誤ってツール呼び出しそのものを上書きしてしまうリスクを防ぐことが可能です。
デフォルトでの将来互換性
v1 の大きな目標の一つは、ACP を拡張可能にすることでした。これは大成功を収め、多くの方がこの仕組みを使って素晴らしい機能を構築し、その一部がプロトコル自体にも取り込まれました。
v2 では、ツール開発時にさらなる実験や拡張ポイントを提供できるよう、ほぼあらゆるレイヤーで拡張が可能になりました。
スキーマ内の列挙型のような値は、実装固有の拡張のために _ プレフィックス付きの未知のバリアントを受け付けます。これはセッション設定オプションで成功したパターンを踏襲し、スキーマに直接組み込んだものです。これにより、新機能によって古いクライアントやエージェントが不明なネストデータで詰まることを防ぎ、必要に応じてプロトコルのさらに多くの部分を拡張するためのパターンを提供します。
草案ステータス
v2 は現在ドラフト版です。 私はスキーマのすべての行を少なくとも一度、多くは複数回確認しましたが、テストを開始するには十分な状態にあると考えています。ただし、安定化されるまでには、さまざまな部分が変更され、さらに変わる可能性があります。これがドラフト段階の目的であり、安定化する前にフィードバックを受けるためです。
実装を始める際は、バージョンネゴシエーションおよび機能フラグ(feature flags)で実装を制限してください。安定化に近づいてからでなければ、本番環境ではデフォルトでリリースしないでください。幸運にも、その間に大きな変更が必要ない可能性もありますが、必要な変更を進める過程でユーザーが混乱しないようにすることも重要です。
v2 のサポートを追加しても、v1 を捨てる必要はありません。v1 だけのピアはしばらくの間も一般的に残るため、実装者は両方のバージョンを並行してサポートする必要があります。各 SDK でこれを容易に表現できるよう、現在取り組んでいます。
多くの型はバージョン間で変更されていませんが、Agent、Client、または SDK を維持している場合は、移行ガイドで、事前と事後の例を交えた主要な変更点を確認できます。
着手地点
- v2 プロトコルドキュメントと移行ガイドを読んでください。
- SDK 作成者は、リポジトリのリリースで v1 と並行して公開されている v2.0.0-alphaX の v2 JSON スキーマに対して生成を行うことができます。
- v2 RFD コレクションには、大規模な変更の背後にある重要な決定が記録されています。
フィードバックを募集しています
フィードバックが最も大きな力を発揮するまさに今です。v2 の実装で何か問題があれば、安定化する前に教えてください。GitHub でイシューやディスカッションを開くか、RFD プロセス を通じて個別の RFD に参加してください。
v2 は、私たちが構築するためのはるかに優れた基盤を提供すると確信しています。これは過去 1 年間で得た知見をすべて取り込み、共通のパターンに集約したものであり、アジェンシーな未来を共に築いていく中で、より大きな柔軟性を可能にします。
ACP を活用してエージェントやクライアント、そして想像できるあらゆるものを構築してくださっている方がこれほど多いことに、私は驚嘆しています。これは大規模なコミュニティであり、新しいユースケースやアプリがこのプロトコルを採用するたびに、私の喜びは大きくなります。皆さんの創造性が私たちを前進させ、v2 で何ができるのか楽しみにしています。
Zed Industries / ACP リードメンテナ
AI算出
主要ニュースainew評価高い
ACP v2 のドラフト公開は、ターン中心モデルからの脱却やセッション状態の柔軟化など具体的な技術的変更を含んでおり、業界標準としての重大な更新であるため novelty は高く評価される。ただし、日本企業固有の情報や日本語一次情報がないため、日本の関連性は低めとなる。
6つの評価軸を見る
- AI関連度
- 100
- 情報源の信頼性
- 50
- 新規性
- 75
- 調べる価値
- 75
- 重複の少なさ
- 100
- 日本での有用性
- 25
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み