はじめに
マイクロサービス化したのに、なぜかデプロイが遅くなった。なぜかサービス間の結合が強くなった。なぜかモノリスより複雑になった——この経験をしたエンジニアは多い。
これは「分散モノリス（Distributed Monolith）」という失敗パターンだ。マイクロサービスの形を取りながら、実態はモノリスと同じ（あるいはそれ以上）の結合度を持つシステム。最悪のパターンは、マイクロサービスとモノリスの両方のデメリットだけを受け取ることになる。
2026年、業界ではもう一つの動きが起きている。「マイクロサービスに急いで移行したチームが、静かにモノリスへ集約し直している」（Java Code Geeks 2026年）。
この記事では、分散モノリスを回避するためのサービス境界分析を Claude Codeで体系的に行う手法と、Strangler Figパターンによる安全な移行手順を解説する。
2026年のアーキテクチャ論争：3つの選択肢
「マイクロサービス一択」という雰囲気は少し変わってきた。2026年時点での3択の位置づけをまとめておく。
| アーキテクチャ | 最適なユースケース | 2026年の位置づけ |
|---|---|---|
| モノリス | 小チーム・初期フェーズ | 再評価の動き。Shopifyは単一のモノリスを維持し成功 |
| モジュラーモノリス | 中規模チーム・段階的移行 | 「第3の道」として急速に注目。マイクロサービスへの踏み台にもなる |
| マイクロサービス | 大チーム・高スケール要件 | 正しく実装すれば有効。ただし「正しく」の難易度が高い |
モジュラーモノリスは「1つのアプリ・モジュールは分離」というアーキテクチャだ。外から見ると1つのデプロイ単位（モノリス）だが、内部構造はサービスごとにモジュールとして分割（マイクロサービス的な境界）されており、データは同一DBを使いつつモジュールごとにスキーマを分割する。
2022年にメルカリが取引ドメインでモジュラーモノリス化を採用（Engineering Blog）したのを皮切りに、国内大手での採用事例が増えている。
Claude Codeによるサービス境界分析
境界を引く前の大前提
まず原則から確認する。
「テーブルは必ず1つのサービスだけが書き込む。モノリスと新サービスの両方が同じテーブルに書くなら、それは本物の境界ではない——分散モノリスを作っているだけだ」（microservices.io 2026年）
Step 1: 依存関係マップの生成
このリポジトリ（Javaコードベース）のモジュール依存関係を分析して：
1. 各クラス・モジュール間の依存グラフをMermaid形式で出力
2. 循環依存を全て特定して強調
3. 高結合度モジュール（依存が集中しているクラス）のトップ10を列挙
4. 自然なサービス境界の候補を3〜5個提案して
モジュール分割の候補は「DDDの境界づけられたコンテキスト（Bounded Context）」を基準にして
Diptendu Das（Medium 2026年3月）の実践報告では「AIが依存マッピング・コントラクト抽出・ボイラープレート生成・テストスキャフォールディングという最も辛い部分を、数日から数時間に圧縮してくれた」とある。
Step 2: サービス抽出の優先順位付け
この依存グラフを元に、サービス化の優先順位を付けて：
良いサービス抽出候補の条件：
- 境界が明確（他モジュールへの依存が少ない）
- DBの結合が低い（専用テーブルを持っている、または持てる）
- ビジネスリスクが低い（失敗してもシステム全体に影響が少ない）
最初に抽出すべきでないもの：
- 最重要ビジネスロジック（失敗リスクが高い）
- 依存が多いモジュール（境界が曖昧）
- 複数モジュールと共有テーブルがある部分
Step 3: 分散モノリスの事前チェック
この抽出計画が「分散モノリス」になっていないかチェックして：
1. どのテーブルを誰が書き込むか（1テーブル1サービスになっているか）
2. 同期HTTP呼び出しが多すぎないか（クリティカルパスのレイテンシを計算）
3. サービス間の変更が連鎖していないか（1サービス変更で他サービスのデプロイが必要か）
4. データの整合性をどう保証するか（SAGAパターン・結果整合性が必要か）
サブエージェントで並列分析を加速する
境界分析はClaude Codeのサブエージェント機能を活用すると効果的だ。Zennのscalar_sol_blog（2026年）では「ドメイン分析・データ依存分析・トラフィックパターン分析・チーム構造との整合性」という4観点を並列で分析するエージェント群を構築し、16本の調査ドキュメントと4フェーズ移行ロードマップを自動生成した事例が報告されている。大規模コードベースの境界分析では、単一セッションより並列サブエージェントの方が見落としを防ぎやすい。
Strangler Figパターン × Claude Code：段階的移行手順
既存のモノリスをいきなり置き換えず、新機能をマイクロサービスとして追加し、徐々にトラフィックを移行させていくパターンが「Strangler Fig（絞め殺しイチジク）パターン」だ。イチジクの木が既存の木に巻きつきながら成長する様子から命名された。
Diptendu Das（Medium 2026年3月）の実践では、11の異なるビジネスドメイン・42万行のJavaコード・3週間に1回しかできなかったデプロイを、このパターンで段階的に移行した。
移行は3つのフェーズで進める。
Phase 1: APIゲートウェイ（ルーティングレイヤー）の導入
「既存のSpring BootモノリスにAPIゲートウェイを追加して。最初は全トラフィックをモノリスに転送するだけ。将来的に個別サービスへルーティングできる設計にすること」
Phase 2: 最初のサービス抽出（低リスクから）
「通知（Notification）サービスを最初に抽出して。通知機能は他ドメインへの依存が少なく、失敗しても主要フローに影響が出ない。モノリスとの共存期間（デュアルライト）の設計を含めること」
Phase 3: 段階的なトラフィック移行
「新通知サービスへのトラフィック移行計画を作って。まず内部テスト（0%）→ 5% → 25% → 100% の段階的な移行で。各段階でのロールバック手順も含めること」
CLAUDE.mdに移行ルールを定義しておくと、各ステップで一貫した判断基準を保てる。
## マイクロサービス移行ルール
境界原則
- 1テーブルは必ず1サービスが所有する（共有書き込み禁止）
- サービス間通信はイベント駆動を優先（同期HTTPは最小限に）
- サービス間でのDB共有は禁止（それぞれがDBを持つ）
移行順序
1. 依存グラフで境界を確認してから着手
2. 低リスク・低結合のサービスから開始
3. デュアルライト期間を設けてからモノリスを無効化
4. 各フェーズでロールバック手順を明示
禁止パターン（分散モノリスの兆候）
- 複数サービスが同じテーブルに書き込む
- 同期HTTP呼び出しが3ホップ以上
- サービスAをデプロイするためにサービスBの変更が必要
モジュラーモノリスを選択すべきケース
マイクロサービスへの移行が常に正解ではない。
| 状況 | 推奨アーキテクチャ | 理由 |
|---|---|---|
| チームが5名以下 | モノリス or モジュラーモノリス | マイクロサービスの運用コストがチーム規模に見合わない |
| 要件が頻繁に変わる | モジュラーモノリス | サービス境界が固定されると変更コストが高い |
| 高スケール要件がある特定機能のみ | モジュラーモノリス + 一部マイクロサービス | 必要な部分だけスケールアウト |
| 将来マイクロサービス化を検討 | モジュラーモノリス | 境界を作りながら段階的に移行できる |
Claude Codeに相談するときはシステム状況をまとめて渡すと精度が上がる。
今のシステム状況：
- チーム規模：8名
- 月間リクエスト：50万
- 現状：Spring Bootモノリス、15万行
- 課題：デプロイが週1回になってきた。チームごとに独立してリリースしたい
マイクロサービス移行すべきか、モジュラーモノリス化すべきか、
メリット・デメリットをConwayの法則とチーム規模の観点で分析して。
移行コストの概算（人月）も含めること
Before/After
Before（境界分析なしの移行）
「マイクロサービス化しよう」という意思決定
↓
機能単位（User Service・Order Service）で分割
↓
実は複数サービスが同じOrderテーブルに書き込む
↓
分散モノリスの完成
↓
「マイクロサービスにしたのに、なぜか複雑化した」
After（Claude Code × 境界分析）
依存グラフ生成（Claude Code）
↓
分散モノリスチェック（Claude Code）
↓
低リスク・低結合サービスから開始（Strangler Fig）
↓
デュアルライト期間でモノリスと共存
↓
段階的トラフィック移行（0% → 5% → 100%）
↓
本物のマイクロサービス（テーブル分離・独立デプロイ）
まとめ
マイクロサービス化でしんどい目に遭ったプロジェクトを振り返ると、たいていは「境界の分析が甘かった」か「そもそも境界を引く前に移行を始めた」のどちらかだった。依存グラフを見て循環依存を洗い出す作業は、人間がやると数日かかって嫌になる。Claude Codeがいると、その部分を数時間で終わらせられる。
着手の順番はこれが動きやすいと思う。
今すぐ（15分）：Claude Codeに「このリポジトリの依存グラフをMermaid形式で出力して、循環依存を特定して」と依頼し、現状を可視化する。グラフを見れば「どこから切り出せるか」が一目で分かる。
今日中：依存グラフを見て「分散モノリス状態になっていないか」を「1テーブル=1サービス」の原則でチェックする。違反しているテーブルがあれば、それが最初に解決すべき課題だ。
チーム展開：CLAUDE.mdに「境界原則」と「禁止パターン（分散モノリスの兆候）」を定義し、レビュー時のチェックリストとして使う。「同期HTTP呼び出しが3ホップ以上」「複数サービスが同じテーブルに書き込む」というルールが文書化されていると、レビュー時の議論が具体的になる。
コメント