> ## 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.
# Trusted Match Protocol
> AdCP のリアルタイム実行層 — 無駄な予算から構造的プライバシーまで、あらゆるサーフェスにわたるクロスパブリッシャーのフリークエンシーキャッピングのストーリーをたどる。
**実験的。** TMP は実験的サーフェスとして AdCP 3.0 の一部です — 少なくとも 6 週間の予告をもって 3.x リリース間で変わることがあります。TMP を実装するセラーは `experimental_features` に `trusted_match.core` を宣言しなければなりません（MUST）。完全なコントラクトについては [実験的ステータス](/docs/reference/experimental-status) を参照。
Priya は CTV パブリッシャー StreamHaus の Ad Products ディレクターです。彼女は StreamHaus のインベントリがバイヤーエージェントにどう見えるか — プロダクトカタログ、クリエイティブ仕様、価格 — を設計しました。
Sam の Acme Outdoor キャンペーンは、フリークエンシーポリシー **週 5 インプレッション、露出間隔は最低 2 時間** で StreamHaus、OutdoorNet、PodTrail で実行されます。Sam がこれを選んだのは、間隔を空けた露出が集中した反復を上回るからです — コマーシャルの合間ごとに同じ広告は、エンゲージメントではなく疲労を生みます。
問題: 各パブリッシャーが独立してカウントします。
## Step 1: 問題 — 無駄な予算
StreamHaus、OutdoorNet、PodTrail はそれぞれ独立してカウントします。夕食後に StreamHaus でハイキングコンテンツを見て、30 分後にスマホで OutdoorNet を閲覧する視聴者は、Sam が設定した 2 時間の recency ウィンドウの十分内で、同じ広告を再び受け取ります。
1 週間で掛け合わせると、視聴者は間隔を空けてではなく集中して 5 ではなく 15 インプレッションを受け取ります:
| Publisher | Impressions counted | Actual viewer experience |
| ---------- | ------------------- | ------------------------ |
| StreamHaus | 5（上限内） | 毎セッション同じ広告 |
| OutdoorNet | 5（上限内） | 毎セッション同じ広告 |
| PodTrail | 5（上限内） | 毎セッション同じ広告 |
| **Total** | **15** | **Sam の上限の 3 倍** |
すべての冗長なインプレッションは、新しい誰かに届けられたはずの予算です。広告は間隔を空けることでよりよく機能します — 最初の数回の後の各露出は逓減する収益を生みます。Sam はリーチを買うべきときにフリークエンシーを買っています。
これは StreamHaus の問題ではありません。構造的な問題です。単一のパブリッシャーが全体像を見ないため、単一のパブリッシャーはクロスパブリッシャーの上限を強制できません。
## Step 2: TMP ルーターの追加
Priya は Trusted Match Protocol（TMP）ルーター — 彼女のアドサーバーとバイヤーエージェントの間に位置し、コンテキストとアイデンティティに構造的に分離されたパスを持つ部品 — をデプロイします。彼女は Sam のバイヤーエージェント（Pinnacle）を、他のバイヤーと並んで TMP プロバイダーとして設定します。
ルーターは StreamHaus のアドサーバーとバイヤーエージェントの間に位置します。ユーザーがページをロードすると、ルーターはリアルタイム評価を扱います。Priya はサーフェス固有のコードを書きませんでした — 同じルーターが StreamHaus のウェブサイト、モバイルアプリ、CTV アプリを扱います。
Priya は Sam のバイヤーエージェント（Pinnacle）をルーターに TMP プロバイダーとして登録します:
```json theme={null}
{
"providers": [
{
"name": "Pinnacle (Acme Outdoor)",
"endpoint": "https://pinnacle.acme.example/tmp",
"context_match": true,
"identity_match": true,
"properties": ["01J5A2B3C4-streamhaus-web", "01J5A2B3C5-streamhaus-ios"],
"latency_budget_ms": 50,
"priority": 1
}
]
}
```
`context_match: true` は、ルーターがターゲティングのためにコンテンツコンテキストを Pinnacle に送ることを意味します。`identity_match: true` は、Pinnacle がフリークエンシーキャップとオーディエンス適格性を強制できるよう、不透明なユーザートークンも送ることを意味します。`properties` はこのプロバイダーが提供する StreamHaus プロパティをスコープします — Pinnacle は CTV ではなく web と iOS を評価します。`latency_budget_ms` はプロバイダーごとのタイムアウトを設定します。Pinnacle が一貫してそれを超えると、ルーターはそれを非優先化します。
ルーターは設定されたすべてのプロバイダーに並列でファンアウトし、そのレスポンスをマージします。
## Step 3: Context Match — ページに何があるか？
視聴者がハイキングギアについての StreamHaus 記事を開きます。StreamHaus のプロパティは安定した `property_rid` 識別子で [プロパティガバナンス](/docs/governance/property) に登録されているため、バイヤーはこのリクエストがどのプロパティから来たかを正確に知ります。StreamHaus は記事のコンテンツシグナル、プレースメント、geo を伴う **Context Match** リクエストを送ります。
Sam のバイヤーエージェントは評価します: 「このハイキングコンテンツは `pkg-outdoor-display` に一致する。」それはクリエイティブマニフェスト — Trail Pro 3000 バナー — を含むオファーで応答します。
鍵となる制約: **ユーザーアイデンティティはこの境界を越えない。** バイヤーは人ではなくコンテンツを評価します。記事を読んでいるのが誰かは知りません — 記事が何についてかだけを知ります。
StreamHaus から Sam のバイヤーエージェントへのリクエスト:
```json theme={null}
{
"type": "context_match_request",
"request_id": "ctx-8f3a2b",
"property_rid": "01916f3a-9c4e-7000-8000-000000000010",
"property_type": "website",
"placement_id": "article-sidebar",
"seller_agent_url": "https://streamhaus.example",
"artifact_refs": [
{ "type": "url", "value": "https://streamhaus.example/articles/hiking-gear-2026" }
],
"context_signals": {
"topics": ["596"],
"taxonomy_source": "iab",
"taxonomy_id": 7,
"keywords": ["hiking gear", "outdoor equipment"]
}
}
```
パブリッシャーは `artifact_refs`（コンテンツを直接クロールするバイヤー向け）と `context_signals`（フォールバックとして事前分類されたトピックとキーワード）の両方を送ります。バイヤーエージェントはこのプレースメントにどのパッケージがアクティブかを既に知っています — `create_media_buy` 経由でそれらをセットアップしました。パッケージリストがワイヤー上を移動する必要はありません。
Sam のバイヤーエージェントからのレスポンス:
```json theme={null}
{
"type": "context_match_response",
"request_id": "ctx-8f3a2b",
"offers": [
{
"package_id": "pkg-outdoor-display"
}
]
}
```
## Step 4: Identity Match — このユーザーは適格か？
別途、StreamHaus は **Identity Match** リクエストを送ります: 不透明なユーザートークンと、あらゆるパブリッシャーにわたる Sam のアクティブなパッケージ ID すべて。
Sam のバイヤーエージェントはその露出履歴を確認します: 「このユーザーは 45 分前に OutdoorNet で 1 インプレッションを見た。2 時間の recency ウィンドウは経過していない。**適格でない。**」
鍵となる制約: **ページコンテキストはこの境界を越えない。** バイヤーはコンテンツ適合ではなく適格性を確認します。ユーザーが何を見ているかは知りません — このユーザーが今もっと広告を見るべきかどうかだけを知ります。
recency チェックは、Sam のバイヤーエージェントが共有された露出ストアを維持するため、パブリッシャー境界を越えます。StreamHaus、OutdoorNet、PodTrail はすべて同じバイヤーエージェントに Identity Match リクエストを送ります — そのためエージェントは 3 つすべてにわたるユーザーの総露出を知ります。
StreamHaus から Sam のバイヤーエージェントへのリクエスト:
```json theme={null}
{
"type": "identity_match_request",
"request_id": "id-7c9e1d",
"seller_agent_url": "https://streamhaus.example",
"identities": [
{ "user_token": "opaque-streamhaus-token-abc123", "uid_type": "uid2" },
{ "user_token": "ID5*zP3wK...", "uid_type": "id5" }
],
"package_ids": [
"pkg-outdoor-display",
"pkg-outdoor-ctv",
"pkg-outdoor-audio"
]
}
```
Sam のバイヤーエージェントからのレスポンス:
```json theme={null}
{
"type": "identity_match_response",
"request_id": "id-7c9e1d",
"eligible_package_ids": ["pkg-outdoor-audio"],
"serve_window_sec": 60
}
```
適格なパッケージのみがリストされます — `pkg-outdoor-audio` がバイヤーのチェックを通過します。`serve_window_sec: 60` はルーターにこの適格性を 60 秒キャッシュするよう伝えます。
例は `package_ids` を明示的に送っていますが、パブリッシャーはそれを省略してもよい（MAY） — Sam の identity-match サービスは `seller_agent_url` からアクティブなパッケージセットを解決します。`package_ids` が送られる *とき*、その構成は現在のページと独立でなければなりません（MUST） — all-active（StreamHaus のすべての Sam パッケージ）または fuzzed（Sam が黙って落とす合成 ID でパディングされたランダムサンプル）のいずれか。ページ固有のサブセットは禁止されています。それはバイヤーが Context Match と Identity Match をまたいでパッケージセットを相関させることを許し、構造的分離を壊します。
## Step 5: 結合 — StreamHaus が決定を下す
StreamHaus は両方のレスポンスをローカルで結合します:
* **Context Match** は言いました: 「このクリエイティブマニフェストで `pkg-outdoor-display` をアクティベートせよ。」
* **Identity Match** は言いました: 「適格でない — recency ウィンドウ。」
結果: **広告を抑制する。** 別の広告主のキャンペーンがスロットを埋めます。Sam の予算は、視聴者が最近広告を見ておらずインプレッションが実際に重要になる、よりよい瞬間のために保存されます。
バイヤーはユーザーアイデンティティとページコンテキストを一緒に見ることは決してありませんでした。プライバシーは違反されうるポリシーではありません — それは構造的です。2 つのパスは決してデータを共有せず、パブリッシャー（既に両方のシグナルを持つ）が最終決定を下します。
## Step 6: 3 人の勝者
**視聴者** は 3 つのプラットフォームにわたって普通の夜を過ごしました。彼らは StreamHaus のハイキングコンテンツ中に Trail Pro 広告を見ました — 関連性があり、タイミングがよい。30 分後に OutdoorNet を閲覧したとき、別の広告が現れました。インターネット中でつけ回される感覚はありません。
**Sam** は集中した反復ではなく間隔を空けた露出を得ました。彼の週 5 インプレッションは異なるコンテキストと瞬間にわたって着地し、それぞれが 6 回目や 7 回目のインプレッションよりも効果的です。そして抑制によって解放された予算は、まだ広告を見ていない視聴者に届きます — 同じ支出でより多くのユニークリーチ。
**Priya** は StreamHaus を差別化しました。バイヤーは、フリークエンシーポリシーが実際に機能するため TMP をサポートするパブリッシャーを好みます。StreamHaus のインベントリはインプレッションあたりより価値が高い。なぜならバイヤーは過剰露出された視聴者に予算を無駄にしていないことを知るからです。
| Before TMP | With TMP |
| ------------------- | -------------------------------- |
| 各パブリッシャーが独立してカウント | バイヤーエージェントがすべてのパブリッシャーにわたって露出を追跡 |
| 視聴者あたり週 15 インプレッション | 視聴者あたり週 5 インプレッション、適切に間隔を空けて |
| 予算がフリークエンシーを買う | 予算がリーチを買う |
| 集中した反復、広告疲労 | 間隔を空けた露出、インプレッションあたりより高い効果 |
| パブリッシャーはボリュームで競争 | パブリッシャーは品質とバイヤー体験で競争 |
## Step 7: 同じプロトコル、あらゆるサーフェス
同じ TMP ルーターが StreamHaus のウェブサイト、モバイルアプリ、CTV アプリ、AI アシスタントを扱います。Sam のバイヤーエージェントは、サーフェス固有のロジックなしにそれらすべてにわたって機能します。プロトコルがサーフェスの違いを扱います。Priya と Sam はビジネスを扱います。
## さらに深く
AI アシスタントのための仲介プロトコル — コンテキストがブロードキャストできないとき、需要がどう会話型 AI を見つけるか。
既存のプロトコルがなぜ配信時に失敗し、TMP がなぜオークションアプローチではなくマッチングアプローチを取るか。
カタログ絞り込みとパブリッシャー側の結合を含む、具体例を伴う両操作。
権威あるメッセージタイプ、フィールド表、適合性要件。
構造的分離、時間的相関除去、TEE アテステーション。
各 TMP 参加者のコントローラー対プロセッサー分析。
デプロイ、ファンアウト、プロバイダー設定。
### サーフェスガイド