【20260212 AI×DevOpsStudy #5】Claude Code によるリファクタリング（1/2）：現行システムの分析と評価の方法

■AI×DevOps Study #5 の概要
2026年2月12日に開催した「AI×DevOps Study」第5回の勉強会資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「Claude Code によるリファクタリング（1/2）：現行システムの分析と評価の方法」

レガシーシステムは、様々な人により改修が繰り返されており、コードの見通しが悪くなり、技術負債が蓄積されていることが多いのが実態です。これを調査して、改善点を洗い出すにも、人手がかかるため、分析が行われずリスクを抱えたシステムが多数運用されています。.

このような企業内に散在するEUCシステムやレガシーなシステムの調査をAIエージェントを用いて行うことで、人の主観によらない客観的な分析を実現することができます。.

本セッションでは、株式会社Scalarでどのように現行システム分析を行い課題の洗い出しを行い、システムの課題を解決していっているのかを2回に渡ってお話しします。 1回目は、現行システムの分析と評価を Claude Code を使って現行システムを分析し、評価する方法をお話しします。

Claude Code とカスタムエージェント（スキル）の基礎
Serena MCP を使った効率的なコード分析手法
デモ：レガシーEC サイトの分析
デモプロジェクトの技術的負債の可視化（MMI スコア30/100 → 85/100への改善予測）

■登壇者情報（敬称略）
深津航
株式会社Scalar Founder & CEO。日本オラクル株式会社、決済系のスタートアップを経て、株式会社Scalarを創業。

■勉強会動画
Claude Code によるリファクタリング（1/2）：現行システムの分析と評価の方法【20260212 AI×DevOpsStudy #5】
https://www.youtube.com/watch?v=FSny8OVw3WY

Transcript

1. Claude Code によるリファクタリング#1 現⾏システムの分析と評価の⽅法 2026/02/12 株式会社Scalar CEO 深津 航
2. ⾃⼰紹介 名前：深津航 所属：株式会社Scalar CEO, Co-Founder 主な関⼼事項 • ⽇本のIT強化 • アーキテクチャ/設計 • DevSecOps, FinOps • AIが与える各種業界へのインパクト ◦ 個⼈的には、Moltbookが⾯⽩い LinkedIn: https://www.linkedin.com/in/wataru-fukatsu-1692655/ 2
 ▪ IPAの専⾨委員としての活動 DADCの専⾨委員としても活動しています。 ▪ 株式会社 Scalar としての活動 株式会社Scalarは、分散トランザクションマネー ジャーのScalarDBと改ざん検知ソフトウェアの ScalarDLを展開中。マイクロサービス化におけるシ ステムの課題やAIなどのデータ基盤の信頼性を担保 するソリューションを展開しています。 ソフトウェア開発、システム開発、マーケティン グ、営業、経営など様々な役割で活動中。
3. レガシーシステムの現状と課題 3 レガシーシステムを維持することのリスク
4. 2024年度のレガシーシステムの現状 4
 2025年6月26日 独立行政法人情報処理推進機構『 DX動向2025（データ集）』より 62.7% わからないまでを含めると 79.5%
5. レガシーシステムを維持することのリスク 5
 • 経済損失の“最⼤”試算：最⼤ 約12兆円∕年 ◦ 基幹系が21年以上稼働のシステムが、2025年に60%との予測もある。 • データ活⽤‧全社最適を阻害（＝DXが進まない） ◦ 全社横断のデータ活⽤ができない∕過剰カスタマイズで複雑化‧ブラックボックス化 ◦ データ資産を多く保有していても連携が難しく活⽤しきれていない ◦ AI等を⼊れても企業データ活⽤が限定的で効果が限定 • 維持費‧運⽤保守に吸われ「攻めの投資」ができない ◦ IT予算の9割以上が維持管理費 ◦ 短期最適の結果として⻑期の運⽤保守費が⾼騰している • セキュリティ‧障害‧災害時リスク ◦ サイバーセキュリティ∕事故‧災害によるトラブル∕データ滅失‧流出リスクも⽇々増⼤ 平成30年9月7日 経済産業省『DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～』より
