> 連載：Claude Code × GitHub運用フロー（全8回）
> ①Issueの書き方｜②clone & branch｜③実装させる対話術｜④動作確認とテスト｜⑤commit & push｜⑥Pull Requestの作り方｜⑦レビューを依頼する（今回）｜⑧merge & deploy（近日公開）
【連載⑦】レビューをClaudeに依頼する方法
Pull Requestを作ったあと、「このままマージしていいのかな」と手が止まったことはありませんか。Claude Codeにレビューを依頼する方法を知っていれば、その迷いはかなり減らせます。この記事では、実際に試したセルフレビューとレビュー依頼の使い分け、そのまま貼れるプロンプトまでまとめます。
Claude Codeにレビューを依頼する結論は「自分の目とAIの目を分ける」こと
結論から言うと、Claude Codeへのレビュー依頼は「自分では気づきにくい観点をAIに肩代わりしてもらう」ために使うのが一番しっくりきました。
自分で書いたコードを自分で見直すと、どうしても「書いたときの思い込み」が抜けません。「ここは大丈夫」と思っている箇所ほど、実は見落としがあったりします。Claude Codeにレビューを依頼すると、diff全体を機械的に見て、バグの可能性や冗長な書き方をリストアップしてくれます。
Claude Codeの公式ドキュメント（code.claude.com/docs/ja/code-review、確認時点2026年9月）によると、`/code-review` はgit diffを対象に、正確性のバグと、再利用・簡略化・効率化の観点からのクリーンアップ提案を行うコマンドです。デフォルトでは、ブランチのアップストリームより先のコミットと、作業ツリーの未コミット変更が対象になります。
セルフレビューとClaudeレビュー、使い分けはこうしている
私が実際にやっているのは、次の2段構えです。
1. PRを作る前に、自分でdiffをひと通り目視する（変な差分が混ざっていないかの確認）
2. PRを作ったあとに、Claude Codeへレビューを依頼する（バグ・重複・簡略化の余地を洗い出す）
最初は「AIに書かせたコードをAIにレビューさせて意味があるのか」と半信半疑でした。実際に調べてみると、この懸念はもっともで、執筆したモデルとレビューするモデルの系統が近いと、同じ盲点を共有してしまう可能性があるという指摘も見かけました。なので「AIレビューだけで完結」ではなく、最終的な合否判断は自分で行う、という位置づけにしています。
実際に使ってみて出てきた指摘
試しに自分のPRで実行してみたところ、次のような指摘が返ってきました。
- エラーハンドリングが一部のファイルだけ抜けている
- 似た処理が3箇所に重複しているので関数化できる
- 変数名が途中から命名規則からズレている
正直、「変数名のズレ」は自分では全く気づいていませんでした。diff全体を横断して一貫性を見てくれるのは、たしかにAIレビューの強みだと感じました。一方で、「このロジックはビジネス要件的に正しいか」という部分までは判断してくれません。ここはまだ自分の目で確認するしかない、というのが今のところの実感です。
公式ドキュメントによれば、`–comment` を付けるとGitHub PRへインラインコメントとして指摘を投稿でき、`–fix` を付けるとレビュー後の指摘を作業ツリーに直接適用できるとのことです。私はまだ `–fix` を試せていません。作業ツリーが自動で書き換わる機能なので、まずは指摘内容を確認してから使ってみる予定です。
読者がそのまま使えるプロンプト
ターミナルでコマンドを打つのが不安な方は、Claude Codeのチャット欄に次のように貼ってみてください。
このリポジトリの現在の変更点（git diff）をレビューしてください。
目的: マージ前にバグと改善点を洗い出すことです。
対象範囲: 現在のブランチでコミット済み・未コミットの変更全体です。
確認事項:
- 指摘のうち「バグ」と「改善提案」を分けて教えてください
- 判断がつかない箇所があれば、推測せずに確認事項として列挙してください
実行前確認: コードの自動修正（--fixに相当する操作）や、ファイルの上書き・削除は絶対に行わず、
指摘のリストアップのみを行ってください。修正を反映する場合は、変更前後の差分を提示し、
私が確認してから実行してください。
注意点：AIレビューだけで安心しきらない
いくつか、まだ迷っている部分も正直に書いておきます。
- レビュー結果の「重大度」の感覚が、人によるレビューと完全に一致するとは限らない
- effortレベル（low〜max）によって指摘の網羅性が変わるため、重要なPRほど高いレベルで試す必要がありそう
- 最終的にマージするかどうかの判断は、やはり自分（またはチームの人）が行うべきだと感じた
このあたりは、まだ試行錯誤中です。
まとめ
- Claude Codeへのレビュー依頼は「自分では気づきにくい観点の補完」として使うのが実感に合っている
- セルフレビュー→AIレビュー→最終判断は自分、という2段構えが今のところしっくりきている
- `–comment`でPRへのインラインコメント、`–fix`で自動修正も可能だが、`–fix`はまだ試せていない
- 変数名の一貫性など、diff全体を横断する指摘はAIレビューの強みだと感じた
- ロジックの妥当性判断はまだ人の目が必要、というのが今の実感
次回は連載最終回、mergeからdeployまでの最終工程をClaude Codeと一緒に進めた記録をお届けします。
—
このトピックをアプリで試す: 現在、GitとClaude Codeの操作を実際のターミナルで練習できる学習アプリを準備中です（app.maahsachi.com 公開準備中）。公開までは、この連載の各回で紹介しているプロンプトをそのまま自分のリポジトリで試してみてください。
