Devin × Renovate 運用効率化の第一歩 : 一次レビューをAIに任せてみた話

はじめに
概要
対象読者
DevinにPRレビューを任せてみた結果
Devinでレビューさせる対象PRの選定基準
プロンプト設定
- プロンプト定義
Devinの2パターンの運用
- Slackから実行
- Playbooksから実行
コスト
Devinは実務で使えるか
今後の運用方針
最後に
- 弊社の各事業部でエンジニアを求めています！

はじめに

こんにちは。PLEXでPLEX JOBの開発を行っている田中です。
前回は、同じ開発メンバーの小松さんが「DevinにE2Eテストさせてみる」という記事を執筆しましたが、今回はその続編として、Devin活用シリーズ第2弾をお届けします！

概要

Devinの導入を検討した背景としては、チーム内で開発効率を高める手段として、Devinを活用したいという声があったためです。
私の所属しているPLEX JOBチームでは、1スプリント(1週間)の中で約10%程度を技術的負債の解消に割り当てています。
また、弊社ではライブラリの依存関係の更新にRenovateを採用しており、対応もその一環になっています！

Renovateをマージする際には、一般的には以下のようなプロセスを踏む必要があります。

①自動更新対象のパッケージに関して、該当バージョンのリリースノートを確認し、破壊的変更が含まれていないかを確認する
②破壊的変更がある場合は、プロジェクトのコードに影響があるかどうかを調査する
③影響があると判断した場合には、既存の動作を維持するためにソースコードの修正や対応を行う

①の破壊的変更がなければ、それほど時間は掛からずにマージが可能と判断できますが、③まで作業を行った場合は、影響範囲によってはかなりの工数がかかることになります。
そこで今回、Devinに一次レビューを依頼し、「マージしても問題ないか」の判断材料を挙げてもらうことで、開発者の負担を軽減できるのではないかと考え、試してみることにしました。

対象読者

Devinを使ったことはないが、実際にどこまで使えるのか興味がある方
AIを活用して日々の業務の時短を行いたい方
Renovateをチーム開発に導入しているが、PRのレビュー対応が負担になっていると感じている方

DevinにPRレビューを任せてみた結果

プロンプトや具体的な指示の出し方については、以下の記事を参考にしつつ、今回の用途や対象となるリポジトリに合わせて、個別にカスタマイズを行いました。

developers.freee.co.jp

drbのマイナーアップデートになりますが、Devinの一次レビューをRenovateのPRにコメントさせてみました。次の観点で、十分な精度のあるアウトプットが得られたと感じています。

視覚的にレビュー内容が見やすい
テストの実行結果が対象の件数を明記した上で、全テストが成功していることが分かる
リリースノートやCHANGELOGの破壊的変更を確認し、分析した上でマージ可能なことが分かる

Devinでレビューさせる対象PRの選定基準

対象となるPRの条件

比較的ボリュームの小さいライブラリかマイナーアップデートのライブラリを対象

対象のPRに対するDevinの役割

フロントエンド
- 破壊的変更の調査
バックエンド
- 破壊的変更の調査
- アップデート後のローカル環境RSpecが通るかの確認
  - テストが通らない場合は、失敗しているテストケースと修正案まで提示

担当者の対応事項 / マージOKかの判断基準

フロントエンド
- リグレッションテストを行い問題がないこと
バックエンド
- 必要があればリグレッションテストを行い問題がないこと

プロンプト設定

Devinの回答精度を向上させるには、何よりプロンプトのチューニングが一番重要です。
DevinはOpenAIのGPT-4をベースに設計されています。
そのため、Open AIが出しているベストプラクティスをもとにプロンプトのチューニングを行いました。

どれも重要ですが、私が特に気を付けていたのは下記になります。

構造を理解しやすいように、コンテキストを明確に区切る
具体的なすべきことや例を提供する
欲しい出力形式を明確にする

これらのポイントを意識することで、回答精度は大きく向上しました！

プロンプト定義

Devinに的確な一次レビューを行ってもらうため、以下のようなバックエンド用のプロンプトを用意しました。

## 対象PR

(URLを入力する)

## 注意事項

- 回答はすべて日本語で行う
- 実際の実装に影響がなければ破壊的変更への対応が不要な分、レポートは簡潔に表現する
- あらゆる一次情報源（コード、コミット履歴、変更履歴等）を参照する
- 全ての引用・参照には必ず元のURLを添付する
- コミットとマージは行わない
- 最後に「対象PR」のコメントとして、以下のようにまとめる
  - (Devinが過去に書いたコメントの中で見本となるリンクを追加)


