AI時代にこそ抑えたい「ソフトウェアアーキテクチャ」を、体系的に整理してみた

最近、生成AIのおかげでコードを書くこと自体は本当に楽になったなぁと思います。

でも、AIに丸投げする前に、「そもそもコードをどう切り分け、どこに置くか」は人間が決めなきゃいけないな、と感じています。

この全体的な判断を扱うのが、ソフトウェアアーキテクチャという位置付けなのかなと感じるこも多くなりました。
設計方針が曖昧なままだと、実装が速くなる分、設計がグチャグチャになるスピードも上がってしまいます。これからのAI時代に本当に必要なのは、すべてのコードを自分で書く力ではなく、「AIが安全にコードを書き換えられる境界」をきれいに引く力だと思っています。

ただ、アーキテクチャの分類や境界線は、エンジニア同士でも特にもめやすいテーマです。
「いや、その分類はちょっと違うんじゃない？」と思われる部分もあるかもしれませんが、まずは全体像をざっくり掴むための「一つの視点」として、気軽に読み進めてもらえたら嬉しいです🙌

この記事を読むとわかること

• アーキテクチャを整理するための5つの分類軸

• モノリス、モジュラーモノリス、マイクロサービスの違い

• レイヤードとクリーンアーキテクチャ系統の違い

• ヘキサゴナル、オニオン、クリーンの関係

• Vertical Sliceやマイクロカーネルの位置づけ

• イベント駆動、CQRS、Sagaなどが解決する問題

• 複数のアーキテクチャを組み合わせる考え方

• 初学者におすすめしたい学習順序

今回はシリーズ全体の「地図」を整理する

本シリーズでは、AI時代に学び直したいソフトウェアアーキテクチャを、基礎から順番に整理していきます。

今回の全体概要編では、個別の実装方法へ入る前に、まず全体像を確認します。

モノリス、マイクロサービス、クリーンアーキテクチャ、イベント駆動、CQRSなどは、すべて同じ基準で比較できるものではありません。

モノリスとマイクロサービスは、システムの分割やデプロイ単位を扱います。

レイヤードやクリーンアーキテクチャは、アプリケーション内部の責務と依存関係に関する考え方です。

CQRSやSagaは、特定のデータ管理上の問題を解決する設計パターンに当たります。SPAとSSRは、主にWebアプリケーションの画面構成や描画方法を表すものです。

MicrosoftのAzure Architecture Centerでも、N-tier、マイクロサービス、イベント駆動、Web-Queue-Workerなどはアーキテクチャスタイルとして整理され、CQRS、Saga、BFFなどは設計パターンとして別に掲載されています。

つまり、厳密には同じ種類の用語ではありません。

本記事では、各用語が「何を決めるためのものなのか」を理解しやすくするため、学習用に5つの視点へ整理します。

ソフトウェアアーキテクチャの全体像

ソフトウェアアーキテクチャ
│
├─ システムの分割・デプロイ
│  ├─ モノリス
│  ├─ モジュラーモノリス
│  ├─ SOA
│  ├─ マイクロサービス
│  └─ サーバーレス
│
├─ アプリケーション内部
│  ├─ レイヤード
│  ├─ ヘキサゴナル
│  ├─ オニオン
│  ├─ クリーン
│  ├─ Vertical Slice
│  └─ マイクロカーネル
│
├─ 通信・処理方式
│  ├─ リクエスト・レスポンス
│  ├─ イベント駆動
│  ├─ Web-Queue-Worker
│  ├─ オーケストレーション
│  └─ コレオグラフィ
│
├─ データ管理
│  ├─ 共有データベース
│  ├─ Database per Service
│  ├─ CQRS
│  ├─ Event Sourcing
│  └─ Saga
│
└─ フロントエンド
   ├─ MVC
   ├─ MVVM
   ├─ SPA
   ├─ SSR
   ├─ BFF
   └─ マイクロフロントエンド

それぞれの分類が答える質問は、次のように異なります。

分類主に考えることシステムの分割・デプロイどの単位で分け、リリースするかアプリケーション内部責務と依存関係をどう整理するか通信・処理方式コンポーネント同士をどう連携させるかデータ管理データを誰が所有し、どう整合させるかフロントエンド画面、状態、バックエンドをどう分担するか

