はてなブログ×CloudflareでAIクローラー制御【Pay per crawl対策第２部】

第1部では、Pay per crawl（PpC）と HTTP 402 の“基礎”を整理し、
はてなブログはそのままでは PpC を扱いづらい――という現実を共有しました。

では、「どうすれば はてなブログを使いながら PpC を運用できるのか？」
ここでカギになるのが、二層化（デュアルレイヤ） と リバースプロキシ（Reverse Proxy） という構成の考え方です。

難しそうに見えて、概念としてはとてもシンプルです。

• 本文（完全版）は Cloudflare 配下で配信する

• はてなブログ側には“抄録・概要”を置く

• サブディレクトリに見せる／見せないの設計を Cloudflare で行う

• AIクローラーの判定・402返却も Cloudflare が担う

つまり、はてなブログの“強み”（書きやすさ・読者導線・コミュニティ性）を活かしつつ、
“弱み”（制御レイヤの無さ）だけ Cloudflare 側で補う、という構造です。

本記事では、具体的なコードや操作手順には 一切触れず、
「二層化とは何か？」
「リバプロ案はどういう発想なのか？」
「はてなブログとCloudflareはどう併存できるのか？」
という“大きな設計図”を、概念図中心でわかりやすく解説していきます。

本記事でわかること

• 二層化（本文＝Cloudflare配下／はてな＝抄録）の構造と役割分担

• リバースプロキシ方式（サブディレクトリ型）の仕組みと注意点

• URL設計・canonical の考え方（重複回避の基本）

• AIクローラー制御（Allow／402／Charge／Block）のレイヤ設計

• 402 本文に何を載せるべきか（項目例・価格レンジの考え方）

• はてなブログ・Cloudflareを併用する際の“落とし穴”と対策

• 次回扱う 「価格・ライセンス・計測」の実務的な設計指針 とのつながり

二層化方式（本文＝Cloudflare配下／はてな＝要約）

情報設計（本文・抄録の役割分担）

二層化（デュアルレイヤ）というと少し難しそうに聞こえますが、
発想はとてもシンプルです。

「本文（フル記事）は Cloudflare 配下に置く」
「はてなブログには“抄録・概要”を置く」

という“役割の切り分け”をするだけなんです。

■ なぜこの切り分けが必要なのか？

はてなブログは……

• コミュニティ性

• 書きやすさ

• はてな読者による回遊

• 独自の検索流入

といった強みがありますが、その一方で、

• HTTP ステータスを返せない（402 が使えない）

• bot 判定のレイヤが持てない

• サブディレクトリや配信階層の制御ができない

という“構造的な弱み”があります。

つまり PpCを動かすために必要な“制御の手”が足りない のです。

そこで、本文は Cloudflare 配下（独自ドメイン側）に置き、
AIクローラーへの応答（Allow／402／Charge／Block）を Cloudflare 側で実現する。
はてなブログは“読者への入り口”“抄録ページ”として活用する、という構造にします。

■ はてなブログ側は「入り口＋要約＋導線」

はてなの記事には 300〜500字ほどの“解説・導入”を置き、

• この続きを読む

• 本文はこちら

• 詳しい解説は独自ドメイン側へ

といった 自然な導線 を付けます。

これなら SEO や UX を損なわず、むしろ読者にも読みやすい構造になります。

■ Cloudflare側は「本文＋402の制御」

Cloudflare 配下には 本文（フルコンテンツ） を置きます。

ここで AI クローラーに対して

• Allow（検索bot）

• 402（条件提示）

• Charge（従量レンジ提示）

• Block（帯域荒らし対策）

といった判定をする“前段レイヤ”が存在するため、
はてなブログを使っていても PpC が成立するわけです。

構造としては分離しつつ、
ユーザー導線はシームレスに保ち、
AIクローラー制御だけ Cloudflare に任せるのが“二層化”のポイントです。

重複回避の基本（canonicalの考え方）

二層化で必ず出てくるのが、
「本文が2ヶ所に存在するのでは？」
という重複問題（duplicate content）です。

ここで重要なのが canonical（正規URLの指定） の考え方。

■ 実質的な本文は「Cloudflare側」

→ canonical = Cloudflare側のURL

■ はてなブログ側は「抄録・要約」

→ canonical を本文側に向ける（＝正規化）

こうすることで、

• 実体は一つ

• SEO評価も一つ

• AIクローラーも正しいURLへ誘導

• はてな側の記事は“説明ページ”として扱われる

という整理ができ、重複評価の心配がなくなります。

はてなの“抄録ページ”はあくまで
「本文へのナビゲーション」 という役割に徹するイメージです。

導線設計（抄録→本文への自然な遷移）

二層化を成功させる一番のポイントはここです。
読者に違和感を与えず、自然に本文へ遷移してもらう導線設計。

