SPAとMPAの選択基準を実務で決める方法

SPA/MPAの議論が揉めやすいのは、技術選定そのものより「同じ言葉で別のものを話している」状態が起きやすいからです。SPAが「Reactのこと」になったり、MPAが「古い作り」になったりすると、前提がズレたまま結論だけが先に決まり、後工程で必ず手戻りが発生します。まずは構造としての定義と、そこから生まれる負担の種類を分けておくと、比較が好みではなく設計判断として安定します。

本記事では、SPA/MPAを「画面遷移の作法」と「責務の置き方」の違いとして整理し、さらにレンダリング方式（CSR/SSR/SSG）を別軸として切り出します。ここを分離すると、「SPAはSEOに弱い」「MPAは速い」といった短いラベルが、どの条件では成り立ち、どの条件では崩れるのかが見えるようになります。結果として、必要以上に極端な選択を避け、入口ページ・作業画面・運用体制といった現実の制約へ議論を接続しやすくなります。

比較のゴールは「どちらが優れているか」を決めることではなく、「自分たちのプロダクトにとって重い論点はどれか」を特定することです。検索流入が勝負のサイトと、ログイン後に長く使う業務アプリでは、同じ「速い」でも意味が違いますし、同じ「運用」でも負担が出る場所が変わります。以降は、構造の定義→負担の出方→選定を左右する前提→誤解が起きるプロセス→判断軸の絞り込み、という順で、現場で合意形成に使える形へ落としていきます。

1. SPAとは

SPA（Single Page Application）とは、単一のHTMLを起点として、以後の画面切り替えを主にブラウザ上のJavaScriptで制御するアプリケーション構造です。URLの変化はクライアント側のルーターで扱われ、必要なデータはAPIなどから取得し、画面はコンポーネントの再描画や差分更新として表現されます。ページ全体の再読み込みを避け、状態を維持したまま操作を続けられる設計が中心になる一方、状態管理・境界設計・データ整合性が品質を左右する比重が大きくなります。

この定義を押さえる理由は、混同が原因で意思決定が「後付け」に流れやすいからです。例えば「SPAにしたら速くなるはず」と期待して始めた結果、初期ロードが重くなり、SEOや計測の問題が出て、さらにSSRやキャッシュを継ぎ足して複雑化することがあります。SPAは強力ですが、同時に「フロントが抱える責務が増える構造」であることを前提にしないと、運用フェーズで破綻しやすくなります。

2. MPAとは

SPAと対比されるMPAも、誤解されやすい言葉です。「昔ながら」「体験が弱い」といった印象だけで評価すると、検索流入や運用性の強みを見落とします。ここではMPAを、単なる実装スタイルではなく、責務の切り方として捉え直します。

MPA（Multi Page Application）とは、URLごとに独立したページを持ち、ページ遷移のたびにサーバーからHTMLを取得して画面を構成するアプリケーション構造です。典型的にはサーバーサイドでHTMLを生成し、リンク遷移はHTTPリクエストとして完結します。ページ単位で責務を分離しやすく、障害や変更の影響範囲を切り分けやすい特徴があります。

この定義が役立つのは、MPAの価値が「速度」より「運用の確実性」に現れやすいからです。検索やSNSから流入して最初の1ページが勝負になるサイトでは、ページ単位で意図を明確にし、構造を安定させることが成果に直結します。MPAは、必要なところだけJavaScriptを濃くする設計とも相性が良く、全面的にアプリ化する前に「痛点の解消」へ投資しやすい構造でもあります。

3. レンダリング方式（CSR・SSR・SSG）とは

SPA/MPAの議論が噛み合わない原因のひとつが、構造とレンダリング方式が混ざることです。「SPAはSEOに弱い」「MPAは速い」といった短い結論は、たいていこの混線から生まれます。ここを分けて整理しておくと、後半の判断が一気に現実的になります。

CSR（Client Side Rendering）は、ブラウザでJavaScriptを実行してDOMを組み立てる方式です。SSR（Server Side Rendering）は、サーバーでHTMLを生成して初期表示を整えたうえで、必要に応じてクライアント側でイベントを結び直す形になります。SSG（Static Site Generation）は、ビルド時にHTMLを生成して配信し、更新頻度やパーソナライズ要件が弱いページで高い効果を発揮します。

重要なのは、SPAでもSSR/SSGを併用できますし、MPAでもCSR的な部分更新を取り入れられる点です。検索エンジン側の挙動も絡むため、JavaScriptを使うサイトは「クロール・レンダリング・インデックス」という処理の流れを理解した上で設計すると、後からの手戻りが減ります。

4. SPAとMPAの基本構造を理解する

ここまでの定義を踏まえると、比較は「体験の好み」ではなく「構造の違いがどこに負担として現れるか」に置き換えられます。以降は、現場で頻出する論点に沿って、SPAとMPAがどのように設計・運用へ影響するかを具体的に見ていきます。

4.1 SPAの仕組みと特徴

SPAは「状態」と「遷移」を中心に設計が組み立ちます。ログイン状態、フィルタ条件、編集中フォーム、未保存の変更、一覧のスクロール位置など、ページをまたいで保持したい情報が多いほど、SPAの価値は上がります。その反面、状態が増えるほど複雑性も増し、状態の所在が曖昧になると、バグが「直したのに別の場所が壊れる」形で表面化しやすくなります。

またSPAはAPI駆動になりやすく、フロントとバックエンドの境界をどう引くかが勝敗を分けます。APIが揺れるとフロントが帳尻合わせを背負い、結果としてビジネスロジックがUI層へ散らばることがあります。逆に境界が固まれば、UI改善のスピードは出やすく、操作中の体験を一貫させやすくなります。

4.2 MPAの仕組みと特徴

MPAは「ページ」を単位に責務を切りやすく、運用時の説明コストが下がりやすい構造です。会社概要、採用情報、記事詳細、商品詳細のように、URLごとに目的が明確で、ページ間で共有する状態が少ない場合、MPAは設計も運用も安定します。障害が起きても影響範囲がページ単位で限定されやすく、復旧判断がしやすいのも実務的な強みです。

一方で、共通UIの改善やデザインの統一を横断的に進める場合は、共通テンプレートやコンポーネントの責務設計が必要になります。MPAは「ページ単位で壊れにくい」代わりに、「全体の一貫性は設計と運用で作る」構造だと捉えると、期待値が適正化されます。

4.3 構造比較のポイント（表）

比較は結論を押し付けるためではなく、議論の座標を揃えるための道具です。よく揉めるポイントを、現場で使いやすい観点に落とすと次のようになります。

この表を使うときは、「自社で重いのはどの行か」を先に決めるのがコツです。例えば検索流入が主戦場ならSEOと初期表示の行が重くなりますし、業務アプリなら遷移と運用（変更影響の管理）の行が重くなります。

5. 選択基準を考える前に整理すべき前提

構造の比較ができても、前提が曖昧だと結論は安定しません。特に「目的」と「ユーザー行動」と「運用体制」が揃っていない状態で、SPA/MPAを決め打つと、後から仕様変更のたびに構造が揺れます。ここでは、選定の前に言語化しておきたい前提を整理します。

5.1 プロジェクトの目的を言語化する

同じWebでも、集客装置と業務装置では成功条件が違います。前者は検索・回遊・問い合わせ、後者は操作性・誤操作防止・処理時間短縮が効きます。「速い」という言葉ひとつ取っても、前者では初期表示の速さ、後者では操作応答の速さが重視されるなど、意味が変わります。

会議では「このWebは何を増やす装置か」と言い換えると整理が進みます。例えば「検索流入を伸ばす装置」「既存顧客の工数を減らす装置」「申込み完了率を上げる装置」といった具合です。目的が揃うと、SEO・体験・コストの優先順位が自然に決まり、構造の議論も現実の制約へ接続しやすくなります。

5.2 ユーザー行動の特性を読む

ユーザーがページを「読む」のか「操作する」のかで、必要な最適化が変わります。読む行動が中心なら、独立したページが入口になり、検索やSNS流入が増えやすい構造になります。操作が中心なら、画面の行き来よりも、作業途中の状態維持、フィードバックの一貫性、入力ミスの防止が価値になります。

例えば採用サイトや記事は「読む」が中心で、MPAの強みが出やすい領域です。対して在庫管理や広告運用の管理画面は「操作」が中心で、フィルタ条件や編集中状態を保持したいのでSPAが効きやすいです。ここを曖昧にすると、コンテンツ側に過剰なアプリ性を持ち込み、逆にアプリ側がページ都合で分断される、といった不自然な構成になりがちです。

5.3 チームの技術スタックと運用体制を前提に置く

最終的に勝つのは「運用できる構造」です。SPAはフロントの責務が増え、状態管理・エラーハンドリング・計測・自動化が弱いと破綻します。MPAはページ運用が回しやすい一方、テンプレート設計や情報設計、SEO運用の知見が属人化すると詰まります。

ここで現実的な観点は「今の体制が抱えられる複雑性の上限」です。フロント専任がいるのか、設計レビューが回るのか、監視やロールバックの運用ができるのか、採用や外注を含めて同じ水準を維持できるのか、といった要素が選択を左右します。技術の優劣ではなく、運用の継続可能性を中心に据えると判断が安定します。

6. よくある誤解と混同が起きるプロセス

選定の失敗は、たいてい「誤解が起き、放置され、悪化する」流れで進みます。とくにSPA/MPAは言葉が短い分、都合の良い解釈が入りやすく、後から修正しようとしても利害関係が増えて難しくなります。ここでは、現場で繰り返される混同のパターンを具体例で押さえます。

典型例は「SPA＝速い」「MPA＝SEOに強い」「SSR＝万能」といった短いラベルで決めてしまうことです。原因は、比較対象が曖昧で、「速い」が初期表示なのか操作応答なのか共有されていない点にあります。発生すると、最初は雰囲気で進み、次に初期表示やインデックスの問題が出た段階で「SSRを足せばいい」と継ぎ足しになり、さらに運用で状態管理やAPI整合性が重くなって改修コストが跳ね上がります。検索エンジン側もJavaScriptの処理に段階があるため、入口設計を誤ると「表示はできるが発見されない」という形で損失が出やすくなります。

この悪化を止めるには、構造（SPA/MPA）とレンダリング（CSR/SSR/SSG）を分けて議論し、成功条件を数値と運用ルールに落とすことが必要です。さらに「どの領域は検索の入口で、どの領域は作業の場か」を最初に線引きしておくと、後付けの継ぎ足しが減ります。

7. 選択基準の中核を3〜5点に絞って深掘りする

ここから先は、比較表だけでは決めきれない「本質的に効く論点」を絞り込みます。ポイントは、たくさんの評価軸を並べることではなく、後で必ず揉める論点を先に押さえることです。実務では次の4つを押さえるだけでも、選定がかなり安定します。

7.1 状態の複雑さはどこにあるか

SPAが向くかどうかは、ページ数より「状態の密度」で決まります。例えば、検索条件が多い一覧から詳細を開き、戻っても同じ絞り込み状態で作業を続けたい業務アプリは、状態保持が価値になります。逆に、記事や静的ページのように、戻ったときに状態がリセットされても問題になりにくい領域は、SPAの複雑性を抱える必然性が薄くなります。

設計で決めたいのは、状態を「URLに持たせる」「ブラウザメモリに持つ」「サーバーに持つ」のどこに置くかです。ここが曖昧だと、共有リンクが再現できない、戻ると壊れる、権限で表示がズレる、といった問題が起きます。会議では「状態が増えるほどSPAは強いが、同時に設計の負担も増える」という前提を置くと、期待値が現実に寄ります。

7.2 データ取得と整合性の責務を誰が持つか

SPAはAPIからデータを取りに行く回数が増え、「いつのデータが正か」をUIが扱う場面が増えます。例えば一覧に出ている在庫数と詳細編集後の在庫数がズレる、権限変更が反映されない、同時編集で競合が起きる、といった問題は、体験の不満だけでなく業務事故にもつながります。リアルタイム性が強いほど、更新通知、競合解決、再試行の設計が必要になり、単なる画面実装を超えた設計課題になります。

MPAは遷移ごとに再取得するため整合性は取りやすい傾向がありますが、ページ間で共有したい情報があると、セッション設計やキャッシュ制御が重要になります。どちらにしても「整合性の最終責務はサーバー」「UIは楽観的に見せるが確定はサーバー」といった役割分担を決めておくと、トラブル時の切り分けが速くなります。

7.3 変更頻度と配布単位をどう設計するか

SPAは共通UIや共通状態を横断で改善しやすい一方、変更が広範囲へ波及しやすい構造でもあります。共有コンポーネントを更新したら別画面の挙動が変わった、といった回帰は、規模が大きいほど起きやすくなります。したがってSPAを選ぶなら、回帰テストや段階的リリース、フィーチャーフラグなど「変更を安全に配る仕組み」もセットで考える必要があります。

MPAはページ単位で更新を切りやすく、影響範囲の説明がしやすい反面、全体の統一感を保つには設計ルールが要ります。ここは「配布単位をアプリに寄せるか、ページに寄せるか」という言い換えが有効です。どちらを重視するかで、設計の優先順位が変わり、チームの運用も変わります。

7.4 障害時の切り分けと復旧の設計

障害が起きたとき、MPAはページ単位で症状が出やすく、原因の切り分けがしやすいことが多いです。一方SPAは、初期ロード資産やルーティング、状態管理が壊れるとアプリ全体が使えなくなる形で表面化しやすく、復旧設計の重要度が上がります。管理画面のように停止が業務停止に直結する領域では、ロールバックや簡易モードのような「止まったときの作法」まで含めて構造を選ぶ方が安全です。

8. SPAを選ぶべきケースと判断基準

中核論点を踏まえたうえで、次は「どんな条件ならSPAが合理的か」を具体化します。SPAの価値は、画面遷移が滑らかになること自体より、作業の途中状態を保ち、操作の文脈を途切れさせない点にあります。以下では現場で判断材料になりやすいパターンを挙げます。

8.1 高いインタラクションが必要な場合

ダッシュボード、SaaS、業務管理画面のように、短時間に多くの操作が行われる領域ではSPAの効果が出やすいです。フィルタやソート、複数タブの参照、フォーム入力、バリデーション、差分保存などが連続すると、ページ全体の再読み込みは心理的負担になります。SPAは状態を維持したまま必要な部分だけ更新できるため、応答の一貫性が作りやすく、入力ミスや離脱を減らしやすくなります。

判断の目安は「途中状態が価値になるか」です。一覧で絞り込んだ状態のまま複数詳細を見たい、編集途中で別画面を参照したい、戻っても作業が続けられるべき、といった要件が強いならSPA寄りです。逆に、単発閲覧や単純フォーム中心なら、SPAの複雑性が費用対効果に見合わないことがあります。

8.2 リアルタイム性が求められる場合（箇条書き）

リアルタイム性は「便利そう」という理由で要件化されやすい一方、設計負担も大きいです。必要性が本物かどうかを見極めるために、次のような状況があるかを確認すると判断がしやすくなります。

・画面を見ている最中に更新が入り、その差分が価値になる（チャット、通知、監視ダッシュボード）
・複数人が同時に触る可能性があり、競合やロックの設計が必要になる（共同編集、承認フロー）
・表示中の数値が頻繁に変わり、古い値を見せることが事故につながる（在庫、価格、残席）

これらに当てはまる場合、SPAは更新体験を統一しやすい反面、イベント順序、再接続、整合性、競合解決が難所になります。リアルタイムはUIの要件であると同時に、整合性と復旧の要件でもある点を押さえておくと、無理な期待値を下げられます。

8.3 UI一貫性を重視する設計思想

SPAはアプリ全体を統一しやすく、デザインシステム、入力コンポーネント、通知、権限表示などを横断で揃えやすい構造です。業務アプリでは操作方法が画面ごとにブレることがミスの温床になるため、一貫性は直接的な価値になります。学習コストが下がるほど、オンボーディングやサポート負荷も下がり、運用コストへ効いてきます。

ただし統一は、共有の増加と表裏一体です。共通化が進むほど、変更影響が広がり回帰リスクが上がるため、コンポーネントの責務分割、状態の扱い、テスト範囲を設計で先に決める必要があります。「統一したい」だけでSPAに寄せると、改善のたびに緊張感が増す状態になりやすいので、統一を支える運用設計とセットで判断するのが現実的です。

9. MPAを選ぶべきケースと判断基準

次に、MPAが強く機能する条件を整理します。MPAは「アプリ体験が弱い構造」ではなく、「ページ単位で目的と責務を固定しやすい構造」です。検索やコンテンツ運用、独立運用が効く領域では、意思決定と運用のコストを下げる方向に働きます。

9.1 SEOを最優先する場合

検索流入が成果の中心で、各ページが独立した着地地点になる場合、MPAは入口ページを作りやすい構造です。もちろんJavaScriptでも検索対応はできますが、検索エンジン側はクロール・レンダリング・インデックスという段階で処理するため、入口での設計ミスが「発見されない」「評価されない」形で損失になり得ます。JavaScriptを使うサイトを検索に乗せる際の考え方は、GoogleのJavaScript SEOガイドが整理しています。

ここでの現実的な落としどころは、入口ページ群をSSR/SSGで固め、ログイン後の操作領域を別に設計することです。つまり「SEOを理由に全体をMPAにする」のではなく、「SEOが効く領域を確実に届ける」ことへ構造を最適化します。入口の確実性を担保できれば、アプリ領域に必要なインタラクションを持ち込む余地も作れます。

9.2 ページ独立性が高い構造（表）

MPAの適性は、ページ間で共有すべき状態が少ないほど上がります。運用担当や更新担当が分散し、ページ単位で責務を切りたい場合も、MPAは説明と管理がしやすくなります。

この表はあくまで目安で、実際は混在します。ECなら商品詳細はコンテンツ的で、カートや決済はアプリ的です。こうした混在を前提に「ページとして強くしたい領域」と「アプリとして強くしたい領域」を分けると、MPAを土台にしつつ部分的にSPA化する戦略が取りやすくなります。

9.3 サーバー主導設計を維持したい場合

権限が複雑で、表示可否や編集可否を厳密に管理する必要がある場合、サーバー主導の設計が安全側に働きます。MPAはページ生成の時点でサーバー側が最終判断を持ちやすく、監査やログの一貫性とも結びつけやすいです。もちろんSPAでも最終判断はサーバーに置けますが、UI側での分岐が増えるほど検証点が増え、実装のばらつきも出やすくなります。

ここは「セキュアにしたいからMPA」という短絡ではなく、「最終責務をどこに置くと、運用上の説明と検証が簡単か」という観点が有効です。統制モデルに合う構造を選ぶほど、事故対応やレビューが型に乗り、結果として開発速度も落ちにくくなります。

10. パフォーマンス観点から見る選択基準

パフォーマンスは、議論が一番盛り上がる一方で、最も誤解が入りやすい領域です。計測対象を決めずに「SPAは重い」「MPAは軽い」と言い切ると、結局どちらも中途半端になります。ここでは、体感を分解し、構造と改善手段を結びつけて整理します。

10.1 初期表示速度と体感速度を分ける

SPAは初回に読み込むJavaScriptが増えやすく、初期表示が不利になりがちです。その代わり、以後の遷移や画面内操作は滑らかにできます。MPAは初期表示が安定しやすい一方、遷移のたびに往復が入り、回遊が多いと体感が落ちることがあります。どちらが良いかは、ユーザーの行動が「最初の1ページで終わる」のか「ログイン後に長く使う」のかで変わります。

ここで決めたいのは、最適化の主戦場です。検索流入が中心なら初期表示と入口の確実性が勝負になりますし、業務アプリなら操作中の応答が勝負になります。「初期の一撃を取りに行くのか、滞在中の体験を取りに行くのか」を先に合意すると、SPA/MPAに求める条件が具体化します。

10.2 キャッシュ戦略の違い

MPAはHTMLやページ単位のキャッシュを設計しやすく、CDNや再検証の運用とも相性が良い傾向があります。SPAは、静的資産（JS/CSS）とAPIレスポンスのキャッシュが中心になり、バージョニングや無効化の運用が難所になります。ここを雑に扱うと「更新が反映されない」「古いデータが残る」「ログイン状態が壊れる」といった事故が起きます。

実務では「何をキャッシュするか」より「何をキャッシュしないか」が重要です。価格、在庫、権限に関わる表示など、誤差が損失に直結するものは、キャッシュより整合性を優先すべき場面があります。選定の時点で、キャッシュの責務（HTML、静的資産、API）と無効化の作法（デプロイ、CDN、バージョン）をセットで決めておくと、後工程の混乱が減ります。

10.3 Core Web Vitalsとの関係（箇条書き）

パフォーマンス議論の共通言語として、Core Web Vitalsを使うと、印象論から抜けやすくなります。Googleは、良好な体験の目安としてLCPは2.5秒以内、INPは200ミリ秒未満、CLSは0.1未満を挙げています。 またINPは、FIDに代わる応答性指標として2024年3月に置き換わった経緯が整理されています。

・LCPは、初期HTMLの薄さや画像・フォント最適化不足で悪化しやすい
・INPは、巨大なJSや過剰な処理、イベントの詰まりで悪化しやすい
・CLSは、後出し描画や枠確保不足で悪化しやすい

