Next.js の use cache でユーザーごとのデータを混ぜない。キャッシュの境界の決め方と、セキュリティリリースの見方

2026年11月3日のセキュリティリリースで直ったこと

公式ブログ「November 2026 Security Release」に載っている7件です。深刻度はブログの表記です（1件目は GitHub のアドバイザリでは Moderate と書かれています）。

表の条件は要約です。詳しい条件は、各アドバイザリ（参考に載せたもの、またはブログからのリンク）で確かめてください。

修正版は 16.4.5（Active LTS）と 15.5.29（Maintenance LTS）です。2026年11月10日時点の npm の latest は 16.4.6 です。15 系へのセキュリティ修正は、公式のサポート方針で2027年1月31日までと書かれています。

1〜4 は Cache Components を使っているときの話です。4 については、アドバイザリに next.config で partialPrefetching: true にする回避策が書かれています。

まず影響を見て、上げる

セキュリティリリースが出たときの手順は、今回に限らず同じです。

1. 使っている版を確かめる。 package.json の範囲指定ではなく、実際に入っている版を見ます。

   npm ls next
   

2. 条件を読む。 上の表の「主な条件」と、自分のプロジェクトの設定（cacheComponents、partialPrefetching、セルフホストかどうか、Edge のルートの有無）を照らします。当てはまらなくても、上げない理由にはしません。条件の読み違いは起きるからです。
3. 修正版以降に上げる。

   # 16 系
   npm install [email protected]   # 16.4.5 以降（2026年11月10日時点の latest は 16.4.6）
   # 15 系
   npm install [email protected]
   

4. 確かめる。 next build が通ること、会員ページを2つの別のアカウントで開いて、相手の情報が出ないことを見ます。CDN を前に置いているなら、CDN のキャッシュも消しておきます。

use cache は「全員で共有する箱」

境界を考える前提として、use cache の箱がどう分かれるかを押さえておきます。公式ドキュメントでは、キャッシュのキーは入力をシリアライズしたものから作られ、次のものが入ります。

• ビルドの ID
• 関数の ID
• シリアライズできる引数
• 外側のスコープから使った変数（自動で引数として扱われ、キーに入る）

root param（[lang] のようなルートの動的な部分）は、関数の中で実際に読んだものだけがキーに入ります。

裏を返すと、キーに入っていない違いは、同じ箱に入ります。 ユーザー A と B で中身が違うのに、キーに違いがなければ、A の結果が B に返ります。今回の1〜3は、キーの作り方の側の不具合でしたが、同じことはアプリの書き方でも起こせてしまいます。

また、use cache の中では cookies()・headers()・searchParams を読めません。呼び出した先の関数でも同じです。リクエストごとに違う値を箱の中でこっそり読めないようにして、違いを必ず引数（＝キー）に出させるための決まりだと考えると、設計の筋が見えてきます。

境界の決め方：use cache／private／remote の使い分け

use cache を書く前に、関数ごとに次の順で決めます。

公式ドキュメントでも、ユーザー固有のデータには 'use cache: remote' ではなく 'use cache: private' を使うよう書かれています。remote は全員で共有する箱です。また公式では、private はコンプライアンス上の要件があるときや、引数で渡す形に直せないときに使う、まれな例外とされています。まずは2の形を考えます。

迷ったときは「この関数の結果を、別の人に見せても困らないか」を問います。困るなら、ユーザーを区別する値がキーに入っているか、private か、キャッシュしないかのどれかです。

コード：cookies() は外で読み、引数で渡す

Next.js 16.4.6、React 19.3.1、Node.js 22 で確かめたコードです。next.config.ts で Cache Components を有効にします。

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
}

export default nextConfig

会員ページです。cookies() はキャッシュの外のコンポーネントで読み、ユーザー ID を引数で渡します。

// app/account/page.tsx
import { Suspense } from 'react'
import { cookies } from 'next/headers'
import { cacheLife, cacheTag } from 'next/cache'

// 引数の userId がキャッシュのキーに入る
async function getPoints(userId: string) {
  'use cache'
  cacheLife('minutes')
  cacheTag(`points-${userId}`)
  return { userId, points: userId.length * 10 } // 例：本当は DB から読む
}

