「RTBのレイテンシーを80%削減し、AIエージェントが広告オークションに直接参加する」 もし本当にそれが実現するなら、プログラマティック広告の世界は根本から変わることになります。
少々古めの話題ですが、AdCPやAgentic AIでプログラマティック広告を語るには知っておくに越したことはないので、改めてまとめておきます。
2025年11月13日、IAB Tech LabはARTF（Agentic RTB Framework）v1.0のパブリックコメント版を公開しました。OpenRTB以来とも評されるこの新しいフレームワークは、コンテナ化されたエージェントがビッドストリームに直接介入し、gRPC(*)による高速通信でリアルタイム入札を再定義するものです。
(*)Googleが開発したオープンソースの高性能な「リモートプロシージャコール（RPC）」フレームワークで、アプリ同士があらかじめ決められた設計図どおりに、無駄のない形式で超高速かつ正確に通信するための仕組み。
この記事では、ARTFの技術仕様をProto定義レベルまで掘り下げて解説します。
Contents
ARTFは、IAB Tech Labが策定したリアルタイム入札（RTB）のための実行レイヤーフレームワークです。
従来のRTBでは、ビッドリクエストが複数のベンダーやクラウドサービスの間をネットワーク越しに行き来していました。ARTFはこの構造を根本から見直し、コンテナ化されたエージェントをホストプラットフォームの内部に配置することで、通信をデータセンター内のローカル処理に変えます。
IAB Tech Lab CEOのAnthony Katsur氏はこう表現しています：
「我々が業界として行っていることは、実質的に時間を折りたたむことです」
| 従来RTB vs ARTF：レイテンシーの変革 | |||
ポイント：レイテンシー最大80%削減。Chalice AIが本番環境で実証済み。 | |||
| 出典: IAB Tech Lab プレスリリース / Chalice AI 実績値 |
重要なのは、ARTFはOpenRTBを置き換えるものではないという点です。既存のOpenRTBの仕組みの上に「実行レイヤー」として機能し、コンテナ化されたエージェントがビッドストリームをエンリッチ（強化）する仕組みを標準化しています。
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を適用するかを制御 | ||
ホストは、SSP、DSP、エクスチェンジ、アドサーバー、またはキュレーションプラットフォームです。コアオークションのワークフローを実行し、インフラを所有し、データへのアクセスを管理します。
ホストの権限は非常に強く、以下を完全にコントロールします：
エージェントは、サードパーティまたはファーストパーティのサービスで、OCI準拠のコンテナとしてパッケージ化されます。具体的なユースケースには以下が含まれます：
ARTFでは、エージェントは以下の要件を満たすコンテナとしてデプロイされます：
| 要件 | 詳細 |
|---|---|
| OCI準拠 | Kubernetes、Docker Compose、Amazon ECS等で管理可能 |
| 高性能プロトコル | gRPCまたはMCPによる通信。Rust、Go、Java等の高効率言語推奨 |
| ネットワーク隔離 | 外部ネットワークアクセスは一切禁止。ホストとの通信のみ許可 |
| 暗号署名 | コンテナの署名によるデータの安全な連携 |
| サブミリ秒応答 | 低〜サブミリ秒のレスポンスタイム要件 |
ARTFが従来のRTBと最も大きく異なるのが、通信プロトコルです。従来のHTTP/JSON（REST API）に代わり、gRPC × Protocol Buffersを採用しています。
IAB Tech Labの仕様書では、gRPCを選択した理由を明確に述べています：
| 観点 | REST（HTTP/JSON） | gRPC（Protocol Buffers） |
|---|---|---|
| シリアライゼーション | JSON（テキストベース） | Protocol Buffers（バイナリ） |
| 通信速度 | リクエストごとに接続開閉 | 双方向ストリーミング、接続維持 |
| 型安全性 | スキーマ検証が任意 | 強い型付け、自動バリデーション |
| ペイロードサイズ | 大きい（人間可読だが冗長） | コンパクト（機械最適化） |
| 不正ペイロード | 手動でバリデーション必要 | 自動的に不正ペイロードを拒否 |
ARTFのgRPCサービスは、驚くほどシンプルな設計です。公式GitHubリポジトリに公開されている.proto定義を見てみましょう。
service RTBExtensionPoint {
// オークションライフサイクルの所定イベントで
// 適用すべきMutationを含むRTBResponseを返す
rpc GetMutations (RTBRequest) returns (RTBResponse);
}
RPCメソッドはたった1つ：GetMutations。ホストがエージェントにRTBRequestを送り、エージェントはRTBResponse（ミューテーションのリスト）を返します。このシンプルさが、実装の容易さとパフォーマンスの両立を可能にしています。
ARTFの心臓部であるProtocol Buffers定義を、メッセージ構造ごとに解説します。
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の一覧。ホストがエージェントの振る舞いを制約するための重要なフィールドmessage RTBResponse {
string id = 1; // 対応するリクエストID
repeated Mutation mutations = 2; // 変更提案のリスト
Metadata metadata = 3; // レスポンスメタデータ
}
エージェントは直接ビッドストリームを書き換えることはできません。代わりに、Mutation（ミューテーション）のリストを提案し、ホストがそれを受け入れるか拒否するかを決定します。
Mutationは、ARTFの最も革新的な設計概念です。エージェントがビッドストリームに対して「こう変更したい」という提案を、構造化された形式で宣言します。
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;
}
}
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設計が重要な理由は以下の通りです：
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」の原則に基づいています。
仕様書で最も強調されているセキュリティ要件は、完全なネットワーク隔離です：
「エージェントは外部ネットワークアクセスを一切持たない。オーケストレーティングエンティティとのサービス通信を除き、すべてのネットワークの入出力が禁止される」
これにより、以下が保証されます：
RTBRequestのapplicable_intentsフィールドにより、ホストはエージェントごとに「許可するIntent」をリクエスト単位で制御できます。たとえば、ID解決専用のエージェントにはACTIVATE_SEGMENTSのみを許可し、価格調整系のIntentを一切渡さない、といった運用が可能です。
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が「何をしたいか」を定義し、ARTFが「どう実行するか」を定義するという、異なるレイヤーを担当しているのです。
業界では当初「AdCP vs ARTF」という対立構図で語られることが多くありました。しかし、実際には18〜24ヶ月の共存期間を経て収束に向かうと多くの識者が予測しています。
IAB Tech Lab CEOのKatsur氏はAdCPに対して批判的な姿勢を見せつつも、ARTF自体は「既存のOpenRTBの上に構築された漸進的な進化」と位置づけています。一方のAdCPは、AnthropicのMCPをベースに「エージェント同士が人間のように交渉する」という、より革新的なビジョンを描いています。
ARTFの仕様書では、v1.0がカバーする範囲を明確に「実行レイヤー」に限定しつつ、将来的な拡張としてMCP（Model Context Protocol）とA2A（Agent-to-Agent）通信のサポートを言及しています。
MCPは、AIモデルやツールが外部リソースやサービスにアクセスするためのJSON-RPCベースのプロトコルです。ARTFはMCPを「モデル対サービス」「モデル対エージェント」のインタラクションのための補完プロトコルとして位置づけています。
現在のv1.0では、gRPCによるHost-Agent間の同期通信に焦点を当てていますが、将来的にはMCPを介してAIモデルがリアルタイムで広告戦略を判断し、ARTFのMutationとして実行するという自律的エージェント取引が想定されています。
ARTFは単なるペーパー仕様ではなく、すでに本番環境での検証が進んでいます。
ARTFの策定には16以上の組織が参加しています：
ARTF v1.0のパブリックコメント期間は2025年11月13日から2026年1月15日まで実施されました。GitHubでのオープンソース貢献も受け付けられています。
1. インフラコストの民主化
Anthony Katsur氏が強調しているように、ARTFの最大のインパクトはスタートアップやイノベーターの参入障壁が大幅に下がることです。従来、プログラマティック広告に参入するには重厚なインフラの構築・維持が必要でした。ARTFにより、エージェントをコンテナ化して「一度パッケージ化すれば、準拠するどのプラットフォームにもデプロイ可能」になります。
これは、かつてクラウドコンピューティングがWebサービスの参入障壁を下げたのと同様のパラダイムシフトを、アドテク業界にもたらす可能性があります。
2. 「意図の透明性」という新しいパラダイム
Intent設計によって、すべてのビッドストリーム変更に「なぜ」が記録されるようになります。これは規制当局（GDPR、デジタル市場法等）への説明責任にも直結します。「AIが勝手に価格を操作した」ではなく「BID_SHADEのIntentで、このモデルバージョンが、この根拠に基づいて価格を提案し、ホストがそれを承認した」というトレーサビリティが確保されます。
3. 日本市場への影響を考える
ARTFの採用は、2026年後半から2027年にかけて欧米市場で本格化すると予想されます。日本市場においても以下の動きが考えられます：
GetMutations）のみ。Intentシステムで拡張性を確保ARTFの技術仕様はGitHubで公開されています。今後のアドテク業界の方向性を理解するうえで、Proto定義を読んでみることをお勧めします。
本記事は以下のニュースソースを参考に作成しました。