Astro Cloudflare デプロイ完全ガイド：SSR 設定＋中国国内アクセス 3 倍高速化

先週、友人の Astro ブログのデプロイを手伝ったとき、面白い問題にぶつかりました。Cloudflare Pages にデプロイしたあと、海外からテストするとページは一瞬で開き、体験はとても快適。ところが中国国内の友人が開くと、読み込みに約 5 秒かかった——これは困りものです。

Cloudflare は世界 300 以上のデータセンターを持ち、無料で帯域幅も無制限なのに、なぜ中国国内からのアクセスはこんなに遅いのでしょうか。多くの開発者が悩む問題です。「最適 IP」という言葉を聞いたことはあっても、具体的な手順やアカウント停止のリスク、実際の効果について、不安を感じる方も多いはずです。

この記事では、Astro の Cloudflare デプロイを基礎の静的サイトから SSR 設定、中国国内アクセス最適化まで一通り解説します。私自身もいろいろとつまずいたので、その経験を整理して、同じ轍を踏まない助けになればと思います。

この記事で得られること：

• 20 分でゼロからデプロイ・公開まで
• SSR アダプターの 3 モードを理解し、迷わなくなる
• 国内アクセス最適化 3 案をマスターし、レイテンシを 3 倍改善

それでは始めましょう。

なぜ Cloudflare Pages か

Cloudflare vs Vercel：無料ホスティング比較

よく聞かれるのが「Vercel と Cloudflare、どっち？」——結局は要件次第です。

帯域幅の制限差が最も目立ちます。Vercel 無料プランは月 100GB。超過分は従量課金で、100GB あたり $40。以前、あるプロジェクトが急にバズってトラフィックが急増し、Vercel の請求書を見てかなりショックを受けました。Cloudflare Pages は帯域無制限・完全無料。個人開発者にとって本当にありがたく、トラフィック爆増で課金される心配がありません。

グローバル性能では、Cloudflare は 300 以上のデータセンターでカバーが広い。欧州・アジア・米州で計測したところ、どこもレイテンシが低かった。Vercel のエッジネットワークも優秀ですが、ノード数は相対的に少なめ。ユーザーが世界各地にいるなら、Cloudflare の方が有利です。

もう一つの実用的な強み：DDoS 保護。Cloudflare 無料プランでも DDoS 保護が標準搭載で、追加設定は不要。以前サイトが攻撃を受けましたが、Cloudflare が自動ブロック。ログすら見ていませんでした。Vercel にも保護はありますが、無料版は主に自社ネットワーク向けで、サイト専用の深い保護ではありません。

Vercel の強みは？ビルドキャッシュが優秀。画像・依存が多いプロジェクトでは、前回ビルドのキャッシュを保持し、2 回目は 3〜4 分で完了。Cloudflare Pages は毎回ゼロからで、10 分以上かかることも。Next.js との深い統合も。Next.js なら Vercel が最適——いわゆる「本命」です。

おすすめの使い分け：

• Astro 静的ブログ → Cloudflare Pages（無料で大容量トラフィック）
• トラフィックが読めないプロジェクト → Cloudflare Pages（従量課金を回避）
• Next.js ヘビーユーザー → Vercel（体験が最も良い）
• 頻繁なビルド・高速イテレーション → Vercel（ビルドキャッシュが速い）

Cloudflare Pages vs Workers：2025 年の変化

最初は私も混乱しました。Cloudflare には Pages も Workers もあり、どちらも Astro をデプロイできる——結局どっち？

本質的な違いはシンプル。Workers は Cloudflare のサーバーレス計算プラットフォームで、エッジで JavaScript を実行できます。Pages は Workers + 自動ビルドツールのラッパー。底層は Workers ですが、Git 連携・自動デプロイなどがすぐ使えます。

2025 年の変化として、Cloudflare 公式は新規プロジェクトに Workers を推奨し始めました。公式ブログによると、Workers の方が柔軟で制御が細かいため。ただし Astro ユーザーにとっては、あまり気にしなくて大丈夫です。

実際の体感：

• Pages 方式：GitHub リポジトリを接続し、push するだけで自動ビルド。シンプル。「とにかく早くデプロイしたい」向け。
• Workers 方式：Wrangler CLI で手動デプロイ、wrangler.jsonc を設定。環境変数・KV バインディングなどを細かく制御可能。

