「検索はOK、学習はNG」をrobots.txtに書く草案｜IETF aipref vocab-08で分類が3つに
OpenAI の文書によると、GPTBot を止めれば「基盤モデルの学習には使わないでほしい」と伝えられます。では GoogleやAnthropic、まだ名前も知らないボットはどうでしょう？ robots.txt の規格（RFC 9309）には使い道を書く欄がありません。だから今は、OpenAI のようにベンダーが自社ボットの名前に使い道を結びつけて決めています。IETFのaipref作業部会は、その使い道をボット名ではなく共通の語彙で書く文法を、草案で詰めているところです。2026年9月14日付のvocab-08で、分類は train-ai・ai-use・search の3つになりました。ただしこの草案は冒頭で、作業部会の合意を反映していないと自ら断っています。
これは取込層（LLMO）の話です。AIの答えに引用される、選ばれる、その一段手前にある層。お店のページがどういう条件で取り込まれてよいかを、お店の側から宣言するための設計図です。
KEY POINTS
| 項目 | 内容 |
|---|---|
| 何が出たか | IETF aipref作業部会の作業文書 draft-ietf-aipref-vocab-08（2026年9月14日付）。書く場所は別の草案 draft-ietf-aipref-attach-05（2026年8月19日付） |
| 分類 | train-ai・ai-use・search の3つ（ai-use は-08で新設） |
| 優先関係 | search が train-ai と ai-use より優先（vocab-08 §4.3） |
| 書き方 | robots.txt の Content-Usage 行か、HTTP の Content-Usage ヘッダーに train-ai=n のような y / n で |
| 位置づけ | 計画段階の草案。§3・§4 に「合意がまだない」との注記があり、宣言の遵守も保証しない |
使い道は今、ボットの名前に結び付いている
RFC 9309 の Allow / Disallow が決めるのは「どこを取りに来てよいか」。使い道を書く欄は、この規格にはありません。
OpenAI などのベンダーは、その空白をボットの名前で埋めてきました。OpenAI は、検索用の OAI-SearchBot と学習用の GPTBot を分けた。robots.txt では、それぞれを別々に設定できます。
Each setting is independent of the others – for example, a webmaster can allow OAI-SearchBot in order to appear in search results while disallowing GPTBot to indicate that crawled content should not be used for training OpenAI’s generative AI foundation models.
OpenAI「Overview of OpenAI Crawlers」
ボットごとの役割の違いは、9月10日の記事でも取り上げました。この方式は、相手の名前と定義を知っていて初めて使えます。新しいボットが現れれば、その度に名前と使い道の対応を調べ直すことになる。
ボット名に頼らない方式も、既にあります。Cloudflare は2025年9月24日に Content Signals Policy を公開しました。robots.txt に search・ai-input・ai-train の3つを書く方式だ。IETF の標準ではなく、Cloudflare 独自のもの。
使い道を書く欄そのものを IETF の規格に足すのが、attach-05 だ。原文の言葉では2段構えです。
This creates a two-stage arrangement that distinguishes acquisition and usage. Acquisition relies on Allow/Disallow rules; usage preference relies on Content-Usage rules.
draft-ietf-aipref-attach-05 §3.1
取得は Allow / Disallow、利用は Content-Usage。同じ節には、Disallow にしたパスには利用の宣言そのものが付かない、という一文もあります。
Usage preferences apply only to those resources that can be crawled according to Allow/Disallow rules; no preferences are implied for resources that are disallowed.
draft-ietf-aipref-attach-05 §3.1
aipref の枠組みでは、「取らせない」と「取らせた上で使い道を指定する」が別々の判断になるわけです。
3つの分類を、お店の言葉に置き換える
ラベルだけ見ると「AI」か「検索」かの二択に見えます。定義を読むと、線はもっと細いところに引かれています。
| 分類 | 原文の定義（一文） | お店のページで言うと |
|---|---|---|
| train-ai | "Using an asset to modify the learned parameters of a generative AI model." | メニュー説明文や店のブログの文章が、生成AIモデルの学習に使われ、モデルそのものに取り込まれる |
| ai-use | "Using an asset as input to a generative AI model, where the asset is not directly provided by the user." | 客が貼ったわけではない店のメニューページやお知らせを、生成AIが答えを作る入力として読み込む |
| search | "Using an asset in an application where the primary purpose of the application is to select assets and direct users to the location of those assets." | 店のページが検索結果に選ばれ、客がリンクから店のページへ来る |
右の列は、原文の文言を店舗サイトに当てはめた私たちの解釈です。どのサービスのどの画面がどの分類に当たるのか、vocab-08 は製品名を挙げて書いてはいません。
表に入りきらない補足が、分類ごとに一つずつある。
train-ai は、非生成タスクだけに使うモデルの学習を含まない。vocab-08 §4.1 の一文です。
The training of models that are used to perform exclusively non-generative tasks is not included in this category, even if the model is capable of generative tasks.
draft-ietf-aipref-vocab-08 §4.1
「生成AIモデル」の定義も、分類・ランキング・スコアリングに使うモデルを含まない。train-ai=n と書いても、ランキング用モデルの学習はこの宣言の対象外という読み方になります。
ai-use には未決の論点が残ります。客が店のURLをAIに貼って「このお店はどう？」と聞く場面が、「直接」に入るかどうか。お店にとって一番気になるところでしょう。
NOTE: Issue 249 addresses the question of whether "direct" includes referencing assets, by URL or other means.
draft-ietf-aipref-vocab-08 §4.2
search には条件が付きます。出力に元の場所への直接の参照かリンクがあること。抜粋を出すなら、利用者が結果の関連性を判断する助けとして出すこと。要約の生成は含まない、という明記もある。
This category does not include the use of assets to generate summaries.
draft-ietf-aipref-vocab-08 §4.3
タイトルや抜粋の表示、翻訳・文字起こし・読み上げといったアクセシビリティのための変更は search に入ります。インバウンドのお店にとっては、外国語で探す客に翻訳した抜粋を見せる使い方も、search の許可に含まれるということ。
-07から-08で変わったところ
8月19日付の-07では、分類は AI Model Training（train-ai）と Search（search）の2つでした。-08 では前者が AI Training に改名され、ai-use が加わった。search が他の分類より優先されるという一文も、-08 で足されたものです。
学習済みモデルを配布するとき宣言も一緒に伝える、という§3.3も新設されました。この節を残すかどうかは、Issue 245 でまだ議論が続く。
「検索はOK・学習はNG」と書くと、どう読まれるか
vocab-08 の定義では、「検索はOK・学習はNG」は字面どおりには成立しません。
attach-05 §1.2 の例は、全ページを取得可にした上で、学習にだけ n を付ける形。
User-Agent: *
Allow: /
Content-Usage: train-ai=n同じ宣言は、HTTP レスポンスのヘッダー Content-Usage: train-ai=n でも送れます。attach-05 の参考文献は-07で、例に出てくるのも train-ai だけ。
ここに-08の分類を当てはめ、「検索はOK、学習もAIの入力もNG」と書くなら、例えば次の形になります。草案の文法に沿って私たちが組んだ例で、仕様書に載っている例ではありません。
User-Agent: *
Allow: /
Content-Usage: train-ai=n, ai-use=n, search=ysearch=y は、検索のための学習まで許す
search を許すことには、検索アプリ内部の処理を許すことが含まれます。その処理にはAIモデルの学習も入る、と §4.3 は書く。
Allowed processing therefore includes the training of AI models using the assets and the use of those models provided that the resulting models and their outputs are used exclusively in ways that meet the above conditions regarding referencing and excerpts.
draft-ietf-aipref-vocab-08 §4.3
その上で、search は train-ai と ai-use を含む他の分類より優先されます。
素直に読めば、train-ai=n が働くのは検索の条件から外れた使い方だけ。ここでいう検索の条件は、元ページへのリンクを返す、抜粋は関連性の判断のため、要約はしない、の3点です。
この草案が線を引いているのは「学習させるかどうか」ではない。出力が、客を元のページへ案内する形に留まるかどうかだ。お店にとっては、AIに学習されるかより、客がリンクを踏んで店のページに来るかのほうが商売に近い。そう考えると、この線の引き方には筋があります。
書き損じると「不明」になる
値の書式は HTTP の Structured Fields の辞書型。大文字と小文字は区別されます。キーに大文字が入ると辞書の解析が失敗し、宣言は「不明」になる（vocab-08 §6.5.1）。Train-AI=n は効かない。同じキーを2回書けば後の値だけが残り、y と n 以外の値も「不明」扱い。
その「不明」をどう扱うかについて、vocab-08 は立場を取らない（§5）。何も書かないのと書き損じるのとは、受け取る側から見れば同じ結果になり得ます。
食い違いの扱いは、Allow / Disallow と逆向きだ。Allow / Disallow は、食い違うと許可側が勝つ。同じパスで食い違う Content-Usage 行は vocab の手順で扱う、と attach-05 は区別する。vocab-08 の組み合わせの手順では、どれか一つでも disallow なら disallow です。
パスごとに書き分ける例
attach-05 §3.4 の Figure 2 は、パスで宣言を分ける例。
User-Agent: *
Allow: /
Disallow: /never/
Content-Usage: train-ai=n
Content-Usage: /ai-ok/ train-ai=y
User-Agent: ExampleBot
Allow: /
Content-Usage: train-ai=yExampleBot 以外のクローラーは1つ目のグループに従います。/never/ 以下は取得できず、宣言も付かない。/ai-ok/ 以下は train-ai=y、それ以外は train-ai=n。ExampleBot は2つ目のグループで、全体を取得できて train-ai=y。店のサイトなら、メニューのページとスタッフ写真を載せたブログで宣言を分けられる設計です。
まだ「書けば効く」段階ではない
草案が決めているのは宣言の書き方まで。守るかどうかは、受け取る側に委ねられます。
Its contents DO NOT REFLECT CONSENSUS of the Working Group either in whole or part.
draft-ietf-aipref-vocab-08「Note to Readers」
この仕様は宣言の遵守を保証せず、受け取る側には従うかどうかの選択がある（vocab-08 §3.2）。受け取る側が処理するのは、自分が実装した方法で届いた宣言だけです（§3.1）。どのクローラーが Content-Usage 行を読むのかは、vocab-08 にも attach-05 にも書かれていません。
時間差もあります。attach-05 によれば、クローラーは robots.txt を最長24時間キャッシュできる。書き換えは、過去に取得したページには遡って効きません。更新後の robots.txt と対象のページを取り直して、初めて反映されます。
Internet-Draft は最長6か月で失効する作業文書で、vocab-08 の失効日は2027年3月18日。分類の名前も定義も版ごとに動く。-07から-08の変化がその実例です。
始めるなら、ここから
- robots.txt を「取得」と「利用」の2列で書き出す：今ある Allow / Disallow は取得の列です。メニュー、予約、ブログ、写真とページ群ごとに、「検索に出したいか」「AIの入力にされてよいか」を表にしておく。草案が固まったとき、その表を書き写せば済みます。
- 「AI学習は拒否済み」とまとめて報告しない：OpenAI の文書では、GPTBot の Disallow は基盤モデルの学習に使わないでほしいという意思表示です。ただしそれは、OpenAI が自社のボットについて定めた取り決め。報告には、どのベンダーのどのボットに何を伝えたかまで書きます。
- search=y が検索のための学習を含むと知った上で判断する：vocab-08 の定義では、search を許すと検索内部の学習も許すことになる。「検索はOK・学習はNG」のつもりで書くと、宣言と思惑がずれます。
- Issue 249 の行方を追う：客が店のURLを貼ってAIに聞く使い方が ai-use に入るかどうかは、ここで決まります。datatracker の vocab のページで、次の版の差分を確認してください。
robots.txt は長いこと、ボットの入口を開け閉めする扉でした。使い道は、扉の前に立つボットの名札で見分けるしかなかった。aipref が描いているのは、扉の内側に「持ち出した後の使い道」を共通の言葉で書いた札を下げる設計です。札の文言はまだ下書きで、読むかどうかも相手次第。それでも、何を許して何を許さないかを表に書き出すのに、草案の完成を待つ理由はありません。
参考資料
- IETF「A Vocabulary For Expressing AI Usage Preferences」draft-ietf-aipref-vocab-08 (2026年9月14日)
- IETF author-tools「draft-ietf-aipref-vocab-07 と -08 の差分」
- IETF「Associating AI Usage Preferences with Content in HTTP」draft-ietf-aipref-attach-05 (2026年8月19日)
- RFC 9309「Robots Exclusion Protocol」(2022年9月)
- OpenAI「Overview of OpenAI Crawlers」
- Cloudflare「Giving users choice with Cloudflare’s new Content Signals Policy」(2025年9月24日)
- MenuMenu「その「llms.txt 200 OK」、中身はHTMLです｜日本の飲食・宿泊・小売30サイト実測」(2026年9月10日)
株式会社MenuMenu 代表取締役
ソフトウェアエンジニアであり、UI・UXデザイナー。2012年からシリコンバレーと韓国でプロダクトをつくってきました。SEO・MEO・AEOの専門家として、訪日観光客と日本のローカルビジネスをつなぐMenuMenuを自ら設計・開発しています。
プロフィールを見る →Next
「見つかっているか」を、数字で確かめませんか。
AIの答え、検索、地図。どこで見つかっていて、どこで見つかっていないのか。まずはサイトを点検し、現状を数字にしてから次の一手を決められます。