組織全体の技術的負債をAIで可視化するCIの構築

これはなに？

こんにちは、DMM.comのミノ駆動です。
プラットフォーム開発本部コード品質チームにて、 プラットフォームの設計品質向上に取り組んでいます。

このたび、エンジニアリング組織全体の技術的負債をAIにより可視化する仕組みを構築しました。
この記事では、構築の経緯や仕組みを解説します。

• これはなに？
• 背景
  • DMMプラットフォームとは
  • 組織全体で増大する技術的負債
  • 負債の分析精度に課題
• Modifius（モディフィウス）の開発
• Modifius CIの構築
  • CI化の背景と狙い
  • Modifius CIの全体像
  • 技術スタックと仕組みの裏側
    • Claude Code Base ActionとModifius MCPの連携
    • バッチ分割と並列実行
    • レポートの生成とデプロイ
    • Slack通知 + スプレッドシート連携 + GAS
  • 導入過程で工夫した点
    • 分析結果の繰り返し精度を高める工夫
    • 運用コストを踏まえた設計
      • Prompt Caching
    • レート制限への対策
    • リトライ機構
    • 導入のセルフサービス化
  • 導入成果
  • 利用者の声
  • 今後の展望
• まとめ
• 宣伝

背景

DMMプラットフォームとは

弊社DMMは、さまざまな事業やサービスを展開しています。 DMM TVやDMMブックス、DMM通販など多岐にわたります。

こうしたサービスを下支えしている基盤がDMMプラットフォームです。 DMMサービス全体の技術基盤であり、 決済やポイント、認証認可や不正対策といった、サービス共通の機能を提供しています。

プロダクト	説明
ID基盤	4,000万人のID管理、及び会員IDに付随するプロダクト管理
決済基盤	月300億円規模の決済トランザクション基盤
ポイント基盤	DMMポイントの発行・消費などの基盤、月100億円規模のトランザクション
クーポン基盤	コンテンツの商品割引を行うクーポン基盤
不正対策	DMMを悪質なユーザーから守る基盤
CS-Platform	24時間365日稼働するカスタマーサポートを支えるCS-Platform
ユーザレビュー基盤	商品レビューの投稿・表示を一元的に管理するシステム群
モバイルSDK	DMMモバイルアプリに提供されるSDK群
DMMポイントクラブ	DMMポイントを「お得に管理・稼げる」を軸に展開しているtoC向けサービス
マイクロサービスプラットフォーム	PFのプロダクト群が乗るマイクロサービス基盤、及び周辺エコシステム
API Gateway	PFが提供しているOpenAPIへのオフロード
認証・認可	PF-OpenAPIへの認証と認可
フロントエンド基盤	PFのプロダクト群向けフロントエンドの共通UI、ビルド・配信基盤などを提供する仕組み
グローバルナビゲーション	DMMサイト内で使われる共通ナビ（ヘッダー）を通じて送客・回遊を促す

各基盤ごとにリポジトリがあり、開発チームが編成されております。 プラットフォーム全体では120名以上のエンジニアが開発に関与しております。

組織全体で増大する技術的負債

サービス規模の拡大に伴い、プラットフォーム全体の開発生産性低下が問題化していました。 技術的負債¹による開発生産性の低下です。 特に問題だったのは、変更容易性²が低いコードです。

この変更容易性の問題を解決するために立ち上げたのが「コード品質チーム」です。 コード品質を向上させるために、プラットフォームの開発チームに向けてさまざまな施策を実施しております。たとえば以下です。

• 書籍を用いた設計講座
• ドメインモデリング講座
• 設計ガイドライン策定
• チームに直接入って設計指導
• 各チームへリファクタリング計画立案と実施を促進
• 設計相談

こうした取り組みにより、全体的にコード品質が改善に向かっております。 しかし、コード品質チームはミノ駆動1人のみ。 さまざまな開発チームに対してもっときめ細やかな設計支援をしたくても限界があります。 なかなかスケールしないのが悩みのタネです。

