Claude Code をローカルで使い込むと、次に欲しくなるのが「人がいなくても回るレビュー」です。ローカルでの対話的な開発は速いものの、その品質は開発者の手元に閉じています。チームで安定して成果を出すには、Pull Request という共通の場で Claude Code を動かし、レビューと品質チェックを自動で通す仕組みが要ります。

この記事では、Claude Code を GitHub Actions の CI に組み込み、PR の自動レビューと品質ゲートを動かす構成を、実装手順とともに整理します。単に動かすだけでなく、コストや誤検知をどう抑え、どこまでを自動化に任せて人がどこを見るのか、その境界の引き方を実務目線でまとめます。CI 連携は Claude Code 導入ロードマップ の後半フェーズにあたるテーマで、ローカル運用が固まったチームの次の一手になります。

なぜ CI に Claude Code を入れるのか — レビュー負荷とリードタイム

CI に AI レビューを組み込む目的は、コードレビューの「一次対応」を自動化することにあります。人間のレビュアーが見るべきは設計判断やドメイン知識を要する部分ですが、実際には命名の一貫性、明らかな nil 参照、テスト漏れ、規約違反といった機械的に拾える指摘がレビューの多くを占めます。この層を Claude Code に肩代わりさせると、レビュアーは本質的な判断に集中できます。

効果が出るのはリードタイムです。レビュー待ちは PR がマージされるまでの停滞時間の大半を占めることが多く、レビュアーのカレンダーが埋まっていれば数日単位で滞ります。PR を開いた瞬間に Claude Code が一次レビューを返せば、作者は人間のレビューを待つ間に指摘を潰せます。レビュアーが見るときには初歩的な指摘が片付いている状態になり、往復回数そのものが減ります。

もう 1 つの狙いは、レビュー品質の底上げと平準化です。レビューの厳しさはレビュアーの調子や経験に左右されますが、CI の自動レビューは PR ごとに同じ観点を必ず通します。レビュー文化がまだ固まっていないチームほど、この「最低ラインを毎回担保する」効果は大きく効きます。

GitHub Actions での基本構成と権限・シークレット管理

実装の出発点は、Anthropic が公開している GitHub Actions 連携です。リポジトリに .github/workflows/ を置き、PR イベントをトリガーに Claude Code を実行するワークフローを定義します。最小構成は次のような形になります。

name: claude-code-review
on:
  pull_request:
    types: [opened, synchronize]
 
permissions:
  contents: read
  pull-requests: write
 
jobs:
  review:
    runs-on: ubuntu-latest
    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 の差分をレビューしてください"

ここで最初に詰めるべきは権限とシークレットです。API キーは必ず GitHub の Secrets に格納し、ワークフロー定義に直書きしません。pull_request トリガーはフォークからの PR でも発火しうるため、外部コントリビューターを受け入れるリポジトリでは pull_request_target との違いと、シークレットがフォーク PR に渡らない挙動を理解しておく必要があります。社内開発が中心なら pull_request で十分ですが、OSS として公開するならフォーク PR ではレビューをスキップする条件分岐を入れるのが安全です。

permissions は必要最小限に絞ります。レビューコメントを書くなら pull-requests: write は要りますが、contents: write まで与える必要は基本的にありません。CI から AI に渡す権限は、ローカルの権限設計と同じ発想で「危険なものは渡さない」が原則です。ローカル側の allow / deny 設計については Claude Code の権限と settings.json 設計 で詳しく整理しています。

PR 差分の自動レビューを動かす

ワークフローが動くようになったら、レビューの中身を設計します。鍵になるのは「何を渡すか」と「何を出させるか」です。

渡す対象は、PR 全体ではなく差分に絞るのが基本です。git diff のベースを PR のターゲットブランチに取り、変更されたファイルとその周辺コンテキストだけを Claude Code に見せます。リポジトリ全体を毎回読ませるとトークン消費が膨らむうえ、無関係な箇所への指摘が増えます。差分中心にすることで、レビューの焦点と実行コストの両方を抑えられます。

