静的サイトジェネレータ比較：AstroとEleventy

TL;DR

企業のWebサイトやメディア、ブログを運営する際、「ページの表示速度をもっと速くしたい」「サーバーのセキュリティ対策や毎月の保守費用をできるだけ抑えたい」と悩んだことはないでしょうか。

従来の一般的なWebサイト（WordPressなど）は、訪問者がアクセスするたびにサーバーがプログラムを動かしてページを組み立てます。そのためアクセスが集中すると表示が遅くなり、プログラムの隙間を突いた不正アクセスの標的にもなりやすいという課題がありました。

この悩みを解消する手法が「静的サイトジェネレータ（SSG）」です。事前に文章やデザインを組み合わせて「完成したWebページ（HTMLファイル）」を一括で作成（事前ビルド）しておき、そのまま配る仕組みです。アクセス時にサーバーで計算を行わないため、表示が一瞬で完了し、不正アクセスの危険も大幅に減らせます。

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

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

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

---

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

事前ビルドの仕組み

通常のサーバーサイドレンダリング（SSR: 訪問者がアクセスするたびにサーバー側でページを組み立てる方式）では、ユーザーがアクセスするたびにサーバーがHTML（Webページの画面を作る標準形式）を生成して返します。一方SSGは、デプロイ前の事前ビルド（公開前にあらかじめページを一括で組み立てておく処理）ですべてのページを完成させておきます。ユーザーがアクセスしたとき、サーバーはすでに完成したHTMLを返すだけです。

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

速い理由

生成済みHTMLはCDN（コンテンツ配信ネットワーク: 世界中の中継拠点から一番近い場所でデータを届ける仕組み）のエッジサーバーにそのまま載せられます。データベースへの問い合わせもサーバー側での計算も発生しないため、Time To First Byte（TTFB: ブラウザがリクエストを送ってから最初のデータが返ってくるまでの待ち時間）が短くなります。CDNによるエッジ配信と組み合わせると、この差はさらに拡大します（CDNの仕組みについては CDNの仕組みと使いどころ — なぜCloudflareを挟むのか を参照してください）。

安全な理由

サーバー側で動くプログラムが存在しないため、そのプログラムの弱点を突く攻撃の標的になりません。代表的なのは、データベースを不正に操作するSQLインジェクションや、外部からサーバーに不正なプログラムを実行させるリモートコード実行です。配信されるのは完成済みのファイルのみです。動的な処理が必要な部分だけは、APIやサーバーレス関数に切り出します。APIは外部サービスとデータをやり取りする接続口で、サーバーレス関数はサーバーを自分で管理せずに必要な処理だけを動かせる仕組みです。そのため、不正アクセスの隙間を最小限に抑えられます。

安い理由

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

---

主要SSGの性格

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

AstroはHTMLファーストの設計を持ち、不要なJavaScriptをデフォルトで生成しないことを特徴とします。「アイランドアーキテクチャ」（ページ全体を静的なHTMLにし、操作が必要な一部分だけを「島」のように独立させて動かす設計手法）を採用しており、インタラクティブなコンポーネント（島）だけに選択的に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の独自テンプレートも許容できる	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は「どれが優れているか」ではなく「自分のコンテンツ・スキル・要件にどれが合うか」で選ぶものです。まず扱うコンテンツ量と動的要素の有無を整理し、次に開発言語の慣れを確認する順番で考えると判断しやすくなります。