広告主の意図を、配信条件と原稿につなぐ課題

広告主は「誰に届けたいか」「何を伝えたいか」を考えます。広告主の意図を配信条件や広告原稿へどう反映するかが、設計上の課題です。広告主はSpotifyのAds Manager（広告配信の管理画面）で、目的、ターゲティング（広告を届ける対象の設定）、予算・日程、クリエイティブ（広告用の制作素材）を段階ごとに入力します。

担当技術者の公開講演では、原稿制作の段階で前工程の文脈が失われ、広告全体を踏まえた制作につながりにくい課題が説明されました。[1]

曖昧な意図と機械で照合できる条件を分ける

フォームは項目を集め、API（別のシステムからデータや機能を呼び出す接続口）は利用できる情報を取得します。Spotify Ads APIからは、利用可能な地域や興味カテゴリを参照できます。AIエージェント（言語モデルで意図を解釈し、役割に沿って処理を進める仕組み）は、自然な言葉に含まれる意図を解釈します。システムは、地域ID（地域を特定する値）、年齢区分、データ形式など、規則で照合できる条件をプログラムで検証します。[2]

担当扱う内容
モデルを使うエージェント曖昧な言葉から意図を解釈し、用途に合わせたツールを選ぶ
Ads APIなどのツールエージェントが使える地域や興味カテゴリを取得する
コードID、年齢区分、形式、業務ルールを検証する

講演では、モデルが意図に合う操作を選べるよう、開発チームがツールの説明と入力形式を用意する設計も示されています。[8]

当初の単一エージェントには、原稿生成、ポリシー確認、オーディエンス解決（広告条件に合う配信対象を特定する処理）が集まっていました。このエージェントは、検索、検証、出力形式、トーンやロケール（言語や地域の設定）まで担っていました。講演者は、指示を変更すると単一エージェントの挙動が不安定になり、問題の原因を切り分けにくかったと説明しています。そこでSpotifyは、役割ごとに分割を進めました。

精度向上を示す比較実験は公表されていません。[3, 11]

役割分担を支える共通文脈・ツール・所有者

Spotifyの講演では、役割ごとに処理を分け、広告制作に必要な文脈を後続の処理へ引き継ぐ設計が説明されました。講演者は、ブランドトーンやCTA、オーディエンス情報を共有session stateに保存すると説明しました。ブランドトーンは広告文に反映する語り口です。CTAは広告を聞いた人に行動を促す呼びかけです。session stateは複数の処理で共有する情報の保存領域です。sessionとは、一連のやり取りを扱う単位です。後続の処理は、そこに蓄積された情報を利用します。[7]

開発チームは、エージェントが呼び出すツールに、用途に合った説明とschema（入力項目と形式の定義）も用意します。これにより、検索やID照会など、意図に沿った操作を選びやすくします。構造化されたエラー情報は、エージェントが回復方法を判断する材料になります。[8]

Spotifyでは、エージェント、コードのpackage（関連コードのまとまり）、担当チームを対応させます。原稿生成は広告制作チームが所有します。オーディエンス解決は、オーディエンスを管理するチームが所有します。Bazelはコードのビルドに使うツールです。visibility設定により、許可されていないpackageへの依存をビルド時に止めます。[5]

この境界はコードの依存関係を制約します。Bazelの公式説明も、visibilityをビルド時の依存制約として説明しています。[5]

後輩共通の文脈を持たせるなら、結局ひとつの大きな担当に戻りませんか？

先輩共有するのは広告の条件やブランド情報だよ。誰が何を処理するかは役割と担当チームで分けている。

後輩その分け方で、障害の原因を追いやすくなる可能性があるんですね。ただ、講演で定量評価された効果ではないですよね。

先輩担当とpackageが対応し、レビューや監視、通知の宛先にも結び付く設計だね。visibilityはビルド時の依存関係を扱うよ。

後輩実行中のアクセスや顧客データの隔離まで、この設定で担保されるかは別に確認が要りそうです。

