全体構造の選び方 ― モノリス/マイクロサービス/モジュラーモノリス ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリ第2弾として、アプリケーションの全体構造の選び方について解説する記事です。

「いくつの塊に分けるか／連携か一体か」は、ソフトウェアアーキテクチャで最も後戻りが効かない決断です。本記事ではモノリス／マイクロサービス／モジュラーモノリスの3パターンを比較し、規模・運用体制・成長フェーズに応じた選び方と「モジュラーモノリスから始めて必要に応じて切り出す」という現代の定石を示します。

このカテゴリの他の記事

「分けるか、まとめるか」は後戻りできない

1つのアプリとして作ったものを途中から複数に分けようとすると、既存コードを大規模に書き直すことになり、現実的には作り直しに近い大工事になります。逆に、複数に分けてしまったものを1つに統合するのも、データ移行と業務停止を伴う重い工事です。要件定義のタイミングで、将来の規模感と運用体制を見据えて腰を据えて決める必要があります。

全体構造は他の全ての技術選定の前提になります。ここを曖昧にしたまま先に進むと、後続の決定を全てやり直すことになります。フレームワーク、言語、人員構成、クラウド構成、テスト戦略、デプロイ方式。どれも全体構造に依存して決まります。

1つのアプリにまとめる場合と、機能ごとに分けて連携させる場合では、必要なエンジニアの人数も得意分野も桁違いに変わります。前者なら5人で作れるものが、後者だと20人必要になることも珍しくありません。

「とりあえず作って、後で分割する」は理論上は可能ですが、実質的には作り直しになります。甘く見ると痛い目を見ます。

3つの基本パターン

アプリケーションの全体構造は、大きく分けてモノリス・マイクロサービス・モジュラーモノリスの3つです。

flowchart LR
    subgraph MONO["モノリス"]
        M1[全機能<br/>1コード/1DB]
    end
    subgraph MODMONO["モジュラーモノリス"]
        MM1[モジュールA]
        MM2[モジュールB]
        MM3[モジュールC]
        MM1 -.|境界明示| MM2
        MM2 -.| MM3
        MM_DB[(共通DB)]
        MM1 --> MM_DB
        MM2 --> MM_DB
        MM3 --> MM_DB
    end
    subgraph MICRO["マイクロサービス"]
        MS1[サービスA]
        MS2[サービスB]
        MS3[サービスC]
        MS_DB1[(DB-A)]
        MS_DB2[(DB-B)]
        MS_DB3[(DB-C)]
        MS1 --> MS_DB1
        MS2 --> MS_DB2
        MS3 --> MS_DB3
        MS1 -.API/Event.- MS2
        MS2 -.- MS3
    end
    classDef mono fill:#dbeafe,stroke:#2563eb;
    classDef mod fill:#fef3c7,stroke:#d97706;
    classDef micro fill:#fae8ff,stroke:#a21caf;
    class MONO,M1 mono;
    class MODMONO,MM1,MM2,MM3,MM_DB mod;
    class MICRO,MS1,MS2,MS3,MS_DB1,MS_DB2,MS_DB3 micro;

パターン	ざっくりした説明
モノリス	全機能を1つのアプリにまとめる伝統的な形。最もシンプル
マイクロサービス	機能ごとに独立したアプリに分け、ネットワーク越しに連携する形
モジュラーモノリス	見た目は1つのアプリだが、内部をきっちり区切る中間形

2010年代にマイクロサービスが爆発的に流行しましたが、今はモジュラーモノリスへの揺り戻しの真っ只中です。新しい・古いではなく、プロジェクトの規模と組織に合わせて選ぶだけ、という冷静な認識が定着しつつあります。

モノリス（Monolith）

「Monolith」（一枚岩）の名前通り、全機能を1つのアプリケーションにまとめる最も伝統的な構造です。ログインも決済も商品管理も、全て同じコードベース・同じサーバー・同じデータベースで動かします。ECサイトから業務システムまで、世の中の多くのアプリは今もこの形で作られています。

小〜中規模では作り始めが圧倒的に速く、データの一貫性を保ちやすく、不具合調査もしやすい。一方で巨大化するとビルド時間が長くなり、多人数開発では変更の衝突が頻発し、一部の障害がアプリ全体を止めます。

