> ## 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.

# メディアバイライフサイクルフロー

> 製品ディスカバリーから配信までのステップバイステップシーケンス、保証ディール IO 受諾パスとクリエイティブ同期タイミングを含む。

このページはメディアバイライフサイクルの正準シーケンスリファレンスです。完全なライフサイクルの概念的背景 — キャンペーン構造、パッケージモデル、プロパティターゲティング、非同期操作 — については [メディアバイライフサイクル](/docs/media-buy/media-buys/) を参照してください。

## 標準フロー

すべてのメディアバイは 4 つのステップに従います:

```mermaid theme={null}
flowchart TD
    A[get_products] --> B[create_media_buy]
    B --> C{initial state}
    C -->|creatives missing| D[pending_creatives]
    C -->|creatives present,\nflight not yet started| E[pending_start]
    C -->|creatives present,\nflight started| F[active]
    C -->|paused: true,\notherwise active| J[paused]
    D --> G[creative supply]
    G --> E
    E --> F
    F --> H{delivery}
    H -->|budget exhausted /\ngoal met / flight ended| I[completed]
    H -->|buyer or seller action| J[paused]
    J --> F
    J -->|flight ended| I
```

1. **`get_products`** — ブリーフに一致する利用可能な在庫を発見。
2. **`create_media_buy`** — パッケージを提出。セラーが検証し確認。
3. **クリエイティブ供給** — それを必要とするパッケージにクリエイティブアセットを割り当てる、`sync_creatives` と `creative_assignments` を通じて、またはセラーがインラインクリエイティブ管理をアドバタイズするときインラインパッケージ `creatives` を通じて。
4. **配信** — バイが `active` に入りインプレッションを計上、または配信保留で作成されたとき `paused` に入る。最終的に終端状態に到達。

## ステートマシン

### メディアバイ状態

| State               | Meaning               | Terminal? |
| ------------------- | --------------------- | --------- |
| `pending_creatives` | 承認済み。まだクリエイティブ未割り当て   | No        |
| `pending_start`     | クリエイティブ割り当て済み。フライト日待ち | No        |
| `active`            | インプレッション配信中           | No        |
| `paused`            | 一時停止                  | No        |
| `completed`         | フライト終了、目標達成、または予算枯渇   | Yes       |
| `rejected`          | セラーがバイを辞退             | Yes       |
| `canceled`          | バイヤーまたはセラーが完了前に終了     | Yes       |

