実験的ステータス

一部の AdCP サーフェスは、リリースに公開されるがまだ凍結されていません。実装者がそれらに対して構築を始められるよう出荷されますが、安定サーフェスよりも弱い安定性コントラクトを運びます。このページはそのコントラクトを定義します。 実験的ステータスは、3.x 安定性保証を信頼に足るものに保つ安全弁です。サーフェスは安定 — その場合 3.x 内で壊れることができない — か、明示的に実験的 — その場合壊れることができる — のいずれかです。宣言されていない中間地帯はありません。プロトコルの非目標と延期項目のリストについては 既知の制限 を参照。

---

​

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

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）。部分的な実装は許されます。黙った実装は許されません。

​

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

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

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

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

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

これは、安定サーフェスに適用される 6 か月の非推奨予告 の意図的な緩和です。 実験的サーフェスで変わらないもの:

• 認証、トランスポート、コアセキュリティ要件。これらはバージョンレベルの関心事で、実験的かどうかにかかわらず 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 の正準リスト: 卒業の進捗と今後の破壊的変更の予告は、3.0 GA から始まる各 3.x リリースの リリースノート で言及されます。

​

拡張との関係

実験的ステータスは 拡張 と同じではありません。拡張は ext.{namespace} フィールドに存在し、拡張レジストリによって統治されます。それらはコアプロトコルにとって恒久的に帯域外です。実験的サーフェスはコアプロトコル内にあります — それらは安定版への昇格の候補であり、サードパーティの追加ではありません。 アーキテクチャ委員会がサーフェスをコアプロトコルの一部として意図するがまだ凍結する用意がないとき、サーフェスは実験的であるべきです。サーフェスがドメイン固有、コアプロトコル外で保守、またはより広い AdCP エコシステムに適用される可能性が低いとき、それは拡張であるべきです。