ここで重要なのは、SPA/MPAのどちらでも改善可能だという点です。構造を決めると同時に「どの指標を守るか」「誰が計測して、悪化したらどう止めるか」まで決めると、改善が運用に乗ります。逆に計測がないまま構造だけ選んでも、良し悪しが検証できず、議論が永遠に終わりません。

11. 開発・保守コストから考えるアーキテクチャ選定

「作れるか」だけでなく「回せるか」で選ぶと、長期の失敗が減ります。SPA/MPAの違いは、実装の難しさより、運用の負債の生まれ方に出やすいです。ここでは初期開発、長期運用、チーム整合の3点で整理します。

11.1 初期開発コストの見積もり方

SPAはルーティング、状態管理、データ取得、権限、エラー境界など、アプリの土台を先に作る必要があり、初期コストは膨らみやすいです。MPAはページ単位で始めやすい一方、共通テンプレート、情報設計、運用導線（更新手順、CMS、レビュー）を整えるほど、後半のスピードが上がります。どちらも「実装工数」だけで見積もると外れます。

現場で効く問いは「運用の設計が見積もりに入っているか」です。SPAならAPIの変更耐性、計測、段階的配信やロールバック、MPAならテンプレートの責務、ページ追加の手順、構造の管理など、運用の前提を含めた見積もりにすると、後からの利子が減ります。

11.2 長期運用の負債リスク

SPAの負債は、状態と依存関係の絡みとして現れやすいです。共通コンポーネントが便利なほど影響範囲が広がり、設計が弱いと回帰が増えます。MPAの負債は、テンプレートの肥大化や、共通化の不徹底による不一致として現れやすく、結果として改善が行き渡らない歪みが出ます。負債は避けられない前提で、増え方を制御するのが現実的です。

制御の鍵は、責務の置き場所を決めることです。SPAなら「状態の分類ルール」「データ取得の層」「権限判断の原則」、MPAなら「共通テンプレの境界」「ページの目的の固定」「リンク構造の設計図化」といった、守るべき約束を少数に絞ります。約束が多すぎると守られず、少なすぎると崩れるため、運用で回る粒度に揃えることが重要です。

11.3 チームスキルとの整合性

SPAは、フロント設計の成熟度が成果を大きく左右します。レビュー文化が弱い、テストがない、計測がない状態でSPAを大規模化すると、改善のたびにリスクが積み上がります。MPAは、更新運用が回るほど強い一方、情報設計やSEO運用が属人化すると、ページが増えた瞬間に破綻します。どちらも「できる人がいる」ではなく「仕組みとして回るか」で判断すべきです。

会議で合意を取りやすくするために、次のチェック観点を使うと実務的です。

・設計レビューと回帰テストを継続できるか
・データ整合性の責務（最終判断）を誰が担保するか
・ページ追加や機能追加の頻度がどれくらいか
・障害時にロールバックや迂回ができるか
・採用・外注を含めて、運用水準を維持できるか

これらは、技術の好みを争うためではなく、運用可能性を可視化するためのものです。弱い項目が見えたら、構成をシンプルにするか、体制を強くするか、いずれかに寄せる判断が必要になります。

12. SPAかMPAかではなくハイブリッドという選択

現場では「全面SPA」も「全面MPA」も極端で、領域ごとに最適化したハイブリッドに落ちることが多いです。重要なのは、混ぜること自体ではなく、混ぜ方のルールを先に決めることです。ここを曖昧にすると、SSRとCSRが絡み合い、複雑さだけが増えます。

12.1 SSRやSSGを活用した中間設計

検索の入口になるページ群はSSR/SSGで確実に届け、ログイン後の操作領域はSPAで体験を作る、という分割は定番です。JavaScriptを使う場合でも、検索エンジンがどう処理するかを踏まえて入口を設計することで、後からの手戻りが減ります。 入口の確実性を固めたうえで、アプリ領域に必要なインタラクションを集中投資する方が、費用対効果が読みやすくなります。

このとき最初に決めたいのは境界です。「どのURL群が入口で、どこからが作業の場か」「ログイン有無で何が変わるか」「権限が絡むのはどこか」を線引きします。境界が決まると、計測KPIも置きやすくなり、構造の議論が具体化します。

12.2 部分SPA化の戦略

