チャット画面の外までついてくるCookie — ChatGPT広告コレクター __obi を解剖する

Metaが十年前に作ったものと同じ仕組みなら、問題は仕組みそのものか、それとも仕組みが取り付けられた場所か?

導入

2026年9月20日、「ChatGPT now knows what you do on other websites via ad collector」という記事がHacker Newsに投稿され、764ポイントを集めた。書いたのはBuchodi’s Threat Intelというセキュリティ系ニュースレターである。主張は一段落に収まる。OpenAIの広告コレクター bzr.openai.com が .openai.com ドメインに __obi というCookieをセットし、その値はChatGPTを使っている間にアカウントと紐づけられる。そしてChatGPTに広告を出稿する企業が自社サイトに設置したOpenAIのピクセルが、ユーザーがそのサイトを訪れるたびに __obi をページ情報とともにOpenAIへ送り返す。

筆者は自分のスマートフォンでこの仕組みを再現し、二つの独立したキャプチャ手段で確認し、数か月にわたって観測したトラフィック(1,029のホスト名にまたがる936種類の広告主ピクセル)と突き合わせたと述べている。

Hacker Newsの最初の反応は二つに割れた。一つは、結局FacebookやGoogleが何十年もやってきたのと同じ種類のトラッキングではないかという反応であり(@Legend2440、直接の引用ではなく、コメントの要旨の要約)、もう一つは原文の一文をそのまま取り上げる反応だった(@mavsman)。「仕組みは標準的なアドテクである。前例がないのは、それをAIチャット製品で動かしていることだ。」本稿はこの二つの反応の間に立つ。技術的に新しいものはない。それなのに、なぜ多くの人が居心地の悪さを覚えるのか。そしてその居心地の悪さは、規制の言葉に翻訳できるのか。

現象分析 — 60秒のトークンと1年のCookie

原文が公開したフローは三段階である。技術的な詳細をそのまま記す。

ステップ1:ChatGPTが識別子を生成し、署名する。 chatgpt.comのクライアントが16バイトの乱数を生成し、POST /backend-api/bazaar/obi/sync-token(ログアウト時は /backend-anon/)を呼び出す。バックエンドはRS256で署名されたJWTを返す。筆者が公開したペイロードのフィールドは以下の通りである(値の一部は筆者が伏せたもの)。

{
  "iss": "chatgpt-wadi",
  "aud": "bzr.openai.com",
  "purpose": "obi_sync",
  "operation": "set",
  "consent_decision": "analytics_allowed",
  "consent_policy_version": "user_granular_consent_v1",
  "subject_type": "account_user",
  "exp": "iat + 60s"
}

これに加えて、アカウントを指す sub と識別子 obi が含まれている。つまりこのトークンはアカウントと識別子を結びつける証書であり、宛先はコレクターに限定され、60秒で失効する。筆者によれば bzr はbazaar、すなわちOpenAI社内での広告プラットフォームの呼び名であり、wadi はトークンの発行サービスである。

ステップ2:識別子がOpenAIドメインのCookieになる。 クライアントはこのJWTを bzr.openai.com/v1/obi/sync へクロスサイトでPOSTする。レスポンスヘッダは __obi Cookieを Domain=.openai.com; HttpOnly; Max-Age=31536000; SameSite=none; Secure でセットする。有効期間は1年、そして SameSite=none。MDNのドキュメントが説明する通り、SameSite=None と Secure の組み合わせは、Cookieがクロスサイトのリクエストに載って送られるために必要な設定である。JWTの obi の値とCookieの値は同一だったと筆者は書いている。

ステップ3:広告主サイトがCookieを送り返す。 広告主のページからOpenAIのホストへ向かう3種類のリクエスト、すなわちSDKスクリプトの読み込み(bzrcdn.openai.com/sdk/oaiq.min.js)、コンバージョンイベントのPOST、そしてSDKの「認証情報なし」経路で送られるPOSTのすべてに __obi が載っていた。対照群であるピクセル設定ファイルのリクエストには、Cookieヘッダ自体がなかった。

この表で筆者が最も強調するのは一行目である。SDKには認証情報を外して送るコードパスがあるが、役に立たない。ブラウザは、OpenAIのコードが一行も実行される前に、<script src> でSDKを読み込むリクエストそのものにCookieを付けるからだ。タグを読み込んだ時点で識別子は渡ってしまう。

