2026年10月8日にRFC 9309とIETFのAIPREF attach-05/vocab-08本文を再確認した。robots.txtはuser-agent、allow、disallowでクローラーの取得範囲を示す標準であり、AIPREFのContent-UsageはAI Training、AI Use、Searchなどの利用意向をHTTPやrobots.txtへ付与する作業中の提案である。AIPREFはRFCではなく、受け手が従う義務やGoogleのランキング対応を確立していないため、取得制御、利用方針、契約・法務、受け手の採用を別層で判断する。
30秒で要点
robots.txtが示すのは主に取得できるかです。IETFのAI Preferences（AIPREF）ワーキンググループでは、取得後の利用意向をContent-UsageとしてHTTPヘッダーやrobots.txtへ関連付けるInternet-Draftが進んでいます。2026年10月時点で、これはRFCではなく、受け手へ法的な禁止を強制する仕組みでもありません。
draft-ietf-aipref-attach-05はHTTPヘッダーとrobots.txtへの関連付け方法を提案draft-ietf-aipref-vocab-08はAI Training、AI Use、Searchの語彙を定義する草案- Searchは元の場所へのリンクと関連性確認の抜粋を条件にし、要約生成を含めない
- 取得のAllow/Disallow、利用意向、契約・法務・相手の運用を別に判断する
1. 2026年10月時点の仕様状況
attach-05のDatatrackerページは、2026年8月19日付のInternet-Draftで、HTTPのContent-Usageヘッダーとrobots.txtのContent-Usageディレクティブを提案します。文書の状態はActive Internet-Draft、IESG stateはI-D Existsで、RFC 9309を更新する意図が記載されています。
vocab-08は2026年9月14日付の語彙草案です。ページには、語彙セクションはワーキンググループの合意を反映していないと明記されています。どちらも正式標準ではなく、改訂・置換・失効の可能性があります。
2. 取得と利用を二つの層に分ける
RFC 9309のRobots Exclusion Protocolは、robots.txtのAllow/DisallowでクローラがURIへアクセスできるかを表します。attach-05は、この既存の取得ルールと別に、取得できるコンテンツへ利用の意向を関連付ける方法を提案しています。表が収まらない場合は、横にスクロールできます
| 層 | 現行・提案の仕組み | 問い |
|---|---|---|
| 取得 | RFC 9309のAllow/Disallow | そのパスをクロールできるか |
| 利用意向 | Content-UsageのHTTP/robots.txt表現 | どの用途を許可・不許可と示すか |
| 実際の運用 | 受け手の実装、契約、法務 | 意向がどう扱われるか |
attach-05は、Content-Usageがクロール可能なパスに適用され、クロールできないパスには利用意向が関連付けられないと説明します。Disallowを書いたから利用条件まで伝わる、またはContent-Usageを書けば取得も止まる、という読み方はできません。
3. vocab-08が置く3つのカテゴリ
現行のvocab-08は、語彙セクションが合意前であることを留保したうえで、次のカテゴリを定義します。
表が収まらない場合は、横にスクロールできます
| カテゴリ | 草案の意味 | 注意点 |
|---|---|---|
| AI Training | 生成AIモデルの学習済みパラメータを変更する用途 | 学習・出力の契約とは別 |
| AI Use | ユーザーが直接提供していない資産を生成AIへ入力する用途 | 実装の内部詳細を定義しない |
| Search | 元の資産へ直接リンクし、関連性確認の抜粋を示す検索 | 要約生成は含めない |
Searchを許可する意向は、検索アプリ内の処理を条件付きで含み得ますが、一般のAIサービスがこの分類を採用するとは限りません。カテゴリ名を見て、学習・入力・要約・リンクの全サービスへ自動的に対応付けないでください。
4. 強制力と競合解決の境界
vocab-08は、受け手が利用意向に従うかどうかを仕様の外に置き、意向はセキュリティ機構ではないと説明します。複数の意向が競合する場合は、同じカテゴリで不許可が一つでもあれば不許可、許可だけなら許可、どちらもなければ未知という処理を提案しています。これは語彙の処理モデルであり、契約や法令を置き換えません。
したがって、学習を止めたい、検索リンクは許可したい、既に取得されたデータを削除したい、といった目的は別の判断です。robots.txt、利用意向、契約、削除請求、アクセス制御の欄を混ぜずに台帳へ置きます。
5. 本番導入の判断表
表が収まらない場合は、横にスクロールできます
| 目的 | 先に確認するもの | 草案だけで確定しないこと |
|---|---|---|
| 新規クロールを止める | robots.txt、対象User-Agent、ログ | 保存済みデータの利用停止 |
| 利用意向を伝える | 相手がContent-Usageを読むか、仕様版、ヘッダー/robots.txt | 相手が従う義務、法的効果 |
| 検索参照は残す | サービスのリンク・抜粋・要約の定義 | Searchカテゴリを採用する保証 |
| 契約・法務で制限する | 契約、規約、法域、保存・削除手続 | I-Dでの解決 |
新しいヘッダーやディレクティブを置く場合も、まず相手の公式対応、変更を戻す手段、監視対象を確認します。非対応のクローラには、機械可読な意向が届かない可能性があります。
6. 最小検証と失敗例
自社のrobots.txt、対象User-Agent、取得ログ、利用目的を一つの表にします。取得を許可したいが学習は不許可、検索リンクは許可したいが要約は不許可、といった意向を記録し、現行の仕組みで表現できるかを確認します。AIPREF対応を名乗る相手が、どの版の草案をどう解釈するかも質問します。
- vocab-07の古いカテゴリを現行仕様として固定する
- Internet-DraftをRFCや法的禁止機能と書く
- Content-Usageを置けば、すべての受け手が従うと考える
- Disallowしたパスの利用意向が必ず伝わると考える
- SearchカテゴリをAI要約や学習の許可と同一視する
7. 取得と利用、仕様と契約を分けて記録する
AIPREFは、取得と利用の意向を別層で表す標準化作業です。2026年10月時点のattach-05とvocab-08はワーキング文書で、強制力や主要サービスの対応を保証しません。robots.txtの取得制御、Content-Usageの意向、受け手の実装、契約・法務を分け、仕様が更新されたときに再確認できる台帳を残してください。