Devinにコードレビューをさせ、コード品質と開発速度を同時に高める

ツール導入前の課題

• チームが細分化され、失敗パターンやベストプラクティスが横展開されにくい
• コードレビュー品質がレビュアーの経験値に依存し、ばらつきが発生していた
• ドキュメントは更新コストが高く、参照漏れも多い
• 目指していた設計パターンから逸脱した実装が増加
• レビュアーの負荷が高まり、本質的なレビューに集中しにくい

どのような状態を目指していたか

• 過去の失敗例やベストプラクティスが、PR を通じて即座にフィードバックされる状態
• ドメイン特有の運用ルールも含め、チームをまたいで一貫した判断基準が適用される仕組み
• ジュニア/シニアを問わず、一定以上のレビュー品質を自動で担保
• 人的レビューがより本質的な部分に集中している状態
• Wiki やドメイン知識の内容が AI に取り込まれ、レビューのたびに自動参照される

改善したかった課題はどれくらい解決されたか

当初課題に感じていた「チーム細分化による知見共有の難しさ」については、Devinの導入によって大きく改善されました。特に、AIがコードレビュー内で過去の失敗やベストプラクティスを自動的に指摘してくれるため、チーム間で同じ失敗を繰り返す頻度が目に見えて減りました。

また、「レビュー品質がレビュアーの経験に大きく依存する」という問題についても、完全に解決とまでは言えませんが、ある程度の改善が見られました。AIが一定の基準で指摘を行ってくれることで、レビュアーの経験差に伴うばらつきを抑える効果を感じています。

「ドキュメントが陳腐化しやすく、更新や参照が難しい」という課題についても、DevinのKnowledgeとして自動的に参照されるため、ドキュメントにかかる更新コストが軽減され、情報が実際の開発フローの中で自然と活用される仕組みになりました。

「目指しているRailsの設計パターンから逸脱した実装が増えてしまう」ことに関しても、導入後の日が浅く完全に解消とは言えませんが、AIが繰り返し設計思想をレビューで指摘することにより、少しずつ良い影響を感じ始めています。

どのような成果が得られたか

成果の詳細は、Zennでの記事 にて詳しく紹介していますが、AIレビュアーの導入により、全体的にコードレビューの早い段階で一定割合のバグや設計上の問題を事前に検知できるようになりました。これによって、人間による最終的なレビュー時の負担が軽減され、開発の効率化につながっています。

当初、AIエージェントに「実装タスク」と「コードレビュー」の両方を任せる可能性を検討しましたが、実装については生成されるコードの品質や挙動がやや不安定で、細かいやりとりや確認コストが想定よりも高くなっていました。

一方で、コードレビュー用途では当初から比較的安定して良い指摘が得られており、運用コストや心理的負担も軽減される実感がありました。そのため、私のチームでは用途を絞り込み、実装ではなくコードレビューに特化してAIを導入することを決めました。（実装タスクにも活用しているチームがありますが、今回はレビューでの活用例に特化した内容になります。）

AI全般に当てはまりますが、Knowledgeや適切な文脈情報・プロンプトによって効果を発揮できるツールです。

組織特有の設計思想やドメイン知識などを丁寧に蓄積・チューニングする必要があるため、誰がKnowledgeを整備し、誰が指摘内容の品質を評価・改善するのかを明確に決めておくことが重要です。

特に初期段階では、シニアエンジニアなどドメインや設計思想に詳しいメンバーが主体的にチューニングや評価をすることをお勧めします。（また、AIツールの市場や個々のツールの機能は非常に速く変化するため、Devinを含め、導入を検討する際にはその時点での最新情報を随時調べ、状況をアップデートしながら判断する必要があります。実際、弊社でも導入当時から状況が大きく変化しており、DevinからRoo Code、そこからClaude Code…のように複数回ツールを置き換えています。）

技術の進歩が非常に速い分野であるため、特定のツールに固定せず、引き続き市場の新しい動きをウォッチし続けることが大切だと感じています。実際に、AIレビュアーについてはDevinからRoo Codeを経由し、現在はClaude Codeへと置き換えが終わっており、引き続きレビューの品質に加えてDORAメトリクスなどの健康指標も見つつ生産性を上げていきます。