Claude Codeでマイクロサービスかモノリスかを比較検討する方法

「マイクロサービスにすべきか、モノリスのままでいくか」は、Claude Codeに聞くと一般論が返ってきやすいテーマです。本記事は、AIを「判断材料の整理役」として使い、自分のチームとシステムに即した結論にたどり着くための比較検討の進め方を整理します。

結論：AIには「判断軸の整理」をさせ、結論は人間が出す

モノリスとマイクロサービスの選択に、どんなシステムにも当てはまる正解はありません。チーム規模、運用体制、システムの成熟度によって答えが変わります。Claude Codeに「どちらがいいか」を直接聞くと、文脈を欠いた一般論になります。

正しい使い方は、AIに次をやらせることです。

1. 判断軸を網羅的に出させる：抜けがちな観点を洗い出す
2. 自分の状況を各軸で評価させる：一般論でなく、自分のシステムに当てはめる
3. 移行案を段階的に出させる：「全部マイクロサービス化」のような極端な案を避ける

最終的な構成の決定は人間が行います。設計相談の基本姿勢は「Claude Codeで大規模開発の設計相談をするときの進め方」と同じで、本記事は構成選定に特化した観点を扱います。

判断軸を網羅的に出させる

最初にやるのは、選定の判断軸をAIに洗い出させることです。1つの軸（たとえば「スケーラビリティ」）だけで決めると、運用コストのような重い軸を見落とします。

目的: モノリス vs マイクロサービスの判断軸を網羅する

依頼:
- システム構成を選ぶときの判断軸を、観点別に列挙する
  （開発・運用・組織・データ・コストなど）
- 各軸について「モノリスが有利になりやすい条件」
  「マイクロサービスが有利になりやすい条件」を1行ずつ書く
- どちらがよいかの結論はまだ出さない

禁止事項:
- 「マイクロサービスは現代的」のような価値判断
- 私のシステムを知らないまま推奨を出すこと

軸が出そろってから、自分のシステムを当てはめます。

主要な判断軸の比較

選定でよく効く判断軸を、おおまかに整理すると次のようになります。これはあくまで「傾向」で、最終判断は自分の状況で行います。

注意したいのは、マイクロサービスは「分散システムの運用コスト」を必ず追加で支払う点です。サービス間通信、分散トレーシング、複数デプロイパイプラインの維持は、それ自体が継続的な負担になります。

データ一貫性は最重要の論点

構成選定で最も慎重に扱うべきなのがデータ一貫性です。モノリスでは1つのトランザクションで完結していた処理が、マイクロサービスではサービスをまたぐため、強い整合性を保てなくなります。

Claude Codeには、自分の業務の具体的な処理で検証させます。

依頼:
次の処理をサービス分割した場合に、データ一貫性で
何が問題になるかを具体的に説明する
- 注文確定と在庫引き当てが別サービスになる
- 決済とポイント付与が別サービスになる

各ケースで「どこで不整合が起きうるか」「結果整合性で
許容できるか」「補償処理が必要か」を書く

「決済とポイント付与」のような、業務上ずれてはいけない処理がサービスをまたぐ場合、補償トランザクションやSagaパターンのようなしくみがコストとしてはっきりかかります。これを軽視した分割は、後から大きな技術的負債になります。負債の考え方は「Claude Codeで技術的負債を増やさないリファクタリング計画」も参照してください。

「全部分割」を避け、段階的な案を出させる

モノリスからマイクロサービスへ移る場合、一度に全体を分割するのは最もリスクの高い進め方です。Claude Codeには、段階的な移行案を出させます。

依頼:
現在のモノリスから、いきなり全分割せずに進める
移行案を3段階で出す
- 第1段階: 最初に切り出す候補と、その理由
- 第2段階・第3段階: 次に切り出す範囲
各段階で「切り出さずに残すもの」と「一方通行になる決定」を明記する

最初に切り出す候補は、境界が明確で、他と密に絡んでいない部分を選びます。逆に、データ一貫性が強く求められる中核部分は、モノリスに残す判断も十分に妥当です。「モジュラーモノリス」（モノリスの内部を明確なモジュールに分ける構成）を中間解として検討するのも有効です。

人間が必ず持つべき判断

構成選定は「一方通行のドア」になりやすい決定です。マイクロサービスへ大きく舵を切ったあと、モノリスへ戻すのは多大なコストがかかります。次の判断は、AIの提案をうのみにせず人間が持ちます。

• 分散システムの運用コストを、自分のチームが払い続けられるか
• データ一貫性の要件を、結果整合性で本当に満たせるか
• 組織体制（チーム分割）が構成と噛み合っているか

AIに任せきりにしない判断の線引きは「AIに任せすぎないためのClaude Code運用ルール」にまとめています。構成選定はその典型例です。

チェックリスト

• 判断軸を観点別に網羅させた（開発・運用・組織・データ・コスト）
• 一般論でなく自分のシステムを各軸で評価した
• マイクロサービスの「運用コスト増」を軸に含めた
• データ一貫性を自分の業務処理の具体例で検証した
• 「全部分割」でなく段階的な移行案を出させた
• モジュラーモノリスを中間解として検討した
• 一方通行の決定であることを踏まえ、人間が最終判断した

次に読むおすすめ記事：

• 「Claude Codeで大規模開発の設計相談をするときの進め方」：案出しとトレードオフ比較の進め方
• 「Claude Codeで技術的負債を増やさないリファクタリング計画」：分割が負債化しないための返済計画
• 「AIに任せすぎないためのClaude Code運用ルール」：構成判断を人間が持つためのゲート設計