Astro 6とは
記事情報: 2026年4月19日初出。本文の仕様は2026年7月25日に公式資料で再確認しています。
Astro 6は、コンテンツ中心のWebサイトを作るフレームワーク「Astro」のメジャーアップデートです。安定版は2026年3月10日に公開されました。
今回の中心は、派手な速度比較ではありません。開発時と本番時の実行環境を近づける開発サーバーの刷新と、外部CMSなどのデータをリクエスト時に取得できるLive Content Collectionsです。加えて、Content Security Policy（CSP）やWebフォントを扱うAPIが組み込まれました。
この記事では、公式発表で確認できる公開済み機能に絞って、Astro 5から何が変わったのかを整理します。
主な変更点
| 項目 | Astro 6での変更 |
|---|---|
| 開発サーバー | ViteのEnvironment APIを利用する構成へ刷新 |
| Content Layer | Live Content Collectionsが安定版に |
| セキュリティ | 組み込みのCSP APIが安定版に |
| フォント | Fonts APIを追加 |
| 主要依存関係 | Vite 7、Shiki 4、Zod 4へ更新 |
| 実行要件 | Node.js 22以降が必要 |
| 実験機能 | Rust compiler、Queued Rendering、Route Caching |
実験機能は、安定機能と同じ前提で本番採用しないことが重要です。設定名や挙動が変更される可能性があるため、検証環境で試してください。
開発サーバーが刷新された理由
従来のastro devはNode.jsを前提に設計されていました。そのため、Cloudflare WorkersなどNode.js以外の環境へデプロイすると、開発環境では動くのに本番環境では動かない差が生じることがありました。
Astro 6はViteのEnvironment APIを利用し、対象ランタイムに近い環境で開発サーバーを動かせる設計になりました。公式発表では、特にCloudflare Workersとの連携強化が紹介されています。
ここで期待できるのは「必ず高速になる」ことではなく、開発時と本番時の差を減らしやすくなることです。実際の応答速度は、アダプター、デプロイ先、キャッシュ、外部APIなどにも左右されます。
Live Content Collections
AstroのContent Collectionsは、MarkdownやMDXなどのコンテンツを型付きで扱う仕組みです。従来のbuild-time collectionは、ビルド時にデータを読み込みます。コンテンツを更新すると、基本的には再ビルドが必要です。
Astro 6で安定版になったLive Content Collectionsは、リクエスト時に外部データへアクセスする用途を扱います。更新頻度の高いCMS、商品情報、イベント情報などを、AstroのContent Layerを通して取得できます。
使い分けは次のように考えられます。
| コンテンツ | 向いている方式 |
|---|---|
| 更新時に再ビルドできる記事 | build-time collection |
| リクエスト時に最新情報が必要 | live collection |
| ページ内の一部だけ動的 | Server Islandsも候補 |
Live Content Collectionsを使うにはオンデマンドレンダリングが必要です。すべてを静的HTMLとして出力するサイトでは、従来のbuild-time collectionが単純です。
組み込みCSP API
CSPは、ページで読み込めるスクリプトやスタイルなどを制限するブラウザ向けセキュリティ機能です。クロスサイトスクリプティングの被害を抑える助けになりますが、インラインスクリプトや動的レスポンスを含むサイトでは設定が複雑になります。
Astro 6ではCSP APIが安定版になり、静的ページと動的ページの両方で設定できるようになりました。
import { defineConfig } from "astro/config";
export default defineConfig({
security: {
csp: true,
},
});
外部ドメインの画像、解析ツール、広告、埋め込みコンテンツを使うサイトでは、必要なCSPディレクティブを追加します。設定後はブラウザのConsoleとレスポンスヘッダーを確認し、必要なリソースまで遮断していないかテストしてください。
Fonts API
Fonts APIは、フォントファイルの取得、フォールバックフォントの生成、preload用ヒントなどをAstro側で扱う仕組みです。最初にastro.config.mjsでfont familyとproviderを登録します。Fontsourceを使う最小例です。
import { defineConfig, fontProviders } from "astro/config";
export default defineConfig({
fonts: [
{
provider: fontProviders.fontsource(),
name: "Roboto",
cssVariable: "--font-roboto",
},
],
});
登録したCSS変数を指定して、レイアウトの<head>で<Font />を読み込みます。
---
import { Font } from "astro:assets";
---
<Font cssVariable="--font-roboto" preload />
<style is:global>
body {
font-family: var(--font-roboto);
}
</style>
フォントの配信元やライセンス、対応するprovider設定は公式ガイドで確認してください。フォントを追加しただけで表示速度が保証されるわけではないため、実際のページで読み込み量とレイアウトシフトを測定します。
Astro 5から移行するときの注意
Astro 6には破壊的変更があります。特に次を確認してください。
- Node.js 22以降へ更新する
- 独自にViteを固定している場合はVite 7以降へ更新する
- スキーマではZodを
astro/zodから読み込む - 廃止された
Astro.glob()や旧Content Collectionsを移行する <ViewTransitions />を使っている場合は新しいルーター構成を確認する- Cloudflare adapterのruntime API変更を確認する
公式のアップグレードCLIを使う場合も、先にGitで変更を保存してから実行します。
npx @astrojs/upgrade
アップグレード後は、開発サーバーだけでなく本番ビルドとデプロイ先でも確認してください。
npm run build
npm run preview
どのサイトで導入を検討するか
Astro 6は、既にAstroを使っているサイト、外部CMSをContent Layerで扱いたいサイト、Cloudflare Workersなど本番ランタイムとの差を小さくしたいサイトで検討できます。
一方、現在のAstro 5サイトが安定しており、新機能を必要としていない場合は、依存パッケージやアダプターの対応を確認してから移行しても遅くありません。メジャーアップデートでは、機能の多さよりも利用中のintegrationが対応しているかが重要です。
移行後の確認項目
ローカルでページが表示できただけでは、移行完了とはいえません。最低限、次を確認します。
- Markdown・MDX・Content Collectionsの全ページを生成できる
- 動的routeと404ページが意図したレスポンスを返す
- 画像最適化とフォントのURLが本番環境でも解決できる
- CSPを有効にした場合、必要なscript・style・imageを遮断していない
- 使用中のadapterでSSRとAPI routeが動く
- sitemap、RSS、OGPなどのintegrationが対応している
- CIでNode.js 22以降を使っている
特に静的出力からオンデマンドレンダリングを含む構成へ変える場合は、キャッシュ、障害時の応答、外部CMSの停止も考慮します。Live Content Collectionsを採用するページと、ビルド時に確定させるページを分けると、外部サービスへの依存範囲を小さくできます。
また、実験機能を有効にした状態で問題が起きたときは、まず実験機能を無効にして再現するか確認します。安定機能の不具合と実験機能の制約を切り分けやすくなります。
まとめ
Astro 6の要点は次の3つです。
- 開発サーバーを刷新し、本番ランタイムとの差を減らしやすくした
- Live Content Collections、CSP、Fonts APIが安定した機能として追加された
- Node.js 22、Vite 7、Zod 4など移行時に確認すべき変更がある
性能はサイト構成によって変わります。根拠のない比較値で判断せず、公式の移行ガイドを読み、自分のサイトでビルド・表示・デプロイを検証してください。
