Cloudflare Pay per Crawl導入方法｜設定手順を完全解説

Cloudflare Pay per Crawl導入方法｜設定手順を完全解説

この記事の結論: Pay per CrawlはAI Crawl Controlの一機能で、ゾーン単位でAIクローラーに1リクエストあたり最低0.01ドルから課金できる。有効化にはドメインのAccount Settingsを「Visible」にすること、私設ベータへの応募、AdministratorによるStripe Connect専用口座の接続が前提になる。設定はAI Crawl Control > Settingsの「Pay Per Crawl」カードでデフォルト単価を決め、Crawlersタブでボットごとに「Allow（無料通過）」「Charge（課金）」「Block（遮断）」のいずれかを割り当てる形で行う。課金対象はHTTP 200が返った成功アクセスのみで、支払わないクローラーにはHTTP 402 Payment Requiredが返る。検索用クローラーをChargeやBlockにすると検索・AI検索双方のインデックスに悪影響が出ると公式が明言しているため、収益化と引用機会確保はトレードオフになる設計であることを理解したうえで導入すべきだ。

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

はじめに

CloudflareのAI Crawl Controlには、AIクローラーへの対応を「許可」「拒否」の二択から一歩進めて、実際に対価を要求できるPay per Crawlという機能がある。2025年7月1日に私設ベータとして発表され、HTTP 402というほとんど使われてこなかったステータスコードを応用し、コンテンツを取得しようとするAIクローラーに支払いを求める仕組みだ。無料で使われ放題にするか、完全にブロックするかの二択しかなかった状況に、「対価を払うなら通す」という第三の選択肢を提示している。

ただし、この機能を実際に自分のドメインで有効化しようとすると、公式ドキュメントは英語かつ複数ページに分散しており、「どの画面でどう操作すればよいか」を一続きで把握しにくい。ダッシュボードの階層、Stripe連携の落とし穴、クローラーごとのポリシー設定、課金が発生するタイミングなど、実装段階でつまずきやすいポイントは多い。

本記事では、当メディアがすでに公開しているCloudflare Content Signals Policyとrobots.txt AIクローラー設定や、Pay per CrawlからPay Per Useへの転換を報じた速報記事、Search/Agent/Training3分類の解説記事とは切り口を変え、「ニュース解説」ではなく「実際に自分のドメインで設定を完了させるための手順書」に徹する。前提条件の確認からStripe連携、価格設定、クローラー別ポリシーの割り当て、収益の現実性まで、公式ドキュメントの記載に沿って順を追って解説する。

→ 詳しくはAI検索最適化ガイド（AIO・AEO・GEO・LLMO）

Pay per Crawlとは何か、従来のブロックと何が違うのか

Pay per Crawlは、AI Crawl Controlの一機能として提供される、ゾーン単位で価格を設定することでAIクローラーによるコンテンツアクセスを制御・収益化する仕組みである。AIクローラーがコンテンツを取得しようとするたびに、リクエストヘッダーで支払い意思を提示してHTTP 200で成功するか、あるいは価格情報付きのHTTP 402 Payment Requiredを受け取るかのいずれかになる。

従来のAIクローラー対策は、robots.txtのDisallowやAI Crawl ControlのBlock設定による「全面拒否」か、何もせず無制限にクロールを許す「全面許可」のいずれかしかなかった。Content Signals Policyのような仕組みは「学習には使わせないが検索引用は歓迎する」という利用目的の意思表示はできても、それ自体に強制力や対価はない。Pay per Crawlはこの中間に、「対価を支払うクローラーだけを通す」という経済的な線引きを持ち込む点が本質的な違いだ。

Cloudflareはこの役割において「Merchant of Record（決済上の販売者）」として機能し、クローラー運営者への請求とサイト運営者への支払いの両方を仲介する。決済処理そのものはStripeを通じて行われる。

なお、WAFやBot Managementで既にブロック設定されているクローラーは、Pay per Crawlの課金機能よりも優先される。支払う意思があっても、WAF側で遮断されていれば一切アクセスできない。

