マイクロサービス vs モノリスを徹底比較！2026年最新のシステム構成と選び方

はじめに：アーキテクチャ選定に絶対的な正解はあるのか

システム開発やDX推進の現場において、「マイクロサービス（Microservices Architecture）」と「モノリス（Monolithic Architecture）」のどちらを採用すべきかという議論は、技術者やアーキテクトの間で長年にわたり交わされてきました。

2010年代半ばから後半にかけては、NetflixやAmazonといった巨大テック企業の成功事例が脚光を浴び、「これからはすべてのシステムがマイクロサービスを目指すべきであり、モノリスは旧態依然としたレガシー構造である」という極端な風潮が一部で見られました。

しかし現在、ソフトウェアエンジニアリング業界におけるアーキテクチャに対する理解は、より成熟した現実的な視点へと回帰しています。

Microsoftは公式のアーキテクチャガイドにおいて、マイクロサービスを「高い回復性、スケーラビリティ、独立したデプロイ可能性を実現できる強力なスタイル」と評価する一方で、その採用には設計、運用、監視、さらには組織文化そのものに及ぶ高度な複雑性の管理が求められると警鐘を鳴らしています。

また、AWSの公式ドキュメント（モノリスとマイクロサービスアーキテクチャの違いに関する技術解説）においても、要件が明確でシンプルな軽量アプリケーションや、初期の概念実証（PoC）、プロトタイプ開発においてはモノリスが極めて現実的で効果的な選択肢であると説明されています。

つまり、現代のシステム開発における結論は極めて明快です。どちらか一方が普遍的に優れているわけではなく、「自社のビジネスフェーズ、チーム体制、運用の成熟度、そして解決すべき課題の性質に応じて最適な構造を選択すること」こそが本質です。

本記事では、クラウドベンダーの公式ガイドラインや実務上のベストプラクティスに基づき、モノリスとマイクロサービスの根本的な違い、メリット・デメリット、データ整合性やインフラの現実解、そして近年急速に支持を集める「モジュラーモノリス」を含めた実践的な選定フレームワークを体系的に解説します。

第1章モノリス（Monolithic Architecture）とは何か

モノリシックアーキテクチャの基本定義

モノリシックアーキテクチャとは、アプリケーションを構成するすべての機能要素を単一のコードベースにまとめ、ひとつの実行単位としてビルド・デプロイ・稼働させる設計様式を指します。

一般的なモノリスシステムでは、以下のようなコンポーネントがひとつの論理的なパッケージとして統合されています。

ユーザーインターフェース（UI）層またはフロントエンドレンダリング層
各種ドメインの業務処理を司るビジネスロジック層（認証、注文、在庫、決済など）
データベースへの問い合わせや更新を制御するデータアクセス層（ORMなど）
外部システムやクライアントと通信するための共通APIインターフェース

AWSの公式解説においても、モノリスは「単一のコードベース内で複数のビジネス機能を実行する伝統的かつ標準的なソフトウェア開発モデル」として整理されています。

モノリスのアーキテクチャ構造と特徴

モノリスの最大の特徴は、システム内の機能間通信が「同一プロセス内」で行われる点にあります。

┌─────────────────────────────────────────────────────────┐
│              Monolithic Application                     │
│                                                         │
│  ┌───────────────┐ ┌───────────────┐ ┌───────────────┐  │
│  │ User Module   │ │ Order Module  │ │ Payment Module│  │
│  └───────┬───────┘ └───────┬───────┘ └───────┬───────┘  │
│          │                 │                 │          │
│          └─────────────────┼─────────────────┘          │
│                            ▼                            │
│                  Data Access Layer                      │
└────────────────────────────┬────────────────────────────┘
                             ▼
                 Shared Database (RDBMS)

モノリスが持つ主要な特徴は以下の4点に集約されます。

