> ## 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. # AXE から TMP への移行 > AXE セグメントターゲティングから TMP のオファーと適格性モデルへの移行方法 — 概念マッピング、並行運用、切り替え。 # AXE から TMP への移行 AXE と TMP は同じ問題 — 事前交渉されたパッケージのインプレッション時実行 — を異なるアーキテクチャで解決します。AXE は完全なリクエスト（ユーザー + コンテキスト + デバイス）を送り、不透明なセグメント ID を返します。TMP はリクエストを 2 つの構造的に分離された操作に分割し、オファーと適格性を返します。 このページは AXE の概念を TMP の同等物にマップし、移行中に両方を並行して実行する方法を記述します。 ## 概念マッピング | AXE | TMP | Notes | | ------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------------------------------- | | `axei`（include segment） | Context Match オファー | パッケージがコンテンツに一致 | | `axex`（exclude segment） | `eligible_package_ids` からパッケージが欠如 | ユーザーが抑制リスト、オーディエンスルール、バイヤー側フリークエンシーチェックに失敗 | | `axem`（macro data） | クリエイティブマニフェスト + オファー `macros` + `{TMPX}` | 構造化アセットはクリエイティブマニフェストに移動。動的キー値はオファー `macros` を通過。ユーザーごとの露出トラッキングは Identity Match の `{TMPX}` マクロを使う | | オーケストレーター AXE エンドポイント | TMP ルーター | 2 つの分離されたコードパスを持つ単一のバイナリ | | Prebid Real-Time Data（RTD）モジュール | TMP Prebid モジュール | ベンダー固有の RTD モジュールを単一のモジュールに置き換え | | `axe_integrations` URL | `trusted_match` ケイパビリティ | `get_adcp_capabilities` レスポンス内 | | OpenRTB スタイルのリクエスト | Context Match + Identity Match | 1 つのバンドルされたリクエストの代わりに 2 つのリクエスト | | アドサーバーのセグメントキー値 | オファーからのターゲティングキー値 | 同じ GAM 統合、異なるソース | ## 各ロールで何が変わるか ### バイヤーエージェント **Before（AXE）:** オーディエンスセグメントをオーケストレーターにアップロード。メディアバイの `axe_include_segment` / `axe_exclude_segment` でセグメント ID を参照。 **After（TMP）:** Context Match と Identity Match エンドポイントを公開。コンテンツシグナル（Context Match）とユーザー適格性（Identity Match）に対してパッケージをリアルタイムで評価。クリエイティブマニフェストと適格性決定を伴うオファーを返す。 **鍵となる違い:** あなたのエージェントは、セグメントメンバーシップを事前計算する代わりにリアルタイムの決定を下します。ターゲティングロジックの完全な制御を持ちます — 仲介オーケストレーターなし。 ### パブリッシャー **Before（AXE）:** オーケストレーターの Prebid RTD モジュールを有効化。`axei`/`axex`/`axem` キー値を受け入れ。それらのキー値をターゲットにする GAM ラインアイテムを作成。 **After（TMP）:** TMP ルーターをデプロイ（または TMP Prebid モジュールを使用）。ルーターからオファーと適格性を受け入れ。オファーシグナルから GAM ターゲティングキー値を設定し、動的クリエイティブレンダリングのためオファー `macros` を通過。GAM ラインアイテムは `axei`/`axex` の代わりに `adcp_pkg` をターゲット。 **鍵となる違い:** ルーターがオーケストレーターの RTD モジュールを置き換えます。GAM ラインアイテムは不透明なセグメント ID の代わりにパッケージ ID を参照します。 ### オーケストレーター **Before（AXE）:** AXE エンドポイントを運用、セグメント状態を管理、Prebid RTD モジュールを配布。 **After（TMP）:** オーケストレーターは、パブリッシャーに代わって TMP ルーターを運用するか、バイヤー側のロール（バイヤーエージェント TMP エンドポイントを運用）に移行できます。仲介者としてのオーケストレーターのロールは TMP では任意です — バイヤーとパブリッシャーはルーターを通じて直接接続できます。 ## 並行運用 移行中、パブリッシャーは AXE と TMP を同時に実行できます: 1. Prebid で新しい TMP モジュールと並んで **既存の AXE RTD モジュールを保持** 2. **新しいメディアバイ** は TMP を使う（`axe_include_segment` / `axe_exclude_segment` なし） 3. **既存のメディアバイ** は期限切れになるまで AXE セグメントを使い続ける 4. **両方の GAM ラインアイテム**: AXE ラインアイテムは `axei`/`axex` をターゲット、TMP ラインアイテムは `adcp_pkg` をターゲット TMP は [`{TMPX}` マクロ](/docs/trusted-match/specification#tmpx-exposure-tokens) 経由でリアルタイムのユーザーごとの露出トラッキングを提供します。並行運用中、AXE と TMP のインプレッションの両方がバイヤーの露出ストアに供給されます — AXE はオーケストレーターのレポート経由、TMP は暗号化 TMPX トークンを受け取るバイヤーのインプレッションピクセル経由。バイヤーの露出ストアがソースにかかわらずユーザートークンとパッケージ ID で重複排除するため、二重カウントのリスクはありません。 ### 切り替え すべてのアクティブなメディアバイが TMP を使うとき: 1. Prebid からオーケストレーターの RTD モジュールを削除 2. AXE ターゲットの GAM ラインアイテムを削除 3. `axe_integrations` を削除し `trusted_match` を保持するよう `get_adcp_capabilities` を更新 ## ターゲティングオーバーレイの移行 `create_media_buy` の AXE ターゲティングフィールドは TMP の動作にマップします: | AXE field | TMP equivalent | | --------------------- | -------------------------------------- | | `axe_include_segment` | Context Match — バイヤーがターゲティングをリアルタイムで評価 | | `axe_exclude_segment` | Identity Match — バイヤーが抑制とオーディエンスルールを確認 | 新しいメディアバイは AXE フィールドを完全に省略すべきです。バイヤーエージェントの Context Match と Identity Match ロジックが、オーケストレーターのセグメント評価を置き換えます。 ## 変わらないもの * **`create_media_buy`** — 同じタスク、同じスキーマ（AXE フィールドを除く） * **`get_media_buy_delivery`** — 同じ配信レポート * **`sync_creatives`** — 同じクリエイティブ同期 * **アドサーバーとしての GAM** — TMP は依然として GAM が評価するキー値を設定 * **地理的およびその他のターゲティングオーバーレイ** — これらはメディアバイフィールドであり、実行層の関心事ではない ## OpenRTB User.eids クロスウォーク OpenRTB 形状のパイプラインから橋渡しするバイヤーのために、TMP Identity Match `identities[]` 形状は OpenRTB 2.6 `User.eids[]` に次のようにマップします: | AdCP TMP `identities[].uid_type` | OpenRTB 2.6 `User.eids[].source` | Notes | | -------------------------------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | `rampid` / `rampid_derived` | `liveramp.com` | `atype: 3`（人ベース、[IAB AdCOM Agent Types](https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md#list_agenttypes) 準拠） | | `id5` | `id5-sync.com` | `atype: 3` | | `uid2` | `uidapi.com` | `atype: 3` | | `euid` | `euid.eu` | `atype: 3` | | `pairid` | `iabtechlab.com/pair` | `atype: 3` | | `maid` | `adid`（Android） / `idfa`（iOS） | OpenRTB では `User.eids` ではなく `Device.ifa` に非典型的に運ばれる | | `hashed_email` | `liveintent.com` またはバイヤー固有 | `atype: 3` | | `publisher_first_party` | パブリッシャー定義の `source` URL | コンテキスト依存。橋渡し実装はトークンが人ベースの識別子を表すときのみ `atype` を省略するか `atype: 3` にデフォルトしてよい | | `other` | バイヤー定義の `source` URL | コンテキスト依存。橋渡し実装はトークンが人ベースの識別子を表すときのみ `atype` を省略するか `atype: 3` にデフォルトしてよい | TMP `user_token` フィールドは `User.eids[].uids[].id` に対応します。OpenRTB の `User.eids[].uids[].atype` は AdCP のより高忠実度の `uid_type` から導出されます。別個の AdCP フィールドではありません。橋渡しコードは上の表から `atype` を計算すべきで、`uid_type` と食い違いうる独立したユーザー提供の `atype` 値を追加すべきではありません。 AdCP は Identity Match リクエストごとに最大 3 つのアイデンティティを運びます（HPKE サイズ予算 — [TMPX サイズ予算](/docs/trusted-match/specification#size-budget) を参照）。OpenRTB にはそのような制限がないため、OpenRTB から TMP に橋渡しするバイヤーは、切り詰めのためにバイヤー設定の優先順位（通常: 決定論的グラフを先に — UID2、RampID — 次に確率的またはパブリッシャースコープの ID）を適用しなければなりません。