同じリクエストで、他のOpenAI Cookieはどうだったか。oai-did と oaicom-stable-id は SameSite=Lax のためブロックされ、セッション系のCookieはドメイン不一致でブロックされた。SameSite=None で設定されたOpenAIの識別子は __obi だけだった。これが原文の小見出し「このCookieはサイトを越えるように作られている」の根拠である。

一緒に送られるもの。 原文によれば、SDKは広告主が意図的に渡す値(in)のほか、フォームフィールド(fm)、レンダリングされたページテキスト(ht)、タグマネージャーのバス(js)から本人情報を収集する。観測されたトラフィックでは、収集された本人情報が広告主提供のものを上回っていた(685件対255件)。SDKは window.dataLayer.push を自前の関数に差し替え、adobeDataLayer も読み、名前を変えたGTMレイヤーまで gtm.js のscriptタグのパラメータを解析して見つけ出す。メールアドレス、電話番号、氏名はSHA-256でハッシュ化して送られるが、国、地域、市、郵便番号は平文である。URLはクエリ文字列を除いたoriginとpathだけが送られる(観測された23,929件のうちクエリ文字列を含むものはなかった)。しかしpathは残り、筆者はコレクターに届いたpathの中に特定の疾患名、債務整理のファネル、訴訟受付フォームがあったと記している。

到達範囲。 筆者の端末では、一つの __obi の値がChewy、Wayfair、ThriftBooks、Eventbrite、HelloFresh、Coursera、SeatGeekなど12の商用サイトから13のピクセルIDのもとでOpenAIへ送信され、すべてのリクエストが202で受理された。より広いトラフィックでは、30種類の __obi の値のうち12が複数の広告主のもとで現れた。ログアウト状態も例外ではない。デコードした同期トークン932件のうち736件が account_user、196件が anonymous であり、匿名の主体も端末ごとに一つ、少なくとも27日間維持されていた。

深層分析 — 何が「標準的なアドテク」と違うのか

1. 技術は同じであり、原文もそう言っている

まず公平に指摘しておく。原文自身が「Metaは構造的に同等のものを何年も前に作っている」と書いている。ログイン済みアカウント、ピクセル発火時のサードパーティCookie、アカウントのプロファイルへ帰属されるサイト外コンバージョン。Hacker Newsでもこの点を挙げて記事自体を低く評価するコメントがあった。あるユーザーは、この記事はサードパーティCookieによるトラッキングの仕組みを長々と説明しているだけだと評した(@gruez、直接の引用ではなく、コメントの要旨の要約)。この批判は技術面では正しい。SameSite=None のCookieをピクセル経由で受け取るのは、教科書通りのサードパーティCookieトラッキングである。

しかし原文の価値は「新しい手法の発見」ではなく「具体的な配線図の公開」にある。とりわけ、広告主にはこれが見えないという点だ。筆者は、__obi が広告主のスクリプトから読めないドメインに属していると指摘する。広告主はコンバージョンピクセルを設置しただけなのに、自社の訪問者がChatGPTのアイデンティティへ解決されていることを知る手段がない。一方、ピクセルのもう一つのCookieである __obref は広告主自身のドメインにセットされ、サイトごとに値が異なるため、観測された2,860の値のうち2,828が一つの広告主のもとでしか現れなかった。つまりサイトごとに分離された計測手段は別に存在する。__obi はそれとは異なる目的、すなわちサイトを越えた紐づけのために存在していると読める。

2. 検索広告トラッキングとの違い:何と結合されるのか

Googleの検索広告トラッキングと比べると、違いがはっきりする。検索広告のトラッキングが結合するのは、おおむね「検索クエリ」である。人は検索窓に短いキーワードを入れる。一方、対話型アシスタントには文章を、文脈を、悩みを入れる。原文の表現を借りれば、「人々はこれらの製品に、SNSには載せないようなことを話す。そしてこれらの製品は、ますますユーザーの代わりに行動するようになっている。」