負債の分析精度に課題

技術的負債の解消には、負債の規模に応じた取り組みが必要です。 技術的負債の分析手段のひとつが静的解析ツールです。 静的解析ツールにより、負債の分量を推し量ることができます。

静的解析ツールはコードの構造を機械的に判定します。 分析によってわかることは、たとえば以下です。

• コード行数
• サイクロマチック複雑度
• 引数の数
• 依存の度合い etc..

これらは指標として一定役に立ちますが、残念ながら限定的です。 なぜなら変更容易性の構造的観点による分析ではないからです。 変更容易性は、たとえば以下の観点で評価する必要があります。

• 同じ関心事でまとまっているか
• 異なる関心事が混在していないか
• 抽象レベルが揃っているか etc..

他にも整合性に問題がないかなどさまざまな評価が必要ですが、 静的解析ツールはコードを機械的にしか分析できません。 真の意味で負債かどうか、静的解析ツールの値だけではどうしても判断しきれない部分があります。

そのため、どの負債に対してどれぐらい解消コストをかけるべきか正確な見通しが立てられず、 開発戦略の策定に課題がありました。

Modifius（モディフィウス）の開発

そこで開発したのが「Modifius（モディフィウス）」です。 変更容易性に関して包括的な支援機能を提供するMCPサーバーで、 AIエージェントと連携して使います。 以下の機能があります。

• 高精度な技術的負債分析
• 設計改善提案
• 高品質なテストコード実装

Modifiusの名は、modifiability(変更容易性) + ius(ラテン語の威厳ある男性名の語尾)、 「変化を司る者」という意味です。

Modifiusの実態は、変更容易性に関するプロンプトを、用途に合わせて加工し返すサーバーです。 変更容易性に関する知見は、拙著などがベースになっています。

AIはコードの意図を推論できます。 静的解析ツールとは異なり、あるコードがドメインロジックなのか、DBロジックなのか、フロントエンドのコードなのかを判別できます。 また、コードの関心事の違いも推論できます。 たとえば予約注文に関するコードなのか、それとも抽選注文に関するコードなのかも見分けがつきます。 そのため、以下のような変更容易性の構造的観点で技術的負債を分析できます。

• 同じ関心事でまとまっているか
• 異なる関心事が混在していないか
• 抽象レベルが揃っているか

たとえば、次のコードは拙著『改訂新版　良いコード／悪いコードで学ぶ設計入門』に記載のコードです³。 変更容易性に問題があります。

int damage = 0;
if (0 < weapon.durability) {
  damage = (member.armPower + weapon.power) - enemy.defence / 2;
  if (damage > 0) {
    if (specialGauge.amount == 100) {
      damage *= 2;
    }
  }
  else {
    damage = 0;
  }
  if (specialGauge.amount < 100) {
    if (damage < 10) {
      weapon.durability -= 1;
    }
  }
  specialGauge.amount += 5 + damage / 100;
  if (specialGauge.amount > 100) {
    specialGauge.amount = 100;
  }
}
else {
  throw new RuntimeException("この武器では攻撃できません");
}

このコードの技術的負債をModifiusで分析すると、以下の結果が得られます(一部のみ記載)。

欠陥モジュール	分離すべき関心(目的)	欠陥の理由	欠陥行数カウント	欠陥スコア
AttackUseCaseクラス	武器の耐久性管理	攻撃処理の目的を持つUseCaseに、武器の耐久性という別の関心事(武器の状態管理)が混在している(13, 24-26, 33-35行目)	6	1
AttackUseCaseクラス	スペシャルゲージ管理	攻撃処理の目的を持つUseCaseに、スペシャルゲージという別の関心事(ゲージの状態管理)が混在している(16-18, 23, 28-31行目)	11	1
AttackUseCaseクラス	ダメージ計算のビジネスルール	攻撃の実行という上位目的に、ダメージ計算という下位の関心事が直接実装されている(14-22行目)	9	1

