AIエージェント同士が広告を売り買いするための共通規格「AdCP（Ad Context Protocol）」は、2026年9月30日（米国時間）に3.2を正式公開しました。当サイトが2026年1月にAdCPの基本を解説した記事を書いた時点のバージョンは2.5系です。その後の9か月で3.0・3.1・3.2と3回の正式版が出て、2.x系は2026年8月1日に完全に廃止されました。2.x系を前提に試作した仕組みは、3.0以降への移行が必要です。
この記事は1月記事の続編です。AdCPの基本構造やOpenRTBとの違いは1月記事に任せ、ここでは「1月に挙げた5つの課題がどうなったか」を答え合わせし、3.2の中身を図解し、規格を取り巻く業界の勢力図を整理します。
関連記事
・Agentic広告にMCPが不可欠な理由・・・AIエージェント時代の「共通言語」を読み解く
・IAB Tech LabがAIエージェントの公開台帳を始動：AAMP Agent Registryの全容
・Sell-Side Agentベータテスト最前線：パブリッシャーのAgentic広告は今どこまで来たか
目次
まず時系列をそろえます。AdCPの公式リポジトリ（GitHub）のリリース記録によると、主なバージョンは次のとおりです。
| AdCPバージョン年表（2025年10月〜2026年9月） | |
| 2025-10-15 | 2.0.0：最初の公開版 |
| 2025-11-22 | 2.5.0：1月記事の時点のバージョン |
| 2026-04-22 | 3.0.0：最初の安定版。取引の安全装置を一新 |
| 2026-06-18 | 3.1.0：実運用に向けた強化 |
| 2026-08-01 | 2.x系サポート終了（完全廃止） |
| 2026-09-30 | 3.2.1：3.2の最初の正式版 |
| 出典：AdCP Release Notes（docs.adcontextprotocol.org）／GitHub Releases（adcontextprotocol/adcp、2026-10-16時点） | |
3.2の最初の正式版が「3.2.0」ではなく「3.2.1」なのには理由があります。リリースノートによると、2026年6月30日に3.1時代の中身で3.2.0を誤って公開してしまい、取り消したものの、公開済みの成果物は書き換えない決まりのため番号ごと欠番にしました。細かい話に見えますが、この「一度出したものは消さずに記録を残す」運用は、後で見る課題の答え合わせにも関わってきます。
開発の速さも目を引きます。GitHubのリリース一覧には、3.0.0の公開から2026年10月16日の3.2.5までに、パッチ版やベータ版を含め100を超えるリリースが並ぶ。3.0系・3.1系・3.2系を並行して保守しており、古いバージョンで動いている企業も切り捨てない方針です。
5つの課題のうち仕様で手当てできるもの（セキュリティ・ガバナンス・既存システムとの統合）は大きく前進しました。一方で、大手DSPの不参加という業界構造の課題は、ほぼ1月のままです。
1月記事では、AdCPの課題として次の5つを挙げていました。
この順番を入れ替えて、進んだものから見ていきます。
| 1月に挙げた5つの課題：2026年10月の答え合わせ | |
| セキュリティ 3.0で署名・重複防止を必須化 | ◎ 大きく前進 |
| ガバナンス 3.0で人の確認を仕様に組み込み | ◎ 大きく前進 |
| 既存システムとの統合 3.2は相手ごとにバージョンを選んで移行できる | ○ 前進 |
| ブラックボックス化 3.2で報告の欠落を検知（実験段階） | △ 途中 |
| 大手DSPの不参加 理事会にも大手DSPはいない | ✕ ほぼ変わらず |
| 出典：1月記事の課題一覧とAdCP Release Notesをもとに筆者作成（判定は筆者評価） | |
1月時点で最も弱かったのがセキュリティでした。3.0のリリースノートは、このバージョンの目玉を「信頼まわりの全面改修」と書いています。中身は主に3つです。
1つ目は、注文や変更などデータを書き換えるすべての要求に、重複防止の鍵（idempotency_key）を付けることの義務化です。通信が途切れてエージェントが同じ注文をやり直しても、二重発注にならない。売り手側は、この鍵に対応しているかどうかを必ず宣言しなければならず、宣言のない売り手は仕様違反になります。
2つ目は、要求そのものへの電子署名です。インターネットの標準規格RFC 9421に沿って、送り手が誰か、途中で中身が書き換えられていないかを受け手が確かめられるようにしました。広告主に通知を送る仕組み（Webhook）にも同じ方式の署名が求められます。
3つ目は、ガバナンス担当のエージェントが出す承認そのものへの署名です。ガバナンス担当のエージェントが設定されている計画では、売り手は署名の付いた承認を確認してから予算を確定させる決まりになりました。
ただし、手放しで評価はできません。3.0の時点で、要求への署名は任意で、必須になるのは「AdCP Verified」という認証を名乗る場合だけです。そのAdCP Verifiedも、3.0の時点では各社がテストを走らせて結果を公開する自己申告で、運営団体が監査するものではないと仕様書自身が明記しています。仕様は整ったが、守られているかを第三者が確かめる段階にはまだない。これが筆者の見立てです。
AI同士の取引で誰が責任を負うのかという問題に、3.0は具体的な答えを出しました。EUの一般データ保護規則（GDPR）第22条と、EU AI法の高リスク分野を、仕様のデータ形式そのものに組み込んだのです。
具体的には、キャンペーン計画に「人の確認が必要か」を示す項目（human_review_required）を設けました。住宅・融資・雇用・医薬品の広告では、この項目を「不要」にした計画はデータ形式の段階で受け付けられません。人の確認を外すには、20文字以上の理由と承認者のメールアドレスを付けた記録が必要で、変更履歴は書き足しだけで消せません。
承認の扱いも変わりました。以前は承認待ちを広告注文の状態の一つとして扱っていましたが、3.0では承認を独立した作業として切り出し、それぞれに履歴を残せるようにしています。
規格の運営そのものも、ガバナンスの成熟を示しています。2026年7月の3.1.3は、パッチ版で新しい項目を足してはいけない決まりに反したとして撤回されました。9月の3.1.22は、実験段階の機能に見つかったプライバシー上の問題を、通常6週間の予告期間を飛ばして緊急で直した版です。どちらも、撤回や例外の理由がリリースノートに記録されています。失敗を記録に残す運用は、仕様の項目以上に信頼につながると筆者は考えます。
1月記事では、レガシーシステムとの互換性や移行コストを課題に挙げました。3.2は、この点で現実的な設計を選んでいます。
リリースノートは「一斉切り替えの日（flag day）はない」と明言しています。売り手は対応できるバージョンの一覧を公開し、買い手は相手が3.2に対応していると分かったときだけ3.2で話しかける決まりです。3.1で動いている接続はそのまま動き続け、新しい機能は一つずつ取り入れられます。
エージェントの負担も軽くなりました。3.2では、広告取引の各段階に専用の小さな道具（ツール）を用意し、MCP（AIと外部ツールをつなぐ規格）で読み込む定義ファイルが、置き換え前の3.1と比べて71〜94%小さくなりました。AIが読み込む文字量が減れば、処理にかかる費用も下がります。ただしこれは定義ファイルの大きさの比較で、通信量や応答速度の比較ではありません。
AIエージェントの判断が見えにくくなる懸念には、3.2が「Reliable Reporting 1.0」という仕組みで答えようとしています。売り手が出すべき報告を一件ずつ記録し、届かなかった報告は「届いていない」と表示されます。数字を訂正するときも上書きはしない。新しい改訂として残す設計です。
あわせて3.2では、効果を誰が測ったか（売り手自身か、関連会社か、第三者か）の開示や、AIが生成した人物表現を含む広告の申告も入りました。
ただし、Reliable Reportingは「実験段階」の扱いです。判断の過程そのものを説明する仕組みではなく、取引の記録を欠けなく残す仕組みです。「なぜこの枠が選ばれたのか」という1月の問いには、まだ半分しか答えていません。
最大の課題は、ほぼ1月のままです。2026年9月28日、AdCPの運営団体AgenticAdvertising.org（AAO）が理事会を発表しました。Marketing Brewの取材に対し、理事長のBenjamin Masse氏は、理事会に大手DSPの代表はまだおらず、大手DSPはAdCPを「試しにかじっている（dabbling）」段階だと説明しています。
AdCPに対応したと受け取られやすい動きにも注意が要ります。後で見るApostra（旧Scope3）は、Google・Meta・Amazon・Reddit・ChatGPT Adsにつなぐ変換プログラム（アダプター）を作ったと発表しました。PPC Landは、このアダプターはApostra自身が作ったもので、これらの企業がAdCPを採用したわけではないと指摘しています。同誌によると、大手は外部の規格に乗るより、自社のAIエージェント窓口を自前で整える道を選んでいます。
1月記事には「2026年第2四半期にCuration Protocolを公開予定」と書きました。この名前の規格は出ていません。ただ、中身にあたるブランドセーフティと在庫の絞り込みは、3.0で「Governance（ガバナンス）」の機能として入りました。掲載先サイトのリストや、ブランドごとの「出してよい・出したくない」基準を、ガバナンス担当のエージェントが管理する仕組みです。
3.0では、扱う範囲も広がりました。広告主の身元を示すBrand Protocol、AIアシスタントの会話の中でブランドが応答するSponsored Intelligence（実験段階）が加わり、対応する媒体の種類は9から20になっています。
AdCP 3.2とは、AIエージェントが実際の広告予算を動かし、何が配信されたかを証明できるようにした版です。リリースノートは3.1と3.2の関係を「3.1でエージェントを安全に動かせるようにし、3.2で実際の媒体を、買い先のプラットフォームの力をフルに使って動かせるようにした」とまとめています。
| 項目 | 3.1.0 | 3.2.1 | 増減 |
|---|---|---|---|
| ツールの数 | 64 | 78 | +15追加・1削除 |
| 専門分野（スペシャリズム）の数 | 21 | 31 | +10 |
| 標準のエラーコード | 92 | 120 | +28 |
| データ形式の定義ファイル | 648 | 1,017 | +369 |
| 適合テストのファイル | 137 | 237 | +100 |
ツールの数は増えましたが、一つずつは軽くなりました。前の節で書いた定義ファイルの71〜94%削減は、このツールの細分化によるものです。
3.2の中心は、広告取引を7つのツールに分けたことです。3.1までは、少数の汎用ツールがいくつもの動作を兼ねていました。3.2では1つのツールが1つの区切りだけを受け持ちます。
| 3.2の取引フロー：7つの段階 | |
| ① list_products：売り手の商品（広告枠）を一覧で見る | |
| ↓ | |
| 提案ルート ② request_proposals：条件を伝えて提案を出してもらう ↓ ③ refine_proposals／④ decline_proposals：提案を詰める／断る ↓ ⑥ accept_proposal：提案を受け入れて契約する | 直接購入ルート ⑤ buy_products：商品を直接買う |
| ↓ | |
| ⑦ control_media_buy：配信中の注文を調整する | |
| 出典：AdCP公式ドキュメント「What’s new in AdCP 3.2」（2026-09-30） | |
提案は一度出したら書き換えられず、合意した条件の要約値（ハッシュ値）を持ちます。配信中の変更は、合意した条件の範囲を超えられません。後から「言った・言わない」にならないよう、買い手と売り手が同じ記録を指させる設計です。
3.2へ移るときに必須の変更は限られています。リリースノートの移行手順から、影響の大きいものを挙げます。
| 対象 | やること |
|---|---|
| 売り手 | 対応するバージョンの一覧に「3.2」を加え、応答にバージョンを書き添える |
| 買い手 | 相手が3.2を宣言しているときだけ3.2で送る |
| 双方 | 注文の作成・変更の応答から、状態の読み取り先を変える |
| 署名を使う企業 | 3.2の署名方式（本文の要約値を必ず含める）に合わせる |
| 双方 | すべてのエラーに「再試行できるか」の情報を付ける |
| SDKの開発者 | 署名済みの3.2.1の配布物からコードを生成する |
1月記事の時点で2.x系を前提に試作していた企業は、まず3.0への移行が必要です。2.x系はすでにサポートが終わっています。
仕様が育つ一方で、規格を取り巻く顔ぶれも入れ替わっています。2026年9月の1週間に、勢力図を変える出来事が3つ重なりました。
AAOの発表では、理事が「広告主・代理店」「媒体社」「技術企業」の3つにまとめて紹介されています。主な顔ぶれは次のとおりです。
| 区分 | 主な理事の所属 |
|---|---|
| 広告主・代理店 | WPP Media、Horizon Media、Butler/Till、Fortune 100の企業1社 |
| 媒体社 | Yahoo、News Corp、iHeartMedia、The Weather Company、CVS Media Exchange |
| 技術企業 | Salesforce、PubMatic、Optable、DoubleVerify、Swivel |
| 理事長 | Benjamin Masse氏（Triton Digital CPO） |
Marketing Brewによると、理事会は全40席のうち22席が埋まった状態です。席は広告主・媒体社・代理店・技術企業に10席ずつ割り振られ、技術企業と媒体社の枠は埋まった一方、ブランドと代理店からはさらに理事を募っています。AAOは、発足から9か月でコミュニティの利用者が3,300人を超えたとしています。
| AAO理事会：40席のうち22席が埋まる（2026-09-28時点） | ||
| 埋まった席 | 22/40 | |
| 空いている席 | 18/40 | |
| 席は広告主・媒体社・代理店・技術企業に10席ずつ。技術企業と媒体社の枠は埋まり、ブランドと代理店を募集中 | ||
| 出典：Marketing Brew（2026-09-28） | ||
筆者が注目するのは、ブランドと代理店の席が空いていることです。Masse氏は「技術者だけで作った規格にはしたくなかった」と語っていますが、現状は技術企業と媒体社が主導する規格です。お金を出す側が席に着くかどうかが、2027年に向けた最大の試金石になるでしょう。
2026年9月23日、AdCPの創設メンバーの一社だったScope3が、社名をApostraに変えました。広告の二酸化炭素排出量を測る事業で知られた会社です。PPC LandがBusiness Insiderなどの取材をもとにまとめたところでは、主な内容は次のとおりです。
Apostraの共同創業者Anne Coghlan氏はAAOの理事でもあります。PPC Landも指摘するように、AdCPは立ち上げ当初からScope3と、その創業者Brian O’Kelley氏の色が濃い規格でした。その会社が「AdCPの上で稼ぐ会社」へとはっきり舵を切ったことになります。規格の中立性をどう保つのかは、AAOが今後説明を求められる点です。
もう一つの勢力が、業界標準団体IAB Tech Labの「AAMP（Agentic Advertising Management Protocols）」です。AAMPの全体像は、当サイトのAdCP Sales AgentとIAB Seller Agentの比較記事とAAMP 2.0の解説記事で扱いました。
その後の動きは次のとおりです。
| 時期 | AAMP側の動き |
|---|---|
| 2026年7月30日 | AAMP 2.3を公開（PPC Land） |
| 2026年8月 | IAB Tech LabのShailley Singh COOが、AAMPとAdCPは13の機能で重なると指摘（PPC Land） |
| 2026年9月22日 | AAMP 3.0のドラフトを公開。中心はメディアプランニング向けの新仕様「OpenProposal」（PPC Land） |
| 2026年10月22日まで | AAMP 3.0の意見募集期間（PPC Land） |
業界では「AdCPはキャンペーン全体、AAMPは広告1回ごとの入札」と役割が分かれているという説明がよく使われてきました。PPC Landによると、Singh氏はこの見方を否定し、買い手と売り手のエージェント、自然言語の発注書、価格交渉、人の承認など13の機能が両者で重なると列挙しました。PPC Landは、この指摘が正しければ、両方に対応する企業は同じ仕事を二重に作ることになると分析しています。
| 提案（プロポーザル）の仕組み：AdCP 3.2 vs AAMP 3.0 | |
| AdCP 3.2 正式版：2026-09-30 request_proposals → refine/decline_proposals → accept_proposal 提案は書き換え不可＋ハッシュ値で固定 idempotency（重複防止）は3.0で義務化 | AAMP 3.0（OpenProposal） ドラフト公開：2026-09-22（意見募集〜10-22） 売り手が提案を返し、買い手エージェントが比べて選ぶ idempotencyの考え方も打ち出す（PPC Land） |
| IAB Tech LabのShailley Singh氏は両者に13の機能の重なりがあると指摘（PPC Land）。AAOのBenjamin Masse氏は「古典物理学と量子物理学を比べるようなもの」と述べ、対立しない立場（Marketing Brew）。 | |
| 出典：PPC Land（2026-08-20、2026-09-22）／Marketing Brew（2026-09-28） | |
一方のMasse氏は、Marketing Brewの取材に「古典物理学と量子物理学を比べるようなもの」と語り、両者は対立しないとの立場を取っています。
筆者の見方は、Singh氏寄りです。AAMP 3.0のOpenProposalは、売り手が提案を返し、買い手のエージェントが比べて選ぶ流れを標準化するもので、AdCP 3.2の提案ツール群（request_proposalsなど）とほぼ同じ場所を狙っています。PPC Landによると、AAMP 3.0は重複防止の仕組み（idempotency）も打ち出しており、AdCPが3.0で義務化した考え方とも重なります。2026年9月末に両陣営がそろって「提案」の仕組みを出したことで、住み分けの説明は苦しくなりました。
| AdCPを取り巻く勢力図（2026年10月時点） |
| AAO（理事長：Triton Digital） 規格を運営：AdCPを管理 Apostra（旧Scope3） 規格の上で事業：AdCPの上で売買を仲介 WPP・Yahoo・PubMatic・Salesforceなど 理事として参加：AdCPを推進 IAB Tech Lab 別の規格を推進：AAMPで競合 大手DSP（Google・Amazon・Meta等） 様子見：理事会に代表なし。自社のAI窓口を整備 |
| 出典：AgenticAdvertising.org（2026-09-28）／Marketing Brew（2026-09-28）／PPC Land（2026-09-27、2026-08-20）をもとに筆者作成 |
AAMPがエージェントの身元を確かめる仕組み（Agent Registry）は、「IAB Tech LabがAIエージェントの公開台帳を始動：AAMP Agent Registryの全容」で解説しています。
立場ごとに、2026年10月時点で取れる行動をまとめます。
2026年1月に挙げた5つの課題のうち、仕様で解ける課題は9か月で大きく進みました。3.0で署名と重複防止を義務化し、人の確認を仕様に組み込み、3.2で取引を7段階に分け、報告の欠落を見える化しています。2.x系の時代と比べると、実際のお金を動かす前提の規格になりました。
残ったのは、仕様では解けない課題です。大手DSPは理事会におらず、規格の顔だったScope3はApostraとして規格の上で稼ぐ側に回り、IAB Tech LabのAAMPは同じ領域に提案の仕組みを出してきました。次の節目は、AAOの理事会にブランドと代理店が加わるか、そしてAAMP 3.0の正式版がAdCPとどう向き合うかです。
AdCPの基本的な仕組みを確認したい方は、1月の解説記事をあわせて読んでください。