→ 詳しくはCloudflare Content Signals Policyとrobots.txt AIクローラー設定

導入前提条件：私設ベータへの応募とドメインのVisible設定

Pay per Crawlは2026年7月時点でも私設ベータ（private beta）の位置づけであり、誰でもすぐに使える一般提供機能ではない。導入には以下の前提を満たす必要がある。

1. 私設ベータへの応募

公式サイトの申込フォーム（cloudflare.com/paypercrawl-signup/）から応募する。フォーム上で「自分がパブリッシャー（サイト運営者）なのかクローラー運営者なのか」を明記する必要がある。既にEnterpriseプランを契約している場合は、担当のAccount Executiveへ直接連絡する経路も用意されている。

ベータであるため、応募してから実際に機能が有効化されるまでにはCloudflare側の審査・順次案内を待つ期間が発生する。今すぐ設定画面が触れるとは限らない点は事前に理解しておきたい。

2. ドメインのVisible設定

Pay per Crawlを有効化する前提として、対象ドメインのAccount Settingsにおける可視性（visibility）が「Visible」になっている必要がある。これはPay per Crawlが正しく機能するために、Cloudflare側がドメインの状態を把握できる状態を要求しているためだ。設定を保存すると、ドメインのステータスは自動的に「Enabled」へ切り替わる。

3. 権限：AdministratorまたはSuper Administrator

Stripeとの連携作業は、Cloudflareアカウント上でAdministratorまたはSuper Administratorの権限を持つユーザーでなければ実行できない。編集者権限などでは操作できないため、事前に社内の権限体制を確認しておく必要がある。

有効化からダッシュボード操作までの手順

前提条件を満たした状態から、実際にPay per Crawlを有効化する一連の流れは以下の通りだ。

1. Cloudflareダッシュボードにログインし、対象アカウントを選択する
2. Manage Account > Settings を開く
3. Pay Per Crawl の項目を選択する
4. Stripeアカウントのセクションで Connect を選び、Continue to Stripe をクリックする
5. Stripeのオンボーディング画面で、事業者情報と銀行口座情報を入力して連携を完了する
6. 対象ゾーンに戻り、AI Crawl Control > Settings を開く
7. Pay Per Crawl カードで Enable を選択する
8. デフォルトの単価（後述）を設定する
9. 必要であればコンテンツ種別ごとの個別単価（Advanced configuration）を設定する
10. Save をクリックする

保存が完了すると、Account SettingsのドメインステータスがEnabledに更新され、Pay per Crawlが実際に稼働を始める。

Stripe連携における最重要注意点

公式ドキュメントが明確に警告している点として、既存のStripeアカウントはPay per Crawlに流用できない。Cloudflareのダッシュボードから新規に作成する「Cloudflare Stripe Connect専用アカウント」を接続する必要がある。すでに別用途でStripeアカウントを運用している事業者であっても、Pay per Crawl用には別アカウントを新設する形になる。この点を知らずに既存アカウントでの連携を試みると、手順の途中でつまずくため注意したい。

価格設定：最低0.01ドルからのデフォルト単価とコンテンツ種別ごとの個別単価

Pay per Crawlの価格はゾーン単位で設定する。

• 最低価格: 1回の成功アクセスあたり0.01米ドル。これを下回る単価は設定できない
• 単価の考え方: 公式ドキュメントは、コンテンツの価値と想定されるクローラーのアクセス量を踏まえて単価を決めるよう案内している
• デフォルト単価: サイト全体に適用される基本の単価をまず設定する
• コンテンツ種別ごとの個別単価: Advanced configurationから、コンテンツの種類によって単価を分けることも可能

なお、価格は「Charge」に設定されたクローラーすべてに一律で適用される単一の単価である。「このクローラーには1セント、あのクローラーには5セント」というように、クローラーごとに異なる金額を個別に設定することはできない。金額の差別化ではなく、次章で説明する「Allow・Charge・Block」というポリシーの割り当てによってクローラーごとの扱いを変える設計になっている。

クローラー別ポリシー：Allow・Charge・Blockの設定手順

