ChatGPT広告の計測ピクセルをめぐる解析が話題――公式仕様では同意の既定が「あり」、日本でも提供済み

ChatGPT Adsの計測タグを解析したとする記事が9月20日に公開され、Hacker Newsで700ポイントを超えた。見出しは断定調だが、著者は末尾の「限界」の節で、中心にある結び付けを自分は観測していないと書いている。

一方、OpenAIの計測ピクセル（広告が自社サイト上のどの行動につながったかを測るタグ）の仕様は公式ドキュメントとして公開されており、誰でも確かめられる。ChatGPT Adsは8月11日に日本でも提供が始まった。海外の出来事ではなく、自社サイトに計測タグを置くかどうかという判断として目の前に来ている。

本記事では、公式に確認できる事実と第三者の主張を分けたうえで、何がどこへ送られるのか・既定の設定はどうなっているのか・日本の法令で何が効くのかを整理した。

解析記事の経緯と、公式に確かめられる範囲

話題の起点は、OpenAIの発表ではなく第三者の解析記事だ。記事が報告している内容と、公式ドキュメントに書かれている内容は最初に切り分ける必要がある。ここでは、解析記事の反響と著者が認めた限界・ChatGPT広告の日本での提供状況を確認する。

解析記事の著者は「結合は観測していない」と書いている

解析記事を出したのは、Buchodi’s Threat Intelという個人運営のニュースレターだ。公開は協定世界時の9月20日15時17分で、日本時間では21日の未明に当たる。著者本人がHacker Newsへ投稿し、21日午前9時30分の時点で717ポイント・382件のコメントが付いていた。

ただし記事の末尾には「限界」の節がある。そこには「The join is not observed.（結合は観測していない）」とあり、著者は、コレクタが識別子付きのイベントを受理したことは分かるが、OpenAIがサーバー側でアカウントに結び付ける場面は見ていないと説明した。

査読も独立した検証もなく、観測に使った生データも公開されていない。見出しの断定と、著者が認めた限界には開きがある。

ChatGPT広告は8月11日に日本でも提供が始まっている

計測ピクセル（measurement pixel）は、広告が自社サイト上のどの行動につながったかを測るために設置する、ブラウザ側のタグを指す。OpenAIは自社の仕様を、ChatGPT内の広告に帰属させられるWebサイト上のイベントを計測するためのブラウザSDKだと定義した。

そのChatGPT Adsは、日本でも提供が始まっている。公式ページ「Testing ads in ChatGPT」の8月11日更新に、ChatGPT広告をイギリス・メキシコ・ブラジル・日本・韓国で提供開始したと明記された。

当メディアは9月1日の記事で、Ads Managerのセルフサービス提供国の一覧（9月1日時点・47カ国）に日本が入っていることを確認している。日本の広告主が現在どこまで出稿・課金できるのかは、今回は確認していない。

公式ドキュメントが示す「送られるもの」

ここからは解析記事を離れ、公式ドキュメントだけで何が分かるかを見ていく。コンバージョン（購入・申し込み・資料請求のように、広告主が成果と定める行動）の計測でピクセルが何を送るかは、仕様として公開されている。ここでは、広告主が渡す項目・SDKが自動で付ける値とCookie・データの保持期間を確認する。

ハッシュが必須の5項目と平文で送る4項目

公式ドキュメントは、広告主が明示的に渡す user オブジェクトの項目を9つ挙げた。ハッシュ化が必須なのはメールアドレス・電話番号・外部ID・名・姓の5項目で、いずれもSHA-256でハッシュ化した値を渡す。生のメールアドレス・電話番号・外部ID・名・姓は送ってはならないと明記されている。

残る4項目の扱いは異なる。国コード・市区・地域・郵便番号にはハッシュ化の指定がなく、平文のまま送る設計だ。市区は最大128文字、郵便番号は英数字・空白・ハイフンで最大32文字という上限も、公式に決められている。

この9項目はいずれも任意で、渡すかどうかは広告主が決める。つまり、平文で届く地理情報をどこまで渡すかは、広告主側の実装しだいだ。

SDKが自動で付ける値と広告主のWebサイトに置くCookie

広告主が何も渡さない場合でも、SDKが自動で付ける値がある。公式の説明では、ランディングページのURLから oppref という識別子を取得し、ファーストパーティCookie __oppref に保存して以後のページビューで再利用する。

さらに現在のページのオリジンを source_url として付加し、タイムスタンプを付けたうえで近接した呼び出しをまとめて送るという。

広告主のWebサイトに置かれるCookieは2つだ。__oppref は書き込みから30日、__obref は作成から365日。後者はそのWebサイト用にランダム生成したブラウザ参照値で、どちらも oaiq("consent", false) を呼ぶと削除される。

コンバージョンデータの保持期間は公式に数値がない