MPAを軸にしながら、特定画面だけSPA的に濃くする方法もあります。例えば商品一覧の絞り込み、予約フォームのステップ入力、地図検索、管理画面の一部など、「操作が集中する箇所」に限定して投資します。全体をアプリ化せずに痛点を解消できるため、運用体制が強くない組織でも採りやすいです。

部分SPA化で大事なのは、統一感を欲張りすぎないことです。見た目は揃えるが、実装単位は揃えない、という割り切りが必要な場面があります。逆に統一が必須の領域は、そこだけをアプリ領域として定義し、責務を集中させる方が結果的に簡単になります。

12.3 現代的フレームワークの動向

近年は、SPA/MPAの二分法だけでは説明しきれない構成が増えています。ReactのServer Componentsは、クライアントに送るJavaScriptを減らしつつ、クライアントアプリやSSRサーバーとは別の環境で事前にレンダリングする考え方として整理されています。 ただしReact側も、周辺の実装（バンドラやフレームワーク）に関わるAPIは変更が起こり得る点を明記しており、採用するなら更新追従を前提に据える必要があります。

Next.js（App Router）では、ページやレイアウトがデフォルトでServer Componentsとして扱われ、必要な箇所だけをClient Componentsにする考え方が説明されています。 こうした潮流は「全部CSRで作るか、全部SSRで作るか」ではなく、「どの責務をどこで実行するか」を細かく選ぶ方向へ進んでいる、と理解しておくと判断がしやすくなります。

13. KPIで判断を固定し、止める条件を入れる

構造選定が宗教戦争になるとき、評価軸が数値に落ちていないことが多いです。KPIは技術を縛るためではなく、選定の結果を検証可能にするためのものです。事業・UX・運用の複数軸で持ち、さらに「悪化したら引き返す条件」まで決めると、議論が前に進みます。

事業KPIの例は、検索流入（表示回数、クリック、CVR）や、ログイン後のタスク完了率、継続率です。UXKPIの例は、Core Web Vitalsの良好率や、操作遅延の報告数、離脱率です。Core Web Vitalsの目安（LCP 2.5秒以内、INP 200ミリ秒未満、CLS 0.1未満）はGoogleが整理しています。 運用KPIの例は、デプロイ頻度、修正リードタイム、ロールバック回数、障害件数などで、改善が回っているかを見ます。

止める条件は、例えば次のように置けます。検索流入が最重要なのに、主要ランディングでインデックス欠損やクロール問題が継続するなら、入口のSSR/SSG比率を上げるなど構成を見直します。操作性を取りに行ったのに、INPが継続的に悪化して改善が追いつかないなら、クライアント責務を減らし、Server寄りの設計へ寄せる判断が現実的です。撤退条件があるだけで、意思決定が「正しいか」から「検証して進めるか」に変わり、運用が安定します。

おわりに

SPAは「単一HTML起点で、画面切り替えを主にブラウザのJavaScriptで制御する構造」であり、価値は遷移の速さそのものより、作業途中の状態や文脈を維持しやすい点にあります。その代わり、状態の増加は複雑性の増加でもあり、境界が弱いと変更が横断し、回帰や不整合が運用フェーズで噴き出します。MPAは「URLごとに独立したページを持ち、遷移ごとにサーバーからHTMLを取得する構造」で、ページ単位の責務分離と復旧判断のしやすさが強みになりやすい一方、全体の統一感は設計と運用で維持する必要があります。

ただし、SPA/MPAだけで結論を作ると、判断が雑になりやすいのも事実です。構造とレンダリング方式（CSR/SSR/SSG）は別の軸で、SPAでもSSR/SSGを併用できますし、MPAでもページ内はCSR的に濃くできます。現場で効くのは「状態の密度」「データ整合性の責務」「変更を安全に配る仕組み」「障害時の切り分けと復旧」といった論点に落とし、どの行が自社で重いかを先に決めることです。議論の焦点が揃うほど、過剰な期待や後付けの継ぎ足しを減らせます。

最終的に勝つのは、作れる構造より回せる構造です。入口の確実性が重要ならSSR/SSGで固め、操作の文脈が重要ならSPA的な領域に投資する、といったハイブリッドは現実解として強い選択肢になります。そのうえで、Core Web Vitalsや事業KPI、運用KPIを「検証できる形」で置き、悪化したら引き返す条件を持つと、選定が宗教戦争になりません。構造は目的を叶えるための制約であり、制約を運用できる形に落とし込めたとき、速度と品質は安定して積み上がります。