以下の内容はhttps://tech.findy.co.jp/entry/2025/12/25/070000より取得しました。

AI時代のDependabot対応。手動からDevin、そしてClaude Code Actionへ

GenAI・LLM GitHub Actions Claude Devin

こんにちは、Findy Freelanceでフロントエンドエンジニアをしている主計（かずえ）です。

この記事は、ファインディエンジニア #3 Advent Calendar 2025の25日目の記事です。

adventar.org

Dependabotが作成するPRの対応、皆さんはどのように運用していますか？依存パッケージの更新は地味ながら継続的に発生する作業で、特に少人数チームでは対応工数の比率が無視できません。

この記事では、私たちのチームがDependabot PR対応を手動運用からDevin、そしてClaude Code Actionへと段階的に改善してきた過程を紹介します。それぞれのアプローチで得られた知見と、最終的にClaude Code Actionに落ち着いた理由をお伝えします。

Dependabot PRの対応フローを効率化したい方、AIツールを活用したコードレビューの自動化に興味がある方の参考になれば幸いです。2025年の変遷を書いているのでDependabot PRのAIレビューをこれから実施したい場合はClaude Code Actionのセクションを中心に見ていただければと思います。

手動時代

フロー

Dependabot PRへの対応は、次のような流れで行っていました。

  1. Dependabotが作成したPRを確認する
  2. CIの実行結果を待ち、成功・失敗を確認する
  3. 更新されたパッケージのリリースノートを確認し、Breaking Changesがないか調べる
  4. CIが失敗している場合は原因を調査し、必要に応じてコードを修正する
  5. 問題がなければレビューを行う
  6. マージする

一見シンプルなフローですが、実際に運用してみると様々な課題があります。

課題

まず、コンテキストスイッチのコストが大きいという問題がありました。Dependabot PRを順番にマージしていくと、他のPRとコンフリクトが発生してrebaseが必要になります。CIの実行を待っている間に別の作業を始め、CIが完了したら戻ってきて次のPRを処理する、という流れで作業が細切れになりがちでした。

リリースノートの確認も手間のかかる作業でした。Breaking Changesは基本的にCIが失敗するので気付けますが、稀にruntimeで問題が発覚することがあります。そのため、念のためリリースノートを確認してからマージするようにしていました。

また、人によってマージの判断基準にズレがあるという問題もありました。あるメンバーはCIが通っていればすぐにマージし、別のメンバーはリリースノートを細かく確認してからマージするといった具合です。リリースノートを確認するというルールは作れば防げますが、どれくらい詳細に確認するかなど個人の感覚に依存してしまいます。

少人数チームでは、こうした定型作業の工数比率が相対的に高くなります。週に数時間をDependabot PR対応に費やしていると、本来注力すべき開発作業に割ける時間が減ってしまいます。

Devinへ移行

こうした課題を解決するため、導入済みだったDevinのPlaybookをDependabot PRのレビューに活用してみることにしました。

Playbookとは

DevinにはPlaybookという機能があります。これは繰り返し行うタスクの手順を定義しておき、再利用できる仕組みです。「Dependabot PRをレビューする」というPlaybookを作成しておけば、毎回同じ手順でレビューを実行できます。

次のような形でPlaybookに記載して繰り返し利用しておりました。 Playbookの例

SlackからPlaybookを呼び出して実行

DevinはSlackと連携できるため、Slackから直接Playbookを呼び出すことができます。 「@Devin playbook:!hoge」とメンションするだけで、定義したPlaybookが実行される仕組みです。

SlackからDevinのPlaybookを実行

レビューが実施されると各PRにコメントを残してくれます。

承認時

Devin承認時

非承認時

Devin非承認時

良かった点

Devinを導入して良かった点は、1つのアクションで各PRのレビュー依頼が完結することでした。Slackでメンションするだけでレビューが始まるため、Devinの作業が完了した後は、各PRについたレビューを確認し、マージするだけで済むようになりました。

運用していく中で見えてきたこと

複数のDependabot PRが同時に作成された場合、一部のPRが漏れてしまうケースがありました。また、すでにレビュー済みのPRを再度レビューしてしまうこともありました。