単一デプロイ単位：ビルド成果物（JAR、WAR、単一バイナリ、コンテナイメージなど）がひとつであり、システム全体を一度の手順でサーバー群に展開します。
単一の統合コードベース：すべての機能が同一のリポジトリで管理され、共通ライブラリの参照や内部クラス・関数の直接呼び出しが容易です。
共有データベース：多くの場合、ひとつのリレーショナルデータベース（RDBMS）を共有し、外部キー制約やトランザクション処理によってデータの厳密な一貫性を担保します。
インプロセスメモリ間通信：機能モジュール間のやり取りは、ネットワーク経由ではなくインメモリの関数呼び出しやメソッド呼び出しによって完結します。

第2章マイクロサービス（Microservices Architecture）とは何か

マイクロサービスの基本定義

Microsoft Azure Architecture Centerにおいて、マイクロサービスは「小さく、自律的で、疎結合なサービスの集合体として構築されるアーキテクチャスタイル」と定義されています。

モノリスのようにすべてをひとつのアプリケーションに包含するのではなく、特定のビジネス機能ごとに境界を区切った独立したサービス群を構築し、それらがネットワーク経由のAPI（HTTP/REST、gRPC、メッセージキューなど）を通じて連携し、ひとつの巨大なシステムを成立させます。

基本構造とコンポーネント配置

典型的なマイクロサービスアーキテクチャの論理構造は、以下の図のように表現されます。

                     [ Client / Web / Mobile ]
                                 │
                                 ▼
                    ┌─────────────────────────┐
                    │       API Gateway       │
                    └────────────┬────────────┘
         ┌───────────────────────┼───────────────────────┐
         │ (HTTP/REST or gRPC)   │                       │
         ▼                       ▼                       ▼
┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│   User Service   │    │  Order Service   │    │ Payment Service  │
│  (Business Logic)│    │  (Business Logic)│    │  (Business Logic)│
└────────┬─────────┘    └────────┬─────────┘    └────────┬─────────┘
         ▼                       ▼                       ▼
   ┌───────────┐           ┌───────────┐           ┌───────────┐
   │  User DB  │           │ Order DB  │           │ Pay DB    │
   └───────────┘           └───────────┘           └───────────┘

マイクロサービスを支える中核概念

マイクロサービスを正しく機能させるためには、単にコードを物理的に分割するだけでなく、以下の設計原則を遵守することが求められます。

ビジネス能力に基づく分割（Business Capability）：技術的なレイヤー（UI層、ロジック層、DB層）ではなく、ビジネス価値を提供するドメイン単位（顧客管理、受発注、在庫配送など）でサービス境界を設定します。
境界づけられたコンテキスト（Bounded Context）：ドメイン駆動設計（DDD）の概念に基づき、サービスごとにモデルや用語の定義を完全にカプセル化します。例えば「ユーザー」という概念であっても、認証サービスにおける定義と配送サービスにおける定義を混同させず、サービス境界内で完結させます。
Database per Service（サービス単位の独立データストア）：マイクロサービスでは原則として、各サービスが専有のデータストアを持ちます。他サービスのテーブルを直接SQLで結合（JOIN）して参照・更新することは厳禁とされ、必ず相手サービスの公開APIを経由してやり取りします。
自律性と独立デプロイ可能性：各サービスは他のサービスを停止させることなく、単独でビルド、テスト、本番リリースが完了できる自律性を備えている必要があります。

第3章モノリスとマイクロサービスの徹底比較

主要クラウドベンダーの公式ガイダンスや分散システムの実務知見に基づき、両アーキテクチャの特性を一覧表として比較します。

評価軸	モノリス（単一構造）	マイクロサービス（分散構造）
デプロイ単位	システム全体を一括でデプロイ	サービスごとに個別のタイミングで独立デプロイ
スケーリング	アプリ全体を複製して水平スケール	高負荷なサービスのみを選択的に局所スケール
初期開発速度	設計オーバーヘッドが少なく極めて高速	インフラ整備や通信設計が必要で立ち上がりが遅い
運用・監視の複雑度	比較的シンプル（ログやメトリクスが集約）	極めて複雑（分散トレーシングや基盤運用が必須）
障害の影響範囲	一箇所のメモリリークやクラッシュが全体に波及	サーキットブレーカー等により局所的な影響に抑止可能
データ整合性	RDBMSのACIDトランザクションで強整合性を維持	結果整合性が基本となり、Sagaパターン等の設計が必要
技術スタックの自由度	単一の言語・フレームワークに統一される	サービス要件に応じたポリグロット（多言語）構成が可能
テストの容易さ	単体テストや統合テストを同一環境で完結できる	契約テスト、モック、外部通信を含む複雑な検証が必要
適した組織規模	単一〜少人数チーム（10人前後までが目安）	複数チームが自律的に協調する中〜大規模組織

