LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

マイクロフロントエンドとは何か

マイクロフロントエンドとは、独立してデプロイ可能な複数のフロントエンドアプリケーションが統合されて1つの画面を形成するアーキテクチャスタイルを指します^*1。バックエンドのマイクロサービス分割の考え方を、フロントエンド側に適用したものです。

本稿で扱うマイクロフロントエンドは、複数リポジトリを1つに集約する「モノレポ」とは別の話です。モノレポはリポジトリの構成、マイクロフロントエンドはフロントエンドという実行単位の分割方法を指し、両者は独立した設計判断になります。あくまで「巨大な1つのフロントエンドを、どう独立した単位に分けて統合するか」を対象にします。

チームの独立性と独立デプロイ — 必要になる背景

マイクロフロントエンドが検討される背景には、複数チームが1つのフロントエンドを同時に開発する際の課題があります。ThoughtWorksのCam Jackson氏による解説では、モノリシックなフロントエンドで複数チームが並行作業すると「互いの作業が干渉し合う」状態が生じやすいと指摘されています^*1。

もう一つの背景が、古いコードベースの制約です。同解説では、古い技術スタックが足かせになり、フロントエンド全体の書き換えが魅力的に見えてしまう状況に触れつつ、実際には全体の一括書き換えではなく段階的な改善を可能にする設計が有効だとしています^*1。

この2つの課題に対応するため、マイクロフロントエンドはフロントエンドを独立した単位に分割し、各単位を担当チームが独自のリリースサイクルでデプロイできる状態を目指します。デプロイが独立していれば、あるチームの変更が別チームのリリーススケジュールを待つ必要がなくなります。

小規模アプリケーションでは過剰になる — 適用条件の見極め

マイクロフロントエンドは、どのフロントエンド開発にも当てはまる解決策ではありません。Cam Jackson氏の解説は結論部分で「マイクロフロントエンドに無償の利点はない」と述べ、採用前に検討すべき問いをいくつか挙げています^*1。インフラの運用体制や組織の成熟度が問われる内容で、小規模なアプリケーションや単一チームでの開発には過剰な複雑さになり得ることを示唆しています^*1。

適用を検討する目安として、次のような状況が当てはまるかを確認します。第一に、複数チームが同一のフロントエンドを同時に触っていて、リリースの調整コストが目に見えて発生しているかです。第二に、機能単位でチームの担当領域が明確に分かれており、独立デプロイのメリットが調整コストを上回るかです。

逆に、開発チームが1つで機能追加のペースも緩やかな場合、実行時統合の仕組みを導入する運用コストが、得られる独立性の利点を上回りやすくなります。この見極めを外注先の提案だけに委ねず、自社のチーム構成と開発ペースを踏まえて判断することが大切です。

ビルド時統合と実行時統合 — 統合方式の分かれ道

マイクロフロントエンドの統合方式は、大きくビルド時統合と実行時統合に分かれます。Cam Jackson氏の解説では、ビルド時統合は各マイクロフロントエンドをパッケージとして公開し、シェル側の依存関係に含めてビルドする方式と説明されています^*1。

ビルド時統合の課題は、デプロイの独立性が損なわれやすい点です。同解説では、この方式ではシェルアプリケーションが新しいバージョンのパッケージを取り込むたびに再ビルド・再デプロイが必要になり、独立デプロイという目的から外れる「ロックステップ」の状態に陥りやすいと指摘されています^*1。

これに対し実行時統合は、各マイクロフロントエンドを実行時にブラウザ上で読み込んで組み合わせる方式です。同解説はJavaScriptによる実行時統合を、柔軟性の高い方式として位置づけています^*1。webpack公式ドキュメントが解説するModule Federationも、この実行時統合の仕組みの1つに位置づけられます^*2。

Module Federation・iframe・Web Components — 実行時統合の種類

実行時統合を実現する具体的な仕組みには、複数の種類があります。優劣を一概に決めるものではなく、既存の技術スタックと分離の要件によって選択が変わります。

Module Federation — ビルド間でモジュールを公開・消費する仕組み

webpack公式ドキュメントでは、Module Federationを「複数の独立したビルドが1つのアプリケーションを構成する」仕組みと定義しています^*2。各ビルドはコンテナとして機能し、他のビルドに向けてモジュールを公開（expose）したり、他のビルドが公開したモジュールを消費（consume）したりできます^*2。

公式ドキュメントが挙げる代表的な使い方は、単一ページアプリケーションの各ページを別々のビルドとして公開し、アプリケーションシェルがそれらをリモートモジュールとして参照する構成です^*2。共有ライブラリ（Shared modules）の仕組みも用意されており、ReactやVue等の共通ライブラリを両方のビルドでオーバーライド可能な形で指定できます^*2。webpackに加え、Rspack（Rust製の高速バンドラー）でもModule Federationの仕組みが提供されています^*3。

公式ドキュメントは注意点として、フォールバックモジュールを常時ダウンロードする設定（eager指定）を使う場合、アプリケーションのどこか1点（シェルなど）だけに限定することを推奨しています^*2。設定を誤ると想定外にモジュールが重複読み込みされる可能性があるため、設計時の見落としに注意が必要です。

iframe — ブラウザ標準機能によるシンプルな分離

iframeは、ブラウザの標準機能を使って別ドメイン・別アプリケーションの画面をそのまま埋め込む方式です。Cam Jackson氏の解説では、iframeはCSSやグローバル変数の衝突を避けられる高い分離性を持つ一方、ルーティングや深いリンク（ページ内の特定状態への直接遷移）の実装が複雑になりやすい点が課題として挙げられています^*1。