独自計算式に基づいた欠陥スコアも算出します。 モジュールごとの負債の度合いがわかります。

Modifiusについてはこちらのスライドでも解説しております。

ModifiusはMCPサーバーなので、GitHub ActionsでCIに組み込むことが可能です。 そしてこのたび、弊社の坂本がプラットフォーム全体の技術的負債をGitHub Actionsで定期分析する仕組みを構築しました。

Modifius CIの構築

こんにちは、DMM.comの坂本です。ここからは私が解説を担当します。
同じくプラットフォーム開発本部にて、Modifiusを組織全体のCIに組み込む「Modifius CI」の開発を担当しました。

CI化の背景と狙い

「組織全体で増大する技術的負債」の章で先述したとおり、コード品質チームはミノ駆動1名で運営されています。
120名以上のエンジニアが関与するプラットフォーム全体の負債を、手動で分析し続けるのは困難です。

そこで、ModifiusをGitHub Actionsに組み込み、定期的かつ自動で技術的負債を分析する仕組みを構築しました。
狙いは次の3点です。

• 各チームが自リポジトリの負債状況を定量的に把握できるようにする
• 共通指標で横断的に比較し、改善の優先度付けを支援する
• 定期実行による変化の追跡を可能にする

これらの狙いを実現するために、Modifius CIでは次のようなアウトプットが得られる仕組みを設計しました。
CIが定期実行されると、分析結果がSlackに通知され、チームは自リポジトリの負債スコアをすぐに確認できます。

詳細な分析結果はHTMLレポートとしてGitHub Pagesにデプロイされ、ブラウザ上で欠陥スコアやファイルごとの詳細を確認できます。

また、技術的負債の解消にかける予算の見積もり・意思決定を行うため、ダッシュボードで全リポジトリの欠陥スコアを俯瞰して確認できる仕組みにしています。

この仕組みを実現するために構築したのが、以下で紹介するModifius CIのパイプラインです。

Modifius CIの全体像

Modifius CIはGitHub Actionsの再利用可能ワークフロー（Reusable Workflow）として設計しました。
各リポジトリに設定ファイルと呼び出し用ワークフローを追加するだけで利用を開始できます。

下図は全体のアーキテクチャ図です。

プロダクトのリポジトリからワークフローを呼び出すと、Modifius CIのパイプラインが起動します。
パイプラインの中核はanalyzeジョブです。
Claude Code Base Actionを介してClaude Codeを実行し、Modifius MCPサーバーと連携してファイルごとに技術的負債を分析します。

パイプラインは以下の8つのジョブで構成されています。

1. parse-config : リポジトリの設定ファイルを読み込む
2. prep : バリデーション処理、分析対象ファイルの列挙、MCPサーバーのセットアップ、バッチ分割
3. analyze : ファイルごとにClaude CodeとModifius MCPで負債分析
4. aggregate : 各ファイルの欠陥スコアを集計する
5. build : HTMLレポートを生成する
6. deploy : GitHub Pagesにデプロイする
7. notify : Slackに通知を送信する
8. update-spreadsheet : 分析結果をスプレッドシートに自動転記する

利用するリポジトリ側では、2つのファイルを追加します。

1つ目は分析対象や通知先を定義する設定ファイル（.github/modifius-config.yml）です。

target_branch: main # 分析対象のブランチ
target_paths: # 分析対象のパス
  - ./src/domain/model
exclude_patterns: # 除外対象
  - '_test\.go$'
  - '\.md$'
deploy_method: branch # GitHub Pagesのデプロイ設定
deploy_branch: gh-pages # デプロイ先のブランチ
slack_channel_id: C01234567 # 通知先のSlackチャンネル

2つ目はModifius CIを呼び出すワークフローファイルです。

name: Modifius CI (remote)
on:
  workflow_dispatch:
  schedule:
    - cron: "0 0 15 * *"
