> ## 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 メジャメントの 3 層モデル — メトリック（配信）、検証（品質）、アトリビューション（結果） — と各層が真実の源泉、プロトコルの居場所、変化速度でどう異なるか。

# メジャメント分類

メジャメントは 1 つではなく 3 つのものです。それらを 1 つのバケットとして扱うことが、メジャメント RFC（SSAI、アイデンティティ喪失、AI コンテンツプロベナンス、クリーンルーム）のほとんどの混乱と、配信レスポンスのほとんどのスキーマ肥大化の源です。AdCP はそれらを意図的に分離します。

3 つの層 — **メトリック**、**検証**、**アトリビューション** — は異なる質問に答え、異なる当事者によって証明され、プロトコルの異なる場所に存在し、異なる速度で進化します。

## 3 つの層

| Layer         | Question     | Source of truth | Protocol home                                 | Rate of change |
| ------------- | ------------ | --------------- | --------------------------------------------- | -------------- |
| **メトリック**     | 起こったか?       | セラー             | 配信レポート                                        | 遅い（10 年スケール）   |
| **検証**        | 適切にカウントされたか? | サードパーティ         | パフォーマンス標準 + ケイパビリティ + マニフェストトラッカー + ベンダー証明配信値 | 中（環境駆動）        |
| **アトリビューション** | 結果を引き起こしたか?  | バイヤー            | ハンドオフフック（イベントソース、ログレベルシグナル）                   | 速い（モデル駆動）      |

### 1. メトリック — 「起こったか?」

配信事実: インプレッション、完了、quartile、クリック、支出、リーチ、フリークエンシー。リーチとフリークエンシーは明示的な `reach_window` 宣言（`cumulative` / `period` / `rolling`）を運び、バイヤーが値を行全体で合計できるか知れます。

