AI検索への掲載とAI学習は同じではありません。OpenAI・Google・Anthropicの2026年9月公式仕様から、検索、学習、ユーザー取得、Geminiのグラウンディングまで整理します。
目次(10)
AI検索や生成AIについて調べていると、「AIにサイトを読ませる」「AI検索に出す」「AI学習を許可する」といった言葉が、ほとんど同じ意味で使われることがあります。
でも、サイトを運営する側から見ると、この3つは本当に同じなのでしょうか。
たとえば、ChatGPT検索には出てほしいけれど、将来のモデル学習には使われたくない。通常のGoogle検索には出したいけれど、Gemini向けの一部利用は制限したい。
こうした設定はできるのか気になって、2026年9月25日時点のOpenAI、Google、Anthropicの公式資料を見比べてみました。
結論から言うと、AIに「読まれる」は1種類ではありません。
先に結論:検索・学習・ユーザー起点取得は別々に制御されている
主要なAIサービスを見ると、少なくとも次の用途は分けて考えた方がよさそうです。
| 用途 | 何のために読むか | 例 |
|---|---|---|
| 学習用クロール | 将来のモデル開発・改善に使う可能性のあるWeb情報を集める | GPTBot、ClaudeBot |
| AI検索・索引用クロール | 現在の検索・回答の関連性を高める | OAI-SearchBot、Claude-SearchBot |
| ユーザー起点の取得 | ユーザーの質問に答えるため、その場でページを取得する | Claude-User |
| 通常の検索クロール | 従来のWeb検索へ掲載するために収集する | Googlebot |
| Google検索内の生成AI表示 | AI Overviews・AI Mode等へリンク/根拠を出す | Search Consoleの生成AI設定 |
つまり、AI検索に表示されることと、将来のモデル学習に使われることは同じスイッチではありません。
OpenAIでは検索向けの OAI-SearchBot と、将来の学習利用を制御する GPTBot が分かれています。さらに、ユーザーの操作に応じてページへアクセスする ChatGPT-User も別に定義されています。Anthropicではさらに、学習候補収集・検索・ユーザー起点取得の3種類を公開しています。Googleはさらに、通常検索・検索内の生成AI表示・生成AIモデルのトレーニングを別の仕組みで制御できるようになっています。
この違いを知らずに「AI botを全部拒否する」「AIに読ませたいから全部許可する」と設定すると、意図と違う状態になる可能性があります。
3社を並べると「何を制御しているか」が見えやすい
| 提供元 | 検索・現在の回答 | 将来のモデル開発 | ユーザー起点取得 | 主な制御 |
|---|---|---|---|---|
| OpenAI | OAI-SearchBot | GPTBot | ChatGPT-User | robots.txt / noindex |
| Anthropic | Claude-SearchBot | ClaudeBot | Claude-User | robots.txt |
| Googlebot + Search Console生成AI設定 | Google-Extendedの対象利用 | Googleのユーザートリガー型fetcher群 | robots.txt / Search Console / noindex |
この表で重要なのは、会社ごとに名前や仕組みが違っても、検索・学習・ユーザー起点取得が同じ概念ではないことです。
特にGoogleは、通常検索、Google検索内の生成AI表示、Gemini系モデルの学習・一部グラウンディング利用で制御面が分かれています。
OpenAIでは「ChatGPT検索」と「将来の学習」を分けて考えられる
OpenAIのパブリッシャー向けFAQでは、ChatGPT検索の要約やスニペットへコンテンツを含めたい場合、OAI-SearchBot をブロックしないよう案内しています。
一方、将来のトレーニングから除外したいサイトやページでは、GPTBot を拒否するよう説明しています。
参考:OpenAI「Overview of OpenAI Crawlers」
参考:OpenAI「Publishers and Developers - FAQ」
OAI-SearchBotを許可し、GPTBotを拒否する設定もできる
例えば、
User-agent: OAI-SearchBot
Allow: /
User-agent: GPTBot
Disallow: /
という設定なら、「ChatGPT検索で発見・引用される可能性は残しつつ、GPTBotによる将来の学習用クロールは拒否する」という方針になります。
これは、検索への露出と学習オプトアウトを別々に考えられることを意味します。
ChatGPT-Userは検索用クローラーではない
OpenAIの現行クローラー資料では、ChatGPT-User はChatGPTやCustom GPTsで、ユーザーの操作をきっかけにWebページへアクセスするためのUser-Agentとして説明されています。
OAI-SearchBotのように自動でWeb全体を巡回して検索掲載可否を決めるbotではなく、Searchへの掲載管理にも使われません。ユーザー起点のアクセスであるため、OpenAIはrobots.txtのルールが適用されない場合があるとも説明しています。
この違いは、OAI-SearchBot を拒否すれば「ChatGPTから自分のURLへ一切アクセスされなくなる」とは限らないことを意味します。
検索への掲載を管理する対象はOAI-SearchBot、学習用途のクロール意思表示はGPTBot、ユーザー起点取得はChatGPT-User、と分けて考える方が正確です。
robots.txt変更はChatGPT検索へ即時反映されるとは限らない
OpenAIは、robots.txtの変更後、ChatGPT検索のシステムが調整されるまで約24時間かかる場合があると案内しています。
そのため設定変更直後に検索結果を確認し、「拒否したのにまだ出る」「許可したのにすぐ出ない」と判断しない方がよいです。
robots.txtで拒否しても、URLそのものが必ず消えるわけではない
OpenAIのFAQにはもう一つ重要な注意があります。
OAI-SearchBotがクロールできないページでも、第三者の検索プロバイダーなどからURLを取得し、関連性のシグナルがある場合には、ChatGPT Atlasでリンクとページタイトルだけが表示されることがあると説明されています。
完全に検索結果へ出したくない場合には noindex が必要です。ただし、クローラーがそのメタタグを読むにはページをクロールできる必要があります。
ここから分かるのは、
- robots.txt:クロール方針
- noindex:インデックス・検索表示の方針
- 認証・アクセス制御:そもそも公開しない
が別物だということです。
robots.txtはアクセス制御ではありません。
ChatGPT検索からの流入はutm_sourceで確認できる
OpenAIの現行FAQでは、ChatGPT検索から外部サイトへ送るURLに utm_source=chatgpt.com を自動付与すると案内しています。
そのため、OAI-SearchBotを許可するかどうかだけでなく、許可した後に実際にChatGPTから流入が発生しているかをGoogle Analytics等で確認できます。
AI検索施策を行う場合も、「許可した」だけで終わらず、参照流入を計測する方が実運用としては重要です。
Anthropicは、同じ「AIが読む」を3種類に分けている
Anthropicの公式ヘルプは、この違いをさらに明確にしています。
2026年9月25日にAnthropicの現行ヘルプを再確認すると、3種類のbotが引き続き公開されています。
| bot | 主な用途 |
|---|---|
| ClaudeBot | モデルの有用性・安全性向上のため、将来のトレーニングに利用される可能性があるWebコンテンツを収集 |
| Claude-User | Claude利用者の質問に応じてWebページを取得 |
| Claude-SearchBot | 検索結果の関連性・精度向上のためにWebを巡回 |
参考:Anthropic「Does Anthropic crawl data from the web, and how can site owners block the crawler?」
ClaudeBotは「将来の学習候補」を集めるbot
Anthropicは、ClaudeBotを制限すると、そのサイトの将来の素材をAIモデルの学習データセットから除外する意思表示になると説明しています。
ここはOpenAIのGPTBotと近い役割です。
Claude-SearchBotは検索品質のために巡回する
Claude-SearchBotは、検索結果の関連性・精度を高めるためにオンラインコンテンツを分析します。
これを拒否すると、Anthropicは検索最適化のためにそのコンテンツを索引できなくなり、検索結果での可視性や精度が下がる可能性があると説明しています。
Claude-Userは「その場でユーザーが読ませる」ためのアクセス
一番興味深いのが Claude-User です。
これは、ユーザーがClaudeに質問したとき、その回答のためにWebページへアクセスする用途です。
つまり、
- 定期的に巡回して将来のモデル開発へ使う
- 検索品質のために索引する
- 今このユーザーの質問に答えるためページを取りに行く
まで分かれています。
サイト運営側も、
学習には使わせたくないが、検索からは見つけてほしい
ユーザーが直接URLを渡した場合は読めるようにしたい
といった中間の判断を持てるわけです。
Googleは2026年8月末から「検索内AI」と「AI学習」をさらに分けて制御できる
GoogleはOpenAIやAnthropicとは少し違い、通常検索、検索内の生成AI機能、AIモデルのトレーニングで制御手段が分かれています。
2026年8月31日から、Search Consoleの検索の生成AI設定が世界中のサイトへ展開されました。ここでは、サイトのリンクやコンテンツをAI Overviews、AI Mode、Google Discoverの生成AI機能へ含めるか、除外するかを管理できます。
参考:Google Search Console「検索の生成 AI 設定」
設定変更の反映にも時間差がある
Googleは、Search Consoleで生成AI設定を変更した後、通常は数日以内に対象機能へ反映され、設定が有効になってから1〜2日以内に除外されることが多いと案内しています。
ただし、キャッシュやシステム全体への伝播によって、さらに時間がかかる場合があります。こちらも変更直後の1回の確認だけで成否を判断しない方が安全です。
検索内AIから外しても、通常検索のランキング設定ではない
Googleは、この設定が通常のGoogle検索のランキングや掲載可否のシグナルとして使われるものではないと説明しています。
つまり2026年9月現在は、
- 通常のGoogle検索には掲載する
- AI Overviews / AI Mode等には出さない
という選択をSearch Consoleから行えます。
AI検索への掲載と、モデル学習の制御も別
Search Consoleの生成AI設定は、GoogleのAIトレーニングには影響しません。Googleは、検索の生成AI機能で回答を生成するモデルのトレーニングを制限したい場合は Google-Extended を使うよう案内しています。
ただし、Google-Extended の対象はトレーニングだけではありません。Googleの現行クローラー資料では、将来のGeminiモデルのトレーニングに加えて、Gemini AppsやVertex AIでGoogle検索インデックスを使って回答をグラウンディングする用途も制御対象と説明されています。
Google-Extended は通常のGooglebotとは別のHTTP User-Agentではなく、robots.txtで利用目的を制御するためのプロダクトトークンです。Google検索への登録やランキングシグナルには影響しません。
したがってGoogleでは、少なくとも次を分けて考える必要があります。
| 目的 | 主な制御 |
|---|---|
| 通常検索に出す・出さない | Googlebot / noindex等 |
| AI Overviews・AI Mode等へ含める | Search Consoleの検索の生成AI設定 |
| Geminiモデルのトレーニング・Gemini Apps/Vertex AIの一部グラウンディング利用を制限 | Google-Extended |
これは記事執筆時点で特に大きく変わった部分です。以前はAI Overviewsを通常の検索向けコントロール中心で説明する必要がありましたが、現在はSearch Consoleに専用の設定が追加されています。
生成AIでの露出もSearch Consoleで別に確認できる
同じく2026年8月31日から、Search Consoleの生成AIパフォーマンスレポートが世界展開されました。
このレポートでは、AI OverviewsとAI Modeでサイトへのリンクが表示されたインプレッションを、ページ・国・日付・デバイスなどで確認できます。
参考:Google Search Console「生成 AI パフォーマンス レポート(検索)」
なお、この「検索」レポートの対象はAI OverviewsとAI Modeです。Discoverの生成AI機能は別の「生成 AI パフォーマンス レポート(Discover)」で確認します。 設定と計測画面の対象を混同しないように分けて見る必要があります。
参考:Google Search Console「生成 AI パフォーマンス レポート(Discover)」
そのため現在は、「AI検索に含めるか」という設定と「実際にどのページがAI検索で露出したか」という測定を、Google Search Console内で以前より明確に分けて扱えます。
「検索される」「学習される」「その場で読まれる」は、時間軸も違う
用途の違いは、いつ情報が使われるかを見るとさらに分かりやすくなります。
学習用クロールは、将来のモデル開発のため
今日クロールされたからといって、その内容が今日の回答に即反映されるとは限りません。
モデルの訓練や更新という別の工程があります。
検索・索引用クロールは、現在の質問へ新しい情報を返すため
AI検索では、モデルが以前から知っている内容だけでなく、検索インデックスやWeb検索を使って現在の情報を参照できます。
これは学習とは別の仕組みです。
ユーザー起点取得は「今このURLを読む」動作に近い
Claude-Userのようなアクセスは、ユーザーのリクエストを処理するため、その時点でWebページへ取りに来る性格が強くなります。
全部を「AIが学習している」と表現すると、この時間軸の違いまで消えてしまいます。
設定を変更する前に書き出す4つの目的
robots.txt等の設定は、何を実現したいのかを決めてから各社の最新ドキュメントへ対応づけます。クローラーの名称や方針は変更されるため、この記事で紹介した一覧を恒久的な設定仕様と見なさないでください。
| 運営者の目的 | 調べるべきこと | 期待してはいけないこと |
|---|---|---|
| 一般検索で発見してもらいたい | 通常検索のクロールとindexの条件 | Allowを書けば必ず掲載されるという保証 |
| AI検索・引用で紹介されたい | 対象サービスが検索・引用のために使う経路 | 受け入れれば必ず引用されるという保証 |
| 将来のモデル学習への利用を分けたい | 事業者が公開する学習用の制御方法 | 既に配布された情報が自動的に消えるという保証 |
| 非公開情報を守りたい | アクセス認証、公開範囲、適切な配信設定 | robots.txtだけで秘密にできるという期待 |
設定を改めるときは、変更前のrobotsやメタ情報を保存し、編集日時、根拠とした公式資料、実際に返すHTTP応答を記録します。方針の記述、クローラーによる遵守、検索・引用の成果は別の観察対象です。
サイト運営者は「AIを許可するか」ではなく、目的ごとに方針を決めた方がいい
botの名前を全部覚えるより、まず自分のサイトで何を許可したいか決める方が分かりやすいです。
通常の検索には出したいか
Googleなど従来検索への掲載方針です。
公開サイトであれば許可したいケースが多いでしょう。
AI検索で引用・紹介されたいか
ChatGPTやClaudeなどから発見されることをメリットと考えるかです。
サービスサイトやコンテンツサイトでは、新しい発見経路として許可する判断があります。
将来のモデル学習に使われる可能性を許容するか
検索露出とは別に決めます。
「AI検索には出したいが、学習用botは拒否する」という方針も成立します。
ユーザーが直接AIへURLを渡した場合に読めるようにするか
公開資料であれば許可したい場合もありますし、有料・会員限定コンテンツでは別の判断になります。
この4つを決めるだけでも、robots.txtの設定意図がかなり明確になります。
robots.txtは「秘密にする」ための仕組みではない
OpenAI・Anthropic・Googleの説明を比較すると、robots.txtは各クローラーへ意思を伝える主要な手段です。
ただし、robots.txtは認証やアクセス制御ではありません。
公開したくない契約書、顧客情報、社内資料、有料会員専用コンテンツを「robots.txtでDisallowしたから安全」と考えるのは危険です。
本当に一般公開させたくない情報には、ログイン、アクセス制御、適切な認可など別の仕組みが必要です。
robots.txtは公開Web上の自動クローラーへクロール方針を伝える仕組みとして扱うのが適切です。
llms.txtは、学習・検索・クロール制御の代わりではない
AI関連のWeb施策として llms.txt も話題になります。
ただ、今回扱っている「誰に何を許可するか」という問題とは分けた方がよさそうです。
robots.txtには、特定crawlerへアクセス許可・拒否を伝える役割があります。
一方llms.txtは、LLMがサイト情報を理解しやすくするための提案として広がっているもので、OpenAI・Google・Anthropicの学習オプトアウト設定を一括管理する標準ではありません。
したがって、
llms.txtを置いたからAI学習を許可した
llms.txtを書かなければAIから読まれない
という関係ではありません。
実例として、oka-projectでも llms.txt はサイトの内容を案内する入口として置いていますが、クローラーや学習用途の許可・拒否はrobots.txtや各社の設定と分けて管理しています。
AI時代のrobots.txtは「拒否リスト」より、用途別の意思表示に近づいている
robots.txtというと、以前は検索エンジンへ「ここはクロールしないでください」と伝える地味な設定ファイルという印象がありました。
2026年の主要サービスを見ると、役割が少し広がって見えます。
検索。
将来の学習。
検索品質向上。
ユーザー起点の取得。
同じ会社でも用途別にアクセス方法を分け、サイト側が選択できるようになっています。
AI時代に重要なのは「AIに読ませるか、読ませないか」という2択ではなく、
誰に、何の目的で、どこまで読ませるのか。
そこを決めることなのだと思います。
自分でサイトを運営する側としても、検索には載せたい、AI検索からも見つけてほしい、でもすべての用途を無条件に許可する必要はない、という中間の方針が一番現実的に感じます。
少なくとも、「AI検索に出る=そのままモデル学習を許可している」ではありません。