Astro 2025 - コンテンツファーストのWebフレームワークを選ぶ基準

Astroを選ぶ前に知ること

Astroは、記事・ドキュメント・採用サイト・サービス紹介のように、まず内容を読んでもらうWebサイトを作りやすいフレームワークです。ページの大部分はHTMLとして出力し、操作が必要な場所だけにJavaScriptを追加する設計を中心にしています。

ここでいう「JavaScriptを追加しない」は、サイトにJavaScriptを一切使えないという意味ではありません。検索候補、カート、コメント、グラフのように操作が必要な部品を、必要なタイミングで動かせます。重要なのは、ページ全体を一つの大きなクライアントアプリとして扱う前に、どの部分に操作性が必要かを選べることです。

この記事はAstro 5期の選定記事です。Astro 5で導入されたContent Layer APIと、Astro 5系で利用できるServer Islandsを中心に、採用判断に必要な範囲へ絞ります。初めてAstroでページを作る手順は、Astroを使ってみようを先に読むと理解しやすくなります。

Islands Architectureとは

Astroの基本は、ページをHTMLとして表示し、必要なUIコンポーネントだけを**アイランド（島）**として動かすことです。静的な見出し、本文、画像、リンクは通常のHTMLのままです。ボタンを押したときに状態が変わる部品だけが、ブラウザでJavaScriptを実行します。

ページ全体
├─ ヘッダー・本文・フッター       → HTMLとして表示
├─ 記事内の目次                   → HTMLとして表示
├─ いいねボタン                   → client directive付きのIsland
└─ 画像カルーセル                 → client directive付きのIsland

この分け方には二つの利点があります。一つは、読めばよい部分の初期表示に、不要なUIライブラリの実行を持ち込まないことです。もう一つは、画面を設計するときに「この機能は本当にブラウザで状態を持つ必要があるか」と考える習慣ができることです。

ただし、Islandsは自動的な高速化スイッチではありません。アイランド内で大きな依存関係を読み込む、初回表示直後に多数のアイランドを動かす、画像や外部スクリプトを無計画に追加すると、配信量は増えます。実際のページでJavaScript量、画像、外部通信を計測して判断します。

client directiveの最小例

ReactなどのUIコンポーネントをAstroページに置いただけでは、通常はブラウザ側で対話機能を動かしません。client:* directiveを付けたときに、その部品をクライアントアイランドとしてハイドレーションします。

---
import SearchBox from '../components/SearchBox.jsx';
import NewsletterForm from '../components/NewsletterForm.jsx';
---

<main>
  <h1>記事一覧</h1>
  <p>この説明文はHTMLとして配信されます。</p>

  <SearchBox client:load />
  <NewsletterForm client:visible />
</main>

client:loadは、表示直後から操作できる必要がある検索欄のような部品に向きます。client:visibleは、画面内に入ってから動かせばよい下部のフォームやコメント欄に向きます。どちらも「便利そうだから」ではなく、利用者がいつ操作するかで選びます。

client:only="react"は、サーバー側でレンダリングできないライブラリを使う場合の逃げ道です。しかし、最初のHTMLがないため、本文・見出し・主要CTAのようにすぐ見せたい内容へ安易に使いません。

Reactを部分利用するときの考え方

AstroはReact、Vue、Svelteなどのコンポーネントを統合できます。これは「一ページに複数フレームワークを混ぜるべき」という意味ではありません。多くのプロジェクトでは、既存資産またはチームの得意なフレームワークを一つ選び、必要なアイランドだけに使う方が保守しやすくなります。

Reactを部分利用するなら、次の境界を先に決めます。

• 記事レイアウト、カード、リンク、見出しはAstroコンポーネントで書けるか
• 状態を持つ検索、絞り込み、入力フォームだけをReactにできるか
• Reactアイランド間で共有状態が必要になっていないか
• 画面のほとんどがReactになった場合、Astroを入口にする利点が残るか

複数のアイランドは独立して動くため、親子のReactコンポーネントのように状態を自然に共有できるとは限りません。共有が必要なら、部品を一つのアイランドへまとめる、URLやサーバーを状態の受け渡し先にする、といった設計を検討します。状態管理の都合だけで、ページ全体をclient:loadにするのは避けます。

