本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰する記事です。
レイヤード／DDD／ヘキサゴナル／クリーン／マイクロサービス／モジュラーモノリス──最も多種多様な思想が混在する分野です。本記事では主要な構造パターンの全体像と、「自分たちの規模・スキル・期間で回せるか」という実務的な判断軸を示します。
このカテゴリの全記事一覧・各記事で学べるポイントは以下のページにまとめています。
本記事のテーマについてさらに詳しく知りたい方は『ソフトウェアアーキテクチャの基礎』も参考にしてみてください。
この記事の結論
- 判断軸は「自分たちのチームで回せるか」に尽きる
- モジュラーモノリス+主流FW+標準プロトコルの3点セットが基本形
- マイクロサービスの実質下限は「チーム30人+運用専任5人」
- AIに優しい設計は長期的に人間にも優しい
この記事を読む前に
本記事はプログラムやAPIといった開発寄りの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもソフトウェアアーキテクチャとは何か
建物の構造設計を想像してください。木造か鉄骨か鉄筋コンクリートか──骨格の選び方で建てられる規模・増改築のしやすさ・耐用年数が全て変わります。内装（アプリケーションアーキテクチャ）はこの骨格の上に乗るので、後から骨格を変えるのは非常に大がかりです。
ソフトウェアアーキテクチャは、アプリケーションの全体構造（モノリス・モジュラーモノリス・マイクロサービスなど）を決める領域です。言語選定・API設計・DB接続方式など、システムの骨格となる判断を含みます。
なぜソフトウェアアーキテクチャが重要なのか
第一に、全体構造の選択は後から変えられないからです。モノリスからマイクロサービスへの移行は「リフォーム」ではなく「建て替え」に近いコストがかかります。
第二に、チーム規模とアーキテクチャのミスマッチが致命的だからです。3人のチームでマイクロサービスを採用すれば運用に潰され、100人のチームでモノリスを維持すればデプロイが渋滞します。組織の規模に合った構造を選ぶのがアーキテクトの最重要判断です。
そしてこの領域は思想の宗派が多く、SNSでは日々宗派戦争が繰り広げられています。ただ、実務で大事なのは「どの思想が真に正しいか」ではなく、「自分たちのチームで運用できるか」という1点です。美しい設計でも運用できなければ意味がなく、泥臭い設計でもチームが回せるなら成功です。
全体構造の3大パターン
| パターン | 特徴 | 向くケース |
|---|---|---|
| モノリス | 1つのアプリにまとめる伝統的な構成 | 小〜中規模 / 少人数チーム |
| マイクロサービス | 機能毎に独立したサービスに分割 | 大規模 / 多人数・多チーム |
| モジュラーモノリス | モノリスだが内部を明確にモジュール分割 | 中規模 / 将来の分割に備える |
家で例えるなら、モノリスはワンルーム（全てが一部屋）、モジュラーモノリスは3LDKの戸建て（部屋は分かれているが同じ家）、マイクロサービスはマンションの各部屋を別世帯に貸す（自由だが鍵・水道・契約を個別に管理）。ワンルームが手狭になる前に「マンション経営」に手を出すと、確実に家賃回収で疲弊します。
モノリスは開発の始めやすさと小規模運用の楽さで圧倒し、マイクロサービスは多チームの並列開発と障害の局所化で勝ちます。「最初からマイクロサービス」は過剰設計の典型で、モジュラーモノリスから始めて組織規模が30人を超えてから段階的に分割するのが健全なパスです。「分けるのはいつでもできる、戻すのは地獄」です。
規模×ソフトウェア構造の段階表
ソフトウェアアーキテクチャはチーム人数で推奨構造がほぼ決まります。Conway’s law（組織構造がシステム構造を決めるという経験則）が強く働く領域です。
| チーム人数 | 推奨構造 | API方式 |
|---|---|---|
| 1〜10人 | モノリス → モジュラーモノリス（1DB・1言語） | REST |
| 10〜30人 | モジュラーモノリス | REST+内部gRPC |
| 30〜100人 | モジュラー+部分的マイクロサービス | REST+gRPC+イベント |
| 100人〜 | マイクロサービス（中核）+モジュラーモノリス（業務領域） | gRPC+Kafka |
マイクロサービスの実質下限は「チーム30人+運用専任5人以上」です。Segmentの140サービス→モノリス回帰（2020年）や、Amazon Prime Videoチームのマイクロサービスからモノリス統合（2023年、インフラコスト90%削減）が典型で、規模に見合わない分散は必ず破綻します。
どう選べばいいのか ― ケース別の選定
新規のWebサービス（スタートアップ・SaaS初期）なら
モジュラーモノリス+TypeScript+Next.js+REST+Cookieセッション。作り始めの速度と、拡大した時の分割容易性を両立できる現在の鉄板です。1DB完結でACIDを効かせ、分散トランザクションを抱えない構成が最もバグを呼びにくいです。
成長した中小SaaSでモノリスが手狭になったら
モジュラーモノリスへ段階移行し、本当にボトルネックになっている機能だけを切り出します。全面マイクロサービス化は運用負荷だけが増えて業務価値に見合いません。トラフィック急増系なら、書き込みは強整合を維持しつつ、閲覧系は結果整合+CDN+キャッシュ層で水平スケールさせるのが常道です。
複雑な業務ロジックの基幹システム（金融・保険・医療）なら
Spring BootまたはASP.NET Core+クリーン or ヘキサゴナル+DDD+強整合（ACID）。業務ルールが多く長寿命な領域では、ドメインを外部依存から守る投資が長期的に回収できます。OIDC+SSO基盤で権限管理も一元化するのが定番です。
AI判断軸 ― AIに読みやすい設計はチームにも読みやすい
AI駆動開発が前提になると、ソフトウェアアーキテクチャ全体で「AIに読みやすく・書きやすい設計」の重要度が増します。
アーキテクチャ選定がAI活用の上限を決める
AIにコードを書かせる時、精度を左右する最大の要因は「AIに渡せるコンテキストの質」です。型定義やスキーマがコードとして存在すれば、AIはそれを読んで正確なコードを生成します。逆に、設計がWiki上の図やSlackでの口頭合意にしか存在しない場合、AIには見えないため毎回手動で説明を書き添える必要があります。ここでのポイントは、AI時代に有利な設計特性（型の明示・標準プロトコル・モジュール分割）は、AI以前から「良い設計」とされてきたものと完全に一致するということです。従来の良い設計をきちんと実践しているチームが、AIの恩恵を最も受けます。
モノリスがAI活用で有利になる構造的な理由
マイクロサービスでは仕様が複数リポジトリに分散します。サービスAの修正時に、サービスBのAPI仕様・サービスCのイベントスキーマ・共有ライブラリの型定義を同時にAIのコンテキストに入れる必要があり、情報収集だけで手間がかかります。モジュラーモノリスであれば、同一リポジトリ内に全ての型定義・スキーマ・テストが存在するため、AIは関連コードを一度に参照できます。境界はモジュールで論理的に区切りつつ物理的には1つのリポジトリで管理する──この構成がAI時代のデフォルトとして最も合理的です。
主流技術スタックの選定がAI精度に直結する
Next.js+TypeScript+Prismaのような主流スタックは、GitHubの公開リポジトリに数十万件規模の実装例があり、生成されるコードの品質が安定します。内製フレームワークやニッチなライブラリの場合、AIは類似の公開コードを参照できないため、基本的な使い方すら間違えることがあります。技術選定の時点で「AIが学習済みかどうか」を判断基準の一つに加えるのが2026年の現実です。
やってはいけないこと
各論記事で詳しく触れる禁じ手のうち、全体構造レベルで押さえるべき核心を6つに絞ります。
| 禁じ手 | なぜダメか |
|---|---|
| 30人未満でマイクロサービス化 | Segment 2020年と同じ結末、分散トランザクションの沼に沈む |
| マイクロサービスを性能目的で選ぶ | サービス間通信のオーバーヘッドで性能はむしろ下がる。スケールは縦が先 |
| 新技術を情報量・人材なしで採用 | 5年後に書ける人が消え、塩漬けプロジェクト化する |
| モジュール境界を引かずモノリス運用 | 10人超えで変更衝突が頻発する。最初から境界を引く |
| 1プロジェクト5言語以上混在 | 保守人員が分散する。2言語以内が健全 |
| 認証を自前実装 | 穴だらけになる。Auth0 / Clerk / Firebase Authへ委譲する |
このカテゴリの知識構造
このカテゴリは全8記事で構成され、大枠の骨格から個別の設計判断へと段階的に降りていく構造です。
グループ1（骨格）では、モノリス/マイクロサービスの全体構造を決め、それに合った言語・FW・モジュール分割を選びます。全体構造を決めずに言語やFWを先に選ぶと、構造と道具のミスマッチが起きます。
グループ2（通信）では、骨格の上でモジュール間・サービス間をどう繋ぐかを設計します。REST/gRPC/GraphQLの選択はAPI記事で、分散トランザクションの扱いはトランザクション記事で掘り下げます。
グループ3（横断）の認証・セッション管理は、全ての通信に絡む横断テーマです。セキュリティアーキテクチャカテゴリの認証設計記事と合わせて読むと、実装レベルとポリシーレベルの両面が揃います。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。それぞれの詳細は配下の各論記事で扱います。
- 全体構造（モノリス / モジュラーモノリス / マイクロサービス）
- プログラミング言語とフレームワーク
- モジュール設計（レイヤード / ヘキサゴナル / クリーン）
- 通信・API設計（REST / GraphQL / gRPC / WebSocket）
- トランザクション設計（ACID / 結果整合 / Saga）
- 認証・セッション管理（Cookie / JWT / OIDC）
まとめ
本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「ソフトウェアアーキテクチャ」カテゴリの入口として、この領域全体を俯瞰しました。如何だったでしょうか。
ソフトウェアアーキテクチャは思想の宗派が多い領域ですが、判断軸は「自分たちのチームで回せるか」に尽きます。モジュラーモノリス+主流FW+標準プロトコルの3点セットを基本に、AIに優しい設計が長期保守では人間にも優しい方向に重なるという見方を外さないのが2026年の現実解です。
次回からはこの領域の各論に入り、まずプログラミング言語の選び方から解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Martin Fowler - Software Architecture Guide も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（23/95）