Webシステムの設計書やフロントエンドの技術記事を読んでいると、「React Routerの利用例として、ToC向け画面はSSR、SEOが不要な管理画面はSPAとする構成」といった一文に出会うことがあります。

たった40文字ほどの短い文章の中に「React Router」「ToC」「SSR」「SEO」「SPA」と5つもの英語・略語が詰め込まれているため、初めて見たときに「ちょっと何言っているか分からない…」「呪文のように見える」と感じてしまうのはごく自然なことです。

しかし、一つひとつの言葉を分解していくと、ここで語られている内容は実はとてもシンプルで理にかなっています。本記事では、登場する専門用語をひとつずつ噛み砕いて解説したうえで、「なぜお客さん向け画面と社内用管理画面で仕組みを分けるのか」「React Routerでどのように両立させるのか」を図解とコード例で分かりやすく紐解きます。

元の文章

「React Routerの利用例として、ToC向け画面はSSR、SEOが不要な管理画面はSPAとする構成」

やさしい日本語に翻訳すると…

「画面の切り替えやデータ取得を管理するツール（React Router）を使うと、一般のお客さんに見てもらう公開ページ（ToC向け画面）は、Google検索で見つけてもらえるようにサーバー側で完成させたページを届ける方式（SSR）にし、逆に検索結果に出す必要（SEO）がない社員専用の管理画面は、アプリのように軽快に操作できるブラウザ側で画面を組み立てる方式（SPA）にする、という『いいとこ取りの使い分け』が1つのツールで実現できますよ」

「ToC向け画面」と「管理画面」の違い（誰が使う画面？）

まずは「どんな人がアクセスする画面なのか」を表す2つの言葉です。

• ToC（トゥーシー ＝ to Consumer）向け画面：「Consumer（一般消費者・個人ユーザー）」に向けた公開画面のことです（ビジネス用語の「BtoC」の後半部分と同じ意味で、企業向けの場合は「ToB」と呼びます）。たとえばネットショップの商品ページ、宿泊・飲食の予約サイト、求人一覧ページ、ニュースやブログ記事などが該当します。「まだログインしていない初めてのお客さん」が検索やSNSから訪れるのが大きな特徴です。
• 管理画面（Admin画面 / バックオフィス画面）：サービスを運営する社員や店舗スタッフだけが、IDとパスワードでログインして使う「裏側の業務用画面」です。商品の在庫登録、注文データの絞り込み検索、売上グラフの確認、顧客サポート対応などが該当します。限られた担当者だけがログイン後に長時間開きっぱなしで何度も操作するのが特徴です。

「SEO」とは？なぜToCには必要で、管理画面には不要なのか

SEO（Search Engine Optimization：検索エンジン最適化）とは、Googleなどの検索ロボット（クローラー）にWebページの内容を正しく読み取ってもらい、検索結果で見つけてもらいやすくする対策のことです（実務では、XやLINEなどにURLを貼ったときにタイトルやサムネイル画像を表示させる「OGP対応」もセットで考えます）。

ToC向けの商品ページや記事ページは、検索結果に表示されなければ新しいお客さんに出会えないため、SEOが集客の生命線になります。
一方で、社員専用の「管理画面」はどうでしょうか？そもそも部外者がアクセスしてはいけない非公開ページ（ログイン必須）なので、Googleの検索結果に載せる必要が一切ありません（むしろ検索除けの設定を入れます）。これが原文にある「SEOが不要な管理画面」という意味です。

「SSR（サーバーサイドレンダリング）」とは？

IT用語の「レンダリング（Rendering）」は、データとデザインを合体させて「画面に表示できるWebページ（HTML）を組み立てること」を指します。

SSR（Server-Side Rendering）は、その名前のとおり「サーバー側であらかじめデータ入りのHTMLを完成させてから、ブラウザへ届ける方式」です。レストランに例えるなら、「厨房（サーバー）でシェフが盛り付けまで済ませた完成料理を、お客さんのテーブル（ブラウザ）へ運ぶスタイル」と言えます。

• 強み：届いたHTMLの中に最初から商品名・価格・本文・メタタグがしっかり書き込まれているため、検索ロボットやSNSの巡回プログラムが内容を確実に読み取れます（＝SEO・OGPに強い）。また、スマホの性能に頼らず最初の画面を素早く表示できます。
• 弱み：ページを開くたびにサーバー（厨房）がHTMLを組み立てる計算を行うため、常時稼働するサーバーが必要になり、アクセスが多いほどサーバー側の負荷が高まります。

