適切な基盤がなければ、エージェント型メディアバイイングをスケールさせることはできません。バイヤーとセラーがDatabricksでどのようにそれを実現しているかをご覧ください。

今日のメディアバイイングにおけるボトルネックは、人材ではなく調整作業です

毎日、何十億ドルもの広告取引が、何十年もほとんど変わっていないプロセス（メール、スプレッドシート、PDF、電話など）を通じて行われています。バイヤーがキャンペーンを設定すると、熟練したチームがパブリッシャーに連絡し、RFPを送信し、料金表を待ち、メディアキットを比較し、価格を交渉した上で、ようやく発注書を発行します。優秀な人材が、戦略的かつクリエイティブな業務を管理する代わりに、取引の調整作業に大半の時間を費やしているのが現状です。

この摩擦の原因は、プロセスの断片化にあります。広告枠の検出、オーディエンスの評価、パートナー間での信頼関係の構築を行うための標準化された方法がないため、バイヤーとセラーのすべての接続が個別のカスタム連携になってしまいます。調整に数日かかるため、意思決定はすでに数時間前、あるいは数日前の古い情報に基づいて行われることがよくあります。広告枠、価格設定、オーディエンスシグナルは絶えず変化しているため、キャンペーンが承認される頃には、絶好の機会を逃してしまっている可能性があります。

エージェントティックワークフロー（自律型エージェントによる業務フロー）の台頭により、チームは手動の反復的な調整作業から解放されます。これにより、より的確なターゲティング、優れたクリエイティブ、そして迅速に立ち上げるだけでなく、より効果的なキャンペーンの展開など、人間の判断が最も重要となる業務に時間を費やすことができるようになります。

なぜこれがついに解決可能になったのか、そしてなぜ標準規格が重要なのか

前回のAIの波は「回答する」ソフトウェアを生み出しました。次の波は「行動する」ソフトウェア、つまり目標を追求し、意思決定を行い、ツールを呼び出し、ユーザーに代わって取引を行うエージェントを生み出します。これこそ、手動のメディアバイイングが忙殺されている調整作業（ブリーフの読み込み、パブリッシャーの調査、料金表の比較、価格交渉、発注書の発行など）そのものです。LLMやMCPのようなプロトコルを使用したマルチエージェントシステムにより、このループを初めて自動的に実行できるようになりました。

しかし、自動化だけでは十分ではありません。IAB Tech LabのAgentic Advertising Management Protocols（AAMP）規格は、一貫した通信パターンを確立します。これには、広告枠とオーディエンスのための共有語彙（AdCOM、タクソノミー）、共通の取引プロトコル（OpenDirect、OpenRTBディール）、そして検出と信頼のためのレジストリモデルが含まれます。2者間だけであれば、標準規格なしでAIを使ってこれを解決することも可能でしょう。しかし、標準規格があるからこそ業界全体が足並みを揃えて前進でき、あらゆるブラウザが任意のウェブサイトを読み込めるのと同じように、準拠しているバイヤーエージェントであれば、準拠しているどのセラーエージェントとも取引できるようになります。

オープンな標準規格は、エージェント同士が何を会話するかを定義します。次の課題は、それらのエージェントが実際にどこで実行されるか、つまり、その状態、モデル、アイデンティティ、ガバナンスをどう管理するかです。そこでDatabricksの出番です。

私たちは、完全にDatabricks上で動作するエージェント型メディアバイイングおよびセリングのサンプルを構築しました。自律的なバイヤーとセラーが互いを発見し、価格に合意し、取引を成立させます。これは公式のオープンソースであるIAB Tech LabのSoftware Development Kit（SDK）に基づいて構築されているため、プロトコルレイヤーでのロックインはありません。現在、1つのコマンドでデプロイできるソリューションアクセラレータとして提供されています。手順はこのブログの最後に記載されています。

エージェント型メディアバイイングの構成要素

エージェント型メディアバイイングは、3つのプレイヤーによるシンプルな取引です。

• バイヤー：予算、リーチしたいオーディエンス、上限価格を設定したキャンペーンを持つ広告主（またはその代理店）。
• セラー：広告枠を持つパブリッシャー。それぞれがカタログ（パッケージや製品のメディアキット）と独自の価格設定を持っています。
• レジストリ：バイヤーがセラーを見つけ、バイヤーの身元や、バイヤーが取得できるアクセス権や価格設定を特定することで信頼を確立するためのディレクトリ。

バイイング自体は短いループです。どのセラーが適切な広告枠を持っているかを検出し、価格を設定し、取引を成約させる（または見送る）というプロセスです。現在、このループの大部分は手動で行われていますが、私たちが実演している変革は、これを双方のAIエージェントで実行することです。

異なる企業のエージェント同士が取引を行うには共通の言語が必要であり、そこにIAB Tech Labのオープン標準規格が価値をもたらします。ここでは彼らのSDKの詳細には触れませんが、代わりにDatabricks上でバイヤーエージェントとセラーエージェントを実行するために何が必要かに焦点を当てます。

