AIクローラーは「拒否」から「取引」の時代へ。課金の系譜とMarkdown for Agentsのトークン削減効果を検証

生成AIの普及により、WebコンテンツとAI企業の関係は大きく変わりました。

生成AIやRAGの普及により、ユーザーが情報元サイトを訪問せずにAIの回答だけで完結するようになりました。
かつて、検索エンジン等にクロールさせる代わりに検索流入をもらうことで成り立っていたWebサイトのマネタイズ方式は、AIがコンテンツを取り込んで回答を生成するようになったことで崩れつつあります。

その象徴的な数字が、Cloudflareが公表している「Crawl-to-refer比率」(クロール数と参照流入の比率) です。
10年前のGoogle検索では、約2ページのクロールにつき1人がサイトに訪問していました。
これが2024 年末には6対1、2025年半ばには18対1まで悪化したとCloudflareは報告しています。
AIチャットボットに至っては、この比率がさらに桁違いに大きいとされます。

クロールされるだけで、トラフィックはほとんど返ってこない、これが「AIのタダ乗り」問題です。

これに対して、Webサイト側は、ここ数年で急速にAIへのコンテンツ提供の仕組みを構築してきました。

今回は、この問題に対してWebサイト側がどのような課金・制御の仕組みを構築してきたのかを時系列で整理します。
また後半では、AIを「歓迎」するためのCloudflareのMarkdown for Agentsを実際に試してみます。

ここでは、これまでに Web サイトが、「AIのタダ乗り」問題に対し、どのような対策を行ってきたのか、振り返りたいと思います。

フェーズ 1: robots.txt

生成 AI ブーム初期 (2023年頃) には、従来より使われているrobots.txtにより、OpenAIのGPTBotなど、特定のクローラーをオプトアウトする手法が取られました。

robots.txtは、検索エンジンが主流だった頃から使われているもので、クローラーに対し「このパスは見ないでほしい」と伝えるための仕組みですが、これに従うかどうかはクローラー側の「善意」に依存しています。

しかし、この方法には根本的に下記のような限界がありました。

• ⚠️内容を無視されても検知・防止できない
• ⚠️拒否または (無償での) 許可しかできず、「対価と引き換えに許可」という選択肢は仕組み的にできない

これまで多くの Web サイトは、コンテンツ自体ではなく、そのページに表示される広告で収入を得ていました。
「コンテンツ自体を売る仕組みを整えること」が、次世代への課題となりました。

フェーズ 2: 大手の個別ライセンス契約など

2023年半ばから、大手メディアがAI企業と個別にライセンス契約を結ぶ動きが始まりました。2023年7月のAP通信とOpenAIの契約を皮切りに、Axel Springer (2023年12月)、Reddit (2024年2月にGoogleと)、News Corp (2024年 5月) と続きます。

一方で、交渉が決裂した側は法廷に向かいました。ニューヨークタイムズは2023年12月にOpenAIとMicrosoftを著作権侵害で提訴しています。「契約するか、訴えるか、ブロックするか」の三択が並存していたのがこの時期です。

このような契約は大手にしか行えず、零細サイトや個人サイトには縁のない話でした。
こういった背景から、TollBit等のスタートアップ企業が、AI企業とWebサイトの間にたち、AIクローラーのアクセス単位で課金を仲介するビジネスを始めました。
「クローラー課金」という概念はこの頃生まれているようです。

フェーズ 3: WAF等での強制ブロック

2024年中頃からは、robots.txtの限界を受け、WAFやCDN等では、AIクローラーのアクセスを、振る舞い検知などを用いて一律でブロックするような機能が普及してきました。
2024年7月には、CloudflareがAIクローラーをワンクリックで一律ブロックする機能をリリースしました。無料プランを含む全ユーザーが対象で、AIクローラーのブロックが一気に一般化する契機となりました。

これによりAIクローラーのブロックについては実現できましたが、一方、そのWebサイトがAIでの検索結果や生成された回答でのリンクに現れる機会まで失う事になるジレンマが課題になりました。

フェーズ 4: Pay Per Crawlのアプローチ

2025年7月、Cloudflareは、「CloudflareがWebサイト管理者に代わってAIクローラーから料金を徴収する機能」をプライベートベータとして発表しました。
これが「クロールへの課金 (Pay Per Crawl)」を汎用的な仕組みとして実装した最初の試みです。

技術的に面白いポイントは、HTTP ステータスコードの「402 Payment Required」の活用です。402はHTTP/1.1の仕様にて「将来の利用のために予約」と定義されていますが、約30年の間ほぼ使われてこなかったコードでした。

Pay Per Crawlのフローは下記です。

1. 1Web サイト管理者は、Cloudflare ダッシュボードで、AI クローラーごとに、「Allow (無料許可) / Charge (課金) / Block (ブロック)」を選択する
2. 2Charge に設定した AI クローラーが Web サイトにアクセスすると、Cloudflare は HTTP ステータスコード 402 と共に価格を提示する
3. 3AI クローラーが支払いに同意するヘッダを付けて再度リクエストすると、Web サイトのコンテンツが返される
4. 4決済は Cloudflare が代行し、Web サイト管理者に収益を分配する