Pay per Crawlの核心は、クローラーを個別に、あるいはまとめて3種類のポリシーに振り分ける操作にある。

3つのポリシーの意味

個別クローラーへの設定手順

1. AI Crawl Control ダッシュボードを開く
2. Crawlers タブを開く
3. 対象のボットの行にある Actions 列から、Allow・Charge・Blockのいずれかを選択する

複数クローラーへの一括設定手順

1. Name・Operator・Categoryなどのフィルタでクローラー一覧を絞り込む
2. 対象クローラーのチェックボックスを選択する
3. テーブル上部に表示される一括操作メニューから、適用したいポリシーを選択して確定する

検索エンジンクローラーへの適用に関する公式の警告

公式ドキュメントは、検索エンジン用のクローラーに対してBlockやChargeを設定すると、検索エンジンが正しくコンテンツをインデックスできなくなる可能性があると明記している。GooglebotやBingbotのような従来型の検索クローラーはPay per Crawlの支払いプロトコルに対応しておらず、402を受け取った時点でそのままインデックス化を諦める。AI検索での引用機会だけでなく、通常のGoogle検索経由の流入まで失うリスクがあるため、検索・AI検索双方からの流入を維持したいサイトは、少なくとも主要な検索インデックス用クローラーはAllowのままにしておく判断が現実的だ。

HTTP 402の挙動とヘッダー仕様

Pay per Crawlの技術的な中核は、HTTP 402 Payment Requiredというほとんど使われてこなかったステータスコードの活用にある。動作は大きく2つの経路に分かれる。

リアクティブ経路（クローラーが後から支払う）

1. AIクローラーがコンテンツにアクセスを試みる
2. サイトがcrawler-priceヘッダー付きのHTTP 402を返す
3. クローラーが提示された価格に同意し、crawler-exact-priceヘッダーを付けて再度リクエストする
4. 支払いが成立すればHTTP 200でコンテンツが返される

プロアクティブ経路（クローラーが上限額を事前提示する）

1. AIクローラーが、支払ってもよい上限額をcrawler-max-priceヘッダーに含めて最初からリクエストする
2. 提示額が設定価格以上であれば、その場でHTTP 200が返り、実際に課金された金額がcrawler-chargedヘッダーで示される

課金が発生しないケース

以下は課金対象から除外される。

• HTTPステータスがエラー（4xx・5xxなど、200以外）の場合は課金されない。課金イベントが発生するのは成功レスポンスの時のみ
• /robots.txt・/sitemap.xml・/security.txt・/.well-known/security.txt・/crawlers.jsonといった、クロール制御やサイト運営に関わる特定のパスは常に無料でアクセスできる
• 同一ページへの再クロールであっても、成功アクセスである限り毎回課金される。「初回だけ課金して以降は無料」という仕組みではない

なりすまし対策：Web Bot Auth

支払い意思の詐称やUser-Agent偽装を防ぐため、Pay per CrawlはWeb Bot Authという仕組みで暗号署名を検証する。AIクローラー側はCloudflareに登録済みのUser-Agentを使い、署名情報をsignature-agent・signature-input・signatureといったヘッダーで提示する必要がある。サイト運営者側は、想定しているクローラーがこの認証の仕組みに対応しているかを事前に確認しておくと、意図しない402の乱発やアクセス失敗を避けやすい。

Stripeでのペイアウト設定と収益受取の実際

Pay per Crawlで発生した課金は即座に手元に入るわけではない。決済からペイアウトまでの流れと制約を理解しておく必要がある。

支払われるまでの流れ

1. AIクローラーがHTTP 200を伴う成功アクセスをするたびに、課金イベントが記録される
2. 記録された課金イベントは集計・照合（reconciliation）された上で確定する
3. 一定の条件を満たしたパブリッシャーに対して、月次でまとめて支払いが行われる

現時点でのペイアウトに関する制約

