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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『アプリケーションアーキテクチャ設計パターン』も参考にしてみてください。

そもそも全体構造とは何か

全体構造とは、ざっくり言えば「アプリケーションをいくつの塊に分けて、どう連携させるかの基本方針」です。

レストラン経営を想像してください。小さな店なら店主一人が調理・接客・会計を全部やる（モノリス）のが効率的です。チェーン展開するなら調理・接客・会計をそれぞれ専門スタッフに分け、マニュアルで連携させる（マイクロサービス）方が回ります。中間として、一つの店舗内で調理場・ホール・レジを明確に区切り、必要に応じて独立させられる準備をしておく（モジュラーモノリス）方法もあります。ソフトウェアも同じで、規模と運用体制に合った分け方を最初に選ぶ必要があります。

なぜ全体構造の選択が重要なのか

もし全体構造を深く考えずに進めたらどうなるか。1つのアプリとして作ったものを途中から複数に分けようとすると、既存コードを大規模に書き直すことになり、現実的には作り直しに近い大工事になります。逆に、複数に分けてしまったものを1つに統合するのも、データ移行と業務停止を伴う重い工事です。

全体構造は他の全ての技術選定の前提になります。ここを曖昧にしたまま先に進むと、後続の決定を全てやり直すことになります。フレームワーク、言語、人員構成、クラウド構成、テスト戦略、デプロイ方式──どれも全体構造に依存して決まります。1つのアプリにまとめる場合と機能ごとに分けて連携させる場合では、必要なエンジニアの人数も得意分野も桁違いに変わり、前者なら5人で作れるものが後者だと20人必要になることも珍しくありません。

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

3つの基本パターン

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

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

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

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

3者の比較

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

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

判断基準

① 規模とチーム人数

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

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

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

② 運用できるか

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

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

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

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

③ 成長フェーズ

プロジェクトの成長段階によっても最適な構造は変わります。アイデア検証・MVPの段階では、とにかく早くリリースして市場の反応を見るのが最優先です。

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

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

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

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

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

ケース別の選び方

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

やってはいけないこと

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

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

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

AI判断軸

AI駆動開発が前提になると、全体構造の選定軸に「AIがコードベース全体を俯瞰できるか」という観点が加わります。モジュラーモノリスは1コードベース内で境界を明示する構造で、AIが全体の文脈を把握しやすいためAI時代の本命として再評価されています。

マイクロサービスはAIのコンテキストを分断する

マイクロサービスが10個に分かれている構成を想像してください。AIに「注文処理のバグを直して」と頼むとき、注文サービス・在庫サービス・決済サービスのコードが別リポジトリにあると、AIはそれぞれを独立して見ることしかできません。サービス間のメッセージ契約や暗黙の依存関係はコードに現れない場合も多く、AIが全体の整合性を保った修正を行うのは困難です。

モジュラーモノリスなら、AIは1つのリポジトリ内で注文モジュール・在庫モジュール・決済モジュールの境界と依存を一度に把握できます。境界はあるが文脈は繋がっているという状態が、AI活用において最も生産性が高い構造です。

モノレポ + 型共有の組み合わせ

マイクロサービスを採用する場合でも、モノレポ（Nx・Turborepo等）で全サービスを1リポジトリにまとめ、型定義を共有する構成にすると、AI活用の効率は大きく改善します。AIがリポジトリ全体を読み込める状態になるため、サービス間の型の不整合やAPIの互換性崩れを検出できるようになります。

選定の優先順位

1. 組織規模とチーム数を直視（人数で候補が決まる）
2. 運用体制の厚みを確認（監視・分散トレース・障害追跡が回せるか）
3. 成長フェーズに合わせる（MVPは必ずモノリス）
4. AIが全体を俯瞰できる構成にする — モジュラーモノリスかモノレポ型マイクロサービス

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

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

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

この記事に関連する記事

まとめ

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

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

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

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

本記事で扱った内容の詳細は Martin Fowler - Patterns of Enterprise Application Architecture も合わせて参考にしてください。

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