AIエージェントで挑んだ大規模リファクタリング

タイトル

はじめに
背景
対応方針
リファクタの対応
- リポジトリ分割の例
  - Before
  - After
リファクタの工夫
リファクタの成果
- 工数削減
- Findy Team+で可視化
まとめ

はじめに

こんにちは。DMMユーザーレビューグループのバックエンドチームの朝妻です。
（本記事は、朝妻が執筆し、TLの松井と協力して仕上げたものです。）

私たちのチームでは、DMMに投稿される「ユーザーレビューを処理するAPI」を開発しています。このシステムは、レビューの投稿・レビューの表示に関するシステムを担っており、DMMの欠かせない基盤です。

本記事では、それらのシステムに関してエージェント型AI（今回は Devin）を活用し、大規模なリファクタリングを安全かつ効率的に進めた事例をご紹介します。

背景

Devinを活用してリファクタリングを進めるにあたり、その背景には大きく3つの要因がありました。

コード品質

ユーザーレビューグループでは、長く使い続けてきたコードが複雑化し、 保守性やレビュー効率の低下 が大きな課題になっていました。
こうした課題を受け、2025年3月に本部内で実施された 「ミノ駆動設計講座」 に参加し、DDDの設計の原則をあらためて学ぶことで、リファクタリングの必要性をチームとして認識しました。

ミノ駆動設計講座とは？

『良いコード／悪いコードで学ぶ設計入門』の著者による講座で、DDD（ドメイン駆動設計）の観点から「良いコードとは何か」を学ぶ場です。特に 関心の分離 が強調され、変更の影響範囲を限定することで保守性・拡張性を高める設計を重視しています。

AX戦略

一方で、私たちの所属する プラットフォーム開発本部ではAX戦略（AI Transformation）を推進 しています。
この戦略の中では「人でやっていた業務の50%をAIに置き換え、その変化を開発リードタイムで観測する」という目標を掲げ、AIを前提としたプロセスへの転換を進めています。

その一環として、 DevinやCursorといったAIエージェント が積極的に導入されてきました。 developersblog.dmm.com

AI活用

また、ユーザーレビューグループ独自の取り組みとして、毎週「AI分析会」を設けています。ここではAI活用事例の共有や、開発プロセスへの適用可能性を検討し、実際の現場に即したAI活用のあり方を探っています。

さらに、Findy Team+を活用して生産性の変化を定量的に把握し、AI導入の効果を継続的にモニタリングしています。こうした活動を通じて、 単なるツール導入に留まらず、チーム全体でAI活用を定着させること を意識しています。

対応方針

こうした背景と戦略を踏まえ、ユーザーレビューグループでは、 膨大な工数を要するリファクタリングにAIエージェントを導入する方針 を策定しました。
リファクタリングは、方針さえ決まっていれば作業内容が明確で、AIに任せやすい領域です。これらにより従来であれば数人月を要した作業も、AIと人の協働により短期間で実現することを狙っています。

AIエージェントとして採用した Devin は、Issue作成から実装・テスト・PR作成まで、開発の一連の流れをほぼ自動で実行できるのが特徴です。

そこでユーザーレビューグループでは、SlackワークフローとDevinを組み合わせることで、自然言語でSlackから指示を出し、「Issue作成 → 実装 → テスト → PR → 修正・マージ」といったサイクルを回すようにしました。

以下に、実際の運用フローイメージを紹介します。
Devinには段階的にドキュメントを作成させ、必要に応じて修正を指示することで、より精度の高いタスク遂行が可能になっています。

リファクタの対応

レビューのバックエンドのAPIコードの構造は以下のようになっています。

DDDの構成となっておりHandler → UseCase → Infra層を構成しています。 architecture

各層において様々な課題がありましたが、特にInfra層はすべてのAPIが共通で利用する基盤でありながら、 DDDにおける関心の分離がもっとも崩れていたため、リファクタリングの優先度をもっとも高く設定しました 。

Infra層の課題
- 主要なリポジトリ層のコードは3,000行超に膨れ上がり、テーブル操作・ビジネスロジック・条件分岐が混在。
- テストファイルは万単位に達し、1つのメソッドで複雑な条件を網羅する必要がありテストも肥大化。
- さらに旧バージョンの GORM v1 を利用しており、型安全性やクエリ表現力にも限界がありました。

