AI学習の可否をrobots.txtで共通指定。新しいポリシートークンの読み方

自社の記事をAIの学習に使われたくない、という意思表示の書き方が変わりつつあります。これまでは事業者ごとのクローラー名を調べ、robots.txtに個別のグループを足していく作業でした。2026年10月30日、その代わりになる共通のポリシートークンを定義したInternet-Draftが公開され、同じ日にGoogleがrobots.txtでの共通AI学習コントロールに対応する計画を、Microsoftが学習と回答生成を分けた設定を公表しました。

先に結論を書きます。書くのは__usage_ai-trainingという1つの名前で、robots.txtの既存の文法をそのまま使います。新しいディレクティブは増えません。ただしいまこの瞬間に書けば学習が止まる、という仕組みではありません。仕様は提出されたばかりのInternet-Draftで、反映の時期は事業者ごとに別に公表されます。

この記事では、トークンの書き方と意味、クロール制御との違い、ワイルドカードの指定が一致しないという落とし穴、GoogleとMicrosoftが公表した範囲、そしてまだ決まっていないことを、一次情報の記載だけで整理します。確認日は2026年10月31日です。AIクローラーをどこまで通すかという判断そのものはAIクローラーに「信頼の帯」。Cloudflareが始めた継続的な検査で扱っているので、ここでは意思表示の書き方に絞ります。

共通トークンは robots.txt のどこに書くのか

仕様は「Machine-Readable Training Preference Signal」という題のInternet-Draftです。著者はAnthropicのKevin Kelley、日付は2026年10月30日、版はdraft-kelley-aipref-training-preference-signal-00で、Standards Trackとして提出されています。書き方は次の形です。

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

User-Agentの行に、クローラーの名前ではなくポリシートークンを書きます。このトークンはRFC 9309で定義されたproduct-tokenの構文に沿っていて、draftは新しいディレクティブ名も新しい文法も導入しないと書いています。使うのはRFC 9309のパス表記、最長一致の優先規則、グループ構造です。つまりrobots.txtを読める既存の仕組みの上に、名前だけを足した形です。

意味の取り方が1つだけ独特です。Disallowは学習に使われたくないという意思表示ですが、Allowは単なる例外ではありません。draftは、パスが許可されていると判断した場合には「その用途に賛成する意思表示がなされた」と読むと書いています。上の例は、サイト全体ではAI学習を望まないが、/press-kit/の中身は使ってよい、という表明になります。報道用の素材や会社情報だけは広く使われたいというサイトは、この形で書き分けられます。

対象になる「AI学習」の範囲も、言葉の定義に戻って決まります。draftが参照しているのはdraft-ietf-aipref-vocab-08の語彙で、AI Trainingは「生成AIモデルの学習済みパラメータを変更するために資産を使うこと」と定義されています。生成モデルのパラメータを動かす用途が対象で、生成モデル以外の学習はこの定義から外れます。社内で「AIに使わせない」と決めるときは、どの用途を指しているのかをこの定義に照らして確かめたほうが安全です。

クロールを止める指定ではない

誤解が起きやすいのはここです。draftは、このポリシートークンがクロールの挙動を指示するものではないと明記しています。Microsoftの告知も同じ線を引いていて、これらの設定が左右するのはコンテンツの使い方であり、クロールのアクセスではないと書いています。

したがって、学習に使われたくないという意思表示を書いても、クローラーはページを取得します。取得そのものを制限したいなら、draftが述べているとおり、クローラーのproduct tokenに対するグループを別に書く作業が引き続き必要です。意思表示と通信量の管理は、別の仕組みとして並んでいるという整理になります。

この区別は、AI検索からの流入を取りたい媒体にとって重要です。取得を一律に止めると、AIの回答に自社が登場する経路も同時に消えます。収集と流入をどう測るかはMicrosoft Clarityが収集と流入を1つの指標に。AI Scrape-to-Referral Ratioで扱いました。止める判断をする前に、いま何が起きているかを測れる状態にしておくほうが先です。

