結論：モノリスの分割は「一気に全部書き直す」のではなく、Claude Codeに読み取り専用の権限で依存関係マップと境界候補を洗い出させ、Strangler Figパターン（AWS・Microsoft公式が提唱する段階移行手法）で新旧を共存させながら、書き込み権限をpermissions.denyとhooksで物理的に分離すると、障害リスクを抑えたまま段階的に進められます（想定シナリオ）。
- 要点1：依存関係マップをClaude Codeに読み取り専用で作らせることで、切り出し候補の優先順位づけにかかる調査工数を圧縮できる余地があります（試算）
- 要点2：
permissions.denyとPreToolUseフックの二重設計で、Claude Codeにレガシー本体への書き込み権限を渡さずに新サービスの実装だけを並行させられます - 要点3：AWS・Microsoftが公式に整理するTransform→Coexist→Eliminateの3フェーズに沿えば、ロールバック可能な単位で切り出しを進められます
対象読者：モノリシックなアプリケーションのスケール限界に直面しているテックリード・エンジニアリングマネージャー・PM
今日やること：直近3ヶ月のhotfixがどのモジュールに集中しているかを一覧化し、切り出し優先度の仮説を1つ立ててみましょう
動作環境：Ruby on Rails 7.1、コード行数約42万行、Sidekiqジョブ180種類超、単一のPostgreSQLデータベース、エンジニア14名、Claude Code + VS Code拡張という構成を想定シナリオとして置きます。
失敗ログから：ある金曜の夕方、決済導線の1行だけを直したいhotfixが、本体の統合テストスイート（52分）の完走待ちで詰まり、障害復旧までに3時間かかった——というのが本記事の出発点です（想定シナリオ）。原因を遡ると、決済ロジックが在庫管理・通知・レポーティングの各モジュールと密結合していて、「1行の修正」のつもりが全体テストの対象になっていたことでした。
この記事では、モノリスを一気に書き直すのではなく、Strangler Figパターン（AWS Prescriptive GuidanceとAzure Architecture Centerが公式に整理する段階分割手法）に沿って、Claude Codeに依存関係の可視化と境界候補の抽出を任せ、書き込み権限を意図的に絞りながら段階的にマイクロサービス化を進める手順を、設定ファイルの例付きで解説します。
なぜ今、モノリス分割が必要になるのか
単一のコードベースにすべての機能を詰め込む「モノリス」構成は、チームが小さいうちは開発速度が最も速い選択肢です。問題が表面化するのは、コード量・機能数・エンジニア数が増えたタイミングです。典型的な兆候として、次のようなものが挙げられます。
- hotfix 1件のデプロイに、無関係なモジュールを含む統合テストスイート全体の完走を待つ必要がある
- 特定の機能（決済・在庫・通知など）だけスケールさせたいのに、アプリケーション全体を水平スケールさせるしかない
- 新しいエンジニアがコードベース全体の依存関係を把握するまでに数週間かかる
- 1つのモジュールの障害が、無関係な機能まで巻き込んでダウンさせる
これらの兆候が複数当てはまる場合、モノリスの一部をマイクロサービスとして切り出す検討に入るタイミングだと考えられます。ただし、分割そのものが目的化すると、単に複雑さを別の場所に移しただけになるリスクもあります。次章で整理するStrangler Figパターンは、この「移しただけ」を避けるための段階的な設計です。
Strangler Figパターンとは
Strangler Fig（絞め殺しの木）パターンは、レガシーシステムを一気に置き換えるのではなく、既存システムを稼働させたまま新しい仕組みを少しずつ被せていく移行手法です。AWS Prescriptive Guidanceは、このパターンを3つのフェーズに整理しています。
- Transform：モダン化する対象コンポーネントを特定し、既存アプリケーションと並行して移植・再実装する
- Coexist：モノリスをロールバック用に残したまま、API Gatewayなどのプロキシで外部からのリクエストを新旧に振り分ける
- Eliminate：トラフィックが新サービスへ移り切った機能について、モノリス側の旧機能を退役させる
Azure Architecture Centerも同様に、クライアントとレガシー・新システムの間にfaçade（プロキシ）を挟み、新旧を切り替え可能な状態に保つ設計を公式に解説しています。ポイントは「移行の途中でも常にロールバックできる」ことで、これは大規模書き換えにありがちな「元に戻せない巨大PR」のリスクを避ける仕組みでもあります（出典は本文末に記載）。
Claude Codeに任せた5つの役割
Strangler Figの3フェーズを実務に落とし込むと、Claude Codeに任せられる作業は次の5つに整理できます。
- 依存関係マップの作成 — import/require文、DBテーブルの参照範囲、内部API呼び出しを洗い出し、モジュール間の結合度を可視化する。この段階ではRead/Grep/Globだけを許可した読み取り専用のsubagentに任せ、コードへの書き込みは一切させない
- ドメイン境界候補の抽出 — 依存関係マップをもとに、循環依存が少なく切り出しやすい機能単位（bounded context）の候補に優先順位をつける
- façade（プロキシ）の実装 — 新旧トラフィックを振り分けるルーティング層のコードを生成する。最初はごく単純な条件分岐でよく、機能フラグと組み合わせて段階的に比率を上げていく設計にする
- 書き込み範囲の分離 — settings.jsonの
permissions.denyとPreToolUseフックで、レガシー本体への書き込みを禁止し、新サービスのディレクトリだけ書き込みを許可する - 退役（Eliminate）支援 — トラフィックが新サービスへ移行し切った機能について、モノリス側のデッドコードを検出し、削除PRの下書きを作成する
切り出したロジックそのものが技術的負債化している場合は、技術的負債を返済する実践ガイドの手順を先に適用してからマイクロサービス化する方が、切り出し後の保守性が上がります。
実装スタック
- Claude Code（依存関係分析用subagent + façade実装用のメインセッションを分離）
- settings.jsonの
permissions（allow / ask / deny） - PreToolUseフック（書き込み系コマンドの動的な許可・拒否判定）
- git worktree（サービスごとに独立した作業ツリーで並行実装。詳細はgit worktree並列開発ガイドを参照）
- API Gateway相当のプロキシ層（言語・フレームワークは問わない。既存インフラのロードバランサ/リバースプロキシで代替可能なことが多い）
手順1〜2：依存関係マップと境界候補の抽出
最初にやるべきは、依存関係マップの作成をClaude Codeの読み取り専用subagentに任せることです。Claude Codeの公式ドキュメントでは、subagentごとに使えるツールを制限できる（Enforce constraints by limiting which tools a subagent can use）ことが明記されています。分析専用のsubagentにはRead / Grep / Globのみを与え、Edit・Write・Bashは持たせません。
// .claude/agents/dependency-mapper.md（例）
---
name: dependency-mapper
description: モジュール間の依存関係を読み取り専用で調査する
tools: Read, Grep, Glob
---
コードベースのimport/require、DBテーブル参照、内部API呼び出しを
一覧化し、モジュールごとの結合度をレポートしてください。
ファイルの編集・実行は行わないでください。
このsubagentが出す依存関係マップをもとに、循環依存が少なく、DBテーブルの専有範囲が明確なモジュールから切り出し候補の優先順位をつけます。優先順位づけの基準として、AWS Prescriptive Guidanceは「他モジュールからの参照が少なく、独立したデータストアを持てる機能」を最初のTransform対象に選ぶことを推奨しています。
手順3〜4：façade実装と書き込み範囲の分離
切り出し対象が決まったら、façade（プロキシ）層の実装に入ります。最初の実装はシンプルな条件分岐で十分です。
// façadeの最小実装イメージ（擬似コード）
function routeRequest(req) {
if (featureFlags.useNewInventoryService && req.path.startsWith('/inventory')) {
return proxyTo(newInventoryService, req);
}
return proxyTo(legacyMonolith, req); // Coexistフェーズ：既存経路を必ず残す
}
ここで重要なのが、Claude Codeにこのfaçadeと新サービスのコードを書かせる間、レガシー本体には一切書き込ませないことです。Claude Code公式ドキュメントのSettings（permissions）に沿って、次のようにdeny/allowを設定します。
{
"permissions": {
"allow": [
"Write(./services/inventory-service/**)",
"Edit(./services/inventory-service/**)",
"Write(./gateway/**)"
],
"deny": [
"Write(./legacy-monolith/**)",
"Edit(./legacy-monolith/app/models/inventory/**)"
],
"ask": [
"Bash(rails db:migrate*)"
]
}
}
さらにPreToolUseフックを組み合わせると、コマンドの内容を見て動的に判断できます。たとえば「新サービスのディレクトリ外へのファイル作成を検知したら拒否する」といったチェックを、settings.jsonの静的ルールに加えて二重で敷けます。権限設計の詳細な考え方はClaude Code権限設計ガイドにまとめています。
手順5：Eliminate（退役）とデッドコード検出
新サービスへのトラフィック比率が100%に達し、一定期間ロールバックが発生しなかった機能から、モノリス側の旧実装を退役させます。この工程でもClaude Codeは有効で、「新サービスに移行済みの機能に対応するモノリス側のコードで、直近90日間呼び出しログが0件のものを一覧化する」といった調査から着手すると安全です。実際の削除作業はデッドコード・未使用コードの削除ガイドの手順に沿って、テストカバレッジと呼び出しログの両方を確認してから進めます。
なお、コードそのものは新しくても内部ロジックが古い設計思想を引きずっている場合は、切り出し前にレガシーコード移行の自動化手順を参考に、まずリファクタリングだけを済ませておくと、façade実装の見通しが良くなります。データベースを分割する段階まで進む場合はDBマイグレーションの実践ガイドも合わせて参照してください。
【要注意】よくある失敗パターンと回避策
❌ 失敗1：境界を決めずに切り出しを始める
思いつきで「よさそうな機能」から手を付けると、他モジュールとの参照が後から見つかり、結局モノリスに逆戻りするケースが多く報告されています。
⭕ 依存関係マップで循環依存の少ないモジュールを先に可視化し、優先順位を決めてから着手する。
❌ 失敗2：Claude Codeにレガシー本体への書き込み権限を渡したまま並行作業させる
新サービスの実装と同時にレガシー側も自由に編集できる状態だと、意図しない結合が再発するリスクがあります。
⭕ permissions.denyでレガシー本体への書き込みを塞ぎ、新サービスのディレクトリだけを許可する。
❌ 失敗3：一度に複数ドメインを同時に切り出そうとする
複数機能を並行して切り出すと、façadeの条件分岐が複雑化し、ロールバック可能な単位を超えてしまいます。
⭕ Strangler Figの原則どおり1機能ずつCoexistさせ、常にロールバック可能な粒度に保つ。
❌ 失敗4：Eliminate（退役）判定を人の記憶だけに頼る
「もう使っていないはず」という感覚だけで削除すると、想定外の呼び出し経路が残っていて障害になることがあります。
⭕ トラフィック監視ログとデッドコード検出をセットで運用し、呼び出しゼロを機械的に確認してから削除する。
段階的導入のロードマップ
Phase 1（1〜2ヶ月）：読み取り専用subagentで依存関係マップを作成し、切り出し候補を1〜2個に絞ってPoCのfaçadeを実装する。
Phase 2（3〜4ヶ月）：PoCで得た知見をもとにpermissions/hooksの設計を標準化し、2〜3機能を並行してCoexistフェーズに進める。
Phase 3（5〜8ヶ月）：トラフィック移行が完了した機能からEliminateを進め、モノリス側のデッドコード検出を定期運用に組み込む。
想定効果（試算）
| 指標 | 分割前 | 分割後（想定） | 変化 |
|---|---|---|---|
| デプロイ頻度 | 週1回 | 対象サービスは1日2〜3回 | 試算 |
| hotfix対応のリードタイム | 平均3時間 | 平均25分 | -86%（試算） |
| 新機能リリースまでの期間 | 平均3週間 | 平均5営業日 | -76%（試算） |
| 該当機能のテスト実行時間 | 52分（全体スイート） | 6分（対象サービスのみ） | 試算 |
※上記はすべて想定シナリオに基づく試算値です。実際の効果は依存関係の複雑さ・チーム体制・切り出し対象の選定によって大きく変わります。
適用余地のある業種・規模
「hotfixのたびに無関係なモジュールのテストを待たされる」「特定機能だけスケールさせたいのに全体を水平スケールするしかない」という構図は、業種を問わず、コード行数20万行超・エンジニア10名以上の規模から現実的な検討課題になりやすいと考えられます。EC・金融・SaaSなど、機能追加の頻度が高く24時間稼働が前提のサービスほど、Coexistフェーズでのロールバック可能性が重要になります。
内部リンク：関連事例・参考記事
- レガシーコード移行をClaude Codeで自動化する手順 — 切り出し前のリファクタリングの参考になります
- Claude Codeで技術的負債を返済する実践ガイド
- デッドコード・未使用コードの削除をClaude Codeで安全に
- Claude Code権限設計ガイド
- DBマイグレーションをClaude Codeで安全に進める実践ガイド
- Claude Code × git worktree 並列開発ガイド
まとめ：今日から始める3つのアクション
- 今日やること：直近3ヶ月のhotfixログを見て、どのモジュールに修正が集中しているかを一覧化する
- 今週中：読み取り専用subagentを1つ作り、そのモジュール周辺の依存関係マップを出力させてみる
- 今月中：
permissions.denyでレガシー本体への書き込みを塞いだ状態で、façadeのPoCを1つ実装してみる
正直にお伝えすると、この設計はまだ発展途上の考え方です。切り出しの境界の引き方はドメインごとに正解が異なりますし、façadeの障害がシステム全体の単一障害点にならないような冗長化も別途必要です。だからこそ「AIに丸投げ」ではなく、依存関係の可視化と定型的なコード生成をClaude Codeに任せ、境界設計そのものの最終判断はアーキテクトやテックリードが行う「AIと協業」の設計が重要だと考えています。
次回予告：次の記事では、Strangler Fig façadeそのものをどこまでClaude Codeの非対話モード（headless）でCI連携し、依存関係マップの再生成を自動化できるかを検証する予定です。
FAQ
- Q: Claude Codeはモノリスの依存関係分析にそのまま使えますか？
- import/require文やDBテーブル参照の洗い出しといった読み取り中心の分析であれば、Read・Grep・Globのみを許可した読み取り専用のsubagentを作ることで、コードを一切変更せずに依存関係マップを作成できます。
- Q: マイクロサービス化は必ずStrangler Figパターンで進めるべきですか？
- 唯一の正解ではありませんが、AWS Prescriptive GuidanceやAzure Architecture Centerが公式に整理している段階移行手法であり、既存システムを稼働させたままロールバック可能な単位で進められる点で、多くのケースで有力な選択肢です。チームの状況によっては他の分割パターンが適する場合もあります。
- Q: Claude Codeにレガシー本体への書き込み権限を与えても大丈夫ですか？
- 推奨しません。settings.jsonのpermissions.denyで書き込み範囲を新サービスのディレクトリだけに絞り、PreToolUseフックで動的なチェックを重ねる二重の安全設計にすることで、意図しない編集がレガシー本体に及ぶリスクを減らせます。
- Q: 本記事の数値・手順は実在する企業の事例ですか？
- 本記事の環境設定・数値・コード例はすべて想定シナリオ（モデルケース）です。特定の実在企業の事例ではなく、AWS・Microsoftが公式に整理する分割パターンをもとに、一般化した実装イメージとして構成しています。
- Q: モノリス分割はどんな規模・業種のチームに向いていますか？
- コード行数20万行超・エンジニア10名以上の規模になり、hotfixのたびに無関係なモジュールのテストを待たされるような兆候が出てきたチームで検討価値が高いと考えられます。業種は問いませんが、機能追加の頻度が高く常時稼働が前提のサービスほど効果を実感しやすい傾向があります。
- Q: hooksとpermissionsを両方設定する必要がありますか？
- 必須ではありませんが、二重にしておくことを推奨します。permissionsはsettings.jsonのallow/ask/denyルールで実行可否を宣言的に設定するものです。hooksはPreToolUseなどのイベントごとに動的なチェックを実行できるため、静的ルールだけでは拾いきれないケースをカバーできます。
参考・出典
- AWS Prescriptive Guidance「Strangler fig pattern」（Transform/Coexist/Eliminateの3フェーズを公式解説。参照日: 2026-07-09）
- AWS Prescriptive Guidance「Decomposing monoliths into microservices」（参照日: 2026-07-09）
- Azure Architecture Center「Strangler Fig pattern」（façade/プロキシによる新旧振り分け設計を公式解説。参照日: 2026-07-09）
- Claude Code公式ドキュメント：Create custom subagents（参照日: 2026-07-09）
- Claude Code公式ドキュメント：Settings（permissions構文）（参照日: 2026-07-09）
- Claude Code公式ドキュメント：Hooks reference（参照日: 2026-07-09）
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（@SuguruKun_ai）で活用法を発信（フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
Claude Code 個別指導・業界別DX導入支援
依存関係の可視化からpermissions/hooksの安全設計まで、モノリス分割の伴走をUravationが行います。ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
