next-cache-components

next-cache-componentsスキルの概要

next-cache-componentsでできること

next-cache-componentsスキルは、エージェントに Next.js 16 の Cache Components をどう扱うかを教えるためのものです。具体的には、Partial Prerendering を有効にし、静的コンテンツ・キャッシュ対象コンテンツ・動的コンテンツを切り分け、use cache、cacheLife、cacheTag、updateTag といった API を正しく使い分ける判断を支援します。実際にやりたいことが「この Next.js ページを、全部を stale にせずに速くしたい」であれば、一般的なパフォーマンス用プロンプトより next-cache-components のほうがはるかに実用的です。

このスキルが向いている人

この next-cache-components skill が特に向いているのは、次のようなケースです。

• Next.js 16 のキャッシュ挙動への移行や、それを前提に設計を進めている Next.js チーム
• リクエストごとのフルレンダリングを減らしたい開発者
• どの route segment はキャッシュすべきで、どこは live のまま維持すべきかを切り分けたい人
• React 全般の最適化ではなく、フレームワークに即した具体的な指針が必要なエージェント

逆に、Next.js 16+ ではない環境、App Router 前提の設計を使っていない場合、あるいはフロントエンド全般の perf 改善アイデアだけが欲しい場合には、効果は限定的です。

本当に達成したい仕事

多くのユーザーが欲しいのは「Cache Components の要約」ではありません。実際に求めているのは、たとえば次のような成果です。

• 完全に dynamic な route を、static・cached・streamed の混成構成に変える
• use cache をどこに入れるべきか決める
• 妥当な cacheLife を選ぶ
• 選択的に無効化できるようにキャッシュエントリへタグを付ける
• cookies、headers、ユーザー固有 state のような本当に request に結びついたデータを壊さない

next-cache-components for Performance Optimization の価値はここにあります。キャッシュを単一のフラグ設定ではなく、route の構成設計の問題として扱えるようにしてくれます。

ありふれたプロンプトとの違い

一般的なプロンプトだと、エージェントは「重いデータをキャッシュする」「Suspense を使う」といった表面的な提案で終わりがちです。next-cache-componentsスキルは、次の点まで踏み込んで扱います。

• cacheComponents: true を有効にすること
• 1つの route 内にある 3 種類のコンテンツ
• どんな async 処理ならキャッシュできるか
• どんな request-time の値が dynamic rendering を強制するか
• 時間ベースのキャッシュだけでなく、invalidations の仕組みをどう使うか

こうした違いは重要です。Next.js でキャッシュ方針を誤ると、UX が stale になったり、パーソナライズが壊れたり、そもそも性能改善が出ないことがあります。

インストール前に知っておくべきこと

このスキルは軽量で、用途がはっきりしています。大きなツールキットではなく、実践例を中心にした単一の SKILL.md で構成されているようです。導入が速いのは利点ですが、そのぶん期待すべきなのは概念整理とコードパターンの提案であり、スクリプト、linter、移行自動化のようなものではありません。

next-cache-componentsスキルの使い方

スキルランナーにnext-cache-componentsをインストールする

Skills CLI パターンを使っている場合は、次のコマンドでインストールできます。

npx skills add https://github.com/vercel-labs/next-skills --skill next-cache-components

その後、Next.js アプリでキャッシュ設計、route の分解、invalidations の設計についてフレームワーク特化の支援が欲しいときに呼び出します。

まず読むべきファイル

最初に確認するのは次のファイルです。

• skills/next-cache-components/SKILL.md

このスキルで公開されている追加の補助フォルダは見当たらないため、価値の大半はこのファイルに集約されています。ページの書き換えをエージェントに依頼する前に目を通しておくと、例示されている設計の考え方を前提に会話できます。

自分のプロジェクトに本当に合うか確認する

next-cache-components を使う前に、次を確認してください。

• Next.js 16 を使っている、またはそれを見据えている
• App Router スタイルのコードベースで作業している
• 1つの route の中に、鮮度要件の異なるコンテンツが混在している
• どこが static、cacheable、request-bound なのかを識別できる

ページ全体がリクエストごとに完全にパーソナライズされる場合、このスキルの効果は dynamic な island の切り出し補助に留まることがあります。

最初に確認したい設定変更

このスキルは、next.config.ts で Cache Components が有効化されている前提です。

const nextConfig = {
  cacheComponents: true,
}

ここは重要です。まだ古い experimental.ppr フラグの感覚で考えているユーザーも少なくありません。アプリ側の設定が合っていないと、その後のガイダンス全体がずれてしまいます。

