情シスの休日：個人ホームページを WordPress から Hugo + AWS へ移行して、コストを 1/100 にした話
これはなに？
こんにちは、しもしゃんです。
WordPress といえば、情シス目線ではプラグイン込みの脆弱性管理が気になるところですよね。
趣味で運営している同人サークルのホームページがあるのですが、今回はそれのお話です。
このホームページはもともと WordPress で動かしていました。
で、毎月まあまあなコスト（約 3,000 円/月）がかかってたので、地味になんとかしたいと思ってたんですよね。
なんやかんやあって、今年は WordPress を卒業して静的サイトジェネレータ（Hugo）へ移行しました。
移行後は月あたりのランニングコストを数十円（約 1/100）まで圧縮できました。
今回は、その移行ログをここにまとめたいと思います。他にも、技術的なこだわりや苦労したポイントも書きたいと思います。
件の HP
今回、WordPress から Hugo に移行した HP はこちらです。
いま、この HP の Hugo のテーマやコンテンツ（画像以外）、インフラの Terraform は以下の GitHub リポジトリで管理されています。
Public リポジトリなので誰でも見ることができます。
HP の歴史
私の HP がどのような変遷を辿ってきたか、大雑把にご紹介します。
2013 年（自宅サーバー期）：
物理サーバーで WordPress 運用。
自由度は最高でしたが、ハードウェアの故障に怯えながらミドルウェアの保守やバックアップに苦しむ日々。
この頃のコストは電気代約 3,000 円/月。
2017 年（VPS 期）：
自宅サーバーを襲った突然の事故(※1)に伴い一般的な VPS へ移行。
ハードウェア管理がなくなり楽になりましたが、ミドルウェアの保守などソフトの辛さは解消されず。
この頃のコストは VPS 代の約 3,400 円/月。
2022 年（Headless CMS 期）：
ミドルウェアの依存性の複雑さが限界に。
SaaS 主体の流行りに乗る形で、Headless WordPress が使える某サービスへ乗り換え。
導入当時は月額約 1,500 円弱と満足してましたが、円安や値上げの影響でコストが月額 3,000 円近くまで上昇。
2025 年（現在、本件）：
ベンダーロックインのリスクを感じ、コストに耐えかねて Hugo + AWS へ移行。
「月 3,000 円なら安いもの」という考え方もありますが、「同じくらいのコスト払うならレンタルサーバーとか VPS とか EC2 の方が自由度あるじゃん。でもミドルウェアの保守は二度とやりたくねぇ～～～」と思ってました。あと、他の SaaS の値上げによるお財布へのプレッシャーがやばい。
コンテナイメージを作って ECS あたりを使うのも考えましたが、それも割高と思ってました。
そんな課題を会社のチームメンバーに話したところ、Hugo というツールのことを教えてもらいました。
概要を調べてみると、「ウチの HP をこれで運用できたら最高じゃん」と感じて Hugo への乗り換えを決意。
Hugo って？
Go 言語製の静的サイトジェネレータです。
ざっくり言うと、「Markdown で書いた記事ファイル」と「HTML ベースのテーマ」を組み合わせることで、一瞬で「Web サイト一式（HTML/CSS）」を生成してくれるツールです。
Headless WordPress でも「コンテンツ編集のときだけ WordPress を立ち上げて、HTML/CSS 一式を出力したあと終了する。HTML/CSS は別サーバーで配信」みたいなことはできます。
とはいえ、WordPress も Headless WordPress どちらをとっても PHP を動かす環境と MySQL のようなデータベース環境が必要です。
WordPress ではこれらの環境の用意が大変な一方、Hugo は CLI ベースのアプリケーションなのでインストールや実行が容易です。
新しいアーキテクチャの全体像
移行にあたって採用した構成は以下の通りです。
- SSG: Hugo（ビルド速度と自由度で選定）
- Hosting: AWS S3 + CloudFront
- CDN/DNS: Cloudflare
- CI/CD: GitHub Actions
- IaC: Terraform
補足１：メディアファイルの分離
リポジトリが画像ファイルで肥大化するのを避けるため、静的 HTML 用の S3 バケットとは別に、メディアファイル専用の S3 バケットを用意しました。
記事の Markdown ファイルは GitHub で管理しますが、メディアファイルは S3 に直接アップロードする運用です。
補足２：DNS や CDN 周りについて
通常は CloudFront + Route53 が王道ですが、ドメイン管理を Cloudflare で行っていたこともあり、あえて Cloudflare → CloudFront → S3 という構成にしました。
ホスティングに AWS を用いたのは趣味みたいなものです。
そりゃあ、Cloudflare Pages を使ったほうがより安いし早いよ？異論は認める。
移行作業が泥臭い
WordPress から Hugo ということで、当たり前の話ですが WordPress のテーマやプラグインはすべて使えません。
とはいえ、直前まで使っていた Headless WordPress サービスもプラグイン周りはかなり制限されていましたが…。
WordPress でやっていたことを Hugo で完全再現するために以下を実施しました。
1. WordPressテーマの「移植」
これまで使っていた Headless WordPress の某サービスは、ビルドした HTML/CSS のエクスポート機能に対応していました。
そこで、その出力データを基に Hugo 用のテーマへ組み直しました。
移植にあたり活用したツールが GitHub Copilot です。
「この HTML 構造を Hugo のテンプレート構文に変換して」とぶん投げると、それっぽいコードが返ってきます。
最初から完璧なコードは出てこないようで、一発目はめちゃくちゃにレイアウトが崩れてました。
しかし、「ここが動いてない」「ここの表示がおかしい」と修正指示を繰り返し、ペアプログラミングのような感覚でなんとか移植に成功しました。
正直…、これが一番苦労した工程です。
2. 機能の代替
WordPress のプラグインに頼っていた機能は、以下のように置き換えました。
- SEO：Hugo の標準機能をフル活用し、テンプレートに meta タグを埋め込むよう調整。
- 埋め込みコンテンツ：SoundCloud などは、Hugo のショートコード機能を使用し、ID を入れるだけで展開されるように自作。
- Cookie 取得の同意機能：大まかな動作を把握したうえで GitHub Copilot に実装してもらう。
- フォーム、コメント、検索機能： 使ってないから無視。そもそも、移行前の Headless WordPress でも利用できない。
DevOps とセキュリティちゃんとやる
はい。ここからが、ただの「ブログ移行」ではなく「技術的な趣味」として力入れたところです。
Terraform と GitHub Actions、そして Renovate で、自動化とセキュリティを強化しました。
Terraform の管理最適化
suzuki-shunsuke/tfaction を導入し、リポジトリ内に複数の Terraform プロジェクトを扱えるようにしました。
さらに、tfaction や GitHub-comment を用いてプラン実行や適用を Pull Request 上にて可視化しました。
「ちりつも」なコスト削減
S3 へのアップロード（PUT リクエスト）は課金対象です。
無料枠内とはいえ無駄は嫌なので、GitHub Actions で「Hugo のコンテンツ（/web）に変更があった場合のみデプロイを実行する」という条件分岐を入れました。
Renovate による依存パッケージの更新だけで、毎度デプロイが走るのは勘弁してほしいですからね…。
評価環境の用意
公開する URL の他に、動作確認・評価用の別 URL を用意しました。Hugo のコンテンツ（/web）に変更がある Pull Request を作ると、自動的に評価環境にデプロイされます。
公開する前に記事の文章やレイアウトを評価環境で確認できます。
評価環境は Cloudflare Access を用いて個人契約している Google Workspace の SAML 認証のみアクセスできる制限を導入しています。
セキュリティの強化と手間の削減
以下のツールも導入して、セキュリティの向上にもトライしてみました。
- Trivy: Terraform コードに脆弱な設定（S3 が公開設定になっている等）がないか、CI でスキャン。
- Renovate: GitHub Actions のアクションや Terraform プロバイダのバージョン更新を自動化。
これにより、「放置していても腐らない」インフラが完成しました。
移行後してよかったこと
移行して数ヶ月経ちますが、かなり使い勝手のいい仕組みができました。
- コスト： 月額 3,000 円 → 数十円（AWS/Cloudflare の無料枠活用）。年間で約 3 万 6 千円の削減。
- 管理： 修正履歴がすべて Git に残るため、いつ何を変更したかが明確。
- 記事の書きやすさ：Markdown なので普段使いで慣れてるテキストエディタを使って編集できる。
- ベンダーロックインの回避：その気になればホスティングサービスをいつでも他のサービスに切り替えられる柔軟性。
以下は Headless WordPress と同じですが、純粋な WordPress と比べたメリット。
- セキュリティ：「WordPress のログイン画面への総当たり攻撃」などを気にする必要がなくなりました。
- パフォーマンス： 静的ファイルなのでページの表示が爆速。
最後に
WordPress は導入しやすい素晴らしい CMS ですが、維持や保守は怠いなと感じていました。
おそらく、これを読んでいる人は同じ思いを抱いていると思います。
とはいえ、静的サイトジェネレータへの移行は初期構築やテーマ移植に一定のスキルと労力が必要です。
しかし、「一度作れば、あとは GitHub に Push するだけ」という運用体験と「脆弱性に怯えなくていい」という安心感は、その労力に見合うだけの価値があります。
というわけで、「WordPress を使わない」という選択肢、いかがでしょうか？
Discussion