Astro プロジェクトはどちら？

• 純静的サイト（output: ‘static’）：Pages + Dashboard Git 連携が最も手軽
• SSR サイト（output: ‘server’ または ‘hybrid’）：どちらも可。Pages + Wrangler CLI を推奨——自動化と柔軟性を両立

初めてなら、まず Pages の Git 連携で試してみてください。数分で効果が見えます。慣れてから Wrangler CLI を検討すれば十分です。

Astro Cloudflare デプロイ完全フロー

静的サイトデプロイ：5 分で始める

Astro プロジェクトが純静的（ブログ・ドキュメント・ポートフォリオなど）なら、デプロイはとても簡単。手順を順に見ていきましょう。

前提条件：

• プロジェクトが GitHub に push 済み
• Cloudflare アカウント（なければ無料登録）

具体的手順：

1. Cloudflare Dashboard にログイン
   dash.cloudflare.com を開き、左メニューの Workers & Pages へ。

2. 新規プロジェクト作成
   右上 Create application → Pages → Connect to Git。

3. GitHub リポジトリ接続
   Astro プロジェクトのリポジトリを選択。初回は Cloudflare への GitHub アクセス許可が必要。指示に従って操作。

4. ビルド設定
   ここを間違えるとデプロイ失敗。設定は以下のとおり：

   • Framework preset：Astro（コマンドが自動入力）
   • Build command：npm run build
   • Build output directory：dist
   • Root directory：リポジトリ直下なら空欄、サブディレクトリならパスを入力

5. デプロイ実行
   Save and Deploy をクリック。数分待てば、Cloudflare がコード取得・依存インストール・ビルド・デプロイを自動実行。

ビルド成功後、your-project.pages.dev ドメインが発行され、直接アクセスできます。GitHub に push するたびに自動ビルドが走り、とても便利です。

よくある問題：

• ビルド失敗、Node.js バージョンエラー：プロジェクトルートに .nvmrc または .node-version を追加し、18 または 20 を記載。Cloudflare が自動認識。
• 404 表示：Build output directory が dist か確認。設定によっては public や build の場合も。astro.config.mjs に合わせて調整。
• ビルドタイムアウト：依存が多い、またはネットワーク問題の可能性。再デプロイを試す。2 回目で通ることが多い。

カスタムドメインの紐付け（任意）：

デプロイ成功後、プロジェクト設定の Custom domains → Set up a custom domain でドメイン（例：blog.yourdomain.com）を入力。Cloudflare が CNAME レコードを提示するので、DNS プロバイダー側で追加。ドメイン自体が Cloudflare DNS なら自動設定でさらに簡単。

SSR サイトデプロイ：@astrojs/cloudflare アダプター設定詳解

SSR は最初、公式ドキュメントが分散していて戸惑いました。ここでは実際の操作順に、各ステップを説明します。

SSR が必要なのはいつ？

先にシーンを整理しておきましょう：

• リアルタイムデータが必要：コメント、アクセス統計、ユーザーログインなど
• サーバー側ロジックが必要：API 呼び出し、DB クエリ、権限検証
• オンデマンドレンダリングが必要：コンテンツ量が巨大で、全部を静的プリレンダリングしたくない

純粋なブログで記事が Markdown ファイルだけなら、SSR は不要。静的デプロイで十分です。

ステップ 1：@astrojs/cloudflare アダプターのインストール

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

プロジェクトルートで実行：

npx astro add cloudflare

このコマンドが自動で 3 つを実行します：

1. @astrojs/cloudflare パッケージのインストール
2. astro.config.mjs へアダプター設定を追加
3. wrangler.jsonc（Cloudflare Workers 設定ファイル）の作成

実行後、astro.config.mjs はおおよそ次のようになります：

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

export default defineConfig({
  output: 'server', // 新規追加
  adapter: cloudflare(),
});

ステップ 2：レンダリングモードの選択（重要！）

3 つの選択肢があり、ここでつまずく人が多い。詳しく説明します：

1. output: 'server' — 全站 SSR

• 全ページをサーバー側でレンダリング
• 向いている：データ駆動アプリ、頻繁に更新するコンテンツ
• 欠点：リクエストごとにレンダリング、性能はやや低下

2. output: 'hybrid' — ハイブリッド（推奨）

