ChatGPTは実際にどのように出典を選んでいるのか（ネットワークトラフィック分析）

• ログイン済みのProアカウント1つで数日間に収集した約1,240件の出典レコードを分析し、最終回答だけでは見えない出典パイプライン、クエリ分類、検索語、実行モデルをブラウザのJSONから確認
• すべてのWeb結果には、serp、labrador、bright、oxylabsのいずれかである**result_source**が付与され、商用・ショッピング・金融・天気クエリではBright Data系のbrightが主に観察された
• クエリは6つのturn_use_caseのいずれかに分類され、textならWeb検索なしで学習データだけを使って回答する。新しさを求めた10件のクエリのうち3件も検索されなかったが、単一アカウントから得た限定的な結果である
• Thinkingモデルは、1つの製品比較を約15〜40件のサブクエリに拡張し、公式価格ページをsite:で検索したり価格を推定したりしたうえで、$や€のような文字列を探して検証する
• 取得・引用・ブランド言及は互いに異なり、公式ページの価格や仕様がJavaScriptや画像に隠れていると、G2のような第三者出典が代わりに引用されることがある。事実はプレーンなHTMLで提供し、評価はレビュー、Reddit、比較コンテンツからも確保する必要がある

---

調査範囲と結果を解釈する基準

• 1人のログイン済みChatGPT Proアカウントで数日間に数十件の検索を実行し、約1,240件の出典レコードを収集した
  • クエリの大半はSaaSと技術分野に偏っている
  • 母集団全体の出典頻度を測定した研究ではなく、ブラウザに渡される内部フィールドと挙動を観察した記録である
• 大規模な可視性調査は、数千件のプロンプトの最終回答からブランド露出頻度を集計するが、内部処理過程は結果から推論する必要がある
• 今回の分析では、ネットワーク応答JSONからエンジン内部ラベルを直接確認した
  • 結果ごとのresult_source
  • クエリごとのturn_use_case
  • 検索プロバイダー名
  • ChatGPTが生成した検索語
  • 実際に実行されたモデル
• 結果の信頼レベルは2種類に分けて見る必要がある
  • 構造的事実: フィールドと値の存在、textクエリでWeb検索が省略されること、Thinkingモデルによる多数のsite:検索と価格検証など、実際のトラフィックで繰り返し確認された構造
  • 頻度の観察: brightの比率、Redditの引用順位、YouTubeが引用されないことなど、単一アカウントと限られたクエリ選択によって変わり得る数値や順位
• Redditは本文テキストを取得できる一方、YouTube検索結果では主にメタデータだけを受け取るという機械的な違いが、観察の方向性を裏づけている。ただし正確な比率を知るには、より大きな標本が必要である

パケットキャプチャではなくブラウザHTTP検査

• Wiresharkのパケットだけではクエリと回答を読めない理由は、実際のメッセージ本文がTLSで暗号化されているためである
  • 宛先ホスト名とIP、ChatGPTアプリがTCPではなくQUICベースのHTTP/3を使っているというメタデータは見える
  • QUICの最初のパケットは仕様で定義された固定キーで難読化されるため、ツールはそれを解いてClientHelloに含まれる暗号化されていないサーバー名を表示できる
  • その後のリクエスト・レスポンス本文は保護されたペイロード内に残り、読むことはできない
• クエリ、回答、メタデータを含むJSONは、復号後のブラウザDevToolsのNetworkパネルで確認する必要がある
• 自動化の過程では2つの問題が発生した
  • クリーンな自動化Chromeで別エンジンを動かすと、数回のクエリ後にCloudflareの人間確認画面が繰り返し表示されたため、実セッションのあるChromeに切り替えた
  • ChatGPTの回答はページ読み込み時に開かれる長時間接続を通じてストリーミングされるため、セッション途中で設置したフックでは最初からキャプチャできなかった

出典ごとに付くresult_source