意識すべきは次の3点。

① 冒頭300〜500字で“読ませる理由”を提示する

• 問題提起

• 読者の疑問

• データや気付き

• 本文で得られるメリット

はてなブログの読者は“軽く読みたい層”も多いため、
ここで 「続きを読もうかな？」 と思ってもらうのが重要。

② 「本文はこちら」ではなく“理由付き導線”にする

NG：

本文はこちら → URL

OK：

この先では「具体的な構成」「二層化の図解」「Cloudflare側の役割」を詳しく解説しています。
👉 本文を読む（独自ドメイン）

ただのリンクより、
「そこに行く意味」を添えるとクリック率が跳ね上がります。

③ はてな側は「完結しないようにしつつ満足度は下げない」絶妙な構成に

• 0〜30％だけ解説

• 残り70％を本文へ誘導

• 抄録としては成立させつつ“物足りなさ”を残す

これが正しいバランスです。

完全版をはてな側に置いてしまうと、
PpCの本文が読まれず価値が失われてしまいます。

二層化の本質は、

「はてなブログ＝入り口（概要）」
「Cloudflare側＝本文（価値の本体）」

という“メディア二段運用”です。

サブディレクトリ・リバースプロキシ方式

概念フロー（/blog/配下の中継）

二層化方式では「本文＝Cloudflare配下」「はてな＝要約」という役割分担を行いましたが、
もうひとつの人気アプローチが サブディレクトリ × リバースプロキシ方式 です。

これは簡単に言うと、

「独自ドメインの /blog/ 配下にあるように見せながら、
実際の中身ははてなブログが提供する」

という“中継”の仕組みです。

■ 直感的に理解すると、こんな構造

 

ユーザー or AIクローラー │ ▼ example.com/blog/◯◯ │ ▼ （Cloudflare：判定・書き換え・中継） │ ▼ はてなブログの記事（実体）

ポイントは、ユーザーやAIからはすべて「独自ドメイン配下」に見えるということ。
見た目は完全に自社サイトの /blog/ 以下ですが、中身ははてなが返しています。

これにより、

• URL の統一

• ドメイン価値の一元化

• SEO 的な評価の蓄積

• 将来の構成変更も柔軟

といったメリットを得ながら、
Cloudflare で AIクローラー制御（Allow / 402 / Block）ができるようになるのが最大の強みです。

リダイレクト / Location 書き換えの思想（具体実装は割愛）

この方式は、Cloudflare が“中継レイヤ”として働くことで成立します。

具体のコードやルールは本記事では扱いませんが（ぼかし方針）、
概念としては次の3つが重要です。

① URL は「統一されたもの」に見せる

ユーザーが押すリンクも、検索結果のURLも、AIクローラーが参照するURLもすべて、

 

https://example.com/blog/〜

に統一します。

実際のページがどこにあるか（はてな or 自社サーバ）は表に出さず、
“表の顔”はすべて独自ドメイン側に寄せる という発想です。

② 内部では「書き換えて中継する」

Cloudflare はアクセスを受け取ると、

1. /blog/◯◯ へのアクセスを受ける

2. それを「対応するはてなURL」に内部で変換

3. はてなからのレスポンスを Cloudflare が一度受ける

4. 必要に応じて HTTPヘッダや Location を書き換える

5. ユーザーに /blog/〜 として返す

という“2段階”の動きを行います。

③ AIクローラーには 402・Allow を返せる

このアプローチの核心です。

Cloudflare が前段にいるので、

• 検索botなら Allow

• 学習系なら 402（条件提示）

• ただの帯域荒らしは Block

といった PpC / AI crawl control が可能になります。

はてなブログ単体ではできない“HTTP レイヤの制御”が、
リバースプロキシを挟むだけで一気に実現できるわけです。

画像・添付の配信系における例外観点

サブディレクトリ方式で見落としがちなのが、
画像・添付ファイルの扱いです。

はてなブログの画像は独自ドメイン配下ではなく、
別ドメイン（cdn系）で配信されるケースが多いため、
リバプロ方式を使うときには必ず次の点を押さえておく必要があります。

① 画像ドメインは“直配信でOK”にするケースが多い

画像は読み込み量が多いため、Cloudflare側で無理に中継すると、

• パフォーマンスが低下

• 帯域コストが上がる

• AIクローラーにも無関係な配信が増える

という問題が起きがちです。

そのため「画像は中継せずオリジナルを読ませる」方式が使われます。

② AIクローラーの画像取得は“本文とは別扱いにする”

多くのAIクローラーは画像学習を行わないか、
行うとしてもテキストとは別レイヤで扱います。

そのため、本文の 402 制御とは独立して、

• 画像は Allow

• 本文は 402

• JSON/API系は Block

といった“レイヤ別の扱い”が必要です。