• デフォルトは静的
• 特定ページだけ SSR を選択可能
• 向いている：大部分が静的なブログだが、一部だけ動的機能が必要
• 利点：柔軟性が最も高く、性能も良好

3. output: 'static' — 純静的

• アダプター不要、前述の静的デプロイ

おすすめ：90% のケースでは hybrid。全站 SSR が確実に必要でない限り。

hybrid モードの使用例：

// astro.config.mjs
export default defineConfig({
  output: 'hybrid', // hybrid に変更
  adapter: cloudflare(),
});

SSR が必要なページに 1 行追加：

// src/pages/api/comments.js
export const prerender = false; // このページは SSR

export async function GET() {
  // DB からコメント取得
  const comments = await fetchComments();
  return new Response(JSON.stringify(comments));
}

他のページはデフォルトで静的のまま、変更不要。

ステップ 3：Cloudflare サービスバインディング（任意）

KV ストレージ、D1 データベース、R2 オブジェクトストレージを使う場合、wrangler.jsonc でバインディングを設定。

例：KV でユーザーセッションを保存する場合：

// wrangler.jsonc
{
  "name": "my-astro-app",
  "compatibility_date": "2024-01-01",
  "kv_namespaces": [
    {
      "binding": "MY_KV",
      "id": "your-kv-namespace-id"
    }
  ]
}

先に Cloudflare Dashboard で KV namespace を作成し、ID をコピーして入力。

コードでの利用例：

// src/pages/api/session.js
export const prerender = false;

export async function GET({ locals }) {
  const { MY_KV } = locals.runtime.env;
  const sessionData = await MY_KV.get('user:123');
  return new Response(sessionData);
}

ステップ 4：ローカル開発とテスト

Wrangler CLI（Cloudflare 公式ツール）をインストール：

npm install wrangler --save-dev

ローカル実行：

npm run build
npx wrangler pages dev ./dist

ローカルサーバーが起動し、Cloudflare 環境を模擬。SSR 機能とバインディングをテストできます。

ステップ 5：本番デプロイ

2 つの方法があります：

方法 1：Wrangler CLI でデプロイ（推奨、制御が細かい）

# Cloudflare アカウントにログイン
npx wrangler login

# ビルド
npm run build

# デプロイ
npx wrangler pages deploy ./dist

初回はプロジェクト名の入力を求められます。2 回目以降は 1 コマンドで完了。

方法 2：Git 連携の自動デプロイ

前述の静的デプロイと同様、GitHub リポジトリを接続。Cloudflare が @astrojs/cloudflare アダプターを自動認識。ただし KV などのバインディングは Dashboard で手動設定が必要で、やや手間。

よくあるエラー対処：

1. 「Hydration completed but contains mismatches」
   よくあるエラー。原因は Cloudflare の Auto Minify が HTML を圧縮して壊したこと。
   対処：Cloudflare Dashboard → ドメイン → Speed → Optimization で、Auto Minify の HTML・CSS・JS をすべてオフ。

2. 「Cannot find module ‘MY_KV’」
   バインディング未設定。wrangler.jsonc の binding 名とコード内の名前が一致しているか確認。

3. デプロイ後 500 エラー
   Cloudflare Dashboard → Workers & Pages → プロジェクト → Logs（リアルタイムログ）で詳細を確認。未バインドのリソースへのアクセスが原因のことが多い。

環境変数とシークレット管理

環境変数は混乱しやすい部分。以前、API キーを誤って GitHub に push し、すぐに revert した経験があります。正しい手順を説明します。

ローカル開発環境：

プロジェクトルートに .dev.vars を作成（先頭にドット）：

# .dev.vars
DATABASE_URL=postgres://localhost:5432/mydb
API_KEY=your-secret-key-for-dev

重要：.dev.vars を .gitignore に追加し、GitHub に push しないこと。

ローカル開発時、Wrangler がこのファイルを自動読み込み。コードでは次のようにアクセス：

export const prerender = false;

export async function GET({ locals }) {
  const apiKey = locals.runtime.env.API_KEY;
  // apiKey でサードパーティ API を呼び出し
}

本番環境：

.dev.vars は使わず、Cloudflare Dashboard で設定。

手順：