メリット	デメリット
作り始めが圧倒的に速い	巨大化すると開発が重くなる
データの一貫性を保ちやすい	多人数開発では変更の衝突が増える
不具合調査がしやすい	一部の障害がアプリ全体を止める
運用・監視がシンプル	技術選定が全体で統一される

代表例：Ruby on Rails のアプリ / Spring Boot の業務システム / WordPress

「モノリス＝古い」は誤解です。小〜中規模では今も最良の選択肢であり続けています。

マイクロサービス（Microservices）

マイクロサービスは、機能ごとに独立した小さなアプリを作り、ネットワーク越しに連携させる構造です。ECサイトなら「ユーザー管理」「商品管理」「決済」「配送」をそれぞれ別アプリとして作り、互いにAPIで通信しながら1つのサービスを構成します。

2010年代にNetflixやAmazonが採用したことで広く知られるようになりました。機能ごとにチームを分けて並行開発でき、部分的にスケールできる一方、運用の複雑さが桁違いに増えるのが最大の弱点です。サービスの数が増えるほど、監視・ログ集約・障害追跡の仕組みを整えること自体が巨大プロジェクトになります。

メリット	デメリット
機能ごとに別チームで並行開発できる	全体の仕組みが非常に複雑になる
一部障害を局所化できる	運用・監視コストが桁違いに高い
サービスごとに技術を選べる	サービス間通信で性能が落ちやすい
部分的にスケールできる	不具合の原因特定が困難

代表例：Amazon / Netflix / メルカリ の大規模サービス

大規模な組織と運用体制があって初めて成立します。小さなチームが真似すると、ほぼ破綻します。

Segmentの「Goodbye Microservices」（業界事例）

分析基盤の Segment は2013年から140以上のマイクロサービスを運用していましたが、運用の複雑さに耐えきれず、2018年に「Goodbye Microservices」と題した記事を公開してモノリスへ回帰した、という事例があります。サービス間の障害連鎖、デプロイの協調、テスト環境の爆発的な増加。個別の問題はどれも解決可能でも、重なると手に負えなくなる、という話が広く共有されました。

あれだけの技術力を持つ企業でも管理しきれなかった、という事実は重いものです。当時、マイクロサービス礼賛のムードがピークだった業界で「ついに出た」と冷笑されていたのを覚えている人も多いはずです。「Netflixが使っているから」という理由でマイクロサービスに飛びつく前に、この事例を思い出す価値があります。

分散は足し算ではなく掛け算で複雑化します。サービス数が2倍になれば、連携パターンは4倍になります。

モジュラーモノリス（Modular Monolith）

モジュラーモノリスは、見た目はモノリス（1つのアプリ）だが、内部を明確な境界で区切る中間構造です。内部は「ユーザー」「商品」「決済」のようなモジュールに分かれ、モジュール同士は勝手に呼び合わず、決められた窓口（インターフェース）経由でしか連携しません。

1つのアプリなのでデプロイや運用はモノリスと同じくシンプル、かつ内部の分割が明確なので、将来マイクロサービス化が必要になった時に比較的低コストで切り出せる。「モノリスの運用しやすさ」と「マイクロサービスの構造的きれいさ」のいいとこ取りを狙った構造です。

メリット	デメリット
運用はモノリスと同じくシンプル	内部境界を守る規律が必要
将来の分割が比較的容易	分割しなければ意味が薄い
大人数開発でも衝突が減る	設計の難易度がやや高い
1つのDBで整合性を保ちやすい	マイクロサービスほどの並列性は出ない

現代の本命構成です。迷ったらまずこれで始めて、必要になったら部分的にマイクロサービス化する。これが現在の定石です。

モジュラーモノリスは「迷ったらここ」の本命構成。分割は後からいつでもできます。

3者の比較

3つのパターンを主要な観点で並べると、モノリスは「作りやすさ」と「運用のしやすさ」で圧勝し、マイクロサービスは「並列開発」と「障害の局所化」で圧勝します。モジュラーモノリスは中間に位置し、ほとんどの観点で○以上というバランスの良さが特徴です。