ワイルドカードの指定では一致しない

実務でいちばん踏みやすい落とし穴がこれです。draftは、ワイルドカードのグループ、つまりUser-Agent: *は、このポリシートークンに一致するものとして解釈してはならないと書いています。

すでにUser-Agent: *に対して広いDisallowを書いているサイトは少なくありません。しかしその記述は、AI学習に関する意思表示としては読まれません。全体に効いているはずの1行が、この仕組みでは効かないということです。社内の運用担当や制作会社に共有しておかないと、「もう書いてあるから大丈夫」という誤解がそのまま残ります。

逆方向の安心もあります。draftは、既存のパーサーが知らないポリシートークンのグループを無視すると説明しています。つまり共通トークンのグループを足しても、いまのクローラー向けの指定が壊れることはありません。追加は追加として扱われます。

優先順位の規則も押さえておきます。draftは、より具体的な記述が一般的な記述より優先されるべきだとし、さらに2つの但し書きを置いています。1つは、事業者が独自のポリシートークンに一致する記述を、共通トークンより具体的なものとして解釈してよいと文書化できること。もう1つは、私的な合意がこの仕組みで示した意思表示を上書きしてよいことです。robots.txtに書いた内容が、常に最後の決定になるとは限りません。

Googleが公表したのは「対応する計画」まで

Googleの告知は、Search Centralのブログに「Supporting a shared AI training control for websites」として出ています。公式フィードに掲載された告知本文で確認できたのは、robots.txtでの共通AI学習コントロールに対応する計画を発表するという内容で、これによってサイトは複数のAI提供者に対する学習の意思表示を1回の操作で示せるようになる、と書かれています。根拠はIETFのAIPREFワーキンググループの作業で、Googleはこれを、同社がこれまで提供してきたGoogle-Extendedを含む一連の管理手段の延長に位置づけています。

ここで止まる点を正直に書いておきます。いつから反映されるのかについて、当サイトが確認できた告知本文の範囲には記述が見当たりませんでした。Googleのブログページは自動取得に対して本文を返さず、確認できたのは同社の公式フィードに掲載された本文だけです。開始時期を他媒体の記述から補うことはしません。

Google-Extendedとの関係も、現時点では「併存するのか、置き換わるのか」を断定できる記載を確認できていません。すでにGoogle-Extendedの指定を書いているサイトは、共通トークンを足したうえで既存の記述も残しておくのが、いまの情報量でとれる無理のない選択です。

Microsoftは学習と回答生成を別の設定にした

同じ日、Microsoftは「Your content, your choice」という告知で、クロールして集めたコンテンツの使い方について2つの設定を独立に示せるようにすると公表しました。AI Training（モデルの学習に使うか）とAI Grounding（AIの回答を生成する材料に使うか）です。

AI Trainingは、robots.txtの共通トークンでサイト全体に、またはページ単位の指定で示せます。ページ単位の書き方は<meta name="Bingbot" content="ai-training:disallow">、HTTPヘッダーならX-Robots-Tag: Bingbot: ai-training:disallowです。AI Groundingはページ単位だけで、ai-grounding:disallowに加えてai-grounding:disallowextendedという値があり、Microsoftが自ら運営する体験には使ってよいが、第三者へのグラウンディング提供には使わせない、という中間の選択ができます。

実務で効く記載が3つあります。1つ目は、どちらの設定も何も公開していなければ Allow として扱われること。2つ目は、ページ単位で設定したAI Trainingの意思表示が、robots.txtの設定を上書きすること。3つ目は、これらの設定が通常のBing検索の掲載適格性を変えないことです。学習に使わせないことと、検索に出ることは、別の話として分けられています。

日付はMicrosoft側だけが具体的に示されています。

