マイクロフロントエンドとは｜分割方式・採用判断・運用コストと見送る基準

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

マイクロフロントエンドは、1つのプロダクトのフロントエンドを機能やドメインの単位に切り出し、それぞれを別々のチームが所有・デプロイできるようにする設計思想です。用語としては2016年ごろから使われ始め、Cam Jacksonがmartinfowler.comのMicro Frontendsで整理した分類が、現在も議論の土台になっています。

重要なのは、これが「ファイルを分ける」話ではない点です。コンポーネント分割やディレクトリ分割はモノリスのままでもできます。マイクロフロントエンドが主に引き受けるのは、リリースの意思決定を誰が持つかという問題です。ただし、レガシースタックとの共存や段階的な技術刷新といった技術側の事情から採用されるケースもあります。

「マイクロサービスのフロント版」という説明のズレ

解説記事の多くは「マイクロサービスの考え方をフロントエンドに広げたもの」と始めます。方向性としては間違っていませんが、この説明だけを鵜呑みにすると判断を誤ります。

バックエンドのサービス分割は、プロセスもデータストアも物理的に分かれます。一方フロントエンドは、最終的にユーザーの1つのブラウザタブという共有環境で合流します。DOM、CSS、グローバル変数、認証トークン、ブラウザ履歴。これらは分割したあとも共有され続けます。

つまりフロントエンドの分割は、バックエンドほどきれいに切れません。サーバーサイドの分割判断についてはマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説で扱っているので、両者を混同しないよう読み分けてください。本記事はフロント側の分割に絞ります。

垂直分割と水平分割

分割の切り方には2通りあります。

垂直分割は、ページやルート単位で切る方法です。「/search 配下は検索チーム、/booking 配下は予約チーム」のように、URLで境界を引きます。合流地点が少ないぶん実装が素直で、国内の採用事例でも多く見られます。

水平分割は、同じ画面の中を領域で切る方法です。1つのページにヘッダー、商品情報、レコメンド、レビューが並び、それぞれ別チームが提供する構成を指します。柔軟ですが、CSSの衝突や読み込み順の制御といった問題が一気に増えます。

最初の採用では、ページやルート単位で境界を引けるなら垂直分割から始めるのが無難です。水平分割は、垂直で回せるようになってから検討しても遅くありません。1つの画面の中で複数ドメインが密接に同居するプロダクトでは、この限りではありません。

ミニFAQ：マイクロサービスを使っていないとマイクロフロントエンドは導入できませんか

いいえ、前提条件ではありません。バックエンドがモノリスのままでもフロントだけ分割する構成は成立します。ただし、バックエンドのAPIが単一チームの管理下にある場合、フロントを分けても結局そのチームが全体のボトルネックになる点には注意してください。

分割方式の5系統と選び方

方式は「いつ統合するか」で分類するのが主流です。結論から言うと、ルーティング分割かModule Federationのどちらかで始めるのが現実的で、残り3つは条件が合ったときの選択肢になります。ページ単位で分けられるならルーティング分割、同一画面内の部品を独立デプロイしたいならModule Federationが出発点です。

ビルド時統合

共通部分をnpmパッケージとして公開し、各アプリが依存として取り込む方式です。仕組みは単純で、既存のCI資産をそのまま使えます。

ただし、パッケージを更新したら取り込み側も再ビルドとデプロイが必要です。「独立してデプロイできる」という目的は達成できません。デザインシステムの配布には向きますが、これ単体をマイクロフロントエンドと呼ぶかは意見が分かれます。

ランタイム統合とModule Federation

実行時にリモートのバンドルを読み込み、ホストアプリに合流させる方式です。Webpack 5で導入されたModule Federationが代表格で、single-spaのようなフレームワークもこの系統に入ります。

この方式の強みは、リモート側をデプロイするだけでホストの挙動が変わる点です。裏を返すと、リモート側の事故がそのまま本番のホストに出ます。バージョン固定やフォールバックの設計を先に決めておかないと、切り分けに時間を取られます。

バンドラ側の前提知識はWebpackとは｜モジュールバンドラーの仕組み・Viteとの違い・基本設定で補完してください。

ルーティング分割

リバースプロキシやフレームワークの機能で、パスごとに別アプリへ振り分けます。Next.jsのMulti-Zonesはこの考え方を公式機能として提供しており、詳細はNext.js公式ドキュメントのMulti-Zonesにまとまっています。