スキルに渡すべき入力情報

next-cache-components usage の精度を上げるには、エージェントに次の情報を渡してください。

• route または component のファイルパス
• 遅いのが build 時間なのか、request 時間なのか、hydration 中なのか
• 関係するデータソース
• 何分〜何時間 stale でも許容できるデータか
• リクエストごとに必ず live である必要があるデータか
• 書き込み後に手動 invalidation が必要か

これがないと、エージェントは抽象的なキャッシュ論しか返せません。

曖昧な目標を良いプロンプトに変える

弱いプロンプト:

Make this Next.js page faster with cache components.

より良いプロンプト:

Use the next-cache-components skill to refactor `app/blog/page.tsx`.
Posts can be 1 hour stale, author bios can be 1 day stale, but user theme and saved items must stay request-specific.
Show which components should be static, which should use `use cache`, where to add `Suspense`, and whether `cacheTag` or `updateTag` should be used after CMS updates.

これが機能する理由は次のとおりです。

• 鮮度の境界が明確になる
• ユーザー固有データが特定されている
• 単なるコード修正ではなく、設計の提案を求めている
• 過剰なキャッシュを避けるための文脈が十分にある

実務でうまく回りやすい進め方

次の順番で進めるのがおすすめです。

1. まず、route の各セクションを static・cached・dynamic のどれかに分類させる
2. そのうえで component の境界案を出させる
3. リクエスト間で再利用できるデータにだけ use cache を入れさせる
4. 許容できる stale 時間に応じて cacheLife を設定する
5. deploy 以外でも内容が更新されるなら、cacheTag と invalidation の起点を追加する
6. request-bound なコンテンツは Suspense で包み、別ストリームで流せるようにする

最初から全面的な書き換えを一発で求めるより、この流れのほうが多くの場合うまくいきます。

next-cache-componentsが整理する3種類のrouteコンテンツ

next-cache-components guide の核になるのは、次の 3 分類です。

• Static: prerender できる同期 UI と純粋な計算
• Cached: リクエストごとに fresh fetch を要せず、再利用できる async データ
• Dynamic: cookies() によるパーソナライズのような request-time の値

この分類こそが、このスキルでもっとも価値の高い部分です。ページ全体を1つの戦略でラベル付けしようとしてしまうことが、キャッシュ設計の失敗につながりがちです。

use cache を置くべき場所

実際には、use cache は次のようなケースで特に有効です。

• CMS やデータベースから取得するコンテンツ一覧
• 更新タイミングがある程度読める product/category データ
• 安定したデータに支えられた共有レイアウト断片
• ユーザー固有ではない、重い async 処理の結果

ただし、これを一律に付ける decorator のように扱ってはいけません。関数が request state、session、高頻度で変わる値に依存しているなら、キャッシュは不正確になります。

キャッシュを強めるよりSuspenseを使うべきとき

よくある失敗は、すべてを無理にキャッシュで解決しようとすることです。このスキルは、一部のデータは dynamic のまま保ち、別ストリームで返すべきだとはっきり示しています。リクエストごとに fresh である必要はあるが、route 全体を待たせたくない場合は Suspense を使います。これは、設定、認証依存 UI、位置情報や session に応じて変わるコンテンツで特に有効です。

invalidationは意図して設計する

cacheLife による時間ベースの鮮度管理は、話の半分にすぎません。管理画面の操作、webhook、書き込み処理などでコンテンツが変化するなら、TTL が切れるまで待つのではなく、cacheTag と updateTag を前提にページ更新を設計するようエージェントに依頼すべきです。

便利なプロンプト例:

Using next-cache-components, propose cache tags for posts, categories, and homepage sections, then show where `updateTag` should run after content mutations.

エージェントに何を出力させるべきか

next-cache-components usage を最大限活かすなら、出力形式は次の形で指定すると効果的です。

• 現在の route の分類
• 提案する component tree
• 正確なコード変更点
• component ごとの鮮度ポリシー
• invalidation 設計
• 想定されるリスクや挙動変化

この形にすると、推測で補う部分が減り、チームレビューもしやすくなります。

next-cache-componentsスキル FAQ

next-cache-componentsはパフォーマンス用途だけのスキルですか？

主にはそうですが、それだけではありません。next-cache-components は不要な request-time rendering を減らすことで性能改善に役立ちますが、同時に設計の見通しもよくします。再利用できるコンテンツと request-bound なコンテンツを、より明快に分離できます。

初心者にも使いやすいですか？

