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

# v3 レディネスチェックリスト

> セラーエージェントが AdCP v3 ストーリーボードテストに合格するための 8 つの最小要件。

# v3 レディネスチェックリスト

AdCP ストーリーボードテストは v3 プロトコルサポートを必要とします。v2 のみをサポートするエージェントは失敗します。このページは、v3 バイヤーとの統合テストのブロックを解除する最小限の変更をカバーします — 完全な移行ではありません。完全なリストについては [移行ガイド](/docs/reference/migration) を参照。

<Warning>
  ストーリーボードテストは、v3 サポートを宣言しない任意のエージェントをハードに失敗させます。まずこれら 8 項目を完了し、次に [完全な移行チェックリスト](/docs/reference/migration) を進めてください。v2 は 2026 年 8 月 1 日（UTC）に完全に非推奨になります — [v2 sunset ページ](/docs/reference/v2-sunset) を参照。
</Warning>

***

## 1. `get_adcp_capabilities` を実装する

v3 バイヤーは、エージェントが何をサポートするかを発見するためにこのタスクを最初に呼びます。それなしでは、バイヤーはプロトコルバージョン、サポートチャネル、価格モデル、機能を判断できません。

これは最も重要な単一の変更です — バイヤー（とストーリーボードテスト）が v3 エージェントを v2 から区別する方法です。

最低限次を返します: `major_versions: [3]`、`supported_protocols`、`features` オブジェクト。

<Card title="get_adcp_capabilities リファレンス" icon="arrow-right" href="/docs/protocol/get_adcp_capabilities">
  タスク仕様とレスポンススキーマ。
</Card>

***

## 2. チャネルタクソノミーを更新する

v3 は v2 の 9 チャネルを 20 のプランニング指向チャネルに置き換えます。バイヤーは v3 チャネル値を送ります — エージェントはそれらを認識しなければなりません。

| Common v2 value | v3 replacement                    |
| --------------- | --------------------------------- |
| `video`         | `olv`、`linear_tv`、または `cinema`    |
| `audio`         | `radio` または `streaming_audio`     |
| `native`        | 削除 — ネイティブインベントリは今や `display` の一部 |
| `retail`        | `retail_media`                    |

`display`、`social`、`ctv`、`podcast`、`dooh` は変更なし。

<Card title="チャネル移行" icon="arrow-right" href="/docs/reference/migration/channels">
  完全なマッピング表と例。
</Card>

***

## 3. 価格フィールドをリネームする

2 つのフィールドリネーム — 同じセマンティクス、異なる名前:

| v2 field               | v3 field              |
| ---------------------- | --------------------- |
| `fixed_rate`           | `fixed_price`         |
| `price_guidance.floor` | `floor_price`（トップレベル） |

バイヤーは v3 スキーマに対して検証します。古いフィールド名はスキーマ検証失敗を引き起こします。

<Card title="価格移行" icon="arrow-right" href="/docs/reference/migration/pricing">
  before/after の例と price guidance の再構築。
</Card>

***

## 4. `creative_assignments` をサポートする

`creative_ids`（文字列配列）は、配信重み付けとプレースメントターゲティングを持つ `creative_assignments`（オブジェクト配列）に置き換えられます。

```json theme={null}
// v2
{ "creative_ids": ["cr_001", "cr_002"] }

// v3
{ "creative_assignments": [
    { "creative_id": "cr_001", "weight": 70 },
    { "creative_id": "cr_002", "weight": 30 }
  ]
}
```

<Card title="クリエイティブ移行" icon="arrow-right" href="/docs/reference/migration/creatives">
  重み付き割り当て、プレースメントターゲティング、アセットディスカバリー。
</Card>

***

## 5. `brand_manifest` の代わりに `brand` ref を受け入れる

バイヤーは、インラインマニフェストの代わりに参照（`{ domain, brand_id }`）としてブランドアイデンティティを渡します。エージェントは実行時に `brand.json` またはレジストリからブランドデータを解決します。

```json theme={null}
// v2
{ "brand_manifest": { "name": "Acme", "logo": "..." } }

// v3
{ "brand": { "domain": "acme.example.com", "brand_id": "acme_main" } }
```

<Card title="ブランドアイデンティティ移行" icon="arrow-right" href="/docs/reference/migration/brand-identity">
  BrandRef スキーマ、解決フロー、移行ステップ。
</Card>

***

## 6. `get_products` の `buying_mode` を扱う

`buying_mode` は今やすべての `get_products` リクエストで必須です。`brief` がキュレーションされたプロダクトディスカバリーのベースラインモードです。エージェントが `media_buy.buying_modes` で `wholesale` または `refine` を宣言する場合、それらのモードセマンティクスも扱わなければなりません。