さらに、課金をする上で重要な AI クローラーのなりすまし対策として、公開鍵暗号を用いたボット認証などの仕組みも整備されました。

フェーズ 5: 標準化の動き

Cloudflareのようなベンダーの仕組みとは別に、標準規格としてコンテンツのライセンス条件を記述する動きも生まれました。

2025年9月には、robots.txtやXMLファイルに、無償・要帰属・クロール課金・推論課金などのライセンス条件を記述できるRSL (Really Simple Licensing) が生まれました。
Reddit、Yahoo、Ziff Davis、Quora、O'Reilly Media、Medium、Fastlyなどが初期サポートを表明し、2025年12月に正式な標準仕様となりました。

決済手段についても、HTTP402を用いたオープンな決済プロトコルとして「x402」が登場しました。Coinbaseが策定したもので、ステーブルコインによる決済を前提としています。RSL 1.0も支払い方式としてx402を組み込めるようになっており、「条件の宣言 (RSL)」と「決済の実行 (x402)」という役割分担が形成されつつあります。

なお、HTTP402自体は現在もRFC9110上「将来の利用のために予約」のままです。
標準化を待たず、実装が先行している状態と言えます。

現在: Pay Per CrawlからPay Per Useへ

2026年7月、Cloudflareは、課金の単位をクロール回数から実際の利用へ移すPay Per Useへの方針転換を発表しました。

背景にあるのは、「クロールされた回数」と「コンテンツの価値」が一致しないという問題です。

AIクローラーは大量のページをクロールしますが、そのコンテンツが実際に回答の生成に使われるのはその一部です。逆に、一度のクロールで得たコンテンツが何百万回の回答に使われることもあります。クロール単位の課金は、価値の実態を捉えられていませんでした。

ここで気づくのは、Webサイト側のスタンスが少しずつ変わってきていることです。
フェーズ3までは、「勝手に持っていくAIからいかにコンテンツを守るか」という、いわばAIを敵視するスタンスだったのに対し、フェーズ4以降は、「コンテンツをいかにしてAIに買ってもらうか」というスタンスに変わりました。

AIがコンテンツを買ってくれるのだとしたら、Webサイト側は、どのような形でコンテンツを渡すのが最適なのか。
この問いに答えるのが、これから試すMarkdown for Agentsです。

ここまで見てきたように、WebサイトのAIクローラに対するスタンスは、「防衛」から「取引」に移っていきました。

これまでWebサイトは、人間の訪問者のため、人間が快適に読めるようにコンテンツを工夫してきました。これと同様にAIも正規の訪問者として捉え、AI が快適に読めるように「取引相手としてもてなす」機能として、Markdown for Agentsが登場しました。

AIにとって「快適に読める」とは、トークン効率です。
「トークン」は、AIが文章などを処理するときの最小単位 (言葉のパーツ) です。

人間向けのHTMLには、ブラウザ上での表示や動作を彩るための<div>などのタグやナビゲーションやスクリプト等が大量に含まれますが、AIにとっては意味をほとんど持たないノイズです。
一方、Markdownは「# 見出し」や「- 項目」のようなシンプルな記法で、文書に書式をつけるシンプルな記法です。

下記のように、同じ「Getting Started」という見出しをHTMLとMarkdownで表現した時、Markdownなら3トークンで済むところ、HTMLは14トークンを消費します。

### HTML
<h2 id="getting-started">Getting Started</h2>   → 14 トークン

### Markdown
## Getting Started   → 3 トークン

※トークン数は o200k_base (OpenAI系トークナイザ) での実測値です。モデルごとにトークナイザーは異なるため数値は多少変わりますが、傾向は同じです。

同じ「Getting Started という見出し」という情報に、HTMLは4.7倍のトークンを費やしています。
この差が、ページ全体で積み重なり、更にタグに付く id や class 等が増えるほど差は開いていきます。

トークンはAIにとってはコストそのものです。
売り手がコンテンツを工夫し、「取引相手」のコストを下げることは、そのコンテンツが選ばれ、使ってもらいやすくなることに直結します。

Cloudflare Markdown for Agents の機能概要

仕組みは HTTP の標準的なネゴシエーションです。
Claude Code などのコーディングエージェントは、リクエスト時に、すでにこの「Accept: text/markdown」を送っており、既存のツールがそのまま恩恵を受けられるようになっています。

有効化する

Cloudflare Markdown for Agentsの有効化は簡単です。

Cloudflareダッシュボードでドメインを選び、[AI Crawl Control] > [Overview] から、[Markdown for Agents] を有効にするだけです。
(利用にはProプラン以上が必要です。)

これだけで、Cloudflareを中継するWeb通信について、Cloudflare Markdown for Agentsが利用できるようになります。

検証のためのWorkerの実装

弊社のコーポレートページを使って検証を行います。

弊社のコーポレートサイト本体で直接有効化すると本番環境に影響が出るため、今回は検証用の別ゾーンを用意しました。

