コーディングエージェント通信規格「ACP v2」ドラフト公開
ACPチームは、エージェントの背景処理やセッション状態の表現を強化し、コア動作を変更するバージョン2のプロトコルドラフトを発表した。
キーポイント
ターンベースから脱却
従来のユーザー発話に基づく「ターン」概念を超え、エージェントが背景で長時間作業を行ったり、セッション中に柔軟に状態を管理したりすることを可能にする設計変更が行われた。
RFDプロセスの活用とリリース戦略
v1での15以上のRFD（Request for Discussion）成功事例を踏まえ、新機能の実装をRFDプロセスに委ねつつ、v2ではコア動作の変更みに焦点を絞ってリリースする戦略が示された。
実装の柔軟性と一貫性の向上
エージェントとクライアント双方に大きな自由度を提供しつつ、必要な意味論的部分で合意形成を図り、セッション状態の表現やパターンを統合して一貫性を高めることが目指されている。
重要な引用
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.
The goal was to avoid cramming as much as possible into a v2 and it never landing.
Our core design goal remains to provide as much freedom as possible to both agents and clients in their implementations.
影響分析・編集コメントを表示
影響分析
このドラフト発表は、自律型エージェントの運用範囲を「ターンベース」から「継続的・背景処理型」へ拡大する重要な転換点となる。実装者にとっては、複雑なセッション管理や非同期処理の標準化が進むことで、開発負荷が軽減され、より高度なエージェントアプリケーションの実現が可能になる。
編集コメント
ACP v2のドラフト発表は、単なるバージョンアップではなく、現在のAIエージェントが抱える「セッション管理」や「非同期処理」の課題に対する明確な解決策を示しています。実装者が直面する混乱を解消し、より複雑なワークフローを標準化できる点は、業界全体にとって大きな前進です。
公開日： 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 リードメンテナ
原文を表示
Published: July 20, 2026
Today is a day the ACP team has been working towards for months, and we are excited to share the first Draft of version 2 of the Agent Client Protocol.
Since releasing v1, we have been able to leverage the future-compatible nature of the protocol and our RFD process to ship 15+ RFDs and their related features. A huge thank you to everyone who made this possible, and also proof that we can evolve the protocol rapidly without needing a huge migration every few months.
However, it also became clear while working with v1 that some breaking changes would unlock new use cases and features that are hard to express in the protocol as it is today. 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.
The goal was to avoid cramming as much as possible into a v2 and it never landing. So we are relying on our RFD process, that already worked so well in v1, to guide new features landing in both v1 and v2 as we move forward, and keep this release tightly focused on changing several core behaviors. If there is a new feature you really want, but don’t see here, that doesn’t mean it won’t be added. We just wanted to decouple the release cadence for features that would remain optional or additive anyway.
Our core design goal remains to provide as much freedom as possible to both agents and clients in their implementations, and agree on the semantically meaningful parts we need in order to do so. v2 enables allows even more flexibility in how an agent is able to work during a session, and also paves the way for new client patterns as well.
The Big Themes of v2
Moving beyond the turn
When we launched ACP v1, most agents happily emitted events only after a user-initiated message and usually stopped once they finished generating. But these days, agents are able to work longer and even orchestrate more and more work in the background. While the ACP v1 spec didn’t *prohibit* session/update notifications from coming outside of the turn, it was a common point of confusion for implementers, who usually wanted to guarantee interaction patterns around the idea of a user-initiated turn, but it is clear that enforcing this actually prevents useful behavior. An agent could be ready to receive new input while background events are happening, but it still wants to provide real-time updates for those as well. If we stick with a turn-focused orientation for prompts, neither side is happy.
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. Now session/update notifications can proceed freely at any point in the session, and a prompt response is the indication that the message was acknowledged by the agent, not the end of the turn. The agent will replay the user message where it inserted it, which also makes it easier for both replay and the potential for multiple clients observing the same session. The agent can indicate when it is “idle”, or ready to receive new inputs, allowing the client to indicate readiness, and agents can continue to update the session state in the meantime.
You can read more about this in the new prompt lifecycle RFD.
Updating Messages and Streaming Tool Calls
User and agent messages, tool calls, and terminal output are patched by stable IDs with uniform semantics: omitted fields stay unchanged, null clears, values replace, and chunks append. Message IDs are required as well so that messages can not only stream, but also update and replace in case of redaction or other needs.
This was a pattern that was only available for tool calls before, but now is uniformly used across these session item types to make things more consistent and flexible.
We also applied the message streaming pattern to tool call content, so that tool calls can be streamed in without buffering and resending the entire content over and over.
Diff Overhaul
The oldText/newText diff is replaced by structured file changes. You can now express add, delete, modify, move, copy, plus binary and non-text cases. Some of these could be inferred in the old structure, but not all, so we’ve hopefully made it possible to report all changes the agent makes on the filesystem.
The agent can also provide an optional git_patch for rendering the changes. This can be shown as is, but is also structured enough for clients to do nice diff rendering for text changes as well.
More flexible permission requests
Permission prompts carry their own required title and optional description, with an extensible subject instead of a hard-wired tool call. This also allows us to provide special permission requests for terminal commands or other objects in the future. And decoupling the title and description from the tool call’s title and content makes it possible to provide more context to the user making the decision without accidentally overriding the tool call itself.
Forward compatibility by default
One of the big goals in v1 was to make ACP extensible, which has been hugely successful. So many of you have built amazing features using these mechanisms, several of which have been upstreamed to the protocol itself.
v2 now makes it possible to extend at just about every layer you can think of to allow for more experimentation or extension points when building tooling on top.
Enum-like values across the schema accept unknown variants with a _ prefix for implementation-specific extensions. This builds on the successful pattern we added for session config options and embeds it right in the schema. This makes sure new features don’t cause older client and agents to choke on unknown nested data, and provides patterns for extending even more parts of the protocol where needed.
Draft status
v2 is a Draft. I personally went through every single line of the schema at least once, if not more, and I think it is in a solid state to start testing. However, various pieces can, and will, change before stabilization. That is the point of the draft stage: to receive feedback before we stabilize it.
As you start implementing it, gate your implementation behind the version negotiation AND feature flags. Don’t ship it by default in production until we are closer to stabilization. If we’re lucky, not much will need to change between now and then. But we also want to avoid causing pain for users while we all navigate the necessary changes.
Adding v2 support should not mean dropping v1. v1-only peers will remain common for some time, so implementers should support both versions side by side. We are working on making this easier to express in the various SDKs.
A majority of the types haven’t changed between versions, but if you maintain an Agent, Client, or SDK, the migration guide walks through the key changes you need to know with before/after examples.
Where to start
- Read the v2 protocol docs and the migration guide.
- SDK authors can generate against the v2 JSON schemas, published in the repository releases as v2.0.0-alphaX alongside v1.
- The v2 RFD collection records the key decisions behind the larger changes.
We want your feedback
This is exactly the moment where feedback has the most leverage. If something in v2 doesn’t work for your implementation, tell us before it stabilizes: open an issue or discussion on GitHub, or engage with the individual RFDs through the RFD process.
I firmly believe v2 provides a much better foundation for us to build on. It incorporates all of the learnings we’ve gained in the past year, consolidates on some common patterns, and allows for much more flexibility as we all build our agentic future together.
Overall, I am astounded by how many of you have been using ACP to build your agents, clients, and just about everything else you can imagine. It is a big tent, and every new use case or app that adopts it brings me joy. Your creativity keeps us going, and I am excited to see what you all can do with v2.
Zed Industries / ACP Lead Maintainer
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み