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 6
ドキュメントポータル	DocusaurusまたはAstro Starlight
低JS・テンプレート駆動サイト	Eleventy 3
静的+サーバー機能が必要なReactアプリ	Next.js 16 + OpenNext
ハイブリッドレンダリングのVueアプリ	Nuxt 4
Svelteチーム、軽量サイト	SvelteKit adapter-static

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

ホスティング先は重要です。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

GatsbyからAstroへ、すべてのコンテンツを書き直さずに移行できますか?

ほぼ可能です。AstroはMarkdownとMDXを両方ネイティブにサポートしているため、これらのコンテンツは最小限の変更で移植できます。難しいのは、GatsbyのGraphQLデータレイヤーをAstroのcontent collectionsに置き換えることと、ReactのページコンポーネントをAstroコンポーネントに書き直すことです。一度に書き換えるのではなく段階的な移行を計画し、プラグインの置き換えに最も時間がかかると見込んでおきましょう。

シンプルなブログやマーケティングサイトにNext.jsは過剰ですか?

たいていの場合、過剰です。Next.jsは主に静的出力しか必要としない場合でも、より多くのフレームワーク的複雑さを抱えているため、必要以上にバンドルサイズが大きくなり、ビルドも複雑になります。認証、動的ルート、サーバーロジックを持たないブログやマーケティングサイトであれば、Astro 6またはEleventy 3の方が通常、より少ない設定とシンプルなデプロイで、より高速なサイトを生成できます。

Astroのislandsアーキテクチャは既存のReactコンポーネントと動作しますか?

はい。AstroはReact、Vue、Svelte、Solidのコンポーネントを直接サポートしており、既存のReactコンポーネントを最小限の変更でAstroページに組み込めます。重要な変化は、client:loadやclient:visibleといったディレクティブを使って、どのコンポーネントにクライアントサイドハイドレーションが必要かを決定することです。これらのディレクティブを持たないコンポーネントはビルド時に静的HTMLとしてレンダリングされ、JavaScriptはゼロで配信されます。

Vercel上のNext.jsでベンダーロックインを懸念すべきですか?

以前ほどではありません。Next.js 16の安定版Adapter APIやOpenNextのようなプロジェクトにより、Cloudflare、AWS Lambda、その他のランタイムへのNext.jsデプロイが実用的になりました。とはいえ、Vercel固有の一部機能は依然としてVercel上で最もよく動作します。プラットフォーム非依存が必須要件であれば、プロジェクトの初期段階で利用機能とアダプターのサポート状況を照合して評価しましょう。