Cloudflare Pages

この記事では、Cloudflare Pagesで運用する3サイトの構成、Hugoのビルド結果、公開フローを扱います。 読者がお金を払ってでも深掘りしたくなる記事にするには、一般論だけでなく、設定ファイル、実行ログ、運用データなどの一次情報が必要です。一方、確認できない体験や成果を「実体験」として書くことはできません。 そのため、以下の3つから執筆方針を選んでください。 A. このサイト固有の実測・設定を使う（推奨） リポジトリで確認できる情報を一次資料として使用します。 掲載対象の例： 3サイトのCloudflare Pages構成 Hugoのビルド設定と実行結果 デプロイから公開確認までのフロー 実際の設定ファイルやログを基にした注意点 再現できた範囲と、確認できなかった範囲 確認できないHiro個人の体験、成果、収益などは創作しません。技術的な再現性と信頼性を最優先する場合は、この方針が適しています。 B. Hiro本人の実体験を使う Hiro本人の経験を中心に構成します。 この方針を選ぶ場合は、掲載可能な範囲で次の情報をご提示ください。 実行ログまたは管理画面のスクリーンショット 運用期間 サイト数と更新頻度 アクセス数の推移 収益または成果の推移 発生した失敗や障害 改善前後を比較できるデータ 個人情報、認証情報、サイトを特定されたくない情報は、伏せ字や数値の丸め処理で保護できます。 C. Aを基本に「Hiroの運用環境」として紹介する リポジトリ上で確認できる設定を、Hiroの運用例として紹介します。 ただし、次のように表現を区別します。 設定ファイルで確認できる事実：断定して記載 実行ログで確認できる結果：確認日時と条件を添えて記載 本人の経験として裏付けられない内容：「運用例」「構成例」として記載 アクセスや収益への効果：データがなければ断定しない 実務的な内容を保ちながら、Hiroの運用環境として記事に個性を持たせたい場合に適しています。 推奨方針 現時点では、一次情報の出所が明確で、読者も再現しやすい方針Aを推奨します。 方針Bを選ぶ場合は、実体験を裏付ける資料が必要です。資料が十分にない状態で個人的な成果や体験を加えると、記事の信頼性を損なう可能性があります。 次にしていただきたいこと A・B・Cのいずれか一つを指定してください。 Bを選ぶ場合は、公開可能な実行ログ、運用期間、アクセス数、収益データなども併せてご提示ください。機密情報を含む場合は、公開できる範囲だけで構いません。