6. なぜモダナイゼーションがうまくいかないのか 6
 ブラックボックス化＋ 「現⾏踏襲」志向 経営改⾰（業務改⾰）と ⼀体で、現場抵抗が⼤きい 体制‧ガバナンス不⾜ ∕丸投げ構造 ⼈材不⾜（特に上流）で詰まる 供給は需要の 66% 過剰なアドオン、カスタマイズの積み重ねによる ブラックボックス化が発⽣し、改修が難しくなっていく データ活⽤のためには既存システム問題の解決だけでなく、 業務⾃体の⾒直し（＝経営改⾰）が必要で、現場サイドの抵抗が⼤きい 外注に依存しており、意思決定するための CxO が設置されていない このため、業務に即した意思決定を迅速に⾏うことができない ビジネス/ITアーキテクトやデータサイエンティスト等の上流⼈材が不⾜ 産業全体で供給が需要の66%の充⾜率に留まる 多くのレガシーシステムは、巨⼤なモノリス、モジュラーモノリスになっていることが多く 1つの変更が全体に及んでしまう、また、度重なる外注による開発によって、ブラックボックス 化しており、どこから⼿を付ければ良いかが判断が付かない状態になっている。
7. 解決のための道のり 7
 全⾯刷新を捨て、リファクタリングを⾏い 段階的に再設計していくことで、早く成果を得ることが可能になる ブラックボックスを可視化する 「機能」ではなく 「ドメイン」で分離する データ整合性を「中央集 権」ではなく「トランザク ション設計」で担保する 内製化し業務とシステムを ⼀致させる 現⾏システムを解析し、現⾏仕様 を明らかにし、技術負債を可視化 する。設計書とコードが乖離して いることも多いため、コードを正 として、設計書を補助として整理 する。 業務をドメインで整理し、業務の 変更とシステムの変更を⼀体化さ せる。業務の変更＝システムのド メインの修正になるようにしま す。これによって柔軟な改修が可 能になります。 業務間のデータの整合性をモノリ スなデータベースではなく、トラ ンザクション設計で担保すること で、ドメイン間の影響を最⼩化す る。 外注し続ける限り、業務とシステ ムの乖離が発⽣します。このた め、アーキテクチャや設計は内製 化し、作業を外注する戦略に変え る必要があります。 AIを使うことで、⾼速かつ低コストで実現可能 ScalarDBで実現可能 AIとSESで対応可能
8. 本⽇のお話 これらの課題に対して、本⽇は以下のお話をします。 8
 ブラックボックスを可視化する 「機能」ではなく 「ドメイン」で分離する データ整合性を「中央集 権」ではなく「トランザク ション設計」で担保する 内製化し業務とシステムを ⼀致させる Claude Code による リファクタリング #1 現⾏システムの分析 と評価の⽅法ç Claude Code による リファクタリング #2 実装計画の策定⽅法
9. 良いアーキテクチャとは何か？ 9 良いアーキテクチャ =「変化に強く、意図が明確で、壊れ方がコントロールできる構造」
10. アーキテクチャと設計と実装の違い 10
 多くのレガシーシステムを見ていると、アーキテクチャをなんとなく決めているケースが多い アーキテクチャ 組織 設計 実装 「何をどういう構造で作るか」という“⾻格” 「どう具体化するか」という“⾁付け” 「実際に動くコード」という”実態” 「どう運営するか」という“体制”
11. アーキテクチャの責務 11
 アーキテクチャの責務 「将来の変化に耐えられるか」の決定 • 非機能要件を担保する ◦ 可用性 ◦ スケーラビリティ ◦ セキュリティ ◦ データ整合性 • 組織構造と整合する（コンウェイの法則） 設計の責務 「今の要求をどう美しく満たすか」の決定 • 可読性 • 保守性 • 再利用性 • バグを生まない構造 コンウェイの法則に⽰されるように、アーキテクチャはそれを実装‧運⽤する組織に左右されます。この ため、アーキテクチャを保つには、逆コンウェイの法則のように、組織をアーキテクチャに合わせるなど の⼿段が必要になります。 常に変化が求められる現代においては、従来のモノリスやモジュラーモノリスのようなアー キテクチャは、ビジネス組織との乖離が起きるため、マイクロサービスのようなアーキテク チャが求められてきています。
