2026年の静的サイトジェネレータ比較記事のほとんどは、2018年のHugoエバンジェリズム記事を引きずったまま、最後にAstroの段落を1つ追加したような内容になっている。このポストは、91,000ページのAstroサイト（HostList.io）を本番環境で運用し、かつ過去2年間でクライアント案件でEleventy、Hugo、Gatsbyの小規模プロジェクトをリリースした経験に基づいている。5つのジェネレータ、実際の本番データ、ノスタルジアなし。Astro paragraph at the end. This is the version after running a 91,000-page Astro site (HostList.io) in production, plus shipping smaller projects on Eleventy, Hugo, and Gatsby across client work in the last two years. Five generators, real production data, no nostalgia.
重要なポイント：Astroはコンテンツサイト向けの現代的なデフォルト、Hugoは生のビルド速度で勝る、Eleventyはコンフィグを最小限にしたシンプルさで勝る、そしてGatsbyは緩やかに衰退している。チームとコンテンツモデルで選択してください。Astro is the modern default for content sites, Hugo wins raw build speed, Eleventy wins config-light simplicity, and Gatsby is in soft decline; pick by team and content model.
2026年の誠実な現状：Astroは「モダン」セグメントを決定的に勝ち取り、Hugoは「高速で言語に依存しない」セグメントを決定的に勝ち取り、Eleventyはシンプルな設定を求めるJavaScript志向のニッチに最適、Gatsbyは緩やかに衰退中、Jekyllはいまやほぼ GitHub Pages と レガシープロジェクト向けに使われている。五者択一はぶっちゃけ「Astroを選べ、ただし理由がある場合を除く」というものだが、その理由は実在し、知る価値がある。フレームワークハブはより広いフレームワーク選択を扱うが、このポストは静的サイトジェネレータの部分に特化している。The framework hub covers the broader framework decision; this post is specifically about the static-site-generator subset.
5つのSSGを60秒で
- Astro——マルチフレームワークコンポーネントモデル（React、Vue、Svelte、Solid）、デフォルトではゼロJS、アイランドアーキテクチャ、Content Layer API。2026年の新しいコンテンツサイトの標準。
- Eleventy（11ty）——JavaScriptベース、シンプルな設定、ビルド時にJavaScriptがクライアントに送られない。ReactやVueのオーバーヘッドなしにJavaScriptの親和性を求めるエンジニアに最適。
- Hugo——Go製、このカテゴリで5～10倍最速のビルド、Node依存なし。ビルド時間が実質的にボトルネックになるコンテンツ豊富なサイト向けの最適選。
- Jekyll——Ruby製、GitHub Pages ネイティブ、成熟したテンプレートエコシステム。2026年ではレガシープロジェクトと無料GitHub Pages ホスティング向けに主に使われている。
- Gatsby——React ベース、GraphQL データレイヤー、2023年の Netlify 買収以降緩やかに衰退中。本番環境で今も安定しているが、新規プロジェクトのデフォルトではもはやない。Netlify acquisition. Still production-stable but no longer the default for new projects.
各 SSG が実際に勝つポイント
Astro: 本番環境で 91,000 ページの実績
Astro は 2026年に新規プロジェクトでほとんどのケースに採用されるようになった SSG。アーキテクチャ――デフォルトではゼロJS、オプションで対話性のアイランドが可能――は大多数のコンテンツサイトに最適な形。Content Layer API は Content Collections に代わり、あらゆるソースからタイプセーフでコンテンツを取得できる。Server Islands を使えば、静的ページの一部をリクエスト時にレンダリングでき、ページ全体を動的にする必要がない。HostList.io は Astro 5 で動作し、91,000ページ、モバイル Lighthouse の中央値92、フルリビルドで約18分のビルド時間、ルートあたり平均約80KBのクライアントJavaScript。
- 勝ちどき: あらゆるスケールの最新コンテンツサイト、プログラマティック SEO、マルチフレームワーク対応の柔軟性、最新インテグレーションをすべて揃えたエコシステム。
- 不足する点: Hugo レベルのビルド速度（Astro は 5,000 ページで約 4～7 分、Hugo は 30～60 秒）、Node がデフォルトでない Ruby および Go ショップ。
Eleventy: フレームワークのオーバーヘッドなしの JavaScript
Eleventy は React、Vue、または特定のコンポーネントモデルにコミットしない JavaScript ベースのテンプレートが欲しいエンジニア向けの SSG。設定は真の意味で最小限、ビルドパイプラインはシンプル、デフォルトのアウトプットはクリーンな HTML。ブログ型サイト、ドキュメント、小規模なマーケティングサイト向けの正解で、「ただ HTML が欲しい」というブリーフであり Astro のコンポーネントモデルがオーバースペックに感じる場合に最適。
- メリット：JavaScriptに精通しているがフレームワークのオーバーヘッドがない、シンプルなブログとドキュメントサイト、設定が軽い。
- デメリット：複雑なインタラクティブコンポーネント（自分で対応する必要がある）、Astroと比べて事前構築済みの統合エコシステムが小さい。
Hugo：実際に重要な場面でのビルド速度
Hugo は、ビルド時間がボトルネックになるサイト向けの SSG。5,000ページの Astro サイトは4～7分でビルドされ、同じサイトを Hugo でビルドすると30～90秒。20,000ページを超え、デプロイ頻度が1日1回以上のサイトでは、その差は機能する CI パイプラインと月200ドルのビルド分数が必要なパイプラインの差になる。トレードオフはテンプレート言語（Go テンプレート）とより小さなモダンエコシステム――Hugo のプラグインと統合は有用性志向で、Astro で得られるような豊かなモダン統合とは異なる。
- メリット：大規模でのビルド速度、言語に依存しないチーム、ビルド時間が実際のコストになる20,000ページを超えるサイト。
- デメリット：現代的なコンポーネントモデル（Goテンプレートはメリットしているエンジニアには古く感じる）、小規模チームの採用（Goテンプレートを知るエンジニアはJSXを知るエンジニアより少ない）。
Jekyll：GitHub Pagesと既存システムのメンテナンス
Jekyllは2026年で主に2つの理由で使われています：GitHub Pagesネイティブサポート（サイトがJekyllの形状なら無料ホスティング）、Jekyll がデフォルトだった時代に構築されたサイトの既存システムのメンテナンスです。2026年の新規プロジェクトでは、唯一のJekyllピックは「無料のGitHub Pagesホスティングが欲しい」です。CloudflareページまたはNetlify無料ティアのAstroが通常は現代的な選択肢です。
- メリット：無料のGitHub Pagesホスティング、既存サイトのメンテナンス。
- 対応が不十分な点：ほとんどの現代的なニーズ――Hugoより遅いビルド、Astroより古いツール類、どちらより小さいエコシステム。
Gatsby: 本番環境対応、緩やかな衰退
Gatsbyは2023年のNetlify買収以降、緩やかに衰退している。フレームワーク自体は安定しており、本番稼働中のサイトは動き続けるが、新規プロジェクトでGatsbyを選ぶ案件は著しく減っている。2018年のGatsbyの差別化要因だったGraphQLデータレイヤーは、今ではコンテンツサイトに対してはオーバースペックと見なされることがほとんど――AstroのContent Layer APIとNext.jsのデータフェッチングが、GraphQLのオーバーヘッドなしに同じ役割をこなしている。既存のGatsbyサイトがあり、移行のコストが合わないという場合のみが正当な判断だ。Next.js's data fetching cover the same ground without the GraphQL overhead. Right call only when you have a Gatsby site already and migrating off is not worth it.
- 有利な点：既存の Gatsby サイトで移行コストが見合わない場合。
- 不利な点：新規プロジェクト（コミュニティが移行済み）、機能開発速度（買収後の開発ペースが低下）。
意思決定ツリー――ビルドサイズとチーム構成で選ぶ
ページ数 10K 未満の最新コンテンツサイト、JavaScript に習熟したチーム
Astro。標準的な選択肢だ。任意のコンテンツソースに対して Content Layer API を使用し、時折の動的コンテンツには Server Islands を、その他すべてにはインテグレーションエコシステムを活用する。2026 年の標準的なケース（80%）である。
1 日複数回デプロイするページ数 20K を超えるサイト
チームが Go テンプレートに習熟している場合は Hugo。HostList は 91K ページを Astro でビルドするのに 18 分かかるが、Hugo なら 2～3 分だ。このスケール水準では、Hugo の CI コスト面での経済性が著しく向上する。HostList at 91K pages on Astro builds in 18 minutes; the same site on Hugo would build in 2-3 minutes. At that scale Hugo's economics get meaningfully better for CI cost.
ブログまたはドキュメンテーションサイト、設定を最小限にしたい場合
Eleventy。JavaScriptベース、最小限の設定、クリーンなHTML出力。「とにかくHTMLがほしい」という要件にぴったり。
無料のGitHub Pagesホスティングが必須
Jekyll。2026年でもなお、これが標準デフォルトの唯一のカテゴリ――GitHub Pagesのネイティブサポートにより、ホスティングインフラストラクチャのメンテナンスが不要。
既存のGatsbyサイト
本当に必要でない限りGatsbyにとどまる。GatsbyからAstroへの移行は標準的なサイズなら4～8週間で実現可能だが、稼働中で正常に機能しているサイトの移行コストは滅多に見合わない。
ビルド時間ベンチマーク――測定値であって、主張ではない
仮想のコンテンツサイト（5,000ページ）を基準に、画像最適化を有効にし、標準的なCI実行環境でデプロイ。
- Hugo: フルビルドに30～60秒。画像処理は並列で実行。このカテゴリーで本当に最速。
- Eleventy: 1～3分。JavaScriptベースだがオーバーヘッドは最小限。
- Astro: 4～7分。画像最適化パイプラインとContent Layerのビルドステップが重い部分。
- Jekyll: 3～8分。Eleventyより遅く、Gatsbyより速く、Rubyのブートが顕著なオーバーヘッドを追加します。
- Gatsby: 8～15分。GraphQLデータレイヤーがこのスケールで実際の時間を費やします。
50Kページでは、差は劇的に広がります。Hugoは約3～5分。Astroは約25～40分。Gatsbyは60分を超えます。日次以上のデプロイ頻度を持つ本番サイトの場合、これは有用なCIループと、ボトルネックになるループの違いです。
FAQ
AstroはHugoより優れていますか？
JavaScriptチームによる現代的なコンテンツサイトであれば、そう――AstroのコンポーネントモデルとContent Layer API、インテグレーションエコシステムはすべて、2026年の典型的なウェブプロジェクトにおいてHugoのGoテンプレーティングより有用である。20K ページを超えており、ビルド時間が実際のコストになるサイトであれば、Hugoが純粋なビルド速度で5～10倍勝る。選択はチームとスケールに依存し、異なるプロジェクト要件に対しては両者ともが正当な答えだ。
GatsbyからAstroに移行すべきですか？
Gatsbyサイトが実際の問題を引き起こしている場合のみ――遅いビルド、チームが保守できないGraphQL複雑性、セキュリティ懸念となる依存関係のドリフト。正常に動作しているGatsbyサイトであれば、4～8週間の移行コストはまず見合わない。Gatsbyコミュニティは先へ進んだが、フレームワークは依然として本番環境では安定している。
Hugoはなぜ、Astroよりはるかに速いのですか？
HugoはGoで書かれており、単一バイナリにコンパイルされ、静的テキスト生成に最適化されたGoのテンプレーティングエンジンを使用する。AstroはJavaScriptベース、Nodeを通じて実行され、必要に応じてReact/Vue/Svelteレンダラーを使う。根本的なアーキテクチャの違いは実在し、解消されない――Astroがビルド速度でHugoに追いつくことはない、言語が異なるから。Astroの答えは「ほとんどのサイトに十分」、Hugoは「本当に重要な場合に著しく高速」である。
Eleventyは2026年でもまだ関連性があるのか？
Astroのコンポーネントモデルなしで、設定が軽いJavaScript SSGを明確に求めるエンジニアにとってはそうだ。Eleventyはより「HTMLをくれ」という立場で、Astroよりシンプルだ。そしてこのシンプルさは本当に一部のチームに価値がある。ほとんどの現代的なコンテンツサイトにはAstroのほうが強力なデフォルトだが、シンプルさが明示的な目標であるブログ型サイトではEleventyがまだ勝つ。
GitHub Pagesの外でJekyllを使える？
技術的には、そう――JekyllはRuby対応のあらゆるホストで動く。2026年では実際にはレアケース。GitHub Pagesにデプロイしないのであれば、現代的な等価物はCloudflare PagesまたはNetlifyフリーティア上のAstro――より高速なビルド、より現代的なツールチェーン、同じフリーホスティングのストーリーを提供する。
関連する記事
Next.js vs Remix vs Astro、2026年――選択肢が純粋なSSGを超えて広がるときのフレームワーク比較。 -- the framework comparison when the choice expands beyond pure SSGs.
Web Frameworks Hub — より広範なフレームワーク判断ツリー、SSGコンテキスト付き。 -- the broader framework decision tree, with SSG context.
Headless WordPress + Astro：動作するセットアップ — SSGの選択がAstroとCMSのペアリングである場合の実践的セットアップ。 -- practical setup if your SSG choice is Astro paired with a CMS.
Next.jsで25,000ページのディレクトリを構築した方法 — スケール時の本番ケーススタディ；SSG vs Next.js判断コンテキストに有用。 -- production case study at scale; useful for SSG-vs-Next.js decision context.
SSG選択はビルド時とチームシェイプの決定であって、機能の決定ではない。次の2年間でチームが実際に保守するものによって選べ。
30分間のSSG選定コールを予約する — サイト構成、チーム、ビルド頻度、デプロイターゲットについて説明する。Astro vs Hugo vs Eleventyの判断を得る、それがブリーフに適合したもの。 -- describe the site shape, the team, the build frequency, the deploy target. Walk away with an Astro-vs-Hugo-vs-Eleventy decision that fits the brief.