jobs:
  modifius:
    uses: a-repository-name-of-modifius-ci@main
    secrets:
      PF_MODIFIUS_ANTHROPIC_API_KEY: ${{ secrets.PF_MODIFIUS_ANTHROPIC_API_KEY }}

設定ファイルで分析対象のパスや除外パターンを指定し、スケジュール実行するだけで負債分析が回り始めます。

技術スタックと仕組みの裏側

Claude Code Base ActionとModifius MCPの連携

分析処理の中核は、Claude Code Base ActionとModifius MCPサーバーの連携です。

prepステップでModifius MCPサーバーを起動し、利用可能なMCPツール一覧を取得します。
analyzeステップでは分析対象ファイルごとにClaude CodeがModifiusのMCPツールを呼び出して負債を分析します。

分析結果はMarkdownテーブル形式で出力されます。
テーブルから欠陥行数カウントと欠陥スコアを抽出し、JSONとして保存します。

推論はLiteLLM基盤で行い、temperatureなどのパラメータ調整ができます。
また、このLiteLLM基盤は弊社レビューグループの松井⁴より提供いただきました。

バッチ分割と並列実行

分析対象のファイル数が多い場合に備え、バッチ分割の仕組みを導入しています。
GitHub Actionsのmatrix strategyには1ジョブあたり256個の上限があります。
そのため、256ファイルごとにバッチを分割し、各バッチ内では最大5並列でClaude Codeを実行します⁵。

レポートの生成とデプロイ

各ファイルの分析結果を集約し、HTMLレポートとして生成します。
レポートはGitHub Pagesにデプロイされ、ブラウザから閲覧できます。
過去の実行履歴も保持されるため、負債スコアの推移を時系列で追跡できます。

Slack通知 + スプレッドシート連携 + GAS

分析完了後、結果のサマリーをSlackに通知します。
あわせて欠陥スコアをスプレッドシートに自動転記します。
複数リポジトリの負債状況を横断的に確認できるダッシュボードは、スプレッドシートからGASでデータを取得し、ホスティングしています。

導入過程で工夫した点

分析結果の繰り返し精度を高める工夫

AIによる分析では、同じ入力に対して異なる結果が返る非決定的な挙動に注意が必要です。
Modifius CIは定点観測として利用するため、繰り返し精度（再現性）が重要になってきます。 そこでModifius CIではLiteLLM経由で推論し、LLMの推論パラメータを以下のように設定して分析結果の決定性を高めています。

パラメータ	値	効果
temperature	0	確率分布のシャープさを最大にする
top_k	1	もっとも確率の高いトークンのみを選択する
top_p	1（または未指定）	top_kの設定に委ねる

この設定は「一番確率が高い答えを1つだけ選べ」と指示している状態です。
ランダム性を排除し、パラメータ的に決定的な挙動にしています。
同じコードに対して可能な限り同じ分析結果が得られることを目指した設定です。

運用コストを踏まえた設計

検証段階では、1ファイルの分析には約0.27ドルの費用が発生していました（非キャッシュ時の検証値。実運用の段階ではLiteLLMのPrompt Cachingを利用[後述]）。
そのためコスト効率を考慮し、以下の運用方針を設けています。

• PR作成時やマージ時ではなく、隔週や月1回のスケジュール実行を推奨
• 分析対象は最大50ファイルに制限
• 変更頻度が高く重要度の高いファイルに絞って分析

Prompt Caching

実運用ではLiteLLMのPrompt Cachingを利用しています。
結果、約12日間の利用で約90%近くキャッシュが効いており、現状は数十ドル程度のコストで運用できています(20個前後のプロダクトに導入した状態にて計測)。

• Prompt Cachingキャッシュ利用率：約 88.6%
  • Cache Read Tokens：52,566,550
  • Cache Creation Tokens：6,726,924
• コスト効果削減率：約 88.7%（約90%削減）
  • キャッシュなし想定：約 $530
  • 実際のコスト：$58.51

レート制限への対策