「SPA（シングルページアプリケーション）」とは？

SPA（Single Page Application）は、最初に「空っぽに近い1枚のHTML枠」と「JavaScriptプログラム」だけをブラウザへ渡し、その後のデータ取得や画面の組み立てをすべて手元の「ブラウザ側（PC・スマホ）」で行う方式です（ブラウザ上でJavaScriptが画面要素を動的に書き換える仕組みについては、DOMの仕組みと役割の記事もあわせてご参照ください）。

先ほどのレストランで例えるなら、「最初にテーブル（ブラウザ）へコンロと鍋だけセットして、あとは手元で具材（データ）を追加しながら次々と調理して食べる焼肉・鍋スタイル」です。

• 強み：一度画面を読み込んだあとは、別メニューへ移動したり検索条件を変えたりしてもページ全体を再読み込みしません。必要なデータ（JSON）だけを裏側で受け取って必要な箇所だけを瞬時に書き換えるため、画面が真っ白にならずデスクトップアプリのようにサクサク軽快に動作します。サーバー側で毎回HTMLを作る負荷もかかりません。
• 弱み：最初にサーバーから届くHTMLの中身がほぼ空っぽなため、検索ロボットやSNSのリンクプレビューがページ内容を読み取りにくく、SEOやSNSシェアを重視する公開ページには不向きです。

「React Router」とは？（画面切り替え役から統合フレームワークへ進化）

最後に主役となるReact Router（リアクト・ルーター）です。これは、現代のWeb画面開発で広く使われているUIライブラリ「React」において、「どのURLにアクセスされたら、どの画面部品を表示し、どうやってデータを読み込むか」を司る定番ツールです（ベースとなるJavaScriptのモダン仕様についてはECMAScriptとは？JavaScriptとの違いや歴史で解説しています）。

かつてのReact Routerは「SPAの中でURLに応じて画面を切り替えるライブラリ」として使われていました。しかしReact Router v7で、SSRを得意としていたフルスタックフレームワーク「Remix（リミックス）」の機能が統合されたことで大きく進化しました。
その結果、現在のReact Router（フレームワークモード）は「SSRも、SPAも、さらにはページ単位での両者の使い分けも、これ1つで自在に扱えるフレームワーク」となっています。

同じアプリ内でURLごとに切り替える方法（loader と clientLoader）

React Router（v7 フレームワークモード）のとても便利な特徴が、1つのプロジェクトの中で、URL（ルートファイル）ごとに「サーバーでデータを取るか」「ブラウザだけでデータを取るか」を選べることです。

たとえば、ルーティング設定ファイル（app/routes.ts）で、一般公開ページと管理画面のURLを次のように定義します。

// app/routes.ts（URLと画面ファイルの対応表）
import { type RouteConfig, index, route, prefix } from "@react-router/dev/routes";

export default [
  // 一般のお客さん向け（ToC向け画面）→ SSRで動かす
  index("routes/home.tsx"),
  route("products/:id", "routes/product-detail.tsx"),

  // 社内スタッフ向け（管理画面）→ SPAとしてブラウザ主導で動かす
  ...prefix("admin", [
    index("routes/admin-dashboard.tsx"),
    route("orders", "routes/admin-orders.tsx"),
  ]),
] satisfies RouteConfig;

まず、ToC向けの商品詳細ページ（SSR）では、サーバー側で実行される loader 関数とSEO用の meta 関数を使います。これにより、商品名や説明文が最初から埋め込まれたHTMLがサーバーから配信されます。

// app/routes/product-detail.tsx（ToC向け画面：SSR）
import type { Route } from "./+types/product-detail";

// サーバー側で実行され、DBやAPIから商品データを取得する
export async function loader({ params }: Route.LoaderArgs) {
  const res = await fetch(`https://api.example.com/products/${params.id}`);
  const product = await res.json();
  return { product };
}

// SEO・SNSシェア用のタイトルや説明文もサーバー側でHTMLに出力される
export function meta({ data }: Route.MetaArgs) {
  return [
    { title: `${data?.product.name} | サンプルショップ` },
    { name: "description", content: data?.product.summary },
  ];
}