第4章モノリスのメリットと直面する課題

モノリスがもたらす強力なメリット

モノリスは決して過去の遺物ではなく、多くのプロジェクトにおいて圧倒的に合理的です。その理由は以下の利点にあります。

シンプルな初期開発と迅速なタイムトゥマーケット：
サービス間の通信プロトコルやデータ直列化の設計、ネットワーク障害への事前配慮が不要なため、ビジネスアイデアを素早く動くソフトウェアとして形にするスピードはモノリスが圧倒的に優れています。
開発・デバッグ環境の平易さ：
開発者はローカルPC上で単一のプロセスとデータベースを立ち上げるだけで、システム全体の挙動を完全に再現できます。ブレークポイントを用いたコードステップ実行やスタックトレースの追跡も極めてスムーズです。
強固なデータ整合性の確保：
単一のRDBMSを利用する場合、データベース標準のローカルトランザクション（ACID特性）をそのまま利用できます。注文確定と在庫引き落とし、ポイント付与などの複雑な処理を単一のトランザクション内で確実にコミット・ロールバックできます。
低いインフラ基盤コスト：
複雑なコンテナオーケストレーション基盤やサービスディスカバリ用のミドルウェアを常時稼働させる必要がないため、運用コストやクラウドインフラの固定費を最小限に抑えられます。

モノリスが成長に伴って直面する課題

一方で、ビジネスが急拡大し、コードベースや開発チームが肥大化すると、モノリスは構造的な限界に直面し始めます。

コードベースの密結合と技術的負債：
明確なレイヤー分割を意識して開発を続けていても、時間の経過とともにモジュール間の境界が曖昧になりがちです。ある機能の微修正が、予期せぬ遠隔のモジュールに副作用を及ぼす「スパゲッティコード化」が発生しやすくなります。
デプロイのボトルネックとリリースリスク：
わずか数行の修正であっても、システム全体のビルド、長時間のテスト実行、そしてアプリケーション全体の再起動が必要になります。一箇所の不具合が原因でシステム全体のデプロイが中断・延期されるリスクを常に抱えることになります。
スケーリングの資源非効率性：
例えば「画像変換処理」や「機械学習によるレコメンド機能」など、特定の一機能のみにCPU負荷が集中した場合でも、システム全体をまるごと複製してスケールアウトしなければならず、ハードウェアリソースの消費効率が低下します。
組織的スケーラビリティの限界：
数十人以上の開発者が同一のリポジトリに対して同時にコミットを繰り返すと、Gitのマージコンフリクトの頻発、ビルド待ち時間の増大、リリース責任の所在の曖昧化が生じ、組織全体の開発速度が急速に低下します。

第5章マイクロサービスのメリットと複雑性の罠

マイクロサービスを採用する明確な利点

マイクロサービスは、モノリスが直面する組織と規模のボトルネックを打破するために設計されています。

独立したスケーラビリティとリソース最適化：
トラフィックの急増する注文受付サービスや決済サービスのみをピンポイントで数百コンテナ規模にオートスケールさせ、静的な管理サービスは最小限のリソースで稼働させるといった、柔軟かつ経済的なインフラ制御が可能です。
高頻度なリリースとデプロイの独立性：
各サービスを担当するチームが、他チームのスケジュールに束縛されることなく、1日に何回でも独立して本番環境へデプロイできます。新機能の市場投入スピード（Time to Market）を劇的に向上させることが可能です。
障害の局所化（Fault Isolation）：
仮に外部レコメンド連携サービスがエラーで停止した場合でも、適切なフォールバック処理を実装しておくことで、ECサイト全体の注文決済処理は停止させることなく正常に継続させることができます。
サービス特性に応じた技術選定の最適化：
高スループットな処理にはGo言語、複雑なドメインモデルの記述にはJava/C#、データ分析やAI推論にはPythonといったように、サービスごとの要件に最適な言語やデータベース（RDBMS、ドキュメント指向DB、KVSなど）を使い分けることが可能です。

