11
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@miloneko(yumika sato)

サーバー代0円・管理コストゼロ。Hugo＋Cloudflare Pagesで構築する運用不要な爆速ブログ

11
Last updated at Posted at 2025-12-24

こちらの記事はTechBull Advent Calendar 2025の24日目の記事です。

はじめに

アウトプットの場として、自分専用のブログを構築しました。
完成したブログ

世の中には多くのブログサービスがありますが、サーバー代を極限まで削りつつ、爆速で、かつ管理の手間がかからない環境を追求した結果、「Hugo + CloudflarePages(Workers基盤）」という構成に辿り着きました。
Hugoとは、Markdownファイルから高速にサイトを生成できる静的サイトジェネレーターです。
今回作成したブログの見た目はHugoが担っていますが、この記事では深掘りしません。
本記事では、サーバーレスの特性を活かしたインフラ構成にフォーカスして紹介していきます。

今回の構成図

スクリーンショット 2025-12-24 17.35.23.png
今回の構成図です。単に静的ファイルを配置しているだけでなく、GitHubへのpushをトリガーにCloudflare Pages上で自動ビルドが実行され、その成果物がCloudflareのグローバルCDNを通じて各エッジロケーションへキャッシュされます。
初回アクセス時はPages(オリジン相当)からコンテンツが取得されますが、以降のリクエストは最寄りのCloudflare EdgeCacheから配信されるため、世界中どこからアクセスしてもHugoで生成した静的サイトを高速に表示できる構成になっています。

CloudflarePages（Freeプラン）が凄い

数あるホスティングサービスの中で、なぜCloudflareを選んだのか。
今回のプロジェクトにおける最速構築かつコスト最小化という要件を完璧に満たすため、Cloudflareを採用しました。選定の決め手となったのは、以下の3点です。

①高付加価値なセキュリティ

通常、他社では有料オプションとなる、DDoS対策、SSL、CDN、DNS機能が、無料プランの中に標準搭載されています。
また、AIボットのブロックや、本来は費用が発生してしまうWAFの基本機能まで無料で解放されており、低コストながら鉄壁のセキュリティを実現できます。

スクリーンショット 2025-12-24 17.49.58.png

CloudflareのFreeプランではGUI上にこの設定ができますが、もしこの設定がない場合
リポジトリに robots.txt を置いて、手動で制御します。

例
User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: *
Allow: /

しかしこの方法では、新しいAIクローラーが登場するたびに手動で追従する必要があり、またルールを無視するボットに対しては無力です。
CloudflareのAI Bot 管理機能を使えば、こうした煩雑なメンテナンスをすべてCloudflare側に委ねることができます。

スクリーンショット 2025-12-24 18.02.49.png

Cloudflareでは、AI Crawl Control画面からAIクローラーごとのアクセス状況と、許可・ブロックの判定結果を確認できます。
クローラー単位でのリクエスト数や失敗数が集計されており、AIクローラーが実際に判定・制御されていることを確認できます。

②実質無制限のインフラ

多くのホスティングサービスには月間転送量◯◯GBといった制限がありますが、Cloudflareは無制限であり、帯域制限やビルド回数を気にせず運用が可能です。
また、急激なアクセス増加が発生しても、予期せぬ超過料金が発生するリスクがなく、安心して公開を続けられます。

③パフォーマンスの最大化

世界最大級のCDNネットワークを利用することで、ユーザーに最も近いエッジからコンテンツを配信できます。これにより、サーバーの物理的距離を感じさせない最速のレスポンスを、追加コストなしで提供できるのが最大の強みです。

サーバーレスの正体とメリット

サーバーレスと言っても、物理的なサーバーが存在しないわけではありません。
本来、Webサイトを公開するにはサーバーのOS管理やセキュリティパッチ、ネットワーク設定などが必要ですが、それらをクラウド側がすべて肩代わりしてくれる仕組みを指します。以前Ubuntu仮想マシン(Multipass)上にNginxを立ててWordPressを構築しました。
サーバーレスの正体をより深く理解するために、その場合と比較してみましょう。

比較項目 自前構築（Multipass + Nginx） サーバーレス（Cloudflare 等）
裏側の仕組み 仮想 OS（Ubuntu 等）上でNginxを常時稼働 実行時だけ関数やコンテナが動作
SSL / TLS 管理 手動管理。mkcert での作成や Certbot の導入、90 日ごとの更新設定（cron）が必須 完全自動。ドメインを接続するだけで証明書が発行され、更新も自動
管理の範囲 OS パッチ、Nginx 設定、SSL 更新失敗の監視、ファイアウォール なし。インフラとセキュリティの維持はプラットフォーム側が担当
スケーラビリティ アクセス増加に応じて CPU / メモリを手動で増強 自動。1 アクセスから大量アクセスまで自動的にスケール
セキュリティ SSH ポート管理、OS / Nginx の脆弱性対応が必要 OS に触れないため攻撃対象が最小限
コスト インスタンス代 + ドメイン代 無料枠内であれば 0 円（ドメイン代のみ）

安い

Multipassなどで構築すると、アクセスがゼロでもOSはメモリやCPUを消費し続けます。一方、サーバーレスはリクエストが来た瞬間だけリソースを消費する仕組みのため、個人レベルでは維持費を限りなく**0円（ドメイン代のみ）**に抑えることが可能です。

早い

自前サーバーは物理的なデータセンターの設置場所に縛られます。サーバーレスの場合、Cloudflareのようなサービスが世界中に配置したサーバー網を自動で使い、ユーザーから物理的に最短の場所からコンテンツを返します。これが爆速の裏側です。

安全

自前でNginxを建てると、Nginx自体の脆弱性やOSのセキュリティホールはすべて自分の責任です。
自前でMultipassを立ち上げ、Nginxをインストールして環境を作る場合、以下のような設定ファイルを1行ずつ精査し、運用し続ける必要があります。

http {
    # 基本的な最適化設定（これらも自分でチューニングが必要）
    sendfile on;
    tcp_nopush on;
    types_hash_max_size 2048;

    # セキュリティ
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    # 運用監視
    log_format custom_format '[nginx] '
        'time:$time_iso8601  '
        'server_addr:$server_addr   '
        'host:$remote_addr     '
        'method:${request_method} '
        'status:$status      '
        'size:$body_bytes_sent  '
        'reqtime:$request_time   ';

    access_log /var/log/nginx/access.log custom_format;
    error_log /var/log/nginx/error.log;

    # 表示速度のために自分で有効化
    gzip on;

    include /etc/nginx/conf.d/*.conf;
}

自前運用では、上記のコードを1行書き間違えるだけで、サイトが落ちるリスクがあります。

サーバーレスは、OSやミドルウェアの管理をGoogleやCloudflareといった世界トップクラスのセキュリティチームに丸投げしている状態なので、運用ミスによる漏洩リスクを劇的に下げられます。

サーバーレスの仕組みがわからないという方や、これからインフラを学びたい方には、仮想サーバー上でNginxを自力で構築してみることをお勧めします。
OSのセットアップから始まり、Nginxのインストール、複雑な設定ファイルの記述、SSL証明書の更新、そしてセキュリティパッチの適用、こうした泥臭い運用をひと通り経験することで、Cloudflareが裏側で代行してくれている膨大な作業のありがたみが、身に染みて理解できるはずです。

なぜGitHub PagesではなくCloudflare Pagesなのか

以前はGitHub Pagesを使っていましたが、今回Cloudflareに乗り換えて感じたメリットは圧倒的でした。

GitHub Actionsの保守からの解放

GitHub PagesのActions経由で久しぶりに更新しようとした際、ライブラリのバージョンが古くてCIが動かないという問題に直面しました。

This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v3`. Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

上記のエラー文は実際に出た例で、actions/upload-artifact: v3 のような古いアクションを使っていると、GitHub側から「v3は廃止されたので自動的に失敗させました」と一方的にビルドを拒否されることがあります。こうしたライブラリの更新を追いかけ、YAMLファイルを書き直し続けるのは意外と大変です。
Cloudflare Pagesなら、ブラウザ上の直感的なダッシュボードだけでビルド設定が完結します。環境変数の設定やブランチごとのプレビュー生成も、コードを書かずに画面上の操作だけで済むため、こうした周辺ツールのメンテナンス」に時間を奪われることがありません。

独自ドメインの設定を自動化する仕組み

Webサイトにアクセスする際、ブラウザはドメイン名をIPアドレスに変換します。これを名前解決と呼びます。
GitHub PagesとCloudflareでは、この名前解決の設定の手間が異なります。
Github Pagesでは手動による静的な名前解決をするため、独自ドメインを運用しようとすると、以下の2つの作業が発生することが多いです。

  • GithubPagesの場合
  1. リポジトリへのCNAMファイル追加
    ドメイン名を記述したファイルを置かないと、GitHub側がどのドメインからの通信かを判別できない。
  2. DNSへのIPアドレス(Aレコード)登録
    GitHubが指定する4つのIPアドレスを、お名前.comなどの管理画面に手動で打ち込む必要がある。

Cloudflare Pagesでは、これらの作業を利用者が個別に行う必要はありません。
ドメインのネームサーバーをCloudflareに委譲し、Cloudflare Pages側でドメインを紐づけるだけで、Pages の公開に必要な DNSレコード(CNAMEなど)はCloudflareが自動的に生成・管理してくれます。

そのため、GitHub Pages のように IP アドレスを手入力したり、リポジトリに CNAME ファイルを配置したりする作業は、基本的に不要です。

以上の理由から、静的サイトを運用することを考えると、個人的には GitHub PagesよりもCloudflare Pagesの方が扱いやすいと感じました。

Cloudflareの柔軟性

Cloudflare Pagesでの構築中、いくつかのビルドエラーに直面し、少し躓く場面がありました。ここでの体験こそがCloudflareの真の魅力を実感するきっかけとなりました。

Cloudflare Pages のビルド環境は、自由度が高いのが特徴です。
今回は個人ブログの構築ということもあり、「まずは動かすこと」を最優先にしました。

CloudflarePagesでは、ビルドコマンド欄に任意のコマンドを直接記述できます。そのため、プリインストールされていないツールであっても、ビルド実行時にその場でダウンロードし、依存関係の解決からビルドまでを一括で実行することが可能です。
あらかじめ整えられた環境でしか動かないサービスとは異なり、足りないものはビルド時に補いながら、とにかく動かす方向へ試行錯誤できる。この柔軟さこそが、Cloudflare Pagesの大きな魅力だと感じました。

まとめ

「サーバーレス」という言葉を聞くと、どこか実体のない魔法のように感じるかもしれません。
でも実際には、裏側で誰かがNginxをチューニングし、SSL証明書を更新し、ネットワークを監視し続けています。
私たちはその膨大で泥臭い作業を、Cloudflare にまとめて任せることができます。
かつて仮想環境でNginxの設定ファイルを前に、「この1行、何が悪いんだろう……」と悩んだ経験があるからこそ、サーバーレスの恩恵が身にしみて分かります。
環境構築そのものは、エンジニアにとって確かに楽しい作業です。
しかし、ただ「流行っているから」「便利そうだから」という理由だけで、脳死で技術を選定してはいけないとも思っています。
今回、私が自分に課した要件はシンプルでした。
「管理コストを極限までゼロにし、執筆だけに100%リソースを割けること」
この目的を最短距離で、かつ高いレベルで達成するための最適解が、私にとっては自作サーバーでも、保守が必要なGitHub Pagesでもなく、Cloudflareという選択肢でした。
私が本当にやりたかったのはサーバーの保守ではありません。
完全に自分で作ったブログを持ち、そこに自分の言葉を載せて、誰かに届けること、それだけです。
「付加価値を生まない管理作業（Undifferentiated Heavy Lifting）」という言葉があります。
その重たい部分はプロに任せて、自分は「価値を生むこと」に集中する。
手段が目的化しがちなエンジニアだからこそ、あえて「目的」を優先し、この「攻めの放置」ができる環境を手に入れる。 これこそが、私にとって最高の執筆環境なのだと今は思っています。
「静的サイトならCloudflareという選択が合理的」これが今回、試行錯誤の末に出した結論です。

11
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
11
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?