Astro 6 + Cloudflare Workersを完全理解する

2026年1月、CloudflareがAstroの開発チームを買収した。そして同年3月10日、Astro 6.0が正式リリースされた。現在の最新版は4月30日にリリースされたばかりの6.2だ。

このAstro 6は、単なるバージョンアップではない。開発サーバーのアーキテクチャが根本から作り直され、Cloudflare WorkersとAstroの統合が「本物」になった。これまで開発環境でシミュレートされていたものが、ようやく本番と同じ動作をするようになった——それがAstro 6の核心だ。

この記事では、Astro 6とCloudflare Workersを組み合わせたときのレンダリング戦略を、改めて整理する。

CloudflareがAstroを買収した

まず背景として知っておきたいのが、Cloudflareによる買収だ。

2026年1月16日、CloudflareはThe Astro Technology Companyの買収を発表した。AstroはオープンソースのままMITライセンスで継続開発される。フルタイムの開発メンバーはそのままCloudflareの社員となり、引き続きAstroの開発に専念している。

この買収が意味するのは、AstroとCloudflare Workersの統合がより深く・早く進んでいくということだ。Astro 6はまさにその第一弾として登場した。

Astro 6最大の変更点：開発環境がworkerdで動く

Astro 6で最も重要な変更は、開発サーバーの刷新だ。

これまでAstroは、開発環境（astro dev）と本番環境でコードパスが別々だった。Cloudflare Workers固有のAPIは開発時にポリフィルやモックで代替されており、ローカルでは動くのに本番でエラーになる、という「デプロイしてみないとわからない」問題が日常的に起きていた。

Astro 6はViteのEnvironment APIを活用することでこの問題を解決した。astro dev が今後は workerd——Cloudflareが本番で使っているオープンソースのJavaScriptランタイム——上で直接動作するようになった。

# セットアップはこれだけ
npx astro add cloudflare

# 以降の astro dev は workerd 上で動く
astro dev

本番と同じランタイムで開発できるということは、Cloudflare固有のAPIやBindings（KV・D1・R2など）の挙動を、デプロイ前にローカルで正確に確認できるということだ。Astro 5まで必要だった「Bindingsをテストするには wrangler dev を使うこと」という注意書きが、もはや不要になった。

Bindings APIの書き方が変わった

Astro 6でもう一つ重要な変更が、CloudflareのBindingsへのアクセス方法だ。

Astro 5では Astro.locals.runtime.env でBindingsにアクセスするのが公式スタイルだったが、Astro 6でこのAPIは廃止された。

代わりに、Cloudflare Workersのネイティブな書き方を使う。

// ❌ Astro 5 の書き方（Astro 6では動かない）
const { env } = Astro.locals.runtime;
const value = await env.MY_KV.get('key');

// ✅ Astro 6 の書き方
import { env } from 'cloudflare:workers';
const value = await env.MY_KV.get('key');

cloudflare:workers からのimportは、Cloudflare Workersのネイティブモジュールだ。workerd上で開発するようになったことで、このような「本物のAPI」をそのまま使えるようになった。

D1（SQLite）を使う場合も同様だ。

// src/pages/posts/[slug].astro
---
export const prerender = false;

import { env } from 'cloudflare:workers';

const post = await env.DB.prepare(
  'SELECT * FROM posts WHERE slug = ?'
).bind(Astro.params.slug).first();
---
<article>{post?.body}</article>

レンダリングモードの基本はAstro 5から継続

レンダリング戦略の設計思想自体はAstro 5から変わっていない。ここで改めて整理しておく。

Astro 6の output 設定は実質2択だ。

output	デフォルト挙動	ページ単位の上書き
static（デフォルト）	ビルド時に全ページSSG	prerender = false でSSR化
server	すべてのページSSR	prerender = true でSSG化

hybrid はAstro 5で廃止済みで、Astro 6には存在しない。static モードがhybridの機能を内包しているため、ほとんどのプロジェクトはデフォルトの static のままでいい。

// astro.config.mjs
import { defineConfig } from 'astro/config';
import cloudflare from '@astrojs/cloudflare';

export default defineConfig({
  adapter: cloudflare(),
  // output は省略時 'static'
  // SSR主体なら output: 'server' を追加
});

ページ単位の制御

---
// ダッシュボード: SSRにしたいページ
export const prerender = false;

import { env } from 'cloudflare:workers';
const user = await env.DB.prepare(
  'SELECT * FROM users WHERE id = ?'
).bind(Astro.cookies.get('user_id')?.value).first();
---
<h1>こんにちは、{user?.name}さん</h1>

---
// 会社概要: ビルド時生成で十分なページ
// output: 'server' のプロジェクトでは明示的に書く
export const prerender = true;
---
<h1>会社概要</h1>

