静的サイトジェネレータの選び方 — Astro / Hugo / Next.js / Eleventy を比較する

TL;DR

静的サイトジェネレータ（SSG）は、ビルド時にHTMLを生成してサーバーレスで配信できる形式に変換するツールです。サーバーサイドの処理をアクセスのたびに行わないため、表示が速く、攻撃対象が少なく、ホスティングコストも低く抑えられます。

主要なSSGには用途と設計思想の違いがあります。

ツール	一言評	向く用途
Astro	コンテンツ重視・島アーキテクチャ	ドキュメント・メディア・ブログ
Hugo	Go製・超高速ビルド	大規模コンテンツ・多言語サイト
Next.js	React・SSG/SSR/ISRハイブリッド	Reactで書きたい・動的要素が多い
Eleventy	シンプル・JavaScriptで拡張	テンプレート自由度が高い小〜中規模

どれを選ぶかは、コンテンツ量・動的要素の有無・開発言語の慣れで決まります。各ツールの詳細は後述します。

---

SSGとは何か — なぜ速く、安全で、安いのか

事前ビルドの仕組み

通常のサーバーサイドレンダリング（SSR）では、ユーザーがアクセスするたびにサーバーがHTMLを生成して返します。一方SSGは、デプロイ前のビルドステップでHTMLをすべて生成します。ユーザーがアクセスしたとき、サーバーはすでに完成したHTMLを返すだけです。

SSR: リクエスト → サーバー処理 → HTML生成 → レスポンス（毎回）
SSG: ビルド時にHTML生成 → CDN配置 → リクエスト → 静的HTML返却（即時）

速い理由

生成済みHTMLはCDNのエッジサーバーにそのまま載せられます。データベースへの問い合わせもサーバーサイド処理も発生しないため、Time To First Byte（TTFB）が短くなります。CDNによるエッジ配信と組み合わせると、この差はさらに拡大します（CDNの仕組みについては CDNの仕組みと使いどころ — なぜCloudflareを挟むのか を参照してください）。

安全な理由

サーバーサイドで動くコードが存在しないため、SQLインジェクションやサーバーサイドのRCE（リモートコード実行）が攻撃対象になりません。配信されるのは静的なHTML・CSS・JavaScriptのみです。動的な処理が必要な部分はAPIやサーバーレス関数に切り出すため、攻撃面を最小化できます。

安い理由

静的ファイルのホスティングは、アプリケーションサーバーの維持に比べてコストが大幅に低くなります。CloudflarePages・Netlify・VercelはいずれもSSGサイトを無料プランで公開できます。トラフィックが増えてもオリジンの負荷は変わらず、CDNが肩代わりします。

---

主要SSGの性格

Astro — コンテンツ重視・島アーキテクチャ

AstroはHTMLファーストの設計を持ち、不要なJavaScriptをデフォルトで生成しないことを特徴とします。「アイランドアーキテクチャ」と呼ばれる概念を採用しており、インタラクティブなコンポーネント（島）だけに選択的にJavaScriptを適用できます。

• テンプレート言語: .astro（独自構文。HTMLに近い）
• フレームワーク統合: React・Vue・Svelte・Solidなどのコンポーネントを同一プロジェクト内で混在可能
• コンテンツコレクション: MarkdownやMDXをスキーマ定義付きで型安全に管理できる仕組みがある
• ビルド速度: 中〜大規模でも実用的な速度

ドキュメントサイト・メディア・ブログのように、コンテンツが主体でJavaScriptは最小限にしたいケースに適しています。なお、本サイト InfraDB 自体も Astro と Cloudflare Pages で構築・運用しています。

Hugo — Go製・超高速ビルド

Hugoは Go で実装されており、ページ数が多くなるほどビルド時間の短さが際立ちます。数千〜数万ページを扱うコンテンツでも実用的なビルド速度を維持することで知られています。

• テンプレート言語: Goテンプレート構文（独自。学習コストは一定必要）
• コンテンツ管理: Markdownに対応。フロントマターでメタデータを管理
• テーマ・エコシステム: 公式テーマが豊富。サードパーティ製プラグインの仕組みはAstroほど柔軟ではない
• JavaScript依存: ゼロ（必要なら自分で追加）

Goを書く必要はありませんが、テンプレート構文の独特さに慣れるまでの壁があります。多言語サイトや大規模なコンテンツサイトで選ばれやすいツールです。

Next.js — React・SSG/SSR/ISRハイブリッド

Next.jsはReactのフレームワークであり、SSGだけでなくSSRやISR（Incremental Static Regeneration）も扱えます。ページ単位でレンダリング方式を選べるため、静的コンテンツと動的コンテンツが混在するアプリケーションに適しています。

• テンプレート言語: React（JSX/TSX）
• レンダリングモード: SSG・SSR・ISRを混在可能
• エコシステム: Reactエコシステムをそのまま活用できる。npmパッケージとの統合が容易
• ホスティング: Vercelとの統合が強い。Cloudflare PagesはNext.jsを部分的にサポート（Edge Runtimeの制約あり）

