まとめ
私の実務感覚でも、AI はコード生成を速くしますが、分散されたサービスの API 契約、スキーマ、ログ、環境変数まで自動で理解し続けてくれるわけではありません。この記事では、Microsoft、AWS、Martin Fowler、Spring Modulith、Anthropic の資料を根拠にしつつ、どこまでが現実的な判断なのかを整理します。
目次
この記事の内容
モジュラーモノリスが再考される理由
新しいサービスを作るとき、「将来大きくなるなら最初からマイクロサービスにすべきか」と考えがちです。独立デプロイ、独立スケール、チームごとの所有権は魅力的です。ただし、それらは無料ではありません。
個人開発や小規模チームでは、最初に問題になるのは高トラフィックよりも、複数リポジトリ、複数デプロイパイプライン、環境変数、認証、ログ、監視、ネットワーク障害、データ整合性を扱う運用コストです。AI コーディングツールを使っていても、この複雑さは消えません。
Modular Monolith は、デプロイ単位はひとつに保ちながら、内部では会員、注文、決済、通知などのビジネスモジュールを分ける考え方です。単なる「大きなモノリス」ではなく、境界を守ることで後から分割できる余地を残します。
モノリス、モジュラーモノリス、マイクロサービス
Monolith
Monolith は、アプリケーション全体をひとつの単位として実行・デプロイする構成です。初期開発ではローカル実行、デバッグ、デプロイが簡単です。一方、境界が曖昧になると、注文処理が決済テーブルを直接変更したり、通知処理が会員情報に密結合したりして、変更が怖いコードになりやすいです。
Modular Monolith
Modular Monolith もデプロイはひとつですが、内部ではビジネス能力ごとにモジュールを分けます。重要なのはディレクトリ名ではなく、依存関係の方向、公開インターフェイス、データ所有権を守ることです。Spring Modulith のようなツールは構造の文書化や検証に役立ちますが、最終的にはチームの習慣が重要です。
Microservices / MSA
マイクロサービスは、機能を独立してデプロイできるサービスに分けます。Martin Fowler と James Lewis の説明でも、サービスはビジネス能力を中心に編成され、独自のデータを持つことが多いとされています。利点は大きい一方で、タイムアウト、再試行、分散トランザクション、可観測性、DevOps 文化などが前提になります。
比較表
| 項目 | Monolith | Modular Monolith | Microservices |
|---|---|---|---|
| デプロイ | 単一 | 単一 | サービスごとに独立 |
| 内部構造 | 境界が曖昧になりやすい | モジュール境界を明確にする | ネットワーク越しに分離する |
| 運用複雑度 | 低い | 低〜中 | 高い |
| 開発速度 | 初期は速い | 初期〜中期でバランスがよい | 準備なしでは遅くなりやすい |
| スケール | アプリ全体 | アプリ全体 | サービス単位 |
| 主なリスク | 大きな泥団子 | ルールを守らないと普通のモノリスになる | 分散システムの運用負債 |
| 向く場面 | MVP、社内ツール | 個人開発、小規模チーム、AI 協業 | 複数チーム、高トラフィック、明確な所有権 |
個人開発 + AI で何が変わるのか
AI エージェントは便利ですが、企業システム全体を無限に覚えているわけではありません。Anthropic の資料が説明するように、モデルは与えられたコンテキストウィンドウ内の情報をもとに判断します。サービスが細かく分かれるほど、AI に説明すべき契約、スキーマ、イベント、ログが増えます。
Modular Monolith なら、ローカルでの実行とテストはひとつのアプリで完結しつつ、「注文モジュールだけを見る」「決済モジュールの公開 API は変えない」といった指示を出しやすくなります。これは人間のレビューにも AI への指示にも有効です。
実際の設計基準
技術層ではなくビジネス能力で分ける
controller、service、repository だけで分けても Modular Monolith にはなりません。会員、注文、決済、通知のような業務能力で境界を考えます。
モジュール間の直接参照を制限する
別モジュールの内部クラスを自由に import できるなら、境界は飾りです。公開 API、アプリケーションサービス、ドメインイベントなどを通して連携させます。
データ所有権を早めに決める
初日からサービスごとにデータベースを分ける必要はありません。ただし、どのモジュールがどのテーブルの書き込み責任を持つかは決めておくべきです。
モジュール単位のテストを持つ
AI がコードを変更する場合も、モジュール単位のテストは回帰を見つける安全装置になります。
よくある誤解と失敗パターン
「サブディレクトリを作れば Modular Monolith ですか？」
いいえ。依存方向、公開インターフェイス、データ所有権を守って初めて意味があります。
「マイクロサービスのほうが常に現代的ですか？」
いいえ。マイクロサービスはコード分割だけでなく、運用分割でもあります。運用能力がない状態では負債になり得ます。
「AI があるなら設計は軽くてよいですか？」
むしろ逆です。AI は速く実装しますが、境界が曖昧だと速く壊します。小さなチームほど、明確な構造が助けになります。
マイクロサービスへ移行する時期
以下の兆候が繰り返し出るなら、特定モジュールのサービス化を検討できます。
- 一部機能だけに負荷が集中し、独立スケールが必要になった
- 複数チームが同じデプロイ単位で頻繁に衝突する
- 障害分離がビジネス上重要になった
- ドメイン境界と API 契約が安定した
- 監視、ログ、デプロイ自動化、障害対応の体制がある
その場合も一括移行ではなく、最も独立性の高いモジュールから抽出するほうが安全です。
結論
問いは「モノリスかマイクロサービスか」ではなく、「今のチーム規模、運用能力、拡張要求に合っているか」です。AI を使って速く作る個人開発者や小規模チームにとっては、境界を守った Modular Monolith が現実的な出発点になりやすいです。
根拠は公式・実務系資料にありますが、最終判断は自分の運用体制で決まります。まずは単一デプロイで検証し、境界とテストを残し、必要になった部分だけを後から分ける。これが、AI 協業時代にも扱いやすい進め方だと思います。
参考文献
- Microsoft Learn — Common web application architectures
- AWS — What are Microservices?
- Martin Fowler / James Lewis — Microservices
- Martin Fowler — Monolith First
- Martin Fowler — Microservice Prerequisites
- Spring Modulith Reference
- microservices.io — Monolithic Architecture
- microservices.io — Microservice Architecture
- Kamil Grzybek — Modular Monolith: A Primer
- Anthropic Docs — Context windows