SSG（Static Site Generation）は、ソースコードとコンテンツからビルド時にあらかじめ静的なHTMLファイル群を生成し、CDN経由でそのまま配信するレンダリング方式です。2008年にTom Preston-Werner氏が公開したJekyllが起点で、Hugo（2013年Steve Francia氏）、Gatsby（2015年Kyle Mathews氏）、そしてHexo・Eleventy・Astroなどがエコシステムを広げました。サーバを動かさずに済むためコストとセキュリティ面で有利で、JAMstackブームの中心的存在となりました。
この記事の目次
- ビルドから配信までの流れ
- SSGに向くサイト
- SSGが手に入る3つの利点
- SSRとの比較で見る使い分け
- まとめ
ビルドから配信までの流れ
SSGの動作は4段階で整理できます。1つ目は記事や商品データ、設定ファイルの用意で、MarkdownやMDXで書かれたコンテンツや、ヘッドレスCMSから取得したJSONをソースとして並べます。2つ目はビルドの実行で、Next.jsならnext build、Gatsbyならgatsby build、Hugoならhugoコマンドを叩くと、フレームワークがテンプレートにデータを差し込んで全ページのHTMLを書き出します。
3つ目の出力ステージでは、distやpublicといったフォルダにHTML・CSS・JS・画像が並んだフラットな静的ファイル群が完成します。4つ目はCDN配信で、Netlify、Vercel、Cloudflare Pages、GitHub Pagesなどのホスティングがその静的ファイルを世界中のエッジに複製し、ユーザーは最も近いエッジから即座にHTMLを受け取ります。サーバ側で動的処理が走らないため攻撃面が小さく、レスポンスも一定して速いという特長が生まれます。
SSGに向くサイト
SSGはコンテンツの更新頻度が高すぎず、ユーザー固有のパーソナライズが薄いサイトと相性が良い方式です。代表例は公式ドキュメントです。Vue、Rust、Reactなど多くのOSSプロジェクトはVitePressやDocusaurusでドキュメントをSSG化しており、GitHub Actionsで本文を更新するとCIがビルドしてホスティングへデプロイされる、という運用が標準化しています。技術ブログや個人サイトでもAstroやEleventyを使ったSSGが定番です。
プロダクトのランディングページ、イベント告知、社内のヘルプセンターなども典型的なSSG用途です。更新頻度が日次以下で、誰が見ても同じ画面でよいなら、SSGの「ビルド時に作ってCDNに置く」モデルは運用が極めて軽くなります。障害発生時もサーバが居ないので「DBが落ちて全画面500エラー」というシナリオが構造的に発生せず、セキュリティパッチ運用も不要に近い水準まで下げられます。コンテンツ量が膨大になるとビルド時間が課題になりますが、後述のISRやインクリメンタルビルドで緩和されています。
SSGが手に入る3つの利点
SSGがもたらす利点は3つの柱に整理できます。1つ目はレスポンス速度で、リクエストがCDNエッジに届いた瞬間に静的ファイルが返るため、DB問い合わせやサーバサイドの計算が一切入らず、世界中どこからアクセスしてもミリ秒単位で応答が返ります。2つ目はコストです。Netlifyの無料枠、Cloudflare Pagesの無制限プラン、GitHub Pagesの完全無料など、個人ブログや小規模サイトであれば月額ゼロ円での運用が現実的に可能です。
3つ目はセキュリティです。動的なバックエンドが存在しないため、SQLインジェクションやRCE（リモートコード実行）のような攻撃が成立しません。認証や決済が必要な部分はサードパーティのSaaS（Auth0、Stripeなど）に任せる構成が定着しており、JAMstack（JavaScript・API・Markup）と呼ばれる設計思想として広まりました。「動かないからこそ壊れにくい」というSSGの哲学は、運用負荷を下げたい中小サイトのオーナーや、個人ブロガーにとって極めて魅力的な選択肢になっています。
SSRとの比較で見る使い分け
SSGとSSRは似て非なる方式で、最大の違いはHTMLを「いつ作るか」です。SSGはビルド時にすべて作り終えてCDNに置き、SSRは毎リクエストで作って返します。そのためSSGは更新頻度が低く誰にとっても同じ内容のページに向き、SSRはユーザー固有のダッシュボードや在庫が刻々と変わる商品ページに向きます。「再生成が遅くてもよいか」「リアルタイム性が要るか」がそのまま判断軸になります。
実務ではこの二択ではなく、画面ごとに混在させるのが普通です。コーポレートサイトのトップやAboutはSSG、商品個別ページはSSR、後述のISRで人気記事だけ動的再生成、ログイン後はCSR、というようにNext.jsやNuxtでは画面単位で方式を選べます。「すべてSSGで足りるか」を最初に問い、足りない部分だけSSRやISRに昇格させるという順番で考えると、シンプルさを保ちつつ必要な動的機能を後付けでき、運用コストを抑えられます。
まとめ
SSGはビルド時に静的HTMLを生成しCDN配信する方式で、Jekyllを起点にHugo・Gatsby・Astroへと広がりました。速度・コスト・安全性の3点で大きな利点があり、ドキュメントやブログ、ランディングページのデファクトとなっています。リアルタイム性が必要な部分はSSRやISRに任せ、画面ごとに方式を組み合わせるのが現代的な使い方です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント