robots.txtが「取らせるか」だけでなく「使わせるか」を言えるようになる｜IETF AIPREFが分けた2つの層

robots.txtが「取らせるか」だけでなく「使わせるか」を言えるようになる｜IETF AIPREFが分けた2つの層

自社サイトのコンテンツがAIモデルの学習に使われることに懸念があり、AIクローラを一律でDisallowすることを検討している——そんな相談を受けるとき、必ず出てくる問いがあります。「クロールを止めれば、それで済むのか」という問いです。

止めればアクセス解析にAIクローラのアクセスは記録されなくなります。しかし、それは「使われない」ことと同じではありません。すでに取得済みのデータがどう扱われるかについて、robots.txtは何も言っていないからです。この記事では、IETF(インターネット技術標準を策定する団体)のAI Preferences(AIPREF)ワーキンググループが2026年に入って進めている拡張提案を手がかりに、「取得を止める」ことと「利用条件を伝える」ことがなぜ別の問題なのかを整理します。

30秒で要点

• IETF AIPREFワーキンググループは、robots.txtにContent-Usageという新しいルールを追加する提案を進めている。狙いは、取得(Acquisition)と利用(Usage)を明確に別の層として扱えるようにすること
• 語彙を定義するdraft-ietf-aipref-vocab-07(2026年8月19日付)は、AI Model Training(AIモデルの学習)とSearch(検索・要約以外の用途に限定)という2つの利用カテゴリを定めている
• 紐付け方法を定めるdraft-ietf-aipref-attach(2026年9月9日時点の最新版は-05)は、取得はAllow/Disallowルールが、利用はContent-Usageルールが担うという「二段構えの取り決め」を明記している
• 2026年9月9日時点でどちらもRFC(正式な標準文書)ではなく、IESGの評価にも入っていない段階のInternet-Draft(草案)である

なぜ「クロールを止める」ことが答えのすべてに見えてしまうのか

robots.txtは1994年に事実上の業界慣行として生まれ、2022年にRFC 9309として正式な標準になった仕組みです。そこで定義されているのはAllow(許可)とDisallow(禁止)というルールで、対象はクローラがそのページを取得してよいかどうかの1点に絞られています。

この設計が長く使われてきたため、多くの担当者は「robots.txtで制御できるのはクロールの可否だけだ」という前提を、意識せずに持っています。AIクローラへの懸念が出たときに「では止めよう」という判断にまっすぐ向かいやすいのは、この前提のもとでは選択肢がAllowかDisallowかの二択しかないからです。取得した後にそのデータがどう扱われるかという、利用側の意向を示す語彙がこれまでのrobots.txtには存在しませんでした。

取得と利用を分ける、二段構えの設計

draft-ietf-aipref-attach(RFC 9309を更新する提案として位置づけられており、"Updates: 9309 (if approved)"と明記されています)は、この状況に対して「取得(Acquisition)」と「利用(Usage)」を明確に別の層として扱う設計を提示しています。取得はこれまで通りAllow/Disallowルールが担い、利用はContent-Usageという新しいルールが担う——この二段構えの取り決めが、この提案の中心にある考え方です。

利用側の語彙を定義しているdraft-ietf-aipref-vocab-07は、現時点で2つのカテゴリを定めています。ひとつはAI Model Training(合成コンテンツを生成するAIモデルの学習済みパラメータを変更する用途)、もうひとつはSearch(アセットを選び出しユーザーをその所在へ導くことが主目的の用途で、コンテンツの要約生成は含まれません)です。学習に使わせたくないが検索での参照は構わない、あるいはその逆、といった意向を、この2カテゴリの組み合わせで表現できるようになる設計です。ただしこの語彙セクションはワーキンググループの合意をまだ反映していない("does not yet have consensus")と明記されており、カテゴリの数や定義そのものが今後変わる可能性があります。

重要なのは、この二段構えが単なる「機能追加」ではなく「取得を許可した上で、利用にだけ制限をかける」という、Allow/Disallowだけでは表現できなかった中間状態を扱えるようにする設計だという点です。従来のrobots.txtでは、取得を許可すれば利用の制御手段がなく、利用を止めたければ取得ごと止めるしかありませんでした。

この設計にも、境界と限界がある

ここで見落としやすいのが、Content-Usageが持つ効力の範囲です。draft-ietf-aipref-vocab-07は、preferences(利用に関する意向)が従われることを保証しないと明記しています。"An entity that receives usage preferences has a choice whether to follow those preferences."——preferencesを受け取った主体には、それに従うかどうかの選択権があるということです。さらに"Preferences are not a security mechanism."ともあり、Content-Usageはアクセス制御のようなセキュリティの仕組みではありません。Allow/Disallowが(それを守るクローラに対しては)取得そのものを技術的に止めるのに対し、Content-Usageは「意向を機械可読な形で伝える」だけの仕組みです。

