マイクロフロントエンド再考2026：Module FederationとWeb Componentsで何が変わったか
「マイクロフロントエンドは複雑すぎる」という声が2022〜2023年に多く聞かれましたが、2026年現在はModule Federation 2.0とVite Federationの成熟、Web Componentsサポート強化により状況が変わっています。
なぜ再評価されているのか
以前の課題: 複数チームのバンドル重複（Reactが3回ロード）、ローカル開発の煩雑さ、バージョン地獄。
Module Federation 2.0が解決したこと: 共有依存関係の自動解決、TypeScript型定義の自動共有、Viteとの統合。
// vite.config.ts
import federation from '@originjs/vite-plugin-federation';
export default {
plugins: [
federation({
name: 'app-shell',
remotes: {
productApp: 'http://localhost:3001/assets/remoteEntry.js',
},
shared: ['react', 'react-dom'],
}),
],
};
2026年の主要パターン
パターン1：シェルアプリ + 機能アプリ
シェルがルーティング・認証を担当し、機能別アプリをリモートロード。異なるフレームワーク混在（React・Vue・Svelte）が現実的になった。
Shell App (Next.js)
├── /dashboard → Dashboard MFE (React)
├── /products → Products MFE (Vue 3)
└── /cart → Cart MFE (React)
パターン2：垂直分割（チーム単位）
コンウェイの法則に従い、チームごとにフロント・バックエンドを一貫して担当。
チームA → /checkout/... (決済フロー全体)
チームB → /catalog/... (商品カタログ全体)
パターン3：Web Componentsウィジェット
ReactコンポーネントをWeb Componentとしてラップし、フレームワーク非依存で共有：
class ProductCard extends HTMLElement {
connectedCallback() {
const root = createRoot(this);
root.render(<ProductCardComponent productId={this.getAttribute('product-id')} />);
}
}
customElements.define('product-card', ProductCard);
アプリ間通信
アンチパターン: window.__sharedStateによるグローバル状態共有（密結合・テスト困難）
推奨: EventTargetベースのイベントバス
const eventBus = new EventTarget();
// Cart MFEから発行
eventBus.dispatchEvent(new CustomEvent('cart:updated', { detail: { itemCount: 3 } }));
// Header MFEで受信
eventBus.addEventListener('cart:updated', (e) => updateCartBadge(e.detail.itemCount));
URLを単一ソース・オブ・トゥルースとして使うことでリロード時の状態維持も実現できます。
CI/CD：独立デプロイを実現する設計
# .github/workflows/products-mfe.yml
on:
push:
paths: ['apps/products-mfe/**']
jobs:
deploy:
steps:
- run: cd apps/products-mfe && pnpm build
- run: aws s3 sync dist/ s3://mfe-bucket/products/ --delete
Shell Appが参照するリモートURLは環境変数で管理し、動的解決します。
採用判断フレームワーク
採用すべきでないケース:
- チームが1〜2チーム（複雑性のコストが利点を上回る）
- 月間PVが1万以下
- SEO要件が厳しくSSRが必須
- 初期フェーズのスタートアップ
採用すべきケース:
- 5チーム以上が一つのフロントエンドを開発
- デプロイ頻度がチームごとに異なる
- レガシーシステムからの段階的移行
- サードパーティへのUIウィジェット提供
FAQ
Q. なぜ再評価されているのか？ A. 本記事ではなぜ再評価されているのかについて詳しく解説しています。記事本文をご参照ください。
Q. 2026年の主要パターンについて教えてください。 A. 本記事では2026年の主要パターンについて詳しく解説しています。記事本文をご参照ください。
Q. アプリ間通信について教えてください。 A. 本記事ではアプリ間通信について詳しく解説しています。記事本文をご参照ください。
まとめ
Module Federation 2.0とWeb Componentsの成熟により、大規模プロダクトには有力な選択肢になりました。しかし複雑性のコストは依然高く、小〜中規模チームには不向きです。「いつ使うべきか」という問いを持つことが2026年のアーキテクト判断の出発点です。
