Claudeでコードレビューをする方法｜変更点の渡し方

Claudeでコードレビューを依頼するときは、差分と変更目的、レビュー対象のルール、確認してほしいリスクを明示します。repository全体を渡して「問題がないか見て」と頼むより、変更範囲を先に見せ、必要な周辺コードを追加する方が指摘を検証しやすくなります。Claudeの指摘は候補であり、実際のコード、テスト、CIを確認してから修正やmergeを判断します。

まず差分と変更目的を揃える

レビュー対象は、変更したdiffを中心にします。その上で、変更した理由、期待する動作、変更しない前提、関連する関数やinterfaceを渡します。目的が分からないと、意図した仕様変更を不具合とみなしたり、逆に変更の副作用を見落としたりします。

修正箇所だけでは判断できない場合、呼び出し元、型定義、設定、関連テストなど必要なファイルを追加します。repositoryを丸ごと貼るのではなく、対象の変更と影響範囲を理解するために必要な情報へ絞ります。機密情報や環境変数、実データを含むファイルを共有しないよう、送る前に確認します。

レビュー観点を一度に混ぜない

目的に応じて、正しさ、セキュリティ、境界条件、性能、互換性、テスト不足を指定します。すべてを同じ強さで評価させるより、今回の変更で失敗した場合に影響が大きい点を先に見ます。見た目や命名の好みは、動作上の問題と別欄に分けさせます。

|観点|具体的に見ること|指摘で求める根拠|

|動作|入力範囲、null、例外、状態遷移|再現条件と該当diff|

|安全性|権限、入力検証、secret、データ露出|攻撃・誤用の成立条件|

|互換性|呼び出し元、保存形式、公開interface|影響する利用者と経路|

|性能|繰り返し処理、I/O、メモリ|問題が起きる規模や条件|

|テスト|境界値、失敗経路、回帰|不足している具体case|

この表はすべての変更へ同じレビュー量を要求するためではありません。単純な文言修正と認証変更では、必要な確認の深さが違います。作業の影響に合わせて、観点を選びます。

Claude CodeのPR向けCode Reviewと通常レビュー

Anthropicの現行Helpでは、Code ReviewはGitHubのPull Requestを複数の観点で調べ、該当行へコメントする機能として説明されています。2026年9月時点の公式案内ではresearch previewで、Team / Enterprise向けであり、organization側の有効化とGitHub連携が必要です。利用条件や画面は変わるため、使う前に最新の公式案内を確認します。

Code ReviewはPRを承認・拒否する機能ではありません。レビューを受けてもmerge判断は既存の人・CIの手順に戻します。またrepositoryのCLAUDE.mdや、rootのREVIEW.mdでreview観点を追加できます。これらはGitHub PR向けの機能で、通常のClaude会話でdiffを見てもらう方法とは設定や権限が異なります。

指摘は「再現できる問題」に限定する

最初の依頼では、修正案ではなく指摘だけを求めます。各指摘に、重要度、該当fileと行、成立条件、ユーザーやシステムへの影響、既存テストとの関係を含めてもらいます。コード上で該当行がない、または成立条件が説明できない指摘は、採用前に追加説明を求めます。

「もっと読みやすくできる」は好みの可能性があります。一方、特定入力で権限チェックが飛ぶ、例外時にデータを二重登録する、といった指摘は検証可能なリスクです。レビュー結果をblocking、要修正、質問、style suggestionなどに分類し、重大度と確信度を混ぜないようにします。高い確信度でも影響が小さい指摘は、優先度が高いとは限りません。

そのまま使えるレビュー依頼

目的：[この変更で達成すること]

変更範囲：[diffと関連ファイル]

壊したくない動作：[既存仕様と互換性]

確認観点：[動作／権限／入力境界／失敗経路など]

指摘形式：[severity、file:line、成立条件、影響、根拠]

制約：まだコードを修正せず、指摘と不足情報だけを出してください。

不確実な点は、断定せず質問として示してください。

repositoryの規約ファイルを渡す場合は、どの規則がどの変更に関係するかも示させます。全ルールを貼り付けるより、対象のコードに適用される規約と例を示す方が、指摘の理由を追いやすくなります。

指摘を実コードとテストで確かめる

レビュー内容は、該当行を開き、実際に問題が起きる条件を確認します。必要なら小さなテストや再現手順で検証します。周辺コードが変わっている場合、Claudeが古い前提で指摘している可能性もあります。指摘を読んだら差分と現在のrepository状態に戻って照合します。

誤検知だった場合は、どの前提が違ったか記録します。同じ形式の誤指摘が続くなら、次のレビュー依頼で前提を明示します。大規模な修正を提案された場合は、まず影響範囲と最小修正案を聞き、依頼せずに全ファイルを書き換えさせない方が安全です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Claude

  公式サイトを見るTool詳細を見る比較を見る

