ディスカッション・質疑応答
ahomu氏：運営から事前に用意したものと、Xやチャット欄できた質問を投影していきます。
v14で辛かったポイントは？
akfm氏：さきほどQuramyさんが触れてくれていたところですよね。Quramy氏：v15でも直っていなところで言うと、Nextそのものの話ではないのですが選定できるライブラリが少ないと思っていました。特にスタイル周りの最近はMaterial UIがゼロワンタイムconfigなどいろいろ対応しているので、そういうものも使えたらよかったのになあと。
スライドにも入れましたが、個人的に残念だったのは普段他のプロジェクトでお世話になっていたMSW（Mock Service Worker）が使えなかったことです。
そのあたりを組み合わせて使い、問題提議の声が大きければ優先的に対応される仕組みは、エコシステム全体で一般的なものだと考えています。
Nextだけでなく、周りでデファクト的に使われるツールとの相性や、コミュニティの盛り上がりがまだ始まったばかりで少なかったため、その点は当時辛かったですし、今でも辛いと感じる部分があります。
ahomu氏：ありがとうございます。MSWは代表的ですが、一時期Storybookもそうでしたでしょうか？ React Server Componentsとの相性など。
エコシステム全体との連携が難しかった経験は、私も記憶しています。今、v15のリリースが近づいている中で、温度感が高いと感じる機能については進展してきたという印象をお持ちでしょうか？
Quramy氏：例えばそれが分かるところで言うと、マニアックな機能ですがサーバコンポーネントをバンドルするときに、よく使われるnode_modulesは意図的にバンドルしないようにするポイントがありますよね。
External Packageかな。
要するにバンドルされるとあまり嬉しくない部分があります。よく使われるパッケージに自分で書くこともできますが、Next側が提供していることもあります。
そうしたパッケージは、ユーザーの要望に応じて増えていくのでライブラリとの組み合わせも考えられているのだなと分かり、一覧を見ながらなるほどと思うこともあります。
akfm氏：エコシステムの話では、テストを書くときにどのように書くべきかを、僕も多くの場面で悩みました。testing-libraryは、まだサーバコンポーネントのレンダリングなどをサポートしていないと思います。
Quramyさんの記事へのリンクに含まれている記事では、昔からあるContainer/ Presentational Patternを使って、React Server Componentsを切り分けていくことで、テストも書けるし、設計も成り立つということが書かれていたと思います。そのやり方でやっていくと、いろいろな書き方ができて、そこら辺のエコシステムの辛さも少し減り、テストも書ける感覚がありました。きちんと試したかは覚えていませんが、Quramyさんの記事では、MSWはサーバコンポーネントでも最終的にコンテナ部分はコンポーネントをレンダリングさせるのではなく、単なる関数として実行していたと思います。
その方法ならMSWは使えると思っていますが、あっていますか？
Quramy氏：はい、使えます。
akfm氏：だとすると、結論としてはQuramyさんの記事を読んでくださいということになりますが、Quramyさんの記事で紹介されているようなContainer / Presentational Patternでコンポーネント設計をしていくことで、テストも柔軟に書けるという現状なのだと思います。
最初に触れた時は、そのようなものも出ていなかったですし、日本や世界で知見が溜まってきた段階に来たと感じています。
Quramy氏：今、テスティングライブラリが未対応という話がありましたが、できることなら一気通貫でテストしたいという気持ちはありますよね。
akfm氏：それはそうですよね。
Quramy氏：テスティングライブラリと言うか、JestやVitestがメインになってくるとは思いますが、そこの動向に期待しています。
今後も注力していこうかなと思います。
ahomu氏：ありがとうございます。次の質問にいきますね。
v15から始めるとどんないいことがありますか？
ahomu氏：お二人から先ほど紹介があった内容に近いかもしれませんが、このテーマはいかがでしょうか？akfm氏：先ほどスライドで紹介しましたが、デフォルトでキャッシュすることが減ってきたのでNext.jsをこれから始める方にとってはハマるポイントが減ったということになると思います。
App Routerでハマって辛いと言われたら、2番目に「キャッシュですか？」と聞きたくなるくらいキャッシュの悩みは多かったと思っています。それが減ったので初学者でこれからApp Routerを始めたい人にとってはいい状態になったと思っています。
v15は始めどきのタイミングになると個人的には思っています。
ahomu氏：今日もキャッシュ殺しや初見殺しなどの話がありましたが、そこら辺の殺しあいがv15以降はだいぶ軽減されるということですよね？
akfm氏：そうですね。ただひとつ注意してほしいのはApp Routerしかり他もですが、なんでも叶う理想のフレームワークはやはりないということです。
エコシステムの未成熟な部分は、1〜2年だと目につくこともありますし、辛さが全くないわけではありません。ただ、今までの辛さからは一歩解放された部分もあります。理想のフレームワークを期待しすぎるとそれとは違いますし、逆に「辛いんでしょ？」と押しのけると、それもまた違うと感じます。期待値のバランスを取って、始めてもらいたいと思っています。
ahomu氏：Quramyさんからは何かありますか？
Quramy氏：正直、PPRの概念はv14ではなかった概念なので、自分が使いこなせるか分からない感じではあります。リリースされたらいろいろな人のブログやアッキーさんのアドバイスを読みながら自分のものにしていけたらいいと思っています。v14の延長で見えるところで言うと、キャッシュ周りでしょうか。
特にクライアント側のキャッシュ、いわゆるRouter Cacheについては、あっきーさんがとても詳しくて社内であっきーさんの発表を聞いていたからどうにかなったところが正直あります。
触っているときに、（これ、あっきーさんがいない会社の人は大丈夫かな？）と思うほどだったのでそういう所が軽減されるのは、いいところだと思っています。
これからの注目機能を教えてください
ahomu氏：運営からの質問は最後になります。Quramy氏：だいぶ日が経過していますが、v15はReact 19のステイブルを「待たない」と決定されました。ただ、React 19でできるようになることが、そのままNext.jsのv15でもほぼ使えるようになると考えています。
その部分で「サーバアクション、非同期アクションはこういうものだよ」と整理されたものが使えるようになり、User action statなどでサーバと通信しながら画面をよしなに部分更新していくような「かゆいところに手が届く機能」が今まで以上にきちんと整備されてみんながいい感じにコードが書けるようになっていく世界に期待しています。
ahomu氏：ありがとうございます。
akfm氏：発表でもあった通り、僕が一番注目している機能はPPRです。
今日は今までの流れで説明したので少しややこしい部分もあったかもしれませんが、シンプルに「基本Static、サスペンス内は動的ダイナミックに」という思考で全て作って行けます。
今まではNext devとNext startの挙動に違いがあり、Next devではうまくいっていたのにNext startだと静的になった経験をした人もいると思います。ページの状態を頭の中に置いておかなければいけない状態は、認知負荷が高いと思っています。それがPPR以降の世界は「このサスペンス内だから動的」「これはページだからStatic」とシンプルなメンタルモデルで実装に当たっていけて、高いパフォーマンスが実現できることが魅力的だと思っています。
SSGやISR、SSRGなど、単語がたくさん並ぶのを薙ぎ払ってPPRだけ「基本Static、部分的にダイナミック」というメンタルモデルでせめていけるのは、今後の開発速度や罠、パフォーマンスなどどの面で見ても夢のある話だと思って期待しています。
ただ、Next.js側の実装がとても大変で、まだまだバグもあると思うのでそこと向き合って慎重に採用していかなければならないという段階が1～2年はあると思います。そこが夢はあるけれど注意ポイントです。
ahomu氏：ありがとうございます。では、次に質問に入っていきます。
Q：API Routesを用いてサーバサイドまでNext.jsで運用している例をご存じでしたら教えていただきたいです。自社でtoBのSaaSを開発しているのですが、サーバ、クライアント共にNext.jsで開発している他社事例を聞いたことが無いので…
akfm氏：僕が知っている範囲や見ている範囲ではAPI Routesをバックエンドとして使うということですよね。Quramy氏：そうだと思います。
akfm氏：Nextのフロントエンドと、API Routesで作ったNextのバックエンドという感じだと思います。
Next.jsはサーバ側でのレンダリングに強みを置いているフレームワークなので、あまりこのような使い方をしているケースを見たことがありません。ただ、たけぺぺさんの本で学習の一環としてこのような構成を採用しているのを見たことがあります。
akfm氏：そうですよね。頑張って考えようとすると、Next.jsでWEBの配信もしているけれど、アプリ向けにAPIも提供しているというユースケースでしょうか？
Quramy氏：あまりないですね。App Routerと関係なく、データフェッチの基本のキはGSSPやGSP、App Routerの場合はServer ComponentやServer Actionsになるので、部分的に少しレンダリングした後に通信したいケースでなければ、本来API Routesは使わないと勝手に思っていました。
ahomu氏：次の質問です。
Q：Data Cacheやfull route cacheあたりのキャッシュの種類が何度見直してもよく分からず、どれくらい細かく意識しないといけないのでしょうか？意識する場合の対策も教えていただけると嬉しいです。
ahomu氏：今日もいろいろご説明いただきましたが、キャッシュ周りの質問です。これまであまたのキャッシュとの殺し合いを潜り抜けてきたあっきーさんとQuramyさん的にはいかがでしょうか？
akfm氏：実案件でこなしているQuramyさんの意見を聞きたいです。
Quramy氏：意識する場合の対策の話でいうと、Data CacheとFull Route Cacheの2つは永続化されて保存されていて、この永続化方式はNext.jsが動いているプロセスのデフォルトだとファイルになるんです。なので、Barthelなどを使わずにセルフホストしている人たちは、その裏側を意識したほうがいいと思っています。
要するにあっきーさんのリクエストとahomuさんのリクエストが仮にData CacheとFull Route Cacheを共有したい場合でも、NextのプロセスがAWSのLambdaなど2つ同時に動いていたら、デフォルターと別にそれぞれでキャッシュができるだけなので、「キャッシュじゃない」ようなことになってしまうんです。
このような所を、あっきーさんが記事に書いています。
https://zenn.dev/akfm/articles/nextjs-revalidate
カスタムキャッシュハンドラーの機能で拡張を変更しないといけないので、そのようなインフラ観点の意識は出てきますよね。
細かくは使っていなかったので、なにかあっきーさんありますか？
akfm氏：混乱しやすい部分だと思うので、読み込むしかないかなと思います。
対策としては、v15を使うと良いと思います。v15からはデフォルトでキャッシュにハマりづらくなっているので、まずv15を使ってみるといいと思います。それでもハマるところは現状では学習コストがかかるところなのでドキュメントとにらめっこをするしかないと思います。
Zennの記事やX（旧ツイッター）で質問をもらえたら応えることもできるので、人に聞いたり記事を利用したりして学んでいくといいですね。
Q：PPRがCDNと相性が悪い理由を教えていただけますでしょうか？ブログでまとめてくださっていたらすみません。
ahomu氏：PPRの話です。akfm氏：ブログで、だいぶ下の方に書いてあるので貼っておきます。
従来CDNはHTTPリクエストに対してHTTPレスポンスをキャッシュする思想なんです。PPRは静的な部分と動的な部分が同居していると説明しましたが、実際にはHTMLとしては動的な仕組みです。静的なHTMLに「穴」を開け、後からその部分をサーバ側で埋めるイメージです。
このため、CDNでキャッシュをしようとすると、動的な部分も含めてHTMLが完全に埋まった状態（ページ全体）で保存されてしまいます。先ほどのECサイトの例で説明すると、ユーザーごとの異なるカートの内容やレコメンドの情報までキャッシュされてしまうので、他のユーザーに同じ内容が表示されるリスクがあります。これが、CDNとPPRの相性が悪い理由です。
ahomu氏：Quramyさんは補足などありますか？
Quramy氏：おっしゃっていただいた通りだと思います。
あくまで、PPRは一つのリクエストに対して全体をキャッシュする「Full Route Cache」のようなイメージでしょうか。サイトの側（シェル）部分やStatic部分を早く読み込み、計算が重い個別のユーザデータはリクエストごとに計算し、それをがっちゃんこして返すイメージです。
あくまでブラウザ側の世界でリクエストの読み込みを見た時に動的なページは動的です。
ahomu氏：このStaticな部分だけはCDNでキャッシュしても支障ないという形にはできるのでしょうか？
Quramy氏：未来の話かもしれませんが、キャッシュと言うよりはエッジコンピューティングのような感じで事前にStaticをエッジに置いておきます。そして、エッジが穴の部分だけを後ろのオリジンに送ってがっちゃんこして返すようなことが、今は夢物語かもしれませんが、そんなアーキテクチャが出てきたら楽しいだろうなという話を社内でしています。
akfm氏：夢のある構成だと思いますが、セルフホスティング勢が自分たちでやるのはさすがにしんどいと思うので、そのような対応をしてくれるベンダーさんがいらっしゃれば...
Quramy氏：それは、Vercelさんなんでしょうね（笑）。
akfm氏：Vercelはじめ、他のベンダーもやってくれると嬉しいですね。
Quramy氏：そうですね。自分で作る自信がないですね。
ahomu氏：ありがとうございます。
Q：nextをフロントで使った場合、おすすめのサーバサイドのフレームワークを教えてください
Quramy氏： 「Nextだから」という部分は正直ないと思っています。
Next.jsが現在提供しているバックエンドサービスとの通信方法は、基本的にfetchに全振りされています。つまり、「fetchが使えれば何でも良い」ので、fetchしやすいオープンAPIと、型生成の機能を備えていれば、使用する言語を問わないのでお好きなもので問題ない気がします。
Q：テスト回りの話で、Quramyさんはprismaのtestの話に言及されましたが、drrizleを使ったときのServer actionのtestを書くとしたら、どういうふうにテストに書くのがいいかなど気をつけないといけないところがあれば教えていただけませんでしょうか？
Quramy氏：触ったことがないので誤解していたら申し訳ないのですが、drrizleはPrismaライクとは別のオルタナティブな「O/Rマッパ系」の類かと思っています。僕がサーバサイドでテストを書く際は、Node.jsに限らず、実際のデータベースと繋いでテストしたいという意思が強いです。
具体的には、SQLまで流して自前でDockerなどでPostgreSQLを立てて意図した通りにクエリやデータ更新が行われているかを確認することを重視しています。そのようなツールを探してみるか、無い場合は自分で組むこともあります。
お答えになっていれば幸いです。
Q：App Routerでデプロイする環境としてVercelかそれ以外で注意すべき点が結構違うのかなと思っているのですが、このへんはいかがでしょうか？
Quramy氏：最近どハマりしたのですが、AWS AmplifyでApp Routerを使うと痛い目を見るという経験談があります。akfm氏：ちょうどラムダのキャッシュの話を持ち出したのは、Amplifyで辛い目に遭った経験があったからです。
全機能が使えないわけではないものの、Nextのキャッシュの挙動を理解していないと辛い目に合う例として、AWSやAmplify、Lambdaをあげています。
同じベンダーでない場合は、Nextのプロセスの動きに気をつけるべきだと思います。
Q：React19、Next.js15に移行すべきかどうか、悩ましい微妙なタイミングなのですが……。React19、Next.js15が出たら、旧のReact18、Next.js14のサポート期限ってどうなるのでしょうか？そのサポートポリシーが分かるURLとかがあれば教えてほしいです。
ahomu氏：ライフサイクルポリシーは今あるのでしょうか？akfm氏：無いと思います。今、まさにこの前「Next.jsが大きくなってきたのでLTSサポートのような考え方を社内で議論し始めている」というツイートを見かけたので、今後サポートポリシーは出てくるかもしれませんが、現状ではない段階です。
Q：事例に関して、フロントエンドの操作トリガーでフェッチ（GET系）したい場合はクライアントサイドからデータフィッチするかと思うのですが、Server Actionで取得していますか？それとも一般的なフェッチライブラリで取得していますか？またXHRとリロードで認証はどう両立していますか？
akfm氏：ものによる気はしますね。Quramy氏：ユーザーがボタンをポチっとしたとかアコーディオンを開いた等のインタラクションに紐づく話だと思います。
akfm氏：これは3パターンで「URLを書き換えて全部レンダリングしなおす」か、「Server Actionsを使う」か、「フェッチライブラリを使う」かのだいたい3択でしょうか？
Quramy氏：性能的に問題がなければ、Server Actionsを使うのが良いと思っています。ただし、Server Actionsには一度に送信できるデータの数に制限があるため、画面のあらゆるところから同時にデータ取得が行われるようなケースでは、要件に合わない可能性があります。
その場合は、フェッチライブラリやAPI Routesと何かを組み合わせることを選択するのも良いと思います。
akfm氏：1か所のトリガーで複数個所を更新しなければいけない場合は、要件や仕様次第ですが画面ごとにURLを書き換えて画面全体を再レンダリングするのも手にはなりますよね。
Quramy氏：そうですね。実装としてはリーズナブルだったりしますよね。
Q：module.exports = output 'standalone' は使っていますか？
akfm氏：使ったことないです。Quramy氏：僕も使ったことがないですね。
ahomu氏：案外そうなのですね。ちなみに私は使ったことがあります。ラムダ配信を夢見て。
akfm氏：サーバレス環境にさっとデプロイしたいときはこれなんですよね。
ahomu氏：Nextのv14当時にまあまあ穴を踏み抜いてケガをした覚えがあります。
今はどうだか分からないので、ご質問された方は興味があればお試しください。
お時間が来てしまったのでご質問はこれにて終了とさせていただきます。
みなさんたくさんご質問いただきありがとうございました。
最後に
最後に、参加者に向けてコメントをいただければと思います。
akfm氏：今Next.js v15は個人的には始めどきとしておすすめなので、ぜひ触ってみようと思ってくれる方がいたらうれしいです。
v15に限らずNext.js全般に関してですが、Zennで最近『Next.jsの考え方』という本を書きました。無料なので興味がある方は読んでくれたら嬉しいです。
Quramy氏：App Routerはまだまだな所もありますが、いいところもたくさんあるので、ぜひ触ってその上で「自分は触ってこうだった」などブログや発表、issuesなどに書いていただけたらいいと思います。
