Claude Codeのコードレビュー方法4つ！プロンプト例も紹介

Claude Codeで書いたコードを、そのままマージしてよいか不安に感じる方もいるでしょう。

Claude Codeのコードレビューには、直接依頼からGitHubの自動化まで4つの方法があります。

小さな差分ならプロンプトか/code-reviewで手軽に確認でき、マージ前の不安を減らせます。

本記事では、4つの方法の違い、コピペできるプロンプト例、実行手順を解説します。AIの指摘を鵜呑みにせず、テストと仕様で検証する方法も確認してみてください。

使い方がわかっても、作業を任せるところまでは進めず「結局は自分で手を動かしている」という方は少なくありません。

チャットに指示を出して、返ってきた内容を確認して、また次を頼む。この繰り返しは自分の時間を使い続けます。

AIエージェントなら「リサーチから資料作成までやっておいて」と伝えるだけで、調べる・まとめる・作るところまで自分で進みます。

SHIFT AIのAIエージェントを学べる無料セミナーでは、この任せ方を実演を交えて解説し、空いた時間を収入につなげた会員の事例も紹介しています。

オンライン開催です。下のボタンから、セミナーの詳細をご確認ください。

Claude Codeのコードレビュー方法は4つ

Claude Codeでコードレビューする方法は、以下の4つです。

差分の大きさ、PRの有無、自動化したい範囲に合わせて選ぶと、必要以上に複雑な設定をせずに済みます。

方法	主な対象	自動化	向いている場面
通常セッション	指定したファイルや差分	なし	小さな変更をすぐ確認したい場面
/code-review	ローカルの差分やPR	手動	push前のセルフレビュー
Managed Code Review	GitHubのPR	自動・手動	組織でレビュー運用を統一したい場面
GitHub Actions	イベントで指定した差分	自動	独自のCI処理へ組み込みたい場面

通常セッション：プロンプトで小さな変更を確認する

最も手軽な方法は、通常セッションでレビューを直接依頼する方法です。対象ファイルと確認観点を文章で指定できるため、専用機能の設定は必要ありません。

たとえば、「認証処理に権限チェック漏れがないか確認して」と依頼します。差分を1〜2ファイルに絞ると、根拠を追いやすくなります。

レビュー観点を探る段階は、通常セッションから始めてください。専用機能へ進む前に、指摘の出力形式も固められます。基本的な使い方は、以下の記事で解説しています。

/code-review：ローカルの差分を確認する

push前の差分をまとめて確認するなら、/code-reviewが適しています。

任意のClaude Codeセッションから呼び出せ、未コミット変更やブランチ差分を対象にできます。必要に応じて、次の範囲へ絞れます。

• ファイルパス
• PR番号
• ブランチ名
• ref範囲

レビュー後は、ターミナル上の指摘を読んで修正対象を選びます。GitHub Appを使わないセルフレビューとしても利用できます。

対象を絞れば、マージ前の確認を標準化しやすくなります。
>Claude Code公式ドキュメントはこちらから

Managed Code Review：GitHub PRを組織で自動レビューする

組織のPRを継続的に確認するなら、Managed Code Reviewが候補です。

GitHub Appを対象リポジトリへ接続し、PR作成時、pushごと、手動のいずれかでレビューを始めます。主な確認対象は以下の通りです。

• ロジックエラー
• セキュリティ上の問題
• 既存機能への回帰

ただし、Managed Code Reviewは組織向けの機能です。個人のローカルレビューとは、利用条件や設定場所が異なります。

チームで同じトリガーと判定基準を使えば、担当者ごとの確認漏れを抑えられます。

GitHub Actions：独自のCIワークフローを構築する

既存のCIへClaude Codeを組み込むなら、GitHub Actionsが向いています。CIは、コード更新時にテストや検査を自動実行する仕組みです。

GitHub Actionsでは、ワークフロー側で次の項目を設計できます。

• 実行イベント
• プロンプト
• 使用モデル
• レビュー後の処理