• DevToolsでPreserve logを有効にしてレスポンスを検索すると、ChatGPTが取得したすべてのWeb結果に**result_source**が付いている
• Mark Williams-Cookはこの値のうち3つを共有しており、Metehanも残りの値をすでに発見していた可能性がある
• 観察された値は4つである
  • serp: オープンWebの基本レイヤーで、YahooやStreetInsiderのようなニュースで主に見られる
  • labrador: Reuters、The Guardian、WSJ、FT、Wikipedia、arXivのような既存出版社の許可リストと見られ、スニペットは約1,080文字まで提供される
  • bright: 商用Webスクレイピング企業Bright Dataを指し、ショッピング、金融、天気、地域クエリで目立つ
  • oxylabs: 競合スクレイピング企業Oxylabsを指し、地域メディアと一部のオープンWeb結果に偏っている
• labradorにはOpenAIとコンテンツ契約を結んだ出版社が複数含まれており、ライセンスレイヤーのように見えるが、トラフィックだけで契約関係を確認することはできない
• brightとoxylabsについても契約や支払いの有無は分からない。ただし、オープンWebの取得が両者を経由しており、各結果をどちらが取得したかはフィールドで確認できる
• 収集サンプルでは、brightが最も多くの取得を担っていた
  • Reuters、WSJ、Wikipedia、TechRadarはlabrador
  • Reddit、Forbes、rtingsはbright
  • Khaleej Times、Gulf Newsのような湾岸地域メディアはoxylabs
• ドバイの天気クエリでは、1つの回答内でも役割が分かれていた
  • metoffice.gov.uk、accuweather.com、timeanddate.comはbright
  • khaleejtimes.com、gulfnews.com、whatson.aeはoxylabs
• 実際にアクセス可能なスクレイピングレイヤーに露出するには、事実と数値をプレーンなHTMLに置き、スクリプト、PDF、画像の背後に隠さない必要がある
• アクセスしにくい出版社レイヤーだけに依存するのではなく、第三者報道、PR、ブランド言及、リンク、Redditを通じて、スクレイパーが読むページにも含まれる必要がある

Webをまったく検索しないtextクエリ

• ChatGPTは検索前に質問を**turn_use_case**に分類し、観察された値は6つである
  • instant search
  • shopping
  • text
  • local
  • thinking
  • image generation
• textに分類されると、Web検索を実行せず学習データだけで回答する
  • 「パンクしたタイヤはどう交換するのか」
  • 「ソート済みの2つのリストをマージするPython関数を書いてほしい」
  • 「この文を4つの言語に翻訳してほしい」
• 新しさと安全性が重要な「2型糖尿病の最新治療ガイドライン」もtextに分類され、Web検索なしで処理された
• 意図的に最新情報を求めた10件の質問のうち、3件が検索なしで処理されたが、限定的なテスト結果であるため一般的な比率とは見なせない
• 分類はテーマだけでなくクエリの文言によっても変わる
  • 「近くの最高のコーヒー」はlocalパイプラインに切り替わる
  • 「買うべき最高の4Kテレビ」はshoppingを有効にする
  • 「レビュー付きの最高の4Kテレビ」は一般検索にとどまる
  • 数学の質問はthinkingの推論モデルに渡る
  • 「今週のTesla株価」はinstant searchにとどまる
• ページを制作する前に、ターゲットクエリが実際にWebを検索するか確認する必要がある
  • 使い方や定義のクエリがtextとして処理されると、現在のページ品質に関係なく検索結果に入れない
  • こうしたクエリでブランドが現れるには、長期的に権威を築き、Common Crawlのようなクローラーがサイトを見られるようにして、将来の学習データに含まれる可能性を作る必要がある

1つの質問を数十件の検索に拡張する方法

• 会話全体をChatGPT自体のAPIから取得すると、モデルが実行したファンアウトクエリを見ることができる
  • 高速モデルは概ね、書き換えられた検索語を1つだけ実行する
  • Thinkingモデルは製品比較の質問1つから、複雑さに応じて約15〜40件のサブクエリを生成する
