静的サイトジェネレーター選定ガイド
静的サイトジェネレーター選定ガイド
このドキュメントは、プロジェクトで静的サイトジェネレーター（SSG）を選定する際の検討事項をまとめたものです。技術選定の一般的なフレームワークに基づき、実践的な評価基準と比較情報を提供します。
静的サイトジェネレーターの進化の歴史
各技術は、前世代の技術が抱えていた課題を解決するために生まれてきました。この進化の流れを理解することで、各技術の本質的な特徴と適切な用途が見えてきます。
第一世代：ブログ生成の自動化（2008-2012年頃）
Jekyll (2008年)
生まれた背景: 手動でHTMLを書く時代から、Markdownでコンテンツを管理し、テンプレートから自動生成する時代へ。
解決した課題:
- ブログ記事のHTML手動作成からの解放
- テンプレートによる一貫したデザイン
- GitHub Pagesとの統合（2013年）
残された課題:
- Ruby依存による環境構築の複雑さ
- ビルド速度が遅い（大規模サイトでは数分〜数十分）
- TypeScript非対応
- テンプレート構文（Liquid）の学習が必要
影響: 多くの静的サイトジェネレーターの基礎となった。GitHub Pagesの標準として広く採用された。
第二世代：パフォーマンスと柔軟性の追求（2013-2016年頃）
Hugo (2013年)
生まれた背景: Jekyllの「ビルドが遅い」という課題を根本的に解決するため、Go言語で高速なビルドエンジンを実装。
解決した課題:
- 極めて高速なビルド: 数千ページでも数秒でビルド完了
- シングルバイナリで環境構築が不要
- テンプレートエンジン（Go templates）の柔軟性
残された課題:
- TypeScript非対応
- Go templates構文の学習が必要
- プラグインエコシステムが限定的
影響: ビルド速度の重要性を業界に示した。大規模サイトでの採用が増加。
Gatsby (2015年)
生まれた背景: Reactエコシステムを静的サイトに持ち込み、CMS統合とパフォーマンス最適化を両立。
解決した課題:
- Reactコンポーネントによる柔軟なUI構築
- GraphQLによる統一的なデータ取得
- 豊富なプラグインエコシステム
- 画像最適化、コード分割などの自動最適化
残された課題:
- ビルド時間が長い（大規模サイトでは数十分）
- GraphQLの学習コスト
- 設定が複雑になりがち
- 静的サイトには過剰な機能が多い
影響: Reactエコシステムを静的サイトに持ち込んだ先駆者。多くの企業サイトで採用。
Next.js (2016年、Static Exportは2017年頃)
生まれた背景: ReactのSSR（サーバーサイドレンダリング）とSSG（静的サイト生成）を統合したフルスタックフレームワーク。
解決した課題:
- SSRとSSGの両方に対応
- Reactエコシステムの完全活用
- ファイルベースルーティング
- API Routesによるバックエンド機能
残された課題:
- 静的サイトには過剰な機能
- ビルド時間が長い
- 学習コストが高い
- デフォルトでJavaScriptが多め
影響: Reactエコシステムでの事実上の標準。多くの企業で採用。
第三世代：柔軟性と開発体験の向上（2017-2020年頃）
11ty (Eleventy, 2017年)
生まれた背景: 「テンプレートエンジンを選べる自由」と「設定の柔軟性」を追求。
解決した課題:
- 複数のテンプレートエンジン（Liquid、Nunjucks、Handlebars等）に対応
- 設定の自由度が高い
- プラグイン不要でシンプルな設計
残された課題:
- TypeScriptの完全対応が弱い
- 設定が複雑になりがち
- デフォルトの最適化が限定的
影響: 「設定より規約」ではなく「柔軟性」を選ぶ開発者に支持された。
VitePress (2020年)
生まれた背景: Viteの高速な開発体験をドキュメントサイトに適用。
解決した課題:
- Viteベースの超高速な開発サーバー
- Vue 3ベースのモダンな開発体験
- ドキュメントサイト向けの最適化
残された課題:
- ドキュメントサイト以外の用途には柔軟性が低い
- Vueエコシステムに依存
影響: 技術ドキュメントサイトの新たな選択肢として定着。
第四世代：パフォーマンスと開発体験の両立（2021年〜）
Astro (2021年)
生まれた背景: 「デフォルトで軽量」を実現し、必要な箇所だけJavaScriptを読み込む「Island Architecture」を提唱。
解決した課題:
- Island Architecture: デフォルトでHTMLとして配信、必要な箇所だけJavaScriptを読み込む
- TypeScript完全対応
- Markdown/MDXのネイティブサポート
- React/Vue/Svelte等のUIフレームワーク統合
- Viteベースの高速な開発体験
- ビルド速度が速い
残された課題:
- 比較的新しい技術（2021年リリース）
- エコシステムが成長中
- 将来のメジャーバージョンアップでの破壊的変更の可能性
影響: 「デフォルトで軽量」という新しいパラダイムを示した。コンテンツサイトでの採用が増加。
技術の系譜と選択の指針
ビルド速度重視の系譜
Jekyll (遅い) → Hugo (超高速) → Astro (高速)選択の指針: 大規模サイト（数千ページ以上）でビルド速度が重要な場合、HugoやAstroが適している。
Reactエコシステム重視の系譜
Gatsby (GraphQL) → Next.js (統合) → Astro (Island Architecture)選択の指針: 既にReactを使用している、またはReactコンポーネントを活用したい場合。ただし、静的サイトにはNext.jsは過剰な場合が多い。
柔軟性重視の系譜
Jekyll (固定) → 11ty (柔軟) → Astro (バランス)選択の指針: カスタマイズ性が重要で、テンプレートエンジンの選択肢が欲しい場合は11ty。バランスを取りたい場合はAstro。
ドキュメントサイト特化の系譜
Jekyll → Docusaurus → VitePress選択の指針: 技術ドキュメント、APIリファレンスなど、ドキュメントサイトに特化した機能が必要な場合。
現在の主要技術の比較
Astro (2021年)
強み:
- Island Architectureによるデフォルトでの軽量性
- TypeScript完全対応
- Markdown/MDXネイティブサポート
- 高速なビルド（Viteベース）
- React/Vue/Svelte等の統合可能
弱み:
- 比較的新しい技術
- エコシステムが成長中
適している用途: コンテンツサイト、ブログ、ポートフォリオ、軽量なWebサイト
選ぶべき場合: パフォーマンスと開発体験の両立を重視し、デフォルトで軽量なサイトを目指す場合。
Next.js (Static Export)
強み:
- Reactエコシステムの完全活用
- 豊富な機能と大規模なコミュニティ
- SSRとSSGの両方に対応
弱み:
- 静的サイトには過剰な機能
- ビルド時間が長い
- 学習コストが高い
- デフォルトでJavaScriptが多め
適している用途: Reactベースの動的サイト、既にNext.jsを使用しているプロジェクト
選ぶべき場合: 既にNext.jsを使用している、または将来的にSSRが必要になる可能性がある場合。
Gatsby
強み:
- GraphQL統合
- 豊富なプラグイン
- パフォーマンス最適化（画像最適化、コード分割等）
- CMS統合が容易
弱み:
- ビルド時間が長い
- 複雑な設定
- 学習コストが高い（GraphQL含む）
適している用途: 大規模なコンテンツサイト、CMS統合が必要なサイト
選ぶべき場合: Headless CMSと統合した大規模サイトを構築する場合。
Hugo
強み:
- 非常に高速なビルド
- シンプルな構造
- シングルバイナリで環境構築が不要
弱み:
- TypeScript非対応
- テンプレート構文（Go templates）の学習が必要
- プラグインエコシステムが限定的
適している用途: 大規模な静的サイト、高速ビルドが重要なプロジェクト
選ぶべき場合: 数千ページ以上の大規模サイトで、ビルド速度が最優先の場合。
Jekyll
強み:
- GitHub Pages統合
- 長い歴史と豊富なテーマ
- シンプルな構造
弱み:
- Ruby依存
- TypeScript非対応
- ビルド速度が遅い
適している用途: GitHub Pagesでホスティングするブログ、シンプルなサイト
選ぶべき場合: GitHub Pagesで簡単にホスティングしたい、シンプルなブログサイトの場合。
VitePress / Docusaurus
強み:
- ドキュメントサイト向けに最適化
- 豊富な機能（検索、ナビゲーション等）
弱み:
- ドキュメントサイト以外の用途には柔軟性が低い
適している用途: 技術ドキュメント、APIリファレンス
選ぶべき場合: 技術ドキュメントやAPIリファレンスサイトを構築する場合。
11ty (Eleventy)
強み:
- 柔軟性が高い
- テンプレートエンジンの選択肢が豊富
- プラグイン不要でシンプル
弱み:
- TypeScriptの完全対応が弱い
- 設定が複雑になりがち
適している用途: カスタマイズ性が重要なプロジェクト
選ぶべき場合: 最大限の柔軟性が必要で、テンプレートエンジンを選びたい場合。
選定時の実践的な検討事項
技術の進化の流れを理解した上で、プロジェクトの要件に合わせて選定します。
1. プロジェクトの規模と要件
サイト規模
- 小規模（〜100ページ）: どの技術でも問題なし。開発体験を重視。
- 中規模（100〜1000ページ）: ビルド速度を考慮。Astro、Hugo、Next.jsが候補。
- 大規模（1000ページ以上）: ビルド速度が重要。Hugo、Astroが有力。
コンテンツ形式
- Markdown/MDX: Astro、11ty、Hugo、Jekyll
- CMS統合: Gatsby、Next.js、Astro
- カスタム形式: 11ty、Astro
型安全性
- TypeScript必須: Astro、Next.js、Gatsby
- TypeScript不要: Hugo、Jekyll、11ty
2. 開発チームの状況
既存スキル
- React経験あり: Next.js、Gatsby、Astro
- Vue経験あり: VitePress、Astro
- テンプレートエンジン経験あり: 11ty、Hugo、Jekyll
学習コスト
- 低: Jekyll、Hugo（シンプルな構造）
- 中: Astro、11ty
- 高: Next.js、Gatsby（複雑な設定）
3. パフォーマンス要件
出力の軽量性
- 最優先: Astro（Island Architecture）
- 重要: Hugo、11ty
- やや重要: Next.js、Gatsby（最適化が必要）
ビルド速度
- 最優先: Hugo（超高速）
- 重要: Astro（高速）
- やや重要: Next.js、Gatsby（大規模では遅い）
4. 将来の拡張性
UIフレームワーク統合
- 必要: Astro、Next.js、Gatsby
- 不要: Hugo、Jekyll、11ty
SSRへの移行可能性
- 可能性あり: Next.js（既に対応）、Astro（SSR対応あり）
- 不要: Hugo、Jekyll、11ty
選定チェックリスト
選定時に確認すべき項目をチェックリスト形式でまとめます。
必須要件
- コンテンツ形式（Markdown/MDX等）に対応しているか
- TypeScript対応（必要な場合）
- 静的サイト生成が可能か
- Docker対応が容易か
- CI/CD統合が可能か
- 既存構造との適合性
開発体験
- シンプルで直感的なAPIか
- 充実したドキュメントがあるか
- ホットリロードが快適か
- ビルド時間が現実的か
パフォーマンス
- 生成されるHTMLが軽量か
- 必要な箇所だけJavaScriptを読み込む設計か
- SEO最適化が容易か
将来性
- 活発な開発が行われているか
- 十分なコミュニティがあるか
- エコシステムが充実しているか
- 技術の成熟度が適切か
コスト
- 学習コストが現実的か
- 既存知識を活用できるか
- 実装コストが適切か
- 運用コストが現実的か