個人ブログを始めるとき、記事を書く場所、公開前の確認方法、サイトを公開するサービスをそれぞれ決める必要があります。選択肢が多く、最初の構成をどう組むか迷いやすいところです。
このブログでは、記事をMarkdownで管理するHugo、変更履歴を保存するGitHub、サイトをビルドして配信するCloudflareを組み合わせました。この記事では、個人で続けやすいかを考えながら、この構成を選んだ理由と日々の公開手順を紹介します。
個人ブログの構成で考えたこと#
今回重視したのは、記事を無理なく書き続けられること、公開前に実際のサイト表示を確認できること、運用するサービスや作業を増やしすぎないことです。記事や設定の変更履歴を確認でき、必要なら以前の状態へ戻せることも考慮しました。
ブログの構成は、運営する人数や執筆場所によって向き不向きが変わります。ブラウザーやスマートフォンから複数人で編集したい場合は、管理画面を備えたCMSが便利です。一方、主に自分で執筆し、MarkdownやGitを使うことに抵抗がなければ、CMSを置かない構成も候補になります。
WordPressも候補にした#
WordPressは多くのサイトで使われているCMSで、ブログを始めるときの有力な候補です。自分でサーバーを用意してWordPressを設置する方法では、利用するホスティングサービスやプランに応じて費用がかかります。一方、WordPress.comのようにホスティングを含むサービスもあり、WordPressを使う場合の費用は方式によって異なります。
今回は、記事をMarkdownファイルで管理し、ローカルでサイト全体を確認できる形を優先したため、WordPressではなくHugoを選びました。サーバー費用だけで決めたのではなく、記事の管理方法や公開までの作業も含めて比較しています。
今回の構成：Hugo・GitHub・Cloudflare#
記事はMarkdownファイルとしてHugoプロジェクト内に保存し、変更をGitHubへ送ります。Cloudflare Workers Buildsがリポジトリの更新を受けてサイトをビルドし、Workers Static Assetsで生成済みのファイルを配信します。
Markdownで記事を執筆
↓
HugoでHTMLなどの静的ファイルを生成
↓
GitHubで変更履歴を管理
↓ push
Cloudflare Workers Buildsでビルド・デプロイ
↓
Workers Static Assetsでサイトを配信このサイトでは、HugoのテーマにBlowfishを使っています。Hugoが記事からサイトを生成し、Blowfishがページの見た目や記事一覧などの表示を担当します。テーマはHugoとは別に選べるため、デザインや必要な機能に合わせて変更できます。
Hugoで記事を書く・公開する仕組み#
Hugoは、Markdownで書いた記事や設定を読み込み、ブラウザーで表示できるHTMLや画像などを生成する静的サイトジェネレーターです。読者がページを開くたびに記事データを取得してHTMLを組み立てるのではなく、あらかじめ生成したファイルを配信します。
記事はテキストファイルとして残るので、エディターを選びやすく、Gitの差分で変更内容も追えます。Hugoのローカルサーバーを起動すれば、公開前にテーマやサイト設定を含む表示を確認できます。
CMSを使わない運用を選んだ理由#
今回は、記事をMarkdownで書き、GitHubを原本とするため、別のCMSへ記事を登録する作業を省けます。記事本文、画像、サイトの設定やテンプレートを同じプロジェクトで管理でき、変更履歴も一か所で確認できます。
この形では、公開操作にGitの基本的な流れを使います。初めて使う人には、ターミナルやブランチ、コミットといった概念を覚える負担があります。また、ブラウザーの管理画面だけで執筆を完結したい人や、複数人が同時に編集するチームには、CMSを使う方が合う場合があります。
CMSなしが常に簡単というわけではありません。日々の原稿をMarkdownで扱えるか、GitHubへの変更を自分で確認できるか、ローカルプレビューの手順を続けられるかが判断の目安になります。
Cloudflareでブログを公開するメリットと注意点#
Hugoが生成するのは静的ファイルなので、記事を読むたびにアプリケーションサーバーで処理を行わずに配信できます。このブログではCloudflare Workers Static Assetsを使い、HTML、CSS、画像などの生成物を配信しています。問い合わせ処理など動的な機能が必要になった場合は、後から別の仕組みを追加する設計もできます。
Cloudflare Pagesも静的サイトを公開する選択肢です。Cloudflareは現在、新しく始めるプロジェクトではWorkersを推奨しており、静的サイトにはWorkers Static Assetsを案内しています。既存サイトの移行や使い慣れた手順など、Pagesを選ぶ理由がある場合は、要件に合わせて比較するとよいでしょう。製品の機能や料金は変わることがあるため、利用を決めるときは公式情報を確認してください。
また、無料枠や運用コストだけで公開先を決めず、ビルド方法、独自ドメインの設定、ログの見方、問題が起きたときの戻し方も確認しておくと安心です。今回の構成ではGitHubの変更をきっかけにCloudflareでビルド・デプロイするため、公開後はビルド結果とサイト表示の両方を確認します。
記事の作成から公開までの流れ#
- Hugoプロジェクト内に記事用フォルダーとMarkdownファイルを作り、Front Matterに
draft: trueを設定します。 - 記事を書き、必要な画像や見出しを加えます。
hugo server --buildDraftsでローカルプレビューを開き、記事の表示やリンクを確認します。- 公開するときは
draft: falseに変更し、プロジェクトで定めたビルドコマンドを実行してエラーがないことを確認します。このブログではnpm run buildを使います。 - 変更をCloudflareに接続した公開用ブランチへ反映します。このブログでは
mainブランチへのpushがデプロイのきっかけです。 - Cloudflare Workers Buildsの結果を確認し、公開URLでページを確認します。
このブログではHugoの buildDrafts を無効にしているため、通常の公開ビルドでは draft: true の記事はサイトに含まれません。ローカルで下書きを表示するときは、--buildDrafts を付けて起動します。ただし、これは生成サイトから記事を除外する設定で、GitHub上の原稿や変更履歴を隠すものではありません。リポジトリが公開設定なら下書きの内容も閲覧できるため、非公開にしたい原稿を保存する場合は、非公開リポジトリを使うか、公開リポジトリへ送る前に別の保管方法を選びます。
構築して確認できたこと#
Hugo、GitHub、Cloudflareの役割を分けたことで、記事の執筆とサイトの公開処理を切り分けられました。ローカルでは公開前の表示を確認でき、GitHubに変更を反映するとCloudflareがビルド・公開する流れを確認しています。
一方、長期間の運用負担やアクセスが増えたときの費用は、継続して記録する必要があります。個人ブログをこれから始める人は、最初から将来の全機能を作り込むより、記事を作成して公開する最小の流れを試し、必要になった機能を後から加える方法もあります。
どんな人に向いているか#
この構成は、Markdownで執筆したい人、公開前にローカルで完成形を見たい人、記事やサイト設定の変更履歴を管理したい人に向いています。テーマやページの表示を自分で調整したい場合にも扱いやすい構成です。
一方、コードやGitの操作をできるだけ避けたい場合、スマートフォンだけで投稿したい場合、複数人で同じ記事を共同編集したい場合は、ブラウザーで使えるCMSやブログサービスも比較するとよいでしょう。
将来、構成を見直すタイミング#
運営を続ける中で、共同執筆者が増えたり、外出先から管理画面で記事を編集したくなったりしたら、CMSの追加を検討できます。複数のサイトへ同じ記事を配信したい場合も、記事の保存場所や公開フローを見直すきっかけになります。
構成を変えるかどうかは、実際に困っている作業があるかを基準にします。必要な機能と運用負担を比べ、現在のMarkdownやGitHubの履歴を活用できる移行方法を選ぶことが大切です。
まとめ#
個人ブログでは、執筆方法、公開前の確認、記事の履歴管理、日々の公開作業を無理なく続けられる構成を選ぶことが大切です。今回はMarkdownをHugoでサイト化し、GitHubで管理してCloudflareから公開する形にしました。
この構成がすべての人に合うわけではありません。自分が記事を書く環境や、共同運営の予定、サイトをどこまで自分で調整したいかを整理し、必要な仕組みから選ぶのがよいでしょう。