コーポレートサイトを GCP から GitHub Pages に移行して月額 $23 を節約した話

Joomla CMS + wget による静的サイト生成パイプラインが、ホスティング移行をシンプルにしてくれた事例です。

はじめに

自社のコーポレートサイト（ccmp.jp）を GCP 上の VM + Cloud Load Balancer + Cloud CDN の構成から GitHub Pages に移行しました。もともと GitHub の有料プラン（Team）でリポジトリを管理していたため、GitHub Pages への移行で GCP 側の月額約 $23 のホスティングコストをまるごと削減できました。

移行がスムーズにいった最大の要因は、もともと Joomla CMS で入稿しつつ、配信は静的 HTML で行う構成を採っていたことでした。ホスティング先が変わっても、入稿ワークフローには一切手を入れる必要がありませんでした。

移行前の構成: Joomla CMS + GCP

CMS 入稿 → 静的 HTML 生成というアーキテクチャ

コーポレートサイトのコンテンツは Joomla CMS で管理しています。ただし、Joomla を本番サーバで動かしているわけではありません。入稿から配信までの流れは次のようになっています:

[Joomla CMS] → wget でクローリング → 静的 HTML 生成 → GitHub リポジトリに push
                                                          ↓
                                                  本番サーバで git pull → nginx 配信
  1. 入稿: ローカル環境の Joomla CMS で記事を作成・編集
  2. 静的化: wget で CMS の出力をクローリングし、静的 HTML ファイルとして localhost/ ディレクトリに出力
  3. デプロイ: 生成した HTML を GitHub リポジトリにマージし、GCP VM 上で git pull → nginx で配信

本番環境には PHP も MySQL も不要で、純粋な静的ファイル配信のみでした。前段に Cloud Load Balancer と Cloud CDN を配置し、キャッシュによるレスポンス高速化と VM への負荷軽減を行っていました。

このアーキテクチャのメリット

この「CMS で入稿、配信は静的 HTML」というアーキテクチャには、当初から以下のメリットがありました:

入稿者にやさしい: 記事の作成・編集は Joomla の WYSIWYG エディタで行えます。Markdown や HTML を直接書く必要がなく、非エンジニアでも入稿できます。

CMS の便利さを維持しつつ脆弱性を排除: Joomla や WordPress などの CMS は頻繁に脆弱性が報告され、攻撃の標的になりがちです。しかしこの構成では CMS はローカル環境でのみ動作し、本番には PHP も MySQL も存在しません。入稿者は CMS の WYSIWYG エディタやテンプレート機能をそのまま使えますが、攻撃者から見える本番環境は単なる静的ファイルだけです。CMS の利便性とセキュリティを両立できます。

ホスティングの自由度が高い: 配信するのは単なる静的ファイルなので、ホスティング先を自由に選べます。今回の GCP → GitHub Pages の移行でも、入稿フロー側は一切変更なしで済みました。

バージョン管理: 静的 HTML を GitHub リポジトリで管理しているため、変更履歴の追跡やロールバックが容易です。

そして、今回このメリットが最大限に活きました。移行作業はホスティング先の変更だけで完結し、コンテンツのワークフローには一切手を入れずに済みました。

移行先の検討: GitHub Pages vs Netlify

候補の選定基準

移行先の条件は以下の通りです:

  • 追加コスト $0: 既存の GitHub プランで利用できる静的ホスティングサービス
  • カスタムドメイン対応: ccmp.jp（apex ドメイン）で運用
  • HTTPS 対応: TLS 証明書の自動発行・更新
  • IPv6 対応: apex ドメインでも IPv6 到達可能
  • 自社 NS 維持: DNS のネームサーバは変更しない

Cloudflare Pages は NS 移管が原則必要なため不採用としました。自社 NS では ccmp.jp 以外のドメインやサービスの DNS も管理しており、NS を Cloudflare に移管すると他のサービスへの影響が避けられません。GitHub Pages と Netlify の 2 候補でステージング検証を行いました。

ステージング検証

それぞれサブドメインでステージング環境を構築し、実際の動作を検証しました。

