🤖

Claude Code Action を使って Dependabot PR を自動レビューする

に公開

TL;DR

  • Dependabot PR の GitHub Action で「@claude レビューして」とコメントさせると勝手にレビューされて超便利
  • ただしデフォルトの GITHUB_TOKEN だと Claude Code Action の権限チェックで弾かれるので、個人アカウントの PAT が必要
  • プロンプトには「依存ライブラリ更新では破壊的変更がないかを重点的にレビューする」など、通常レビューと観点を分けて書くとレビュー精度が高くなる

ここから本文

リーナー開発チームの黒曜(@kokuyouwind)です。

以前、「Devin に Dependabot PR をレビューしてもらおう」という記事を書きました。

https://zenn.dev/leaner_dev/articles/20250218-devin-review-bump-prs

しかしながら、一言だけとはいえ Devin に依頼を投げるのが面倒ですし、依頼後に待ち時間が発生するため他のことをすると結果確認を忘れてしまうという問題もありました。

ところで、現在は各リポジトリにClaude Code GitHub Actionsを導入し、各自の PR レビューなどに役立てています。

Dependabot PR も「Claude Code にレビューしてもらえばいいのでは?」「なんなら PR 作られるごとにレビュー処理が起動すれば、人間が見る頃にはレビューコメントがついていて即座にマージできるのでは?」と思って実装してみました。

Claude Code GitHub Action の設定

Claude Code GitHub Action 自体は公式・非公式ともに資料がいっぱいあるのでよしなに設定します。

弊社ではリポジトリごとに設定を管理せず済むよう、 Reusable Workflow を使って集約管理しています。[1] ただし Reusable Workflow は色々設定が面倒になりがちなので、Claude Code を実行したいだけであれば、以下記事のように Composite Action にしたほうが大抵は便利でしょう。

https://zenn.dev/reality_tech/articles/5980dfc645dd5d

Claude Code Review for Dependabot


身も蓋もない話をすると、以下のように依存性更新の Pull Request オープン時の Action で「@dependabot レビューして」というコメントをつけるだけです。[2]

claude_code_review.yml
name: Claude Code Review

on:
  pull_request:
    types: [opened]
    branches: [main]

jobs:
  claude-code-review:
    permissions:
      contents: write
    # Only run for bot PRs (dependabot, renovate)
    if: |
      github.event.pull_request.user.login == 'dependabot[bot]' ||
      github.event.pull_request.user.login == 'renovate[bot]'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    permissions:
      contents: read
      pull-requests: write
      issues: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
        with:
          persist-credentials: false
      - name: Request Claude Code Review
        uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7.0.1
        with:
          github-token: ${{ secrets.github-token }}
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: '@claude レビューして'
            });

ただし、ポイントがいくつかあります。

トリガーは opened のみにする

大抵の Pull Request Action では起動トリガーを [opened, synchronized] としますが、こうすると Dependabot PR を rebase するたびにレビューされてコメント欄が大変なことになります。

そもそもレビューしてほしいのは「更新先のバージョンに破壊的変更がないか」なので、 rebase しても内容が変わることはほとんどありません。

このため、起動トリガーは opened のみで十分としています。

コメントをつける GitHub Token は別途指定する

デフォルトで Actions に設定される GITHUB_TOKEN は Workflow を起動したイベントの owner です。つまり、 Dependabot PR では dependabot[bot] になり、コメントを投稿するユーザーもボットになります。

Claude Code Action は checkWritePermissions で書き込み権限のあるユーザーが起動したかをチェックするため、これだと以下 Issue のとおり Actor has insufficient permissions で引っかかりレビュー処理が実行されません。

https://github.com/anthropics/claude-code-action/issues/93

このため、コメントを投稿する際は secrets.github-token から個人の PAT を渡して権限のあるユーザーからのコメントにしています。

…という罠があったんですが、この記事を書くために最新コードをチェックしたところ checkWritePermissions の処理が更新されて bot user を許可していそうな見た目になっていました。

https://github.com/anthropics/claude-code-action/blob/7ed3b616d54fd445625b77b219342949146bae9e/src/github/validation/permissions.ts#L46-L50

もしかしたらわざわざ個人の PAT を使わなくても Claude Code Action が問題なく起動できるようになってるかもしれません。[3]

プロンプトにライブラリ更新のレビュー観点を埋め込む

同じ「レビューして」という指示でも、新機能追加などと依存ライブラリ更新では見てほしい観点が大きく異なります。そこで、以下のように claude.yml のカスタムインストラクションで「レビュー対象 PR の種別に応じてレビュー観点ファイルを読み込む」という指示を入れています。[4]