バイヤーおよびセラーエージェントのための完全なエコシステム

複雑なエージェントは、大規模言語モデル（LLM）への単純なリクエストをはるかに超える処理を行います。これらのエージェントが、オーディエンスのプランニング、予算の配分、パブリッシャーの検出、上限価格の遵守、取引の成約など、さまざまなタスクを伴うメディア取引を実行するには、以下を管理するシステムが必要です。

• 状態（State）：永続的かつトランザクションとして正確である必要があるブリーフ、アイデンティティ、カタログ、見積もり、および注文。
• 提供されるモデル（Models served）：エージェントが呼び出すことができる、ガバナンスの効いた基盤モデル。各タスクに適したモデルが用意されます。
• ガバナンスされたデータ（Governed data）：アクセス制御が適用された、エージェントが推論の対象とするカタログおよびオーディエンスデータ。
• アイデンティティと信頼（Identity and trust）：このエージェントは誰であり、何を表示し実行することが許可されているか。
• オブザーバビリティ（Observability）：デバッグや監査のための、すべての意思決定とツール呼び出しのトレース。

このシステムは、データベースベンダー、モデルホスト、ガバナンスツール、アプリプラットフォーム、トレースサービスを組み合わせて構築することもできます。しかしDatabricksなら、これらが1つのプラットフォームに統合されています。

適切なアーキテクチャとはどのようなものでしょうか？

まず、この市場における事実から始めましょう。バイヤー、セラー、レジストリはそれぞれ独立したエンティティです。これにより、問題は2つに分かれます。関係者同士がどのように通信するか、そして各関係者が取引の自社側を実際にどこで実行するかです。オープンプロトコルは前者の問いに答えます。プロトコルは関係者間のパイプ役となり、検出、交渉、決済を伝達しますが、役割はそこまでです。エージェントがどこで実行され、状態を保持し、アイデンティティを証明し、ガバナンスを維持するかは、プラットフォームの役割です。そのため、各関係者はDatabricks Apps上に構築された自己完結型のアプリケーションを持ち、自身の状態、アイデンティティ、実行するモデルを管理し、プロトコルを介してのみ他者と接続します。以下のセクションでは、これらの要素を1つずつ取り上げ、それぞれがなぜそこに配置されるべきなのかを説明します。

Databricks Model Serving：エージェントクルー

内部的には、バイヤーエージェントはCrewAIを使用して構築されたスペシャリストエージェントの「クルー（グループ）」です。このクルーは3つのレベルにわたって階層的に動作し、レベル1のエージェントはレベル2のエージェントにタスクを委任することができます。これらのエージェントには、戦略を設定して予算を配分するレベル1のポートフォリオマネージャー、特定のメディアでの買い付けに特化したレベル2 of チャネルスペシャリスト、そしてオーディエンスをプランニングして買い付けを実行するレベル3の戦術担当者が含まれます。これらはDatabricks Foundation Model APIs上で動作し、タスクの複雑さに応じてClaudeモデルを使用するように構成されています。これらのエージェントの実行にDatabricks Unity AI Gatewayを使用することで、他の部分を変更することなく、各エージェントを駆動するLLMを簡単に変更できます。

Lakebase：エージェントのためのトランザクション状態管理

エージェントがデータに求めるものは2つあります。行動の根拠となるコンテキストと、行動を記録する場所です。バイヤーはブリーフを読み込み、各セラーは広告枠カタログと価格設定ルールを読み込み、成約したすべての注文を書き戻します。これは典型的なOLTPであるため、レイクハウスのすぐ隣で動作するDatabricksのサーバーレスPostgresであるLakebaseに配置しました。エージェントはトランザクションの保証を伴って状態を迅速に読み書きでき、Postgresであるため、セラーコンポーネントはカスタムデータレイヤーなしでそのまま配置できます。また、Lakebaseはサーバーレスであるため、ミリ秒単位で自動スケーリングし、突発的な需要に対応します。エージェントのアクセスは一定ではなく、バイヤーは事前にキャパシティをプロビジョニングすることなく、一度に多くのセラーに並行してアクセスできます。

ガバナンス：現在はLakebase、今後はUnity Catalogへ

現在、このデモではLakebaseのみを使用しています。実際の環境では、Lakebaseはガバナンスの効いた2つのUnity Catalogの境界の間に位置します。インプット側では、データがUnity CatalogのテーブルからLakebaseにハイドレート（取り込み）されます。これには、セラーの広告枠やMLモデル駆動の価格設定、バイヤーのキャンペーンブリーフやオーディエンス定義が含まれます。アウトプット側では、エージェントが生成したトランザクション状態（誰が何をいくらで購入したか）がレポート環境に同期されます。双方向のデータ移動は、壊れやすい手書きのETLではなく、Databricksの管理されたパイプライン上で実行されます。これにより、ガバナンスの効いたラウンドトリップが実現します。Unity Catalogはすべてのハイドレートと同期のリネージ（系統）を自動的に追跡するため、どのデータがどこに移動したかを常に追跡できます。レイクハウスは両端で信頼できる唯一の情報源（Source of Truth）であり続け、Lakebaseはエージェントが取引を行う運用上のホットサービングレイヤーとして機能します。

