資料の概要
データカンパニー所属のソフトウェアエンジニア nogu氏（RevenueCat Shipaton 2026 参加・Shipaton Ambassador）による登壇資料。AIエージェント（Claude Code・Codex等）をコードレビューに活かすとき、「レビューのタイミングと観点」をどう制御（設計）するかを実践的に解説しています。
キーコンセプトは「ハーネス」。エージェントの「見る・使う・確かめる」を制御する仕組みで、モデルの賢さだけでなく何を見せるか（コンテキスト）・何を実行できるか（ツール・権限）・いつ確かめるか（検証・Hook）を設計することが重要という立場です。
AIエージェントコードレビューClaude CodeハーネスCI/CD
コードレビューの目的と「5つのレビュー対象」
コードレビューの目的（早期バグ検出・セキュリティ強化・コンプライアンス維持・知識共有）を分解すると、AIに任せる範囲が見えてきます。資料では5つの観点を「AI担当」と「人間担当」に切り分けます。
| # | 観点 | 検証項目 | 担い手 |
|---|
| 1 | 正しさ | バグ、境界条件、例外処理 | AI + テスト |
| 2 | 品質 | 可読性、保守性、重複、技術的負債 | AI + 基準 |
| 3 | 安全性 | 脆弱性、権限、データ漏洩、依存関係 | AI + スキャン |
| 4 | 設計・意図 | 要件、トレードオフ、プロダクトへの適合 | 人間 |
| 5 | 知識共有 | なぜこの実装にしたかをチームに残す | 人間 |
「AIを足すだけでは負荷は減らない」問題
観点の設計なしにAIレビューを導入すると、むしろこうなります（Bad）：
- 誤検知と見落とし: 観点が明確でなく誤った指摘が発生し、本来レビューすべき箇所が見過ごされる
- 重要度がわからない: 致命的な指摘が大量の些細な指摘に埋もれ、PJ固有の重要な欠陥がスルーされる
- 意図を判断できない: 仕様や設計背景が渡されておらず、表記やPJ固有ワードを理解できない
❌ Bad Prompt「このPRをレビューして」── 観点・出力形式・禁止事項が定まっていない依頼は、指摘の質を運任せにする。
解決策：レビューの置き方を設計する4つの軸
STEP 1
タイミング
レビューを工程全体に置く。仕様・設計（意図確認）→実装中（変更後に検証）→実装完了→PR（差分評価・CI/CDとAI評価）→マージ前（人間が評価）。早い工程で拾える指摘をPRまで持ち越さない。
STEP 2
観点
観点をコンテキストとして固定。Agent Skillやルールとして、観点（正しさ/セキュリティ/テスト/保守性）・出力内容（重要度/file:line/根拠/推奨）・禁止事項（推測/自動修正/マージ判断）を用意。同じ基準を何度でも再利用。
STEP 3
検証
Hookで検証を「必ず」挟む。LLMの気分に左右されず、編集後（変更ファイルにlint/型検索）・停止前（テストが通るまで終わらせない）・PR作成時（差分要約と検証結果を必ず添付）にイベント紐づけ。
STEP 4
独立性
サブエージェントで観点を分ける（正しさ/セキュリティ/テストの各レビュー→統合）。重複が減り抜け漏れが減る。さらに独立環境のエージェント同士で相互レビュー（Claude Code×Codex等）、最終判断は人間。
さらにレビューはCI/CDに組み込む運用を推奨：PR作成 → CI・テスト・lint → AIレビュー（CodeRabbit・Claude・Codex等）→ 指摘の整理 → 人間が判断。運用ルールの例として「重要度の高い指摘だけをマージ判断の対象にする」を挙げています。
人間が引き受ける判断を残す
| AIに渡す | 人間が持つ |
|---|
| 網羅的な検出／規約と形式の確認／テストの実行と再現／差分の要約と分類 | 設定意図とトレードオフ／リリースの可否と時期／指摘を「対応しない」判断／チームへの知識の残し方 |
📌 レビューの説明責任は、最後まで人間側に残る。
まとめ：AIコードレビュー導入の4ステップ
- ① レビュー観点を固定（Agent Skill / ルールなど）
- ② 必ず検証を挟む（Hook、CI/CD、PR）
- ③ 観点を分ける（SubAgent）
- ④ 相互レビュー（Codex、Claude Code）
「AIレビューは銀の弾丸ではなく、ハーネス（文脈・権限・検証の設計）あってこそ機能する」というメッセージが一貫した、実務にすぐ適用できる良資料です。
📄 本レポートはSpeaker Deckページから抽出したスライド本文テキスト（全17枚）に基づいて作成しています。