claude.yml
  # ...
      - name: Run Claude Code
        uses: anthropics/claude-code-action@a5528eec7426a4f0c9c1ac96018daa53ebd05bc4 # v1.0.7
        with:
          claude_args: |
            --system-prompt '
              **For Pull Request Reviews (MANDATORY STEPS)**: 
                * STEP 1: Determine PR type and read the corresponding guideline file:
                  - Library/dependency updates (renovate/dependabot) → `.github/workflows/claude-review/review-guideline-library-dependency-updates.md`
                  # ...

ライブラリ・依存関係更新のレビューガイドラインは以下のようにしています。[5]

review-guideline-library-dependency-updates.md
# ライブラリ・依存関係更新のレビューガイドライン

## レビュー項目

### 1. バージョン差分の調査
- 変更されるライブラリのCHANGELOGやリリースノートを確認
- Web検索でBreaking Changesやセキュリティ修正の詳細を調査
- Descriptionに参考リンクを提示して影響範囲を明確化

### 2. 影響範囲の評価
- Breaking Changes がある場合、アプリケーションがその影響を受けるかを調査
  - 設定や API のインターフェイスが変わる場合、その影響を受ける記述がないか
  - バージョン間のマイグレーションに何らかの作業が必要でないか

### 3. セキュリティ影響
- セキュリティパッチが含まれているか
- 新しい脆弱性が修正されているか

## 全体コメントテンプレート

### 🎯 総合評価
**[ライブラリ名] v[旧バージョン] → v[新バージョン]** の更新について評価します。

[調査結果に基づく承認/要修正の判断]

### 📋 更新内容の調査結果
- **リリースノート**: [リンク]
- **主な変更**: [重要な変更点を簡潔に]
- **Breaking Changes**: [有無と詳細]
- **セキュリティ修正**: [有無と詳細]

### 🚨 強く修正を推奨
**[既存実装の修正が必要な場合や、バージョン間のマイグレーション処理が必要な場合など、必須の修正事項がある場合のみ使用]**
- 破壊的変更への対応が必要(具体的な修正箇所)
- 設定ファイルの更新が必要(具体的な更新作業手順)

### ⚠️ 要確認
**[調査が難しい場合や、確証がないが非互換変更による懸念がある場合など、どうしても人間の目による確認が必要な項目がある場合のみ使用]**
- 破壊的変更の影響調査を推奨(具体的な懸念点)
- パフォーマンスへの影響要確認(具体的な懸念されるケース)

なお、全体をカスタムインストラクションに埋め込むと不要な情報が増えて動作に悪影響がありそうなことと、単に見通しが悪くメンテナンスしづらそうなため、レビュー観点は PR 種別ごとにファイル分割して Claude Code から読み込ませています。

動作例

例えば Puma gem の v6 から v7 への更新 PR が作られた場合、以下のようにまず「レビュー依頼コメント」が自動投稿され、それに応じる形で Claude がレビューしてコメントを投稿します。[6]


レビュー内容を見ると「on_worker_bootbefore_worker_boot に変更された」など破壊的変更を把握したうえで、「プロジェクトコードで on_worker_boot などを使用していないため影響がない」と評価し、マージ可能としています。

従来だとこのような確認を人間がしていましたが、 Claude が代行してくれるので人間は判断するだけで済むようになりさっとマージできて便利ですね。

もちろん、 Claude の確認が漏れていて破壊的変更の影響を受ける可能性もあるので、影響の大きいものはダブルチェックしたほうが望ましいですが、それでも確認事項を列挙してくれたり最初の確認をしてくれるのはかなり便利です。

まとめ

Claude GitHub Action を設定している場合、簡単に依存性更新 PR の自動レビューが実現できます。

かなり体験が良いのでぜひ試してみてください!

宣伝


リーナーでは AI を使った開発生産性向上に取り組んでいます。

興味があるかたは気軽にお話しましょう!

https://pitta.me/matches/HTxgLMvyqyBw

脚注
  1. actionlint や pinact など、主にセキュリティ周りのワークフローを共通化ために整備していたため、それに揃えています。 ↩︎

  2. わかりやすいように普通の GitHub Action の形で書いてますが、実際には Reusable Workflow で共通化しています。書き換える過程でなんかミスっててコピペでは動かないかもしれません。 ↩︎

  3. 試してないので、もし問題なく動いた方がいたら教えて下さい。 ↩︎

  4. なんとなく指示追従性能が高くなりそうなので、プロンプトを英語で記述しています。 ↩︎

  5. こちらはコメントテンプレートが日本語なので、全体も日本語で書いています。 ↩︎

  6. ボットアカウントを弊社マスコットキャラクターのリーニャーにしているのは、筆者の単なる趣味です。また語尾を「ニャ」にしているのも筆者の趣味で、非公式設定です。 ↩︎

リーナーテックブログ

Discussion