OpenAI が明かす ChatGPT 広告システムの仕組み：回答の質を損なわずに的確な広告を挿入する方法

ChatGPTで広告の掲載が始まりました。旅行の計画を立てたり、ソフトウェアを選んだり、新しい趣味について相談したりしているとき、回答の下に「スポンサー（Sponsored）」と明記された商品やサービスのプロモーションが表示されることがあります。これは OpenAI のビジネスモデルの一環であり、事業者は費用を支払って ChatGPT 内に広告を出稿できます。

ChatGPT の広告システムは、こうした広告の選定と配信を担うバックエンド基盤です。会話の流れを踏まえて広告を表示する適切な機会があるかを判断し、どの広告を選ぶか、そして今回の回答の下に実際に表示できるかを判定します。

ここで当然の疑問が湧きます。「ランニングの雑談をしているだけなのに、なぜ靴を買いたいかどうかがわかるのか？」「事業者がお金を払っているなら、ChatGPT は回答の中でスポンサーのブランドをひいきするのではないか？」「広告の選定を待つために、回答の表示が待たされることはないのか？」

OpenAI はこのシステムのエンジニアリング設計を公開しました。広告が複数ターンの対話を通じてどのようにユーザーのニーズを理解し、そして回答生成プロセスとどのように分かれて動作しているのかが明らかにされています。

なぜ1通ごとのメッセージを単体の広告リクエストとして処理できないのか？

検索連動型広告には明確な起点があります。ユーザーが検索キーワードを入力し、システムがそれに基づいて候補を検索・ランキング・入札し、広告を表示します。しかし ChatGPT では、「レースに出場する準備をしたい」という話題から始まり、何往復かやり取りした後にようやくトレーニングシューズの話題が出ることもあります。最初のランニングに関する相談は、自動的にギアの購入意欲を意味するわけではありません。

OpenAI のエンジニアリングチームが挙げているのもまさにこの例です。最初は一般的なランニングの質問から始まり、徐々にトレーニングに適した靴の話題へと移っていきます。目的や条件、好みが会話の中で補足されていくにつれ、広告システムはその瞬間のニーズを再判断する必要があり、最初のメッセージだけを対話全体の代表として扱い続けるわけにはいきません。

もし毎回のやり取りを単独の独立したクエリとして扱ってしまうと、広告の表示タイミングが早すぎたり、システムが同じような処理を無駄に繰り返したりしてしまいます。そこで OpenAI は、ステートフル（状態保持型）な広告セッションを導入しました。すでに出てきた関連情報を記録しておき、新しいコンテキストを受け取るたびにそれを更新していく仕組みであり、毎回ゼロから推測し直すことはありません。

ここでの「状態（ステート）」とは、システムの手元で常に更新されるニーズの記録簿のようなものです。以前に何を話したか、現在どんな条件が追加されたか、どの情報がすでに古くなったかを管理します。情報を記憶できると同時に、その情報が今も当てはまるかどうかを判断できなければなりません。会話のついでにブランド名を出しただけのことや、仮定の話をしただけのやり取りを、そのまま購入リクエストと受け取るべきではないのです。

2系統の独立：「文脈理解」と「回答への不干渉」はなぜ両立できるのか？

広告が会話に合わせて商品を探せるとなると、逆に ChatGPT の回答がスポンサー企業をひいきするようになるのではないかという懸念が生じます。OpenAI が公開したアプローチは、2つの処理経路を分けることです。回答は ChatGPT の中核サービスが生成し、広告は独立した別のサービスが選定します。両者は異なるモデルとコードベースを使用しており、コンテンツ生成モデルを共有することはありません。

この図で見落としやすいのが破線の存在です。回答が独立しているからといって、広告システムが会話を読み取らないわけではありません。広告側は利用可能なセッションのコンテキストを参照し、適切な商業機会があるかどうかを判断します。選定された広告は独立したスポンサー枠として表示され、通常の自然な回答文の中に書き込まれることはありません。