たとえば、特定ディレクトリの変更時だけレビューし、結果を別の処理へ渡せます。一方、YAML、API認証、GitHub権限の設定が必要です。

独自の自動化が必要な場面だけで採用すると、運用負担を抑えられます。詳しい導入手順は以下の記事をご覧ください。

Claude Codeにプロンプトでコードレビューを依頼する3ステップ

Claude Codeにプロンプトでコードレビューを依頼する手順は、以下の3つです。

対象と判定基準を先に決めると、抽象的な一般論ではなく、修正に使える指摘を得やすくなります。

ステップ1：対象のリポジトリと差分を用意する

まず対象リポジトリでClaude Codeを起動し、確認する差分を決めます。

レビュー対象は、次の4種類から選べます。

• 未コミット変更
• 特定ファイル
• ブランチ差分
• PR

たとえば、ログイン画面の変更なら、認証処理、セッション管理、関連テストに絞ります。生成ファイルや無関係な整形は対象から外してください。

差分を機能単位に分けると、重要な指摘が埋もれにくく、人間も変更意図を追いやすくなります。確認後の修正範囲も限定できるため、テストをやり直す範囲も明確になります。

ステップ2：目的・対象・観点・出力形式を指定する

次に、レビューの判定基準をプロンプトに書きます。

指定する項目は以下の4つです。

• 変更目的
• 対象差分
• 確認観点
• 出力形式

「シニアエンジニアとして確認して」だけでは、重視する観点と合格基準が伝わりません。以下はバグ、セキュリティ、回帰を優先させる例です。

現在の変更差分をコードレビューしてください。

変更目的：
ログイン後のセッション更新処理を修正する

対象：
現在のブランチとmainの差分

確認観点：
- ロジックエラー
- 認証・認可の欠落
- 入力検証の漏れ
- 既存機能への回帰
- 不足しているテスト

出力形式：
1. 重大度をHigh・Medium・Lowで示す
2. file:lineの形式で対象箇所を示す
3. 問題の根拠と再現条件を書く
4. 最小限の修正案を示す
5. 問題がなければ「重大な指摘なし」と書く

出力に根拠と再現条件を含めると、どの指摘を先に検証すべきか判断できます。

初回の結果が抽象的なら、対象ファイルと失敗条件を追加し、同じ差分をもう一度確認してください。

ステップ3：指摘を仕様とテストで検証する

Claude Codeの指摘は修正の決定ではなく、検証を始める候補です。

指摘ごとに次の順序で確認します。

1. 指摘行と呼び出し元を読む
2. 実際に到達するコードパスか調べる
3. 要件定義、画面仕様、API仕様と照合する
4. 再現テストで失敗条件を固定する

不具合を再現できたら、修正前の失敗と修正後の成功を確かめます。証拠が取れない指摘は保留し、その理由を残してください。

仕様とテストを根拠にすると、誤検知による不要な修正や、修正から生まれる回帰を防ぎやすくなります。

コードレビュー以外の使い方や料金プランを含めたClaude Codeの全体像は、以下の記事で解説しています。

Claude Codeの/code-reviewで差分を確認する4ステップ

/code-reviewで差分を確認する手順は、以下の4つです。

コマンド実行だけで終わらず、指摘の根拠と修正後の差分まで確認してください。

ステップ1：レビュー対象の差分を決める

/code-reviewを実行する前に、確認する差分の範囲を決めます。

対象を指定しない場合は、アップストリームより先のコミットと未コミット変更が主な対象です。

他の変更が混じる場合は、次のように範囲を絞ります。

• ファイルパスを指定する
• main...my-featureのようなref範囲を指定する
• 生成ファイルや整形だけの変更を外す

git diffなどで作業目的と差分が一致しているか確認します。差分を絞ると、重要なロジックを深く調べられます。

ステップ2：/code-reviewを実行する

対象を決めたら、任意のClaude Codeセッションで実行します。

/code-review

特定の対象を見てほしい場合は、コマンドにref範囲を1つ渡します。

/code-review main...feature/session-refresh