• 支払いには決済の締め期間（settlement period）と最低支払い基準額（minimum payout threshold）が設定されているが、公式ドキュメント上に具体的な金額は明示されていない
• ダッシュボード上で未払いの累積残高（accrued balance）をリアルタイムに確認する機能は、現時点では提供されていない。残高を知りたい場合はCloudflareのチームへ個別に問い合わせる必要がある
• 支払いを受け取るには「good standing（良好な状態）」であることが条件とされている。具体的な判定基準は公開ドキュメントには詳述されていない

これらの制約から、Pay per Crawlを導入した直後に「今月いくら入ったか」をダッシュボードで手軽に確認できるとは考えないほうがよい。運用初期は問い合わせベースでの確認が前提になる。

収益の現実性：本当に稼げるのか

Pay per Crawlを検討するうえで最も現実的な論点は、実際にどの程度の収益が見込めるかという点だ。

最低単価は0.01ドルからだが、これはあくまで下限であり、多くのサイトはコンテンツの希少性や想定クローラー量に応じてこれより高い単価を設定することになる。一方で、単価を上げすぎるとクローラー側が支払いを拒否してアクセス自体が発生しなくなり、収益がゼロになるというトレードオフも生じる。

収益規模を左右する主な要因は次の3つだ。

• AIクローラーからのアクセス絶対量: 月間ページビューにおけるAIクローラーの比率が数パーセント程度の中小規模サイトでは、たとえ全アクセスに課金できても絶対額は限定的になりやすい
• 設定単価: 0.01ドル単位の積み上げであるため、月間数千〜数万アクセス規模でなければ意味のある金額にはなりにくい
• クローラー側の支払い受容度: AIクローラー運営者がどこまで高い単価を許容して支払うかは運営者ごとの方針次第であり、サイト側がコントロールできる範囲は限られる

なお、Cloudflareは2026年7月に、クロール回数そのものではなく「AIの回答に実際に使われたかどうか」を起点に支払う新しいPay Per Useプログラムへの移行も並行して打ち出している。これはPay per Crawlとは別枠の取り組みで、初期パートナーはCeramic.aiとYou.comの2社に限定される。クロール量と実際にAI回答へ引用される価値は必ずしも一致しないという課題意識がその背景にあり、Pay per Crawl単体での収益化を検討するサイト運営者は、この「クロール量ベース課金の構造的な限界」も踏まえておく必要がある。詳しくはPay Per Use転換の詳報記事を参照してほしい。

過度な期待を避けるという観点では、Pay per Crawlは「AIクローラーへの対価を求める意思表示と実効的な線引きの手段」として位置づけ、収益そのものよりも「無断利用への牽制」「学習利用の実質的な制御」という副次効果を主目的に据えるほうが、現時点では現実的な導入動機になりやすい。

Stack Overflowなど先行事例に見る運用パターン

Pay per Crawlの公表当初から名前が挙がる事例の一つがStack Overflowだ。プログラミングQ&Aという性質上、AIモデルの学習データとして高い価値を持つコンテンツを大量に保有しており、無断でのAI学習利用に対する懸念を早期から表明してきた経緯がある。こうしたサイトでは、Allow・Charge・Blockのポリシーを使い分けることで、「検索エンジンには無料でインデックスさせて発見可能性を維持しつつ、学習目的で大量に取得しようとするクローラーには課金または遮断で応じる」という設計が想定される。

日本国内では、Cloudflareを利用するサイト自体は非常に多いものの、Pay per Crawlの私設ベータに応募し実際に運用しているとみられる事例の公表はまだ限定的だ。海外の先行事例から学べる実務上のポイントは、次の2点に集約される。

• 課金対象にするクローラーは「学習目的が明確なもの」に絞り、検索・AI検索の引用に関わるクローラーはAllowで維持するという切り分けを徹底すること
• 導入直後から高い収益を期待するのではなく、まずは「無断利用への牽制」としての効果を確認しながら単価と対象クローラーを調整していくこと

robots.txtやContent Signals Policyとの併用設計

Pay per Crawlは単体で完結する仕組みではなく、robots.txtやContent Signals Policyと役割を分担させることで、より一貫性のあるアクセス制御設計になる。

