なぜ今、AIエージェントでシステム刷新なのか — 3エージェント連携の全体像
はじめに
「このモノリス、マイクロサービスに分割したいんだけど、まず何からやればいい？」
レガシーシステムの刷新プロジェクトに関わったエンジニアなら、この問いに何度もぶつかったことがあるはずです。現状の調査、DDD（ドメイン駆動設計）に基づく分析と評価、新アーキテクチャの設計、そして実装計画の策定——これらを一つずつ進めるのは膨大な作業であり、専門知識も求められます。
この連載では、3つのAIエージェントを活用して、レガシーシステムの分析から DDD ベースの再設計、そして ScalarDB を使った新システムの実装計画策定までを一貫して行うワークフローを紹介します。
3つのエージェントはいずれも Claude Code のスキルシステム上に構築されており、GitHub で公開しています。
- Refactoring Agent for Claude Code — 現状分析・評価
- Architecture Redesign Agent — DDD再設計・コード生成
- Coding Agent for ScalarDB — 実装計画・レビュー
レガシーシステム刷新の「壁」
レガシーシステムの刷新が難しいのには、いくつかの構造的な理由があります。
1. 分析フェーズの膨大さ
リファクタリングの最初のステップは「現状を知ること」ですが、これだけでも多くの作業が発生します。
- 技術スタックの調査
- パッケージ構造の把握
- ドメイン用語の抽出（ユビキタス言語の整理）
- エンティティ間の関係マッピング
- モジュールの成熟度評価
これらは定型的でありながら網羅性が求められるタスクです。人間がやると漏れが出やすく、プロジェクトごとに車輪の再発明になりがちです。
2. DDD の専門知識の属人化
DDD の戦略的設計（境界コンテキスト、コンテキストマップ）や戦術的設計（エンティティ、値オブジェクト、集約）には、多くのベストプラクティスがあります。しかし、それらの知見をプロジェクトに適用するには専門知識が必要で、属人化しやすい領域です。
3. 設計と実装の断絶
アーキテクチャ設計が完了しても、それを実装に落とし込む段階で情報が失われたり、設計意図が伝わらなかったりすることがよくあります。設計ドキュメントと実装コードの間に大きなギャップが生じるのです。
3つのエージェントは、これらの壁をそれぞれのステージで突破します。
3つのエージェントとその役割
┌──────────────────────────────────────────────────────────────────┐
│ レガシーシステム刷新パイプライン │
│ │
│ ┌─────────────┐ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Refactoring │ │ Architecture │ │ Coding │ │
│ │ Agent │───→│ Redesign Agent │───→│ Agent for │ │
│ │ (18スキル) │ │ (37スキル) │ │ ScalarDB │ │
│ └─────────────┘ └─────────────────┘ │ (10エージェント) │ │
│ └─────────────────┘ │
│ 現状分析・評価 DDD再設計・コード生成 実装計画・レビュー │
└──────────────────────────────────────────────────────────────────┘
1. Refactoring Agent — 既存システムの「今」を可視化する
18スキル | 分析と設計まで | コード生成なし
レガシーコードベースを入力として受け取り、技術スタック、パッケージ構造、ドメイン用語、モジュールの成熟度（MMI: Modularity Maturity Index）を分析します。
# メインコマンド
/refactor-system-cmd ./legacy-project
| カテゴリ | 主要スキル |
|---|---|
| 分析 |
/analyze-system, /evaluate-mmi, /map-domains
|
| 設計 |
/design-microservices, /design-api, /design-scalardb
|
| ナレッジグラフ |
/build-graph, /query-graph, /visualize-graph
|
| ユーティリティ |
/compile-report, /render-mermaid, /fix-mermaid
|
Serena MCP と連携してJavaコードのAST（抽象構文木）レベル解析を行えるのが特徴です。単なるテキスト検索ではなく、クラスの定義やメソッドの参照関係を構造的に追跡できます。
2. Architecture Redesign Agent — DDDに基づいてシステムを再設計する
37スキル | Refactoring Agent の全機能 + α | コード生成あり
Refactoring Agent の進化版で、以下の機能が追加されています：
- DDD適合度評価（戦略的設計 + 戦術的設計の両面）
- セキュリティ分析（OWASP Top 10、ゼロトラスト準備度）
- Spring Boot + ScalarDB のコード自動生成
- Kubernetes / Terraform のインフラ設計
- BDDテスト仕様の生成
-
対話的ワークフロー選択（
/workflow）
# 3つの実行モード
/workflow ./legacy-project # 対話的に選択（推奨）
/full-pipeline ./legacy-project # 全13フェーズ一括実行
/refactor-system ./legacy-project # 分析・設計のみ（v1互換）
13フェーズ・26以上のサブフェーズから成るパイプラインを実行し、70以上のMarkdownドキュメントと実装可能なコードを生成します。
3. Coding Agent for ScalarDB — 実装ロードマップを策定する
10エージェント（3実行 + 5レビュー + 1統合 + 1管理） | 4フェーズ・13ステップ
上流の2つのエージェントが出したアーキテクチャ上の意思決定を受け取り、ScalarDB を使ったマイクロサービスの実装計画を策定します。
/plan # ワークフロー管理・進捗確認
/plan-step 01 # ステップ01（要件分析）を実行
/plan-review phase1 # フェーズ1を5観点で並列レビュー
/plan-review final # 最終GO/NO-GO判定
最大の特徴は 組み込みレビューシステム です。各フェーズ完了時に、5つの異なる観点（整合性、ScalarDB適合性、運用性、セキュリティ、実装可能性）から並列レビューを実行し、PASS / CONDITIONAL PASS / FAIL の判定を行います。最終的にはクロスフェーズの整合性検証を経て GO / NO-GO の判定が下されます。
さらに、ScalarDB の基礎からパターン、比較まで 16の調査ドキュメント が事前に組み込まれており、エージェントが設計判断を行う際の知識ベースとして機能します。
なぜ3つに分かれているのか
「1つのエージェントで全部やればいいのでは？」——当然の疑問です。分割した理由は3つあります。
1. 関心の分離（Separation of Concerns）
レガシー分析、アーキテクチャ設計、実装計画策定はそれぞれ異なる専門知識を必要とします。1つのエージェントにすべてを詰め込むと、スキルファイルが肥大化し、LLMが指示を混同するリスクが高まります。ソフトウェア設計の「単一責任原則」は、エージェント設計にも適用できるのです。
2. 柔軟な組み合わせ
プロジェクトの状況に応じて、使うエージェントを選べます。
| シナリオ | 使用するエージェント |
|---|---|
| まず現状把握だけしたい | Refactoring Agent のみ |
| 分析からコード生成まで一気に | Architecture Redesign Agent のみ |
| アーキテクチャは決まっている。ScalarDB の実装計画が欲しい | Coding Agent for ScalarDB のみ |
| レガシーシステムをゼロから刷新したい | 3つすべて |
3. コンテキストウィンドウの効率的な活用
LLMには一度に処理できるテキスト量の上限があります。ステージごとにエージェントを分けることで、各エージェントが自分の担当範囲に集中でき、コンテキストを効率的に使えます。前ステージの成果物はファイル経由で受け渡すため、コンテキストの引き継ぎも問題ありません。
3エージェント連携の全体ワークフロー
レガシーコードベース（Java / Spring Boot）
│
▼
┌──────────────────────────────────────────┐
│ Stage 1: 現状分析（Refactoring Agent） │
│ │
│ ・技術スタック調査 │
│ ・ドメイン用語抽出（ユビキタス言語） │
│ ・MMI モジュール成熟度評価 │
│ ・マイクロサービス分割案 │
│ ・ナレッジグラフ構築 │
│ │
│ 出力: reports/ + knowledge.ryugraph │
└──────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────┐
│ Stage 2: DDD再設計（Architecture Redesign Agent） │
│ │
│ ・Stage 1の分析結果を読み込み │
│ ・DDD適合度評価（戦略 + 戦術） │
│ ・境界コンテキストの再定義 │
│ ・マイクロサービスアーキテクチャ設計 │
│ ・ScalarDB スキーマ設計 │
│ ・Spring Boot + ScalarDB コード生成 │
│ ・Kubernetes / Terraform インフラ設計 │
│ │
│ 出力: reports/ + generated/ + インフラ設計 │
└──────────┬───────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ Stage 3: 実装計画（Coding Agent for ScalarDB） │
│ │
│ Phase 1: 要件分析・ドメインモデリング・ScalarDBスコープ │
│ Phase 2: データモデル・トランザクション・API設計 │
│ Phase 3: インフラ・セキュリティ・可観測性・DR設計 │
│ Phase 4: 実装ガイド・テスト戦略・デプロイ計画 │
│ │
│ 各フェーズ完了時: 5観点並列レビュー │
│ 全フェーズ完了時: 最終GO/NO-GO判定 │
│ │
│ 出力: 13ドキュメント + レビューレポート │
└──────────────────────────────────────────────────────┘
│
▼
実装可能な設計書一式
（エンジニアリングチームが即座に着手可能）
連載の構成
| 回 | タイトル | 内容 |
|---|---|---|
| 第1回（本記事） | 3エージェント連携の全体像 | 背景・動機・3つのエージェントの役割・ワークフロー |
| 第2回 | 現状分析 — Refactoring Agent | セットアップ、/refactor-system-cmd の実行、出力の読み方 |
| 第3回 | DDD再設計 — Architecture Redesign Agent | 評価フェーズ、境界コンテキスト設計、コード生成 |
| 第4回 | 実装計画 — Coding Agent for ScalarDB | 13ステップワークフロー、レビューシステム、GO/NO-GO判定 |
| 第5回 | 実践ガイド — 3エージェント連携のTipsと応用 | ハマりポイント、大規模対応、カスタムスキルの追加 |
次回は、Refactoring Agent を使ってレガシーシステムの現状分析を行う手順を解説します。
深津 航 / 株式会社Scalar CEO / AI時代のアーキテクチャ、データマネジメントを試行錯誤中
Discussion