処理の分離は、広告サービスの応答が遅れたり利用できなくなったりしても、回答は通常通り生成され、広告の結果を待つ必要がないことも意味します。システムが「広告なし」と判定して返すことも、正常な成功結果の一つです。OpenAI の設計思想では、ユーザーと広告主の双方に価値がある場合にのみ広告が配信されます。これは2つのサービスパイプラインをどのように分けているかを説明するものではありますが、アーキテクチャの説明それ自体が、あらゆる状況においてプロダクトに一切の偏り（バイアス）が生じないことを保証・証明するわけではありません。

大規模言語モデルがオーケストレーターとなり、ツールが検索と入札を担う

OpenAI は既存の大規模言語モデルに対し、広告タスクに特化した追加の訓練を行いました。この工程を「後学習（ポストトレーニング）」と呼びます。訓練を受けたモデルは、ここでオーケストレーターとしての役割を果たします。その動作はツール呼び出しが可能な Agent（エージェント）に似ています。まず会話を理解し、その結果に応じて次にどのツールを呼び出すかを選択します。新しい情報がもたらされれば、再度検索を実行したり、候補を再評価したりすることもできます。

たとえば、前半で旅行ルートを尋ね、後半であるブランドの新作について質問した場合、オーケストレーターは両者に関連性があるかどうかを判断します。モデルはこうした理解と思考のプロセスを束ねる役割を担い、検索、予算チェック、スコアリング、入札などの実処理は対応する専用ツールが実行します。

ツールチェーン内の各ステップは、それぞれ異なる問いに答えます。検索ツールはまず関連のありそうな広告を探し出し、適格性ツールはそれらの候補が配信可能かどうかをチェックします。スコアリングツールは関連性と想定されるインタラクションを評価し、入札ツールが最終的に誰を選ぶかとその価格を決定します。

大規模言語モデルは言語の理解とこれらのツールの呼び出し管理を担当しており、最終的な落札者を直接決めたり、自ら価格を定めたりすることはありません。入札の段階において、モデルの役割は入札ツールに対して適切な候補を推薦（ノミネート）することに留まります。

意図の書き換えとマルチパス検索：すべての発言を購入指示とはみなさない

ユーザーが複数ターンの対話を重ねる中で、オーケストレーターはまず複雑な文脈を、広告インデックスの検索に適した表現形式へと書き換える必要があります。

公式に公開されたヨセミテ国立公園の2日間の旅行の例を見てみましょう。

• 第 1 ターン：ユーザーがヨセミテへの2日間の旅行の観光ルートを質問する；
• 第 2 ターン：ユーザーが来週の現地はかなり冷え込むかどうかを重ねて尋ねる；
• 第 3 ターン：ユーザーがあるアウトドアブランドに最近新しい製品ラインが出ているかを何気なく尋ねる。

この例において、ユーザーは靴を買いたいとは明言していません。オーケストレーターは、旅程やブランドの新作といった手がかりをつなぎ合わせ、ハイキングや外出に関連する検索方向を試行するのであって、3ターンの会話をそのまま検索キーワードとして連結するわけではありません。生成される検索クエリの例としては次のようなものがあります。

• [ハイキング・トレッキングに適したフットウェア]
• [該当ブランドのアウトドア向け新作コレクション]

これらのテキストクエリは、続いて意味ベクトル（セマンティックベクトル）へとエンコードされます。意味を数値の並びとして表現することで、広告データベースの中から意味合いの近いコンテンツを探し出せるようになります。「ハイキング用の靴」という表現が広告の文面と一字一句一致していなくても、意味的に関連する候補を見つけ出すことができます。

検索には近似最近傍探索（ANN）が用いられます。すべての広告をしらみつぶしに調べて唯一の最適解を探すのではなく、大まかに近い選択肢を高速に見つけ出し、関連する候補を幅広く残す手法です。システム内には、一般的な広告や個別商品広告などの用途に応じて複数のインデックスが用意されており、商品広告インデックスでは商品の好意的なレビューや批判的なレビューも考慮要素に含まれます。

候補プールが形成された後、3段階の異なる判定を通過する必要があります。

