エグゼクティブ・サマリー：エージェント型広告の新たなアーキテクチャ
デジタル広告業界は、AIによる「自動化（Automation）」から「自律化（Autonomy）」への地殻変動の最中にあります。この「エージェント型広告」への移行は、既存のプログラマティック・インフラ、特にOpenRTBに、2つの根本的な課題を突きつけています。
(1) リアルタイムの複雑な意思決定を可能にするための「超低遅延」の実行環境、
(2) 複数のプラットフォームを横断してAIエージェントが自律的に計画・交渉するための「統一された通信言語」です。
この2つの課題に対応するため、業界では一見競合するように見える2つの主要な標準化の動きが2025年後半に同時に発生し、混乱を招いています。それが、IAB Tech Labが主導する Agentic RTB Framework (ARTF) と、アドテク・コンソーシアムが推進する Ad Context Protocol (AdCP) です。
本記事では、ARTFとAdCPについて詳しく解説すると共に、直接的な競合関係にはないことを明らかにしています。両者は、エージェント型広告という未来のスタックにおいて、根本的に異なるレイヤーで機能するよう設計されています。
1. ARTF（インフラストラクチャ層）: ARTFは、エージェントが動作するための、コンテナ化された安全な「実行環境」を標準化するインフラストラクチャ・フレームワークです。その主目的は、OpenRTBオークション内部のレイテンシを劇的に削減し（最大80%）、リアルタイムのビッド・エンリッチメントを可能にすることです。
2. AdCP（コミュニケーション層）: AdCPは、エージェントが対話するための「統一API」を標準化するコミュニケーション・プロトコルです。その主目的は、OpenRTBオークションの外部で行われる、キャンペーンの計画、交渉、レポートといった高レベルのワークフローを自動化することです。
業界の「論争」の本質は、技術的な優劣ではなく、標準化のガバナンスとビジョンの主導権争いです。このパズルを完成させる第三のピースが、IAB Tech Labが採用した User Context Protocol (UCP)であり、これはプライバシーを保護する「エンベディング」を用いてシグナルを交換する「データ層」として機能します。
本記事では、これら3つの標準（ARTF, AdCP, UCP）の技術的アーキテクチャを詳細に解説し、それらが競合するのではなく、いかにして未来の自律型広告スタックの「インフラ層」「コミュニケーション層」「データ層」として協調し得るか、その全体像を明らかにします。
第1部：エージェント型広告へのパラダイムシフト
1.1. 「エージェント型広告」の定義：自動化から自律化へ
従来のプログラマティック広告は、事前に定義されたルールセットに基づき、タスクを実行する「自動化」（Automation）の追求でした。しかし、「エージェント型広告（Agentic Advertising）」は、その次の段階である「自律化（Autonomy）」を意味します。
エージェント型広告とは、AIエージェント（自律型システム）が、人間の介在を最小限に、独立したインテリジェントな意思決定を行い、広告キャンペーンの計画、交渉、実行、最適化をリアルタイムで行う概念です。これらのエージェントは、単にルールを実行するのではなく、与えられた目標（例：「ROASを最大化する」）に基づき、自ら「推論し、計画し、行動する」能力を持ちます。例えば、エージェントは自らデータを分析し、チャネル間の予算を再配分し、新たなオーディエンスを発見し、継続的に学習と最適化を行います。
1.2. エージェントが直面する2つの壁：レイテンシとフラグメンテーション
AIエージェントの能力が実用レベルに達した今、その本格的な導入を妨げているのが、既存のプログラマティック・インフラが持つ2つの構造的欠陥です。エージェント型広告への移行は、単一の課題ではなく、根本的に異なる2つの技術的課題を同時に露呈させました。ARTFとAdCPは、それぞれがこれらの異なる課題に対するソリューションとして登場したため、一見競合するように見えますが、実際には異なる問題領域をターゲットにしています。
課題1：「実行の壁」（レイテンシ問題）
AIエージェントがインプレッションごとに複雑な推論（例：高度な不正検知、リアルタイムのシグナル分析）を行うには、超低遅延の実行環境が必要です。しかし、既存のOpenRTBアーキテクチャは、SSPとDSPのデータセンター間をインターネット経由で通信が「ping」するため、物理的な往復（round-trip）に数百ミリ秒のレイテンシが不可避的に発生します。このレイテンシは、エージェントが「思考する」ための時間を奪い、リアルタイムの高度な意思決定を著しく困難にしています。
・この「実行の壁」を解決することを目指すのが ARTF です。
課題2：「オーケストレーションの壁」（API断片化問題）
AIエージェントがキャンペーンを「自律的に計画」するためには、複数のプラットフォーム（SSP、DSP、CTVプラットフォーム、パブリッシャー、Google Ad Managerなど）とコミュニケーションを取り、交渉する必要があります。しかし、アドテクエコシステムは「長年の断片化」に苦しんでおり、各プラットフォームが独自の非互換APIを維持しています。エージェントがプラットフォームを横断してキャンペーンを管理しようにも、プラットフォームごとにカスタム統合（通訳）が必要となり、自律的なオーケストレーションは事実上不可能です。
・この「オーケストレーションの壁」を解決することを目指すのが AdCP です。
第2部：ARTF (Agentic RTB Framework)：ビッドストリーム・インフラの近代化
2.1. 詳細解説：IAB Tech Labが描くリアルタイム実行環境
ARTF (Agentic RTB Framework) v1.0は、OpenRTBの標準化団体であるIAB Tech Labによって2025年11月13日に発表され、2026年1月15日までパブリックコメントが募集された技術仕様です。
これは、プログラマティック広告エコシステム全体の相互運用性を変革することを目指す、新しいインフラストラクチャ標準です。その核心は「コンテナ化されたアーキテクチャ (containerized architecture)」を利用し、リアルタイム・ビッディング（RTB）インフラストラクチャ内部で、サードパーティのエージェント（サービス）を安全かつ高速に動作させるための標準を定義するものです。
2.2. コア・アーキテクチャ：「コロケーション」によるコンテナ化実行環境
ARTFの技術的基盤は、OCI (Open Container Initiative) 準拠のコンテナ（Docker, Kubernetesなど）です。このフレームワークは、DSPや第三者ベンダー（サービスプロバイダー）が、自社の「エージェント」（例：入札ロジック、不正検出モジュール）をコンテナとして一度パッケージ化し、それをホストプラットフォーム（主にSSP）のインフラストラクチャ内に直接デプロイ（配備）することを可能にします。
これは、アドテクにおける「ネットワーク・アーキテクチャ」から「ローカル実行・アーキテクチャ」への根本的な転換を意味します。
・従来のRTB（ネットワーク型）： SSPがビッドリクエストを受け取ると、それをインターネット経由で複数のDSPのデータセンターに送信します。DSPは意思決定を行い、レスポンスを返します。この通信では、データ（ビッドリクエスト）がロジック（入札アルゴリズム）の場所へ移動していました。
・ARTF（ローカル実行型）： SSP（ホスト）は、DSP（サービスプロバイダー）の入札エージェントを、自社のデータセンター内のコンテナとして既に実行しています。ビッドリクエストが来ると、SSPはインターネットにリクエストを送信する代わりに、同じサーバーまたは仮想マシン内で実行されているDSPエージェントにローカル・コールで処理を委任します。
この「コロケーション（同一場所への設置）」の概念は、データを移動させるのではなく、ロジック（エージェント）をデータの存在する場所（SSPのデータセンター）に移動させることで、ネットワーク遅延を事実上ゼロにします。
2.3. 主目的：レイテンシの抜本的削減（最大80%）とリアルタイム・エンリッチメント
ARTFの最大の目的は、このアーキテクチャ変更による「レイテンシの削減」です。IAB Tech Labは、ビッドリクエストとレスポンスの時間を最大80%削減（例：従来の600-800msから約100msへ）できると主張しています。
この速度向上は、単に「オークションを速くする」こと以上の意味を持ちます。これは、これまでレイテンシの制約により不可能だった「リッチな意思決定」を、OpenRTBのオークション内部で可能にするための「実行ウィンドウ」の創出です。
従来のRTBオークションの厳格なタイムアウト（約100-200ms）では、複雑なAIモデルの実行、高度な不正検出、あるいはリッチなオーディエンス・データの照合は困難でした。そのため、これらのプロセスはオークションの前（例：オーディエンス・セグメントの事前同期）または後（例：分析）に行われる必要がありました。ARTFがネットワーク遅延に費やされていた時間を劇的に削減することで、新たな「実行ウィンドウ」が生まれます。この創出された時間（ウィンドウ）を使い、サードパーティの専門技術（例：リアルタイムのブランドセーフティ検証エージェント、ID解決エージェント）が、インプレッションごとにリッチな「ビッド・エンリッチメント」と「リアルタイム意思決定」を行うことが可能になります。
2.4. ARTFモデルにおけるセキュリティとプライバシー
サードパーティのエージェントをホストのインフラで実行することは、深刻なセキュリティとデータガバナンスの懸念を生じさせます。ARTFは、コンテナ化によってこの問題に対処します。
ホストプラットフォーム（SSP）は、「データとSLA（サービス品質保証）の制御を維持」できます。コンテナはサンドボックスとして機能し、サービスエージェント（DSPなど）がアクセスできるデータや実行できる操作を厳格に制限します。
このアーキテクチャは、意図せずして強力な「プライバシー強化技術（PET）」として機能する可能性があります。これは「データ・クリーンルーム」のリアルタイム実行版とも言えます。
・ポストクッキー時代とプライバシー規制の強化は、「データ最小化」と「データ漏洩の防止」を強く求めています。
・従来のRTBでは、ユーザーのIPアドレスやIDなどのシグナルが、オークションのたびに多数のベンダーに「スプレー（噴霧）」され、データ漏洩の重大なリスクとなっていました。
・ARTFのモデルでは、ホスト（SSP）は機微な（あるいは価値のある）ファーストパーティ・データをコンテナの外部に保持します。
・サービスエージェント（DSP）は、そのデータにアクセスして分析や意思決定を行うことはできますが、「データ漏洩や不正使用の懸念なしに」データをコンテナの外部（自社サーバー）に持ち出すことはできません。
・これは「データを動かすのではなく、ロジック（エージェント）をデータの元へ動かす」という、データ・クリーンルームの基本原則と同じです。ARTFは、SSPが自社の貴重なファーストパーティ・データを（プライバシーを保護しつつ）収益化し、DSPが（データを盗むことなく）それを利用して入札することを可能にする、安全な「コロケーション環境」を提供します。
2.5. ユースケースとガバナンス
・ユースケース: ビッドエンリッチメント、リアルタイムの入札判断、不正検出、ブランドセーフティ検証など、オークションのコア・ビッドストリームに参加する必要があるあらゆるタスク。
・ガバナンス: IAB Tech Lab。OpenRTBと同じガバナンス下にあり、既存のインフラとの互換性・継続性が重視されます。
・OpenRTBとの関係: ARTFはOpenRTBを置き換えるものではありません。ARTFはOpenRTBを「搭載」し、OpenRTBのビッドストリームにエージェントが「参加する」ためのインフラ拡張です。
テーブル 1：ARTF v1.0の主要技術要件
| 要件カテゴリ | 技術仕様 | 目的と意味 |
| コンテナ標準 | OCI (Open Container Initiative) 準拠 | Docker, Kubernetes, Amazon ECSなど、業界標準のコンテナ管理システムとの完全な互換性を保証する。 |
| エージェントの宣言 | インテント（意図）の宣言 | エージェントがオークションに対して行う可能性のある変更（例：入札単価の変更、拒否）を事前に宣言させ、ホストがそれを許可/拒否できるようにする。 |
| 通信プロトコル | Protobuf (Protocol Buffers) シリアライゼーション | OpenRTBで使われるJSONよりも高速で効率的なバイナリ・メッセージング・プロトコル。低遅延のリアルタイム通信に不可欠。 |
| 監視・運用 | 標準ヘルスチェック | ホストがコンテナ（エージェント）の正常性を監視し、異常時に自動的に再起動などを行うための標準化されたプローブ。 |
| テレメトリ | Open Telemetry サポート | メトリクスと分散トレーシングの標準をサポートし、複雑なエージェント・パイプラインの動作を可視化・デバッグできるようにする。 |
第3部：AdCP (Ad Context Protocol)：コミュニケーション層の標準化
ARTFがエージェントの「実行インフラ」を標準化するのに対し、AdCP (Ad Context Protocol) は、エージェントがプラットフォーム間で対話するための「コミュニケーション言語」を標準化するオープンソースのフレームワークです。
その主な目的は、アドテクエコシステムの「長年の断片化問題」に対処することです。AIエージェントが、OpenRTBのビッドストリーム外で、キャンペーンの計画、交渉、オーケストレーションといった高レベルのタスクを自動化できるように、統一されたAPIを提供します。
AdCPに関する詳細な解説は、CEESAWで以前公開した以下の解説記事をご参照ください。
参照記事：Ad Context Protocol (AdCP): エージェント型広告の次世代オープンスタンダード
第4部：ARTF vs. AdCP：それぞれの役割と違い
ARTFとAdCPは、エージェント型広告スタックの異なるレイヤーで機能し、直接競合するものではなく相互補完的な関係にあります。ARTFが「インフラ層」で同期的なリアルタイム実行を扱うのに対し、AdCPは「コミュニケーション層」で非同期的なオーケストレーションを扱います。
両者の主な違いについて、以下の比較表に要約します。
テーブル 2：エージェント型広告標準の比較（AdCP vs. ARTF）
| 標準化名称 | ARTF (Agentic RTB Framework) | AdCP (Ad Context Protocol) |
| 管理団体 | IAB Tech Lab | AdCPコンソーシアム (Yahoo, PubMatic, Scope3, etc.) |
| 分類 | インフラストラクチャ・フレームワーク | コミュニケーション・プロトコル |
| 核となる目的 | リアルタイム実行の高速化（低遅延） | 広告ワークフローの統一（断片化の解消） |
| 適用領域 | ビッドストリーム内部 | ビッドストリーム外部 |
| 対話モデル | 同期的（Synchronous）/ リアルタイム | 非同期（Asynchronous） |
| 想定応答時間 | サブ100ミリ秒 | 数秒〜数日（人間による介在を含む） |
| 基盤技術 | OCI準拠コンテナ (Docker, K8s) | Model Context Protocol (MCP) |
| 主なユースケース | ビッド・エンリッチメント、リアルタイム入札 | キャンペーン計画、交渉、レポーティング |
| OpenRTBとの関係 | 拡張 (Extension) / 強化 | 補完 (Complement) / 上位の抽象化 |
第5部：欠けていたピース：UCPと統合エージェント・スタック
ARTFとAdCPの論争を理解する上で、IAB Tech Labが2025年11月初旬に（AdCPの発表直後、ARTFの発表直前に）発表した「UCP (User Context Protocol)」の存在が極めて重要です。
5.1. UCP (User Context Protocol)：「データプレーン」の登場
UCPは、もともとLiveRampによって開発され、IAB Tech Labに寄贈されたオープンソース標準です。IAB Tech LabがUCPを採用したことは、AdCPの「Signals Protocol」に対する直接的な回答と見なすことができます。これにより、IAB Tech Labは「実行インフラ（ARTF）」に加えて「データ交換（UCP）」の標準も手に入れ、AdCP（オーケストレーション言語）と対峙する体制を整えました。
UCPの目的は、AIエージェントが「シグナル」を交換する方法を標準化することです。交換されるシグナルは3種類定義されています：
1. Identity Signals（ユーザーは誰か）
2. Contextual Signals（ユーザーが今何をしているか）
3. Reinforcement Signals（ユーザーが広告にどう反応したか）
5.2. プライバシー保護エンベディング：ポストクッキー時代のシグナル伝達
UCPの技術的な核心は、シグナルの交換に「エンベディング（Embeddings）」または「ベクトル（Vectors）」と呼ばれる技術を使用する点です。
これは、従来のテキストベース（例：オーディエンスセグメント名）やIDベース（例：Cookie ID）のシグナル交換とは根本的に異なります。エンベディングは、数千のデータポイント（例：ユーザーの行動履歴や文脈）を、256〜1024次元の「高密度なベクトル表現」（数値の配列）に圧縮します。
UCPは、ポストクッキー時代における「プライバシーとパーソナライゼーションのジレンマ」を解決するための、最も現実的な技術的アプローチの一つです。
・クッキーが廃止され、プライバシー規制（GDPRなど）が強化される中、個人の生データ（PII）やIDをプラットフォーム間で受け渡すことはますます困難になっています。
・しかし、広告の関連性（パーソナライゼーション）のためには、何らかの「意図」や「文脈」のシグナルが必要です。
・エンベディングは、この問題を解決します。ベクトル（数値の配列）自体は、元の生データを復元できない（あるいは極めて困難な）「非可逆的」な表現です。しかし、ベクトル間の「近さ」（距離計算）によって、「このユーザーのベクトルは『スポーツカーに興味がある人』のベクトルに近い」といったセマンティック（意味的）な類似性を計算することは可能です。
・結論として、UCPは、エージェントが「プライバシーを侵害する生データを交換することなく、広告的な意図や文脈の類似性（エンベディング）だけを効率的に交換する」ための標準的なデータフォーマットを提供します。IAB Tech LabがGPP（Global Privacy Protocol）やTCF（Transparency and Consent Framework）と連携させると述べているのは、このためです。
5.3. 一貫性のある未来像：ARTF、AdCP、UCPはいかに連携し得るか
これらの標準は競合するのではなく、未来の「統合エージェント・スタック」の異なるレイヤーを形成します。業界分析は、この補完関係を明確に示しています：
・AdCP（コントロールプレーン）: 「何を」「どのように」取引するか（メディア・オーケストレーション）を扱う。
・UCP（データプレーン）: 「誰が」「いつ」のシグナル（オーディエンス・IDオーケストレーション）を扱う。
・ARTF（実行プレーン）: 決定された取引を「リアルタイムで実行」する。
この3つの標準が連携する将来的なワークフロー（統合スタック）は、以下のように想定されます。
1. 【Phase 1: オーケストレーション (AdCP)】
広告主のエージェントが、自然言語のブリーフ（例：「日本の持続可能性に関心のあるアウトドア好きの女性にリーチしたい」）を AdCP プロトコル（create_media_buy）を使って発行します。
2. 【Phase 2: シグナル交渉 (UCP + AdCP)】
パブリッシャーのセールスエージェントが AdCP で応答します。オーディエンスを定義するため、両エージェントは「アウトドア好きの女性」の定義を生データではなく、UCP のプライバシー保護された「エンベディング（ベクトル）」として交換します。
3. 【Phase 3: ディール成立 (AdCP)】
両エージェントは、価格や条件について AdCP を介して非同期で交渉し、最終的にディールIDまたはフライト条件を成立させます。
4. 【Phase 4: リアルタイム実行 (ARTF + UCP + OpenRTB)】
ディールが実行フェーズに移ります。SSP（ホスト）のインフラ内で、ARTFによってコンテナ化されたDSP（バイヤー）の入札エージェントが待機します。
5. 【Phase 5: ローカル実行 (ARTF)】
インプレッションが発生すると、SSPは（ネットワーク越しではなく）ローカルの ARTF 環境にいるDSPエージェントを呼び出します。
6. 【Phase 6: リアルタイム照合 (UCP + OpenRTB)】
DSPエージェントは、そのインプレッションのコンテキスト（これも UCP エンベディングとして提供される可能性がある）と、Phase 2で合意した「ターゲット・エンベディング」をリアルタイムで照合し、サブ100msで入札決定を行い、OpenRTBを介して入札を返します。
7. 【Phase 7: リアルタイム検証 (ARTF)】
この実行中、同じ ARTF 環境で動作するScope3のエージェントが炭素排出量をチェックし、Optableのエージェントがプライバシーコンプライアンスをリアルタイムで検証する、といった並列処理も可能になります。
第6部：戦略的提言と将来展望
6.1. パブリッシャー（セルサイド）への提言
・ARTFへの対応: SSPや大手パブリッシャー連合は、ARTF準拠の「ホスト」インフラの提供を検討するとよいでしょう。これにより、DSPや検証ベンダーに対し、安全かつ低遅延の「実行環境」を提供でき、自社インフラの競争優位性を高められます。
・AdCPへの対応: AdCP準拠の「セールスエージェント」を構築し、自社のインベントリやパッケージを「ユニバーサルAPI」経由でAIバイヤーエージェントに公開することを検討するとよいでしょう。これにより、手動の営業プロセスを自動化し、新たなデマンドを開拓できます。
・UCPへの対応: 自社の貴重なファーストパーティ・データを、UCPの「エンベディング」としてプライバシーセーフな形で提供できるように準備するとよいでしょう。これがポストクッキー時代の新たなデータ収益化の源泉となります。
6.2. 広告主とDSP（バイサイド）への提言
・ARTFへの対応: 自社の入札ロジック、IDソリューション、不正検知アルゴリズムを、ARTF準拠の「コンテナ」としてパッケージ化する技術開発が必要です。これにより、SSPのインフラ内で高速に実行できるようになります。
・AdCPへの対応: 自社のシステムが外部のプラットフォームと自律的に通信・取引できるように、AdCPという共通言語（プロトコル）を使った「バイヤーエージェント」のソフトウェア開発の計画をロードマップに組み込むとよいでしょう。これにより、自然言語によるブリーフから、複数プラットフォームにまたがるキャンペーンの計画と実行を自律化できます。
・UCPへの対応: UCPの「エンベディング」を理解し、それに基づいて入札決定ができるAIモデルの訓練が求められます。
6.3. 将来展望：標準化への道筋
エージェント型広告の未来は、ARTF（インフラ）、AdCP（言語）、UCP（データ）という3つの標準が、いかにして相互運用可能なスタックに収斂していくかにかかっています。
現在の「論争」は、技術的な非互換性によるものではなく、標準化の主導権（ガバナンス）を巡る政治的なものです。AdCPコンソーシアムは強力な業界の支持を得てトップダウンの「言語」を推進し、IAB Tech LabはOpenRTBという既存の強力な「インフラ」からボトムアップで拡張しています。
最も論理的な帰結は、IAB Tech LabがLiveRampのUCPを寄贈として受け入れたのと同様に、最終的にAdCPのオーケストレーション言語も（競合する標準を自ら開発するのではなく）何らかの形でIAB Tech Labの管理下で協力・統合されることです。業界は断片化の解消を望んでおり、標準化団体の断片化を望んでいるわけではありません。
この3つの標準は、エージェント型広告という複雑な未来において、それぞれが不可欠な役割を担っており、業界の真の課題は、これらをいかにしてシームレスに連携させるかにあります。