出力形式は、PR へのインラインコメントか、サマリーコメント 1 本かを選びます。指摘の数が多くなりがちな初期は、ファイル行単位のインラインより、サマリーコメントに「重要度順の指摘リスト」をまとめさせる方が読みやすく、ノイズも管理しやすい傾向があります。運用が安定し、誤検知が減ってからインラインに切り替えると、PR 画面上で指摘の場所が一目でわかる体験になります。

レビュー観点は、プロジェクト固有のルールを CLAUDE.md に書いておき、それを読ませるのが効果的です。命名規約、禁止パターン、テストの方針といったチーム固有の文脈を渡すことで、汎用的な指摘から「このプロジェクトで本当に守るべきこと」のレビューへ精度が上がります。

品質ゲート — lint・型・テストとの組み合わせ

Claude Code のレビューは強力ですが、それ単体をマージ条件にするのは危険です。AI のレビューは確率的で、毎回同じ判断を返す保証がありません。確定的に落とせるものは、従来どおり lint・型チェック・テストで止めるべきです。

実務では、品質ゲートを二層に分けて考えます。一層目は機械的に白黒がつく検証で、ESLint や TypeScript の型チェック、ユニットテストがこれにあたります。ここは Required status checks に設定し、失敗したらマージをブロックします。二層目が Claude Code のレビューで、こちらは助言として PR にコメントを残す位置づけにします。AI の指摘でブロックするのではなく、人間が指摘を読んで取捨選択する。この分担なら、確定的な品質は従来の仕組みで担保しつつ、AI には拾いきれない観点の補強を任せられます。

ジョブの順序も整理しておくと無駄が減ります。lint と型チェックを先に走らせ、それが通った PR にだけ Claude Code のレビューを実行する構成にすると、そもそも型が通らない PR に API コストをかけずに済みます。needs でジョブ依存を張り、軽い確定的チェックを前段に置くのがコスト面でも理にかなっています。

コストと実行頻度のコントロール

CI で AI を回すと、見落としがちなのが API コストです。synchronize イベントは PR にコミットが積まれるたびに発火するため、何も制御しないと作者が小刻みにプッシュするたびにフルレビューが走り、トークン消費が積み上がります。

実行頻度は、いくつかの手段で抑えます。まず concurrency を設定し、同じ PR で新しいコミットが来たら走行中のレビューをキャンセルさせます。これで連続プッシュ時の重複実行が消えます。次に、ドキュメントのみの変更や軽微な差分ではレビューをスキップする条件を paths フィルタや差分行数のしきい値で入れます。さらに、毎コミットではなく PR を Ready for review にしたタイミングや、特定ラベルが付いたときだけ走らせる運用にすれば、ドラフト段階の試行錯誤にコストをかけずに済みます。

渡すコンテキスト量の制御も効きます。前述のとおり差分中心に絞ること、巨大な自動生成ファイルやロックファイルはレビュー対象から除外することで、1 回あたりの消費を下げられます。コスト最適化の考え方はローカル運用でも共通で、Claude Code のコスト最適化 の発想がそのまま CI にも応用できます。

誤検知・過剰指摘を抑えるプロンプト設計

AI レビューを導入した直後に最も嫌われるのは、的外れな指摘や、すでに正しいコードへの過剰な「改善提案」です。これが続くとチームは指摘を読まなくなり、せっかくの仕組みが形骸化します。プロンプト設計で抑え込むのが要点です。

効くのは、まず指摘の範囲を絞る指示です。「バグ・セキュリティリスク・明確な規約違反に限定し、好みのスタイルや軽微なリファクタ提案はしない」と明示するだけで、ノイズは大きく減ります。次に、重要度の付与を必須にします。指摘を Critical / Warning / Info のように分類させると、レビュアーは Critical だけ確認すれば最低限の安全が担保され、Info は時間があるときに見ればよくなります。

確信度のしきい値を持たせるのも有効です。「確証が持てない指摘は出さない」「推測でしか言えないことは前置きを付ける」と指示すると、断定的な誤指摘が減ります。加えて、既存コードの慣習や設計意図を尊重し、PR の差分外の書き換えを提案しないよう制約をかけると、レビューが差分の文脈に収まります。

プロンプトは一度書いて終わりではありません。導入初期は実際に出た誤検知を集め、それを抑える指示をプロンプトや CLAUDE.md に追記していく運用が前提です。数週間チューニングを回すと、チームが信頼できるレビュー精度に落ち着いてきます。

FIXIT の運用 — リリースリードタイム短縮の実感

FIXIT では、複数のクライアントプロジェクトで Claude Code を CI に組み込んでいます。共通して効いているのは、レビューの往復回数が減ることでマージまでのリードタイムが縮む点です。PR を開いた直後に一次レビューが返るため、作者は人間のレビューを待つ前に初歩的な指摘を片付けられ、レビュアーが見る頃には論点が本質的なものに絞られています。

運用設計の勘所は、AI レビューを「品質を確定させる門番」ではなく「人間レビューを助ける一次フィルタ」と位置づけることです。確定的な品質は lint・型・テストの Required check で担保し、Claude Code はそこに乗らない観点を補強する。この役割分担を最初に決めておくと、AI の指摘に振り回されず、安全にマージできるプロセスが組めます。あるプロジェクトでは、この構成で初歩的な手戻りが目に見えて減り、レビュアーの負荷が下がったという手応えがありました。

CI 連携は、ローカルでの Claude Code 運用が固まった先にあるフェーズです。導入の全体像から自社プロジェクトへの落とし込みまでを伴走する支援は AI 駆動開発のサービス で提供しています。

よくある質問 (FAQ)

Claude Code を CI に組み込むのに必要な準備は何ですか

GitHub Actions が使えるリポジトリと、Anthropic の API キーがあれば始められます。API キーは GitHub の Secrets に格納し、.github/workflows/ に PR トリガーのワークフローを置きます。まずはサマリーコメント形式の一次レビューから始め、lint・型・テストの Required check は従来どおり残すのが安全です。ローカルでの Claude Code 運用が固まってから CI に広げると、レビュー観点を CLAUDE.md に蓄積した状態で移行でき、立ち上がりがスムーズです。

AI のレビューだけでマージを自動承認してよいですか

推奨しません。AI のレビューは確率的で、毎回同じ判断を返す保証がないためです。確定的に白黒がつく検証 (lint・型チェック・テスト) を Required status checks にしてマージ条件にし、Claude Code のレビューは助言としてコメントに残す位置づけにします。人間がその指摘を読んで取捨選択する分担なら、確定品質を担保しつつ AI で観点を補強できます。

API コストが膨らまないか心配です

synchronize イベントは毎コミットで発火するため、無制御だとコストが積み上がります。concurrency で連続プッシュ時の重複実行をキャンセルし、レビュー対象を PR の差分に絞り、ロックファイルや自動生成物を除外するのが基本です。さらに Ready for review や特定ラベルのときだけ走らせる、lint と型が通った PR にだけレビューを実行するといった条件を入れると、ドラフト段階の無駄な消費を避けられます。

誤検知や過剰な指摘が多くて困っています

プロンプトで指摘範囲を絞るのが最も効きます。バグ・セキュリティ・明確な規約違反に限定し、好みのスタイル提案はさせない、確証のない指摘は出させない、と明示します。指摘に重要度を付けさせれば、レビュアーは Critical だけ確認すればよくなります。導入初期は実際に出た誤検知を集め、それを抑える指示をプロンプトや CLAUDE.md に追記していくチューニングを数週間回すと、信頼できる精度に落ち着きます。

Claude Code の CI 連携は、ローカル運用の延長で「人がいなくても回るレビュー」を組む取り組みです。自社の開発フローに合わせた CI 設計や品質ゲートの組み方を相談したい方は、AI 駆動開発の無料相談 (/contact/) からお気軽にお問い合わせください。