Next.js 16の`use cache: private`で個人情報がブラウザに残る罠と対策

• 事実と背景：Next.js 16の`use cache: private`は、特定条件下でブラウザメモリにキャッシュが残留する挙動が判明。
• 技術的変革：Partial Prefetching有効かつstale timeが5分以上の場合、App Shellにキャッシュが組み込まれブラウザに保持される。
• 現場への影響：Route HandlerやJSでCookieを削除してもキャッシュが残るため、ログアウト時は画面の強制リロード等の対策が必須。

「サーバーキャッシュには保存されない」――このドキュメントの一文を鵜呑みにし、我々エンジニアはどれほど安易にセキュリティの安全神話を信じ込んでしまうのだろうか。Next.js 16で導入されたuse cache: privateディレクティブは、cookies()などのリクエスト固有の値を読み込む関数の結果をキャッシュするための強力な機能だ。開発者ドキュメントには、本番環境において同一リクエスト内での呼び出しは再利用されるが、リクエストをまたいでサーバーキャッシュに保存されることはないと明記されている。これだけを読めば、マルチテナントなWebアプリケーションにおいて、あるユーザーのプライベートなセッションデータが他者に漏洩するリスクはサーバーサイドにおいては排除されているように思える。

しかし、ここにフロントエンド開発における巨大な落とし穴、すなわち「クライアントサイドのブラックボックス」が潜んでいる。深夜の障害対応で「サーバーのキャッシュは完全にクリアしたはずなのに、なぜか特定のブラウザで古いユーザーの画面が表示され続けている」という、背筋が凍るようなバグに直面した経験はないだろうか。Next.jsのクライアントルーターは、我々開発者のあずかり知らぬところで、レンダリング結果をブラウザのメモリ上にキャッシュ（ルーターキャッシュ）しているのだ。ドキュメントの行間を注意深く読み解くと、cacheLifeで設定されたstale time（有効期限）の間、レンダリング出力がブラウザメモリに保持され得ることが示唆されている。これは、同一ブラウザを操作する限り、リクエスト間をまたいでキャッシュが使い回される「ゴーストデータ」の発生を意味している。

では、このブラウザキャッシュはどのような条件下で牙をむくのだろうか。検証の結果、単にコンポーネントキャッシュを有効化（cacheComponents: true）しただけでは、ページ遷移のたびにサーバーへデータを取りに行くため、ブラウザにキャッシュは残らない。しかし、Next.jsのパフォーマンス最適化の目玉である「Partial Prefetching（部分的プリフェッチ）」を有効にした瞬間、挙動は一変する。Partial Prefetchingを有効にすると、ルーターは各ルートの「App Shell（アプリケーションの骨格）」を事前に取得する。そして、このApp Shellには、静的コンテンツだけでなく、cookies()やheaders()に由来するセッションデータも含まれてしまうのだ。

さらに厄介なのが、キャッシュの有効期限（stale time）の閾値である。Next.jsの仕様上、stale timeが「5分（300秒）以上」に設定されているキャッシュデータは、App Shellの一部としてブラウザに再利用される仕組みになっている。実際にcacheLife({ stale: 300 })として検証した結果、同一パスへの2回目以降の遷移では、サーバーへのリクエストは発生せず、ブラウザに残留した古いキャッシュがそのまま画面に描画された。以下に、検証における画面遷移とキャッシュ生成時刻の推移をまとめる。

この挙動は、パフォーマンス向上という観点では極めて合理的だが、セキュリティの観点からは「一度表示した個人情報が、ブラウザのメモリ上に最大5分間、無防備に漂い続ける」というデッドロック状態を意味している。

この問題が最も深刻化するのは、ユーザーが「ログアウト」した瞬間だ。一般的なWebアプリケーションでは、ログアウト処理時にCookieを削除し、セッションを無効化する。しかし、use cache: privateによってブラウザメモリに焼き付けられたキャッシュは、Cookieの削除に対してどのように振る舞うのだろうか。検証では、Cookieを削除する3つのアプローチ（Server Action、Route Handler、クライアントサイドJS）において、驚くべき挙動の差異が明らかになった。

React Server Functionを<form>のsubmit経由で呼び出す「Server Action」を用いてCookieを削除した場合、Next.jsはサーバー側で現在のページとレイアウトを再レンダリングし、最新のUI状態を単一のラウンドトリップでクライアントに返却する。そのため、古いキャッシュは即座に破棄され、画面は正常に更新される。しかし、ボタンクリック時のfetchイベント等で「Route Handler」を叩いてCookieを消去したり、クライアントサイドで直接document.cookieを操作して削除した場合、Next.jsのルーターはCookieの消失を検知できない。結果として、Cookieが消滅しているにもかかわらず、ブラウザのメモリに残った「ログイン状態のUIキャッシュ」がそのまま表示され続けるという、極めて危険な状態が発生する。この状態で別のユーザーが同じブラウザを操作すれば、前者の個人情報が丸見えになってしまうのだ。

この「消えないキャッシュ」というセキュリティリスクに対し、我々フロントエンドエンジニアが明日から実務で導入すべき具体的な処方箋は明確だ。Route HandlerやクライアントサイドのJavaScriptでログアウト処理やセッション破棄を行う場合、単にCookieを消すだけで処理を終えてはならない。処理の直後にrouter.refresh()を明示的に呼び出してルーターキャッシュを強制的にパージするか、あるいは最も確実な方法として、ログアウト完了後にwindow.location.href = "/login"を実行し、ブラウザのページ全体をハードリロード（再読み込み）させるべきである。これにより、メモリ上に蓄積されたNext.jsのルーターキャッシュは完全に揮発し、ゴーストデータの残留を防ぐことができる。

しかし、ここで我々が真に思考すべきは、個別具体的なワークアラウンドの導入だけではない。現代のフロントエンドフレームワークは、パフォーマンス最適化のために「サーバーとクライアントの境界」を極限まで曖昧にし、複雑なキャッシュレイヤーを何重にも重ね合わせている。我々は「便利で高速なマジック」と引き換えに、アプリケーションの決定論的な制御性を失いつつあるのではないか。フレームワークがブラックボックス化していく中で、仕様の隙間に潜むセキュリティホールを予見し、防衛的設計（Defensive Design）を貫くことこそが、今シニアエンジニアに求められる真の技術的誠実さであると私は考える。