<Note>
  `pending_manual` と `pending_permission` は **タスクレベル** ステータスです — それらは *操作*（例: `create_media_buy`）が人間レビューのためキューされているかを記述し、メディアバイ自身の状態ではありません。メディアバイは操作が完了すると `pending_creatives`、`pending_start`、`active`、または `paused` に入ります。[非同期操作](/docs/media-buy/media-buys/#asynchronous-operations-and-human-in-the-loop) を参照してください。
</Note>

### 遷移

```mermaid theme={null}
stateDiagram-v2
    [*] --> pending_creatives : create_media_buy\n(no creatives)
    [*] --> pending_start : create_media_buy\n(creatives present,\nflight future)
    [*] --> active : create_media_buy\n(creatives present,\nflight started)
    [*] --> paused : create_media_buy\n(paused: true,\notherwise active)

    pending_creatives --> pending_start : sync_creatives\nor update_media_buy creatives
    pending_creatives --> paused : sync_creatives\nor update_media_buy creatives\n(create held)
    pending_start --> active : flight date reached
    pending_start --> paused : flight date reached\n(create held)

    active --> paused : update_media_buy\n(paused: true)
    paused --> active : update_media_buy\n(paused: false)

    active --> completed : flight ended /\ngoal met / budget exhausted
    paused --> completed : flight ended /\ngoal met / budget exhausted

    pending_creatives --> rejected : seller declines
    pending_start --> rejected : seller declines

    pending_creatives --> canceled : update_media_buy\n(canceled: true)
    pending_start --> canceled : update_media_buy\n(canceled: true)
    active --> canceled : update_media_buy\n(canceled: true)
    paused --> canceled : update_media_buy\n(canceled: true)

    completed --> [*]
    rejected --> [*]
    canceled --> [*]
```

### ランタイムでの有効なアクションの発見

ステートマシンをハードコードするのではなく、`get_media_buys` から `valid_actions` を読みます。セラーは現在の状態でバイヤーができることを正確に返します:

```json theme={null}
{
  "media_buy_id": "mb_12345",
  "status": "active",
  "revision": 3,
  "valid_actions": ["pause", "cancel", "update_budget", "update_dates", "update_packages", "add_packages", "sync_creatives"]
}
```

バイヤーは状態を変えることを意図したすべての `update_media_buy` 呼び出しで最新の `revision` を渡すべきです（SHOULD）。フィールドは後方互換性のためオプションですが、存在するとき、リビジョンが最後の読み取り以来変わっていればセラーは `CONFLICT` で拒否し、チェックは並行更新が互いを上書きできないよう書き込みとアトミックに起こらなければなりません。[楽観的並行性](/docs/media-buy/task-reference/update_media_buy#optimistic-concurrency) を参照してください。

クリエイティブ変更には、`valid_actions` の `sync_creatives` はレガシーアクションラベルです。セラーがアドバタイズするクリエイティブパスを使います: ライブラリバックのセラーには `sync_creatives` と `creative_assignments`、インラインのみのセラーには `update_media_buy` の `packages[].creatives`。

## 保証 / PG ディールバリエーション

`delivery_type: "guaranteed"` の製品は、配信開始前に契約上のコミットメントを要求します。フローは `create_media_buy` の後に分岐します:

```mermaid theme={null}
flowchart TD
    A[get_products\ndelivery_type: guaranteed] --> B[create_media_buy\nwith accountability_terms]
    B --> C{task status}
    C -->|IO signing needed| D[submitted\ntask_id returned]
    C -->|IO pre-signed| E[pending_creatives\nor pending_start]
    D --> F[IO signed\nout-of-band]
    F --> E
    E --> G[creative supply\nif needed]
    G --> H[active — guaranteed delivery]
    H --> I{performance}
    I -->|standards met| J[completed]
    I -->|under-delivery| K[makegood / remediation]
    K --> J
```

### 保証バイを異なるものにするもの

**`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`。バイヤーは受諾または異議を唱えます。

<Note>
  過小配信せずに受諾するセラーは好ましいアカウンタビリティシグナルを獲得します。バイヤーが `create_media_buy` 時に非デフォルト条件を提案できる方法を含む完全な交渉フローについては [アカウンタビリティ](/docs/media-buy/advanced-topics/accountability) を参照してください。
</Note>

## クリエイティブ同期タイミング

### クリエイティブがいつ必要か

`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` のまま）。

```
Deadline hierarchy:
  package.creative_deadline  (if present — wins)
    ↓ else
  media_buy.creative_deadline
```

### バイが終わるときのクリエイティブへの影響

メディアバイが `rejected`、`canceled`、`completed` に到達するとき、クリエイティブ割り当ては解放されます。ライブラリバックのセラーには、クリエイティブ自体は削除されません — 既存のレビューステータスでライブラリに残り、他のメディアバイへの割り当てに利用可能です。インラインのみのセラーは、再利用可能なライブラリエントリーを露出せずに監査とレポートのためパッケージスコープのクリエイティブレコードを保持するかもしれません。

## Health and dependency impairment

`status` は運用状態を記述します — バイは配信中、一時停止、または終端か? **`health`** は、アップストリーム依存関係が無傷かを記述する別の直交フィールドです:

| Field    | Tracks | Values                                                                                        |
| -------- | ------ | --------------------------------------------------------------------------------------------- |
| `status` | 運用状態   | `pending_creatives`, `pending_start`, `active`, `paused`, `completed`, `rejected`, `canceled` |
| `health` | 依存関係状態 | `ok`, `impaired`                                                                              |

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 エントリーを運びます:

```json theme={null}
{
  "media_buy_id": "mb_456",
  "status": "active",
  "health": "impaired",
  "impairments": [
    {
      "impairment_id": "imp_01HZX9...",
      "resource_type": "audience",
      "resource_id": "aud_123",
      "package_ids": ["pkg_a"],
      "transition": { "from": "ready", "to": "suspended" },
      "reason_code": "consent_expired",
      "reason": "Hashed identifier consent basis expired on 2026-06-01.",
      "observed_at": "2026-06-02T14:11:00Z",
      "remediation": "Re-sync audience after refreshing consent upstream."
    }
  ]
}
```

### マテリアリティ

`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](/docs/building/by-layer/L3/webhooks#persistent-channel-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` フィールドは、典型的なパスに合わないセラー固有コンテキストを運びます（例: 「このオーディエンスを昨日復元した。今同期してリフレッシュを拾って」）。

| `reason_code`                    | Typical buyer remediation                                                                                                                                                          |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `consent_expired`                | アップストリーム同意をリフレッシュ（例: クリーンルームフローでのハッシュ id 同意更新）、次に `sync_audiences` 経由でオーディエンスを再同期。                                                                                                 |
| `ttl_expired`                    | 更新のため `sync_audiences` 経由でオーディエンスを再同期。                                                                                                                                             |
| `pii_audit_failed`               | アップストリームで監査発見に対処（ハッシュ、識別子衛生）。セラーが監査クリアをシグナルした **後** にのみ再同期 — クリアされていない監査に対して `sync_audiences` をループするバイヤーエージェントは収束しない。                                                              |
| `content_rejected`               | 初期クリエイティブ承認と同じパス — 問題を修正し、ライブラリバックのセラーには `sync_creatives` 経由で、インラインのみのセラーには `update_media_buy` の `packages[].creatives` 経由で再提出。キャンペーンレベル決定（置き換え対再提出待ち）はクリエイティブプール構成に依存しバイヤーに委ねられる。 |
| `identity_authorization_revoked` | セラーの接続フローを通じて下流アイデンティティ/投稿認可を復元、または認可が復元できない場合影響を受ける `published_post` クリエイティブを置き換え。                                                                                                |
| `identity_authorization_expired` | セラーの接続フローを通じて下流アイデンティティ/投稿認可を更新、次にセラーにクリエイティブを再チェックまたは再レビューさせる。                                                                                                                    |
| `source_private`                 | ソース投稿可視性を復元、または影響を受ける `published_post` 参照を置き換え。                                                                                                                                    |
| `source_offline`                 | タグがバイヤーのプロパティで発火していることを検証（これはしばしばセラー側停止ではなくバイヤー/パブリッシャー統合問題）、次に `sync_event_sources` 経由で再同期。                                                                                       |
| `seller_removed`                 | バイヤー側再提出パスなし。キャンペーンセットアップで使われたのと同じディスカバリーツール（`get_products`、`get_signals`、`list_creative_formats`）経由で置き換えを見つける、またはセラーに復元 ETA を連絡。                                                  |
| `policy_violation`               | セラー側強制。バイヤー側再提出はクリアの可能性が低い。解決を待つかセラーの標準連絡パスに従いエスカレート。                                                                                                                              |
| `property_depublished`           | バイヤー側修正なし — プロパティ公開はパブリッシャーの `brand.json` / `adagents.json` で制御される。`get_products` 経由で置き換えプロパティを見つけるかターゲティングから削除。                                                                   |

### トリアージ順序

非空の `impairments[]` をトリアージするバイヤーエージェントは、エントリーを `observed_at` 昇順でソートすべきです（SHOULD） — 最も古いオープンな機能低下が既に配信を食っている可能性が最も高い。Webhook 到着時間は信頼できるプロキシではありません: 合体ルール（[webhooks § Coalescence](/docs/building/by-layer/L3/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`](https://adcontextprotocol.org/schemas/v3/protocol/get-adcp-capabilities-response.json) 経由でどの表面を使うかを宣言します — 非排他的配列なので、バイスナップショットで機能低下をミラーし かつ webhook を発火するセラーは `["snapshot", "webhook"]` を宣言（プレミアム保証セラーの一般的なケース）。3 つの表面値:

* **`snapshot`** — セラーが `get_media_buys` 読み取りで `health` + `impairments[]` を投入。上のコントラクトがこの表面を統制。`impairment.coherence` ストーリーボードは宣言されるときそれをグレード、そうでなければ `not_applicable`。
* **`webhook`** — セラーが `push_notification_config` 経由で `notification-type: impairment` webhook を発火。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](/docs/protocol/snapshot-and-log) を参照してください。

<Tip>
  ライブラリバックのセラーには、クリエイティブライブラリ状態とクリエイティブ割り当て状態は独立に追跡されます。キャンセルされたバイに割り当てられたクリエイティブは、獲得したレビューステータスを依然として持ち即座に新しいバイに割り当てられます。インラインのみのセラーは `get_media_buys` でパッケージスコープのクリエイティブステータスを露出しますが再利用可能なライブラリクリエイティブをアドバタイズしません。[クリエイティブ状態と割り当て状態](/docs/creative/creative-libraries#creative-state-and-assignment-state-are-separate) を参照してください。
</Tip>

## 関連項目

* [メディアバイライフサイクル](/docs/media-buy/media-buys/) — 完全なライフサイクルリファレンス: キャンペーン構造、パッケージモデル、非同期操作
* [`create_media_buy`](/docs/media-buy/task-reference/create_media_buy) — リクエストパラメーター、レスポンス形状、例を伴うタスクリファレンス
* [`sync_creatives`](/docs/creative/task-reference/sync_creatives) — セラーが `creative.has_creative_library: true` をアドバタイズするときライブラリクリエイティブをアップロードして更新
* [アカウンタビリティ](/docs/media-buy/advanced-topics/accountability) — パフォーマンス標準、測定条件、メイクグッド解決
* [最適化とレポート](/docs/media-buy/media-buys/optimization-reporting) — 配信監視、次元レポート、キャンペーン更新