公開 / 更新
【脱 CMS!】 Astro + GitHub + Cloudflare Pages で実現する安全かつ安価な静的サイト
CMSを使わず、Astro、GitHub、Cloudflare Pagesを組み合わせて、安全性と費用のバランスがよい静的サイトを運用する考え方を紹介します。

ブログを始めるとき、まず WordPress の様な CMS を思い浮かべる人は多いと思います。 管理画面からすぐに記事を書けて、画像のアップロードや公開も簡単です。
ただ、最近は生成 AI の台頭もあり、ある程度 IT の素養がある人にとって、管理画面ですべて手作業でブログを書くということは中々面倒ではないかと思います。
また、小さな技術ブログを一人で運営する場合、CMS の便利さを十分に使わないこともあります。 それでも本体やプラグインの更新、データベース、ログイン画面の保護は必要です。
そこで選択肢になるのが、Astro、GitHub、Cloudflare Pages を組み合わせた静的サイトです。 CMS を否定するのではなく、必要な機能を見直した結果、もっと小さな構成でも足りるかもしれない、という話です。
CMSを外すと何が残るのか
この構成では、それぞれのサービスに一つずつ役割を持たせます。
Astro 記事から静的なHTMLを作る
GitHub 記事とソースコードの履歴を残す
Cloudflare Pages ビルドしたサイトを公開する
Akamai Cloud Object Storage 必要なら記事画像を分けて保存する
記事は Markdown や MDX のファイルです。 Astro がビルド時にHTMLへ変換し、Cloudflare Pages がその結果を配信します。
ページを表示するたびにサーバーでプログラムを動かしたり、データベースから記事を取得したりはしません。 公開後にあるのは、ほぼHTML、CSS、画像だけです。
静的サイトが比較的安全な理由
CMS には管理画面やデータベースがあり、サーバー上でアプリケーションが動いています。 便利な一方で、ログイン試行、古いプラグイン、設定ミスなど、気にかける場所も増えます。
静的サイトには、訪問者が操作できる管理画面も、記事を書き換えるためのAPIもありません。 動的な仕組みが少ないぶん、攻撃される入口も小さくなります。
もちろん、静的なら無条件に安全というわけではありませんが、狙われやすい対象が少なく、構成を把握しやすいことは大きな利点です。
Akamai Cloud Object Storage を採用した理由
GitHub は記事の管理に便利ですが、記事が増え画像が増えてくると少々運用が面倒になってきます。
そこで画像だけ別で管理したいと考え、安価で料金の予測がしやすい Akamai Cloud の Object Storage を採用しました。
料金体系はサービスごとにかなり違います。そこで、標準クラスに画像を100 GB保存し、1か月に1 TBをインターネットへ配信する場合を例に、おおよその月額を比べました。
| サービス | 保存料金と無料・内包枠 | インターネットへの転送 | 月額の概算 |
|---|---|---|---|
| Akamai Cloud Object Storage | 月額 $5 に250 GBを含む | 1 TBを転送プールに追加 | 約 $5.00 |
| Amazon S3 Standard | $0.023 / GB・月 | 最初の100 GBは無料、以降 $0.09 / GB | 約 $83.30 |
| Google Cloud Storage Standard | $0.020 / GiB・月、条件を満たせば5 GB無料 | 条件を満たせば100 GB無料、以降 $0.12 / GiB | 約 $109.90 |
| Azure Blob Storage Hot LRS | $0.0208 / GB・月 | 最初の100 GBは無料、以降 $0.087 / GB | 約 $80.38 |
| Cloudflare R2 Standard | $0.015 / GB・月、10 GB無料 | 無料 | 約 $1.35 |
料金だけを見ると、小規模な画像配信では Cloudflare R2 がかなり有利です。一方、このブログでは最安値だけではなく、月額 $5 の枠に保存容量と転送量が収まり、請求額を予測しやすいことを重視して Akamai Cloud を選びました。
従来は WordPress を VPS にホストしていましたが、そこが Cloudflare Pages のおかげで浮いたため、その料金を Object Storage に充てています。
GitHubが管理画面の代わりになる
CMS の公開ボタンの代わりになるのが、Git の流れです。
記事用のブランチで文章を書き、GitHub へ push すると、Cloudflare Pages がプレビュー用のURLを作ります。
表示を確認してから main ブランチへマージすると、本番サイトが更新されます。
少し開発者向けではありますが、一人で運用しているのであれば、git push までのやり方を覚えておけば困ることは少ないと思います。
バイブコーディングとの相性も抜群
今はエンジニアでなくても AI にコードを書かせるような時代です。 ただ、AI に任せてサイトを作った結果、SPA や DB がモリモリの無駄にリッチな構成になってしまったり、データベースの制限がうまくできず内部データが露出している状態のサイトも多く目にします。
IT の素養がないと判断基準が成果物の見た目や表面上の機能になってしまいがちですが、必要以上にリッチな構成になっていないか、もっと最小限の構成でやれないかを検討してみるとよいかもしれません。
無駄を削ぎ落すことはシステムの安全性を高め、長期的な運用に耐えるシステムにつながります。
とはいえ、最初は小さく始めるものの、将来的な拡張性も考えなければいけない場合もあり、この辺りの判断はまだまだエンジニアの審美眼が必要だと感じています。