既存のReactアプリを段階的に移す場合も、まず静的なページや独立したウィジェットから試します。認証済み画面、複雑な共有状態、頻繁なリアルタイム更新まで一度に移すと、レンダリング方式よりアプリの状態設計が主な難所になります。

Content Layer APIでコンテンツを扱う

Astro 5では、Content Layer APIにより、コンテンツコレクションをloaderとschemaで定義できます。Markdownのようなローカルファイルだけでなく、構造が決まったデータを読み込み、スキーマで検査して利用するための仕組みです。

このリポジトリのようにMarkdown記事を多数持つサイトでは、タイトル、説明、日付、タグの形式を揃える助けになります。データが不正ならビルド時に早く気づけるため、表示ページで「日付がない」「tagsが文字列だった」といった例外を減らせます。

// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';

const articles = defineCollection({
  loader: glob({
    pattern: '**/*.{md,mdx}',
    base: './src/content/articles',
  }),
  schema: z.object({
    title: z.string(),
    description: z.string(),
    date: z.string(),
    tags: z.array(z.string()),
  }),
});

export const collections = { articles };

この例では、loaderが対象ファイルを集め、schemaがfrontmatterの形を検査します。プロジェクトの実際の型に合わせて、dateを文字列にするかDateへ変換するか、任意項目を何にするかを決めます。型を厳しくしすぎると既存コンテンツの移行負担が増えるため、必須項目は本当に表示・検索・並び替えで必要なものに絞ります。

外部データをつなぐ前の確認

Content Layerは外部CMSやAPIを読む設計にも使えますが、外部データを追加すれば必ず便利になるわけではありません。外部取得には、認証情報、失敗時の扱い、更新タイミング、ビルド時間、公開前プレビューの責任が伴います。

次の問いに答えられてから導入すると安全です。

1. 外部データが取得できないとき、前回の内容で公開するかビルドを止めるか
2. APIの値をどのschemaで検査し、不正値を誰が直すか
3. シークレットをクライアントへ送らず、ビルドまたはサーバー側だけで使えているか
4. 更新頻度に対して、静的再ビルドで十分か

単に記事を書くためなら、ローカルMarkdownとglob()のコレクションで十分なことが多いです。外部CMSは編集体験や複数編集者の要件が明確になってから追加します。

Server Islandsは静的ページの中の動的部分

Server Islandsは、静的に配信するページの中で、一部だけを遅れてサーバーレンダリングする機能です。例えば商品説明は共通の静的HTMLとして先に出し、ログイン中の利用者名や個別のお知らせだけを後から取得できます。

---
import AccountMenu from '../components/AccountMenu.astro';
---

<header>
  <a href="/">サイト名</a>

  <AccountMenu server:defer>
    <span slot="fallback">アカウントを読み込み中</span>
  </AccountMenu>
</header>

server:deferを付けると、最初のページにはfallbackが表示され、対象コンポーネントは別に取得・表示されます。ページ全体を待たせずに個別表示を遅らせられるため、個人向け部分を静的コンテンツから分離するのに役立ちます。

ただし、Server Islandsにはオンデマンドレンダリングを行うadapterが必要です。静的ホスティングだけの構成では、そのまま使えません。また、渡すpropsはネットワーク転送できる形でなければならず、関数や循環参照を含むオブジェクトは渡せません。

サーバーアイランドを使う前に、次を確認します。

• 遅れてもよいUIか。購入確定のような主要操作をfallbackのままにしない
• Cookieやセッションを読む処理で、キャッシュに個人情報を混ぜないか
• propsは最小限か。大きいオブジェクトを渡して通信を増やしていないか
• 失敗時に何を見せるか。空欄、再試行、ログイン導線を決めたか

個人化のためにページ全体をSSRへ変える前に、Server Islandsで必要な境界だけを動的にできないか考える価値があります。一方、画面の大部分が利用者ごとに変わり、データ整合性も強く求められるなら、通常のSSRやアプリケーション用フレームワークの方が分かりやすい場合があります。

View Transitionsは見た目だけではない