概念図です。Cloudflare Pagesの実際の管理画面ではありません。 「ブログを増やしたいが、サーバー管理や記事公開に時間を取られたくない」「アクセスが増えたときの表示速度や費用が心配」という悩みは、収益化を目指すサイト運営で繰り返し発生します。 記事を書くたびに管理画面へログインし、画像を登録して公開ボタンを押していると、記事数に比例して作業時間が増えます。自分が動き続けなければ止まる運用は、自動化された資産とは呼べません。 そこで相性がよいのが、Hugoで静的サイトを生成し、Cloudflare Pagesで配信する構成です。静的サイトとは、アクセスのたびにデータベースからページを組み立てるのではなく、あらかじめ生成したHTMLを配るサイトです。たとえば、完成済みのindex.htmlをそのまま読者へ返します。 この記事では、HugoブログをCloudflare Pagesへ接続する手順に加え、筆者（Hiro）が運用するauto-ai-blogの実測結果、失敗ログ、公開判定基準、KPI、収益導線まで紹介します。読了後には、Gitへ記事を追加すると、検査・ビルド・公開確認まで進む仕組みを設計できるようになります。 本記事は一般的な技術情報です。サイトのアクセス数、広告収入、アフィリエイト成果などを保証するものではありません。料金やサービス制限は変更される可能性があるため、導入時には公式ドキュメントも確認してください。 Cloudflare PagesとHugoの全体像 Hugoは、Markdownで書いた記事をHTMLへ変換する静的サイトジェネレーターです。Markdownとは、## 見出しや**強調**のような簡単な記法で文章を構造化できる形式です。 Cloudflare Pagesは、生成されたHTML、CSS、画像などをCloudflareのネットワークから配信するサービスです。GitHubまたはGitLabと接続すると、ブランチへのプッシュを検知し、ビルドとデプロイを自動実行できます。 CloudflareのHugo公式ガイドでは、標準的な設定としてビルドコマンドhugo、出力先publicが案内されています。 処理の流れは次のとおりです。 記事テーマ・一次情報 ↓ Markdown記事を作成 ↓ 品質検査・Hugoビルド ↓ GitHubへコミット・プッシュ ↓ Cloudflare Pagesが変更を検知 ↓ HugoがHTMLを生成 ↓ プレビュー環境で検査 ↓ Cloudflareのネットワークから本番公開 ↓ 検索流入・商品ページ・成果計測 この構成では、人間の役割を「毎回の公開作業」から「テーマ選定、一次情報の追加、品質基準の設計、例外への対応」へ移せます。記事生成、テスト、公開、リンク確認を連結できれば、手作業を減らしながら更新を続けられるメディアへ近づきます。 概念図です。実際のデプロイ結果や収益を示すものではありません。 Cloudflare PagesでHugoブログを配信するメリット 1. 閲覧時にデータベース処理を待たなくてよい WordPressなどの動的CMSでは、アクセスを受けてからPHPやデータベースがページを組み立てる場合があります。Hugoは公開前にHTMLを生成するため、閲覧時の処理を単純化できます。 ただし、「Hugoなら必ず何秒で表示される」とは断定できません。画像容量、外部広告、アクセス解析タグ、Webフォント、読者の回線も表示速度を左右します。静的化は高速化に有利な土台ですが、画像やJavaScriptの最適化は別途必要です。 2. 世界各地へ配信しやすい Cloudflare Pagesでは、サイトのファイルがCloudflareの分散ネットワークから配信されます。読者から遠い単一サーバーへ毎回アクセスする構成と比べ、遅延を抑えやすくなります。 ただし、キャッシュの有無をサービス名だけで決めつけてはいけません。次のコマンドでレスポンスヘッダーを確認し、実際の配信状態を判断してください。 curl.exe -I https://example.com/ 確認候補はCF-Cache-Status、Cache-Control、Age、Serverです。キャッシュ動作はファイル種別、レスポンスヘッダー、Cache Rulesなどによって変わります。Cloudflareのキャッシュ解説も参照してください。 3. Gitへの保存と公開を同じ流れにできる 記事をMarkdownファイルとしてGit管理すると、誰が、いつ、何を変更したかを追跡できます。誤った商品リンクを公開した場合も、変更履歴から原因と影響範囲を調査できます。 Cloudflare PagesのGit連携では、プッシュごとの自動デプロイ、ブランチ別プレビュー、Git上でのデプロイ状況確認を利用できます。Git連携の公式説明によると、GitHubとGitLabが対応対象です。 ...

