# Vercel 本番運用ガイド：フロント専用ホストではなく『フルコンピュート基盤』として使い倒す

> Vercel公式ドキュメントに忠実な本番運用ガイド。Fluid Compute（既定）・Vercel Functions・レンダリングとキャッシュ（ISR/CDN/Runtime Cache）・デプロイ（プレビュー/Promote/Instant Rollback/Rolling Releases）・Firewall/WAF/BotID・ストレージ（Blob/Edge Config/Marketplace）・Active CPU課金まで、2026年最新の正しいメンタルモデルと実コードで体系化します。

- 公開日: 2026-06-28
- 著者: 友田 陽大
- タグ: Vercel, Next.js, サーバーレス, Fluid Compute, インフラ, コスト最適化, 可観測性, TypeScript
- URL: https://tomodahinata.com/blog/vercel-production-platform-guide
- カテゴリ: Vercel 本番運用

## 要点

- 2026年のVercelは『フロントエンド／静的サイトのホスト』ではなく、Express・FastAPI・NestJS・Honoなどのバックエンドもゼロ設定で動かす『フルコンピュート基盤』。古い知識（Edge Functions推奨・Vercel Postgres/KV・Node18・60秒タイムアウト）は捨て、Fluid Compute・Marketplace・Node24・既定300秒に更新する
- 実行基盤の既定はFluid Compute（2025-04-23以降の新規プロジェクトで既定ON）。1インスタンスで複数リクエストを処理する『最適化された並行性』でコールドスタートとコストを下げ、waitUntilで応答後のバックグラウンド処理ができ、未処理例外が同居リクエストを巻き込まないエラー隔離を持つ。Node.js・Python・Edge・Bun・Rustが動く
- 課金はActive CPU方式——コードが実際にCPUを使った時間だけ課金され、DBやAI呼び出しのI/O待ちは課金されない。プロビジョンドメモリ（GB-hr）とInvocationsを足した3軸。従来の壁時計GB秒とは別物で、I/O主体のアプリほど安くなる
- レンダリングとキャッシュは『静的（自動）／ISR（フレームワーク連携）／CDN Cache（Cache-Controlヘッダ）／Runtime Cache（関数内データ）』の4層。ISRはstale-while-revalidateで31日間の永続キャッシュ・300msのグローバル purge・リクエスト併合・即時ロールバックを提供する
- 本番の安全弁は4つ——プレビューURLでのレビュー、Production Promote、Instant Rollback（不変デプロイへ即時復帰）、Rolling Releases（カナリア配信）。設定はvercel.ts（型安全・ビルド時に動的生成）かvercel.jsonで宣言し、秘密は環境変数、入口はFirewall/WAF/BotIDで守る

---

「Vercel はフロントエンド（Next.js の静的サイト）を置く場所でしょう？バックエンドは AWS で」——これは2026年現在、**半分以上が誤り**になったメンタルモデルです。いまの Vercel は、Express・FastAPI・NestJS・Hono といったバックエンドフレームワークを**ゼロ設定でそのまま動かすフルコンピュートのアプリケーション基盤**であり、データベース・オブジェクトストレージ・WAF・キュー・サンドボックス・AI ゲートウェイまでをプラットフォームとして備えています。

私自身、この**ポートフォリオサイト（Next.js 16）を含む複数の Next.js 製プロダクトを Vercel の本番で運用**しています。その経験から言えるのは、Vercel を「便利なデプロイ先」としてしか使っていないチームは、**コスト・可観測性・回復性・セキュリティ**の多くを取りこぼしているということです。

