robots.txtのAI学習拒否とは？共通信号の条件

robots.txtのAI学習拒否は、何が変わる？

新しい提案の中心は__usage_ai-trainingというポリシートークンだ。サイト全体について基盤モデルの学習を望まない場合、IETFの草案は次の書き方を示している。[3]

User-Agent: __usage_ai-training
Disallow: /

従来はAI事業者ごとのクローラー名を調べ、GPTBot、Google-Extendedなどへ個別にルールを書く必要があった。共通信号に参加する事業者が増えれば、同じ意思を一度で広く伝えられる。

項目	これまでの主な方法	共通信号の提案
指定先	事業者・クローラーごと	__usage_ai-training
対象	指定した事業者の用途	参加事業者の基盤モデル学習
導入状況	現在利用できる	OpenAIとGoogleは対応予定
標準化	各社の運用ルール	IETFで議論中の草案
強制力	各社の遵守方針による	同じく自主的な遵守が前提

Disallowという見た目でも、共通信号はクローラーの通信を止めるための命令ではない。IETF草案は「コンテンツ利用の選好」と「アクセス制御」を別のものと定義する。つまり、学習に使わないでほしいという意思を示しても、検索や別用途のクローラーが必ず巡回を止めるとは限らない。[3]

「学習」と「検索表示」を分けて考える

AIサービスはモデルを作るための学習と、回答時に最新ページを検索して出典を示す機能の両方でWebを利用する。今回の共通信号が対象にするのは、基盤となる生成AIモデルの学習だ。検索結果やグラウンディングへの掲載を一律に拒否する合図ではない。

OpenAIは現在、GPTBotをモデル学習、OAI-SearchBotをChatGPTの検索表示に使うクローラーとして案内し、両方を独立して設定できるとしている。GPTBotを拒否しつつOAI-SearchBotを許可すれば、学習への利用を断りながらChatGPT検索の参照候補になる余地を残せる。設定反映には約24時間かかる場合がある。[4]

Googleも同じ区別を置く。Google-ExtendedはGeminiのモデル改善やグラウンディングを管理するためのトークンで、Google検索への掲載順位には影響しないと説明してきた。今回の発表では、共通信号で学習拒否を示し、Google-Extendedを明示していない場合、Google-Extendedを拒否したものとして扱う予定だ。一方で、Google-Extendedを明示的に許可すれば、その個別指定を優先できる。[2]

目的	OpenAIの現行指定	Googleの現行指定	共通信号との関係
基盤モデル学習	GPTBot	Google-Extended	将来まとめて拒否を表明できる
AI検索への表示	OAI-SearchBot	Google検索・グラウンディングの条件	共通信号だけでは一律に止めない
通常の検索	別の検索用制御	Googlebot	従来の検索制御を維持

サイト流入を保ちながら学習だけを拒否したい運営者にとって、この切り分けは重要だ。AI検索で引用されることによる流入と、事前学習への利用は同じではない。Google検索のゼロクリック化を扱った記事でも見たように、検索画面内で答えが完結するほど、掲載可否と送客の関係は慎重に測る必要がある。

今すぐ共通信号だけに置き換えない

OpenAIは共通信号を「今後数カ月で実装する」とし、詳しい実装情報を後日案内する。Googleは2027年の対応を目指す。どちらも従来の個別指定を廃止するとは述べていない。したがって、2026年11月時点では共通信号だけに切り替えると、対応開始まで希望が伝わらない期間が生じる。

実務では次の順で進めたい。

1. 現在のrobots.txtを保存し、GPTBot、OAI-SearchBot、Google-Extendedなどの個別指定を確認する。
2. 学習、AI検索、通常検索のどれを許可・拒否したいか、目的ごとに決める。
3. 既存の個別指定を残したまま、共通信号を追加する。
4. 公開後にrobots.txtが200で返り、意図したパスが記載されているか確認する。
5. 各社の実装開始とIETF草案の更新を追い、記法や優先順位が変わっていないか見直す。

サイト全体ではなく、会員向け資料や特定ディレクトリだけを拒否したい場合は、Disallow: /members/のように対象パスを絞る考え方も草案に含まれる。逆にAllowを使えば、利用を認める選好も示せる。ワイルドカードのUser-Agent: *は共通ポリシートークンの代わりにはならない。[3]

なお、robots.txtは公開ファイルであり、秘密情報を守るアクセス制御ではない。非公開資料は認証や権限管理で保護する必要がある。共通信号を無視する事業者、契約で別条件を定める事業者、学習以外の用途にも自動で効くと期待してはいけない。

共通化の価値は、意思表示の運用コストを下げること

共通信号の価値は技術的な遮断を保証することより、サイト運営者が増え続けるAI事業者を個別に追いかける負担を減らす点にある。OpenAIとGoogleが同日に支持を表明したことで、少なくとも主要2社へ同じ語彙で選好を伝える道筋が見えた。

一方で、IETFの文書はまだ標準ではない。draft-kelley-aipref-training-preference-signal-00は期限を持つInternet-Draftで、今後の議論で内容が変わる可能性がある。企業の発表も対応方針であって、実装済みの成果ではない。[3]

運営判断は「拒否を書いたから終わり」ではなく、次の3つを分けて記録するとよい。

• 意思表示：どの用途を許可・拒否するか
• 実装状況：各社が共通信号をいつ、どう解釈するか
• 事業影響：AI検索からの参照や流入、コンテンツ契約にどんな変化があるか

共通化が進めば、法務・編集・開発が同じ設定を参照しやすくなる。ただし、利用規約やライセンス、技術的なアクセス制御を置き換えるものではない。robots.txtは、あくまで公開された選好を機械が読み取る入口である。

まとめ

• AI学習の共通信号は__usage_ai-trainingをrobots.txtに書き、参加する複数事業者へ一度で選好を伝える提案だ。
• 2026年11月時点ではIETF草案で、OpenAIとGoogleも実装前である。既存のGPTBotやGoogle-Extendedの個別指定は残したい。
• 学習拒否とAI検索への掲載、通常検索、アクセス制御は別の判断になる。目的を分けて設定し、各社の実装後に流入と利用状況を検証する必要がある。

出典・参考

1. OpenAI「Making it easier for websites to express AI training preferences」（2026年10月30日）
2. Google Search Central「Supporting a shared AI training control for websites」（2026年10月30日）
3. IETF Datatracker「draft-kelley-aipref-training-preference-signal-00」（2026年10月30日）
4. OpenAI Developers「Overview of OpenAI Crawlers」（2026年11月3日確認）