現実的な組み合わせ方としては、まずrobots.txtとContent Signals Policyで「検索表示は歓迎、学習利用は拒否」といった方針を宣言し、その方針を裏付ける形でPay per CrawlのCharge・Blockを学習系クローラーに適用する、という二段構えが整理された設計になる。Content Signals Policyでの意思表示だけでは無視するクローラーに対して無力だが、Pay per Crawlを併用すれば、支払わないアクセスをHTTP 402で実際に止められる。

一方で、検索エンジンやAI検索の引用に関わるクローラーに対しては、robots.txt側でsearch=yes・ai-input=yesと明示しつつ、Pay per Crawl側でもAllowを維持するという整合性が必要になる。片方だけ許可してもう片方でChargeやBlockにしてしまうと、意図と実際の挙動がずれてしまうため、複数の仕組みを併用する場合は設定の棚卸しを定期的に行うことが欠かせない。

→ 詳しくはAIクローラーのrobots.txt設定とAI検索引用戦略【2026年版】

Google/GPTBotをブロックすると検索流入は落ちるのか

Pay per Crawlを導入する際に最も慎重な判断が求められるのが、この点だ。公式ドキュメントが明言している通り、検索エンジンのクローラーに対してBlockやChargeを設定すると、そのクローラーは支払いプロトコルに対応していないため、検索エンジンが正しくコンテンツをインデックスできなくなる可能性がある。

Google検索の通常インデックス化に関わるGooglebotや、Bing検索のBingbotをChargeやBlockにしてしまうと、Pay per Crawlの収益以前に、サイトの主要な流入源である通常検索経由のトラフィックそのものを失うリスクがある。同様に、ChatGPT SearchやPerplexityなど、AI検索の回答内で引用されるために使われるクローラー（OAI-SearchBotやPerplexityBotなど）をChargeやBlockに設定すると、AI検索経由の引用機会も失われる。

一方、モデルの事前学習・ファインチューニングを目的とするクローラー（GPTBotやCCBotなど）に対してChargeやBlockを適用しても、検索インデックスやAI検索の引用そのものには直接影響しない。したがって、Pay per Crawlを導入する際の基本設計は次の通りになる。

• 検索インデックス用クローラー: Allow（課金対象にしない）
• AI検索引用用クローラー: Allow（課金対象にしない、引用機会を優先）
• 学習専用クローラー: ChargeまたはBlock（対価を求めるか遮断する）

この切り分けを誤ると、収益化を狙ったつもりが検索流入とAI引用の両方を犠牲にする結果になりかねない。導入前に、対象クローラーが「検索・引用用」なのか「学習専用」なのかを一つずつ確認する作業は省略できない。

LLMO的には課金とAI引用のどちらを取るべきか

aiseo-llmo.comの立場から強調しておきたいのは、Pay per Crawlの収益化とAI検索での引用獲得は、必ずしも相反しないという点だ。両者が衝突するのは、対象クローラーの分類を誤って「引用に関わるクローラー」まで一律にChargeやBlockにしてしまった場合に限られる。

LLMOの観点で優先すべきは、まずAI検索での引用機会を確保することにある。ChatGPT SearchやPerplexity、Google AI Overviewsといった生成AI検索の回答内で自社サイトが参照される経路を維持しないことには、AI経由の新しい流入チャネルそのものが育たない。したがって、検索・AI検索引用に関わるクローラーは原則としてAllowに設定し、収益化の対象は「引用にも検索にも寄与しない、純粋な学習目的のクローラー」に絞り込むのが基本方針になる。

逆に言えば、Pay per Crawlは「AI検索での露出を諦めて収益を取る」ための機能ではなく、「露出は維持しながら、無断学習だけには対価を求める」ための機能として設計されている。この理解を持たずに導入すると、検索エンジンからの警告通り、収益と引用機会の両方を同時に損なう結果になりやすい。

→ 詳しくはLLMO完全ガイド

日本のサイトでも使えるのか

Pay per Crawlは地域を限定した機能ではなく、私設ベータに応募し条件を満たせば日本国内のドメインでも利用できる。ただし現状では以下の点に留意する必要がある。