12. 良いアーキテクチャとは何か？ 12
 良いアーキテクチャ = 「変化に強く、意図が明確で、壊れ方がコントロールできる構造」 変化に強い （Evolvable） 意図が明確 （Explainable） 負債を制御できる （Sustainable） • 要件が変わっても壊れない • 組織が変わってもスケールできる • 技術が変わっても置き換え可能 良いアーキテクチャは、説明することがで きる。 • なぜこの構成なのか？ • なぜこのTx戦略なのか？ • なぜこの分割なのか？ どこに技術負債があるかわかっている。 • 暫定実装がどこか • 将来リファクタ予定箇所 • スケールボトルネック ビジネスと整合している （Strategic） 観測可能 （Observable） 壊れ⽅が美しい （Graceful Degradation） 良いアーキテクチャは、企業戦略の延長線 上にある。 • 金融基幹なのに結果整合性のみ → 危険 • AIプロダクトなのにデータ統制が弱い → 将来崩壊 良いアーキテクチャは、観測できる。 • ログ • メトリクス • トレース • 相関ID 良いアーキテクチャは、壊れることを想定 している。 • 部分停止しても全停止しない • リトライ戦略がある • データ整合性の回復手段がある
13. 良いアーキテクチャの評価基準 13
 観点 良い状態 悪い状態 ビジネスへの影響 変化耐性（Evolvability） 要件変更に局所対応できる / 疎結合 1箇所変更で全体に波及 変更コスト増大、リリース遅延 境界の明確性（Bounded Context） ドメイン責務が明確 責務が混在、巨大モジュール化 組織摩擦、属人化 データ所有権 データオーナーが明確 共有DB依存 改修時の衝突・事故 トランザクション戦略 一貫性モデルが明示（ ACID / Saga等） 暗黙的整合性 データ不整合、監査リスク 観測性（Observability） 相関ID・ログ・トレース完備 障害原因が特定不能 MTTR増大、信頼低下 スケーラビリティ 水平分離・独立スケール可能 モノリシック依存 負荷増で停止 技術選定の合理性 意図と根拠が説明可能 流行・好み 長期保守コスト増 負債管理 負債が可視化・管理されている 不明瞭・放置 将来爆発 セキュリティ/統制 設計段階で組込み 後付け対策 法規制違反リスク 障害時の設計 部分停止可能、補償あり 全停止 事業停止リスク ビジネス整合性 戦略と整合 技術主導 投資対効果低下 構造 データ 運⽤ 組織 経営 境界が正しく 引かれている 主権と整合性モデルが 明確 観測可能で制御可能 チーム構造と⼀致 戦略と整合し 投資効率が⾼い
14. レガシーシステムの分析 14 巨大な技術負債を可視化していくには？
15. レガシーシステムの調査費⽤の実態 15
 # 調査手法 主な内容 期間目安 費用目安 精度 向いているケース 1 ドキュメント・ヒアリング型 既存資料レビュー、キーパーソンヒアリング、構成図再 作成 1〜2ヶ月 200万〜800万円 ★★☆☆☆ 初期スコープ把握 2 ソースコード静的解析 依存関係抽出、複雑度分析、技術負債測定 1〜3ヶ月 500万〜2000万円 ★★★★☆ コードが唯一の真実 3 動的解析・トレース 実行ログ解析、トランザクション追跡 1〜2ヶ月 500万〜1500万円 ★★★★☆ 実態把握が必要 4 データアセスメント ER再構築、テーブル依存分析、データ品質診断 1〜2ヶ月 300万〜1500万円 ★★★★☆ DB依存が強い 5 業務プロセス分析 As-Is整理、手作業依存特定、ボトルネック抽出 1〜2ヶ月 300万〜1000万円 ★★★☆☆ 業務起点で改革 6 包括アーキテクチャ診断 全体統合診断、リスクマップ、ロードマップ策定 2〜6ヶ月 1000万〜5000万円 ★★★★★ 大規模基幹刷新前 いずれの調査⼿法においても、⼈⼿と時間とコストがかかるのが課題 AIを⽤いた解析を⾏うことで正確性と低コストを実現する 解析だけに留まらず、Refactoring も含めて⾏う
16. Architecture Re-Design Agentとは 16
 ⾃動分析 MMI評価 DDD準拠 ScalarDB設計 コードとドキュメントからユビ キタス言語、アクター、ロール を抽出。ドメイン-コード間の マッピングを作成します。 凝集度、結合度、独立性、再利 用性に基づき、モジュール成熟 度（MMI）を定量的に評価しま す。 境界づけられたコンテキストを マッピングし、ドメインタイプ （パイプライン、ブラックボー ド、対話）を定義して境界を明 確化します。 ターゲットとなるマイクロサー ビスアーキテクチャに合わせ て、分散トランザクション （ACID）とスキーマを自動設計 します。 Architecture Re-Design Agentは、既存システムのモダナイゼーションという複雑なプロセスを自動化します。 ソースコードと設計書を取り込み、包括的なリファクタリング計画を生成します。 入力：ソースコード + 設計書 出力：包括的なリファクタリングの移行計画書、 MMIスコア、ScalarDBアーキテクチャ 目標：手作業による分析時間を 80%削減し、一貫性を確保する
17. エージェント‧パイプライン全体像 17
 調査 Phase 0-1 評価 Phase 2 再設計 Phase 3-6 コード⽣成 Phase 7-8 • コード構造分析 • セキュリティ分析 • データモデル分析 • MMI品質スコア • DDD適合度評価 • 統合レポート • DDD再設計 • マイクロサービス化 • ScalarDB/API/k8sインフラ • テスト仕様書⽣成 • デザインパターン適⽤ • コード⽣成 • 中断‧再開可能なワークフロー • 37種類のスキルを適宜利⽤ • 戦略的設計 （Bounded Context, Context Map） • 戦術的設計 （Aggregate, Entity, VO） • DDD + マイクロサービス + Kong API Gateway + ScalarDBを軸に再設計 • テスト仕様書⽣成
18. スキル構成 - オーケストレーション 18
 スキル名 用途 特徴 /workflow 対話型ワークフロー選択 推奨エントリーポイント。 AskUserQuestion で実行タイプを選択 /full-pipeline 全フェーズ自動実行 27ステップ。--resume-from で中断再開対応 /refactor-system 分析＋設計のみ コード生成（Phase 8）をスキップ可能
19. スキル構成 - 調査 19
 Phase スキル名 内容 0 /system-investigation 技術スタック、構造、課題、DDD適合度 0.5 /security-analysis OWASP Top 10、ゼロトラスト評価 0.5 /access-control-analysis アクセス制御マトリクス、認証フロー 1 /analyze-system ユビキタス言語、アクター、ドメインマッピング 1.5 /data-model-analysis エンティティ/リレーション/ドメインルール 1.5 /db-design-analysis + /er-diagram-analysis テーブル定義、インデックス、ER図
20. スキル構成 - 評価 20
 Phase スキル名 内容 2a /evaluate-mmi + /mmi-analyzer MMI評価（4軸定性評価、Lilienthal3軸定量評価） 2b /ddd-evaluation 戦略的・戦術的DDD評価 2.5 /integrate-evaluations MMI/DDD統合、相関マトリクス
21. スキル構成 - 再設計 21
 Phase スキル名 内容 3 /ddd-redesign Bounded Context、Aggregate、Context Map 4 /design-microservices サービス分解、通信パターン 4.7-4.8 /select-scalardb-edition + app-patterns エディション選択、ドメイン型別パターン 5 /design-scalardb スキーマ、トランザクション、Saga、Helm 5.5 /design-scalardb-analytics Apache Spark + HTAP（オプション） 5.95 /design-api REST/GraphQL/gRPC/AsyncAPI 同時生成 6 /design-implementation 詳細実装仕様（Kong, JWT, RBAC, Resilience4j）
22. スキル構成 - コード⽣成 22
 Phase スキル名 内容 7 /generate-test-specs BDD/JUnit/k6 テスト仕様 8 /generate-scalardb-code Spring Boot サービス完全生成 8.7 /design-infrastructure K8s/Terraform/Pulumi/OpenShift
23. ブラックボックスを 可視化するには 23 Re-Architect Agentはどのように動いているのか
24. 最初に理解不能状態を解決する 24
 業務 マニュアル 設計書 ソースコード コード内のコメント、関数名などから処理内容を推定する どのような業務に対してどのような機能を実装しているのか ⾮機能の要件や想定はどうなっているのか 現状の業務はどのように⾏われているのか？ 実際に⾏われていれば、 概ね正しいことが多い。 多くの場合、実態やコードと ずれていることが多い。 実態とのずれはないが、実装 されているが、使われていない 機能があったりする。 ブラックボックスを解消するために、以下のような情報を収集します。