<Card title="get_products リファレンス" icon="arrow-right" href="/docs/media-buy/task-reference/get_products">
  buying\_mode を含む完全なリクエストスキーマ。
</Card>

***

## 7. `buyer_ref` を削除 — `idempotency_key` を使う

v3 はすべてのリクエストとレスポンスから `buyer_ref`、`buyer_campaign_ref`、`campaign_ref` を削除します。セラー割り当ての `media_buy_id` と `package_id` が今や唯一の正準識別子です。

エージェントが重複排除に `buyer_ref` に依存していた場合、代わりに新しい `idempotency_key` フィールドを使ってください。`idempotency_key`（UUID v4）はすべての変更リクエストで **必須** です — エージェントはそれを省略するリクエストを `INVALID_REQUEST` で拒否しなければならず（MUST）、キーが異なるペイロードで再利用されたとき `IDEMPOTENCY_CONFLICT` を返さなければなりません（MUST）。規範的セマンティクスについては [冪等性実装ガイド](/docs/building/by-layer/L1/security#冪等性) を参照。

エージェントが内部トラッキングや相関（例: キャンペーン ID、セッショントレース、UI 状態へのマッピング）に `buyer_ref` を使った場合、代わりに `context` フィールドを使ってください。`context` は、すべてのレスポンスと webhook で変更なくエコーされる不透明なオブジェクトです — エージェントはそれを決してパースしたり、それに基づいて行動したりしてはなりません。`create_media_buy` のパッケージ相関については、非推奨のトップレベル `buyer_ref` ではなく `packages[i].context`（例えば `context.buyer_ref`）にパッケージごとのトラッキングを置いてください。3.1+ セラーは明示的なパッケージレスポンスに `product_id` をエコーしなければならず（MUST）、パッケージコンテキストはそうしないレガシーセラーのフォールバックのままです。

| v2 field                    | v3 replacement                  |
| --------------------------- | ------------------------------- |
| `buyer_ref`                 | 削除 — `media_buy_id`（セラー割り当て）を使う |
| `buyer_campaign_ref`        | 削除                              |
| `campaign_ref`              | 削除                              |
| 暗黙の重複排除としての `buyer_ref`     | 変更リクエストの明示的な `idempotency_key`  |
| 相関 / トラッキングとしての `buyer_ref` | `context`（不透明、変更なくエコー）          |

```json theme={null}
// v2 — バイヤーが自身の ref を提供
{ "buyer_ref": "camp-2024-q3", "start_time": "..." }

// v3 — セラー割り当て ID、明示的な冪等性、トラッキング用の context
{
  "idempotency_key": "550e8400-e29b-41d4-a716-446655440000",
  "context": { "campaign": "camp-2024-q3", "trace_id": "abc-123" },
  "start_time": "..."
}
```

パッケージレベルのラインアイテム相関については、バイレベルのコンテキストを各パッケージのフォールバック相関ハンドルと分けて保ちます:

```json test=false theme={null}
{
  "idempotency_key": "550e8400-e29b-41d4-a716-446655440001",
  "context": {
    "internal_campaign_id": "camp-2024-q3"
  },
  "brand": {
    "domain": "example-brand.test"
  },
  "packages": [
    {
      "product_id": "prod_weekday_display",
      "pricing_option_id": "cpm_usd_auction",
      "format_ids": [
        {
          "agent_url": "https://creative.adcontextprotocol.org",
          "id": "display_300x250_image"
        }
      ],
      "budget": 12000,
      "context": {
        "buyer_ref": "line-001"
      }
    },
    {
      "product_id": "prod_weekend_video",
      "pricing_option_id": "cpm_usd_auction",
      "format_ids": [
        {
          "agent_url": "https://creative.adcontextprotocol.org",
          "id": "video_standard_30s"
        }
      ],
      "budget": 18000,
      "context": {
        "buyer_ref": "line-002"
      }
    }
  ],
  "start_time": "2026-07-01T00:00:00Z",
  "end_time": "2026-07-31T23:59:59Z"
}
```

***

## 8. `sync_accounts` を実装する

v3 バイヤーは、バイを置く前に課金関係を確立します。エージェントは `sync_accounts` 呼び出しを受け入れ、バイヤーが後続のリクエストに含めるアカウント参照を返さなければなりません。

<Card title="Accounts Protocol" icon="arrow-right" href="/docs/accounts/overview">
  アカウントプロビジョニング、ライフサイクル、sync\_accounts タスク。
</Card>

***

## これら 8 項目の後

これらが整ったら、エージェントに対してストーリーボードテストを実行してください。既存のトラック（products、media buy、creative）は v3 スキーマを詳細に検証し、残るフィールドレベルの問題をサーフェスします。

完全な移行 — ジオターゲティング、最適化目標、シグナル、オーディエンス、アトリビューションを含む — については [完全な移行ガイド](/docs/reference/migration) を参照。
