コンテンツライセンスとは？AI学習だけ断る3つの合図と収益分配の今【図解】

「うちの記事、AIに勝手に使われているんじゃないか」。社内でそう聞かれて、答えに詰まったことはないでしょうか。

止めたいのは、モデルの学習に使われることなのか。それとも、AI検索の答えの中に出ること自体なのか。ここが整理できていないと、robots.txtのたった1行で、自社を丸ごと閉じてしまうことになりかねません。

この記事は、その手前で止まっている方に向けて書きました。専門用語は出てきたその場で言い換えます。最後は「自社ならどの初期値を選ぶか」まで決められる形にしています。

この記事では、あるメディア運営会社の2人と、専門家の会話をはさみながら進めます。高梨課長（実務担当）は「誰がどう設定するのか」を、大森部長（事業責任者）は「収益にどう効くのか」を聞く役です。鈴木さん（AIO/SEOの専門家・本誌監修）が答えます。

01AI対策として、コンテンツのライセンスと収益分配は何から考えるんですか？

高梨課長

高梨課長の発言

記事がAIに使われている、という話は分かるんです。ただ、何をどう設定すればいいのかが見えなくて。

鈴木さん

鈴木さんの発言

最初にやるのは、設定を書くことではないんですよ。「止めたいのは、どの使われ方か」を分けるところからです。同じ1台のクローラーが取りにきていても、その先の使い道は別々ですから。

AIクローラーが対価なくコンテンツを集めていく状態に対して、業界側からの反応が具体化してきました。robots.txtを拡張する動きと、クロールそのものに課金する動きが、続けて出てきています。

この記事が土台にする一次情報は2つです。Cloudflareの公式発表と、RSL（Really Simple Licensing）標準。どちらも公開されている文書で、誰でも読めます。

主な動きは3つです（出典: Cloudflare公式、RSL Collective）。

3つはバラバラに出てきたように見えますが、並べると同じ方向を向いています。サイト側が言えることが、段階的に増えているという方向です。

02これまでのrobots.txtは、AI検索の時代に何が足りないんですか？

従来のrobots.txtは、クローラーの巡回を許可するか拒否するかの二択しか表現できませんでした。検索エンジンだけが相手だった時代は、それで十分でした。取りにくる目的が、ほぼ一つしかなかったからです。

いまは事情が違います。検索インデックスを作るために取りにくることもあれば、AIの答えをその場で組み立てるために取りにくることもあり、モデルを鍛えるために取りにくることもあります。同じクローラーであっても、目的が異なる場合があるわけです。

ところが二択の窓口では、どの目的についての回答なのかを示せません。「拒否」と書けば全部が閉まり、「許可」と書けば全部が開きます。ここを解こうとする仕組みが、2025年後半に相次いで登場しました。

03search・ai-input・ai-trainは、AI検索対策としてコンテンツをどう扱う合図なんですか？

Cloudflareは、robots.txtに「Content-Signal」という機械が読める語彙を追加しました。コンテンツの3つの利用目的を、個別に表明できる仕組みです（出典: Cloudflare公式）。

言葉が硬いので、身近なものに置き換えてみます。

ai-inputだけ補足します。RAG（検索してから答えを作る仕組み）は、AIがその場で外部の文章を読みにいって答えに反映する動きです。覚えるのではなく答えるたびに読みにくる点が、ai-trainと違います。

3つのシグナルは、それぞれyes・noで表明します。記述はrobots.txtのUser-agentグループの中に置きます（出典: Cloudflare公式）。検索は許可し、学習利用を拒否し、ai-inputについては意思表示しない場合の書き方は次のとおりです。

User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /

ここで大事なのが、書かなかった項目の扱いです。ai-inputを記述しないことは、拒否ではなく「選好を表明していない」状態を意味します（出典: Cloudflare公式）。

04Cloudflareの既定値は、うちのコンテンツのAI対策にも関係あるんですか？

関係があります。自分で設定した覚えがなくても、です。

この方針は、Cloudflareが管理するrobots.txtを提供している380万以上のドメインに、既定で適用されています（出典: Cloudflare公式）。設定内容は「Content-Signal: search=yes, ai-train=no」、つまり検索は許可・AI学習は拒否です。

ai-inputについては、顧客の意向が分からず推測したくないという理由から、Cloudflareはシグナル自体を配信していません（出典: Cloudflare公式）。前の章で見た「書かない＝表明していない」が、ここでそのまま効いています。

自社がいまどこまで言えているのかは、次の3点を見れば分かります。

