AIレビュー導入記：Devinと歩んだ “60%からのチューニング”
はじめに
言語やライブラリの定期的なアップデートが 「つい後回しになってしまう」「更新内容をキャッチアップする時間がない」 と思うことはありませんか？
Renovate や Dependabot などで更新用の Pull Request 作成は自動化できますが、それでも 人手で行う作業 が残ってしまいます。
必要な作業の例
- リリースノートのリンクを探す
- Breaking Change や Deprecated が含まれているか確認する
- 含まれていれば、コードベースへの影響調査・判断・修正を行う
⚠️ 特に負荷が大きいのがメジャーバージョンアップ対応です。
マイナー/パッチは CI が通れば流せることもありますが、メジャー更新ではガッツリとした確認が必要になります。
こうした背景から、私は AIによる対応の自動化 を試みました。
✅ この記事のポイント
- Devin を使って Renovate PR の一次レビューを自動化
- 導入自体は簡単だったが、精度向上にはプロンプトの工夫が必要
- 精度が上がっても、人間によるチェックが前提
- 人間がチェックしやすいプロンプト設計により、作業精度向上・人的負荷低減を実現できた
Devin の導入と最初のプロンプト
Devin を使った PR レビューの自動化は、Cognition 社の公式ブログで紹介されています。
これを参考に、次のような流れで Devin がレビューする仕組みを作りました。
- PR 作成をトリガーに GitHub Actions を起動
- Actions 内で Devin API を呼び出し、セッションを開始
- セッション内で PR の情報を読み込み、レビューを実施
- レビュー結果を PR コメントとして投稿
最初に使用したプロンプトは以下のようなものでした。
🧠 最初のプロンプト
## 概要
Renovateによって自動生成されたプルリクエスト（PR）をレビューし、ライブラリのアップデートに伴う変更点の調査、コードへの影響評価、および必要な修正作業を提案してください。
## レビュー対象のRenovateのプルリクエストのURL
{URL}
## 手順
1. 指定されたRenovateのプルリクエストを開き、Renovateがどのライブラリをどのバージョンからどのバージョンへアップデートしようとしているかを確認します。
2. アップデート対象となった各ライブラリの公式ドキュメント、リリースノート、変更履歴（changelog）などを参照し、変更内容とアップデートするための修正事項（非推奨機能、破壊的変更など）を特定します。
3. 特定した変更内容と修正事項を、RenovateのプルリクエストにGitHubのコメント機能を使用して、「ライブラリ変更点の概要」として記載します。破壊的変更や対応が必須と思われる項目については太字で明記してください。
4. ライブラリの変更点を踏まえ、リポジトリ内の既存コード（アプリケーションコード、テストコード等）への影響範囲を調査します。具体的には、以下のような点を確認します。
- 廃止されたAPIや変更されたAPIの使用箇所
- 仕様変更に伴い、修正が必要となるロジック
- アップデートによる潜在的なバグやパフォーマンスへの影響
5. 調査したコードへの影響範囲と、推奨される修正対応について、元のRenovateのプルリクエストにGitHubのコメント機能を使用して、「コードへの影響と対応案」として記載します。
## 仕様
RenovateのPRには、「ライブラリ変更点の概要」と「コードへの影響と対応案」がコメントとして記載されていること。
## アドバイスとポイント
1. ライブラリの変更点を調査する際は、公式ドキュメントやリリースノート、Githubリポジトリを最優先の情報源として、根拠となる URL を提示してください。
2. コードへの影響調査は、直接的な利用箇所だけでなく、間接的な影響や全体的な動作への影響も考慮に入れてください。
3. GitHubへのコメントやプルリクエストの説明文は、他の開発者が変更の意図と内容を迅速に理解できるよう、明確かつ簡潔に記述してください。
4. 大規模な変更や判断に迷う場合は、途中で状況を報告し、指示を仰いでください。
## 禁止事項
1. Renovateが自動生成したプルリクエスト、および自身が作成した作業プルリクエストを、レビュアーの承認なしに勝手にマージしないでください。
2. ライブラリの公式ドキュメントを確認せずに、変更点や影響範囲を憶測で判断しないでください。
3. 元のRenovate PRのブランチに直接コミットを追加しないでください
このプロンプトを使って、Devin の PR レビューをスタートしました。
最初の成果と出てきた課題
Devin による PR レビューをスタートしたところ、おおよそ60%くらいは期待通りの動作をしてくれました。
ここで言う「60%」とは、リリースノートの取得や Breaking Change の検出など、ひと通りの作業をこなせた割合の感覚値です。
💡 上手く行ったこと
- リリースノートを添付してくれた
- Breaking Change を見つけて注意を促してくれた
- Breaking Change の影響を受ける箇所を説明してくれた
しかし、残り40%は手動でカバーする必要があり、課題がいくつか見つかりました。
❗ 見つかった課題
- Breaking Change や Deprecated の検出が漏れることがある
- 影響範囲の調査が甘い／そもそも実行されていない
- 一部のライブラリが解析対象として認識されていない
- コメントのフォーマットがバラバラで必要な情報を見つけづらい
初期のプロンプトでは、「動いてはいるけれど運用には乗せづらい」という状態でした。
対応その1: プロンプトチューニング
先ほど挙げた課題に対して、プロンプトを調整することで1つずつ解消していきました。
どのようにプロンプトを調整したのかをまとめます。
Breaking Change や Deprecated の検出が漏れることがある
Breaking Change の事を「破壊的変更」、Deprecated を「非推奨」と日本語で指示していました。
しかし、リリースノートは英語表記のため、それぞれが指すものをこちらの想定通りに捉えてくれないことが原因のようでした。
そのため、「Breaking Change」「Deprecated」と英語で表現するようにしました。
また、「変更差分は Breaking Change や deprecated が含まれているかどうかに焦点を当てて調べる」ように強調しました。
✅ これにより、検出漏れが大きく減りました。
影響範囲の調査が甘い／そもそも実行されていない
コードベースの影響調査をするように以下のように強調しました。
「Breaking Change や Deprecated が含まれている場合、それらがコードベースに含まれているかを必ず調査してください」
✅ これにより、影響調査がしっかり行われるようになりました。
一部のライブラリが解析対象として認識されていない
Renovate が作成したPR概要欄には更新対象のライブラリの一部しか書かれておらず、それを信用してしまっていたのが原因でした。
「git diff コマンドでベースブランチとの差分を確認し、変更された全ての依存関係をリストアップしてください」と指示して、コードの変更差分に基づいて認識するようにしました。
✅ これにより、解析対象のライブラリを正確に把握するようになりました。
コメントのフォーマットがバラバラで必要な情報を見つけづらい
投稿フォーマットを以下のように指定し、「投稿フォーマットは次の通りで [] の中身を埋める形で投稿してください」という指示を行いました。
## [ライブラリ名]（[旧] → [新]）
### breaking change の有無
[無し✅ or 有り🚨]
#### 使用箇所の調査結果
[それぞれのbreaking changeに対して、コードベースでの使用箇所を調査した結果を記載]
### deprecated の有無
[無し✅ or 有り⚠️]
#### 使用箇所の調査結果
[それぞれのdeprecatedに対して、コードベースでの使用箇所を調査した結果を記載]
### その他、主な変更内容
[変更概要]
「フォーマットに則って記載してください」という指示ではフォーマットが無視されてしまいましたが、「[]の中身を埋める形で投稿してください」とするとフォーマット通りにコメントしてくれました。
✅ フォーマットを定めて人間が注目すべき箇所を固定化したことで、確認しやすくなりました。
こうしたチューニングによって、作業範囲の網羅率や指摘制度は一定レベルまで改善できました。
🤔 それでも残った課題感
- Devin(LLM) の出力は決定論的ではないので、人間のチェックは依然として必要
- Devinにやらせること（求めること）が増えると、何がどこまで出来ているか確認するのが大変
こうした課題に対応するため、人的介入をしやすいプロンプト設計が重要だと感じました。
対応その2: 人的介入しやすいプロンプト設計
Devin の出力結果を人間がチェック・サポートしやすくするために、作業フローと各工程でのチェックポイントを整理しました。
🗺 作業フロー
プロンプトの全体像を、図で整理しました。
🔍 各工程でのチェックポイント
各工程で Devin に求めることと、人間が確認すべきポイントを表にまとめました。
| No | 工程 | Devin に求めること | 人間が確認すること |
|---|---|---|---|
| 1 | 更新対象の依存関係を特定 | PR 内の更新対象を正確に抽出 | - |
| 2 | リリースノートの検索 | リリースノート URL の検索、記載 | 更新対象に漏れがないか リリースノートが全て添付されているか |
| 3 | Breaking Change / Deprecated の有無確認 | 有無のチェック 有れば要点の記載 |
抽出漏れがないか 要点が正確か |
| 4 | コードベースへの影響調査 | 影響調査 影響有無の判断 |
影響調査の漏れがないか |
| 5 | 修正方針の作成 | 修正案の提示 | 方針の妥当性 |
| 6 | 最終結果の提示 | 修正作業の要否判断を提示 | 判断の妥当性 |
このように工程を分けてDevinに依頼し結果を出力したことで、人間は Devin の作業をトレースすることができ、成果物のチェックがしやすくなり、誤っている所が有ればそこからフォローに入りやすくなりました。
🧠 プロンプト
上記の整理を踏まえて作成したプロンプトが以下です。
更新版のプロンプト
## 概要
あなたは依存関係更新の影響分析とリスク評価を専門とするテクニカルレビュアーです。
あなたの役割は、Renovateによって自動生成されたプルリクエストのレビューを行うことです。
Release Note, Release History に記載されている内容から breaking change/deprecated の検出、既存コードへの影響範囲の特定に精通しています。
具体的には以下のことを行います。
- Release Note, Release History の内容を読んで、breaking change や deprecated が含まれているかどうかの調査を行う
- breaking change や deprecated が含まれている場合、既存コードに影響を及ぼすものかどうかコードベースを調査する
- 既存コードに影響を及ぼしている場合、コードの修正提案を行う
## 対象情報
- **リポジトリ**: ${{ github.repository }}
- **PR番号**: #${{ github.event.pull_request.number }}
- **PR URL**: ${PR_URL}
## GitHubへのコメント投稿方法
GitHub CLI (\`gh\`) コマンドまたはGitHub REST APIを使用して、PR #${{ github.event.pull_request.number }} にコメントを投稿してください。
## 実行手順
以下のフェーズ1からフェーズ4までを順番に実行してください。
### フェーズ1: 更新対象の特定
このフェーズでは、更新対象となる依存関係を特定してください。
このフェーズで得た情報をフェーズ2で使用するため、出力結果をtmpファイルに記録してください。
1. リポジトリ ${{ github.repository }} をローカルにクローンし、PR #${{ github.event.pull_request.number }} のブランチをチェックアウトしてください。
2. git diff コマンドでベースブランチとの差分を確認し、変更された全ての依存関係をリストアップしてください。
3. リストアップした依存関係に対して、旧バージョンと新バージョンを正確に記録してください。
## フェーズ2: 変更内容に関するドキュメント調査
このフェーズでは、更新対象の依存関係について変更された内容を把握するための情報を調査してください。
このフェーズで得た情報をフェーズ3で使用するため、出力結果をtmpファイルに記録してください。
1. フェーズ1で出力された更新対象の各依存関係について、変更差分を把握するためのドキュメント（Release Note, Release History）を探してリストアップしてください。
2. リストアップした内容を Pull Request のコメントとして投稿してください。
### フェーズ3: 変更内容のレビュー
このフェーズでは、次のstep1~3を更新対象の依存関係毎に実行してください。
### step1
フェーズ2で出力した変更差分を上から順番に読み込んで、『breaking change』や『deprecated』が含まれているかどうかに焦点を当てて調べ、結果を記録してください。
### step2
『breaking change』や『deprecated』が含まれていない場合、それらが含まれていない旨を Pull Request のコメントとして投稿してください。
投稿フォーマットは次の通りで、[変更概要]のみを埋める形で投稿してください。
---
## [ライブラリ名]（[旧] → [新]）
### breaking change の有無
無し✅
### deprecated の有無
無し✅
### 主な変更内容
[変更概要]
---
投稿後、次の依存関係のレビューを step1 から開始してください。
### step3
『breaking change』や『deprecated』が含まれている場合、それらがコードベースに含まれているかを必ず調査してください。
例えば、環境変数 `X` が非推奨になったのであれば、コードベースに環境変数 `X` の使用箇所を調査してください。
調査の結果、影響を受ける箇所がある場合は修正案を提示してください。
修正案を提示するにあたって、マイグレーションガイドがあればその内容に従ってください。
提示した内容を Pull Request のコメントとして投稿してください。
投稿フォーマットは、次の通りで`[]`の中身を埋める形で投稿してください。
---
## [ライブラリ名]（[旧] → [新]）
### breaking change の有無
[無し✅ or 有り🚨]
#### 使用箇所の調査結果
[それぞれのbreaking changeに対して、コードベースでの使用箇所を調査した結果を記載]
### deprecated の有無
[無し✅ or 有り⚠️]
#### 使用箇所の調査結果
[それぞれのdeprecatedに対して、コードベースでの使用箇所を調査した結果を記載]
### その他、主な変更内容
[変更概要]
---
**重要:**
- 次のライブラリに進む前に、必ずコメントを投稿してください。
- コメント投稿後は、必ず投稿が成功したことを確認してから次に進んでください。
- **同じライブラリについて2回コメントしないでください**
- 各ライブラリは1回のみレビューしてください
- 既に投稿したライブラリのリストを記録し、重複を防いでください
### フェーズ4: 最終結果のサマリー投稿
更新対象の全依存関係についてコメントの投稿が完了したら、以下を実行してください。
1. **PRのコメント履歴を確認**: あなたが投稿した各ライブラリのレビューコメントを読み直してください。
2. **結論を集約**: 各ライブラリで『breaking change』や『deprecated』が含まれているかを確認してください。
3. **サマリーコメントを投稿**: 以下の形式で最終結果を Pull Request のコメントとして投稿してください。投稿フォーマットは、次の通りで`[]`の中身を埋める形で投稿してください。
---
## 📋 Renovate PR レビューサマリー
このPRでは [N個] のライブラリがアップデートされます。
### 🚨 breaking changeが含まれるもの
- [ライブラリ名] [旧] → [新]
### ⚠️ deprecatedが含まれるもの
- [ライブラリ名] [旧] → [新]
### ✅ breaking change、deprecatedが含まれないもの
- [ライブラリ名] [旧] → [新]
## 総合結論
[総合結論を記載]
## 備考
詳細は各ライブラリのレビューコメントを参照してください。
Devinセッション: [session URL]
---
## 重要なルールと制約
### 必須ルール
1. **絶対にコミットやプッシュをしないでください** - あなたの役割はレビューとコメントのみです
2. **ユーザーに確認を求めないでください** - このタスクは自動実行されます
3. **ユーザーメッセージを待たないでください** - すべての手順を自律的に実行してください
4. **変更点や影響範囲の調査は必ず公式ドキュメント等を確認し、判断に使用した情報のURLを調査結果として記載してください**
### 禁止事項
1. **Renovateが自動生成したPRを、レビュアーの承認なしにマージしないでください**
2. **Renovate PRのブランチに直接コミットを追加しないでください**
## 最後に
すべての手順を完了したら、作業を終了してください。大規模な変更で判断に迷う場合でも、調査結果をコメントに記載し、人間のレビュアーに判断を委ねてください。
作業フェーズを1~4に区切ってそれぞれのフェーズで出力するようにしたことで、依頼する作業が小さくなり、精度を上げやすくなりました。
特に、1つの長大なプロンプトにすべてのタスクを詰め込むのではなく、目的ごとに分割した設計にしたことで、Devin の処理結果が工程単位で明確になり、人間が途中からレビューや補完に入るのも容易になりました。
チューニングしたい工程があればその部分のプロンプトだけを調整すれば良く、問題の切り分けがしやすくなりました。
上記では全ての指示を一つのプロンプトとして紹介しましたが、プロンプトが安定してきたら PlayBook を作成したり、細かい指示は knowledge に登録するなど、より自分たちに合ったやり方に調整できると思います。
🎯 最終的な成果事例
最後に、実際に Devin を使ってどのような成果が出たのかを紹介します。
Google Cloud Pub/Sub の Go SDK のメジャーバージョンアップ対応（v1 → v2）を例に、作業の様子を説明します。
更新PRの作成
まず、Renovate によって pubsub v2 を依存関係として追加する PR が作成されます。
主なファイル差分は go.mod に pubsub v2 バージョンが追加されました。
元々v1に依存しており、その依存関係は残ったままとなっています。
cloud.google.com/go/pubsub v1.50.1
+ cloud.google.com/go/pubsub/v2 v2.3.0
更新対象の特定・リリースノートの検索
PR が作成されたタイミングで github actions が走り、Devin セッションが開始されます。
最初に Devin が出力するのは、変更差分に関するドキュメントの調査結果です。
v2.0.0 から最新の v2.3.0 までのリリースノートと、v1 から v2 へのマイグレーションガイドを添付してくれました。
Breaking Change / Deprecated の有無、影響調査、修正方針の提示
次に、リリースノートを元に Breaking Change / Deprecated の有無を調べてくれました。
Breaking Change があり、その API を使っている箇所がコードベースに存在するため、移行方法を説明してくれました。
最終結果の提示
最後にレビューサマリーが投稿されました。
今回は更新対象のライブラリが1つなのでサマリーの有効性を感じづらいですが、Breaking Change を含むライブラリがあること、その影響の概要を説明してくれました。
私が実施した作業
Devin の一次レビューを踏まえて、私は主に次のことを行いました。
- 添付のマイグレーションガイドを読んで理解する
- Devin の影響調査結果の妥当性を判断
- Devin の修正方針の妥当性判断
- 別の Devin セッションで修正を実施
【No.1】
まず、マイグレーションガイドが添付されていたことが有り難く、探すというひと手間を省略できました。
次に、マイグレーションガイドを読んでみると、Breaking Change が多数記載されており、どのような影響がありどう修正するかを正確に判断するのは時間がかかる印象でした。
しかし、Devin が説明してくれた変更概要などを参考に読み進めたことでその時間を短縮することができました。
【No.2】
Devin の影響調査はほぼ正確でしたが、修正対象ファイルを1つ見逃しており私の方でフォローしました。
【No.3】
Devin の修正方針はほとんど文句の無い仕上がりでした。
【No.4】
影響調査結果と修正方針を元に、別の Devin セッションで修正作業を依頼し、手動介入なしの一発で修正を完遂することができました。
💰 Devin にかかる費用
1回のPRレビューで消費するACUは約2.0でした。
🧾 まとめ
Devin を導入した直後は、「60%くらいは動くけど、信頼して任せるには足りない」 というのが正直な印象でした。
しかし、プロンプトチューニングによって精度を上げ、誤りがあった場合も人間がフォローしやすい構造にしたことで、実運用に組み込めるレベルまで引き上げられたと感じています。
同じような課題を感じている方にとって、この記事が何かの参考になれば幸いです。
Discussion