AdCP Sales Agent vs IAB Seller Agent: 同じ「売り手AI」でも設計思想が根本から違う

エージェンティック広告のバズワードが飛び交う2026年、ついに具体的なコードが出そろった。AdCP陣営の「Sales Agent」とIAB Tech Labの「Seller Agent」。どちらもパブリッシャーがAIエージェントで広告在庫を販売するためのオープンソースライブラリだが、中身を開いてみると設計思想からして別物だ。

2026年3月4日、MLエンジニアのWilliam Cichowskiが両ライブラリを週末で徹底比較したLinkedIn記事を公開した。合計15万行超のコードベースを実際にセットアップし、統合テストまで行った実践的なレビューだ。この記事を起点に、業界ソースも交えながら両者の構造的差異を整理してみる。


関連記事
Prebid Sales Agentが登場:パブリッシャー向けAIエージェントで広告収益は変わるのか
Agentic AIがプログラマティック広告を変える – 2026年CESで見えた自律型AI運用の実像
ARTF(Agentic RTB Framework)とは?gRPC×コンテナで実現する次世代広告取引の技術仕様を解説

そもそも何が起きているのか

2025年10月、Scope3やPubMatic、Yahoo、Optableなどが「Ad Context Protocol(AdCP)」を発表。AIエージェント同士が広告取引を行うための共通言語を、ゼロから設計するという野心的なプロジェクトだった。運営母体としてAgentic Advertising Organization(AAO)が設立され、ボードにはBrian O’KelleyとIAB元CEOのRandall Rothenbergが名を連ねる。

対するIAB Tech Labは「既存の標準を壊す必要はない」と反発。CEOのAnthony KatsurはAdCPを「deeply flawed」と公然と批判し、OpenRTBやAdCOMなど既存仕様をエージェント対応に拡張する方針を打ち出した。2026年2月にはこの取り組みを「AAMP(Agentic Advertising Management Protocols)」と命名し、Agent Registryの立ち上げを進めている。

両陣営の哲学的対立は、Adnami CPOのThomas Fromが端的に表現している。「AdCPは”全部壊して作り直す”思想。IAB Tech Labは”既存の上に積み上げる”思想」。革命か進化か。その対立が、売り手エージェントの実装にも如実に表れている。

AdCP Sales Agent vs IAB Seller Agent: 比較サマリー
評価軸 AdCP Sales Agent IAB Seller Agent
設計思想 エージェントネイティブ
ゼロから再設計
既存標準の拡張
OpenRTB/AdCOMベース
開発開始 2025年7月〜
Prebid.org管理、約8ヶ月の蓄積
2026年2月〜
正式ドキュメントなし
広告サーバー統合 GAM / Xandr / Kevel / Broadstreet
レポーティング機能あり
GAMのみ
レポーティング機能なし
在庫公開モデル 独立サーバー型
バイヤーが直接接続
マーケットプレイス型
IAB集中型サーバー経由
ガバナンス 本番レベル
承認フロー・監査ログ・Slack通知
深刻な欠陥あり
在庫偽装・サイレント承認バグ
GitHubスター数 24 6
出典: William Cichowski, LinkedIn (2026-03-04) / AdExchanger / GitHub各リポジトリ

開発タイムラインの差が品質に直結している

Cichowskiの比較で最初に目を引くのは、両プロジェクトの成熟度の違いだ。

AdCP Sales Agentは2025年7月後半から開発が続き、2026年1月にPrebid.orgがコードの管理権を引き受けた。ドキュメントは整備され、テストスイートもプロジェクトの大部分をカバーしている。GitHubスター数は24。

IAB Seller Agentの最初のパブリックコミットは2026年2月初旬。正式なドキュメントは存在せず、docstringに頼る状態。ユニットテストも機能の一部しかカバーしていない。GitHubスター数は6。

参考までに、Prebid.jsが約1,500スター、OpenRTBが約500スター。どちらのエージェントもまだ採用初期段階にある。ただし半年以上の開発蓄積がある AdCP と、出たばかりの IAB では土台が違う。


パブリッシャー広告サーバー統合:対応幅が決定的に異なる

パブリッシャーにとって最も実務的な評価軸が、広告サーバーとの互換性だ。

AdCP Sales Agentは「アダプター」ライブラリを持ち、Google Ad Manager(GAM)、Xandr、Kevel、Broadstreetの4つの広告サーバーに対応。GAMについてはオーダー、ラインアイテム、広告ユニットの作成・一覧取得に加え、カスタムレポートの取得まで可能だ。

IAB Seller AgentはGAMのみ対応。機能的にはオーダー、ラインアイテム、広告ユニットのCRUD操作は提供しているが、レポーティング機能はない。

Cichowskiは「自分のプロダクトに広告サーバーのAPI呼び出しを統合することが最優先だった。AdCPはこの用途でかなり満足できる出来」と評価している。


ディール交渉のアーキテクチャ:独立店舗 vs マーケットプレイス

両ライブラリの設計思想が最も鮮明に分かれるのが、在庫公開とディール交渉の仕組みだ。

AdCP Sales Agentはパブリッシャー自身がサーバーをデプロイし、バイヤーエージェントが直接接続して在庫を発見・取引する。いわば「独立した店舗」を自前で構える形だ。バイヤーエージェントが自然言語でニーズを伝えると、サーバー側が実際の在庫をランク付けしてマッチング。クリエイティブのアップロード、ディール承認へと進む。

IAB Seller Agentはマーケットプレイスモデルを採用する。ローカルにデプロイするが、IABの集中型OpenDirectサーバーに接続し、在庫を登録してインバウンド提案を受け取る仕組みだ。バイヤーはその共有取引所を通じてパブリッシャーを発見する。

