> ## 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 が、仕様に含まれるがまだ凍結されていないサーフェスをどう印付けるか。実験的が実装者にとって何を意味するか、3.x 内で何が変わるか、実験的サーフェスがどう安定版に卒業するか。

一部の AdCP サーフェスは、リリースに公開されるがまだ凍結されていません。実装者がそれらに対して構築を始められるよう出荷されますが、安定サーフェスよりも弱い安定性コントラクトを運びます。このページはそのコントラクトを定義します。

実験的ステータスは、[3.x 安定性保証](/docs/reference/versioning#3x-stability-guarantees)を信頼に足るものに保つ安全弁です。サーフェスは安定 — その場合 3.x 内で壊れることができない — か、明示的に実験的 — その場合壊れることができる — のいずれかです。宣言されていない中間地帯はありません。プロトコルの非目標と延期項目のリストについては [既知の制限](/docs/reference/known-limitations) を参照。

***

## 何が実験的と見なされるか

AdCP サーフェスは、次の両方が真のとき実験的です:

1. そのスキーマが、スキーマルートまたは特定のプロパティに `x-status: experimental` を運ぶ。
2. それを実装するセラーが、その `get_adcp_capabilities` レスポンスの `experimental_features` にそのサーフェスを宣言する。

両方のマーカーが必要です。1 つ目はエコシステムにサーフェスが凍結されていないことを伝えます。2 つ目は特定のバイヤーに、この特定のセラーがこのサーフェスについて実験的コントラクトにオプトインしたことを伝えます。

任意の実験的サーフェスを実装するセラーは、それを `experimental_features` にリストしなければなりません（MUST）。実験的サーフェスをリストしないセラーはそれを実装してはなりません（MUST NOT） — 「黙って実験的」モードはありません。

実験的機能 id は関連タスクのクラスターをカバーします。クラスター内の任意のタスクを実装するセラー（例: `get_rights` だけで `acquire_rights` や `update_rights` はなし）は、依然としてクラスターの機能 id（`brand.rights_lifecycle`）を宣言しなければなりません（MUST）。部分的な実装は許されます。黙った実装は許されません。

<Note>
  `x-status: experimental` はスキーマローカルな注釈です。`$ref` を通じて継承されません — 実験的サブスキーマを参照する安定スキーマが自動的に実験的になることはありません。`get_adcp_capabilities` の `experimental_features` 宣言が権威あるランタイムシグナルです。`x-status` はスキーマ読み取り者とツール向けのオーサリングヒントです。
</Note>

## 実験的サーフェスのコントラクト

**3.x 内で、実験的サーフェスは安定サーフェスにはできない方法で変わることがあります（MAY）:**

* フィールドがリネーム、削除、または型変更されることがある
* 必須フィールドが任意になり、逆もありうる
* Enum が値を削除またはリネームされることがある
* タスク名がリネームまたは削除されることがある
* 実験的サーフェス用に導入されたエラーコードがリネームまたは削除されることがある

**実験的サーフェスへの破壊的変更の予告要件:**

* 変更が着地する前に、リリースノートとチェンジログで少なくとも **6 週間** 公開
* 可能な場合は before/after の例を伴う、変更を記述する移行ノート
* 実行可能な場合、変更を導入するリリースで新旧両形式を受け入れるエイリアス

これは、安定サーフェスに適用される [6 か月の非推奨予告](/docs/reference/versioning#deprecation-policy) の意図的な緩和です。

<Tip>
  **なぜ実験的が存在するか。** アーキテクチャ委員会は、真にコアプロトコルの一部だがまだフィールドテストされていないサーフェスにこのラベルを使います。反復パスがなければ、AdCP は誰もデプロイしていない硬直したスキーマを出荷するか、機能が完璧になるまで保留するかのいずれかになります。どちらも実装者に役立ちません。
</Tip>

**実験的サーフェスで変わらないもの:**

* 認証、トランスポート、コアセキュリティ要件。これらはバージョンレベルの関心事で、実験的かどうかにかかわらず 3.x 内で決して変わりません。
* 冪等性セマンティクス。セラーの宣言された冪等性コントラクトは、安定サーフェスに適用されるのと同じ方法で実験的サーフェスに適用されます。
* エラーエンベロープ形状。実験的サーフェスは安定サーフェスと同じエンベロープを使ってエラーを返します。特定のコードのみがシフトすることがあります。

## 安定版への卒業

実験的サーフェスは、次のすべてが満たされたとき安定版に卒業します:

| Criterion     | Requirement                                                                                                 |
| ------------- | ----------------------------------------------------------------------------------------------------------- |
| **本番シグナル**    | 少なくとも 1 つの実装が **本番**（サンドボックスでない）で **45 日以上** 稼働。                                                            |
| **クロスパーティ検証** | (a) 2 番目の実装が存在し 45 日以上稼働、うち少なくとも 1 つが本番、または (b) 少なくとも 1 バイヤーが本番でサーフェスに対して統合成功、のいずれか。バイヤー統合なしの単独実装者卒業は許されない。 |
| **スキーマ安定性**   | 卒業前 **30 日以上** サーフェスに対するオープンな破壊的変更 issue がない。                                                               |
| **意図的な昇格**    | 卒業 PR がスキーマから `x-status: experimental` を削除し、正準実験的リストから機能 id を削除、変更を運ぶ 3.x リリースのリリースノートで言及される。               |

2 実装者が 1 より低いハードルなのは、クロス実装の摩擦こそが仕様の曖昧さを振るい落とすからです。単一の実装者は反射的に自身のスキーマに一致させられますが、2 つはできません。1 実装者のみが準備できているとき、バイヤー統合シグナルが代替します — そのシグナルは、単独実装者が見逃すバイヤー側の人間工学バグをカバーします。

卒業は決して自動ではありません。アーキテクチャ委員会は卒業 PR をレビューし、サーフェスがまだ不安定性の兆候を示す場合、追加サイクルを要求することがあります。

### 卒業ケイデンス

アーキテクチャ委員会は各 3.x リリースで実験的サーフェスをレビューします。すべてのリリースのノートは、各実験的サーフェスについて次を含みます:

* 現在のステータス（依然実験的 / 卒業予定 / 活発な破壊的改訂中）
* 次のリリースが運ぶと予想される変更のリスト
* 該当する場合、そのサーフェスの最新の破壊的変更予告へのポインター

エンタープライズ調達チームは、予測可能なレビューケイデンスで実験的サーフェスを追跡するためにリリースノートを購読できます。別個のメーリングリストやチケットプロセスはありません。

## クライアントの動作

AdCP セラーに対して統合するバイヤーは次をすべきです（SHOULD）:

* **実験的サーフェスに依存する前に `experimental_features` を検査する。** 実験的サーフェスをリストしないセラーは、そのサーフェスを実装しないと主張しています。
* 実験的サーフェスに依存するとき **特定の 3.x リリースにピン留めする**、または消費する機能のリリースノートを購読する。
* **リトライとエラー処理をリリース間で追加された新しいエラーコードに耐えるよう設計する**。
* 追加のベンダー保証なしに **実験的サーフェスを規制されたワークフローに不適当として扱う**。実験的はコンプライアンスグレードの安定性のクレームではありません。

### バイヤー側の拒否

実験的サーフェスと対話したくないバイヤー — 典型的には規制されたワークフロー、コンプライアンス敏感なデプロイ、凍結されていない機能を禁じる調達ポリシー — は、これをクライアント側で強制します。パターン:

1. **ケイパビリティディスカバリー時**に、セラーの `get_adcp_capabilities` レスポンスから `experimental_features` を読む。
2. **呼び出し前にフィルタリングする。** あなたのポリシーが拒否する実験的機能 id に属するタスクを呼ばない。機能 id ごとのタスクのリストは下記の正準実験的サーフェスリストで公開されている。
3. **上流で短絡する。** オーケストレーターや上流呼び出し元が実験的サーフェスを要求する動作をリクエストするとき、呼び出しを試みるのではなくポリシーレベルのエラー（例: 呼び出し元自身の `POLICY_EXPERIMENTAL_REFUSED`）を返す。拒否はバイヤーの関心事でありセラーのものではない — セラーがバイヤーポリシーを推論することを期待してはならない（MUST NOT）。

3.0 にワイヤーレベルの拒否フィールドはありません。バイヤー側フィルタリングで十分で、コントラクトを非対称に保ちます（セラーは宣言し、バイヤーは決定する）。マルチパーティ拒否ハンドオフパターンが実際の統合から現れる場合、相互的なワイヤーメカニズムが将来のリリースで再検討されるかもしれません。

## 現在の実験的サーフェス

`x-status: experimental` でマークされたスキーマが権威あるソースです。AdCP 3.x の `experimental_features` の機能 id の正準リスト:

| Feature id                        | Surface                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | Why experimental                                                                                                                                                                                                                                                                                                                                                                                                                           |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `brand.rights_lifecycle`          | [`get_rights`](/docs/brand-protocol/tasks/get_rights)、[`acquire_rights`](/docs/brand-protocol/tasks/acquire_rights)、[`update_rights`](/docs/brand-protocol/tasks/update_rights)。`get_adcp_capabilities` の `brand.rights`、`brand.right_types`、`brand.available_uses`、`brand.generation_providers` ケイパビリティフィールド。これらのサーフェスが参照する `right-use` と `right-type` enum                                                                                                                                 | 3.0 サイクル後期に追加された法的構成のサーフェス。最初のエンタープライズデプロイが部分的権利、サブライセンス、失効、紛争解決のエッジケースを露出させる。2 つの enum は、新しいライセンス可能利用カテゴリー（例: 具現化、ホログラム、生成音楽スタイル）が現れるにつれ値が進化すると予想されるため実験的とマークされる。                                                                                                                                                                                                                                                                         |
| `governance.campaign`             | [`sync_plans`](/docs/governance/campaign/tasks/sync_plans)、[`check_governance`](/docs/governance/campaign/tasks/check_governance)、[`report_plan_outcome`](/docs/governance/campaign/tasks/report_plan_outcome)、[`get_plan_audit_logs`](/docs/governance/campaign/tasks/get_plan_audit_logs)                                                                                                                                                                                                  | マルチパーティガバナンスセマンティクス（バイヤー vs セラー承認の衝突、監査来歴の検証、Embedded Human Judgment 下のタイブレーク）がまだ確定していない。                                                                                                                                                                                                                                                                                                                                                  |
| `measurement.core`                | [`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities#measurement) の `measurement` ケイパビリティブロックと `supported_protocols` の `measurement` 値                                                                                                                                                                                                                                                                                                                                             | 測定は現在ベンダーメトリクスカタログのディスカバリーのみを公開。レポート、アトリビューション、価格/カバレッジ、ベースラインコンプライアンスストーリーボードは凍結されていないため、サーフェスは 3.1 で実験的のまま。                                                                                                                                                                                                                                                                                                                              |
| `trusted_match.core`              | [TMP](/docs/trusted-match/)                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | プライバシーアーキテクチャが、規制当局の深掘りが要求するものに対して薄く仕様化されている。エクスポージャートークン、国分割アイデンティティ、Offer マクロは変わると予想される。                                                                                                                                                                                                                                                                                                                                                 |
| `trusted_match.verified_identity` | `identity-match-request` エントリの `attestation` オブジェクト、トップレベルの `sealed_credentials[]` 配列、`uid-type` enum の `world_id_nullifier` 値、`attestation-claim` enum、`brand.json` の `identity_relying_parties[]` — [Verified Identity Attestation](/docs/trusted-match/specification#verified-identity-attestation) を参照                                                                                                                                                                                   | 検証可能な人格証明 / 年齢を Identity Match に転送し、バイヤーがアサーションを信頼するのではなく検証する。発行者非依存だが、これまで World ID スキームのみが仕様化されている。`signal_binding` 鮮度ポリシー、発行者/スキームのレジストリ対自由形式の決定、`brand.json` バリアント配置は WG オープン。そうでなければ `additionalProperties:false` の identity-match-request スキーマの拡大はコントラクトを担い、実験的の下で改訂されることがある。                                                                                                                                                        |
| `sponsored_intelligence.core`     | [`si_get_offering`](/docs/sponsored-intelligence/tasks/si_get_offering)、[`si_initiate_session`](/docs/sponsored-intelligence/tasks/si_initiate_session)、[`si_send_message`](/docs/sponsored-intelligence/tasks/si_send_message)、[`si_terminate_session`](/docs/sponsored-intelligence/tasks/si_terminate_session)。`get_adcp_capabilities` の `sponsored_intelligence` ケイパビリティフィールド。[SI 仕様](/docs/sponsored-intelligence/specification) で定義される SI アイデンティティ、ケイパビリティネゴシエーション、UI コンポーネントサーフェス     | 会話的なブランド体験は新しい広告モデル。セッションライフサイクル、UI コンポーネント、アイデンティティ/同意オブジェクト形状、ケイパビリティネゴシエーションは、ファーストパーティ AI ホストとブランドエージェントが統合するにつれ進化すると予想される。計画された変更は [3.1.0 ロードマップ](https://github.com/adcontextprotocol/adcp/issues/2201) を追跡する。                                                                                                                                                                                                                       |
| `creative.evaluator`              | [`build_creative`](/docs/creative/task-reference/build_creative) の `evaluator` 入力、ビルドレスポンスのリーフごとの `eval` ブロック、`get_adcp_capabilities` の `creative.supports_evaluator` ケイパビリティフィールド（スキーマ: `core/evaluator-spec.json`）                                                                                                                                                                                                                                                                         | 新しい gate-then-rank のクリエイティブ機能オラクルサーフェス（#5241 / #5311）、まだ当事者間でフィールドテストされていない。エバリュエーターランキングは、並行するエバリュエーターカタログを鋳造するのではなく、意図的に既存の安定クリエイティブ機能カタログを再利用する: `rank_by`、`feature_requirement`、`eval.features[]` はすべて `governance.creative_features` の機能 ID を参照する。`evaluator_id` はそのカタログとは別: 出力が依然クリエイティブ機能結果に解決される、事前プロビジョニング/アカウント手配されたプリセット。別個の `supports_evaluator_gate` ケイパビリティとハードな MUST-enforce-gate セマンティクスは、エバリュエーターフィールドを再形成しうる予約されたフォローオン。 |
| `creative.signal_fanout`          | [`build_creative`](/docs/creative/task-reference/build_creative) の `signal_conditions[]` と `selection_strategy` 入力、そのレスポンスの `creatives[].signal_condition` / `selection_strategy_applied` / `estimate.conditions_total` フィールド、`get_adcp_capabilities` の `creative.multiplicity.supports_signal_fanout` / `max_signal_conditions_limit` / `selection_strategies` ケイパビリティフィールド、`enums/creative-selection-strategy.json` enum、`SIGNAL_TARGETING_INCOMPATIBLE` エラーコード（#5240 / #5304、#5262 を折り込む） | クリエイティブエージェント + セールスエージェントにまたがるクロスエージェントの reject-at-trafficking MUST（`SIGNAL_TARGETING_INCOMPATIBLE`）を導入する新しいシグナル駆動のクリエイティブファンアウトサーフェス — まだ当事者間でフィールドテストされていない。数値（`value_type: numeric`）条件互換性比較（範囲重複対完全一致）はまだ WG オープンで、`proximity` 選択戦略のジオ入力バインドはまだ確定していない — 両方とも実験的の下で改訂可能なまま。条件アイデンティティ自体は今日解決可能（`get_signals` 経由の `signal_agent_segment_id` / `signal_ref`）なので、凍結識別子の問題はない。                                                             |

卒業の進捗と今後の破壊的変更の予告は、3.0 GA から始まる各 3.x リリースの [リリースノート](/docs/reference/release-notes) で言及されます。

## 拡張との関係

実験的ステータスは [拡張](/docs/reference/versioning#extensibility) と同じではありません。拡張は `ext.{namespace}` フィールドに存在し、拡張レジストリによって統治されます。それらはコアプロトコルにとって恒久的に帯域外です。実験的サーフェスはコアプロトコル内にあります — それらは安定版への昇格の候補であり、サードパーティの追加ではありません。

アーキテクチャ委員会がサーフェスをコアプロトコルの一部として意図するがまだ凍結する用意がないとき、サーフェスは実験的であるべきです。サーフェスがドメイン固有、コアプロトコル外で保守、またはより広い AdCP エコシステムに適用される可能性が低いとき、それは拡張であるべきです。