③ 添付ファイルは Cloudflare 側で“条件付き許可”にする場合もある

PDF や CSV など、情報価値が高いものは、

• 本文より優先して制限すべき

• 逆に公開性を重視して Allow にすべき

というケースがあり“扱いの揺れ幅”が大きい領域です。

PpC導入後のログを見てから最適化すべきポイントでもあります。

AIクローラー制御のレイヤ設計

Allow（検索系）／402（案内）／Charge（従量）／Block（帯域荒らし）

AIクローラーを扱ううえで最も重要なのは、
「すべてのbotを同じ扱いにしない」ことです。

PpC（Pay per crawl）によって、AIクローラーは
“拒否する対象”ではなく “条件を提示して扱い分ける対象” へと変わりました。

Cloudflare の前段レイヤを使えば、この「扱い分け」を
HTTP ステータス＋条件提示」で実装できます。

そして、基本となる4レイヤがこちらです。

① Allow（検索エンジン系）

── 守るべきクローラー

Google、Bing などの検索botは
あなたのサイトの生命線です。

• インデックス

• 検索順位

• オーガニック流入

• サイト評価

これらを支えているのは検索botなので、
PpCを導入しても絶対に Allow を維持 します。

ここをミスると、PpCどころかアクセス全体が落ちてしまいます。

② 402（案内）

── 学習系AIへの“条件付き許可”

402 Payment Required は、
PpCの中核となるステータス です。

学習AIクローラーに対して、

• 料金レンジ

• ライセンス条件

• API・連絡先

• 使用条件の概要

• キャッシュ期限・再配布ポリシー

などを提示し、

「読むのはOKだけど、条件はこちらにまとまっているよ」

と案内できる万能レイヤです。

“拒否”ではなく“条件提示”へ。
PpC時代のメイン思想がここに凝縮されています。

③ Charge（課金案内／従量レイヤ）

── 高負荷 or 大量学習への“追加ライン”

402 と似ていますが、
Charge レイヤは “さらに踏み込んだ条件提示” を行う場所。

例（抽象表現のみ）：

• 一定量以上のクロール

• 高頻度の再クロール

• 高価値記事の束ごとの閲覧

• 特定フォーマットの取得

こうした“負荷や価値が大きい行為”に対して、
追加条件・追加レンジ を提示するための階層です。

PpCは1つの単価で運用されるわけではなく、
“段階制”で扱うとより現実的なコントロールができます。

④ Block（帯域荒らし／偽装クローラー）

── 読ませる必要がない対象

UA（User-Agent）偽装や、
帯域を大量に使うだけのクローラー、
意味不明なスクレイパー系は 迷わず Block へ。

ただし、

• 検索系との誤判定

• 軽量AI要約系との曖昧な境界

• ASN やヘッダが不安定なbot

などが混在しているため、
Block の条件は必ずログを見ながら微調整する必要があります。

402本文の要素例（価格のレンジ・窓口・API導線）

ここからは、実際に AIクローラーへ返す
“402本文（メッセージ）」に含めるべき項目 の話。

※具体的な文言は出しませんが、
どんな「項目」が必要かは理解しておくべきです。

402本文でよく使われる構成要素（抽象例）

① 利用条件の概要

• 読み取り目的の明記

• 内容利用の範囲

• 再配布・二次利用の制限

• キャッシュ期間の目安

② 料金レンジ（“目安の幅”）

• 明確な金額ではなく“帯”で提示

• 従量課金 or 束ライセンスのカテゴリ案内

• botカテゴリー別の扱い

※具体の数値を書く必要はありません。
“具体額は問い合わせ”の姿勢が最も安全です。

③ 連絡先・窓口

• ライセンス交渉用のメールアドレス or ページ

• AI企業が問い合わせる“入り口”

これは AI企業が“正式に交渉して良い相手”として認識するための大事な要素 です。

④ API / 機械判読用の案内（任意）

• 条件を取得するエンドポイント

• Bot側が自動取得しやすい JSON 表現の提示

• 変更通知の方法

※現在はまだ発展途上ですが、将来的には主流になります。

402本文の思想：

『条件が明確なら AI は従いやすい』

AIクローラーは“雑に読む”ように思えますが、
実際には 明示されたルールに従う能力が高いです。

• robots.txt

• HTTPヘッダ

• canonical

• 402本文

• JSON化された条件（任意）

これらを揃えれば、
“透明性が高いサイト”として扱われ、
不必要な誤爆やトラブルが大幅に減ります。

“拒否”より“条件提示”に寄せる理由

最後に、この章で一番伝えたいポイントです。

❌ AIクローラー時代に「403拒否」中心の運用は不利

なぜなら……

• 交渉の余地がゼロになる

• botが“代替ルート”で読みに来る可能性がある

• 学習AIがあなたのコンテンツを正しく扱わなくなる

