__usage_ai-training による robots.txt での AI 学習オプトアウト: Google の対応付けは Gemini のグラウンディングにも及ぶ

このサイトの robots.txt は数行しかなく、その 1 行は Content-Signal: ai-train=yes, search=yes, ai-input=yes です。4 月に追加したもので、一部はエージェント対応度スキャナーを通すためでした。10 月 30 日、3 つの発表が同時に出ました。AI 学習用の共通 robots.txt トークンを定義する IETF ドラフト、それを尊重するという Google の投稿、同じことを言う OpenAI の投稿です。どれもこの行には触れていません。

自分にとっては問題ありません。すべて許可したいのですし、何も書かなければだいたい許可と同じ扱いになるからです。困るのは、学習には No、それ以外には Yes と言いたい人です。Google では、新しいトークンが自身の定義より広い範囲に効くことになるからです。

robots.txt のトークン __usage_ai-training とは?

ごく普通の robots.txt のグループで、User-Agent 行にクローラー名ではなく目的を書きます。その下の Disallow は該当パスについて AI 学習に反対する意思表示、Allow は賛成の意思表示で、グループがなければ意思表示なしです。ドラフトは新しいディレクティブも新しい文法も追加しません。

ドラフトは draft-kelley-aipref-training-preference-signal-00 で、Anthropic の Kevin Kelley が書き、10 月 30 日に公開されました。個人提出のドラフトで、文書自体が IETF の承認を受けておらず正式な位置づけもないと明記しています。AI 学習の定義は AIPREF ワーキンググループの語彙ドラフトから借りており、そこでは学習とはアセットを "to modify the learned parameters of a generative AI model" ために使うことです。ドラフトの例:

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

例そのものより重要なルールが 2 つあります。まず、このトークンはクロールの指示ではありません。尊重するクローラーでもページの取得はできますし、クロールの制限は各クローラー固有のプロダクトトークンに残ります。そしてワイルドカードのグループは数に入りません:

Wildcard groups (User-Agent: *) MUST NOT be interpreted as
matching the policy token.

つまり、User-Agent: * に Disallow: / だけを書いたファイルは、クローラーに「クロールしないで」と伝えているだけで、学習については何も言っていません。

共通の AI 学習トークンについて Google と OpenAI は何を発表したか

Google は対応付けと目標の年を発表し、OpenAI はトークン名も時期も示さずに "a common signal" を尊重すると発表しました。どちらもまだ実装していません。

John Mueller による Google の投稿は、トークンが Google にとって具体的に何を意味するかを書いています:

When a website uses this policy token to opt out of training
in its robots.txt file (and Google-Extended is not explicitly
specified), Google plans to interpret that as if the publisher
had disallowed Google-Extended.

投稿によれば対応は "in 2027" が目標です。同じ日に更新されたクローラーのドキュメントは "early 2027" としてトークン名も挙げています。Google-Extended など既存の制御は並行して使えます。

OpenAI の投稿は、robots.txt の共通シグナルを "for foundational generative AI training" で尊重し、"in the coming months" の実装を目指すと述べ、実装の詳細は別の投稿で出すとしています。既存のクローラー制御はそのまま有効です。シグナルと GPTBot の関係は、その次の投稿を待つことになります。

共通トークンで AI 学習を拒否すると Gemini のグラウンディングから外れるのか?

Google の 2 つの文書を合わせて読むと、対応付けが始まれば外れます。トークンは学習を拒否し、Google はそれを Google-Extended の Disallow に読み替える予定で、Google-Extended はもともと学習だけの制御ではありません。クローラーのドキュメントによる対象範囲:

Google-Extended is a standalone product token that web
publishers can use to manage whether content Google crawls
from their sites may be used for training future generations
of Gemini models that power Gemini Apps and Vertex AI API for
Gemini and for grounding (providing content from the Google
Search index to the model at prompt time to improve factuality
and relevancy) in Gemini Apps and Grounding with Google Search
on Vertex AI.

そしてブログ投稿の、対応付けの 1 段落後:

Websites that specifically allow Google-Extended are eligible
to appear in responses and receive clicks via grounding in
Gemini Apps.

