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

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

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

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

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

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

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

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

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

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

コンピュート：既定の 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）

ポイントは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 でトグルするか、設定ファイルで宣言します。

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

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

本番設計の前提になる数値です（Functions Limits より）。

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

ランタイム・ストリーミング・waitUntil・Cron の実コードは Functions・Fluid Compute ガイド で詳説します。

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

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

ISR の要点（公式の挙動）

ISR（Incremental Static Regeneration）は stale-while-revalidate パターンです。「キャッシュ済みを即返しつつ、裏で再生成」。Vercel の CDN が乗ると、フレームワークの ISR は次の最適化を自動で得ます（ISR より）。

• 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 するだけです。

// 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 ガイド で扱います。

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

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

// 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 はカスタム）。

# プレビュー → 検証 → 本番昇格 → 問題があれば即ロールバック
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・ロールバック ガイド で詳説します。

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

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

// 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() 呼び出し。

// 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 ガイド で扱います。

秘密：環境変数と OIDC

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

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

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

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

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

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

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

// 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 ガイド で扱います。

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

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

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 最適化ガイド で詳説します。

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

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

これらは「決済の二重課金0件」を実現してきた設計原則と地続きです（決済の冪等性設計）。

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

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

AI 機能を作るなら、プロバイダ専用 SDK を直に叩く前に AI Gateway 経由の "provider/model" を既定に検討してください（Vercel AI SDK の本番実装）。

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

実際に私が新規 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 公式ドキュメント（Fluid Compute / Functions / ISR / CDN Cache / Rolling Releases / WAF / BotID / Blob / Edge Config、2026年6月時点）に基づき、実運用の判断軸を加えて再構成したものです。仕様・価格は更新されるため、本番採用時は各公式ページで最新値をご確認ください。