> ## Documentation Index
> Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# バージョニングとガバナンス

> AdCP がリリースをどうバージョン管理し、スキーマ変更を管理し、プロトコルの進化を統治するか。

AdCP は 3 ティアの番号付けシステムを使います: **VERSION.RELEASE.PATCH**（例: 3.1.2）。

***

## Version tiers

| Tier        | Example     | Description                                                                                                      |
| ----------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |
| **Version** | 3.0 → 4.0   | プロトコルの新しい世代。単一の機能ではなく、前のサイクルにわたって蓄積されたアーキテクチャ変更を反映。エコシステムのためのクリーンなベースラインを示す。                                     |
| **Release** | 3.0 → 3.1   | 新しいフィールド、新しいケイパビリティ、またはプロトコルのアーキテクチャを変えない小さなスキーマ変更。既存の実装に周縁で影響することがある。                                           |
| **Patch**   | 3.1 → 3.1.1 | バグ修正、明確化、訂正。安定 AdCP サーフェスについて常にアップグレードが安全。パッチは安定仕様から逸脱した動作を訂正するが、新しい安定ケイパビリティを導入しない。実験的のみのパッチは下記の実験的予告コントラクトに従う。 |

### リリースと新バージョンを区別するものは何か？

新バージョン（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](#migration-timeline) を参照。

### Bidirectional negotiation (3.1+)

1. **セラーがアドバタイズ**: `get_adcp_capabilities` レスポンスの `adcp.supported_versions` が、セラーが話すすべてのリリース精度バージョンをリストする（例: `["3.0", "3.1"]`）。`adcp.build_version`（例: `"3.1.2+vendor.42"`）はインシデントトリアージ用の任意の助言的メタデータ — ワイヤーコントラクトの一部ではない。
2. **バイヤーが宣言**: すべてのリクエストの `adcp_version`（リリース精度文字列）が、バイヤーのペイロードがどのリリースに準拠するかをセラーに伝える。3.x を通じてバイヤーは `adcp_major_version` も発すべき（SHOULD）で、整数のみを読むレガシー 3.x セラーが正しく交渉し続けられるようにする。
3. **サーバーが解決**:
   * 完全一致 → そのリリースで提供。
   * 同じメジャー、プレリリースとリリースの両方が存在、バイヤーがリリースをピン → 完全一致が勝つ。サーバーは黙ってプレリリースにダウンシフトしてはならない（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` のみが送られた場合、そのメジャーの最高のサポートリリース）。
4. **サーバーがエコー**: すべてのレスポンスの `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`](https://github.com/adcontextprotocol/adcp/blob/main/static/schemas/source/error-details/version-unsupported.json) に従います:

```json theme={null}
{
  "adcp_version": "4.0",
  "adcp_major_version": 4,
  "supported_versions": ["3.0", "3.1"],
  "supported_majors": [3],
  "build_version": "3.1.2+vendor.42"
}
```

`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](https://semver.org/#spec-item-9) に従って任意でプレリリースとビルドメタデータセグメントで拡張されます。例: `"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](/docs/building/schemas-and-sdks#version-discovery) を参照。

### 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 で認証を望むセラーはレスポンスエコーを出荷します。

| Phase          | Spec — buyer                                              | Spec — seller                                                                                    | Compliance grader                                                           |
| -------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
| **3.1（加算的出荷）** | `adcp_version` を発すべき（`adcp_major_version` ミラー付き）。         | `adcp_version` を尊重しエコーすべき。ケイパビリティに `supported_versions` を発すべき。                                   | 助言的: リクエストとレスポンスの存在をレポート。                                                   |
| **3.2**        | （3.1 から変更なし）                                              | （3.1 から変更なし）                                                                                     | セラーが `adcp_version` をエコーしないか、ケイパビリティに `supported_versions` を発しないときブロッキング失敗。 |
| **4.0**        | `adcp_version` を発しなければならない（MUST）。`adcp_major_version` 削除。 | `adcp_version` を尊重しエコーしなければならない（MUST）。`adcp.major_versions` と `extensions.adcp.adcp_version` 削除。 | 欠如でブロッキング失敗。レガシーフィールド拒否。                                                    |

まだ 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`](/docs/protocol/get_adcp_capabilities) を参照。

***

## Schema changes in releases: scope and limits

スキーマ変更は、次の条件の下でリリースで受け入れられます:

**リリースのスコープ内:**

* フィールドを optional から required に変更（またはその逆）
* 同じリリースで文書化されたエイリアスと移行ノート付きでフィールドをリネーム
* 既存パラメーターの検証ルールを厳格化（before/after の例で文書化）
* 同じリリースで置き換えが出荷されるときオブジェクトやメソッドを非推奨化

**スコープ外 — バージョンレベルの変更のみ:**

* プロトコルのアーキテクチャ的または構造的な再設計
* 事前の非推奨リリースなしにフィールドやメソッドを削除
* 認証、トランスポート、コアセキュリティ要件の変更
* 基本的な動作セマンティクスを変える変更

### Deprecation policy

非推奨予告は、任意の機能が削除される前に少なくとも **6 か月** 公開されます。非推奨機能は、非推奨化後少なくとも 1 つの完全なリリースサイクル機能し続け、同じメジャーバージョン内で決して削除されません — 3.x で非推奨化された機能は、早くても 4.0 まで削除されません。

スキーマ変更を伴うすべてのリリースは、チェンジログ、リリースノート、インラインドキュメントで言及されます。スキーマ変更を伴うすべてのリリースは移行ガイドとともに出荷されます。

[実験的サーフェス](/docs/reference/experimental-status) は、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 ディレクトリ間のストーリーボードの移動、シナリオカバレッジのリファクタリング、変更されていない仕様に合わせたランナー動作の調整はすべてパッチ変更です。

適合性スイートの変更は、エージェントがワイヤー上でしなければならないことを変える場合にのみマイナーまたはメジャーにエスカレートします — すなわち、暗黙の仕様検証を厳格化する、存在しなかった新しいケイパビリティをセラーにアドバタイズさせる、またはエージェントが積極的に主張している安定した専門分野を削除する（現在それをアドバタイズしているエージェントが非準拠になるため破壊的）とき。

| Change                                                                  | Tier                        |
| ----------------------------------------------------------------------- | --------------------------- |
| 既存ケイパビリティに新しい universal ストーリーボードを追加                                     | Patch                       |
| ストーリーボードをディレクトリ間で移動（`specialisms/{id}/` → `universal/` など）              | Patch                       |
| プレビューステータスの専門分野を再分類（グレードされたユーザーなし）                                      | Patch                       |
| 既存ストーリーボード内にシナリオを追加                                                     | Patch                       |
| 予告コントラクトの下で実験的のみのスキーマを変更、安定 AdCP タスクペイロード/ネゴシエーション/コンプライアンス/規範的ルールの変更なし | Patch                       |
| enum に新しい安定した専門分野を追加                                                    | Minor（エージェントができる新しいクレーム）    |
| enum から安定した専門分野を削除                                                      | Major（現在それを主張しているエージェントを壊す） |
| リクエスト/レスポンススキーマに新しいエラーコードまたは新しい任意フィールドを追加                               | Minor                       |

この分離により、レジストリトランスポート、検証機構、実験的フィードバックサーフェスが、安定した仕様レベルのバージョニングを引きずることなく素早く進化できます。

***

## 3.x stability guarantees

3.0 に対して構築された実装は、3.x サイクルを通じて次の安定サーフェス保証に依存できます。実験的サーフェスは下記の予告とパッチ分類ルールに従います。

| Artifact                | Guarantee within 3.x                                                                        |
| ----------------------- | ------------------------------------------------------------------------------------------- |
| **Fields**              | 決して削除されない。同じリリースで両方の名前を受け入れる文書化されたエイリアス付きでリネームされることがある。optional → required は事前の非推奨リリースの後のみ。 |
| **Enums**               | 加算的のみ。既存の値は決して削除もリネームもされない。クライアントは未知の値を許容し、賢明なデフォルトにフォールバックしなければならない。                       |
| **Error codes**         | 加算的のみ。既存のコードはそのセマンティクスを保持。未知のエラーコードを汎用的に扱うクライアントは互換のまま。                                     |
| **Task names**          | 決して削除もリネームもされない。新しいタスクが追加されることがある。                                                          |
| **認証、トランスポート、コアセキュリティ** | 決して変わらない。これらはバージョンレベルの変更のみ。                                                                 |

### Experimental surfaces

上の表の安定性保証は安定サーフェスにのみ適用されます。AdCP は、コアプロトコルの一部だがまだ凍結されていないサーフェスを **実験的** として公開することがあります。実験的サーフェスはそのスキーマで `x-status: experimental` とマークされ、それらを実装するセラーは `get_adcp_capabilities` の `experimental_features` 経由でそう宣言します。

実験的サーフェスは、リリースノートで少なくとも 6 週間の予告をもって、任意の 2 つの 3.x リリース間で壊れることがあります（MAY）。実験的のみのスキーマ変更は、安定 AdCP タスクペイロード、ネゴシエーションフィールド、コンプライアンスアーティファクト、規範的プロトコルルールを変えないときパッチレベルです。採用者は実験的機能を宣言することでそのより速い動きにオプトインします。歴史的なプレリリースノートは実験的な再形成をマイナーと分類したかもしれませんが、このポリシーはリリースティアを安定サーフェスへの影響 + 実験的予告義務として扱います。実験的サーフェスは、実世界のシグナルを実証したら安定版に卒業します — 卒業基準、予告要件、クライアントガイダンスについては完全な [実験的ステータスコントラクト](/docs/reference/experimental-status) を参照。

実験的ステータスは意図的にスコープされています。サーフェスが実験的とマークされていない場合、上記の 3.x 保証が適用されます。

### Patch releases

パッチリリース（`3.0.1`、`3.1.2`）は、ドキュメント、表現、文書化された安定仕様から逸脱していた検証、レジストリバージョン管理アーティファクト、適合性スイートアーティファクト、または実験的のみのサーフェスのみを変えます。安定 AdCP サーフェスについて、パッチは決してスキーマを変えません — 新しいフィールドなし、リネームされたフィールドなし、新しい enum 値なし。現在のリリースの最新パッチへのアップグレードは、安定 AdCP サーフェスについて常に安全です。実験的採用者は、宣言した実験的機能のリリースノートにも従わなければなりません。

### Security fixes

セキュリティ関連の修正は、`security` ラベル付きでリリースノートに文書化され、現在のリリースに着地します。実装はセキュリティ勧告の後速やかにアップグレードすべき（SHOULD）。3.x 内の古いリリースは定期的なバックポートを受け取りません。現在のリリースへのアップグレードが期待される修正パスです。同じ姿勢がセキュリティのみのウィンドウ中の v2 に適用されます — そのタイムラインについては [v2 sunset ページ](/docs/reference/v2-sunset) を参照。

### Breaking-change notice

実装に適応を要求する任意の変更 — リネームされたフィールド、required-to-optional 遷移、厳格化された検証 — は、次のすべてとともに出荷されます:

* 移行ノート付きの [リリースノート](/docs/reference/release-notes) のエントリ
* [チェンジログ](/docs/reference/changelog) のエントリ
* [移行ガイド](/docs/reference/migration) のセクションまたは専用の深掘りページ
* 可能な場合、変更を導入するリリースで新旧両名を受け入れるエイリアス

### Schema publication at merge

最新の公開タグは、常にソース HEAD と同じ required フィールドセットを反映しなければなりません。任意の `required` 配列を変える、判別子 `const` を変える、または検証制約を厳格化する PR は、変更が外部コンシューマーのアクティブな実装ターゲットになる前に、新しいタグをカットして伴わなければなりません。これは任意の上流義務に加えてです — 例えば、上記の安定性保証で記述された optional→required 遷移の非推奨要件。

**なぜ:** 実装者は公開タグに対して検証します（正確なバージョンにピン留めするか、[バージョンエイリアス](/docs/building/schemas-and-sdks#schema-versioning) を通じて解決するか）。ソース HEAD の required フィールドがそのタグが宣言するものを超えて増えると、ソースを読むエバリュエーターと公開タグを読む実装者の検証器が不一致になります — どちらかが間違っているからではなく、公開されたコントラクトが追いついていないからです。実装者はソース履歴を読まずにギャップを調停できません。

**RC サイクル中:** 同じ不変条件が RC タグ間に適用されます。`rc.N` と `rc.N+1` の間に着地するスキーマ変更は、新しい required フィールドセットがアクティブとして扱われる前に `rc.N+1` をカットすることを要求します。

**CI 強制が整うまで:** PR 作成者は、変更がエバリュエーターに伝播する前に新しいリリースまたは RC タグをカットする責任があります。レビュアーは、新しいタグが公開準備できていることを確認せずに、`required` 配列、判別子 `const`、または検証制約を変える PR を承認すべきではありません。

***

## Release cadence

AdCP は、実装者が計画できるよう次の名前付きポリシーを公開します:

| Commitment             | Window      |
| ---------------------- | ----------- |
| **メジャーリリース（破壊的）**      | 最小 18 か月間隔  |
| **次のメジャー（4.0）**        | 2027 年初頭を目標 |
| **後継 GA 後の前メジャーのサポート** | 最小 12 か月    |
| **削除前の非推奨予告**          | 最小 6 か月     |

バージョン内では、リリースはサイクル初期に 6〜8 週間ごとに着地し、バージョンが安定するにつれ四半期に向けて伸びます。バージョン内のリリース数は固定されていません。

### Support window for previous major

新しいメジャーが出荷されると、前のメジャーは後継 GA の後少なくとも 12 か月間セキュリティパッチを受け取ります。セキュリティパッチ（CVE 修正とセキュリティ勧告）は全ウィンドウでバックポートされます。機能作業はされません。各バージョンの正確な EOL 日付はバージョンごとのサンセットページで公開され、後継の GA リリースに伴う遷移ノートからリンクされます。

非推奨ウィンドウは、非推奨機能が変更されてもリセットされません — 元の削除日が保たれます。

v2 サンセットは、このコミットメントの文書化された例外です: v2 はこのポリシーに先行し、バックポートできないアカウントとガバナンスの保護を欠きます。そのセキュリティのみのウィンドウは 2026 年 8 月 1 日まで走ります — [v2 sunset ページ](/docs/reference/v2-sunset) を参照。将来のメジャーはこの例外を呼び出しません。

### Planned releases

| Release | Target                       |
| ------- | ---------------------------- |
| **3.0** | 2026 年 4 月 — GA リリース         |
| **3.1** | 2026 年 6 月下旬                 |
| **3.2** | 2026 年 9 月下旬                 |
| **4.0** | 2027 年初頭 — 次のメジャー、蓄積された破壊的変更 |

さらなる 3.x リリースは、実装フィードバックとワーキンググループの優先事項に基づき、リリース間に少なくとも 8 週間空けてスケジュールされます。各リリースの計画されたスコープは [GitHub マイルストーンページ](https://github.com/adcontextprotocol/adcp/milestones) で追跡されます — `3.1.0` と `3.2.0` マイルストーンのオープン issue は、固定されたコミットメントではなく現在の候補作業を反映します。

***

## Extensibility

AdCP は 3 レベルのスキーマ拡張を区別します。下記のルールは、タスクリファレンスページが別途述べない限り、すべての AdCP スキーマに適用されます。

| Surface                                     | Who may extend                           | How                                                                                                                                                                         |
| ------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| プロトコルが定義する **コアフィールド**                      | ワーキンググループ、リリース経由                         | ワーキンググループで提案され、通常のリリースプロセスを通じて受け入れられる。実装者によってインラインで拡張されることは決してない。                                                                                                           |
| 任意のリクエスト/レスポンスオブジェクトの **`ext.{namespace}`** | 誰でも、`extensions_supported` に名前空間を宣言することで | 名前空間化、帯域外、ベースライン相互運用に影響しない。名前空間は [拡張レジストリ](/docs/building/by-layer/L2/context-sessions#extensions) に登録すべき（SHOULD）。                                                          |
| それを許すコンテナの **`additionalProperties: true`** | 誰でも                                      | 宣言された位置での加算的フィールド。コアフィールドをシャドウしたり再定義したりしてはならない（MUST NOT）。読み取り者はエラーにするのではなく未知のフィールドを無視しなければならない（MUST）。追加フィールドが後のリリースで定義されたコアフィールドと名前で衝突するとき、読み取り者はコアフィールドを優先しなければならない（MUST）。 |

**起こってはならないこと:**

* `ext.{namespace}` の代わりにレスポンススキーマに新しいトップレベルプロパティを導入すること。`ext` の外にフィールドが必要な実装者は、そのフィールドをワーキンググループに提案しなければならない（MUST）。
* コアフィールドをインラインでリネームすること。エイリアスは仕様レベルの操作であり、実装者の操作ではない。
* コアフィールドの検証をローカルで厳格化すること。より厳格な検証が必要な実装者は、発する前または受け取った後にそれを実行する — ワイヤースキーマではない。

この分離が、すべての非準拠実装が断片化のクレームにならずに仕様を進化させられる理由です。ワイヤーコントラクトは狭く予測可能なまま保たれます。`ext.{namespace}` は、誰もが協調なしに素早く動ける場所です。

### Adding to the core protocol

フィールドやタスクは、次のパスの 1 つを通じてコアプロトコルに入ります:

1. **リリース追加。** 加算的変更（新しい任意フィールド、新しいタスク、新しい enum 値）は通常のリリースプロセスの下で 3.x リリースで出荷されます。これらは出荷されたリリースから安定です。
2. **実験的追加。** ワーキンググループがフィードバックのために出荷したいがまだ凍結する用意がないサーフェスは、実験的としてプロトコルに入ります — [実験的ステータス](/docs/reference/experimental-status) を参照。実験的サーフェスは安定版に卒業するか削除されます。恒久的な実験的状態はありません。
3. **バージョン境界。** 現在のバージョンと互換でない変更は次のメジャーのために保留されます。リリースのスコープ内外については [schema changes in releases](#schema-changes-in-releases-scope-and-limits) を参照。

***

## Governance

AdCP の開発は **[ワーキンググループ](/docs/community/working-group)** を中心に組織され、それぞれが特定のプロトコルドメイン（クリエイティブ、ガバナンス、メディアバイ、シグナル、ブランド、sponsored intelligence）に焦点を当てます。ワーキンググループは機能提案を推進し、実装フィードバックをサーフェスし、その領域の方向を形作ります。横断的な設計決定 — ドメイン間の一貫性、ワーキンググループ間の衝突、共有プリミティブ — は、閉じたドアの背後ではなく、ワーキンググループフォーラムと GitHub の公開 issue で解決されます。

ワーキンググループは次を通じて貢献します:

* 提案と技術的議論のための **GitHub Discussions**
* リアルタイムコラボレーションのための **Slack チャネル**
* AdCP 上に構築する組織からの **メンバーフィードバック**
* 設計決定を検証する **リファレンス実装**

プロトコルとその実装基盤が成熟するにつれ、ドメインリードは自身の領域の所有権をますます引き受けます。

***

## Additional resources

* **[バージョンと互換性](/docs/reference/versions)** — 公開されたすべてのバージョンの一目でのステータス
* **[仕様ライフサイクル](/docs/reference/specification-lifecycle)** — ステージ定義（Draft → Proposed → Final → Deprecated → Sunset）、参入基準、仕様セクションの現在のステージの確認方法
* **[ロードマップ](/docs/reference/roadmap)** — 計画された機能とマイルストーン
* **[リリースノート](/docs/reference/release-notes)** — 何が出荷されたか、移行ガイド付き
* **[チェンジログ](/docs/reference/changelog)** — 技術変更履歴