Devin×Claudeで実現する持続可能なAI開発体制

サムネイル

はじめに
1. Devin導入期：生産性の爆発的向上
2. Devin運用期：PRレビューボトルネックの発生
4. 改善期：持続可能なAI開発体制の構築
まとめ

はじめに

プラットフォーム開発本部第一開発部認証グループの菅原です。

DMMでは、プラットフォーム開発本部のAX戦略（AI Transformation）に基づき、各チームでAIエージェントの活用を推進しています。私たちのチームでも、DevinやCursorなどのAIツールを積極的に導入し、開発生産性の向上に取り組んできました。

Devin活用開始当初、生産量（PR作成数）は爆発的に増加したものの、それに伴いPRレビュー負荷の増加という新たな課題が発生しました。

本記事では、これらの課題に対する改善活動を通じて、持続可能なAI活用前提の開発体制を構築するまでの過程を、具体的な数値と実装例を交えてご紹介します。Devin活用を検討している開発チームの皆様にとって、実践的な参考情報となれば幸いです。

1. Devin導入期：生産性の爆発的向上

自律型AIエージェントの可能性に着目

2025年5月、私たちのチームはDevinの試験運用を開始しました。自律型AIエージェントとして注目を集めていたDevinは、タスクを完全に委譲できる可能性を秘めていました。

従来の開発フローでは、CursorやGitHub Copilotなどのコーディング支援ツールを使いながらエンジニアがコードを書き、テストを作成し、PRを作成する一連の作業を手動で行っていました。しかし、Devinを活用することで、これらの作業の大部分をAIに委譲できるのではないかと考えました。

驚異的な成果

試験運用の結果は期待を大きく上回るものでした。

チーム全体のベロシティは、Devin使用前に比べて、約1.7倍 (平均)
個人のタスク消化量は、Devin使用前に比べて、約2.4倍 (平均)

具体的な工数削減効果

実際のタスクで比較した結果、以下のような工数削減を実現しました（一例）。

タスク	手作業	Devin活用	削減時間
比較的軽微なライブラリアップデート	2時間00分	0時間01分	1時間59分
影響が大きく、ビルドエラーが発生したライブラリアップデート	8時間00分	0時間50分	7時間10分
既存機能の修正	2時間00分	0時間20分	1時間40分

合計工数削減：23時間45分（3スプリント分、自チームでは1スプリント2週間）

検証期間は私一人でDevinを活用していましたが、1スプリントあたり約8時間（1稼働日分）の工数削減を実現しました。チームの開発メンバー全員（4人）が同様にDevinを活用すれば、より大きな工数削減を実現できる可能性があります。

これらの数値は、Devin活用が単なる効率化ツールではなく、開発生産性を根本的に変革する可能性を示していました。

2. Devin運用期：PRレビューボトルネックの発生

生産量増加の副作用

Devin導入による生産性向上は確実でしたが、新たな課題が発生しました。PR作成数が爆発的に増加したことで、PRレビューボトルネックが深刻な問題となったのです。

従来の開発フローでは、エンジニアが作成するPRの数は限定的でした。しかし、Devinが大量のPRを生成するようになると、人間によるレビュー作業が追いつかなくなりました。

ボトルネックの実態

問題の構造

Devinの生産量：約2.4倍向上
人間のレビュー能力：変化なし
結果：レビュー待ちのPRが蓄積

この状況は、開発生産性の向上に限界があることを意味していました。いくらAIがコードを生成しても、人間がレビューする速度には限界があるからです。

根本原因の分析

PRレビューボトルネックの根本原因は、AI前提のプロセス設計の欠如にありました。

従来の開発プロセスは「人間がコードを書く」ことを前提として設計されていました。そのため、AIが大量のコードを生成するようになると、既存のプロセスが機能しなくなったのです。

従来のプロセス

エンジニアがコードを書く
エンジニアがPRを作成する
他のエンジニアがレビューする
マージする

AI導入後の現実

AIが大量のコードを生成する
AIが大量のPRを作成する
エンジニアがレビューする → 発生した課題: 人間のレビュー能力が追いつかない
マージする → 発生した課題: 上記3で発生した課題により、マージタイミングが遅延

この問題を解決するには、プロセス自体をAI前提のプロセスに作り変える必要がありました。

持続可能な開発体制の必要性

チームの生産性を維持するには、持続可能な開発体制の構築が急務でした。

従来のアプローチでは、以下のような課題がありました。

従来の問題

人間のリソースに依存した開発体制
メンバーのスキルや経験に左右される生産性

解決すべき課題

AIを活用した自律的な開発体制
人間の介入を最小限に抑えたプロセス

この状況下で、私たちはDevin活用の次のステップを模索することになりました。単なる効率化ツールとしてのDevin活用から、AI前提の持続可能な開発体制への転換が必要だったのです。

4. 改善期：持続可能なAI開発体制の構築

Claude Code導入：PRレビューボトルネックの解決

PRレビューボトルネックを解決するため、私たちはClaude Codeを導入しました。特にClaude Code GitHub Actionsは、柔軟にプロンプトも調整でき、PRレビューに特化したエージェントにできる期待がありました。

また、issueやPRコメントから @claude のメンションをつけて指示することで、これまでのエディタでの修正 -> commit / push の開発部分もGitHub上で完結できるようになります。

Claude Code GitHub Actionsの構成

ワークフロー	用途	効果
`.github/workflows/claude_code_issue_comment.yml`	Issueからタスク実行	非同期での作業委譲
`.github/workflows/claude_code_pr_review_comment.yml`	PRコメントから修正	レビューコメントの即座修正
`.github/workflows/claude_code_pr_review.yml`	PR自動レビュー	レビュー負荷の大幅削減

