Cloudflare の Pay Per Use — クロールではなく「AI が実際に使ったとき」に publisher へ支払う

要約

Cloudflare は 2026-09-30、AI 企業が publisher のコンテンツを利用したときに publisher へ支払いが発生する Pay Per Use をベータ公開しました。公式の説明は「AI 企業が利用を申告し、Cloudflare が課金・支払い・レポートを処理する」です。

狙っている問題は明確です。 AI の回答エンジンが publisher のコンテンツを要約して提示する一方で、publisher 側にはトラフィックも収益も戻らないという構造です。検索経由の流入で広告収益を得るモデルが、回答が直接返される形式では成立しません。

ここで、設計上の核心が1つあります。クロールに課金するのではなく、実際の利用に課金する点です。

これまでの議論は、ほぼ「クロールを有料にする」という方向でした。 ボットのアクセスを検知し、ブロックするか、アクセス権を売る。Cloudflare 自身も AI Crawl Control などでこの方向の機能を出してきました。

しかし、クロール課金には構造的な弱点があります。 クロールされた量と、実際にユーザーへ届いた量が一致しません。 AI 企業は大量のページを学習や索引のために取得しますが、そのうち実際に回答として引用されるのはごく一部です。 クロール単位で課金すると、使われなかったページにも支払いが発生し、価格交渉が噛み合いません。

Pay Per Use は、ここを「利用」へずらしています。 公式が挙げる例は、**「検索結果が publisher のコンテンツを引用してユーザーへ提示したとき」と、「商品レビューがショッピング推薦に影響したとき」**です。どちらも、コンテンツが実際に価値を生んだ瞬間を課金点にしています。

運用の流れはこうです。 publisher は Cloudflare ダッシュボードの Monetize → Pay Per Use で、AI 企業ごとのオファーを確認します。オファーに含まれるのは、企業名・利用用途の定義・価格の3点です。publisher は個別に承諾または辞退でき、参加の取り下げはいつでも可能です。ドメイン別・期間別の利用量と収益を追跡できます。

技術作業がほぼ不要な点は、実務的に大きいです。 公式は「AI パートナーごとの技術連携やオリジン側の変更は不要」と明記しています。Cloudflare を経由しているなら、ダッシュボードの操作だけで参加できるという形です。

支払いは、Cloudflare が申告された利用を集計して買い手へ課金し、月次で publisher の決済アカウントへ支払います。

同日発表の Monetization Gateway との棲み分けも説明されています。 Pay Per Use は「検証済みの買い手ネットワークを必要とする高価値コンテンツ」向け、Monetization Gateway は x402 を使って API・ツール・データへリクエスト単位で課金する用途（すべてのリクエストが利用そのものである領域）向け、という切り分けです。両者は ID 検証・利用計測・価格設定・分析の基盤を共有しています。

提供状況は、ベータです。 Cloudflare が買い手と publisher を個別に組み入れて、モデルが成立するかを検証している段階とされています。

何が変わったか

• AI 企業がコンテンツを利用した時点で publisher へ支払いが発生する仕組みをベータ提供
• クロール（アクセス）ではなく実際の利用（use）への課金
• 公式が挙げる「利用」の例:
  • 検索結果が publisher のコンテンツを引用してユーザーへ提示したとき
  • 商品レビューがショッピング推薦に影響したとき
• 価格と「何を有償の利用とみなすか」は AI 企業側が定義して提示
• publisher はダッシュボードの Monetize → Pay Per Use でオファー（企業名 / 利用用途 / 価格）を個別に承諾・辞退。取り下げはいつでも可能
• ドメイン別・期間別の利用量と収益を追跡
• AI パートナーごとの技術連携やオリジン側の変更は不要
• Cloudflare が集計・課金し、月次で publisher へ支払い
• ベータ。買い手と publisher を個別に組み入れて検証中
• Monetization Gateway との棲み分け: Pay Per Use は検証済み買い手が必要な高価値コンテンツ、Monetization Gateway は x402 でリクエスト単位に課金する API / ツール / データ

業務インパクト（一般企業向け）

オウンドメディアやコンテンツ事業を持つ組織にとって、これは収益経路の選択肢が1つ増えたという話です。ただし、期待値は正確に置く必要があります。