マイクロサービス導入に伴う「分散システムの複雑性」という代償

マイクロサービスの恩恵を享受するためには、分散システム特有の極めて重いトレードオフを引き受けなければなりません。

通信オーバーヘッドとネットワーク障害のリスク：
モノリスにおける内部関数呼び出しはナノ秒〜マイクロ秒単位で完了しますが、マイクロサービスのHTTPやgRPC通信ではミリ秒単位のネットワークレイテンシが発生します。また、サービス間のネットワークは常に瞬断、遅延、パケットロスのリスクに晒されており、呼び出し元でのタイムアウト設定やリトライ処理が必須となります。
データ整合性の喪失とトランザクション管理の難化：
Database per Serviceの原則により、単一のデータベーストランザクションを利用した一括更新が不可能になります。複数サービスにまたがる処理の整合性を保つためには、補償トランザクション（Compensating Transaction）を伴う「Sagaパターン」やイベント駆動アーキテクチャによる結果整合性（Eventual Consistency）の設計が必要不可欠であり、実装難易度は跳ね上がります。
運用監視・可観測性（Observability）の負荷急増：
1回のリクエストが数十個のサービス間を飛び交うため、どこで遅延やエラーが発生したかを特定することが困難になります。分散トレーシング（OpenTelemetry等）の導入や、サービスメトリクス・ログの統合基盤構築が運用上不可欠です。

第6章ネットワーク耐障害性とデータ整合性の真実

通信障害に対する誤解：モノリスとマイクロサービスの違い

アーキテクチャの比較において、「モノリスではネットワーク障害が起きない」と誤認されることがありますが、これは正確ではありません。

モノリス構成であっても、アプリケーションサーバーと外部のデータベースサーバー間、キャッシュサーバー間、あるいは決済代行会社などのサードパーティ外部APIとの通信においては、当然ながらネットワーク遅延や切断のリスクが存在します。

両者の本質的な相違点は、「主要な業務ロジック間の内部呼び出しにおいてネットワークを介するかどうか」にあります。

【モノリスの内部呼び出し】
User Logic ────[ In-Memory Function Call ]────► Order Logic
※同一プロセス内のため、ネットワーク起因の遅延やパケット消失は構造上発生しない。

【マイクロサービスのサービス間呼び出し】
User Service ────[ Network (HTTP/gRPC) ]────► Order Service
※ネットワークの瞬断、パケットロス、DNS解決失敗、接続プール枯渇などの障害リスクが常時介在する。

マイクロサービスでは、サービス間の境界ごとにネットワークが介在するため、通信失敗を前提としたアーキテクチャ設計が義務付けられます。

サーキットブレーカー（Circuit Breaker）：呼び出し先のサービスがダウンしている場合、即座にリクエストを遮断してエラーまたはキャッシュ応答を返し、障害のドミノ倒し（カスケード障害）を防止する。
指数バックオフ付きリトライ（Exponential Backoff Retry）：一時的なネットワーク瞬断に対して、再試行間隔を徐々に広げながら安全に再リクエストを行う。
タイムアウトの厳格な設定：通信が無限に待機してスレッドプールやコネクションが枯渇することを防ぐ。

分散トランザクションとSagaパターンの現実

モノリスでは以下のように容易に実現できたトランザクション処理が、マイクロサービスでは高度な設計課題へと変化します。

// モノリスにおけるACIDトランザクションの例（擬似コード）
@Transactional
public void processOrder(OrderRequest req) {
    userAccountRepository.deductBalance(req.getUserId(), req.getAmount());
    inventoryRepository.reduceStock(req.getProductId(), req.getQuantity());
    orderRepository.save(new Order(req));
} // いずれか失敗すれば全自動でロールバック

