SSG

概要

SSG（Static Site Generation、静的サイト生成）は、リクエストが来てからHTMLを作るのではなく、デプロイ前のビルド時に全ページのHTMLをあらかじめ作っておく方式です。アクセスが来たら、できあがったファイルをそのまま返すだけ。サーバ側での計算が一切発生しないため配信は最速クラスで、アプリケーションサーバの運用そのものが不要になります。

MarkdownやCMSのデータを材料に、テンプレートやコンポーネントを通してHTML群を吐き出すツールを静的サイトジェネレータと呼びます。古くはJekyll、現在はAstro・Next.js・Hugo・Eleventyなどが代表格です。ブログ、ドキュメントサイト、コーポレートサイト、そしてこの知星図も、SSGで作られています。

なぜ生まれたか

もともとWebは静的なHTMLファイルの置き場でした。しかし手書きのHTMLでは、ヘッダーを1箇所直すのに全ページを編集する羽目になります。この管理不能さを解決したのが、データベースからHTMLを毎回動的に生成するCMS（WordPressなど）でしたが、今度は別の問題を抱えました。内容が昨日から変わっていないブログ記事のために、アクセスのたびにPHPが走りSQLが発行される。サーバは重く、攻撃対象領域は広く、プラグインの脆弱性やDBの故障が絶えません。

「更新はたまにしかないのに、なぜ毎回作り直すのか。更新のタイミングで一度だけ生成すればいいはずだ」——この割り切りがSSGです。2008年のJekyllとGitHub Pagesの組み合わせが火付け役となり、Gitで原稿を管理してpushしたら自動でビルド・公開、という開発者フレンドリーなワークフローが広まりました。動的生成の柔軟さを手放す代わりに、速度・堅牢性・運用の簡単さを得るという交換です。

詳細

ビルドと配信の二段構え

SSGの世界では、「ページを作る時間（ビルド時）」と「ページを届ける時間（リクエスト時）」が完全に分離されます。

2つの時間はCDNに置かれたファイルだけでつながっており、リクエスト時に走る計算はゼロです。

重い処理（データ取得、テンプレート展開、最適化）はすべてビルド時に済んでいるので、リクエスト時にはもう何も考えることがありません。この単純さは性能だけでなくセキュリティにも効きます。リクエスト時に実行されるコードが存在しないため、SQLインジェクションのようなサーバ側の脆弱性が原理的に成立しないのです。

CDNとJamstack

生成物がただのファイルであることは、CDNとの相性が抜群であることを意味します。世界中のエッジサーバにHTMLを複製しておけば、どこからのアクセスにも近距離で応答でき、オリジンサーバは不要です。この「静的配信 + 必要な動的機能はAPIで後付け」という構成はJamstackと呼ばれ、Netlify・Vercel・Cloudflare Pagesといったホスティングサービスが、Git連携からCI/CDによるビルド、CDN配信までを一体で提供しています。コメント欄や検索のような動的要素は、ブラウザ上のJavaScriptから外部APIを呼ぶ形で組み込みます。

制約: 更新はビルト待ち、ページ数はビルド時間

SSGの弱点は「内容の鮮度」と「規模」に集約されます。内容を1文字直すだけでも再ビルドと再デプロイが必要で、反映まで数分のタイムラグが生まれます。リクエストごとに内容が変わるページ——ログインユーザーのマイページ、リアルタイムの在庫表示——はそもそも作り置きできません。また、ページ数が数万〜数百万に達すると、全ページの事前生成はビルド時間の爆発を招きます。「更新頻度が低く、全員に同じ内容を見せる、規模が現実的なサイト」がSSGの適地であり、そこから外れるほどSSRやクライアント側での描画に軍配が上がります。

SSRとの中間解

この境界を柔らかくする手法も発達しています。代表がISR（Incremental Static Regeneration）で、生成済みの静的ページを配信しつつ、一定時間が過ぎたら裏側で再生成して差し替えます。「ほぼ静的だが、たまに新しくなる」ページ（ニュース一覧やECのカタログ）に有効です。また、Astroなどの現代的フレームワークはページ単位でSSGとSSRを混在でき、「基本は静的、動的が必要なページだけサーバレンダリング」という構成が標準になりつつあります。SSGかSSRかは二者択一ではなく、ページごとの更新頻度とパーソナライズの要否で使い分けるグラデーションとして捉えるのが現代的な理解です。