【書評】マイクロフロントエンド ―マイクロサービスアーキテクチャの概念をフロントエンドに拡張し、信頼性、自律性の高いシステムを構築する

Posted at 2026-09-20

はじめに

「マイクロサービスは浸透したのに、フロントエンドは相変わらず一枚岩のまま」という状況に心当たりのある方は多いのではないでしょうか。

API 層はドメインごとに分割され、チームごとに独立してデプロイできるようになった。それなのにフロントエンドだけは巨大な SPA のままで、リリースのたびに全チームの調整が必要になる。この非対称性を正面から扱ったのが、Luca Mezzalira 著『マイクロフロントエンド』（オライリー・ジャパン, 2022）です。

本記事では、本書の全体像と、設計・アーキテクチャに関心のあるエンジニアにとっての読みどころを整理します。

書誌情報

項目	内容
原題	Building Micro-Frontends
著者	Luca Mezzalira（AWS プリンシパルソリューションアーキテクト）
訳者	嶋田健志
出版社	オライリー・ジャパン
発行	2022年10月
序文	Neal Ford（『ソフトウェアアーキテクチャの基礎』著者）

著者は動画ストリーミングプラットフォーム DAZN で、数百人規模の分散チームを抱えるプロジェクトにマイクロフロントエンドを導入した経験を持ちます。本書はその実践知を体系化したものです。

本書の立ち位置：コードではなくメンタルモデルの本

まず押さえておきたいのは、本書が「何百行ものコードを載せた実装書」ではないという点です。著者自身が「はじめに」で明言しています。

本書は、マイクロフロントエンドを実装する際に学んだアーキテクチャ、メンタルモデル、方法論に焦点を当てています。

単一の実装方法を深掘りするのではなく、複数のアプローチを並べてそれぞれの利点と落とし穴を理解させる構成になっています。技術が数年で入れ替わることを前提に、「どのフレームワークを使っても正しい方向を決められる」判断軸を渡すことが目的です。

老子の「授人以魚不如授人以漁」（魚を与えるのではなく釣り方を教える）が引用されているのが、本書の性格をよく表しています。

1章：なぜ既存アーキテクチャでは足りないのか

冒頭では SPA、アイソモーフィックアプリケーション、静的サイト、Jamstack といった既存の選択肢が棚卸しされます。それぞれに適材適所があり、マイクロフロントエンドが唯一の正解ではないという前提が最初に置かれます。

その上で、SPA の課題として挙げられるのが組織面の問題です。

大規模な SPA を分散チームで開発すると、アプリの領域ごとに方針や判断が混在する
チーム間の調整コストが「隠れたコスト」として積み上がる
開発者が入社する何年も前に始まったコードベースに、所有権を感じにくい

これらは請求書として可視化されないため見落とされがちですが、確実にスループットを削っていきます。マイクロフロントエンドは、この「欠けていたピース」として位置付けられます。

コンウェイの法則と逆コンウェイ作戦への言及も 1 章から登場し、本書が技術と組織を一体で扱う姿勢が示されます。

2章：マイクロサービスの原則をフロントエンドへ

Sam Newman『マイクロサービスアーキテクチャ』で提示された 7 つの原則を、そのままフロントエンドに写像していく章です。

原則	フロントエンドへの適用
ビジネスドメインのモデル化	DDD でサブドメインを特定し、チームに所有権を与える
自動化の文化	数十〜数百の成果物を扱うため CI/CD が生命線
実装の詳細を隠す	チーム間で契約を先に定義し、内部実装は自由に変える
ガバナンスの分散	画一的な妥協ではなく、ドメインに適した判断を現場が下す
独立デプロイ可能性	外部依存の解決を待たずに自分たちの速度でリリース
障害の分離	実行時に UI を組み立てる以上、404 やネットワーク障害への代替表示が必須
高い観測性	Sentry / LogRocket 等で「防ぐ」より「素早く直す」へ

章の締めくくりは「マイクロフロントエンドは銀の弾丸ではない」という節です。技術的にも組織的にも複雑さを増す選択である以上、欠点が利点を上回るなら採用すべきではない、と明確に線が引かれます。

3章：意思決定フレームワーク（本書の核）

本書でもっとも実用性が高いのがこの章です。マイクロフロントエンドの設計を、4 つの決定に分解します。

1. 定義：水平分割か垂直分割か

水平分割：1 つのビューに複数のマイクロフロントエンドが同居する。再利用性は高いが、規律とガバナンスが要求される
垂直分割：チームが認証・カタログなどのビジネスドメインを丸ごと担当する。SPA に近い開発体験

2. 構成（コンポジション）：どこで組み立てるか

クライアントサイド：アプリケーションシェルが CDN から読み込む
エッジサイド：CDN 層で ESI により組み立てる
サーバサイド：オリジンで最終ページを構築する

3. ルーティング：どこで振り分けるか

構成の選択とほぼ連動します。クライアントサイド構成ならアプリケーションシェルがルーティングを持つ、という具合です。

4. コミュニケーション：どうデータをやり取りするか