マイクロサービスではデータベースが物理的に分離されているため、2フェーズコミット（2PC）のような重い分散トランザクションは通常推奨されず、代わりにSagaパターンが採用されます。

Sagaパターンには、オーケストレーターが各サービスに順次指示を出す「オーケストレーション型」と、各サービスが発行するイベントを購読して連鎖的に処理する「コレオグラフィ型」が存在します。いずれの方式においても、後続の処理（例：決済）が失敗した際には、先行して成功していた処理（例：在庫仮押さえ）を取り消すための「補償トランザクション（Compensating Action）」を明示的にプログラミングする必要があります。この実装・運用の複雑さは、マイクロサービスを採用する際の最大の技術的ハードルのひとつです。

第7章インフラ基盤の現実解：コンテナ環境とサービスメッシュの選定基準

Kubernetesは必須か？マネージドコンテナという選択肢

マイクロサービスの実装基盤としてKubernetes（K8s）はデファクトスタンダードとして広く認知されています。自己修復（セルフヒーリング）、自動スケーリング、ローリングアップデート、宣言型リソース管理など、分散コンテナ群を統括する機能が網羅されているためです。

しかし、Kubernetesクラスタ自体の設計、運用、バージョン追従、コントロールプレーンの保護には極めて高度なSRE（Site Reliability Engineering）スキルと多大な工数が必要です。

Microsoftの公式アーキテクチャドキュメントでも示されているように、コンテナオーケストレーションの選択肢はフルマネージドKubernetes（AKS等）だけではありません。現在では以下のようなマネージドコンテナ環境が有力な選択肢となっています。

Azure Container Apps：Kubernetesの複雑な管理を抽象化し、マイクロサービス開発に必要なKEDA（イベント駆動オートスケール）やDapr（分散アプリケーションランタイム）を容易に扱えるマネージド環境。
AWS ECS / AWS Fargate：クラスタ管理のオーバーヘッドを大幅に削減し、コンテナをサーバーレス感覚で安定運用できる実務的な選択肢。
Google Cloud Run：リクエストに応じた自動スケーリングが強力で、コンテナ化された個別の軽量マイクロサービスを効率よくホスト可能。

専任のインフラ基盤チームが存在しない組織においては、最初からKubernetesを自前運用するのではなく、マネージドコンテナプラットフォームを採用することで、運用コストを大幅に抑制しながらマイクロサービスのメリットを享受することが可能です。

Service Mesh（サービスメッシュ）の適切な位置づけ

IstioやLinkerdに代表されるService Meshは、マイクロサービス間の通信制御（mTLS暗号化、トラフィック分割、詳細な可観測性の収集など）をアプリケーションコードから分離し、インフラ層のサイドカープロキシで担保する技術です。

米国国立標準技術研究所（NIST）のマイクロサービスセキュリティガイドライン（SP 800-204シリーズ）でも、サービス間相互認証やゼロトラストアーキテクチャを確立するための有効な手段としてサービスメッシュのアーキテクチャが解説されています。

しかし、サービスメッシュはすべてのマイクロサービスで無条件に導入すべき「一般的な標準ツール」ではありません。プロキシの挟み込みによるわずかなレイテンシの増加や、クラスタ内のリソース消費、トラブルシューティングの高度化といった追加コストが確実に発生します。実務上は、サービス数が数十規模を超え、通信の可視化やmTLSによる厳格なゼロトラスト暗号化が強く求められるフェーズに達して初めて導入を検討するのが現実的です。

第8章クラウドネイティブ時代の有力解「モジュラーモノリス」

「クラウドネイティブ＝マイクロサービス」という誤解

現代のシステム設計において最も頻繁に見られる誤解のひとつが、「クラウドネイティブなモダンアーキテクチャを実現するには、最初からマイクロサービスに分割しなければならない」という考え方です。

クラウドネイティブの本質は、コンテナ化、自動化されたCI/CDパイプライン、Infrastructure as Code（IaC）、動的なスケーラビリティ、そして可観測性にあります。これらの特性は、モノリス構成であっても十分に享受することが可能です。