標準とベンダーメトリックフローの両方にわたる完全なケイパビリティ → コミットメント → 最適化 → 配信の絵については、[メトリックライフサイクル](/docs/media-buy/media-buys/optimization-reporting#metric-lifecycle) を参照。同じ `(vendor, metric_id)` キーが、ベンダー証明メトリックのすべての表面 — ディスカバリー、最適化ケイパビリティ、レポートケイパビリティ、パッケージコミットメント、最適化目標、パフォーマンス標準、配信値 — を通じて流れます。

セラーが真実の源泉です — セラーが広告をサーブしイベントをカウントします。業界カウント規約（MRC、IAB）が何がインプレッションとして資格を持つか、何が動画ビューを完了するか、どう重複排除するかを定義します。AdCP はセラーがこれらのカウントをどう露出するかを標準化します。それらが何をカウントするかを再定義しません。

1 つのニュアンス: `available-metric.json` の一部のメトリック（ROAS、CPA、コンバージョン、conversion\_value、units\_sold）はセラーレポートだが **アトリビューション由来** です — セラーがバイヤー供給のイベントソースにアトリビューションモデルを実行し結果をレポートします。それらは、すべての DSP とリテールメディアプラットフォームが今日それらを露出する場所だから配信レポートに存在しますが、基盤となる真実のイベントはバイヤー証明です。これらを *「配信を通じて表示されたアトリビューション」* として読み、純粋な配信事実として読まないでください。セラーの数値はバイヤーのイベントに対するセラーのアトリビューションモデルを反映します。バイヤー側グラウンドトゥルースに対する照合は依然としてアトリビューション境界に属します。

AdCP では、メトリックは配信レポートを通じて流れます:

* [`get_media_buy_delivery`](/docs/media-buy/task-reference/get_media_buy_delivery) — 現在の配信状態
* [`provide_performance_feedback`](/docs/media-buy/task-reference/provide_performance_feedback) — バイヤー側観測パフォーマンス
* [最適化とレポート](/docs/media-buy/media-buys/optimization-reporting) — レポートが最適化目標にどう接続するか

メトリックはゆっくり進化します。定義は業界団体によって統制されます。新しいメトリック（ビューアブルインプレッション、アテンション秒）は 10 年スケールで現れます。ここでのスキーマ圧力は低いです。

### 2. 検証 — 「適切にカウントされたか?」

品質証明: ビューアビリティ、無効トラフィック（IVT）、ブランドセーフティ、geo 精度、コンテキスト適合性、広告コンテンツプロベナンス。

検証の全ポイントは、それがセラーの言葉 *でない* ことです。バイヤーは、独立した当事者がインプレッションが品質しきい値を満たしたことを確認できるよう、まさにサードパーティ測定ベンダー（Moat、IAS、DoubleVerify）と契約します。検証は配信環境を生き延びる実行パスを要求します — 歴史的にはクライアント側で動く OMID と VPAID。SSAI では、サーバー側回避策としての [SIVA](https://iabtechlab.com/standards/siva/)。

AdCP では、検証はベンダーの `brand.json` 測定エージェントレコードにアンカーされ、バイライフサイクル全体で構造化表面を持ちます:

* **ディスカバリー。** バイヤーは [`get_products`](/docs/media-buy/task-reference/get_products) で `required_performance_standards`（「DoubleVerify による 70% MRC ビューアビリティ」）、`required_metrics`、`required_vendor_metrics` で製品をフィルターします。セラーは `reporting_capabilities.available_metrics`、`vendor_metrics`、`committed_metrics_supported` ケイパビリティフラグ経由でサポートを宣言します。
* **コミットメント。** [`performance-standard.json`](/docs/media-buy/task-reference/create_media_buy) が `metric` + `threshold` + `standard`（例: MRC 対 GroupM ビューアビリティ）+ `vendor` をバイコントラクトにバインドします。ベンダーはベンダーの `brand.json` `agents[type='measurement']` レコードに解決する `BrandRef` です。パフォーマンス標準がコミットされると、*クリエイティブはそのベンダーからの `tracker_script` または `tracker_pixel` アセットを含まなければなりません（MUST）* — プロトコルがパスを強制します。`committed_metrics` は `create_media_buy` でパッケージのレポートコントラクトをスナップショットし（閉じた `available-metric.json` enum からの標準メトリックと `BrandRef` にアンカーされたベンダー定義メトリックの両方を運ぶ統一された判別された配列、各エントリーが `committed_at` でタイムスタンプ付き）、バイの寿命の間追加のみです。
* **実行。** [クリエイティブマニフェスト](/docs/creative/creative-manifests) は、サードパーティベンダーがイベントを記録するよう配信時に発火するトラッカーとマクロ（`vast_tracker`、`daast_tracker`、ユニバーサルマクロ）を運びます。それらがクライアント側かサーバー側で発火するかはセラーの実装詳細です。バイヤーのコントラクトはパスではなくメトリックにあります。
* **レポート。** 閉じた `available-metric.json` enum に卒業した標準検証メトリック（例: `viewability`）は、[`delivery-metrics.json`](/docs/media-buy/task-reference/get_media_buy_delivery) の専用配信スカラーを通じて流れます。非卒業のベンダー定義メトリックは、カバレッジ分母としての `measurable_impressions` とともに `vendor_metric_values` を通じて流れます。ベンダーアトリビューションは、配信行自体ではなく、`committed_metrics` と `performance_standards.vendor` 経由でコントラクトレベルでアンカーされます。`missing_metrics` は、セラーがコミットされたメトリックを配信しなかったときアカウンタビリティギャップを表示します — `committed_metrics` が存在するとき、照合は正確でタイムスタンプ対応です。不在のとき、`missing_metrics` はコミットメントタイムスタンプフィルターなしで製品のライブ `available_metrics` にフォールバックしギャップを過小レポートします。バイヤーは `committed_metrics` の不在を *「監査グレードのコントラクトなし」* として扱うべきで（SHOULD）、*「クリーンな配信」* ではありません。

ベンダーの完全な *ダッシュボード* はベンダー（Moat、IAS、DV、HUMAN など）に存在しますが、証明された数値は AdCP 配信レポートを通じて戻ります。測定エージェントはファーストクラスアイデンティティです — `brand.json` `agents[type='measurement']`（BrandRef アンカー）経由で発見可能で、メトリックカタログ（`metric_id`、`standard_reference`、`accreditations[]`、`unit`、`methodology_url`、`methodology_version`）はエージェントの [`get_adcp_capabilities`](/docs/protocol/get_adcp_capabilities) レスポンスの `measurement` ブロックの下でサーブされます。`brand.json` がディスカバリーポイント。エージェントがカタログをサーブします。

#### 卒業した検証メトリック

検証メトリックは標準化の異なる速度で進化し、プロトコルはそのグラデーションのどこに位置するかに基づいて異なるレベルの構造サポートを与えます:

* **Tier 1 — 卒業。** 業界公開、MRC または同等認定。複数の競合する標準が存在しうる。閉じた `available-metric.json` enum の専用エントリー、`delivery-metrics.json` の専用構造化ブロック、（標準が相互に互換でないとき）曖昧性解消のための `committed_metrics` の `qualifier` スロットを得る。**ビューアビリティ** は今日の正準 Tier 1 メトリック — MRC と GroupM は実質的に異なるしきい値を定義し `qualifier.viewability_standard` 経由のスキーマ強制曖昧性解消を要求。
* **Tier 2 — ベンダー拡張。** 業界公開標準のないベンダー定義メトリック。セラーは `reporting_capabilities.vendor_metrics` 経由でレポートサポートを、`vendor_metric_optimization.supported_metrics` 経由で最適化サポートを宣言。値は `vendor_metric_values` 経由で流れる。目標は `kind: "vendor_metric"` で `optimization_goals` 経由でベンダーにバインド。アイデンティティはベンダーの `BrandRef` にアンカーされカタログはベンダーの測定エージェントケイパビリティに存在。**アテンションスコア、パネルベースブランドリフト、パネルデモグラフィック、インプレッションごと排出量** が今日ここに位置。
* **Tier 3 — 主張。** 構造化ベンダーアイデンティティまたは標準担持者証明のない製品上のフリーフォームクレーム。BrandRef パターンに先行し、漸増的に上方に再構築されている。

メトリックは、業界標準団体が測定仕様を公開するとき Tier 2 から Tier 1 に卒業します — ベンダー数しきい値や非公式収束ではなく、標準団体の公開にアンカーされます。Tier 1 をサポートするパターン（`qualifier` スロット、専用配信スカラー、パフォーマンス標準バインディング）は再利用可能なテンプレートです: ビューアビリティは最初のインスタンスで、ビューアビリティ固有のカスタム形状ではありません。

#### クローズドループトポロジー: セラーを測定エージェントとして

卒業したメトリックフレーミングは、デフォルト測定トポロジーが *セラーがサーブ、サードパーティが検証* — DV/IAS がビューアビリティを証明しパブリッシャーの広告サーバーがインプレッションをカウント — であると仮定します。それは依然として従来の CTV、ビデオ、ディスプレイの支配的パターンです。しかし 2 つのチャネルクラスは異なるデフォルトを持ちます:

* **リテールメディアクローズドループ**: Walmart Connect、Kroger Precision、Amazon DSP、Criteo Retail Media。リテーラーは自身の表面で広告をサーブし、自身の表面でクリックを観測し、自身の表面でコンバージョン（ロイヤルティカード、ログイン、POS）を観測します。セラーは測定ベンダーでもあります。トラストモデルはサードパーティ独立性ではなくリテーラーのファーストパーティデータアセットに基づきます。
* **AI ネイティブチャネル**: ChatGPT と他のエージェンティック会話表面は、広告を会話ストリームに直接注入します（サーバー側）。クリックナビゲーションはセラーが制御するアプリ内 webview で起こります。コンバージョンアトリビューションは、マーチャントのプロパティにデプロイされたセラー提供 SDK（OpenAI には `oaiq.min.js`）を通じて戻ります。セラーは再び測定ベンダーでもあります。

これらはサードパーティ検証の劣化ケースではありません — プロトコルが既存のプリミティブ経由でクリーンにサポートする構造的に異なるトポロジーです:

* **セラーがベンダーのときベンダーアイデンティティは暗黙**: BrandRef が `delivery_measurement.vendors` でセラーにアンカー。ベンダースコープの `committed_metrics` エントリーがセラーの測定エージェントケイパビリティを指す。`performance_standards.vendor`（存在するとき）がセラーを名指す。追加スキーマ不要。
* **結果メトリックは同じ語彙を通じて流れる**: `conversion_value` + `qualifier.attribution_methodology: "deterministic_purchase"` + `qualifier.attribution_window: { interval: 30, unit: "days" }` が、ChatGPT のアトリビューショントークンベースのコンバージョンアトリビューションと Walmart Connect の `attributedSalesIn14Days` をクリーンに表現。リテールメディア固有スキーマなし、AI ネイティブ固有スキーマなし。
* **`(metric_id, qualifier)` 行形状が両方を処理**: コントラクト / diff / 配信 / フィードバックが、ベンダーがサードパーティかセラー-as-ベンダーかにかかわらず同じ方法で照合。

今日欠けているもの: セラーが、イベントをセラーに戻すためバイヤーがプロパティにデプロイする **マーチャント側 SDK**（OAIQ パターン）を宣言する構造化された方法。別の RFC（[#3889](https://github.com/adcontextprotocol/adcp/issues/3889)）として追跡 — 既存のプリミティブは *何が測定されるか* を表現。SDK 配布 / 統合 / サプライチェーンストーリーがギャップ。

検証は中程度のペースで進化します。環境シフト — CTV、SSAI、ウォールドガーデン、クッキーレス、AI 生成コンテンツ、AI ネイティブチャネル — が新しいシグナル喪失問題とそれらを回復する新しいプロトコルを駆動します。検証ケイパビリティへのスキーマ圧力を 1〜3 年ごとに期待してください。

### 3. アトリビューション — 「結果を引き起こしたか?」

配信と結果間のバイヤー側結合: コンバージョン、リフト、マルチタッチアトリビューション、メディアミックスモデリング、インクリメンタリティ。

セラーはコンバージョンイベントを知りません。バイヤー（またはバイヤーの測定パートナー）が結果データを保持しそれを配信に結合します。AdCP の役割は結合を可能にすることです — ログレベルシグナル、アイデンティティフック、クリーンルームへのハンドオフパターンを露出 — モデルを実行することではありません。

AdCP では、アトリビューションは *境界* に現れます:

* [`sync_event_sources`](/docs/media-buy/task-reference/sync_event_sources) — バイヤーがコンバージョンイベントソースをセラープラットフォームにプッシュし、プラットフォームが実結果に向けて最適化できる
* [`log_event`](/docs/media-buy/task-reference/log_event) — バイヤー証明イベント配信
* [コンバージョントラッキング](/docs/media-buy/conversion-tracking/) — 配信を結果に接続するパターン
* [Trusted Match](/docs/trusted-match/) — PII をリークせずに結合を可能にするアイデンティティ解決

モデル自体（クリーンルーム、MMM、因果推論、エージェンティック結果アトリビューション）は完全にプロトコルの外側に存在します。

アトリビューションは最も速く進化します。クリーンルームパターン、MMM 復活、因果 AI、コマースメディアアトリビューション、エージェンティック結果モデルはすべて、四半期から年のスケールでアトリビューション層をシフトします。アトリビューションが配信スキーマ内に存在したら、それはサイクルごとにスキーマ破損を強いるでしょう。

## なぜ分離が重要か

ワーキンググループのほとんどのメジャメント議論は、層が名指しされるとより速く解決します:

* **SSAI**（[#3759](https://github.com/adcontextprotocol/adcp/issues/3759)）は *検証* 問題です。どのメトリックがレポートされるかを変えません。どの検証パスが有効か、生き延びるシグナルがどれだけリッチかを変えます。修正は配信レポートではなくケイパビリティ + クリエイティブマニフェストトラッカーに存在します。
* **アイデンティティ喪失**（クッキーレス、IDFA 非推奨、ウォールドガーデンシグナル崩壊）はメトリックではなく *アトリビューション* に現れます。セラーは依然としてサーブしインプレッションをカウントします。バイヤーの結果への結合が劣化します。修正は配信ペイロードではなくアトリビューション境界（クリーンルーム、[Trusted Match](/docs/trusted-match/)）に属します。
* **AI コンテンツプロベナンス** は *検証* の関心事（この広告はブランドが承認したものか?）で、アトリビューションの関心事ではありません。他の検証ケイパビリティと並ぶべきで — [プロベナンス検証](/docs/governance/creative/provenance-verification) を参照 — 結果レポートにボルト留めされません。
* **結果ベースの最適化目標**（CPA、ROAS、カスタムイベント）は、最適化入力として表示される *アトリビューション* の関心事です。バイヤーがプラットフォームが何に向けて最適化すべきかを引き渡すイベントソース境界に属します。

提案がアトリビューション概念（リフト、ROAS、MMM 入力）を配信レポートに、または検証概念（OMID、SIVA）をアトリビューションフックに入れるとき、押し返してください。層の不一致はほぼ常に、提案が壊れるまでエッジケースを蓄積することを意味します。

## 実用的経験則

メジャメントフィールドがどこに属するかを評価するとき、**誰が真実の源泉か?** と尋ねます。

* **セラー** がそれをカウント → メトリック → 配信レポート
* **サードパーティ** がそれを証明 → 検証 → ケイパビリティ + クリエイティブマニフェスト
* **バイヤー** が結果を所有 → アトリビューション → イベントソース / ログレベルハンドオフ

この単一の質問がほとんどの配置議論を解決します。2 つの層が同じフィールドを主張するように見える場合、フィールドはおそらく 1 つの名前をまとった 2 つのフィールドです — それを分割してください。

## 原子単位: `(metric_id, qualifier)`

プロトコルのメジャメントプリミティブは、同じ方法でインデックスされ照合される 1 つのタプルに還元されます:

* **`committed_metrics` 行**: `{ scope, metric_id, qualifier, committed_at }` — セラーが投入に同意したもの（[#3576](https://github.com/adcontextprotocol/adcp/pull/3576)、出荷済み）
* **`missing_metrics` 行**: `{ scope, metric_id, qualifier }` — 現れなかったもの（[#3576](https://github.com/adcontextprotocol/adcp/pull/3576)、出荷済み）
* **`metric_aggregates` 行**: `{ metric_id, qualifier, value, …components }` — 実際に配信されたもの、qualifier で分割（[#3848](https://github.com/adcontextprotocol/adcp/issues/3848)、提案）

照合は `(metric_id, qualifier)` の結合に崩れます。各 `committed_metrics` 行について、一致する `metric_aggregates` 行を見つける。一致がないものは `missing_metrics` として表示。カスタムのメトリックごと照合ロジックなし、コントラクトと配信間のトラバーサル非対称なし。

`qualifier` 語彙は表面によって異なります: コントラクトは閉じている（`additionalProperties: false`、今日 `viewability_standard` のみを運ぶ）。配信は意図的な **スーパーセット**（例: `tracker_firing` は、バイヤーがコミットしないがセラーが配信後に露出できる透明性開示として存在）。非対称は名指しされ、偶然ではありません — バイヤーは語彙を共有するものにコミットし、セラーは配信されたもののパスレベル透明性を露出します。

将来の qualifier（`completion_threshold`、標準化するならアテンション方法論）が構造サポートを必要とするとき、既存のスロットに差し込みます。並行 `*_by_*` フィールドなし、新しい集計表面なし、スキーマ破損なし。

## Signals と Governance との境界

メジャメントは AdCP の唯一のサードパーティ証明表面ではありません。[Signals](/docs/signals/overview) と [Governance](/docs/governance/overview) もサードパーティを関与させ、証明されたアーティファクトを生成し、コアメディアバイプリミティブより速く進化します。境界は実際ですが、プロトコルはベンダーとライフサイクルで重なります — Signals 自身の key-concepts ページはシグナルが「ターゲティングまたはメジャメントに」使われると記し、その曖昧性が問題の境界です。

最も明確な分離はライフサイクルモーメントと尋ねられる質問による:

| Lifecycle moment | Question          | Protocol home                 |
| ---------------- | ----------------- | ----------------------------- |
| 決定前              | 何をすべきか?           | Signals                       |
| プラン時             | これをすることを許可されているか? | Governance（ポリシーレジストリ、プランチェック） |
| 配信               | 起こったか? カウントされたか?  | Measurement（メトリック、検証）         |
| 配信後              | どの結果を引き起こしたか?     | Measurement（アトリビューション）        |
| 継続               | 監査証跡は無傷か?         | Governance（監査証跡）              |

同じベンダーがしばしば複数のレーンでプレイします。例えば DoubleVerify は、事前入札ブランドセーフティ *シグナル*、配信後 *検証* 証明、*ガバナンス* ポリシー強制が消費するコンテンツ分類フィードを販売します。ベンダーは 1 つのエンティティです。プロトコル表面は、タイミング、真実の源泉、消費パターンが異なるため 3 つです。

### 線が鮮明な場所

* **シグナルは予測的、メジャメントは記述的。** 事前入札ビューアビリティスコアはシグナル — インプレッションがビューアブルである可能性の推定。配信後ビューアビリティレートはメジャメント。同じ方法論ファミリー、異なる質問。
* **ガバナンスは規範的、メジャメントは事実的。** ガバナンスは「これは私たちが設定したルールに準拠したか?」と尋ねます。メジャメントは「客観的に何が起こったか?」と尋ねます。アトリビューションモデルは、任意のポリシーに違反せずにバイヤーの結果目標と不一致になりうる。配信がクリーンに測定されてもブランドセーフティ違反は起こりうる。
* **シグナルは入力、メジャメントは出力、ガバナンスは制約。** 購入決定はシグナルを消費し、ガバナンスに境界され、メジャメントが記録する事実を生成します。

### 線がぼやける場所

* 事前入札ブランドセーフティ分類子は *シグナル* として販売される。同じベンダーの配信後レポートは *検証*。同じ入力データ、異なるプロトコルの居場所 — データが *いつ* 消費されるかで駆動。
* *ガバナンス* ポリシーが証拠として *メジャメント* 証明を要求できる（「このキャンペーンは MRC 認定ベンダーで検証しなければならない」）。メジャメントがガバナンス承認の前提条件になる。
* *シグナル* が *アトリビューション* モデルを供給 — オーディエンスセグメントとアイデンティティシグナルが結果推定を生成するリフトまたは MMM モデルへの入力。

これらの重複はバグではありません。それらはメジャメントとデータ業界が実際にどう機能するかを反映します: ベンダーはライフサイクル全体で運用し、ある層のイベントがしばしば別の層への入力になります。プロトコルの仕事は *インターフェース* をクリーンに保つこと — 同じベンダー、複数のロール、複数のエンドポイント — で、ライフサイクルを単一の表面に崩すことではありません。

## 実例: サードパーティビューアビリティコミットメント

バイヤーが CTV キャンペーンで MRC しきい値の DoubleVerify ビューアビリティを必要とします。SSAI がスコープ内です。バイヤーはどの製品がそれを使うか知らず気にしません。

**1. ディスカバリー。** バイヤーが以下で `get_products` を呼びます:

```json theme={null}
{
  "required_performance_standards": [
    {
      "metric": "viewability",
      "threshold": 0.70,
      "standard": "mrc",
      "vendor": { "domain": "doubleverify.com" }
    }
  ]
}
```

この在庫で DV の測定をサポートできない製品は — DV のパスが劣化する SSAI 環境を含むどの配管理由でも — 黙ってフィルターアウトされます（filter-not-fail）。セラーは「私は SSAI」と宣言しません。*「このベンダーでこの製品でこのパフォーマンス標準を配信できる」* と宣言します。配管はセラーの問題です。

**2. コミットメント。** バイヤーが `create_media_buy` を呼びます。`performance_standards` がバイコントラクトに入ります。`performance-standard.json` に従い、*クリエイティブは `doubleverify.com` からの `tracker_script` または `tracker_pixel` アセットを含まなければなりません（MUST）*。セラーはコントラクトをスナップショットする `committed_metrics`（標準とベンダーエントリーの両方を運ぶ統一された配列、各が `committed_at` 付き）を返します — バイの寿命の間追加のみ。ビューアビリティコミットメントは `qualifier.viewability_standard: "mrc"` を運び、MRC と GroupM が互いに対して決して照合しないようにします。

**3. 実行。** クリエイティブマニフェストが DV のトラッカーアセットを運びます。それらが発火します — クライアント側、サーバー側、OMID、SIVA、セラーがコミットメントを尊重するため選んだどのパスでも。バイヤーはパスを見ません。

**4. レポート。** バイごとの `totals` が標準 `viewability` ブロック（卒業した Tier 1 表面 — `measurable_impressions`、`viewable_impressions`、`viewable_rate`、`standard`）を投入します。バイ横断の `aggregated_totals` が `metric_aggregates` 経由で qualifier で分割（[#3848](https://github.com/adcontextprotocol/adcp/issues/3848)、提案） — コントラクトと同じ原子単位、`(metric_id, qualifier)` で結合。セラーが任意のコミットされたメトリックを配信できない場合、それは `missing_metrics` に現れます — アカウンタビリティ違反、プロトコル内で表示。

**この例が示すもの。** バイヤーは決して *「これは SSAI か?」* と尋ねません。彼らが実際に持つ質問 — *「選んだ検証ベンダーはこの在庫で信頼できるビューアビリティを生成できるか?」* — は、製品がフィルターを通過するかどうかで構造的に答えられます。セラーの配管は、彼らが作成時に署名したコントラクトに束縛された私的な実装詳細です。SSAI、CSAI、アプリ内、ウェブ、DOOH がすべて同じ表面を通じて流れます。どれも特別なスキーマを得ません。

これは、層が機能するはずの方法で機能する検証です: バイヤーが *必要とする結果*（ベンダー + 標準 + しきい値）を指定し、セラーがコミットするか自身を除外し、アカウンタビリティはナラティブではなく構造的です。

## オープンな質問

分類は何が別個かを明確にしますが、2 つの質問が境界に位置します。

### メジャメントは専用のプロトコル表面を得るべきか?

測定エージェントは既にファーストクラスです: ベンダーは `brand.json` `agents[type='measurement']`（BrandRef アンカー）として発見可能で、`get_adcp_capabilities.measurement.metrics[]` 経由でメトリックカタログを公開し、`performance-standard.vendor`、`vendor_metrics`、`committed_metrics`（ベンダースコープエントリー）から `BrandRef` で参照され、`delivery-metrics.viewability`（卒業した標準）と `vendor_metric_values`（非卒業ベンダーメトリック）を通じて証明された値を発行します。パターンは *「複数のプロトコル全体で消費される発見可能なエージェントアイデンティティ」* で、*「プロトコルの居場所なし」* ではありません。

オープンな質問は、その分散パターンが正しいか、メジャメントが Signals と Governance と並ぶ *ピアプロトコル* に値するか — 自身のタスク表面（例: `register_measurement`、`attest_outcome`、`dispute_measurement`）と自身の仕様ページとともに。今日、測定エージェントコントラクトは暗黙で、BrandRef が消費される場所の union によって定義されます。

**現状（分散）のケース。** 測定ベンダーは既に OMID、MRC 認定、ベンダー SDK 経由で運用します。プロトコルの仕事はそれらをバイヤー/セラーフローから呼び出し可能にすることで、それをしています。専用プロトコルは既に機能するものを複製するリスクを負います。

**ピアプロトコルのケース。** 紛争解決、再カウント、（配信行のベンダーフィールドではなく）主要アーティファクトとしての署名付き測定証明は、共通プリミティブから利益を得るかもしれません。測定エージェントケイパビリティが *「値をレポート」* を超えて — 飛行中のシグナル生存レポート、予測測定可能性、独立ガバナンス監査へ — 拡大すると、分散パターンが緊張します。

この質問は抽象的な答えを必要としません。現在のパターンに合わない測定ベンダーケイパビリティが表面化するとすぐに解決します。

### 事前入札測定シグナルはどこに存在するか?

事前入札ビューアビリティスコア（インプレッションがビューアブルになる予測可能性）は、配信後ビューアビリティ測定を生成する同じベンダーによって販売されます。今日、予測は *シグナル*（決定前に消費）。測定は *検証*（配信後に消費）。同じベンダー、同じ方法論ファミリー、2 つのプロトコルの居場所。これは *消費パターン* が異なるから機能します — が、特に予測測定と配信後測定がリアルタイムビディングコンテキストで収束するにつれ、重複コストが層化利益を上回るか監視する価値があります。

### 会話コンテキストターゲティングはどこに合うか?

AI ネイティブチャネル（ChatGPT と類似のエージェンティック会話表面）は、会話トピックをシグナルとして広告をターゲットします — クッキーなし、フィンガープリンティングなし、オーディエンスグラフなし。同じアカウントが異なるチャット主題で異なるアドバタイザーを得ます。プロンプト自体がリアルタイムでターゲティングシグナルを運びます。

これは構造的に *シグナル* 層パターン（予測的、決定前）ですが、従来のコンテキストシグナル（ページ URL またはページコンテンツをターゲット）より細かい粒度です。従来のコンテキスト広告よりウォールドガーデンエンゲージメントシグナルターゲティング（Facebook News Feed）に近い — 在庫がフィード投稿ではなく会話テキストであることを除いて。

AdCP のシグナル分類は今日会話コンテキストターゲティングを直接モデル化しません。それが新しいシグナルタイプに値するか既存の `Contextual signals` カテゴリー内に合うかはオープンな質問です — 在庫形状（会話対ページベース）とシグナルライフサイクル（プロンプトごと対ページビューごと）は異なりますが、消費パターン（決定前ターゲティング入力）は同じです。

## このプロトコルがしないこと

AdCP はメジャメントモデルを実行しません。競合する検証ベンダー間を裁定しません。MRC カウント規約を定義しません。アトリビューション出力を保存または正規化しません。

AdCP がすることは、正しい *接続ポイント* を存在させること — セラーのメトリックがクエリ可能、検証者のパスが宣言可能で実行可能、バイヤーの結果データが添付する場所を持つ、ように。30 年かけて成長したメジャメント業界がそれらの接続ポイントの上に座ります。プロトコルはそれを置き換えません。