ここからは、この順番に沿って代表的な構成を確認します。

1．システムの分割・デプロイに関するアーキテクチャ

最初の分類は、システムをどの単位に分け、どの単位でデプロイするかという視点です。

モノリス

モノリスは、アプリケーション全体を一つの単位としてデプロイする構成です。

画面、API、業務ロジック、データアクセスなどが、一つのアプリケーションに含まれます。

構成が比較的単純で、ローカル開発、テスト、デバッグ、デプロイの流れを理解しやすい点が特徴です。小規模チームや新規サービスでは、十分に合理的な選択になります。

モノリスであることと、コードが整理されていないことは別問題です。

Microsoftのガイドでも、モノリシックとは「単一の単位としてデプロイされること」を指しており、内部を複数のレイヤーに整理した構成が紹介されています。

モジュラーモノリス

モジュラーモノリスは、デプロイ単位を一つに保ちながら、内部を注文、在庫、会員などの業務モジュールへ分ける構成です。

単にディレクトリを分割するだけではありません。

各モジュールの責務、公開インターフェース、依存方向、データ所有権を明確にします。

モノリスの運用上の単純さを維持しながら、機能間の結合を抑えやすい点が特徴です。将来的に一部のモジュールをサービスとして切り出す場合にも、境界を検討しやすくなります。

ただし、「将来はマイクロサービスにするかもしれない」という理由だけで、最初から過度な抽象化を持ち込む必要はありません。

まずは現在の業務境界を明確にすることが先です。

SOA

SOAは、Service-Oriented Architectureの略です。

顧客管理、決済、在庫管理などの業務機能をサービスとして提供し、企業内の複数システムから再利用します。

マイクロサービスよりサービスの粒度が大きく、個別のアプリケーションを細かく分割することよりも、企業全体のシステム統合を目的とすることが多い構成です。

AWSも、SOAのサービスは比較的大きな業務能力を担当し、マイクロサービスはより小さな機能へ特化する傾向があると説明しています。

マイクロサービス

マイクロサービスでは、システムを複数の小さな自律サービスへ分割します。

各サービスは特定の業務能力を担当し、APIやメッセージを通して連携します。独立してデプロイでき、原則として自身のデータを管理することも重要な特徴です。

サービス単位でリリースやスケールを行えるため、複数チームによる開発と相性があります。

一方で、ネットワーク障害、タイムアウト、サービス間認証、結果整合性、分散トレーシングなど、分散システム特有の課題が増えます。

サービスを小さく分ければ、システム全体が単純になるわけではありません。

独立して変更・デプロイする必要があるのか。その利益が運用の複雑さを上回るのか。

この判断が必要です。

サーバーレス

サーバーレスは、クラウド事業者がインフラのプロビジョニング、スケーリング、保守を担当する実行モデルです。

サーバーが存在しないという意味ではありません。開発者がサーバー管理を直接行わず、コードやデータへ集中できるようにする考え方です。

HTTPリクエスト、ファイルのアップロード、メッセージ受信などを起点とする処理に向いています。

ただし、サーバーレスはモノリスやマイクロサービスと完全に同じ分類ではありません。

モノリスの一部処理だけをサーバーレス関数へ切り出す構成も可能です。

2．アプリケーション内部を整理するアーキテクチャ

システム全体の分割方法を確認したところで、次は一つのアプリケーションやサービスの内部を考えます。

レイヤードアーキテクチャ

レイヤードアーキテクチャでは、コードを技術的な責務ごとの層へ分けます。

プレゼンテーション層
        ↓
アプリケーション層
        ↓
ドメイン層
        ↓
インフラストラクチャ層

構成を理解しやすく、多くの業務システムで利用されています。

ただし、典型的なレイヤード構成には、性質の異なる二つの課題があります。

一つ目は、一つの機能に関係するコードが複数レイヤーへ散らばりやすいことです。

注文作成機能を変更するだけでも、Controller、Service、Repositoryなどを横断する場合があります。この問題に対する選択肢が、Vertical Sliceです。

二つ目は、実装方法によって、重要な業務ロジックがデータベースやフレームワークなどの技術詳細へ依存しやすいこと。

この依存方向を見直す動機から、ヘキサゴナル、オニオン、クリーンといった考え方が登場します。