まず、前提を確認してください。この仕組みが意味を持つのは、「AI に使われるだけの価値があるコンテンツ」を持っている場合だけです。

公式が Pay Per Use の対象を「検証済みの買い手ネットワークを必要とする高価値コンテンツ」と位置づけている点が、そのまま条件です。一般的な企業ブログ、製品紹介、採用情報は、AI 企業が対価を払って使う対象にはなりません。 該当するのは、独自の調査データ、専門領域の継続的な記事、構造化された商品レビュー、業界固有の情報といった種類です。

自社のコンテンツがこれに当たるかを、先に判断してください。 当たらない場合、この発表は自社には直接関係しません。 時間を使う価値は低いです。

該当する場合、検討すべき点を4つ挙げます。

1つ目。価格の決定権が publisher 側にないという構造です。

公式の記述は「各 AI 企業が、何を有償の利用とみなすかを提案し、価格を設定する」です。 publisher ができるのは、提示されたオファーを承諾するか辞退するかです。価格を交渉する経路は、この発表文には書かれていません。

これは、publisher 側の交渉力が構造的に弱いことを意味します。 個々の publisher が「この価格は安すぎる」と判断して辞退しても、AI 企業は他の publisher から同種のコンテンツを得られます。 交渉力が生まれるのは、代替不可能なコンテンツを持っている場合だけです。

したがって、判断の軸はこうなります。「この価格でも、もらえないより良いか」。 本来の価値に見合うかという問いではありません。現状、AI 企業に使われても1円も入っていないのであれば、少額でも入る方が良いという比較です。この割り切りができるかどうかで、参加の判断が決まります。

2つ目。利用量の申告が AI 企業側から来るという点です。

**「AI 企業が利用を申告し、Cloudflare が課金・支払い・レポートを処理する」**という構造です。つまり、どれだけ使ったかを報告するのは買い手側です。

publisher 側に検証手段があるかは、この発表文からは読み取れません。 Cloudflare がダッシュボードで利用量を見せるとしても、それは AI 企業が申告した数字です。 自社のアクセスログと突き合わせて検証することは、「利用」がクロールと一致しないため原理的に困難です。

この点は、参加するなら受け入れる前提として認識しておくべきです。 申告ベースの収益であり、監査はできません。 少額であれば許容できますが、事業の収益の柱として依存する構造ではありません。

3つ目。既存の AI クローラー対策との関係です。

多くの組織は、既に何らかの判断をしています。 AI クローラーをブロックしている、robots.txt で制限している、Cloudflare の AI Crawl Control で制御している、あるいは何もしていない。

Pay Per Use へ参加するということは、「使われることを許す」という方向の判断です。 ブロックしていた組織がこれに参加するなら、方針の転換になります。 この転換を社内で説明する必要があります。

説明の論点は、「使われないようにする」から「使われるなら対価を得る」への移行です。 現実として、完全にブロックし切ることは難しく、ブロックしても流入は戻りません。 対価を得る方向へ寄せる判断には合理性がありますが、法務・広報の観点から、コンテンツの二次利用を許諾することの意味を確認しておく必要があります。

4つ目。ベータであることです。

買い手と publisher を Cloudflare が個別に組み入れて検証している段階です。つまり、参加できるかどうかが Cloudflare 側の判断で決まります。 日本の publisher が対象に含まれるかは、公式には書かれていません。Monetization Gateway が米国限定であることを踏まえると、Pay Per Use も当初は米国中心と想定するのが妥当です。

現時点での推奨アクションは、次のとおりです。 (1) 自社のコンテンツが「AI に対価を払われる価値」を持つかを判断する。 (2) 該当する場合、ダッシュボードで Monetize → Pay Per Use が表示されるかを確認する。 (3) 表示されない場合は、動向の記録に留める。 (4) 並行して、AI クローラーの流入状況を把握しておく（AI Crawl Control などで、どの AI 企業がどれだけ来ているか）。

4番目が、実は最も実利があります。 Pay Per Use へ参加するかどうかに関係なく、「どの AI 企業が自社のコンテンツをどれだけ取得しているか」は把握しておく価値があります。 交渉の材料であり、流入減の原因分析の材料でもあります。

副業・個人活用視点