ドラフトが定義するのは学習に関する意思表示で、利用に関する意思表示は他のすべてと独立しているとしています。ところが、トークンの読み方をこれまでに示した唯一のベンダーである Google は、学習のオプトアウトを Google-Extended のオプトアウトとして読みます。そして Google-Extended は、学習と Gemini アプリおよび Vertex AI でのグラウンディングを一括りにしています。「学習に使わないで」とだけ言いたかったサイトも、Gemini アプリで出典を引用してリンクするグラウンディングから外れることになります。Google はこれをコストとしては書いていません。対応付けの 1 段落後に Google-Extended を許可すると何が得られるかを書き、引き算は読者に任せています。その引き算は、2 つの文書を並べて読んだ筆者の解釈です。AI 機能を含む Google 検索自体は別の制御で、影響を受けません。

抜け道は同じ文の中の優先ルールにあります。対応付けが適用されるのは Google-Extended が "is not explicitly specified" の場合だけです。Google-Extended に明示的な Allow を書けば、Google はそちらを読みます。ただし、その Allow は学習も含みます。Google が現在ドキュメント化している robots.txt の制御では、Gemini の学習と Gemini のグラウンディングは 1 つのスイッチです。

OpenAI は両者を分けています。クローラーのドキュメントでは各設定が "independent of the others" とされ、GPTBot が学習の制御、OAI-SearchBot が ChatGPT 検索の回答にサイトが出るかどうかを決めます。3 つ目のエージェント ChatGPT-User はユーザーの依頼でページを取得するもので、OpenAI はこれについて "robots.txt rules may not apply" と書いています。

Cloudflare の Content-Signal は Google-Extended やトークンとどう関係するか

Content-Signal は Cloudflare 独自の語彙で、2025 年 9 月に公開され、User-Agent: * のグループに書きます。新しいドラフトのワイルドカードのルールでは、このグループの記述はトークンについて何も意味せず、Google と OpenAI の投稿も Content-Signal には触れていません。

それでも 1 行書く価値はあります。3 つの仕組みのうち、グラウンディングを指す言葉を持つのはこれだけです。定義されているシグナルは 3 つ:

search : building a search index and providing search results
  (e.g., returning hyperlinks and short excerpts from your
  website's contents). Search does not include providing
  AI-generated search summaries.
ai-input : inputting content into one or more AI models (e.g.,
  retrieval augmented generation, grounding, or other real-time
  taking of content for generative AI search answers)
ai-train : training or fine-tuning AI models

AIPREF の語彙にも似たカテゴリ (AI Training、AI Use、Search) がありますが、定義は完全には一致せず、10 月 30 日のドラフトがトークンにしたのは最初の 1 つだけです。現時点の整理:

Content-Signal には法的な段落も付いています。Cloudflare が提案するポリシー文は、あらゆる制限を EU 著作権指令第 4 条に基づく明示的な権利留保と位置づけています。学習トークンはそのような主張をしていません。

標準の robots.txt パーサーが __usage_ai-training を誤読するのはなぜか

標準のパーサーが答えるのはクロールの質問で、トークンが問うのは意思表示だからです。RFC 9309 では * は専用グループを持たないすべてのクローラーに適用されるので、パーサーはトークンをクローラー名の 1 つとして扱い、ドラフトが求める 3 つ目の答え「意思表示なし」の代わりに Yes か No を返します。Python 標準のパーサーに、4 つのファイルについてトークンを問い合わせた結果:

from urllib.robotparser import RobotFileParser
def check(name, txt, path="/post"):
    rp = RobotFileParser(); rp.parse(txt.splitlines())
    print(name, rp.can_fetch("__usage_ai-training", "https://example.com" + path))
check("star-disallow", "User-Agent: *\nDisallow: /\n")
check("star-allow", "User-Agent: *\nAllow: /\n")
check("token-disallow", "User-Agent: __usage_ai-training\nDisallow: /\n\nUser-Agent: *\nAllow: /\n")
check("draft-example", "User-Agent: __usage_ai-training\nDisallow: /\nAllow: /press-kit/\n", "/press-kit/logo.png")

Python 3.12.3 での出力:

star-disallow False
star-allow True
token-disallow False
draft-example False

ドラフトのルールでは最初の 2 つは「意思表示なし」のはずで、オプトアウトやオプトインではありません。全員に Disallow: / を返すステージングサイトが、それで学習を拒否したことにはなりません。正しいのは 3 つ目だけです。4 つ目はドラフト自身の例で、ここでパーサーが間違える理由は別です。RFC 9309 では最も長く一致したルールが優先されますが、パーサーは最初に一致したルールを採用するので、/press-kit/ が拒否として読まれます。このトークンのチェッカーには、クロール用ライブラリにない 3 つが必要です。ワイルドカードの例外、最長一致の優先、そして「意思表示なし」の状態です。既製のパーサーで robots.txt を監査するなら、トークンのグループは手で確認してください。

2027 年に向けて AI 学習のためにどんな robots.txt を書くべきか

3 つの意図のどれなのかを決めて、明示的に書きます。上で見た暗黙のケースは、どれも読む側によって解釈が変わります。どのファイルでも * のグループが既定のクロールルールを担い、ベンダーのグループが例外になります。共通トークンが届くのは参加するプロバイダーだけなので、各ファイルには今のベンダー別の制御も書いておきます。これは今すぐ効き、トークンが実装された後も効き続けます。

参加プロバイダーには学習させない。Gemini のグラウンディングを失うことも受け入れる:

User-Agent: __usage_ai-training
Disallow: /
 
User-Agent: Google-Extended
Disallow: /
 
User-Agent: GPTBot
Disallow: /
 
User-Agent: *
Allow: /

Google 以外には学習させず、Gemini のグラウンディングに残る。 Gemini の学習を拒否しつつ Gemini のグラウンディングを維持することはできません。いちばん近いのは、トークンと GPTBot で拒否し、Google-Extended を明示的に許可するファイルです。つまり Google は学習してよいことになります:

User-Agent: __usage_ai-training
Disallow: /
 
User-Agent: Google-Extended
Allow: /
 
User-Agent: GPTBot
Disallow: /
 
User-Agent: *
Allow: /

すべてに Yes:

User-Agent: __usage_ai-training
Allow: /
 
User-Agent: Google-Extended
Allow: /
 
User-Agent: *
Allow: /
 
Content-Signal: ai-train=yes, search=yes, ai-input=yes

最後のものが自分の意図です。今のファイルにあるのは * のグループ、Content-Signal の行、サイトマップだけで、明示的なグループはありません。トークンより前に書いたものだからです。通常の robots.txt のルールでは、* のグループがすでに Google-Extended を許可しています。それでも明示的なグループを書くのは、Google の投稿の一語のためです。Google-Extended を "specifically allow" しているサイトがグラウンディングの対象になるとあり、既定の許可がそれに含まれるかは書かれていません。

既存のファイルに組み込むときに知っておきたい仕組みが 2 つあります。同じ User-Agent の 2 つのグループは、位置で上書きされるのではなく結合されます。そしてグループ内では最も長く一致したパスが優先され、同じ長さなら Allow が勝ちます。

AI クローラーのアクセスについて robots.txt からわからないことは?

実際に誰かが入れているかどうかです。robots.txt は公開する意思表示であり、実際のアクセスはエッジで決まります。先週、自分のサイトで漏れているパスを調べたとき、プラットフォームのボット対策がリクエストをチャレンジの向こうに置き、解除されるまで死活監視はサイトがダウンしていると報告していました。すべての AI クローラーに Yes と言うファイルの前に、ときどき No と言うエッジがあることもあります。AI システムに読まれることが大事なら、ファイルを信じるのではなく、許可したクローラーをエッジのログで確認し、回答に引用されているかを測ってください。

パブリッシャーにとって重要なのは robots.txt による学習のオプトアウトなのか?

多くのサイトにとっては、小さいほうの半分だと考えています。学習は次の世代のモデルが知ることを変えますが、ゆっくりで、リンクも返ってきません。グラウンディングは回答時の検索で、回答がページを引用してクリックを送れる段階です。共通トークンが扱わないのはまさにこの目的で、例外は Google だけです。Google では対応付けが始まれば、学習と一緒にこれも止まります。

このサイトは何も売らず、広告もないので、読みに来るエージェントはすべて配信経路です。すべてに Yes が安上がりな選択になります。まだトークンを読む者はいません。今日何を書いても、それは 2 つのベンダーが来年どう実装するかへの賭けです。