本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
レイヤード／DDD／ヘキサゴナル／クリーン／マイクロサービス／モジュラーモノリス──最も多種多様な思想が混在する分野です。本記事では主要な構造パターンの全体像と、「自分たちの規模・スキル・期間で回せるか」という実務的な判断軸を示します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。
そもそもソフトウェアアーキテクチャとは何か
建物の構造設計を想像してください。木造か鉄骨か鉄筋コンクリートか──骨格の選び方で建てられる規模・増改築のしやすさ・耐用年数が全て変わります。内装（アプリケーションアーキテクチャ）はこの骨格の上に乗るので、後から骨格を変えるのは非常に大がかりです。
ソフトウェアアーキテクチャは、アプリケーションの全体構造（モノリス・モジュラーモノリス・マイクロサービスなど）を決める領域です。言語選定・API設計・DB接続方式など、システムの骨格となる判断を含みます。
もしソフトウェアアーキテクチャを決めずに開発を始めると、規模が大きくなった時にコードが絡み合い、変更のたびに予想外の場所が壊れる状態に陥ります。
なぜソフトウェアアーキテクチャが重要なのか
全体構造の選択は後から変えられない
モノリスからマイクロサービスへの移行は「リフォーム」ではなく「建て替え」に近いコストがかかります。最初にどの構造を選ぶかで、チームの開発速度・拡張性・運用負荷が決まります。
チーム規模とアーキテクチャのミスマッチが致命的
3人のチームでマイクロサービスを採用すれば運用に潰され、100人のチームでモノリスを維持すればデプロイが渋滞します。組織の規模に合った構造を選ぶのがアーキテクトの最重要判断です。
設計思想の選択がコードの寿命を決める
レイヤード・DDD・クリーンアーキテクチャなど思想は多様ですが、「チームが運用できるか」という1点で選ぶのが実務の正解です。
宗派の多い領域
システムアーキテクチャと対を成す存在として、「システムを構成する要素の中で根幹となるアプリケーションの外部構造」に注目する領域です。ここで決めた設計方針は、アプリケーションアーキテクチャにも大きく影響するので、整合性を取るのが重要です。
どの思想にも支持者と反対派がいて、SNSでは日々宗派戦争が繰り広げられています。ただ、実務で大事なのは「どの思想が真に正しいか」ではなく、「自分たちのチームで運用できるか」という1点です。
美しい設計でも運用できなければ意味がなく、泥臭い設計でもチームが回せるなら成功です。思想選びではなく、自分たちの規模・スキル・期間で回せるかが判断軸になります。
全体構造の3大パターン
ソフトウェアアーキテクチャの全体構造は、大きく3つのパターンに分かれます。
| パターン | 特徴 | 向くケース |
|---|---|---|
| モノリス | 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・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人超えで変更衝突が頻発、最初から境界を引く |
| マイクロサービスを性能目的で選ぶ | 性能はサービス間通信のオーバーヘッドでむしろ下がる。スケールは縦が先 |
| DDDのパターン名だけ真似て業務用語を整理しない | ただクラスが増えるだけの過剰設計に終わる |
ソフトウェアアーキテクチャは規模と成熟度の関数。自分たちの痛みで選びます。
AI判断軸
AI駆動開発（バイブコーディング）が前提になると、ソフトウェアアーキテクチャ全体で「AIに読みやすく・書きやすい設計」の重要度が増します。
| AI時代に有利 | AI時代に不利 |
|---|---|
| コードで明示される設計（型・スキーマ・制約） | 口頭伝承・属人的な運用ルール |
| 主流の組み合わせ（Next.js・Spring Boot等） | ニッチ・内製フレームワーク |
| モジュラーモノリス + 標準プロトコル | 複雑なマイクロサービス+独自プロトコル |
| 単一リポジトリで全体が見える構成 | 多数のリポジトリに分散した仕様 |
選定の優先順位をまとめると次の通りです。
- 規模・チーム体制を先に見て、過剰設計を避ける（デフォルトはモノリス系）
- 言語・フレームワークは主流を選ぶ（AI時代の生産性で差がつく）
- 標準プロトコル（REST/gRPC/OIDC等）に寄せる
- 型・スキーマ・制約をコードで明示する（AIに読める設計）
アーキテクチャ選定がAI活用の上限を決める
AIにコードを書かせる時、精度を左右する最大の要因は「AIに渡せるコンテキストの質」です。型定義やスキーマがコードとして存在すれば、AIはそれを読んで正確なコードを生成します。逆に、設計がWiki上の図やSlackでの口頭合意にしか存在しない場合、AIには見えないため毎回手動で説明を書き添える必要があります。
ここでのポイントは、AI時代に有利な設計特性（型の明示・標準プロトコル・モジュール分割）は、AI以前から「良い設計」とされてきたものと完全に一致するということです。AI時代だからといって特殊なアーキテクチャが求められるのではなく、従来の良い設計をきちんと実践しているチームがAIの恩恵を最も受けます。
モノリスがAI活用で有利になる構造的な理由
マイクロサービスでは仕様が複数リポジトリに分散します。サービスAのコードを修正する際に、サービスBのAPI仕様・サービスCのイベントスキーマ・共有ライブラリの型定義を同時にAIのコンテキストに入れる必要があり、情報収集だけで手間がかかります。
モジュラーモノリスであれば、同一リポジトリ内にすべての型定義・スキーマ・テストが存在するため、AIは関連コードを一度に参照できます。境界はモジュール（パッケージ）で論理的に区切りつつ、物理的には1つのリポジトリで管理する――この構成がAI時代のデフォルトとして最も合理的です。
主流技術スタックの選定がAI精度に直結する
Next.js + TypeScript + Prismaのような主流スタックは、GitHubの公開リポジトリに数十万件規模の実装例があります。AIの学習データにこれらのパターンが大量に含まれているため、生成されるコードの品質が安定します。
内製フレームワークやニッチなライブラリの場合、AIは類似の公開コードを参照できないため、基本的な使い方すら間違えることがあります。技術選定の時点で「AIが学習済みかどうか」を判断基準の一つに加えるのが2026年の現実です。
このカテゴリの知識構造
このカテゴリは全8記事で構成されています。記事は3つのグループに分かれ、大枠の骨格から個別の設計判断へと段階的に降りていく構造です。
**グループ1（骨格）**では、モノリス/マイクロサービスの全体構造を決め、それに合った言語・FW・モジュール分割を選びます。全体構造を決めずに言語やFWを先に選ぶと、構造と道具のミスマッチが起きます。
**グループ2（通信）**では、骨格の上でモジュール間・サービス間をどう繋ぐかを設計します。REST/gRPC/GraphQLの選択はAPI記事で、分散トランザクションの扱いはトランザクション記事で掘り下げます。
**グループ3（横断）**の認証・セッション管理は、全ての通信に絡む横断テーマです。セキュリティアーキテクチャカテゴリの認証設計記事と合わせて読むと、実装レベルとポリシーレベルの両面が揃います。
ケース別の選定
新規の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 + キャッシュ層。書き込みは強整合を維持しつつ、閲覧系は結果整合で水平スケールさせるのが常道。最初からマイクロサービスに分けるより、ボトルネック箇所を見極めて部分的にスケールする方が健全です。
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
ソフトウェアアーキテクチャは思想の宗派が多い領域ですが、判断軸は「自分たちのチームで回せるか」に尽きます。モジュラーモノリス + 主流FW + 標準プロトコルの3点セットを基本に、AIに優しい設計が長期保守では人間にも優しい方向に重なるという見方を外さないのが2026年の現実解です。
次回からはこの領域の各論に入り、まずプログラミング言語の選び方から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Martin Fowler - Software Architecture Guide も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（17/89）