繰り返し使う確認観点はCLAUDE.mdに記載し、個別の依頼は通常セッションで伝えてください。

コマンドが表示されない場合は、Claude Codeを現行版へ更新します。/code-reviewは同梱スキルですが、利用環境によって表示されない場合があります。

実行できる状態まで確認すれば、push前レビューを標準化できます。他のコマンドは以下の記事をご覧ください。

ステップ3：指摘の根拠と影響範囲を確認する

レビュー完了後は、指摘の根拠と影響範囲を確認します。

確認する項目は以下の5つです。

• 指摘行
• 呼び出し元
• 失敗条件
• 影響する機能
• 関連テスト

たとえば、null参照の指摘なら、実際にnullが入る入力経路と認証後のデータ変換を追います。

命名や型だけからの推測であれば、その指摘を確定として扱わないでください。

影響範囲が広い場合は、関連モジュールのテストを追加し、修正の前後で結果を比べます。根拠を追ってから修正すると、AIが作ったバグのマージを防ぎやすくなります。

ステップ4：--commentと--fixを必要に応じて使う

--commentと--fixは、対応に合わせて使い分けます。

オプション	実行例	主な用途	実行後の確認
--comment	/code-review --comment	PRのインラインコメントに投稿	投稿する指摘と対象行
--fix	/code-review --fix	修正をワーキングツリーへ適用	変更差分、テスト、仕様との整合

--commentはチームへ指摘を共有する場合に使います。--fixはファイルを更新するため、実行後のdiffとテストが必要です。

どちらも人間の判断を省く機能ではありません。共有する指摘と自動修正する指摘を分けると、不要なコメントや誤修正を減らせます。

Claude Codeのコードレビュー精度を高める3つのコツ

Claude Codeのコードレビュー精度を高めるコツは、以下の3つです。

スタイル指摘を増やすより、本番を壊すバグと固有の必須条件に焦点を当ててください。

レビューの目的と確認観点を具体的に書く

レビューの目的と確認観点を具体化すると、実務で使える指摘が増えます。

「問題を教えて」だけでは優先順位が不明確です。変更目的と一緒に、次の観点から必要なものを選びます。

• バグと回帰
• 認証・認可
• 入力検証
• パフォーマンス

出力には、重大度、根拠、再現条件、修正案の順序を指定します。結果が抽象的なら、失敗する入力条件を追加して再レビューします。

確認観点をリスクに合わせて絞り、判定基準を残すと、次回以降も同じ品質でレビューできます。

CLAUDE.mdにレビュー基準を記載する

繰り返し使うレビュー基準は、CLAUDE.mdに記載します。

毎回プロンプトで伝えると、指定漏れや表現のぶれが起きます。次のようなプロジェクト共通の項目をまとめてください。

• 必須のテストコマンド
• 重視するバグや回帰
• 除外する生成ファイル
• 指摘の出力形式

個人のローカルレビューなら、まずCLAUDE.mdに基準をまとめるだけで十分です。正本化すると、毎回同じ観点と出力形式でレビューできます。CLAUDE.mdの書き方は以下の記事をご覧ください。

AIの指摘をテストと仕様で最終確認する

AIレビューは初期チェックに使い、最終判断は人間が行います。

Claude Codeはコードを広く読めますが、ビジネス要件や企画時の意図まで常に把握しているわけではありません。人間が判断する主な項目は以下の4つです。

• 設計方針
• ユーザー体験
• 修正の優先度
• マージ可否

指摘ごとに再現テストを作り、修正前の失敗と修正後の成功を確認します。画面仕様や運用ルールは、要件定義とPR本文に照らします。

AIの提案と人間の判断を分けると、レビュー速度を上げながら誤修正を抑えられます。

注意点を押さえておけば、AIは安心して任せられる相手になります。

作業をまるごと任せるAIエージェントでは、この見極めがそのまま成果の差になります。

SHIFT AIのAIエージェントを学べる無料セミナーでは、AIに作業を任せる方法を、実演を交えて解説しています。下のボタンから詳細をご確認ください。

