コンテキストを考慮したコードレビューとは、コード変更を差分だけでなく、それが組み込まれるより広いシステムに照らしてレビューすることである。すなわち、その変更が既存のシステムに適合するか、ソフトウェアのインフラストラクチャに何を及ぼすか、ベストプラクティスに従っているかを見る。Phodal による AI 支援コードレビューの章は、CodeRabbit の記事を下敷きに API の変更を例に取り、こうしたレビューを、API の既存システムとの互換性やソフトウェアインフラストラクチャへの影響を確認し、既存のフレームワークに円滑に統合されるようにするものとして説明している。
用法
同章は、こうしたレビューで一般に検討される要素を次のように挙げている。
- コーディング規約 — ファイルの命名やディレクトリ構成といったプロジェクト固有の規約、そして変更が既存のライブラリ・クラス・メソッドを重複させずに再利用しているかどうか。
- 既存コードへの影響 — 変更がバグを持ち込まないか、どのような追加テストが必要か、API ドキュメントやユーザー向けドキュメントの更新が必要か。
- インフラストラクチャとパフォーマンス — データベースや API の移行が必要か、コードベースの他の箇所でパフォーマンスが低下しうるか。
- セキュリティと堅牢性 — 変更を「壊そう」と試みて、バグや脆弱性をあぶり出すこと。
- 一貫性と最適化 — 新しい API と既存 API との一貫性、変更履歴（changelog）の記載が正確か、提案された解決策がその問題に最も適しているか。
AI コードレビューツールを概観するなかで、同章は「コンテキストこそが王である（context is king）」を繰り返し現れるテーマと呼び、各ツールの異なるアプローチ — 検索拡張生成（RAG）、コードグラフ分析、コードベース全体の分析 — を、プロジェクト固有のコンテキストを供給するための競合する手段として読み解いている。これは、初期の AI レビューツールの主な限界として同章が挙げる、コンテキスト認識の欠如への直接的な応答である。例として、CodeRabbit のコードグラフ分析や、Sourcegraph Cody のコード検索による検索（retrieval）が挙げられている。
適用される場面
このアプローチは、レビュアーが人間であれ AI であれ、変更の適合性を判断できるだけのコードベースを見渡せることを前提としており、AI レビュアーにとってはそれは周辺コードをどれだけ供給するかを決めることを意味する。同章の Sourcery についての記述は、これがうまくいかなくなる点を示している。コンテキストを多く与えるほど収益は逓減し、ある点を超えると精度がかえって下がり — 誤検知（false positive）や幻覚によるレビューコメントを生む — しかもコストが高い。Sourcery はこれに対し、決定論的なフィルタを通過した差分チャンクだけを展開するという形で、コンテキストを選択的に追加している。同章において、この実践は計測された結果としてではなく、AI レビューツールのベンダー自身の文章から導かれた原則として提示されている。