🤔
「Next.jsの考え方」のあっきーさんが語る！ App Routerの勘所とキャッシュの未来 レポート
2024年12月18日、 「Next.jsの考え方」 の著者・あっきーさんを招いて、Next.js最新バージョン（v15相当）の動向からApp Routerの本質、そして今後のキャッシュの在り方まで、徹底的に解説していただくイベントが開催されました。Next.js Confで話題の“dynamicIO”のトピックを含め、いま注目しておきたいポイントをぎゅっとまとめた内容でした。ここでは、当日の講演やQ&Aで取り上げられた議題を振り返りながら、Next.jsが描く未来図に迫ります。
オープニング：Next.jsの進化を追いきれない…？
イベント冒頭、モデレーターから「近年のNext.jsは変化が激しすぎて正直ついていけない」という声が紹介されました。実際にApp Router（以下、アプルーター）のリリース後、リアクトサーバーコンポーネント（RSC）の導入や、各種キャッシュ仕様の更新など、大きなアーキテクチャ変更が連続しています。
その一方で、「アプルーター自体、まだ事例が少ないので採用判断が難しい」「キャッシュ周りでハマる」という意見も多く、初期段階で断念しているケースもあるようです。そこで本イベントでは、Zenn記事「Next.jsの考え方」を執筆し、App Router活用に深い知見を持つあっきーさんが、ベストプラクティスと近未来像を語る場となりました。
あっきーさんが見るApp Routerのメリットと「採用すべきか」の考え方
ページズルーターからの移行は慎重に
Next.jsの歴史を支えてきた「Pages Router」（以下、ペイジズルーター）を現在進行形で運用しているプロジェクトは多く、乗り換えの是非で悩むケースが少なくありません。あっきーさんによると、「ペイジズルーターがすぐ削除されることはない」とのことで、一斉乗り換えは不要。ただし今後のアップデートはアプルーターが主体になるため、新規プロジェクトや中長期的に成長を見込むプロダクトならアプルーターを学んでおく価値が高いとのことです。
学んで損はないApp Router
アプルーターはハマりやすい箇所（キャッシュやストリーミングなど）もあるものの、リアクトサーバーコンポーネントを活用した高パフォーマンスや、データフェッチのシンプル化といったメリットが大きいそうです。 学ぶ上での最適な入り口として、あっきーさん自身がまとめた無料の電子書籍「Next.jsの考え方」もおすすめとのこと。サンプルコードと理論がバランスよく解説されているため、「アプルーターにちょっと興味ある」という段階でも読んでおくと、後々の実装で迷いが少なくなるそうです。
Next.jsの要点5つ 〜データフェッチからストリーミングまで〜
講演の中盤では、App Routerを支える主要コンセプトが5つにまとめられました。
サーバーコンポーネントでデータフェッチ ユーエフェクトやSWRを使うのではなく、リアクトサーバーコンポーネント内でフェッチを行うことでパフォーマンスと実装のシンプルさを両立。
データフェッチのコロケーション 従来の「getServerSidePropsでまとめてデータを取って渡す」方式とは異なり、「必要なコンポーネントで必要なデータを取る」という分散的な方法が推奨される。
ストリーミング ユーザーがページを読み込んだ際、重い処理だけ後で流し込み、先に表示できる部分をとにかく早く返す。部分的ローディングが簡単に実装可能に。
サーバーアクションズ
use server指定を使って、サーバー側でデータ操作やキャッシュ更新を行う。サーバーアクションズを利用することで、クッキー書き込みなどもシンプル化。スタティック or ダイナミック レンダリングの選択 デフォルトはスタティック寄りだが、ユーザー情報など各種トリガーで動的に切り替える。従来のSSR/SSG/ISRのような区分をもっと柔軟に扱える仕組み。
これからのNext.js：PPRとdynamicIO
PPR（Partial Pre Rendering）
一部を静的、他を動的にするレンダリング手法。 アプリケーション開発で「画面の大半は変わらないが、一部だけリアルタイムに更新したい」というケースがよくある。その際に従来はSSRとクライアントサイド描画の組み合わせで頑張っていたところを、サスペンスとストリーミングで自然に実装できるようになったのがPPR。
dynamicIO
キャッシュ仕様を再設計し、「デフォルトはダイナミック、必要に応じてキャッシュを明示的につける」という方向へと変わりつつある試み。
「使いにくい」「把握が難しい」と不評だった従来のキャッシュ周りが一気にシンプルになる見込みで、今後はuse cacheの宣言を用いながら任意の範囲をキャッシュ化できるようになる。
どちらもまだエクスペリメンタルな段階ですが、App Router最大の難所であったキャッシュ管理が見通し良くなるため、「これからが一番始めやすい」とあっきーさんは語りました。
Q&Aピックアップ
当日のQ&Aセッションも盛り上がりました。特に多かった質問と、その一部の概要をまとめます。
Q1. 「検索機能はサーバーアクションズか、クライアントフェッチか？」
A. App Router的には、サーバーコンポーネント（もしくはサーバーアクションズ）で対応する形がおすすめ。クッキーやユーザーIDと絡むならサーバーアクションズ一択だが、単なるクエリパラメータだけならURLを切り替えてサーバーコンポーネントでレンダリングするだけでもOK。
Q2. 「アプリ全体をサービス層で包む設計と、データフェッチのコロケーションは両立できる？」
A. 基本的にはコロケーションを重視して自律分散設計に寄せた方がApp Routerの恩恵を受けられるとのこと。複数箇所で再利用したい処理だけ関数化（データフェッチ層）するスタイルが現実的。
Q3. 「キャッシュがつらいのは改善される？」
A. DynamicIOによって、キャッシュはオプトインの方式へ大きく舵を切る予定。これにより複雑さが軽減され、今後のApp Router利用がさらに快適になる見込み。
全体を踏まえた感想
今回のイベントを通して、Next.js App Routerはまだゴールに達していないものの、明らかに「使いやすさ」を目指して激変している印象を受けました。特に、キャッシュ周りの混乱を取り除く“dynamicIO”や、ページ単位からセクション単位へと拡張される“PPR”のアプローチは、従来のSSR/SSG/ISRなどの枠組みを超えて、真に柔軟なレンダリングを追求する形に進化しつつあります。
あっきーさんいわく、 「いまこそ学び始めのベストタイミング」 とのこと。リアクトサーバーコンポーネントはラーニングコストが決して低くはありませんが、一度把握するとデータフェッチやパフォーマンス最適化の苦労が大幅に減り、運用面でも高い拡張性を得られます。 新規プロダクトでも既存のPages Router運用でも、App Routerの基本設計とこれからの進化を押さえておけば、「なんだか難しそう」という不安を越えて、Next.jsが持つ本質的な強みを存分に活かすことができるでしょう。 まさに Next.jsの「次のステージ」 が見えてきた今、今回のイベントで得られた知見が、あなたの開発現場の一助となれば幸いです。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...