• 将来のAI流入（検索や要約）を取りこぼすリスクがある

⭕ “条件提示（402）”は柔らかく、交渉の土台が作れる

• 相手が読める

• 条件を示せる

• レンジで提示すれば後から調整可能

• 料金だけでなく“ルール”も伝えられる

• AI企業側も扱いやすい

つまり 402は“拒否”と“許可”の中間を作る技術 であり、
AI時代に最もフィットしたアプローチと言えます。

まとめ（キーワード：はてなブログ Cloudflare 設計 まとめ）

第2部では、
「はてなブログ × Cloudflare で AIクローラー制御を成立させる構成」 を、
二層化とリバースプロキシという2つの視点から整理してきました。

本章のポイントを振り返ると、次の3つに集約されます。

① はてなブログ単体では PpC を扱う“HTTP レイヤ”が不足している

はてなブログは非常に優れた執筆・公開プラットフォームですが、

• 402 の返却

• bot 判定

• サブディレクトリ制御

• ルールの段階適用

といった PpCの実装に必要な要素 が構造的に存在しません。

そのため、前段に Cloudflare などの “判定レイヤ”を追加する 必要があります。

② 二層化（本文＝Cloudflare／抄録＝はてな）で役割を綺麗に分けられる

• 本文＝価値のある情報 → Cloudflare 配下

• はてなブログ＝読者への“入り口”＋要約

この“メディア二段構造”により、

• 読者体験

• SEO

• Google Discover

• コミュニティ回遊

など“はてなの強み”を失わずに、
AIクローラー制御だけ強化する ことができるようになります。

③ サブディレクトリ×リバースプロキシ方式は URL 統一が魅力

• example.com/blog/以下はすべて自社サイト“に見える”

• 実体ははてな → Cloudflare が中継して整える

という構造により、

• ドメイン評価が一箇所に集まる

• 将来的な移行も柔軟

• PpC / 402 の前段制御が可能

• bot や検索エンジンにも分かりやすい構造

といったメリットが得られます。

まとめると…

はてなブログだけではできない制御を Cloudflare が補完する。
そのうえで、本文と抄録の役割を分担し、URL と AIクローラー制御を統一する。

これが「はてな×PpC時代」の基本設計図です。

次回はこの“設計図”を実際に“運用できる体系”へ落とし込むため、
価格設計・402内容・ライセンス・計測 の実務的なフレームへ入っていきます。

次回予告（キーワード：PpC 価格設計 計測 運用）

この第2部では、「構造と設計思想」を大まかに俯瞰しました。
次回の第3部では、いよいよ 具体的な運用フェーズ に進みます。

テーマは――

「PpCの価格設計と計測運用

── ライセンス文面・402・GA4/ログの“見える化”」

ここでは次のような疑問に答えていきます。

✔ PpC の“単価”はどう決める？（目安レンジの考え方）

✔ 402 本文には何を書けばいい？（項目テンプレ／抽象文）

✔ ライセンスページはどう構成する？

✔ GA4やログで AIクローラーをどう分類する？

✔ Allow／402／Charge／Block の比率はどう見る？

✔ 運用のチェックサイクル（週次／月次／四半期）とは？

次の記事への導線文

続きはこちら：
👉 第3部「PpCの価格設計と計測運用 ― 402・ログ・ライセンスの型」
── 実際の“運用面”をわかりやすく整理し、PpCの判断フレームを完成させます。

今回はここで終わりにしたいと思います！

最後までお読みいただきありがとうございました！

このブログでは「ChatGPT×副業」をテーマに、AIをフル活用したリアルな副業チャレンジを発信しています🎶

むずかしい話はナシで、「ちょっとやってみたいかも」と思えるような内容を目指しています😁

私は現在、ChatGPTを使ってTシャツのデザインを作って販売したり、

LINEスタンプのキャラ制作に挑戦したりしています👍

デザインの知識ゼロでも、AIの画像生成機能を使えばかなりいい感じになりますよ！

ブログの内容やSEO対策も、ぜんぶChatGPTに相談しながら書いています。

アイデアが出ないときも、相棒みたいに助けてくれます🎶

さらに、楽天ルームのレビュー文章もChatGPTと一緒に考えたり、

X（旧Twitter）の投稿や運用方法も提案してもらったりと、あらゆる場面でAIに頼っています。😅

「AIって便利そうだけど、自分にも使えるのかな？」

と思っている人には、ぜひ読んでほしいです。

このブログは、AI初心者でも副業が始められるように、

体験ベースでわかりやすく書いています。

私の成功も失敗もまるごとシェアしていくので、よかったら気軽に読んでいってくださいね。

Xでも日々の活動をゆるっと更新しているので、ぜひのぞいてみてください！

明日のあなたがより豊かになりますように😌

それでは、おやすみなさい😴