構成がわかりやすく、障害の切り分けも楽です。弱点は遷移体験で、ゾーンをまたぐ移動でフルリロードが発生することがあります。アプリの性格によっては許容できません。Next.js自体の基礎はNext.jsとは？React基盤のフレームワークの特徴・できること・年収・将来性をフリーランス視点で解説を参照してください。

Web Componentsとiframe

Web Componentsは、フレームワークに依存しないカスタム要素として各部品を提供する方式です。理屈の上ではもっとも中立ですが、実務では詰まりどころが多く報告されています（後述の事例を参照）。

iframeは分離の強さが利点です。スタイルもスクリプトも確実に隔離されます。その代わり、高さの同期、認証情報の受け渡し、ブラウザ履歴の制御といった実装負荷が増えやすくなります。社内管理画面のようにUXより分離を優先できる場面なら、今でも合理的な選択肢です。

クラウド上での構成パターンはAWS規範ガイダンスのマイクロフロントエンドに日本語でまとまっており、CDNやオリジンの持ち方まで含めて確認できます。

Module Federationの現在地

Module Federationは長くWebpack専用の機能でしたが、2.x系でランタイムがバンドラから切り離され、RspackやViteでも同等の構成を組めるようになりました。公式の情報源はmodule-federation.ioで、リリース経緯はGitHub Discussionsの2.0リリース告知から追えます。

本記事執筆時点（2026年9月）で公式ドキュメントが案内しているのは2.x系ですが、この領域はバージョンの動きが速いため、採用前に公式サイトで現行の安定版と対応バンドラを必ず確認してください。日本語の解説記事はWebpack 5を前提としたものが多く、そのまま読むと構成の選択肢を狭く見積もることになります。

型情報の共有やマニフェスト経由の読み込みなど、運用を楽にする機能も追加されています。ただし機能が増えたぶん設定の面は厚くなりました。「Module Federationを入れたから独立デプロイできる」わけではなく、共有依存の方針とリリース手順を人間側で決める作業が残ります。

採用判断｜割に合うかを決める6つの軸

先に結論を書くと、判断の主語は「技術構成」ではなく「チームの数と、そのチームがリリースを待たされているか」です。以下の表は、国内外で公開されている採用事例と撤退事例に共通して現れる条件を、判断しやすい形に整理したものです。定量的な調査に基づく基準値ではなく、判断の出発点として使う目安として読んでください。

上の列に3つ以上当てはまるなら検討の価値があります。下の列が目立つなら、分割はコストのほうが先に来ます。

導入しないほうがよいケース｜モノレポで足りる線引き

「ビルドが遅い」「コードが大きすぎる」という不満だけが動機なら、マイクロフロントエンドは過剰です。モノレポにワークスペースを切り、ビルドキャッシュを効かせるだけで解決する問題が大半を占めます。

分割が必要になるのは、技術的な重さではなく組織的な待ち時間が問題になったときです。「他チームのレビューが終わらないとリリースできない」「リリース列車の時刻に間に合わないと1週間待ち」という状態が常態化しているかどうかで判断してください。

技術選定そのものを社内で通す手順は技術選定の進め方5ステップ｜評価軸の作り方と提案を通す型にまとめています。

ミニFAQ：既存のモノリスから段階的に移行できますか

できます。新規画面や改修予定の画面だけを新アプリとして切り出し、ルーティングで少しずつ振り分け先を移していくやり方（ストラングラーパターン）が現実的です。一気に全画面を分割する進め方は、移行期間中に両方を保守することになり、途中で息切れしやすくなります。

運用コストの内訳｜モノリスと比べて何が増えるか

デメリットとして「複雑性が増す」とだけ書かれることが多い部分を、項目ごとに分解します。ここが採用判断の実質的な争点です。

とくに見落とされやすいのがE2Eテストと障害対応です。この2つは「誰の仕事か」が決まっていないと、境界のすき間に落ちます。分割の設計と同時に、テストと監視の責任分界を文書にしておくと後が楽になります。E2Eの実装手段はPlaywrightとは｜E2Eテスト自動化の基本・Cypressとの違い・案件単価をフリーランス視点で解説を参考にしてください。

