> ## 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.
# 需要はどう AI アシスタントに到達するか
> AI アシスタントのための仲介プロトコル — コンテキストをすべてのバイヤーにブロードキャストできないとき、需要がどう会話型 AI を見つけるか。
StreamHaus は 6 か月前に AI アシスタントをローンチしました。ユーザーはハイキングトレイル、ギアのおすすめ、旅行計画について尋ねます — 広告主がその一部になるためにプレミアムを支払う類の高い意図の会話です。Priya は利用数が上昇し広告収益がゼロのままなのを見ています。
アシスタントはブラックボックスです。アドサーバーがありません。インプレッションがありません。ユーザーが「岩場の地形にどんなトレイルシューズを買うべき？」と尋ねるとき、ブロードキャストする入札リクエストがありません — そしてあったとしても、生の会話コンテキストをエクスチェンジ上のすべてのバイヤーに送ることは、ユーザーコンテンツを大規模に漏らします。
これはすべての AI プラットフォームが直面する需要問題です: バイヤーが参加する標準的な方法のない高い意図の会話。
## 中核となる設計原則
TMP は関心の分離でこれを解決します: プロトコルはどのスポンサーコンテンツが利用可能で関連性があるか **what** を決め、プラットフォームの LLM はそれをどう提示するか **how** を決めます。バイヤーはユーザー体験に決して触れません。プラットフォームはカスタム広告ロジックを決して構築しません。
これが TMP を広告注入システムではなく仲介プロトコルにするものです。複数のバイヤーエージェントが標準インターフェースを通じてオファーを提出し、プラットフォームはおすすめがどう — そしてそもそも — 現れるかについての編集制御を保持します。
## Step 1: 需要問題
AI アシスタント以前のすべての広告サーフェスは同じように機能します: ユーザーがページをロードし、入札リクエストがコンテキストをバイヤーにブロードキャストし、アドサーバーが定義されたスロットにクリエイティブをレンダリングします。AI アシスタントは 3 つの前提すべてを壊します:
* **定義されたスロットなし** — スポンサーコンテンツはレスポンステキストに織り込まれる
* **入札リクエストなし** — 会話はプライベートで一時的、クロール可能な URL ではない
* **アドサーバーなし** — プラットフォームの LLM がレスポンスを生成する
これに標準はありません。仲介層なし、プロトコルなし、複数のバイヤーが会話で関連性を競う方法なし。今日のほとんどの AI プラットフォームは単一のアドネットワークと提携するか、独自のスポンサーシップロジックを構築するか、収益化を完全にスキップします。
Priya は 1 つのアドネットワークを選びたくありません。彼女は Pinnacle Agency の Sam と、関連するパッケージを持つ他のすべてのバイヤーエージェントに、標準プロトコルを通じて関連性を競わせたいのです。TMP はコンテキスト評価をユーザー識別から分離することでこれに対処します。
## Step 2: 需要をコンテキストにもたらす
web では、コンテキストは外向きに放射します — URL は公開、ページコンテンツはクロール可能、バイヤーはそれを並列で評価します。AI アシスタントはそれができません。会話はプライベートで一時的、オープンに共有できないユーザーコンテンツを含みます。
TMP のアーキテクチャはこの制約のために構築されました。コンテキストを外向きにブロードキャストする代わりに、ルーターはバイヤーエージェントを内向きにもたらします — 彼らは会話自体ではなく、会話についての分類されたシグナルを見ます。Priya は web と CTV を扱うのと同じ TMP ルーターに、アシスタントを新しいプロパティとして登録します:
* **プロパティタイプ**: `ai_assistant`
* **プレースメント**: `chat-inline-recommendation` — LLM がスポンサーおすすめを組み込める会話コンテキスト
ルーターは登録されたすべてのバイヤーエージェントに並列で Context Match リクエストをファンアウトします。Sam のエージェントは他のバイヤーと並んで競います — これは単一パートナーディールではなく仲介です。
## Step 3: 入札リクエストの代わりに分類されたシグナル
ユーザーが尋ねます: 「岩場の地形にどんなトレイルシューズを買うべき？ 良い足首サポートが必要。」
LLM がレスポンスを生成する前に、StreamHaus は **Context Match** リクエストを送ります。会話ターンは URL ではありません — 一時的で、ユーザーコンテンツを含み、バイヤーに送れません。代わりに、プラットフォームは **分類されたシグナル** を送ります: IAB トピックコード、センチメント、キーワード、自然言語 summary。バイヤーはユーザーの実際の言葉を見ずに関連性を評価します。
```json theme={null}
{
"type": "context_match_request",
"request_id": "ctx-trail-shoes-01",
"property_rid": "01916f3a-f8cb-7000-8000-000000000051",
"property_type": "ai_assistant",
"placement_id": "chat-inline-recommendation",
"seller_agent_url": "https://streamhaus.example",
"context_signals": {
"topics": ["596", "477"],
"taxonomy_source": "iab",
"taxonomy_id": 7,
"sentiment": "positive",
"keywords": ["trail shoes", "rocky terrain", "ankle support"],
"language": "en",
"summary": "User seeking trail shoe recommendations for rocky terrain with ankle support"
}
}
```
`artifact_refs` なし — 会話ターンは一時的です。`context_signals` は分類された出力を運びます。`summary` フィールドは、関連性をセマンティックに評価する LLM ネイティブなバイヤーに特に有用です。信頼された実行環境で動作するプラットフォームは、代わりに完全な会話を `artifact` として送れます — パブリッシャーが開示レベルを制御します。
Sam のバイヤーエージェントは評価します: 「岩場の地形のトレイルシューズ — これは Acme Outdoor の Trail Pro 3000 キャンペーンに一致する。」それは **テキストと構造化データ** — LLM が自然なおすすめを生成するのに必要な生の素材 — を含むオファーで応答します。
すべての統合が完全なクリエイティブマニフェストを必要とするわけではありません。TMP はスペクトラムをサポートします:
| Integration level | What the offer contains | How the platform uses it |
| ----------------- | -------------------------------------------------------- | ------------------------------------------------------------ |
| アクティベーションのみ | `package_id` | プラットフォームのアドサーバーがラインアイテムをアクティベート（AI と並んで従来の広告配信を持つプラットフォーム向け） |
| ブランドメンション | `package_id` + `brand` + `summary` | LLM が summary を使って自然なブランドメンションを生成 |
| 完全なおすすめ | `package_id` + `brand` + `summary` + `creative_manifest` | LLM がマニフェストからのプロダクト詳細をレスポンスに織り込む |
| カタログステアリング | カタログアイテムを伴う `package_id` + `brand` + `creative_manifest` | LLM が同期されたカタログから特定のプロダクトをおすすめ |
Priya は StreamHaus のアシスタントに完全なおすすめを選びました:
```json theme={null}
{
"type": "context_match_response",
"request_id": "ctx-trail-shoes-01",
"offers": [
{
"package_id": "pkg-outdoor-display",
"brand": { "domain": "acmeoutdoor.example" },
"summary": "Trail Pro 3000 — ankle-height trail runner with rock plate, relevant to user's terrain needs",
"creative_manifest": {
"format_id": { "agent_url": "https://streamhaus.example", "id": "sponsored_recommendation" },
"assets": {
"headline": { "content": "Built for rocky trails" },
"body": { "content": "The Trail Pro 3000 has a full rock plate and ankle-height collar for technical terrain. Vibram outsole with 4mm lugs." }
}
}
}
]
}
```
`summary` は、プラットフォームがオファーを組み込むかを決める前に関連性を判断するのを助けます。`body` は、LLM が自然なレスポンスに織り込める事実に基づくプロダクト詳細を与えます。
## Step 4: フリークエンシーキャップはすべてのサーフェスを越える
StreamHaus はセッショントークンを伴う Identity Match リクエストを送ります。バイヤーは、web と CTV をカバーする同じ共有された露出ストアに対して、フリークエンシーキャップ、オーディエンス適格性、recency を確認します。
AI アシスタントユーザーはしばしば認証されています — プラットフォームにログイン済み — つまりアイデンティティシグナルは通常 web より弱くなく強いです。このユーザーが 30 分前に StreamHaus の CTV アプリで Trail Pro 3000 広告を見た場合、2 時間の recency ウィンドウはここにも適用されます。AI アシスタントは、異なるサーフェスだからといってフリークエンシーキャップのフリーパスを得ません。
## Step 5: プラットフォームが体験を制御する
StreamHaus は Context Match と Identity Match のレスポンスを結合します。Trail Pro 3000 オファーは適格です。オファーのクリエイティブマニフェストが LLM の生成コンテキストの一部になります:
> 「良い足首サポートのある岩場の地形には、rock plate とより高いカラーのあるシューズが欲しいでしょう。**Trail Pro 3000** はまさにこのために設計されています — 鋭い岩から守る full rock plate と、テクニカルな地形での安定性のための足首の高さのカラーがあります。4mm ラグの Vibram アウトソールが緩い地面で確実なグリップを与えます。
>
> こちらも見てみるとよいかもしれません…」
>
> *Acme Outdoor からのスポンサーおすすめ*
LLM はクリエイティブマニフェストを逐語的にコピーしませんでした。プロダクト詳細を、ユーザーの特定の質問に対応する自然なおすすめに織り込みました。プラットフォームは独自の編集ポリシー — スポンサーコンテンツラベル、自然な統合、非スポンサー代替との継続 — を適用しました。AI 生成スポンサーコンテンツをめぐる規制要件（FTC 開示、EU AI Act）はプラットフォームの責任で、プロトコルではなく LLM 統合を通じて強制されます。
## Step 6: これが解き放つもの
**ユーザー** は質問し有用な答えを得ました。Trail Pro 3000 のおすすめは関連性がありました — 彼らは岩場の地形と足首サポートについて尋ね、それがプロダクトが作られた目的です。スポンサーラベルは透明です。レスポンスは非スポンサーオプションで続きました。
**Sam** は、何を買うか尋ねた瞬間にユーザーに届きました — 意図は直接の質問より具体的にはなりません。web と CTV で実行される同じパッケージが AI アシスタントでアクティベートされました。クリエイティブマニフェストはバナーの代わりにテキストを運びましたが、Sam のバイヤーエージェントはサーフェス固有のロジックを必要としませんでした。
**Priya** は、独自のスポンサーシップロジックなしに、単一のアドネットワークにロックインせずに、ユーザー体験を妥協せずに AI アシスタントを収益化しました。TMP を話すすべてのバイヤーエージェントが参加できます。ルーターがファンアウトを扱います。StreamHaus が編集統合を制御します。web と CTV からのフリークエンシーキャップが引き継がれます。そして配信レポートは他のすべてのサーフェスと同じ測定インフラを通じて流れます。
| Without TMP | With TMP |
| ------------------------ | --------------------- |
| 単一のアドネットワークまたは収益化なし | 任意のバイヤーエージェントが関連性を競える |
| 広告主ごとの独自統合 | 標準プロトコル、オープンな需要 |
| サーフェスをまたいだフリークエンシーキャップなし | 共有された露出ストア、どこでも同じキャップ |
| プラットフォームが広告ロジックを構築 | プラットフォームは編集統合のみを制御 |
| アドネットワークが体験を制御 | プラットフォーム LLM が提示を制御 |
## マルチターン会話
各ユーザーメッセージは新しい Context Match 評価をトリガーします。プラットフォームはいつ再評価するかを決めます — 推奨トリガーはトピックシフト（プラットフォームの分類器が検出）、明示的なプロダクト関心（「もっと教えて…」）、またはセッションタイムアウト（5 分以上の非アクティブ）です。
プラットフォームは最新の Context Match レスポンスをキャッシュし、同じトピックのフォローアップ質問の再評価をスキップしてもかまいません。これは広告品質に影響せずにレイテンシーとプロバイダー負荷を減らします。
複数のバイヤーが同じ会話ターンのオファーを返すとき、プラットフォームは価格ではなく会話への関連性でランク付けします。これはオークションではなく仲介です。
インプレッションは、LLM がクリエイティブマニフェストをそのレスポンスに組み込むときに起こります。おすすめされたプロダクトについてのフォローアップ質問（「どこで買える？」）は新しいインプレッションではなくエンゲージメントイベントです。
**レイテンシー。** TMP の 50ms 未満の往復は LLM の生成時間（通常 1-3 秒）内に隠れます。プラットフォームは LLM プロンプトを準備しながら Context Match リクエストを送るため、TMP はユーザー体験に知覚可能な遅延を追加しません。
## さらに深く
AI アシスタント統合の技術リファレンス — リクエスト/レスポンス形式、コンテキストシグナル、アクティベーションパターン。
2 操作モデルがすべてのサーフェスにわたってどう機能するか、具体例付き。
クロスパブリッシャーフリークエンシーキャッピングのウォークスルー — TMP がどう実行ギャップを解決するか。
権威あるメッセージタイプ、フィールド表、適合性要件。