個人でメディアやブログを運営している場合、この仕組みへの期待は抑えた方が無難です。

理由は、対象が「高価値コンテンツ」とされている点です。 AI 企業が対価を払うのは、他では得られない情報です。個人ブログの技術解説記事や体験記は、同種の情報が大量に存在するため、対価の対象にはなりにくいです。

それでも、考える価値がある論点が3つあります。

1つ目。自分のコンテンツの性質を、この基準で見直すことです。

「AI が対価を払って使う価値があるか」という問いは、コンテンツ戦略の良い評価軸になります。 これは、「検索で上位に出るか」とは別の基準です。

検索で上位に出るコンテンツは、多くの人が探している情報です。 競合も多く、AI が要約できる内容です。AI が対価を払うコンテンツは、他に存在しない情報です。 自分で取ったデータ、自分で検証した結果、自分の実務から出た具体的な数字。

この違いは、個人が書くものの方向性に関わります。 「○○の使い方」という記事は、AI に要約されて流入が消える側です。 「○○を3か月使った結果の実測値」という記事は、AI が参照しても元の情報源としての価値が残る側です。

AI 経由の流入減に対する最も現実的な対策は、代替できないコンテンツを書くことです。 Pay Per Use のような仕組みに期待するより、こちらの方が確実です。

2つ目。クロールと利用の違いという概念です。

この区別は、自分のサイトのアクセス解析を見るときに効きます。

AI クローラーのアクセス数が多いことは、「AI に使われている」ことを意味しません。 取得されただけで、引用されていない可能性が高いです。逆に、クロール数が少なくても、特定の記事が繰り返し引用されている可能性もあります。

現状、個人が「引用されたか」を知る手段はほぼありません。 AI の回答に自分の記事が参照されたかは、各 AI サービスで自分で検索してみる以外に確認方法がありません。 これは手作業ですが、自分の主要な記事について、主要な AI サービスで関連する質問をしてみるという確認は、月1回程度なら実行できます。引用されていれば、そのコンテンツには代替困難な価値があるという証拠になります。

3つ目。受託・支援の文脈です。

メディアやコンテンツ事業を持つ顧客からは、「AI で流入が減った」という相談が確実に来ます。 これは2025年以降、一貫して増えている相談です。

ここで Pay Per Use を「解決策」として提示するのは、現時点では誠実ではありません。 ベータで、買い手が限られ、価格の決定権は publisher 側になく、日本の publisher が対象かも不明です。「これで収益が戻ります」という説明は、事実に合いません。

代わりに提案できることを、3つ挙げます。

(1) 現状把握。 どの AI クローラーがどれだけ来ているか、流入がどれだけ減ったか、減った分がどの記事かを数字で出す。この作業自体が独立した案件になります。 多くの組織は「減った」という感覚だけを持っていて、内訳を持っていません。

(2) コンテンツの選別。 保有コンテンツを「AI に要約されて価値が消えるもの」と「元の情報源としての価値が残るもの」に分類する。後者へ投資を集中させる提案です。

(3) 動向の監視を引き受ける。 Pay Per Use が日本で使えるようになったときに動けるよう、条件を把握しておく役割を担う。 これは小さな継続契約として成立します。

3番目は、金額は小さくても関係が続く形です。 「使えるようになったら教えてください」という依頼は、顧客側から見ると自分で追わなくて済むという価値があります。

最後に、この発表全体をどう位置づけるかについて。

Cloudflare が Pay Per Use と Monetization Gateway を同日に出した意味は、「エージェントが顧客になる」という前提を実装に落とし始めたということです。 片方は publisher 向け、もう片方は API / ツールの提供者向けですが、どちらも「人間以外から対価を得る」という同じ構造です。

個人として押さえるべきは、この構造が成立するかどうかの検証が、今まさに行われているという点です。 成立すれば、個人が作ったものを人間以外へ売る経路ができます。 成立しなければ、AI 経由の流入減に対しては「代替できないものを作る」以外の答えがないことが確定します。

どちらに転んでも、「代替できないものを作る」は有効です。 だから、仕組みの成否を待つ必要はありません。 動向は記録しつつ、今書くものの性質を変える方に時間を使うのが、個人にとっては合理的です。