AI検索に記事を使われたら収益になる？Cloudflare Pay Per Useの仕組みと条件

AIが記事を参考にして回答しても、読者が元のサイトを訪れるとは限りません。記事は使われているのに、広告表示や問い合わせにつながらない。そんな媒体側の課題に向け、Cloudflareは2026年9月30日、「Pay Per Use」のベータ提供を発表しました。

仕組みは、AI側が提示した利用条件に媒体が参加し、その条件に当てはまる利用について対価を受け取るというものです。すべてのAIから自動的に料金を回収する機能ではありません。Cloudflareの発表

この記事では、AI検索での利用、サイトへの訪問、実際の入金を分けて考え、参加前に何を確認すればよいかを整理します。2026年10月8日に公開資料を確認しており、個別の参加契約や収益を検証した記事ではありません。

AI検索で記事が使われたときに支払う仕組み

Pay Per Useでは、買い手となるAI事業者が、何への利用にいくら払うかを提示します。媒体はその提案を確認して参加を選びます。「記事を置いておけば、どこかのAIが引用した分だけ入金される」という仕組みとして読むと、導入判断を誤ります。

最初に見たいのは、自社のコンテンツに関心を持つ買い手がいるかと、その利用条件を受け入れられるかです。大量に巡回されているサイトでも、その巡回数をそのまま有料の利用件数にはできません。

巡回への課金と利用への課金を分ける

Cloudflareには、AIクローラーによる取得に料金を設定するPay Per Crawlもあります。こちらはサイトへのアクセスが課金対象であり、取得した内容が後からどう使われたかを見るPay Per Useとは、数える出来事が違います。Pay Per Crawlの公式説明

たとえば、ある記事を一度取得して何度も参考にする使い方と、更新を確かめるために何度も取得する使い方では、取得回数と利用回数は一致しません。「AIがたくさん来た」というアクセス解析だけでは、利用に対する対価を見積もれない理由がここにあります。

確認したい出来事	見る記録	置き換えてはいけない数字
AIがページを取りに来た	サーバーや巡回の記録	AI回答で使われた回数
合意した用途に使われた	対象プログラムの利用報告	人が記事を読んだ回数
人が自社サイトへ来た	自社のアクセス解析	利用料の入金額
代金を受け取った	決済・入金の記録	画面上の未確定な見積額

この表は、媒体が社内で数字を整理するための例です。管理画面にこの四つの欄がそのまま並ぶという意味ではありません。

媒体は参加する条件を選ぶ

導入の検討では、相手企業名だけで判断せず、利用目的と対象のコンテンツを読みます。検索回答の参考に使う提案と、別の商品へ組み込む提案では、自社が検討したい点も変わります。

同じ買い手から複数の提案が届いた場合も、一つを受け入れたことがすべての用途への同意になるとは考えないでください。どの条件を読んで判断したかが後から分かるよう、確認した提案の名前、版、日付を記録すると整理しやすくなります。これは自社の判断記録の作り方であり、特定の契約条項の解釈ではありません。

Pay Per Useで誰が何を記録する？

公式発表では、買い手が利用を報告し、Cloudflareが集計と請求、媒体への支払いを担います。利用報告は買い手による自己申告であり、Cloudflareがインターネット上のすべてのAI回答を見張って、無断利用を自動で発見する仕組みとは異なります。利用報告と精算の説明

媒体側では、報告の対象と、自社で観測できるアクセスの範囲を切り分けておきましょう。別々の数字を持っていること自体は矛盾ではありません。何を数えたのかを確認せずに合計したり、一方をもう一方の欠損分とみなしたりすると、説明が難しくなります。

買い手が報告する利用記録

公式発表の報告例には、利用時刻、元ページのURL、イベントIDが含まれます。媒体が確認したいのは、対象のプログラムと期間が一致しているか、見覚えのないURLが混ざっていないか、再集計や訂正がどう示されるかです。