1. Workers & Pages → プロジェクトを選択
2. Settings → Environment Variables
3. Add variable で名前と値を入力
4. 環境（Production または Preview）を選択

機密情報は Secrets を使用：

特に敏感なデータ（決済 API キーなど）は Cloudflare Secrets で暗号化保存：

npx wrangler secret put API_KEY

実行後に値を入力。コマンドラインには表示されず、より安全。

おすすめ：

• DB URL、サードパーティ API キー → Secrets
• 公開設定（サイト名、CDN アドレスなど）→ 通常の環境変数

中国国内アクセス速度最適化の実践

問題診断：国内からの実速度をテスト

デプロイ後、いきなり最適化せず、まず実速度を計測。ユーザーが主に海外なら、Cloudflare デフォルト設定で十分なことも多い。

オンライン測速ツール：

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

1. 17ce.com（推奨）
   17ce.com を開き、ドメインを入力してサイト速度テストを選択。中国国内の各省・各キャリアからテスト。応答時間の列に注目。200ms 以内なら良好、300ms 超なら最適化を検討。

2. Chinaz ツール Ping テスト
   tool.chinaz.com/speedtest。機能は類似。より詳細なルーティング情報が見える。

ローカルテスト：

中国国内にいるなら、Chrome DevTools で計測：

1. F12 で DevTools を開く
2. Network タブに切り替え
3. ページをリロードし、最初のリクエストの Time を確認

判断基準：

• レイテンシ < 150ms：良好、最適化不要
• レイテンシ 150〜250ms：許容範囲、要件次第
• レイテンシ > 250ms または 読み込み > 3 秒：最適化を推奨

なぜ国内は遅い？

Cloudflare は Anycast 技術を使いますが、中国国内のネットワーク環境は特殊で、ルーティングが遠回りになることがあります。北京からアクセスしても、トラフィックが香港経由で戻るなど、レイテンシが高くなります。最適 IP / CNAME の原理は、より直接的なルートのノードを見つけることです。

案 1：最適 IP を使う（無料、効果最大）

最も効果が出やすい方法。私のテストではレイテンシ 280ms → 70ms 程度。ただし多少の手間とリスクあり（後述）。

最適 IP とは？

Cloudflare には数百の IP アドレスがあり、それぞれ異なるデータセンターに対応。中国国内からのアクセス速度は IP ごとに大きく差があり、遠回りで遅いものも、直結で速いものもあります。最適 IP とは、速い IP を見つけてドメインを直接そこに解決すること。

ステップ 1：最適 IP をテスト

CloudflareSpeedTest ツールを GitHub からダウンロード：XIU2/CloudflareSpeedTest

Windows は CloudflareST.exe、Linux/Mac は対応版。

実行方法（Windows）：

# ダブルクリックまたはコマンドライン
CloudflareST.exe

数百の Cloudflare IP を自動テスト。5〜10 分程度。完了後、最速 IP リストが出力されます：

IP アドレス       レイテンシ  ダウンロード速度
104.16.160.10   68ms    15.2MB/s
172.64.32.5     75ms    14.8MB/s
104.23.240.28   82ms    13.9MB/s

1 番目（最低レイテンシ）の IP をメモ。

ステップ 2：DNS 解決を変更

重要な前提：ドメイン DNS は Cloudflare 以外（Alibaba Cloud（アリババクラウド）、DNSPod など）で管理すること。Cloudflare DNS 上だと Anycast が強制され、A レコードを変えても効果がありません。

設定方法（DNSPod の例）：

1. DNS プロバイダーにログイン

2. ドメインの A レコードを追加/変更：

   • ホスト：@（ルートドメイン）または www
   • タイプ：A
   • 値：104.16.160.10（計測した最適 IP）
   • TTL：600（10 分）

3. 保存し、反映待ち（通常 5〜10 分）

ステップ 3：効果を検証

DNS 反映後、17ce.com で再計測。明確な改善が見えるはず。

リスク提示（重要！）：

2025 年 1 月、Cloudflare が利用規約を更新。「乱用」行為を制限・処罰する条項があります。最適 IP が該当するかは明記されていませんが、リスクは存在します。

おすすめ：

• 個人ブログ・小規模プロジェクト：使ってもリスクは低め
• 商用サイト・大規模トラフィック：慎重に。案 2（CNAME）または案 3（地域別解決）を推奨
• 定期チェック：IP は失効する可能性。1〜2 か月ごとに計測し、新しい IP に更新