モジュラーモノリス（Modular Monolith）のアーキテクチャ設計

そこで現在、多くのテック企業やアーキテクトから「第一の選択肢」として再評価されているのがモジュラーモノリスです。

モジュラーモノリスとは、デプロイメントの単位としては単一のアプリケーション（ひとつのプロセス・コンテナ）でありながら、コードベースの内部構造がドメイン境界に基づいて厳密にモジュール化されているアーキテクチャを指します。

┌─────────────────────────────────────────────────────────────┐
│                 Modular Monolithic App                      │
│                                                             │
│  ┌────────────────────────┐     ┌────────────────────────┐  │
│  │      User Module       │     │      Order Module      │  │
│  │ ┌────────────────────┐ │     │ ┌────────────────────┐ │  │
│  │ │ Public Interface   │◄┼─────┼─┤ Public Interface   │ │  │
│  │ └─────────┬──────────┘ │     │ └─────────┬──────────┘ │  │
│  │           ▼            │     │           ▼            │  │
│  │  Internal Logic & DB  │ │     │  Internal Logic & DB  │ │  │
│  └────────────────────────┘     └────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
                               │
                               ▼
                    Single Deployable Unit

モジュラーモノリスの設計規範には以下の原則が含まれます。

各モジュールは厳格に定義されたパブリックインターフェースのみを外部に公開し、内部実装クラスやスキーマへの直接アクセスを禁止する。
モジュール間の呼び出しはインプロセスで行われるため、ネットワーク遅延や通信障害のハンドリングが不要。
データベーススキーマもモジュールごとに論理的に分離（テーブルプレフィックスの分離や別スキーマ管理）し、他モジュールのテーブルと暗黙的に結合させない。

なぜモジュラーモノリスが強力なのか

モジュラーモノリスは、モノリスの「運用のシンプルさ、ローカル開発の容易さ、ACIDトランザクションの恩恵」を維持したまま、モノリス最大の弱点であった「コードの肥大化と密結合」を強力に防止します。

さらに、ビジネスが成長し、特定のモジュール（例：決済やレコメンド）だけを個別にスケールアウト・独立リリースしたくなった場合には、すでに境界が綺麗に分離されているため、そのモジュールだけを最小限のコストでマイクロサービスとして外部に切り出すことが可能です。Martin Fowler氏をはじめとする多くのソフトウェア設計思想家が提唱するように、「まずは規律あるモジュラーモノリスから始め、必要に応じて段階的に切り出す」アプローチは極めて実用的です。

第9章組織構造とコンウェイの法則（Conway’s Law）

アーキテクチャとチーム人数の現実的な目安

アーキテクチャの成否は、純粋な技術選定だけでなく、開発組織の構造やコミュニケーションのあり方に深く規定されます。これを示す有名な法則がコンウェイの法則（「システムを設計する組織は、その組織のコミュニケーション構造を反映した設計を生み出す」）です。

実務における一般的な判断目安として、開発者規模に応じた適正は以下のように整理されます（※これらは厳密な一次資料上の絶対値ではなく、組織コミュニケーションの複雑度に基づく実務的目安です）。

10人前後の単一チーム規模：
全員がひとつの部屋やオンラインの共通チャンネルで緊密に対話できるフェーズです。この規模でマイクロサービスを導入すると、サービスの数に対して開発者が不足し、1人のエンジニアが複数のサービスと通信基盤の保守に追われる「運用破綻」を引き起こします。単一のモノリスまたはモジュラーモノリスが最も高い開発生産性を発揮します。
数十人〜数百人規模（複数の自律チーム）：
組織が複数の機能別チーム（Stream-aligned teams）に分かれ、チーム間の調整コストやマージ待ちが開発のボトルネックになり始めた段階です。このフェーズに至って初めて、チーム境界とサービス境界を一致させるマイクロサービスの恩恵が、分散システムの運用コストを上回るようになります。

Amazonの「2ピザチーム」規則とサービスの自律性