イベントIDがあるからといって、媒体側で全件を自由に取得したり、すべての利用内容を再現したりできるとは限りません。閲覧できる項目、出力できる形式、問い合わせで照合できる情報は、実際に提示された機能と条件を確認します。

利用報告に疑問があるときは、「数字が少ない」だけで問い合わせず、対象の買い手、期間、表示された値、問題に気付いた日をまとめると説明しやすくなります。参照している画面が見積もりか確定記録かも、同じメモへ残してください。

利用件数と入金は同じ数字ではない

Cloudflareは月ごとの集計と支払いを説明していますが、具体的な受取条件は、参加時に確認する必要があります。利用の記録を見た日と、代金が実際に入る日を同じものとして扱わないことが大切です。

社内の月次報告では、利用件数、確認できた金額、入金確認を別の列にします。金額をまだ確定できない場合は、計算で埋めず「確認中」とします。次の表は記録のひな型で、売上実績やCloudflareの画面を再現したものではありません。

対象月・買い手	報告された利用	金額の状態	入金の確認
確認した対象を記入	表示値と確認日を記録	見積もり／確定／不明	未確認／確認日を記入

参加前に比較したい利用条件

単価だけを見て決める前に、何を渡し、何への利用を認め、どう確認できるかを書き出します。以下は媒体側で用意する検討表です。すべてが管理画面で設定できるわけではなく、不明な項目は担当窓口に確認するための質問として残します。

項目	自社で確認する質問
買い手とプログラム	どの企業の、どのサービスへの利用か
対象コンテンツ	ドメイン全体か、対象外のページはあるか
用途	検索、回答、学習などをどう扱う条件か
課金単位	何が一件として数えられるか
報告と訂正	いつ確認でき、不一致をどう問い合わせるか
受取	通貨、手数料、支払条件をどこで確認するか
終了	参加を止めた後の利用や精算をどう扱うか

確認先が分からない項目を「おそらく大丈夫」で埋めないことが、担当者の引き継ぎにも役立ちます。契約の適用範囲を判断できない部分は、自社の権利管理や契約を担当する人に確認してから進めます。

対象コンテンツと利用の目的

自社ドメインに載っていても、記事内のすべての素材を同じ条件で第三者へ提供できるとは限りません。取材写真、外部から提供された図、転載記事などは、媒体が持つ利用条件を確認する対象になります。

まず、検討対象の記事を少数選び、文章、写真、図表、外部データに分けて、誰が作り、どの条件で掲載しているかを整理します。「自社記事」という一括りでは見落としやすい素材を洗い出す作業です。これだけで許諾可否が決まるわけではありませんが、確認を依頼する材料になります。

AI側の用途についても、記事を検索回答の参考に使うことと、モデルの学習へ使うことを混同しないようにしましょう。許可する用途を、自社の普段のコンテンツ方針と照らして確認します。

単価・報告・停止後の扱い

比較する単価の前提が違えば、金額だけを並べても意味がありません。利用一件の定義、集計期間、訂正時の扱いをそろえてから比べます。定義が分からない場合は、計算表を先に完成させるのではなく、質問を先にまとめます。

外貨で条件が示された場合は、元の通貨と金額を残したまま、社内比較用の円換算を別欄にします。換算した日とレートを添えれば、実際の契約通貨や受取額と混同しにくくなります。本稿では確認できた実単価がないため、架空のドル単価や円の収益額は掲載していません。

停止後の利用や精算も、提案ごとの条件を読む項目です。ボタンで参加を終了できることから、保存済みデータがすぐ消える、未精算分が即時入金される、といった動作まで推測しないでください。

AI検索の送客と利用料を別に評価する

記事の役割は、直接の収益だけでは決まりません。問い合わせの前に読まれる記事、既存顧客の疑問を解消する記事、独自調査を伝える記事では、媒体が評価したい成果が異なります。

Pay Per Useを検討するときも、利用料だけで記事の価値を並べ替えるのではなく、どの役割のコンテンツを対象にするかを先に決めましょう。問い合わせ獲得のための記事と、コンテンツそのものを提供する記事では、比較に使う記録も変わります。