よくある問題：

1. DNS 変更が反映されない

   • ブラウザキャッシュをクリア、またはシークレットモードでテスト
   • nslookup yourdomain.com で DNS 反映を確認

2. しばらくしてまた遅くなった

   • IP 失効の可能性。再計測して新しい IP に変更

3. 地域によって速度差

   • キャリア（China Telecom / China Unicom / China Mobile）ごとに最速 IP が異なる。案 3（キャリア別 DNS 解決）で解決

案 2：最適 CNAME ドメイン（無料、より安定）

自分で IP を計測するのが面倒、または IP 失効が心配なら、公共の最適 CNAME ドメインが使えます。裏側で誰かが最適 IP を定期更新してくれるので、かなり楽。

原理：

開発者やコミュニティがドメインを用意し、定期テストして最新の最適 IP に解決。自分のドメインを CNAME でそのドメインに向けるだけで加速効果を得られます。

ステップ 1：公共 CNAME を選択

よく使われる公共最適ドメイン（例示のみ。使用前に自分でテスト）：

• cdn.cloudflare.quest
• cf.xiu2.xyz

注意：公共 CNAME はいつ失効してもおかしくない。関連コミュニティや Telegram グループに参加し、最新の有効ドメインを入手することを推奨。

ステップ 2：DNS 解決を変更

こちらも DNS は Cloudflare 外である必要あり。設定方法（DNSPod の例）：

1. DNS プロバイダーにログイン

2. CNAME レコードを追加：

   • ホスト：@ または www
   • タイプ：CNAME
   • 値：cdn.cloudflare.quest（選択した公共ドメイン）
   • TTL：600

3. 保存し、反映待ち

ステップ 3：403 エラーの対処

CNAME 方式では 403 Forbidden が出やすい。Cloudflare が、システムに未登録のドメインが IP 経由でアクセスしていると検知するため。

対処法：

1. ドメイン DNS を Cloudflare から移出（まだ Cloudflare 上なら）
2. Cloudflare Dashboard でそのサイトを削除
3. 数分待ってから再アクセス。通常は正常化

ステップ 4：効果を検証

CNAME 反映後、nslookup yourdomain.com で公共 CNAME ドメインに解決されているか確認し、測速で検証。

メリット・デメリット：

• メリット：

  • 自分で IP 計測不要
  • 管理者が定期更新、安定性がやや高い
  • 最適 IP 直書きよりリスクがやや低い

• デメリット：

  • 第三者依存。停止したら自分も止まる
  • 自分専用に最適化された IP より速度は劣る場合も

おすすめ：「最適化したいがあまりいじりたくない」ユーザー向け。コスパが高い。

案 3：分地域解決（有料 DNS、効果最大）

最終手段。効果は最大だが、多少のコストがかかる。国内外ユーザーが多く、速度重視のサイト向け。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

基本的な考え方：

地域ごとに異なる IP を返す。例：

• 中国国内 China Telecom ユーザー → China Telecom 向け最適 IP
• 中国国内 China Unicom ユーザー → China Unicom 向け最適 IP
• 海外ユーザー → Cloudflare デフォルト（または your-project.pages.dev）

全員が最適ルートでアクセスできます。

必要なツール：

スマート解決対応 DNS プロバイダー：

• DNSPod（Tencent Cloud 傘下、個人版無料で基本機能あり）
• Alibaba Cloud DNS（有料だが機能が強力）
• Cloudflare DNS（国内キャリア別非対応、この用途には不向き）

設定方法（DNSPod の例）：

1. キャリア別に最適 IP をテスト

   CloudflareSpeedTest を China Telecom・China Unicom・China Mobile 各ネットワークで実行し、最速 IP を記録。または以下の IP 帯を参考（自分で計測する方が正確）：

   • China Telecom：104.16.160.0/24
   • China Unicom：104.23.240.0/24
   • China Mobile：172.64.32.0/24

