ANTIGRAVITY LABEN
記事一覧/アプリ開発
アプリ開発/2026-03-10中級

Cloudflare Workers × Antigravity デプロイガイド

Cloudflare WorkersとAntrigravityを使ったエッジコンピューティングデプロイガイド

Cloudflare Workers7デプロイ5Next.js6エッジWrangler

Cloudflare Workers × Antigravity デプロイガイド

エッジコンピューティングの時代において、グローバル規模での高速配信は必須要件です。Cloudflare Workersはこの課題を解決する強力なプラットフォームであり、Antigravity Labと組み合わせることで、エンジニアの生産性を大幅に向上させることができます。

ここでCloudflare WorkersとAntrigraityを連携させたデプロイフロー、環境構築から本番運用までのすべてをカバーします。

Cloudflare Workersとは

Cloudflare Workersは、Cloudflareのグローバルネットワーク上で実行されるサーバーレス関数プラットフォームです。従来のサーバーレスアーキテクチャとは異なり、ユーザーに地理的に近いエッジロケーションでコードが実行されます。

エッジコンピューティングの利点

レイテンシ削減 中央集約型のサーバーではなく、世界中の280以上のロケーションから配信されるため、平均レスポンスタイムが30~40%削減されます。

スケーラビリティ リクエストが自動的に地理的に近いエッジに分散されるため、トラフィック急増時の対応が容易です。

コスト効率 従量課金制であり、実行時間とリクエスト数に基づいて課金されるため、予測不可能なトラフィックパターンに対応しやすいです。

セキュリティ強化 DDoS対策やWAFがネイティブに統合されており、追加設定なしにセキュリティが確保されます。

Antigravityでプロジェクトを始める

Antigravity Labのエージェント機能を活用すれば、Cloudflare Workersプロジェクトの初期設定を大幅に短縮できます。

ステップ1: Wranglerのインストール

npm install -g wrangler
wrangler login

Wranglerは、Cloudflare Workersの公式CLIツールです。wrangler loginでCloudflareアカウントに認証します。

ステップ2: 新規プロジェクトの生成

wrangler generate my-workers-project
cd my-workers-project

このコマンドで基本的なプロジェクト構造が自動生成されます。Antigravity Labを使用する場合、このタイミングでプロジェクト構造の最適化を提案させることができます。

ステップ3: プロジェクト構造の確認

my-workers-project/
├── src/
│   └── index.ts          # メインの関数
├── wrangler.toml         # 設定ファイル
├── package.json
├── tsconfig.json
└── .gitignore

Antigravity Labのコード解析機能を使用すれば、この構造を自動的に検査し、最適化の提案が得られます。

Next.js + OpenNext アダプターでのデプロイ

Next.jsで構築したアプリケーションをCloudflare Workersにデプロイするには、OpenNextというアダプターが必須です。

OpenNextのセットアップ

npm install -D @opennextjs/cloudflare

next.config.jsの設定

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    platformLogs: {
      edge: "debug",
      nodeCompat: true,
    },
  },
};
 
module.exports = nextConfig;

wrangler.tomlの完全設定例

name = "my-next-app"
type = "service-worker"
account_id = "your-account-id"
workers_dev = true
route = "example.com/*"
zone_id = "your-zone-id"
 
env = "production"
 
[env.production]
vars = { ENVIRONMENT = "production" }
routes = [
  { pattern = "example.com/api/*", zone_name = "example.com" }
]
 
[build]
command = "npm run build"
cwd = "./"
main = "./.open-next/server/index.js"
 
[[migrations]]
tag = "v1"
new_sqlite_db = "async_db"

ビルドと検証

npm run build
wrangler deploy --dry-run

--dry-runフラグにより、実際のデプロイなしに構成を検証できます。Antigravity Labはこのログを自動解析し、問題を特定できます。

wrangler.toml の設定方法

wrangler.tomlはCloudflare Workersプロジェクトの中核です。詳細な設定オプションをカバーします。