「Reactで書きたい」「一部のページはリアルタイムデータを使いたい」という要件があるときに選ばれます。純粋なSSG用途には必ずしもオーバースペックになるため、要件整理が先決です。

Eleventy（11ty）— シンプル・JavaScript

EleventyはJavaScriptで書かれたシンプルなSSGです。特定のフレームワークへの依存が少なく、テンプレートエンジンをNunjucks・Liquid・Markdownなど複数から選べます。設定ファイルがJavaScriptのため、カスタマイズの自由度が高い一方で、エコシステムは他のツールに比べて小さめです。

• テンプレート言語: 複数対応（Nunjucks・Liquid・Markdown・Handlebars 等）
• 依存: ゼロに近い。最小構成で動かしやすい
• JavaScript統合: サーバーサイドのロジックをJSで書けるため、柔軟にカスタマイズ可能
• フレームワーク: 特定のUIフレームワークへの縛りがない

既存のHTMLテンプレートを活かしたい・シンプルな構成を好む・フレームワーク非依存で管理したい、というケースに合います。

---

選定軸 — どれを選ぶか

以下の4軸で考えると整理しやすくなります。

1. コンテンツ量

• ページ数が数千を超えるなら: Hugo（ビルド速度の優位が顕著になる）
• 数十〜数百ページ規模なら: Astro・Eleventy（十分実用的）
• ページ数は少ないが動的要素が多いなら: Next.js

2. 動的要素の有無

• 完全に静的でよい（ブログ・ドキュメント）: Astro・Hugo・Eleventy
• 認証・リアルタイムデータ・パーソナライズが必要: Next.js（SSRやISRを活用）

インタラクティブな部品をSSGに足したい場合は、Astroの島アーキテクチャが選択肢になります。必要な部分だけにReactやVueコンポーネントを挿入できます。

3. 開発言語・チームのスキルセット

スキルセット	向くSSG
Reactを書き慣れている	Next.js（または Astro の React 統合）
JavaScriptには慣れているがフレームワーク非依存でいたい	Eleventy
GoやRubyの独自テンプレートも許容できる	Hugo
どれでもよい・コンテンツ優先	Astro

4. エコシステムとプラグイン

Next.jsはReactエコシステムをそのまま使えます。Astroは公式インテグレーションが多く、Tailwind・Reactコンポーネント・MDXなどを公式でサポートしています。HugoとEleventyはエコシステムがより小さく、外部ライブラリへの依存も少ないです。

---

ホスティング — 静的ファイルをどこに置くか

SSGのビルド成果物は静的ファイルのため、サーバーレスで配信できるプラットフォームが適しています。

プラットフォーム	特徴	無料プラン
Cloudflare Pages	Cloudflareのエッジ全拠点で配信・Workers連携可	あり
Netlify	CI/CDと統合・フォーム・サーバーレス関数	あり（帯域制限）
Vercel	Next.js開発元・ISR/Edge Functionsと統合	あり（商用利用制限）
GitHub Pages	GitHubと直結・シンプル	あり（パブリックリポジトリ）
AWS S3 + CloudFront	大規模・細かい制御が必要な場合	従量課金

コンテンツ重視のSSGサイトであれば、Cloudflare Pages はエッジ配信・独自ドメイン・HTTPS・無制限の帯域（Freeプラン）を揃えており、始めやすい選択肢です。デプロイはGitHub連携でプッシュのたびに自動実行されます。

Next.jsのSSRやISRを使う場合はVercelが機能的に最も統合されています。ただし商用利用には有料プランへの移行が必要になるケースがあります。

インフラをコードで管理する観点については インフラをGit管理すべき理由 — 設定ファイルをバージョン管理する も参照してください。

---

移行性 — 乗り換えのしやすさ

SSGを途中で変更する場合、コンテンツ（Markdown）は多くのSSGで再利用できますが、テンプレートやレイアウトは書き直しが必要です。

• Markdownコンテンツ: ほぼそのまま移行可能（フロントマターのスキーマ差異を調整）
• テンプレート/レイアウト: SSGごとに独自構文のため、原則書き直し
• プラグイン・統合: 依存するエコシステムが異なるため、代替を探す作業が発生

ツール選定の段階で「コンテンツ構造をMarkdownに閉じ込める」設計にしておくと、将来の乗り換えコストを下げられます。SSG固有の機能に深くロックインするほど移行コストは上がります。

---

まとめ

選定軸	向くSSG
コンテンツ量が多い・ビルド速度優先	Hugo
コンテンツ重視・JS最小化・フレームワーク混在	Astro
Reactスキルがある・動的要素が混在する	Next.js
シンプルさ重視・フレームワーク非依存	Eleventy
ホスティング（静的・無料帯域）	Cloudflare Pages
ホスティング（Next.js SSR/ISR）	Vercel

SSGは「どれが優れているか」ではなく「自分のコンテンツ・スキル・要件にどれが合うか」で選ぶものです。まず扱うコンテンツ量と動的要素の有無を整理し、次に開発言語の慣れを確認する順番で考えると判断しやすくなります。