ここで分析を一つ加える。原文は、サーバー側での結合は観測していないと明記している(202はコレクターがイベントを受け取ったという意味にすぎない)。したがって「OpenAIが会話内容とサイト外の行動を一つのプロファイルに統合している」というのは確認された事実ではなく、設計から導かれる可能性である。ただ、その可能性の重みが検索広告とは違う。検索履歴と購買履歴が出会えば「何を買おうとしているか」が見える。会話履歴と購買履歴が出会えば「なぜ買おうとしているか」が見えうる。疾患に関するpath、債務整理のファネル、訴訟受付フォームがコレクターに届いていたという観測は、この点で意味を持つ。同じユーザーが同じテーマでアシスタントと会話していたなら、結合の産物は広告セグメントというより、事実上の身上調書に近い。

Hacker Newsでも、この文脈の違いを指摘したコメントが共感を集めた。技術自体は新しくないが、人がAIと会話するときに期待するプライバシーの水準はFacebookを眺めるときとはまったく違い、しかもFacebookは無料だがGPTはサブスクリプション料金を払って使っている、という指摘である(@1saadcodes、直接の引用ではなく、コメントの要旨の要約)。有料ユーザーであるという事実は、「無料サービスの対価としてデータを差し出す」という古い正当化を弱める。

3. 同意の設計:analyticsとmarketingの間

規制の観点で最も鋭い観察は、同意のカテゴリーである。原文によれば、OpenAIのCookieポリシーは __obi を「Analytics Cookie」(有効期間1年、chatgpt.comとopenai.com)に分類しており、その項目にある唯一のCookieである。ポリシーはanalytics Cookieを「サービスがどのように機能し、どう使われているかを理解するのに役立つ」と説明している。一方でOpenAIはanalyticsとmarketingを別々の同意選択肢(oai_consent_analytics、oai_consent_marketing)として運用しているが、筆者がデコードしたすべての同期トークンには consent_decision: analytics_allowed が入っていた。筆者の結論はこうである。analyticsを許可しmarketingを拒否したユーザーも、このCookieを受け取る。

広告プラットフォーム(bazaar)のコレクターが発行し、広告主のピクセルを通じてサイト外の行動と結びつくCookieをanalyticsに分類することは妥当なのか。これは筆者が9月14日にOpenAIのpress窓口とprivacy窓口へ送った二つの質問のうちの一つでもある。原文によれば、OpenAI Supportから返信があり、問い合わせを受け付けて社内の検討に共有するとしたが、どちらの質問にも答えなかった。

[分析] 欧州型の規制の枠組みでは、必須でないCookieについて目的ごとに同意を得ることが一般的な要件であり、同意のカテゴリーが実際の目的と食い違っているなら、それ自体が論点になりうる。ただし本稿は法的判断ではなく、原文が観測したのはAndroid版Chromeである。欧州のユーザーに同じ動作が起きるのか、どの同意画面が表示されるのかは、原文では確認されていない。

展望と示唆 — ブラウザは防ぎ、市場は広がる

ブラウザによって結果が分かれる

原文の「限界」の節は誠実である。観測環境はAndroid版Chromeだ。SafariのIntelligent Tracking PreventionはサードパーティCookieをすべてブロックし、iOS版ChromeはWebKit上で動くため、この仕組みはiOSのどのブラウザでも動作しないと筆者は書いている。デスクトップ版Chromeは未検証である。また、ChatGPTのセッションのおよそ5回に1回しか同期トークンを生成せず、モバイルWebクライアントは同期なしで広告を表示することもあった。

MDNのドキュメントによれば、Firefoxはデフォルトで有効なEnhanced Tracking ProtectionのもとでTotal Cookie Protectionを適用し、サードパーティCookieをサイトごとのCookie Jarに分離する。Safariもデフォルトで同様の保護を適用し、BraveはトラッキングCookieをデフォルトでブロックする。一方Google Chromeは、デフォルトではサードパーティCookieをブロックしない(シークレットモードやユーザーが明示的に設定した場合を除く)。Hacker Newsでも、Cookieのパーティショニングを厳格に実装したブラウザではこの懸念は事実上意味がない、というコメントがあった(@varenc、直接の引用ではなく、コメントの要旨の要約)。これに対し、現代のアドテクはCookieと無関係にブラウザフィンガープリンティングを使うので、Cookieの分離だけでは不十分だという反論が付いた(@ferro_、直接の引用ではなく、コメントの要旨の要約)。後者の主張のうち、ChatGPTがフィンガープリンティングを使っているという部分は、原文では確認されていないコメント投稿者の主張である。

