Agentic eXecution Engine (AXE)

AXE は非推奨です。トラステッドマッチプロトコル（TMP）が、構造的なプライバシー分離、マルチサーフェスのサポート（ウェブ、モバイル、CTV、AI アシスタント、リテールメディア）、標準化されたオファーモデルとともに AXE を置き換えます。新規の統合は TMP を使うべきです。既存の AXE 統合は引き続き機能します——axei/axex/axem のセグメントモデルは TMP のオファーとシグナルにマップされます。

Agentic eXecution Engine (AXE) は、インプレッション時に動的ターゲティング・ブランドセーフティ・頻度管理を行う AdCP の元来のリアルタイム実行レイヤーです。 AXE は、AdCP がインプレッション時の実行に到達する方法です。OpenRTB がプログラマティックな判断を可能にするのと同じ方法で——アドサーバーが配信するかどうかを決める前に、各インプレッションに対するリアルタイムの視点をバイヤーまたはオーケストレーターに与えることで——パブリッシャー横断のフリークエンシーキャップを可能にします。

2 フェーズのワークフロー

AXE は オフラインのセットアップ と リアルタイム配信 の 2 フェーズで動作します。

Phase 1: オフラインセットアップ

広告を配信する前に、キャンペーン設定とセグメントデータの同期を行います。 流れ:

Buyer Agent がターゲティング・予算付きキャンペーンを作成
Signal Agent がコンテキストデータ（オーディエンス、ブランドセーフティルール、天気トリガー等）を付与
Orchestrator がキャンペーンを AXE セグメントにマッピングしリアルタイムモジュールへ同期
Sales Agent が AXE セグメントのキー値に基づくラインアイテムを作成

Phase 2: リアルタイム配信

広告リクエストが届くと、AXE がリアルタイムで評価しセグメント判定を返します。 流れ:

ユーザーがページ訪問し広告リクエスト発火
アドサーバーが Prebid 等へリクエスト
Prebid が OpenRTB 入札リクエストを AXE に送信
AXE がユーザー/コンテキストを評価しセグメント値を返却
アドサーバーがセグメントに合うラインアイテムを選び配信

AXE セグメントタイプ

AXE はアドサーバーへ 3 種のセグメント値を返します:

Segment	Key	Purpose	Example
Include	`axei`	オーディエンス用（ユーザーが所属）	`"seg_auto_intenders"`
Exclude	`axex`	ブランドセーフティ/抑制用（このインプレッションをブロック）	`"unsafe_content"`
Macro	`axem`	クリエイティブのパーソナライズデータ	`"eyJjb250ZXh0IjoiLi4uIn0="`

セグメントがクリエイティブへ渡る流れ

{
  "packages": [{
    "product_id": "premium_video",
    "targeting_overlay": {
      "axe_include_segment": "seg_auto_intenders_q1",
      "axe_exclude_segment": "seg_existing_customers"
    }
  }]
}

インプレッション時:

axei を axe_include_segment と照合 → 一致していれば配信
axex を axe_exclude_segment と照合 → 一致していれば配信しません
axem を {AXEM} マクロ経由でクリエイティブに渡します

データフロー例

顧客獲得キャンペーンでの AXE 利用例:

セットアップ（オフライン）

1. Buyer がサプレッションリストをアップロード:

Advertiser CRM
  → Hash emails (SHA256)
  → Upload to orchestrator
  → Receive segment ID: "seg_existing_customers_acme"

2. AXE ターゲティング付きで media buy を作成:

{
  "packages": [{
    "product_id": "premium_video_millennials",
    "budget": { "amount": 50000 },
    "targeting_overlay": {
      "axe_exclude_segment": "seg_existing_customers_acme"
    }
  }]
}

3. Sales Agent がラインアイテムを作成:

Line item: "Acme Q1 Acquisition"
Targeting: axex != "seg_existing_customers_acme"

配信（リアルタイム）

4. ユーザーがパブリッシャーサイトを訪問:

GET /ad-request
User-Agent: Mozilla/5.0...
Cookie: uid=abc123

5. AXE ルックアップ:

Input: uid=abc123
Check: Is abc123 in seg_existing_customers_acme?
Result: YES (hashed email matches)

6. AXE レスポンス:

{
  "axei": null,
  "axex": "seg_existing_customers_acme",
  "axem": null
}

7. アドサーバーでの判定:

Line item requires: axex != "seg_existing_customers_acme"
Current axex: "seg_existing_customers_acme"
Decision: DO NOT SERVE (user is existing customer)