もうひとつ押さえておくべきなのが、Content-Usageと Allow/Disallow の関係です。draft-ietf-aipref-attachは、利用preferenceがAllow/Disallowルールに従ってクロール可能なリソースにのみ適用され、Disallowされたリソースには利用preferenceが含意されないと定めています。つまりDisallowしたページにContent-Usageを書いても、そもそも取得されない以上その意向が参照される機会自体がありません。

また、同一パスに矛盾するContent-Usageが設定された場合の扱いにも非対称性があります。Allow/Disallowの競合は「より許可的な方が勝つ」(クロールを許可する方向に倒れる)のに対し、Content-Usageの競合は逆に「より制限的な方が勝つ」設計です。語彙側の仕様(draft-ietf-aipref-vocab-07)は、いずれかの意向表明が「不許可」を示せば結果は不許可になるとし、"This process ensures that the most restrictive preference applies."(このプロセスにより、最も制限的な意向が適用されることが保証される)と説明しています。取得側は許可に寄り、利用側は制限に寄る——この向きの違いを理解していないと、両方のルールを組み合わせたときに意図と違う結果になりえます。

一律ブロックという選択肢を、そのまま持ち続けてよいか

ここまでの整理を踏まえると、「AIクローラを一律でDisallowする」という判断そのものが間違っているわけではないことが分かります。取得を止めれば、その時点でAI Model TrainingにもSearchにも使われる余地がなくなるという意味では、一律ブロックは目的に対して確実な手段です。

問題は、この手段が持つトレードオフです。一律Disallowは、AI検索エンジン経由での参照・引用の機会も同時に失います。学習には使わせたくないが、検索での参照(引用元として名前が出る形)は構わない、というように用途ごとに意向を分けたい場合、現行のAllow/Disallowだけではこの粒度を表現できません。Content-Usageのような利用レイヤーの仕様が標準化されれば、「取得は許可しつつ、学習用途だけを制限する」という中間的な選択肢が技術的に表現可能になります。ただし前述の通り、この意向表明に法的な強制力はなく、あくまで相手の判断に委ねる仕組みである点は変わりません。

つまり、一律ブロックとContent-Usageは対立する選択肢ではなく、「確実性を取るか、粒度を取るか」というトレードオフの両端にあります。確実に止めたいなら一律Disallowが今のところ唯一の手段であり、用途ごとに意向を分けたいなら、標準化を待ちながらContent-Usageの動向を追う必要がある、という整理になります。

「新しい語彙ができた」と「対策が完了した」の間にある距離

新しい標準の提案を目にすると、「この仕様に対応すれば懸念が解消する」という受け取り方をしがちです。しかしContent-Usageが実際にできるのは「意向を機械可読な形で置いておく」ことまでで、相手がそれに従うかどうかは相手次第だとドラフト自身が明言しています。加えて、この提案自体がまだRFCではなく、IESG(IETFの標準化を最終承認する機関)による評価にも入っていない"I-D Exists"という段階のInternet-Draftです。仕様の細部は今後の議論で変わりうる状態にあります。

「新しい語彙が提案された」という事実と、「対応すれば解決する」という期待の間には、まだ埋まっていない距離があります。この距離を意識せずに「AIPREFに対応すれば安心」と判断してしまうことが、混乱の起点になりやすいところです。

確かなことと、まだ確かではないこと

確かなこと: AIPREFワーキンググループが、robots.txtに取得と利用を分けるContent-Usageルールを追加する提案を進めていること。語彙定義はAI Model TrainingとSearchの2カテゴリを設けていること。Content-Usageの効力はAllow/Disallowでクロール可能なリソースに限定され、preferencesに従う義務は受け手側にないとドラフト自身が明記していること。競合解決の向きがAllow/Disallow(より許可的な方が勝つ)とContent-Usage(より制限的な方が勝つ)で逆であること。

まだ確かではないこと: 語彙セクションがワーキンググループの合意を得ていないため、カテゴリの数や定義が今後変わる可能性があること。この提案が最終的にRFCとして承認されるかどうか、承認される場合の条項がどう変わるか。主要なAIクローラの運営企業がContent-Usageルールをどこまで尊重する方針を示すか(2026年9月9日時点で本記事が確認した範囲では、この点についての公式な言及はありません)。

自分でも試せる、最小の検証

自社のrobots.txtを開き、現在Allow/Disallowだけで表現しようとしている意向の中に、「取得は許可したいが利用は限定したい(またはその逆)」という中間状態が含まれていないか確認してみてください。含まれているなら、それは現行のAllow/Disallowだけでは正確に表現できていない意向であり、Content-Usageのような利用レイヤーの仕様が標準化された後に見直す対象の候補になります。

判断に迷ったときに立ち返る問い

「クロールを止めるかどうか」と「利用条件をどう示すか」を、同じ1つの判断として扱わないこと。 取得と利用は異なる層の問題であり、Allow/Disallowで取得を止めたとしても、それは利用に関する意向を示したことにはなりません。逆にContent-Usageのような利用レイヤーの仕様が使えるようになったとしても、それは強制力のある禁止手段ではなく、相手の判断に委ねる意向表明にとどまります。この区別を保ったまま、標準化の進捗を追っていくことが必要です。

この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。