25. コードを解析するための⾜がかりを作る 25
 業務 設計書 コード 実際に動いているもの ただし、ビジネスの要求通り に作られているとは限らない 業務とコードを紐付けている 陳腐化して、コードとミス マッチしている可能性がある 実際の業務 システム外のオペレーション も存在することが多い 最初に、ビジネス⽤語を抽出し、 システムのコードを探る⾜がかりを作る 多くのケースでこの情報が⽋けているか、 不⼀致が起きている
26. 解析の⼿順 26
 設計書の解析 コード解析 ユビキタス⾔語の抽出 ドキュメントとコード読み取り アクター‧ロール‧権限の整理 ドメイン-コード対応表の作成 メタデータの最終更新
27. コード解析の⼿順 27
 技術スタック調査 構造分析 問題点特定 DDD適正評価 ⾔語、バージョン、フレームワーク、データベース、外部サービス、ビルドツール、テスト フレームワークなど ディレクトリ構成、モジュール構成（主要モジュール特定、公開インターフェイス）、依存 関係（モジュール間依存、循環依存検出）、エントリポイント（メイン関数/クラス、APIエ ンドポイント） コード品質、アーキテクチャ、セキュリティ、保守性 ドメイン層の存在、境界の明確さ、ユビキタス⾔語の痕跡、移⾏難易度 Domain Driven Design
28. ドメイン駆動設計（DDD）に基づいて動作 28
 ドメインエキスパート ユビキタス⾔語 ドメインモデル リポジトリ ドメインサービス ドメインオブジェクト 制約 エンティティ 集約 値オブジェクト コーディング モデリング ドメイン ドメインとは、課題を解決したいビジネスの範囲 のことです。 ドメインモデル ドメインの事象や概念が抽象化されたモデル です。 エンティティ 識別⼦によって⽐較されるオブジェクトです。 エンティティは、作成‧更新‧削除といったライフサイクルを持 ちます。 値オブジェクト 値によって⽐較され、不変であるオブジェクトのことを指しま す。 制約（ビジネスルール） オブジェクトを作成する際に 守らなくてはいけないルール で す。 集約 ドメインオブジェクト同⼠で強く整合性を取りたい範囲 を表し ます。また、永続化と再構築を⾏う単位でもあります。 ドメインオブジェクト ドメインモデルをソフトウェア上で表現したものです。 モデルの妥当性 実装で発⾒した知識 ソフトウェアとして 反映しやすいモデルか
29. ドメイン分類フレームワーク 29
 タイプ 特徴 例 Pipeline 順序的なデータ/処理フロー 注文処理、ワークフロー Blackboard 共有データへの協調的アクセス 在庫管理、予約システム Dialogue 双方向のインタラクション チャット、通知システム カテゴリ 責務 特徴 Process ビジネスプロセスの実行 ステートフル、サガ管理 Master マスタデータの管理 CRUD中心、データ整合性 Integration 外部システム連携 アダプタ、変換処理 Supporting 横断的機能の提供 認証、ログ、通知 ビジネス構造軸での分類（Domain Type） マイクロサービス境界軸（Service Category）
30. DDD - 戦略的設計の評価 30
 境界コンテキストの分析 ユビキタス⾔語の分析 コンテキストマップの分析 評価項目: ├── コンテキスト境界の明確さ │ ├── モジュール/パッケージによる分離 │ ├── 名前空間による分離 │ └── 責務の分離度 ├── コンテキスト間の関係 │ ├── 依存の方向性 │ ├── 共有カーネルの有無 │ └── 腐敗防止層の有無 └── コンテキストの独立性 ├── デプロイ独立性 ├── データ独立性 └── チーム独立性 評価項目: ├── 用語の一貫性 │ ├── コード内での命名 │ ├── コメント/ドキュメント │ └── テストケース名 ├── ドメインエキスパートとの整合性 │ ├── ビジネス用語の使用 │ ├── 技術用語の混入度 │ └── 略語の使用状況 └── コンテキスト間での用語の分離 ├── 同一用語の異なる意味 ├── ポリセミ（多義語）の検出 └── コンテキスト固有の語彙 関係パターンの検出 : ├── Partnership（協力関係） ├── Shared Kernel（共有カーネル） ├── Customer-Supplier（顧客-供給者） ├── Conformist（順応者） ├── Anti-Corruption Layer（腐敗防止層） ├── Open Host Service（公開ホストサービス） ├── Published Language（公表された言語） └── Separate Ways（別々の道） ビジネス整合性、組織適合性、技術的健全性の3つの観点で評価を⾏い、 事業構造とシステム構造の整合性が設計に反映されているかを評価します。