使い分けの目安

• ブログ・ドキュメント・マーケティングサイト → static（デフォルト）のまま。動的部分だけ prerender = false
• ECサイト → 商品ページはSSG、カート・マイページはSSR。static モードで十分
• ダッシュボード・SaaS管理画面 → ほぼSSR。output: 'server' にして静的ページに prerender = true

新機能①：Live Content Collections

Astro 6で安定版になった注目機能のひとつが Live Content Collections だ。

従来のContent Collectionsはビルド時にデータを取得するため、コンテンツを更新するたびに再ビルドが必要だった。Live Collectionsはリクエスト時にデータを取得するため、再ビルドなしでリアルタイムにコンテンツが更新される。

// src/content/config.ts
import { defineLiveCollection } from 'astro:content';
import { storeLoader } from '@mystore/astro-loader';

const products = defineLiveCollection({
  loader: storeLoader({
    apiKey: import.meta.env.STORE_API_KEY,
  }),
});

export const collections = { products };

Cloudflare Workersのエッジで動作するため、世界中のユーザーに対してリアルタイムデータを低レイテンシで配信できる。ECサイトの在庫情報、ニュースフィード、スポーツのスコアなど、常に最新データが必要なコンテンツに適している。

新機能②：CSP（Content Security Policy）サポート

Astro 6でもう一つ安定版になったのが、ビルトインCSPサポートだ。これはAstroで最も要望が多かった機能だという。

XSS（クロスサイトスクリプティング）などのコードインジェクション攻撃を防ぐCSP設定を、Astroが自動的に生成してくれる。インラインスクリプトやスタイルのハッシュも自動計算されるため、手動でのハッシュリスト管理が不要になった。

// astro.config.mjs
export default defineConfig({
  adapter: cloudflare(),
  csp: true, // デフォルト保護を有効化
});

詳細なポリシーを設定したい場合はオブジェクト形式で書ける。

csp: {
  scriptDirective: {
    resources: ["'self'", "https://cdn.example.com"]
  }
}

Static・SSR・SPAのすべてのレンダリングモードで動作し、Cloudflare・Netlify・Node・Vercelの全アダプターに対応している。

実験的機能：ルートキャッシングとRustコンパイラ

Astro 6では実験的機能もいくつか入っている。

ルートキャッシングAPIは、プラットフォームに依存しないWeb標準ベースのSSRレスポンスキャッシュだ。従来はCloudflare KVを使ったISRをミドルウェアで自前実装する必要があったが、このAPIが安定版になれば標準的な手段として使えるようになる予定だ。

キューイングレンダリングは、従来の再帰的なコンポーネントレンダリングを2パスのキューベースアプローチに置き換えるもので、早期ベンチマークでは最大2倍の速度改善が確認されている。

Rustコンパイラ（@astrojs/compiler-rs）も実験的に使えるようになった。従来のGoベースのコンパイラから移行中で、より高速でより信頼性の高い診断が得られるとされている。

アップグレードの注意点

既存のAstro 5プロジェクトからは、公式CLIツールでアップグレードできる。

npx @astrojs/upgrade

主な注意点は2つだ。

Node.js 22以上が必須になった。Astro 5は18.17.1以上だったので、Node.jsのバージョンを確認・更新しておく必要がある。

Astro.locals.runtime.env の廃止。Cloudflare Bindingsにアクセスしている箇所をすべて import { env } from 'cloudflare:workers' に書き換える必要がある。影響範囲はコードベース内をgrepすれば一発で出てくる。

# 影響箇所の確認
grep -r "Astro.locals.runtime" src/

まとめ

Astro 6 + Cloudflare Workersのポイントを整理するとこうなる。

• CloudflareがAstroを買収（2026年1月）。Cloudflare Workersとの統合が一気に深まった
• astro dev がworkerd上で動くようになった。本番と開発の差異がなくなり、「デプロイしてみないとわからない」問題が解消された
• Astro.locals.runtime.env は廃止。import { env } from 'cloudflare:workers' のネイティブAPIに統一
• レンダリングモードの設計はAstro 5から継続。static（デフォルト）＋ prerender = false という組み合わせが基本
• Live Content Collections が安定版に。再ビルドなしでリアルタイムデータを配信できる
• CSPサポートが安定版に。XSS対策がconfig一行で有効になる

AstroはCloudflareのバックアップを得て、Cloudflare Workersとの親和性がこれ以上ないレベルまで高まっている。Vite 7・Zod 4・Shiki 4といったコア依存関係も最新化され、スタックとしての鮮度も高い。「速くて、安全で、動的にもなれる」という三拍子を揃えたWebスタックとして、2026年現在これ以上の選択肢はそうそうないと思っている。