結論：Claude Code はコードレビューを「置き換える」ツールではなく、レビューに入る前と最中の準備作業を肩代わりする道具です。PR を出す前の自己レビュー、観点の洗い出し、大きな差分の要約、レビューコメントと PR 説明文の整理、チームのレビュー基準の共有──この5つを Claude Code に任せると、レビューにかかる時間と「見落としたかも」という不安をまとめて減らせます。
- 要点1：レビューの工程を「観点出し・自己レビュー・差分理解・コメント整理・基準共有」の5つに分解し、それぞれにプロンプトを用意する。
- 要点2：レビュー観点は
CLAUDE.mdに書いてチーム全員で共有すると、人によってレビューのブレが減る。 - 要点3：AI の指摘には見落としと誤検知の両方がある。マージするかどうかの最終判断は必ず人がやる。
対象読者：レビューに時間がかかる・見落としが不安な開発者、チームのレビュー品質を揃えたいリードエンジニア・PM。今日できること：自分の次の PR で、出す前に Claude Code に自己レビューを1回かけてみる。
正直に言うと、私自身がいちばん時間を食っていたのが「自分の PR を出す前の最終チェック」と「他人の大きな PR を読む最初の30分」でした。差分が500行を超えてくると、どこから読めばいいか分からなくなって、結局ざっと眺めて approve してしまう。あとから「あのバグ、レビューで気づけたよな」と後悔する。これ、開発者なら一度はやったことがあるはずです。
Claude Code をレビュー前のワークフローに組み込んでから、この「最初の30分」と「出す前の不安」がかなり軽くなりました。この記事では、2026年6月時点の Claude Code で実際にどう書いたか、どこで詰まったかを含めて、レビュー効率化の5つの実践ワークフローをプロンプトとコード例つきで紹介します。
先に大事な前提を1つ。Claude Code の指摘はあくまで補助です。AI は確かに観点出しは速いですが、文脈を取り違えた誤指摘もしますし、肝心なバグを見落とすこともあります。「AI が OK と言ったから安全」ではなく、「AI に下調べさせて、人が判断する」という使い方が前提です。機密性の高いコードを扱う場合は、後述のセキュリティ注意も必ず読んでください。
この記事で紹介する効率化のワークフローは、次の5ステップです。順に手を動かしていけば、レビュー前の準備がそのまま整います。
- 自分の PR を出す前に、Claude Code で自己レビューをかける
- 他人の PR をレビューする前に、注意して見るべき観点を洗い出す
- 大きな差分を要約させ、影響範囲を先に掴む
- レビューコメントと PR 説明文の下書きを整理する
- レビュー基準を
CLAUDE.mdに書いてチームで共有する
なぜコードレビューに Claude Code を使うのか
コードレビューが重いのは、作業が一本道ではないからです。バグを探しながら、設計の妥当性を考え、テストの抜けを確認し、命名や可読性も見て、セキュリティも気にする。これを差分を追いながら同時にやるので、頭の切り替えコストが高い。
Claude Code は、ターミナルから直接リポジトリのコードを読み、git diff の結果を理解できるエージェント型の開発ツールです（公式ドキュメントの overview を参照）。だから「この差分について、バグの観点だけ先に洗い出して」のように、レビューの観点を1つずつ分けて下調べさせられます。人間がやると同時並行で疲れる作業を、AI に直列で先回りさせるイメージです。
ただし誤解しないでほしいのは、Claude Code はレビュアーの代わりではないということ。承認の責任、設計判断、チームの文脈を踏まえた取捨選択は人間の仕事です。AI は「見るべき場所のリストアップ」と「説明文の下書き」が得意で、そこを任せることで人間が本質的な判断に集中できる、という分担で考えるのが現実的です。
ワークフロー1：自分の PR を出す前に自己レビューさせる
いちばん効果が大きくて、今日からすぐ試せるのがこれです。PR を出す前に、自分の変更を Claude Code にチェックさせる。レビュアーに見つけてもらう前に、自分で潰しておくわけです。
やり方はシンプルで、変更をコミット（またはステージ）した状態で、Claude Code に差分を見させて観点ごとにチェックを頼みます。
あなたはこのリポジトリのシニアレビュアーです。
これからマージしたい変更の差分を見て、レビュー前の自己チェックをしてください。
確認してほしい観点（観点ごとに分けて出力）:
1. バグ・エッジケースの見落とし（null/空配列/境界値/例外時）
2. 設計の妥当性（責務の置き場所、既存パターンとの一貫性）
3. テストの抜け（追加した分岐にテストがあるか）
4. 命名・可読性（意図が読み取れない変数名・関数名）
5. セキュリティ（入力検証、機密情報のログ出力、権限）
各観点で「問題なし」か「要確認: 該当箇所と理由」を箇条書きで。
確信度が低い指摘には(低)と付けてください。推測でバグを断定しないこと。ポイントは2つあります。1つ目は観点を明示的に列挙すること。「レビューして」とだけ頼むと、表面的な指摘か、逆に大量の細かい指摘が返ってきて使いものになりません。観点を区切ると、人間が後で「設計の指摘だけ先に見る」といった読み方ができます。
2つ目は確信度を出させること。「推測で断定しないで、自信のない指摘には (低) を付けて」と書いておくと、誤検知を仕分けしやすくなります。私の体感では、(低) が付いた指摘の半分くらいは文脈を取り違えた誤指摘でした。それでも残り半分は気づけてよかったものなので、フィルタとしては十分機能します。
差分を渡す方法は、Claude Code がリポジトリ内のファイルを直接読めるので、「ステージ済みの変更を見て」「直近のコミットの差分を見て」と日本語で指示すれば git diff 相当の内容を拾ってくれます。明示的にコマンドの出力を渡したい場合は、次のようにシェル側で差分を作っておいてから読ませる方法もあります。
# レビュー対象の差分をファイルに出しておく
git diff main...HEAD > /tmp/pr.diff
# Claude Code 起動後のプロンプト:
# /tmp/pr.diff の内容を読んで、上の5観点で自己レビューしてワークフロー2：レビュー観点を洗い出してもらう
他人の PR をレビューするとき、いきなり差分を読み始めると視野が狭くなります。先に「この変更で特に気をつけて見るべき場所」を Claude Code に洗い出させてから読むと、漏れが減ります。
このブランチの変更（main との差分）をレビューします。
差分の内容から、レビュアーとして特に注意して見るべきポイントを優先度つきで挙げてください。
- 触っている機能ごとに「壊れやすい場所」を指摘
- 変更が他のどのモジュールに影響しうるかを推測
- テストでカバーされていなさそうな分岐を列挙
- 「ここはレビュアーが手元で動かして確認すべき」という箇所があれば明示
確信が持てない推測には(要確認)を付けてください。これは「答え合わせ」ではなく「読む順番のナビ」として使うのがコツです。Claude Code が挙げたポイントを、人間が実際に差分を読みながら確認していく。AI が見落としたところを人間が、人間が見落としたところを AI が、お互いに補完する形になります。
観点出しは、レビュー基準が曖昧なチームほど効きます。「何を見ればいいか分からない」若手が、ベテランの観点を借りられるからです。後述のワークフロー5で、この観点自体を CLAUDE.md に固定すると、チーム全体のレビュー品質が揃っていきます。
ワークフロー3：大きな差分を要約して影響範囲を掴む
500行、1000行を超える PR は、読む前に心が折れます。ここで Claude Code に「まず全体像を要約させる」と、読み始めのハードルがぐっと下がります。
このブランチ（main との差分）の変更全体を要約してください。
出力フォーマット:
## この PR が何をするものか（3行以内）
## 主な変更ファイルと役割（ファイルごとに1行）
## 振る舞いが変わる箇所（ユーザー・API・DBへの影響）
## レビューで重点的に見るべき差分 Top3
事実だけ書いてください。差分に書かれていない機能を勝手に補完しないこと。「差分に書かれていないことを補完するな」という一文は地味に重要です。これがないと、Claude Code が「たぶんこういう意図だろう」という推測を事実のように書いてしまい、レビューの判断を狂わせます。要約はあくまで差分という一次情報に忠実であるべきで、想像で埋めさせてはいけません。
大規模なコードベースを横断して影響範囲を追いたいときは、Claude Code がリポジトリ全体を検索しながら関連箇所を辿れる点が効きます。「この関数のシグネチャを変えたけど、呼び出し元は全部直っている?」のように聞くと、差分の外まで含めて確認してくれます。ただしこれも結果を鵜呑みにせず、重要な箇所は人間が grep で裏取りするのが安全です。
ワークフロー4：レビューコメントと PR 説明文を整理する
レビューで意外と時間を食うのが「指摘の言語化」と「PR 説明文を書くこと」です。頭では分かっているのに、相手に伝わる文章にするのに5分かかる。ここを Claude Code に下書きさせます。
レビューコメントの整理は、自分のメモを渡して整えてもらう使い方が一番速いです。
以下は私がレビューで気づいた点のメモです。
これをレビューコメントとして、相手が直しやすいように整えてください。
- ここ、エラー時に握りつぶしてる。ログ出して上に投げるべき
- この関数長すぎ。3つに分けられる
- 命名 getData が曖昧。何を取るか分かる名前に
ルール:
- 高圧的にしない。「〜してはどうでしょう」のトーン
- 「なぜそう直すべきか」の理由を一言添える
- 必須(must)と提案(nits)を分けてPR 説明文の方は、差分から下書きを作らせます。
このブランチの差分から、PR の説明文を書いてください。
テンプレート:
## 変更概要
## 変更理由（なぜ必要か）
## 主な変更点（箇条書き）
## レビュー時の確認ポイント
## 動作確認した内容
差分から読み取れる事実のみ。やっていないテストを「実施済み」と書かないこと。「やっていないテストを実施済みと書くな」という制約は必須です。AI は説明文を“それっぽく”埋めようとして、確認していない動作確認まで書いてしまうことがあります。下書きを受け取ったら、必ず自分で読み直して、事実と違う部分を消す。これは人間の責任です。
ワークフロー5：レビュー基準を CLAUDE.md でチーム共有する
ここまでの4つは「個人がレビューを速くする」話でした。最後の5つ目は「チームでレビュー品質を揃える」話です。鍵になるのが CLAUDE.md です。
公式ドキュメントによると、CLAUDE.md はプロジェクトの永続的な指示を書いておくマークダウンファイルで、Claude Code が毎セッションの開始時に読み込みます。プロジェクトルートの ./CLAUDE.md（または ./.claude/CLAUDE.md）に置けば、バージョン管理を通じてチーム全員に共有されます。ここに「うちのチームのレビュー観点」を書いておけば、誰が Claude Code でレビューしても同じ基準が適用されるわけです。
# CLAUDE.md（抜粋）
## コードレビューの観点
PR をレビュー・自己レビューするときは、以下を必ず確認する。
### 必須（must）
- エラーを握りつぶしていないか（catch して握り潰すの禁止）
- 外部入力のバリデーションがあるか
- 機密情報（APIキー・個人情報）をログに出していないか
- 追加した分岐にテストがあるか
### 推奨（nits）
- 関数は50行以内を目安に
- 命名は「何をするか」が読み取れること
- マジックナンバーは定数化
## レビューコメントのトーン
- 高圧的にしない。提案ベース（〜してはどうでしょう）
- must と nits を必ず分ける個人の好みは CLAUDE.md ではなく、ユーザー単位の ~/.claude/CLAUDE.md に分けて書けます。プロジェクト共有のルールと個人ルールを混ぜないのがコツです。公式ドキュメントでは、組織全体に配る managed policy、ユーザー単位、プロジェクト単位、ローカル単位（CLAUDE.local.md）という4階層が説明されています。チームの基準はプロジェクト単位に、自分だけの好みはユーザー単位に置く、と切り分けます。
さらに踏み込むなら、レビュー用のカスタムスラッシュコマンドを .claude/commands/ に置く手もあります。たとえば .claude/commands/self-review.md にワークフロー1のプロンプトを書いておけば、/self-review の一言で自己レビューが走ります（2026年6月時点では、カスタムコマンドは Skills に統合されており、.claude/commands/ のファイルもそのまま動作します）。チームで観点をプロンプト化して共有することで、「レビューのやり方」自体を資産にできます。
なお、Claude Code には /code-review や /security-review といったレビュー向けのバンドル機能も用意されています。チーム独自の観点を CLAUDE.md やカスタムコマンドで足しつつ、こうした標準機能も併用すると守備範囲が広がります。専用の観点でレビューさせたいときは、独立したコンテキストを持つサブエージェント（.claude/agents/ に定義する code-reviewer など）を使う方法もあります。
よくある失敗パターンと対策
私が実際にやらかした失敗を共有します。同じ轍を踏まないでください。
❌ AI が「問題なし」と言ったからそのままマージ
これが一番危険です。Claude Code は見落とします。特にビジネスロジックの間違い（仕様の取り違え）は、コードとして正しく書けていれば AI は気づけません。⭕ AI の指摘は観点の下調べと割り切り、マージ判断は人間が差分を読んでから下す。
❌ 大量の細かい指摘をぜんぶ鵜呑みにして直す
観点を絞らずにレビューさせると、些末なスタイル指摘が大量に返ってきて、本質的な問題が埋もれます。⭕ 観点を列挙し、(低)（要確認）で確信度を出させて、人間が仕分けする。
❌ 機密性の高いコードをそのまま読ませる
クライアントの未公開コード、認証ロジック、個人情報を含むコードを無防備に扱うのはリスクです。⭕ 機密コードを扱う前に、組織のデータ取り扱いポリシーとツールの設定（公式の security ドキュメント）を確認する。社外秘の判断が必要なら人に確認する。
❌ 要約や説明文を読まずにそのまま使う
Claude Code は差分にない内容を推測で補ったり、やっていないテストを「実施済み」と書いたりします。⭕ プロンプトで「事実のみ・推測禁止」を指示し、生成物は必ず人間が読み直して事実と照合する。
まとめ：AI に下調べ、人が判断
Claude Code でコードレビューを効率化するコアは、レビューを5つの工程に分解して、それぞれを AI に下調べさせることです。自己レビュー、観点出し、差分要約、コメント・説明文の整理、そして CLAUDE.md での基準共有。どれも「AI がやってくれて人間が確認する」という分担で成り立ちます。
繰り返しになりますが、AI の指摘には見落としと誤検知があり、マージの最終判断は必ず人がやるのが大前提です。機密コードの取り扱いにも注意してください。この線引きさえ守れば、レビューにかかる時間と「見落としたかも」という不安は、確実に軽くなります。
今日やることはシンプルです。次に出す自分の PR で、ワークフロー1の自己レビューを1回かけてみてください。それだけで「出す前の不安」が変わるのを体感できるはずです。慣れてきたら、観点を CLAUDE.md に書いてチームに広げていきましょう。
関連して、テスト・QA の自動化と組み合わせるとレビュー前の品質がさらに上がります。Claude CodeでQA・テスト自動化を加速する実践ガイドも参考にしてください。レビュー基準を書く土台となる CLAUDE.md の設計についてはCLAUDE.md設計・運用ガイドが詳しいです。Claude Code 全体の使いこなしを体系的に学びたい方はClaude Code 実践テクニック完全ガイドを、API 仕様の変更差分に特化したレビューはAPI仕様変更レビューをClaude Codeで標準化をどうぞ。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。
参考・出典
- Claude Code overview – Anthropic 公式ドキュメント
- How Claude remembers your project（CLAUDE.md / memory）- Anthropic 公式ドキュメント
- Slash commands（カスタムコマンド / /code-review）- Anthropic 公式ドキュメント
- Subagents（code-reviewer 等）- Anthropic 公式ドキュメント
- Claude Code security – Anthropic 公式ドキュメント
- Claude Code: Best practices for agentic coding – Anthropic Engineering