async function Points() {
  // 例として生のクッキーを使う。本番ではセッションを検証して得た ID を渡す
  const userId = (await cookies()).get('uid')?.value
  if (!userId) return <p>ログインしてください</p>
  const { points } = await getPoints(userId)
  return <p>{userId} さんのポイント：{points}</p>
}

export default function AccountPage() {
  return (
    <main>
      <h1>マイページ</h1>
      <Suspense fallback={<p>読み込み中</p>}>
        <Points />
      </Suspense>
    </main>
  )
}

next start で、クッキー uid=alice と uid=bob で開くと、それぞれ自分のポイントが返りました。use cache の関数の中で cookies() を読むように書き換えると、エラーになります。静的に組めるルートでは next build が止まり、この会員ページのように動的なルートでは、build は通って next start でリクエストしたときにエラーが出ます。手元で静的なルートで試したときは、build が次のエラーで止まりました。

Error: Route "/bad": `cookies()` can't be read inside `"use cache"`. Read it outside the cached function and pass what you need as an argument.

どうしてもクッキーの中身を関数の中で使う必要があるときは 'use cache: private' にします。こちらは中で cookies() を読めて、alice と bob でそれぞれの結果が返ることを確かめました。

async function getGreeting() {
  'use cache: private'
  cacheLife({ stale: 60 })
  const userId = (await cookies()).get('uid')?.value ?? 'guest'
  return `${userId} さん、こんにちは`
}

private は、リンクごとの先読みを効かせるには stale を30秒以上にする必要があります（公式ドキュメントより）。

あわせて守っておきたいことが2つあります。

• ユーザーを区別する値は、文字列か数値で渡す。 今回の3はバイナリの引数の識別子が重なる不具合でした。ID は素直な値で渡すほうが、キーの中身を人が確かめやすくなります。
• unstable_cache の中から use cache の関数を呼ばない。 今回の1の条件で、アドバイザリでは、この入れ子をやめることが回避策として書かれています。移行は関数ごとに切り替えます。

CDN の前に置くとき：Cache-Control と Vary

動的なページの応答には、Next.js が Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate を付けます。手元で確かめた会員ページの応答も、この値でした。CDN の設定でこれを上書きして「全部キャッシュ」にすると、アプリ側でどれだけ境界を守っても崩れます。

もうひとつは Vary です。Next.js は rsc、next-router-state-tree、next-router-prefetch、next-router-segment-prefetch（インターセプトするルートでは next-url も）を Vary に入れます。Vary に対応していない CDN のために _rsc というクエリが付くので、_rsc はキャッシュのキーに含めます（公式の「Using a CDN with Next.js」より）。

公開前のチェックリスト

• npm ls next で、修正版（16.4.5／15.5.29）以降が入っている
• use cache の関数ごとに「別の人に見せても困らないか」を答えられる
• ユーザーごとの関数は、ユーザー ID を文字列の引数で受け取るか、private になっている
• use cache: remote にユーザー固有のデータを入れていない
• unstable_cache の中から use cache の関数を呼んでいない
• セルフホストなら partialPrefetching を明示している
• CDN で Cache-Control を上書きしていない、_rsc をキーに入れている
• 2つのアカウントで会員ページを開き、相手の情報が出ない

キャッシュの境界は、レビューで「この関数の結果を誰に見せてよいか」を1行コメントで残しておくと、次に触る人も迷いません。MODS BASE でも、会員機能のあるサイトの設計や見直しをお手伝いしています。

参考

• November 2026 Security Release（Next.js）
• Information disclosure across root params in Next.js when a 'use cache' function is called through unstable_cache()（GitHub）
• Cache poisoning of shared fallback shells in Cache Components via request-supplied placeholder route params（GitHub）
• use cache（Next.js Docs）
• use cache: private（Next.js Docs）
• use cache: remote（Next.js Docs）
• cacheComponents（Next.js Docs）
• Using a CDN with Next.js（Next.js Docs）
• Support Policy（Next.js）