ヘキサゴナル・オニオン・クリーンは近い系統にある

ヘキサゴナル、オニオン、クリーンアーキテクチャは、完全に同じものではありません。

しかし、互いに無関係な三つの選択肢でもありません。

Robert C. Martin氏はクリーンアーキテクチャの原典で、ヘキサゴナルやオニオンなどは細部こそ異なるものの、関心の分離や業務ルールの独立という共通目的を持つ、非常によく似たアーキテクチャだと説明しています。

学習時には、三つの細かな図の違いを暗記するより、次の共通原則を押さえる方が重要です。

• 業務ルールを中心へ置く

• UIやデータベースを外側の詳細として扱う

• 依存関係を外側から内側へ向ける

• 外部技術との接続点をインターフェースで分離する

ヘキサゴナルアーキテクチャ

ヘキサゴナルアーキテクチャは、Ports and Adaptersとも呼ばれます。

アプリケーションと外部世界の接続点をPortとして定義し、Web API、データベース、外部サービスなどをAdapterとして接続します。

特定のデータベースやUIを交換しても、中心の業務ロジックへ影響が広がりにくい構成を目指します。

オニオンアーキテクチャ

オニオンアーキテクチャは、ドメインモデルを中心に置き、その外側をアプリケーション、インフラ、UIなどが取り囲む構成です。

外側の層は内側へ依存しますが、内側は外側の実装詳細を知りません。

クリーンアーキテクチャ

クリーンアーキテクチャも、業務ルールを外部技術から分離する考え方です。

一般的には、Entities、Use Cases、Interface Adapters、Frameworks and Driversなどの領域で説明されます。

重要なのはフォルダ名をそろえることではなく、依存関係を内側へ向けることです。

💡レイヤードアーキテクチャとの違い

• レイヤードアーキテクチャは、コードを技術的な役割ごとの層へ分けます。

• 典型的には、画面、アプリケーション、ドメイン、インフラの順に処理を呼び出します。

• クリーンアーキテクチャは、業務ルールがデータベースやフレームワークへ依存しない構造を重視します。

• データベースの具体的な実装は、内側で定義したインターフェースへ依存します。

• レイヤードでも依存性逆転を利用できるため、両者が完全に別の構成というわけではありません。

💡オニオンアーキテクチャとの違い

• どちらも、業務ルールを中心に置き、依存関係を外側から内側へ向けます。

• オニオンアーキテクチャは、特にドメインモデルを中心にした構造を重視します。

• クリーンアーキテクチャは、Entitiesに加えて、Use Casesや入出力の境界も明確に分けます。

• オニオンはドメインとインフラの分離を説明しやすい構成です。

• クリーンは、入力からUse Caseを通り、出力へ至る処理の流れまで整理しやすい特徴があります。

• 両者は非常に近い考え方であり、実務では組み合わせた構成も使われます。

Vertical Slice Architecture

Vertical Slice Architectureでは、コードを技術レイヤーではなく、機能やユースケース単位でまとめます。

Features
├─ CreateOrder
│  ├─ Endpoint
│  ├─ Validation
│  ├─ Handler
│  └─ DataAccess
├─ CancelOrder
└─ GetOrder

提唱者のJimmy Bogard氏は、一つの機能変更で複数レイヤーを横断するのではなく、変更軸に沿って関連コードを一つのSliceへまとめる考え方として説明しています。

AIコーディングエージェントに対しても、「CreateOrderの範囲だけを変更する」と指定しやすくなります。

なお、Vertical Sliceとクリーンアーキテクチャは必ずしも排他的ではありません。

機能単位でコードをまとめつつ、その機能内の重要な業務ルールだけを外部技術から分離する設計も可能です。

マイクロカーネルアーキテクチャ

マイクロカーネルアーキテクチャでは、最小限のコア機能と、追加可能なプラグインへシステムを分けます。

IDE、CMS、ブラウザ、業務パッケージなど、利用者や用途に応じて機能を拡張したいシステムで使われます。

レイヤードやクリーンとは異なり、主に「依存方向」ではなく「拡張性」を扱う考え方です。

3．通信・処理方式に関するアーキテクチャ

内部構造を分けた後は、コンポーネント同士をどのようにつなぐかを考えます。