観点	モノリス	モジュラー モノリス	マイクロ サービス
作り始めやすさ	◎	◯	×
運用コストの低さ	◎	◯	×
大規模並列開発	×	△	◎
障害の局所化	×	△	◎
将来の分割容易性	×	◎	―
必要な人員・スキル	少	少〜中	多
学習コスト	低	中	高

マイクロサービスは「できること」が多い反面、「払うコスト」も圧倒的に大きい、と認識しておくのが正しい視点です。

判断基準

① 規模とチーム人数

全体構造を決める最大の要因はチーム人数です。1〜10人のチームでマイクロサービスを採用すると、機能ごとの分割に人員が足りず、1人で複数サービスを掛け持ちすることになり、結局は運用コストだけが増えて効果は出ません。

逆に数十〜数百人の組織でモノリスを維持すると、全員が同じコードベースを触ることになり、変更の衝突・デプロイの競合・レビューの遅延が常態化します。この場合は機能単位で分けたほうが、チームごとに独立して動ける分、全体の生産性が上がります。

規模	向く形
数人〜10人で作る	モノリスが圧倒的に有利
10〜30人	モジュラーモノリスが無難
30人以上・複数拠点	マイクロサービスを検討

Conway’s law（組織構造がアーキテクチャに反映される経験則）は現実に強く働きます。1チームなのにマイクロサービスを選んでも、分割の効果は出ず運用コストだけが跳ね上がります。

② 運用できるか

マイクロサービスの運用は想像以上に大変です。1つのアプリを動かすだけでも監視・ログ・デプロイの仕組みが必要ですが、それが10個・20個になると、サービス間通信の監視や横断的な障害追跡のために専用基盤（分散トレーシング、サービスメッシュ：サービス間通信を肩代わりする共通基盤 等）が必須になります。

これらを運用するには、コンテナや分散システムに慣れた専任のインフラ人員が最低でも数人必要です。「機能が独立していて気持ちいい」というのは開発者側の感覚で、運用側から見ると管理対象が指数関数的に増えます。

• サービス横断の監視・ログ基盤を作れる人員はいるか
• コンテナや分散システムの運用経験はあるか
• 不具合を複数サービスを跨いで追える体制はあるか

この3つのどれかが欠けていたら、マイクロサービスは選ばない方が良い。例外なく、です。

③ 成長フェーズ

プロジェクトの成長段階によっても最適な構造は変わります。アイデア検証・MVP（Minimum Viable Product、必要最小限の機能で作った試作版）の段階では、とにかく早くリリースして市場の反応を見るのが最優先です。

作るのが一番速いモノリスで始めるのが定石で、いきなりマイクロサービスで始めると、機能を作る前にインフラ構築に時間を取られ、「MVP段階で力尽きる」のが典型的な失敗パターンです。

PMF（プロダクトマーケットフィット）を達成して拡大期に入り、チームが増え始めたらモジュラーモノリスに整理します。さらに組織が大きくなり、1つのアプリでは管理しきれなくなった段階で、ボトルネックになっている機能だけをマイクロサービスとして切り出します。

フェーズ	推奨
アイデア検証・MVP	モノリスで最速リリース
PMF後の拡大期	モジュラーモノリスで構造を整える
組織が大きくなってから	必要な箇所だけマイクロサービス化

モジュラーモノリスから切り出すトリガー

モジュラーモノリスで始めて、どのタイミングで一部をマイクロサービス化すべきか。曖昧な「大きくなったら」ではなく、数値の閾値で判断するのが合理的です。

切り出しを検討すべきサイン	目安
開発チームが独立を要求し始める	30人超・複数拠点
特定機能のリクエストが全体の10倍以上	スパイク部分だけスケールしたい
ビルド時間が開発を阻害	10分超／デプロイ頻度が落ちる
特定機能のSLOが全体と大きく乖離	決済は99.99%、その他は99.9%
言語・実行環境を変えたい部分がある	ML推論を Python、本体は TypeScript など

切り出すのは機能単位ではなく、「負荷が突出している箇所」「独立したいチームの領域」からです。全部を一気に分けるのは確実に失敗します。

ケース別の選び方

個人開発・スタートアップのMVP

