RSL(Really Simple Licensing)とは?robots.txtでAIライセンスを設定する方法

RSL(Really Simple Licensing)とは?robots.txtでAIライセンスを設定する方法

この記事の結論: RSLはrobots.txtにLicense:ディレクティブを1行追加し、外部のXMLライセンス文書(license.xml)でAI利用の許可・禁止と課金条件(無料・属性表示・購読・クロール課金・推論課金)を機械可読に宣言する2025年12月に1.0が正式発行された業界標準である。Reddit・Yahoo・O'Reilly・BuzzFeedなど1500以上の組織が支持を表明しているが、GoogleはCloudflareのContent Signalsについて「効力はない」と明言しており、RSLも法的強制力を持つわけではない点は注意が必要だ。とはいえコンテンツの利用条件を機械可読な形で明示すること自体には一定の意味があり、AIクローラーとの交渉材料や訴訟時の証拠として運用する価値はある。

最終更新日: 2026年7月17日

はじめに

2025年9月10日、RSS(Really Simple Syndication)の共同開発者であるEckart Walther氏と元Ask.com CEOのDoug Leeds氏が非営利団体RSL Collectiveを設立し、「RSL(Really Simple Licensing)」という新しいWeb標準を発表した。その後2025年12月10日、技術運営委員会がRSL 1.0の正式仕様を公開し、Yahoo・Ziff Davis・O'Reilly Mediaなど幅広いパブリッシャー団体が策定に関与したと明らかにした。Reddit・BuzzFeedはローンチ時点からの早期採用者として名を連ねている。

これまでrobots.txtは「クロールを許可するか拒否するか」の二択しか表現できなかった。RSLはこの単純なAllow/Disallowモデルを拡張し、AI企業に対して「学習には使ってよいが検索には使うな」「クロールごとに0.015ドル支払え」といった、ライセンス条件・課金モデルまで機械可読な形でrobots.txtから参照できるようにする。本記事では、日本のサイト運営者がRSLを実際にどう実装し、AIクローラーへのライセンス表明・課金設計をどう組み立てるかを、robots.txtの記述例とlicense.xmlの構造を中心に解説する。なお、RSL自体に法的強制力があるかどうかは業界内でも見解が分かれており、本記事内でその点は都度明記する。

RSLとは何か

RSLは、パブリッシャーがAIクローラーに対してコンテンツの利用条件・ロイヤリティ条件を宣言するためのオープンなライセンス規格である。技術的には、robots.txt・HTTPレスポンスヘッダー・RSSフィード・HTML <link>要素のいずれかから、機械可読なXMLライセンス文書(license.xml)を参照させる仕組みになっている。

RSSが「コンテンツの配信形式」を標準化したのに対し、RSLは「コンテンツの利用条件」を標準化するという位置づけだ。開発者自身がRSSの共同開発者であることからも、この系譜は意識的に踏襲されている。

RSLが解決しようとしている課題は明確で、これまでAI企業によるクロール・学習利用に対してパブリッシャーが取れる手段は「robots.txtでブロックする」か「泣き寝入りする」の二択に近かった。RSLは「条件付きで許可し、対価を得る」という第三の選択肢を機械可読な形で提示する。

RSLの仕様(ライセンス種別・課金モデル)

RSL 1.0の仕様は大きく「利用種別(usage type)」と「課金モデル(payment type)」の2軸で構成される。

利用種別(usage type)

<permits>または<prohibits>要素にtype="usage"を指定し、以下のいずれかの値で許可・禁止を宣言する。

RSL 1.0では特にai-all・ai-input・ai-indexという粒度の細かい区分が追加され、「検索エンジンへの掲載は許可するが、AI検索アプリでの利用は拒否する」といった条件分岐が可能になった。

課金モデル(payment type)

<payment>要素のtype属性で課金方式を指定する。

<amount>要素で通貨と金額、<standard>要素で外部の料金体系ページを、<accepts>要素で決済方法を指定できる。この課金モデルの粒度は、CloudflareのPay Per Crawl(クロール単位の課金インフラ)やTollBit(AIクローラー向けライセンス仲介)が個別に提供してきた仕組みを、標準規格レベルで表現しようとする試みだと理解しておくとよい。

