エンジニア向けAIコードレビュー術｜Claude×ChatGPT

「自分のタスクも進めたいのに、PRレビューが積み上がって手が止まる」——チームの規模が大きくなるほど、エンジニアのレビュー工数は肥大化します。筆者が所属するチームでは、ClaudeとChatGPTを一次レビュワーとして組み込むことで、レビュー平均時間を1PRあたり18分から6分に短縮できました。本記事では、その役割分担と実戦プロンプトを公開します。

なぜ一次レビューをAIに任せるのか

コードレビューの工程は、大きく分けて次の3段階があります。

1. 機械的チェック: 命名規則・型ズレ・単純なバグ・コピペミス
2. 設計レビュー: 責務分離・拡張性・パフォーマンス
3. ドメイン判断: 要件との整合性・ビジネスロジックの妥当性

このうち(1)と(2)の一部はAIが得意領域です。人間のレビュワーは(3)と(2)の意思決定部分に集中できるため、結果的に品質が上がります。AIを「自分の代わりに1回目を読んでくれる同僚」として位置づけるのがポイントです。

役割分担: Claude vs ChatGPT

編集部では用途別に明確に使い分けています。

工程	担当AI	理由
静的チェック・バグ検出	Claude	長文のdiffを一度に読み込める
リファクタ提案	Claude	コード品質への提案が構造的
エラーログ調査・外部情報	ChatGPT	Web検索・最新フレームワーク情報が強い
画像（UI）からの挙動推定	ChatGPT	マルチモーダル画像認識が優秀
テストケース生成	Claude	網羅性の高いテストを設計しやすい

この役割分担は「ChatGPT vs Claude｜用途別の使い分け完全ガイド2026」でも触れていますが、コードレビュー用途に限ると、ベースはClaude、情報収集はChatGPT、というハイブリッドが最強です。

ステップ1: 一次レビュー用の万能プロンプト

まずはClaudeに投げる一次レビュー用プロンプトです。これを自分のPRテンプレートにコピペしておくだけで、毎回同じ観点でAIレビューが走ります。

あなたは経験15年のシニアソフトウェアエンジニアです。
以下のPull Requestのdiffを、次の観点で厳しくレビューしてください。

## レビュー観点
1. バグの可能性（null/undefined、境界値、例外処理）
2. 型安全性（TypeScriptならany濫用、anyアサーション）
3. 命名・可読性（関数名/変数名が意図を表しているか）
4. 設計（単一責任、依存方向、副作用の局所化）
5. パフォーマンス（N+1、不要な再レンダリング、O(n^2)）
6. セキュリティ（SQLインジェクション、XSS、認可漏れ）
7. テストの網羅性（境界ケース・エラーケース）

## 出力フォーマット
- 指摘は優先度タグを付ける: [Critical] / [High] / [Medium] / [Low] / [Nit]
- 各指摘に「該当ファイル名:行番号（推測可）」を付与
- 代替コードの提案は最小限の差分で示す
- 不明点は質問形式で提示してよい

## PR情報
- PR目的: {ここに1-2行で目的を記述}
- 関連Issue: {Issue番号}

## diff
{ここにgit diff出力を貼り付け}

このプロンプトの肝は優先度タグです。[Critical]や[High]を明示的に出させることで、自分が対応すべき項目の見分けがつきます。[Nit]ばかり並んでいたら、そのPRは大きな問題なしと判断できます。

ステップ2: リファクタ候補の提案を引き出す

diffレビューで「ここは改善の余地がある」と感じた部分に、追加でリファクタ提案を求めます。

上記の中で特に以下のコードブロックに注目してください。

{対象コードを再掲}

このコードを、次の観点でリファクタリング案を3つ提案してください。
1. 関心の分離を強化する案
2. テスタビリティを高める案
3. 型安全性を最大化する案

各案は以下を含めてください:
- 提案コード（before/after対比）
- メリット（3点）
- デメリット・トレードオフ（あれば）
- 採用を推奨するケース

3案を比較形式で出させることで、自分の設計センスと照らし合わせながら最適解を選べます。「1案だけ出して」と頼むと、AIが無難な選択肢に寄ってしまい、学びが減ります。

実務での使い方

筆者は「dailyのリファクタ15分枠」を作り、前日に気になった箇所をこのプロンプトに投げるようにしています。週に3-4箇所の改善が積み上がるだけで、1ヶ月後のコードベースは別物になります。

ステップ3: テストケース生成

機能追加のPRでは、テストの網羅性が不足しがちです。Claudeは設計起点で網羅的なテストを作るのが得意です。

以下の関数について、ユニットテストを作成してください。
テストフレームワーク: {Vitest/Jest/Pytest等}

## 関数コード
{関数を貼り付け}

## テスト観点
1. ハッピーパス（正常系）
2. 境界値（0、負数、最大値、空配列、空文字列）
3. 異常系（型ミスマッチ、例外、タイムアウト）
4. セキュリティ（不正入力、インジェクション）
5. 並行処理（競合、順序依存）

## 要件
- テストケース名は仕様を表す日本語で
- describe/itで階層化
- モックが必要な依存は明記
- 不足情報があれば質問形式で提示

テスト生成プロンプトの注意点

自動生成されたテストは必ず「本当に意味のあるアサーション」になっているかを目視で確認してください。AIはプレースホルダ的なexpect(result).toBeTruthy()のような弱いアサーションを挟みがちです。

Before/After: 実測データ

筆者のチーム（エンジニア6名）で1ヶ月間計測した結果が以下です。

指標	Before（人間のみ）	After（AI併用）
1PRあたりレビュー時間	約18分	約6分
1日あたりレビューPR数	3-4件	8-10件
リリース後バグ発生率	月3件	月2件
レビュワー負荷感（1-5）	4.2	2.8

レビュー時間が減ったうえにバグ件数も微減しました。AIが機械的ミスを着実に拾う分、人間は設計とドメイン判断に集中できる、という好循環です。

注意点: AIレビューを過信しない

• ドメイン知識の欠如: ビジネスルールや社内規約はAIには見えません。最終判断は人間が必ず行う。
• バージョン依存: 使用ライブラリの最新仕様をAIが把握していない場合があります。ChatGPTのWeb検索機能を併用するとこのギャップを埋められます。
• 秘匿コード: 競争優位に直結する核心ロジックは、エンタープライズ契約やローカルLLMを検討してください。

エンジニア以外にも応用可能

このレビューワークフローは、マーケティング担当者が書くSQLクエリや、データアナリストのPythonノートブックにもそのまま応用できます。実際、編集部のマーケチームはClaudeに「Claude Artifacts活用事例5選」で紹介した手法と組み合わせ、非エンジニアの社内SQLレビューを自動化しています。

まとめ: 「レビュワー疲れ」からの解放

AIを一次レビュワーに据えることで、エンジニアの負荷は大きく軽減されます。浮いた時間は、設計ディスカッション・技術選定・若手への指導など、人にしかできない仕事に振り向けましょう。

コードレビュー用のプロンプトはプロンプトマーケットの職種タグ「エンジニア」で一覧できます。チーム全体で同じテンプレを共有すれば、レビュー品質もさらに揃います。