元々Mediumで公開：
https://medium.com/@rajkundalia/how-i-review-prs-with-ai-without-losing-my-own-judgment-f930ad30dc60
ここ数か月で、私のコードレビューのキューは完全に変わりました。エージェント型のコーディングにより、PRはより大きく、より速く生成される一方で、考えるのが難しくなっています。
私は、もっと速い仕組みが必要でした。でも、絶対に「AIに投げて、AIのチェックでレビューしたことにする」ようなことはしたくありません。
組み込みツールはあります。Claude Codeには/reviewや/deep-reviewがあり、GitHub CopilotのPRレビューもデフォルトの出来としては悪くありません。AIの一次パスだけが欲しいなら、これらはうまく機能します。ですが私は、単にAIのパス最適化をしているわけではありません。理解と、アーキテクチャ上のシグナルを最大化したいのです。
ここに、AIに重いスキャン処理を任せつつ、重い思考や判断は確実に自分の手で行うために私が使っている、反復可能なフレームワークがあります。
（注：以下で参照するすべてのプロンプトは、私のGitHubリポジトリでオープンソースです。 https://github.com/rajkundalia/ai-code-review-prompts。これらはツールに依存しません—Claude、ChatGPT、Cursor、あるいはお好みの何にでも貼り付けて使えます。）
黄金律：コンテキストの隔離
フェーズに入る前に、この仕組み全体を成立させるための、譲れないルールが1つあります：PRごとに1回のAIセッション。
自分の日々の作業、複数のPRレビュー、ランダムな質問を1つのAIセッションに混ぜると、コンテキストが失われます。PRレビューはコンテキストが濃いものです。たとえば同僚が4日後にあなたのコメントに返信してきたとき、専用で保持されたAIセッションがあると、あなたはそのコメントを最初にした理由や、自分の頭の中のモデルをすぐに思い出せます。
レビュー開始からマージまで、スレッドを生かし続けてください。
4フェーズのPRレビュー・ワークフロー
最初のプロンプトを読み込むと、そこから出発点を与えてくれます。高レベルな要約、変更されたファイル、そしてPRの中核となる意図です。そこから、私は4つの明確なフェーズを順に進めます。先に進んで省略しないでください。
フェーズ1：理解を構築する（人間が先）
次に起きることは、完全に私の番です。ファイルごと、行ごとに見て、AIに質問しながら、フローについて自分自身の理解を組み立てるまで問い続けます：
- これは何をしている？
- このデータモデルは、下流のどこで使われる？
- この前提が変わると何が壊れる？
これはあえて手作業にしています。AIに詰めて質問しても、まだ理解できないことがあれば、それは人間向けコメントとしてフラグを立てます。
このフェーズを飛ばすなら、コードをレビューしているのではなく、コードに対するAIの意見をレビューしていることになります。
フェーズ2：AIの一次パス（ノイズをふるい落とす）
ここでAIが最初の本番パスを実行します。標準的な問題や不整合を指摘します。意図的に浅いパスにしています。
この「ディープレビュー」と別フェーズにしている理由はシンプルです。明らかなものを早い段階で拾って処理しておきたいからです。次のフェーズがノイズで散らからないように、関連のない提案をすぐに切り捨てられる余地が生まれます。
これは意思決定ではなく、シグナル抽出だと考えてください。
フェーズ3：ディープレビュー（圧力テスト）
最も重いフェーズで、いくつかの特定の強制要件によって動かされます：
「チーフ・プログラマー」＆「チーフ・アーキテクト」のペルソナ
AIに特定の役割を与えると、「このコードをレビューして」といった一般的な指示よりも、鋭く、より批判的な出力になります。ドメインに合わせて役割を調整できます。たとえば、プロンプトコードをレビューしているなら、chief AI engineer などにします。
実際のカバレッジ vs. 舞台装置
AIエージェントは膨大な量のテストを生成します。放っておくと、ロジックのないデータモデル向けのテストを書いたり、Pythonが動くことを確認するだけのテストを書いたりします。私は明示的に、意味のある振る舞いの検証を探すようAIに指示します。そうすることで、ノイズを最初に掴んでおけるのです。冗長なテストを都度「削除して」とAIに頼むより、そのほうが良いです。
テストは「存在」を証明すべきではなく、「振る舞い」を証明すべきです。
悪魔の代弁者を演じる
私はLLMに、自分自身の前提に疑問を持たせます。何がまずいことになる可能性がある？ それは3か月後の本番環境でどこで破綻する？
これにより、標準的なレビューでは見落としがちなエッジケースが表に出てきます。
フェーズ4：評決（Verdict）
最後に、私はフェーズ1で得た自分の理解と、AIのディープレビューから得た洞察を統合します。AIは私に、発見事項を次のように分類する手助けをします：
- 必ず直すべきブロッカー
- あると良いスタイル上の提案
- 捨てるべきノイズ
著者の義務：セルフレビュー
あなたのコードが別の人間に渡される前に、それをレビューする責任はあなたにあります。
私はPRレビューのフレームワークを、セルフレビュー用のプロンプトに変換しました。自分のコードでも、まったく同じフェーズを順に実行します。ここに出力される結果は非常に外科的です。どのファイルのどの行か、何が問題で、代わりに何をすべきかを教えてくれます。
目的はシンプルです：
最終的にあなたの同僚からもらうコメントは、高レベルな設計上の意思決定についてであるべきであり、自分で気づけたような些細なことについてではないはずです。
継続的に質が高く、事前に検証されたPRを上げられる人は、強い「ボーナスポイント」を獲得できます。
プロセスのスケーリング
すべてのPRに4つのフェーズ全部が必要とは限りません。
- 10行の設定変更 → クイックパス
- 1,000行のリファクタリング → フルのディープレビュー
レビューの深さは、リスクと複雑さに合わせます。
小さな変更を過剰にレビューするのは無駄です。
大きな変更を過少にレビューするのは危険です。
最後に
私は思考をAIに丸投げしていません。より速く探索し、前提を検証し、意思決定をストレステストするために使っています。考えるのは、依然として私のものです。
レバレッジは新しい。
責任は新しくない。
これらのツールは非常に強力ですが、それでもリード（手綱）を握っておく必要があります。
私が使っているプロンプトとガイドラインはオープンソースにしています：
https://github.com/rajkundalia/ai-code-review-prompts
もし、より良いアイデアや改善案、ノイズを減らす方法があるなら—ぜひ本気で見てみたいです。