Web Components — カスタム要素として実装する方式

Web Componentsは、ブラウザ標準のカスタム要素としてマイクロフロントエンドを実装する方式です。同解説では、宣言的なHTMLタグとしてマイクロフロントエンドを扱える点が特徴として紹介されています^*1。フレームワークに依存しない標準機能をベースにするため、特定のバンドラー設定に縛られにくい方式です。

共通依存の重複とパフォーマンスの課題

実行時統合を採用する場合、最初に検討すべき課題が共通依存の重複です。Cam Jackson氏の解説では、各マイクロフロントエンドが独立してビルドされると、React等の共通ライブラリがそれぞれのビルドに重複して含まれ、ダウンロードサイズが増加すると指摘されています^*1。

この課題への対応として、共通ライブラリをビルドから外部化し、実行時に1つだけ読み込む方法があります。ただしこの対応にはビルド時の結合が一部生じるため、独立デプロイの利点と依存の重複回避の間でトレードオフが発生します^*1。Module Federationの共有モジュール機能も、この重複を抑えるための仕組みの1つです^*2。

パフォーマンス面では、単一ページの初回読み込みは高速化する可能性がある一方、ページ間の遷移で同じ依存を再度ダウンロードする課題が生じ得ると同解説は述べています^*1。共有モジュールの読み込みタイミングとキャッシュ戦略を設計時に詰めておく必要があります。

スタイル分離とバージョン整合の課題

CSSはグローバルに適用される仕組みで、モジュールごとのカプセル化機能を持ちません。Cam Jackson氏の解説は、この特性のためチーム間でCSSセレクタが競合しやすいと指摘し、CSS-in-JSやShadow DOM（Web Componentsのカプセル化機能）で対応する方法を挙げています^*1。

ルーティングの整合性も見落とされやすい課題です。同解説は、各マイクロフロントエンドが担当するルート（URLパス）を「契約」として扱うべきだと説明しています^*1。あるチームがルート構成を変更すると、他のチームが参照しているリンクや遷移処理に影響するため、ルート変更の周知ルールを事前に決めておく必要があります。

共有ライブラリのバージョン整合も課題です。同解説は、共有する依存関係に破壊的変更が入ると、関係する複数チームを巻き込んだ大掛かりなバージョンアップ作業が必要になり得ると述べています^*1。共有モジュールの更新方針とバージョン固定の範囲を、チーム間で事前に合意しておくことが実務上重要です。

外注の委託範囲と発注準備

マイクロフロントエンド導入を外注する際は、意思決定が必要な部分と実装作業を分けて考える必要があります。どの単位でフロントエンドを分割するか、どの統合方式（Module Federation・iframe・Web Components等）を選ぶか、共有ライブラリの更新ルールをどう決めるかは、チーム編成と将来の拡張方針を理解している自社側が主導すべき判断です。

一方、統合方式の実装・共有モジュールの設定・CIパイプラインの改修・既存フロントエンドの分割作業は、外注先に委託しやすい領域です。特定の技術（Module Federation、Web Components等）の実装経験を持つ外注先であれば、初期構築を効率的に進められます。

発注準備として、RFP（提案依頼書）には次の項目を含めておくと提案の比較がしやすくなります。

• 現状のフロントエンド構成：単一SPAか複数アプリケーションか、使用フレームワーク・バンドラー
• 分割の目標範囲：全体を分割するか、一部の機能領域のみを分割するか
• チーム編成との対応：分割単位とチームの担当範囲をどう対応させたいか
• 候補方式の希望：Module Federation・iframe・Web Components等の指定有無、または外注先からの提案を受けるか
• 共有ライブラリの範囲：共通化したいUIコンポーネントやライブラリの現状と更新頻度

必要スキル・工数の面では、実行時統合の設計には、対象フレームワークのバンドラー設定・共有モジュールの依存管理・ルーティング設計の3つの知識が必要になります。設計を誤ると共通依存が二重に読み込まれ、想定より読み込みが遅くなる事態や、チーム間のCSS競合による表示崩れが発生し得ます。複数の外注先から同一要件で見積もりを取得し、分割単位の設計方針や共有モジュールの提案内容を比較することが、発注後の手戻りを防ぐうえで大切です。

まとめ：マイクロフロントエンド導入を外注する前に決めておくべきこと

マイクロフロントエンドは、大規模なフロントエンドを独立デプロイ可能な単位に分割し、複数チームの並行開発を可能にするアーキテクチャです。一方で小規模な開発では過剰な複雑さになり得るため、適用条件を見極める必要があります。要点を3つに集約すると次の通りです。第一に、統合方式にはビルド時統合と実行時統合（Module Federation・iframe・Web Components等）があり、優劣は要件次第です。第二に、共通依存の重複・スタイル分離・バージョン整合という課題への対応方針を事前に固めておく必要があります。第三に、分割単位とチーム編成の対応関係は自社主導で決め、実装作業を外注の委託範囲とすることが手戻りを防ぎます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Cam Jackson「Micro Frontends」martinfowler.com（2019年）
2. *2　出典：webpack「Module Federation」（webpack公式ドキュメント）
3. *3　出典：Module Federation「Module Federation」（公式サイト、RspackおよびWebpackのビルドサポートを記載）

Tweet