本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
レイヤード／DDD／ヘキサゴナル／クリーン／マイクロサービス／モジュラーモノリス──最も多種多様な思想が混在する分野です。本記事では主要な構造パターンの全体像と、「自分たちの規模・スキル・期間で回せるか」という実務的な判断軸を示します。
このカテゴリの他の記事
宗派の多い領域
システムアーキテクチャと対を成す存在として、「システムを構成する要素の中で根幹となるアプリケーションの外部構造」に注目する領域です。ここで決めた設計方針は、アプリケーションアーキテクチャにも大きく影響するので、整合性を取るのが重要です。
どの思想にも支持者と反対派がいて、SNSでは日々宗派戦争が繰り広げられています。ただ、実務で大事なのは「どの思想が真に正しいか」ではなく、「自分たちのチームで運用できるか」という1点です。
美しい設計でも運用できなければ意味がなく、泥臭い設計でもチームが回せるなら成功です。思想選びではなく、自分たちの規模・スキル・期間で回せるかが判断軸になります。
全体構造の3大パターン
ソフトウェアアーキテクチャの全体構造は、大きく3つのパターンに分かれます。
flowchart LR
M["モノリス<br/>(全機能を1アプリ)"]
MM["モジュラーモノリス<br/>(1アプリだが内部分割)"]
MS["マイクロサービス<br/>(機能毎に独立サービス)"]
M -- "規模拡大・<br/>組織肥大" --> MM
MM -- "30人超え/<br/>独立デプロイ要" --> MS
MS -. "過剰分割の反省" .-> MM
classDef mono fill:#dbeafe,stroke:#2563eb;
classDef mod fill:#fef3c7,stroke:#d97706;
classDef micro fill:#fae8ff,stroke:#a21caf;
class M mono;
class MM mod;
class MS micro;| パターン | 特徴 | 向くケース |
|---|---|---|
| モノリス | 1つのアプリにまとめる伝統的な構成 | 小〜中規模 / 少人数チーム |
| マイクロサービス | 機能毎に独立したサービスに分割 | 大規模 / 多人数・多チーム |
| モジュラーモノリス | モノリスだが内部を明確にモジュール分割 | 中規模 / 将来の分割に備える |
家で例えるなら、モノリスはワンルーム（全てが一部屋）、モジュラーモノリスは3LDKの戸建て（部屋は分かれているが同じ家）、マイクロサービスはマンションの各部屋を別世帯に貸す（自由だが鍵・水道・契約を個別に管理）。こう整理すると、規模と負荷の関係が掴みやすくなります。
ワンルームが手狭になる前に「マンション経営」に手を出すと、確実に家賃回収で疲弊します。
モノリス vs マイクロサービス
| 観点 | モノリス | マイクロサービス |
|---|---|---|
| 開発の始めやすさ | ◎ シンプル | △ 複雑 |
| 小規模運用 | ◎ 楽 | × オーバースペック |
| 大規模・多チーム運用 | △ コンフリクト多発 | ◎ 並列開発可能 |
| デプロイ単位 | 全体を一括 | サービス毎に独立 |
| 障害の影響範囲 | 全体に波及 | 局所化しやすい |
「最初からマイクロサービス」は過剰設計の典型です。モジュラーモノリスから始めるのが現在の本命で、組織規模が30人を超えてから段階的に分割するのが健全なパスです。
「分けるのはいつでもできる、戻すのは地獄」モジュラーモノリスから始めるのが鉄則です。
決めるべきこと — あなたのプロジェクトでの答えは？
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
構造・言語・フレームワーク
| 項目 | 選択肢の例 |
|---|---|
| 全体構造 | モノリス・マイクロサービス・モジュラーモノリス等 |
| モジュール設計 | レイヤード・ドメイン駆動・ヘキサゴナル等 |
| プログラミング言語 | Java・C#・Python・Go・Rust・TypeScript等 |
| フレームワーク | Spring・.NET・Next.js・Django等 |
| アプリケーションサーバ | Spring Boot・Tomcat・Gunicorn・Node.js等 |
通信・認証・トランザクション
| 項目 | 選択肢の例 |
|---|---|
| 通信・API設計 | REST・GraphQL・gRPC・WebSocket |
| トランザクション設計 | ACID（DBの整合性4原則）・結果整合性・Saga（分散TXを補償処理でつなぐパターン） |
| エラーハンドリング | 例外方針・リトライ・Circuit Breaker（連続失敗時に呼び出しを遮断する仕組み） |
| ログ設計 | 構造化ログ・相関ID・集約基盤 |
| 暗号化設計 | 転送時・保存時の暗号化方針 |
| セッション管理 | Cookie・JWT（JSON Web Token、署名付きトークン）・Refresh Token |
規模×ソフトウェア構造の段階表
ソフトウェアアーキテクチャはチーム人数で推奨構造がほぼ決まります。Conway’s law（組織構造がシステム構造を決めるという経験則）が強く働く領域です。
ざっくり結論だけ先に言うと、1〜10人なら TypeScript の単一DBモノリスで十分、10〜30人でモジュラーモノリスに昇格、30人を超えてから部分的にマイクロサービスを切り出す。このパスが2026年時点で最も失敗が少ないルートです。
| チーム人数 | 推奨構造 | DB構成 | 言語数 | API方式 |
|---|---|---|---|---|
| 1〜3人 | モノリス | 1DB | 1言語（TS等） | REST |
| 3〜10人 | モノリス → モジュラーモノリス | 1DB | 1〜2言語 | REST + 一部WebSocket |
| 10〜30人 | モジュラーモノリス | 1〜2DB | 2言語以内 | REST + 内部gRPC |
| 30〜100人 | モジュラー + 部分的マイクロサービス | 用途別分離 | 2〜3言語 | REST + gRPC + イベント |
| 100人〜 | マイクロサービス（中核）+ モジュラーモノリス（業務領域） | サービスごと | 3〜5言語 | gRPC + Kafka |
マイクロサービスの実質下限は「チーム30人 + 運用専任5人以上」です。Segmentの140サービス → モノリス回帰（2020年）や、Amazon Prime Video チームのサーバーレス+マイクロサービスからモノリス統合（2023年、インフラコスト90%削減）が典型で、規模に見合わない分散は必ず破綻します。
モジュラーモノリスから始めます。分けるのはいつでもできるが、戻すのは地獄になります。
ソフトウェアアーキテクチャ全体の鬼門
各論記事で触れた禁じ手のうち、ソフトウェアアーキテクチャレベルで押さえるべき核心を整理します。
| 禁じ手 | なぜダメか |
|---|---|
| 30人未満でマイクロサービス化 | Segment 2020年と同じ結末、分散TXの沼 |
| 新技術を情報量・人材なしで採用 | 5年後に書ける人が消え、塩漬けプロジェクト化 |
| スキーマレスDBを強整合業務に採用 | MongoDB事件の定番、PostgreSQLから始める |
| 認証を自前実装 | 穴だらけになる、Auth0 / Clerk / Firebase Auth へ委譲 |
| APIをスキーマなしで公開 | OpenAPI / Protobuf / GraphQL Schema で明示 |
| 2PC（Two-Phase Commit、2相コミット）をクラウドで本番運用 | ネットワーク障害で全停止、Saga + Outbox へ |
| 1プロジェクト5言語以上混在 | 保守人員が分散、2言語以内が健全 |
| モジュール境界を引かずモノリス運用 | 10人超えで変更衝突が頻発、最初から境界を引く |
ソフトウェアアーキテクチャは規模と成熟度の関数。自分たちの痛みで選びます。
AI時代の視点
AI駆動開発（バイブコーディング）が前提になると、ソフトウェアアーキテクチャ全体で「AIに読みやすく・書きやすい設計」の価値が跳ね上がります。全体構造・言語・API・認証などの各選定は、AIがどれだけそのパターンを知っているかが精度を決定します。
| AI時代に有利 | AI時代に不利 |
|---|---|
| コードで明示される設計（型・スキーマ・制約） | 口頭伝承・属人的な運用ルール |
| 主流の組み合わせ（Next.js・Spring Boot等） | ニッチ・内製フレームワーク |
| モジュラーモノリス + 標準プロトコル | 複雑なマイクロサービス+独自プロトコル |
| 単一リポジトリで全体が見える構成 | 多数のリポジトリに分散した仕様 |
AI時代の鉄則は「選択を単純化し、標準に寄せる」です。尖った構成は人間が楽しむ時だけで、業務ではAIの精度が上がる主流構成を選ぶのが賢い判断です。
「AIに優しい設計」と「人間にも優しい設計」は、主流・標準・規約という軸で重なる― この見方が全領域で通用します。
ケース別の選定
新規のWEBサービス（スタートアップ・SaaS初期）
モジュラーモノリス + TypeScript + Next.js + REST + Cookieセッション。作り始めの速度と、拡大した時の分割容易性を両立できる現在の鉄板です。1DB完結でACIDを効かせ、分散TXを抱えない構成が最もバグを呼びにくい。
既存モノリスの分割が必要になった
モジュラーモノリスへ段階移行 → 本当にボトルネックになっている機能だけを切り出します。全面マイクロサービス化は運用負荷が跳ね上がるだけで、業務価値に見合いません。Saga + Outbox（DBの更新と一緒にメッセージも書き込み、後から確実に配送するパターン）は切り出した時に初めて導入します。
複雑な業務ロジックがある基幹システム（金融・保険・医療）
Spring Boot または ASP.NET Core + クリーン or ヘキサゴナル + DDD + 強整合（ACID）。業務ルールが多く長寿命な領域では、ドメインを外部依存から守る投資が長期的に回収できます。OIDC + SSO基盤で権限管理も一元化するのが定番です。
トラフィック急増が予想されるSaaS・コンシューマーサービス
モジュラーモノリス + 読み取り系は結果整合 + CDN + キャッシュ層。書き込みは強整合を維持しつつ、閲覧系は結果整合で水平スケールさせるのが常道。最初からマイクロサービスに分けるより、ボトルネック箇所を見極めて部分的にスケールする方が健全です。
よくある勘違い
- 「マイクロサービス ＝ スケーラブル」 → マイクロサービスは「組織の分割」の話で、性能の話ではありません。実際、サービス間通信のオーバーヘッドでモノリスより遅くなるケースも珍しくなく、性能目的だけなら1DBの縦スケールの方が速く安く済む。典型的な地雷
- 「DDD ＝ 技術的パターン」 → DDDはリポジトリや集約といったパターン名が有名ですが、本質は「業務の言葉でモデルを育てる設計思想」パターンだけ真似して業務用語を整理しないと、ただクラスが増えるだけの過剰設計に終わる
- 「言語・FW選定 ＝ 個人の好み」 → 言語とフレームワークは人材市場・採用コスト・5年後の保守性を決める経営判断です。尖った新興言語を好みで選ぶと、数年後に書ける人が採れず、プロジェクトが塩漬けになる
- 「最新の思想ほど優れている」 → モノリスは今も現役で、小〜中規模では最良の選択肢であり続けています。新しい概念は大規模組織の痛みを解決するために生まれたもので、自分たちに同じ痛みがないなら採用する理由がない
最終的な判断の仕方
ソフトウェアアーキテクチャは思想の宗派が最も多い領域で、「正解は1つではない」が大前提です。そのため選定の核は「どの思想が正しいか」ではなく、「自分たちの規模・スキル・期間で回せるか」に尽きます。
人気の思想に流されて過剰設計に走るより、シンプルな構成から始めて必要に応じて分割するほうが、ほぼ常に正解になります。
定石は「モジュラーモノリス + 主流フレームワーク + 標準プロトコル」の組み合わせです。最初からマイクロサービスは過剰設計の典型で、組織規模と運用体制がついてきてから分割するのが健全なパスです。
AI駆動開発では「AIが熟知している主流構成」ほど生産性が高くなるため、「尖った選定は趣味の領域、業務は主流に寄せる」という割り切りが効きます。
選定の優先順位をまとめると次の通りです。
- 規模・チーム体制を先に見て、過剰設計を避ける（デフォルトはモノリス系）
- 言語・フレームワークは主流を選ぶ（AI時代の生産性で差がつく）
- 標準プロトコル（REST/gRPC/OIDC等）に寄せる
- 型・スキーマ・制約をコードで明示する（AIに読める設計）
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
ソフトウェアアーキテクチャは思想の宗派が多い領域ですが、判断軸は「自分たちのチームで回せるか」に尽きます。モジュラーモノリス + 主流FW + 標準プロトコルの3点セットを基本に、AIに優しい設計が長期保守では人間にも優しい方向に重なるという見方を外さないのが2026年の現実解です。
次回からはこの領域の各論に入り、まずプログラミング言語の選び方から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（17/89）