05Pay Per Crawlは、AI検索のクロールにコンテンツの対価を請求できるということですか？

大森部長

大森部長の発言

断るかどうかの話は分かった。それで、使われた分の対価を取る、という話はどうなっているんですか。

鈴木さん

鈴木さんの発言

そこも動き始めています。ただ、まだ完成した仕組みとして提供されているわけではない、というのが正直なところです。段階を分けてお話ししますね。

Cloudflareは2025年7月1日、「Pay Per Crawl」の非公開ベータを発表しました（出典: Cloudflare公式）。パブリッシャーがAIクローラーへのアクセスを、許可・課金・ブロックの3択から選べる仕組みです。

料金は、サイト全体で統一された1リクエストあたりの価格として設定します。AIクローラーが課金対象のコンテンツにアクセスすると、HTTP 402（Payment Required）が返されます（出典: Cloudflare公式）。価格は「crawler-price」ヘッダーで通知される仕組みです。クローラー側は「crawler-exact-price」「crawler-max-price」ヘッダーで支払い意思を示すと、アクセスできます。

やり取りの順番は、思っているより単純です。

06クロールの回数で数えると、AI検索でのコンテンツの使われ方とずれるのはなぜですか？

その1年後にあたる2026年7月1日、Cloudflareは続きの投稿を公開しました。「Pay Per CrawlをPay Per Useへと形づくり始めている」という内容です（出典: Cloudflare公式）。

背景にあるのは、クロール回数と実際の利用量が一致しない点です。1ページが1回のクロールで数千の回答に引用されることもあれば、何度クロールされても一度も使われないこともあります（出典: Cloudflare公式）。

取りにきた回数は「どれだけ読まれたか」を表していません。ここがずれると、対価の根拠も揺らぎます。

ただし、この段階ではパートナーとの試行として紹介されており、完成した課金方式ではありません。「その方向で検討が進んでいる」までが、いま確認できている範囲です。

なお、特定のプラットフォームと個別に契約する形での収益分配も、同じ潮流の一例として動いています。Perplexityが2025年8月に発表した収益分配モデルは、人間の訪問・検索での引用・AIエージェントの行動という3種のトラフィックに応じて収益を分ける仕組みです。詳しくは別記事『Comet Plusの収益分配とは？対象になる3つのトラフィック』（AIOM-035）で解説しています。

07RSL標準は、コンテンツのライセンスと収益分配をAI検索最適化にどうつなぐんですか？

もう一つの動きが、業界標準としてライセンス条件を書く仕組みです。

非営利団体RSL Collectiveは、2025年9月10日にサンフランシスコで設立を発表しました（出典: RSL Collective）。オンラインクリエイターとパブリッシャーが、AIによる利用時に公正な対価を得られるようにすることを使命としています。

RSL標準の仕様バージョン1.0は、2025年12月10日に公式仕様として発行されました（出典: RSL Collective）。robots.txtに「License: [絶対URL]」というディレクティブを追加し、ライセンス条件を記述した文書の場所を宣言する方式です。

License: https://example.com/license.xml
User-agent: *
Allow: /

robots.txtに条件そのものを書き込むのではなく、条件を書いた文書の住所だけを置く。この形にすることで、細かい条件を別の場所で管理できます。

実装は2ステップです。先にライセンス文書を配置し、その後にrobots.txtから指し示します。

08RSLのライセンス文書には、AI検索でのコンテンツの扱いをどう書くんですか？

文書の最小構成は、次のようになります（出典: RSL Collective）。

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

<permits>要素で許可する活動を、<prohibits>要素で禁止する活動を列挙します。両方が存在する場合は、禁止の指定が優先されます（出典: RSL Collective）。どんな要素が使えるか、対価の条件をどう書くかは、RSL公式仕様に一覧があります。実装するときはそちらを直接お読みください。

この「重なったら禁止が残る」という決まりは、書く側にとっては安全側に倒れる設計です。書き漏らしよりも、書きすぎたときのほうが事故が小さくなります。

発表時点で、Reddit・Yahoo・O'Reilly Mediaを含む15組織が支持を表明しています（出典: RSL Collective）。内訳は、RSL Collectiveと標準の両方を支持する12組織と、標準のみを支持する3社（Fastly・Quora・ADWEEK）です。

09LLMOの観点で、うちのコンテンツはどの初期値から決めればいいんですか？

大森部長

大森部長の発言

仕組みは分かりました。それで、うちはどう決めればいいんですか。全部拒否しておけば安全、では駄目なんですよね。