robots.txtへの記述方法(コード例)

RSLの導入で実際にrobots.txtに追加するのは、基本的にLicense:ディレクティブ1行だけだ。

# サイト全体に適用するRSLライセンス
License: https://example.com/rsl-license.xml

User-agent: *
Allow: /

User-agent: GPTBot
Allow: /

複数のライセンス文書を宣言することも可能で、User-agentグループごとに個別のライセンスを紐づけることもできる。

# デフォルトのライセンス
License: https://example.com/rsl-license-default.xml

User-agent: *
Allow: /

# GPTBot向けには学習利用の課金条件を明示した別ライセンスを適用
User-agent: GPTBot
License: https://example.com/rsl-license-gptbot.xml
Allow: /

# 特定のAI検索クローラーは学習・インデックス双方を禁止
User-agent: PerplexityBot
License: https://example.com/rsl-license-noai.xml
Disallow: /

ポイントは、License:ディレクティブが「クロールの可否」を決めるものではないという点だ。Allow/Disallowは従来どおりRobots Exclusion Protocol(REP)のルールとして機能し、License:はその上に「もしクロールするならどの条件に従うか」を追加で提示する仕組みになる。したがって、RSLだけを設置してもクロール自体をブロックする効果はなく、必要であれば従来どおりAllow/Disallowの設定も併用しなければならない。

license.xmlの書き方

license.xmlはRSLの中核となる機械可読ライセンス文書で、ルート要素<rsl>の中に、対象URLごとの<content>要素、その中に条件を定義する<license>要素を配置する。

基本構造

<?xml version="1.0" encoding="UTF-8"?>
<rsl xmlns="https://rslstandard.org/rsl">
  <content url="https://example.com/blog/">
    <license>
      <!-- このURL配下に適用する条件 -->
    </license>
  </content>
</rsl>

例1: AI学習利用を全面禁止し、検索インデックスのみ許可する

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="https://example.com/">
    <license>
      <permits type="usage">search</permits>
      <prohibits type="usage">ai-all</prohibits>
    </license>
  </content>
</rsl>

例2: 属性表示を条件に検索・AI引用を許可する

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="https://example.com/articles/">
    <license>
      <permits type="usage">search</permits>
      <permits type="usage">ai-input</permits>
      <payment type="attribution">
        <standard>https://creativecommons.org/licenses/by/4.0/</standard>
      </payment>
    </license>
  </content>
</rsl>

例3: クロール単位で課金する(pay-per-crawl)

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="https://example.com/premium-reports/">
    <license>
      <permits type="usage">ai-train</permits>
      <payment type="crawl">
        <amount currency="USD">0.015</amount>
        <standard>https://example.com/pay-per-crawl</standard>
      </payment>
    </license>
  </content>
</rsl>

例4: コンテンツ種別ごとに条件を分ける

同一サイト内でも、通常記事は無償で検索利用を許可しつつ、有料会員限定コンテンツはAI学習利用を一律禁止する、といった使い分けが可能だ。<content>要素をURLパターンごとに複数並べればよい。

<rsl xmlns="https://rslstandard.org/rsl">
  <content url="https://example.com/free/">
    <license>
      <permits type="usage">all</permits>
      <payment type="free" />
    </license>
  </content>
  <content url="https://example.com/members/">
    <license>
      <prohibits type="usage">ai-all</prohibits>
    </license>
  </content>
</rsl>

license.xmlの妥当性については、公開時点でRSL側から公式のバリデーションツールが提供されているかは筆者調査の範囲では確認できなかった(2026年7月時点、未確認)。導入時はXMLとしての整形式チェックに加え、実際にRSL対応クローラーがどう解釈するかを別途確認することを推奨する。

実装手順(ステップ)

RSLを実際に自社サイトへ導入する場合の標準的な流れを示す。