## 依頼内容

- 「対象PR」の依存関係更新に問題がないかの確認を行う
- 「対象PR」のタイトルからでなく、ファイルの更新内容を元に調査を行う
- 現在のバージョンと更新後のバージョン間の破壊的変更(breaking changes)を確認する
- CIが失敗している場合は、CIを直すためにローカルで検証し、コミットは行わず修正案の提出だけをする
- バージョン更新後の動作確認を行う
- バージョン更新後docker compose run --rm web bundle exec rspecを実行してRSpecのテストが問題ないかの確認を行う

## 破壊的変更への対応
破壊的変更が見つかった場合：

- 具体的な実装パターンへの影響例（ある場合は実際のコード例）
- 互換性維持のための具体的なコード修正案
- プロジェクト全体への影響度合い
- ただし、ライブラリのバージョンアップデートだけで問題が解決する場合は修正案不要

## レビュー結果の提示

- 必ず単一のコメントにまとめて提供
- 結論を最初に明示（承認または修正必要）
- 調査に使用した全てのドキュメント・ソースへの直接リンク
- コード例はマークダウン形式で、行番号参照付きで
- 分析は事実に基づき、重要な問題に集中

## 調査結果 : 

- 下記の観点で最後にまとめる
    - 結論
    - 脆弱性の詳細
    - パッケージ更新の適切性評価
    - プロジェクトへの影響
    - 調査方法
    - 参考リンク
- 調査結果は「対象のPR」コメントする

フロントエンド側のプロンプトは、破壊的変更の調査のみに限定しているため、RSpecのテスト確認の一文を削除して使用しております。

Devinの2パターンの運用

Slackに直接プロンプトを入力して実行
Playbooksからマクロを呼び出して実行

Slackから実行

Slack上で「@Devin」を入力した上で「プロンプト定義」のプロンプトを入力します。
「対象PR」のURLだけはそれぞれのリンクを貼り付けて実行するようなイメージになります。

Playbooksから実行

Playbooksとは、繰り返し実行されるタスクのプロンプトを定義するための機能になります。
作成したPlaybooksには「プロンプト定義」のプロンプトと同じものを貼り付けします。

「対象PR」

{{ pr_url }}

「対象PR」のURLを貼り付けるところだけ動的にしますので、この部分だけ修正が必要です。

その上でPlaybooksから「Use Playbooks」ボタンを押下し、以下のような画面で入力を行うことで実行できます。

好みになりますが、Slackから実行する時の方が、直に貼っている分、プロンプトの内容をより網羅的に回答している印象です。 Playbooksはコピペのミスがなくなったり、入力のテキストが少ないという利点があるので、両方試してみて使い勝手が良い方法を導入して頂ければと思います。

コスト

Devinを使う上でACUでどれくらい一つのタスクで金額が消費されたかの目安を知ることが重要です。
ACUとは、Devinが作業を行う際に消費する計算リソースの単位になります。

実際にどれくらい使ったかはDevinのUsage Historyでセッションごとに確認することができます。
弊社ではTeamプランを契約しており、1ACUあたり2ドルかかります。
おおよそ軽いRenovateなら1〜2ACU(300円~600円)ぐらいに収まります。
この程度のコストであれば、試してみる価値は十分にあると感じています。

Devinは実務で使えるか

結論としては、範囲を限定的にすれば実務で使えるかなと思いました。
例えば画面のUIの確認はDevinの苦手な分野かなと考えています。
Material UIのメジャーアップデートでプレビュー環境でアイコンの表示崩れや画面の動作確認などもさせてみましたが、網羅性にはやや疑問が残る印象でした。
結果としてフロントエンドは、作業者が実際にリグレッションテストを行うべきかなと思い、破壊的変更のレビューのみに絞りました。

とはいえ、Devinの一次レビュー活用は、Renovateの対応工数を削減する選択肢としてはかなりアリかなと思いました！

今後の運用方針

今回は私が中心となって検証を行いましたが、来月からは運用ルールを整備し、Renovate対応に関してはDevinによる一次レビューを必須とする試験運用をPLEX JOBチーム内で開始する予定です。

具体的には、各メンバーに検証対象とするRenovateをアサインし、スプレッドシートにDevinの検証結果を記入してもらいます。
メンバーからの評価や所感を聞くことで更に改善できることも見えてくると思います。
後々はしっかり本格的な運用まで結びつけたいと考えています！

最後に

弊社では各事業部でエンジニアを募集しております！気になるポジションあればお気軽にお問い合わせください。一緒に働きましょう。

弊社の各事業部でエンジニアを求めています！