SSG（Static Site Generator、静的サイトジェネレーター）は、原稿とテンプレートを組み合わせてビルドの段階でHTMLを作り、完成したファイルだけを配信する仕組みです。この記事では、リクエストのたびにHTMLを組み立てる従来型CMSとの構造差を整理したうえで、Next.js・Astro・Hugoの選び分け、Cloudflare Pagesのビルド20分という実際の上限、Next.jsのstatic exportで使えなくなる機能の一覧まで、一次情報の数値で確認します。WordPressで運用中のサイトを置き換えるべきか、ヘッドレスCMSとして残すべきかという分岐も検討の対象です。会員機能や在庫連動がある案件でSSGを見送る条件も、要件の形で言い切ります。
まとめ：静的サイトジェネレーターを企業サイトへ採用する条件と見送る線引き
判断は3つの要件で決まります。ログイン後の出し分けが不要であること、更新の反映が数分遅れても業務が回ること、公開ページ数が数千規模に収まること。この3つが揃う企業サイトなら、SSGは表示速度と運用費の両方で効きます。逆に1つでも外れるなら、従来型CMSかサーバーレンダリングを選ぶほうが総費用は下がります。
ツールは既存の技術資産で決めるのが現実的です。社内にReactの実装者がいるならNext.js、コンテンツ中心の広報サイトならAstro、記事数が多く構成が単純ならHugo。3つとも公式ドキュメントで想定用途が明示されており、そこから外れた使い方をすると追加実装の費用がかさみます。
制作会社へ依頼する前に決めておく項目も固定です。誰が原稿を更新するか、更新者が公開前に画面を確認する手段をどう用意するか、公開の承認を誰が持つか。この3点を決めずに着手した案件は、公開後に運用が回らず管理画面の追加開発に戻ります。
SSGの仕組み：ビルド時にHTMLを生成する流れと動的CMSとの構造差
SSGを理解する近道は、HTMLが作られる時点をどこに置いているかを見ることです。ここが従来型CMSとの唯一かつ最大の分岐点になります。
静的サイトジェネレーターの定義：原稿とテンプレートから事前生成するHTML
静的サイトジェネレーターは、Markdownファイルやヘッドレスの管理画面に入った原稿データを読み込み、テンプレートに流し込んで、ページごとのHTMLファイルを書き出すツールです。書き出しが終わった時点で成果物はHTML・CSS・JavaScriptの静的ファイルだけになり、公開サーバー側にPHPやデータベースは要りません。
Next.jsの公式ドキュメントでは、next.config.js に output: 'export' を指定して next build を実行すると、out フォルダにHTMLとCSS・JavaScriptが生成されると説明されています。ルートが2件なら out/index.html と out/404.html、記事ページは out/blog/post-1.html のようにファイル単位で並ぶ構成です。Next.js公式のstatic exportガイドに、この生成結果がそのまま記載されています。
配信されるのは、この書き出し済みファイルです。閲覧者のリクエストごとにHTMLを組み立てる処理が存在しないため、アクセスが増えても生成処理の負荷は増えません。
SSRやCSRとの違い：HTMLを作る時点がビルド時かリクエスト時かの差
SSR（サーバーサイドレンダリング）はリクエストが届くたびにサーバーでHTMLを組み立て、CSR（クライアントサイドレンダリング）はブラウザ側のJavaScriptで画面を描きます。SSGはこの処理を公開前のビルドへ前倒ししたものだと捉えると、3方式の関係が整理できます。同じフレームワークの中でページ単位に使い分けることも珍しくありません。
レンダリング方式そのものの定義や、ISR（差分再生成）を含めた速度・SEOの比較はSSR・CSR・SSG・ISG・ISRの違いと使い分けで技術面から扱っています。本記事はサイト構築の手法としてのSSG、つまりどのツールで何を作るかという層を担当します。
実務で混同が起きるのは、SSGという語がツール（静的サイトジェネレーター）と手法（静的サイト生成）の両方を指すためです。発注や要件定義の場では「ビルド時に全ページを書き出す構成」と言い換えると、認識のずれが消えます。
更新の流れ：原稿修正からビルド・デプロイまでに挟まる待ち時間の実際
SSGサイトの更新は、原稿を保存した瞬間には反映されません。管理画面やGitリポジトリの更新をきっかけにWebhookが飛び、ホスティング側がビルドを開始し、生成物をCDNへ配信して初めて公開状態になります。工程は次の順に進みます。
- 執筆者がヘッドレスCMSまたはMarkdownファイルで原稿を保存する
- 保存イベントがWebhookでホスティングサービスへ通知される
- ホスティング側がソースを取得し、ビルドコマンドを実行する
- 生成されたHTMLがCDNへ配信され、公開URLが差し替わる
この待ち時間が、SSGを採用できるかどうかの最初のふるいになります。数十ページ規模なら1分前後で終わりますが、後述するとおりページ数に比例して伸びる性質があり、修正のたびに全ページを作り直す構成では待ち時間が業務のリズムを決めてしまいます。
SSGのメリット：表示速度・攻撃面の縮小・配信コストに出る具体差
SSGの利点は抽象的な「速い・安全」ではなく、処理が存在しないことから来る構造上の差です。差がどこに出るかを分けて見ます。
表示速度：CDNから完成済みHTMLを返すため処理時間が積み上がらない
従来型CMSでは、1ページの表示にデータベース照会・テンプレート展開・プラグインの処理が積み上がります。SSGはその合計がゼロになり、残るのはCDNからファイルを返す時間だけです。Astroの公式ドキュメントは、同じサイトを主要なReactフレームワークで作った場合と比べて40%高速・JavaScriptは90%削減という数字を掲げています。これは配信するJavaScriptを既定で最小限にする設計から来る差です。
セキュリティと運用費：データベースと管理画面を公開側から切り離す構造
公開サーバーに動くプログラムが無い構成では、プラグインの脆弱性や管理画面への総当たりログインという攻撃経路が公開側に存在しません。WordPressの運用で毎月発生していたコアとプラグインの更新作業も、公開サーバーに対しては不要になります。守る対象はビルド環境とヘッドレスCMSの認証に絞られます。
配信コストも読みやすくなります。Cloudflare Pagesの公式ドキュメントでは、無料プランで月500回のビルド、1デプロイあたり20,000ファイル、Proプランで月5,000回のビルドと100,000ファイルという上限が示されています（2026年9月時点）。中小規模の企業サイトであれば、配信そのものの費用が月額数千円の枠に収まる計算です。
SSGのデメリット：更新反映の遅さとページ数増加で伸びるビルド時間
採用可否を分けるのは、利点ではなく制約のほうです。3つの制約は、どれも要件定義の段階で確認できます。
更新反映：公開操作からサイトに出るまでビルド時間ぶん遅れる制約
原稿の修正が即座に反映されないことは、運用部門にとって最初の違和感になります。誤字の修正でも、ビルドとデプロイが終わるまで公開ページは古いままです。ニュースリリースを時刻指定で出す運用がある企業では、予約公開のタイミングにビルドを走らせる仕組みを別途組む必要があります。
回避策は2つあります。1つはISR（差分再生成）のように、変更されたページだけを後から作り直す構成へ移すこと。もう1つは、頻繁に変わる部分だけをクライアント側から読み込む設計にすることです。ただし前者はサーバー機能を前提とするため、完全な静的書き出しからは外れます。
機能の制約：Next.jsのstatic exportで使えなくなる機能の一覧
完全な静的書き出しでは、サーバー側の実行を前提にした機能が落ちます。Next.js公式ドキュメント（version 16.3.5・2026年8月25日更新の表示）は、output: 'export' で非対応となる機能を明示しています。
| 落ちる機能 | 企業サイトで影響が出る場面 |
|---|---|
| Cookies | ログイン状態や同意状態に応じた出し分け |
| 書き換え・転送・ヘッダ設定 | 旧URLの転送設定やセキュリティヘッダの付与 |
| ISR（差分再生成） | 更新ページだけの差分再生成 |
| Server Actions | フォーム送信をサーバー側で受ける処理 |
| Draft Mode | 編集中の下書きプレビュー |
| 既定loaderの画像処理 | 画像の自動リサイズと形式変換 |
| Requestに依存するRoute Handler | リクエスト内容で応答を変えるAPI |
表の書き換え・転送・ヘッダ設定はRewrites・Redirects・Headers、ISRはIncremental Static Regenerationを指します。実務で痛いのはリダイレクトと下書きプレビューです。サイトリニューアルでは旧URLの転送が必須になりますが、静的書き出しではフレームワーク側の設定が効かず、ホスティングサービス側の転送機能で代替することになります。画像処理も外部サービスへの切り出しが前提となり、公式ドキュメントではカスタムloaderでCloudinaryなどへ寄せる例が示されています。
ビルド時間：Cloudflare Pagesの20分上限に当たるページ数の目安
ページ数が増えると、全ページ書き出しにかかる時間は上限に達するため注意が必要です。Cloudflare Pagesはビルドが20分でタイムアウトし、1デプロイで扱えるファイル数も無料プランで20,000という制限が公式に示されています。1ページあたりHTML・JSON・画像で複数ファイルを生成する構成なら、公開ページが数千に達した段階でファイル数の上限が先に見えてきます。
対処は3つの方向に分かれます。ビルド対象を更新分に絞る差分ビルド、画像を外部の配信サービスへ逃がす構成、そしてサーバー機能を持つホスティングへ移して差分再生成に切り替える判断です。ページ数が今後1万件規模へ伸びる計画があるなら、初期構成の段階でどの方向へ抜けるかを決めておくほうが安全です。
主要SSGの比較：Next.js・Astro・Hugoの想定用途と制作体制での選び分け
ツール選定で失敗する典型は、知名度で選んで運用体制と噛み合わないパターンです。公式が掲げる想定用途から逆算します。
3ツールの比較：言語・想定用途・企業サイトの運用で効く特性の違い
代表的な3つを、公式ドキュメントに書かれた設計思想の面から並べます。
| ツール | 実装言語・記法 | 公式が掲げる想定用途 | 企業サイトでの向き |
|---|---|---|---|
| Next.js（16.3系・2026年9月時点） | React・TypeScript | 静的サイト・SPAからサーバー機能へ段階的に拡張 | 将来的に会員機能や管理画面を足す前提の案件 |
| Astro | Astro記法・各種UIフレームワーク併用可 | ブログ・販促サイト・文書などコンテンツ駆動型 | 表示速度優先の広報サイト・オウンドメディア |
| Hugo（v0.166系・2026年9月時点） | Go製の単一バイナリ・テンプレート記法 | コンテンツ量の多い静的サイトの高速な生成 | 記事数が多く、構成が定型のサイト |
Next.jsはApp Routerでの最小構成と採用判断を別記事で扱っています。Astroが採るislandsの考え方はアイランドアーキテクチャの仕組みで実装面から整理しました。Hugoは公式ドキュメントで提供形態と設定項目を確認できます。
選び分けの基準：既存の技術資産と更新頻度の2軸で構成を決める手順
判断軸は2つで足ります。1つ目は社内または委託先にReactの実装者がいるかどうか。いるならNext.js、いないならAstroかHugoのほうが学習と保守の負担が軽くなります。2つ目は、後からサーバー側の処理を足す計画があるかどうかです。会員限定ページや予約機能を1年以内に足す構想があるなら、最初からNext.jsで組んでおくと移行工数が発生しません。
Hugoが向くのは、テンプレートが定型で記事本数が多い構成です。単一バイナリで動くため、ビルド環境にNode.jsのバージョン差異が持ち込まれない利点があります。一方でReactコンポーネントの資産は流用できないため、既存のデザインシステムをReactで持っている企業では選びません。
WordPressとの比較：更新担当が非エンジニアの企業サイトでの判断軸
日本の企業サイトはWordPressで動いているものが多く、SSGの検討は実質「WordPressをどうするか」の議論になります。置き換えるか、残して使うかで判断が分かれます。
更新体験の差：管理画面のプレビューとGit運用のあいだにある落差
WordPressの管理画面は、非エンジニアの更新者が下書きを保存し、公開前の見た目を確認し、そのまま公開できる導線を持っています。SSGでMarkdownファイルをGitで管理する構成にすると、この3つがすべて開発者の担当する作業です。広報担当が原稿を書いてエンジニアがコミットする運用は、更新頻度が週1回を超えた時点で滞ります。
そのため、非エンジニアが更新する企業サイトでSSGを選ぶなら、ヘッドレスCMSの併用がほぼ前提です。CMSの選定軸はヘッドレスCMSとは？従来型CMSとの違い・主要サービス比較と選び方で整理しています。プレビュー機能の有無は製品ごとに差が大きく、要件に入れずに選ぶと公開前確認ができない構成ができあがります。
併用の現実解：WordPressをヘッドレスCMSとして残す構成の適合条件
既存のWordPressを管理画面として残し、記事データをREST API経由で取得してSSGで書き出す構成も選択肢に入ります。更新者の操作は変わらず、公開側だけを静的ファイルに置き換える形です。適合するのは、投稿の編集権限やワークフローがすでにWordPress側で運用に乗っていて、それを壊したくない場合です。
この構成を選ばないほうがよい条件も明確です。プラグインで実現している機能（フォーム、会員、多言語の切り替え）が公開側で動いている場合、静的化すると同時にその機能が消えます。プラグイン依存を棚卸しして、公開側で動作する必要があるものが2つ以上残るなら、WordPressのまま高速化を図るほうが費用対効果は上です。
SSGを見送るべき場面：会員機能・在庫連動・即時更新が要る案件での線引き
ここは判断を曖昧にせず、要件の形で言い切ります。次の条件に当たる案件で完全な静的書き出しを選ぶと、追加開発で費用が膨らみます。
見送る条件：ログイン後の出し分け・在庫連動・分単位の更新がある要件
1つ目は、ログイン状態によって表示内容が変わる要件です。静的書き出しではCookieを前提とした出し分けができず、クライアント側で認証して描画し直す実装を足すことになります。会員向け価格の表示や取引先専用ページが要件にあるなら、この時点で採用しません。
2つ目は、在庫数や価格が営業時間中に変わる商材です。ビルドを挟む以上、更新は必ず遅れます。5分おきに全体をビルドし直す構成は、ビルド上限にも費用にも跳ね返ります。3つ目は、報道対応のように分単位で修正が必要な情報を出すサイトです。プレスリリースの差し替えに数分の遅延が許されない広報要件では、動的CMSを選ぶほうが筋が通ります。
採用してよい条件：更新が日次以下で公開ページが数千以内の企業サイト
逆に、次の3条件が揃うなら迷わず採用してよい領域です。更新頻度が日次または週次で、公開ページ数が数千以内に収まり、ログイン後の機能が無いこと。コーポレートサイト、採用サイト、製品紹介サイト、技術ブログの多くがここに入ります。
この条件下では、SSGは表示速度と運用の安全性を同時に取れます。フォームは外部のフォームサービスかサーバーレス関数へ切り出し、サイト内検索はクライアント側の索引か外部検索サービスで賄う構成が定番です。どちらも公開側にサーバーを戻さずに解決できます。
SSG導入の進め方：ホスティング選定と発注前に決めておく項目
構成の良し悪しより、決めごとの抜けが失敗を生みます。着手前に固める順序を示します。
ホスティング選定：制限値から逆算して企業サイトの構成を決める確認項目
先に見るのはホスティングの制限値です。Cloudflare Pagesを例にすると、ビルドは20分でタイムアウトし、1アセットは25MiBまで、1デプロイのファイル数は無料20,000・有料100,000、月間ビルド回数は無料500・Pro 5,000・Business 20,000という線が引かれています。ここから逆算して、想定ページ数と1日の更新回数が枠に収まるかを確認します。
月間500ビルドという枠は、1日あたり16回程度の公開操作に相当します。ニュースを1日3本更新する広報サイトなら十分ですが、複数部門が各自のタイミングで更新する運用では有料プランを前提にした方が安全です。動画や高解像度の画像を直接置く計画があるなら、1ファイル25MiBの制限にも当たります。
発注時に決める項目：企業サイトの更新者・プレビュー・公開承認の3点
制作会社へ依頼する段階で決めるべきことは3つです。誰が原稿を更新するか（広報担当か、制作会社か）、更新者が公開前に見た目を確認する手段をどう用意するか（ヘッドレスCMSのプレビュー機能か、ステージング環境か）、公開の承認を誰が持つか。この3点が決まっていれば、CMS選定とワークフロー設計はほぼ自動的に決まります。
逆に決めずに着手すると、公開直前に「広報が自分で直せない」という指摘が出て、管理画面の追加開発が発生します。企業サイトの構築を外部に依頼する場合は、この3点を要件書に書いたうえで見積もりを取ってください。当社の企業サイト制作・コーポレートサイト制作でも、更新体制の設計を構成決定の前段に置いています。
SSGに関するよくある質問：企業サイトでの方式選定・移行・機能実装の判断
SSGの検討時に実際に多い質問を、判断に必要な範囲で答えます。
SSGとSSRはどちらを選ぶべきですか？
更新の即時性が要件にあるかで決まります。ログイン後の出し分けや、在庫・価格のように分単位で変わるデータを表示するならSSRです。更新が日次以下で、全員に同じ内容を見せる企業サイトならSSGで足ります。両者は排他ではなく、Next.jsのようにページ単位で方式を変えられるフレームワークでは、トップページと製品ページを静的に、会員ページだけをサーバーレンダリングにする構成も取れます。判断の順序は、まず出し分けの有無、次に更新頻度です。
SSGはSEOに強いと言われますが実際はどうですか？
静的HTMLを返す構成はクローラーがJavaScriptを実行せずに内容を取得できるため、CSR中心の構成と比べるとインデックスの確実性は上がります。ただし順位を決めるのは内容と検索意図への適合であり、生成方式そのものが加点されるわけではありません。速度の改善はページ体験の指標に効きますが、記事の情報量や被リンクの差を覆すほどの効果は期待できません。CSR構成からの移行では効果が出やすく、WordPressで十分に速いサイトからの移行では差が小さくなります。
WordPressからSSGへ移行できますか？
記事データはREST API経由で取り出せるため、コンテンツの移行自体は可能です。問題になるのはプラグインで動いている機能で、問い合わせフォーム、会員ログイン、サイト内検索、多言語切り替えは静的化と同時に別の仕組みへ置き換える作業が発生します。移行前にプラグイン一覧を棚卸しし、公開側で動作している必要があるものを数えてください。2つ以上残るなら、移行費用が回収できない可能性が高くなります。
SSGで問い合わせフォームや検索機能は作れますか？
作れますが、公開側のサーバーではなく外部サービスかサーバーレス関数で受けます。フォームはホスティングサービスのフォーム機能や外部フォームサービスへ送信先を向ける構成が一般的です。サイト内検索は、ビルド時に生成した索引ファイルをブラウザ側で検索する方式と、外部の検索サービスへ問い合わせる方式に分かれます。記事数が数百までなら前者、数千を超えるなら後者が扱いやすくなります。
ビルド時間はどのくらいかかりますか？
ページ数と画像処理の量で変わるため、一律の目安は置けません。判断材料になるのはホスティング側の上限で、Cloudflare Pagesの場合は20分を超えるとタイムアウトします。数十ページの企業サイトは1分前後、数千ページのメディアでは10分を超える例が出てきます。上限に近づいたら、差分ビルドへの切り替えか、画像を外部配信サービスへ逃がす構成変更を検討する段階です。
関連記事
- CMSとは？種類・選び方：SSGと対比される従来型CMSの仕組みと選定軸を整理しています。
- コーポレートサイトとは：企業サイトに求められる役割と構成要素から要件を組み立てる記事です。
- サイトリニューアルの進め方：既存サイトからの移行で発生する作業と進行の順序を扱っています。
- レンダリングとは？CSR・SSR・SSGの違い：ブラウザ描画の仕組み側からレンダリング方式を解説しています。
- ヘッドレスCMSとは：SSGと組み合わせる管理画面の選定基準を製品比較つきで扱っています。
