チーム開発でプルリクエストのレビュー待ちが長引いて、開発の勢いが止まった経験はないでしょうか。レビュアーの時間は有限で、コーディング規約のチェックやセキュリティ上の見落としを毎回人力で行うのはかなりの負荷がかかります。
最近、AnthropicがリリースしたGitHub Action「claude-code-action」を使うと、PRが作成されるたびにClaude Codeがコードを読み、自動でレビューコメントを付けてくれます。調べてみたら導入の敷居が想像より低かったので、この記事ではセットアップからCLAUDE.mdによるレビュールールの定義、運用時の注意点まで一通りまとめます。
動作確認環境: Claude Code CLI 最新版(2026年4月時点)、anthropics/claude-code-action@v1、GitHub Actions。
なぜPRレビューを自動化するのか
レビュー待ちがボトルネックになる問題
開発チームの生産性を計測すると、意外とコードを書いている時間よりレビュー待ちの時間が長いケースがあります。特に少人数のチームでは、シニアエンジニアにレビューが集中しがちです。
GitHubの調査によると、PRがオープンされてからマージまでの平均時間のうち、約40%がレビュー待ちに費やされているというデータもあります。これはコードの品質とは関係なく、単にレビュアーが忙しいだけという場合も多いです。
自動レビューで解決できること
AIによるコードレビューの自動化は、人間のレビューを置き換えるものではなく、一次フィルタとして機能させるのが現実的な使い方です。具体的には以下のような観点を自動でチェックできます。
- コーディング規約への準拠(命名規則、フォーマット)
- セキュリティ上の一般的な問題(SQLインジェクション、XSS等)
- パフォーマンス面で明らかに非効率なコード
- ドキュメントやコメントの不足
- テストカバレッジの確認
人間のレビュアーは、ビジネスロジックの妥当性やアーキテクチャの判断といった、より高次の観点に集中できるようになります。
claude-code-actionの仕組み
GitHub Actionとしての動作フロー
claude-code-actionはAnthropicが公式に提供しているGitHub Actionです。ワークフローに組み込むと、以下の流れで動作します。
- PRがオープン(または更新)されるとワークフローがトリガーされる
- Claude Codeがリポジトリのコードをチェックアウトして差分を分析する
- CLAUDE.mdに記載されたルールに従ってレビューを実行する
- 指摘事項をPRのコメントとして投稿する
公式ドキュメントによると、PRへのコメントで@claudeとメンションすると、追加の質問や修正依頼もできます。単なる一方通行のレビューではなく、対話的にやり取りできるのが特徴です。
従来のレビューツールとの比較
自動レビューツールはいくつかありますが、それぞれ得意分野が異なります。
| ツール | 特徴 | レビュー観点 | カスタマイズ性 |
|---|---|---|---|
| ESLint / golangci-lint | ルールベースの静的解析 | 構文・スタイル | ルール単位で設定可能 |
| SonarQube | 品質ゲート付きの総合解析 | バグ・脆弱性・コード臭 | プロファイルで管理 |
| CodeRabbit | AIベースのレビュー | ロジック・設計 | 設定ファイルで調整 |
| claude-code-action | Claude Codeによるレビュー | 総合的(ロジック・設計・セキュリティ) | CLAUDE.mdで自由に定義 |
ESLintやgolangci-lintは構文レベルのチェックには優秀ですが、「この変数名はビジネスドメインの用語と合っていない」といったコンテキストを踏まえた指摘はできません。claude-code-actionの強みは、CLAUDE.mdに自然言語でルールを書ける点にあります。プロジェクト固有の規約をそのまま文章で定義できるので、設定の学習コストが低いです。
ワークフローの設定手順
最小構成のワークフローを作る
まずは最もシンプルな構成から始めます。リポジトリの.github/workflows/に以下のYAMLファイルを作成してください。
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
これだけで、PRが作成・更新されるたびにClaude Codeがレビューを実行してくれます。permissionsでpull-requests: writeを設定しているのは、レビューコメントを書き込むために必要な権限です。
// PRコメントの例
Claude Code Review が以下の指摘を行いました:
- src/handler.go:42 - エラーハンドリングが不足しています。err != nil の場合にログを出力してから返却することを推奨します。
- src/service.go:78 - この関数は責務が大きすぎます。データ取得とバリデーションを分離することを検討してください。
メンションでレビューを呼び出す設定
PRのコメントで@claudeと書くとClaude Codeに追加の指示を出せる設定も追加できます。
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
review:
if: |
github.event_name == 'pull_request' ||
(github.event_name == 'issue_comment' &&
contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review_comment' &&
contains(github.event.comment.body, '@claude'))
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
issues: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
issue_commentとpull_request_review_commentをトリガーに追加し、if条件で@claudeを含むコメントのみ反応するようにしています。これにより「@claude この関数のパフォーマンスをチェックして」のように対話的にレビューを依頼できます。
環境変数とシークレットの設定
GitHub ActionsのシークレットにANTHROPIC_API_KEYを登録する手順は以下の通りです。
- GitHubのリポジトリ設定 → Secrets and variables → Actions を開く
- 「New repository secret」をクリック
- Name に
ANTHROPIC_API_KEY、Value にAnthropicのAPIキーを入力して保存
GITHUB_TOKENはGitHub Actionsが自動で提供するので、追加の設定は不要です。permissionsセクションで適切な権限を付与するだけで動きます。
CLAUDE.mdでレビュールールを定義する
プロジェクト固有の規約を書く
claude-code-actionの最大の利点は、CLAUDE.mdファイルでレビュー基準を自然言語で定義できることです。リポジトリのルートにCLAUDE.mdを配置すると、Claude Codeがレビュー時にその内容を参照します。
# コードレビュー規約
## 命名規則
- 関数名はキャメルケース、定数はスネークケース大文字
- ブール型の変数には is/has/can のプレフィックスを付ける
- HTTPハンドラの引数名は w, r を使う
## エラーハンドリング
- エラーは必ず呼び出し元に返すか、ログを出力して処理する
- エラーメッセージには発生箇所のコンテキストを含める(fmt.Errorf + %w)
- panicはmain関数以外では使用しない
## テスト
- 新規の公開関数には必ずテストを追加する
- テーブル駆動テストを優先する
- テスト名は Test_関数名_条件_期待結果 の形式にする
// CLAUDE.mdを配置した場合のレビューコメント例
指摘: src/user.go:25 の変数 `flag` はブール型ですが、is/has/canのプレフィックスがありません。
CLAUDE.mdの命名規則に従い、`isActive` のような名前に変更することを推奨します。
ルールを自然言語で書けるため、「新しいメンバーがジョインしたときのオンボーディングコスト」も下がります。従来はESLintのカスタムルールをJavaScriptで書く必要がありましたが、CLAUDE.mdなら日本語で書くだけです。
レビュー観点をカスタマイズする
CLAUDE.mdにはレビュー観点の優先度も指定できます。たとえば、セキュリティを重視するプロジェクトでは以下のように書けます。
# レビュー優先度
## 必ずチェックする(ブロッキング)
- SQLクエリに文字列結合で値を埋め込んでいないか
- ユーザー入力をサニタイズせずにHTML出力していないか
- 秘密情報(APIキー、パスワード)がハードコードされていないか
## 推奨(提案レベル)
- 関数の行数が50行を超えていないか
- 重複コードがないか
- 変数のスコープが必要以上に広くないか
ブロッキングとして定義した観点に違反があれば強い指摘として、推奨レベルの観点はサジェスチョンとして、トーンを変えてコメントしてくれます。この仕組みにより、チームのレビュー文化をそのままCLAUDE.mdにエンコードできるわけです。
アンチパターンと改善策
NG: すべてのPRで無制限にレビューを実行する
導入当初にやりがちなのが、全PRに対して無条件でレビューを走らせる設定です。
# アンチパターン: フィルタなしで全PR対象
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize, reopened, edited]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
この設定の問題点は主に2つあります。
- APIコスト: ドキュメントの修正やCI設定の変更など、レビュー不要なPRにもトークンを消費してしまう
- ノイズ: READMEの修正PRに「テストが不足しています」と指摘されるような、的外れなコメントが発生する
OK: パスフィルタとラベルで制御する
以下のように、対象ファイルのパスやラベルで制御するのが実用的です。
# 改善版: パスフィルタ + ラベル制御
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
paths:
- 'src/**'
- 'pkg/**'
- 'internal/**'
jobs:
review:
if: "!contains(github.event.pull_request.labels.*.name, 'skip-ai-review')"
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 1
- uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
pathsでソースコードのディレクトリだけを対象にし、skip-ai-reviewラベルが付いたPRはスキップします。ドキュメントの修正やdependabot等のPRにラベルを付けておけば、無駄なレビューを防げます。
導入後のレビューフローと効果
PRオープンからマージまでの流れ
claude-code-actionを導入した後の典型的なフローは以下のようになります。
- Step 1: 開発者がPRを作成する
- Step 2: GitHub Actionsがトリガーされ、Claude Codeがレビューを実行(1〜3分程度)
- Step 3: Claude Codeがレビューコメントを投稿する
- Step 4: 開発者がAIの指摘を確認し、修正が必要なものは対応する
- Step 5: 人間のレビュアーが、AIレビュー済みのPRを確認する
- Step 6: 承認後にマージ
ポイントは、Step 5で人間のレビュアーが見るときには、基本的な指摘がすでに反映されている状態になっていることです。レビュアーはコーディング規約やタイポのチェックから解放され、設計判断やビジネスロジックの確認に集中できます。
人間レビューとの使い分け
ここは最初に自分も悩んだところですが、実際に運用してみると、以下のような使い分けがしっくりきました。
| レビュー観点 | AIレビュー | 人間レビュー |
|---|---|---|
| コーディング規約 | 得意 | 不要(AIに任せる) |
| セキュリティの基本チェック | 得意 | 高度な攻撃パターンは人間が確認 |
| パフォーマンス | 明らかな非効率は検出可能 | ベンチマーク結果の判断は人間 |
| 設計・アーキテクチャ | 提案レベルのコメントは可能 | 最終判断は人間 |
| ビジネスロジック | コンテキスト不足で限界あり | 必須 |
AIレビューは「正解が明確な観点」に強く、「判断が必要な観点」は人間が担うというのが現時点での落とし所だと感じています。AIの指摘を鵜呑みにするのではなく、参考情報として活用するスタンスが重要です。
まとめ
Claude CodeとGitHub Actionsによるコードレビュー自動化のポイントを振り返ります。
anthropics/claude-code-action@v1をワークフローに追加するだけで、PRレビューを自動化できる@claudeメンションで対話的にレビューを依頼することも可能- CLAUDE.mdにプロジェクト固有のルールを自然言語で定義できるのが最大の利点
- パスフィルタやラベルで対象PRを制御し、APIコストとノイズを抑える
- AIレビューは一次フィルタとして活用し、設計判断やビジネスロジックは人間が担当する
- 導入により、レビュアーの負荷軽減とレビュー待ち時間の短縮が期待できる
よくある質問(FAQ)
Q1: APIコストはどのくらいかかる?
PRの差分サイズによりますが、一般的なPR(数百行の変更)であれば1回のレビューで数十円程度です。1日に10件のPRがある場合でも、月額のコストは数千円から1万円程度に収まることが多いです。パスフィルタを設定してレビュー対象を絞れば、さらにコストを削減できます。
Q2: プライベートリポジトリでも使える?
使えます。GitHub Actionsのワークフロー内で動作するため、コードがAnthropicのサーバーに永続的に保存されることはありません。ただし、APIリクエスト時にコードの差分がAnthropicのAPIに送信されるため、セキュリティポリシーが厳しい組織では事前に情報セキュリティ部門と確認することを推奨します。
Q3: Claude Codeが誤った指摘をした場合どうする?
PRのコメントで@claude この指摘は意図的な実装です。理由は〇〇ですと返信すると、Claude Codeがコンテキストを理解して指摘を取り下げたり、別のアプローチを提案してくれます。また、CLAUDE.mdに「このパターンは許容する」というルールを追加しておけば、同じ指摘が繰り返されることを防げます。

