Cloudflare Pages×Hugo自動ブログの実装記録——高速化より効いた「低品質記事を公開しない」設計

Cloudflare PagesでHugoブログを運用する利点は、表示速度や配信基盤だけではありません。

私が実際に運用している環境で最も価値を感じたのは、記事生成、品質検証、テスト、公開を一本のパイプラインにし、不合格の記事を本番へ出さない仕組みを作れたことです。

2026年7月16日、この仕組みはAIが生成した記事を品質スコア2/8で却下しました。同じ日の18時台には、記事生成がタイムアウトしたため、同一テーマが15分間隔で繰り返し選択されています。

成功例だけを並べると、自動ブログは簡単に見えます。しかし実務では、Hugoのビルド速度よりも次の3点が運用品質を左右します。

低品質な原稿を公開前に止められるか
生成失敗とデプロイ失敗を切り分けられるか
人が見ていなくても、次の実行で復旧できるか

この記事では、私のHiro運用環境にある3サイト構成と、2026年7月16日の実行ログをもとに、Cloudflare PagesとHugoを使った自動ブログの設計を解説します。

先に結論：Cloudflare Pagesの価値は「高速配信」だけではない

HugoはMarkdownから静的HTMLを生成します。記事閲覧のたびにデータベースへ問い合わせたり、サーバー側でページを組み立てたりする必要がありません。

生成されたHTML、CSS、JavaScript、画像をCloudflare Pagesへ配置すれば、静的アセットはCloudflareの配信基盤から提供されます。Cloudflareの公式資料でも、Pagesへアップロードした静的アセットはTiered Cacheから自動配信されると説明されています。

参考：Cloudflare Pagesの配信とキャッシュ

ただし、「Cloudflare Pagesを使えば必ず検索順位が上がる」「売上が増える」とまでは言えません。表示速度はUXやSEOに関係する一要素ですが、記事の独自性、検索意図との一致、導線、信頼性が弱ければ収益にはつながらないからです。

私の環境で確認できている事実は、次の範囲です。

Hugoで3つの静的サイトを生成している
PaperModを共通テーマとして使っている
GitHub Actionsで静的チェックとテストを実行している
合格したコミットだけをCloudflare Pagesへデプロイしている
AIスロップ検証が基準未満の記事を公開前に停止している

一方、この記事の執筆時点では、3サイトについて統一条件でLCPやINPを計測した比較データはありません。そのため、「何秒短縮した」といった未計測の数字は掲載しません。

実際に運用している3サイト構成

私の環境では、1つのリポジトリ内に次の3サイトを配置しています。

分野	Hugoソース	Cloudflare Pagesプロジェクト
AI・テック	`sites/ai-tech`	`ai-tech-blog`
ビジネス・副業	`sites/business`	`business-blog`
不動産投資	`sites/real-estate`	`real-estate-blog`

カテゴリとサイトの対応は設定ファイルで管理しています。

AI・テック
AI×不動産
    └─ sites/ai-tech

不動産投資
賃貸経営
    └─ sites/real-estate

不動産マーケティング
ビジネス・副業
    └─ sites/business

各サイトのhugo.tomlでは、共通して次の設定を使っています。

defaultContentLanguage = 'ja'
theme = 'PaperMod'

[params]
  defaultTheme = 'auto'
  ShowToc = true
  TocOpen = true
  ShowPostNavLinks = true
  ShowBreadCrumbs = true

[outputs]
  home = ['HTML', 'RSS', 'JSON']

目次、パンくず、前後記事へのリンク、RSS、JSON出力をテーマ側で用意することで、記事生成プログラムは本文作成に集中できます。

ここでの設計上のポイントは、サイトごとに生成処理を複製していないことです。記事のカテゴリを見て出力先を決め、同じ検証処理とデプロイ処理を通します。

サイトを増やす場合も、原則として必要なのは次の3点です。

Hugoサイトのディレクトリを追加する
カテゴリとサイトの対応を設定する
Cloudflare Pagesのプロジェクト情報を登録する

サイト数に比例して自動化スクリプトをコピーすると、修正漏れやバージョン差が発生します。設定と処理を分離したほうが、長期運用では安全です。

公開までのデータフロー

現在の公開フローは次のとおりです。

トピック選択
    ↓
AIによる原稿生成
    ↓
文章レビュー・最終チェック
    ↓
AIスロップ検証
    ├─ 不合格 → 保存・公開を停止
    └─ 合格
          ↓
      Markdown保存
          ↓
      Git commit / push
          ↓
      GitHub Actions
          ├─ ruff
          ├─ pytest
          ├─ Hugoビルド
          └─ WranglerでCloudflare Pagesへデプロイ