1. 参加資格があるか（配信適格性）： 広告やキャンペーンが現在も有効か、配信地域が合致しているか、ポリシー要件を満たしているか、予算に残額があるか、現時点でその予算を消化すべきタイミングか、この種の対話プレースメントに表示可能か、そして同一の広告主やキャンペーンが重複して候補を占有しないよう重複排除を行うかどうかが審査されます。予算ペーシング（消化ペース制御）は、不適切なタイミングで予算が集中的に消化されてしまうのを防ぐためのものです。
2. 現在の目的にどれだけ合致しているか（関連性と予測スコア）： スコアリングツールが意味的な関連性を評価し、ユーザーが閲覧・クリックするか、あるいは購入や会員登録といった広告主が期待する「コンバージョン」に至るかを予測します。過去の実績パフォーマンスも参照されます。関連性があり安全と認められた候補だけが、次の入札準備へと進むことができます。
3. 最終的に誰を選び、価格はいくらか（入札と価格決定）： オーケストレーターによる候補のノミネートを受けた後、入札ツールが最低限の関連性・価値基準の適用、予算ペーシング、品質調整を加味したランキング、価格決定、そして最終選定を実行します。入札額だけでなく品質も決定に関与しますが、原文では具体的なオークションの計算式は公開されていません。

したがって、「ハイキングシューズの広告が見つかった」というのは最初のステップに過ぎません。配信条件を満たし、その瞬間のニーズに関連しており、オークションを勝ち抜いて初めて表示の機会を得ることができます。

なぜオークションで勝っても実際に表示されるとは限らないのか？時間との競争と表示確認通知

ある広告が入札で勝利を収めたとしても、今回の回答の下に表示されないことがあります。対話型プロダクトにおいては、さらに2つの問題をクリアしなければなりません。「このタイミングで広告を出すのが適切かどうか」、そして「今回の回答の生成に広告が間に合うかどうか」です。

原文では、広告パッケージがサーバーからフロントエンドへ送信されることを「サーバーサイド配信（server-side delivery）」と呼んでいますが、「サーバーから送信されたこと」と「ユーザーの目に実際に触れたこと」は依然として異なる2つのフェーズです。

回答が完了するまでに間に合わなければ、そのターンでは表示されない

ChatGPT が回答を生成するのにかかる時間は動的（ケースバイケース）であり、広告の全処理はその時間枠（ウィンドウ）の中で完了しなければなりません。フロントエンドは、回答の生成が完全に完了する前に広告パッケージを受信できた場合にのみ、そのターンの回答下に広告を表示します。到着が遅すぎた場合は表示されません。回答の生成が広告を待つために一時停止することはありません。

広告がポリシーに準拠していても、現在の文脈に合わない場合がある

ポリシー準拠（コンプライアンス）が扱うのは、その広告と対話が最低限の配信基準を満たしているかどうかです。しかし、それらを実際に組み合わせたとき、やはり不自然または不適切に感じられることがあります。たとえ広告が入札で勝っていたとしても、オーケストレーターは現在の文脈にそぐわないと判断すれば、広告の表示を遮断（ブロック）することができます。これは入札が行われた後に実施される、もう一つのセーフティネットです。

広告はどこに表示され、システムは配信完了をどのように確認するのか？

広告システムが返却するパッケージには、見出し、説明文、リンク先 URL、アクションボタンといった広告クリエイティブのほか、その広告と今回の会話との関係性を説明する、モデルが生成した短く中立的な「前置き（導入文）」も含まれています。前置きと広告クリエイティブを明確に分けることで、広告主が意図した訴求内容をそのまま保ちつつ、事業者側の宣伝口調が ChatGPT 自身の回答文に紛れ込むのを防いでいます。

フロントエンドは広告を回答の下部に配置し、スポンサー表示を明確に付与します。公式のシーケンス図によると、表示端末側での描画確認が行われた後、ChatGPT から広告システムへと配信確認（受領通知）が送り返されて初めて、システムは「配信成功」を記録します。オークションでの勝利、サーバーからの送信、端末での実際の表示、そして受領通知の受信は、それぞれ区別して捉える必要があります。なお、これらの配信ステップ自体は、どのような課金方式が採用されているかを説明するものではありません。