2. キャリア別解決を設定

   DNSPod にログインし、複数の A レコードを追加。各レコードに異なる回線タイプを設定：

   レコード 1：
   - ホスト名：@
   - レコードタイプ：A
   - 回線タイプ：China Telecom
   - レコード値：104.16.160.10
   
   レコード 2：
   - ホスト名：@
   - レコードタイプ：A
   - 回線タイプ：China Unicom
   - レコード値：104.23.240.5
   
   レコード 3：
   - ホスト名：@
   - レコードタイプ：A
   - 回線タイプ：China Mobile
   - レコード値：172.64.32.8
   
   レコード 4（デフォルト回線、海外ユーザー向け）：
   - ホスト名：@
   - レコードタイプ：CNAME
   - 回線タイプ：デフォルト
   - レコード値：your-project.pages.dev

3. 保存し、反映待ち

効果：

キャリア別解決後、国内各キャリアユーザーは最速ノードに、海外ユーザーはネイティブ Cloudflare に。両方をカバー。

コスト：

• DNSPod 個人版：無料（基本キャリア別対応）
• DNSPod プロ版：20 人民元/月（より細かい地域分け）
• Alibaba Cloud DNS：クエリ量課金、小規模サイトなら月数人民元程度

おすすめ：月間 PV が 1 万超なら、このコストは十分に見合う。体験向上が明確。

最適化効果の比較とモニタリング

各案の効果を実データで比較します。

最適化前後の速度比較（あるブログの実測、北京・China Telecom）：

最適化後は 3〜5 倍の速度向上。ユーザー体験がまったく変わります。

長期モニタリング：

最適化後も IP 失効の可能性があるため、定期監視が必要。

おすすめツール：

1. UptimeRobot（uptimerobot.com）

   • 無料で 50 サイト監視
   • 5 分ごとに ping、ダウン時にメール通知
   • 応答時間トレンドを確認可能

2. Cloudflare Analytics

   • Cloudflare Dashboard 標準、無料
   • アクセス元、帯域使用量、エラー率
   • 国内レイテンシの詳細は見えない欠点

3. Better Uptime（betteruptime.com）

   • 有料だが無料版あり
   • 公開ステータスページ作成可能、ユーザー信頼向上

最適 IP の更新タイミング：

1〜2 か月ごとにリマインダーを設定：

1. 17ce.com で計測、レイテンシが明らかに悪化していないか
2. 200ms 超なら CloudflareSpeedTest を再実行し、新 IP に更新
3. DNS レコードを更新

私の経験では、IP は 2〜3 か月で一度、明らかな変動があります。タイムリーに更新すれば問題ありません。

まとめ

要点を整理します。

デプロイフローでは、Cloudflare Pages への Astro デプロイは本当に簡単。純静的なら GitHub 接続で数分、SSR なら npx astro add cloudflare で一発設定。hybrid または server を選び、静的は静的、動的は動的——柔軟で効率的。

SSR 設定のポイント：

• 90% のシーンでは hybrid が最適
• KV/D1/R2 が必要なら wrangler.jsonc でバインディング
• ローカルは .dev.vars、本番は Dashboard で環境変数
• Hydration エラーは Auto Minify をオフ

国内アクセス最適化の 3 案：

• 案 1（最適 IP）：効果最大・無料・定期メンテ必要・一定リスク
• 案 2（公共 CNAME）：手間少・無料・中程度・いじりたくないユーザー向け
• 案 3（キャリア別 DNS 解決）：最終手段・少額コスト・国内外両方カバー

おすすめ：

• 個人ブログ・小規模 → 案 1 または案 2
• トラフィック大・体験重視 → 案 3
• 商用サイト → 最適 IP は慎重に。案 3 かデフォルト速度を優先

次のアクション：

まだ始めていなければ：

1. Cloudflare アカウントを作成し、静的デプロイで速度を体感
2. 国内アクセスが遅ければ 17ce.com で計測し、最適化の要否を判断
3. 最適化後はリマインダーを設定し、IP 失効を定期確認

次の学習ステップ：

デプロイは第一歩。Cloudflare エコシステムにはまだ強力な機能があります：

• Workers KV：キーバリューストア、キャッシュ・セッション向け
• D1：SQLite データベース、エッジで直接実行
• R2：オブジェクトストレージ、AWS S3 相当、無料枠も大きい
• Pages Functions：Pages 内でサーバーレス関数を記述

これらは Astro とシームレスに連携可能。少しずつ探索してください。

最後に、この記事が役に立ったら、コメント欄でデプロイ体験やつまずきポイントを共有してください。みんなで学び合いましょう。