Fluid Compute は何を解決したか
- 年に GA した Vercel Fluid Compute は、従来「Serverless Functions」と「Edge Functions」に分かれていたランタイムを統合した新世代の実行基盤である。従来の serverless は「1 リクエスト = 1 コンテナ」の idle 課金が重く、Edge Functions は 50MB のコードサイズ上限と Node.js 互換性の制約が重かった。Fluid Compute は単一のインスタンスが複数リクエストを並行処理する「multi-tenant concurrency」モデルを採用し、I/O 待ち時間を課金対象から外す。結果として、DB コネクションを維持しつつエッジに近いレイテンシを得られる、という従来トレードオフだった特性が両立する。
- 年4月時点では、next.config.ts の runtime オプションは "nodejs" / "edge" / "fluid" の3択になっている。Next.js 16 のデフォルトは "fluid" で、/app 配下のルートは明示的に export const runtime = "edge" を書かない限り Fluid 上で動く。Edge Functions は WebSocket 終端や極小レイテンシ API に用途が狭まり、従来「エッジか Lambda か」という選定議論は「Fluid で十分か、Edge が必要か」にシフトした。
Next.js 16 の RSC エッジレンダリング
Next.js 16 は React Server Components（RSC）のストリーミング出力を PoP で生成できるようになった。具体的には、Suspense 境界ごとに HTML と RSC payload を非同期 flush し、TTFB を 40ms 前後まで短縮する。重要なのはデータフェッチの配置である。RSC はサーバー側で完結する fetch を書けるが、オリジン DB への直結は避け、Vercel Data Cache（旧 Request Memoization）か Hyperdrive / PlanetScale Boost などのエッジキャッシュ層を挟むのが鉄則となる。
Edge Runtime 上で動く RSC には制約がある。Node.js の fs / net / child_process は使えず、暗号化は Web Crypto API 経由となる。2025年末に追加された edge-compatible adapter により、Prisma 6 と Drizzle ORM はそのまま動くが、Sequelize や TypeORM は Fluid 推奨のままだ。「RSC は Edge、DB 書き込みは Fluid」と役割分担するアーキテクチャが2026年の標準解である。
```typescript // app/products/[id]/page.tsx export const runtime = "edge"; export const revalidate = 60; export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) { const { id } = await params; const product = await fetch(`${process.env.EDGE_API}/products/${id}`, { next: { revalidate: 60, tags: [`product-${id}`] }, }).then((r) => r.json()); return ( <> <ProductHeader product={product} /> <Suspense fallback={<ReviewsSkeleton />}> <ProductReviews id={id} /> </Suspense> </> ); } ```
Streaming SSR と Partial Prerendering（PPR）
PPR は Next.js 14 で実験導入、15 で stable 化、16 でデフォルト有効になった機能で、「静的シェル + 動的穴埋め」をビルド時と実行時のハイブリッドで配信する。ビルド時に生成した HTML の骨組みを PoP から即座に返しつつ、ユーザー固有部分（カートアイコン、おすすめ商品）を Suspense 境界として残し、サーバーから追って flush する。これにより CDN ヒット率を維持しつつパーソナライズを両立できる。
実装上の落とし穴は「cookies() や headers() を参照した瞬間、そのツリー全体が動的になる」点である。不用意にレイアウトで headers() を呼ぶと、PPR の静的シェルが生成されなくなり、毎回フル SSR に格下げされる。next build の出力ログで「Static (prerendered)」と「Dynamic (on-demand)」の比率を定期監査し、静的率が落ちていないかを CI で検知すべきだ。
Edge Config と CDN-Backed Feature Flag
Edge Config は Vercel が提供する「読み取り最適化の JSON ストア」で、Edge Runtime から 1ms 未満で読める。LaunchDarkly や Statsig のような SaaS を使わず、内製の feature flag 基盤を Edge Config + Vercel Flags SDK で構築するのが2026年の現実解となっている。書き込みは管理 API 経由で数秒以内に全リージョン伝播、読み取りはランタイムの Isolate 内に埋め込まれるためネットワーク RTT が発生しない。
Flags SDK は A/B テストとフラグ評価を同じ API で扱い、RSC とクライアントコンポーネントで identity を一致させる。具体的には、middleware でユーザー ID を cookie に固定し、RSC 内で flag("new-checkout").bucket(userId) を評価、結果を searchParams として子コンポーネントに伝搬する。これにより「初回アクセス時にサーバー側で決定した variant が、遷移後も維持される」という SPA ライクな体験が、エッジ完結で実現する。
```typescript import { flag } from "@vercel/flags/next"; import { get } from "@vercel/edge-config"; export const newCheckout = flag<boolean>({ key: "new-checkout", async decide({ entities }) { const config = await get<{ rollout: number }>("new-checkout"); const userId = entities?.user?.id ?? "anon"; return hash(userId) % 100 < (config?.rollout ?? 0); }, }); ```
Edge Config のサイズ上限は 512KB / store、10 stores / project まで拡大された（2025年末）。実務的には「フラグ定義」「価格テーブル」「地域別禁止ワード」など、数秒から分オーダーの更新で十分な設定値を格納する用途が中心で、ユーザープロフィールのような高頻度更新データには向かない。それらは KV や Redis を使い分ける。
Observability と Sourcemaps
Fluid Compute は OpenTelemetry の自動計装を標準サポートし、@vercel/otel パッケージをインポートするだけで trace が Datadog / Honeycomb / Grafana Cloud に流れる。RSC の中で fetch を呼ぶと自動的に span が切られ、Web Vitals（LCP / INP / CLS）は RUM として別ストリームで吸い上げられる。2026年からは Vercel Observability Plus により、本番 sourcemap を安全にアップロードしてスタックトレースを TypeScript 行番号で解決できる。
エラー予算の運用は Vercel Monitoring のクエリ言語（VQL）で SLO を定義し、Slack / PagerDuty に burn rate alert を流すのが定番である。Edge Functions の p99 レイテンシ、Fluid の concurrent invocations、Data Cache のヒット率を同一ダッシュボードで並べると、PPR の静的率低下やキャッシュミスの増加を早期検知できる。エッジの勝負は「速さ」だけでなく「速さが変わらないこと」である。