Claude CodeでPRの穴をmerge前に読む

結論：作者はローカル、teamはPR自動レビューで二段にする

読者の具体的な困りごとは、PR待ち時間を減らしたくて自動reviewを入れたのに、style上のnitや重複コメントが増え、重大なlogic errorを人間が見落とすことです。この記事を読むと、ローカル実行、PR自動実行、従来CIの役割を分け、採用条件を判断できます。

次の行動：直近10件のreview指摘を「本番障害」「security」「回帰」「保守性」「style」に分類し、Code Reviewへ必ず求める上位二分類と、出してほしくない項目を一文ずつ決めてください。

Code Reviewの提供条件と確認対象

Anthropic公式Code Review guideでは、GitHub pull requestをagent群がcodebase全体の文脈から調べ、logic error、security vulnerability、壊れたedge case、subtle regressionをinline commentとして示す機能をresearch previewと位置付けています。GitHub連携版はTeam・Enterprise subscription向けで、Zero Data Retentionを有効にした組織では利用できません。

一方、他planでもlocalの/code-reviewでdiffをreviewできます。2026年8月6日のClaude Code v2.1.223では、/reviewが/code-reviewのaliasになり、現在diffまたはPRを対象にできる形へ整理されました。effort levelを指定しない場合は、前回入力したlevelを再利用します。深いcloud reviewを選ぶultraも案内されています。

利用可否を「Claude Codeへloginできるか」だけで判断しません。GitHub組織、対象repository、subscription、ZDR、App権限、branch protection、reviewの起動条件を確認します。またresearch previewであるため、本番mergeを単独で自動承認する役割には置かず、結果の精度と運用負荷をpilotで測ります。

Code Reviewはtest runnerの代わりではありません。静的lintが確実に見つけるformat違反をAIへ重ねるより、複数fileの状態遷移、権限境界、error時cleanup、後方互換など、文脈を横断する確認へ使います。機械的規則はCI、業務判断は人間、文脈探索はCode Reviewと分担します。

ローカル・PR自動・従来CIを7軸で比較する

1. 実行時点：ローカルはpush前、PR自動は共有後、CIはcommitごとです。早期修正とteam証跡を分けます。
2. 対象：ローカルは現在diff、PR自動はpull requestとcodebase文脈、CIはtestやruleで定義した入力を扱います。
3. 再現性：CIは同じcodeとversionなら再現しやすく、AI reviewは文脈評価を含みます。重要指摘には再現testを追加します。
4. 共有：ローカル結果は作者の改善に向き、PR commentはreviewerと履歴を共有できます。秘密情報をcommentへ貼らないruleも必要です。
5. noise：作者向けは広め、PR向けはImportant中心に絞ります。nit上限とskip pathをREVIEW.mdへ書きます。
6. 権限：ローカルは端末とrepository権限、PR自動はGitHub Appと組織policyの影響を受けます。書込権限を必要以上に広げません。
7. merge判断：どの面も単独では決めません。required checks、CODEOWNERS、人間承認、release条件を残します。

最初のpilotでは、ローカルとPR自動を同時に全repositoryへ広げず、変更頻度が中程度でtestがある一つのrepositoryを選びます。既存CIが弱いrepositoryでは、AIの指摘が正しいか検証する基準も弱くなるため、先に最低限のtestとownerを整えます。

実務へ導入する8手順

1. 対象repositoryの障害履歴とreview遅延を確認し、Code Reviewへ解かせる問題を一つに固定します。目的を「reviewを自動化する」にしません。
2. subscription、GitHub組織、ZDR、repository権限を確認し、GitHub版を使えない場合はlocal /code-reviewから始めます。
3. 作者が小さなdiffで/code-reviewを実行し、指摘ごとに正しい、誤り、既存CI重複、判断不能を記録します。
4. REVIEW.mdへImportantの定義、nit上限、skip path、repository固有check、証拠の形式、再review時の収束ruleを書きます。
5. GitHub連携を最小権限で設定し、対象repositoryと起動条件を限定します。生成code、vendor、lockfileはskipまたは高い報告barを設定します。
6. 二週間または20PRをpilotし、真陽性、誤検知、重複、修正時間、reviewer待ち時間、見逃しを同じ表で測ります。
7. Important指摘にはfile・line、影響、再現条件、推奨testを要求し、作者が修正または却下理由を残します。AI commentを未確認でresolveしません。
8. 継続条件と停止条件をreviewし、noise上限、費用、権限、preview仕様変更を満たすrepositoryだけ段階拡大します。

REVIEW.mdは自由形式のMarkdownで、Claudeのreview指示に使われます。公式guideは、severity定義、nit数、skip rule、repo固有check、証拠のbar、再reviewの収束、summary形式を調整対象として挙げています。長い一般論ではなく、誤検知を減らす具体的な境界を書きます。

merge gateへ入れる前のチェックリスト

• 解く問題を一つに固定した
• Team・EnterpriseとZDR条件を確認した
• GitHub Appの対象repositoryを限定した
• local reviewで基準値を取った
• Importantの定義を書いた
• nit上限を決めた
• generated・vendor・lockfileの扱いを決めた
• 指摘にfile・line・影響・再現条件を求めた
• 既存CIとの重複を分類した
• 人間reviewerを残した
• AI commentへ秘密情報を載せないruleを決めた
• pilot終了日とownerを決めた
• 誤検知率と見逃しを測った
• 停止・rollback条件を確認した

評価ではコメント数が多いほど良いとしません。真陽性率、Important一件の確認時間、既存CIとの重複率、修正につながった割合、人間review待ち時間を見ます。見逃しはrelease後のincidentと人間が追加した重大指摘から逆算し、AIが出さなかった問題も記録します。

料金はresearch previewの提供条件や契約で変わり得るため、固定額を推測しません。Team・Enterpriseの契約、利用seat、実行頻度、深いreviewの選択、GitHub運用費を公開直前に管理画面と契約窓口で確認します。機能が表示されることと、全repositoryへ費用承認済みであることを分けます。

よくある質問と次の行動

GitHub版の提供条件、ZDR制限、agent review、REVIEW.mdはAnthropic公式Code Review guide、/review aliasとeffort指定はClaude Code公式Changelog、repository連携の全体像は公式GitHub Actions guideで公開直前にも確認してください。

GitHub連携の権限はClaude CodeとGitHubの連携、変更前の操作境界はClaude Codeの権限設定、判断記録は監査ログと判断記録へつなげます。Miraigentの無料診断では、CI、AI review、人間review、merge条件を一枚のreview flowへ整理します。