保持期間については、公式ドキュメントに数値が見当たらない。計測ピクセルのページは、Cookieの有効期限がアトリビューションウィンドウやコンバージョンデータの保持とは別だと書きながら、その保持が何日なのかを示していない。

数値が公開されているのはレポートを参照できる期間のほうで、時間別の配信レポートは約30日、時間別以外は直近365日とされる。送ったデータがOpenAI側にどれだけ残るのかは読み取れない。

Cookieの期間も確定した値ではない。公式は、30日と365日はピクセルが要求する寿命であり、ブラウザの制限や利用者によるCookie削除で短くなりうると補足した。

同意の既定は「あり」で自動収集も既定で動く

仕様そのものより実務に効くのは、既定値がどちらへ倒れているかだ。同意も顧客情報の収集も、広告主が何もしなければ有効な側で動き出す。ここでは、同意の初期値・自動アドバンストマッチング・広告主に課された義務を確認する。

オプトインにするには初期化の前に1行書く必要がある

公式ドキュメントは、同意の初期値をはっきり書いている。

「The Pixel initializes consent to true by default unless you set it to false or the Pixel finds a stored denial.（ピクセルは、あなたが false を設定するか、保存済みの拒否を検出しない限り、既定では同意を true として初期化する）」という記述だ。

同意が false のあいだ、計測イベントの送信は止まる。true に戻せば以後のイベントは許可されるが、止まっていた分は再送されない。オプトイン（同意を得てから計測を始める運用）にするなら、初期化の前に1行が要る。公式のサンプルは次の順序だ。

oaiq("consent", false);
oaiq("init", { pixelId: "<YOUR-PIXEL-ID>" });
// 利用者が計測への同意を与えた後に呼ぶ
oaiq("consent", true);

自動アドバンストマッチングは取得源が書かれていない

アドバンストマッチングは、顧客情報をハッシュ化して送り、広告への接触とWebサイト上の行動を同じ人物のものとして結び付ける精度を上げる仕組みを指す。その自動版について公式は、有効にするとOpenAIピクセルがWebサイトから対応する顧客情報を自動的に検出すると説明した。

検出した情報はブラウザ内でハッシュ化され、生の顧客情報は送らないともいう。一方で、どこから・どの項目を検出するのかは書かれていない。「対応する顧客情報」の定義も、公式ドキュメントに見当たらなかった。

有効になる条件はAPIリファレンスにある。コンバージョン設定のエンドポイントで作成したWebピクセルは自動的に自動アドバンストマッチングを使用する、と記されている。Ads Managerの画面から作ったピクセルが同じ扱いになるかどうかは、公式ドキュメントからは判断できない。

通知と同意の責任は広告主にあると契約に書かれている

通知や同意を用意する責任は、広告主の側に置かれた。Conversion Termsの第2条(a)は、コンバージョンデータを収集・利用・共有しOpenAIへ提供するために必要な通知を全て行い、権利・同意・許可・法的根拠を取得して維持していることを、広告主に表明保証させている。

Ad Tools Termsは「禁止データ」も定めた。児童向けサービスに関する情報・適用法上のセンシティブ情報・健康状態を識別しうる情報が対象で、列挙されたカテゴリには人種や民族的出自・宗教的信条・経済的困窮・政治的意見・障害の有無が並ぶ。

Conversion Termsの第5条は、制限付き処理を除き、広告主とOpenAIがそれぞれ独立したデータ管理者として行動すると規定した。

解析が指摘したことと、確かめられていないこと

解析記事の記述は、公式で裏が取れる部分と取れない部分が混在している。混ぜて読むと、公式が認めていない挙動まで確定した事実に見えてしまう。ここでは、公式に載っている事項・裏付けのない主張・文書の分断に分けて見ていく。

送信先ドメインとハッシュの扱いは公式に載っている

送信先のドメインは、公式のCSP設定表に載っている。SDKは bzrcdn.openai.com から読み込み、イベントは bzr.openai.com へ送るという記載で、第三者が見つけた隠しドメインではない。ハッシュ化する5項目と平文の4項目の別も、公式仕様のとおりだ。

__obi というCookieも、OpenAIのクッキーポリシーに記載がある。分類はAnalytics（分析）、有効期間は1年、設定ドメインは chatgpt.com と openai.com だ。ただし記載はこの3点にとどまり、広告計測に使う旨も、広告主のWebサイトから送られる旨も書かれていない。

中心的な主張には公式の裏付けがない

解析記事の中心にある主張は、広告主のWebサイトからOpenAIへ送られるリクエストに __obi が同送される、というものだ。この挙動について公式ドキュメントに記載はなく、著者がそう報告しているだけで、独立した検証は取れていない。

集計値も同じ扱いになる。著者は、Webサイト側から自動で拾われた識別情報が広告主の渡した分を685イベント対255イベント（約2.7倍）で上回ったと報告しているが、検証方法の詳細は記事に記載がなく、独立した再現はできない。

