2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

席替えアプリをNext.jsに移行したら「あれ、Reactと変わらなくね?」ってなった話

2
Last updated at Posted at 2026-04-27

はじめに

教員である友人のために、席替えアプリ「Seat Tree」を作成しました。
これは、ボタン一つで様々な配慮を考慮した座席が生成されるアプリです。

画面収録 2026-04-27 17.17.19.gif

React SPAで作成したときは、ルーティングのためにReact-routerの導入やCSSの簡略化のためにTailWindCSSの導入してきました。
Next.jsでは、初期からApp RouterTailWindCSSがあり、また、クライアントサイドレンダリング(CSR)ではなく、サーバーサイドレンダリング(SSR)がベースとなっているため、アプリの可能性がさらに広げられるという希望を持っていました。

サーバーサイドレンダリング(SSR)とは、サーバーでデータを集めてHTMLとJavaScriptを実行し、クライアントサイドにそれをHTMLファイルにまとめて渡す手法。

⭕️すでに完成されたHTMLが初めから届く!→SEOに良い
⭕️APIキーなど秘匿の物がサーバーで実行されるから、クライアント側に見えない

Next.jsではデフォルトの設定である。

クライアントサイドレンダリング(CSR)とは、サーバーから最小限に記述したHTMLファイルだけが送られて、クライアントサイドでJavaScriptが実行され、HTMLを書いていくという手法。

⭕️最小限で届くので、初回にクライアントで読み込んでしまえば、後は高速
❌ただ、クライアント側でコードを実行するので、APIキーなどが見えてしまう危険性

これまでのReact SPAアプリではこれを使っていました。

そんな希望を持った自分が実際にNext.jsにアプリを全て書き換えてみて、「席替えアプリではあまり恩恵が受けられなかった」という学びをお話したいと思います。

落とし穴その1「"use client"が極めて多いアプリであったこと」

席替えを行うには、生徒の状態や、座席の状態など、ユーザーの手によって状態の変化する処理がたくさんあります。そのため、ボタンの操作などで、結果的にクライアントサイドである、ユーザー操作でHTMLをどんどん書き換えていく必要があります。
また、席替えの状態を管理するグローバルステートが数えただけでも6個もありました。これも全てクライアントサイドでのみ実行可能です。

以下は、npm run buildで本番用の環境を構築した結果です。全てのページにおいて、席替えする前のある程度完成したHTMLが送られてきています。このページごとにはユーザー操作によってインタラクティブな部分はその都度更新し、席替えを行うという処理になります。

image.png

前作ったReact SPAとほぼ一緒の構成になってしまいました

追記 レンダリング方法を更新することができました!

このことからの学び

Next.jsが得意な用途として、
・記事を取得して表示するだけのブログサイトやニュースサイト
・商品を取得して表示するだけのECサイト
・ユーザーの情報を取得して表示するだけのダッシュボード

取得して表示するだけなら良さが活きてきそうです。

リアルタイム操作が豊富な席替えアプリはあまり恩恵が受けにくいです。

落とし穴その2「SEO対策が微妙であったこと」

SEO対策は初回表示のHTMLが鍵を握ります。
初回表示を見てみると、以下のような結果でした。
スクリーンショット 2026-04-27 15.54.25.png

確かに、headタグは充実していますが、bodyタグが期待より遥かに下という感じです。

当たり前ですが、ロード画面を用意していたので、読み込み中しか表示されていません。これでは、せっかく書いていたh1タグなどがもったいないので対策を打ちたいと思います。

このことからの学び

単なるアプリを作成して使うだけなら良いが、本格的にSEO対策をするのであれば、トップページには、静的なサイトを配置して、アプリに遷移させるとより良くなる。
→またいつか作成する。

落とし穴その3「APIキーがクライアントに露出してしまったこと」

これも大きな落とし穴でした。
supabaseのURLとanon keyが見えております。これも、JavaScriptをクライアントサイドで実行しているため、クライアントサイドにキーが見えるようになってしまいました。

Supabase は anon key が公開されることを前提に設計されており、Row Level Security(RLS)で何を許可するか制御するのが正しい使い方です。

QiitaのAPIなど漏洩すると良くないものもありますので、それはサーバーサイドで実行できるようにコードを書きます。

このことからの学び

それぞれAPIキーの意義について考え、どのサイドで実行されているのか見極める必要がある。

まとめ

限定的ですが今回の恩恵も

・App Routerはファイルの管理がとても楽で、自動でURLが振られて使い勝手よし
・installしなくても初回からTailWindCSSが使えて楽
・App Routerのおかげでプロジェクト全体のコード管理が見やすい
・React SPAとの違いがわかった(最大の収穫)

今後はNext.jsの恩恵が受けられるサイトを作成したいと思います。
その時には、今回使えなかったPPRやISRのようなレンダリング方式も採用したいと思います。

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?