この記事は、**[Vercel 公式ドキュメント](https://vercel.com/docs)に忠実でありながら、公式より「どの場面でどう使うか」がわかる**ことを目的にした、本番運用の地図です。まず2026年の正しいメンタルモデルへ知識を更新し、コンピュート・レンダリング/キャッシュ・デプロイ・セキュリティ・データ・コスト・可観測性を一気通貫で扱います。各テーマの深掘りは個別記事へ分けました（本稿が「クラスタの入口＝ピラー」です）。

---

## まず2026年のメンタルモデルへ更新する（よくある誤解の訂正）

LLM や少し前の記事に残る「古い Vercel 像」は、いまや**請求とアーキテクチャの判断を誤らせる**レベルで陳腐化しています。最初にここを直しておきます。

| 古い理解（捨てる） | 2026年の正しい理解（公式） |
|---|---|
| 低レイテンシには **Edge Functions** を使う | Edge は互換性に難。**Fluid Compute（既定）** で通常の Node.js を同一リージョン・同一価格で動かすのが推奨。Middleware と Edge Functions は内部的に Vercel Functions で動く |
| **Middleware は Edge 専用**（Web API のみ） | Middleware は**フル Node.js** で書ける（Fluid Compute）。さらに「Routing Middleware」はフレームワーク非依存の Vercel プロダクト |
| DB は **Vercel Postgres / Vercel KV** | 両者は提供終了。**Vercel Marketplace** 経由で Neon（Postgres）・Upstash（Redis）等を統合する |
| 関数のタイムアウトは **60〜90秒** | **既定300秒**（全プラン）。Pro/Ent は800秒（GA）、拡張1800秒（ベータ） |
| 課金は **壁時計の GB 秒** | **Active CPU 課金**。CPU を実際に使った時間だけ課金、I/O 待ちは非課金 |
| ランタイムは **Node 18** | **Node.js 24 LTS が既定**。Node 18 は非推奨 |
| ISR は **Next.js 専用** | **SvelteKit・Nuxt・Astro でも ISR** が動く |
| Vercel は **静的/フロント専用ホスト** | **フルコンピュート基盤**。Express/FastAPI/NestJS/Hono 等をゼロ設定で実行 |

この表の各行は、後続の各章と個別記事で実コードとともに裏取りしていきます。**「Vercel = フロントを置く場所」という前提を捨てる**——それがこの記事の出発点です。

---

## プラットフォームの全体像：6つのレイヤー

Vercel を本番で使い倒すには、機能を「レイヤー」で捉えるのが近道です。各レイヤーの深掘りは個別記事へリンクしています。

| レイヤー | 主な構成要素 | 一言でいうと | 深掘り |
|---|---|---|---|
| **コンピュート** | Vercel Functions / Fluid Compute / Cron / Workflows | コードを動かす。既定は Fluid Compute | [Functions・Fluid Compute ガイド](/blog/vercel-functions-fluid-compute-streaming-cron-guide) |
| **レンダリング/キャッシュ** | 静的 / ISR / CDN Cache / Runtime Cache / Cache Components(PPR) | 速く返す。4層のキャッシュを使い分ける | [キャッシュ・ISR・Cache Components ガイド](/blog/vercel-caching-isr-cache-components-ppr-guide) |
| **デプロイ/配信** | Git連携 / プレビュー / Promote / Instant Rollback / Rolling Releases | 安全に出す・即戻す | [デプロイ・CI/CD・ロールバック ガイド](/blog/vercel-deployments-cicd-rollback-rolling-releases-guide) |
| **セキュリティ** | Firewall / WAF / BotID / DDoS緩和 / 環境変数 / OIDC | 入口を守る | [Firewall・WAF・BotID ガイド](/blog/vercel-firewall-waf-botid-ddos-security-guide) |
| **データ/ストレージ** | Blob / Edge Config / Marketplace(Neon, Upstash) | 状態を置く | [ストレージ・Blob・Edge Config ガイド](/blog/vercel-storage-blob-edge-config-marketplace-guide) |
| **コスト/運用** | Active CPU 課金 / 可観測性 / Speed Insights | 安く・追える状態にする | [コスト・Active CPU 最適化ガイド](/blog/vercel-cost-active-cpu-pricing-optimization-guide) |

以下、本稿では各レイヤーの「本番でまず押さえるべき要点」を示し、詳細は各リンク先に委ねます。

---

## コンピュート：既定の Fluid Compute を理解する

### Fluid Compute とは何か

従来のサーバーレスは「1リクエスト＝1インスタンス」で、リクエストごとにコールドスタートが起き、I/O 待ちの間も1インスタンスが遊ぶという無駄がありました。**Fluid Compute** は、これを「1インスタンスで複数リクエストを並行処理する」モデルに変えます。公式の言葉では——

> Fluid compute offers a blend of serverless flexibility and server-like capabilities.（— [Fluid compute](https://vercel.com/docs/fluid-compute)）

ポイントは5つです。

- **既定でON**：2025-04-23 以降に作成した新規プロジェクトでは Fluid Compute が既定で有効。
- **最適化された並行性（in-function concurrency）**：1つの関数インスタンスが複数の呼び出しを処理。AI のように「埋め込み取得・ベクトルDB照会・外部API呼び出し」で **I/O バウンド**になるワークロードで特に効く（Node.js・Python ランタイムで利用可）。
- **バックグラウンド処理（`waitUntil`）**：ユーザーにレスポンスを返した**後**で、ログ送信や分析などの後処理を続けられる。
- **コールドスタート低減**：Node.js 20+ では**バイトコードキャッシュ**で再コンパイルを省き、本番では関数のプリウォームも行う。
- **エラー隔離**：Node.js で未処理例外・未処理 Rejection が起きても、Fluid はエラーをログして**実行中の他リクエストを巻き込まず**にプロセスを止める。

> **設計上の含意**：Fluid Compute では、複数リクエストが**同一プロセス（グローバル状態）を共有**します。モジュールスコープに「リクエスト固有の状態」を置くと**漏洩**します。グローバルに置いてよいのは DB 接続プールや設定など「リクエスト間で共有して安全なもの」だけ——これは後述のセキュリティと直結します。

### 有効化（既存プロジェクト）

ダッシュボードの **Project → Settings → Functions** でトグルするか、設定ファイルで宣言します。

```json
// vercel.json — 特定環境やデプロイ単位で Fluid を有効化したいとき
{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "fluid": true
}
```

### 押さえるべき制限（公式の数値）

本番設計の前提になる数値です（[Functions Limits](https://vercel.com/docs/functions/limitations) より）。

| 項目 | Hobby | Pro / Enterprise |
|---|---|---|
| **既定タイムアウト** | 300秒 | 300秒 |
| **最大タイムアウト** | 300秒 | 800秒（GA）／拡張1800秒（ベータ・関数単位設定） |
| **メモリ** | 2 GB / 1 vCPU | 最大 4 GB / 2 vCPU |
| **並行スケール** | 最大 30,000 | 30,000（Pro）／100,000+（Ent） |
| **バンドルサイズ（非圧縮）** | 250 MB（Python は 500 MB） | 同左 |
| **リクエスト/レスポンス本文** | 4.5 MB（超過で 413 `FUNCTION_PAYLOAD_TOO_LARGE`） | 同左 |
| **ファイルディスクリプタ** | 1,024（ランタイム使用分含む・並行実行で共有） | 同左 |
| **既定リージョン** | `iad1`（変更可） | 複数リージョン可（Pro は最大3） |

> **タイムアウトでは足りないとき**：分〜月単位で状態を保ちつつ pause/resume したい処理は、関数のタイムアウトを伸ばすのではなく **[Vercel Workflows](https://vercel.com/docs/workflows)** に切り出します（実行時間の上限なし）。重い同期処理を HTTP 関数に抱え込まないのが鉄則です。

ランタイム・ストリーミング・`waitUntil`・Cron の実コードは [Functions・Fluid Compute ガイド](/blog/vercel-functions-fluid-compute-streaming-cron-guide) で詳説します。

---

## レンダリングとキャッシュ：4つの層を使い分ける

「速い」は1種類のキャッシュで作るものではありません。Vercel は**4層**を提供しており、要件で選びます。

| 層 | 何をキャッシュするか | 設定方法 | いつ使うか |
|---|---|---|---|
| **静的ファイル** | ビルド出力（JS/CSS/画像/フォント） | 自動（設定不要） | すべてのデプロイ。ハッシュ付きファイル名でデプロイ跨ぎも持続 |
| **ISR** | ページ（HTML＋データ） | フレームワークの API（`revalidate` 等） | スケジュール更新（分〜時）のページ。永続・ロールバック耐性・リクエスト併合が欲しいとき |
| **CDN Cache** | 関数のHTTPレスポンス | `Cache-Control` / `CDN-Cache-Control` ヘッダ | ISR非対応フレームワークやAPIレスポンスを地域ごとにキャッシュ |
| **Runtime Cache** | 関数**内**のデータ（fetch結果・DBクエリ・計算値） | Runtime Cache API（タグ無効化） | レスポンス全体ではなく、個別のデータ片を再利用したいとき |

### ISR の要点（公式の挙動）

ISR（Incremental Static Regeneration）は **stale-while-revalidate** パターンです。「キャッシュ済みを即返しつつ、裏で再生成」。Vercel の CDN が乗ると、フレームワークの ISR は次の最適化を**自動で**得ます（[ISR](https://vercel.com/docs/incremental-static-regeneration) より）。

- **31日間の永続ストレージ**：ISR キャッシュは Function リージョンに永続。デプロイごとに独立。
- **300ms のグローバル purge**：再検証すると、全リージョンのキャッシュが 300ms 以内に更新。HTML とデータを**アトミックに**差し替える。
- **リクエスト併合（request collapsing）**：未キャッシュの同一パスに同時アクセスが来ても、リージョンごとに**1回だけ**関数を呼ぶ。トラフィックスパイク時のオリジン保護。
- **即時ロールバック耐性**：過去デプロイのキャッシュは purge されないので、ロールバックしても生成済みコンテンツを失わない。
- **失敗時はステイル維持**：再検証が失敗（ネットワークエラー／200,301,302,307,308,404,410 以外のステータス／関数エラー）したら、**既存のキャッシュを返し続け**、30秒の TTL で再試行。

対応フレームワークは Next.js・SvelteKit・Nuxt・Astro・Gatsby（DSG）。Next.js なら App Router でルートセグメントから `revalidate` を export するだけです。

```ts
// app/products/[id]/page.tsx — 60秒ごとに裏で再生成（stale-while-revalidate）
export const revalidate = 60;

export default async function ProductPage({
  params,
}: {
  params: Promise<{ id: string }>;
}) {
  const { id } = await params;
  const product = await getProduct(id); // ビルド時 or 再検証時に実行
  return <ProductView product={product} />;
}
```

オンデマンド再検証（在庫更新の Webhook 等で即時反映）、Cache Components（PPR）、`Cache-Control` 3種ヘッダの使い分けは [キャッシュ・ISR・Cache Components ガイド](/blog/vercel-caching-isr-cache-components-ppr-guide) で扱います。

### 関数レスポンスを CDN に載せる最小例

ISR を使わない API でも、`Cache-Control` を返せば CDN にキャッシュされます。Vercel は**ブラウザ／下流CDN／Vercel CDN を別々に制御**できる3ヘッダを持ちます。

```ts
// app/api/rates/route.ts
export async function GET() {
  return Response.json(await getRates(), {
    headers: {
      "Cache-Control": "max-age=10",            // ブラウザ：10秒
      "CDN-Cache-Control": "max-age=60",        // 下流CDN：60秒
      "Vercel-CDN-Cache-Control": "max-age=3600" // Vercel CDN：3600秒
    },
  });
}
```

キャッシュ可能条件は厳格です：`GET`/`HEAD`、`Authorization` ヘッダなし、`Set-Cookie` なし、`private`/`no-store` なし、非ストリーミングで 10MB 以下（ストリーミングは 20MB）。結果は `x-vercel-cache` ヘッダ（`HIT`/`MISS`/`STALE`/`PRERENDER`）で確認できます。

---

## デプロイと配信：4つの安全弁

Vercel のデプロイ体験は「git push したら本番に出る」だけではありません。本番事故を防ぐ**4つの安全弁**を最初から組み込みます。

1. **プレビューURL**：ブランチ／PR ごとに本番同等の独立URLが自動生成。レビューと QA はここで。
2. **Production Promote**：プレビューで検証済みのデプロイを本番へ昇格。`vercel promote` または ダッシュボード。
3. **Instant Rollback**：本番デプロイは**不変（イミュータブル）**なスナップショット。問題が出たら過去デプロイへ**即時**復帰できる。
4. **Rolling Releases**：新デプロイをいきなり100%に出さず、**例えば5%**だけに流して Speed Insights 等のメトリクスを比較し、問題なければ段階的に100%へ（Pro は1プロジェクト、Enterprise はカスタム）。

```bash
# プレビュー → 検証 → 本番昇格 → 問題があれば即ロールバック
vercel deploy                 # プレビューデプロイ
vercel promote <deployment>   # 本番へ昇格（Rolling Releases 有効なら自動でカナリア開始）
vercel rollback <deployment>  # 直前の本番へ即時復帰
```

> **Rolling Releases には Skew Protection を併用**：カナリアと現行で「ページのバージョン」と「バックエンドAPIのバージョン」が食い違うと壊れます。Skew Protection が、どちらのデプロイに当たったユーザーも**同じバージョンのバックエンド**と通信することを保証します。

CI/CD（GitHub Actions、`--prebuilt`、OIDC 鍵レス）、Rolling Releases の段階設計、`vcrrForceCanary` での検証、REST API での自動化は [デプロイ・CI/CD・ロールバック ガイド](/blog/vercel-deployments-cicd-rollback-rolling-releases-guide) で詳説します。

### 設定は vercel.ts（型安全）か vercel.json で

2026年の推奨は **`vercel.ts`**——`@vercel/config` を入れて型付き設定を export します。`vercel.json` と違い**ビルド時に実行**されるので、環境変数や API 取得で設定を動的に組み立てられます（どちらか一方のみ使用）。

```ts
// vercel.ts
import { routes, type VercelConfig } from "@vercel/config/v1";

export const config: VercelConfig = {
  framework: "nextjs",
  buildCommand: "npm run build",
  rewrites: [routes.rewrite("/api/(.*)", "https://backend.example.com/$1")],
  redirects: [routes.redirect("/old-docs", "/docs", { permanent: true })],
  headers: [
    routes.cacheControl("/static/(.*)", {
      public: true,
      maxAge: "1 week",
      immutable: true,
    }),
  ],
  crons: [{ path: "/api/cleanup", schedule: "0 0 * * *" }],
};
```

---

## セキュリティ：入口・秘密・実行を多層で守る

Vercel のセキュリティは「アプリのコードを書く前」に効かせるのが基本です。

### 入口：Firewall / WAF / BotID / DDoS

- **DDoS 緩和**は全プランで自動。
- **Vercel WAF** はカスタムルール（allow/deny/challenge/log/rate limit）・IP ブロック・マネージドルールセット（Enterprise）を提供。**設定変更は 300ms でグローバル反映**、問題があれば**即時ロールバック**。
- **BotID** は「見えない CAPTCHA」（Kasada）。チェックアウト・サインアップ・API のような高価値ルートに、ユーザー操作なしで bot 検知を足せる。Basic は全プラン無料、Deep Analysis は Pro が `$1/1000 checkBotId()` 呼び出し。

```ts
// app/api/checkout/route.ts — サーバー側で BotID を検証
import { checkBotId } from "botid/server";

export async function POST(request: Request) {
  const verification = await checkBotId();
  if (verification.isBot) {
    return new Response("Forbidden", { status: 403 });
  }
  return handleCheckout(request);
}
```

WAF のカスタムルール・レート制限・Attack Challenge Mode、BotID のクライアント計装、`vercel firewall` CLI は [Firewall・WAF・BotID ガイド](/blog/vercel-firewall-waf-botid-ddos-security-guide) で扱います。

### 秘密：環境変数と OIDC

秘密はコードに書かず**環境変数**へ。`NEXT_PUBLIC_` 接頭辞の変数は**ブラウザに露出する**ので、API キーには絶対に付けません。`vercel env pull` でローカル `.env` に同期できます。外部クラウド（AWS等）へは長命のアクセスキーを置かず、**OIDic トークン連携（鍵レス）**を使うのが2026年の標準です。

```bash
vercel env pull .env.local      # 本番/プレビュー/開発の環境変数をローカルへ
vercel env add STRIPE_SECRET_KEY production
```

> **Fluid Compute での落とし穴（再掲）**：インスタンスは複数リクエストで共有されます。リクエスト固有のトークンやユーザー情報を**モジュールスコープのグローバル変数**にキャッシュしないでください。テナント越境・情報漏洩の温床になります。

---

## データとストレージ：状態をどこに置くか

Vercel Postgres / Vercel KV は提供終了し、いまは用途で使い分けます。

| 用途 | 選択肢 | 特徴 |
|---|---|---|
| **オブジェクト（画像・動画・PDF等）** | **Vercel Blob** | public/private、S3 バックエンド（11 nines 耐久性）、`@vercel/blob` SDK、CDN 配信 |
| **超低遅延の読み取り（フラグ・リダイレクト・IPブロック）** | **Edge Config** | P99 15ms 未満（多くは 1ms 未満）のグローバル読み取り。更新は稀・読み取りは高頻度なデータ向け |
| **リレーショナルDB** | **Marketplace: Neon (Postgres)** | サーバーレス Postgres。`vercel integration` で統合・環境変数自動注入 |
| **KV / キャッシュ / レート制限** | **Marketplace: Upstash (Redis)** | サーバーレス Redis |

```ts
// Vercel Blob：private で保存し、関数経由で配信
import { put } from "@vercel/blob";

const blob = await put(`invoices/${id}.pdf`, pdfBuffer, {
  access: "private",         // 'public' も選べる（作成後は変更不可）
  addRandomSuffix: true,     // 上書き事故を避け、URL 衝突を防ぐ
});
```

```ts
// Edge Config：機能フラグを超低遅延で読む（Middleware/関数）
import { get } from "@vercel/edge-config";

const maintenance = await get<boolean>("maintenance_mode");
if (maintenance) {
  return Response.redirect(new URL("/maintenance", request.url));
}
```

Blob の client/server アップロード・条件付き書き込み（`ifMatch`）・multipart、Edge Config の書き込み運用、Marketplace 統合の流れは [ストレージ・Blob・Edge Config ガイド](/blog/vercel-storage-blob-edge-config-marketplace-guide) で扱います。

---

## コスト：Active CPU 課金を理解すれば設計が変わる

Vercel Functions の課金は **3軸**で、従来の「壁時計 GB 秒」とは別物です。

| 軸 | 課金対象 | 重要な性質 |
|---|---|---|
| **Active CPU** | コードが**実際に CPU を使った時間** | DB クエリや AI 呼び出しの **I/O 待ちは課金されない**（CPU 課金が一時停止） |
| **Provisioned Memory** | 割り当てメモリ × インスタンス稼働時間（GB-hr） | I/O 待ち中も課金継続。最後の処理中リクエストが終わるまで |
| **Invocations** | 受信リクエスト数 | 成否に関わらず1件ずつ。Pro は $0.60/100万 |

Hobby は **Active CPU 4時間・メモリ 360 GB-hr・Invocations 100万/月**が無料枠。公式の計算例（サンプル）：São Paulo（CPU $0.221/h、メモリ $0.0183/GB-h）で、4GB メモリ・CPU 4秒・インスタンス生存10秒の呼び出しは——

- CPU：(4 / 3600) × $0.221 = $0.0002456
- メモリ：(4 × 10 / 3600) × $0.0183 = $0.0002033
- 合計：**$0.0004489 / 呼び出し**

> **設計が変わるポイント**：I/O 主体（AI/外部API/DB）のアプリは、Active CPU 課金と Fluid の並行性によって**従来より安くなる**ことが多い。逆に画像処理など CPU バウンドな処理は Active CPU を多く消費します。だからこそ「重い CPU 処理は関数から切り離す（ジョブ/ワークフロー化）」が効きます。

リージョン別単価（東京 `hnd1`・大阪 `kix1` は CPU $0.202/h、メモリ $0.0167/GB-h）、`maxDuration`/メモリの最適化、コスト監視は [コスト・Active CPU 最適化ガイド](/blog/vercel-cost-active-cpu-pricing-optimization-guide) で詳説します。

---

## 可観測性と回復性：本番で「追える・止まらない」状態を作る

- **Observability / Speed Insights**：関数の実行時間・エラー率・Core Web Vitals をダッシュボードで追う。Rolling Releases のカナリア比較もここで。
- **回復性**：Fluid の**クロスリージョン／AZ フェイルオーバー**（あるゾーンが落ちたら同一リージョンの別 AZ→近隣リージョンへ自動転送）と、デプロイの**Instant Rollback**が二本柱。
- **冪等性**：`waitUntil` の後処理や Webhook 受けは「少なくとも1回」を前提に**冪等**に設計する（同じイベントが二重に届いても二重課金・二重送信しない）。
- **グレースフルシャットダウン**：Fluid は終了前にシグナルを送る。処理中リクエストの完了・接続クローズを実装しておく。

これらは「決済の二重課金0件」を実現してきた設計原則と地続きです（[決済の冪等性設計](/blog/stripe-payments-production-guide-webhooks-idempotency-subscriptions)）。

---

## 2026年の新プリミティブ（知らないと損する）

Vercel は「ホスティング」を超えて、アプリの構成要素そのものを増やしています。

| プロダクト | 状態 | 何のためか |
|---|---|---|
| **AI Gateway** | GA（2025-08） | 複数 AI プロバイダへの統一API。可観測性・フォールバック・ゼロデータ保持。`"provider/model"` 文字列で切替 |
| **Workflows (WDK)** | — | 分〜月単位の耐久ワークフロー。pause/resume・リトライ・クラッシュ耐性 |
| **Queues** | パブリックベータ | at-least-once の耐久イベントストリーミング（Fluid Compute上） |
| **Sandbox** | GA（2026-01） | 信頼できないコード（AI生成等）を隔離実行する microVM |
| **BotID** | GA（2025-06） | 見えない CAPTCHA（前述） |
| **Sign in with Vercel** | GA（2025-11） | 第三者アプリ向け OAuth プロバイダ |
| **Vercel Agent** | パブリックベータ | AI コードレビュー・本番障害調査 |

AI 機能を作るなら、プロバイダ専用 SDK を直に叩く前に **AI Gateway 経由の `"provider/model"`** を既定に検討してください（[Vercel AI SDK の本番実装](/blog/vercel-ai-sdk-production-llm-apps-streaming-tools-rag)）。

---

## 本番リリース前チェックリスト

実際に私が新規 Vercel プロジェクトを本番に出すとき確認している項目です。

- [ ] **Fluid Compute が有効**で、グローバル状態にリクエスト固有データを置いていない
- [ ] 関数の `maxDuration` とメモリを**用途に合わせて明示**（既定の300秒を放置しない）
- [ ] 長時間/重 CPU 処理は関数から**Workflows/Queues/ジョブへ分離**
- [ ] キャッシュ戦略を**4層から選択**（静的/ISR/CDN/Runtime）し、`x-vercel-cache` で HIT を確認
- [ ] **プレビュー→Promote→（Rolling Releases）→必要なら Instant Rollback** の手順が確立
- [ ] Rolling Releases を使うなら **Skew Protection を有効化**
- [ ] **WAF / BotID** で高価値ルートを保護、DDoS 緩和は自動で効いている
- [ ] 秘密は環境変数、`NEXT_PUBLIC_` に**機密を載せていない**、外部クラウドは OIDC 鍵レス
- [ ] ストレージを用途で選択（Blob / Edge Config / Marketplace）
- [ ] **Active CPU 課金**前提でコスト試算、Observability で実値を監視
- [ ] Webhook/後処理は**冪等**、グレースフルシャットダウンを実装

---

## まとめ：Vercel を「基盤」として設計する

2026年の Vercel は、フロントエンドの置き場所ではなく、**コンピュート・データ・配信・セキュリティを束ねたフルコンピュート基盤**です。本番品質は「デプロイできた」ではなく、

- **Fluid Compute** の並行性とエラー隔離を理解し、グローバル状態を汚さない
- **4層キャッシュ**を要件で選ぶ
- **プレビュー／Promote／Instant Rollback／Rolling Releases** で安全に出す
- **WAF/BotID** で入口を守り、秘密と実行境界を分ける
- **Active CPU 課金**を前提にコストとアーキテクチャを設計する

——この5点を最初から織り込めるかで決まります。各テーマの実コードは本クラスタの個別記事に揃えました。まずは自分のプロジェクトの「キャッシュ層」と「課金軸」を1つずつ確認することから始めてください。

> この記事は [Vercel 公式ドキュメント](https://vercel.com/docs)（Fluid Compute / Functions / ISR / CDN Cache / Rolling Releases / WAF / BotID / Blob / Edge Config、2026年6月時点）に基づき、実運用の判断軸を加えて再構成したものです。仕様・価格は更新されるため、本番採用時は各公式ページで最新値をご確認ください。