これらはDevin自体の問題ではなく、1回の依頼で複数PRをまとめて処理させていた運用方法に起因する課題でした。DevinにはAPIが提供されているため、GitHub ActionsからPRごとにDevin APIを呼び出す仕組みを作れば解決できる課題と考えました。

Claude Code Actionへ移行

GitHub ActionsからDevin APIを呼び出す仕組みの構築を検討していたところ、Claude Code Actionがリリースされました。

Claude Code Actionは、名前の通りGitHub Actions上でClaude Codeを実行できるActionです。PRの作成やコメントをトリガーにして、自動でコードレビューやタスクの実行ができます。

PRごとにワークフローが実行されるため、「このPRに対してレビューを行う」というスコープが明確になります。公式のGitHub Actionとして提供されていることと、AIモデルを選択できることが決め手となり、Claude Code Actionへ移行することとしました。

bot作成PRでは動作しないためClaude Code Base Actionを利用

導入当初、Claude Code ActionにはDependabotのようなbotが作成したPRでは実行できないという制約がありました。

この制約を回避するため、Claude Code Base Actionを利用することにしました。Base Actionはbot作成のPRでも動作させることができ、機能的にもClaude Code Actionと同等のことができます。

allowed_botsでClaude Code Actionへ移行

その後、Claude Code Actionにallowed_botsオプションが追加されました。これにより、Dependabotが作成したPRでもClaude Code Actionを実行できるようになりました。

Claude Code Base Actionからの移行を行った理由は、機能的な差はほとんどないものの、他のCIワークフローとの一貫性を保つためでした。チーム内で複数のActionを使い分けるよりも、統一した方がメンテナンス性が高くなります。

各CI完了後にレビューを実施

Claude Code Base Actionのワークフローはlint、test、typecheckなどのCIジョブが完了した後にClaude Code Base Actionを実行するようにしました。そうすることで、CIの結果を踏まえたレビューができます。

CIの流れは次のようなイメージです。

jobs:
  test:
    ...(省略)...
  lint:
    ...(省略)...
  typecheck:
    ...(省略)...
  claude-review-for-dependabot-pr:
    name: Claude Review for Dependabot PR
    # `always()`を指定しCIが失敗しても実行
    if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' && always() }}
    # 各CIの結果が欲しいので終了してから実行
    needs: [test, lint, typecheck]
    ...(省略)...
    steps:
      - name: Checkout repository
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Claude Review for Dependabot PR
        uses: anthropics/claude-code-action@f0c8eb29807907de7f5412d04afceb5e24817127 # v1.0.23
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ github.token }}
          show_full_output: false #デバッグしたいときはshow_full_outputをtrueにして確認
          allowed_bots: dependabot
          claude_args: |
            --allowedTools "View,GlobTool,GrepTool,BatchTool,Bash(gh auth status),Bash(gh pr view:*),Bash(gh run list:*),Bash(gh pr comment:*),Bash(gh pr review:*),Bash(gh pr diff:*),Bash(gh pr checks:*),Bash(gh run view:*),Bash(gh release view:*),Bash(git log:*),Bash(git status:*),Bash(git diff:*)"
            --model claude-opus-4-5-20251101
          prompt: |
            （プロンプト例は下記に記載）

プロンプト例

## 命令
CI実行中のDependabotのプルリクエスト #${{ github.event.pull_request.number }} を評価しマージして問題ないか判断してください

## 手順
1. プルリクエストを確認（gh pr view ${{ github.event.pull_request.number }}）
2. package.jsonとpackage-lock.jsonの差分を確認
3. バージョン差分から公式リリースノートとGitHubのリリースを確認しライブラリの変更内容を把握（gh release view）
4. test, lint, typecheckの実行結果を確認（gh pr checks ${{ github.event.pull_request.number }}）
5. test, lint, typecheckが失敗していた場合、ログを確認（gh run view）
6. 既存コードや他ライブラリのバージョンとの整合性を確認
7. 変更内容を評価しフォーマットに沿ってプルリクエストにレビューコメント（日本語）を1件投稿

## フォーマット
```
# {ライブラリ名} x.x.x -> x.x.x
## 評価結果
✅ 承認 / ⚠️ 確認が必要 / ❌ 要対応 / etc...
## ライブラリの変更内容
- 変更内容1
- 変更内容2
## リスク、注意事項
- リスク1
- リスク2
## 必要な対応
- 対応1
- 対応2
```