ある程度は使いやすいですが、前提として Next.js App Router の基本概念を理解しているほうが安心です。例自体は具体的でも、cookies、headers、ユーザー単位データがなぜ dynamic boundary を作るのかは、初学者には補助説明が必要なことがあります。

Next.jsのキャッシュについて直接聞くのと何が違いますか？

next-cache-components skill は対象範囲が狭いぶん、このテーマでは信頼しやすいのが利点です。広いプロンプトだと、古い API、Pages Router 前提の発想、React 全般論が混ざりやすくなります。このスキルは、現在の Cache Components モデルと、その前提となる primitives に焦点を合わせています。

next-cache-componentsを使わないほうがよいのはどんなときですか？

次のような場合は、使わないか、軽く補助的に使う程度でよいでしょう。

• アプリが Next.js 16+ ではない
• ページのほぼ全体が request-specific である
• route レベルのキャッシュ設計ではなく、CDN やデータベースの低レベルなチューニングが必要
• 自動コード移行ツールを期待している

これは設計と実装のガイドであって、完全な移行システムではありません。

キャッシュだけでなくinvalidationsにも役立ちますか？

はい。next-cache-components for Performance Optimization の実践的な強みの1つは、キャッシュだけでなく、タグベースの invalidation とセットで考えられる点です。多くのチームは、本番で stale データが見えてから初めて invalidation の重要性に気づきます。

プロファイリングや実測の代わりになりますか？

いいえ。適切な rendering と caching の構造を選ぶ助けにはなりますが、最終的には自分たちのメトリクス、route timings、ユーザーフローで検証する必要があります。良い設計と、改善が実証された状態は同義ではありません。

next-cache-componentsスキルを改善する方法

鮮度要件をもっと具体的に伝える

品質を最も左右するのは、データソースごとの許容 stale 時間を明示することです。「速くして」は弱い依頼です。「投稿は 30 分 stale でもよいが、cart count は常に live でなければならない」と伝えれば、エージェントは use cache、cacheLife、Suspense を正しく配置しやすくなります。

実際のcomponent境界を見せる

component の一部だけではなく、route tree や関連ファイルを貼ってください。next-cache-components は、何を切り出すべきか見えているときに最も力を発揮します。巨大な page component の中にすべてが隠れている状態では、キャッシュの提案精度が落ちます。

request-boundな依存を早めに特定する

次の利用があるなら、最初に明示してください。

• cookies()
• auth/session データ
• ユーザー単位のパーソナライズ
• request に結びついた geo や locale のロジック
• 変化の速い値

これらは、dynamic rendering を維持すべき境界になりやすい要素です。先に共有しないと、最初の提案が過剰キャッシュになりがちです。

コード修正の前に分類フェーズを求める

シグナルの強いプロンプト例は次のとおりです。

Use the next-cache-components skill to classify every part of this route as static, cached, or dynamic before suggesting code changes.

この一手で、早い段階でミスに気づきやすくなり、いきなり実装に飛び込むよりも設計の質が上がります。

推奨事項だけでなくトレードオフも説明させる

エージェントには、次の点も説明させてください。

• 何が stale になるのか
• 何が引き続き route をブロックするのか
• 何が後から stream できるのか
• 何を手動で invalidation しなければならないのか

そうすることで、next-cache-components guide はチームレビューに使いやすくなり、「速くなる」の裏で UX 退行が隠れるのを防げます。

注意したい典型的な失敗パターン

弱い出力によくあるのは次のような内容です。

• request-specific なロジックに use cache を付けてしまう
• 本当に dynamic なセクションの周囲に Suspense がない
• 無関係なデータ型に同じ TTL を当てている
• 書き込み後の invalidation を無視している
• Cache Components が有効か確認せずにキャッシュ案を出している

変更を適用する前に、こうした点を必ず見直してください。

初回ドラフトの後に詰める

最初の出力を受けたあとに、次のような追加指示を出すと改善しやすくなります。

• “Reduce staleness risk for user-adjacent sections.”
• “Separate shared CMS data from request-bound UI.”
• “Replace broad TTL-based caching with tag-based invalidation where updates are event-driven.”
• “Show the minimal refactor with the biggest gain.”

完全に新しい回答を求めるより、このように詰めていくほうが結果が良くなることが多いです。

実際のリポジトリ文脈と合わせてnext-cache-componentsを使う

next-cache-components install の判断にも、継続的な活用にも、実際の route ファイル、現在の Next.js バージョン、コンテンツ更新フローをセットで渡すのがベストです。このスキルは、フレームワークの primitives を抽象論として説明するより、あなたのページ構成に落とし込んだときに最も価値を発揮します。