モノリス一択。作る速度が最優先で、ユーザーが付くかも分からない段階で運用複雑性を抱え込むのは自殺行為です。Ruby on Rails、Laravel、Django のような「1人で全部作れる」フレームワークを選ぶのが最速です。

中規模の業務アプリ（社内システム・SaaS初期）

モジュラーモノリス。将来、機能が増えることが予想されるので、最初から内部境界を明確にしておきます。いざ分割が必要になった時、モノリスから分けるより圧倒的に低コストです。

多チームで並列開発する大規模サービス

マイクロサービス。チームごとに独立してデプロイ・リリースできる効果が大きく、組織規模に見合ったメリットが出ます。ただし運用基盤への投資は必須です。

既存モノリスの一部だけ性能課題がある

その機能だけマイクロサービス化。全体を作り直す必要はありません。「通知機能だけスケールさせたい」なら、通知機能だけを切り出し、残りはモノリスのまま維持します。

将来の拡大は未確定だが、今は小規模

モジュラーモノリス。モノリスで始めて後から分割するより、最初から内部をモジュール化しておいたほうが、分割の必要が生じた時のコストが桁違いに小さいです。

組織規模×構造の実務段階表

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

Conway’s lawを踏まえると、チーム人数で推奨構造がほぼ決まります。下記が現場の経験則です。

組織フェーズ	人数	推奨構造	典型的なサービス数	DB構成
MVP・個人開発	1〜3人	モノリス	1	1DB
初期スタートアップ	3〜10人	モノリス → モジュラーモノリス	1	1DB
中規模SaaS	10〜30人	モジュラーモノリス	1〜3	1〜2DB
スケール期	30〜100人	モジュラーモノリス + 部分的マイクロサービス	5〜15	用途別に分離
大企業・多拠点	100人〜	マイクロサービス（中核）+ モジュラーモノリス（業務領域）	30〜数百	サービスごと

マイクロサービスを選ぶ実質下限は「チーム30人 + 運用専任5人以上」です。これ未満で選ぶと、サービス間通信・分散トレース・データ整合性の運用コストだけが跳ね上がり、開発速度は落ちます。

Segmentが2018年に140サービスから数個にまとめ直した事例は、「規模に見合わないマイクロサービス」の象徴です。

マイクロサービスは30人組織の特権。10人チームで真似すると確実に破綻します。

モノリス分割・マイクロサービス化の鬼門

既存モノリスを分割する判断でよくある罠を整理します。ここを踏むと分割したのに恩恵が出ない、最悪のパターンに陥ります。

禁じ手	なぜダメか
全機能を一気にマイクロサービス化	Segmentが2018年に学んだ通り、分散の複雑性は指数関数的。一つずつ切り出すStrangler Figが現実的な唯一解
サービス間通信を同期RESTだけで組む	1サービスの障害が全体に波及。非同期メッセージング（Kafka / SQS）を組み合わせる
分割時にDBを共有したまま	共有DBで密結合が残り、サービス独立性のメリットが消える。DB分離が分割の本丸
マイクロサービス化と言語分散を同時にやる	5言語混在になると保守人員が分散し、全体を把握する人が消える
分散トレース・ログ集約基盤を後から入れる	分散の初日から必要。ないと障害時に原因特定不能、MTTRが数時間に
Saga / Outboxパターンを知らずに分散TXを実装	本番で二重決済・在庫不整合が発生。分散TXは設計の専門知識が必須
Conway’s lawを無視して分割	「1つのチームが複数サービスを触る」状態は分割の意味がない。1チーム1サービスが原則

モジュラーモノリス → 部分的マイクロサービス化の順序を、10人超えから始めるのが王道です。いきなり分散を選ぶのは、「技術負債を先払いするのと同じ」です。

モノリスに戻るのは新規作成より難しい。最初の選定で分散に走らないのが最大の防御です。

AI時代の視点

AI駆動開発（バイブコーディング）が前提になると、全体構造の選定軸は大きく変わります。マイクロサービスの運用複雑性はAIでも解決しにくく、サービス間通信・分散トレース・データ整合性といった根本的な難しさは残り続けます。

