SPAとマイクロフロントエンドが噛み合う理由

SPAは「画面遷移をしないWeb」であり、だからマイクロフロントエンドと相性が良い

SPAがマイクロフロントエンドと相性が良い理由は単純です。
SPAはもともと「1つのページの中に複数のアプリケーションを同居させる設計」だからです。

マイクロフロントエンドは「フロントエンドを分割して複数チームで独立開発する」アーキテクチャですが、従来のMPA（ページ遷移型Web）ではこれが非常に困難でした。
なぜならMPAはページ単位でシステムが分かれるからです。

しかしSPAでは画面遷移をJavaScriptが管理します。
つまり、URLは変わってもブラウザはページを再読み込みしません。
この「再読み込みしない」という性質が、マイクロフロントエンド成立の土台になります。

MPAでフロントエンド分割が難しい本当の理由

MPAで分割が難しいのは、単に技術が古いからではありません。
ブラウザの動作モデルが原因です。

ページ遷移時、ブラウザは必ず次の動作をします。

• 現在のJavaScriptを破棄
• DOMを全削除
• 新しいHTMLをロード
• 新しいJSを実行

つまり、ページごとに「完全に別のアプリ」が動いている状態になります。
この構造では、同一画面上に別チームのUIを常駐させることができません。

例：ECサイト

• 商品検索（チームA）
• カート（チームB）
• レコメンド（チームC）

MPAではこれらはページごとに分断されます。

SPAでは「1つのOSの上に複数アプリ」が動く

SPAになると状況が変わります。
SPAはブラウザの中に「アプリケーションランタイム」を持ちます。いわば小さなOSのようなものです。

ルーターがURLを監視します。

router.push("/cart");

この時ブラウザはページ遷移しません。
代わりに、特定のコンポーネントだけを差し替えます。

つまりSPAでは、

• DOMは消えない
• JavaScriptプロセスは継続
• 状態が保持される

この性質により、同一ページ上に複数の独立アプリを常駐させることが可能になります。
これがマイクロフロントエンドとSPAの相性が良い理由です。

マイクロフロントエンドの正体は「ルーティングの分散管理」

マイクロフロントエンドは難しそうに聞こえますが、本質はシンプルです。

URLの管理責任をチーム単位に分割する設計です。

例：

パス	担当チーム
/search	検索チーム
/cart	カートチーム
/account	会員チーム

SPAではルーターが画面描画を支配しています。
このルーターを「親アプリ」が持ち、配下に子アプリを読み込むことでマイクロフロントエンドが成立します。

実際の実装は「アプリを後から読み込む」

マイクロフロントエンドの典型的な実装は遅延ロードです。

import("https://cart.example.com/app.js");

ユーザーがカートを開いたときだけ、カートアプリをダウンロードして起動します。
この時、検索アプリは動いたままです。

つまり1つのWebページに複数のSPAが同居します。

なぜSSRでは難しくなるのか

SSRはリクエストごとにHTMLを生成します。
サーバが画面構造を決定するため、フロントエンド単体では独立できません。

マイクロフロントエンドは「フロントエンドだけで画面を構成する」思想です。
したがって、サーバ中心のレンダリングと衝突します。

具体的には次の問題が起きます。

• 各アプリのビルドが同期必要
• HTMLテンプレートの責任が曖昧
• デプロイの独立性が消える

SPAはクライアントが画面の最終決定権を持つため、この問題が発生しません。

実際に起きるメリット

マイクロフロントエンドをSPAで採用すると、現場で体感できる変化があります。

• チームごとにデプロイ可能
• フロントエンドの巨大化を防げる
• 技術スタックを分離できる
• 障害の影響範囲が限定される

例えば検索機能が落ちても、カートは動き続けます。
これはMPAでは実現しにくい特性です。

ただし大きな落とし穴がある

メリットばかりではありません。
最も多い失敗は「分割しすぎ」です。

マイクロフロントエンドはアプリを分けるため、次の問題が発生します。

• JSファイル数が増加
• 初回ロードが遅くなる
• デザイン統一が崩れる
• グローバル状態管理が複雑化

特に状態共有（ログイン状態、テーマ、通知）は難しくなります。
ReduxやEventBusなどの共有基盤が必要になります。

向いているケース

• 大規模組織
• 10人以上のフロントエンド開発
• 複数ドメインのサービス統合

小規模プロジェクトでは逆に管理コストが増えます。

どう考えると理解しやすいか

マイクロフロントエンドは「画面分割」ではありません。
組織構造をソフトウェアに反映する設計です。

SPAはページを再読み込みしないため、1つのブラウザ上に複数のアプリケーションを常駐させられます。
だからこそチーム単位でUIを持つマイクロフロントエンドと自然に噛み合います。

SPAの本質は「ブラウザをアプリケーション実行環境にする」ことです。
そしてマイクロフロントエンドは、その実行環境の中に複数のサービスを配置するアーキテクチャです。

この2つは偶然相性が良いのではありません。
設計思想が同じ方向を向いているため、結果として自然に結びついているのです。