先に要点
SPA ってよく聞くけど、結局どういう作り方なの？ React や Vue を使えば自動で SPA になるの？ という疑問はかなり多いです。
特にフロントエンドを触り始めたばかりだと、SPA、SSR、CSR、MPA が一気に出てきて混乱しやすいです。
この記事では、SPA の基本から、メリット・デメリット、どう実現するのか、どんな案件で向いているのかまでを初心者向けに整理します。
まず大前提として、SPA は 流行っているから採用するもの ではなく、画面の使われ方に合わせて選ぶもの です。
SPAとは何か
SPA は Single Page Application の略です。
ざっくり言うと、最初に読み込んだ 1 枚の HTML を土台にして、以降は JavaScript で画面の中身だけを差し替えながら動く Web アプリの作り方です。
たとえば、管理画面で一覧から詳細へ移ったり、タブを切り替えたり、検索条件を変えたりするときに、毎回ページ全体が真っ白から読み直されるのではなく、必要な部分だけ差し替わるイメージです。
注意したい点
SPA だから必ず速い、というわけではありません。最初の JavaScript が重いと、逆に初回表示は遅く見えることがあります。
MPAとの違いは何か
比較対象としてよく出るのが MPA です。
MPA は Multi Page Application の略で、ページを移るたびに新しい HTML をサーバーから受け取る作り方です。
| 観点 | SPA | MPA |
|---|---|---|
| 画面遷移 | 中身だけ切り替える | ページ全体を読み直す |
| 初回表示 | JavaScript が重いと遅くなりやすい | HTML を返せるので分かりやすい |
| 操作感 | 軽く見せやすい | 遷移ごとのリロード感が出やすい |
| SEO | 工夫が必要なことがある | サーバー側で HTML を返しやすい |
| 向いている場面 | 管理画面、会員画面、社内ツール | コーポレートサイト、記事サイト、EC の公開ページ |
ここで大事なのは、どちらが上か ではなく 何を作るかで向き不向きが違う ことです。
たとえば、記事中心の公開サイトなら MPA や SSR の方が素直なことが多いですし、逆に入力や操作が多い画面では SPA の方がかなり扱いやすいです。
SPAのメリット
1. 操作感を軽くしやすい
SPA の一番分かりやすい強みはここです。
一覧と詳細の切り替え、モーダルの表示、検索条件変更、タブ切り替えのような操作が多い画面では、全部を再読み込みしないだけでも体感がかなり変わります。
2. 状態を持ったまま動かしやすい
フォームの入力途中、絞り込み条件、タブの開閉状態のような その場の状態 を保ちながら画面を組み立てやすいのも SPA の強みです。
管理画面やダッシュボードでよく使われる理由はここにあります。
3. フロントと API を分けやすい
SPA は、画面と API を分離した構成と相性がよいです。
フロントエンドは React や Vue、バックエンドは Laravel や Django という組み合わせにしやすく、役割を分けて開発したいときに便利です。
SPAのデメリット
1. 初回表示が重くなりやすい
一見軽そうに見えますが、最初に JavaScript をたくさん読み込むと初回表示は重くなります。
特に、公開ページなのに大きなバンドルを最初から読み込む構成だと、利用者から見ると「反応が遅いサイト」になりやすいです。
2. SEOやOGPで気をつける点が増える
SPA は CSR だけで組むと、ブラウザ側で JavaScript が動いて初めて画面が完成するため、検索エンジンや OGP の扱いで気をつける点が増えます。
いまは検索エンジンもかなり賢くなっていますが、だからといって 何もしなくてよい わけではありません。
このあたりの背景を広く見たいなら、CORSとは？初心者がつまずきやすい原因と考え方をわかりやすく解説 や Next.jsは他のフレームワークと何が違う？｜React単体・Nuxt・バックエンド系との比較で整理 もつながりやすいです。
3. 設計をごまかしにくい
データ取得、状態管理、ルーティング、認証、エラー表示、読み込み中の扱いまで考える必要があるので、規模が大きくなるほど設計の雑さが表に出ます。
とりあえず動いた のまま増やしていくと、あとからかなりつらくなりやすいです。
SPAはどうやって実現するのか
実装の基本は、次の 4 つです。
| 要素 | 役割 | 例 |
|---|---|---|
| 画面部品 | UI を作る | React / Vue |
| ルーティング | URL と画面を結びつける | React Router / Vue Router |
| データ取得 | API からデータを取る | fetch / Axios |
| 状態管理 | 画面の状態を持つ | useState / Context / Zustand |
たとえば React で SPA を作るなら、流れはだいたいこうです。
- React で画面コンポーネントを作る
- React Router で
/usersや/settingsのようなルーティングを組む - API から JSON を取得して一覧や詳細を描画する
- フィルター条件やログイン状態を保持する
Vue なら、同じ考え方で Vue Router と状態管理を組み合わせます。
ReactやVueを使えば自動でSPAになるのか
半分正解で、半分違います。
React や Vue は SPA を作りやすい道具ですが、使ったら自動で最適な SPA になる わけではありません。
どの画面をクライアント側で持つのか、URL をどう切るのか、初回に何を読み込むのか、どのデータをキャッシュするのかは、やはり自分で決める必要があります。
Next.jsやNuxtはSPAなのか
ここは初心者がかなり混ざりやすいところです。
Next.js や Nuxt は SPA も作れますが、SPA 専用の道具ではありません。
これらは SSR や SSG も含めて選べるフレームワークです。
つまり、SPAの実現もできるし、SPAにしない選択もできる のが実際のところです。
実務でどんな場面に向いているか
SPA が特に向いているのは、次のような場面です。
- 社内管理画面
- 会員向けダッシュボード
- 入力と一覧操作が多い業務アプリ
- リアルタイム更新や細かい UI 反応が必要な画面
逆に、最初から全部 SPA にしなくてもよいのはこんな場面です。
- 記事中心のオウンドメディア
- 検索流入が大事な公開ページ
- 更新頻度が低い会社サイト
- 小さな LP や静的ページ群
小規模サービスでどこまで作り込むかの考え方は、小規模サービスのインフラはどこまで作り込むべき？最初にやりすぎない考え方を整理 にも通じます。
技術的に作れることと、最初からそこまで作るべきかは別で考えた方が安全です。
よくある誤解
SPAにすれば速くなる
半分だけ正しいです。
画面遷移の体感は軽くしやすいですが、初回表示や JavaScript の重さまで自動で解決するわけではありません。
SPAの方が今っぽいから正解
これも違います。
公開サイトで検索流入が大事なら、SSR や MPA の方が素直なことは普通にあります。
今っぽいか より 要件に合っているか で見る方が実務的です。
APIを使えば全部SPA
API を使っていても、画面側の作りが MPA のことはあります。
SPA かどうかは API の有無ではなく、画面遷移や描画をどこでやっているか で見た方が分かりやすいです。
まとめ
SPA は、最初に読み込んだページを土台にして、中身だけを書き換えながら動く Web アプリの作り方です。
操作感を軽くしやすく、管理画面や会員画面ではかなり相性がよい一方で、初回表示、SEO、状態管理、データ取得の設計をきちんと考える必要があります。
大事なのは、SPA にできるか ではなく SPA にした方が本当に扱いやすいか です。
React や Vue は SPA を実現しやすい道具ですが、Next.js や Nuxt のように SPA 以外も選べるフレームワークとどう使い分けるかまで考えると、判断しやすくなります。
Next.js 側から見た違いも合わせて整理したいなら、Next.jsは他のフレームワークと何が違う？｜React単体・Nuxt・バックエンド系との比較で整理 も続けて読むとつながりやすいです。
参考リンク
- MDN: Single-page application
- web.dev: Rendering on the Web
- React: Create a React App - Alternatives
- Vue: Ways of Using Vue