31. DDD - 戦術的設計の評価 31
 エンティティの分析 値オブジェクトの分析 集約の分析 評価項目: ├── 識別子の設計 │ ├── ID生成戦略 │ ├── 自然キー vs サロゲートキー │ └── ID型の適切さ ├── ライフサイクル管理 │ ├── 生成パターン │ ├── 状態遷移 │ └── 不変条件 └── 振る舞いの充実度 ├── ビジネスロジックの配置 ├── 貧血ドメインモデルの検出 └── Tell, Don't Askの適用 評価項目: ├── 不変性の確保 │ ├── イミュータブル設計 │ ├── 副作用のない操作 │ └── コンストラクタでの検証 ├── 等価性の実装 │ ├── equals/hashCode │ ├── 構造的同一性 │ └── 型安全性 └── 値オブジェクト候補の検出 ├── プリミティブ執着の検出 ├── 複合値の検出 └── 型エイリアスの検出 評価項目: ├── 集約ルートの特定 │ ├── ルートの責務 │ ├── 不変条件の保護 │ └── トランザクション境界 ├── 集約サイズの適切さ │ ├── 小さすぎる集約 │ ├── 大きすぎる集約 │ └── 参照vs値の判断 └── 集約間の参照 ├── IDによる参照 ├── オブジェクト参照の回避 └── 整合性境界 コードを調査し、実装レベルの設計パターンを分析し、 モデルがビジネスを正しく表現できているか？を評価します。 リポジトリの分析 評価項目: ├── インターフェース設計 │ ├── コレクション指向 vs 永続化指向 │ ├── クエリメソッドの設計 │ └── 仕様パターンの適用 ├── 実装の品質 │ ├── インフラ層への分離 │ ├── テスト容易性 │ └── トランザクション管理 └── 集約単位の永続化 ├── 集約全体の保存 ├── 遅延ロード戦略 └── キャッシュ戦略 ドメインサービスの分析 評価項目: ├── サービスの責務 │ ├── ステートレス性 │ ├── ドメインロジックの配置 │ └── 複数集約の協調 ├── サービスの粒度 │ ├── 単一責任 │ ├── インターフェースの明確さ │ └── 依存の最小化 └── アプリケーションサービスとの区別 ├── ユースケース層との分離 ├── トランザクション管理 └── セキュリティ/認可 戦術的パターン : ├── Factory（ファクトリ） ├── Repository（リポジトリ） ├── Domain Event（ドメインイベント） ├── Domain Service（ドメインサービス） ├── Application Service（アプリケーションサービス） ├── Specification（仕様） └── Policy（ポリシー） アーキテクチャパターン : ├── Layered Architecture（レイヤードアーキテクチャ） ├── Hexagonal Architecture（ヘキサゴナルアーキテクチャ） ├── Clean Architecture（クリーンアーキテクチャ） ├── CQRS └── Event Sourcing
32. モジュール成熟度指標（MMI）分析 32
 Modularity Maturity Index（MMI）評価（ 4軸定性） 4軸のモジュール成熟度評価により、マイクロサービス移行準備度を判定する定性評価を行います。 評価軸 軸 重み 評価観点 Cohesion （凝集度） 30% 単一責任原則の遵守度、機能的凝集度 Coupling （結合度） 30% 他モジュールへの依存度、インターフェースの 明確さ Independence （独立性） 20% 独立デプロイ・スケーリング可能性 Reusability （再利用性） 20% 他ドメインでの再利用可能性 スコア スコア レベル 意味 80-100 High マイクロサービス化準備完了 60-80 Medium 軽微なリファクタリングで移行可能 40-60 Low-Medium 大幅なリファクタリングが必要 0-40 Immature 全面再設計が必要
33. モジュール成熟度指標（MMI）分析 33
 Modularity Maturity Index（MMI）評価（ Lilienthal 3軸定量） Dr. Carola Lilienthal の手法に基づき、アーキテクチャ品質を定量評価します。 評価軸 カテゴリ 重み 主な評価対象 Modularity （モジュール性） 45% モジュール分割、インターフェース、プロ ポーション Hierarchy （階層性） 30% レイヤー違反、循環依存 Pattern Consistency （パターン一貫性） 25% パターン適用率、DDD分離 スコア スコア レベル 意味 8-10 Good 技術的負債が少ない 4-8 Warning 段階的リファクタリングを推奨 0-4 Critical リファクタリング vs 置換の判断が必要 具体的な実装方法は以下を見てみてください。 「モジュール成熟度指数を Claude Code で計測する」