## 注意事項
- 承認する場合：`gh pr review {プルリクエスト番号} --approve --body "{BODY}"`
- 承認しない場合：`gh pr comment {プルリクエスト番号} --body "{BODY}"`
- 実行時に足りない権限があった場合はコメント

## 追加確認項目
- Breaking Changesの有無
- セキュリティ脆弱性の修正状況
- 他の依存関係への影響

他のCIジョブの完了を待ってからActionを実行することで、CIが失敗している場合は「なぜ失敗したか」の分析をさせることができます。失敗ログから原因を特定し、次に取るべきアクションをPRコメントとして残すことができます。 対応すべきことがわかれば対応時の工数感がわかりすぐ取り掛かるかタスクとして積んでおくかの判断がしやすいです。

現在のフロー

  1. DependabotがPRを作成する
  2. lint、test、typecheckのCIジョブが実行される
  3. CIジョブ完了後、Claude Code Actionが実行される
  4. Claude Code Actionが更新内容の要約、リリースノートの重要ポイント、CI失敗時の原因分析と修正提案をPRコメントとして残す
  5. 人間がコメントを確認し、最終判断を行う
  6. 問題なければマージする

人間が行う作業は「Claude Code Actionのコメントを確認して最終判断する」ことに集中できるようになりました。

承認時

Claude Code Action承認時

非承認時

Claude Code Action非承認時

効果

この改善により、Dependabot PR対応にかかる工数が週あたり約30分〜1時間削減されました。 削減される主な内訳としては、リリース内容の確認と対応要否の調査にかかる時間です。 必要な対応が出力されるのですぐ対応するかタスクとして積むかの判断がしやすくなったのは良かったと感じます。

また、レビューの観点がプロンプトで統一されているため、属人性が低下しました。誰が対応しても同じ基準でレビューが行われます。

コンテキストスイッチのコストも低下しました。コンフリクトしたPRは自動でrebaseと再レビューがされるため、自分の切りがいいタイミングでマージするだけで済むようになりました。

注意点

ANTHROPIC_API_KEYはDependabot用のSecretに設定

ANTHROPIC_API_KEYはGitHub ActionsのSecretsだけでなく、Dependabot側のSecretsにも設定する必要があります。Dependabotが作成したPRでは、通常のRepository Secretsにアクセスできないためです。

設定場所はhttps://github.com/{Org}/{Repo}/settings/secrets/dependabotです。これを忘れると、Dependabot PRでClaude Code Actionが動作しません。

WebFetchの不安定さ

当初、リリースノートの取得にWebFetch機能を使っていましたが、フリーズすることがありました。（2025年11月ごろ）

対策として、外部情報の取得はghコマンドを使う方針に変更しました。GitHub CLIを使ってリリース情報を取得する方が安定性と再現性が高く、トラブルが減りました。

Claude Code側でWebFetchがフリーズするissueがいくつかあります。show_full_outputを有効化してもログが表示されないため直接的な原因は掴めていませんが、現状ではghコマンドで必要な情報は取得できているのでallowedToolsからWebFetchは一時的に除外しています。 github.com

まとめ

Dependabot PR対応を手動運用からDevin、そしてClaude Code Actionへと改善してきた過程を紹介しました。

定期的に発生する作業は自動化すると効果が大きいです。特にDependabot PRのような「PRごとに自動でトリガーされる」タイプのタスクには、GitHub Actionsと連携するClaude Code Actionが適していました。

今後の課題としては、Claude Code ActionがApproveしたPRを自動マージする仕組みの導入を検討しています。現在nxを利用したモノレポで運用しており、ユニットテストやVRTは各アプリで整備できています。ただし、管理画面など一部のアプリではE2Eテストが未整備のため、まだ自動マージには踏み切れていません。E2Eテストを拡充し、自動マージしても安全という確信を持てる体制を整えていきたいと考えています。

上記のように、AIのガードレール整備が重要なのでテスト等をしっかりやっていくことは今後さらに重要になってくると再認識しました。

ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。

herp.careers



以上の内容はhttps://tech.findy.co.jp/entry/2025/12/25/070000より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14