アーキテクチャパターン入門：モノリス・モジュラモノリス・マイクロサービス・サーバーレスを判断軸として
「マイクロサービスを採用しています」という言葉は、技術の成熟を示すシグナルにも、組織能力を超えた過剰設計のシグナルにもなります。アーキテクチャの選択は「どのパターンが技術的に優れているか」という問いではありません。チームの規模・開発速度・コスト許容度・将来の組織設計という4変数を同時に決定する経営判断です。
M&A担当者やVCキャピタリストがアーキテクチャを評価する目的は、技術の優劣を判定することではありません。「そのアーキテクチャの選択がフェーズに見合っているか」「組織の実力と設計の複雑さが釣り合っているか」を見ることにあります。
アーキテクチャ選択の本質：組織と技術の鏡
ソフトウェアアーキテクチャの研究者メルヴィン・コンウェイは1967年に次の命題を提唱しました。
システムを設計する組織は、その組織のコミュニケーション構造を写した設計を産み出す。
これを「コンウェイの法則」といいます。50年以上前の観察ですが、今も実務で頻繁に確認されます。10人の会社が作るソフトウェアと、1000人の会社が作るソフトウェアは構造が異なって当然であり、むしろそうあるべきです。
この法則が示す実践的な意味は2つあります。第1に、アーキテクチャを変えるには組織を変える必要があるという点です。「マイクロサービスに移行したい」という判断は、チームの分割・コミュニケーションの再設計・CI/CDの整備を伴う組織変革であり、技術の問題ではありません。第2に、組織の成熟度より複雑なアーキテクチャを採用すると失敗するという点です。3人のエンジニアがマイクロサービスを運用しようとすれば、1人が複数のサービスを担当することになり、分割した意味が失われます。
投資先のアーキテクチャを評価するとき、「何を選んでいるか」と同時に「その選択を支える組織があるか」を問うのはこのためです。
モノリス：誤解されている強み
「モノリス（Monolith）」は「時代遅れの設計」として語られることが多いですが、これは誤解です。正確には、モノリスは1つのプロセスとして動作するシステムを指します。すべての機能が一つのコードベースに存在し、一括してデプロイされます。
モノリスの強みは、シンプルさから来る開発速度にあります。
モノリスで最も重要な特徴は「関数呼び出しレベルの通信コスト」です。機能Aが機能Bのロジックを使いたいとき、同一プロセス内で直接呼び出せます。マイクロサービスでは、ネットワーク経由のAPI通信になります。これは単純な速度差だけでなく、障害の複雑さの差でもあります。「ネットワーク障害でA→B間の通信が失敗した場合のリトライをどう設計するか」という問題は、モノリスでは存在しません。
スタートアップがモノリスから始めるべき理由は明確です。開発チームが小規模なうちは、全員が全コードを把握できる範囲に収める方が開発速度が高くなります。コードベース全体の整合性を一人が確認できる規模では、サービス間の整合性を保つための仕組み（APIバージョン管理・スキーマ定義・契約テスト）を構築するコストの方が大きくなります。
「モノリスは技術負債だ」という誤解が根強くありますが、正確ではありません。技術負債の本質は「意識されていない設計上の妥協の蓄積」であり、アーキテクチャパターンとは独立した概念です。整理されたモノリスは、スパゲッティ化したマイクロサービスより遥かに健全です。
モジュラモノリス：モノリスとマイクロサービスの中間地点
モジュラモノリス（Modular Monolith）は、1つのプロセスとして動作するという点ではモノリスと同じですが、内部に明確なモジュール境界（ドメイン境界）を設けた設計です。各モジュールは独自の内部データ・ロジック・インターフェースを持ち、他のモジュールとは公開されたAPIのみで通信します。
従来のモノリスが抱える問題の多くは、「どこからでもどこでもアクセスできる」という無秩序さから来ています。モジュラモノリスはこれを構造的に防ぎます。モジュール間の通信は関数呼び出しのままであるため、ネットワーク通信コストは発生しません。
モジュラモノリスが価値を発揮する条件
モジュラモノリスは次のような状況で特に有効です。
- チームが10〜50名規模になり、コードベースの構造化が必要になってきた — 全員が全体を把握できる限界を超え始めた段階で、ドメイン境界を設けることで認知負荷を下げられます
- 将来的なマイクロサービス移行を見据えている — 境界が整理されたモジュラモノリスは、必要なモジュールだけを後からサービスとして切り出しやすい設計です
- マイクロサービスの運用複雑さに対応できる体制がまだない — DevOps・監視・分散トレーシングの整備が追いついていない段階では、モジュラモノリスで境界設計の訓練ができます
従来のモノリス・マイクロサービスとの比較
| モノリス | モジュラモノリス | マイクロサービス | |
|---|---|---|---|
| デプロイ単位 | 全体一括 | 全体一括 | サービスごと独立 |
| モジュール間通信 | 関数呼び出し（無制限） | 関数呼び出し（公開IFのみ） | ネットワーク（HTTP / メッセージ） |
| データ管理 | 共有DB | モジュールごとに独占 | サービスごとに独立DB |
| 開発速度 | ◎ 高い | ○ 高い | △ チーム分割後に向上 |
| 境界の強制 | ✗ なし | ○ コードレベルで強制 | ◎ プロセス境界で物理的に強制 |
| 運用複雑さ | ○ 低い | ○ 低い | △〜× 高い |
| 推奨フェーズ | 〜10名 | 10〜50名 | 50名〜 |
Shopifyは長年モジュラモノリスを採用し、RailsアプリケーションをComponentsと呼ばれるモジュール単位で管理しながら、必要な機能のみをサービスとして切り出すアプローチを取っています。「最初からマイクロサービスにしなかったことが、初期の開発速度を支えた」と公式ブログで述べており、フェーズに合った選択の実例として参照されます。
モジュラモノリスへの移行アプローチ
既存のモノリスをモジュラモノリスに移行する手順は比較的シンプルです。まずドメインを特定し（ユーザー管理・注文・決済など）、次に各ドメインのコードを専用ディレクトリ（/modules/user/など）に整理します。その後、モジュール間で直接データベーステーブルを参照しているコードを洗い出し、公開インターフェース経由に書き換えます。
この移行は段階的に進められるため、機能開発を止めることなく実施できます。完全な書き直しが不要な点がマイクロサービス移行との大きな違いです。
マイクロサービス：適用条件と落とし穴
マイクロサービスは「機能ごとに独立したサービスとして分割し、それぞれが独自のプロセス・データベース・デプロイサイクルを持つ」設計です。Amazonが2000年代に自社の急成長に対応するために採用した手法として知られており、「スケーラブルな大規模システムの正解」というイメージが広がっています。
しかし、Amazon採用時の規模は数千人のエンジニアが存在していました。この規模感を無視したマイクロサービス採用が、スタートアップに多く見られる過剰設計の典型です。
マイクロサービスが有効に機能する条件
マイクロサービスが本来の価値を発揮するのは、次の条件が揃った場合です。
- チームが複数に分かれており、それぞれが独立して開発・デプロイできる必要がある — 10人以下のチームでは、独立デプロイのメリットより、サービス間整合性の維持コストが上回ります
- 機能ごとにスケール要件が大きく異なる — 「決済処理は月末に集中するが、ユーザー認証は均一」という場合、別々にスケールできる価値があります
- CI/CD・モニタリング・サービスメッシュを維持するDevOps能力がある — マイクロサービスは「インフラ管理コスト」をアプリケーション側に転移させる設計でもあります
見落とされがちな分散システムの複雑さ
マイクロサービスを採用すると、モノリスでは存在しなかった問題クラスが発生します。
分散トランザクション問題: 「注文の作成」と「在庫の引き落とし」が別サービスにある場合、注文は作成されたが在庫の引き落としがネットワーク障害で失敗した状態をどう処理するかという問題が生じます。モノリスならデータベースのトランザクションで解決できますが、マイクロサービスでは「サービス間の結果整合性」という複雑な問題になります。
可観測性の複雑化: 1つのAPIリクエストが5つのサービスを経由して完結する場合、どのサービスでレイテンシが発生しているかを特定するには分散トレーシングの仕組みが必要です。これはモノリスでは不要なインフラコストです。
投資先がマイクロサービスを採用している場合に確認すべきは「なぜ分割したか」という意思決定の根拠です。「マイクロサービスがモダンだから」「CTOが前職で使っていたから」という理由であれば、フェーズに見合わない設計コストを抱えている可能性が高いといえます。
サーバーレス：コスト構造と制約
サーバーレス（Serverless）は「サーバーの存在を意識せず、関数（Function）を単位としてコードを実行する」モデルです。AWS Lambda・Google Cloud Functions・Cloudflare Workersが代表例です。
「サーバーレス」という名称は誤解を招きますが、サーバーが存在しないのではありません。クラウドプロバイダーがサーバーを管理し、開発者はインフラの存在を意識しなくてよいという意味です。
サーバーレスの経済的特徴
サーバーレスの最大の特徴は従量課金モデルです。「実行した時間 × 使用したメモリ量 × 実行回数」に基づいて課金されます。常時稼働するサーバーを持たないため、トラフィックがゼロの時間帯のコストもゼロになります。
これは特定のユースケースで非常に有利です。
| ユースケース | サーバーレスの適性 | 理由 |
|---|---|---|
| バッチ処理・夜間ジョブ | ◎ 非常に高い | 実行時間のみ課金、アイドル時間なし |
| Webhook受信・イベント処理 | ◎ 高い | 不定期なイベントへの応答に最適 |
| 常時稼働のAPIサーバー | △ 条件次第 | コールドスタート問題・実行時間制限あり |
| 長時間バッチ処理 | × 不向き | 実行時間の上限（通常15分〜1時間）があります |
| WebSocket・リアルタイム通信 | × 不向き | ステートレスが前提のため状態保持が困難です |
コールドスタートと実行時間制限
サーバーレスの制約として投資・技術評価で確認すべき点は2つあります。
コールドスタート問題: 一定時間リクエストがなかった後の初回リクエストは、関数の起動（コールドスタート）に数十ミリ秒〜数秒かかります。一般的なAPI応答が100ms以下を求められる場合、これは無視できません。有料のプロビジョンドコンカレンシー（常時起動）で回避できますが、コストが増加します。
ステートレス前提: サーバーレス関数はリクエストをまたいで状態を保持できません。セッション・接続状態・処理中のデータは外部ストレージ（データベース・キャッシュ）に持つ必要があります。これは設計を制約しますが、スケールアウトが容易というメリットの裏返しでもあります。
スタートアップフェーズ別の推奨判断
アーキテクチャの選択は、事業フェーズによって合理的な答えが変わります。
重要なのは「フェーズに先行したアーキテクチャ採用は技術負債を生む」という点です。フェーズ1の10人チームがマイクロサービスを採用すると、実際に開発に使える時間より、サービス間の整合性管理・デプロイパイプラインの整備・ローカル開発環境の複雑化に時間を取られます。これはAI駆動開発が生む技術負債リスクでも触れた「過剰設計が速度を奪う」パターンの典型です。
投資・M&A時のアーキテクチャ評価観点
アーキテクチャパターンを理解した上で、投資・買収判断で問うべき観点を整理します。
「なぜそのアーキテクチャを選んだか」の説明責任
選択の理由が説明できるかどうかが、技術組織の成熟度指標になります。「マイクロサービスです」という回答に対して「いつ・なぜ・何のために分割したか」を深掘りするとよいでしょう。
フェーズに合った合理的な選択であれば、明確な理由が返ってきます。「とりあえず最初からマイクロサービスにした」「前職でそうだったから」という回答は、技術意思決定の文化が成熟していないサインです。
スケール戦略との整合性
「今後3年でトラフィックが100倍になると想定しているが、現在のアーキテクチャはどうスケールするか」という問いへの回答を確認します。
モノリスであれば「水平スケール（サーバー台数増加）で対応できるか、データベースのボトルネックをどう処理するか」が論点になります。マイクロサービスであれば「ボトルネックになるサービスを特定してそこだけスケールできる」という回答が期待できます。回答の質から、エンジニアリングチームが自社システムのボトルネックを正確に把握しているかを確認できます。
移行コストの認識
M&Aにおける技術デューデリジェンスでは、アーキテクチャ移行の必要性とそのコストを評価する場面があります。
モノリスからマイクロサービスへの移行は、段階的に実施できます。まず外側から独立性の高い機能（通知・バッチ処理・画像変換等）を分離し、コアのビジネスロジックは最後に分割するアプローチが一般的です。全面書き直しは最もリスクが高く、「ストラングラーフィグパターン（既存を絞め殺すように新しいシステムで置き換える）」のような段階的移行が推奨されます。
移行コストの見積もり精度が低い場合——「あの部分は絡み合っていて手をつけにくい」という曖昧な回答しか返ってこない場合——は、技術負債が可視化されていない状態を示している可能性があります。
チェックリスト：アーキテクチャ評価で問うべき5つの問い
- 「今のアーキテクチャを選んだ理由と、そのトレードオフを教えてください」 — 意思決定の質を確認します
- 「デプロイ頻度と1回あたりのリードタイムはどのくらいですか」 — アーキテクチャの実用性を定量確認します（モノリスの健全な状態：週1〜毎日、マイクロサービスの期待値：チームごとに独立して毎日〜複数回）
- 「本番障害が発生した時、原因特定に平均何分かかりますか」 — モニタリング成熟度とアーキテクチャ複雑さの関係を確認します
- 「チームを2倍にした場合、現在のアーキテクチャで開発速度も2倍になりますか」 — スケール戦略とアーキテクチャの整合性を問います
- 「最もリファクタリングしたいシステムの箇所とその理由を教えてください」 — 現場エンジニアの認識から技術的課題を特定します
まとめ：アーキテクチャを「判断の質」として読む
4つのパターンに優劣はありません。あるのは「フェーズ・組織・事業目標との整合性」です。
- モノリス: スタートアップ初期の合理的な選択です。デファクトの出発点として問題ありません
- モジュラモノリス: チームが10〜50名規模になり構造化が必要になった段階の選択です。モノリスの開発速度を保ちながら、将来のマイクロサービス移行を準備できます
- マイクロサービス: 大規模・複数チームのための選択です。チームの分割と同時に実施すべきものです
- サーバーレス: 特定の用途（バッチ・イベント処理）では強力です。常時稼働APIには制約があります
投資・買収において技術評価が必要なのは、アーキテクチャの選択が組織の意思決定能力を映す鏡であるからです。「フェーズに合った合理的な選択ができているか」という観点は、技術デューデリジェンスの全体像の中でもシステム設計評価の核となる視点です。
関連記事
アーキテクチャの選択と深く関係するのがクラウドの選択です。設計パターンとインフラの関係についてはクラウドサービス入門：AWS/GCP/Azure を「事業上の意思決定」として読み解くで詳しく解説しています。
アーキテクチャの複雑さが技術負債に転化するメカニズムは「技術負債」の正体とスタートアップで問題になるパターンで整理しています。技術DDの全体的な評価フレームワークは技術デューデリジェンスの全体像と7つの評価軸をご覧ください。
Tied株式会社では、VC・事業会社のM&A担当者向けに技術デューデリジェンス支援を提供しています。アーキテクチャ評価を含む技術DDの詳細は投資家向けサービスページをご覧いただくか、お問い合わせからご相談ください。