ステップ1: ライセンス方針を決める コンテンツの種類(無料記事/有料コンテンツ/画像・動画/データセット)ごとに、AI学習・AI検索・通常検索それぞれに対して許可するか、対価を求めるかを整理する。全面禁止・条件付き許可・完全無償公開のいずれかに大別すると設計しやすい。

ステップ2: license.xmlを作成する 上記の書き方を参考に、サイトのルート直下、もしくは/rsl/のような専用パスにlicense.xml(ファイル名は任意)を配置する。コンテンツ種別ごとに<content>要素を分けて条件を記述する。

ステップ3: robots.txtにLicense:ディレクティブを追加する License: https://example.com/rsl-license.xmlの形式で、robots.txtのグローバルスコープまたはUser-agentグループごとに追記する。

ステップ4: 既存のAllow/Disallow設定と整合させる RSLのLicense:はクロール可否を制御しないため、学習禁止にしたいクローラーがいる場合は引き続きDisallowも設定する。RSLのライセンス条件とrobots.txtのクロール許可設定に矛盾がないか確認する。

ステップ5: HTTPヘッダーやHTMLへの併記を検討する RSLはrobots.txt以外に、HTTPレスポンスヘッダーのLinkヘッダーやHTMLの<link>要素からもライセンス文書を参照できる。動的コンテンツやAPI経由の配信がある場合は、robots.txtだけに頼らずこれらも併用すると発見性が高まる。

ステップ6: 対応クローラーとの実利用状況をモニタリングする RSLを設置しても強制力があるわけではないため、実際にAI企業側のクローラーがライセンス条件を尊重しているかどうかをアクセスログで継続的に確認する必要がある。

ステップ7: 定期的な見直し 仕様自体がまだ発行から日が浅く(2025年12月に1.0発行)、今後のマイナーバージョンで語彙が追加される可能性がある。半年〜1年ごとに仕様のアップデートを確認し、license.xmlを見直すことが望ましい。

Cloudflare Content Signals・llms.txtとの違い

AIクローラー制御の文脈では、RSLの他にCloudflareの「Content Signals Policy」や「llms.txt」もよく比較対象になる。それぞれ目的とアプローチが異なるため整理しておく。

Content SignalsはRSLを補完する関係にあると公式にも説明されており、Content Signalsが「search/ai-input/ai-train」という3区分でざっくり意思表示するのに対し、RSLはその先の「では対価はいくらか、どの支払い方式か」まで踏み込んで規定する点が最大の違いだ。llms.txtはそもそも目的が異なり、クロール制御やライセンス表明ではなく、LLMに読んでほしいコンテンツを案内するためのファイルである。

なお、2026年に入りGoogleがCloudflareのContent Signalsディレクティブについて「いかなるクローラー・LLMに対しても効果を持たない」と明言したと報じられている。この事実は、RSLについても同様の限界がある可能性を示唆しており、robots.txtに記述したからといって主要AI企業のクローラーが自動的に従うとは限らない点は認識しておく必要がある。あくまで現時点では、企業側が自主的に尊重するかどうかに委ねられている「意思表示レイヤー」だと捉えるのが実情に近い。

導入すべきか判断基準

RSLを導入すべきかどうかは、サイトの性質によって判断が分かれる。

導入を積極的に検討すべきケース

• 独自の一次情報・調査データ・専門解説など、AI学習素材として価値の高いコンテンツを保有している
• すでにAI企業との個別ライセンス交渉や、TollBitのような仲介サービスの利用を検討している
• 将来的に訴訟・交渉における「利用条件を明示していた」という証跡を残しておきたい

優先度を下げてよいケース

• コンテンツの大半が一般的な情報でオリジナリティが低く、AI学習素材としての希少性が乏しい
• サイト運営リソースが限られており、robots.txtやCloudflareの基本設定すら手が回っていない
• そもそも検索流入・AI経由の流入拡大を優先したいフェーズにあり、ブロック・課金より露出を優先したい