Cloudflareの公式手順では、GitリポジトリをPagesへ接続し、hugoをビルドコマンド、publicを出力ディレクトリとして指定する方法が案内されています。

参考：Cloudflare PagesでHugoサイトをデプロイする公式手順

私の環境では、Cloudflare Pages側に直接ビルドを任せるのではなく、GitHub Actionsで次の順番を固定しています。

- name: Python static check
  run: ruff check .

- name: Python tests
  run: pytest

- name: Setup Hugo
  uses: peaceiris/actions-hugo@v3
  with:
    hugo-version: '0.163.3'
    extended: true

- name: Build and deploy all Hugo sites to Cloudflare Pages
  run: python scripts/deploy_cloudflare_pages.py

この方式を選んだ理由は、Hugoのビルドに成功しただけでは公開条件を満たしたことにならないからです。

記事生成やカテゴリ振り分けに不具合があっても、Markdownの構文が偶然通ればHugoはビルドできる場合があります。そこで、デプロイ前にPythonコードの静的チェックとテストを実行しています。

一次情報：AIスロップ検証が2/8で公開を止めた

2026年7月16日15時22分、マニュアル紹介記事の生成処理は完了しました。しかし、その後のAIスロップ検証で停止しました。

実行ログは次のとおりです。

2026-07-16 15:20:50 [INFO]
Selected manual 5/7:
完全無人AIトレードBot VPS環境構築マニュアル

2026-07-16 15:22:29 [INFO]
manual_draft: codex CLI succeeded

2026-07-16 15:22:29 [ERROR]
AI slop validation failed: score=2/8

不足していると判定された項目もログに残っています。

failed=
Hiroの実体験・固有データ,
一人称の具体エピソード,
他者が書けない独自情報,
冒頭で役立つ,
視覚的証拠,
反論・限界・注意点,
読後アクション,
差別化

注目すべき点は、AIの呼び出し自体は成功していたことです。

manual_draft: codex CLI succeeded

つまり、技術的には「記事を生成できた」のに、編集上は「公開できない」と判断されています。

自動化では、この2つを分ける必要があります。

判定	意味
生成成功	AIからテキストを取得できた
品質合格	公開基準を満たした
保存成功	正しい場所にMarkdownを出力できた
デプロイ成功	本番URLで配信できた

「AIから文章が返った」を成功条件にすると、一般論を並べただけの記事も自動公開されます。生成成功の後ろに品質ゲートを置くことで、公開事故を減らせます。

私の環境では、AIスロップ防止基準として10項目を確認し、最低合格点を8点に設定しています。

実体験や固有データがある
一人称の具体的なエピソードがある
他者が書けない独自情報がある
数字に根拠がある
冒頭で記事の価値が分かる
AI特有の定型文を避けている
画像、ログ、図表などの視覚的証拠がある
限界や注意点を開示している
読者の次の行動が明確である
類似記事との差別化ができている

この検証は、文章が正しいことを保証するものではありません。事実確認、著作権、法務、専門家による確認は別途必要です。それでも、一般論だけの記事を機械的に止める一次フィルターとしては機能しています。

一次情報：同じテーマが15分間隔で再選択された

同日の18時12分以降、次のテーマが選択されました。

Cloudflare PagesでHugoブログを高速配信するメリット

しかし、最初の実行は240秒でタイムアウトしました。

18:12:39  Selected topic 17/50
18:19:15  draft CLI timeout

その後も同一テーマが選ばれています。

18:27:39  Selected topic 17/50
18:32:30  draft CLI timeout

18:42:39  Selected topic 17/50
18:49:14  draft CLI timeout

18:57:39  Selected topic 17/50
18:59:47  draft CLI succeeded

選択時刻だけを見ると、18時12分、18時27分、18時42分、18時57分と、約15分間隔です。

このログから分かるのは、生成処理が失敗した時点ではトピックを消費済みにせず、次回実行で再試行できていたことです。

ただし、無制限の再試行は危険です。

同じ障害が続くとAPI利用量が増える
複数ジョブが重なると二重公開の可能性がある
タイムアウトしたプロセスが裏で残る場合がある
障害原因が解消されないままログだけが増える

そのため、本番では次の情報を永続化すべきです。

{
  "topic_id": 17,
  "status": "generation_failed",
  "attempt_count": 3,
  "last_error": "CLI timeout after 240s",
  "next_retry_at": "2026-07-16T18:57:39+09:00"
}

さらに、同一トピックの連続失敗回数が上限を超えたら、通常キューから隔離する設計が必要です。

1回目失敗 → 15分後に再試行
2回目失敗 → 30分後に再試行
3回目失敗 → 保留キューへ移動
4回目以降 → 人へ通知するまで停止