export default function ProductDetail({ loaderData }: Route.ComponentProps) {
  const { product } = loaderData;
  return (
    <main>
      <h1>{product.name}</h1>
      <p>価格：{product.price}円</p>
    </main>
  );
}

次に、SEOが不要な管理画面（SPA動作）では、サーバー用の loader を書かずに、ブラウザ上だけで実行される clientLoader と、データ読込中の待機画面 HydrateFallback を定義します。

// app/routes/admin-dashboard.tsx（管理画面：ブラウザ完結のSPA動作）
import type { Route } from "./+types/admin-dashboard";

// サーバーを経由せず、ブラウザ（クライアント）側だけでAPI通信を行う
export async function clientLoader() {
  const token = localStorage.getItem("admin_token") ?? "";
  const res = await fetch("https://api.example.com/admin/stats", {
    headers: { Authorization: `Bearer ${token}` },
  });
  return await res.json();
}

// ブラウザ側でデータ取得が終わるまでの間に表示するローディングUI
export function HydrateFallback() {
  return <p>管理画面データを読み込み中です...</p>;
}

export default function AdminDashboard({ loaderData }: Route.ComponentProps) {
  return (
    <section>
      <h1>売上・注文ダッシュボード</h1>
      <p>本日の注文数：{loaderData.todayOrders}件</p>
    </section>
  );
}

このように書くだけで、管理画面の重い集計通信はSSRサーバーを通らずブラウザとバックエンドAPIの間で直接やり取りされ、画面遷移もSPAとして軽快に動くようになります。

公開サイトと管理画面でプロジェクトを分け、管理側を「ssr: false」にする方法

もう1つ、実務でよく使われるのが「お客さん向けサイト（例：shop.example.com）」と「社内管理画面（例：admin.example.com）」を別々のアプリとしてビルド・配信する構成です（サブドメインの仕組みについてはサブドメインの仕組みとサブディレクトリとの違いでも解説しています）。

React Routerの設定ファイル（react-router.config.ts）には、わずか1行でSSRとSPAモードを切り替える設定が用意されています。

// 管理画面アプリ側の react-router.config.ts
import type { Config } from "@react-router/dev/config";

export default {
  // ToC向けアプリでは true（既定値）、管理画面アプリでは false にするだけ！
  ssr: false,
} satisfies Config;

管理画面側を ssr: false（SPAモード）にすると、ビルド時に静的なHTML・CSS・JavaScriptファイルだけが出力されます。そのため、管理画面のためだけにNode.jsサーバーを動かす必要すらなくなり、Amazon S3やCloudflare Pagesなどの安価で手軽な静的ファイル置き場へそのまま配置できるようになります。
それでいて、ToC向け画面と管理画面のどちらも「React ＋ React Router」という共通の書き方・共通のボタンやフォーム部品で開発できるため、「表側はフレームワークA、管理画面は別のライブラリB」とバラバラに作るのに比べて、学習コストや保守の手間を大きく減らせるのです。

• 管理画面の権限チェックは必ずバックエンドAPI側でも行う：SPAはブラウザ上で動くため、画面上の見た目としてボタンを隠すだけではセキュリティ対策として不十分です。「ログイン中の担当者に本当にそのデータを閲覧・更新する権限があるか」のチェックは、データを提供するAPIサーバー側で必ず実施してください。
• サーバー専用の秘密情報をブラウザ側に混ぜない：1つのプロジェクト内でSSR（loader）とSPA（clientLoader）を混在させる場合、データベースの接続キーや外部サービスの秘密鍵は *.server.ts のようなサーバー専用ファイルに閉じ込め、ブラウザへ配信されるコードに含まれないように分離して管理しましょう。

本記事のまとめ

• 検索やSNSから初めてのお客さんを集めたい「ToC向け公開画面」には、完成済みHTMLを届けるSSRが向いている。
• 社員だけがログインして使い、検索に出す必要（SEO）がない「管理画面」には、ブラウザ上で軽快に動くSPAが向いている。
• React Routerを使えば、loader と clientLoader の使い分け（または ssr: false 設定）によって、別々のフレームワークを覚えなくても1つの技術スタックでこの適材適所の構成を実現できる。