前提知識

Next.js とは？ 初心者向けガイド

Next.js が SaaS に適する理由: ルーティング、SSR/SSG、API ルートを 1 リポジトリで — 初心者にも読みやすいロングガイド。

Next.js とは？ 初心者向けガイド

Next.js は React と Node.js の上に構築されたフレームワークで、モダンな Web アプリ開発を楽にしてくれます（概要）。要するに、Next.js はフロントエンドとバックエンドを 1 つのプロジェクトに統合し、SaaS（Software‑as‑a‑Service）のようなリッチなアプリを作るためのオールインワンな解決策を提供します。ルーティング、サーバーサイドレンダリング（SSR）、静的サイト生成（SSG）、API ルートなどが最初から使え、ボイラープレートの設定に時間を取られずアプリ本体の開発に集中できます（なぜ Next.js を使うか）。これらが 1 つにまとまっているからこそ、Next.js は SaaS で人気です。高速なページ表示、SEO に強いページ、バックエンドのエンドポイントを同一コードベースで実現できます。

Next.js が最初から提供するもの

Next.js の大きな利点の 1 つは、ゼロ設定で得られる機能がとても多いことです。代表的なものを挙げます。

ファイルベースのルーティング: 別途ルーターの設定や React Router は不要です。Next.js はファイル／フォルダ構成から自動的にルートを生成します（ファイルベースルーティング）。たとえば pages/about.js というファイルは、そのまま /about ページになります。ページの整理が直感的になり、手動のルート定義が要りません。

サーバーサイドレンダリング（SSR）: Next.js はリクエストごとにサーバーでページを描画し、完成した HTML をクライアントへ返せます（SSR の基本）。初回表示が速く、検索エンジンがコンテンツをクロールしやすいので SEO に有利です。サーバーが HTML を返した後は、クライアント側で React がハイドレーションしてインタラクションを提供します。

静的サイト生成（SSG）: 毎回動的にする必要のないページは、ビルド時に静的ファイルとして事前生成できます（SSG）。CDN などから静的に配信されるため非常に高速で、SEO にも有利です。マーケティングページやドキュメントなど、更新頻度が低いコンテンツに最適です。

組み込みの API ルート: api ディレクトリにファイルを追加するだけでバックエンドのエンドポイントを作れます（API ルート）。これらは Next.js アプリの一部として Node.js（あるいはサーバーレス）で動作します。フォーム送信、DB クエリ、認証などを、別の Express サーバーを立てずに同じプロジェクト内で扱えます（後述）。

自動コード分割と最適化: Next.js はページ単位で自動的に JS バンドルを分割し、アセットを最適化します（最適化）。各ページは本当に必要な JS/CSS だけを読み込み、巨大な単一バンドルを避けられます。結果としてページ表示が速くなり、ユーザー体験が向上します。ミニファイ、ツリーシェイキング、画像最適化など本番向けの最適化も内蔵。Webpack や Babel の複雑な設定は不要です。

ゼロコンフィグの DX: TypeScript のサポート、CSS/Sass の組み込みサポート、状態管理やスタイリング、データ取得など人気ライブラリとの統合がシームレスです（DX の概要）。最小限のセットアップで、すぐに機能開発に取り掛かれます。

要するに、Next.js は「フルスタックな React フレームワーク」です。ルーティング、バンドル、レンダリングの重労働を肩代わりしてくれるので、「あなたは React コンポーネントを書くことに集中できる」（ディスカッション）。SaaS 開発では特に強力で、基本性能（高速表示や SEO 対応）が最初から担保されます。

Next.js のルーティングとレイアウト

Next.js は、フォルダ構成を URL にマッピングするファイルベースのルーティングを採用しています。pages（または新しい app）配下のファイルやフォルダが自動的にルートになります。たとえば pages/user/settings/notifications.js のような入れ子構造は、そのまま /user/settings/notifications というパスを生成します。手動設定なしで URL 構造がプロジェクト構造と同期し、整然と保てます。

ルート定義はファイルを作るだけ。ディレクトリでページを整理すれば、Next.js がナビゲーション可能な URL を用意してくれます。動的ルートもカバーしており、pages/posts/[id].js のようなファイルは /posts/123 のようなルートになります。内部的にはリンクやコード分割が自動化され、ページ遷移は軽快、フルリロードも不要です。