34. 技術スタック調査 34
 カテゴリ 調査内容 言語・バージョン package.json, pom.xml, build.gradle, requirements.txt フレームワーク Spring, Express, React, Vue, Django, Flask データベース 設定ファイル、マイグレーション、ORM設定 外部サービス API呼び出し、SDK使用状況 ビルドツール Maven, Gradle, npm, webpack, Poetry テストフレームワーク JUnit, Jest, pytest, Mocha コード内に含まれる技術スタックを調査します。この結果に基づいて、これ以後 の処理のためのキーワードなどのヒントを取得します。
35. DDD適性評価の分析タスク 35

36. DDD適性評価 - Serena MCPによる処理 36
 カテゴリ 言語 Web/Backend TypeScript, JavaScript, PHP, Ruby, Python, Perl, Elixir, Erlang JVM系 Java, Kotlin, Scala コンパイル言語 C/C++, Go, Rust, Swift, Zig 関数型 Haskell, Clojure, Elm スクリプト Bash, Lua, R, Julia .NET C# その他 Dart, Fortran, Nix, Rego, Terraform マークアップ Markdown, YAML Serena MCPを利⽤して、シンボル解析（クラス、メソッド、関数）、参照追跡（使⽤箇所の特定）、型推論（型情報に基 づく精密な分析）、リネーム（プロジェクト全体の⼀括変更）、AST操作（構⽂⽊レベルの編集）を⾏い解析を進めます。 LSPが対応していない場合は、Glop, Grep, File Read で逐次処理を⾏います。LSPは、個別に追加することが可能なので、 巨⼤なコードベースの場合、LSPを作ることをお勧めします。
37. 構造分析 37
 技術スタックの分析結果に基づいて、構造分 析を⾏います。 モジュール同⼠の依存関係、God Class など の問題となりうるコードの調査を⾏い、中間 ファイルに出⼒します。
38. 問題点特定 38
 カテゴリ 検出項目 コード品質 巨大クラス/関数（500行以上）、複雑な条件分岐、重複コード アーキテクチャ 循環依存、God Object、レイヤー違反、密結合 セキュリティ ハードコード認証情報、SQLインジェクション、入力検証欠如 保守性 ドキュメント不足、テストカバレッジ、エラーハンドリング 重要度に合わせて分類し、レポートに出力します。 🔴 重大 → 🟠 高 → 🟡 中 → 🟢 低
39. 出⼒レポートの例 デモアプリケーションの分析 39
40. Architecture Redesign Agent for Claude Code 40
 このエージェントは、以下のURLから入手できます。 https://github.com/wfukatsu/architecture-redesign-agent 前提条件： • Claude Code • Serena MCP ◦ 対応⾔語はSerenaに依存するが、LSP（Language Server Protocol）を拡張すれば、多⾔語でも対応 することが可能。アセンブラの場合は、リバースし てC⾔語に変換することで対応できます。 • Context7 ◦ コーディングエージェントが最新のコード記述パ ターンを理解するのに利⽤します。 • RyuGraph（オプション） ◦ ドメインとコードの関係を可視化する場合に利⽤ します。 MITライセンスで提供しており、著作権を表⽰し、ScalarDBの設 計エンジンを外さなければ、ダウンロードして⾃由に使っていた だいてもOKです。
41. まとめ 41
42. まとめ 42
 ⼈⼿による調査 短時間かつ包括的な調査の実現 AIを⽤いることで、設計書とコードから⾃動で調査を実施 評価者のスキルや 主観に依存 主観に寄らない定量的‧定性的な評価の実現 AIによる、ルールに基づいた定量的‧定性的な評価 ボトムアップ型の 調査 ビジネス戦略とシステムを⼀致させるための評価の実現 ボトムアップとトップダウンの両側⾯から評価
43. 次回のお知らせ 分析と評価の結果に基づいて、どのようにシステムを再設計していけば良いのか。 マイクロサービス‧アーキテクチャを⾏う際のサービスの分割の考え⽅。 上記をAIを⽤いて実施する⽅法。 43

44. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催