今回のログでは最終的に原稿生成まで進みましたが、「いつか成功するから繰り返す」だけでは安定運用とは呼べません。再試行回数、待機時間、重複防止キー、隔離条件まで決めて初めて運用設計になります。

Cloudflare PagesとHugoが向いている理由

1. 公開物が静的ファイルなので障害点が少ない

Hugoが生成するのは、基本的にHTMLやCSSなどの静的ファイルです。公開後の記事閲覧にPythonの生成プログラムは関与しません。

生成システムが一時停止しても、すでに公開済みの記事は配信し続けられます。これは、生成系と閲覧系を分離する大きな利点です。

2. ビルド結果をローカルでも再現しやすい

私の環境では、各サイトを次の形式でビルドしています。

hugo --source sites/ai-tech --gc --minify

同じコマンドをCIでも実行すれば、公開前に構文エラー、テーマ参照エラー、テンプレートエラーを検出できます。

ただし、HugoのバージョンがローカルとCIで違うと結果が変わる可能性があります。CI側だけでなく、ローカル環境でも使用バージョンを固定するのが安全です。

3. 3サイトを同じデプロイ処理で扱える

デプロイスクリプトは、設定されたサイトを順番にビルドし、Wranglerで各プロジェクトへ送ります。

npx wrangler pages deploy sites/ai-tech/public `
  --project-name ai-tech-blog `
  --branch main

1サイトだけを確認したい場合は、対象を限定できます。

python scripts/deploy_cloudflare_pages.py --site ai-tech-blog

障害調査中に毎回3サイトすべてをデプロイする必要がなくなり、切り分けがしやすくなります。

4. キャッシュを自作しすぎずに済む

Cloudflare Pagesには静的アセット向けのキャッシュ挙動があります。公式資料では、多くの場合、独自のキャッシュ設定を追加しすぎないことが推奨されています。

更新後も古いファイルが表示される場合はキャッシュの確認が必要ですが、最初から複雑なCache Rulesを重ねると、リダイレクトやPages Functionsより先に古いレスポンスが返る可能性があります。

また、Hugoのビルドキャッシュを使う場合は、公式資料に次の例があります。

hugo --minify --cacheDir=$PWD/.cache

参考：Cloudflare Pagesのビルドキャッシュ

私の現在のデプロイコマンドはhugo --gc --minifyであり、--cacheDirはまだ追加していません。記事数が増えてビルド時間が問題になった段階で、変更前後の時間を測定して導入を判断します。

初心者が最初に作るべき最小構成

最初からAI生成、商品販売、3サイト展開まで実装する必要はありません。まずは、1記事を安全に公開できる最小構成を作ります。

ステップ1：Hugoサイトをローカルで表示する

hugo new site my-blog
Set-Location my-blog
git init

テーマを導入して記事を1本作成したら、ローカルサーバーを起動します。

hugo server -D

ブラウザで表示し、見出し、画像、リンク、スマートフォン幅でのレイアウトを確認します。

ステップ2：本番用ビルドを確認する

hugo --gc --minify

publicディレクトリが生成され、public/index.htmlが存在することを確認します。

ステップ3：GitHubへ保存する

git add .
git commit -m "Initial Hugo site"
git branch -M main
git push -u origin main

この段階では自動生成を追加せず、手書きの記事が正しく更新されることを先に確認してください。

ステップ4：Cloudflare Pagesへ公開する

Cloudflare Pagesでリポジトリを接続する場合、基本設定は次のとおりです。

項目	値
Production branch	`main`
Build command	`hugo`
Build output directory	`public`

テーマをGit submoduleで管理している場合は、Cloudflare側でもsubmoduleを取得できる構成になっているか確認します。

ステップ5：公開前チェックを1つ追加する

最初の品質ゲートは複雑でなくて構いません。たとえば、次の条件を満たさない記事を公開対象から外します。

タイトルが空ではない
本文が最低文字数を満たす
下書き状態ではない
Markdownリンクが壊れていない
Hugoのビルドが成功する

ここまで安定してから、AI生成や複数サイトへの振り分けを追加します。

収益化では「記事数」より導線を分解する

自動ブログを収益化する場合、記事生成数だけをKPIにすると判断を誤ります。

最低でも次の段階に分けて確認します。

検索・SNSで表示
    ↓
記事をクリック
    ↓
本文を一定位置まで読む
    ↓
商品CTAをクリック
    ↓
販売ページを読む
    ↓
購入・問い合わせ

見るべき指標は、記事数ではなく次のようなものです。

指標	確認したいこと
タイトルクリック率	読者の課題がタイトルに表れているか
本文到達率	冒頭で読む理由を示せているか
CTAクリック率	無料記事と商品が自然につながっているか
商品ページ到達後の離脱率	価格、対象者、成果物が明確か
購入・問い合わせ率	提案が読者の課題に合っているか
品質ゲート不合格率	生成設定やプロンプトに構造的な欠陥がないか