マイクロサービスのパイオニアであるAmazonでは、「2枚のピザを分け合える規模のチーム（6〜10人程度）」が単一のサービスに対してエンドツーエンドの責任（設計、実装、テスト、デプロイ、運用保守＝You build it, you run it）を持つ組織モデルが採用されています。

マイクロサービスを成功させるためには、システムを分割する前に、組織側が「サービスごとに責任を持って自律稼働できるチーム体制」へと進化していることが前提条件となります。

第10章レガシーモノリスからの移行戦略：Strangler Fig Pattern

ビッグバン型移行の失敗リスク

稼働中のモノリスシステムを刷新する際、システム全体をゼロからマイクロサービスとして一括で作り直す「ビッグバン型リプレイス（Big Bang Rewrite）」は、最も失敗率が高いアプローチのひとつです。長期間にわたる機能開発の凍結、仕様のブラックボックス化、カットオーバー時の予期せぬトラブルなど、事業上のリスクが極めて大きいためです。

ストラングラー・フィグ・パターン（Strangler Fig Pattern）の段階的適用

AWSやMicrosoftの移行ガイドラインにおいて推奨されている標準的な移行手法がストラングラー・フィグ・パターン（絞め殺し植物パターン）です。巨木に巻き付いて徐々に成長し、最終的に宿主の木を置き換える植物の生態になぞらえて命名されました。

【ステップ1：境界設定とプロキシの導入】
Clients ───► [ API Gateway / Reverse Proxy ] ───► [ Existing Monolith ]

【ステップ2：新機能・特定機能の切り出し】
Clients ───► [ API Gateway ] ──┬──► (Legacy Routes) ──► [ Existing Monolith ]
                               └──► (New Route)      ──► [ New Microservice ]

【ステップ3：段階的なモジュール移行と旧システムの廃止】
Clients ───► [ API Gateway ] ─────► [ Microservices Cluster ]
                                    (Old Monolith is decommissioned)

具体的な移行プロセスは以下の順序で進行します。

ルーティング層（API Gateway / リバースプロキシ）の設置：クライアントと既存モノリスの間にプロキシを配置し、トラフィックを一元管理します。
新規機能のマイクロサービス化：今後新設する機能は既存モノリスに追加せず、最初から独立したマイクロサービスとして新規構築し、プロキシからルーティングします。
境界が明確な既存ドメインの切り出し：既存モノリスの中から依存関係が比較的少なく、スケール要求の高いドメイン（例：通知機能、認証機能、決済機能など）を特定し、イベント駆動やデータ同期を活用しながら段階的に新サービスへ移行します。
旧モジュールの段階的停止：新サービスが安定稼働した段階で、モノリス側の古いコードを順次削除・停止していきます。

第11章アーキテクチャ選定フレームワーク：自社に適した判断フロー

自社のプロジェクトやシステムにおいて、どちらのアプローチを選択すべきかを判断するための実務チェックリストです。

                    [ アーキテクチャ選定フロー ]
                                 │
                                 ▼
      【質問1】開発チーム全体の規模は10人前後の単一チームか？
                   ├────── YES ──────► [ モノリス / モジュラーモノリス ]
                   ▼ NO
      【質問2】ドメイン境界や業務仕様がまだ流動的で未確定か？
                   ├────── YES ──────► [ モジュラーモノリス ]
                   ▼ NO
      【質問3】特定機能のみ極端なスケーリング要求があるか？
           または独立した高頻度リリースが組織的に不可欠か？
                   ├────── NO  ──────► [ モジュラーモノリス ]
                   ▼ YES
      【質問4】SRE専任者や可観測性基盤を運用するリソース・技術力があるか？
                   ├────── NO  ──────► [ マネージドコンテナ＋部分的分散 ]
                   ▼ YES
                   └─────────────────► [ マイクロサービスアーキテクチャ ]

チェックシートによる自己診断

以下の項目をチェックし、該当数が多い方向性を評価してください。

モノリス / モジュラーモノリス寄りのシグナル

