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

# 実行ギャップ

> 既存のプロトコルがなぜリアルタイム実行に失敗し、TMP がなぜオークションアプローチではなくマッチングアプローチを取るか。

# 実行ギャップ

バイヤーエージェントは `get_products` を通じてインベントリを発見し、`create_media_buy` を通じてディールを交渉し、後に `get_media_buy_delivery` を通じて配信を測定します。ディールは存在します。パッケージは合意された価格、ターゲティング、予算で定義されます。

そしてユーザーがページを訪れます。またはアプリを開きます。または AI アシスタントに質問します。

何が起こるでしょうか？

## 今日何が起こるか

答えは完全にサーフェスに依存します — そして各サーフェスで、それは場当たり的です。

### Web（アドサーバー付き）

パブリッシャーの広告運用チームは、各 AdCP パッケージに対応するラインアイテムまたは PMP ディールを、アドサーバー（GAM、Kevel、FreeWheel）で手動で作成します。ページがロードされると、アドサーバーは独自のターゲティングルールを評価してどのラインアイテムが適格かを決めます。パブリッシャーが Prebid Server を使う場合、ベンダー固有の RTD（Real-Time Data）モジュールがオークションにシグナルを注入できます — しかし各モジュールは独自の API を話し、完全な OpenRTB BidRequest（約 2-10KB の JSON）を送り、AdCP ディール構造と独立して動作します。

結果: AdCP を通じて交渉されたパッケージは、別個の手動プロセスを通じてアクティベートされます。ディールと実行が切り離されています。

### AI アシスタント

標準メカニズムはありません。会話を収益化したい AI プラットフォーム（ChatGPT、Snap AI、Reddit chat、character.ai）は、バイヤーエージェントに「あなたのパッケージのどれがこの会話に一致するか？」を尋ねるプロトコルを持ちません。各プラットフォームは独自の広告配信ロジック、独自のバイヤー統合、独自のターゲティングシステムを構築するか — 単一のアドネットワークと提携して問題全体を委譲します。

### モバイルアプリ

メディエーション SDK（AppLovin MAX、ironSource、Google AdMob）が決定を扱います: このユーザーとプレースメントにどのネットワークディールが提供すべきか？ しかしメディエーションは独自のディールレジストリで動作し、AdCP パッケージから切り離されています。アプリ開発者はメディエーションダッシュボード内でウォーターフォール優先度やオークションルールを設定します。「AdCP パッケージが存在する」から「メディエーション層がそれをアクティベートする」へのプロトコルパスはありません。

### CTV

ポッドサーバーは複数のディールから広告ブレイクを構成します。各ディールは、ターゲティングルール、競合分離制約、クリエイティブローテーションロジックとともに放送局のアドサーバーで設定されます。ポッド構成は複雑でサーフェス固有の問題です。バイヤーエージェントが「このポッドに私のパッケージをアクティベートし、15 秒カットダウンを優先せよ」と言う標準的な方法はありません。

### リテールメディア

リテーラーは内部のレコメンデーションエンジンを通じてスポンサープロダクトプレースメントを管理します。買い物客が検索したりカテゴリーを閲覧したりすると、リテーラーのアルゴリズムがどのスポンサープロダクトを表示するかを決めます。バイヤーエージェントは、初期のディール条件を超えてこの決定へのリアルタイム入力を持ちません。「この検索コンテキストにこれらの GTIN を優先しこれらのプロモーションを除外せよ」と言うプロトコルはありません。

## なぜ OpenRTB はこれに誤っているか

OpenRTB は特定のシナリオのために設計されました: アドエクスチェンジが、既存の関係を持たない入札者の間でオークションを実行する。それはコールドスタート問題を解決します — 見知らぬ者同士がどうやってリアルタイムで広告インベントリを取引するか？

しかしパッケージが AdCP を通じて事前交渉されているとき、当事者は見知らぬ者ではありません。彼らはディールを持っています。実行時の問いは「誰が最も高く入札するか？」ではなく「合意されたパッケージのどれがこのコンテキストにアクティベートすべきか？」です。

OpenRTB はこれに 3 つの具体的な点で誤っています:

**ユーザーアイデンティティをページコンテキストとバンドルする。** すべての OpenRTB 入札リクエストは、ユーザー ID、デバイスフィンガープリント、IP アドレス、ページ URL を単一のオブジェクトで送ります。これは構造的なプライバシー失敗です。バイヤーはこのデータを使ってクロスサイトの閲覧プロファイルを構築でき — そして実際にします。いかなる同意管理もアーキテクチャを修正しません。データは設計上一緒に移動します。

**オークションセマンティクスを強制する。** OpenRTB はすべてのインプレッションが競争的オークションだと仮定します。しかし事前交渉されたディールは競争的ではありません — 価格は既に合意されています。ディールをオークション機構に強制することは、オープンな競争のために設計されたプロトコルの上に PMP ロジック、ディール ID マッチング、フロア価格強制を構築することを意味します。尻尾が犬を振ります。