実務的には、まずCloudflareのContent Signals PolicyのようなシンプルなON/OFFレベルの意思表示から始め、収益化の見込める独自コンテンツについてのみRSLで課金モデルを設計する、という段階的な導入が現実的だろう。RSL単体で収益が発生する保証はなく、AI企業側の対応状況(2026年7月時点では主要アドオン企業の追従状況は限定的)を継続的にウォッチしながら判断することを推奨する。

よくある質問

Q1. RSLを設置すればAIクローラーのアクセスを完全にブロックできますか?

できません。License:ディレクティブはライセンス条件を提示するだけで、クロール自体の可否は従来どおりrobots.txtのAllow/Disallowで制御する必要があります。RSLと既存のクロール制御設定は別レイヤーとして併用するのが正しい理解です。

Q2. RSLに法的な強制力はありますか?

現時点では限定的です。RSLはあくまで機械可読な意思表示であり、AI企業側が自主的に尊重するかどうかに委ねられています。GoogleはCloudflareのContent Signalsについて「効果はない」と明言しており、RSLについても同様の課題があり得ます。ただし利用条件を明示していたという事実は、将来的な交渉や法的手続きの証跡として意味を持つ可能性があります。

Q3. license.xmlはどこに設置すればよいですか?

設置場所自体に厳密な規定はなく、robots.txtのLicense:ディレクティブから絶対URLで参照できる場所であれば構いません。サイトルート直下や/rsl/license.xmlのような専用パスに置くのが一般的です。

Q4. 既にllms.txtを設置している場合、RSLも追加すべきですか?

目的が異なるため併用が可能です。llms.txtはLLMに読ませたいコンテンツの案内、RSLはライセンス条件と課金モデルの宣言という別の役割を持ちます。両方を設置しても矛盾は生じません。

Q5. RSLの課金モデルを設定すれば実際にAI企業から支払いを受けられますか?

保証はありません。RSLは支払いの条件を宣言する仕組みであり、支払いの実行や徴収の仕組み自体は含んでいません。実際に対価を得るには、AI企業側がRSLの条件を認識し、個別に応じる必要があります。2026年7月時点でどの程度のAI企業が実際に支払いに応じているかは、本記事執筆時点の公開情報からは確認できませんでした。

Q6. RSLとCloudflareのPay Per Crawlは同じものですか?

異なります。Pay Per CrawlはCloudflareが提供する決済インフラそのものであるのに対し、RSLはライセンス条件を記述する標準規格です。RSLのpayment type="crawl"はPay Per Crawlのような課金モデルを標準の語彙で表現する役割を果たしますが、決済処理自体を担うものではありません。

Q7. 中小規模のサイトでもRSLを導入する意味はありますか?

コンテンツの独自性次第です。一般的な情報の再構成が中心のサイトでは優先度は低く、独自調査や専門性の高い一次情報を持つサイトであれば、意思表示としての価値はあります。まずは無料で設定できるため、リスクは低い施策と言えます。

Q8. RSL 1.0の仕様は今後変更される可能性がありますか?

あります。2025年12月に1.0が正式発行されたばかりの新しい標準であり、今後マイナーバージョンで語彙や機能が追加される可能性があります。導入後も仕様のアップデートを定期的に確認することが推奨されます。

Q9. robots.txtに複数のLicenseディレクティブを書いても問題ありませんか?

問題ありません。RSLの仕様ではUser-agentグループごとに個別のライセンス文書を指定でき、グループ固有のLicense:はグローバルな指定より優先されます。クローラーごとに異なる条件を提示したい場合はこの仕組みを利用します。

関連用語

• robots.txt
• llms.txt
• クローラー
• インデックス
• noindex
• 構造化データ
• Schema.org

関連記事

• Cloudflare Content Signals Policyとrobots.txtでAIクローラーを設定する方法
• Cloudflare Pay Per Crawlとは何か
• TollBitによるAIクローラーライセンスの仕組み
• robots.txtとllms.txtのSEOへの影響の違い
• llms.txtは必要か不要か GoogleとAgentic Commerceの視点
• AIクローラーとrobots.txtによるインデックス戦略
• SearchBotとTrainingBotのAllow/Blockと引用適格性
• LLMO完全ガイド