先輩その通り。講演で示されたvisibilityの範囲は、ビルド時の依存制約だよ。

原稿制作の処理と、利用者・運用チームへの影響

講演で紹介された原稿制作では、まず内部のmoderation classifier（広告内容を事前判定する分類器）が入力を確認します。入力が拒否対象の場合、システムは大規模言語モデル（LLM。大量の文章を学習し、文章を生成・処理するモデル）を呼ぶ前に処理を終えます。入力が審査を通過した場合、システムは原稿生成エージェントと広告ポリシー確認エージェントを並列に実行します。

本稿では、二つのエージェントを並列に実行する点を確認しています。生成中の完成原稿を確認エージェントが読むデータフローまでは、この記述から推定しません。[9]

講演時点で本番稼働していたのは、原稿生成とポリシー確認です。Audience Recommendation/Resolverはpilot（試験運用）でした。

講演では、router（条件に応じて処理先を選ぶ仕組み）と逐次処理（前段の結果を後段へ渡す方式）が紹介されています。fan-out/fan-inは、処理を複数に分けて実行し、結果を合流させる方式です。generator-critic loopは、生成と評価を繰り返す方式です。これらはエンジニア向けの試作パターンや説明例として紹介されています。[4]

本稿の設計案では、各分岐が他の分岐の処理内容を参照しない前提に置きます。必要なキャンペーン条件を各分岐に渡し、合流後に照合する設計が必要になる、というのは本稿の実装上の提案です。逐次処理では前段の結果を後段へ渡せますが、各工程の処理時間が積み重なります。前段の失敗を後段へどう伝えるかは、エラー処理の設計で確認する項目です。本稿では、並列化やエージェントの追加ごとに、速度と精度を評価する方法を提案します。[15]

広告主はAds Managerに指示を入力して原稿を作成し、声やトーン、音楽を選べます。利用者は生成結果を調整し、再生成しながら制作を進めます。内部構成の説明と、広告主が利用できる機能の範囲は分けて捉える必要があります。[6]

処理経路と品質をどう確かめ、何が分かるか

traceとは、最終出力に至る処理経路の記録です。Spotifyの講演では、処理時間、ツール呼び出し、moderation、入力と出力などを記録し、本番traceの再生や調査に使う設計が説明されました。traceは、問題が起きた工程を追跡するための記録です。[12]

評価は三つの層に分かれます。tool trajectory（ツールの使用経路）は、必要なツールを適切な順序で使ったかを確認します。同じ入力に同じ判定を返すコード検査では、schema、地域ID（Geo ID）、年齢区分などの条件を確認します。LLM judge（別の言語モデルによる評価役）は、トーン、ブランド適合性、意味の一貫性を判定します。[10, 13]

本稿では、LLM judgeで問題候補を検出し、人が確認した不具合をコードの判定条件に反映する運用を提案します。

講演者は、本番の呼び出しごとにtraceを残し、live evaluation（本番トラフィックの一部を対象にした評価）を実行すると説明しました。講演では、評価対象の割合を変更できる仕組みが説明されました。新しいエージェントでは、高めの割合から評価を始める運用です。開発者は、本番トラフィックを使わない評価を繰り返します。さらに、評価項目一式を毎晩実行します。

merge時のCI gate（変更の統合時に継続的インテグレーションで行う判定）を避ける理由として、ビルドごとにLLM呼び出しが発生する点が挙げられました。これらは、Spotifyの運用例として紹介されています。[14]

講演では評価の仕組みが説明されましたが、正解率、LLM judgeと人間の一致率、単一エージェントとの精度比較、違反の見逃し率や誤検知率は公表されていません。安全策として、広告内容のmoderationとブランドセーフティ（ブランドの安全性を損なう広告の確認）が説明されています。広告制作AIの品質を評価する際は、仕組みの説明と実測された成果を分けて読む必要があります。[13, 16]