|
| 1 | +--- |
| 2 | +source-updated-at: 2025-05-29T18:05:49.000Z |
| 3 | +translation-updated-at: 2025-06-03T22:46:51.057Z |
| 4 | +title: Next.js におけるコンポーザブルなキャッシュ |
| 5 | +description: キャッシュ機能 'use cache' の API 設計と利点について学びます |
| 6 | +author: |
| 7 | + - name: Lee Robinson |
| 8 | + image: /static/team/lee.jpg |
| 9 | +date: 2025-01-03T14:00:00.507Z |
| 10 | +image: >- |
| 11 | + https://h8DxKfmAPhn8O0p3.public.blob.vercel-storage.com/static/blog/composable-caching/twitter-card.png |
| 12 | +--- |
| 13 | + |
| 14 | +Next.js 向けにシンプルで強力なキャッシュモデルの開発を進めています。前回の投稿では、[キャッシュとの歩み](/blog/our-journey-with-caching)と `'use cache'` ディレクティブに至った経緯についてお話ししました。 |
| 15 | + |
| 16 | +この投稿では、`'use cache'` の API 設計と利点について説明します。 |
| 17 | + |
| 18 | +[`'use cache'` とは？](#what-is-use-cache) |
| 19 | +-------------------------------------------- |
| 20 | + |
| 21 | +`'use cache'` は、必要に応じてデータやコンポーネントをキャッシュすることでアプリケーションを高速化します。 |
| 22 | + |
| 23 | +これは JavaScript の「ディレクティブ」—コードに追加する文字列リテラル—であり、Next.js コンパイラに異なる「境界」に入ることを伝えます。例えば、サーバーからクライアントへの移行などです。 |
| 24 | + |
| 25 | +これは React の `'use client'` や `'use server'` といったディレクティブと同様の考え方です。ディレクティブはコードの実行場所を定義するコンパイラ指示であり、フレームワークが個々の要素を最適化・調整できるようにします。 |
| 26 | + |
| 27 | +[動作原理](#how-does-it-work) |
| 28 | +-------------------------------------- |
| 29 | + |
| 30 | +簡単な例から見ていきましょう: |
| 31 | + |
| 32 | +``` |
| 33 | +async function getUser(id) { |
| 34 | + 'use cache'; |
| 35 | + let res = await fetch(`https://api.vercel.app/user/${id}`); |
| 36 | + return res.json(); |
| 37 | +} |
| 38 | +``` |
| 39 | + |
| 40 | +内部的には、Next.js は `'use cache'` ディレクティブによりこのコードをサーバー関数に変換します。コンパイル時に、このキャッシュエントリの「依存関係」が検出され、キャッシュキーの一部として使用されます。 |
| 41 | + |
| 42 | +例えば、`id` はキャッシュキーの一部になります。`getUser(1)` を複数回呼び出すと、キャッシュされたサーバー関数からメモ化された出力が返されます。この値を変更すると、キャッシュに新しいエントリが作成されます。 |
| 43 | + |
| 44 | +[クロージャ](https://v0.dev/chat/5kD47RIecQK?b=b_rCP4CvfbFFW)を使用したサーバーコンポーネントでのキャッシュ関数の使用例を見てみましょう。 |
| 45 | + |
| 46 | +``` |
| 47 | +function Profile({ id }) { |
| 48 | + async function getNotifications(index, limit) { |
| 49 | + 'use cache'; |
| 50 | + return await db |
| 51 | + .select() |
| 52 | + .from(notifications) |
| 53 | + .limit(limit) |
| 54 | + .offset(index) |
| 55 | + .where(eq(notifications.userId, id)); |
| 56 | + } |
| 57 | + |
| 58 | + return <User notifications={getNotifications} />; |
| 59 | +} |
| 60 | +``` |
| 61 | + |
| 62 | +この例はより複雑です。キャッシュキーの一部となるべきすべての依存関係を見つけられますか？ |
| 63 | + |
| 64 | +引数 `index` と `limit` は理解しやすい—これらの値が変更されると、通知の異なるスライスを選択します。しかし、ユーザー `id` はどうでしょうか？その値は親コンポーネントから来ています。 |
| 65 | + |
| 66 | +コンパイラは `getNotifications` が `id` にも依存していることを理解でき、その値は自動的にキャッシュキーに含まれます。これにより、キャッシュキーにおける依存関係の不足や誤りによるキャッシュ問題の全カテゴリを防ぎます。 |
| 67 | + |
| 68 | +[キャッシュ関数を使用しない理由](#why-not-use-a-cache-function) |
| 69 | +-------------------------------------------------------------- |
| 70 | + |
| 71 | +前の例を再考しましょう。ディレクティブの代わりに `cache()` 関数を使用できないでしょうか？ |
| 72 | + |
| 73 | +``` |
| 74 | +function Profile({ id }) { |
| 75 | + async function getNotifications(index, limit) { |
| 76 | + return await cache(async () => { |
| 77 | + return await db |
| 78 | + .select() |
| 79 | + .from(notifications) |
| 80 | + .limit(limit) |
| 81 | + .offset(index) |
| 82 | + // おっと！ id をキャッシュキーに含める場所は？ |
| 83 | + .where(eq(notifications.userId, id)); |
| 84 | + }); |
| 85 | + } |
| 86 | + |
| 87 | + return <User notifications={getNotifications} />; |
| 88 | +} |
| 89 | +``` |
| 90 | + |
| 91 | +`cache()` 関数はクロージャを調べて `id` の値をキャッシュキーの一部にすべきか判断できません。手動で `id` をキーの一部として指定する必要があります。これを忘れたり、誤ったりすると、キャッシュの衝突や古いデータのリスクが生じます。 |
| 92 | + |
| 93 | +クロージャはあらゆる種類のローカル変数を捕捉できます。単純なアプローチでは、意図しない変数が誤って含まれたり（または除外されたり）する可能性があります。これにより、誤ったデータがキャッシュされたり、機密情報がキャッシュキーに漏洩してキャッシュ汚染のリスクが生じたりする可能性があります。 |
| 94 | + |
| 95 | +`'use cache'` はコンパイラにクロージャを安全に扱い、キャッシュキーを正しく生成するための十分なコンテキストを提供します。`cache()` のようなランタイムのみのソリューションでは、すべてを手動で行う必要があり、ミスを犯しやすくなります。対照的に、ディレクティブは静的に分析でき、すべての依存関係を確実に処理できます。 |
| 96 | + |
| 97 | +[シリアライズ不可能な入力値の扱い](#how-are-non-serialized-input-values-handled) |
| 98 | +-------------------------------------------------------------------------------------------- |
| 99 | + |
| 100 | +キャッシュする入力値には2種類あります: |
| 101 | + |
| 102 | +* **シリアライズ可能**: ここで「シリアライズ可能」とは、意味を失うことなく安定した文字列ベースの形式に変換できる入力を指します。多くの人が最初に `JSON.stringify` を思い浮かべますが、実際には React のシリアライゼーション（例えばサーバーコンポーネント経由）を使用して、プロミス、循環データ構造、その他の複雑なオブジェクトなど、より広範な入力を処理します。これはプレーンな JSON ができることを超えています。 |
| 103 | +* **シリアライズ不可能**: これらの入力はキャッシュキーの一部ではありません。これらの値をキャッシュしようとすると、サーバー「参照」を返します。この参照は Next.js によってランタイム時に元の値に復元されます。 |
| 104 | + |
| 105 | +`id` をキャッシュキーに含めることを覚えていたとしましょう: |
| 106 | + |
| 107 | +``` |
| 108 | +await cache(async () => { |
| 109 | + return await db |
| 110 | + .select() |
| 111 | + .from(notifications) |
| 112 | + .limit(limit) |
| 113 | + .offset(index) |
| 114 | + .where(eq(notifications.userId, id)); |
| 115 | +}, [id, index, limit]); |
| 116 | +``` |
| 117 | + |
| 118 | +これは入力値がシリアライズ可能な場合に機能します。しかし、`id` が React 要素やより複雑な値であった場合、入力キーを手動でシリアライズする必要があります。`id` プロップに基づいて現在のユーザーを取得するサーバーコンポーネントを考えてみましょう: |
| 119 | + |
| 120 | +``` |
| 121 | +async function Profile({ id, children }) { |
| 122 | + 'use cache'; |
| 123 | + const user = await getUser(id); |
| 124 | + |
| 125 | + return ( |
| 126 | + <> |
| 127 | + <h1>{user.name}</h1> |
| 128 | + {/* children を変更してもキャッシュが壊れない...なぜ？ */} |
| 129 | + {children} |
| 130 | + </> |
| 131 | + ); |
| 132 | +} |
| 133 | +``` |
| 134 | + |
| 135 | +この動作を順を追って説明します: |
| 136 | + |
| 137 | +1. コンパイル中、Next.js は `'use cache'` ディレクティブを認識し、キャッシュをサポートする特別なサーバー関数を作成するためにコードを変換します。コンパイル時にキャッシュが行われるわけではなく、Next.js はランタイムキャッシュに必要なメカニズムを設定しています。 |
| 138 | +2. コードが「キャッシュ関数」を呼び出すと、Next.js は関数の引数をシリアライズします。JSX のように直接シリアライズできないものは、「参照」プレースホルダーに置き換えられます。 |
| 139 | +3. Next.js は指定されたシリアライズされた引数に対してキャッシュされた結果が存在するかチェックします。結果が見つからない場合、関数はキャッシュする新しい値を計算します。 |
| 140 | +4. 関数が終了すると、戻り値がシリアライズされます。戻り値のシリアライズ不可能な部分は参照に戻されます。 |
| 141 | +5. キャッシュ関数を呼び出したコードは出力をデシリアライズし、参照を評価します。これにより、Next.js は参照を実際のオブジェクトや値と交換でき、`children` のようなシリアライズ不可能な入力は元の、キャッシュされていない値を保持できます。 |
| 142 | + |
| 143 | +これは、`<Profile>` コンポーネントだけを安全にキャッシュし、子をキャッシュしないことを意味します。後続のレンダリングでは、`getUser()` は再度呼び出されません。`children` の値は動的であるか、異なるキャッシュ寿命を持つ別個にキャッシュされた要素である可能性があります。これがコンポーザブルなキャッシュです。 |
| 144 | + |
| 145 | +[これは見覚えが...](#this-seems-familiar) |
| 146 | +-------------------------------------------- |
| 147 | + |
| 148 | +「サーバーとクライアントのコンポジションと同じモデルのように感じる」と思ったなら、まったく正しいです。これは時々「ドーナツ」パターンと呼ばれます: |
| 149 | + |
| 150 | +* **外側**の部分はデータ取得や重いロジックを処理するサーバーコンポーネント |
| 151 | +* 中央の**穴**はインタラクティブ性を持つ可能性のある子コンポーネント |
| 152 | + |
| 153 | +```tsx filename="app/page.tsx" |
| 154 | +export default function Page() { |
| 155 | + return ( |
| 156 | + <ServerComponent> |
| 157 | + {/* クライアントへの穴を作成 */} |
| 158 | + <ClientComponent /> |
| 159 | + <ServerComponent /> |
| 160 | + ); |
| 161 | +} |
| 162 | +``` |
| 163 | + |
| 164 | +`'use cache'` も同じです。ドーナツは外側のコンポーネントのキャッシュされた値で、穴はランタイム時に埋められる参照です。これが `children` を変更してもキャッシュされた出力全体が無効化されない理由です。子は後で埋められる単なる参照です。 |
| 165 | + |
| 166 | +[タグ付けと無効化については？](#what-about-tagging-and-invalidation) |
| 167 | +---------------------------------------------------------------------------- |
| 168 | + |
| 169 | +キャッシュの寿命はさまざまな[プロファイル](/docs/app/api-reference/functions/cacheLife)で定義できます。デフォルトのプロファイルセットが含まれていますが、必要に応じてカスタム値を定義できます。 |
| 170 | + |
| 171 | +``` |
| 172 | +async function getUser(id) { |
| 173 | + 'use cache'; |
| 174 | + cacheLife('hours'); |
| 175 | + let res = await fetch(`https://api.vercel.app/user/${id}`); |
| 176 | + return res.json(); |
| 177 | +} |
| 178 | +``` |
| 179 | + |
| 180 | +特定のキャッシュエントリを無効化するには、[キャッシュにタグを付け](/docs/app/api-reference/functions/cacheTag)、`revalidateTag()` を呼び出します。強力なパターンの1つは、データ（例えば CMS から）を取得した後にキャッシュにタグを付けられることです: |
| 181 | + |
| 182 | +``` |
| 183 | +async function getPost(postId) { |
| 184 | + 'use cache'; |
| 185 | + let res = await fetch(`https://api.vercel.app/blog/${postId}`); |
| 186 | + let data = await res.json(); |
| 187 | + cacheTag(postId, data.authorId); |
| 188 | + return data; |
| 189 | +} |
| 190 | +``` |
| 191 | + |
| 192 | +[シンプルで強力](#simple-and-powerful) |
| 193 | +------------------------------------------- |
| 194 | + |
| 195 | +`'use cache'` の目標は、キャッシュロジックの作成をシンプルかつ強力にすることです。 |
| 196 | + |
| 197 | +* **シンプル**: ローカルな推論でキャッシュエントリを作成できます。キャッシュキーエントリの忘却やコードベースの他の部分への意図しない変更といったグローバルな副作用を心配する必要はありません。 |
| 198 | +* **強力**: 静的に分析可能なコードだけでなく、より多くのものをキャッシュできます。例えば、ランタイム時に変更される可能性がある値でも、評価後の出力結果をキャッシュしたい場合があります。 |
| 199 | + |
| 200 | +`'use cache` は Next.js 内部ではまだ**実験的**です。テストする際の早期フィードバックをお待ちしています。 |
| 201 | + |
| 202 | +[ドキュメントで詳細を確認](/docs/app/api-reference/directives/use-cache)。 |
0 commit comments