リクエスト・レスポンス

呼び出し元が処理を依頼し、結果が返るまで待つ方式です。

REST API、GraphQL、gRPCなどが代表例になります。

処理の流れを追いやすい一方、同期呼び出しが何段も連鎖すると、一つの遅延や障害が後続処理へ広がりやすくなります。

イベント駆動

イベント駆動では、システム内で発生した出来事をイベントとして発行し、必要なコンポーネントが受け取ります。

基本的な構成要素は、イベントを生成するProducer、受け取るConsumer、両者をつなぐイベントチャネルです。

発行側と受信側を疎結合にしやすい反面、重複、順序、再送、スキーマ変更、障害追跡などを設計する必要があります。

Web-Queue-Worker

Web-Queue-Workerは、HTTPリクエストを受け付けるWeb部分と、重い処理を担当するWorkerをキューで分離します。

動画変換、メール送信、帳票生成、AI処理など、完了まで時間のかかる処理に適しています。

WebフロントエンドとWorkerは、非同期のメッセージキューを介して通信します。

オーケストレーションとコレオグラフィ

オーケストレーションでは、中央のサービスやワークフローエンジンが処理順序を制御します。

全体の流れを把握しやすい一方、中央コンポーネントへ責務が集中しやすくなります。

コレオグラフィでは中央の司令塔を置かず、各サービスがイベントへ反応して処理を進めます。

疎結合にしやすい反面、業務フロー全体が見えにくくなることがあります。

どちらが常に優れているわけではありません。

処理全体の可視性と、各サービスの自律性のどちらを重視するかで判断します。

4．データ管理に関するアーキテクチャとパターン

通信方法まで決めても、データの所有者が曖昧では、システムの境界を保てません。

そこで必要になるのが、データ管理の設計です。

共有データベース

複数のモジュールやサービスが、同じデータベースを利用する構成です。

JOINやトランザクションを扱いやすい反面、他のモジュールが所有するテーブルを自由に更新すると、データベースを通じて強く結合します。

一つのデータベースを使う場合でも、モジュールごとに所有するテーブルやスキーマを決めることが重要です。

Database per Service

各サービスが、自分のデータベースまたはデータ領域を所有します。

他のサービスは、APIやイベントを通して必要な情報を取得します。

サービスの独立性を高められる一方、複数サービスをまたぐJOINや一括トランザクションは難しくなります。

CQRS

CQRSは、データを変更するCommandと、参照するQueryを分離するパターンです。

更新側は業務ルールや整合性を重視し、参照側は検索や画面表示へ最適化できます。

ただし、モデルや処理経路が増えるため、単純なCRUDシステムへ一律に導入するものではありません。

Event Sourcing

Event Sourcingでは、現在の状態だけでなく、状態を変更した出来事をイベントとして保存します。

イベントを順番に再生することで、現在または過去時点の状態を再構築できます。

監査や履歴の復元に強みがある一方、イベントのバージョン管理、スキーマ進化、再生、検索などの複雑さが増します。

Microsoftも、多くのシステムでは従来のデータ管理で十分であり、利点が複雑さを正当化する場合に採用すべきだと説明しています。

Saga

Sagaは、複数サービスにまたがる業務処理を、小さなローカルトランザクションの連鎖として管理するパターンです。

途中で失敗した場合は、決済取消や在庫解放などの補償処理を行います。

単一のデータベーストランザクションを利用できない分散システムで、データ整合性を管理するための考え方です。

5．フロントエンドに関するアーキテクチャ

最後は、画面、表示状態、バックエンド通信をどのように分担するかという視点です。

ここにも異なる種類の概念が含まれています。

• MVC、MVVMは画面内部の責務分割

• SPA、SSRは画面の配信・描画方式

• BFFはフロントエンド専用バックエンド

• マイクロフロントエンドは開発・デプロイ単位の分割

MVCとMVVM

MVCは、Model、View、Controllerへ責務を分ける構成です。

MVVMは、Model、View、ViewModelへ分け、ViewModelが画面に必要な状態や操作を提供します。

どちらも、画面表示と処理を一つの場所へ集中させないための考え方です。

SPAとSSR

SPAは、初回にアプリケーションを読み込み、その後の画面遷移や更新を主にブラウザ側で行います。