そこで、Infra層に対して次の3つの施策を実施しました。

リポジトリ分割
- 巨大化したファイルをテーブルごとに分割し、責務を明確化。
- これによりコードがコンパクトになり、見通しと保守性が大幅に改善しました。
ドメイン層へのロジック移譲
- Infra層に混在していたビジネスロジックを切り出し、ValueObjectやサービスに移譲。
- データアクセスとビジネスルールを分離することで、拡張性を高めました。
GORM v2への移行
- クエリビルダーを導入し、可読性・型安全性・パフォーマンスを向上。
- SQL直書きによる複雑さや保守コストを解消しました。

リポジトリ分割の例

Before

1つの巨大ファイルに複数テーブルの処理が混在し、3000行を超える複雑な状態でした。

// Before: 単一リポジトリで複数テーブルを処理
func (r dataRepository) FindPublishedData(...) {
    // 複雑なraw SQLクエリと長大な条件分岐...
}

After

テーブルごとに専用のリポジトリを分割し、責務を明確化しました。クエリも型安全なビルダーで表現できるようになり、読みやすさと保守性が向上しています。

// After: テーブル単位の専用リポジトリ
func (r *mainDataRepository) FindPublished(...) {
    return r.reader.MainData.
        LeftJoin(r.reader.User, ...).
        Where(...).
        Scan(&data)
}

リファクタの工夫

今回のリファクタリングで特に意識したことは 「Infra層の外部仕様は変えずに中身だけ整理する」 ということです。一度に大きくリファクタしてしまうとリリース時のリスクが高いため、段階的に安全に移行できる仕組みが必要だったからです。

そこで次のような工夫を取り入れました。

新旧のInfra層を並行して用意
- 旧実装と新実装を同時に持ち、状況に応じて切り替え可能にしました。
Interface層で切り替え可能に
- 外側の形（Interface）はそのまま維持しつつ、内部の実装だけを差し替えられる設計にしました。
段階的に移行
- 新しい実装へ少しずつ移行し、既存のテストや利用コードを壊さないようにしました

この仕組みにより、安全に少しずつリファクタを進められるだけでなく、問題が発生しても即座に旧実装へ戻せる体制を整えられました。

例）新旧Infra層を並行運用し、Interfaceで切り替える仕組み switch

リファクタの成果

現在も進行中ですが、リファクタによりコードの見通しが大きく改善し、コードの負債を段階的に解消できています。
また、AIエージェント活用の成果として特に効果が大きかったのは次の2点です。

工数削減

従来であれば、これらを人力で修正するには少なくとも1人月以上の工数が必要でした。しかし、Devinを活用することにより、1ファイルあたり1人日以下で対応でき、工数を半分以下に削減できました。

そのため、他業務と並行しながらリファクタを進められるようになったのです。

また、今回の方針が有効だった点として、既存のInterfaceとUnitTestをそのまま流用できたことが挙げられます。これにより検証作業を大幅に省略でき、AI導入が難しいとされるテスト工程でも効率化を実現できました。

さらに、事前に整備していた依存性注入やUnitTest基盤があったからこそ、この効率化が可能になったとも言えます。

Findy Team+で可視化

さらに、Findy Team+によるメトリクスを活用し、リファクタ前（5月以前）とリファクタ期間の変化を比較したところ、以下の成果も見られました。

プルリク作成数：平均0.5件前後 → 1.5件以上（約3倍に増加）

この結果からも、AI活用がチーム全体の生産性を確実に高めていることが分かりました。 findy

さらに、今回のリファクタリングは 「Infra層の外部仕様を変えずに中身だけ整理する」 という方針を徹底したため、既存のInterfaceやUnitTestをそのまま流用でき、レビュー工数もあまり必要ありませんでした。これにより、他業務と並行しながらリファクタを進められるようになったのです。

ただし、このようにレビューをほとんど必要としないのは、外部仕様を変えずに進められる領域に限られます。
どのタスクにAIを適用すべきかを見極めることが、成功の鍵である と私たちは考えています。