基本設定

name = "my-workers-app"
main = "src/index.ts"
compatibility_date = "2026-03-01"
compatibility_flags = ["nodejs_compat"]

compatibility_dateは重要です。この日付から有効になった機能セットが使用されます。定期的に更新することで、最新の最適化が自動適用されます。

データベース連携

[[d1_databases]]
binding = "DB"
database_name = "production-db"
database_id = "abc123..."
migrations_dir = "src/migrations"

Cloudflare D1(SQLiteベースのエッジデータベース)を連携させる場合の設定です。

KVストア設定

[[kv_namespaces]]
binding = "KV_CACHE"
id = "xxxx..."
preview_id = "yyyy..."
 
[[kv_namespaces]]
binding = "KV_SESSION"
id = "zzzz..."
preview_id = "wwww..."

複数のKVバインディングを定義することで、キャッシュとセッション管理を分離できます。

アナリティクスエンジン設定

[[analytics_engine_datasets]]
binding = "ANALYTICS"

ユーザー行動やパフォーマンスメトリクスの収集にはこの設定が必要です。

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

本番環境での環境変数管理は、セキュリティと運用性のバランスが重要です。

開発環境での設定

# .env.development
DATABASE_URL=http://localhost:5432
API_KEY=dev-key-12345

本番環境での設定

wrangler secret put DATABASE_URL
wrangler secret put API_KEY

対話形式でシークレットを登録します。シークレットはCloudflareのシステムで暗号化され、エッジで復号化されます。

コード内でのアクセス

// src/index.ts
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const dbUrl = env.DATABASE_URL;
    const apiKey = env.API_KEY;
 
    return new Response(`Using database: ${dbUrl}`);
  },
};
 
interface Env {
  DATABASE_URL: string;
  API_KEY: string;
  DB: D1Database;
  KV_CACHE: KVNamespace;
}

TypeScriptの型定義を用意することで、開発時に環境変数の不在をキャッチできます。

環境別の設定切り替え

[env.staging]
vars = { API_ENDPOINT = "https://staging.example.com" }
routes = [
  { pattern = "staging.example.com/*", zone_name = "example.com" }
]
 
[env.production]
vars = { API_ENDPOINT = "https://api.example.com" }
routes = [
  { pattern = "example.com/*", zone_name = "example.com" }
]

デプロイ時に環境を指定することで、同一コードベースから複数環境への配信が可能です:

wrangler deploy --env staging
wrangler deploy --env production

CI/CD パイプライン(GitHub → Cloudflare Pages → Workers)

自動デプロイの仕組みを構築することで、手動作業を排除し、品質を向上させます。

GitHub Actions ワークフローの構築

# .github/workflows/deploy.yml
name: Deploy to Cloudflare
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
 
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
 
      - name: Install dependencies
        run: npm ci
 
      - name: Run tests
        run: npm test
 
      - name: Build project
        run: npm run build
 
      - name: Deploy to Cloudflare Workers
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          environment: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}

このワークフローにより、pushイベント時に自動的にテスト・ビルド・デプロイが実行されます。

プレビューデプロイメント

- name: Deploy to Preview
  if: github.event_name == 'pull_request'
  uses: cloudflare/wrangler-action@v3
  with:
    apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
    accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
    previewToken: true
    secrets: |
      DATABASE_URL
      API_KEY

プルリクエスト時にはプレビュー環境にデプロイし、マージ前に動作確認ができます。

カスタムドメインの設定

Cloudflare Workersで配信するコンテンツに独自ドメインを割り当てる方法です。

DNS設定

記録タイプ: CNAME
名前: app.example.com
ターゲット: example.com.cdn.cloudflare.net
TTL: Auto

ドメインのDNS設定でCloudflareをネームサーバーとして指定している場合、Cloudflareダッシュボードから直接ルーティングを設定できます。

wrangler.tomlでのルート定義

route = "app.example.com/*"
zone_id = "your-zone-id"
 
