[レベル: 上級]
Google、OpenAI、Microsoft の 3 社は 2026 年 10 月 30 日、AI 学習へのコンテンツ利用を拒否するための robots.txt の共通シグナルに対応すると、それぞれ発表しました。
概要
この共通シグナルを使えば、サイト運営者は 1 回の設定で、対応するすべての AI 事業者に学習の拒否を伝えられます。
これまでは AI 企業のクローラーごとに個別のルールを書く必要がありました。
たとえば、Google Gemini の学習利用を拒否したいなら、Google-Extended を robots.txt でブロック (Disallow) します。
OpenAI の AI モデルの学習利用を拒否したいなら、GPTBot を robots.txt でブロックします。
しかし、共通シグナルを利用すれば、こうした個別の設定の手間がなくなります。
仕様は、Anthropic の Kevin Kelley 氏が IETF に提出した Internet-Draft「Machine-Readable Training Preference Signal」にまとめられています。
「AI 学習」の定義は、IETF の AIPREF (AI Preferences) ワーキンググループの語彙ドラフト「draft-ietf-aipref-vocab-08」から引用されています。
書き方と仕組み
書き方はシンプルです。
robots.txt に User-Agent: __usage_ai-training のグループを作り、いつもどおり Disallow と Allow をパスごとに書くだけです。
User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/User-Agent で指定する「__usage_ai-training」は固定です。
この値が、各 AI 企業の AI モデルが従う共通のシグナルであることを示します。
2 行目の Disallow: / でサイト全体のコンテンツの学習利用を拒否しています。
3 行目の Allow: /press-kit/ は拒否の例外設定です。/press-kit/ ディレクトリ配下のコンテンツに関しては学習利用を許可しています。
なお、robots.txt における新しいディレクティブや文法は追加されていません。
つまり、robots.txt の書き方そのものは変えず、既存のルールの枠組みにそのまま収まる形にした仕組みです。
たとえば、 Content-Usage: train-ai=n のような新しいディレクティブを追加したわけではありません（AIPREF の初期では、例に出したディレクティブが AI 学習を拒否するための新たな命令として議論されていた）。
このシグナルに対応していないパーサーやクローラーから見ると、__usage_ai-training のグループは「知らないクローラー向けのルール」にすぎません。
自分宛てではないので読み飛ばします。
その結果、
- Googlebot や Bingbot などのクロール制御は、これまでとまったく同じように動きます
- 構文エラーになったり、ほかのルールの解釈が変わったりすることはありません
ただし、対応していないパーサーが、その行を無視するのか、エラーとして扱うのか、前後のルールの解釈が崩れるのかは、AI 企業の実装しだいでばらつく可能性があります。
ドラフトは「実際に使われているパーサーで問題なく動くこと」を設計目標に挙げていて、作者の Kelley 氏もメーリングリストの投稿で、パーサーごとの挙動の違いに頼らない方式を選んだと説明しています。
ちなみに、User-Agent の名前の先頭に __ を付けているのは、柔軟すぎるマッチングをするパーサーが、ほかのクローラー名と誤って一致させるのを防ぐためとのことです。
少し脱線しましたが、押さえておきたいポイントは次のとおりです。
- 対象は生成 AI モデルの学習だけ：
ここでいう「AI 学習」は、コンテンツを使って生成 AI モデルのパラメータを更新することを指す。分類、ランキング、スコアリングなど、生成以外の用途だけに使うモデルの学習は含まれない。 User-Agent: *は対象外：
ワイルドカードのグループを学習の意思表示として読んではならないと定められている。__usage_ai-trainingのグループがなければ、意思表示はなかったものとみなされる。- クロール制御とは別物：
このトークンが示すのはコンテンツの使い道であり、クロールしてよいかどうかではない。クローラーごとのルールはこれまでどおり機能する。 - 具体的な指定が優先される：
企業独自のトークンのような具体的な指定を、共通トークンより優先させてもかまわない。また、サイト運営者と AI 事業者が個別に契約 (ライセンス契約など) を結んでいる場合は、その内容をシグナルより優先させてもかまわない。
なお、どちらのドラフトもまだ Internet-Draft の段階で、正式な標準ではありません。
Kelley 氏のドラフトは個人提出のもので、IETF の承認はなく、有効期限は 2027 年 5 月 3 日です。
各社の対応
各 AI 企業の現時点での対応は次のとおりです。
Google は、サイトが共通トークンで学習を拒否していて、Google-Extended を明示的に指定していなければ、Google-Extended を Disallow したものとして扱います。
Google-Extended は今後も使え、明示的に許可したサイトは、Gemini アプリのグラウンディング経由で回答に表示され、クリックを得られます。
対応は 2027 年の予定です。
Google は、この取り組みが EU AI 法の GPAI 行動規範にも沿っているとしています。
OpenAI
OpenAI は今後数か月以内に導入する予定です。
詳細はそのときに公表するとしています。
既存のクローラー制御も引き続き有効です。
Anthropic
Anthropic は、ドラフトの公開を知らせる Kelley 氏のメーリングリスト投稿によると、すでに対応の実装を始めています。
既存のクローラー制御を置き換えるのではなく、補うものだとしています。
Microsoft
Microsoft (Bing) は共通シグナルに加えて独自の拡張を用意し、2027 年 2 月 1 日から適用します。
ページ単位での学習設定に加え、学習とは別に、コンテンツを AI の回答の根拠に使う「グラウンディング」の設定を追加し、従来の NoArchive と NoCache を置き換えます。
NoArchive や NoCache を使って AI の学習・引用を制御しているサイトは、2027 年 3 月 1 日までに対応が必要です。
詳しくは別記事で後日解説します。
◇ ◇ ◇
大手 AI 事業者が、AI 学習を拒否するための robots.txt の共通トークンに足並みをそろえつつあります。
ただし、仕様はまだドラフトの段階で、対応時期も各社で異なります。
今後の標準化の動きと、各社の実装状況を見守りたいところです。
進展があればお伝えします。