共有依存の重複は、Module Federationの共有設定で抑えられます。ただし設定漏れは計測しないと気づきません。バンドルサイズの上限をCIでチェックする仕組みを、分割の初日から入れておくことをおすすめします。後から入れると、すでに膨らんだ数字が基準値になってしまいます。

国内の公開事例に学ぶ失敗パターン

海外の大企業事例は多くの記事で紹介されていますが、規模が違いすぎて参考になりにくい面があります。ここでは日本企業が公開している実装記録から、再現性の高いつまずきを拾います。いずれも各社が自社ブログで公開している内容です。

Web Components方式が合わなかったケース

サイボウズは新卒でマイクロフロントエンドを経験してみてで、Web Componentsによる統合を検証した末に採用を見送った経緯を公開しています。理由として挙げられているのは、CSS in JSで書いたスタイルが適用されない、一部のカスタムフックが期待どおりに動かない、既存ライブラリとReactの協調が読みきれない、といった点です。

技術的に可能であることと、既存資産の上で成立することは別という典型例です。検証段階でスタイルとフックの挙動を先に潰しておくと、判断が早くなります。

通信設計と認証設計で作り直しになったケース

マネーフォワードのMicro Frontendsで築いた共通基盤と運用の試行錯誤では、アプリ間通信をCustomEventで組んだ結果、描画タイミングに依存する問題が出てイベント設計が複雑化したことが書かれています。認証についても、ホスト経由で各アプリのバックエンドを呼ぶ設計から直接通信へ変更しています。

加えて、ホスト側のデザイン更新でマイクロフロントエンド部分だけ見た目がずれる、E2Eの保守負荷が残る、といった未解決の課題も率直に共有されています。分割後に残る宿題の実例として読む価値があります。

CSSとルーティングで削られるケース

カケハシの爆速でプロダクトをリリースしようと思ったらマイクロフロントエンドを選んでいたでは、グローバルCSSによるレイアウト崩れやz-index管理の煩雑さが挙げられています。令和トラベルのNext.jsで実現するマイクロフロントエンドでも、アプリ間のコード重複やrewrites設定に起因する不具合が報告されています。

共通するのは、アーキテクチャの本質的な難しさではなく、スタイルとルーティングという地味な層で時間が溶けている点です。導入検討時の見積もりには、この層の調整期間を明示的に積んでおいてください。

やめる・戻すときの出口戦略

採用の話に比べて、畳み方を書いた日本語記事はほとんど見当たりません。しかし参画する側にとっては、撤退基準が決まっているかどうかがその現場の成熟度を示す指標になります。

再統合を検討すべきサイン

• 分割したのに、結局すべてのリリースが週次の全体調整会議を通っている

• アプリごとの担当が実質的に同じ人・同じチームになっている

• 共有ライブラリの更新のたびに、全アプリの改修を1人が横断して行っている

• 障害の一次切り分けに、分割前より時間がかかるようになった

これらが揃っているなら、分割のメリットは失われ、コストだけが残っています。組織が縮小して1チームに戻った場合も同様です。

畳み方の順序

戻すときは、分割したときの逆順が安全です。まずルーティングの振り分けを1アプリに寄せ、次にリモート読み込みをビルド時の依存に置き換え、最後にリポジトリを統合します。一度に全部を戻そうとすると、分割時と同じかそれ以上の作業量になります。

この判断は技術的負債の整理と同じ性質を持ちます。合意形成の進め方は技術的負債とは｜リファクタリング案件の合意形成と単価への影響が参考になります。

フリーランスが参画するときの実務

業務委託でマイクロフロントエンド構成の案件に入る場合、通常のフロントエンド案件とは確認すべき点が変わります。ここが他の解説記事でほぼ触れられていない領域です。

案件での遭遇の仕方

実際に出会うパターンは、おおむね3つに分かれます。大規模SaaSで既にマイクロフロントエンド化されている現場に1アプリの担当として入るケース。既存モノリスからの段階移行プロジェクトに、移行要員として入るケース。そして、分割そのものの設計を任されるケースです。

3つ目は設計と組織調整の比重が高く、テックリードとは？仕事内容・年収・PMやEMとの違いをエンジニア視点で解説で扱っている役割に近づきます。求められるのはReactの実装力だけではありません。

参画前に確認したい7項目

商談や初回面談の場で、以下を聞いておくと入ってからの事故が減ります。

