本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリ第2弾として、アプリケーションの全体構造の選び方について解説する記事です。
「いくつの塊に分けるか／連携か一体か」は、ソフトウェアアーキテクチャで最も後戻りが効かない決断です。本記事ではモノリス／マイクロサービス／モジュラーモノリスの3パターンを比較し、規模・運用体制・成長フェーズに応じた選び方を示します。
本記事のテーマについてさらに詳しく知りたい方は『アプリケーションアーキテクチャ設計パターン』も参考にしてみてください。
この記事の結論
- 迷ったらモジュラーモノリス
- MVPは必ずモノリスで始める
- マイクロサービスは30人超+運用専任5人以上が下限
- 切り出す時は数値の閾値で判断し、一気に分けない
この記事を読む前に
本記事はプログラムやAPIといった開発寄りの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも全体構造とは何か
全体構造とは、ざっくり言えば「アプリケーションをいくつの塊に分けて、どう連携させるかの基本方針」です。
レストラン経営を想像してください。小さな店なら店主一人が調理・接客・会計を全部やる（モノリス）のが効率的です。チェーン展開するなら調理・接客・会計をそれぞれ専門スタッフに分け、マニュアルで連携させる（マイクロサービス）方が回ります。中間として、一つの店舗内で調理場・ホール・レジを明確に区切り、必要に応じて独立させられる準備をしておく（モジュラーモノリス）方法もあります。ソフトウェアも同じで、規模と運用体制に合った分け方を最初に選ぶ必要があります。
なぜ全体構造の選択が重要なのか
もし全体構造を深く考えずに進めたらどうなるか。1つのアプリとして作ったものを途中から複数に分けようとすると、既存コードの大規模な書き直しになり、現実的には作り直しに近い大工事になります。逆に、複数に分けたものを1つに統合するのも、データ移行と業務停止を伴う重い工事です。
そして全体構造は他の全ての技術選定の前提になります。フレームワーク・言語・人員構成・クラウド構成・テスト戦略・デプロイ方式──どれも全体構造に依存して決まります。1つのアプリなら5人で作れるものが、分割構成だと20人必要になることも珍しくありません。
3つの基本パターン
| パターン | ざっくりした説明 |
|---|---|
| モノリス | 全機能を1つのアプリにまとめる伝統的な形。最もシンプル |
| マイクロサービス | 機能ごとに独立したアプリに分け、ネットワーク越しに連携する形 |
| モジュラーモノリス | 見た目は1つのアプリだが、内部をきっちり区切る中間形 |
2010年代にマイクロサービスが爆発的に流行しましたが、今はモジュラーモノリスへの揺り戻しの真っ只中です。新しい・古いではなく、プロジェクトの規模と組織に合わせて選ぶだけ、という冷静な認識が定着しつつあります。
モノリス ― 小〜中規模では今も最良
「Monolith」（一枚岩）の名前通り、全機能を1つのコードベース・同じサーバー・同じデータベースで動かす構造です。作り始めが圧倒的に速く、データの一貫性を保ちやすく、不具合調査も運用もシンプル。一方で巨大化するとビルドが重くなり、多人数開発では変更の衝突が頻発し、一部の障害がアプリ全体を止めます。「モノリス＝古い」は誤解で、小〜中規模では今も最良の選択肢であり続けています。
マイクロサービス ― 大組織の並列開発のための構造
機能ごとに独立した小さなアプリを作り、APIで通信しながら1つのサービスを構成します。機能ごとにチームを分けて並行開発でき、障害を局所化し、部分的にスケールできる一方、運用の複雑さが桁違いに増えるのが最大の弱点です。サービスが増えるほど、監視・ログ集約・分散トレースの基盤整備自体が巨大プロジェクトになります。
象徴的なのが分析基盤Segmentの事例です。140以上のマイクロサービスを運用していましたが、障害連鎖・デプロイの協調・テスト環境の爆発に耐えきれず、2018年に「Goodbye Microservices」と題した記事を公開してモノリスへ回帰しました。あれだけの技術力を持つ企業でも管理しきれなかった、という事実は重い。分散は足し算ではなく掛け算で複雑化します。
モジュラーモノリス ― 迷ったらここ
見た目はモノリス（1つのアプリ・1つのデプロイ単位）ですが、内部を「ユーザー」「商品」「決済」のようなモジュールに明確に区切り、モジュール同士は決められた窓口（インターフェース）経由でしか連携させない中間構造です。運用はモノリスと同じくシンプル、かつ将来マイクロサービス化が必要になった時に比較的低コストで切り出せる。「モノリスの運用しやすさ」と「マイクロサービスの構造的きれいさ」のいいとこ取りを狙った、現代の本命構成です。
3者の比較
マイクロサービスは「できること」が多い反面、「払うコスト」も圧倒的に大きい、と認識しておくのが正しい視点です。
どう選べばいいのか ― 規模別の3シナリオ
決め手はConway’s law（組織構造がシステム構造を決める経験則）です。チーム人数と運用体制で候補がほぼ決まります。
個人開発・スタートアップのMVPなら ― モノリス一択
作る速度が最優先ですので、ユーザーが付くかも分からない段階で運用複雑性を抱え込むのは自殺行為だと思います。いきなりマイクロサービスで始めてしまうと、機能を作る前にインフラ構築に時間を取られて「MVP段階で力尽きる」というのが典型的な失敗パターンです。RailsやLaravel、Next.jsのような「1人で全部作れる」フレームワークで最速リリースを目指しましょう。
中小SaaS・社内システムなら ― モジュラーモノリスで境界を引く
PMF後の拡大期・10〜30人のチームなら、モジュラーモノリスで内部境界を明確にします。将来の分割が必要になった時、モノリスから分けるより圧倒的に低コストです。1つのDBで整合性を保ちながら、モジュール間はインターフェース経由のみに統制するのがポイントです。
大企業・多チーム並列開発なら ― 運用投資込みのマイクロサービス
30人超・複数拠点でチームごとに独立デプロイしたい規模になって初めて、マイクロサービスのメリットがコストを上回ります。その際も、サービス横断の監視・ログ基盤、分散システムの運用経験者、複数サービスを跨いだ障害追跡体制の3つが揃っていることが前提です。どれか1つでも欠けていたら選ばない。例外なく、です。
規模×構造の実務段階表
※ 2026年4月時点の業界相場値です。
| 組織フェーズ | 人数 | 推奨構造 |
|---|---|---|
| MVP・個人開発 | 1〜3人 | モノリス |
| 初期スタートアップ | 3〜10人 | モノリス → モジュラーモノリス |
| 中規模SaaS | 10〜30人 | モジュラーモノリス |
| スケール期 | 30〜100人 | モジュラーモノリス+部分的マイクロサービス |
| 大企業・多拠点 | 100人〜 | マイクロサービス（中核）+モジュラーモノリス（業務領域） |
マイクロサービスの実質下限は「チーム30人+運用専任5人以上」です。これ未満で選ぶと、サービス間通信・分散トレース・データ整合性の運用コストだけが膨らみ、開発速度は落ちます。
モジュラーモノリスから切り出すトリガー
どのタイミングで一部をマイクロサービス化すべきか。曖昧な「大きくなったら」ではなく、数値の閾値で判断するのが合理的です。
| 切り出しを検討すべきサイン | 目安 |
|---|---|
| 開発チームが独立を要求し始める | 30人超・複数拠点 |
| 特定機能のリクエストが全体の10倍以上 | スパイク部分だけスケールしたい |
| ビルド時間が開発を阻害 | 10分超／デプロイ頻度が落ちる |
| 特定機能のSLOが全体と大きく乖離 | 決済は99.99%、その他は99.9% |
| 言語・実行環境を変えたい部分がある | ML推論はPython、本体はTypeScript等 |
切り出すのは機能単位ではなく、「負荷が突出している箇所」「独立したいチームの領域」からです。全部を一気に分けるのは確実に失敗します。
AI判断軸 ― AIがコードベース全体を俯瞰できるか
AI駆動開発が前提になると、全体構造の選定軸に「AIがコードベース全体を俯瞰できるか」という観点が加わります。
マイクロサービスはAIのコンテキストを分断する
マイクロサービスが10個に分かれている構成でAIに「注文処理のバグを直して」と頼むとき、注文・在庫・決済サービスのコードが別リポジトリにあると、AIはそれぞれを独立して見ることしかできません。サービス間のメッセージ契約や暗黙の依存関係はコードに現れない場合も多く、AIが全体の整合性を保った修正を行うのは困難です。モジュラーモノリスなら、AIは1つのリポジトリ内でモジュールの境界と依存を一度に把握できます。境界はあるが文脈は繋がっているという状態が、AI活用において最も生産性が高い構造です。
モノレポ+型共有の組み合わせ
マイクロサービスを採用する場合でも、モノレポ（Nx・Turborepo等）で全サービスを1リポジトリにまとめて型定義を共有すると、AI活用の効率は大きく改善します。AIがリポジトリ全体を読み込める状態になるため、サービス間の型の不整合やAPIの互換性崩れを検出できるようになります。
やってはいけないこと
既存モノリスを分割する判断でよくある罠を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 全機能を一気にマイクロサービス化 | 分散の複雑性は指数関数的に増える → 一つずつ切り出すStrangler Figが唯一の現実解 |
| 分割時にDBを共有したまま | 密結合が残り独立性のメリットが消える → DB分離こそが分割の本丸 |
| サービス間通信を同期RESTだけで組む | 1サービスの障害が全体に波及する → 非同期メッセージング（Kafka / SQS）を組み合わせる |
| 分散トレース・ログ集約を後から入れる | 障害時に原因特定不能でMTTRが数時間になる → 分散の初日から用意する |
| Saga / Outboxを知らずに分散トランザクションを実装 | 本番で二重決済・在庫不整合が起きる → 設計パターンを先に学ぶ |
| 「マイクロサービス＝モダン」の思考停止で選ぶ | 単なる選択肢の1つ → 規模・体制・フェーズで冷静に選ぶ |
モジュラーモノリス → 部分的マイクロサービス化の順序を10人超えから始めるのが王道です。モノリスに戻るのは新規作成より難しいので、最初の選定で分散に走らないのが最大の防御です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 初期リリースはどの形で作るか（モノリス／モジュラー／マイクロ）
- 内部のモジュール境界をどう引くか（機能別か、業務領域別か）
- データベースは分けるか／共有するか
- 将来の分割シナリオを想定しておくか
- 運用体制（監視・デプロイ・障害対応）が現在の構成に耐えるか
- チームの組織構造が設計と整合しているか（Conway’s law）
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はソフトウェアアーキテクチャの全体構造について、モノリス・マイクロサービス・モジュラーモノリスの3パターンを規模・運用体制・成長フェーズの観点から解説しました。如何だったでしょうか。
迷ったらモジュラーモノリス、MVPは必ずモノリス、マイクロサービスは30人超え+運用専任5人以上が下限。これがAI時代も含めた2026年の現実解です。
次回は「モジュール設計」（レイヤード/ヘキサゴナル/オニオン/クリーン）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Martin Fowler - Patterns of Enterprise Application Architecture も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（25/95）