• ダッシュボードやドキュメントは英語表記が中心であり、日本語での操作ガイドはまだ整備されていない
• Stripe Connectでの事業者情報・銀行口座情報の登録は日本の事業者としての情報で行う必要があり、Stripeが日本でサポートする決済・送金の枠組みに準拠する形になる
• 日本語コンテンツに対するAIクローラーのアクセス頻度は、英語圏コンテンツと比較して相対的に低い傾向が報告されており、同じ単価設定でも収益の絶対額は英語圏サイトより小さくなりやすい

私設ベータであることから、応募してもすぐに機能が有効化されるとは限らない点も含め、日本国内のサイト運営者は「今すぐ収益化できる」というより「将来の選択肢として仕込んでおく」段階として捉えるのが実態に近い。

まとめ：導入判断のフロー

最後に、Pay per Crawl導入の可否を判断するための一連の流れを整理する。

1. 私設ベータに応募する: cloudflare.com/paypercrawl-signup/から申し込み、パブリッシャーとして案内を受けられるかを確認する
2. ドメインをVisibleに設定する: Account Settingsで対象ドメインの可視性を確認・変更する
3. Stripe Connect専用アカウントを新設する: 既存のStripeアカウントは使えないため、Cloudflareダッシュボード経由で新規に作成する
4. 単価を決める: 最低0.01ドルを起点に、コンテンツ価値とクローラー量を踏まえた単価を設定する
5. クローラーを分類する: 検索・AI検索引用用クローラーはAllow、学習専用クローラーはChargeまたはBlockに振り分ける
6. robots.txt・Content Signals Policyと整合させる: 意思表示レベルの設定とPay per Crawlの実効的な制御が矛盾していないか確認する
7. 月次のペイアウトを確認する: ダッシュボードでの残高確認が限定的であることを踏まえ、必要に応じてCloudflareチームへ問い合わせる運用を組み込む

Pay per Crawlは、AIクローラー対策における「意思表示」から「実効的な経済的線引き」への進化を体現する機能だ。ただし現時点では私設ベータであり、収益額そのものも過度に期待すべきではない。まずは学習専用クローラーへの対価要求という限定的な用途から始め、検索・AI検索での露出を守りながら段階的に運用を広げていくのが、2026年時点での現実的な導入アプローチといえる。

よくある質問

Q1. Pay per Crawlは誰でもすぐに使えますか?

いいえ、2026年7月時点では私設ベータのため、事前の応募と案内を待つ必要があります。

cloudflare.com/paypercrawl-signup/のフォームからパブリッシャーとして応募するか、Enterpriseプランの顧客であればAccount Executiveに直接連絡します。応募後すぐに機能が有効化されるとは限らず、Cloudflare側の順次案内を待つ段階です。

Q2. 最低いくらから価格を設定できますか?

1回の成功アクセスあたり0.01米ドルが最低価格です。

これを下回る単価は設定できません。単価はゾーン単位のデフォルト価格として設定し、Advanced configurationからコンテンツ種別ごとに個別単価を分けることも可能です。ただしクローラーごとに異なる金額を設定することはできず、Chargeに設定した全クローラーに同一単価が適用されます。

Q3. HTTP 402はどのような場面で返されますか?

支払い情報を提示せずにChargeポリシーのクローラーがアクセスした際に、価格情報付きで返されます。

クローラーがリアクティブ経路で402を受け取った場合、crawler-priceヘッダーで示された価格に同意してcrawler-exact-priceヘッダー付きで再リクエストすれば、HTTP 200でコンテンツが返されます。事前にcrawler-max-priceを提示するプロアクティブ経路であれば、最初からHTTP 200で応答され、実際の課金額がcrawler-chargedヘッダーに示されます。

Q4. Allow・Charge・Blockはどう使い分ければよいですか?

検索エンジンやAI検索引用に関わるクローラーはAllow、無断学習が懸念される学習専用クローラーはChargeまたはBlockが基本です。

