> ## 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 がメディアバイの課金メトリックの権威的カウンターをどう名指し、数値を最終としてマークし、バイヤーとセラーのビューが不一致のときそれらを照合するか。 ## 概要 メディアバイが決定的に請求するには、2 つの質問が機械可読な答えを持たなければなりません: 1. **誰の数値が権威的か?** 異なるディールは異なる当事者を名指します — セラーの広告サーバー、バイヤーのサードパーティ広告サーバー、または Nielsen や IAS のような名指しされた測定ベンダー。 2. **その数値は動くのを止めたか?** テレメトリーは数時間、数日、数週間で落ち着きます（放送 C3 → C7 DVR 蓄積、デジタル IVT 後スクラブ、ポッドキャスト 30 日ダウンロード、コンバージョン dedup）。最終数値は請求可能。暫定数値はそうでない。 AdCP は両方に、既にワイヤー上にある構造化条件で答えます: `measurement_terms.billing_measurement`（`create_media_buy` で交渉）が権威を名指す。`finalized_at` タイムスタンプ付き `is_final` / `final` フラグ（`get_media_buy_delivery` と `report_usage` 上）がクロージャーをマークする。 このページはそれらの部分を結びつけます。 ## 権威の名指し `measurement_terms.billing_measurement` は以下を運びます: | Field | Meaning | | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `vendor`（必須、[BrandRef](/docs/brand-protocol/brand-json)） | 課金メトリックのカウントが請求を統制する当事者。同じフィールド形状がセラーの広告サーバー、バイヤーの 3PAS、またはサードパーティベンダーをカバー — BrandRef ドメインが曖昧性解消。 | | `max_variance_percent` | セラーと権威当事者のカウントが `makegood_policy` の下で解決をトリガーする許容度。IAB デフォルトは 10%。放送/CTV はしばしば 5%。 | | `measurement_window` | データのどの成熟段階が照合ポイントか（`c7`、`post_sivt`、`downloads_30d` など） — 製品の `reporting_capabilities.measurement_windows` からの `window_id` を参照。 | | `finalization_deadline_hours` | 権威当事者が最終レコードを公開しなければならない（MUST）最大時間。`measurement_window` が設定されているとき、時間はウィンドウのクローズから数えられる（`reporting_period.end` からではない）。不在のとき、`reporting_period.end` から。デッドラインは `vendor` に名指しされたどちらの当事者にも対称的に適用。ミス時、相手方は自身の証明にフォールバックしてもよい（MAY）。違反は `makegood_policy` の下で処理される。 | 不在は情報的です: `billing_measurement` が不在のとき、デフォルトはセラー証明で、契約上の最終化デッドラインなし。 ## 数値を最終としてマーク Final は **名指しされた測定ウィンドウについて落ち着いた** を意味します — 「永遠に最終」ではありません。`measurement_window: "c3"` について `is_final: true` とマークされた放送行は C3 について最終です。後の `c7` 行が自身の暫定 → 最終ライフサイクルでそれを置き換えます。紛争（AdCP 3.2 が追加するとき）は `(media_buy_id, reporting_period, measurement_window)` で結合します。 ### `get_media_buy_delivery` 上 `media_buy_deliveries[]` の各行は以下を運びます: * `is_final: boolean` — 行レベルの最終性、行のすべてのパッケージが同じウィンドウについて最終であることと同等。 * `finalized_at: string (date-time)` — `is_final: true` のとき、かつそのときのみ存在。`billing_measurement.finalization_deadline_hours` で宣言された任意のデッドラインをアンカー。 * パッケージごと: `by_package[*].is_final`、`by_package[*].finalized_at`、`by_package[*].measurement_window`、`by_package[*].supersedes_window`。 ### `report_usage` 上 各使用レコードは以下を運びます: * `final: boolean` — **不在は不明を意味する。** レポーターが実際に数値を落ち着けたとき（例: post-SIVT 月末クローズ）のみ `true` を設定。予備レコード（日次ペーシングプッシュ、期間内進捗）には `false` を設定。`measurement_terms.billing_measurement` がこのレポーターを権威的と名指すとき、受信者は `final: false` または不在で請求してはならない（MUST NOT） — まず最終レコードを要求。`billing_measurement` なしの 3.0 スタイル使用と非メディアバイバリアント（signals、governance、creative、brand — 暫定状態概念のないドメイン）には、受信者は不在を最終として扱い既存動作を保持してもよい（MAY）。 * `finalized_at: string (date-time)` — `final: true` のとき、かつそのときのみ存在。 * `measurement_window: string` — バイの `billing_measurement.measurement_window` が設定されているとき設定すべき（SHOULD）、受信者が正しい段階に対して照合するように。 同じ `(account, media_buy_id, reporting_period)` が後で `final: true` でレポートされるとき、そのレコードは期間の任意の以前のレコードを置き換えます。 ### Webhook 最終性を行最終性から区別する `get_media_buy_delivery` webhook は `"final"` を含むトップレベル `notification_type` enum を運びます — これは **「これはキャンペーンの最後の予定された通知」** をシグナルし、含まれる行が請求に最終であることではありません。2 つの軸は独立: `notification_type: "final"` の webhook は依然として `is_final: false` の行を含むかも（例: C7 が落ち着く前のキャンペーン終了通知）。課金決定には常に行ごとの `is_final` をチェックしてください。 ## セラーが請求書をどう生成するか ### セラー証明（デフォルト） ``` billing_measurement absent, or vendor names seller's own ad server ``` セラーは契約された `measurement_window` について `is_final: true` の `get_media_buy_delivery` 行から請求します。バイヤーからの `report_usage` は不要。 ### バイヤー証明（3PAS） ``` billing_measurement.vendor.domain = "campaignmanager.google.com" (buyer's CM360) billing_measurement.max_variance_percent = 10 billing_measurement.measurement_window = "post_sivt" billing_measurement.finalization_deadline_hours = 240 // 10 days after post_sivt close ``` シーケンス: 1. バイヤーの CM360 が期間について post-SIVT を落ち着ける。 2. バイヤーのオペレーター — 実際には holdco プラットフォーム（例: Choreograph、Annalect、Acxiom）または CM360 エクスポートをラップするインハウスエージェンシーエンジニアリングチーム — がメディアバイレコードで `report_usage` を呼ぶ: `media_buy_id`、`impressions`、`vendor_cost`、`currency`、`final: true`、`finalized_at`、`measurement_window: "post_sivt"`。日次ペーシングプッシュ（使われる場合）は `final: false` を設定。落ち着いたファイルのみが `final: true` を設定。 3. セラーが `get_media_buy_delivery` からの自身の post-SIVT 行（`is_final: true`、同じ `measurement_window`）と比較。`|seller - buyer| / max ≤ max_variance_percent` なら、セラーはバイヤーの数値で請求。 4. 分散がしきい値を超えるなら、セラーは `makegood_policy.available_remedies` から救済を提案。 5. バイヤーが `finalization_deadline_hours` 内に最終レコードを公開しないなら、セラーは自身のセラー証明数値から請求し遅い最終化を `makegood_policy` の下の違反として扱ってもよい（MAY）。 > **今日の現実:** 月次 3PAS 照合はほとんど、セラーの AR チームにメールされた CSV/PDF 経由で帯域外で処理されます。このフローはワイヤー形式アップグレードです — 最初のアダプターは、CM360 / Flashtalking / Innovid エクスポートを `report_usage` でラップするエンジニアリングを持つ holdco オペレーターの可能性が高く、RTB SSP ではなく共感的な直接パブリッシャーと働きます。 ### ベンダー証明（名指しされたサードパーティ） ``` billing_measurement.vendor.domain = "nielsen.com" billing_measurement.max_variance_percent = 5 billing_measurement.measurement_window = "c7" billing_measurement.finalization_deadline_hours = 528 // 22 days after c7 close ``` 誰がベンダー関係を保持するかに応じて 2 つの運用パターン: * **セラーがベンダー関係を保持（一般的な CTV パターン）。** セラーは自身のスケジュールで Nielsen（NPower など）から C7 数値を引き、C7 ウィンドウがクローズプラス内部処理するとき `measurement_window: "c7"`、`is_final: true`、`finalized_at` 設定で `get_media_buy_delivery` に行として公開。バイヤーからの `report_usage` プッシュ不要。照合はセラーの行に対して起こる。 * **バイヤーがベンダー関係を保持。** バイヤー（またはそのオペレーター）がベンダーの権威数値をフェッチ — 例: エージェンシーの iSpot サブスクリプション、インハウス IAS ダッシュボードエクスポート — し、`final: true`、`finalized_at`、`measurement_window: "c7"` でバイのアカウントに対して `report_usage` 経由でプッシュ。ベンダー自体は AdCP を呼ばない。 `vendor.domain` BrandRef はコントラクトが誰を名指すかを識別し、誰が API を呼ぶかではありません。ベンダー自身の統合（NPower フィード、IAS API、DV pinnacle）は AdCP 範囲外です。 > **今日の現実:** RTB を実行する SSP は当面セラー証明であり続けます — 彼らの課金システムはバイヤー証明の請求基準のため設計されたことがなく、`max_variance_percent` プラス `makegood_policy` は彼らがそれをレトロフィットする十分な商業カバーではありません。ここでの最初の実際のアダプターは、Nielsen バックの保証が既に測定ベンダーのカウントで請求する CTV 直接セラー（例: Disney、NBCU、Paramount）です — 彼らにとってこの PR は既存の慣行を構造化された条件で記述するだけです。 ## 今日の不一致の解決 数値が `max_variance_percent` を超えて不一致のとき、AdCP 3.0–3.1 は以下に裏付けられた相手方間の帯域外解決を期待します: * バイの `makegood_policy.available_remedies` — セラーが事前コミットした救済のメニュー（追加配信、クレジット、請求書調整）。 * 両側の `finalized_at` タイムスタンプ付き最終レコード — 誰が何が最終と言ったか、いつかの完全な監査証跡。 * `create_media_buy` で捕捉された元の `committed_metrics` と `measurement_terms` — 当事者が同意したもの。 構造化紛争タスク — ワイヤー上で紛争を開き、`under_review` / `seller_proposed_adjustment` / `buyer_accepted` / `unresolved_arbitration` を通じて遷移させ、監査ログに解決を記録 — は AdCP 3.2 にターゲットされています。紛争に必要なデータ形状（最終レコード、証明、測定ウィンドウ、メイクグッドメニュー）は既に 3.1 でワイヤー上にあります。 ## 実例: バイヤー証明 3PAS 照合 ```json title="create_media_buy excerpt — measurement terms" theme={null} { "measurement_terms": { "billing_measurement": { "vendor": { "domain": "campaignmanager.google.com" }, "max_variance_percent": 10, "measurement_window": "post_sivt", "finalization_deadline_hours": 240 }, "makegood_policy": { "available_remedies": ["additional_delivery", "credit", "invoice_adjustment"] } } } ``` ```json title="get_media_buy_delivery — seller's final post-SIVT row" theme={null} { "media_buy_deliveries": [ { "media_buy_id": "mb_q1_2026", "is_final": true, "finalized_at": "2026-04-08T18:00:00Z", "by_package": [ { "package_id": "pkg_001", "is_final": true, "finalized_at": "2026-04-08T18:00:00Z", "measurement_window": "post_sivt", "impressions": 5120000, "spend": 51200 } ] } ] } ``` ```json title="report_usage — buyer's final 3PAS push" theme={null} { "idempotency_key": "f9b3...e2a1", "reporting_period": { "start": "2026-03-01T00:00:00Z", "end": "2026-03-31T23:59:59Z" }, "usage": [ { "account": { "account_id": "acct_acme_seller" }, "media_buy_id": "mb_q1_2026", "currency": "USD", "impressions": 5040000, "vendor_cost": 50400, "final": true, "finalized_at": "2026-04-09T14:32:00Z", "measurement_window": "post_sivt" } ] } ``` 分散: `|5120000 - 5040000| / 5120000 = 1.56%` — 10% しきい値を十分に下回る。セラーはバイヤーの 5.04M インプレッション × 合意されたレートで請求。両側が監査追跡可能な最終レコードを保持。 ## 関連 * [`measurement-terms`](https://adcontextprotocol.org/schemas/v3/core/measurement-terms.json) — スキーマ * [`get_media_buy_delivery`](/docs/media-buy/task-reference/get_media_buy_delivery) — セラー側最終性フラグ * [`report_usage`](/docs/accounts/tasks/report_usage) — バイヤー側 / サードパーティ最終性フラグ * [アカウンタビリティ](/docs/media-buy/advanced-topics/accountability) — パフォーマンス標準、メイクグッド救済、キャンセル * [レポートケイパビリティと測定ウィンドウ](/docs/media-buy/media-buys/optimization-reporting)