AstroのView Transitionsは、ページ遷移時の見た目とナビゲーションを選択できる機能です。通常のAstroサイトは、ブラウザによる通常のページ遷移です。クライアント側ルーティングや遷移効果は、必要なときだけ明示的に有効にします。

---
import { ClientRouter } from 'astro:transitions';
---

<head>
  <title>記事一覧</title>
  <ClientRouter />
</head>

<ClientRouter />は内部リンクの移動を扱い、View Transition APIの対応状況に応じたfallbackも提供します。transition:nameやtransition:persistを使えば、対応する見出し・画像を結び付けたり、音楽プレーヤーのような要素を遷移後も維持したりできます。

しかし、ClientRouterを入れると、従来の全ページ再読み込みを前提にしたスクリプトが毎回実行されない場合があります。ナビゲーション後にも初期化が必要な処理は、astro:page-loadなどのイベントで動かす設計を確認します。計測タグ、フォーム、モーダル、フォーカス管理を含めてテストしてから、サイト全体に広げます。

アクセシビリティも確認します。AstroのClientRouterには経路変更を知らせる仕組みやprefers-reduced-motionへの対応がありますが、各ページに適切な<title>と<h1>があり、キーボード操作とフォーカス移動が自然かを実機で確認する必要があります。アニメーションがあることより、遷移後に目的の内容へ到達できることが優先です。

Astroが向くサイト・向かないサイト

Astroは、次のようなサイトと相性がよいです。

• 記事、ドキュメント、採用、コーポレート、LPなど、読む部分が中心のサイト
• ページごとのレイアウトは安定し、操作が必要なのは一部の検索・フォーム・ウィジェットだけのサイト
• MarkdownやCMSのコンテンツを、型を揃えて公開したいサイト
• 既存のReactやVue部品を、必要な範囲だけ再利用したいサイト

一方で、次の状況では別の構成も比較します。

• 画面の大部分がログイン利用者ごとに変わり、常にサーバー状態を反映する
• 多数の部品が複雑なクライアント状態を共有し、ページ全体が一つのアプリとして動く
• オフライン同期、常時接続、共同編集など、クライアントアプリそのものが中心である
• チームがすでにReactやVueのアプリ基盤・運用・テストに大きく投資している

これはAstroが「使えない」という意味ではありません。必要なSSRやアイランドを組み合わせることはできます。ただし、フレームワークの得意な形と実際の画面構造が離れるほど、例外的な実装と運用判断が増えます。SSRが必要かを考えるも参照し、レンダリング方式を機能単位で決めてください。

選定前のチェックリスト

導入候補として比較するときは、次の順に確認します。

1. 主要ページで、HTMLだけで読める部分と操作が必要な部分を書き出す
2. 各アイランドに必要なclient:* directiveを理由とともに決める
3. 記事・商品・FAQなどのデータ形と、Content Layerのschemaを決める
4. 個人化が必要な箇所だけを特定し、Server IslandsまたはSSRの必要性を確認する
5. View Transitionsを有効にするなら、フォーム・計測・キーボード操作を遷移後もテストする
6. 実際のページをビルドし、JavaScript量、画像、外部通信、表示の安定性を計測する

評価はベンチマーク表の順位だけで決めません。同じAstroでも、アイランドの数、読み込むUIライブラリ、画像形式、ホスティング、利用者の端末で結果は変わります。自分の代表ページと実際のデータで測ることが、最も再現性の高い選定方法です。

まとめ

Astro 5期の重要な考え方は、静的HTMLを基本にしながら、必要な場所だけをクライアントアイランド・サーバーアイランドとして動かすことです。Content Layer APIはコンテンツの形を揃え、View Transitionsは必要なときにナビゲーション体験を拡張します。

まずは記事一覧や紹介ページのように境界が分かりやすい一画面で試し、どの部分に本当にJavaScriptや動的レンダリングが必要かを測ってください。その結果をもとに、Astroを中心にするか、別のアプリ基盤を選ぶか判断するのが安全です。

関連記事・参考リソース

• Astroを使ってみよう
• SSRが必要かを考える
• Astro 5.0の機能紹介
• Astro 公式ドキュメント
• Islands Architecture
• Content Collections
• Server Islands
• View Transitions

×

PR

×

PR