• 比較過程では複数の検索パターンが続く
  • ベンダーの価格ページを直接site:検索する
  • 価格を先に推定してから、その金額が正しいか検索する
  • プロンプトになかったScrunch AIのようなツールを調査中に発見し、比較範囲を広げる
  • 新たに見つけたツールの価格まで連鎖的に確認する
• 検索結果を取得するだけでなく、ブラウジングツールの**find、open、clickコマンド**をサーバー側で実行する
  • $、€、99、Agencyのような文字列を直接探す
  • ユーザー画面を操作するエージェントではなく、サーバー側ツールがページ結果を探索する
• 「keyword insights pricing」クエリでは、site:keywordinsights.ai/pricingを実行し、「Starter $58, Pro $145, Advanced $299」のような値を推定した後、HTML内の通貨記号を探して確認する
• 価格と重要な数値は画像ではなくHTMLテキストで提供すべきであり、JavaScriptトグルや動的データ読み込みは避けるべきである
• 人間が入力した文だけを狙うのではなく、モデルが整理して実行する検索語やsite:yourdomain.com/pricing形式の直接検査でも情報を見つけられるようにする必要がある

取得・引用・言及はそれぞれ別の結果

• 出典には3つの独立した状態がある
  • 取得（Fetched）: ページをモデルの文脈に入れるが読者には見えず、result_sourceオブジェクトで確認される
  • 引用（Cited）: 特定の文の後にクリック可能な出典としてリンクされる
  • 言及（Mentioned）: 回答にブランド名やサイトチップが出るが、その主張の出典ではない
• 限定的な技術・商用クエリのサンプルでは、RedditとYouTubeがそれぞれ278回と201回取得された
  • Redditは11回引用された
  • YouTubeは一度も引用されなかった
• YouTube検索結果では動画の文字起こしよりメタデータを取得する一方、Redditスレッドはページに本文テキストがあるため、特定の文に出典を紐づけやすかった
• 外部の大規模分析でも同じ方向性が見られる
  • Ahrefsは140万件のChatGPTプロンプトで、Redditの引用率1.93%、YouTubeの引用率0.51%を確認した
  • Profoundも両サービス間で同じ差を確認した
• 小規模サンプルではRedditが最も多く引用された単一ドメインであり、その次の引用はrtings、TechRadarのようなレビューサイトとベンダーページに分散した
• ベンダーページは自社の価格と仕様の出典として引用される
  • Zoho、Semrush、VPN事業者が自社情報を裏づける根拠としてリンクされた
  • どの製品が最も良いかという評価には、主に第三者ページが引用される
• 引用は回答全体ではなく特定の文に結合されるため、トピックの関連性だけでは不十分で、正確な主張1つを最もよく裏づける必要がある
• 結果はドメイン単位で重複排除されるため、同じサイトの薄いページ20件が1つにまとめられることがある
• ファンアウト検索語ごとに低品質ページを大量生成するより、主張ごとに強いページを1つ作るほうが有利である
• 自社に関する評価的な主張は自社ページではなく、第三者レビュー、Reddit、比較コンテンツから根拠を得ており、テキストは動画より直接引用されやすい

公式ページを読めないときの出典切り替え

• ブラウザに渡されるトラフィックでは、ドメイン権威スコア、信頼重み、ランキング公式のような隠れたランキングスコアは確認できない
  • 関連ロジックはOpenAIサーバーに残っている
  • ブラウザデータだけで「ChatGPTのランキング要因」を断定して販売する根拠はない
• 保存されたThinkingモデルの推論には、出典を選ぶ過程が文章として残っている
  • 価格や仕様のような事実は公式ページを優先する
  • Ahrefs比較では、公式ページのLite $129、Standard $249、Advanced $449を確認し、より新しい価格ページを引用対象として選んだ
• ProfoundとPeecでは価格が検索結果に直接表示されず、JavaScriptで読み込まれていた可能性が記録された
• 公式ページをパースできない場合、モデルはG2のような第三者出典へ切り替える
  • 公式価格を確認しようとしたが、ページ内で見つけられなかった
  • その結果、自社の数値が別サイトのページを根拠に引用される
