JavaScriptプロジェクトのための静的サイトジェネレーター選び

静的サイトジェネレーターの選択を誤ると、時間以上のコストがかかります。それはデプロイモデル、ランタイムの複雑さ、そしてユーザーに届けるJavaScriptの量を左右します。2026年現在、選択肢は大きく成熟しましたが、同時に重要な点で分岐もしています。本記事では、その選び方の考え方を整理します。

すべての「SSG」が同じものではない

ツールを比較する前に、カテゴリを明確にしておくと役立ちます。Astro 6とEleventy 3は、純粋にコンテンツ重視の静的サイトジェネレーターです。JavaScriptを最小限に抑えた出力を生成し、ビルド時レンダリングを重視するよう設計されています。

Next.js 16、Nuxt 4、SvelteKitは、静的出力をサポートするハイブリッドフレームワークですが、主たる用途はSSGではありません。これらの基本的なメンタルモデルは、サーバーレンダリングまたはエッジデプロイされたアプリケーションです。純粋に静的生成のためだけに使うのも有効ですが、その場合でも、真の静的ファーストなツールに比べてかなり多くのフレームワーク的複雑さを抱え込むことになります。

これら2つのグループを同等に扱うと、誤った判断につながります。

フレームワーク別の概観

Astro 6は、コンテンツ中心のサイトやドキュメントポータルにおける最有力候補の一つになりました。islandsアーキテクチャによりデフォルトでJavaScriptをゼロ出力とし、コンポーネントごとにオプトインでインタラクティブ性を追加できます。Astro 6は同一プロジェクト内でReact、Vue、Svelte、Solidのコンポーネントをサポートします。コンテンツのパフォーマンスを最優先し、フレームワークの柔軟性が欲しいなら、2026年において最も明確な推奨はAstroです。

Eleventy 3は、フレームワークのオーバーヘッドを避けつつシンプルさと制御性を求める場合に最適なツールであり続けています。複数のテンプレート言語をサポートし、ビルド時間が高速で、クリーンなHTMLを生成します。Eleventy 3では完全なESMサポートと非同期設定が追加されました。これは時代遅れではなく、意図的にミニマルであり、それこそが一部のプロジェクトに必要なものなのです。

Next.js 16では安定版Adapter APIが導入され、マルチプラットフォームへのデプロイサポートが大幅に向上しました。これにはOpenNextが含まれ、Cloudflare、AWS Lambda、その他非Vercelランタイムへのデプロイが可能になります。チームがReactネイティブで、プロジェクトに静的ページ、APIルート、サーバーコンポーネントが混在するなら、Next.jsは依然として最も多機能な選択肢です。ただし、純粋なSSGではなくフルフレームワークを動かしているのだという認識は持っておくべきです。

Nuxt 4は、同等のハイブリッド機能をVueエコシステムにもたらします。nuxt generateによる静的生成は堅実で、ヘッドレスCMSプラットフォームともきれいに統合できます。マーケティングサイトや、後にサーバー機能が必要になりうるコンテンツ駆動アプリを構築するVueチームにとって、Nuxt 4は自然な選択肢です。

SvelteKit + adapter-static は、ほぼ静的なサイトを構築するSvelteチームにとって有効です。アダプターは完全に静的な出力を生成しますが、フレームワーク自体はサーバーファーストなモデルを前提としているため、純粋な静的モードでは一部の機能に回避策が必要になります。チームがすでにSvelteに精通していて、プロジェクトが軽量であれば、良い選択です。

Gatsby は依然として存在し、Netlify買収後もアップデートを受けていますが、かつてReact向けSSGのデフォルトたらしめていたエコシステムの勢いは、おおむねAstroやNext.jsへ移っています。GatsbyのGraphQLデータレイヤーは複雑なコンテンツメッシュにおいて有用ではありますが、新規のReact静的プロジェクトの出発点として自明な選択肢ではなくなりました。

Docusaurus は、大規模チームやオープンソースプロジェクトが運用するドキュメントサイトにおいて現実的なデフォルトです。Reactベースで、Metaがメンテナンスし、バージョニング、i18n、検索を標準で扱えます。個人開発者や小規模チームがドキュメントを構築する場合は、AstroのStarlightテーマが軽量な代替として検討に値します。

シンプルな意思決定フレームワーク

デプロイとホスティングの考慮点

ホスティング先は重要です。AstroとEleventyは、Netlify、Cloudflare Pages、S3、自前サーバーなど、どこにでもデプロイできるプレーンな静的ファイルを生成します。OpenNextを組み合わせたNext.js 16は非Vercelデプロイにおいて大きく改善されましたが、それでも真の静的出力よりは多くの設定を必要とします。NuxtとSvelteKitも同様の考慮が必要です。

Cloudflare Pagesを対象とする、あるいはエッジネイティブなデプロイが必要な場合、AstroとEleventyが最も摩擦の少ない選択肢です。ISRやサーバーコンポーネントが必要なら、どれを選んでもハイブリッドフレームワークの領域に入ります。

まず問うべき正しい質問

「どのフレームワークが最も人気か」から始めてはいけません。出発点は次の問いです。このプロジェクトはランタイムで実際にどれだけのJavaScriptを必要とし、自分はどれだけのサーバーインフラを管理する覚悟があるか?

答えが「最小限のJavaScript、サーバー不要」なら、Astro 6またはEleventy 3が、ハイブリッドフレームワークをそれらしく構成したものよりも適しています。動的ルート、認証、パーソナライゼーションが絡むなら、Next.js 16またはNuxt 4がプロジェクト途中でのツール切り替えなしに成長余地を提供してくれます。

まとめ

プロジェクトに最適なSSGは、レンダリング要件に合致したものであり、GitHubのスター数が最多のものではありません。プロジェクトが本当にどれだけのインタラクティブ性、サーバーロジック、インフラを必要とするのかについて正直に評価し、そのニーズを満たす最も軽量なツールを選びましょう。コンテンツサイトにハイブリッドフレームワークは不要であり、認証や動的ルートを持つアプリは純粋なSSGでは十分に機能しません。ツールをワークロードに合わせれば、自分自身のスタックと戦う数ヶ月を節約できます。

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.