DevinとDependabotが協業してパッケージの脆弱性対応をしてもらう仕組みづくり

こんにちは。UPSIDERでエンジニアをしているYutoです。

UPSIDERではCursorやClaude Codeをはじめとする各種AIコーディングツールを利用することができます。その中にはDevinも含まれており、日々の業務で利用しています。しかし、Devinには「なんでもこなしてくれる万能エージェント」ではなく「驚くほど上手くタスクを完遂させるパターン」と「かなり迷走した挙句、思い描いたものとはかけ離れた結果を出すパターン」があります。

その中でも比較的うまくいっていることを紹介します。

ライブラリのアップデートは大変

早速ですが皆さんは脆弱性対応のためにライブラリのアップデートを行ったことはありますか？脆弱性監視ツールを導入したものの、管理に時間を取られるようになり最終的に放置している経験があるのではないでしょうか？

またこれらのアップデートはただ闇雲にバージョンを上げればいいというものではなく一つ一つの警告に対して慎重に取り組まないと、思いもよらぬ事態に発展する可能性があります。

ライブラリをアップデートする際には下記の問題が発生します。

アップデートする対象のライブラリが他のライブラリと依存関係にあり、その互換性を保つ必要がある
メジャーアップデートなどで破壊的変更が発生する場合、アップデートのみならず実装の変更が必要になる

Dependabotが作成するPRをレビューするのは意外と手間がかかる

UPSIDERではライブラリの脆弱性管理にDependabotを使用しています。自動でライブラリごとにバージョン更新のPRを作成してくれるので大変便利ですよね。しかし、これらのPRは「何も考えずにただマージして終わりにできる」というものではなく以下のことを念頭に置いてレビューする必要があります。

アップデートするバージョンのリリースノートを確認して、破壊的変更があるかどうかを確認する
1で破壊的変更がある場合は、ソースコードのどの部分に影響があるかを調査する
2の調査の結果、影響があると判断された場合には振る舞いの変更が必要な箇所についてソースコードの修正が必要となる

1で破壊的変更がないと判断された場合は、それほど時間をかけずに「マージして対応完了」とできるのですが、2で調査を行い3で修正まで行う場合、影響範囲によっては想定以上の工数が発生してしまいます。

そこで「Devinに一次レビューをしてもらい、各開発者のレビュー負荷の軽減ができないか？」と考え、試してみることにしました。

DevinにDependabotのPRのレビューを依頼してみる

Devinにタスクを依頼する方法は下記の2通りがあります。

Slackで＠Devinをメンションして、依頼内容（プロンプト）を入力する
Playbooksを使って上記の依頼内容をコマンド化する

今回は2番目のPlaybooksを使う方法を試してみました。Playbooksとは繰り返し利用するプロンプトをあらかじめ定義しておくことができる辞書のような機能です。 DependabotのPRをレビューするタスクは単発ではなくアラートが存在する限り繰り返し依頼することを考慮し毎回長文のプロンプトを使うことは避けたかったため利用しました。

docs.devin.ai

実際にPlaybooksに記載しているプロンプトはこちらです。（UPSIDERには英語話者のエンジニアもいるので社内の誰でもわかるように日本語と英語の両方でプロンプトを記載しています。）

🔒 **Security‑Focused Dependabot PR Review** 🔒
You are a Principal Software Engineer specializing in security reviews.
Provide a thorough, bilingual analysis focused on breaking changes, compatibility, and an approval recommendation.
Please review the Dependabot security-fix PR at {{PR_URL}}. 

## Procedure

1. **Potential Breaking Changes / 破壊的変更の可能性** 
   - Analyze whether any dependency version bump could break existing functionality.  /既存の機能が動かなくなるような変更点がないか確認する
   - Investigate based on the contents of the file changes, not the PR title./PRのタイトルからではなく変更内容を基に調査を行う
   - Specific code fixes to maintain compatibility / 互換性維持のための具体的な実装を提案する
   - Overall project impact / プロジェクト全体への影響度を報告する
   - *Note:* If simply updating the library version resolves the issue, no code fixes are needed.  
     （ただし、ライブラリのバージョンアップデートだけで問題が解決する場合は修正案は不要）

2. **Recommendation for Approval / 承認の可否と理由**  
   - Based on the above, recommend **Approve** or **Request Changes**.  
   - 上記を踏まえて、「承認」または「修正依頼」の判断とその理由を示す

3. **Review Presentation / レビュー結果の提示方法**  
  - Provide as a single comment / 単一のコメントにする  
  - State the conclusion first (Approve or Requires changes) / 結論を最初に明示する（承認もしくは修正が必要か）  
  - Include direct links to all documents/sources used / 調査に使用した全てのドキュメント・ソースへのリンク を添付する
  - Code examples in Markdown with line numbers / 実装例はマークダウン形式でかつ行番号参照付きで提供する
  - Fact-based analysis focusing on critical issues / 分析は事実に基づき重要な問題だけに集中する  

4. **Bilingual Review Format / 日英レビュー例**  
   - Conclusion / 結論  
   - Vulnerability details / 脆弱性の詳細  
   - Evaluation of package update appropriateness / パッケージ更新の適切性評価  
   - Project impact / プロジェクトへの影響  
   - Methodology / 調査方法  
   - Reference links / 参考リンク  

## Advice & Pointers
- Make sure to use both Japanese and English in the review./ 回答には日本語と英語を使用する
- Post the investigation summary as a comment on the target PR. / 調査結果をPRのコメントに残す
- Refer to all primary sources (code, commit history, change logs, etc.). / 実装や過去のコミット履歴などのあらゆる情報源を参照する
- For every citation or reference, always include the original URL./全ての引用と参照には元のURLを添付する
Helpful facts here

## Forbidden actions
- DO NOT commit and merge PR you review. Human reviewers will make the final decision after your analysis./ 人間が最終的な判断を下すのでPRにコミットやマージは行わない

前述したプロンプトを使ってSlack上でDevinに依頼するにはこのように依頼します。

Hi @Devin
!review_dependabot
{{PR_URL}}

ここに登場している「!review_dependabot」は合言葉です。Playbooksでは合言葉に応じてどのPlaybooksを呼び出すかを設定することができます。Devinをメンションして設定した合言葉をメッセージ内に記載すると、それに対応したPlaybooksを使うという仕様です。これにより、Devinに「どのPlaybooksを使ってほしいか」を簡潔に伝えることができます。

SlackだけでなくDevinのプラットフォームにて「Playbooks > Use Playbook」を選択して利用することもできます。

Devinがレビューしてくれた結果、このようなコメントを残してくれました。

期待していたレビュー項目を網羅してくれており、コメントも日本語と英語の両方で残してくれています。

特に調査に関してはかなり上手くいってくれており、どのように調査し何を参考にしたかを明確に示しています。Devinが調査をしてコメントを残してくれていると、それ以降の人間によるレビューは格段に楽になります。

Playbooksを使わずにPRのレビューを依頼してみる

次にPlaybooksを使わない場合はSlackに前述のプロンプトを貼り付けて依頼してみて結果がどう異なるかを比べてみました。どちらも出力結果に大きな違いはなく、期待していた内容を記載してくれています。Slackに直接貼り付けた場合はプロジェクトの「どのファイルの何行目で使用されているか」も教えてくれました。リグレッションテストを行う際に、どこに注力すればいいのか明確になって便利です。

Majorアップデートを含んだPRのレビューを依頼してみる

最後にDependabotがMajorとラベル付けをした破壊的変更を含んだパッケージのPRを依頼してみます。前述の2つの例はどちらもMinorかPatchといった比較的影響度合いが低いパッケージのアップデートでした。しかし現実ではそのような変更を含んだパッケージの脆弱性対応を行わなければならないケースも多々あります。

その結果がこちらです。