↓ メインコンテンツへスキップ

個人ブログをHugoとCloudflareで運営する構成にした理由

·4419 文字·9 分
著者
MZGen
AIやデジタルツールを試し、実際に使って分かったことや、うまくいかなかったことを記録しています。
個人ブログをHugoとCloudflareで運営する構成にした理由

個人ブログを始めるとき、記事を書く場所、公開前の表示チェック方法、サイトを配信するインフラをどう選ぶかは最初の大きな悩みどころです。選択肢が多いため、どの構成が自分にとって続けやすいか迷いやすい部分でもあります。

このブログでは、記事をMarkdownで管理する「Hugo」、変更履歴を記録する「GitHub」、そして高速にサイトをビルド・配信する「Cloudflare」を組み合わせました。

この記事では、個人で無理なく運営を続けられるかという視点から、この構成を選んだ理由や日々の公開手順、CMSを使わない運用の向き不向きを紹介します。

個人ブログの構成で重視したこと
#

今回の構成を検討するにあたり、以下のポイントを重視しました。

  • 執筆に集中できること: お気に入りのローカルエディターでMarkdownを無理なく書き続けられる。
  • 公開前に確実にプレビューできること: ローカル環境で本番と同じ表示やリンクの状態をチェックできる。
  • 管理の手間を増やしすぎないこと: データベースの保守やプラグイン更新などの運用負担を減らす。
  • 変更履歴を確実に残せること: 記事や設定の変更をGitで記録し、いつでも過去の状態へ戻せる。

ブログの最適な構成は、執筆スタイルや運営体制によって変わります。ブラウザーやスマートフォンから複数人で手軽に更新したい場合は、管理画面を備えたCMS(コンテンツ管理システム)が便利です。一方、主に一人で執筆し、MarkdownやGitの操作に抵抗がなければ、CMSを持たない静的サイトの構成が有力な選択肢になります。

WordPressとの比較とHugoを選んだ決め手
#

ブログ運営の代表格であるWordPressも有力な候補でした。しかし、レンタルサーバーの契約や定期的なアップデート保守が必要になること、記事データがデータベース内に保存される点などを考慮し、今回は見送りました。

静的サイトジェネレーターには他にもAstroやNext.jsなど多くの選択肢がありますが、その中でもHugoを選んだ決め手は以下の点です。

  • 圧倒的なビルド速度: 記事数が増えても一瞬でHTMLが生成されるため、ローカルプレビュー時の待ち時間がほぼありません。
  • 環境構築がシンプル: Go言語製の単一バイナリで動作するため、Node.jsなどの複雑なランタイム依存に起因するトラブルが起きにくいです。
  • Markdownとの親和性: 記事をプレーンなテキストファイルとして手元に残せるため、将来的な移行やバックアップも容易です。

今回の構成:Hugo・GitHub・Cloudflare
#

記事はMarkdownファイルとしてHugoプロジェクト内で管理し、GitHubへpushします。Cloudflare Workers Buildsがリポジトリの更新を検知して自動でビルドを行い、Workers Static Assetsを通じて静的ファイルを世界中に配信します。

Markdownで記事を執筆・ローカルプレビュー
        ↓ push
GitHubで変更履歴・ソースコードを管理
        ↓ 連携(webhook)
Cloudflare Workers Buildsでサイトをビルド(HTML生成)
        ↓
Workers Static Assetsで静的ファイルを配信

ローカルで生成したHTMLをサーバーへ直接アップロードするのではなく、GitHub上のソースをトリガーとしてクラウド上でビルドが走るため、執筆端末を選ばずクリーンな公開フローを維持できます。

なお、このサイトではHugoのテーマに「Blowfish」を採用しています。ページのレイアウトや一覧表示、ダークモード対応などをテーマ側が担ってくれるため、デザインを一から組む必要がありません。

Hugoで記事を書く・公開する仕組み
#

Hugoは、Markdownで書いた記事や設定ファイルを読み込み、ブラウザーで表示できるHTMLやCSS、画像などを一括生成する静的サイトジェネレーターです。読者がページを開くたびにデータベースへ問い合わせてHTMLを組み立てる動的CMSとは異なり、事前に生成したファイルをそのまま配信します。

記事がテキストファイルとして残るため、好みのエディター(VS CodeやObsidianなど)を自由に選べ、Gitの差分で執筆の進捗や修正履歴も一目で把握できます。ローカルで開発サーバーを起動すれば、本番とまったく同じデザインでプレビューしながら執筆を進められます。

CMSを使わない運用を選んだ理由
#

記事をMarkdownで書き、GitHubを原本(マスター)とすることで、別のCMS管理画面へログインしてコピペや入稿を行う二重の手間を省けます。記事本文、画像アセット、サイト設定、テーマのテンプレートをすべてひとつのリポジトリで一元管理できるのが最大の魅力です。

一方で、公開にはGitの基本的な操作(コミットやpush)が前提となります。ターミナルやブランチの扱いに慣れていない人にとっては学習コストがかかる点や、外出先からスマートフォン単体で手軽にサッと記事を投稿したい場合にはやや不向きな側面もあります。