修正は別の段階で行う

レビューと修正を同時に頼むと、指摘の妥当性を確認する前にコードが変わります。問題候補を人が選び、修正を依頼する場合も、一つの論点ずつに分けて差分を確認します。修正後は、指摘が解消したか、他の挙動へ影響していないかをテストします。

修正案に代替案があるなら、保守性だけでなく、互換性、データ移行、運用監視の影響を並べます。レビューは設計変更の権限を自動で与えるものではありません。API契約、保存schema、認証境界など広範囲の意味を変える提案は、既存の設計判断へ戻して扱います。

テスト観点を出す方法

テスト不足を指摘させる場合は、入力と期待結果を具体化します。「もっとテストする」だけでは実装へ移せません。正常系、空入力、上限値、不正値、権限不足、依存サービス失敗、再試行など、変更箇所に関係する条件を選びます。必要のない境界値をすべて列挙するのではなく、変更によって新しく壊れ得る経路に絞ります。

Claudeにテスト案を出させた場合、テストが実際の仕様を検証しているかを確認します。実装の現状をそのまま期待値にすると、バグをテストで固定してしまいます。仕様が不明なら、テストを書く前に設計の正本や既存契約へ戻ります。

レビュー結果の採用チェック

• 指摘の該当箇所が実際のdiffにある

• 問題が起きる入力や状態を説明できる

• 影響する利用者・データ・処理が明確

• 既存テストや仕様と照合した

• styleの好みと動作上の問題を分けた

• 修正後の検証方法が決まっている

• 最終merge判断を人と既存CIへ戻した

原因が確認できない指摘は、severityが高く見えてもそのまま採用しません。反対に、再現可能なセキュリティやデータ破損リスクを「AIの意見」として無視せず、適切な責任者へ確認します。

AIものさしの判断

Claudeによるコードレビューは、変更差分を起点に潜在的な問題を探す一次確認として使えます。変更目的、既存ルール、影響範囲、テスト観点を渡し、根拠付きの指摘だけを候補にします。PR向けCode Reviewと通常会話のレビューは、提供条件や連携方法が異なるため、混同しないでください。

指摘が正しいかは実コードとテストで確かめ、修正とmergeの決定は既存の人・CIの手順へ戻します。まず指摘のみを受け、人が採用箇所を選び、修正後に回帰テストを行う。この順なら、見落としの発見に使いながら過剰な変更を避けられます。

指摘を整理する小さな出力形式

レビュー結果は、次の項目を一件ずつ揃えると検証に移しやすくなります。

|項目|記録すること|

|重要度|merge前に直す／修正推奨／確認事項／style|

|場所|fileと行、該当するdiff|

|成立条件|どの入力・状態で問題が起きるか|

|影響|誤動作、権限逸脱、データ損失など|

|確認方法|再現手順、既存test、追加test候補|

「重大そう」という印象だけで重要度を決めず、問題の成立条件と影響を分けます。高いseverityが付いていても条件が説明されないなら、断定を保留し、根拠を追加で尋ねます。

権限や機密を扱う差分では範囲を広げる

認証、アクセス制御、secret、個人情報、データ保存に触れる変更では、対象ファイルだけでなく、呼び出し元、保存先、ログ、テスト用設定も確認します。コードをレビュー用に渡す際は、実際のkey、顧客データ、内部URLが含まれないかを調べます。PR向けCode Reviewのrepository連携も、組織管理者が許可した範囲に限定してください。

新しいAPI経路や権限を加える差分なら、正常な利用者だけでなく、権限のない利用者、期限切れ、再送、部分失敗もテスト対象にします。reviewerがセキュリティ専門家でない場合、重大な指摘を専門担当へエスカレーションします。採用前には、再現ケース・期待動作・実際の動作・該当test・判断を一件ずつ記録します。再現できない指摘は「未確認」とし、修正済み扱いにしません。修正後は同じ条件で再試験し、関連testの結果を残します。

CIが失敗した場合は、Claudeの「問題なし」より実行結果を優先し、失敗したtestを確認します。レビューが問題を見つけなかったことと、変更が正しいことは同じ判定ではありません。

修正を採用しない場合も、仕様上問題がないと確認できたのか、影響が小さいため後回しにしたのかを分けて記録すると、未解決のriskを後工程へ渡せます。

指摘に対応してコードを変更した後は、元の指摘だけでなく、追加したテストと周辺機能の回帰も確認します。テスト結果が得られない場合は、解決済みとして閉じず、検証待ちの状態を残します。