Version tiers
リリースと新バージョンを区別するものは何か？
新バージョン（4.0）は、変更がアーキテクチャ的なとき、前バージョンからの累積ドリフトがクリーンなベースラインがエコシステムに役立つほど大きいとき、または新世代を示す戦略的理由があるときに出荷されます。 リリース（3.x）は周縁でスキーマを変えられます — フィールドの required/optional ステータス、文書化されたエイリアス付きのリネームされたフィールド、厳格化された検証、同じリリースで置き換えが利用可能なオブジェクトの非推奨化。これらはビルダーがターゲットを絞った更新で吸収できる変更です。前方互換性
3.0 に対して構築された実装は、任意の 3.x リリースに対して機能し続けます。バージョン内のスキーマ変更は、書き直しではなくターゲットを絞った更新で吸収されるよう設計されています。Version negotiation
バイヤーとセラーは、すべてのリクエストとレスポンスで リリース精度（VERSION.RELEASE、例:"3.0"、"3.1"）で交渉します。リリース精度のピン留めは、バイヤー SDK がどのスキーマに対して検証するかを選べるようにし、セラーがバイヤーの期待するコントラクトに合わせて形作られたレスポンスを返せるようにします（Stripe モデル）。
ワイヤーを直接実装する社内クライアントは、3.x を通じてadcp_major_versionに留まれます。adcp_versionは 4.0 までオプトインです。ケイデンスについては Migration timeline を参照。
Bidirectional negotiation (3.1+)
- セラーがアドバタイズ:
get_adcp_capabilitiesレスポンスのadcp.supported_versionsが、セラーが話すすべてのリリース精度バージョンをリストする（例:["3.0", "3.1"]）。adcp.build_version（例:"3.1.2+vendor.42"）はインシデントトリアージ用の任意の助言的メタデータ — ワイヤーコントラクトの一部ではない。 - バイヤーが宣言: すべてのリクエストの
adcp_version（リリース精度文字列）が、バイヤーのペイロードがどのリリースに準拠するかをセラーに伝える。3.x を通じてバイヤーはadcp_major_versionも発すべき（SHOULD）で、整数のみを読むレガシー 3.x セラーが正しく交渉し続けられるようにする。 - サーバーが解決:
- 完全一致 → そのリリースで提供。
- 同じメジャー、プレリリースとリリースの両方が存在、バイヤーがリリースをピン → 完全一致が勝つ。サーバーは黙ってプレリリースにダウンシフトしてはならない（MUST NOT）。（サーバー
["3.1-beta", "3.1"]+ ピン"3.1"→"3.1"を提供。） - 同じメジャー、完全一致なし、少なくとも 1 つのサーバーリリース ≤ バイヤーのピン → ピン以下の最高のサポートリリースにダウンシフト。「サーバーの最大 < ピン」とギャップケース（例: サーバー
["3.0", "3.2"]+ ピン"3.1"→"3.0"を提供）の両方をカバー。 - 同じメジャー、バイヤーのピン以下のサーバーリリースなし（sub-min: すべてのサポートリリースが厳密に大きい） →
error.dataにsupported_versionsを伴うVERSION_UNSUPPORTEDを返す。 - 異なるメジャー →
error.dataにsupported_versionsを伴うVERSION_UNSUPPORTEDを返す。 - 省略 → サーバーはそのデフォルトリリースを使う（または、
adcp_major_versionのみが送られた場合、そのメジャーの最高のサポートリリース）。
- サーバーがエコー: すべてのレスポンスの
adcp_versionが、セラーが実際に提供したリリースをバイヤーに伝える。エコーされる値は 提供されたリリース であり、セラー自身の最新リリースではない — 3.0 で 3.0 バイヤーに提供する 3.1 セラーは"3.0"をエコーする。バイヤーは、自身のピンではなくそのリリースのスキーマに対してレスポンスを検証すべき（SHOULD）。
adcp_version を省略するとき（フィールドを読まないレガシー 3.0 セラー — additionalProperties: true がそこでそれを不可視にする）、バイヤーは自身のピンに対して検証し、ケイパビリティ推論についてはセラーを 3.0 のみとして扱うべき（SHOULD）。この場合、バイヤーの SDK はコンストラクターのピンにフォールバックする。
get_adcp_capabilities が完全に欠けているとき。 get_adcp_capabilities を公開しないセラー（そのツールが MCP ツールリスト、A2A スキルリスト、REST ツールインデックスにアドバタイズされない）は v3 以前の実装です — ツール自体が v3 以降。この場合バイヤーは v2 を推論し、リクエストを v2 ワイヤー形状アダプター経由でルーティングし、このセラーについてリトライ安全保証が不明であること（replay_ttl_seconds 宣言が利用できない）を示す一度限りの助言的警告を発すべき（SHOULD）。これは意図的な fail-open です: このシグナルで fail-closed にすると、最も一般的な採用パス — v2 ツールを出荷し v3 ディスカバリーを決して実装しなかったセラー — をブロックします。バイヤーは get_adcp_capabilities の欠如を肯定的な v2 適合性シグナルとして使ってはならない（MUST NOT）。それは純粋に「v3 ディスカバリーサーフェスが欠けている」からの推論です。冪等性、署名付きリクエスト、その他の v3 信頼プリミティブは不明として扱わなければならず（MUST）、それらの保証を必要とするバイヤーは、セラーがそれらをアドバタイズできないときアプリケーション層で fail-closed にしなければならない（MUST）。fail-open ルールはワイヤー形状アダプターにのみ適用され、ワイヤー形状が運ぶ信頼プリミティブには適用されません。
これにより、バイヤーとセラーは独立してアップグレードできます — セラーはマルチリリースサポートを宣言でき、バイヤーは移行を調整せずに特定のリリースにピン留めできます。
Pre-release pins
プレリリースタグ（"3.1-beta"、"3.1-rc.1"）は supported_versions に対して 正確に マッチされます。範囲解決されません: ["3.0", "3.1"] をリストするサーバー（リストに beta なし）に対して "3.1-beta" をピンするバイヤーは、"3.0" へのダウンシフトではなく VERSION_UNSUPPORTED を得ます。サーバーはリリースピンをプレリリースにダウンシフトしてはなりません（"3.1" → "3.1-beta"）（MUST NOT）。両方がアドバタイズされるとき、リリースが完全一致で勝ちます。
VERSION_UNSUPPORTED error data
セラーがピンを尊重できないとき、error.data は error-details/version-unsupported.json に従います:
supported_versions は権威的 — クライアントはこのリストから値を選んでリトライすべき（SHOULD）。SDK は黙ってリトライするのではなく型付きエラーを上げるべき（SHOULD）。自動ダウンシフトは呼び出し元の下でワイヤー形状を変えます。
Patches are not negotiated
3 ティアモデルに従い、パッチは安定 AdCP コントラクトの変更を導入しません — 安定サーフェスのバグ修正と明確化です。ワイヤーネゴシエーションフィールド（adcp_version）はリリース精度のみを使います。サーバーは運用可視性のために任意の build_version ケイパビリティ経由でビルドパッチをサーフェスしてもよい（MAY）が、バイヤーはそれをネゴシエーションに使ってはならない（MUST NOT）。実験的のみのパッチ変更は、パッチレベルのネゴシエーションではなく、experimental_features 宣言と下記の予告コントラクトによって統治されます。
build_version は、パッチコンポーネントが投入された有効な semver 文字列でなければならず（MUST）、semver §9–§10 に従って任意でプレリリースとビルドメタデータセグメントで拡張されます。例: "3.1.2"、"3.1.2+scope3.deploy.4821"、"3.1.0-beta.3+sha.a1b2c3d"。
adcp_version ワイヤー形状は MAJOR.MINOR または MAJOR.MINOR-PRERELEASE です。パッチコンポーネントはワイヤー上で有効でない、プレリリースタグと並んでいてもです。完全な semver（"3.1.0-beta.1"）を使って内部でバンドルをキー付けする SDK は、発する前にリリース精度（"3.1-beta.1"）に正規化しなければなりません（MUST）。"3.1.2"、"3.1.0-beta.1"、"v3.1"、"3" はすべて無効なワイヤー値で、検証によって拒否されます。
ワイヤーフィールドをバンドルメタデータと混同しないでください。 スキーマレジストリ、tarball マニフェスト、コンプライアンスインデックス、/protocol/ HTTP ディスカバリーエンドポイントはすべて、完全 semver 精度で published_version フィールド（例: "3.1.0-beta.1"）を公開します — それは公開されたアーティファクトのバージョンであり、ワイヤー値ではありません。@adcp/sdk.ComplianceIndex 互換性のため、レガシー adcp_version エイリアスも 3.x を通じてそれらのメタオブジェクトに存在し、4.0 でサンセットします。メタフィールド値をワイヤー上で決して発しない — 先にリリース精度に正規化してください。ディスカバリー URL については schemas-and-sdks を参照。
Major-precision negotiation (deprecated, kept through 3.x)
レガシーadcp_major_version（リクエストごとの整数）と adcp.major_versions（ケイパビリティ上の整数配列）は、後方互換性のため 3.x を通じて機能し続けます。新しいバイヤーとセラーはリリース精度ネゴシエーションを優先すべき（SHOULD）。両方のレガシーフィールドは 4.0 で削除されます。
3.x 中のデュアル発行: adcp_version を発するバイヤーは、同じリクエストで adcp_major_version（そのピンのメジャーコンポーネント付き）も発すべき（SHOULD）。これにより整数のみを読むレガシー 3.x セラーが正しく交渉し続けられます。両方のフィールドが存在しメジャーレベルで不一致のとき、サーバーはリクエストを不正な形式として扱い VERSION_UNSUPPORTED を返さなければなりません（MUST）。
メジャー精度のみが提供されるとき:
- バイヤーが
adcp_major_version: 3を送る → サーバーはメジャー 3 の最高のサポートリリースを提供。 - サーバーが
adcp.major_versions: [3]を発する → バイヤーはメジャー精度で交渉できるがリリースレベルの情報を失う。
Migration timeline
仕様は 3.x を通じて両側で SHOULD に留まります — フィールドがメジャー内で optional → required に卒業しないという 3.x 安定性保証と一致します。AdCP コンプライアンスグレーダーが 3.x 内で採用圧力を担います: 3.2 で認証を望むセラーはレスポンスエコーを出荷します。
まだ SDK に移行していない社内クライアントは、3.x を通じて
adcp_major_version のみを送り続けられます — サーバーがそれにフォールバックします。adcp_version の追加は 3.2 で認証可能な動作になります（グレーダー経由）。仕様自体は 4.0 までそれを要求しません。
Relationship to MCP protocolVersion
MCP は initialize ハンドシェイクに独自の protocolVersion フィールドを運びます（例: "2025-06-18"）。そのハンドシェイクは MCP ワイヤー をバージョン管理します — JSON-RPC フレーミング、トランスポートセマンティクス。AdCP adcp_version は AdCP ペイロード をバージョン管理します — params と result コンテンツのスキーマ。2 つは独立: MCP-2025-06-18 サーバーは AdCP 3.0 または 3.1 を話せ、AdCP "3.1" をピンする MCP クライアントは、MCP ハンドシェイクが成功しても 3.0 のみを話すサーバーに対して VERSION_UNSUPPORTED で失敗します。A2A には MCP initialize に相当するものがなく、それが adcp_version がペイロードに乗る理由です（両トランスポートがそれを運べる場所）。
Features over versions
バージョンネゴシエーションはメジャーなアーキテクチャ境界を扱います。機能レベルの互換性については、代わりにケイパビリティモデルを使います。セラーは特定の機能、ターゲティングシステム、実行統合、拡張をget_adcp_capabilities で宣言します。バイヤーは必要なケイパビリティを確認し、それらが存在すれば続行します。
特定のメジャーバージョンのすべてのセラーがすべての機能をサポートするわけではありません。すべてのバイヤーがすべての機能を必要とするわけではありません。ケイパビリティコントラクトはこうです: 宣言されたら、セラーはそれを尊重しなければならない（MUST）。これはバージョン番号だけよりも細かい粒度の互換性を与えます。
完全なケイパビリティリファレンスについては get_adcp_capabilities を参照。
Schema changes in releases: scope and limits
スキーマ変更は、次の条件の下でリリースで受け入れられます: リリースのスコープ内:- フィールドを optional から required に変更（またはその逆）
- 同じリリースで文書化されたエイリアスと移行ノート付きでフィールドをリネーム
- 既存パラメーターの検証ルールを厳格化（before/after の例で文書化）
- 同じリリースで置き換えが出荷されるときオブジェクトやメソッドを非推奨化
- プロトコルのアーキテクチャ的または構造的な再設計
- 事前の非推奨リリースなしにフィールドやメソッドを削除
- 認証、トランスポート、コアセキュリティ要件の変更
- 基本的な動作セマンティクスを変える変更
Deprecation policy
非推奨予告は、任意の機能が削除される前に少なくとも 6 か月 公開されます。非推奨機能は、非推奨化後少なくとも 1 つの完全なリリースサイクル機能し続け、同じメジャーバージョン内で決して削除されません — 3.x で非推奨化された機能は、早くても 4.0 まで削除されません。 スキーマ変更を伴うすべてのリリースは、チェンジログ、リリースノート、インラインドキュメントで言及されます。スキーマ変更を伴うすべてのリリースは移行ガイドとともに出荷されます。 実験的サーフェス は、6 週間の別個のより速い予告ウィンドウの下で動作します。上記の非推奨ポリシーは安定サーフェスにのみ適用されます。Spec, registry, conformance, and experimental changes
上記のリリース対パッチのルールは 仕様レベルのアーティファクト に適用されます —static/schemas/source/ の下の JSON Schema、docs/ の規範的な散文、プロトコルタスク定義。これらは、エージェントがワイヤー上で実装するもの、バイヤーが相互運用のために依存するものです。
AgenticAdvertising.org レジストリ API とフィードトランスポートは、adcontextprotocol とは別にバージョン管理されます。レジストリ OpenAPI ドキュメント、レジストリ公開ポリシーファイル、レジストリフィードトランスポートスキーマへの変更は、それらが安定 AdCP タスクペイロード、ネゴシエーションフィールド、コンプライアンスアーティファクト、規範的プロトコルルールも変えない限り、それ自体では adcontextprotocol パッケージバージョンを上げません。static/schemas/source/ の下のレジストリ JSON Schema は、レビュアーがトランスポート形状の変更を見られるよう changeset スコープゲートによって追跡されたままですが、それらのリリース分類は、安定 AdCP セマンティクスに踏み込まない限りレジストリサーフェスに属します。
適合性スイート — ストーリーボード、専門分野タクソノミー、シナリオ分類、ランナーメカニクス — は独立してバージョン管理され、デフォルトでパッチレベル です。適合性スイートは AAO が保守する検証アーティファクトです。仕様でもドキュメントでもありません。プレビューステータスの専門分野の追加、削除、リネーム、再分類、universal/protocol/specialism ディレクトリ間のストーリーボードの移動、シナリオカバレッジのリファクタリング、変更されていない仕様に合わせたランナー動作の調整はすべてパッチ変更です。
適合性スイートの変更は、エージェントがワイヤー上でしなければならないことを変える場合にのみマイナーまたはメジャーにエスカレートします — すなわち、暗黙の仕様検証を厳格化する、存在しなかった新しいケイパビリティをセラーにアドバタイズさせる、またはエージェントが積極的に主張している安定した専門分野を削除する（現在それをアドバタイズしているエージェントが非準拠になるため破壊的）とき。
この分離により、レジストリトランスポート、検証機構、実験的フィードバックサーフェスが、安定した仕様レベルのバージョニングを引きずることなく素早く進化できます。
3.x stability guarantees
3.0 に対して構築された実装は、3.x サイクルを通じて次の安定サーフェス保証に依存できます。実験的サーフェスは下記の予告とパッチ分類ルールに従います。Experimental surfaces
上の表の安定性保証は安定サーフェスにのみ適用されます。AdCP は、コアプロトコルの一部だがまだ凍結されていないサーフェスを 実験的 として公開することがあります。実験的サーフェスはそのスキーマでx-status: experimental とマークされ、それらを実装するセラーは get_adcp_capabilities の experimental_features 経由でそう宣言します。
実験的サーフェスは、リリースノートで少なくとも 6 週間の予告をもって、任意の 2 つの 3.x リリース間で壊れることがあります（MAY）。実験的のみのスキーマ変更は、安定 AdCP タスクペイロード、ネゴシエーションフィールド、コンプライアンスアーティファクト、規範的プロトコルルールを変えないときパッチレベルです。採用者は実験的機能を宣言することでそのより速い動きにオプトインします。歴史的なプレリリースノートは実験的な再形成をマイナーと分類したかもしれませんが、このポリシーはリリースティアを安定サーフェスへの影響 + 実験的予告義務として扱います。実験的サーフェスは、実世界のシグナルを実証したら安定版に卒業します — 卒業基準、予告要件、クライアントガイダンスについては完全な 実験的ステータスコントラクト を参照。
実験的ステータスは意図的にスコープされています。サーフェスが実験的とマークされていない場合、上記の 3.x 保証が適用されます。
Patch releases
パッチリリース（3.0.1、3.1.2）は、ドキュメント、表現、文書化された安定仕様から逸脱していた検証、レジストリバージョン管理アーティファクト、適合性スイートアーティファクト、または実験的のみのサーフェスのみを変えます。安定 AdCP サーフェスについて、パッチは決してスキーマを変えません — 新しいフィールドなし、リネームされたフィールドなし、新しい enum 値なし。現在のリリースの最新パッチへのアップグレードは、安定 AdCP サーフェスについて常に安全です。実験的採用者は、宣言した実験的機能のリリースノートにも従わなければなりません。
Security fixes
セキュリティ関連の修正は、security ラベル付きでリリースノートに文書化され、現在のリリースに着地します。実装はセキュリティ勧告の後速やかにアップグレードすべき（SHOULD）。3.x 内の古いリリースは定期的なバックポートを受け取りません。現在のリリースへのアップグレードが期待される修正パスです。同じ姿勢がセキュリティのみのウィンドウ中の v2 に適用されます — そのタイムラインについては v2 sunset ページ を参照。
Breaking-change notice
実装に適応を要求する任意の変更 — リネームされたフィールド、required-to-optional 遷移、厳格化された検証 — は、次のすべてとともに出荷されます:Schema publication at merge
最新の公開タグは、常にソース HEAD と同じ required フィールドセットを反映しなければなりません。任意のrequired 配列を変える、判別子 const を変える、または検証制約を厳格化する PR は、変更が外部コンシューマーのアクティブな実装ターゲットになる前に、新しいタグをカットして伴わなければなりません。これは任意の上流義務に加えてです — 例えば、上記の安定性保証で記述された optional→required 遷移の非推奨要件。
なぜ: 実装者は公開タグに対して検証します（正確なバージョンにピン留めするか、バージョンエイリアス を通じて解決するか）。ソース HEAD の required フィールドがそのタグが宣言するものを超えて増えると、ソースを読むエバリュエーターと公開タグを読む実装者の検証器が不一致になります — どちらかが間違っているからではなく、公開されたコントラクトが追いついていないからです。実装者はソース履歴を読まずにギャップを調停できません。
RC サイクル中: 同じ不変条件が RC タグ間に適用されます。rc.N と rc.N+1 の間に着地するスキーマ変更は、新しい required フィールドセットがアクティブとして扱われる前に rc.N+1 をカットすることを要求します。
CI 強制が整うまで: PR 作成者は、変更がエバリュエーターに伝播する前に新しいリリースまたは RC タグをカットする責任があります。レビュアーは、新しいタグが公開準備できていることを確認せずに、required 配列、判別子 const、または検証制約を変える PR を承認すべきではありません。
Release cadence
AdCP は、実装者が計画できるよう次の名前付きポリシーを公開します:
バージョン内では、リリースはサイクル初期に 6〜8 週間ごとに着地し、バージョンが安定するにつれ四半期に向けて伸びます。バージョン内のリリース数は固定されていません。
Support window for previous major
新しいメジャーが出荷されると、前のメジャーは後継 GA の後少なくとも 12 か月間セキュリティパッチを受け取ります。セキュリティパッチ（CVE 修正とセキュリティ勧告）は全ウィンドウでバックポートされます。機能作業はされません。各バージョンの正確な EOL 日付はバージョンごとのサンセットページで公開され、後継の GA リリースに伴う遷移ノートからリンクされます。 非推奨ウィンドウは、非推奨機能が変更されてもリセットされません — 元の削除日が保たれます。 v2 サンセットは、このコミットメントの文書化された例外です: v2 はこのポリシーに先行し、バックポートできないアカウントとガバナンスの保護を欠きます。そのセキュリティのみのウィンドウは 2026 年 8 月 1 日まで走ります — v2 sunset ページ を参照。将来のメジャーはこの例外を呼び出しません。Planned releases
さらなる 3.x リリースは、実装フィードバックとワーキンググループの優先事項に基づき、リリース間に少なくとも 8 週間空けてスケジュールされます。各リリースの計画されたスコープは GitHub マイルストーンページ で追跡されます —
3.1.0 と 3.2.0 マイルストーンのオープン issue は、固定されたコミットメントではなく現在の候補作業を反映します。
Extensibility
AdCP は 3 レベルのスキーマ拡張を区別します。下記のルールは、タスクリファレンスページが別途述べない限り、すべての AdCP スキーマに適用されます。
起こってはならないこと:
ext.{namespace}の代わりにレスポンススキーマに新しいトップレベルプロパティを導入すること。extの外にフィールドが必要な実装者は、そのフィールドをワーキンググループに提案しなければならない（MUST）。- コアフィールドをインラインでリネームすること。エイリアスは仕様レベルの操作であり、実装者の操作ではない。
- コアフィールドの検証をローカルで厳格化すること。より厳格な検証が必要な実装者は、発する前または受け取った後にそれを実行する — ワイヤースキーマではない。
ext.{namespace} は、誰もが協調なしに素早く動ける場所です。
Adding to the core protocol
フィールドやタスクは、次のパスの 1 つを通じてコアプロトコルに入ります:- リリース追加。 加算的変更（新しい任意フィールド、新しいタスク、新しい enum 値）は通常のリリースプロセスの下で 3.x リリースで出荷されます。これらは出荷されたリリースから安定です。
- 実験的追加。 ワーキンググループがフィードバックのために出荷したいがまだ凍結する用意がないサーフェスは、実験的としてプロトコルに入ります — 実験的ステータス を参照。実験的サーフェスは安定版に卒業するか削除されます。恒久的な実験的状態はありません。
- バージョン境界。 現在のバージョンと互換でない変更は次のメジャーのために保留されます。リリースのスコープ内外については schema changes in releases を参照。
Governance
AdCP の開発は ワーキンググループ を中心に組織され、それぞれが特定のプロトコルドメイン（クリエイティブ、ガバナンス、メディアバイ、シグナル、ブランド、sponsored intelligence）に焦点を当てます。ワーキンググループは機能提案を推進し、実装フィードバックをサーフェスし、その領域の方向を形作ります。横断的な設計決定 — ドメイン間の一貫性、ワーキンググループ間の衝突、共有プリミティブ — は、閉じたドアの背後ではなく、ワーキンググループフォーラムと GitHub の公開 issue で解決されます。 ワーキンググループは次を通じて貢献します:- 提案と技術的議論のための GitHub Discussions
- リアルタイムコラボレーションのための Slack チャネル
- AdCP 上に構築する組織からの メンバーフィードバック
- 設計決定を検証する リファレンス実装