データの流れ、プライバシー管理、そしてフィードバックによる進化

広告システムを持続的に運用するには客観的なデータ測定が不可欠ですが、対話型プロダクトにとって最も重要なコア資産は、ユーザーからのプライバシーに対する信頼です。

プライバシーの境界線とパーソナライズ設定

広告システムは基本的に現在の対話コンテキストを使用します。ユーザーが広告のパーソナライズを有効にしている場合に限り、オーケストレーターは過去の会話の中から利用可能なセンシティブではない情報も考慮に入れます。これが過去情報を利用する上での明確な前提条件であり、内部で個々のデータがどのように保存、隔離、あるいは消去されているかについて、この記述からそれ以上を推し量ることはできません。

OpenAI は広告原則の中で、広告主がユーザーのプライベートな会話内容を閲覧することはできず、ユーザーデータが広告主に売却されることもないと約束しています。ユーザーはいつでもパーソナライズを無効化でき、広告用に保持されたデータを削除することも可能です。広告システムが文脈を利用できることと、広告主が生のチャットログを直接入手できることとは、全く別の事象です。

システムはどのプロセスを改善すべきかをどうやって判断するのか？

広告処理のパイプラインは、様々な段階で中断することもあれば、最後までスムーズに完走することもあります。「このターンはそもそも広告に適していなかった」「セッションを開始したが検索を行わなかった」「検索したが候補が見つからなかった」「候補が適格性審査を通らなかった」、あるいは「広告が実際に表示され、その後にユーザーからの反応があった」などです。ログがこれらの結果をフェーズごとに分けて記録しているからこそ、機会認識、検索品質、候補フィルタリング、配信信頼性のうち、どのステップを改善すべきかを正確に判断できます。

OpenAI はさらに、より高度な推論能力を持つモデルを用いてシステム全体の出力を評価し、そのフィードバックによって広告モデルを訓練しています。これにより、オンラインのすべての工程に最も高性能なモデルを投入することなく、オーケストレーションや検索といった処理を、より小さなモデルや、効率のよいモデル、推論コストの低いモデルに担わせることが可能になります。

ただし、AI モデルによる評価が唯一の判断基準ではありません。ユーザーによるクリックや非表示操作、アンケート調査、そして広告主が Ads Manager を通じて寄せる直接のフィードバックも、システムの改善を後押しします。OpenAI によると、こうした生身の人間のフィードバックがプロダクトの進化の方向に与える影響は、モデルによる観察フィードバックを上回るといいます。関連性の判定はモデルが支援できても、広告の出方が適切で心地よいものであるかどうかは、最終的に人間の感覚に耳を傾ける必要があるからです。

規模データと進化の現在地

OpenAI は以前、ChatGPT Ads のローンチから200日未満で年換算ランレート（Annualized Run Rate）が10億ドルに達したことを公表しました。また、今回のエンジニアリング記事では、サービス開始以来、累計で10万社を超える広告主が出稿した実績があることも明らかにされています。

年換算ランレートとは、ある一定期間の売上ペースを1年間の規模に引き延ばして換算した指標であり、実際にすでに1年分の10億ドルを受け取ったことを意味するわけではありません。また、累計で出稿したことのある広告主数も、現在アクティブに出稿し続けている広告主の数とは異なります。これらはいずれも OpenAI 自身が公表した数値ですが、このシステムがすでに本格的な実ビジネスの基盤として稼働していることを物語っています。

開発プロセス自体にも AI が活用されました。開発チームは初期段階から Codex をワークフローに組み込み、コードガードレールやデータ基盤向けプラグインと連携させることで、問題の検知、洞察の獲得、そして改善の実装に至るサイクルを短縮しました。

OpenAI は今後、ユーザーが広告を通じて直接事業者と対話できるような、より動的な広告フォーマットの模索も進めたいとしています。これらは将来の展望です。今回の技術公開においてとりわけ注目に値するのは、刻々と変化するニーズの理解をモデルに委ね、検索・スコアリング・入札といった具体的な処理は専用ツールに任せ、さらにサービスの独立性と厳格な表示条件によって広告の出現タイミングを適切に統制するという設計思想です。