統一性は、到達すべきゴールではありません。それは、支払い続けるサブスクリプションなのです。あらゆるエンジニアリング組織は、最終的にこれに気づきます。通常、2つ目または3つ目のチームが同じリポジトリへのコミットを開始したタイミングでです。単一の React モノリスを運用していようと、独立してデプロイ可能なフロントエンドの集合体を運用していようと、コストゼロを目指して最適化しているわけではありません。あなたは単に、四半期ごとにどの請求書が届くかを選択しているだけなのです。

モノリスの調整コスト

モノリス型アーキテクチャにおいて、その請求書は「エンジニアの工数」という形で書かれます。チームは、共有コード、スタイル、リリーススケジュールの調整に日々を費やします。軽微なチェックアウト機能の修正をデプロイしたい開発者は、他の6つのチームが使用している共有依存関係を更新し、その後、フルリグレッションテストが完了するのを待たなければならないかもしれません。コストは静かに蓄積していきます。それはクラウドの請求書に項目として現れることはありません。速度の低下、コードスタイルに関する Slack スレッド間でのエンジニアのコンテキストスイッチ、そして誰も所有していないが誰もが触れる CSS アーキテクチャによる緩やかな摩擦の中に隠れているのです。

チームが成長するにつれ、このコストも増大します。コードレビューのボトルネックは、技術的な懸念から社会的な懸念へとシフトします。200人のコントリビューターがいる単一のリポジトリは、線形にはスケールしません。組み合わせ爆発的にスケールします。マージキューは滞留し、リリース・トレインは数日間に及びます。デザインシステムは、新しいボタンのバリエーションを承認するために管理評議会を必要とするような、政治的な存在へと変貌します。モノリスが変化に抵抗するのは、悪意があるからではありません。すべての接点が共有されており、あらゆる変更が合意を必要とするからです。

境界線を引く

マイクロフロントエンドは、調整コストを特定の境界内に移動させます。共有の状態管理に関する毎週の会議を行う代わりに、境界線を引きます。チームAはプロダクトカタログを担当し、チームBはカートを担当します。彼らは、通常はルーティングの境界や限定的なイベントスキーマといった「契約（contract）」に合意し、それ以降は互いに干渉しません。これが核心となるトレードオフです。自律性と引き換えに、別の種類の規律を受け入れるのです。

理論は明快です。もし Shipping チームがルーティング層をリファクタリングしても、Billing チームは気にする必要はありません。もし検索インターフェースが1日に5回のデプロイを必要としても、アカウント設定ページの E2E テストが完了するのを待つ必要はありません。境界線は、組織的な摩擦を技術的なインターフェースへと変換します。しかし、その境界線を引くこと自体が、決して無料で行えるわけではありません。

インフラストラクチャの請求書

マイクロフロントエンドは、プラットフォームのコストを生み出します。実行時に断片を合成できるシェルアプリケーションが必要になります。複数のビルドジョブから生成されたアーティファクトを、単一の整合性のあるページへと組み立てる方法を理解したデプロイパイプラインが必要になります。Webpack Module Federation を使用している場合、独立してビルドされたバンドル間で共有依存関係のバージョンを管理することになります。iframe を使用している場合は、クロスオリジン・メッセージングのデバッグやレイアウトシフトとの戦いに直面します。Web Components を使用している場合は、あるチームのアップグレードが別のチームに影響を及ぼす可能性がある分散グラフの中で、カスタム要素のバージョニングを行うことになります。

これらのコストは具体的であり、継続的に発生します。7番目のフロントエンドを壊さずに6つのフロントエンドをリリースできるビルド・オーケストレーションにコストを支払います。3つの異なるチームが所有する3つの別々の JavaScript バンドルにわたってユーザーのアクションを追跡できるオブザーバビリティにコストを支払います。また、パフォーマンスのガバナンスにもコストがかかります。6つのチームがそれぞれ独自のユーティリティライブラリのコピーをバンドルしていると、誰かが重複排除戦略を構築して維持しない限り、ページは重く、動作の遅いものになってしまうからです。その時点で、あなたは逃れようとしていたモノリスの一部を再構築してしまっています。ただし、今度はそれを維持するためのプラットフォームチームが必要になっているという違いがあります。

コストがシフトする時

単一の Next.js アプリケーションを共有している4つのフロントエンドチームを持つ、中規模の SaaS 企業を考えてみましょう。デプロイは、3時間の CI 実行を経て、1日に2回行われます。Shipping チームがナビゲーションのリファクタリングを行いたい場合、彼らはコメントを求めるリクエストを出し、ツリー全体のインポートパスを更新し、Billing チームが統合テストを調整するのを2週間待ちます。コストは、単純明快な「調整」です。

彼らはマイクロフロントエンドへと分割します。各チームは垂直方向の領域（vertical）を所有し、独自のスケジュールでプロダクションへプッシュします。最初の1ヶ月は自由を感じるでしょう。しかし、あるバグが発生します。Shipping チームが CSS-in-JS ライブラリをアップグレードしたことで、Search チームが注入したベーススタイルと競合し、Safari でグローバルヘッダーがレンダリングされなくなります。デバッグには3人のオンコールエンジニア、共有のウォー・ルーム（war room）、そしてシェルアプリがモジュール・マニフェストをキャッシュしているために、2つのサービスを痛みを伴いながらロールバックする必要があります。コストは移動したのです。消え去ったわけではありません。

スケーリングの算術

Neither model is free. A fifteen-person startup does not need a platform team. The overhead of module federation, independent deployment pipelines, and distributed contract testing would eat their entire velocity. They should pay in coordination because the coordination is cheap. They can agree on a state management pattern in a ten-minute conversation and ship it in the same afternoon.

A five-hundred-person enterprise with a dozen business units operating on different quarterly cycles faces the opposite problem. The coordination tax has become exponential. Release trains take weeks. Platform engineering headcount is already a budget reality, so adding microfrontend infrastructure is a marginal cost, not a new line item. For them, trading alignment meetings for deployment graphs is rational arithmetic.

The real question is which bill scales better for your team. Monoliths tax you at the edge of human coordination. Microfrontends tax you at the foundation of platform engineering.

Choosing Your Currency

If you choose microfrontends, be explicit about what you are buying. You are purchasing team autonomy and independent deployability. Be ready to fund the following:

  • A runtime shell that handles composition, routing, and error boundaries between fragments.
  • A shared dependency policy focused on deduplication strategy, not shared implementation logic.
  • Cross-team contract testing for every integration surface.
  • Unified observability that can correlate a user click across distributed bundles.
  • A performance governance model, because no single team owns the final payload the browser downloads.

If you choose the monolith, be honest about the invoice. You are buying simplicity in exchange for synchronization. Expect to pay for:

  • Shared code ownership and the governance rituals required to keep it coherent.
  • A release cadence determined by the slowest integration test in the pipeline.
  • Wide blast radius on library upgrades.
  • The creeping reality that your fastest engineers will move at the speed of your most cautious ones.

The Real Takeaway

There is no architecture that removes the price. There is only the choice of currency. Smart organizations stop searching for the free option and start auditing which cost they can actually afford to carry. You must decide if you want to pay in human coordination or in platform overhead. Uniformity, in either case, remains a subscription. The only question is who cuts the check.