robots.txtは長らく、「クロールを許可するか、拒否するか」という二択の意思表示を担ってきました。しかし生成AI時代に入り、その前提は大きく揺らぎます。問題は「取得されること」ではなく、「取得されたデータがどのように利用されるか」へと移行したからです。拒否か容認かではなく、「条件付きで許可したい」「対価を伴って流通させたい」というニーズが顕在化しました。こうした要請に応える形で登場したのが、robots.txtを起点に利用条件の提示とライセンス取得を機械可読で扱う規格、RSL 1.0（Really Simple Licensing）です。 結論から言うと、クローラー制御は「Disallowで拒否する」だけの時代から、「利用条件を提示し、同意（ライセンス取得）を前提に許可する」方向へシフトしています。robots.txtは引き続き入口として有効ですが、RSL 1.0のように「何に使ってよいか/だめか」「必要な対価」「遵守すべき条件」を示せる仕組みが、AIクローリングに対する現実的なオプションになりつつあります。RSL 1.0はrobots.txtに利用条件指定（License Directive）を追加し、クローラーにライセンス文書の取得と遵守を求めます。 robots.txtは「Robots Exclusion Protocol（REP）」として標準化されており、クローラーがサイト所有者の意思を参照するための規約です。IETFのRFC 9309では、robots.txtがクローラー向けの“指示”を提供する仕組みとして仕様化されています。つまり、認証・認可のような強制力のあるアクセス制御そのものではありません。
結論
robots.txtの基本
押さえておきたいポイント
- robots.txtは「User-agent」と「Allow/Disallow」のルール群で構成される
- 適用範囲は、同一ホスト・同一プロトコル・同一ポートに限定される
- 多くのクローラーは遵守するが、守らないクローラーを技術的に止める仕組みではない
実務上は、検索エンジン向けのガイドとして使われることが多く、Googleもrobots.txtの配置場所や適用範囲、取得方法などをドキュメントで明確にしています。
「拒否」運用の限界
robots.txt中心の運用は、次のような場面で限界が出ます。
AI用途の粒度が足りない
たとえば「検索インデックスはOKだが、生成AIの学習や要約はNG」といった要件が増えています。しかしrobots.txtの基本ディレクティブはAllow/Disallowが中心で、用途別の条件を表現しにくいのが実情です。
守らないクローラーに無力
robots.txtは“拒否の意思表示”にはなりますが、HTTPレベルで遮断する仕組みではありません。悪質なスクレイパー対策としては、WAF、レート制限、署名付き配信、認証など別レイヤーが必要になります。
交渉・契約の入口になりにくい
本当に欲しいのは「使っていい。その代わり条件がある」という世界です。ところが従来のrobots.txtでは、条件（対価、利用範囲、保存期間、再配布可否など）を機械可読で提示しづらく、運用が個別交渉・メール・法務手続きに寄りがちでした。
注意
robots.txtは法的な契約書そのものではありません。とはいえ、サイト側が明確なポリシーを提示し、相手がそれを参照した上でアクセスしている状況は、後段の法的整理（契約・不法行為・不正アクセス等）で争点になり得ます。社内の法務・コンプライアンスとセットで運用設計するのが安全です。
RSL 1.0とは
RSL 1.0（Really Simple Licensing）は、robots.txtを拡張して利用条件とライセンスを機械可読で提示し、クローラーに「取得・遵守」を求めるための仕様です。報道ベースでも、RSLはrobots.txtを土台にしつつ、AIクローリングの利用条件・補償（支払い等）といった枠組みを整える狙いが説明されています。
robots.txtにLicenseを追加
RSLのガイドでは、RSL準拠のrobots.txtに利用条件指定（License Directive）を含め、RSLライセンス文書（またはフィード）のURLを指すことが求められます。さらに、そのディレクティブはユーザーエージェントに紐づかないグローバルな扱いとされています。
# robots.txt（例）
License: https://example.com/license.xml
User-agent: Googlebot
Allow: /
User-agent: *
Disallow: /private/「拒否」から「契約」へ
RSLの肝は、単に「来るな」ではなく、「来てよいが、こう使ってほしい（条件を守ってほしい）」を表現できる点です。これにより、出版社・EC・データ提供企業などが、AI/検索/提携など用途別に条件を設計しやすくなります。
導入の進め方
ここからが本題です。RSL 1.0の導入は「robots.txtを直す」だけで終わりません。運用まで含めて段階的に設計します。
1. 目的を分解する
まず、クローラーに対して何をしたいのかを分解します。
- 検索インデックスは許可したいか
- AI学習・要約・回答生成への利用を許可するか
- 許可する場合、対価や再利用範囲をどうするか
- 社内規約（利用規約/プライバシー/著作権方針）と整合するか
2. ライセンス文書を用意
RSLでは、robots.txtから参照されるライセンス文書（またはフィード）が前提になります。ここに「何を許可し、何を禁止し、どんな対価・条件が必要か」を定義します。法務レビューを必須にするのが現実的です。
3. robots.txtにLicenseを追記
RSLのガイドに従い、利用条件指定（License Directive）を追加します。URLは絶対URLで、ホストが異なってもよいとされています。
RSLは“契約の入口”を整えますが、守らない相手を技術的に排除する機能は環境依存になります。実務では次を組み合わせます。 運用で効かせるコツ 「結局どちらを使えばいいのか？」という疑問に答えるため、役割の違いを整理します。 RSLを入れるなら、利用規約・著作権ポリシー・API利用条件と齟齬がないようにします。例えば「robots.txtでは許可、規約では禁止」のような矛盾は、交渉・紛争時に不利になり得ます。 AI向けを締めつつ検索は維持したい場合、対象クローラー（User-agent）を分けたルール設計が重要です。Googleの解釈や適用範囲は検索セントラルのドキュメントで確認し、意図しないブロックを避けます。 REPではrobots.txtの適用範囲が「ホスト・プロトコル・ポート」に限定されるため、サブドメインや別ホストに分散した配信（画像CDN、静的配信、API）では個別に設計が必要です。 注意 RSLは比較的新しい仕様です。相手クローラーがRSLに対応していない場合、期待通りに「契約として機能」しない可能性があります。対応状況の確認と、非対応相手への技術対策（WAF等）を前提にしてください。4. 強制力は別レイヤーで補う
robots.txtとRSL比較
観点
robots.txt（REP）
RSL 1.0
主目的
クロール可否の指示
利用条件・ライセンス提示
表現粒度
Allow/Disallow中心
条件やライセンス取得を前提化
強制力
原則アドバイザリ
契約設計の枠組み（実効性は運用と組合せ）
想定相手
主に検索クローラー
AI/データ収集クローラーを含む
実務の論点
規約と整合させる
検索流入を落とさない
適用範囲を明確に
クローラー対策を整備しませんか？
RSL 1.0とrobots.txtを起点に、技術対策（WAF/レート制限）と契約・規約を整合させた運用設計まで支援します。現状のアクセスログを前提に、効く対策から段階的に進めましょう。
まとめ
- robots.txtはREPとして標準化された一方、アクセス制御そのものではなく“指示”に留まる
- 生成AI時代は「拒否」だけでなく「許可＋条件提示（契約）」のニーズが増えている
- RSL 1.0はrobots.txtにLicenseを追加し、ライセンス取得と遵守をクローラに求める枠組み
- 実効性は、相手の対応状況とWAF/レート制限等の運用設計で決まる
参考リンク
