Micro Frontend は「過剰設計」か「必然」か
Micro Frontend（MFE）は 2018 年の ThoughtWorks Technology Radar に初登場以来、賞賛と批判の両極を受けてきた。2022-2023 年の「モノレポ + Turborepo」隆盛期には存在感を失ったが、2025 年以降、Module Federation 2.0 の安定化、Rspack の本番実用化、AI エージェントによるチーム生産性格差の拡大——という 3 つの追い風で再び脚光を浴びている。本稿では 2026 年 4 月現在の MFE 技術スタックを概観し、日本の大手金融・SaaS・EC 企業の段階的移行事例を 3 つ紹介する。
Module Federation 2.0: 第二世代の完成
Module Federation は Webpack 5 で 2020 年に導入された、実行時にリモートからモジュールを動的ロードする仕組みだ。2.0 では Rspack チーム（ByteDance）の貢献で Webpack/Rspack 両対応の新 API が整備された。改善点は 3 つ。第一にランタイムプラグインシステムで、「リモート一覧」「共有依存バージョン」を実行時に動的書き換え可能になり、A/B テストやユーザー属性別配信がリロードなしで実現した。第二に型安全性——2.0 は .d.ts をリモートコンテナに同梱し、IDE 補完が効く。第三に Chrome DevTools 拡張「Module Federation Inspector」でロード状況をリアルタイム可視化できるようになった。
Rspack / Vite / Webpack: ビルドツール戦線
Webpack 5 は legacy 的な立ち位置だがエコシステムの厚みで既存大規模プロジェクトの第一選択肢だ。Rspack 1.x は Rust ベースの Webpack 互換ビルダーで速度は 5-10 倍、Module Federation 2.0 を公式サポートし 2025 年以降の定番となった。Vite 6 は @module-federation/vite プラグインでサポートするが、HMR と実行時解決の相性は悪く開発時は experimental 扱いが無難。Turbopack は 2026 年 4 月時点で Module Federation の公式サポートが未実装で、Module Federation を使うなら Webpack/Rspack への退避が現実的だ。
Single-SPA と iframe: もう一つの道
Single-SPA はアプリケーション・シェルが複数の SPA をライフサイクル管理する方式で、フレームワーク異種混在（React + Vue + Angular）が必要な組織にはいまだに最善の選択肢だ。2025 年の 7.0 リリースで起動オーバーヘッドが 40% 削減された。実務で最もバランスが良いのは Module Federation + Single-SPA のハイブリッドで、Single-SPA でマウント制御、Module Federation で依存共有を担う。この構成は Zalando、IKEA、そして後述する日本の事例でも採用されている。
エッジ配信とキャッシュ無効化
MFE の最大のオペレーション課題は「リモートのバージョン整合性」だ。2026 年のベストプラクティスは Immutable Assets + Manifest Indirection。リモートの JS チャンクには内容ハッシュベースのファイル名を付け `max-age=31536000, immutable` で長期保存し、エントリの mf-manifest.json のみを短命キャッシュ（max-age=60、stale-while-revalidate=300）で配信する。manifest がバージョン切り替えのインダイレクションとして働き、エントリを更新すれば次の TTL 経過後に全ホストが新版を取得する。
Cloudflare、Fastly、CloudFront いずれでも manifest をエッジ KV で一元管理する運用が定着した。カナリアは manifest に traffic_split フィールドを持たせ、Module Federation 2.0 のランタイムプラグインで割合判定する。
事例 1: メガバンクの「勘定系フロントエンド」分割
ある大手銀行のインターネットバンキングは、モノリシックな React アプリ（約 2.4M LoC）をチーム別に 7 つの MFE へ分割した。きっかけは「1 チームの変更が他 6 チームのリリースを止める」「npm install が 8 分」「ビルドが 22 分」という古典的な肥大化問題だった。
採用構成は Webpack + Module Federation 2.0 + Single-SPA。ホストは口座概要・ナビゲーション・認証のみを持つ薄いシェルで、「振込」「投資信託」「ローン」「カード」「税務申告」「保険」「問い合わせ」の 7 MFE を動的ロードする。
段階的移行は 18 ヶ月計画で、まずシェルを先に切り出し、既存モノリスを 1 つの MFE として包み込む「ストラングラー・ファサード」から始まった。続いて機能単位で既存モノリスから MFE を剥離していく。各チームは独立して React のバージョンを上げられるようになり、移行完了時点で各 MFE の React バージョンは 18 から 19.2 まで分布していた。
成果は明確だった。ビルド時間は各チーム平均 3 分（22 分から 86% 削減）、デプロイ頻度は週 1 回から 1 日平均 12 回へ、インシデント時の影響範囲は「全機能停止」から「該当 MFE のみ」へ。金融規制上の監査対応では、MFE ごとに独立したデプロイ証跡が残せることが追加メリットとなった。
事例 2: SaaS 企業の Rspack + Vite 共存
ある HR Tech SaaS 企業は、管理者ポータル（Rspack）と従業員向けセルフサービス（Vite）を異なるビルドツールで運営している。管理者ポータルは巨大で IE11 互換が必要（レガシー顧客要件）、従業員ポータルはモバイル中心で DX 優先、という要件の違いからビルドツールを分けた。
MFE 連携は共通ナビゲーションバー、通知センター、検索、ヘルプチャットの 4 機能。これらはそれぞれ独立したリポジトリから Rspack でビルドされ、両ポータルが Module Federation 2.0 経由でロードする。Vite 側は @module-federation/vite プラグインでリモート消費側として統合した。
教訓は 「共有依存は最小限に」。当初は React・dayjs・Zustand など多数を shared に指定したが、singleton 競合で 3 回本番事故を起こし、最終的に React、React-DOM、i18n コンテキストの 3 つのみに絞った。Bundle サイズは増えたが運用安定性は格段に向上した。
事例 3: EC プラットフォームのエッジ配信移行
大手 EC のショップビルダー SaaS は、テナントごとにカスタムフロントエンドを提供する性質上 MFE と親和性が高い。2025 年に Rspack + Module Federation 2.0 へ移行し、Cloudflare Workers がテナント ID から MFE manifest を動的生成する構成とした。「特定顧客にだけ新機能を段階公開」「祝日限定デザインをテナント別配信」がエンジニアのデプロイなしで可能になった。落とし穴は SEO で、SSR での manifest 事前解決と構造化データの静的埋め込みで回避した。インデックス有効率は 92% → 98% に改善。
MFE を採用すべきか: 意思決定のチェックリスト
採用可否は次の観点で判断したい。該当項目が 3 つ以上なら MFE は真剣に検討すべきだ。チーム数が 5 以上で独立したリリースサイクルを持つ／モノリポのビルド時間が 10 分超／異なるフレームワーク・バージョンの共存／テナント別カスタマイズ配信／障害影響を機能単位に限定したい／機能ごとに独立した監査証跡が必要。逆にチームが 1-2、ビルドが 3 分以内、初回ロードのシンプルさを最優先するなら MFE は過剰だ。
まとめ: MFE は「再発見」の時代に
Module Federation 2.0、Rspack の成熟、エッジ配信の進化、そして AI エージェントによるチーム自律性の追い風を受けて、2026 年の MFE は「一部の先進組織のための技術」から「条件が合う組織の定石」へ格上げされた。重要なのは、MFE を「万能解」として導入することではなく、組織の痛みとビジネスの要件に対する具体的な処方として導入することだ。本稿で紹介した 3 事例が示すとおり、適切な条件下での MFE はビルド時間、リリース頻度、障害影響範囲、カスタマイズ自由度のすべてで桁違いの改善をもたらす。次のアーキテクチャ会議で「MFE？古いよね」と切り捨てる前に、もう一度組織の現状を見直す価値がある。