どちらの発見レイヤーもまだネットワーク効果は生まれていない。AdCPにはエージェントレジストリがあり、IABも2026年3月にAgent Registryを立ち上げる予定だが、パブリッシャー・広告主の大量参入はどちらも経験していない。

在庫公開モデルの構造比較
AdCP Sales Agent
独立店舗モデル
IAB Seller Agent
マーケットプレイスモデル
バイヤーエージェント
自然言語でニーズを送信
パブリッシャー独自サーバー
在庫ランク付け・マッチング
クリエイティブ入稿 → ディール承認
バイヤーエージェント
IAB集中型OpenDirectサーバー
共有取引所でパブリッシャーを発見
パブリッシャーのローカルエージェント
インバウンド提案を受け取る
ディール承認
パブリッシャーが自前サーバーを保有
バイヤーが直接P2P接続
発見はAdCPエージェントレジスト経由
IABが仲介者として機能
集中型インフラに依存
2026年3月Agent Registry立ち上げ予定
出典: William Cichowski, LinkedIn (2026-03-04) / PubMatic Blog

ガバナンスと安全装置:ここが実運用で明暗を分ける

Cichowskiのレビューで最も深刻な指摘が、ガバナンス層の差だ。

AdCP Sales Agentの承認フローは高度に設定可能。「人間が常に承認」「1,000ドル超のディールのみ人間が承認」といったルールを柔軟に定義できる。Webhookによる非同期処理、予算閾値に基づく自動フラグ、全意思決定の監査テーブル記録、1万ドル超のディールでの自動Slack通知まで備える。

IAB Seller Agentにも興味深いロジックはある。グローバル、プロダクト、交渉ティアの3段階でフロアプライスを設定でき、Yield Optimizerが収益、バイヤー関係性、フィルレート、価格支配力に基づいてスコアリングする。ただしCichowskiの評価では、このスコアリングは「恣意的でぎこちない」プロトタイプ段階だ。

問題はそれだけではない。IAB Seller Agentには以下の深刻な不具合が存在する。

  • 在庫チェックがハードコードされたプレースホルダーを参照し、実際の在庫を見ていない
  • オーディエンスバリデーションで例外が発生すると、ディールをサイレントに承認してしまう
  • LLMレビュアーが自身の出力を基本的な文字列マッチングで解析する。”I cannot accept these terms”というフレーズに”accept”が含まれるため、拒否すべきディールを承認してしまう
  • 外部アラート機構がなく、エラーはインメモリリストに溜まるだけでリクエスト終了時に消失する

パブリッシャーにとって、ライブの在庫をこれらの不具合があるシステムに任せるのはリスクが高すぎる。Cichowski自身「IABのプロセスは面白いが、パブリッシャーとしてライブ在庫を委ねる気にはなれない」と述べている。


業界の反応:LinkedIn上の議論

Cichowskiの記事に対し、Scott Messer(RevOpsリーダー、AdTech Therapy主宰)がLinkedInでコメントしている。「IABの不足はほとんどが開発工数の不足が原因に見える。技術的にどれだけ遅れているのか?」という問いに対し、Cichowski本人は「その通り。機能の多くは作り直しではなく拡張とドキュメント化が必要な段階。ただし開発速度は読みにくい。大きなコミットを一括で出す傾向がある」と回答している。

業界全体では、PubMaticが「AdCPとARTFは競合ではなく補完関係」と主張。AdCPがアプリケーション層(意図や制約の表現)を、ARTFがトランザクション層(安全で予測可能な実行)をそれぞれ担うという整理だ。理想的には協調が最善だが、標準を握る者が参加条件を決める以上、これは技術論であると同時に業界の主導権争いでもある。


So What? パブリッシャーは何をすべきか

1. 現時点でエージェント統合を試すなら、AdCP Sales Agentを選ぶのが妥当だ。 ドキュメント、テストカバレッジ、ガバナンス機能のいずれも実運用に近い水準にある。Prebid.orgが管理を引き受けたことで、オープンソースとしての持続性にも一定の安心感がある。

2. IAB Seller Agentは「将来の有力候補」として注視する。 マーケットプレイスモデルのコンセプトや、AAMP全体のAgent Registryは魅力的だ。ただし現状のコードは本番投入には早い。IAB Tech Labは2026年中に全標準をエージェント対応にするとコミットしており、年後半に再評価する価値がある。

3. 両標準は18~24ヶ月で収束する可能性が高い。 アドテク業界の標準争いは、歴史的に「しばらくの混在→収束」というパターンをたどる。どちらか一方に賭けるよりも、自社のプログラマティック基盤がエージェント対応可能な構造になっているかを点検する方が優先度は高いだろう。


まとめ

  • 設計思想: AdCPはエージェントネイティブでゼロから構築。IABは既存標準の拡張アプローチ
  • 成熟度: AdCPが約8ヶ月先行。ドキュメント、テスト、統合対象いずれも充実
  • 在庫公開: AdCPは独立サーバー型、IABはマーケットプレイス型。どちらもネットワーク効果は未発生
  • ガバナンス: AdCPは本番レベルの承認フローと監査ログ。IABには深刻な安全上の欠陥が残る
  • 現実的な選択: 今すぐ試すならAdCP。IABは年後半の再評価で十分

Cichowskiはこう締めくくった。「どのプロトコルが支配的になるかは、最終的に最大のネットワークを構築した側が決める」。技術的優位は出発点に過ぎない。


関連記事

参考記事

本記事は以下のソースを参考に作成しました。

主要ソース

関連記事

GitHubリポジトリ

コメントを残す

上部へスクロール

Legare Techをもっと見る

今すぐ購読し、続きを読んで、すべてのアーカイブにアクセスしましょう。

続きを読む