結論：--max-findingsはレビューの深さを切り替える
Claude Code 2.1.288では、ローカルの/code-reviewに--max-findings <n>|allを指定し、報告するfindingの数を通常の上限より少なく、または多くできます。設定は結果の表示量を変えるもので、検出の正しさ、PRの承認、脆弱性ゼロを保証しません。まず通常設定で重大度と再現性を見て、追加調査が必要なPRだけallへ切り替えるのが安全です。
Anthropic公式のClaude Code changelogは、2.1.288で--max-findings <n>|allを追加し、指定はdefaultを渡すまで再利用されると説明しています。Code Review公式リファレンスは、GitHub PR向け機能がresearch previewでTeam・Enterprise向け、Zero Data Retention組織では利用不可であること、ローカルの/code-reviewを別経路として示しています。本稿は検出数の判断と運用に絞ります。
Code Reviewの対象と制限を分けて確認する
公式文書上、GitHub PRのCode Reviewは複数agentが差分と周辺コードを見てfindingをinline commentとして投稿する管理サービスです。一方、端末で実行する/code-reviewはローカル差分のレビューに使います。両者を同じ自動承認機能と考えると、料金、データ境界、コメントの責任者を誤ります。
| 場面 | 確認すること | 判断 |
|---|---|---|
| 小さなPR | 通常上限と重大度 | 既定値で人間レビュー |
| 大きな変更 | 追加finding、重複、ノイズ | 段階的にnを増やす |
| 監査・事故調査 | 全候補の保存と再現条件 | allを限定利用 |
| GitHub運用 | 契約、preview条件、保存範囲 | Ownerとデータ責任者が承認 |
Code ReviewのfindingはPRを自動でapproveまたはblockするものではありません。指摘数を増やしても、開発者が全件を確認しなければ運用上の安全性にはつながりません。既存のplugin evalの記事のように、入力・判定・出力を固定して比較する考え方が有効です。
--max-findingsを8手順で試す
claude --versionで2.1.288以上か、利用環境とproviderを記録します。- 対象PRの目的を、通常レビュー、広い探索、事故調査のいずれかに固定します。
- 変更ファイル、テスト、関連仕様、機密データの有無を人間が確認します。
- まず
/code-reviewを既定値で実行し、findingの重大度・場所・再現性を保存します。 - 追加確認が必要な場合だけ
--max-findings 20など明示した数で再実行します。 - 上限を決めにくい調査時だけ
--max-findings allを使い、所要時間とノイズを記録します。 - 結果を重複、誤検知、修正済み、未確認に分類し、コード変更と混ぜずにレビュー記録へ残します。
- 次の実行で既定値へ戻すなら
--max-findings defaultを渡し、CIやチーム手順も確認します。
同じPRに何度も異なる上限を試す場合は、version、prompt、対象commit、設定、結果の保存先を揃えます。検出数だけを比較すると、コード差分やモデル更新の影響を見落とします。PRの承認条件は別に持ち、重大な指摘はテスト、再現、担当者の確認で閉じます。
レビュー結果を業務へ接続する比較
「全部出す」ことと「重要なものだけ見る」ことは対立ではありません。入口の既定値、追加調査の上限、報告書へ残す範囲を分けます。利用者が検出数を増やしたことを、品質改善率や安全保証として社内宣伝しないことも重要です。
| 運用 | 向いているケース | 停止条件 |
|---|---|---|
| 既定値 | 日常の短いPR | 重大度と修正方針が確認できる |
| 固定n | レビュー時間を管理したい | 未確認findingが一定数を超える |
| all | 事故調査・境界確認 | 機密情報、実行系の副作用、ログ過多 |
GitHub連携を使う場合は、Team・Enterprise、Owner設定、対象repository、PRコメントの扱いを先に決めます。Zero Data Retentionの条件に該当するなら、Code Reviewの利用可否を公式条件に照らし、ローカルレビューや自社CIなど別経路を選びます。料金や利用上限は契約・画面でreadbackし、記事や社内表へ固定値として転記しません。
公開前チェックリスト
- Claude Codeのversionと実行面が記録されている
- GitHub PRのCode Reviewとローカル
/code-reviewを混同していない - 研究プレビュー、Team・Enterprise、Zero Data Retention条件を確認した
- 既定値、固定n、
allの使い分けと停止条件がある - findingの重大度、重複、誤検知、未確認を分類した
- 指摘数を品質保証や承認の代替にしていない
- 対象commit、設定、出力、レビュー担当者を保存した
レビューの改善を続けるなら、PRの種類ごとに代表ケースを作り、検出数・確認時間・修正率を同じ基準で記録します。セキュリティ上の判断は、Claude Codeの出力だけで確定せず、既存のSAST、テスト、専門担当者の確認と組み合わせます。運用設計の全体像はCode Review導入ガイド、変更の証跡はBash変更差分の記事も参照してください。
FAQ
- --max-findings allなら漏れなく出ますか？
- 漏れゼロは保証されません。出力上限を外して候補を広く見る指定なので、重大度、再現性、テスト、人間レビューを続けます。
- GitHubのCode Reviewでも同じ指定を使えますか？
- 公式changelogの指定はローカルの
/code-review向けです。GitHub PRの管理サービス側で同じ挙動になると推測せず、公式リファレンスと実画面を確認してください。 - レビュー運用を無料診断できますか？
- できます。対象repository、PRの種類、データ境界、現在のレビュー時間、承認者を無料診断（60秒）へまとめてください。
実装担当者へ依頼する時は、「findingを増やす」だけで終わらせず、何を発見したいのかを一文にします。認証変更なら権限とsecret、DB変更ならmigrationとrollback、外部送信なら宛先とデータ分類というように、PRのリスク軸とレビュー結果を接続します。上限の変更理由が説明できない場合は、まず既定値の結果を人間が読む方が速いこともあります。
継続運用では、Claude Codeの更新で既定の挙動や表示が変わる可能性を前提にします。月次でversion、代表PR、上限、finding分類、レビュー時間を見直し、設定をチームの共有手順へ反映します。採用を止める条件も先に決め、誤検知が増えた時に上限だけを無制限に上げないようにします。
新しい設定を導入した日は、担当者が結果を読める時間を確保し、通知だけで処理完了としない運用にします。