CMSを使わない構成が常に万能というわけではありません。「日常的にMarkdownで原稿を書くのが苦にならないか」「Gitによる履歴管理をメリットと感じられるか」が判断の大きな基準になります。

Cloudflareでブログを公開するメリットと注意点
#

Hugoが生成する静的ファイルは、Cloudflareのエッジネットワーク(CDN)を通じて世界中から超高速に読み込めます。このブログでは「Cloudflare Workers Static Assets」を利用して配信を行っています。

静的サイトの配信先としては「Cloudflare Pages」も広く知られていますが、Cloudflare公式では現在、新しく開始するプロジェクトにおいてWorkersへの統合(Workers Static Assets)を推奨しています。将来的に動的なAPIやエッジ処理(問い合わせフォームの処理や認証など)が必要になった際も、同じWorkersエコシステム内でシームレスに機能拡張できる点が大きな強みです。

ただし、無料枠の範囲や機能仕様はアップデートされることがあるため、定期的に公式のアナウンスをチェックしておくのが安心です。また、ビルド設定や独自ドメインのDNS設定、万が一のデプロイ失敗時にロールバックできる手順も事前に把握しておくと落ち着いて運用できます。

記事の作成から公開までの流れ
#

日々の執筆から本番公開までは、以下のシンプルなステップで進みます。

  1. 記事の作成: Hugoプロジェクト内に記事用フォルダーとMarkdownファイルを作成し、フロントマター(記事先頭のメタ情報)に draft: true を設定します。
  2. 執筆と画像配置: Markdownで本文を書き、必要な画像や見出しを整えます。
  3. ローカルプレビュー: hugo server --buildDrafts を実行し、ブラウザーで表示崩れやリンク切れがないかをチェックします。
  4. 公開準備と検証: draft: false に切り替えます。このブログではテーマのアセットビルドも含めた検証スクリプトとして npm run build を実行し、エラーが出ないことを確かめます。
  5. GitHubへpush: 変更をコミットし、公開ブランチ(main ブランチ)へpushします。
  6. 自動デプロイと公開確認: Cloudflare Workers Buildsが自動的にビルドを開始します。管理画面でデプロイログをチェックし、公開URLで実際の表示を検証します。

下書き(draft)管理の注意点
#

Hugoは標準の挙動として、本番用の公開ビルド時に draft: true の記事をサイトから除外します。ローカルで下書きを確認するときだけ --buildDrafts フラグを付けてサーバーを起動します。

注意点として、これは「生成されるWebサイトから記事を除外する」機能であり、GitHubリポジトリ上のファイル自体が隠れるわけではありません。公開リポジトリ(Public)を使っている場合、pushした時点でMarkdownの原稿自体は誰でも閲覧できてしまいます。公開前の原稿を完全に非公開にしたい場合は、プライベートリポジトリ(Private)を使用するのが鉄則です。

実際に運用して実感したメリットと課題
#

実感したメリット
#

  • 執筆から公開までの摩擦が少ない: お気に入りのエディターで書いてGit pushするだけで、数秒〜数十秒で本番反映されるため執筆のテンポが落ちません。
  • 表示速度が速く安定している: エッジキャッシュと静的配信の組み合わせにより、ページの表示が極めて高速です。
  • 保守の手間がほぼゼロ: データベースやサーバーOSのセキュリティ更新、プラグインの互換性トラブルから解放されました。

今後の課題・観察ポイント
#

一方で、長期間運用する中でのアクセス数増加に伴うコスト変動や、記事数が数百本規模に達したときのビルド時間の推移などは、今後も継続して観察していく必要があります。

どんな人に向いているか
#

この構成は、特に以下のような人に向いています。

  • 普段からMarkdownで文章やメモを書くのが好きな人
  • 公開前にローカル環境で完成形をしっかりチェックしたい人
  • 記事やサイト設定の変更履歴をGitで几帳面に残したい人
  • サーバー保守やセキュリティ対策の手間を最小限に抑えたい人

逆に、以下のような用途であればWordPressや各種ブログサービス(note、Zenn、はてなブログなど)のほうが適しています。

  • 管理画面からリッチテキストエディターで直感的に書きたい
  • スマートフォンやタブレットのアプリから手軽に投稿したい
  • 複数人のライターでブラウザー上で共同編集・校正を行いたい

将来、構成を見直すタイミング
#

個人ブログの構成は、一度決めたら絶対に変えられないものではありません。

もし将来的に「外出先から手軽に更新したい」「複数人で共同執筆したい」というニーズが生まれたら、ヘッドレスCMS(microCMSやNotionなど)を導入してHugoと連携させる方法もあります。

重要なのは、最初から複雑な仕組みを作り込みすぎず、「現在の自分がもっとも書き続けやすいシンプルなフロー」からスタートすることです。

まとめ
#

個人ブログを長く続けるためには、執筆の手軽さ、公開前の確認しやすさ、そして保守の負担が少ない構成を選ぶことが大切です。今回はMarkdown、Hugo、GitHub、Cloudflareを組み合わせることで、身軽で快適なブログ運営環境を作ることができました。

どのプラットフォームやツールにも一長一短があります。自分の執筆環境やITスキルの習熟度、将来の運営方針に合わせて、納得のいく最適な構成を選んでみてください。

参考資料
#

B!

関連記事