公式ドキュメントは、検索エンジンクローラーにBlockやChargeを設定するとインデックス化に支障が出る可能性を明記しています。GooglebotやOAI-SearchBotのような検索・引用用クローラーはAllowで維持し、GPTBotのような学習専用クローラーに対してのみChargeやBlockを検討するのが安全な設計です。

Q5. Stripeとの連携で注意すべき点は何ですか?

既存のStripeアカウントは使えず、Cloudflareダッシュボードから新規にStripe Connect専用アカウントを作成する必要があります。

連携作業はAdministratorまたはSuper Administrator権限を持つユーザーのみが実行できます。Manage Account > Settings > Pay Per CrawlからConnectを選び、Stripeのオンボーディング画面で事業者情報と銀行口座情報を入力して完了させます。

Q6. 実際にどのくらい稼げますか?

サイト規模やAIクローラーからのアクセス量に大きく左右され、公式に具体的な目安額は示されていません。

最低単価0.01ドルの積み上げであるため、月間のAIクローラーアクセスが少ない中小規模サイトでは絶対額は限定的になりやすいと考えられます。Cloudflareはクロール回数ではなく実際の利用実績に基づくPay Per Useへの移行も並行して進めており、クロール量ベースの課金には構造的な限界があるという指摘もあります。過度な収益期待は避け、無断学習への牽制効果を主目的とする位置づけが現実的です。

Q7. Google検索やAI検索での引用機会は失われませんか?

検索・AI検索引用用のクローラーをAllowのまま維持すれば、引用機会を損なわずにPay per Crawlを導入できます。

失われるのは、検索・引用に関わるクローラーを誤ってChargeやBlockに設定してしまった場合です。学習専用クローラーだけを課金・遮断対象に絞り込む運用であれば、検索流入もAI検索での引用機会も維持したまま、無断学習だけに対価を求めることができます。

Q8. robots.txtやContent Signals Policyと併用する必要はありますか?

推奨されます。両者は意思表示のレイヤー、Pay per Crawlは実効的な執行のレイヤーという役割分担です。

robots.txtやContent Signals Policyでのai-train=noのような宣言は、それ自体には強制力がありません。Pay per CrawlのChargeやBlockを組み合わせることで、宣言した方針を実際のアクセス制御として裏付けることができます。ただし両者の設定が矛盾しないよう、定期的な棚卸しが必要です。

Q9. 月次のペイアウトはどのように確認できますか?

現時点ではダッシュボード上でリアルタイムの累積残高を確認する機能が提供されておらず、Cloudflareチームへの問い合わせが基本になります。

課金イベントは成功アクセス（HTTP 200）ごとに記録・集計され、決済の締め期間と最低支払い基準額を満たしたパブリッシャーに対して月次で支払われます。具体的な最低基準額は公開ドキュメントに明示されていません。

Q10. 日本のサイトでも同じ手順で導入できますか?

はい、地域限定の機能ではないため、私設ベータの条件を満たせば日本のドメインでも同じ手順で導入できます。

ただしダッシュボードやドキュメントは英語表記が中心で、日本語コンテンツはAIクローラーのアクセス頻度が英語圏より低い傾向があるため、収益効果を英語圏サイトと同じ水準で期待するのは避けたほうがよいでしょう。

関連用語

• クローラー
• robots.txt
• llms.txt
• LLM
• LLMO
• GEO
• ChatGPT Search
• Perplexity

関連記事

• Cloudflare Content Signals Policyとrobots.txt AIクローラー設定
• Cloudflare、AIクローラー課金を「クロール単位」から「引用単位」へ転換
• Cloudflare、AIクローラーを「Search/Agent/Training」の3分類で個別制御可能に
• AIクローラーのrobots.txt設定とAI検索引用戦略【2026年版】
• AIクローラーのアクセスログ分析 GPTBot・ClaudeBotとGEO
• robots.txtでAIトレーニングと検索ボットを分離する戦略【2026年版】
• AI検索最適化ガイド（AIO・AEO・GEO・LLMO）
• LLMO完全ガイド
• Google AIモードのショッピング機能、日本の対応状況を整理