同一ビュー内：イベントエミッター / カスタムイベント（状態の共有はアンチパターン）
ビュー間：揮発的なデータはクエリ文字列、永続的なデータは Web ストレージ

この 4 本柱を先に決めることで、後続の技術選定・自動化戦略・デザインシステムの設計がほぼ自動的に絞り込まれます。「iframe にするか Web Components にするか」から入るのではなく、ビジネスの観点から入るべきだという主張が一貫しています。

章の後半では Zalando、HelloFresh、AllegroTech、Spotify、SAP、OpenTable、DAZN の事例が紹介されます。Spotify が iframe 方式をパフォーマンス上の理由で撤回して SPA に戻した話など、失敗も含めて書かれているのが誠実です。

4章：アーキテクチャの分類とトレードオフ採点

本書で最も分量のある章です。各実装を 8 つのアーキテクチャ特性（デプロイ可能性 / モジュール性 / 簡素性 / テスト容易性 / パフォーマンス / 開発者体験 / スケーラビリティ / 全体管理）で 5 点満点採点していきます。

実装	デプロイ	モジュール性	簡素性	パフォーマンス	DX	スケーラビリティ
垂直分割 + アプリシェル	5	2	4	4	4	5
モジュールフェデレーション	4	4	5	4	5	5
iframe	5	3	3	2	3	5
Web Components	4	3	4	4	4	5
サーバサイド構成	4	5	3	5	3	3
エッジサイド構成（ESI）	3	4	2	3	2	4

数値そのものより、トレードオフの形が可視化されることに価値があります。パフォーマンスを最大化したければサーバサイド構成だが開発者体験とスケーラビリティを払う、開発者体験を取るならモジュールフェデレーションだが全体管理の難易度が上がる、といった構図が一目で分かります。

Neal Ford と Mark Richards の言葉が引用されているのも印象的です。

最高のアーキテクチャを目指すな、むしろ最小最悪のアーキテクチャを目指せ

個人的に刺さった節：誤った抽象化

垂直分割の課題として、コードの重複と共有ライブラリのどちらを選ぶかという議論が展開されます。ここで Sandi Metz の "The Wrong Abstraction"、Kent Dodds の AHA プログラミングが引かれ、DRY 原則の誤用に釘が刺されます。

誤った抽象化はコードの重複よりもずっと高くつきます。

判断に迷ったら複製してみて、数回繰り返してから抽象化を検討する。分散アーキテクチャでは、この判断が組織の外部依存の数に直結します。

パフォーマンスの説明が明快

500KB の SPA を例に、非認証エリア 100KB / 認証エリア 250KB / 共有依存 250KB という内訳を示し、垂直分割ならユーザの行動に応じて必要な分だけダウンロードできるという説明があります。「アプリケーション全体のパフォーマンスではなく、ユーザ体験に基づいて最適化する」という視点の転換が分かりやすく提示されています。

5章：モジュールフェデレーションによる実装

webpack 5 のモジュールフェデレーションを使い、ホスト（アプリケーションシェル）とリモート（マイクロフロントエンド）で EC サイトを構築していきます。

重要な設計指針として、共有は一方向にすべきという主張があります。

どのコードがどこから来たか追えるのでデバッグが容易
制御しやすくエラーが起こりにくい
境界が明確になるため効率的

Flux が双方向から単方向データフローへ移行した歴史との類推で説明されており、腑に落ちます。

「webpack へのロックインが怖い」という懸念にも 1 節が割かれています。代替手段でのリファクタリングコスト、プロジェクトの寿命、3〜5 年での技術変化の見込みを実際に見積もれば、多くの場合その恐怖は軽減される、という現実的な回答です。

6・7章：自動化戦略

分散システムにおける CI/CD の話で、以下 5 つの原則が提示されます。

フィードバックループを高速に保つ（8〜10 分を超えたら見直す）
頻繁に反復する
チームに権限を与える
ガードレールを定義する
テスト戦略を定義する

リポジトリ戦略

単一リポジトリ（モノリポ）と複数リポジトリ（ポリリポ）の利点・課題が並べられ、最後にサブドメイン単位でまとめるハイブリッドという第三の選択肢も提示されます。

適応度関数

『進化的アーキテクチャ』の概念を持ち込み、CI パイプライン内でアーキテクチャ特性を機械的に検証します。

バンドルサイズの上限
Lighthouse / WebPageTest によるパフォーマンス計測
SonarQube による循環的複雑度の測定
コードカバレッジ
セキュリティルールへの適合
デザインシステムライブラリのバージョンチェック（マイクロフロントエンド固有）

最後のものは特に実用的で、package.json を検証して古いバージョンならビルドを失敗させる、といった運用が紹介されています。

デプロイ

ブルーグリーンデプロイとカナリアリリースの違い、そして既存アプリからの移行に使うストラングラーフィグパターンが扱われます。DAZN での実例として、レガシー / ハイブリッド / マイクロフロントエンドの 3 バージョンを数ヶ月並走させ、問題があれば即座にレガシーへ戻せる体制を組んだ話が出てきます。

