Astroフレームワークとは？特徴と使い方・Next.jsとの使い分けを解説【2026年版】

Astro（アストロ）は、ブログ・コーポレートサイト・ドキュメントのようなコンテンツ主体のWebサイトを高速に表示することへ振り切ったWebフレームワークです。既定ではJavaScriptをブラウザへほぼ送らず、動きが必要な部分だけを「アイランド」として個別に読み込みます。この記事では、Astroの特徴と仕組み、プロジェクト作成から公開までの使い方、2026年6月に公開されたAstro 7系の変更点、そしてNext.jsやWordPressとの使い分けまで、実装と技術選定に必要な範囲を一次情報ベースで解説します。掲載したコマンドと設定ファイルは、いずれもそのまま手元で動かせる形式です。

まとめ：Astroはコンテンツ主体サイトの高速表示に強い選択肢

Astroは「表示するHTMLをビルド時に作り切り、JavaScriptは必要な島にだけ渡す」設計のフレームワークで、記事型サイトの初期表示速度とSEO面の技術要件を素直に満たせます。React・Vue・Svelteのコンポーネントを同じプロジェクトに混在させられるため、既存のUI資産を持つチームでも導入の敷居は低めです。

2026年9月22日時点の安定版はnpmレジストリのlatestタグで7.3.3（2026年9月16日公開）。メジャー版のAstro 7.0は2026年6月22日公開で、ビルド時間が公式ベンチマークで15〜61%短縮され、バンドラはVite 8経由でRust製のRolldownに置き換わりました。逆に、ログイン後の画面が中心のWebアプリや、編集者が管理画面だけで完結したい運用にはNext.jsやWordPressのほうが向きます。本文では、この採用・見送りの線引きを条件付きで具体的に示します。

同じVite 8を土台にしながら用途が違う例として、Markdownからスライドを組み立てるSlidevがあります。静的ビルドとGitHub Pagesでの公開まで流れが似ているため、Slidevの実装ガイドと読み比べるとVite系の構成の共通点が見えます。

Astroフレームワークの定義とコンテンツ駆動サイトへの特化構造

AstroはオープンソースのWebフレームワークで、公式は自らを「コンテンツ駆動のWebサイトのためのフレームワーク」と定義しています。SPA（シングルページアプリケーション）を志向するNext.jsやNuxtと異なり、出力の中心はサーバーで生成した静的HTMLです。位置づけとしては静的サイトジェネレーター（SSG）の系譜に属しますが、部分的な動的UIを許容する点が従来型のSSGと違います。この章では、その速さを支える3つの設計を順に見ます。

アイランドアーキテクチャによる部分ハイドレーションの動作原理

アイランドアーキテクチャは、ページ全体を静的HTMLの「海」とみなし、カルーセルや検索フォームのような動的UIだけを「島（Island）」として切り出す設計です。島ごとにJavaScriptを分割して読み込むため、1つの重いコンポーネントがページ全体の操作可能になるまでの時間を道連れにしません。考え方そのものはAstro固有ではなく、アイランドアーキテクチャとPPRの違いで整理した通り他の実装系にも広がっています。

読み込みタイミングはclientディレクティブで島単位に制御します。公式のIslands解説が挙げるのはclient:load（即時）、client:idle（ブラウザの手が空いた時点）、client:visible（画面に入った時点）の3つ。ファーストビュー外のUIをclient:visibleに落とすだけで、初期転送量を目に見えて削れます。サーバー側の重い処理だけを切り離したい場合は、同じページ内でserver:deferを付けたサーバーアイランドという選択肢もあります。

デフォルトゼロJavaScriptが表示速度とSEO評価に与える効果

Astroは既定でクライアントサイドJavaScriptを出力しません。ReactやVueで書いたコンポーネントも、ディレクティブを付けなければビルド時にHTMLへ変換されて終わりです。フレームワークのランタイムを常に同梱するSPA構成と比べ、転送量とメインスレッドの処理時間を根本から抑えられます。

この性質はCore Web Vitals、特にLCP（最大コンテンツの描画）とINP（操作への応答性）の改善に直結します。実際に当サイトでは、AstroでPageSpeed Insightsスコア100点を達成する手順を画像・フォント設定込みで検証済みです。検索順位を直接押し上げる魔法ではないものの、速度要因の減点をなくす土台になります。

Content LayerとMarkdown対応で完結するコンテンツ管理の設計

記事やお知らせのような構造化コンテンツは、Content Layerで型付きコレクションとして扱います。MarkdownやMDX、外部CMSのAPIをローダー経由で同じ形に正規化し、フロントマターのスキーマ検証まで行う仕組みで、Astro 5.0（npmレジストリ上の公開は2024年12月3日）で導入されました。ローダーとスキーマの書き方はContent Collectionsの公式ガイドが一次情報で、設計面の解説はAstro v5のContent LayerとServer Islandsの検証記事で扱っています。

執筆者はMarkdownを書くだけ、開発者はスキーマと表示だけを管理する分業が成立するため、数百ページ規模のオウンドメディアでも破綻しにくい構成です。ヘッドレスCMS（microCMSやContentful等）と組み合わせる場合も、取得コードはローダーに集約されます。

同じMarkdown原稿を配布用のdocxやPDFへ回す工程が要るなら、Pandocでの変換手順と日本語出力の詰まり方で変換コマンドとテンプレートの当て方を扱っています。

Astroの使い方：プロジェクト作成から公開までの手順と開発の流れ

ここからは実装者向けに、ローカル環境の構築から本番公開までの流れを追います。Astro 7系が要求するNode.jsは、npmレジストリ上のenginesフィールドで22.12.0以上。この条件さえ満たしていれば、開始までに必要な操作は数分で終わる分量です。

create astro実行から開発サーバー起動までの初期セットアップ

プロジェクト作成は対話式CLIで行います。公式のインストール手順に沿うと、次の4コマンドで開発サーバーまで到達します。

npm create astro@latest my-site
cd my-site
npm install
npm run dev

対話では、テンプレートの選択とTypeScript設定の厳密さを聞かれます。srcの下のpagesディレクトリに置いたファイルがそのままURLになるファイルベースルーティングで、pagesの中のindex.astroがトップページに対応する構造です。ビルドはnpm run build、出力確認はnpm run previewと、コマンド体系は他のViteベースのツールと揃っています。

.astroコンポーネントの記法とReact等UI部品の組み込み手順

.astroファイルは、上部のコードフェンス（3連ハイフンで挟む領域）にサーバー側で走るJavaScriptやTypeScriptを書き、下部にHTMLライクなテンプレートを書く2層構造です。JSXと違いclass属性をそのまま書け、スタイルはstyleタグを置くだけでコンポーネント単位にスコープされます。Reactコンポーネントを島として差し込むと、次のような形になります。

---
import Carousel from '../components/Carousel.jsx';
import { getCollection } from 'astro:content';
const items = await getCollection('news');
---
<section>
  <h2>お知らせ</h2>
  <Carousel client:visible items={items} />
</section>

この例では、見出しとセクションは静的HTMLのまま出力され、Carouselだけが画面に入った時点でJavaScriptを読み込みます。React・Vue・Svelte等を使うにはnpx astro add reactのようにインテグレーションを追加する手順が必要です。どの範囲をReact島にするか、全面React化と何が違うかはAstroとReactの違いと使い分けの解説で比較しているので、React資産を持つチームはそちらが判断材料になります。

コンテンツコレクションをcontent.config.tsで型付けする記述

記事データはsrc直下のcontent.config.tsで定義します。globローダーでファイルを拾い、zodスキーマでフロントマターを検証する形が基本形です。7.1.0で追加されたdeferRenderをtrueにすると、Markdownのレンダリングをコンテンツ同期時ではなくページ描画時まで遅らせられます。

import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

export const collections = {
  news: defineCollection({
    loader: glob({
      pattern: '**/*.md',
      base: 'src/content/news',
      deferRender: true,
    }),
    schema: z.object({
      title: z.string(),
      pubDate: z.date(),
      draft: z.boolean().default(false),
    }),
  }),
};

既定値はfalseで、従来どおり同期時に全件を描画してキャッシュします。数千件規模のコレクションでrehype-katexのような重いプラグインを通していると、この先読みでビルドがメモリ不足に落ちることがあり、その回避策として追加されたオプションです。件数が数百に収まるコーポレートサイトなら、既定のままで困りません。

静的ビルドとSSRの切り替え・ホスティング先を決める判断基準

出力モードはページ単位で静的（プリレンダリング）とSSR（リクエスト時レンダリング）を混在できます。既定は静的生成で、会員向けページや在庫表示のような鮮度必須の箇所だけ公式がアダプターを提供するNetlify・Vercel・Cloudflare・Node.jsのいずれかを入れてSSR化する構成が、実務では扱いやすい形です。

全ページ静的で済むサイトなら、ビルド成果物は素のHTMLと少量のアセットなので、静的ホスティングへそのまま配置できます。サーバー実行環境の運用が要らない分、保守費は月額のホスティング費だけに収束し、WAFやCDNの構成も単純化されます。SSRを混ぜた時点でアダプター対象プラットフォームの制約を受けるため、ホスティング先はSSR要否を決めてから選ぶ順番が安全です。

Astro 7系の新機能と旧バージョンからの移行を判断する材料

Astroはメジャーバージョンの更新が速く、5.0が2024年12月3日、6.0が2026年3月10日、7.0が2026年6月22日の公開です。この章は導入済みチームの移行判断と、これから始める人のバージョン選定のために、7系の変更点を一次情報から整理します。

Astro 7.0のビルド時間短縮とVite 8・Rolldown移行の刷新内容

公式リリースノートが示す7.0の柱はビルド性能です。.astroコンパイラがGo実装からRust実装へ置き換わり、この入れ替え単体で約6%の改善。加えてMarkdown処理系がunified（remark・rehype系）からRust製のSätteriへ移りました。公開されたベンチマークは次の通りで、全体では15〜61%の短縮です。

バンドラはVite 8への更新に伴い、esbuildとRollupを1つに統合したRust製のRolldownへ置き換わりました。土台側の変更点はVite 8の変更点をまとめた記事と重なるため、Viteの設定ファイルを触っているプロジェクトは先にそちらを確認してください。機能面では、6.0で実験扱いだったQueued Renderingが標準の描画エンジンになり、従来の再帰方式比で約2.4倍。src直下のfetch.tsによるリクエストパイプライン制御と、Netlify・Vercel・Cloudflare向けRoute Cachingの標準APIも入っています。

7.1から7.3で入ったプレビュー機能とローダーの追加オプション

7系のマイナー更新は、開発コマンドまわりの手入れが中心です。7.1.0（2026年7月16日）がglobローダーのdeferRender、7.2.0（2026年8月6日）がastro preview --backgroundと付随サブコマンド、7.3.0（2026年9月3日）がastro preview --ignore-lockという並びになります。

• 背景実行したプレビューはastro preview status・astro preview logs・astro preview stopで操作する
• AIコーディングエージェントからの実行を検出すると背景モードが自動で有効になり、ASTRO_PREVIEW_BACKGROUND=0で抑止できる
• --ignore-lockはポート違いのプレビューサーバーを同時に立てるためのもので、Playwright等のE2Eを並列実行する用途を想定している

CI上でE2Eを回しているプロジェクトは、この2つでジョブの組み方が変わります。逆に、静的書き出ししかしないコーポレートサイトの保守案件なら、7.1から7.3のあいだに急いで上げる理由は薄めです。5系の新機能から追いたい場合はAstro v5.16の新機能まとめが前提整理に使えます。

v5・v6から7系へ移行するときの破壊的変更と互換性の確認手順

公式のv7アップグレードガイドが挙げる破壊的変更のうち、既存サイトで実害が出やすいのは次の4点です。

• Rustコンパイラの標準化でHTMLの自動補正が廃止され、閉じ忘れタグがビルドエラーになる
• compressHTMLの既定値がtrueから’jsx’へ変わり、インライン要素間のスペースが畳まれる
• Markdownの既定パイプラインがSätteriになり、remark・rehypeプラグインはSätteri向けへの移植が要る
• @astrojs/dbが削除され、Node.js組み込みのSQLiteやDrizzle ORM等への置き換えが要る

加えてsrc直下のfetch.tsが予約ファイル名になったため、同名のファイルを置いているプロジェクトはfetchFile設定で別名を指すか、ファイル名を変えます。移行作業そのものは公式のアップグレードコマンドで足りますが、その後の確認まで含めて3手です。

npx @astrojs/upgrade
npx astro check
npm run build

ステージング環境で依存を上げてビルドエラーを潰し、主要ページの表示差分をスクリーンショット比較で確認する流れが堅実でしょう。特にcompressHTMLの既定値変更は、文中リンクの前後など見た目が静かに変わる種類の差分なので、ビルドが通ったことだけで判断すると取りこぼします。マイナー更新は7.1から7.3までおよそ月1本のペースで続いているため、追従は四半期単位でまとめて行うと運用負荷を抑えられます。

Next.js等との使い分けと受託制作でAstroを採用する判断基準

技術選定で迷うのは「Astroでも作れるが、他でも作れる」案件です。この章では代表的な選択肢との守備範囲の違いを整理したうえで、受託制作の現場でAstroを推す条件と見送る条件を言い切ります。

Next.js・WordPressとの比較で見る守備範囲と選定の目安

3者は競合というより得意分野が異なります。判断軸は「動的機能の比重」と「更新を誰が行うか」の2つ。Next.jsの16系App Routerで最小アプリを動かす手順と読み比べると、同じ画面を作るのに必要な前提の差が分かります。

ダッシュボードや会員機能のように画面の大半が動的ならNext.js、編集部が管理画面で完結したいならWordPressかヘッドレスCMS併用のAstro、表示速度と保守の軽さを最優先するコンテンツサイトならAstroが目安になります。

Astroの採用を推す案件条件と見送るべき場面の具体的な線引き

採用を推すのは、ページ数の大半が記事・製品紹介・会社情報で占められ、動的UIが検索窓や問い合わせフォーム程度に収まる案件です。コーポレートサイト、オウンドメディア、ドキュメントサイト、LP群がこの典型で、表示速度の要件が厳しいほどAstroの構造が効きます。既存のReactコンポーネント資産を島として持ち込める点も、リニューアル案件では効率面の追い風になるでしょう。

逆に、ログイン後の画面が主体のSaaS管理画面、リアルタイム更新が多い在庫・予約システム、ページ遷移なしの操作感が要件のツール型UIでは採用を見送るべきです。島が増えすぎるとゼロJSの利点が薄れ、状態共有の設計コストだけが残ります。加えて、更新担当者が非エンジニアのみでビルドの仕組みを持てない体制なら、ヘッドレスCMSを併設しない限りAstro単体は過剰。この線を越える案件は素直にNext.jsか既存CMSを選ぶほうが総コストは下がります。

Astroでの制作を外注するときに伝える要件と体制面の確認事項

外注時は、実装可否よりも運用設計の合意が失敗を分けます。最低限、公開後に誰がどの頻度で更新するか、更新はMarkdownかCMS管理画面か、SSRを要するページが存在するか、計測目標（PageSpeed InsightsやCore Web Vitalsの水準）をどこに置くかの4点を要件に明記すると、フレームワーク選定の妥当性を発注側でも検証できます。

制作会社側の確認事項としては、メジャー更新への追従を保守契約に含むか、ヘッドレスCMS併設時の月額費用、公開基盤の運用責任範囲が挙げられます。7.0のようにコンパイラごと入れ替わる更新では、テンプレートの書き方まで直す作業が発生するため、ここを曖昧にしたままの契約は次の更新で揉める原因です。当社ではAstroを含む静的構成・CMS構成の両方に対応した企業サイト制作・コーポレートサイト制作を提供しており、表示速度要件と更新体制から構成を逆算する進め方を取っています。要件が固まりきる前の技術選定段階からの相談にも対応可能です。

よくある質問

Astroの導入検討で実際に検索されている疑問を5つ取り上げ、本文の要点を補足します。

AstroとReactはどちらを選べばよいですか？

比較の軸が異なります。Reactは画面を作るUIライブラリ、Astroはサイト全体を組み立てるフレームワークで、AstroのなかでReactコンポーネントを島として使う併用が成立します。コンテンツ中心のサイトならAstroを土台にし、動的な部分だけReactを持ち込む構成が転送量の面で有利です。画面の大半が動的操作ならNext.js等のReactフレームワークを選びます。

Astroはどの言語で書きますか？

テンプレートは独自の.astro形式で、HTMLの上位互換に近い記法です。ロジック部分はJavaScriptとTypeScriptの両方に対応し、型チェックはnpx astro checkで実行します。加えてMarkdown・MDXをページとしてそのまま扱えるため、記事の執筆自体にプログラミング言語の知識は不要です。

Astroが向かないのはどんなサイトですか？

ログイン後の操作画面が主体のWebアプリ、リアルタイム性が要件のダッシュボード、ネイティブアプリ的な操作感を求めるツール型UIには向きません。動的な島が画面の大半を占めると、ゼロJavaScriptという前提の利点が消えるためです。この場合はNext.jsやReact Routerのようなアプリ志向のフレームワークが適します。

Astroの最新バージョンはいくつですか？

2026年9月22日にnpmレジストリで確認した時点のlatestは7.3.3で、公開日は2026年9月16日です。メジャー版のAstro 7.0は2026年6月22日に公開され、ビルド時間の15〜61%短縮とVite 8・Rolldownへの移行が柱でした。メジャー更新はおおむね年1回のペースなので、導入時は最新メジャーの安定版を選び、保守計画に年次の追従作業を組み込むのが実務的です。

既存のWordPressサイトからAstroへ移行できますか？

可能です。WordPressをヘッドレスCMSとして残し、REST APIやGraphQL経由で記事を取得してAstro側で表示する構成が代表的でしょう。管理画面での執筆体験を維持したまま、公開側の表示速度とセキュリティ面（PHP実行環境の露出削減）を改善できます。移行時はURL構造の維持と301リダイレクトの設計を先に固める必要があります。

関連記事

• AstroとReactの違いと使い分け｜AstroでReactを使う方法：本記事の「使い方」で触れたUIフレームワーク統合を、React併用の観点から掘り下げた比較記事
• Astroの画像処理とパフォーマンス改善：ゼロJavaScript設計を実際のスコア改善につなげる実装手順
• Astro 5の新機能と移行手順｜Content Layer・Server Islands：本文で扱ったContent Layerの導入背景と設計の詳細
• Astro v5.16の新機能を徹底解説：7系移行の前提となるv5後期の変更点まとめ
• ヘッドレスCMSとは？従来型CMSとの違いと選び方：Astroと組み合わせる編集基盤を選ぶときの比較軸