GitHub Pages（stg-g.ccmp.jp）: GitHub Actions ワークフローで localhost/ を Pages にデプロイしました。CNAME と .nojekyll はワークフロー内で動的生成する構成としています（コンテンツ生成時に rm -rf localhost/ されるため、ファイルを直接置けません）。全項目問題ありませんでした。

Netlify（stg-n.ccmp.jp）: 今回のリポジトリは GitHub Organization 所有のプライベートリポジトリですが、Netlify Free プランではこの種のリポジトリの Git 連携が不可です（Pro $19/月が必要）。GitHub Actions から netlify deploy --prod で CLI デプロイする方式で回避しました。また、wget が生成するファイル名に ? や # が含まれており Netlify が拒否するため、デプロイ前にクリーンアップが必要でした。

比較結果

項目GitHub PagesNetlify Free
追加コスト$0$0
apex ドメイン A レコード4 IP1 IP のみ
apex ドメイン IPv6OK（AAAA 4 IP）NG（AAAA 非公開）
Git 連携ネイティブCLI 回避策が必要
ファイル名制約なし? # 不可

GitHub Pages を採用しました。決め手は apex ドメインでの IPv6 対応、ネイティブ Git 連携、ファイル名制約がない点です。なお、CDN については GitHub Pages も Fastly ベースの CDN を内蔵しており、Cloud CDN を別途構築する必要がなくなりました。

本番移行の実施

ステージング検証で問題がないことを確認した翌日に本番移行を実施しました。ステージング検証から GCP 撤去完了まで、作業期間は 2 日間でした。

  1. GitHub Actions ワークフローの CNAME をステージング用からプロダクション用（ccmp.jp）に変更
  2. GitHub の Settings → Pages → Custom domain を ccmp.jp に設定（DNS 切替前に実施し、TLS 証明書の発行を最速化）
  3. 自社 NS で ccmp.jp の A/AAAA レコードを GitHub Pages の IP に切替
  4. www.ccmp.jp の CNAME を追加（GitHub Pages が www → apex の自動リダイレクトを提供）
  5. 動作確認: HTTPS、Clean URL、リダイレクト、IPv4/IPv6 すべて OK

TLS 証明書について:

  • GitHub Pages は DNS が向いた時点で自動的に Let's Encrypt 証明書を発行します
  • 旧 GCP VM の証明書との衝突はありません（Let's Encrypt は同一ドメインに複数証明書を許可）
  • GCP 側の証明書は自然に期限切れになるだけで、手動対応は不要です

GCP インフラの撤去

本番移行の完了後、旧 GCP インフラ（VM、VPC、ロードバランサー、固定 IP、SSL 証明書など計 20 リソース以上）を Terraform で一括撤去しました。再構築が必要になった場合に備え、Terraform コードと手順書はリポジトリに残してあります。

まとめ

項目移行前（GCP）移行後（GitHub Pages）
GCP ホスティングコスト約 $23/月$0（GitHub Pages に移行）
TLS 証明書Let's Encrypt 手動更新自動発行・更新
IPv6対応対応
デプロイgit pull + nginxGitHub Actions 自動デプロイ
インフラ運用VM・LB・CDN の管理が必要不要

※ GitHub Pages をプライベートリポジトリで利用するには GitHub Pro 以上のプランが必要です。今回は既に GitHub Team プランを利用していたため、追加コストなしで移行できました。パブリックリポジトリであれば Free プランでも利用でき、GitHub Actions の無料枠（月 2,000 分）の範囲内であれば完全に $0 で運用可能です。

今回の移行で改めて実感したのは、入稿と配信を分離するアーキテクチャの強さでした。Joomla CMS による入稿ワークフローは一切変更せず、ホスティング先だけを差し替えることで移行が完了しました。コンテンツ管理と配信基盤を疎結合にしておくことで、将来また別のホスティングサービスに移る場合でも同様にスムーズな移行ができます。

もし「CMS は使いたいけど静的ホスティングのメリットも享受したい」という状況であれば、CMS + wget による静的サイト生成パイプラインは検討に値するアプローチだと思います。