一方、モジュラーモノリスは1コードベース内で境界を明示する構造で、AIが全体を俯瞰して修正しやすく、AI時代の本命として再評価されています。

AI時代に有利	AI時代に不利
モジュラーモノリス（境界+全体俯瞰）	過剰なマイクロサービス分割
型共有・モノレポ（複数プロジェクトを1リポジトリで管理）（tRPC・Turborepo）	gRPC（高速バイナリAPI）+ Proto の手動管理分散構成
明示的なモジュール境界・インターフェース	暗黙的な依存・隠れたAPI契約
TypeScript等の型安全な単一スタック	言語バラバラのポリグロット（複数言語混在）構成

AI時代の「1人で中規模サービスを作れる」現実を踏まえると、わざわざマイクロサービスに分ける理由はさらに少なくなります。チーム規模が本当に大きくない限り、モジュラーモノリスで始めるのが新しい定石です。

AI時代は「境界を明示したモノリス」が本命。マイクロサービスは組織規模が本当に必要な時だけです。

よくある勘違い

• 「マイクロサービスのほうがモダン」 → 単なる選択肢の1つです。モノリスは今も現役で、多くの成功サービスで使われています。新しい＝優れているではない。典型的な思考停止
• 「大は小を兼ねる」 → 大規模前提の設計は小規模には重すぎる過剰設計になります。機能を作る時間が運用の整備に奪われ、プロジェクトが前に進まなくなる
• 「有名サービスが採用してるから」 → NetflixやAmazonの規模・組織・運用体制は通常の企業とは全く違います。彼らの選定理由をそのまま真似ても、同じ効果は出ない。むしろ真似ると高確率で破綻する
• 「1度モノリスにしたら分割できない」 → モジュラーモノリス化 → 段階的なマイクロサービス化という現実的な移行パスが存在します。最初から完璧に設計する必要はない

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• 初期リリースはどの形で作るか（モノリス／モジュラー／マイクロ）
• 内部のモジュール境界をどう引くか（機能別か、業務領域別か）
• データベースは分けるか／共有するか
• 将来の分割シナリオを想定しておくか
• 運用体制（監視・デプロイ・障害対応）が現在の構成に耐えるか
• チームの組織構造が設計と整合しているか（Conway’s law）
• マイクロサービス化する場合、最初に切り出す機能はどれか

最終的な判断の仕方

全体構造選定は「組織の大きさに合わせる」が絶対原則で、技術的な好みや流行は二の次です。Conway’s law（組織の構造がアーキテクチャに反映される）は現実に強く働き、1チームでマイクロサービスを採用すれば運用コストだけが跳ね上がり、100人組織でモノリスを維持すれば変更衝突で身動きが取れなくなります。

つまり「組織規模 × 運用体制」の2軸で選び、迷ったらより単純な側に倒すのが鉄則です。

現在の定石は「モジュラーモノリスから始め、必要に応じて部分的にマイクロサービス化」で、これはAI駆動開発の文脈でさらに強化されます。AIが全体を俯瞰して修正するには1コードベースのほうが圧倒的に扱いやすく、過剰なマイクロサービス分割はAI生産性を下げる。「境界をコードで明示したモノリス」こそ、現代の本命構成です。

選定の優先順位をまとめると次の通りです。

1. 組織規模とチーム数を直視（人数で候補が決まる）
2. 運用体制の厚みを確認（監視・分散トレース・障害追跡が回せるか）
3. 成長フェーズに合わせる（MVPは必ずモノリス）
4. AIとの親和性（1コードベースでAIが俯瞰できる構成）を加味

「より単純な側」を選ぶ勇気を持ちます。複雑さは後からでも足せますが、一度広げた分散は戻すのが困難です。

まとめ

本記事はソフトウェアアーキテクチャの全体構造について、モノリス・マイクロサービス・モジュラーモノリスの3パターンを規模・運用体制・成長フェーズの観点から解説しました。如何だったでしょうか。

迷ったらモジュラーモノリス、MVPは必ずモノリス、マイクロサービスは30人超え + 運用専任5人以上が下限。これがAI時代も含めた2026年の現実解です。

次回は「モジュール設計」（レイヤード/ヘキサゴナル/オニオン/クリーン）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。