「RTBのレイテンシーを80%削減し、AIエージェントが広告オークションに直接参加する」 もし本当にそれが実現するなら、プログラマティック広告の世界は根本から変わることになります。
少々古めの話題ですが、AdCPやAgentic AIでプログラマティック広告を語るには知っておくに越したことはないので、改めてまとめておきます。
2025年11月13日、IAB Tech LabはARTF(Agentic RTB Framework)v1.0のパブリックコメント版を公開しました。OpenRTB以来とも評されるこの新しいフレームワークは、コンテナ化されたエージェントがビッドストリームに直接介入し、gRPC(*)による高速通信でリアルタイム入札を再定義するものです。
(*)Googleが開発したオープンソースの高性能な「リモートプロシージャコール(RPC)」フレームワークで、アプリ同士があらかじめ決められた設計図どおりに、無駄のない形式で超高速かつ正確に通信するための仕組み。
この記事では、ARTFの技術仕様をProto定義レベルまで掘り下げて解説します。
- ARTFのコンテナ化アーキテクチャの全体像
- gRPC × Protocol Buffers による通信設計
- OpenRTB Patchとミューテーション(Mutation)の仕組み
- Intent(意図宣言)システムの設計思想
- RTB・AdCP・ARTFの3者比較
目次
- 1 ARTFとは何か?・・・「時間を折りたたむ」フレームワーク
- 2 ARTFのアーキテクチャ:3つの構成要素
- 3 gRPC × Protocol Buffers:通信プロトコルの設計
- 4 Proto定義から読み解くデータモデル
- 5 Mutation(ミューテーション):ビッドストリーム変更の設計
- 6 ライフサイクル管理:オークションのどこでエージェントが動くか
- 7 セキュリティモデル:ネットワーク隔離と最小権限
- 8 RTB・AdCP・ARTF:3つの標準を比較する
- 9 MCP・A2Aとの統合:将来のエージェンティック取引
- 10 業界の採用状況と主要プレイヤー
- 11 分析・考察:ARTFが業界にもたらすインパクト
- 12 まとめ
- 13 参考記事
ARTFとは何か?・・・「時間を折りたたむ」フレームワーク
ARTFは、IAB Tech Labが策定したリアルタイム入札(RTB)のための実行レイヤーフレームワークです。
従来のRTBでは、ビッドリクエストが複数のベンダーやクラウドサービスの間をネットワーク越しに行き来していました。ARTFはこの構造を根本から見直し、コンテナ化されたエージェントをホストプラットフォームの内部に配置することで、通信をデータセンター内のローカル処理に変えます。
IAB Tech Lab CEOのAnthony Katsur氏はこう表現しています:
「我々が業界として行っていることは、実質的に時間を折りたたむことです」
ARTFが解決する課題
| 従来RTB vs ARTF:レイテンシーの変革 | |||
ポイント:レイテンシー最大80%削減。Chalice AIが本番環境で実証済み。
|
|||
| 出典: IAB Tech Lab プレスリリース / Chalice AI 実績値 |
重要なのは、ARTFはOpenRTBを置き換えるものではないという点です。既存のOpenRTBの仕組みの上に「実行レイヤー」として機能し、コンテナ化されたエージェントがビッドストリームをエンリッチ(強化)する仕組みを標準化しています。
ARTFのアーキテクチャ:3つの構成要素
ARTFのアーキテクチャは、Host・Agent Service・Containerの3つの要素で構成されます。
| ARTFアーキテクチャ概要 | ||
| Host Platform(SSP / DSP / Exchange / Ad Server) | ||
|
Agent A
ID解決 コンテナ化サービス |
Agent B
不正検知 コンテナ化サービス |
Agent C
ビッド最適化 コンテナ化サービス |
|
↕ gRPC + Protocol Buffers
|
||
| Orchestrator(ホストが制御) | ||
|
↕
|
||
| OpenRTB Bidstream(BidRequest / BidResponse) | ||
| 【ポイント】 – Agentはホストのインフラ内にコンテナとしてデプロイされる – 外部ネットワークアクセスは一切禁止(セキュリティ・バイ・デザイン) – ホストがどのAgentを呼び出し、どのMutationを適用するかを制御 |
||
1. Host Platform(ホスト)
ホストは、SSP、DSP、エクスチェンジ、アドサーバー、またはキュレーションプラットフォームです。コアオークションのワークフローを実行し、インフラを所有し、データへのアクセスを管理します。
ホストの権限は非常に強く、以下を完全にコントロールします:
- どのエージェントを呼び出すか(シーケンシング)
- どのミューテーションを適用するか(ポリシー適用)
- SLAの管理(タイムアウト含む)
2. Agent Service(エージェント)
エージェントは、サードパーティまたはファーストパーティのサービスで、OCI準拠のコンテナとしてパッケージ化されます。具体的なユースケースには以下が含まれます:
- ID解決(Identity Resolution)
- 不正検知(Fraud Detection)
- コンテキスト/オーディエンスエンリッチメント
- ビッドロジック(入札最適化)
- 計測・アトリビューション
- ディール活性化(Deal Activation)
- サプライパス最適化(SPO)
3. Container(コンテナ)
ARTFでは、エージェントは以下の要件を満たすコンテナとしてデプロイされます:
| 要件 | 詳細 |
|---|---|
| OCI準拠 | Kubernetes、Docker Compose、Amazon ECS等で管理可能 |
| 高性能プロトコル | gRPCまたはMCPによる通信。Rust、Go、Java等の高効率言語推奨 |
| ネットワーク隔離 | 外部ネットワークアクセスは一切禁止。ホストとの通信のみ許可 |
| 暗号署名 | コンテナの署名によるデータの安全な連携 |
| サブミリ秒応答 | 低〜サブミリ秒のレスポンスタイム要件 |
gRPC × Protocol Buffers:通信プロトコルの設計
ARTFが従来のRTBと最も大きく異なるのが、通信プロトコルです。従来のHTTP/JSON(REST API)に代わり、gRPC × Protocol Buffersを採用しています。
なぜgRPCなのか?
IAB Tech Labの仕様書では、gRPCを選択した理由を明確に述べています:
| 観点 | REST(HTTP/JSON) | gRPC(Protocol Buffers) |
|---|---|---|
| シリアライゼーション | JSON(テキストベース) | Protocol Buffers(バイナリ) |
| 通信速度 | リクエストごとに接続開閉 | 双方向ストリーミング、接続維持 |
| 型安全性 | スキーマ検証が任意 | 強い型付け、自動バリデーション |
| ペイロードサイズ | 大きい(人間可読だが冗長) | コンパクト(機械最適化) |
| 不正ペイロード | 手動でバリデーション必要 | 自動的に不正ペイロードを拒否 |
gRPCサービス定義
ARTFのgRPCサービスは、驚くほどシンプルな設計です。公式GitHubリポジトリに公開されている.proto定義を見てみましょう。
service RTBExtensionPoint {
// オークションライフサイクルの所定イベントで
// 適用すべきMutationを含むRTBResponseを返す
rpc GetMutations (RTBRequest) returns (RTBResponse);
}
RPCメソッドはたった1つ:GetMutations。ホストがエージェントにRTBRequestを送り、エージェントはRTBResponse(ミューテーションのリスト)を返します。このシンプルさが、実装の容易さとパフォーマンスの両立を可能にしています。
Proto定義から読み解くデータモデル
ARTFの心臓部であるProtocol Buffers定義を、メッセージ構造ごとに解説します。
RTBRequest:ホストからエージェントへのリクエスト
message RTBRequest {
Lifecycle lifecycle = 1; // オークションの段階
string id = 2; // リクエスト固有ID
int32 tmax = 3; // タイムアウト(ms)
BidRequest bid_request = 4; // OpenRTB BidRequest
BidResponse bid_response = 5; // OpenRTB BidResponse
Originator originator = 6; // 送信元エンティティ
repeated Intent applicable_intents = 7; // 許可されたIntent
}
注目すべきポイント:
lifecycleフィールド:オークションのどの段階でエージェントが呼ばれるかを示す。現在はPUBLISHER_BID_REQUEST(パブリッシャーのビッドリクエスト時)とDSP_BID_RESPONSE(DSPのビッドレスポンス時)の2段階が定義されているtmaxフィールド:エージェントに許されるレイテンシーの上限(ミリ秒)。ホストがSLAを強制する仕組みapplicable_intentsフィールド:エージェントが返して良いIntentの一覧。ホストがエージェントの振る舞いを制約するための重要なフィールド
RTBResponse:エージェントからの応答
message RTBResponse {
string id = 1; // 対応するリクエストID
repeated Mutation mutations = 2; // 変更提案のリスト
Metadata metadata = 3; // レスポンスメタデータ
}
エージェントは直接ビッドストリームを書き換えることはできません。代わりに、Mutation(ミューテーション)のリストを提案し、ホストがそれを受け入れるか拒否するかを決定します。
Mutation(ミューテーション):ビッドストリーム変更の設計
Mutationは、ARTFの最も革新的な設計概念です。エージェントがビッドストリームに対して「こう変更したい」という提案を、構造化された形式で宣言します。
Mutationの構造
message Mutation {
Intent intent = 1; // 変更の目的
Operation op = 2; // 操作種別(追加/削除/置換)
string path = 3; // 変更対象のセマンティックパス
oneof value { // Intent固有のペイロード
IDsPayload ids = 100;
AdjustDealPayload adjust_deal = 101;
AdjustBidPayload adjust_bid = 102;
MetricsPayload metrics = 103;
DataPayload content_data = 104;
}
}
Intent(意図宣言)システム
ARTFの設計で特に注目すべきはIntent(意図)システムです。すべてのMutationは「なぜその変更をするのか」を宣言しなければなりません。
| ARTF Intent一覧(v1.0) | ||
| Intent | 目的 | ペイロード |
ACTIVATE_SEGMENTS |
ユーザーセグメントの活性化 | IDsPayload |
ACTIVATE_DEALS |
ディールの活性化 | IDsPayload |
SUPPRESS_DEALS |
ディールの抑制 | IDsPayload |
ADJUST_DEAL_FLOOR |
ディールのフロア価格調整 | AdjustDealPayload |
ADJUST_DEAL_MARGIN |
ディールのマージン調整 | AdjustDealPayload |
BID_SHADE |
ビッド価格の調整 | AdjustBidPayload |
ADD_METRICS |
メトリクスの追加 | MetricsPayload |
ADD_CIDS |
拡張コンテンツIDの追加 | DataPayload |
| 出典: IAB Tech Lab agenticrtbframework.proto(GitHub公開) | ||
このIntent設計が重要な理由は以下の通りです:
- ホストのポリシー適用:ホストは「このエージェントにはBID_SHADEだけ許可する」といった制御が可能
- エージェントの順序制御:ID解決 → 不正検知 → ビッド最適化、といったパイプライン構築が可能
- 監査可能性:すべての変更に「なぜ」が記録されるため、透明性が確保される
Operation(操作種別)
Mutationは、OpenRTBオブジェクトに対する3種類の操作を定義しています:
| Operation | 説明 | 例 |
|---|---|---|
ADD |
新しいデータを追加 | セグメントIDの追加 |
REMOVE |
既存データを削除 | ディールの抑制 |
REPLACE |
既存データを置換 | フロア価格の変更 |
セマンティック・パスの採用
Mutationのpathフィールドは、セマンティック参照(OpenRTBの概念に基づく意味的な参照)を使用します。JSONPathのような明示的パスではなく、ビジネスドメインの用語でターゲットを指定します。
これにより、ホストプラットフォームは内部データ構造を自由に最適化でき、エージェントの実装を壊すことなく進化できます。
ライフサイクル管理:オークションのどこでエージェントが動くか
ARTFは、プログラマティックオークションのライフサイクルを定義し、エージェントが介入するタイミングを制御します。
| ARTFオークション・ライフサイクル | |
| Stage 1 | PUBLISHER_BID_REQUEST パブリッシャー側でビッドリクエストが生成されたタイミング。 用途: コンテキスト追加、オーディエンスエンリッチメント、ID解決、不正検知 |
| Stage 2 | DSP_BID_RESPONSE DSP側でビッドレスポンスが返されたタイミング。 用途: ビッドシェーディング、マージン調整、計測データ付与 |
| 将来拡張 | 追加ステージ予定 v1.0では2段階のみ。将来的にオークション後の計測段階等が追加される可能性。 |
| 出典: agenticrtbframework.proto – Lifecycle enum | |
セキュリティモデル:ネットワーク隔離と最小権限
ARTFのセキュリティ設計は「Security by Design」の原則に基づいています。
ネットワーク隔離
仕様書で最も強調されているセキュリティ要件は、完全なネットワーク隔離です:
「エージェントは外部ネットワークアクセスを一切持たない。オーケストレーティングエンティティとのサービス通信を除き、すべてのネットワークの入出力が禁止される」
これにより、以下が保証されます:
- データ漏洩の防止:エージェントはホストから渡されたデータのみにアクセス可能
- ホストによるデータガバナンス:SLAの管理とデータ制御をホストが完全に保持
- 暗号署名によるコンテナ認証:デプロイされるコンテナの真正性を保証
Intentによるアクセス制御
RTBRequestのapplicable_intentsフィールドにより、ホストはエージェントごとに「許可するIntent」をリクエスト単位で制御できます。たとえば、ID解決専用のエージェントにはACTIVATE_SEGMENTSのみを許可し、価格調整系のIntentを一切渡さない、といった運用が可能です。
RTB・AdCP・ARTF:3つの標準を比較する
2025年から2026年にかけて、プログラマティック広告の世界では3つのフレームワークが注目を集めています。それぞれ異なるレイヤーと目的を持っており、「どれが最も優れているか」ではなく、「それぞれが何を担当するか」を理解することが重要です。
| RTB / AdCP / ARTF 技術比較 | |||
| 比較項目 | 従来RTB (OpenRTB 2.x) |
AdCP (Ad Context Protocol) |
ARTF (Agentic RTB Framework) |
| 策定団体 | IAB Tech Lab | AAO(Agentic Advertising Organization) | IAB Tech Lab |
| 対象レイヤー | トランザクション | アプリケーション (意図・推論) |
実行 (ビッドストリーム処理) |
| 通信プロトコル | HTTP/JSON | JSON-RPC (MCPベース) |
gRPC (Protocol Buffers) |
| 処理モデル | 同期 (100ms以内) |
非同期 (秒〜日単位) |
同期 (サブミリ秒) |
| デプロイモデル | 分散 (ネットワーク越し) |
分散 (MCPサーバー間) |
コロケーション (同一DC内コンテナ) |
| レイテンシー | 600〜800ms | 秒〜日(非同期) | 約100ms (最大80%削減) |
| 人間介在 | なし | 対応 (Human-in-the-Loop) |
なし |
| 主要支持企業 | 業界全体 | Scope3, PubMatic, Yahoo, Optable |
Index Exchange, The Trade Desk, Amazon Ads, Netflix |
| 設計思想 | 既存標準 | ゼロから再設計 (革新的) |
既存を拡張 (漸進的) |
| 出典: 各仕様書・公式発表より筆者作成 | |||
レイヤーの違いを理解する
PubMaticのNishant Khatri氏は、両者の関係を以下のように整理しています:
- AdCP = アプリケーションレイヤー:AIエージェントが目的・制約・権限を標準化された形式で表現するための共通言語
- ARTF = 実行レイヤー:リアルタイム入札環境内での具体的な処理を実行するフレームワーク
つまり、AdCPが「何をしたいか」を定義し、ARTFが「どう実行するか」を定義するという、異なるレイヤーを担当しているのです。
競合ではなく共存
業界では当初「AdCP vs ARTF」という対立構図で語られることが多くありました。しかし、実際には18〜24ヶ月の共存期間を経て収束に向かうと多くの識者が予測しています。
IAB Tech Lab CEOのKatsur氏はAdCPに対して批判的な姿勢を見せつつも、ARTF自体は「既存のOpenRTBの上に構築された漸進的な進化」と位置づけています。一方のAdCPは、AnthropicのMCPをベースに「エージェント同士が人間のように交渉する」という、より革新的なビジョンを描いています。
MCP・A2Aとの統合:将来のエージェンティック取引
ARTFの仕様書では、v1.0がカバーする範囲を明確に「実行レイヤー」に限定しつつ、将来的な拡張としてMCP(Model Context Protocol)とA2A(Agent-to-Agent)通信のサポートを言及しています。
MCPとの関係
MCPは、AIモデルやツールが外部リソースやサービスにアクセスするためのJSON-RPCベースのプロトコルです。ARTFはMCPを「モデル対サービス」「モデル対エージェント」のインタラクションのための補完プロトコルとして位置づけています。
現在のv1.0では、gRPCによるHost-Agent間の同期通信に焦点を当てていますが、将来的にはMCPを介してAIモデルがリアルタイムで広告戦略を判断し、ARTFのMutationとして実行するという自律的エージェント取引が想定されています。
業界の採用状況と主要プレイヤー
ARTFは単なるペーパー仕様ではなく、すでに本番環境での検証が進んでいます。
Container Project Working Group参加企業
ARTFの策定には16以上の組織が参加しています:
- Index Exchange(Chief Architect Joshua Prismon氏が「production-tested」と評価)
- Chalice AI(CEO Adam Heimlich氏、レイテンシー80%削減を実証)
- The Trade Desk
- Amazon Ads
- Netflix
- Yahoo DSP
- Paramount
- Publicis Group(Epsilon)
- PubMatic
- OpenX
公開コメント期間
ARTF v1.0のパブリックコメント期間は2025年11月13日から2026年1月15日まで実施されました。GitHubでのオープンソース貢献も受け付けられています。
分析・考察:ARTFが業界にもたらすインパクト
So What?(だから何なのか)
1. インフラコストの民主化
Anthony Katsur氏が強調しているように、ARTFの最大のインパクトはスタートアップやイノベーターの参入障壁が大幅に下がることです。従来、プログラマティック広告に参入するには重厚なインフラの構築・維持が必要でした。ARTFにより、エージェントをコンテナ化して「一度パッケージ化すれば、準拠するどのプラットフォームにもデプロイ可能」になります。
これは、かつてクラウドコンピューティングがWebサービスの参入障壁を下げたのと同様のパラダイムシフトを、アドテク業界にもたらす可能性があります。
2. 「意図の透明性」という新しいパラダイム
Intent設計によって、すべてのビッドストリーム変更に「なぜ」が記録されるようになります。これは規制当局(GDPR、デジタル市場法等)への説明責任にも直結します。「AIが勝手に価格を操作した」ではなく「BID_SHADEのIntentで、このモデルバージョンが、この根拠に基づいて価格を提案し、ホストがそれを承認した」というトレーサビリティが確保されます。
3. 日本市場への影響を考える
ARTFの採用は、2026年後半から2027年にかけて欧米市場で本格化すると予想されます。日本市場においても以下の動きが考えられます:
- SSP/DSPベンダーの対応:グローバル展開するSSP/DSPがARTF対応を進めれば、日本市場でも利用可能になる
- データプロバイダーの機会:コンテキスト解析やオーディエンスデータのプロバイダーが、ARTFエージェントとしてサービスを提供する可能性
- パブリッシャーへの影響:リアルタイムエンリッチメントにより、収益最適化の機会が広がる
まとめ
- ARTFはOpenRTB以来の大きな変革:コンテナ化×gRPCで、広告取引のインフラそのものを再設計するフレームワーク
- シンプルかつ拡張性のある設計:gRPCサービスはRPCメソッド1つ(
GetMutations)のみ。Intentシステムで拡張性を確保 - セキュリティ・バイ・デザイン:ネットワーク隔離、Intent制御、コンテナ署名による多層防御
- AdCPとは対象レイヤーが異なる:AdCPは「何をしたいか」(アプリケーション層)、ARTFは「どう実行するか」(実行層)
- すでに本番実証済み:Index Exchange、Chalice AIが本番環境でレイテンシー80%削減を確認
ARTFの技術仕様はGitHubで公開されています。今後のアドテク業界の方向性を理解するうえで、Proto定義を読んでみることをお勧めします。
参考記事
本記事は以下のニュースソースを参考に作成しました。
公式リソース
- IAB Tech Lab Announces Agentic RTB Framework (ARTF) v1.0 for Public Comment – IAB Tech Lab (2025-11-13)
- GitHub – IABTechLab/agentic-rtb-framework – IAB Tech Lab
- Breaking Down the Walls: IAB Tech Lab’s Blueprint for Containerized Agent-Powered Advertising – IAB Tech Lab
- ARTF Technical Specs – artf.ai
業界メディア
- For the agentic-curious: WTF is the Agentic RTB Framework? – DIGIDAY
- IAB Tech Lab unveils Agentic RTB Framework – MarTech
- IAB Tech Lab opens agentic RTB framework for container-based advertising – PPC Land
- IAB Tech Lab, not a fan of AdCP, releases an agentic advertising framework – The Current
比較・分析
- Moving Beyond AdCP vs ARTF – PubMatic
- Anthony Katsur on ARTF – LinkedIn
関連記事
- IAB Tech Lab Agentic AIロードマップ – Legare Tech
- AdCPとは?AI時代の広告取引を変革する新標準を解説 – Legare Tech