SSRは、サーバー側でHTMLを生成してからブラウザへ返す方式です。

現在はどちらか一方へ統一するのではなく、ページや機能に応じて組み合わせる構成もあります。

BFF

BFFは、Backend for Frontendの略です。

Web、モバイル、管理画面など、フロントエンドごとに専用のバックエンドを配置します。

クライアント固有のデータ変換や通信を集約できる一方、似た処理を複数のBFFへ重複させない工夫が必要です。

マイクロフロントエンド

マイクロフロントエンドでは、大きなフロントエンドを独立して開発・デプロイできる単位へ分割します。

複数チームが各領域を担当しやすくなる反面、デザイン統一、認証状態の共有、依存ライブラリ、画面間通信などの課題が増えます。

バックエンドがマイクロサービスだからといって、必ずマイクロフロントエンドにする必要はありません。

アーキテクチャは複数を組み合わせて使う

ここまで紹介したものから、一つだけを選ぶわけではありません。

実際のシステムでは、異なる問題を解決するために複数の構成を組み合わせます。

システムの分割・デプロイ
：モジュラーモノリス

アプリケーション内部
：Vertical Slice
：複雑な業務領域だけクリーンアーキテクチャを適用

通信・処理方式
：通常処理はリクエスト・レスポンス
：時間のかかる処理はWeb-Queue-Worker

データ管理
：一つのデータベース
：モジュールごとに所有テーブルを分離

フロントエンド
：Vueを利用したSPA
：必要に応じてBFFを配置

これは矛盾した構成ではありません。

モジュラーモノリスは、システム全体の分割とデプロイ単位を扱います。

Vertical Sliceは、コードを変更単位でまとめる考え方です。

クリーンアーキテクチャは、重要な業務ルールと技術詳細の依存関係を整理します。

それぞれが別の問題へ答えています。

初学者におすすめの学習順序

アーキテクチャ用語を最初からすべて暗記する必要はありません。

次の順番で学ぶと、それぞれの必要性を理解しやすくなります。

整理されたモノリス
        ↓
レイヤード
        ↓
モジュラーモノリス
        ↓
Vertical Slice
        ↓
ヘキサゴナル／オニオン／クリーン
        ↓
キュー／イベント駆動
        ↓
マイクロサービス
        ↓
CQRS／Event Sourcing／Saga

まずは、一つのアプリケーションを最後まで作る経験が必要です。

その後、責務の分離、モジュール境界、依存方向、非同期処理、データ所有権という順に理解を広げます。

マイクロサービスは、アーキテクチャ学習の入口でなくても構いません。

モノリスの中で適切な境界を作れなければ、サービスへ分割しても境界は曖昧なままです。

まとめ：結局、大切なのは「アーキテクチャの名前」じゃなくて「目の前の問題」

色んな用語を整理しましたが、私が一番感じているのは「どれを使うか」より、自分の中で次の3つに答えが出ているかが大事だな、ということです。

• 「何」を綺麗に分けたくて、その設計にするのか？

• 今、目の前にある「どんな問題」を解決したいのか？

• その代わりに、どんな「面倒くささ（複雑さ）」を背負う覚悟があるか？

万能な正解はないので、小さく始めるなら普通のモノリスと1つのDBで十分。必要に迫られたら、その時に変えればいいんです。

AI時代の設計も、用語の暗記が目的ではないはず。 「自分とAIが同じシンプルな方針を共有できて、変更の影響をサクッと予測できるか」。結局はここに尽きるな、と実感しています。

この記事が、迷ったときのちょっとした道しるべになれば嬉しいです。

参考文献

• Microsoft Learn「Architecture Styles」

• Microsoft Learn「Common web application architectures」

• Microsoft Learn「Microservices architecture style」

• Microsoft Learn「Event-driven architecture style」

• Microsoft Learn「CQRS pattern」

• Microsoft Learn「Event Sourcing pattern」

• Microsoft Learn「Saga design pattern」

• Alistair Cockburn「Hexagonal Architecture」

• Robert C. Martin「The Clean Architecture」

• Jimmy Bogard「Vertical Slice Architecture」

• AWS「SOA vs. Microservices」

• AWS Prescriptive Guidance「Understanding and implementing micro-frontends」