無料記事で説明を省き、すぐ有料商品へ誘導すると、読者は「何が得られるのか」を判断できません。

無料部分では、少なくとも次の内容を開示すべきです。

問題が起きる理由
最小構成の手順
実際の失敗例
導入時の制約
読者自身で確認できるチェック項目

有料部分では、テンプレート、設定例、監視設計、復旧手順、測定方法など、実装時間を短縮する成果物を提供します。単に無料記事を長くしただけでは、対価を払う理由になりません。

この構成の限界と注意点

Cloudflare PagesとHugoは有力な選択肢ですが、すべてのブログに最適とは限りません。

動的な会員機能には追加実装が必要

ログイン、会員別コンテンツ、複雑な検索、コメント、管理画面などは、静的HTMLだけでは完結しません。Pages Functions、Workers、外部サービスなどを組み合わせる必要があります。

デプロイ成功は売上を保証しない

高速に表示できても、記事に一次情報がなければ競合との差は生まれません。技術基盤の改善と編集品質の改善は、別の仕事として管理すべきです。

AIスロップ判定にも誤判定がある

キーワードや構成要素を機械的に確認するだけでは、内容の正確性までは判断できません。形だけ実体験風に書いた文章が通る可能性もあります。

高リスク分野では、人による確認を残す必要があります。

自動化には停止条件が必要

AI、GitHub、Cloudflareのどこかで障害が起きる可能性があります。無人運用とは、人が一切関与しないことではありません。

実務上の無人運用は、次の状態です。

正常時は人が操作しなくてよい
異常時は安全側に停止する
原因をログから追跡できる
復旧後に重複なく再開できる
人が介入すべき条件が決まっている

今日90分で実行するチェックリスト

これから始めるなら、今日は次の順番で進めてください。

0〜15分： Hugoをインストールし、バージョンを記録する
15〜30分： サンプルサイトを作り、hugo server -Dで表示する
30〜45分： 本番ビルドを実行し、public/index.htmlを確認する
45〜60分： GitHubへpushする
60〜75分： Cloudflare Pagesへ接続し、本番URLを開く
75〜90分： 意図的にMarkdownを壊し、公開前にビルドが止まることを確認する

最後の失敗テストを省かないでください。正常系だけ確認した自動化は、障害時に初めて本当の仕様が分かります。

高速化の先にある、自動メディアの設計へ

Cloudflare PagesとHugoを組み合わせると、静的ブログを軽量な構成で公開できます。しかし、私の運用で大きかったのは速度そのものよりも、公開工程をコード化できたことでした。

2026年7月16日のログでは、AIが文章を生成できても、品質スコア2/8なら公開を止めています。また、生成タイムアウト時には同じテーマを15分間隔で再選択し、最終的に次の工程へ進みました。

このような失敗記録を残すと、改善点を「AIの調子が悪かった」で終わらせず、タイムアウト、再試行、品質判定、保存、デプロイという工程ごとに分析できます。

自動メディアで資産になるのは、記事本文だけではありません。

再利用できる記事構成
品質判定ルール
失敗時の停止条件
カテゴリ別の配信設計
商品への導線
KPIの測定方法
復旧手順と実行ログ

これらを一つずつテンプレート化することで、記事数を増やしても品質を管理しやすくなります。

より具体的な設定テンプレート、品質ゲート、商品CTA、監視・復旧設計まで実装したい方は、次の実践マニュアルを確認してください。

👉 自動化・不労所得構築マニュアルを見る

先に結論：Cloudflare Pagesの価値は「高速配信」だけではない#

実際に運用している3サイト構成#

公開までのデータフロー#

一次情報：AIスロップ検証が2/8で公開を止めた#

一次情報：同じテーマが15分間隔で再選択された#

Cloudflare PagesとHugoが向いている理由#

1. 公開物が静的ファイルなので障害点が少ない#

2. ビルド結果をローカルでも再現しやすい#

3. 3サイトを同じデプロイ処理で扱える#

4. キャッシュを自作しすぎずに済む#

初心者が最初に作るべき最小構成#

ステップ1：Hugoサイトをローカルで表示する#

ステップ2：本番用ビルドを確認する#

ステップ3：GitHubへ保存する#

ステップ4：Cloudflare Pagesへ公開する#

ステップ5：公開前チェックを1つ追加する#

収益化では「記事数」より導線を分解する#

この構成の限界と注意点#

動的な会員機能には追加実装が必要#

デプロイ成功は売上を保証しない#

AIスロップ判定にも誤判定がある#

自動化には停止条件が必要#

今日90分で実行するチェックリスト#

高速化の先にある、自動メディアの設計へ#