従来の広告システムは、ユーザーの意図を個々の独立した単位として捉え、それに応じるように構築されています。ユーザーがオンラインで何かを検索したり閲覧したりすると、広告システムはその検索クエリやページビューをイベントとして受け取り、それに合う広告を探します。ChatGPT の広告基盤の構築では、事情が異なりました。ユーザーの意図は会話を通じて形づくられ、複数のターンにわたって変化します。広告を表示するのに適したタイミングがないこともあります。この新しいあり方に対応するため、専用の広告配信システムを構築しました。この新しい広告基盤の中核にあるのは、独自の事後学習済みフロンティア LLM です。このモデルは、検索（有力な選択肢の特定）、ランキング（ユーザーのエンゲージメント予測）、関連性の評価（広告の有用性の判定）、最終的な広告選定と価格設定のためのオークション実行を、ツール呼び出しによって行います。
変化するユーザーの目標をきめ細かく捉えるため、広告システムでは三つの重要な設計方針を採用しています。1）状態を保持する広告セッションを実装し、会話内のターン間や複数の会話にまたがって情報を記憶すること。2）ツール呼び出し型のアーキテクチャを備えた独自の事後学習済み LLM を活用し、会話の文脈とその背後にある意図を解釈して、広告を効果的に選定・ランク付け・配信すること。3）広告選定を ChatGPT の回答生成とは別の独立したサービスで実行し、広告が回答に影響しないようにして、ChatGPT の中立的な語り口を維持することです。事後学習済み LLM が広告フロー全体を統括し、ユーザーの現在のターンと会話履歴の両方に基づいて、適切なタイミングで表示する適切な広告を判断します。このような自己改善型の広告システムをゼロから立ち上げるには、かつては何年もかかりました。しかし、ChatGPT 広告は提供開始から 200 日足らずで年換算売上 10 億ドルの規模に達しました。現在では、提供開始以来 10 万を超える広告主が ChatGPT に広告を掲載しています。
従来の広告リクエストは通常、明確に定義されたイベントから始まります。ユーザーが検索クエリを送信したり、ウェブページを開いたりすると、広告システムがリクエストを受け取ります。このタイプのシステムは比較的シンプルです。広告候補を検索してランク付けし、オークションで掲載機会に適切な価格を付け、選ばれた広告をユーザーに表示します。ChatGPT では、このように明確なタイミングが自然に生まれるわけではありません。
ChatGPT で会話する人は、一つの答えを得るための検索クエリではなく、達成したい目標を持っています。旅行の計画、仕事で使うソフトウェア選び、家の家具選び、新しい趣味の習得など、その目標はさまざまです。こうしたことが、会話の一つのターンですべて完結するわけではありません。ChatGPT は多くの場合、やり取りの中でユーザーが何を重視しているかを明確にする手助けをします。
たとえば、当社のエンジニアリングチームが、レースに向けたトレーニング方法を ChatGPT に尋ねたことがあります。会話は、ランニングについての一般的な質問から始まります。数ターン後には、トレーニングに役立つシューズについて質問しています。条件が加わるたびに、会話が持つ商業的な意味は変化します。そして、このユーザー固有の文脈は、複数のセッションにまたがって変化していきます。最初のメッセージだけで動作するシステムでは、意図をまったく取り違えた検索を行い、ユーザー体験を損なったり、ユーザーの妨げになったりする可能性があります。
そのため、リクエストとレスポンスに基づく従来の広告アーキテクチャを超え、ユーザーの信頼と価値を最優先にしながら、潜在的な経済機会を見つける広告基盤をゼロから構築する必要がありました。
従来の広告システムのように、すべてのメッセージを独立したリクエストとして扱うと、チャットではいくつかのリスクが生じます。1）ユーザーの目標を単純化しすぎて誤読すること。2）本当のニーズが明らかになる前に、広告フローを早まって開始すること。3）ユーザーの目的達成を支えるのではなく、妨げる広告を表示すること。4）リクエストが変わるたびに広告フローを非効率に再実行し、ノイズと無駄なコストを生むことです。そこで、検索・ランキング・配信から成る広告システムは、個々のイベントを中心に構築するのではなく、状態を保持するセッションを維持する設計にしました。広告セッションは、掲載対象となるターンの間、継続して動作し、変化する情報を記憶・更新します。ChatGPT は、最初のリクエストの文脈を広告サーバーに送信します。広告システムは、単一のクエリに単純化された情報に頼るのではなく、やり取りの進展を追い、それに適応します。
広告選定プロセスは ChatGPT の通常の回答生成と並行して実行され、広告フローが ChatGPT の回答に影響しないようにしています。広告の絞り込みと選定は、会話を受け取り、独自の掲載資格・品質・配信の条件に従って処理する別のシステムで行います。別々のモデルとコードを使う独立したサービスという、この重要なアーキテクチャ上の境界により、ChatGPT の中核サーバーは通常の回答生成を担います。一方、広告システムは適切な広告機会があるかを独立して評価し、機会があれば別の配信プロセスでスポンサー広告の掲載を準備します。
広告の処理は、ChatGPT の回答処理と並行して実行されます。
この分離には、ユーザー体験を守るだけでなく、運用上の効果もあります。ChatGPT は広告システムに依存していません。両サービスは完全に独立しており、コンテンツ生成モデルも共有していません。そのため、広告配信システムが利用できない場合や遅延している場合でも、ChatGPT の通常の回答には影響しません。つまり、広告システムが原因で ChatGPT が停止したり、応答が遅れたりすることはありません。この分離のもう一つの利点は、広告の有用性に対して非常に高い基準を維持できることです。広告を返さないことも、想定どおりの正常な結果です。システムが広告を配信するのは、ユーザーと広告主の双方にとって明確に有益な場合だけです。
広告基盤のアーキテクチャを支えるもう一つの重要な要素が、事後学習済み LLM です。会話を解釈し、エージェントとして反復処理を行いながら広告フロー全体を実行します。検索からランキング、オークション、そして最終的な配信まで、広告システムの中核機能をツールとして呼び出します。この LLM をオーケストレーターと呼んでいます。
広告フローの最初の段階は、ユーザーの意図を理解して検索プロセスを開始することです。検索では、後から絞り込む広告候補を、意図的に幅広く、素早く集めます。会話を逐次受け取ることで検索に使える情報は豊富になりますが、曖昧さも増します。広告システムは、現在の意図と、すでに状況に合わなくなった文脈を区別する必要があるためです。オーケストレーターには、以前のメッセージへの言及を解釈し、ユーザーが仮定の話をしていることを認識する能力が求められます。また、商品やサービスへの言及をすべて購入希望と捉えてはいけません。
広告オーケストレーターは、利用可能な会話とユーザーの文脈をもとに、適切な広告を探す処理を繰り返し、その都度、どのツールをいつ呼び出すかを選びます。その根底にある目的は、会話と文脈に最も適した広告、つまりユーザーにとっての高い価値と広告主にとっての高い価値を両立する広告を見つけることです。ユーザーが広告のパーソナライズを選択した場合、オーケストレーターは過去の会話について利用可能な非センシティブ情報も考慮し、最も適した広告を探します。
広告オーケストレーターは、広告配信ツールを繰り返し呼び出して、価値のある広告を探します。
会話が進み、広告オーケストレーターが新しい情報を受け取ると、更新された文脈に基づいて一連のツール呼び出しを改めて実行し、より適した広告を探してクライアントに返すことができます。新しい広告が間に合えば、クライアントはそれを使用できます。
オーケストレーターは、常にユーザーを最優先にしながら、ユーザーと広告主の双方にとっての価値を両立するように設計されています。
広告システムは個別のツールで構成されており、オーケストレーターはそれらを繰り返し呼び出して、会話に最も適した広告を探します。大まかに言うと、オーケストレーターは会話を短いテキストに要約し、それを意味埋め込み（広告システムが検索しやすい形で意味を格納したもの）に変換します。その意味埋め込みを使って広告候補を検索し、予算やユーザー設定などの初期チェックに基づいて掲載資格のある候補を絞り込み、品質と関連性を評価します。最後にランキングを行い、チャットの回答の末尾に掲載する価値が高い広告を特定します。そのため、各広告は、掲載資格と関連性の両面で高い基準を満たして初めて掲載対象になります。
オーケストレーターの LLM はまず、会話に関連する商業的な意図を表すクエリを一つ以上準備します。その際、会話の文脈を書き換えることで、発言と一対一で対応する検索クエリの範囲を超えて商業的な可能性を広げ、意味表現を作成することがあります。オーケストレーターは複数ターンにわたる会話を検索システム向けに要約し、データベースから的を絞って広告を検索します。
ユーザーの意図を深く理解できたときにだけ広告を表示すれば、ユーザーと広告主の双方にとって、より良い広告掲載につながります。複数のクエリを使えば、意図のさまざまな側面を保持できます。たとえば旅行の計画についての会話には、交通手段、宿泊、アクティビティに関する、それぞれ異なるニーズが含まれることがあります。検索システムは、会話全体を一つの文字列に圧縮するのではなく、こうした違いを保持できます。
例として、ハイキングシューズに関する次のような会話の流れを考えてみましょう。
ヨセミテへの 2 日間の旅行では、どこを回るといい？
来週は寒いかな？
[insert brand] の新しい商品ラインは？
ユーザーは靴のブランドに関する質問をヨセミテ旅行と結び付けていませんが、広告システムでは、この会話を [ハイキング旅行に適した靴] と [旅行に適した[ブランド名]の新しい商品ライン] のような二つのクエリで表現できます。これは最初の試みにすぎないかもしれません。オーケストレーターは、広告在庫の中からユーザーにとって価値の高い広告が見つかるまで、こうした表現を繰り返し調整するように設計されています。
検索は、広告の選択肢を意図的に幅広く集めるプロセスです。候補は異なる検索戦略から取得されることがあり、その後、同じ配信条件のもとで競い合います。システムやプロダクトの異なる制約に合わせて最適化した、複数のインデックスを構築しています。たとえば、商品フィード広告用のインデックスは、最適な広告を取得する際に、肯定的・否定的な商品レビューを考慮するように設計されています。レビューが紐づいていない他の広告では、この点を考慮する必要はありません。各インデックスは、ユーザーの意図を表す埋め込みを用いた、いずれかの方式の近似最近傍（ANN）検索に最適化されています。この ANN 検索は、大規模な意味インデックスを検索するための近似アルゴリズムです。「正解」を探し求めるのではなく良い解に近づくことで、関連する候補の大部分を保持しながら、広告を非常に高速に取得します。
広告システムは、広告検索の過程で書き換えたクエリから意味埋め込みを作成し、幅広い広告候補を集めます。
フィルタリングの目的は、関連性、入札額、予算の面で掲載基準を満たさない広告候補を、すべて検討対象から除外することです。候補や設定に応じて、フィルタリングでは次のような項目を確認します。クリエイティブとキャンペーンの利用可否（キャンペーンや広告クリエイティブが有効か）、キャンペーンのターゲティング（配信を許可されているロケールなど）、ポリシー上の制限（広告掲載が可能な内容に関するコンプライアンス要件）、予算の有無（使用できる予算が残っているか）、ペーシング（今予算を使うべきか、その日の別の時間帯に使うべきか）、掲載先との適合性（どのような会話に掲載できる広告か）、広告主・キャンペーン単位の重複排除（企業間での公平な参加を確保するため、広告主ごとの広告数を適切に選ぶこと）などです。
掲載資格のチェックを通過した候補は、スコアリングの段階に進みます。ここではオーケストレーターが各種のスコアリングシステムをツールとして呼び出し、配信に関わる要素を評価します。たとえば、意味的な関連性（広告がユーザーの目標に関連しているか）、予測エンゲージメント（閲覧やクリック、広告主が望む成果につながる可能性があるか）、過去の実績（これまでユーザーに表示された際に良い成果を上げているか）などです。オーケストレーターは、オークションの前にも広告を絞り込み、関連性と安全性を確保します。これらのシステムによって、候補はオークションに参加できる少数の広告に絞り込まれますが、この時点ではまだ、最終的に配信する広告は決まりません。
オーケストレーターは、準備された候補を会話の文脈に照らして評価し、最終オークションに参加させるのに十分適切な広告候補を選びます。オーケストレーターが、配信する広告を直接決定したり、価格を設定したりするわけではありません。文脈に適した候補を選び、オークションツールの評価に委ねます。
オークションでは、最終的な配信決定に必要な処理を適用します。具体的には、参加資格の判定（関連性と価値の最低基準を満たしているか）、ペーシング（広告予算をより均等に消化するための調整）、入札額とオークション用特徴量の計算、品質を加味したランキング、価格設定、最終選定です。
オークション後に広告が配信されないケースは二つあります。どちらも ChatGPT という対話型の媒体に特有のものです。
チャットの中では広告が不適切に感じられる場合：会話自体はインテグリティモデル（広告を配信してよい場面かを判断するモデル）によって安全な掲載先と判定され、広告自体もポリシーに準拠していると判定されていても、特定の会話の文脈では広告が不適切に感じられることがあります。オーケストレーターは、こうした広告が表示されないようにします。
広告リクエストが間に合わない場合：ChatGPT モデルが回答できる状態になっても、広告を掲載する準備が整っていなければ、広告リクエストはタイムアウトし、広告は配信されません。そのため、広告システムの目標の一つは、可能な限り高速に動作することです。ChatGPT モデルの応答時間は状況に応じて変わりますが、広告の読み込みを待つためにチャットの回答を遅らせることはありません。
上記のすべてのチェックを通過すると、描画のために広告をフロントエンドに送信します。これをサーバー側での広告の配信とみなしますが、この段階でもまだユーザーに広告が表示されない可能性があります。これは意図した設計です。
ChatGPT のような対話型プロダクトでは、サーバー側で広告クリエイティブを配信しても、表示されるとは限りません。そのターンに含められるよう、時間内に広告が届く必要もあります。広告クリエイティブには、タイトル、説明、リンク先、行動喚起が含まれます。さらに、広告システムは、モデルが生成した前置き文も返します。これは、広告と会話の関連を説明する、短く中立的な紹介文です。前置き文とクリエイティブを分けることで、広告主のメッセージを保ちながら、ChatGPT の語り口を中立に維持できます。
ChatGPT のフロントエンドは、前置き文と広告クリエイティブを一つのまとまりとして受け取ります。ChatGPT の回答が完全に生成される前に届けば、フロントエンドは回答の下に、スポンサー広告であることを明示して広告を表示します。到着が間に合わなければ、そのターンでは広告を表示しません。ここに、サーバー側での広告配信と、ユーザーへの広告表示であるインプレッションの違いがあります。
落札広告の選定と配信は別々のイベントです。選定された広告は、ChatGPT が掲載を承認して表示し、配信確認が行われて初めて配信として扱われます。
広告基盤には、従来型のログ記録とデータパイプラインを採用しています。主な利点は三つあります。広告主が既存システムを当社の基盤と連携させやすくなること、レポートデータを使って戦略を改善できること、そして当社のチームがシステムの改善点を見つけられることです。こうしたレポート作成・最適化ツールに加え、高品質なモデルを導入して配信を評価し、他の広告モデルを学習させることで、強力な自己改善ループを生み出しています。
何が起きたかを細かく分析することで、広告システムの各部分を個別に理解し、改善できます。ログ処理システムは、次のような詳細な結果も記録します。
そのターンは広告掲載の対象外でした。
広告セッションは開始されましたが、検索はリクエストされませんでした。
検索で候補が返されませんでした。
候補は取得されましたが、詳細データの補完または掲載資格のチェックに失敗しました。
広告が配信され、その後ユーザーが反応しました。
こうした詳細な内訳によって、広告配信システムの各部分を個別に改善できます。広告機会の検出を改善するために必要な情報は、検索、候補の品質、オークションへの参加、配信の信頼性を改善するための情報とは異なります。
配信、広告提供、品質の各システムは、ライフサイクルの異なる部分を観測します。プライバシー保護のための制御を適用した処理によって、測定やモデルの改善に利用できる情報が決まります。
モデルによる評価の基本的な考え方は、当社で最も高性能かつ推論能力の高いモデルがシステムの結果を観察・評価し、その結果をもとに事後学習済み LLM をさらに学習させて、性能を改善するというものです。たとえば、最も高性能なモデルがフィードバックを集め、小型モデルが最大限の成果を出せるように学習させれば、オーケストレーションや検索には、より小さく効率的なモデルや、推論能力が低いモデルを使うことができます。
ユーザーのクリックや非表示操作に加え、ユーザーアンケートや広告マネージャーを通じた広告主からの直接の意見など、人からのフィードバックを集めて改善に生かしています。開発中もチームがフィードバックを受け付け、ChatGPT のユーザーと広告主の双方が何を求めているか、直接耳を傾けています。こうしたフィードバックは、モデルによる観察からのフィードバック以上に私たちの方向性を導き、素早く試行錯誤を重ねて適切なプロダクト判断にたどり着くうえで、大きな役割を果たしてきました。モデルはユーザーの意図を理解し、批判的に考えて価値あるものを届けられるかもしれません。しかし、何が心地よく適切かという感覚を育むのは人です。
1 年前には広告システムはなく、この領域の課題を検討していたのはわずか数人でした。今では、LLM ベースのオーケストレーターが広告フローを実行する堅牢な広告システムが、年換算で 10 億ドルを超える売上規模を支えています。Codex は開発力を飛躍的に高める中核的な存在でした。システムをゼロから立ち上げ、この大きな利用規模の節目に、かつてない速さで到達できたのは Codex のおかげです。当初から、Codex を活用してシステムを迅速に構築・拡張できるよう、チームと開発ワークフローを整えました。Codex が確実かつ安全にコードをリリースできるよう、ガードレールを構築しました。並行して、Codex 用のデータインフラプラグインも整備しました。これにより、インサイトの収集から、新しいプロダクト機能、品質向上、システム性能の改善といった施策の反映までのサイクルを大幅に短縮しました。
広告に関する原則に基づくシステムの境界と、LLM ベースのオーケストレーターを組み合わせることで、すべての会話を広告リクエストとして扱うことなく、役立つ広告を提供できます。今後も、ユーザーと広告主の双方にとっての価値を高めるため、より動的な広告形式の試行を続けていきます。たとえば、広告を通じてユーザーが企業と直接対話できるようにすることなどを考えています。OpenAI のモデルを基盤とし、継続的なフィードバックループを備えた自己改善型のアーキテクチャによって、関連性とパーソナライズの継続的な向上をさらに加速していきます。
