標準フロー
すべてのメディアバイは 4 つのステップに従います:get_products— ブリーフに一致する利用可能な在庫を発見。create_media_buy— パッケージを提出。セラーが検証し確認。- クリエイティブ供給 — それを必要とするパッケージにクリエイティブアセットを割り当てる、
sync_creativesとcreative_assignmentsを通じて、またはセラーがインラインクリエイティブ管理をアドバタイズするときインラインパッケージcreativesを通じて。 - 配信 — バイが
activeに入りインプレッションを計上、または配信保留で作成されたときpausedに入る。最終的に終端状態に到達。
ステートマシン
メディアバイ状態
pending_manual と pending_permission は タスクレベル ステータスです — それらは 操作（例: create_media_buy）が人間レビューのためキューされているかを記述し、メディアバイ自身の状態ではありません。メディアバイは操作が完了すると pending_creatives、pending_start、active、または paused に入ります。非同期操作 を参照してください。遷移
ランタイムでの有効なアクションの発見
ステートマシンをハードコードするのではなく、get_media_buys から valid_actions を読みます。セラーは現在の状態でバイヤーができることを正確に返します:
update_media_buy 呼び出しで最新の revision を渡すべきです（SHOULD）。フィールドは後方互換性のためオプションですが、存在するとき、リビジョンが最後の読み取り以来変わっていればセラーは CONFLICT で拒否し、チェックは並行更新が互いを上書きできないよう書き込みとアトミックに起こらなければなりません。楽観的並行性 を参照してください。
クリエイティブ変更には、valid_actions の sync_creatives はレガシーアクションラベルです。セラーがアドバタイズするクリエイティブパスを使います: ライブラリバックのセラーには sync_creatives と creative_assignments、インラインのみのセラーには update_media_buy の packages[].creatives。
保証 / PG ディールバリエーション
delivery_type: "guaranteed" の製品は、配信開始前に契約上のコミットメントを要求します。フローは create_media_buy の後に分岐します:
保証バイを異なるものにするもの
accountability_terms は必須 です、保証製品を持つ各パッケージ上で。3 つのフィールドが必須:
performance_standards— ビューアビリティ、IVT、完了レート、測定ベンダーを伴う他のしきい値measurement_terms— 誰が課金メトリックを数えるか、許容分散、メイクグッド救済cancellation_policy— 早期終了の通知期間とキャンセル料
TERMS_REJECTED を返します。
IO 署名 — 保証製品の create_media_buy は同期的に完了するのではなく task_id を伴うタスクステータス submitted を返すかもしれません。これはセラーのシステムがインサーションオーダー（IO）受諾を待っていることを意味します。tasks/get でポーリングするか webhook を構成します。IO が署名されると、完了アーティファクトが media_buy_id を運びメディアバイは pending_creatives または pending_start に入ります。
メイクグッド — セラーが合意された performance_standards に対して過小配信する場合、makegood_policy から救済を提案します: additional_delivery、credit、または invoice_adjustment。バイヤーは受諾または異議を唱えます。
過小配信せずに受諾するセラーは好ましいアカウンタビリティシグナルを獲得します。バイヤーが
create_media_buy 時に非デフォルト条件を提案できる方法を含む完全な交渉フローについては アカウンタビリティ を参照してください。クリエイティブ同期タイミング
クリエイティブがいつ必要か
create_media_buy はパッケージごとのインライン creative_assignments または creatives を受け入れます。作成時にそれらを供給しフライト日が過ぎている場合、バイは直接 active に入る、またはリクエストがトップレベル paused: true を運ぶとき paused に入る。フライト日が未来の場合、pending_start に入る。トップレベル paused: true では、保留は潜在的でフライト日が到着するとバイは paused に入る。
作成時にクリエイティブが割り当てられない場合、バイは pending_creatives に入る。トップレベル paused: true では、保留は潜在的で、必要なクリエイティブが供給され任意の未来の開始日が到着した後バイは paused に入る。配信は、バイヤーがセラーがアドバタイズするパスを通じてパッケージごとに少なくとも 1 つのクリエイティブを供給するまで開始できません。creative.has_creative_library: true のセラーは sync_creatives と creative_assignments を使います。creative.has_creative_library: true と inline_creative_management: true の両方をアドバタイズするセラーは、create_media_buy と update_media_buy でインライン packages[].creatives も受け入れます。インラインのみのセラーは update_media_buy の packages[].creatives のみを使います。
作成時保留は、配信がそうでなければ準備できる前にクリアされるかも。paused: false の update_media_buy は保存された保留をクリアします。クリエイティブがまだ欠けているかフライト日がまだ未来の場合、そのブロッカーがクリアするまで可視ステータスは pending_creatives または pending_start のままです。
creative_deadline
create_media_buy はメディアバイレスポンスで creative_deadline タイムスタンプを返します。個別のパッケージは自身の creative_deadline を運ぶかもしれません。パッケージレベルデッドラインはメディアバイデッドラインより優先します。 これは混合チャネルオーダーに重要です — プリントパッケージは同じバイのデジタルパッケージより数日前の素材デッドラインを持つかもしれません。
デッドライン後、そのパッケージのクリエイティブ提出は、sync_creatives または update_media_buy のインライン packages[].creatives のどちらを通じて到着しても CREATIVE_REJECTED を返します。クリエイティブ変更はブロックされます。配信は現在割り当てられているクリエイティブで続きます（またはクリエイティブが決して割り当てられなかった場合パッケージは pending_creatives のまま）。
バイが終わるときのクリエイティブへの影響
メディアバイがrejected、canceled、completed に到達するとき、クリエイティブ割り当ては解放されます。ライブラリバックのセラーには、クリエイティブ自体は削除されません — 既存のレビューステータスでライブラリに残り、他のメディアバイへの割り当てに利用可能です。インラインのみのセラーは、再利用可能なライブラリエントリーを露出せずに監査とレポートのためパッケージスコープのクリエイティブレコードを保持するかもしれません。
Health and dependency impairment
status は運用状態を記述します — バイは配信中、一時停止、または終端か? health は、アップストリーム依存関係が無傷かを記述する別の直交フィールドです:
2 つは直交です。バイは
paused かつ impaired、pending_creatives かつ impaired、または active かつ impaired になりえます。Health は status を変えません。valid_actions は影響を受けません。
health が impaired のとき
health は、バイが参照するアップストリーム依存関係が少なくとも 1 つのパッケージの配信に影響するオフライン状態に入るとき impaired に遷移します:
- バイがターゲットするオーディエンスが
suspendedに遷移（同意期限切れ、TTL、ポリシー強制）。 - バイが使うクリエイティブが
approvedからsuspended（回復可能な依存関係/認可喪失）、suspendedからrejected（終端依存関係/認可喪失）、またはapprovedからrejected（承認後失効）に遷移。 - バイがターゲットするカタログアイテムが
withdrawnに遷移（セラー開始の削除）。 - バイが依存するイベントソースが
insufficientに入る（ゼロイベント受信）。 - バイがターゲットするプロパティが brand.json / adagents.json 経由で depublish される。
impairments[] 配列は影響を受ける依存関係ごとに 1 エントリーを運びます:
マテリアリティ
impairments[] の各エントリーは、配信能力が劣化した少なくとも 1 つのパッケージをリストしなければなりません（MUST）。表面的な影響（依然としてサービス可能な仲間を持つパッケージの 1 つの拒否されたクリエイティブ）は機能低下としてレポートされてはなりません（MUST NOT） — それらはバイのではなくリソース自身のステータス経由で表示されます。
逆方向
基盤リソースがサービス可能な状態に戻るとき（オーディエンス再同期、クリエイティブ再承認）、セラーはimpairments[] から対応するエントリーを削除しなければならず（MUST）、他の機能低下が残らなければ health を ok に反転しなければなりません。バイヤーは次のスナップショット読み取りまたは次の impairment プッシュ（クロージャーを運ぶ）で回復した状態を見ます。
impairment webhook 経由でプッシュ
バイの health が遷移するか機能低下が追加/削除されるとき、セラーはバイの push_notification_config に対して impairment 通知を発火します。ペイロードは impairment オブジェクト形状プラスバイの更新された health を再利用します。配信セマンティクス（at-least-once、順序なし、合体、スナップショット経由リプレイ）については persistent webhook contract を参照してください。
機能低下 webhook は設計上 package_ids[] で影響を受けるパッケージを識別します。context.buyer_ref のようなパッケージレベル相関コンテキストを必要とするバイヤーは、機能低下発火を受け取った後 get_media_buys を呼びパッケージスナップショットを読むべきです。
マテリアリティカバレッジ
MUST 強度のマテリアリティルールは、リソース → バイ結合が安価で 1:N のリソースタイプ — audience、event_source、property — に適用されます。creative と catalog_item には、マテリアリティは SHOULD 強度です: 大きなプールのクリエイティブは削除されても配信を劣化させないかもしれず、結合はセラーが計算するのにより高価です。実装者は不確かなとき保守的にレポートすべきで（SHOULD）、配信が証明可能に影響を受けないときレポートしてはなりません（MUST NOT）。reason_code による修復
各 reason_code は典型的なバイヤー修復パスを持ちます。セラーは機能低下ごとにこれを埋めません — バイヤーエージェントは reason_code から直接修復をキーします。下のテーブルはプロトコルレベルガイダンスです。機能低下ごとのフリーテキスト remediation フィールドは、典型的なパスに合わないセラー固有コンテキストを運びます（例: 「このオーディエンスを昨日復元した。今同期してリフレッシュを拾って」）。
トリアージ順序
非空のimpairments[] をトリアージするバイヤーエージェントは、エントリーを observed_at 昇順でソートすべきです（SHOULD） — 最も古いオープンな機能低下が既に配信を食っている可能性が最も高い。Webhook 到着時間は信頼できるプロキシではありません: 合体ルール（webhooks § Coalescence を参照）の下でセラーは複数の状態変更を 1 つの発火にバッチしてもよく（MAY）、新しい idempotency_key 下の再発行は observed_at を変えずにトランスポートタイムスタンプをリセットします。
機能低下は運用シグナルで、商業イベントではない
impairment はアップストリーム依存関係変更からの劣化した配信をレポートします。それは課金イベント、メイクグッドトリガー、またはクレジット紛争では ありません。過小配信の商業救済は保証バイの accountability_terms で統制され、この表面の範囲外のままです。紛争パイプラインを構築するインテグレーターは、impairments[] からではなく配信レポートとアカウンタビリティ条件からそれらを駆動すべきです。
Compliance
impairment.coherence アサーションは、バイの impairments[] 表面がそれが参照する基盤リソースと同期を保つことを検証します。それはクロスリソース不変条件です — 同じコンプライアンス実行でリソース遷移とバイスナップショットの両方を観測します。
前方ルール。 バイの impairments[] の各エントリーは、現在ステータスがオフライン状態のリソースを参照しなければなりません（MUST） — audience: suspended（audience-status 上）、creative: suspended または creative: rejected（creative-status 上）、catalog_item: withdrawn（catalog-item-status 上）、event_source: insufficient（event-source-health.status を通じて表示される assessment-status 値）、または brand.json / adagents.json 経由で depublish されたプロパティ。参照されたリソースがもはやオフラインでない機能低下をレポートするバイはチェックに失敗 — セラーはバイに古い状態を持つ。
逆ルール。 非終端バイが参照するオフライン状態の任意のリソースは、そのバイの impairments[] に現れなければなりません（MUST）。影響を受けるバイに伝播せずにリソースを遷移するセラーはチェックに失敗 — セラーはリソースに古い状態を持つ。
Health-iff ルール。 非終端バイの health は、impairments[] が非空のときは常に impaired でなければならず（MUST）、impairments[] が空のときは常に ok でなければなりません（MUST）。これは厳格な iff です — 空の impairments[] を持つ古い health: "impaired"（または非空の impairments[] を持つ health: "ok"）は、前方と逆ルールが個別に満たされてもルールに違反します。
範囲外。 3 つのルールすべてが終端ステータス（completed、canceled、rejected）のバイで緩和されます。セラーは終端遷移で保持されていた状態のまま impairments[] と health を残してもよい（MAY） — それらをクリーンアップする必要はありません。バイヤーは終端後ドリフトを一貫性違反として扱ってはなりません（MUST NOT）。バイはもはや配信しておらず同期は無駄な努力です。マテリアリティ（package_ids が非空である要件）は impairment.json の package_ids: minItems: 1 によってスキーマ層で強制されます — impairment.coherence はそれを再チェックしません。
スナップショットはいくつかの伝播表面の 1 つ。 セラーは get_adcp_capabilities の capabilities.media_buy.propagation_surfaces 経由でどの表面を使うかを宣言します — 非排他的配列なので、バイスナップショットで機能低下をミラーし かつ webhook を発火するセラーは ["snapshot", "webhook"] を宣言（プレミアム保証セラーの一般的なケース）。3 つの表面値:
snapshot— セラーがget_media_buys読み取りでhealth+impairments[]を投入。上のコントラクトがこの表面を統制。impairment.coherenceストーリーボードは宣言されるときそれをグレード、そうでなければnot_applicable。webhook— セラーがpush_notification_config経由でnotification-type: impairmentwebhook を発火。persistent-channel webhook コントラクトに従う。out_of_band— セラーが AdCP プロトコル表面外のチャネル（メール、ダッシュボード、パートナー固有フィード）経由で伝播。機能低下ワークフローが人間チャネルで管理されるとき、ロングテールとエンタープライズバンドルプラットフォームが一般的にこれを使う。["out_of_band"]のみを宣言するセラーはスナップショットまたは webhook コンプライアンスでグレードされない — 彼らのバーはオフライン合意。
["snapshot"]。各表面は他から独立。バイヤーがエージェントで観測する実際の表面の混合を宣言。非 AdCP フィールド名（マッピングギャップ）の下の API に機能低下データを持つセラーは、out_of_band を宣言するのではなくマッピングを文書化すべき（SHOULD） — 仕様のギャップが out_of_band が正当にカバーするもの。
他の不変条件との関係。 impairment.coherence は、単一リソース遷移のみを観測する status.monotonic を補完します。2 つは、リソース状態遷移とメディアバイスナップショット読み取りの両方を行使するストーリーボードを持つすべての専門分野で一緒に実行 — audience-sync、creative-ad-server、creative-template、creative-generative、sales-catalog-driven。非 NA グレーディングを駆動するクロスリソース行使は dependency-impairment ストーリーボード（media_buy_seller/dependency_impairment、creative-track）で、アクティブなバイのクリエイティブをオフライン状態（回復可能な依存関係喪失には approved → suspended、終端失効には approved/suspended → rejected）に強制し、バイが一致する impairments[] エントリーで health: impaired を反映することを検証し、クリエイティブを回復または置き換え、バイが impairments[] クリアで health: ok に戻ることを検証します。Audience-track と catalog-track バリアントはフォローアップで、コンプライアンステストコントローラーの force_audience_status / force_catalog_item_status サポート待ち。
impairments[]（スナップショット）を impairment プッシュ（ログ）に結びつける読み取り側ルールについては Snapshot and log contract を参照してください。
関連項目
- メディアバイライフサイクル — 完全なライフサイクルリファレンス: キャンペーン構造、パッケージモデル、非同期操作
create_media_buy— リクエストパラメーター、レスポンス形状、例を伴うタスクリファレンスsync_creatives— セラーがcreative.has_creative_library: trueをアドバタイズするときライブラリクリエイティブをアップロードして更新- アカウンタビリティ — パフォーマンス標準、測定条件、メイクグッド解決
- 最適化とレポート — 配信監視、次元レポート、キャンペーン更新