Claude Code経由でAPIを呼び出す際、短時間に多くのリクエストを送信するとレート超過エラーが発生します。
検証では10個以上のファイルを並列実行した際に高確率で発生していました。
GitHub Actionsのmatrix strategyでmax-parallel: 5を設定し、同時実行数を制限することで対処しています。

リトライ機構

Claude Code Base Action内部でリトライ処理が実装されていますが、AI実行の不安定さを考慮し、分析ステップではClaude Code Actionを2回実行する構成にしています。
1回目が失敗した場合に自動で2回目を実行し、その結果を使用します。

導入のセルフサービス化

各チームが自律的に導入できるよう、いくつかの仕組みを整備しました。

• 設定ファイルのテンプレートとオンボーディングガイドの提供
• Slackのワークフローによる利用申請の自動化
• 専用の問い合わせチャンネルの開設

しかし現状、整備が追いついておらず、運用負荷の軽減が今後の課題の1つです。

導入成果

Modifius CIの導入により、以下の成果が得られました。

• プラットフォーム内の複数リポジトリに対して、技術的負債の定期的な可視化を実現
• GitHub PagesのHTMLレポートにより、チーム内で分析結果を共有可能に
• スプレッドシートのダッシュボードで複数リポジトリの欠陥スコアを横断的に把握
• 共通指標による負債の定量化で、改善の優先度付けの議論が容易に

利用者の声

Modifius CIを導入したチームから、分析結果をきっかけに負債を改善できた事例が報告されています。
DMMポイントクラブのモバイルアプリ開発を担当する宮里さんに話を伺いました。

DIコンテナ構築のためのボイラープレートコードが1つのクラスに集中していました。
利用していたDIツール（Dagger2）の都合上やむを得ないコードだったため、チームとしては問題視していませんでした。

しかしModifius CIの分析では、「30以上のDaggerコンポーネント生成と依存関係構築ロジックが混在している」という欠陥理由で200近いスコアが付きました。
スコアを重点的に確認していく中で、DIツールを置き換えれば大きく改善できることに気づきました。

DIツールの置き換え自体は数年前からIssueとして積まれていましたが、コード全体に影響する変更のため実施に踏み切れていませんでした。
Modifius CIの結果によって問題が数値として明確になり、メンバー全員が改善の必要性を共有できたことで、対応を決定しました。

AIの力も借りつつDagger2からDagger Hiltへの置き換えを完遂し、直近のModifius CI実行結果では該当クラスの欠陥スコアが大きく減少していることを確認できました。

今後の展望

Modifius CIは現在「負債の可視化」を実現した段階です。
今後は以下の取り組みを予定しています。

• 欠陥スコアを元にしたリファクタリング計画の策定と実施
• PR差分を対象とした負債検知機能の開発
• カスタムプロンプトによる分析の拡張

まとめ

本記事では、AIを活用した技術的負債の分析ツール「Modifius」と、それをGitHub Actionsで組織全体に展開する「Modifius CI」を紹介しました。

AIの推論能力を活かすことで、静的解析ツールでは捉えきれなかった変更容易性の構造的な課題を分析できるようになりました。
さらにCIとして自動化することで、組織全体の技術的負債を定期的・定量的に可視化する仕組みを実現しました。

技術的負債の解消はまだこれからですが、「見える化」によって問題提起と改善の優先度付けがしやすくなりました。
今後は分析結果を活用したリファクタリング計画の推進に取り組んでいきます。

宣伝

弊社のPF開発本部ではDMMのサービスを支える基盤開発やAIを活用した業務改善などを行い、持続可能なプロダクトを目指して開発に取り組んでいます。
専門性の高いメンバー（時には他部署のエンジニアやマネージャーとも）協力しながら自らのアイデアを実装し、多様な事業を技術で支えつつ、エンドユーザーの体験向上にも携われる環境です。
チームとプロダクトの成長を支える一員として一緒に活動していきませんか？
少しでも興味がある方はぜひ下記採用ページをご確認ください。
dmm-corp.com