**ヘビー級である。** 典型的な OpenRTB 入札リクエストは 2-10KB の JSON で、完全なデバイスオブジェクト、ユーザーオブジェクト、site/app オブジェクト、インプレッション配列を運びます。実行が「どのパッケージがこのページコンテキストに一致するか？」だけを知る必要があるとき、そのペイロードのほとんどは無駄な帯域と無駄なパース時間です。

| What execution needs | What OpenRTB sends                         |
| -------------------- | ------------------------------------------ |
| ページコンテンツシグナル         | 完全な site オブジェクト + referrer チェーン + キーワードリスト |
| 利用可能なパッケージ           | なし — バイヤーはディール ID から推論しなければならない            |
| コンテンツ分類              | 部分的 — バイヤーはしばしば独立して再分類する                   |
| ユーザー適格性              | 生のユーザー ID、デバイス ID、IP アドレス、GPS              |
| 結果: パッケージアクティベーション   | 結果: 価格、クリエイティブ URL、トラッキングピクセルを伴う入札         |

## なぜオークションは解決戦略であってプロトコルでないか

関連する本能は、新しいオークションプロトコル — より速く、より軽く、よりプライバシー認識 — を構築し、リアルタイム実行にそれを使うことです。CloudX の OpenAuction はこのアプローチを取ります: 暗号化された入札とアテステーション証明を伴い TEE（Trusted Execution Environment）で実行されるオープンソースのオークションロジック。よく設計されています。

しかしオークションは、ほとんどのリアルタイム広告決定にとって誤ったプリミティブです:

**競争ではなくフィルタリング。** 「私の事前購入したパッケージのどれがこのコンテキストに適用されるか？」はフィルタリング操作です。バイヤーは利用可能なパッケージを自身のキャンペーンターゲティングと予算に対して評価します。敵対的な競争はありません — バイヤーは自身のディールから選択しています。

**入札ではなくステアリング。** 「このパッケージ内で、どのカタログアイテムやクリエイティブバリアントを優先すべきか？」はステアリング操作です。バイヤーは合意されたディールの範囲内で好みを表現します。計算する価格はありません。

**ランキングではなく適格性。** 「このユーザーはこのパッケージについてフリークエンシーキャップされているか、高い意図を持つか？」は適格性チェックです。バイヤーはユーザーのステータスをルックアップします。ランク付けする入札はありません。

オークションは、複数のバイヤーからの複数のパッケージが同じプレースメントを競うときの 1 つの有効な解決戦略です。しかしオークションをプロトコルにすることは、すべてのサーフェス — 関連性でスポンサーコンテンツを選択する AI アシスタント、プロダクト適合でカルーセルを埋めるリテーラー、編集判断でポッドを構成する CTV 放送局を含む — を入札パラダイムに強制します。

TMP は異なるアプローチを取ります: 一致するパッケージを返し、パブリッシャーにそれらをどう解決するかを決めさせます。パブリッシャーがオークションを望むなら、実行できます — 検証可能な公平性のために CloudX の TEE インフラを使う可能性もあります。しかしオークションはマッチングの代わりにではなく、マッチングの上に位置します。

## プロトコルレベルのソリューションはどう見えるか

実行ギャップは、次のプロトコルを要求します:

1. **事前交渉されたパッケージで機能する。** 市場は計画時に既に起こりました。リアルタイム層はディールをアクティベートし、交渉しません。

2. **コンテキストをアイデンティティから分離する。** バイヤーはどのパッケージが一致するかを決めるためにコンテンツシグナルを必要とします。バイヤーは適格性を評価するためにユーザーシグナルを必要とします。これら 2 つのニーズは、バイヤーがそれらを相関させられないよう、2 つの独立した操作によって提供されなければなりません。

3. **カタログとクリエイティブの絞り込みをサポートする。** パッケージのアクティベートは常にバイナリの on/off ではありません。バイヤーは、どのカタログアイテムを特集するか、どのクリエイティブバリアントを提供するか、どのプロモーションがアクティブかを指定する必要があるかもしれません。

4. **サーフェスをまたいで機能する。** 同じプロトコルが、アドサーバーを持つウェブページ、アドサーバーのない AI アシスタント、メディエーション層を持つモバイルアプリ、レコメンデーションエンジンを持つリテーラー、ポッドサーバーを持つ放送局で機能しなければなりません。

5. **リアルタイムのレイテンシー要件を満たす。** エンドツーエンドで 50ms 未満。なぜなら実行はすべてのページロード、すべての会話ターン、すべてのアプリ画面で起こるからです。

これが TMP が提供するものです: 2 つの軽量な操作 — [Context Match と Identity Match](/docs/trusted-match/context-and-identity) — が、構造的プライバシー保証と 50ms 未満のレイテンシーで、あらゆるサーフェスにわたって事前交渉されたパッケージをアクティベートします。