• 価格と製品仕様はJavaScriptで読み込んだり画像に入れたりせず、クロール可能なテキストで提供すべきである
• 読みやすい価格ページは自社の事実が直接引用される可能性を高めるが、推薦や評価は別途、レビュー、Reddit、率直な比較コンテンツで確保する必要がある

パーソナライズ・ローカル検索と確認できない領域

• ある出典が別の出典より選ばれた理由は、モデルが保存した自己記述以外ではサーバー側ロジックに属するため確認できない
• パーソナライズはすべてのクエリではなく、一部の関連クエリに選択的に適用される
  • ユーザーの過去作業と重なるクエリでpersonal_sources: ["convo_search", "gmail", "files"]が現れる
  • 調査した3つの会話のうち、ユーザー履歴と一致した1つで、過去の会話が一般的な「最高のツール」回答に使われた
• 一部の回答は外部から最適化できない個人データで構成されるため、ユーザーごとに結果が変わり、可視性スコアも揺らぎ得る
• ローカル検索には**local_results_limitの値が2**に設定されている
  • 近くの最高のコーヒーを尋ねると、上位10件ではなく2店だけが返る
  • ローカル検索では上位2件に入れなければ回答に現れない
• shoppingパイプラインは1回のクエリしか観察しておらず、別の調査者が1回のクエリで見た結果と正面から衝突しているため、現時点では構成方式を確定できない
• 構造は約1,240件のレコードで繰り返し観察されたが、SaaS・技術中心の小規模な商用クエリから出た比率については、複数業界を対象により大規模な検証が必要である
• システムは毎週変わり得るため、構造は維持されても数値は動くスナップショットとして見るべきである

自分で確認する方法と拡張機能

• 追加権限なしに、自分のブラウザで基本パイプラインを確認できる
  • ChatGPTでCmd+Option+Iを押してDevToolsを開く
  • NetworkでPreserve logを有効にする
  • クエリを実行した後、Cmd+Option+Fでレスポンス内のresult_sourceを検索する
• ファンアウト、引用、推論まで見るには、Consoleでallow pastingを一度入力し、Web検索を行った会話の/backend-api/conversation/データを読める
• 提供されたスクリプトは現在セッションのアクセストークンで自分の会話データだけを読み取り、出典ドメインとパイプラインを表形式で出力する
  • techradar.comとwhathifi.comはlabrador
  • soundguys.comとrtings.comはbright
  • khaleejtimes.comはoxylabs
  • streetinsider.comはserp
• 収集フィールドを変えれば、検索語、引用、保存された推論も同じ方法で取り出せる
• FanoutFoxはこのプロセスを自動化した無料のChrome拡張機能である
  • 出典別のresult_sourceパイプラインを表示する
  • 取得・引用・言及の状態を区別する
  • 1つの質問から生成されたすべてのファンアウトクエリと、site:・価格確認検索を表示する
  • データはブラウザの外に出ない
  • Chrome Web Storeからインストールでき、Part 2で追加分析を見られる
• Olivier de Segonzacの無料拡張機能もローカルセッションからデータを読み取り、Excelにエクスポートする
  • turn_use_caseを表示し、検索前にshopping、local、textのどの分類へ切り替わるかを確認できる
  • 引用トークンから、製品、検索結果、ニュース、画像の参照タイプ比率を分離する
  • 会話ごとのresult_source構成をチャートで表示する
  • Chrome Web Storeと更新説明で確認できる

検索エンジン最適化とは異なる設計原理

• 限定的なサンプルでは、従来の助言のうちReddit、リスト型コンテンツ、レビューサイトの影響が概ね確認された
• 良いコンテンツであっても、モデルが実際に読める部分にしか効果はなく、読めなかった事実は別サイトから取得される可能性がある
• ChatGPTは自社ページからパース可能な事実を読み、他者のページから評価を取得し、クエリが検索対象に分類された場合にだけこの過程を実行する
• 検索エンジン順位だけを狙うのではなく、検索実行の有無、HTMLのパース可能性、主張ごとの引用適合性、第三者評価の出典をあわせて設計する必要がある