ブログ記事を増やすたびにサーバーへログインしてファイルをアップロードし、公開後に表示崩れを確認する——。この定型作業は、HugoとCloudflare Pagesを組み合わせることで大部分を自動化できます。 基本的な仕組みは、記事をGitHubへpushするとCloudflare PagesがHugoを実行し、生成されたHTMLを公開するというものです。 提供されたHiroの運用記録では、次の規模まで拡張されています。 運用サイト数：3サイト 記事数：合計836記事 記録当日のコミット数：22件 公開確認：各サイトのURLを3回ずつ計測 ただし、元の記録には計測日時、対象URL、HTTPステータス、応答時間、コミットSHAなどが含まれていません。そのため、この記事では確認できる数値だけを掲載し、表示速度やSEO、収益への効果を推測で補いません。 この記事を読むと、初心者向けの構築手順だけでなく、複数サイトを壊さずに運用する方法、証拠として使えるログの残し方、失敗時の復旧方法、SEOとKPIの設計まで理解できます。 上の画像は構成を説明するための概念図であり、実際のCloudflare管理画面や運用実績の証拠ではありません。運用実績は、後述するURL、コミットSHA、Deployment ID、計測結果で検証します。 結論：自動化できるのは「公開作業」であり「ブログの成長」ではない Cloudflare Pages＋Hugoで自動化できるのは、主に次の処理です。 MarkdownからHTMLを生成する Gitへのpushを検知する 本番サイトやプレビュー環境へデプロイする 同じ手順を複数サイトへ展開する 公開結果をスクリプトで検査する 一方、次の仕事は自動化後も残ります。 キーワードと検索意図の選定 事実確認と引用元の検証 AIが生成した文章の編集 内部リンクの設計 古くなった情報の更新 CTAとコンバージョンの改善 障害や誤公開への対応 つまり、この構成の価値は「無人で収益が増えること」ではありません。公開処理を標準化し、人間が事実確認や品質判断に集中できることです。 Cloudflare Pages＋Hugoで何を自動化できるのか Hugoは、Markdownで書いた記事からHTMLを生成する静的サイトジェネレーターです。WordPressのようにアクセスのたびにデータベースからページを生成するのではなく、公開前にHTMLを作ります。 Cloudflare PagesのGit連携を利用すると、GitHubまたはGitLabのブランチへ変更をpushするたびに、ビルドとデプロイを自動実行できます。Pull Request単位のプレビューURLも利用できます。ただし、フォークされたリポジトリからのPull Requestではプレビューが作成されないなどの制約があります。Cloudflare PagesのGit連携に関する公式仕様 基本的な公開フローは次のとおりです。 Markdownで記事を作成する Hugoでローカルビルドする GitHubへpushする Cloudflare Pagesが変更を検知する Hugoによる本番ビルドを実行する 生成されたHTMLを公開する 公開URLのHTTPステータスや本文を確認する 計測結果とデプロイ情報をログへ残す この構成によって公開作業は減らせますが、収益や検索順位まで自動的に伸びるわけではありません。記事品質、独自情報、内部リンク、情報更新、コンバージョン改善は別途必要です。 この構成が向いている人・向いていない人 向いているケース Cloudflare Pages＋Hugoは、次のようなサイトに向いています。 記事、ドキュメント、比較ページが中心 更新履歴をGitで管理したい 複数サイトへ同じ公開手順を適用したい サーバー保守を減らしたい 公開前にプレビュー環境で確認したい AIで作成した下書きを人間が確認して公開したい 過去の状態へ戻せる運用にしたい 向いていないケース 次の場合は、WordPress、ECプラットフォーム、ヘッドレスCMSなども比較してください。 編集者がGitやMarkdownを使えない 会員管理や複雑な権限制御が必要 在庫、予約、決済などの動的処理が中心 管理画面上で頻繁に記事を修正したい プラグインを組み合わせて短期間で機能を追加したい 非エンジニアだけで日常運用を完結させたい Cloudflare Pages Functionsなどを追加すれば動的処理も可能ですが、構成と障害箇所は増えます。静的サイトの利点を保つなら、動的機能は問い合わせフォームや小規模なAPI連携などに限定するのが現実的です。 ...

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出力をテーマ側で用意することで、記事生成プログラムは本文作成に集中できます。 ...

ブログを始めたものの、サーバー管理、表示速度、更新作業、SEO対策、商品導線の設計に時間を取られていませんか。毎回WordPressの管理画面を開き、画像を入れ、公開し、表示崩れを確認する運用では、記事が増えるほど人間の作業時間も増えます。 そこで候補になるのが、Cloudflare Pages と Hugo を組み合わせた 静的サイト 構成です。HugoはMarkdown、たとえば posts/sample.md のような記事ファイルからHTMLを生成するツールです。Cloudflare Pagesは、そのHTMLを世界中のCloudflareネットワークから配信するホスティング基盤です。 この記事では、Cloudflare PagesでHugoブログを高速配信するメリットを、単なる技術解説ではなく、人間の作業時間を減らし、記事生成・公開・計測・商品導線までを自動化資産に近づける設計として解説します。収益やポイント獲得を保証する話ではありません。一般的な情報提供として、再現しやすい作業順序と判断基準を整理します。 全体像：Cloudflare Pages、Hugo、静的サイトの役割 Hugoは、Markdown記事、テンプレート、画像、設定ファイルを読み込み、事前にHTMLを作る静的サイトジェネレーターです。静的サイトとは、アクセスのたびにデータベースへ問い合わせてページを組み立てるのではなく、あらかじめ作ったHTML、CSS、画像を配信するサイトです。 Cloudflare公式のHugoガイドでは、PagesでHugoを使う場合の基本設定として、Build commandに hugo、Build directoryに public を指定する流れが示されています。baseURL をPagesのURLに合わせる例として hugo -b $CF_PAGES_URL も紹介されています。参考: Cloudflare Pages Hugo guide 流れは次の通りです。 Markdownで記事を書く、またはAIで下書きを生成する HugoがHTML、RSS、サイトマップ、一覧ページを生成する GitHubへpushする、またはWranglerでCloudflare Pagesへアップロードする Cloudflare Pagesが public ディレクトリを配信する 読者が検索、SNS、ブックマークから記事へ来る 記事内CTAから /products/、アフィリエイト、資料請求、ポイント案件ページへ進む この構成の良さは、記事公開を「毎回の手作業」から「ログが残るパイプライン」に変えられる点です。完全放置で成果が出るとは言いません。ただ、HugoとCloudflare Pagesを使うと、人間が毎回介在する箇所を減らし、検証と改善に時間を寄せやすくなります。 Hiro環境で確認した一次情報 この記事は一般論だけで書いていません。手元の auto-ai-blog リポジトリで、2026年7月12日に確認できた実行情報を含めています。 確認した構成は、README_ja.md にある Hugo + PaperMod + Python CLI 自動生成 + GitHub + Cloudflare Pages です。PythonからAI APIを直接呼ばず、claude、gemini、codex などのCLIを subprocess で呼び出す構成です。 ...