記事への訪問と、AI側での利用を区別する

自社サイトの解析で見えるのは、基本的に自社に届いたアクセスです。AIの回答内で内容が使われても、読者がリンクを開かなければ、人の訪問としては数えられません。一方、サイトへのAI巡回は、その後の回答利用を示す記録ではありません。

そのため、媒体の月次レビューでは「人の検索流入」「AIの巡回」「買い手が報告した有料利用」を別の表で扱う方法が考えられます。期間をそろえ、値がどのシステムから出たかも添えると、会議で数字の意味を説明しやすくなります。

AIからの訪問を調べる具体的な手順は、GA4でAI流入と成果を確認するガイドで紹介しています。流入が増えたことと、利用料を受け取れたことを同じ成果として数えないようにしてください。

自社記事の費用と価値を整理する

導入候補を選ぶために、既存記事の維持に必要な作業も書き出してみましょう。取材、データ更新、図表の修正、専門担当者への確認など、続けて公開するための作業を挙げます。費用がまだ算出できなくても、担当者と頻度が分かれば比較の材料になります。

たとえば、自社調査の記事を候補にするなら、更新の頻度、読者からの問い合わせ、再利用する素材の条件を同じ行にまとめます。外部提供の素材が多い記事は、収益の想定より先に利用条件を確認する候補になります。これは記事選定の例であり、特定の種類の記事が必ず高く売れるという予測ではありません。

参加後は、報告された収益だけでなく、確認や問い合わせにかかった作業も記録します。最初の一回で成否を決めず、同じ条件の記録をそろえてから継続を判断すると、印象だけの評価を避けられます。

日本の媒体が今確認できる範囲

2026年10月8日に確認した資料では、Pay Per Useはベータとして説明されています。日本のすべての媒体が同じ条件で参加できることや、現在選べる買い手・単価の一覧までは確認できませんでした。提供済みの機能と、今後の構想を区別して読む必要があります。

Cloudflareは2026年7月にも利用に応じた支払いの実験を紹介していますが、そこで挙がった企業名を、現在すべてのアカウントで選べる買い手の一覧として扱うことはできません。7月時点の公式説明

管理画面に対象の案内があるか確認する

公式発表では、ダッシュボードの Monetize → Pay Per Use で提案を確認する流れが示されています。対象アカウントでこの案内がある場合は、買い手、利用目的、提示価格を読み、上の確認表へ記入します。この記事の制作では、実際のアカウント内で参加や支払い設定は行っていません。

項目が見当たらない場合は、別の課金機能を代わりに有効化せず、ベータの対象条件をCloudflareへ確認してください。問い合わせには、利用したいドメイン、運営地域、想定するコンテンツ、現在見えているメニューをまとめると話を進めやすくなります。認証情報や決済情報を公開の問い合わせ欄へ記載する必要はありません。

案内を読めたこと、参加条件を確認できたこと、実際に利用報告や入金を確認したことは、それぞれ別の段階として記録します。管理画面を開いただけで「収益化できた」と報告しないためです。

許可・拒否の既存設定も記録する

利用条件への参加と、クローラーへのアクセス許可は、担当者同士で確認する必要があります。Pay Per Crawlの公式資料でも、WAFやBot Managementで拒否した場合は課金設定より拒否が優先すると説明されています。ただし、この説明をPay Per Useの全処理へそのまま当てはめてはいけません。

まず、対象ドメインのAI巡回にどのルールを適用しているかを記録し、参加予定のプログラムと両立するかを管理担当者や提供元に確認します。収益化の検討を理由に、既存のBot対策をまとめて解除する作業は不要です。巡回の確認手順は、CloudflareでAIの巡回を確認・制限する方法にまとめています。

今日できる作業は、候補の記事と権利関係を整理し、利用条件を比較する表を用意することです。実際の提案を確認できたら、アクセス、報告された利用、入金を分けて記録し、自社の媒体に合う条件かを判断していきましょう。