1. 統合方式は何か（Module Federation／ルーティング分割／Web Components のどれか）

2. 共有依存のバージョン方針（誰がいつ上げるか、ずれを許容するか）

3. 自分が担当するアプリの境界（画面単位か、ページ内の領域か）

4. デザインシステムの有無と更新主体（ホスト側が更新したとき誰が追従するか）

5. E2Eテストの責任分界（境界をまたぐシナリオは誰が持つか）

6. 障害時の一次切り分け担当（どのアプリ起因かを誰が判定するか）

7. オンボーディング資料とローカル起動手順（全アプリを立ち上げないと動かない構成か）

7番目は軽視されがちですが、影響が大きい項目です。ローカルで全アプリを起動する必要がある構成だと、初日の環境構築だけで数日かかることがあります。参画から全体像をつかんで手が動くまで、この種の構成では2〜4週間程度を見込んでおくと、稼働計画のずれが小さくなります。3か月程度の短期案件では、この立ち上がり期間が稼働全体に占める比率を事前に計算しておいてください。

スキル要件と単価への効き方

マイクロフロントエンド案件で評価されるのは、フレームワークの実装力に加えて、ビルド基盤への理解と設計判断の経験です。この掛け算が効くぶん、同じフロントエンドでも要件が一段上がる傾向が見られます。

具体的なレンジについては本記事では扱いません。経験年数別・技術別の整理はフロントエンドエンジニアのフリーランス単価相場｜経験別・技術別レンジと動向にまとめてあります。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方で整理しています。自分が今どのくらいの単価を狙える位置にいるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。大規模フロント案件の募集状況はフリコンの案件一覧から探せます。

学習の進め方

いきなりModule Federationの設定から入ると、手段の理解だけで終わりがちです。順序としては、まず垂直分割の構成を小さく作ってみるところから始めるのが理解が早くなります。

• 既存のReactアプリを2つに分け、リバースプロキシでパスごとに振り分ける構成を手元で作る

• 次にModule Federationでホストとリモートの最小構成を組み、共有依存の指定を変えて挙動の違いを見る

• 共有ライブラリのバージョンを意図的にずらし、何が壊れるかを確認する

• 最後に、認証トークンの受け渡しとルーティング状態の同期を設計する

3つ目を実際に壊してみる経験があると、現場での議論の解像度が変わります。Reactそのものの基礎固めが必要ならReactとは？初心者向け入門解説｜できること・人気の理由までから入ってください。

まとめ

マイクロフロントエンドは、複数チームのリリースを独立させるための手段であり、コードを綺麗にするための手段ではありません。チームが分かれていない現場では、コストだけが先に立ちます。

• 分割方式は5系統。まずはルーティング分割かModule Federationから検討する

• 採用の目安は、独立したチームが3つ以上あり、各チームが週1回以上のペースで自分の判断でリリースしたい状態

• 1〜2チーム・月1回程度のリリース頻度なら、モノレポとビルドキャッシュで足りる

• 増えるコストはCI・共有依存・デザイン統一・E2E・障害切り分け。とくに後ろ2つは責任分界を先に決める

• 国内事例でつまずいているのはスタイルとルーティングという地味な層。見積もりに調整期間を積む

• 撤退基準を持っている現場は成熟度が高い。戻すときは分割の逆順で進める

• 参画前に、統合方式・共有依存のバージョン方針・障害時の一次切り分け担当の3点を確認する

• 逆に、1〜2チームで全体を見渡せる段階なら、まずはモノレポと運用改善を優先するのが現実的です

次のステップとしては、手元のReactアプリを2つに分けてリバースプロキシで振り分ける構成を作り、そのうえでModule Federationの最小構成を組んでみてください。設定を書くより、共有依存をずらして壊してみるほうが学びが大きくなります。

参照した一次情報は以下のとおりです。バンドラの対応状況やバージョン情報は公開後も変わりやすいため、採用を決める前に公式ドキュメントで現行の安定版を確認してください。

• Micro Frontends（martinfowler.com）

• Module Federation 公式ドキュメント

• Module Federation 2.0 リリース告知（GitHub Discussions）

• Next.js Multi-Zones（公式ドキュメント）

• single-spa 公式サイト

• AWS規範ガイダンス｜マイクロフロントエンドの理解と実装