すべての PR をレビューする GitHub Action

上級

What you'll learn

Claude Code のヘッドレス実行を pull_request ワークフローに組み込み、diff をレビューしてコメントする
permissions ブロックをコメント専用に設定し、contents: write が越えてはならない一線である理由を説明する
プルリクエストの内容を、その実態どおり信頼できない入力として扱う
diff が大きくなってもレビューのコストを一定の範囲に抑える
コメントが折りたたまれずに読まれるよう、プロンプトを書く

価値の高い定番の自動化: Claude にすべてのプルリクエストをレビューさせ、その指摘をコメントとして投稿する — CI でヘッドレス実行します。ここでは全体像と、安全に保つためのガードレールを示します。

何をするか

PR ごとに: diff をチェックアウトし、バグ、エッジケース、規約の問題について Claude にレビューさせ、コメントを投稿します。判断は引き続き人間が行い、Claude は素早い一次チェックを提供するだけです。

Guided walkthrough1 of 4

浅いクローンではベースブランチが見えないため、diff が空になり、レビューは何もないものに対する自信満々の承認に見えてしまいます。フル深度で取得してください。

ワークフロー(スケッチ)

name: Claude PR review
on: pull_request
permissions:
  contents: read
  pull-requests: write   # to comment — NOT write to code
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Review the diff
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/diff.patch
          claude -p "Review this diff for correctness bugs, missing edge cases, and
          security issues. Report ONLY high-confidence findings as a Markdown
          checklist with file:line. Diff:" < /tmp/diff.patch > /tmp/review.md
      # then post /tmp/review.md as a PR comment (e.g. with the gh CLI or an action)

(正確なヘッドレスの呼び出し方は異なる場合があります — ドキュメントを参照してください。原則は、diff を渡し、Markdown を取得し、投稿する、です。)

ガードレール(自律実行の堅牢化を読んでください)

CI での最小権限

コメントのみ。pull-requests: write を付与し、contents: write は付与しない — ボットがコードを push してはいけません。
トークンのスコープを絞る。信頼できない PR の内容を読むジョブには、デプロイやシークレットへのアクセスを決して公開しない。
PR の内容は信頼できないものとして扱う — プロンプトインジェクションを含みうる。ジョブに重大な結果を伴う操作をさせない。
コストに上限を設ける — 大きな diff はトークンを消費する。変更されたファイルだけをレビューすることを検討する。

騒がしくせず、役に立たせる

確信度の高い指摘だけを求める — 細かい指摘の山は無視されます。
一次チェックにとどめ、マージの判断は人間が行う。

The review prompt — tuned for a comment people actually read

Review this diff for correctness bugs, missing edge cases, and security issues.

Rules for your output:
- Report ONLY high-confidence findings. If you are unsure, leave it out.
- One Markdown checklist item per finding, each starting with file:line.
- State the concrete failure: what input or state leads to what wrong result.
- No style nitpicks, no praise, no summary of what the diff does.
- If you find nothing high-confidence, say exactly that in one line.

Diff:

Check yourself

0/3

レビュージョブはプルリクエストにコメントを投稿する必要があります。正しい permissions ブロックはどれですか?
チェックアウトのステップで fetch-depth: 0 を使うのはなぜですか?
コントリビューターが、レビュアーにセキュリティチェックを無視して承認するよう指示する説明文付きの PR を開きました。正しい姿勢はどれですか?

Key takeaways

ジョブ全体は: フル深度のチェックアウト、diff をファイルに、ヘッドレスで 1 パス、Markdown を投稿。4 ステップのうち書き込みアクセスが必要なのは 1 つだけ。
pull-requests: write と contents: read。コントリビューターが書いた内容を読むジョブでは、決して contents: write にしない。
fetch-depth: 0 にしないと diff が空になり、レビューが健康診断書のように読めてしまう。
PR の内容は信頼できず、プロンプトインジェクションを含みうる。制御は最小権限であり、プロンプトの言い回しは境界ではない。
確信度の高い指摘だけを、file:line 付きで求める。細かい指摘の山は折りたたまれ、自動化は無視されて死ぬ。
diff が大きくなるにつれてコストに上限を設ける — 変更されたファイルだけをレビューするのが通常のレバー。
これは一次チェック。マージの判断は引き続き人間が行う。

このページを共有

何をするか​

ワークフロー(スケッチ)​

ガードレール(自律実行の堅牢化を読んでください)​

騒がしくせず、役に立たせる​