SDKが window.dataLayer を自前の関数に置き換えるという記述・ログアウト状態でも動くという報告・1つの識別子が12の商用サイトから送られたという観測も、公式の裏付けを欠く。

著者自身も範囲を限っている。観測はChrome for Androidに限られ、iOSのブラウザでは動作しないとし、ChatGPTのセッションのおよそ5回に1回しか同期が起きなかったと書いた。

文書の分断が残り、公式の反応も確認できない

__obi をめぐっては、文書が分かれた状態が残る。クッキーポリシーには載っているが、計測ピクセルのドキュメントには一度も出てこない。逆に、ピクセルが広告主のWebサイトに置く __oppref と __obref は、クッキーポリシーに載っていなかった。

その行はAnalyticsカテゴリで唯一のエントリで、記載からは広告の計測に関わる識別子かどうかまで読み取れない。

OpenAIの反応も確認できなかった。9月21日の時点で、OpenAIの公式サイトと広告のドキュメント、クッキーポリシーを見た範囲では、この解析記事への公式コメント・反論・ドキュメントの更新は見当たらない。著者は9月14日にOpenAIへ2点を問い合わせたが、受領と社内共有の連絡があっただけで、実質的な回答は得られなかったと報告している。

日本の会社が自社サイトに入れる前に決めること

日本の法令では、同じ会社の同じドメインでも、ページによって扱いが分かれる。プライバシー一般の議論ではなく、公式のFAQとガイドラインに沿って線を引ける部分がある。ここでは、電気通信事業法の外部送信規律・個人情報保護法・設置の前に残る3つの論点を見ていく。

総務省は一般の事業会社の自社サイトを対象外と整理している

総務省は外部送信規律のFAQで、一般の事業会社の自社サイトを対象外と整理した。

小売業者がWebサイトを開設して商品を販売する場合は、本来業務の遂行の手段として電気通信を用いているに過ぎず、自己の需要のために電気通信サービスを提供しているため「電気通信事業」に該当せず、外部送信規律も適用されないという回答だ（問1-12）。

実店舗を持たない場合も扱いは変わらず（問1-13）、サービスの案内ページ（問1-18）と来店予約のページ（問1-19）も対象外とされた。自社の商品やサービスを売るためにサイトを持っているだけなら、計測タグを置いてもこの規律は及ばない、という整理になる。

同じサイトでも、ニュース配信のページは対象になる

対象かどうかは、同じサイトの中で分かれる。問2-12は、ニュース配信を行っているページについて、各種情報のオンライン提供サービスとして施行規則第4号に該当し、外部送信規律への対応が必要だと答えた。同じWebサイトの会社案内のページは対象にならない。

自社サイトで記事や各種情報を配信しているBtoB企業には、この線引きが効いてくる。ただしFAQが答えているのは個々の事例で、自社のどのページが第4号に当たるかは、提供しているサービスとページ構成に即して確かめる必要がある。なお同FAQは、外部送信規律がターゲティング広告自体を規制するものではないとも記した（問1-6）。

個人情報保護法の側は別の論点として残る

個人情報保護委員会のガイドライン（通則編）は、個人関連情報（生存する個人に関する情報のうち、個人情報・仮名加工情報・匿名加工情報のいずれにも当たらないもの）の該当事例の1つ目に「Cookie等の端末識別子を通じて収集された、ある個人のウェブサイトの閲覧履歴」を挙げている。計測タグが扱う情報そのものだ。

提供先の第三者が、受け取った個人関連情報をID等を介して自社の個人データへ付加することが想定される場合には、法第31条により、提供元（タグを置いた事業者）に本人同意の確認義務が生じる。

外国にある第三者への提供では要件がもう1段増え、同等の水準にあると認められる制度を持つ国として指定されているのはEUと英国で、米国は含まれない。自社の設置が該当するかどうかは、弁護士・専門家に確認する論点になる。

設置の前に社内で決まっていない3点

公式ドキュメントと日本の法令を突き合わせると、設置の前に社内で決まっていない事項は3つだ。

1. 同意の既定をどちらにするか：既定は同意ありで初期化される。オプトインで運用するなら、初期化の前に oaiq("consent", false) を書く実装が必要になる。
2. 自動アドバンストマッチングを使うか：公式が取得源を説明していない以上、確かめられるのは自社サイト側だけだ。どのフォームに何の入力欄があり、ページに何が表示されているかの棚卸しが前提だ。
3. どのページを対象に含めるか：ニュース配信や各種情報の提供に当たるページがサイト内にあるかを、ページ単位で洗い出す。

この3点の答えは、いずれも公式ドキュメントと自社の実装を見れば出せる。解析記事が可視化したのは、判断の材料が計測ピクセルのドキュメントとクッキーポリシーに分かれて置かれている状態そのものだった。