コードレビューをCIに組み込みたいという欲求は昔からあったのですが、「LLMに自動レビューをさせると、コメントが多すぎて逆に使いにくい」という経験から、しばらく試さずにいました。
Claude CodeのGitHub PRトリガーを設定してから2週間ほど、個人プロジェクトで実際に使い続けて、その印象が変わりました。コメント量のコントロールができることと、「レビューをお願いする相手」としての使い方が定まったことが大きかったです。設定の記録と、実運用で気づいたことを書きます。
PR トリガーとは何か
Claude CodeのPRトリガーは、GitHubのプルリクエストが作成・更新されたタイミングでClaude Codeを自動実行する機能です。Claude Codeはコードの差分（diff）を受け取り、設定したルールに沿ってレビューコメントをPRに書き込みます。
トリガーできるイベントは以下の通りです。
pull_request— PR作成・同期（push）・再オープンpull_request_review_comment— レビューコメントへの返信issue_comment— PRのコメント欄に@claudeのメンションを含む投稿
最後の @claude メンションが個人的には一番使いやすいです。「全PRに自動コメント」より「必要なときだけ呼ぶ」の方が、実際のフローに馴染みました。
セットアップ手順
前提条件
- GitHub リポジトリのオーナーまたは管理者権限
ANTHROPIC_API_KEY— Anthropicのコンソールから取得- GitHub Actions の有効化（デフォルトで有効）
Step 1: シークレットの登録
リポジトリの Settings > Secrets and variables > Actions に移動し、ANTHROPIC_API_KEY を追加します。
# ローカルで確認する場合（gh CLI使用）
gh secret set ANTHROPIC_API_KEY --body "sk-ant-..."Step 2: ワークフローファイルの作成
.github/workflows/claude-review.yml を作成します。
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize, reopened]
issue_comment:
types: [created]
jobs:
claude-review:
# @claude メンションのみトリガーする場合はこの条件を追加
if: |
github.event_name == 'pull_request' ||
(github.event_name == 'issue_comment' &&
contains(github.event.comment.body, '@claude') &&
github.event.issue.pull_request)
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
issues: write
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0 # 差分取得に必要
- name: Run Claude Code Review
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
# レビュースタイルの設定
review_style: "constructive" # constructive / strict / minimal
# コメントする最大件数（省略時: 無制限）
max_comments: "5"Step 3: CLAUDE.md でレビュー方針を記述
リポジトリルートの CLAUDE.md にレビューの重点領域を書くと、Claude Codeがその方針に従ってレビューします。
# CLAUDE.md — コードレビュー方針
## レビューで重点を置くこと
- **型安全性**: TypeScriptの型が適切に定義されているか
- **エラーハンドリング**: 例外が握りつぶされていないか
- **パフォーマンス**: N+1クエリ、不必要なre-renderが発生していないか
## レビューしなくていいこと
- コメントのスタイル（JSDocの形式統一など）
- インデントや空白（Prettierが自動整形するため）
- 命名規則の個人的な好み
## 自動マージOKな変更
以下は軽微なため、コメントなしで承認してよい:
- `package.json` のバージョンバンプのみ
- `.gitignore` の更新
- README の誤字修正この CLAUDE.md の記述が、コメント量を適切にコントロールする最大の要因です。書かないと全てにコメントしてくる一方、細かく書きすぎても汎用性が落ちます。「何を見てほしいか」「何は見なくていいか」の2軸を書くのがバランスが取りやすいです。
実際の動作確認
設定後、試しにNextJSのAPI Routeを新規追加するPRを出してみました。Claude Codeが自動でレビューした内容は以下の3点でした。
1. `error` オブジェクトをコンソールに直接出力しているが、本番環境でスタックトレースが
漏洩する可能性がある。`error instanceof Error ? error.message : 'Unknown error'`
パターンを使うことを推奨。
2. `await` なしで非同期関数を呼び出している箇所がある。
意図的なfire-and-forgetなら、コメントを添えると意図が伝わりやすい。
3. レスポンスの型定義が `any` になっている。
型パラメータを追加するか、zod等でバリデーションを入れることを推奨。
3点とも的を射たコメントで、「言われてみれば直すべきだった」内容でした。CLAUDE.mdでスタイル系は除外しているため、本質的な問題だけが上がってきた印象です。
@claude メンションでの呼び出し方
@claude メンションは、PRのコメント欄から特定の質問や指示を伝えられます。
@claude このファイルのパフォーマンスへの影響を詳しく分析してください。
特にキャッシュ戦略との兼ね合いが気になっています。
@claude Aのアプローチ vs Bのアプローチ、どちらが適切か意見を聞かせてください。
全PRに自動コメントを出すより、「迷った部分だけ聞く」方がノイズが少なく、実際のコードレビュープロセスに溶け込みやすいです。個人開発では、自分でメンションして自分でレビューを受ける、という少し奇妙な使い方をしていますが、それでも発見があります。
運用して気づいたこと
2週間使って気づいた実際のポイントをいくつか。
コスト感覚
1PRあたりの実行コスト（Anthropic API料金）は、差分の大きさにもよりますが小規模なPRで$0.01〜$0.05程度でした。月に50本のPRを出すとして、数百円程度です。個人プロジェクトであれば許容範囲内です。
レビュー速度
PRの差分が大きい場合、レビューに30〜60秒かかることがあります。急いでいる場合は待つのが少し煩わしいですが、コーヒーを1口飲む間に終わります。
false positive の扱い
「これは意図的な設計なのにコメントが来た」という場面は週に1〜2回ありました。そのたびに CLAUDE.md の「レビューしなくていいこと」セクションに追記しています。2週間で5〜6件追記したところで、false positiveがほぼゼロになりました。育てる感覚に近いです。
より高度なCI連携のパターンについては、Claude Code を使った HTTP Hooks と CI/CD 統合ガイドもあわせて参考にしてください。
はじめの一歩
まず @claude メンション方式だけ設定して試すのがおすすめです。全PRへの自動コメントは、慣れるまでノイズになりやすいです。
設定ファイルを入れて、手元のPRに @claude このコード、何か気になる点はありますか？ とコメントするだけで動作確認できます。それだけで今日から使い始められます。