[triggers.crons]
crons = ["0 0 * * *"]

このルート定義により、app.example.comへのすべてのリクエストがWorkerで処理されます。

ワイルドカードルーティング

[[routes]]
pattern = "*.example.com/*"
zone_name = "example.com"
 
[[routes]]
pattern = "example.com/api/*"
zone_name = "example.com"

複数のサブドメインやパスパターンに対応する場合、複数のルート定義が可能です。

パフォーマンス最適化のコツ

エッジでの実行により基本的に高速ですが、さらなる最適化のポイントを紹介します。

キャッシング戦略

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const cacheKey = new Request(request.url, { method: "GET" });
    const cache = caches.default;
 
    let response = await cache.match(cacheKey);
 
    if (!response) {
      response = await fetch(request);
 
      // 5分間キャッシュ
      const headers = new Headers(response.headers);
      headers.set("Cache-Control", "public, max-age=300");
      response = new Response(response.body, {
        ...response,
        headers,
      });
 
      await cache.put(cacheKey, response.clone());
    }
 
    return response;
  },
};

KVストアを活用したきめ細かいキャッシュ制御も可能です:

const cached = await env.KV_CACHE.get(cacheKey);
if (cached) {
  return new Response(cached, {
    headers: { "X-Cache": "HIT" },
  });
}
 
const response = await fetch(upstreamUrl);
await env.KV_CACHE.put(cacheKey, await response.text(), {
  expirationTtl: 3600, // 1時間
});
 
return response;

リクエスト圧縮

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const response = await fetch(request);
    const text = await response.text();
 
    // gzip圧縮
    const compressed = await compress(text);
 
    return new Response(compressed, {
      headers: {
        ...response.headers,
        "Content-Encoding": "gzip",
      },
    });
  },
};

データベースクエリの最適化

// ❌ 非効率:N+1問題
const users = await env.DB.prepare("SELECT id FROM users LIMIT 100").all();
for (const user of users.results) {
  const posts = await env.DB.prepare(
    "SELECT * FROM posts WHERE user_id = ?"
  ).bind(user.id).all();
}
 
// ✅ 効率的:JOINを使用
const results = await env.DB.prepare(`
  SELECT users.*, posts.*
  FROM users
  LEFT JOIN posts ON users.id = posts.user_id
  LIMIT 100
`).all();

バンドルサイズの削減

npm run build -- --analyze

wrangler内でのバンドルサイズを確認し、不要な依存関係を削除します。

{
  "dependencies": {
    "lodash": "remove if unused",
    "moment": "use date-fns instead"
  }
}
シェア

お読みいただきありがとうございます

Antigravity Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

もしこの記事がお役に立ちましたら、チップ(¥150)で応援いただけると大変励みになります。広告なしでの運営を続けるため、皆さまのご支援が大きな力になっています。

関連記事

アプリ開発2026-07-14
デプロイは成功なのに、ユーザーには古いビルドが出ていたとき — 出荷したコミットがエッジに届いたかを検証するゲートの運用メモ
デプロイが成功と表示されたのに本番が古いビルドを配り続けていたとき、出荷したコミットが実際にエッジへ届いたかをビルド印で検証するゲートの作り方を、運用ログの実測とともに整理します。
アプリ開発2026-06-13
TanStack Query v5 のキャッシュ整合性を壊さない設計 — 無効化境界・楽観的更新・SSR の落とし穴を Antigravity で詰めていく
いいねを押すと表示が一瞬で巻き戻る、別タブから戻ると古い値が残る。TanStack Query v5 で起きるキャッシュ不整合を「壊れる3地点」から逆算し、無効化境界・onMutateのロールバック・QueryClientのリクエスト分離を実コードで設計します。
アプリ開発2026-03-30
Antigravity のデプロイ・ビルドエラーを切り分けて直す実践手順
Antigravity でデプロイやビルドが失敗する原因をエラーメッセージ別に解説し、具体的な解決手順を提供します。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →