VercelのData CacheがRuntime Cacheへ統合 — 課金の変化と移行前に確認すべきこと
2026年10月30日、VercelはData CacheをRuntime Cacheへ統合すると発表しました。Next.jsのfetchキャッシュとunstable_cacheはコード変更なしで切り替わります。実務上のインパクトは2つです。1つはプロジェクトあたりのキャッシュ容量がPro 8倍・Enterprise 10倍に増えること。もう1つは、これまで請求対象外だったData Cacheの読み書きがRuntime Cacheの料金体系で課金されることです。Hobbyチームは2026年11月29日に移行予定、Proは個別に移行日が通知されます。つまり「何もしなくても動く」一方で、「何もしないとコストが見えないまま増える」変更です。
統合で何が1つになるのか
これまでVercel上のデータキャッシュは2系統に分かれていました。Next.jsのfetchキャッシュとunstable_cacheはData Cacheを使い、@vercel/functionsのgetCacheとNext.js 16の 'use cache: remote' はRuntime Cacheを使う、という分かれ方です。今回の統合で、この4つのAPIがすべてRuntime Cacheの上に乗ります。
Vercelが統合に動いた背景は、Data CacheがNext.js App Router向けに作られたサービスだったことにあります。Runtime CacheはgetCacheという直接的なAPIを持ち、SvelteKitやNuxt、Routing Middleware、ビルド中のCMSコンテンツ取得などフレームワークを問わず使えます。1つの製品に寄せることで、ストレージの割り当ても使用量の可視化も一箇所にまとまります。
ここで混同しやすいのがCDNキャッシュとの違いです。CDNキャッシュはHTTPレスポンス全体を保存しますが、Runtime Cacheはレスポンスを組み立てるための「データ」を保存します。商品ページを例にすると、カタログデータはRuntime Cacheから再利用しつつ、訪問者ごとにパーソナライズした出力を返す、という使い分けになります。レスポンス全体がキャッシュ可能なら、Runtime Cacheではなくキャッシュ制御ヘッダーやISRでCDNに任せるほうが、そもそも関数を動かさずに済みます。
無料だった読み書きが課金対象になる
移行後、Data Cacheの読み書きはRuntime Cacheのリージョン別料金で請求されます。読み取りは100万read unitあたり$0.40〜$0.64、書き込みは100万write unitあたり$4.00〜$6.40で、実行リージョンによって単価が変わります。
見積もりで重要なのは単位の定義です。1 read unit = 8KB、1 write unit = 8KB として換算されます。つまり課金されるのは「何回読んだか」だけでなく「何バイト読んだか」です。Vercelの最適化ガイドでも、500KBのエントリを読んで実際に使うのが2KBだけでも、全量を読んで63 read unitを消費する例が挙げられています。巨大なJSONを1エントリにまとめる設計は、読み取り回数が減ってもコストが減るとは限りません。
無料枠は、Hobbyがチーム全体で月100万read unit・20万write unit。Proは毎月$20のインフラクレジットから消費され、超過分がリージョン単価で請求されます。Enterpriseは担当チームとの個別条件です。
仕組みから来る3つの前提
コストと挙動を判断するには、Runtime Cacheの構造を押さえておく必要があります。
第一に、キャッシュはリージョン単位です。読み取りヒットは関数が動いているリージョンのキャッシュサービスへの1往復で完結します。逆にミスした場合、他リージョンにコピーがあっても参照しません。複数リージョンで実行する構成では、リージョンごとにキャッシュが温まる前提で考えます。
第二に、無効化はタグのタイムスタンプで行われます。各エントリはタグと書き込み時刻を持ち、読み取り時に同一リージョンのタグストアで無効化時刻を照合します。タグが無効化された時刻のほうが新しければ、そのエントリは古いと判定されます。この方式なら、100万件が同じタグを共有していても書き込むタイムスタンプは1つで済みます。無効化はまず受信リージョンに即時反映され、他リージョンへはグローバルな配信経路で通常数百ミリ秒で届きます。なお、タグベースの無効化呼び出しには1秒あたりのレート制限があり、Hobbyはチームあたり50回、Proは200回、Enterpriseはプロジェクトあたり500回です。超過すると429が返り、キャッシュは変更されません。
第三に、ストレージ上限に達するとLRU（最近使われていないものから削除）で追い出されます。TTLが残っていても消える可能性があるため、「必ずTTLいっぱい保持されてほしいデータ」の置き場所としては適しません。1エントリは最大2MB、タグは1エントリ128個まで、タグ長は256バイトまでという制限もあります。
性能面では、Vercelは8月に全リージョンでサーキットブレーカーを有効化したと説明しています。タグストアの応答が遅いシャードがあっても、メモリ上のタグタイムスタンプで鮮度判定を行い読み取りを進める仕組みです。最大リージョンの急激なトラフィック増時にp99の読み取りレイテンシが従来の約5分の1になった一方、このフォールバック中は無効化直後のデータが一時的に新鮮と扱われることがある、という副作用も明記されています。厳密な読み取り整合性が要る処理はキャッシュを経由させない、という判断材料になります。
移行前に実行する5つの点検
- Observabilityの Runtime Cache ビューで、現状の読み書き量・ヒット率・エントリサイズを記録する。移行後の請求と比較する基準になります。
- 1リクエスト内で同じキーを複数回読んでいないか確認する。複数のServer Componentから同じヘルパーを呼ぶ構成は、ReactのcacheでラップしたヘルパーをエクスポートしてGET重複を解消できます。
- ループ内の読み取りを洗い出す。アイテムごとにfetchやunstable_cacheを呼んでいる箇所は、まとめて使うデータを1エントリに集約できないか検討します（2MB上限の範囲で）。
- キーの粒度を見直す。リクエストごとに変わるキーは再利用されず、オリジンへのフェッチとキャッシュ書き込みを増やします。共有コンテンツはロケールなど再利用可能な値で切り、ユーザーやテナントの境界だけは崩さないようにします。
- CDNで答えられるルートを関数から外す。全訪問者に同じ出力を返す動的ルートは、プリレンダーやISRにすれば関数自体が動きません。ただしRouting MiddlewareはCDNキャッシュより前に動くため、レスポンスをキャッシュしてもミドルウェア内の読み取りは減りません。
Vercelは最適化ガイドに加えて、コーディングエージェントに貼り付けるためのプロンプトや、ダッシュボード上の「Optimize with Vercel Agent」も提供しています。既存のHobby・Proチームは10月30日からチームのCDN設定で早期オプトインでき、その時点からRuntime Cacheの料金が適用されます。同じ設定画面でfetchとunstable_cacheのキャッシュを無効化することもできますが、データソースへのリクエストが増えるだけで移行自体は止まりません。
'use cache: remote' はデプロイをまたげない点に注意
統合とは別に、Next.js 16を使うなら押さえておきたい挙動があります。Runtime Cacheのストレージはオーナー・プロジェクト・環境・キーで管理され、デプロイしても中身は消えません。しかし 'use cache: remote' のキーにはビルドIDが（deploymentId設定時はそのID）含まれるため、新しいビルドでは前のビルドのエントリを読めません。結果として、デプロイのたびにこのディレクティブ分のキャッシュは空から始まり、データソースへのアクセスが一時的に跳ねます。
デプロイをまたいで保持したいデータは、fetchのforce-cacheかunstable_cache、あるいは自分でキーを決めるgetCacheで書き込むのが現実的な選択です。Vercelのドキュメントは、これをNext.jsの意図的な設計（ビルド間で戻り値の形が変わるリスクを避けるため）としつつ、将来的に改善が検討されている現時点の挙動だと説明しています。APIを選ぶ前に、デプロイ頻度とオリジンの負荷を合わせて見積もってください。
まとめ
今回の変更でコードを書き換える必要はありません。やるべきは、移行日が来る前にObservabilityで自プロジェクトの読み書き量とエントリサイズを把握し、無駄な読み取り・過剰に細かいキー・CDNで済むルートを潰しておくことです。特にHobbyチームは2026年11月29日が目安になります。
Next.jsやVercel上のキャッシュ設計、移行に伴うコストとパフォーマンスのチューニングについて相談先をお探しでしたら、chot Inc.のお問い合わせからお気軽にご連絡ください。