ブログを収益導線にしたいのに、毎回の投稿、サーバー管理、表示速度の改善、デプロイ確認に時間を取られていませんか。 検索流入から商品ページ、資料請求、アフィリエイト、ポイント案件へ読者を送るブログでは、記事を書く時間だけでなく、公開後に安定して速く配信される仕組みが収益機会を左右します。表示が遅い、更新が面倒、公開ミスが多い状態では、記事数を増やしても運用が詰まります。 そこで使いやすい構成が、Cloudflare Pages × Hugo です。HugoでMarkdown記事を静的HTMLに変換し、Cloudflare PagesからCDN配信します。WordPressのようにアクセスごとにDBからページを組み立てる構成ではないため、ブログ、資料ページ、商品導線ページのような「読み物中心の収益メディア」と相性があります。 この記事では、初心者が手順通りに進められるように、Cloudflare PagesでHugoブログを公開する流れ、失敗しやすい設定、SEO改善、KPI、Hiro環境で確認した実行ログまでまとめます。 収益化に関する内容は一般的な情報提供です。成果や利益を保証するものではありません。 Cloudflare PagesとHugoの役割 Cloudflare Pagesは、Git連携またはDirect Uploadで静的サイトを公開できるホスティング基盤です。Cloudflare公式のHugoガイドでは、Hugoの baseURL をCloudflare Pagesの環境変数 CF_PAGES_URL に合わせる例として、次のようなビルドコマンドが紹介されています。 hugo -b $CF_PAGES_URL 出典: Cloudflare Pages Hugo guide Hugoは、MarkdownやテンプレートからHTMLを生成する静的サイトジェネレーターです。公式リポジトリでも、Go製の高速な静的サイト生成ツールとして説明されています。 出典: Hugo GitHub repository 全体の流れは次の通りです。 Markdownで記事を書く、またはAI生成する HugoでHTML、RSS、sitemap、OGP用ページを生成する GitHubへpushする、またはWranglerで直接アップロードする Cloudflare Pagesが public ディレクトリを配信する 読者が検索結果やSNSから記事へ流入する 記事内CTAから /products/ や案件ページへ進む この構成の強みは、投稿作業を「人間が管理画面で毎回やる作業」から「ログが残る公開パイプライン」に変えられる点です。 Hiro検証メモ: このサイトで確認した一次情報 この記事は一般論だけで書いていません。手元の auto-ai-blog リポジトリで、次の一次情報を確認しました。 確認対象 確認できた内容 README_ja.md 「Hugo + PaperMod + Python CLI 自動生成 + GitHub + Cloudflare Pages」で動く日本語ブログ自動運用システムと明記 .github/workflows/daily-post.yml Python 3.12、Hugo 0.163.3、Node 22をセットアップし、scripts/deploy_cloudflare_pages.py を実行 generator/config.yaml 3サイトをCloudflare Pagesへデプロイする設定 scripts/deploy_cloudflare_pages.py hugo --source <site> --gc --minify でビルドし、npx wrangler pages deploy でPagesへ送信 generator/logs/generate.log 2026-07-10 09:22:13 JSTに git push succeeded to origin/main を記録 設定されているPagesプロジェクトは次の3つです。 ...