8月17日、Search Engine Landが「Inside ChatGPT's retrieval stack: The index, cache, and pages it actually reads」と題した記事を公開した。この記事では、ChatGPTが回答を生成する際に実際にどのようなページを取得・参照しているかを、独自調査によって明らかにした内部構造について詳しく紹介されている。

RESONEOのチームが今年7月に実施した調査では、ChatGPTの回答1,200件・検索結果88,000件・個別ページ26,900件を収集・解析した。その結果、ChatGPTが回答を「根拠づける」仕組みには3つの層があることが判明した。

1. ディスカバリーインデックス（ページを見つける）
2. リーディングキャッシュ（取得済みページのフルコピーを保持）
3. ライブオープン（少数ページをリアルタイムで取得）

各層にはそれぞれ固有のルールと鮮度・盲点がある。

フリーユーザーと有料ユーザーで「見ているウェブが違う」

最も実用的な発見は、ChatGPTの動作モードによって参照するウェブのコーパスが根本的に異なるという点だ。

同じ質問をしても、フリーの「Think」モードと有料の「Thinking」モードでは参照元の構成が逆転する。

• フリーThink：取得URLの74.7%がlabrador（OpenAI独自インデックス）、Googleスクレイピングはわずか3.1%
• 有料Thinking：75.3%がスクレイピングによるGoogle結果、labradorは24.7%

ソース量はほぼ同じでも（フリーThinkで平均35.3 URL、有料ThinkingのMedium努力レベルで34.5 URL）、中身のコーパスはほぼ逆になっている。Googleで上位表示されることは有料Thinkingには有効だが、フリーThinkの取得セットに入る保証にはならない。

重要な前提として：ChatGPTユーザーの90%以上がフリー層にいる。フリーユーザーはデフォルトで「Instant」モードを使い、そこではlabradorがほぼ唯一の情報源になる。labradorはOpenAI独自のウェブインデックスで、**BingとはURL重複率わずか1.5%**しかない別物だ。スニペットの文字数制限もBingの75文字に対しlabradorは無制限で、289文字のタイトルも観測された。

labradorのスニペットは「H1周辺の200文字だけ」

なお、labradorとはOpenAIが独自に運用するウェブクロール・インデックスパイプラインの名称で、一般的なWeb検索エンジンとは別系統のインフラだ。後述するbrightはGoogleスクレイピングを利用するパイプラインを指す。いずれも元記事の調査によって識別された内部呼称である。

Instantモードでは、モデルが受け取るのはURL・タイトル・約200文字のスニペットのみで、ページ本文は一切開かれない（Instantの93%でページ開封ゼロ）。

このスニペットの仕様が問題だ。

• H1タグを大文字で先頭に置き、その周辺の可視テキストを拾う
• カテゴリラベル、画像のalt属性、著者名、公開日、目次など、意図しない要素が混入する
• メタディスクリプションは完全に無視される
• クエリに依存せず固定。価格を聞かれても歴史を聞かれても同じスニペットが返る

「スニペットが目次100%・コンテンツ0%だったケースも観測した」と記事は述べる。クエリ非依存の固定スニペットは、現代の検索技術からは約20年退行したような仕様だが、2026年現在のChatGPTのベースを支えている。

対照的に、Googleスクレイピングベースのbrightパイプラインはタイトルを60文字でカットし、メタディスクリプションを3回に1回使うなど、通常のGoogle検索結果に近い挙動を示す。

全ユーザーで共有される「リーディングキャッシュ」の盲点

ChatGPTはフェッチ済みページのフルコピーをMarkdown変換して保存するキャッシュを持ち、これは全ユーザー・全ティア間で共有される。ベルリンのフリーユーザーが質問しても、先週オハイオの有料ユーザーが参照したキャッシュが返ってくる。

このキャッシュの仕様を、OncrawlのSEOテクニカルコンサルタントであるJérôme Salomon氏とともに調査した結果、いくつかの特性が明らかになった。

• 新鮮とみなされる期間は約30分（stale-while-revalidate方式）
• 人気のないページは90日以上経過したコピーが供給され続ける事例を確認
• Cache-Control: no-storeヘッダー・noindexいずれも無視される
• JSON-LDなどの構造化データはMarkdown変換時に剥ぎ取られ、モデルには届かない
• JavaScriptは実行されないため、クライアントサイドレンダリングのコンテンツは不可視
• ページが4MBを超えると、切り詰めではなくリクエスト自体が400エラーで拒否される

ファネルの実態と「UTMが追えない読み」

調査コーパスでの引用ファネルは次の通りだ。

• ソースサイドバーに表示されたURL：61,332
• 引用の主要ソースになったURL：5,032
• 実際にページが開かれたURL：759（すべてThinkingモード）

開かれたページの引用率は**74%、取得だけされて開かれなかったページは7%**。

さらに、utm_source=chatgpt.comパラメータはユーザー向けのクリックリンクにのみ付与される。Thinkingモードでモデルが自律的に開いたページには、このUTMが付かない。 引用率74%の「本当に読まれたページ」がアナリティクスから抜け落ちる構造になっている。サーバーログのChatGPT-Userユーザーエージェントを別途監視する必要がある。

未解明：「検索せず記憶から引用」問題

記事は最後に、解明できなかった現象を正直に開示している。

Instantモードでは、スニペットのないURL（RedditやarXivを除く）の引用率が14.9%と、スニペットありのURL（8.2%）を上回っている。また、どの検索結果にも対応しないリンクが引用される事例が確認されており、モデルが学習時の重みに焼き込まれたパラメトリックメモリから直接URLを生成している可能性があるという。これらのURLはutm_source=chatgpt.comが付いた状態で出力されており、検索結果と見分けがつかない。

詳細はChatGPTの検索スタックの内側：インデックス、キャッシュ、実際に読んでいるページを参照していただきたい。