7 章では、これらを ACME という架空企業の具体的なパイプライン（Lerna + Git + SonarQube + Jest + webpack + S3 + CloudFront + Lambda@Edge）として組み上げます。

8章：バックエンドパターン

マイクロフロントエンドは必ずしもマイクロサービスとセットではありません。この章では 3 つのパターンが整理されます。

サービスディクショナリ：利用可能なエンドポイント一覧を JSON で配る。エンドポイントのハードコードを避け、発見可能性も上がる
API ゲートウェイ：単一エントリポイント。トークン検証・レート制限・ログを一元化
BFF：クライアント種別ごとにバックエンドを用意し、レスポンスを集約する

加えて GraphQL とスキーマフェデレーションの節もあります。

面白いのは、BFF × クライアントサイド水平分割は相性が悪いと明言している点です。ホストページが全マイクロフロントエンドのデータ取得を担うと独立性が壊れるため、利点より課題が大きくなる可能性があると警告しています。パターンを紹介するだけでなく、組み合わせの適否まで踏み込むのが本書らしいところです。

「2 枚のピザのチーム」ルールの根拠として、n(n-1)/2 でリンク数が二次関数的に増える話が挟まれるのも良いアクセントです。

9章：モノリスからの移行事例

動画ストリーミング企業 ACME を題材に、Angular 製 SPA からマイクロフロントエンドへ移行するプロセスを追体験します。

特筆すべきは、Google Analytics のデータに基づいて分割を決めている点です。

ビュー	新規ユーザのトラフィック
ランディングページ	100%
サインアップ	70%
支払い	60%
カタログ	30%

認証済みユーザの 92% はカタログに留まり、ランディングページには 0% しか戻らない。この実測値から「ランディングページ・認証・カタログは切り離すべき」という結論が導かれます。

マイクロフロントエンドを分割するにはデータに基づいて行うことを強くお勧めします。

推測ではなく計測から始める、という姿勢が具体例として示されるので説得力があります。

10章：組織にマイクロフロントエンドを導入する

最終章はまるごと組織論です。ここを本の締めに置いている構成自体が、著者の主張を物語っています。

機能チーム vs コンポーネントチーム

水平分割 → 機能チーム（クロスファンクショナル）が向く
垂直分割 → コンポーネントチームでも機能する

ガバナンスのためのドキュメント

RFC：新しい技術やプラクティスの提案を非同期に議論する。分散チームで特に有効
ADR：アーキテクチャ決定の背景・当時のコンテキスト・却下した選択肢を記録する

どちらも「後から入ってきた人が、なぜその決定がなされたかを理解できる」ことを目的としています。分散チームで働いた経験があると、この価値は実感しやすいはずです。

外部依存は健康診断の指標

スプリント中に外部依存でブロックされる頻度が高いなら、マイクロフロントエンドの境界設定を見直すべきサインだと述べられています。逆に、複数のマイクロフロントエンドをまたぐ変更が年に 1〜2 回程度なら、分割は妥当だと判断できます。

指標として使えるので、導入後の振り返りに持ち込みやすい考え方です。

読みどころのまとめ

本書を通して繰り返される主張は、次の 3 点に集約できます。

完璧なアーキテクチャは存在しない。あるのはコンテキストに対するトレードオフだけ
技術的決定と組織構造は分離できない
推測ではなくデータで境界を決める

いずれもマイクロフロントエンド固有の話ではなく、分散アーキテクチャ全般に通用する原則です。実際、マイクロフロントエンドを採用しない判断をした人にとっても、4 章のトレードオフ分析や 10 章の組織論は十分に読む価値があります。

こんな方におすすめ

フロントエンドのスケーリングに組織的な限界を感じている方
既にマイクロサービスを運用していて、フロントエンドとの非対称性が気になっている方
アーキテクチャ選定の判断軸を言語化したい方
分散チームでのコミュニケーション設計に関心がある方

注意点

具体的なコードは 5 章に集中しており、実装レシピを期待すると肩透かしになります
2022 年刊行のため、モジュールフェデレーション周辺のエコシステムは執筆時点から進んでいます。設計思想の部分を主に読むのが良さそうです
「3 チーム以上がフロントエンドに専従している中〜大規模組織」向けという前提が明示されています。小規模プロジェクトでは適用が難しい話も含まれます

おわりに

個人的にもっとも価値を感じたのは、3 章の意思決定フレームワークです。「定義・構成・ルーティング・コミュニケーション」の 4 つを先に決めるという枠組みは、マイクロフロントエンドに限らず、フロントエンドの構成を検討する場面全般で使える思考の型になっています。

そして最終章まで読み進めると、この本が本当に扱っていたのは技術ではなく「チームがどうすれば自律的に動けるか」だった、ということが見えてきます。アーキテクチャの本でありながら組織の本でもある。その二重性こそが、本書を単なる技術解説書と分けている点だと感じました。

分散アーキテクチャに関わる方には、一読をおすすめします。