こんにちは！Androidエンジニアの関根です。
今回は、RenovateのPR対応を自動化する取り組みについてご紹介します。
はじめに
皆さんの職場では、Renovateを使いこなせていますか？依存関係を最新に保つ上で、本当に頼もしい存在ですよね。
弊社のAndroidチームではRenovateのPullRequestを定例で確認し、マージの判断をする運用は行っていますが、だんだんとPullRequestが溜まってしまっていました。
影響の少ないアップデートならその場で判断し、マージできますが、調査が必要な場合に、先送りしてしまうということが起きていました。
「影響範囲の調査が必要だな…」「後でやろう…」
そう思っているうちに、PRはどんどん溜まっていき、上限数に達してしまうということが定常化していました。
この記事では、そんな「調査待ちRenovate PR」の渋滞を、今話題のAIエージェントDevinを使って解消する実践的なノウハウをご紹介します。
Part 1：実現したこと
まずは、この仕組みを導入したことで、私たちのチームにどんな変化があったかをお見せします。
これまで先送りしがちだった「調査が必要なPR」。ここにDevinが介在することで、人間は「Devinからの調査報告をレビューするだけ」 になりました。
システムの流れ
この自動化システムは、以下のような流れで動作します：
- Renovateが依存関係の更新を検知し、PullRequestを作成
- GitHub ActionsがPRの作成を検知し、Devin APIにリクエストを送信
- DevinがPlaybookを読み取り、以下のレビューを実施
この一連の流れでのレビューには、以下のような情報が含まれます：
ライブラリ変更点の概要
- バージョン間の主要な変更点
- 破壊的変更の有無
- 新機能や非推奨機能の情報
コードへの影響と対応案
- 影響を受ける箇所の特定
- 推奨される修正方法
- テストが必要な範囲
具体的なサンプルをお見せすると、以下の通りです。こちらは実際のレビュー内容を生成AIでマスキングしたものです。
ライブラリ変更点の概要
### com.example.library:core 2.1.0 → 2.2.0
**リリース日**: 2024年3月15日
**変更内容**:
- **バグ修正**: 特定の条件下でメモリリークが発生する問題を修正
- **パフォーマンス改善**: データ処理の最適化により、処理速度が約20%向上
**詳細**:
- 公式ドキュメント: https://example.com/library/docs/releases/2.2.0
- メモリリークの修正により、長時間の運用時の安定性が向上
- 破壊的変更はありません
**影響レベル**: 中（バグ修正とパフォーマンス改善）
## コードへの影響と対応案
### 影響範囲の調査結果
ライブラリの使用箇所を調査した結果：
**使用箇所**:
- `src/main/java/com/example/app/ImageProcessor.kt` のみ
**現在の使用方法**:
val processor = HogeProcessor()
val data = processor.getData(source)
コードへの影響と対応案
✅ **影響なし**:
- 現在のコードは基本的なメタデータ読み取りのみを行っており、修正対象の機能は使用していません
- 高度な機能（今回修正された部分）は使用していないため、影響はありません
- 既存の実装は基本的な機能のみを使用しており、安全です
### 対応案
**推奨対応**:
- ✅ **コード修正不要** - このアップデートは安全に適用可能です
- ✅ **テスト実行** - 念のため既存のテストを実行して動作確認を行うことを推奨します
- ✅ **マージ可能** - 破壊的変更がないため、レビュー後にマージして問題ありません
**理由**:
1. バグ修正のみで新機能や仕様変更はありません
2. 修正対象の高度な機能は使用していません
3. 既存の基本的な機能に影響はありません
このアップデートにより、将来的に高度な機能を使用する際の安全性が向上します。
このように、人間が行っていた調査作業をDevinが自動化することで、レビュアーは「調査結果の確認と判断」に集中できるようになりました。
Part 2：実践！自動化システムの作り方
今回はDevinとGitHubActionsの機能のシンプルな組み合わせで実装しており、以下の2つの実装で完結します。
- DevinにPlaybookを設定する
- GitHubActionsからDevin APIにリクエストを送信
まずは比較的DevinのPlaybookを採用した理由から解説をさせていただきます。
Devin Playbook
docs.devin.ai
Playbookを選んだ理由
DevinのPlaybookを採用した理由は、RenovateのPR対応が以下のような定型的な作業の繰り返しになるためです：
更新内容の確認
- ライブラリの変更履歴やリリースノートの確認
- 破壊的変更の有無の確認
コードベースへの影響調査
- 更新対象のライブラリを使用している箇所の特定
- 影響範囲の特定と評価
必要に応じた修正作業
このような明確な手順と繰り返しの作業は、まさにDevinのPlaybookの得意分野だと考えたためです。Playbookは以下の内容で定義しています。
## 概要
Renovateによって自動生成されたプルリクエスト（PR）をレビューし、ライブラリのアップデートに伴う変更点の調査、コードへの影響評価、および必要な修正作業を実施します。
## ユーザーに必要なもの
- レビュー対象のRenovateのプルリクエストのURL
- (もしあれば) 対象ライブラリに関する特記事項や注意点
## 手順
1. 指定されたRenovateのプルリクエストを開き、Renovateがどのライブラリをどのバージョンからどのバージョンへアップデートしようとしているかを確認します。
2. アップデート対象となった各ライブラリの公式ドキュメント、リリースノート、変更履歴（changelog）などを参照し、バージョン間の主要な変更点（新機能、非推奨機能、破壊的変更、バグ修正など）を特定します。
3. 特定したライブラリの変更点を、元のRenovateのプルリクエストにGitHubのコメント機能を使用して、「ライブラリ変更点の概要」として記載します。破壊的変更や対応が必須と思われる項目については特に明記してください。
4. ライブラリの変更点を踏まえ、リポジトリ内の既存コード（アプリケーションコード、テストコード等）への影響範囲を調査します。具体的には、以下のような点を確認します。
* 廃止されたAPIや変更されたAPIの使用箇所
* 仕様変更に伴い、修正が必要となるロジック
* アップデートによる潜在的なバグやパフォーマンスへの影響
5. 調査したコードへの影響範囲と、推奨される修正対応について、元のRenovateのプルリクエストにGitHubのコメント機能を使用して、「コードへの影響と対応案」として記載します。
6. コードの修正が必要だと判断された場合、Renovateのプルリクエストのブランチ（例: `renovate/ライブラリ名-2.x`）をベースブランチとして、`fix/renovate-対応内容` の命名規則で新しい作業ブランチを作成します。
7. 作成した作業ブランチで、ステップ5で特定した影響箇所に必要なコード修正作業、および関連するテストコードの修正や追加を行います。
8. 全ての修正作業とテストが完了したら、作業ブランチから元のRenovateのプルリクエストのブランチに向けて、新しいプルリクエストを作成します。
* 新しいプルリクエストのタイトルには、例：「Fix: Renovateによる[ライブラリ名] vX.Y.Zへのアップデート対応」のように、内容がわかるように記載します。
* 新しいプルリクエストの説明文には、元のRenovateのプルリクエストへのリンク、実施した修正内容の概要、およびレビューしてほしいポイントを明記します。
## 仕様
1. RenovateのPRには、「ライブラリ変更点の概要」と「コードへの影響と対応案」がコメントとして記載されていること。
2. 必要な修正作業が完了した場合、適切なターゲットブランチに対して新しいプルリクエストが作成されていること。
3. 新しいプルリクエストは、レビュアーによる確認と承認が行われるまではマージされない状態であること。
## アドバイスとポイント
1. ライブラリの変更点を調査する際は、公式ドキュメントやリリースノートを最優先の情報源としてください。フォーラムやIssue Trackerの情報は補助的に使用してください。
2. コードへの影響調査は、直接的な利用箇所だけでなく、間接的な影響や全体的な動作への影響も考慮に入れてください。
3. GitHubへのコメントやプルリクエストの説明文は、他の開発者が変更の意図と内容を迅速に理解できるよう、明確かつ簡潔に記述してください。
4. 作業ブランチ名は、そのブランチの目的が容易に理解できるような命名規則に従ってください。
5. 大規模な変更や判断に迷う場合は、途中で状況を報告し、指示を仰いでください。
## 禁止事項
1. **Renovateが自動生成したプルリクエスト、および自身が作成した作業プルリクエストを、レビュアーの承認なしに勝手にマージしないでください。**
2. ライブラリの公式ドキュメントを確認せずに、変更点や影響範囲を憶測で判断しないでください。
3. 元のRenovate PRのブランチに直接コミットを追加しないでください
Step 1：DevinのPlaybook準備編
さて、ここからは具体的な実装方法です。
この自動化システムの心臓部となるのが、Devinに与える指示、つまりPlaybook（プロンプト）です。
「Devinへの最適な指示なんて、どうやって作ればいいんだ…」と悩みますよね。
ご安心ください。私は、AI（Gemini）に作ってもらいました！
具体的には、Devinの公式サイトにあるPlaybookのサンプルと、今回Devinに「やりたいこと」を箇条書きにしたものをGeminiに渡し、Playbookの形式に合うようにプロンプトを生成してもらったのです。
使用したDevin Playbookサンプル
docs.devin.ai
Geminiに渡したプロンプト
以下が、実際に私がGeminiに渡したプロンプトの全文です。
構造としては、「Geminiへの指示」「Devinにやってほしいこと」「出力形式のサンプル」の3つを伝えています。
# あなたへの指示
生成AIへのプロンプトを考えてください。
「やりたいこと」を達成するための指示を「サンプル」を参考に生成してください。
# やりたいこと
- PRで変更されたライブラリの更新内容について調査する
- ライブラリの更新内容が明確になったら、コード内変更への影響を調査する
- 必要に応じて、修正作業を行う
# サンプル
## 概要
Rマークダウンノートブックを使用してデータサイエンスのチュートリアルを作成します。
### ユーザーからの必要事項
- データセットへのリンク（CSVファイルの添付またはKaggleリンク）
- データサイエンスチュートリアルを作成するための具体的なタスク
### 手順
1. ユーザーから提供されたデータセットをダウンロードします。
- 必要に応じて、Kaggle CLIを使用してデータセットをダウンロードします。これには認証情報は必要ありません。
2. `data_science_tutorial.Rmd` というタイトルのRマークダウンノートブックを作成します。
3. 中間コードを記述および保存するために `tmp.Rmd` ファイルを作成します。
4. `data_science_tutorial.Rmd` ファイル内に5つの主要なセクションを作成し、`tmp.Rmd` ファイルから以下の内容を含むコードを追加します。
- **データセットの統計**: データセットの統計的要約を生成します。
- **EDA（探索的データ分析）**: 提供されたデータに対して棒グラフと散布図を作成します。
- **訓練データとテストデータの分割**: データを80:20の比率で分割します。訓練データとテストデータを保存します。
- **機械学習モデルの訓練**: 訓練が完了したらモデルを保存します。
- **保存されたモデルでの推論**: 保存されたモデルをロードし、ユーザーが指定した評価指標を使用してテストセットでのパフォーマンスを評価します。
5. コードの記述が完了したら、各セクションに簡単な説明を追加します。
6. RマークダウンノートブックをHTML形式に変換します。
7. 最終的なRマークダウンノートブック、HTMLファイル、保存されたモデル、およびテストデータをユーザーに送信します。
### 仕様
1. RマークダウンノートブックとHTMLファイルをユーザーに送信してください。
2. 保存されたモデルとテストデータをユーザーに送信してください。
### アドバイスとヒント
1. パッケージがすでにインストールされている場合は、再インストールしないでください。
2. このタスクを完了するためにRStudioへのサインインは必要ありません。
3. 各セクションのコードを追加した後、ノートブック全体を実行してください。
### 禁止事項
1. `data_science_tutorial.Rmd` ファイルを上書きしないでください。
このように、「正解の形」を具体的にサンプルとして見せてあげることで、AIは期待するアウトプットを非常に高い精度で生成してくれます。ぜひ皆さんも試してみてください。✨
Step 2：GitHub Actions連携編
次に、DevinとGitHub Actionsを連携させる具体的な実装方法について説明します。
ワークフローの概要
まず、RenovateのPRが作成されたときに自動的にDevinにレビューを依頼するワークフローを実装しました。
このワークフローは以下のような特徴を持っています：
- Renovateアカウントが
developブランチに対してPRを作成したときのみ実行
- 他のPRや他のブランチでは実行されない
- PRのURLをPlaybookのマクロと共に送信
実際の内容
name: Review by Devin on Renovate PR
on:
pull_request:
types: [opened]
branches:
- develop
jobs:
review-by-devin:
if: github.actor == 'renovate[bot]'
runs-on: ubuntu-latest
env:
DEVIN_API_KEY: ${{ secrets.DEVIN_API_KEY }}
PR_URL: ${{ github.event.pull_request.html_url }}
steps:
- name: Review by Devin API
run: |
JSON_PAYLOAD=$(cat <<EOF
{
"prompt": "!renovatepullrequest ${PR_URL}"
}
EOF
)
curl -X POST "https://api.devin.ai/v1/sessions" \
-H "Authorization: Bearer $DEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d "$JSON_PAYLOAD"
こちらのGitHubActionsがトリガーとなり、Devinのレビューが開始される流れとなります。
※現在は、他のチームと共有で使えるReusable Workflowが整備されたことで、このワークフローはそちらの呼び出しに置き換えています
Devin APIの連携
DevinのAPI連携で直面した問題と解決策について共有します。
API Keyの作成画面に表示されるサンプルコードでは、playbook_idをパラメータとして渡す方法が案内されています。しかし、この方法を試したところ、私の環境ではDevinがPlaybookを参照してくれないという問題が発生しました。
試行錯誤の結果、プロンプト内にPlaybookのマクロ（例: !your-playbook-macro）を直接記述する方法で、無事にPlaybookを読み込ませることができました。
この件についてDevinのサポートに問い合わせたところ、本来はどちらの方法でも動作することを意図しており、playbook_idパラメータが機能しない問題は修正するとの回答を得ました。
Thank you so much for the kind words, and we're thrilled to hear Devin is helping advance your development—means a lot to the team!
Also, really appreciate you flagging this. We do intend for both methods—passing playbook_id as a parameter and using a Playbook macro in the prompt—to work seamlessly. I'll check in with the team about why the first method isn't working as expected and get it fixed.
Thanks again for taking the time to share this!
Best regards,
もし同じ現象に遭遇した場合は、プロンプトに直接マクロを埋め込む方法を試してみてください。
Part 3： 上手くいったこと/上手くいかないこと/困ってること
ここまで、DevinとGitHub Actionsを連携させてRenovateのPRを自動レビューする仕組みの実装方法について説明してきました。しかし、実際に運用を始めてみると、予想外の効果や課題が見えてきました。このPart 3では、実際の運用で得られた知見や、より良い運用のために気をつけるべきポイントを共有します。
上手くいったこと
アップデートのマージ判断がスムーズになった
Devinが調査と対策を検討してくれるため、人間がやることは内容の正誤判断のみになりました。
このことで、「後で調査しよう」というステップがなくなり、定例を待たずにマージ判断を行えるようになってきました。
加えて、Devinが提示してくれた作業内容を、Devinに追加でお願いすることも試行しているところです。
これにより、調査から実装までを一気通貫で自動化できる可能性が見えてきました。
副次的な効果としてCI失敗も調査してくれる
当初の目的は「Renovate PRの影響範囲調査」でしたが、副次的な効果として嬉しい発見がありました。
それは、CIが失敗したPRに対しても、Devinが自動でエラー内容を読み解き、「〇〇が原因でテストが落ちています。□□を修正すれば通るはずです」といった具体的な対策まで提示してくれたことです。
このおかげで、失敗原因の調査という、また別の面倒な作業まで効率化できました。
特にAndroidではAndroid Gradle Pluginの更新が必要なものなどの、依存関係の更新が原因でビルドが失敗するケースが多々あります。このような場合に具体的な解決策を提案してくれます。
Devinの提案内容:
## ビルドエラーの詳細
### 1. Android Gradle Plugin バージョン不足
- 要求: Android Gradle Plugin 8.x.x以上
- 現在: 8.y.y
- 影響ライブラリ:
- androidx.navigation:navigation-compose-android:x.y.z
- androidx.lifecycle:lifecycle-viewmodel-compose-android:x.y.z
- androidx.lifecycle:lifecycle-runtime-compose-android:x.y.z
### 2. Compile SDK バージョン不足
- 要求: compileSdk xx以上
- 現在: compileSdk yy
- 影響: 上記と同じライブラリ群
## 必要な追加更新
このNavigation x.y.zアップデートを適用するには、以下の追加更新が必要です：
Android Gradle Plugin: 8.x.x → 8.y.y以上
Compile SDK: xx → yy
関連するlifecycleライブラリも同時にx.x.xxに更新される
## 推奨対応
### オプション1: 段階的アップデート
1. 先にAGPとcompileSdkを更新
2. その後でNavigation x.x.xを適用
### オプション2: 一括アップデート
- AGP、compileSdk、Navigation、Lifecycleを同時に更新
### オプション3: アップデート延期
- より安定したタイミングでの一括更新を検討
この作業はPlaybookで指示をしていないため、毎回必ず実行してくれるわけではないため、プロンプトの改善を考えています。
上手くいかないこと
指示した範囲外の判断は人間の役割
Devinは指示した範囲でしか作業をしてくれません。
ライブラリAのレビューをお願いした場合、ライブラリAとライブラリBに依存関係で問題が起きた場合、本来であればライブラリBの更新が望ましいという判断はDevinにはできないため、ライブラリAの更新で解決する提案になります。
具体例として、ライブラリBを更新することで必要なくなるはずの、「競合する設定をライブラリAからオプトアウトする」といったような変更が提案されました。
ここは人間が想像力を働かせて、より本質的な判断をする必要がある部分だと感じています。
困ってること
チームでの可視性に課題
普段はDevinにはSlackから指示を出しています。今回のようにDevinAPI経由で開始すると、WebUIから操作する必要があり、チームでの可視化に課題があります。
ここはCognition Support Teamに共有し、要望として伝えさせてもらいました。
まとめ
本記事では、AIエージェントDevinとGitHub Actionsを用いて、これまで手作業で行っていたRenovateのPR対応を自動化する具体的な方法をご紹介しました。
このアプローチによって、面倒な調査作業から解放され、より本質的な開発業務に集中できる時間が生まれます。
皆さんの日々の業務の中にも、きっと応用できる場面があるはずです。ぜひ、この記事を参考に、身の回りの小さな課題から自動化を試してみてはいかがでしょうか。
もし、もっと良い方法や面白いアイデアがあれば、ぜひSNSなどで教えていただけると嬉しいです。一緒にベストプラクティスを見つけていきましょう！