日付	公表されている内容
2027年2月1日	ページをクロールする際に、新しい設定を尊重し始める
2027年3月1日	NoArchive・NoCache を学習・グラウンディングの意思表示として読まなくなる
2027年9月30日	Webmaster Tools で設定した一時的なグラウンディングの設定が失効する

出典はMicrosoftのBing公式ブログで、確認日は2026年10月31日です。古い指定（NoArchive・NoCache）を代わりに使ってきたサイトは、2027年3月1日より前に、新しい書き方へ置き換える作業が必要になります。

まだ標準ではない。強制力は仕様の対象外

この仕組みをどこまで信頼するかを決めるために、仕様の立ち位置も確認しておきます。

共通トークンを定義したのは、ワーキンググループの文書ではなく個人提出のInternet-Draftで、有効期限は2027年5月3日です。期限までに更新されるか、ワーキンググループの文書へ取り込まれるかは、現時点では分かりません。

AIPREFワーキンググループ自体の憲章は、AIモデルの開発・配備・利用のためにコンテンツがどう収集・処理されるかについて、意思表示のための構成要素を標準化することを目的に掲げています。成果物は、語彙の仕様、意思表示をコンテンツへ結びつける手順（Robots Exclusion Protocolのような Well-Known URI やHTTPレスポンスヘッダーを含む）、複数の意思表示を突き合わせる方法の3つです。

同時に、憲章は範囲外のものを明示しています。技術的な強制、認証・認可のプロトコル、意思表示の登録簿、監査の手段はいずれも対象外です。つまりこの仕組みは、守らせるための装置ではなく、意思を機械が読める形で置くための共通の書き方です。書いたから必ず止まる、とは読めません。

誰がこのトークンを尊重するかも、draftには書かれていません。当サイトが一次情報で確認できたのは、GoogleとMicrosoftが公表した内容だけです。他社の対応状況については、公式の発表ページを自動取得できず本文を確認できなかったため、この記事には書きません。

日本の実務者が先に決めること

書き方そのものは数行です。決めるのに時間がかかるのは、方針と体制のほうです。

学習と回答生成の方針を分けて決める、という作業が最初に来ます。AI検索からの流入を取りたいなら、学習には使わせないがグラウンディングは許すという組み合わせが書けます。逆に、有料の記事や調査資料を抱えている媒体は、両方を止める判断になることもあります。一律で決めず、コンテンツの種類ごとに分けて考えるほうが現実的です。AI検索に出るための考え方はAI検索時代のSEOはどう変わるかで整理しています。

次に、誰がrobots.txtを変更できるのかという体制です。意思表示が権利の話に近づくほど、変更の経緯を記録しておく価値が上がります。いつ・誰が・どの意図で書いたのかを残していないと、数年後に「このサイトは学習を許していたのか」を自社で答えられなくなります。

ページ単位の指定は、CMSの仕様に依存します。記事ごとに<meta>やHTTPヘッダーを出し分けられるか、できないなら誰が実装するのかを先に確かめておきます。できない前提でサイト全体の指定だけに頼ると、例外を作りたくなったときに手が止まります。

この記事で確認できなかったこと

• Googleがこの共通トークンを尊重し始める時期。確認できた告知本文の範囲には記述が見当たりませんでした
• Google-Extendedが今後も併存するのか、共通トークンへ寄せられるのか
• GoogleとMicrosoft以外の事業者の対応状況。公式の発表ページの本文を自動取得できず、確認できていません
• 共通トークンのdraftがワーキンググループの文書として採用される見込み。draftにも憲章にも、その予定は書かれていません
• 意思表示に反した使い方があった場合の確認手段。AIPREFの憲章は、強制・監査を範囲外としています

この領域は仕様も各社の対応も動きます。この記事の内容はすべて2026年10月31日に確認したもので、見直し周期は90日に設定しています。自社のrobots.txtを変更する前には、IETFのdraftの版が上がっていないか、各社の告知が更新されていないかを、同じURLで確かめてください。