さらに Next.js 13 の App Router は「レイアウト」の概念を強化し、フォルダ単位で入れ子のレイアウトを定義できます。たとえば app/dashboard/layout.js にサイドバーやヘッダーを定義すれば、/dashboard/* 配下のすべてのページでそのレイアウトが共有されます（ネストされたレイアウト）。SaaS では、マーケティング用の公開ページと、ログイン後のアプリ UI で異なるレイアウトを使い分ける、という整理が容易です。

要は、Next.js のルーティングとレイアウトにより、マルチページアプリを苦労なく構築できます。ユーザーにも検索エンジンにもやさしいクリーンな URL と、共通 UI の容易な維持管理。外部ルーターの細かい調整や、レイアウトのマウント／アンマウントに悩まされる必要はありません。

サーバーコンポーネント vs クライアントコンポーネント（やさしい説明）

とくに Next.js 13+ では、Server Component と Client Component という用語を目にします。これは Next.js と React のレンダリング方式に関わる話です。噛み砕いて説明します。

サーバーコンポーネントは、サーバー側で実行される React コンポーネントです（ブラウザが受け取る前にサーバーで描画）。サーバーで HTML を生成してブラウザに送るため、そのコンポーネントの React JS はクライアントに送られません（比較）。表示が非常に速く、サーバーで直接データ取得できるので、データ表示やインタラクション不要の UI に最適です。サーバーで完済した HTML をそのまま見せるイメージで、機密データもサーバーに留められるため安全です。ただし、クリックなどのインタラクションは扱えません（クライアント JS を含まないため）。

クライアントコンポーネントは、従来どおりブラウザで実行される React コンポーネントです。ポップアップを開くボタン、ユーザーが入力するフォーム、ページ表示後に動的に更新される UI など、インタラクティブな部分にはクライアントコンポーネントが必要です（クライアント側）。動作のためにブラウザで JS を読み込むぶん、純粋な HTML に比べて初回表示はやや重くなります。Next.js では、ファイル先頭に特別なディレクティブ "use client" を置くことで、そのファイルをクライアントコンポーネントとして指定します。

実運用では、1 つのページを両者の組み合わせで構成します。たとえばページの骨格やデータ表示はサーバーコンポーネント（高速で SEO に有利）、内部のグラフや入力フォームはクライアントコンポーネント、という具合です。これでサーバー描画の速度と SEO の利点、クライアントのリッチな動作の両取りができます。ダッシュボードなら、大枠のデータとレイアウトはサーバー側でレンダリングし、ズーム可能なチャートや送信フォームだけクライアント化――といった使い分けが現実的です。

まとめると、サーバーコンポーネント＝サーバーで描画（クライアント JS なし、静的表示や速度に最適）、クライアントコンポーネント＝ブラウザで描画（インタラクションに必須）。Next.js は基本をサーバー側に寄せ、必要な所だけ "use client" で明示してクライアント化します。これは、SaaS における「速度」と「リッチさ」のバランスを取るための強力な仕組みです。

組み込み API ルート：同じリポジトリにバックエンド

SaaS 開発で光る Next.js の機能が API ルートです。通常、バックエンドを作るには、データ取得やフォーム処理、認証などのために別のサーバー（Node/Express や Nest.js）を用意することがあります。Next.js では、しばしばその追加構築をスキップできます。フロントページの隣にバックエンドのエンドポイントを定義できるからです。

Next.js プロジェクトでは、Pages Router なら pages/api/、App Router なら app/api/ 配下のファイルが HTTP エンドポイントになります。たとえば pages/api/hello.js を次のように作成します。

// pages/api/hello.js
export default function handler(req, res) {
  res.status(200).json({ greeting: "Hello from Next API" });
}

アプリが起動していれば、/api/hello へのアクセスで上のハンドラーがサーバー上で実行され、{ "greeting": "Hello from Next API" } という JSON が返ります。これが非常に強力です。React のフロントと API を同じコードベースに同居させ、ユーザー情報の取得、フォーム保存、ヘルスチェックなどのエンドポイントを、別サーバーなしで用意できます。Vercel などにデプロイすれば、API ルートは自動的にサーバーレス関数として動きます。

多くのケースで、Next.js の API ルートがあれば「別バックエンドなし」で SaaS を構築できます。初期段階では UI を Next.js のページで、データ取得を Next.js の API ルートで、という構成が現実的です。フロントとコード／設定／型を共有でき、開発がスムーズになります。API ルートはサーバー側で実行されるため、シークレットや DB 資格情報を安全に保持できるのも利点です。

なお、API ルートのコードはクライアント側に送られません（サーバー専用）。フロントのバンドルが肥大化しないので、UI 側への負担もありません。

具体例として、SaaS の簡単なヘルスチェック用エンドポイント（バックエンドが動いていることの確認）を作りたいとします。api/health.js を用意し、{ status: "ok" } のような JSON を返すだけ。pnpm dev でアプリを起動し、ブラウザで http://localhost:3000/api/health を開くと JSON 応答が見られます。🎉 これは Next.js がフロントとバックの両方を同時に提供できていることを手早く確かめる方法でもあります。

もちろん、SaaS が成長すれば外部データベースや複雑なロジックが必要になります。API ルートから DB にアクセスしたり、外部 API を呼び出したりも可能です。内蔵の API で足りなくなったら、後から専用のバックエンドサービスを足す選択肢もあります。とはいえ、小〜中規模では API ルートだけで十分というチームも多いでしょう。

トレードオフ：Next.js が不要な場合もある？

ここまで見ると「常に Next.js が最適？」と思うかもしれません。とても良いツールですが、過剰になり得る場面やトレードオフも理解しておくと健全です。

超シンプルな用途ではオーバーキル？ 1 ページだけのランディングや、極めて基本的な静的サイトなら、SSR や API ルートが不要で、Next.js は「やりすぎ」に感じるかもしれません。その場合は Vite + React のような軽量構成や、素の静的 HTML でも十分です。Next.js には学習コストやビルド工程もあります。ただし、Next.js はスケールと共に真価を発揮します。最初はオーバーキルに見えても、後に複雑化したときに備えができている（オーバーキルか？）。つまり、小さく始めても将来の拡張に強いという安心感があります。

別バックエンドなしで SaaS は作れる？ はい、多くのプロジェクトがそうしています。Next.js の API ルートにより、最初は別サーバーを持たなくても十分です。UI は React で、データは API ルート経由で JSON として提供。たとえば sushi-templates.com では、ユーザー向けページとバックエンドロジックが 1 つの Next.js コードベースに同居しています。デプロイも 1 アプリで済み、UI と API の整合性も取りやすい。もちろん別バックエンドを使っても構いませんが、要件がない限り最初は API ルートだけで十分、というのがコミュニティでも一般的です（別バックエンド？）。

まったく Next.js が要らない場面は？ SEO を気にせず、全面的にクライアントサイドのインタラクションに寄った内向きツールやゲームのようなケースでは、もっと軽い React セットアップで十分かもしれません。Next.js は規約やビルド手順など一定の前提があるため、超特化のウィジェットや一発のプロトタイプでは、素の React が軽快なこともあります。既に完全に別バックエンドがあり、フロントはクライアントレンダリングのみという構成でも Next.js を使うのは問題ありませんが、SEO が不要で自由度を最優先するチームは Vite + React 等を選ぶこともあります。要は、Next.js は「意見のあるフルスタックフレームワーク」。要件が極端にシンプル、または極端に特殊なら、その意見が重く感じられることがあります。

まとめると、Next.js はほとんどの Web アプリ、とりわけ SaaS に強力な選択肢です。静的一枚物にはやや過剰でも、悪手ではなく、将来の成長に備えられます。そして、Next.js を用いれば別バックエンドなしでも SaaS を構築可能です――多くの個人開発者や企業が、UI と API を 1 つのプロジェクトで完結させています（バックエンドの選択肢 / なぜゲームチェンジャーか）。

まとめと次の一歩

Next.js は、初心者にも扱いやすく、かつ強力な Web アプリ構築の道を提供します。ルーティング、描画最適化、バックエンド機能が最初から揃っており、SaaS を作る人にとっては「少ない部品で、早くオンラインへ」が実現します。車輪の再発明は不要――Next.js が堅実な土台を用意してくれます。

試してみたいなら、まず開発サーバーを起動して、どれか 1 つ機能を触ってみましょう。チームのテンプレートや npx create-next-app@latest でプロジェクトを用意し、pnpm dev で起動。/api/health を開いて API ルートのレスポンス（JSON）を確認すれば、フロントとバックが 1 つで動いていることが体感できます。

ここからは、ファイルベースルーティングでページを増やし、サーバーコンポーネントで高速表示を実現し、必要な部分だけクライアントコンポーネントでインタラクションを加えていきましょう。重い処理は Next.js が裏で面倒を見てくれます。

ハッピーコーディング！React のスキルを活かして、フルスタックな SaaS 開発を「悩み」から「楽しさ」へ。

参考

SaaS 101 — 『Software as a Service』の本当の意味

SaaS（Software‑as‑a‑Service）とは何か、どう動くのか、主要な利点、そしてなぜクラウド時代のソフトウェア提供の主流になったのかをやさしく解説。

ミドルウェアとは？ 初心者向けガイド

ミドルウェアの基本、SaaS で役立つ理由、当プロジェクトの Next.js ミドルウェア（i18n と request ID）の動きと安全なカスタマイズ方法を解説。

On this page

Next.js とは？ 初心者向けガイド
Next.js が最初から提供するもの
Next.js のルーティングとレイアウト
サーバーコンポーネント vs クライアントコンポーネント（やさしい説明）
組み込み API ルート：同じリポジトリにバックエンド
トレードオフ：Next.js が不要な場合もある？
まとめと次の一歩
参考