はじめに#

AIがコードレビューを補助する時代になりました。
ChatGPT、CodeRabbit、Cursorなどのツールは、構文や命名、簡単なロジックミスを高い精度で指摘してくれます。

しかしそれと同時に、現場のレビューアーにとっては新たな問いが生まれています。

「では、人間は何をすればいいのか？」

本記事では、AIレビューの導入を前提としたときに、人間のレビューアーがどこに責任を持ち、どこをAIに委ねてよいのかをレビュー視点から整理します。

「AIに任せられる範囲」と「任せてはいけない領域」#

まず、人間とAIで担える範囲の違いを整理しておきましょう。

この表から明らかなのは、AIが強いのは「現在のコード構造」に対する表層的な指摘に留まる一方、レビューアーは「コードの外にある情報」を読み取ることが求められるということです。

AIはコードを“見る”、人間はコードの“意味”を見る#

レビューアーの役割は、単にコードが正しいかどうかを判断することではありません。
コードが書かれた背景・意図・責務といった非構文的情報の妥当性を読み解く役割です。

例：ChatGPTが見落とす“設計上の危険”#

function save(data: any) {
  localStorage.setItem("backup", JSON.stringify(data));
}

@AI: Consider specifying a more precise type instead of `any`.

しかし実際には、ここで問題となるのは以下です：

• なぜlocalStorageを使っているのか？
• 保存するべきデータとして妥当なのか？
• シリアライズして安全に復元できる構造か？

これらは、文脈を理解した人間にしか判断できない問いです。

判断が必要な5つのレビュー観点#

レビューアーがAIレビューを前提にした運用に切り替えたとしても、以下の観点については必ず人間の判断が必要です。

1. 削除されたコードの意味#

• その処理はなぜなくなったのか？
• 依存モジュールに影響はないか？

2. 設計意図と変更構造の整合性#

• 「この機能追加にしては影響範囲が広すぎる」
• 「このロジックは別モジュールにあるべきでは？」

3. 要件理解に基づいた構造の検証#

• 「この設計は将来の仕様変更に耐えうるか？」
• 「この設計では例外ケースに弱いのでは？」

4. チームルール・設計原則への適合#

• 「命名規則に従っていない」
• 「コンポーネント分割のポリシーに反している」

5. 説明責任を果たせるかどうか#

• 「この変更は、なぜ必要だったのか」
• 「誰が見ても理解できる設計意図が伝わっているか」

これらはすべて、コードだけでは判断できない構造上・設計上の問いです。

AIと人間の判断領域モデル#

実務での分担方法：役割の明示と確認プロセスの整備#

1. “AIで済ませる”範囲を明示する#

• 例：構文・型・未使用コードなどはAIコメントを信頼する
• Lint + AIで完結できる領域は自動チェックで統一

2. “人間が判断すべき領域”をレビュー観点リストに明記#

人間レビュー観点チェックリスト（例）：
- 削除されたコードに意味があるか？
- 設計上、責務分離は妥当か？
- チームの命名規約に沿っているか？
- UIの状態管理に副作用はないか？
- PRの変更理由は明確に説明されているか？

3. PRテンプレートに設計意図記述欄を設ける#

### このPRで実現したいこと
- ユーザー削除処理に管理者権限チェックを追加

### 設計上の判断ポイント
- 権限チェックは `UserService` に集約して、他APIでも使えるように

こうした「設計意図の明文化」があることで、人間のレビュー判断も効率化します。

結論：AIを“判断の根拠”ではなく“補助線”とみなす#

AIレビューはもはや開発の一部になりました。
しかしそれは、「レビューを任せられるようになった」という話ではなく、「レビューを構造化しやすくなった」というだけです。

レビューアーの本質的役割は変わりません：

• 判断する
• 説明する
• 整合性を見る
• 文脈を読む

AIが補完してくれる今だからこそ、レビューアーにはより明確な判断の軸が求められています。
それは単なる「良し悪し」ではなく、「なぜこの設計が妥当かを説明できるか」という責任です。

この判断軸を持ち続けられる限り、レビューアーの価値は揺らぎません。