自動レビュー判定ワークフローの構築

もっとも重要な改善は、自動レビュー判定ワークフローの構築でした。

ワークフローの仕組み

PRが作成されると自動的にClaude Code GitHub Actionsがレビューする
PRを「AIレビューのみ」または「人間のレビューが必要」に分類
AIレビューのみの場合は自動approve
修正などあれば、Claude Code GitHub Actionsがインラインコメントを挿入する

分類基準の例

AIレビューのみ: バリデーション修正、表示ロジック変更など
人間のレビューが必要: ビジネスロジック変更、セキュリティ関連など

このワークフローにより、人間がレビューすべきPRとAIのみで処理できるPRを自動的に判別し、レビュー負荷を大幅に削減できる見通しが立ちました。

工夫した点：コンテキストの使い回し設計

Claude Code GitHub Actionsを効果的に活用するため、コンテキスト管理を工夫しました。

CLAUDE.mdの導入

セッション開始時に自動的に読み込まれるファイル
AGENTS.mdを参照するように設定

AGENTS.mdの設計

リポジトリのコンテキストや、コーディングルールなどが書かれたmdファイルを読み込み
複数のAIエージェントで共通利用可能な設計

使い回しのメリット

Devin、Cursor、Claude Codeなど、異なるAIエージェントでも同じコンテキストを利用
コンテキストの一元管理により、メンテナンス負荷を削減
AIエージェントの切り替え時も、継続性のある品質を維持

/.claude
  |_ /memory
     |_ role.md
     |_ context.md
     |_ coding_standards.md
     |_ pr_review_classification.md
     |_ pr_review_comment_rules.md
AGENTS.md
CLAUDE.md

Pull Requestが作成されると、ワークフローが実行され、Claude Code GitHub ActionsがPRレビューを開始します。分類: AIレビュー かつ修正箇所がない場合は、自動でapproveするようにしました。

claude_output

claude_comment

まだ、Claude Code GitHub ActionsのPRレビュー分類は試験運用中ですが、エンジニアがレビューするべきPull Requestを、AIレビューのみに誤認してしまうケースは発生していないので、十分な精度がでていると感じています。

このまま、本格運用に移行できれば、エンジニアのPRレビュー負荷は、これまでの半分になる想定です。

Devin Playbooks活用：コンテキストの自動育成

持続可能なAI開発体制を実現するため、DevinのPlaybooks機能を活用したコンテキスト自動育成ワークフローを構築しました。

コンテキスト育成Playbook

実行頻度: 毎週月曜日9:00
処理内容: PRコメントのコメント (bot以外) から有用な情報を抽出
更新ファイル:
- .claude/memory/coding_standards.md
- .claude/memory/context.md

完全自動化ワークフローの実現

これらの改善により、以下のような完全自動化ワークフローを実現しました。

コンテキスト自動更新

Slackワークフロー → Devin Playbook → コンテキストファイル / コーディングルール更新 → PR作成

masked_icon_slack

masked_devin_message

AIに読み込ませる、これらのマークダウンファイルを、エンジニアが普段の業務の合間でメンテナンスし続けるのは、難しいです。

また、主なメンテナーが退職や異動により、その後誰もメンテナンスしなくなってしまう、というリスクもあります。

AIを使いワークフローを構築しておくことで、エンジニアの介入を最小限にでき、コンテキストのメンテナンスを続けやすい仕組みになっています。

ちなみに、このcontext.mdとcoding_standards.mdについては、一からエンジニアが書いたわけではありません。Devinにリポジトリ全体を走査させて、リポジトリのドメイン知識や、コーディングスタイルを確認させて作成しました。そして、別のAIエージェントを使い、AIが理解しやすい形に構造化 (XMLタグを利用するなど) しました。

持続可能性の実現

これらの改善により、以下の持続可能性を実現しました：

人間の介入最小化

コンテキストメンテナンス：自動化
PRレビュー：50%をAIのみレビューでマージ可能

スケーラビリティ

AI活用のノウハウが自動的に蓄積
新しいメンバーへの知識移転が不要

まとめ

Devin活用の本質的な価値

本記事で紹介した取り組みを通じて、Devin活用の本質的な価値が見えてきました。それは、単なる効率化ツールとしてのDevin活用から、AI前提の持続可能な開発体制への転換です。

従来のDevin活用

人間の作業をAIで置き換える
既存プロセスにAIを当てはめる
一時的な生産性向上

AI前提の開発体制

AIと人間の協働を前提としたプロセス設計
持続可能な自動化システム

学んだこと

プロセス設計の重要性
Devin活用の成功は、ツールの選択よりもプロセス設計に依存します。既存のプロセスにAIを当てはめるのではなく、AI前提のプロセスに作り変えることが重要です。

持続可能性の確保
一時的な生産性向上ではなく、持続可能な仕組みの構築が重要です。人間の介入を最小限に抑え、自動化できる部分は徹底的に自動化する必要があります。

今後の展望

私たちのチームでは、さらなるDevin活用を目指しています。現在、検証しているのは、AIが定期的にリポジトリを走査し、発見した負債箇所をIssue化します。エンジニアが内容を確認して問題なければ、Claude Codeに修正させPRを作成します。最低限のチェックポイントはありますが、リポジトリのリファクタを自動で進めてくれます。

まだ、完全に自動化するには精度が不十分な部分があるので、簡単なリファクタから始めている状態です。これから、より広範囲のリファクタをAIで自動化していきたいと考えています。