結果: 獲得予算が既存顧客に浪費されない。

コア機能

1. 動的オーディエンスターゲティング

手持ちの DMP/CDP セグメントをパブリッシャー在庫に適用:

オーディエンスデータをアップロード（ハッシュ済みメール、デバイス ID など）
オーケストレーターからセグメント ID を受領
axe_include_segment にセグメント ID を参照
インプレッション時に AXE がユーザーを照合

ユースケース: Lookalike、CRM 活用、行動セグメント

2. ブランドセーフティ

インプレッション時のリアルタイムコンテンツ評価:

コンテンツ分類 - ニュース/エンタメ/スポーツなど
センチメント分析 - ポジ/ネガの検知
キーワードブロック - ブランド固有の NG ワード回避
隣接ルール - ページ上の他広告との並び

ブランドセーフティのルールは Signal Agent からオーケストレーターを経て AXE に流れます。

3. パブリッシャー横断のフリークエンシー管理

パブリッシャー側の頻度制御と異なり、AXE は以下を横断管理します:

複数パブリッシャー
複数キャンペーン
複数デバイス（ID 解決を含む）

AXE が頻度キャップを適用し、アドサーバーにセグメント判定を返します。アドサーバーは「なぜ」ではなく「配信可否」のみを知ります。

パブリッシャー横断のフリークエンシーキャップの仕組み

パブリッシャー横断のフリークエンシーキャップは、現在はトラステッドマッチプロトコル（TMP）によって扱われます。TMP は構造的に分離されたコンテキストマッチとアイデンティティマッチの操作を使います。AXE のセグメントモデルは、TMP のオファーと適格性レスポンスにマップされます。

AXE モデルでは、すべての適格なインプレッションが、共有された露出状態に対してリアルタイムで確認されます: TMP では、この同じパターンが構造的なプライバシーとともに実現されます: アイデンティティマッチのパスがフリークエンシーキャップを扱い（バイヤーは、ユーザーがどのページにいるかを知らずに露出履歴を確認します）、コンテキストマッチのパスがコンテンツの関連性を扱います（バイヤーは、ユーザーが誰かを知らずにパッケージを評価します）。パブリッシャーは両方のレスポンスをローカルで結合します。

4. ファーストパーティデータ活用

PII を共有せずに顧客データを活用:

顧客 ID（メール/電話など）をハッシュ化
オーケストレーターへアップロード（データはオーケストレーターに留まる）
キャンペーンでセグメント ID を参照
AXE がインプレッション時に照合
パブリッシャーは生データに触れない

Privacy by Design: 不透明なセグメント ID

AXE の設計原則は セグメント ID を意図的に不透明にすること です。アドサーバーは ABCD が一致/不一致だったことだけを知り、そのセグメントが何を意味するかは分かりません。それは以下を意味し得ます:

ユーザーが頻度上限を超えた
ページがブランドセーフティ検査に失敗
ユーザーがファーストパーティサプレッションリストに含まれます
ユーザーがオーディエンスセグメントに一致

この不透明性がバイヤーデータを守ります。パブリッシャーやアドサーバーは次のような逆算ができません:

CRM リストに誰が含まれるか
頻度キャップの閾値
ブランドセーフティルールの内容
オーディエンスセグメントの定義

アドサーバーが知るのは「AXE が配信可と言った/不可と言った」だけです。

インテグレーションの要点

バイヤー向け

Step	Action	Result
1	オーディエンスをオーケストレーターにアップロード	セグメント ID を受領
2	`create_media_buy` にセグメント ID を含める	AXE ターゲティング付きでキャンペーン作成
3	配信レポートを監視	セグメントのマッチ率を追跡

パブリッシャー向け

パブリッシャーは AXE を直接実装しません。AXE ターゲティングをサポートするには:

Prebid 等の RTD と統合
キーバリューターゲティングを受け入れる - axei/axex をアドサーバーへ渡します
ラインアイテム設定 - AXE セグメントのキーバリューでターゲティング
対応表明 - adagents.json で AXE 対応を宣言

オーケストレーター向け

オーケストレーターは AXE レイヤーを運用します。

セグメントインジェスト - バイヤーからオーディエンスデータを受け入れる
リアルタイムルックアップ - 10ms 未満でセグメント所属判定
シグナル統合 - ブランドセーフティやコンテキストシグナルを適用
頻度状態の維持 - キャンペーン横断の露出管理
RTD モジュール - Prebid や OpenRTB でセグメントを公開

