この記事は、評価記事や製品発表ではなく、Devin をコードレビューの日常的な一部とした弥生のチームによる実践者の報告である。詳細の大半は、エージェントとともにリポジトリにコミットされた 2 つの成果物、すなわちレビュー観点のファイルとプロジェクトのコンテキストのファイルに関するものであり、最後に、著者が委任に向かないと考えるレビューの部分を挙げて締めくくっている。
著者は、チームが軽減しようとしていた 5 つの問題を挙げている。レビュー工数の増大、レビュアーの負荷、人同士が細かな指摘をやり取りする際の双方の心理的コスト、確認する観点の標準化の難しさ、そして小さな問題の見落としである。注目すべきは、3 つ目が明確に人間同士のレビューに特有の問題として述べられている点である。
この報告は明示的に途中経過のものである。継続的なプロンプトの調整、誤検知パターンに関する知見の蓄積、CI の調整、定期的な振り返りについての節は、測定された成果としてではなく、チームが進もうとしている方向として書かれており、著者は仕組みがまだ構築途中であることを記している。
要点
- レビュー観点は、リポジトリの
.github/devin-review-prompt.mdにコミットすることで標準化されており、コード品質、アーキテクチャと設計、セキュリティ、パフォーマンス、テスト、ドキュメント、プロジェクト固有の要件という 7 つのグループに整理されている。リポジトリに置く理由として著者が挙げるのは、CI/CD がそこから読み込めることと、チームメンバーが容易に共有できることである。 - 著者は、標準化に関する効果と小さな問題の検出に関する効果の中で、プロジェクト固有のグループを漏れなくチェックされるものとして 2 度取り上げている。このグループにはプロジェクト特有のルールが含まれる。ログ出力には
console.log()ではなくチームの OpenTelemetry 形式のロガーを使うこと、ブランチ名はfeatures/{ticket-number}[/task-name]に従うこと、PR のタイトルにはfeat:/fix:/hotfix:のプレフィックスを付けること、そしてデータベース・API・インフラを変更した際には特定の設計ドキュメントを更新しなければならないことである。 - レビューは、プルリクエストの
opened、synchronize、reopenedをトリガーに GitHub Actions から実行される。ワークフローは PR の変更ファイルを収集し、レビュー観点のファイルを読み込み、AGENTS.md内で区切られたプロンプトテンプレートを抽出して、Devin API に対してセッションを作成する。Devin は指摘を PR へのコメントとして投稿する。 - ワークフローの 2 つの条件は、付随的な設定ではなく、コストとノイズを抑える手段として示されている。フォークされた PR とドラフトの PR は除外され、
cancel-in-progressを指定した concurrency グループによって、PR への最新のプッシュだけがレビューされるようになっている。 - チームは AGENTS.md が Devin に自動的に読み込まれることに依拠しており、セットアップコマンド、コードスタイルとテストのガイドライン、プロジェクト構成、開発ワークフロー、Devin 固有の注意事項を記載するのに使っている。これは Devin の振る舞いについての著者の説明であり、仕様上の主張ではない。
- 出力は固定の形式で求められる。優先度ごとにグループ化された指摘で、それぞれに具体的な修正案が付き、さらに「良い点」の節がある。著者は、結果を素早く処理できるのは指摘そのものではなく、この固定された形式のおかげだとしている。
- 精度の低い AI レビュアーは、むしろ逆効果だと述べられている。ノイズが蓄積し、やがて開発者がレビューコメントをまったく読まなくなるからである。著者は、継続的なプロンプトの調整と知見の蓄積を、この実践の改良ではなく前提条件として提示している。
- AI レビューは、リリース直前やホットフィックスのように速度が重要な場面では邪魔になるとされ、著者は concurrency の設定とラベルによるスキップを運用上の答えとして挙げている。
- 応答の遅延は当初は大きかったが、エージェントがプロジェクトのコンテキストを蓄積するにつれて改善した。ただし著者は、最初のセッションは依然として遅いままだと報告している。これは 1 つのチームの観察であり、測定されたベンチマークではない。
- 記事は特定の作業を人間のために残している。レビューを通すかどうかの判断、その理由の言語化、そしてエンジニアリング以外のステークホルダーへの設計判断の説明である。また、合否の判断の背後にある理由を PR 上に記録すること自体が、共通理解を蓄積する手段として行う価値があると論じている。
背景
この記事は、エージェント型コードレビュー に関するこの wiki の他の一次報告と並ぶものである。このチームのアプローチを特徴づけるのは、エンジニアリングの労力をどこに注いでいるかである。エージェントのアーキテクチャではなく、単一のエージェントが読み込む 2 つのファイルを絞り込み、コミットすることに注いでいる。
著者はこの視点の限界について明確である。提示される根拠はチーム自身の経験だけであり、精度の数値は示されず、改善策は意図として述べられている。記事がレビュー文化について行っている別の観察、すなわち人間のレビュアーの間で言い回しが異なることが避けられるはずの摩擦を生んでおり、統一された形式がそれを和らげるかもしれないという観察は、チームが測定したものではなく、期待される効果についての仮説として示されている。
著者はまた、Web ベースのコードレビュープラットフォームとして説明される Devin の新しい機能 Devin Review にも触れ、ここで用いた API 駆動のアプローチと比較する意向を述べている。比較の結果は報告されていない。