Astroとは｜静的サイトジェネレーターの特徴・Next.jsとの違い・将来性を解説
最終更新日：2026/07/04
Astroとは、コンテンツ主体のWebサイトを高速に配信するためのオープンソースWebフレームワークです。ひとことで言うと、ブログ・LP・ドキュメントを静的HTML中心で配信し、動きが必要な部分にだけJSを差し込むタイプのフレームワークで、Next.jsとは別方向のパフォーマンス最適化を狙えます。フロントエンド技術の選定に悩むフリーランスエンジニア向けに、特徴・違い・案件動向・学習ロードマップを整理します。
先に結論
Astroはコンテンツ重視サイト（ブログ・LP・ドキュメント）に強いフレームワーク。デフォルトで静的HTMLを吐き、必要な部品だけJSを動かすIslandsアーキテクチャが中核
Next.jsとの違いは思想の差。Astroは「静的をベースに動的を足す」、Next.jsは「アプリを前提に静的化オプションを持つ」設計
ReactだけでなくVue、Svelte、Solidなど複数UIフレームワークを同一プロジェクトに混在できる点が独特
日本のフリーランス公開案件は執筆時点でまだ少なめ。Next.js/Reactを主戦場にしつつ、Astroは差別化スキルとして持つのが現実解
学習はAstro公式ドキュメントのチュートリアル→個人ブログ構築→Content Collections活用の順で立ち上がる
この記事でわかること
Astroの基本概念とIslandsアーキテクチャの仕組み
Next.js・Nuxt.js・SvelteKit・Gatsbyとの違いを比較表で整理
向いているケース・向かないケースの判断基準
フリーランスエンジニアから見た案件動向・単価相場の考え方
学習ロードマップとキャリア戦略
目次
Astroとは何か
Astroの主な特徴
Next.jsとの違い・使い分け
Nuxt.js・SvelteKit・Gatsbyとの違い
Astroが向いているケース・向かないケース
Astroの案件動向と単価相場（フリーランス視点）
学習ロードマップと将来性
よくある失敗と実践チェックリスト
まとめ
よくある質問
Astroとは何か
Astroは、2021年にFred K. Schott氏が公開したオープンソースのWebフレームワークです。ブログ・ドキュメント・企業サイト・LP（ランディングページ）のようなコンテンツ主体のサイトを、静的HTMLベースで高速に配信することに主眼を置いています。
Next.js・Nuxt.js・SvelteKitがいずれもアプリケーション開発にも強い設計で、SPA・SSR・SSGを柔軟に切り替えられるのに対し、Astroは「まず静的HTMLで出す。動きが必要な部分だけJavaScriptを流し込む」を出発点に据えて設計されています。ページ全体をSPA化する構成ではなく、ページを構成する部品単位でJSを送るか送らないかを決められるのが特徴です。
執筆時点ではAstro 5系がメジャーリリースの対象です。最新版・安定版は必ずAstro公式サイトのリリースノートで確認してから学習を始めてください。
開発の経緯とバージョン変遷
2021年8月：Fred K. Schott氏（Snowpack開発チーム）によるアルファ公開
2022年8月：Astro 1.0が正式リリース。ゼロJSデフォルトとMulti-framework対応が話題に
2023年8月：Astro 3.0でView Transitions API対応
2024年11月：Astro 5.0リリース。Content Layer API・Server Islandsが安定機能として提供
背景にあるのは、いわゆるJAMstackの潮流と「JSバンドルの肥大化」への反省です。SPA一辺倒で作られたコンテンツサイトが初期ロードや検索エンジン最適化の観点で不利になるケースが増え、そこに対する回答としてAstroが登場しました。
Islandsアーキテクチャの位置づけ
「Islands（アイランズ）」という概念自体は、Katie Sylor-Miller氏らが2019年頃から提唱していたUI設計パターンです。Astroはこの考え方をフレームワークとして本格実装した最初期のプロダクトとして広まりました。ページの大部分は静的HTMLで、点在するインタラクティブ部品（＝島）だけがハイドレーション（JSによる有効化）される、というモデルです。
ミニFAQ
Q. AstroはSSGだけのフレームワーク？
主軸は静的サイト生成（SSG）ですが、SSR・ハイブリッドレンダリング・オンデマンドの動的ルートにも対応しています。用途に合わせて出力モードを切り替えられます。
Astroの主な特徴
ゼロJSデフォルトと部分的ハイドレーション
Astroコンポーネント（.astroファイル）は、ビルド時にJavaScriptを含まないHTMLへ変換されるのが基本です。UIフレームワークのコンポーネント（React・Vue・Svelteなど）を埋め込んだ場合も、client:loadやclient:visibleといったクライアント指示を明示しない限り、そのままだと静的HTMLとして出力されます。
つまり、ページ内で「動きが必要な部品」だけをJavaScriptで動かせるため、送るバンドルサイズを部品単位でコントロールできます。ページ全体をハイドレーションするSPA型と比べ、適切にクライアント指示を絞れば、初期ロードやLighthouseスコアで有利になりやすい傾向があります（実際のスコアは実装・計測方法により変動します）。
複数UIフレームワークの混在
同じプロジェクトの中に、React・Vue・Svelte・Preact・Solid・Lit のコンポーネントを混在させて配置できます。「ヘッダーはReact製の既存資産、記事本文はAstro純正、コメント欄はSvelte」といった構成も物理的には可能です。
もちろん実務ではプロジェクト全体で1〜2種類に絞るのが保守性の観点で無難ですが、既存資産の移行時にどれか1つを選べる自由度は独特です。
Content Collections / Markdown・MDXネイティブ対応
コンテンツをプロジェクトの所定のフォルダ配下にMarkdown・MDX・JSON・YAMLで置き、Zodスキーマで型付きに扱えます。Astro 5ではContent Layer APIとして安定化し、CMSやAPIから取得したコンテンツも同じインターフェースで扱えるようになりました。
ブログ・ドキュメントサイト・ナレッジベースのように、大量の記事を型安全にビルドする用途で効いてきます。
SSG・SSR・ハイブリッドの切り替え
デフォルトはSSG（静的サイト生成）ですが、サーバー出力モード・ハイブリッドモードの設定で、ページ単位のSSRやオンデマンドレンダリングに切り替えできます。Astro 5からはServer Islandsとして、静的ページに動的な部品を差し込む仕組みも標準化されました。
View TransitionsとClient Router
ページ遷移時のアニメーションや、SPAライクな部分更新を実現する仕組みが公式パッケージに含まれます。SPA全振りにしなくても、ユーザー体験を近づけられる選択肢です。
ミニFAQ
Q. AstroはReactの代替になる？
考え方が異なるため単純な代替ではありません。Reactは「アプリケーションを組み立てるUIライブラリ」、Astroは「ページを組み上げる仕組み」です。Astroの中でReactコンポーネントを使うことも可能で、両者は組み合わせが前提の関係にあります。
Next.jsとの違い・使い分け
AstroとNext.jsは「モダンフロントエンドで選ばれることが多い」という点は共通ですが、思想と得意領域は異なります。
観点 | Astro | Next.js |
|---|---|---|
主な用途 | コンテンツ主体サイト（ブログ・LP・ドキュメント） | Webアプリケーション全般（SaaS・ダッシュボード・ECほか） |
デフォルト出力 | 静的HTML＋部分的JS | Reactベース（SSG／SSR／ISRを選択） |
UIレイヤー | フレームワーク非依存（React/Vue/Svelte等を混在可） | React前提 |
ハイドレーション | 部品単位（Islandsアーキテクチャ） | ページ／コンポーネント単位（RSC・Client Components） |
ルーティング | ファイルベース＋SSR/SSG切替 | App Router（RSC）／Pages Router |
データ取得 | Content Collections・fetch・API連携 | Server ComponentsやRoute Handlers |
デプロイ先 | 静的ホスティング全般＋各種アダプター | Vercel最適化、他プラットフォームも対応 |
学習コスト | 低〜中（HTML/JS基礎＋独自構文少し） | 中〜高（React・RSC・App Routerの理解が必要） |
日本の案件数 | 少ない部類（執筆時点） | 多い部類 |
Next.jsの詳細はNext.jsとは？React基盤のフレームワークの特徴・案件・将来性にまとめています。
使い分けの判断基準
サイトの中身が「記事・情報・LP」中心 → Astroが向くケースが多い
ダッシュボード・SaaS・複雑な状態管理を伴うUI → Next.jsが安定
既存のReact資産を活かしたい／チームがReactに集中 → Next.js寄り。ただしAstroの中でReactコンポーネントを部品として持ち込む選択肢もある
初期ロード・Lighthouseスコアを厳しく要求される → Astroの部分ハイドレーションが効きやすい
将来的にサーバーサイド機能を強く拡張したい → Next.jsが実績豊富
ミニFAQ
Q. Next.jsも静的サイト生成できるのに、あえてAstroを選ぶ理由は？
Next.jsもSSG可能ですが、Reactベースのアプリ設計を前提にする場面が多く、コンテンツサイトでもReact中心の構成になりやすい傾向があります。Astroは静的をベースに置きJSを部品単位でしか送らないのが標準挙動のため、コンテンツサイト用途では初期バンドルを絞りやすい設計になっています。
Nuxt.js・SvelteKit・Gatsbyとの違い
Nuxt.jsとの違い
Nuxt.jsとは？Vue.jsベースの特徴・案件単価で解説しているとおり、Nuxt.jsはVue.jsをベースにしたメタフレームワークで、Vue Router・状態管理・SSR/SSG／APIルートまで一体化しています。
AstroはVueも使えるが、Vueに縛られない：ページの多くは静的HTMLで、必要な部分にVueコンポーネントを差し込む使い方
NuxtはVueアプリを前提とした設計：ページ全体がVueで組み上がるSPA/SSRアプリ
Vueベースでコンテンツサイトも書きたい場合、NuxtのSSGを使う道もあります。Vue主体のアプリならNuxt、コンテンツ主体でVueも一部使いたいならAstro＋Vueインテグレーション、という切り分けが実務的です。
SvelteKitとの違い
SvelteKitはSvelteをベースにしたメタフレームワーク（詳細はSvelteとは？特徴・年収・将来性を参照）で、SPA・SSR・SSGをファイルベースルーティングで書けます。
AstroはUIフレームワーク非依存、SvelteKitはSvelte前提
コンテンツ主体サイトならAstro＋Svelteインテグレーションという組み合わせも可能
大規模アプリケーションを1つのUIレイヤーで統一するならSvelteKitのほうが素直
Gatsbyとの違い
Gatsbyは、Reactベースの老舗SSGです。GraphQLでデータレイヤーを扱うのが特徴でしたが、近年は開発ペースが鈍化し、コミュニティの重心が他フレームワークに移っている印象があります。
Gatsbyから移行を検討するチームは、コンテンツサイトならAstro、アプリケーション寄りならNext.jsに移るケースが目立ちます
Content Collectionsの導入で、GatsbyのGraphQL層に依存していた「型付きコンテンツ取得」の代替がAstro単体でしやすくなりました
比較サマリ
観点 | Astro | Nuxt.js | SvelteKit | Gatsby |
|---|---|---|---|---|
UIレイヤー | 非依存（React/Vue/Svelte等） | Vue | Svelte | React |
デフォルト挙動 | 静的HTML＋Islands | Vueアプリ（SSR/SSG） | Svelteアプリ（SSR/SSG） | 静的サイト（Reactアプリ） |
得意領域 | コンテンツ主体サイト | Vue系Webアプリ全般 | Svelte系アプリ全般 | Reactベースの旧来型SSG |
コミュニティ動向 | 拡大傾向 | 安定 | 拡大傾向 | 相対的に鈍化 |
※コミュニティ動向欄は、公式リポジトリのリリース頻度・周辺プラグインの拡充・カンファレンス／登壇での露出などを踏まえた概観です。数値による厳密な指標ではないため、詳細は各プロダクトのGitHubや公式ブログで最新状況を確認してください。
Astroが向いているケース・向かないケース
向いているケース
企業のオウンドメディア・ブログ（記事数が多く、更新頻度は中程度）
プロダクトの公式ドキュメントサイト（バージョン管理・全文検索と相性がよい）
LP・キャンペーンサイト（Lighthouseスコア・Core Web Vitalsをシビアに要求されるケース）
技術ブログ・ポートフォリオ（Markdown中心で書きたい個人開発者）
中規模の企業サイト（部分的にお問い合わせフォーム・検索機能など動的部品が入る構成）
向かないケース
管理画面・ダッシュボード・SaaS本体（状態管理・認証・多数のクライアント側インタラクションが中心）
リアルタイム性が要件のアプリ（チャット・ライブコラボ・ゲーム）
チームがReact・Next.js運用に完全に慣れており、新規学習の余裕がないプロジェクト
極端に小規模なペライチサイト（Astroを持ち出すほどの構成ではないケースがある）
規模別の判断イメージ
ページ規模 | インタラクション量 | 相性 | コメント |
|---|---|---|---|
数ページ〜十数ページ | 少ない | ◎ | Astroの真価が出やすい |
数十〜数百ページ | 中程度 | ◎ | Content Collectionsで型付きに扱える |
数千ページ超のコンテンツ | 少〜中 | ○ | ビルド時間・増分ビルド対策を検討 |
全ページが対話的アプリ | 多い | △ | Next.jsやSvelteKitが素直 |
Astroの案件動向と単価相場（フリーランス視点）
国内のフリーランス公開案件の状況
国内主要フリーランスエージェントの公開案件検索ベース（執筆時点）で見る限り、Astro単独指定の案件はNext.js・Reactに比べて大幅に少ない傾向があります。エージェントや期間によって表示件数は変動しますが、Next.jsで検索したときの件数と比べると1桁〜2桁少ないケースも珍しくありません。
一方で、次のような形での露出は徐々に増えています。
メディア・オウンドメディアのリニューアル案件でAstroが指定される
既存Next.jsサイトのマーケティング領域（ブログやドキュメントのパス配下）だけをAstroに切り出す構成
スタートアップのプロダクトサイト・ドキュメントサイトの新規構築
副業・受託・海外リモートでの個別委託
母集団が小さく時期によるブレが大きいため、単価数字を一律で言い切るのは避けたい状況です。実際の相場は、各エージェントの最新公開案件で確認するのが確実です。
単価帯の捉え方
Astro単独指定の案件は数が限られるため、モダンフロントエンド全般（React／TypeScript／Next.js）を軸にAstroも扱えるプロフィールで応募するのが現実的です。フロントエンド全体の単価感については、2026年版フリーランスエンジニアの単価相場も参考にしてください。
求められがちなスキルセット
HTML・CSS・JavaScript（ES2015以降）の基礎
TypeScriptの実務経験
React または Vue のいずれかを実務で1つ以上扱える
静的ホスティング（Vercel・Netlify・Cloudflare Pages）のデプロイ経験
Markdown・Content Collections等でのコンテンツ設計経験
Astroの案件は「静的化・パフォーマンス改善・SEO対策」を目的とすることが多く、コンテンツ設計とパフォーマンス最適化の両方に踏み込める人が評価されやすい印象です。
ミニFAQ
Q. Astroだけを武器にフリーランス独立できる？
現状の国内公開案件の少なさを踏まえると、Astro単独に絞るのはリスクが大きい選択です。React／Next.jsを主力に据え、Astroは「静的化・パフォーマンス改善の差別化スキル」として持つほうが立ち上がりが早いはずです。
学習ロードマップと将来性
ステップ1：前提知識の確認
HTML・CSS・JavaScript ES2015以降（JavaScriptとは？できることや年収・将来性）
TypeScriptの基礎（TypeScriptとは？JavaScriptとの違い）
ReactかVue、いずれかのコンポーネント指向UIの経験があると理解が早い（Reactとは？初心者向け入門解説）
ステップ2：公式チュートリアルで構文に触れる
Astro公式のチュートリアル（Build a blog）を最初にこなすのが最短ルートです。ブログサイトの立ち上げを通じて、ページ・レイアウト・コンポーネント・Markdownの扱いを一通り体験できます。
ステップ3：Content Collectionsで型付きコンテンツを扱う
型付きコンテンツをZodスキーマで定義し、記事一覧やタグ絞り込みを実装します。ここまで押さえると、個人ブログ・小規模メディアなら実運用に耐える構成が組めるようになります。
ステップ4：Islands＋UIフレームワークを組み合わせる
React・Vue・Svelteのいずれかを組み込み、フォームやモーダルなどのインタラクティブ部品を実装します。クライアント指示（client:loadやclient:visible等）の使い分けを覚えることで、部分ハイドレーションの感覚がつかめます。
ステップ5：SSR／Server Islands・デプロイまで一気通貫
Vercel／Netlify／Cloudflare Pagesのいずれかにデプロイし、SSRやサーバーサイド機能（Server Islands・APIエンドポイント）を1本作ってみます。デプロイ環境の理解はVercelとは？特徴・Next.js連携・料金やNetlifyとは？特徴・Vercelとの違い・料金も併読しておくとイメージしやすくなります。
将来性の論点
エコシステムの厚み：インテグレーション（React・Vue・Svelte・Tailwind・MDX・画像最適化・サイトマップなど）は年々充実
企業サイト・ドキュメントサイトでの採用事例：Astro公式のショーケースで企業サイトやプロダクトドキュメントの導入例がまとまっており、実務プロジェクトでの採用が広がりつつある
Server Islands / Content Layer：Astro 5系で提供された機能が、実務での適用範囲を「静的サイト」から一歩広げる方向へ動かしている
国内普及の鍵：メディア・出版・企業サイト領域での採用事例が積み上がるほど、公開案件にも波及しやすくなる
「廃れるか」という観点では、少なくとも現時点ではコミュニティ活動やアップデート頻度を見る限り、急速に縮小する兆候は強くありません。一方、「日本のフリーランス案件で主役になるか」は別問題で、日本の公開案件市場では現時点では限定的で、今後の拡大余地を見込む段階という見方が安全です。
よくある失敗と実践チェックリスト
失敗1：SPAの発想でAstroを使う
「ページ全体でReactを動かす」感覚のままAstroを触ると、client:loadをすべての部品に付けてしまい、Astroの軽さが消えます。まず静的で書き、動きが必要な部品だけをクライアント指示で明示的にハイドレーションする、という順序が基本です。
失敗2：複数UIフレームワークを本格運用に持ち込みすぎる
「React・Vue・Svelteを同時に使える」ことに惹かれて全部混ぜると、ビルドサイズと保守負荷が跳ね上がります。実務ではプロジェクト単位で1〜2種に絞るのが現実的です。
失敗3：SSRを過剰に選ぶ
デフォルトはSSGで、その方が高速かつ運用が単純です。リアルタイム性が求められないページまでSSRにしてしまうと、Astroを選んだ理由が薄れます。ページ単位で必要最小限に絞りましょう。
失敗4：バージョン間の破壊的変更を追えていない
Astroはメジャーバージョンごとに設定・API・出力モードが変わってきました。学習・実装時は、参照している記事やチュートリアルがどのバージョンを前提に書かれているかを必ず確認してください。旧バージョンのサンプルコードで詰まるケースがよくあります。
実践チェックリスト：Astroを技術選定する前に
[ ] サイトの中心が「コンテンツ配信」か「アプリケーション」かを明確にした
[ ] Lighthouse／Core Web Vitalsの目標値がプロジェクト内で合意されている
[ ] Reactのみを使うのか、Vue・Svelteも混ぜるのかチーム内で決めた
[ ] SSGだけで足りるのか、SSR／Server Islandsが必要なのかを整理した
[ ] デプロイ先（Vercel／Netlify／Cloudflare／自社サーバー等）とアダプターの相性を確認した
[ ] Content Collectionsで扱うコンテンツのスキーマ設計を最低限イメージできている
[ ] チーム全員が最新バージョンのドキュメントを読む前提を作れる
実践チェックリスト：Astroを学習する前に
[ ] HTML・CSS・JavaScriptの基礎が固まっている
[ ] Reactか Vueのいずれかを実務またはハンズオンで触った経験がある
[ ] Node.js／npmでのプロジェクト初期化に慣れている
[ ] 公式ドキュメントを英語で読む耐性がある（一次情報は英語がメイン）
[ ] 静的ホスティング（Vercel・Netlify・Cloudflare Pages）のデプロイを体験している
まとめ
Astroは「コンテンツ主体サイトのために設計された、静的HTMLベースのフレームワーク」です。要するに、Astroは「静的を基本に、必要な部分だけ動的化する」フレームワークで、Reactに縛られず、Islandsアーキテクチャで部品単位にJSをコントロールできる点が他フレームワークとの最大の違いです。フリーランスエンジニアにとってはNext.js／Reactを主軸にしつつ、Astroは差別化スキルとして持つのが現実解になります。
Astroは静的HTMLをベースに、必要な部品だけJSを動かすIslandsアーキテクチャが中核
Next.jsは「アプリ前提」、Astroは「コンテンツ前提」で、思想がそもそも異なる
React・Vue・Svelte・Solidなど複数UIフレームワークを混在でき、既存資産の活用余地が大きい
日本のフリーランス公開案件はまだ少なめ。React／Next.js＋TypeScriptを本線に、Astroは差別化スキルとして育てる戦略が有効
学習ロードマップは「公式チュートリアル→Content Collections→Islands＋UIフレームワーク→SSR／デプロイ」が現実的
技術選定は「サイトの中心がコンテンツか、アプリケーションか」を最初に切り分けるのが判断のコツ
次のアクションとしては、まずAstro公式ドキュメントのチュートリアルで小さなブログサイトを1本作ってみることをおすすめします。フロントエンドの市場感や案件動向については、フロントエンドエンジニアとは？仕事内容・スキル・年収・Reactとは？初心者向け入門解説・Next.jsとは？React基盤のフレームワークの特徴・案件・将来性・Nuxt.jsとは？Vue.jsベースの特徴・案件単価・Svelteとは？特徴・年収・将来性もあわせて確認してください。
参照元・一次情報：
よくある質問
Q1. Astroは初心者でも学べる？
HTML・CSS・JavaScriptの基礎があれば、フレームワークとしては入りやすい部類です。「まず静的HTMLで作り、あとから動きを足す」思考のため、モダンフロントエンドの入り口としても向いています。ただし、実務ではTypeScriptや周辺エコシステムの理解も必要になるため、フロントエンドの基礎は並行して押さえておくのが無難です。
Q2. AstroとNext.jsはどちらを先に学ぶべき？
案件数の多さで選ぶなら、まずはReact／Next.jsに投資したほうが立ち上がりは早いです。Astroは差別化スキルとして「静的化・パフォーマンス改善」を武器にしたい人が選ぶルートになります。両方を扱えると、案件で「サイト構成の切り分け提案」ができるようになります。
Q3. Astroの中でReactコンポーネントを使うと重くなる？
クライアント指示（client:load等）を付けなければ、Reactコンポーネントもビルド時に静的HTMLへレンダリングされます。動きが必要な部品だけをクライアント指示でハイドレーションする限り、ページ全体をReactで動かす構成より軽くなるのが基本形です。
Q4. AstroはSEOに強い？
SSGでHTMLを直接配信できるため、検索エンジンとの相性は良好です。ただし「フレームワークが優れているから順位が上がる」わけではなく、コンテンツ品質・構造化データ・内部リンク設計といった本筋を別途詰める必要があります。
Q5. AstroとJAMstackは何が違う？
JAMstackは「JavaScript／API／Markupを組み合わせた構成」というアーキテクチャの考え方の名前で、Astroはその考え方を実装したフレームワークの1つです。Next.js（静的モード）や11ty、Hugoなども広い意味でJAMstack的な構成を作れます。
Q6. Astroにデータベースは繋げられる？
SSRモードやAPIエンドポイントを使えば、通常のNode.jsアプリと同様にデータベースと連携できます。Content Layer APIを使えば、外部APIやCMSからのコンテンツ取得もビルド時に一元化できます。
Q7. Astro DBは今も使える？
Astro DBは当初公式サービスとして提供されていましたが、方針転換が公表されているため、採用前に必ずAstro公式ブログで最新の提供状況を確認してください。永続的なデータ保持を伴う機能を業務利用する場合は、Turso・Supabase・PlanetScaleなど汎用DBを組み合わせる構成のほうが読み手側でも安心です。
Q8. Astroで会員制サイトや認証機能は作れる？
Server IslandsやAPIエンドポイントを使えば、認証つきのページも実装可能です。ただし、会員機能・課金・ダッシュボードが中心のサービスであれば、Next.jsやSvelteKitのほうが実装例・情報量ともに豊富です。Astroの真価はコンテンツ主体サイトで出やすい点は押さえておいてください。
Q9. Astroの案件はどうやって探す？
主要フリーランスエージェントの公開案件検索で「Astro」を指定するのが基本ですが、件数は執筆時点で限られています。「Next.js／React案件のなかで、静的サイト部分の切り出し提案としてAstroを差し込む」ような文脈で機会を作るのが現実的なルートです。
Q10. Astroで作ったサイトの運用コストは？
小〜中規模の静的サイトであれば、Netlify・Vercel・Cloudflare Pagesなどの無料枠に収まるケースもあります。ただし、トラフィックの規模・ビルド実行回数・SSRの利用有無で料金条件は変わるため、選択したホスティングの料金ページを事前に確認してください。