Claude Codeのコードレビューに関するよくある質問

Claude Codeのコードレビューに関する質問は、以下の3つです。

• Claude Codeは日本語でコードレビューできるか
• /code-reviewが表示されないときはどうするか
• Codexのコードレビューとどう違うか

回答を確認して、Claude Codeのレビュー方法を選ぶ際の参考にしてみてください。

Claude Codeは日本語でコードレビューできる？

Claude Codeは、コードレビューの指摘を日本語で出力できます。

プロンプトに「回答は日本語で」と書き、次の出力項目を指定します。

• 指摘内容
• 指摘の根拠
• 修正案

毎回日本語で出力したい場合は、CLAUDE.mdに回答言語と共通フォーマットを記載します。識別子、関数名、エラー文は原文のまま残してください。

技術用語を無理に翻訳させず、説明だけを日本語にすると、意味の取り違えを減らせます。詳細は以下の記事もご覧ください。

/code-reviewが表示されないときは？

/code-reviewが表示されない場合は、まずClaude Codeを現行版へ更新します。

/code-reviewはClaude Codeに同梱されるレビュー用スキルですが、利用できる機能は環境によって異なる場合があります。次の順で表示を確認してください。

1. Claude Codeを現行版へ更新する
2. セッションを再起動する
3. 入力欄で/を入力して候補を確認する

候補に出ないときは、通常セッションで「現在の差分をコードレビューして」と依頼すれば、同じ差分をレビューできます。ただし、/code-reviewと処理内容や網羅性が同じとは限りません。

その際は、対象の差分、バグやセキュリティなどの観点、期待する出力形式を明記します。実行方法が異なっても、人間が仕様とテストで指摘を検証する原則は同じです。

Codexのコードレビューとの違いは？

Claude CodeとCodexはどちらもAIでレビューできますが、呼び出し方と設定が異なります。

比較項目	Claude Code	Codex
主な呼び出し	/code-review、GitHub Actionsなど	GitHub上の@codex reviewなど
リポジトリ指示	CLAUDE.md	AGENTS.md
設定手順	Claude Codeの公式仕様に従う	Codexの公式仕様に従う

そのため、Claude Codeの手順に@codex reviewやAGENTS.mdを混ぜないでください。共通基準と固有の呼び出し方は分けます。

呼び出しを混同しなければ、同じ判定基準を両ツールで使えます。Codexの手順とコツは以下の記事をご覧ください。

Claude Codeのコードレビューでマージ前の不安を減らそう

Claude Codeのコードレビューは、以下の4方式から選べます。

• 通常セッション
• /code-review
• Managed Code Review
• GitHub Actions

個人で始めるなら、小さな差分をプロンプトか/code-reviewで確認します。目的、対象、観点、出力形式を指定すると、修正に使える指摘を得やすくなります。

AIの指摘はテストと仕様で検証し、マージ可否は人間が判断します。レビューを習慣化できれば、次はAIに任せる範囲と人が確認する範囲を設計できます。

ここまでの手順どおりに進めれば、目の前の作業は確実に速くなります。ただ、作業が速くなっただけでは、空いた時間が別の作業で埋まってしまうのもよくある話です。

SHIFT AIでは、AIエージェントに仕事を任せる側に回るための無料セミナーを開催しています。空いた時間を副業や収入につなげた会員の事例もご覧いただけます。

当日は、AIエージェントに作業を任せる実演と、AIで収入や働き方を変えた会員の事例をご覧いただけます。

登壇するのは、SHIFT AI代表の木内翔大です。参加は無料で、オンライン開催です。

「AIは使えているが、働き方は何も変わっていない」という方は、下のボタンから、セミナーの詳細をご確認ください。

事例を眺めるのと、自分の仕事に置き換えるのとでは大きな差があります。

しかも今は、事例のような作業をAIエージェントにまとめて任せられるようになっています。

SHIFT AIのAIエージェントを学べる無料セミナーでは、会員の実例を交えながら、AIに作業を任せる方法を解説しています。下のボタンから詳細をご確認ください。