具体的には、受け取ったリクエストをそのままwww.accelia.netに転送し、その応答を返すだけのWorkerを実装し、カスタムドメインを割り当てています。
このWorkerのゾーン側でMarkdown for Agentsを有効化することで、本番サイトのコンテンツを使いながら、本番には影響を与えずに挙動を確認できます。

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    url.hostname = "www.accelia.net";
    url.protocol = "https:"
    url.port = "";
    return fetch(new Request(url, request), { redirect: "manual" });
  }
};

動作確認

ゾーンに対して有効化できたので、実際に検証してみます。

まずは通常のブラウザ相当のリクエストです。
当たり前ですが、HTMLが応答されていますね。

$ curl -H "Accept: text/html" https://test.example.com/
<!doctype html>
<html>

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no" />

                <!-- All in One SEO 5.0.2 - aioseo.com -->
                <title>アクセリア株式会社 - CDN・セキュリティ・DXでビジネスを支援</title>
        <meta name="description" content="アクセリアはWebシステム、ネットワーク、サイバーセキュリティの開発・運用・保守までトータルサポート。企業のDX
化やサイバーレジリエンスに関する課題解決は、20年以上の純国産CDN開発・運用のノウハウを持つアクセリア株式会社へお任せください。" />

...

続いて、AI相当のリクエストです。
HTMLと同一の内容がMarkdownに変換されて応答されています。

$ curl -H "Accept: text/markdown" https://test.example.com/
---
description: アクセリアはWebシステム、ネットワーク、サイバーセキュリティの開発・運用・保守までトータルサポート。企業のDX化やサイバーレジリエンスに関す
る課題解決は、20年以上の純国産CDN開発・運用のノウハウを持つアクセリア株式会社へお任せください。
title: アクセリア株式会社 - CDN・セキュリティ・DXでビジネスを支援
---

[アクセリアの強み](https://www.accelia.net/reason/)

...

トークン効率の確認

続いて、このHTMLとMarkdownにてAIに与えたとき、どの程度のトークンを消費するかを比べて見ます。

下記のような、標準入力のデータのトークン数を表示する簡易コードを書き、実際に応答を与えてみます。

### tokens.js

#!/usr/bin/env node

const { encode } = require("gpt-tokenizer/encoding/o200k_base");

const chunks = [];
process.stdin.on("data", (c) => chunks.push(c));
process.stdin.on("end", () => {
  console.log(encode(Buffer.concat(chunks).toString("utf8")).length);
});

まずは HTML (ブラウザ相当リクエスト) の応答です。

$ curl -H "Accept: text/html" https://test.example.com/ | node tokens.js
61958

次に、Markdown (AI相当リクエスト) の応答です。

$ curl -H "Accept: text/markdown" https://test.example.com/ | node tokens.js
12151

他のページもいくつか比べてみると、下記のようになりました。

www.accelia.net 上のパス	トークン数HTML	トークン数Markdown	削減率
/	61958	12151	80.4 %
/company_info/outline/	57596	9728	83.1 %
/column/cloudflaretips/9372/	63136	12838	79.7 %
/column/cloudflaretips/9349/	65947	13838	79.0 %
/column/cloudflaretips/9236/	72675	15759	78.3 %

弊社のコーポレートページの場合、概ね80%のトークン削減効果があるようです。

ただし、ここで比較しているHTML側はcurlで取得した生のHTML全体で、<script>や<style>の中身も含まれています。
実際のAIクローラーの中には本文抽出処理を行うものもあるため、すべてのケースでこの削減率がそのまま当てはまるわけではない点は補足しておきます。
それでも、何の前処理も持たないクライアントがそのまま取得した場合の差としては、十分に大きな数字です。

導入コストがほぼゼロ

設定はCloudflareダッシュボードのトグル 1 つで、オリジン側の改修は一切不要でした。
(今回は検証のためのWorkerを実装していますが、すでにCloudflareを利用していれば、トグルのみで有効にできます。)

AI向けにコンテンツを最適化する手法としては、/llms.txtやMarkdown版のページを別途用意する方法も広く行われています。
ただし、これらは「AI向けのコンテンツのメンテナンスする」という追加コストを伴い、更新漏れによる本文との乖離も起こりえます。
Markdown for AgentsはCloudflareでの動的変換となるので、原本はHTML一つのままで済みます。
CDN利用の利点が本当によく出ている機能だと思います。

トークン削減効果

検証では、弊社コーポレートサイトで約80%のトークン削減効果が確認できました。
これは公式で言及されている数値とも一致し、誇張や特殊ケースではなく、実態に近い値であることが確認できました。

▶Cloudflareブログ：エージェント向けマークダウンの導入

今回は、AIクローラに対するWebサイト側の対応を時系列で整理し、その最新形としてMarkdown for Agentsを試してみました。

WebサイトのAIに対する対応は、「拒否」から始まり、様々な仕組みを整えながら「歓迎」する方向に変わってきました。
今回試したMarkdown for Agentsは、まさにその最先端にある機能です。

今後のWebコンテンツはどうなっていくのでしょうか？
弊社ではCloudflareを取り扱う立場から、引き続き実際に手を動かしながら追いかけていきます。