PR レビュー Bot を立ち上げる 1 日プロジェクト

コース構成

このコースで学ぶこと

1. 01

   設計と前提

   Claude Code の GitHub Action は、PR コメントの `@claude` メンションで起動する。これを自動化する。

   通常は人間がコメントで `@claude` と書いて起動しますが、本プロジェクトでは『PR が作成された瞬間に自動で Claude がレビュー』を作る。負荷とコストを抑えるため、条件付き起動が肝。

   • PR 作成時に自動起動（手動 `@claude` 不要）
   • draft PR はスキップ（コスト節約）
   • 「skip-ai-review」ラベルがあればスキップ
   • 変更が 1000 行を超えたら部分レビュー（最重要ファイルのみ）
   GitHub Action を仕込む
2. 02

   GitHub Action を仕込む

   .github/workflows/claude-review.yml を追加。これだけで動く。

   yaml

   name: Claude PR Review
   on:
     pull_request:
       types: [opened, synchronize, ready_for_review]
   
   jobs:
     review:
       if: |
         !github.event.pull_request.draft &&
         !contains(github.event.pull_request.labels.*.name, 'skip-ai-review')
       runs-on: ubuntu-latest
       permissions:
         contents: read
         pull-requests: write
         issues: write
       steps:
         - uses: actions/checkout@v4
           with:
             fetch-depth: 0
         - uses: anthropics/claude-code-action@v1
           with:
             anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }}
             prompt: |
               この PR をレビューしてください。REVIEW.md の観点に従い、
               P0/P1/P2 の severity で指摘を残してください。

   出力イメージPR が作成されたとき自動投稿されるレビュー

   ## Claude PR Review — REVIEW.md に基づく
   
   ### P0
   - `src/handlers/○○.ts:31` ユーザー入力をそのままクエリに連結しています。SQL インジェクションの恐れがあるため、プレースホルダ化してはどうでしょう。
   
   ### P1
   - `src/components/○○.tsx:54` リストレンダリングに key がありません。
   
   ### good
   - 例外時のロールバック処理が漏れなく入っていて安心して読めました
   …（P2 を 2 件 省略）

   設計と前提REVIEW.md でレビューのトーンを統一
3. 03

   REVIEW.md でレビューのトーンを統一

   毎回同じ品質のレビューを得るには、REVIEW.md でレビューの観点を明文化する。

   markdown

   # REVIEW.md — Claude PR Review の指針
   
   ## 重視する
   - セキュリティ：認証・認可・SQL インジェクション・XSS
   - データ整合性：競合状態・トランザクション境界
   - パフォーマンス：N+1 クエリ・無限ループ・キャッシュ無効化
   - a11y：キーボード操作・スクリーンリーダー対応
   
   ## 無視する
   - フォーマッティング（Biome が処理）
   - import 順（自動整理）
   - コメントの言い回し
   
   ## Severity
   - **P0**：本番で即障害 → 必ず修正
   - **P1**：レビュー前に直したい
   - **P2**：余裕があれば
   
   ## コメントのトーン
   - 命令ではなく提案：「〜してください」ではなく「〜してはどうでしょう」
   - 理由を明示：「なぜそう思うか」を 1 行添える
   - 良い箇所も褒める：P0/P1 だけでなく『good』も付ける

   GitHub Action を仕込むテスト運用：自分の PR で試す
4. 04

   テスト運用：自分の PR で試す

   いきなりチームに展開しない。まず自分の PR で 1 週間試して、トーンを調整。

   手を動かす

   0 / 5

   • ANTHROPIC_API_KEY を GitHub Secrets に登録
   • ワークフローと REVIEW.md を main にマージ
   • 自分の作業用の PR を 3-5 件作る
   • Claude のレビューを読み、ピント外れだったら REVIEW.md を調整
   • 1 週間後、改善した REVIEW.md でチーム展開
   REVIEW.md でレビューのトーンを統一チーム展開とフィードバックループ
5. 05

   チーム展開とフィードバックループ

   1 週間自分で使って良ければ、チームへ。改善は週次で。

   • Slack で告知：「@claude PR レビュー始まりました。REVIEW.md がコメントの基準です」
   • 週次でレビュー結果を振り返り（『役に立った』『邪魔だった』）
   • REVIEW.md を週次で更新（チームのフィードバックを反映）
   • コメントに reactions（👍/👎）を付ける文化を作って質感を可視化

   Lv.8 — Code Review

   理解度チェック

   1. Q1.PR レビュー Bot を本番運用するうえで、コストと信頼性の両方を保つ鍵は？

      A全 PR に必ずレビューを走らせるBdraft / 巨大変更 / skip-ai-review ラベル付きを除外し、REVIEW.md を週次で更新するCREVIEW.md を一度書いたら変更しないDAPI キーを全員に共有する

   2. Q2.PR レビュー Bot を導入する一番の目的はどれか？

      A人間レビュアーを完全に置き換えるB毎 PR で同じ観点（セキュリティ・性能・命名）を機械的に拾い、人間レビュアーが本質に集中できるようにするCGitHub Actions の使用量を増やすDClaude のモデル選定を毎回試す

   3. Q3.Bot が出した指摘のうち、必ず人間が判断すべきはどれか？

      Aセミコロン抜けなどの自動修正可能なフォーマット指摘Bimport の並び順Cセキュリティ・データ整合性・本番影響に関する P0 指摘の最終判断Dコミットメッセージの絵文字
   テスト運用：自分の PR で試す