アイデンティティと信頼

アプリ同士は、お互いが何者であるかを確立し検証する仕組みであるOAuthを使用して相互に認証し、レジストリが各バイヤーに信頼ティアを割り当てます。そのティアによって、バイヤーが表示できる情報が決まります。未知のパブリックバイヤーは価格帯のみを取得し、取引を行うことはできません。信頼され検証されたバイヤーは正確な価格を取得し、予約することができます。バイヤーの信頼度を切り替えることで、価格帯に制限されていた同じキャンペーンを予約できるようになります。Databricksでは、このアイデンティティの仕組みは、アプリやデータアクセスがすでに動作している方法にネイティブに組み込まれています。IABのリファレンスSDKがAPIキーを必要とするのに対し、私たちはプラットフォームに組み込まれたサービスプリンシパルとOAuthを使用して、今日のベストプラクティスに従って認証を行うため、追加で構築するものは何もありません。

オブザーバビリティ

エージェントクルーはMLflowのトレースに対応しており、これはわずか1行のCrewAI自動ログフックで簡単に実装できます。これにより、すべてのエージェント実行における推論ステップ、ツール呼び出し、読み取られた価格、そして予約かパスかの決定をキャプチャできます。デモではオプションにしていますが、予算管理において自律型システムを本番運用し、デバッグし、チューニングし、信頼するためには、まさにこのように行う必要があります。

エージェントによる購買アプリの実際の動作を見る

1つのキャンペーンにおける一連の実行プロセスを見てみましょう。まず、広告主のブリーフ（概要）を送信します。このシナリオでは「Q3ブランドローンチ」とし、予算はCTVとリニアTVのメディアタイプ全体で200,000ドル、CPM（1,000回表示あたりのコスト）の上限は38ドルに設定されています。このブリーフが購買アプリに送信され、エージェントクルーが購買プロセスを開始します。

1. 予算の計画：ポートフォリオマネージャーがブリーフを読み取り、支出をチャネル間で分割し、CTVに12万ドル、リニアに8万ドルを割り当てます。

2. オーディエンスの変換：専門家が、ブリーフの自然言語によるオーディエンスを、IAB Tech Lab Audience Taxonomyに対して検証された標準セグメントにマッピングします。例えば、"sports fans"（スポーツファン）は“Sports Enthusiasts”に、"auto intenders"（自動車購入検討者）は“Auto Intenders”にマッピングされます。

3. セラーの検出：バイヤーはレジストリ内のパブリッシャー（セラーA（CTV）とセラーB（リニア））を検出します。これによりバイヤーのアイデンティティが確認され、アクセスティアが設定されます。

4. 価格の確認：各チャネルのチャネルスペシャリストが、MCPを介してセラーを探索し、オーディエンスセグメントを利用可能なプロダクトにマッチングさせ、正式な価格を読み取ります。

5. 予約またはパス：ルールは1つです。価格が38ドルの上限以下であり、プロダクトのオーディエンスが一致する場合は予約し、そうでない場合は見送ります。

今後の展望

ここでご紹介したのは、取引の中間部分、つまり取引を行うエージェントです。しかし、同じプラットフォームは、その前後のプロセス（バイヤーのブリーフ作成、セラーのパッケージ価格を設定するMLモデル、収益と支出を予測するために使用されるモデルやダッシュボードなど）を構築するのにも最適な場所です。これらは、ガバナンスが効いたデータとMLに依存する課題であり、その両方がDatabricks上にネイティブに存在しています。私たちのチームはリポジトリの更新に努めており、追加のAAMP機能がリリースされるのに合わせて、IAB Tech Labとともに進化させていく予定です。

ご自身でデプロイする

このシステムは、Databricks Automation Bundleのアクセラレータとして提供されています。リポジトリをクローンし、Databricks CLIをワークスペースに向けて、単一のコマンドを実行するだけです。

このコマンドを使用して、アプリとLakebaseインスタンスをビルドおよびデプロイし、データをシードし、レジストリを介してバイヤーとセラーを接続します。数分後には、2つのアクティブなセラーエージェント、レジストリ、およびバイヤーコンソールがすべてご自身のワークスペース内で取引を開始します。

そこからは、自由にカスタマイズしてください。独自のインベントリ、価格設定ルール、オーディエンスを入れ替えたり、Lakebaseレイヤーを実際のカタログやモデルに接続したりできます。バイヤーまたはセラーとして取引に参加し、エージェントがどのように反応するか観察してみましょう。価格を変更したり、バイヤーの信頼ティアを切り替えたり、セラーを追加したりして、交渉がどのように進むかを確認できます。これは、エージェントによるメディアの売買に合わせてカスタマイズされた、実際に動作するブループリントです。

5分間のデモをご覧いただき、ご自身のワークスペースにアクセラレータをデプロイしてください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事