鈴木さん

鈴木さんの発言

はい、そこは事業の形によって答えが変わります。判断の軸は2つだけです。AI検索経由の露出を取りにいくのか。そして、コンテンツ自体が商品なのか。この2つで、だいたい決まります。

大森部長

大森部長の発言

逆に言えば、その2つを決めないと設定は決まらないと。

鈴木さん

鈴木さんの発言

そのとおりです。設定の話に見えて、実は事業の方針の話なんですよ。

判断の軸は、AI検索経由の露出を取りにいくか、コンテンツ自体が商品かの2点です。この2つを縦横に置くと、自社がどこに立っているかが見えます。

10事業タイプごとに、AI検索でのコンテンツの初期値はどう変わるんですか？

立ち位置が決まったら、初期値の考え方に落とします。次の表は、WEBMARKSの見解として示す目安です。

この表は初期値の目安であり、法的効果や収益性を保証するものではありません。特にai-inputは、Cloudflare自身が推測を避けてシグナルを配信していない領域です（出典: Cloudflare公式）。書くか書かないかは、自社で決めたうえで判断してください。

11シグナルを出してもコンテンツの無断利用が止まらないなら、AI対策として意味はあるんですか？

ここは正直に書きます。

Cloudflareは、Content Signalsがスクレイピングに対する技術的な対抗手段ではないと明記しています（出典: Cloudflare公式）。RSLもrobots.txtでライセンス条件の所在を宣言する方式であり、条件を無視する事業者を自動で締め出す仕組みではありません（出典: RSL Collective）。

• できること: 利用目的別に、自社の意思を機械可読な形で残す
• できないこと: 意思に反する収集を技術的に止める

一方でCloudflareは、Content Signalsで表明した制限を権利の明示的な留保と位置づけています。根拠として挙げているのは、EU著作権指令（2019/790）第4条です（出典: Cloudflare公式）。法的な効果がどこまで及ぶかは法域や個別事情で異なるため、自社での判断は専門家に確認することをおすすめします。

12AI検索対策の担当者は、ライセンス方針を社内でどう決めていくんですか？

高梨課長

高梨課長の発言

決め方は分かってきました。ただ、これは私一人で決めていい話ではない気がしていて。

鈴木さん

鈴木さんの発言

そこは大事な感覚です。設定を書く人と、方針を決める人は別でいいんですよ。担当者がやるのは、決めるための材料を並べるところまでです。

高梨課長

高梨課長の発言

材料というのは、いまの設定と、選べる範囲ということですか。

鈴木さん

鈴木さんの発言

はい。その2つが並ぶと、決裁の場でその日のうちに決まることが多いです。

手順としては、次の順に進めると迷いにくくなります。

1. 現状のrobots.txt設定を棚卸しする。各AIクローラーへの許可・拒否設定を確認します。クローラーごとの記述テンプレートは、別記事『AIクローラーrobots.txt設定ガイド』（AIOM-014）を参照してください。
2. 利用目的別の意思を明確化する。検索表示は許可し学習利用は拒否する、といった方針を目的別に決めます。
3. Content Signals・RSLの導入可否を検討する。Cloudflare管理下ならContent Signalsは既定で適用され、RSLはrobots.txtへの1行追加で導入できます。
4. 個別プラットフォームとの収益分配契約も選択肢に入れる。標準化されたシグナルとは別の選択肢になります。
5. 導入後も採用状況の広がりを確認し続ける。どちらも登場して間もない仕組みで、対応するAI事業者の範囲は今後変化しうるためです。

13コンテンツライセンスのAI対策で、つまずくのはどこですか？

着手前の確認は、次のリストが目安になります。

• 自社サイトのrobots.txt設定を棚卸しした
• 検索・AI入力・AI学習それぞれへの利用方針を決めている
• 自社の事業タイプに対応する初期値を確認した
• Content Signals Policyの適用状況（Cloudflare利用時）を確認した
• RSL標準の導入可否を検討した
• 個別プラットフォームとの収益分配契約の可能性も把握している

この順に進めても、同じところで足を取られる方が多くいます。よく見かけるのは2つです。

14よくある質問

15まとめ｜今日から始める3つのこと

巡回の可否をまとめて扱ってきたrobots.txtが、目的ごと・対価つきのライセンス表示へ移っていく動きは、もう具体的な形になっています。いずれも発展途上の仕組みなので、まずはrobots.txtの現状棚卸しと、利用目的別の方針決定から始めることをおすすめします。