AI学習を断るrobots.txtの共通指定「__usage_ai-training」|Google・OpenAIなど4社の対応時期と、WordPressでの書き方
Google、OpenAI、Microsoft、AnthropicがAI学習を断る共通の書き方を支持した
AnthropicとOpenAI、Google、Microsoftの4社は2026年10月30日、Webサイトのrobots.txtに書く共通の指定「__usage_ai-training」を尊重すると相次いで発表しました。サイトの運営者がこの指定を書くと、自分のページを生成AIの学習に使わないでほしいという意向を、対応する複数のAI企業へ一度に伝えられます。もとになったのは、Anthropicで標準化を担当するKevin Kelley氏が同じ日にIETF(インターネットの技術標準を議論する団体)へ出した個人の提案文書「Machine-Readable Training Preference Signal」です。
これまでAI学習を断りたいサイトは、OpenAIならGPTBot、GoogleならGoogle-Extendedというように、会社ごとに違う名前を調べてrobots.txtへ書き分ける必要がありました。共通の指定は、その書き分けを1か所にまとめるための仕組みです。ただし各社の対応時期はそろっておらず、Anthropicは実装に着手した段階、OpenAIは「今後数か月以内」、Microsoftは2027年2月1日、Googleは2027年中を予定しています。
この記事では、指定の書き方と意味、各社の扱いの違い、既存のクローラー別の指定との関係を整理します。あわせて、よく使われる3つのrobots.txt解析ライブラリと、Docker上のWordPress 7.1.4で実際の出力を確かめた結果も紹介します。ブログやWebサイトを運営していて、AI学習への利用について意思表示をしておきたい人に向けた内容です。
3分で把握
2行足すだけで、対応するAI企業へまとめて「学習には使わないで」と伝わる
2026年10月30日の4社の発表と提案文書、手元での検証をもとにまとめました。
書き方
User-Agent: __usage_ai-training
続けてDisallow: /と書くと、サイト全体について学習に使わないでほしいという意向になる。
検索エンジンなどの巡回
そのまま続く
伝わるのは学習への利用の意向だけ。3つの解析ライブラリでも、GooglebotやGPTBotの巡回の許可は変わらなかった。
対応時期
2026〜2027年
Anthropicは実装に着手、OpenAIは数か月以内、Microsoftは2027年2月1日、Googleは2027年中。
書き方は、クローラー名の代わりに共通の名前を置く2行
robots.txtは、サイトのいちばん上の階層に置くテキストファイルです。検索エンジンなどの自動巡回プログラム(クローラー)に、どのページを読みに来てよいかを伝えるために使われてきました。通常はUser-Agent:の行にクローラーの名前を書き、その下のDisallow:(読まないで)やAllow:(読んでよい)でページの範囲を指定します。
今回の提案は、この書式を変えずに使います。User-Agent:の行にクローラー名の代わりに__usage_ai-trainingという共通の名前を書くと、そのまとまりは「巡回してよいか」ではなく「生成AIの学習に使ってよいか」の意向として読まれます。提案文書は、この名前を「ポリシートークン」と呼んでいます。サイト全体について断る場合は、次の2行です。
User-Agent: __usage_ai-training
Disallow: /
一部のディレクトリだけを断ることもできます。次の例では、/members/以下を学習に使わないでほしい範囲にし、プレス向けの素材を置く/press-kit/は学習に使ってよいと明示しています。複数の行が当てはまるときは、通常のrobots.txtと同じく、より長く一致した行が優先されます。
User-Agent: __usage_ai-training
Disallow: /members/
Allow: /press-kit/
ここでいう「学習」は、IETFで議論中の用語集の定義に沿っています。コンテンツを使って生成AIモデルの中身(学習済みのパラメーター)を変えることを指し、文章や画像を生成しない分類用などのモデルだけに使う場合は含みません。名前の先頭に下線を2つ付けているのは、実在するクローラーの名前と偶然重ならないようにするためです。
4社の対応は2027年にかけて順に始まり、会社ごとの指定も残る
4社とも共通の指定を尊重すると表明していますが、始める時期と、これまでの会社ごとの指定との組み合わせ方は少しずつ違います。発表の内容を会社ごとに並べると、次のようになります。
対応が始まる見込みの早い順に、Anthropic → OpenAI → Microsoft → Google
Anthropic|実装に着手(展開はこれから)
提案者のKelley氏が10月30日、IETFのメーリングリストで「すでに対応の実装を始めた」と表明。全サービスへの展開には時間がかかり、解釈は標準化の進み方に合わせて変わりうるとしています。
OpenAI|今後数か月以内
実装の詳細は対応時に改めて案内する予定。GPTBotなどを名指しする既存のクローラー制御は、引き続き適用されます。
Microsoft|2027年2月1日から
学習の意向はrobots.txtとページ単位の指定(metaタグかHTTPヘッダー)の両方で受け付け、ページ単位の指定が優先されます。AIの回答の根拠に使うこと(グラウンディング)は別の項目で、ページ単位だけで指定します。
Google|2027年中
共通の指定で断っていてGoogle-Extendedの指定がないサイトは、Google-Extendedを拒否したものとして扱う方針。Google-Extendedを明示した指定は、共通の指定と並んで引き続き機能するとしています。両者が食い違うときの扱いは明言していません。
出典: 各社の2026年10月30日の発表と、Kelley氏のIETFメーリングリストへの投稿(参考資料を参照)。
Microsoftは、従来NoArchiveとNoCacheの指定を学習やグラウンディングの意向としても読んでいましたが、新しい指定に置き換えます。2027年3月1日を過ぎると、この2つは学習やグラウンディングの意向として読まれなくなります。学習とグラウンディングのどちらも、意向を何も書かなければ「使ってよい」の扱いになります。Bingの検索結果への掲載には影響しないと説明しています。
共通の指定と、これまでの会社ごとの指定は、受け持つ役割が違います。使い分けの要点は次のとおりです。
共通の指定
__usage_ai-training
- 伝えるのは「学習に使ってよいか」の意向
- 1回書けば、対応する会社へまとめて届く(Googleは、
Google-Extendedを明示していないサイトで共通の指定が学習を断っていれば、Google-Extendedも拒否したものとして扱う) - クローラーの巡回はそのまま続く
会社ごとの指定
GPTBot、Google-Extendedなど
- クローラーの名前を指定して、巡回の範囲を決める
- 会社ごとに名前を調べて書き分ける
- 共通の指定が入っても、引き続き有効
提案文書は、特定の会社だけが読む既存の名前を「独自のポリシートークン」と呼び、共通の指定とは別のものとして扱うよう定めています。また、より具体的な指定を優先するのが望ましいとし、各社が独自の名前を共通の指定より具体的なものとして扱うと文書で示すことも認めています。Googleは、この扱いをまだ明示していません。そのため、すでにGoogle-Extendedを許可しているサイトが共通の指定で学習を断ると、Googleには食い違った2つの意向が届き、どちらが採られるかは今のところはっきりしません。両方を書く場合は、許可と拒否をそろえておくと意図どおりに伝わります。
3つの解析ライブラリで、巡回の許可が変わらないことを確かめた
共通の指定を足したとき、検索エンジンやAI企業のクローラーの巡回に影響が出ないかを、手元で確かめました。robots.txtを読んで「このページを読んでよいか」を判定するプログラム部品(解析ライブラリ)のうち、Python標準のurllib.robotparser、Pythonの巡回フレームワークScrapyが使うProtego 0.4.0、Node.jsのrobots-parser 3.0.1の3つを使い、それぞれに同じrobots.txtを読ませ、Googlebot、GPTBot、ClaudeBot、__usage_ai-trainingの4つの名前で、3つのページを読んでよいかを判定させました。
手元での検証結果(2026年11月3日)
4つのケースすべてで、3つのライブラリの判定は一致した
サイト全体を断った場合
共通の名前だけが全ページ「不可」。Googlebot、GPTBot、ClaudeBotは全ページ「可」のまま。
一部のディレクトリを断った場合
共通の名前で/members/だけが「不可」、/press-kit/とトップは「可」。
GPTBotを明示で許可した場合
GPTBotは「可」、共通の名前は「不可」。2つの指定は互いに影響しない。
「User-Agent: *」で全体を閉じた場合(Disallow: /)
3つとも共通の名前を*のまとまりに当てはめて「不可」と判定。提案文書は、*を学習の意向として読まないよう定めている。
macOS上のPython 3.13(Protego 0.4.0)とNode.js(robots-parser 3.0.1)で実行。判定は「そのページを読んでよいか」の結果です。
最初の3つのケースでは、共通の指定を足しても、既存のクローラーの許可はそのまま保たれました。3つのライブラリの判定では、巡回の許可を保ったまま、学習についての意向だけを別のまとまりに書き分けられました。
4つ目のケースでは、読み方の違いが出ました。汎用の解析ライブラリは、名前が書かれていないものに*のまとまりを当てはめるため、共通の名前も「不可」になります。一方、提案文書は「User-Agent: *のまとまりを共通の名前に当てはめてはならない」と定めており、共通の名前のまとまりがないサイトは「意向を示していない」扱いになります。*で全体を閉じているサイトでも、学習についての意向を伝えたいなら、共通の名前を明示して書く必要があります。
WordPressでは、robots_txtフィルターで先頭に足せる
WordPressは、robots.txtのファイルを置いていない場合、内容をその場で組み立てて返します。この出力はrobots_txtというフィルターで書き換えられるので、テーマを変えても消えない「必須プラグイン」(wp-content/mu-plugins/に置くファイル)として、次のコードを追加しました。
<?php
/**
* Plugin Name: AI training preference (robots.txt)
*/
add_filter( 'robots_txt', function ( $output, $is_public ) {
if ( ! $is_public ) {
return $output;
}
$group = "User-agent: __usage_ai-training\nDisallow: /\n\n";
return $group . $output;
}, 10, 2 );
Docker上のWordPress 7.1.4(PHP 8.3)でこのファイルを置き、/robots.txtを開くと、WordPressが標準で出す内容の前に共通の指定が加わりました。$is_publicは、管理画面の「検索エンジンでの表示」の設定を受け取る引数で、検索エンジンにサイトを見せない設定のときは何も足さないようにしています。
User-agent: __usage_ai-training
Disallow: /
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: http://127.0.0.1:8093/wp-sitemap.xml
WordPressを設置したフォルダー(サイトのいちばん上の階層)にrobots.txtのファイルを実際に置いている場合は、そのファイルがそのまま返され、フィルターは働きません。同じ環境にファイルを置いて確かめると、フィルターで足した行は出力から消えました。ファイルを置いているサイトでは、ファイルへ直接2行を書き足します。どちらの方法でも、書き足したあとにブラウザでhttps://(自分のドメイン)/robots.txtを開き、共通の指定が出ていることを確かめておきます。
書き足す前に、断る範囲と会社ごとの指定の許可・拒否を確かめる
共通の指定は2行で書けますが、何を断りたいかによって、合わせて見直す指定が変わります。書き足す前に、次の順で確かめておくと迷いません。
1. 断りたいのは学習だけか
学習だけなら共通の指定で足ります。AIの検索や回答に使われることも止めたい場合は、各社の該当するクローラー名や、Microsoftのページ単位のグラウンディングの指定を別に確かめます。
2. サイト全体か、一部のディレクトリか
全体ならDisallow: /、一部なら対象のディレクトリをDisallow:に書き、学習に使ってよい場所はAllow:で明示します。
3. 会社ごとの指定と許可・拒否がそろっているか
Google-Extendedなどをすでに書いている場合は、共通の指定と許可・拒否をそろえます。Googleは、Google-Extendedを明示していないサイトで共通の指定が学習を断っていれば、Google-Extendedも拒否したものとして扱うとしています。
提案文書では、ページの意向は、そのページを取得した時点のrobots.txtで判断されます。Microsoftも、意向はページを読みに来た時点から有効になると説明しています。断りたいサイトは、各社の対応開始を待たずに書いておくと、対応が始まった直後の取得から意向が伝わります。
まとめ:今のうちに2行を書き、会社ごとの指定と許可・拒否をそろえる
AIの学習への利用について、サイトの運営者が1回書くだけで複数の会社へ意向を伝えられる仕組みが、主要な4社の支持を得て動き始めました。提案はIETFの個人の提案文書の段階で、各社の対応は2026年から2027年にかけて順に始まります。
書き方はUser-Agent: __usage_ai-trainingとDisallow: /の2行で、検索エンジンやAI企業のクローラーの巡回はそのまま続きます。User-Agent: *のまとまりは学習の意向として読まれないので、意向を伝えたいサイトは共通の名前を明示します。WordPressではrobots_txtフィルターか、robots.txtのファイルへの書き足しで設定でき、すでに会社ごとの指定を書いているサイトは許可・拒否をそろえておくと意図どおりに伝わります。
参考資料
- Machine-Readable Training Preference Signal(draft-kelley-aipref-training-preference-signal-00)(Kevin Kelley、IETF、2026年10月30日)。書き方、学習の定義、
*の扱い、独自のポリシートークンとの関係。IETFの作業部会が正式に採択する前の、個人の提案文書 - Kelley氏のai-controlメーリングリストへの投稿(2026年10月30日)。Anthropicによる実装への着手
- AI 学習への利用意向をウェブサイトが伝えやすくする仕組み(OpenAI、2026年10月30日)
- Google Search Centralブログの発表(Google、2026年10月30日)。
Google-Extendedとの関係と対応時期 - Your content, your choice: clearer preferences for training and grounding(Microsoft Bing、2026年10月30日)。学習とグラウンディングの指定、移行の日程
- Nieman Labの記事(2026年11月2日)。報道機関向けの解説とMetaのコメント