まとめると、技術的な防御は存在し、その防御はブラウザ選択という形でユーザーに押し付けられている。世界で最も使われているブラウザがデフォルトでこの経路を開けているという事実こそが、この仕組みに実効性を与えている。

ピクセルはすでに広がっている

この仕組みは9月に突然現れたものではない。Hacker Newsのあるコメントがリンクした、4月17日付のAdExchangerの記事によれば、OpenAIのトラッキングピクセルはすでにChatGPT広告パイロットの一部の広告主を対象にテスト中であり、その前の週にOpenAIは広告マネージャー(ad manager)をリリースしていた。記事は、このピクセルが会員登録、注文、リード完了、サブスクリプションの作成、ページ閲覧といった行動をトラッキングするとみられると伝え、これも公式発表ではなく、誰かがOpenAIのコードを調べて見つけたものだと書いている。別のコメントは、ChatGPT広告トラッカーを設置したWebサイトの数が前月比で倍増するペースだというBloomberryのデータを引用していた(この数値は本稿では直接確認していない)。

原文の観測も同じ方向を示している。自動マッチングは、設定が判明しているピクセル881件のうち638件で有効になっており、観測されたすべてのクレジット・融資系広告主が含まれていた。この機能はOpenAIのAds Managerから制御される。パスワード、ワンタイムコード、カード番号、SSN、生年月日、病歴、診断、裁判関連のフィールドを除外するdenylistがあることも原文は記録している。また、SDKのバージョン0.1.31は氏名と地域情報まで取得していたが、8月27日に範囲が狭められた。つまり収集範囲は固定されたものではなく、バージョンごとに動いている。

示唆:アシスタントが広告プラットフォームになるとき

Hacker Newsのある長文コメントは、興味深い予測を残した。ユーザーが明示的にオプトインし、データを管理し、消去し、パーソナライズされた応答をオンオフできるなら、この種のトラッキングはむしろ製品を改善するかもしれない。しかし実際には、OpenAIはまずクリックとコンバージョンの計測体系を作り、広告主にコンバージョン率を見せ、そのうえで明示的な広告プラットフォームを構築してチャット製品を劣化させるだろう、という予測である(@jfasi、直接の引用ではなく、コメントの要旨の要約)。

この予測の前半は、すでに原文とAdExchangerの記事が示す現実と重なっている。残る問いは後半だ。広告収益がアシスタントの応答そのものに影響するのか。別のコメントは、業務用のAIには無用な文脈が混ざるべきではなく、何かを売る方向に傾いたバイアスがあってはならないと書いていた(@bcorigliano、直接の引用ではなく、コメントの要旨の要約)。現時点で原文が示したのは、計測と識別の配管までである。応答が広告に合わせて調整されているという証拠は原文にはない。しかし配管が敷かれれば、その上を何が流れるかは会社の一つの決定次第になる。

結論

__obi は新しい技術ではない。SameSite=None、1年の有効期間、広告主サイトのピクセル。この組み合わせは、Metaがずっと前に定着させたものである。原文の貢献は、その古い配管がいまAIアシスタントにつながっていることを、60秒のJWTのフィールド名まで公開して検証可能にした点にある。

違いは結合の対象にある。検索クエリではなく会話が、ログインユーザーだけでなくログアウトユーザーの端末単位の識別子が、そして広告主にさえ見えないCookieを通じて結びつきうる構造。この結合がサーバー側で実際に行われているかは、まだ観測されていない。しかし、analyticsに分類されたCookieが広告コレクターから発行されているという同意カテゴリーの食い違いは、結合の有無にかかわらず、すでに答えが必要な問いである。OpenAIは筆者の質問にまだ答えていない。

実務的に残ることは二つある。ユーザーはブラウザの選択とCookieの設定でこの経路を断つことができる。そして広告主は、自社サイトに設置したコンバージョンピクセルが訪問者をどこへつないでいるのかを改めて確認すべきである。原文の最後の一文にある通り、彼らはコンバージョンピクセルを設置しただけで、それが何をしているのかを見る手段を持っていないのだから。

出典: