AstroとReactの違いと使い分け|AstroでReactを使う方法【2026年版】
AstroとReactは「どちらか一方を選ぶもの」と説明されがちですが、Astroは公式にReact統合を提供しており、両方を組み合わせる前提で設計されています。Astroはページ全体を静的HTMLとして配信し、インタラクティブが必要な部分にだけReactコンポーネントを「島(アイランド)」として置きます。この記事では、2026年7月時点の仕様をもとに、AstroとReactの違い、どちらを主役にすべきかの判断基準、そして@astrojs/reactでReactコンポーネントを動かす具体的な手順までをまとめます。Astro自体の特徴やセットアップ手順の全体像はAstroフレームワークとは?特徴と使い方の解説で扱っています。
まとめ:AstroとReactの違いと選び方の結論
- 違いの核心はJavaScriptの配り方。ReactはUI全体をクライアントのJavaScriptで組み立て、Astroはビルド時にHTMLを出し、指定した箇所だけをJavaScriptで動かす(アイランドアーキテクチャ)。
- 対立関係ではない。Astroは
@astrojs/react統合でReactコンポーネントをそのまま描画・ハイドレートできる。npx astro add reactの1コマンドで導入が完了する。 - 選び分けの基準は「画面遷移後も状態を持ち続けるか」。持ち続ける(管理画面・エディタ・チャット)ならReact主体のSPA/Next.js、ページ単位で完結する(記事・LP・ドキュメント・EC商品ページ)ならAstro主体。
- Astro内でReactを使うときに詰まりやすいのは状態共有。島どうしはコンポーネントツリーが分断されるため、React ContextやuseStateを島をまたいで共有できない。公式は専用レシピを設け、Nano Storesを推奨している。
- 2026年の状況:Astro 6.0が2026年3月10日に安定版としてリリース(Node 22以上が必須)。開発元のThe Astro Technology Companyは2026年1月16日にCloudflareへの参画(Cloudflareのプレスリリース上は買収)が発表されたが、AstroはMITライセンスのオープンソースとして継続する方針が示されている。
AstroとReactの違い:レンダリングモデルと役割分担
ReactはUIライブラリで、Astroはサイトを組み立てるWebフレームワークです。同じレイヤーの製品ではないため、「速さ」ではなくJavaScriptをいつ・どれだけブラウザに送るかで比較すると違いが正確につかめます。
レンダリングの仕組みと出力されるJavaScript量
Reactで作った一般的なSPAは、初回アクセス時にアプリ本体のJavaScriptバンドルを読み込み、ブラウザ上でDOMを構築します。Next.jsのようなフレームワークを使えばサーバー側で先にHTMLを描画できますが、その後にクライアントでハイドレーションを行う点は変わりません。
Astroはビルド時(またはリクエスト時)にHTMLを生成し、クライアントJavaScriptをデフォルトでゼロにします。React・Vue・Svelteなどのコンポーネントを置いても、client:*ディレクティブを付けない限り静的HTMLとして出力されるだけで、そのコンポーネントのJavaScriptは配信されません。動かす必要がある部分にだけJavaScriptを送る、というのがアイランドアーキテクチャの実装です。
| 観点 | Astro | React(SPA/Next.js) |
|---|---|---|
| レイヤー | Webフレームワーク | UIライブラリ(+Next.js等のFW) |
| 既定のクライアントJS | 0KB | ランタイム+アプリバンドル |
| UIの更新単位 | ページ/島(island) | アプリ全体のコンポーネントツリー |
| ルーティング | ファイルベース(サーバー側) | クライアントルータ(React Router等) |
| 他FWの混在 | React/Vue/Svelte等を同一プロジェクトで併用可 | 基本はReactに統一 |
| 得意領域 | 記事・LP・ドキュメント・EC商品ページ | 管理画面・SaaS・エディタ・チャット |
どちらを主役にするかの判断基準
判断は「ページをまたいでクライアント状態を保持し続ける必要があるか」の一点で決めて構いません。フィルタ条件・編集中の下書き・WebSocket接続などをページ遷移後も維持する画面は、サーバー側でHTMLを組み直すAstroの前提と噛み合いません。この場合はReact主体(Next.jsを含む)を選びます。逆に、各ページが独立していて訪問者の大半が数ページで離脱するコンテンツ型サイトでは、Reactのランタイムを全ページに配る合理性が薄く、Astroが有利です。
なお両者は排他ではありません。マーケティングサイトをAstro、ログイン後のアプリをReactで別配信し、ドメイン配下でパスを分ける構成も取れます。Reactの開発環境そのものについてはViteを使ったReactプロジェクトのセットアップ方法を徹底解説、Reactベースのフルスタック構成を検討する場合はNext.js 16とは?ReactベースのWeb開発フレームワーク最新版の概要や主要機能を詳しく紹介が参考になります。
AstroでReactコンポーネントを動かす手順
「astro react」で検索する人の多くが求めているのは比較ではなく、AstroプロジェクトでReactを動かす方法です。公式統合@astrojs/reactを入れれば、既存の.jsx/.tsxコンポーネントをほぼそのまま使えます。
@astrojs/reactの導入とtsconfigの設定
統合の追加はCLIコマンド1本で完了します。依存パッケージのインストール、astro.config.mjsへの追記、TypeScript利用時のtsconfig.jsonのJSX設定まで自動で行われます。
npx astro add react
手動でインストールする場合は、次の2ファイルを自分で書き換えます。
// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
export default defineConfig({
integrations: [react()],
});
Astro既定のastro/tsconfigs/baseはjsxがpreserveでjsxImportSourceを持たないため、手動導入では次の指定を入れないと型エラーになります。
{
"extends": "astro/tsconfigs/strict",
"compilerOptions": {
"jsx": "react-jsx",
"jsxImportSource": "react"
}
}
統合のオプションは、include/exclude(ReactとPreactなど複数のJSXフレームワークを併用する際に、どのファイルをどちらで処理するかをパスで振り分ける)、babel(Vite Reactプラグインへ渡すBabelの設定)、experimentalReactChildren(子要素をReactの仮想DOMノードとして渡し一部ライブラリの互換性を確保する。ランタイムコストが増える)、experimentalDisableStreaming(CSS-in-JS系ライブラリ利用時にストリーミングを止める)です。名前のとおりexperimentalの2つは現行版でも実験扱いのままなので、常用は避けてください。型定義の基礎はTypeScriptの基本的な型と型推論、型注釈についてで確認できます。
client:*ディレクティブによるハイドレーションタイミングの制御
Astroに置いたReactコンポーネントは、client:*ディレクティブを付けて初めてブラウザで動きます。どれを選ぶかがそのままページの初期表示コストに直結します。
| ディレクティブ | ハイドレートするタイミング | 向く用途 |
|---|---|---|
client:load |
ページ読み込みと同時 | ファーストビューの操作要素 |
client:idle |
ブラウザがアイドル状態になったとき | 優先度の低いUI |
client:visible |
画面内に入ったとき(IntersectionObserver) | ページ下部の重いUI |
client:media |
メディアクエリが一致したとき | モバイル限定のメニュー等 |
client:only |
サーバー描画を行わずブラウザのみ | windowに依存する処理 |
---
import Counter from '../components/Counter.jsx';
---
<Counter client:load />
<Counter client:idle={{timeout: 500}} />
<Counter client:visible={{rootMargin: "200px"}} />
<Counter client:media="(max-width: 50em)" />
<Counter client:only="react" />
client:idleのtimeoutはミリ秒で、読み込みが終わらなくてもその時間までにハイドレートを強制します。client:visibleのrootMarginは要素の手前で先読みを始める余白で、200pxのように指定するとスクロールが到達する前にJavaScriptを読み込み始め、操作可能になるまでの待ちが減ります。client:onlyはサーバー側でHTMLを出さないため、フレームワーク名("react")の明示が必須です。
サーバー側で遅延描画したい部分にはserver:defer(Server Islands)があります。Astro 4.12で実験機能として導入され、5.0で安定化した仕組みで、ログイン名やカート個数のようなパーソナライズ要素をページ本体のキャッシュから切り離せます。詳細はAstro v5のハイライト: Content LayerやServer Islandsなど主要新機能の紹介で解説しています。
島をまたぐ状態共有とReact Contextの限界
client:loadを付けたコンポーネントは、それぞれ独立したReactツリーとしてマウントされます。ヘッダーのカートボタンと商品一覧の追加ボタンを別々の島にすると、両者の間には共通の親が存在せず、React Contextのプロバイダーで包むことができません。Astro公式ドキュメントが「島の間で状態を共有する」専用レシピを設けているほど、ここは詰まりやすい箇所です。公式はその解決策としてNano Storesを挙げています。
npm install nanostores @nanostores/react
// src/stores/cart.js
import { atom } from 'nanostores';
export const cartCount = atom(0);
// src/components/CartButton.jsx
import { useStore } from '@nanostores/react';
import { cartCount } from '../stores/cart.js';
export default function CartButton() {
const count = useStore(cartCount);
return <button onClick={() => cartCount.set(cartCount.get() + 1)}>カート: {count}</button>;
}
Nano Storesはatom単体で340バイト(minify+brotli)・依存ゼロで、React以外の島(VueやSvelte)とも同じストアを共有できます。どうしてもContextを使いたい場合は、状態を共有すべき範囲をひとつのReactコンポーネント内にまとめ、その1コンポーネントだけを島にする(プロバイダーごと島の内側に閉じ込める)設計に変えてください。ページ全体をReactで包む必要が出てきた時点で、それはAstroではなくReact主体で作るべきサインです。
Astroとは:.astro構文と併用できるUIフレームワーク
Astroはプログラミング言語ではなく、Webフレームワークです(「astro 言語」で検索されることが多いものの、独自言語を新たに覚える必要はありません)。テンプレートは.astroファイルで、上部の---で囲んだフロントマターにサーバーで動くJavaScript/TypeScriptを書き、下にHTMLを書きます。JSXに似ていますが、そのままclass属性を書け、<style>タグはデフォルトでそのコンポーネントにスコープされます。
---
const posts = await fetch('https://example.com/api/posts').then((r) => r.json());
---
<ul>
{posts.map((post) => <li>{post.title}</li>)}
</ul>
<style>
li { line-height: 1.8; }
</style>
フロントマターのコードはビルド時(SSRならリクエスト時)にサーバーで実行され、ブラウザには送られません。UIコンポーネントとしてはReactのほか、Vue、Svelte、Solid、Preact、AlpineなどをそれぞれAstro公式の統合パッケージ経由で追加でき、同一プロジェクト内での併用も可能です。ReactとVueの選定で迷っている場合はReactとVue3の違いを比較|どっちを選ぶべきか初心者向けに解説が判断材料になります。Markdown/MDXは追加設定なしでページとして扱え、コンテンツ主体のサイトではこれが実質の主戦力になります。
Cloudflare傘下入りとAstro 6:2026年時点の最新動向
2026年に入ってAstroには2つの大きな変化がありました。ひとつは組織面です。2026年1月16日、CloudflareはAstroを開発するThe Astro Technology Companyの参画を発表しました(Cloudflareのプレスリリースの表題は「Cloudflare Acquires Astro」で、買収と明示されています)。開発チームの全従業員がCloudflareの従業員となり、AstroはMITライセンスのオープンソースを維持し、オープンガバナンスと公開ロードマップのもとで開発を続ける方針が示されています。Cloudflare以外のプラットフォームやクラウドへデプロイできる点も変わらないと明言されており、現時点でロックインを示す発表はありません。
もうひとつはメジャーバージョンです。Astro 6.0が2026年3月10日に安定版としてリリースされました。主な内容は次のとおりです。
- Node 22以上が必須。Node 18/20のサポートは終了したため、既存プロジェクトのアップグレード時はまずランタイムを確認する。
- Fonts API:Webフォントのセルフホストと最適化を設定ベースで行える。6.0で新規に入った機能。
- Live Content Collections:5.x系の実験機能が6.0で安定化。サイト全体を再ビルドせずにリクエスト時点のコンテンツを取得できる。
- CSP対応:5.9で実験導入され6.0で安定化。スクリプトやスタイルのハッシュを自動生成する。Astroへの要望投票で最多だった機能。
- 開発サーバーがViteのEnvironment APIベースに再設計され、Vite 7・Shiki 4・Zod 4へ更新。
astro:contentからのZodインポートはastro/zodへ変更が必要。
2026年5月28日の6.4ではmarkdown.processorが差し替え可能になり、Rust製のSätteriを選べるようになりました。ただしSätteriは別パッケージのオプトインで既定ではなく、remark/rehypeプラグインが動きません。既定のMarkdown処理は引き続きunifiedです。バージョンごとの差分はAstro v5.16の新機能を徹底解説:SVG最適化やCLIショートカットなど最新アップデートの全概要!も参照し、導入時点の最新版は公式リリースノートで確認してください。
Astroを選ぶべきでない場面と、移行が失敗するパターン
Astroは万能ではありません。次のいずれかに当てはまるなら、Astroへの移行は見送るべきです。
- ページ遷移をまたいでクライアント状態を保持する画面が中心:SaaSの管理画面、エディタ、チャット、リアルタイムダッシュボード。Astroはページごとにサーバー側でHTMLを組み直すため、SPA前提の状態管理と設計が衝突します。
- React Routerによるクライアントルーティングに依存している:Astroのルーティングは
src/pages/配下のファイルベースで、サーバー側で解決されます。React Routerを動かすにはclient:onlyの島の内側に閉じ込めるしかなく、その時点でAstroの利点(JavaScriptを配らない)が消えます。 - ページの主要部分が軒並みインタラクティブ:島が増えるほどハイドレーション対象と各島のランタイムが積み上がり、最終的にアプリ全体分のJavaScriptを配ることになります。主要な要素がどれも
client:*を必要とする状態なら、設計そのものを疑ってください。
「Astroは人気がないのか」という疑問を持つ人がいますが、実態は用途が分かれているだけです。コンテンツ主体のサイトではAstro、業務アプリ領域ではReact/Next.jsが選ばれており、両者は同じ土俵で競合していません。移行判断で見るべきは知名度ではなく、上記3条件に自社の画面が当てはまるかどうかです。なお、Astroに移行してもチューニングを怠れば表示速度は上がりません。実測での改善手順はAstroを使った最適化でPageSpeed Insightsスコア100点を達成する方法にまとめています。
よくある質問
AstroとReactはどちらが速いですか?
同じ画面を作る前提なら、クライアントに配るJavaScriptが少ないAstroのほうが初期表示は速くなります。ただしAstroでも島を増やしてclient:loadを多用すれば、送られるJavaScript量はReactアプリに近づきます。「Astroだから速い」のではなく、ハイドレートする範囲を絞った結果として速くなる、という因果関係です。
AstroでReactを使う場合、React 19は使えますか?
使えます。@astrojs/reactのv4系はReact 19と18に対応しており、島の内側では通常のReactとして動作します。ただしサーバーコンポーネントのようにフレームワーク側のルーティングと密結合した機能は、Astroのページ構造とは前提が異なります。
Astroで使えるプログラミング言語は何ですか?
.astroファイルのフロントマターで書くのはJavaScriptとTypeScriptです。UI部分はReact・Vue・Svelte・Solid・Preactなどのコンポーネントを統合経由で使え、コンテンツはMarkdownとMDXを追加設定なしで扱えます。PHPやPythonのようなサーバー言語をAstro内部で実行することはできません。
Astroに既存のReactコンポーネントをそのまま移植できますか?
UIの描画とローカルなuseStateで完結するコンポーネントは、ファイルをコピーしてclient:*を付けるだけで動きます。移植で問題になるのは、React Contextで上位から値を受け取っているコンポーネント、React RouterのuseNavigate等に依存するコンポーネント、グローバルストアを前提にしたコンポーネントです。これらは島の外に依存があるため、Nano Storesへの置き換えか、島の切り方の見直しが必要になります。
Astroは商用サイトで使えますか?
AstroはMITライセンスのオープンソースで、商用利用に追加費用はかかりません。2026年1月にCloudflareが開発会社を買収しましたが、MITライセンスのまま継続する方針が公表されています。ライセンス条件は導入時点で公式リポジトリを確認してください。より詳しくは、React Flowの記事で整理しています。