AXE がページに到達する仕組み

AXE はプロトコルレベルの概念です。オーケストレーターが AXE を実装し、それを広告配信環境に統合します。統合の経路は広告プラットフォームに依存します:

統合の経路	仕組み	例
Prebid RTD モジュール	オーケストレーターが、オークション中に AXE エンドポイントを呼ぶ Prebid モジュールを配布する	`exampleRtdProvider`
独自の広告プラットフォーム	AXE がプラットフォームのインフラ内でコンテナまたはセキュアエンクレーブとして実行される	プラットフォームネイティブな統合
サーバーサイド	判断の前に広告プラットフォームがサーバー間で AXE エンドポイントを呼ぶ	カスタムアドサーバー統合

共通する筋道: 統合の経路が何であれ、AXE はセグメントを評価し、広告プラットフォームがターゲティングに使う axei/axex/axem の判定を返します。パブリッシャー横断のフリークエンシーキャップでは、それらのインプレッション時の呼び出しこそが、一つのパブリッシャーのローカルなアドサーバーのカウンターに頼るのではなく、バイヤーがセラー横断で共有された露出ルールを適用できるようにするものです。

連鎖: オーケストレーター → AXE エンドポイント → セグメントターゲティング

Ad platform calls orchestrator's AXE endpoint
  → AXE evaluates segments and returns axei/axex/axem values
  → Values used for targeting decisions (key-values, container logic, etc.)
  → Matching campaigns serve

セラーの get_adcp_capabilities レスポンスにある axe_integrations の URL は、セラーがどのオーケストレーターの AXE エンドポイントに接続するかをバイヤーに伝えます:

{
  "media_buy": {
    "execution": {
      "axe_integrations": ["https://axe.example.com"]
    }
  }
}

Prebid 統合（ウェブ）

Prebid を使うウェブパブリッシャーでは、AXE はオーケストレーターの RTD モジュールを介して統合されます。Prebid のモジュール名は「AXE」ではなくオーケストレーターに一致します:

test=false

// Prebid build includes: rtdModule, exampleRtdProvider, ...other modules

pbjs.setConfig({
  realTimeData: {
    auctionDelay: 100,
    dataProviders: [{
      name: 'example',       // Orchestrator's module name
      waitForIt: true,
      params: {
        // Orchestrator-specific configuration
      }
    }]
  }
});

オーケストレーターの RTD モジュールは:

入札がリクエストされる前にオークションを傍受する
AXE エンドポイントに OpenRTB スタイルのリクエストを送る
セグメント判定（axei/axex/axem）を受け取る
アドサーバーのリクエストにターゲティングのキーバリューを設定する

パブリッシャーは AXE の内部を知る必要はありません——オーケストレーターのモジュールがすべてを扱います。

独自プラットフォームの統合

AXE は、独自の広告プラットフォーム内でコンテナまたはセキュアエンクレーブとして実行することもできます。このモデルでは:

オーケストレーターが AXE のロジックをプラットフォームのインフラにデプロイする
セグメント評価がプラットフォームの判断パイプライン内で行われる
インプレッション時に外部ネットワーク呼び出しが不要——レイテンシを削減する
プラットフォームが、ネイティブな広告選択プロセスの一部として AXE を呼ぶ

これは、Prebid を使わないプラットフォームや、外部の RTD 呼び出しが許すよりも厳しいレイテンシ要件を持つプラットフォームで特に関連します。

AXE サポートの見分け方

決定的な確認方法は、セラーの get_adcp_capabilities レスポンスです。Prebid ベースの統合では、ページを直接調べることもできます:

見るべきもの	場所	意味
ケイパビリティ内の `axe_integrations`	`get_adcp_capabilities` レスポンス	セラーが AXE をサポート
`axei`/`axex`/`axem` のキーバリュー	アドサーバーのリクエスト（ネットワークタブ）	AXE セグメントがアドサーバーへ流れている
Prebid ビルド内のオーケストレーター RTD モジュール（例: `exampleRtdProvider`）	ページソースまたは `pbjs.installedModules`	Prebid 経由の AXE
`realTimeData.dataProviders` 内のオーケストレーターのエントリ	`pbjs.getConfig('realTimeData')`	AXE がアクティブ

異なるオーケストレーターは異なる統合経路を通じて AXE を実装する場合があります——セグメントプロトコル（axei/axex/axem）は、AXE がどのようにデプロイされるかに関わらず同じです。

ユニバーサルマクロ:

クリエイティブは AXE のコンテキストデータを受け取り動的レンダリングが可能です。

<img src="https://cdn.brand.com/creative.png"
     data-context="{AXEM}" />

{AXEM} マクロには base64 エンコードのコンテキストメタデータが含まれます:

天候条件
コンテンツカテゴリ
ユーザーセグメント属性（匿名化）
カスタムオーケストレーターデータ

詳細はユニバーサルマクロを参照してください。

AXE を使うべき/避けるべきシナリオ

Scenario	Use AXE?	Alternative
CRM 内ユーザーをターゲティング	✅ Yes	—
既存顧客を除外	✅ Yes	—
パブリッシャー横断の頻度キャップ	✅ Yes	—
リアルタイムブランドセーフティ	✅ Yes	—
「カリフォルニア在住のミレニアル」	❌ No	ブリーフで表現
地理的制約	❌ No	`geo_country_any_of` を使用
パブリッシャーのオーディエンスセグメント	❌ No	ブリーフで表現
単一パブリッシャーの頻度キャップ	❌ No	パブリッシャーのアドサーバーで対応

性能

AXE は広告配信のレイテンシ要件に沿って設計されています。

Operation	Target Latency
セグメント所属判定	< 10ms
ブランドセーフティ評価	< 20ms
頻度チェック	< 5ms
AXE 判定全体	< 50ms

はじめに

AdCP で構築する

プロトコル

FAQ

トラストとセキュリティ

リファレンス

AAO

認定

2 フェーズのワークフロー

Phase 1: オフラインセットアップ

Phase 2: リアルタイム配信

AXE セグメントタイプ

セグメントがクリエイティブへ渡る流れ

データフロー例

セットアップ（オフライン）

配信（リアルタイム）

コア機能

1. 動的オーディエンスターゲティング

2. ブランドセーフティ

3. パブリッシャー横断のフリークエンシー管理

パブリッシャー横断のフリークエンシーキャップの仕組み

4. ファーストパーティデータ活用

Privacy by Design: 不透明なセグメント ID

インテグレーションの要点

バイヤー向け

パブリッシャー向け

オーケストレーター向け

AXE がページに到達する仕組み

連鎖: オーケストレーター → AXE エンドポイント → セグメントターゲティング

Prebid 統合（ウェブ）

独自プラットフォームの統合

AXE サポートの見分け方

ユニバーサルマクロ:

AXE を使うべき/避けるべきシナリオ

性能

関連ドキュメント

​2 フェーズのワークフロー

​Phase 1: オフラインセットアップ

​Phase 2: リアルタイム配信

​AXE セグメントタイプ

​セグメントがクリエイティブへ渡る流れ

​データフロー例

​セットアップ（オフライン）

​配信（リアルタイム）

​コア機能

​1. 動的オーディエンスターゲティング

​2. ブランドセーフティ

​3. パブリッシャー横断のフリークエンシー管理

​パブリッシャー横断のフリークエンシーキャップの仕組み

​4. ファーストパーティデータ活用

​Privacy by Design: 不透明なセグメント ID

​インテグレーションの要点

​バイヤー向け

​パブリッシャー向け

​オーケストレーター向け

​AXE がページに到達する仕組み

​連鎖: オーケストレーター → AXE エンドポイント → セグメントターゲティング

​Prebid 統合（ウェブ）

​独自プラットフォームの統合

​AXE サポートの見分け方

​ユニバーサルマクロ:

​AXE を使うべき/避けるべきシナリオ

​性能

​関連ドキュメント

2 フェーズのワークフロー

Phase 1: オフラインセットアップ

Phase 2: リアルタイム配信

AXE セグメントタイプ

セグメントがクリエイティブへ渡る流れ

データフロー例

セットアップ（オフライン）

配信（リアルタイム）

コア機能

1. 動的オーディエンスターゲティング

2. ブランドセーフティ

3. パブリッシャー横断のフリークエンシー管理

パブリッシャー横断のフリークエンシーキャップの仕組み

4. ファーストパーティデータ活用

Privacy by Design: 不透明なセグメント ID

インテグレーションの要点

バイヤー向け

パブリッシャー向け

オーケストレーター向け

AXE がページに到達する仕組み

連鎖: オーケストレーター → AXE エンドポイント → セグメントターゲティング

Prebid 統合（ウェブ）

独自プラットフォームの統合

AXE サポートの見分け方

ユニバーサルマクロ:

AXE を使うべき/避けるべきシナリオ

性能

関連ドキュメント