新規事業の立ち上げ、PoC、MVP（実用最小限の製品）検証のフェーズである。
開発エンジニアが10人前後の単一チームで構成されている。
ビジネスモデルが確立しておらず、データモデルや仕様変更が頻繁に発生する。
インフラやKubernetesの保守運用に専任のリソースを割くことができない。
データベースの厳密なACIDトランザクションと一貫性が最優先事項である。

マイクロサービス寄りのシグナル

複数の独立したチーム（合計数十人以上）が並行して機能開発を行っている。
特定のサービス（動画処理、決済、リアルタイム通信など）のみ負荷が桁違いに高い。
チームごとに他チームの影響を受けずに毎日複数回の本番デプロイを行いたい。
障害発生時に一部機能が縮退運転しても、主要な業務フローを絶対に停止させたくない。
ログ分析、メトリクス監視、分散トレーシングを運用・改善できる体制が整っている。

第12章よくある質問（FAQ）

Q1. スタートアップの初期開発でマイクロサービスを採用するのは避けるべきですか？

多くの場合、避けるべきです。スタートアップの初期フェーズにおいて最も重要なのは「顧客のフィードバックを得てプロダクトを素早く改善するスピード」です。ビジネスモデルが固まっていない段階でサービス境界を正しく設定することは極めて困難であり、誤った境界設定による分散システムの修正コストは莫大になります。初期はモジュラーモノリスで俊敏に開発を進め、PMF（プロダクトマーケットフィット）を達成して組織と負荷が拡大した後に分割を検討するのが王道です。

Q2. マイクロサービスを採用する場合、データベースは絶対に物理分離しなければなりませんか？

原則として分離する必要があります。複数のマイクロサービスが同一のデータベースや同一のテーブルを直接参照・更新してしまうと、データベース層を介してシステム全体が強固に密結合してしまい、「独立デプロイが不可能になる」「一方のスキーマ変更で他方が停止する」という最悪の状況（分散モノリス）に陥ります。完全な別インスタンスを用意できない場合でも、論理スキーマやアクセスユーザーを厳格に分離し、他サービスへのデータアクセスは必ずAPIを経由させる規律が不可欠です。

Q3. モノリスからモジュラーモノリスへ移行する際、何から始めるべきですか？

まずはコードベース内のパッケージ構造やディレクトリ構造を機能ドメイン単位に再編成し、モジュール間の暗黙的な循環参照を排除することから始めます。Javaであればパッケージプライベートのアクセス修飾子やArchUnit、Goであれば内部パッケージ（internal）、TypeScriptであればプロジェクト参照などを利用し、「公開インターフェース以外への直接参照をビルド時にエラーにする」静的解析ルールを導入することが効果的です。

Q4. サービスメッシュはマイクロサービスを始めたらすぐに導入すべきですか？

初期から導入する必要はありません。数個〜十数個程度のサービス規模であれば、API Gatewayと各クラウドプロバイダが提供するロードバランサー、標準の分散トレーシングライブラリで十分運用可能です。サービスメッシュの導入は、サービス間通信のmTLS強制化や高度なカナリアリリースなど、明確なセキュリティ・運用要件が生じた段階で検討してください。

まとめ：段階的アーキテクチャ進化論

マイクロサービスとモノリスの対立は、「どちらが新しく優れたアーキテクチャか」という単純な優劣の争いではありません。

AWSの公式解説にあるように、要件が明確でシンプルなシステムや初期フェーズにおいてはモノリスが圧倒的な効率性を誇ります。一方でMicrosoftが示す通り、複雑で大規模なビジネスを自律的な複数チームでスケールさせるためには、マイクロサービスが提供する高い回復性と独立性が不可欠な武器となります。

現代のシステム開発において最も成功確率の高いアプローチは、「規律あるモジュラーモノリスから開発をスタートさせ、事業成長と組織拡大のプレッシャーに応じて、ボトルネックとなる境界から順次マイクロサービスへと切り出していく」という段階的アプローチです。

流行やバズワードに惑わされることなく、自社の事業フェーズ、チーム体制、運用リソースを客観的に見極め、現時点で最もビジネス価値を最大化できるアーキテクチャを選択してください。