■ 1. AI時代におけるコードレビューのボトルネック化
- AIが実装速度を3〜10倍に引き上げた現場では、コードレビュー（PR確認）工程が新たな詰まりとなっている
- コードは大量に生成されるが、下流でシニアエンジニアがPR対応に溺れる構造が生まれている
- パネルセッションでの会場調査では、約半数がコードレビューをチームのボトルネックと認識している
■ 2. 「シニアが最後に見るから大丈夫」という前提の崩壊
- コードレビューの本来の目的は「内部規約への準拠」と「チームが定めた最低限の品質の維持」にある
- いつの間にか「最後の品質の砦」かつ「承認の儀式」に変質した
- シニアエンジニアが1日に10〜20本のPRを目視で漏れなく検査することは現実的でない
- 「シニアが最後に見る」という運用は、AI以前からすでに薄い前提であり、流量が少ない間は機能しているように見えていただけに過ぎない
- AI時代の流量増加によってその前提が剥がれた
■ 3. コードレビューの解体: 観点の言語化
- シニアエンジニアが頭の中で何を・どんな順番で・どこに照らして確認しているかを言語化する作業が「コードレビューの解体」である
- 観点が言語化されるとAIが読み取れる入力となり、定型化できる観点はAIが同じ厳密さで繰り返し安定して処理できる
- 定型レビューをAIに渡せない組織の多くは、そもそもレビュー観点が言語化できていない組織である
- 観点が言語化されていない組織では、シニアが退職した瞬間に品質が崩壊するリスクがある
- 解体によりシニアの暗黙の判断基準がハーネスのルールとして整理され、チーム全体に継承可能な形になる
- コードレビューの解体は属人性を解きほぐす作業でもある
■ 4. スイスチーズモデルによる多層防御と並列レビューの設計
- スイスチーズモデル: 穴の空いたチーズを複数枚重ねることで穴の貫通を防ぐ品質保証の考え方（航空安全の分野で発展）
- ソフトウェアでも静的解析・リンター・ユニットテスト・プロパティベーステスト・E2Eテスト・コードレビュー・セキュリティスキャンを重ねることで欠陥の貫通を抑える
- AIレビューを多層ハーネスとして組み立てる際の要点は、観点を細かく分けて並列に走らせることにある
- 実践例（セキュリティレビュー）:
- 観点を9つに分割: 権限の境界、入力検証の死角、機密値の露出経路、依存ライブラリの来歴、SSRF・SQLインジェクションなどの外部攻撃経路、CSRF防御、セッション管理、暗号化運用、ログと監査の妥当性
- Codexに9観点を1つずつ割り当て、Claude Codeにも同様に9観点を割り当て、合計18セッションを並列実行
- 両系統が同じ箇所を指した場合は確度が高い問題、片系統のみが指した箇所はトリアージ候補とする
- 並列化の理由:
- 同一モデルに同一プロンプトで長時間レビューさせると、同じ思い込みや仕様の勘違いが温存される
- 異なるモデルを当てることで思い込みの方向がずれ、穴の位置が変わって貫通リスクが減る
- 1人のシニアエンジニアが全観点を同時に処理することはそもそも過大な期待であり、観点を分けて並列に当てることで見落としを大幅に減らせる
■ 5. 観点のハーネス化がもたらす品質とスピードの両立
- 観点がハーネスに沈むと、次のPRからCIが自動で検査してくれる「当たり前の水準」として組織に定着する
- 人間の役割は「次にどの観点を入れるか」を考えることへ移行する
- これまで人材不足や難易度を理由に諦めていた品質基準も、言葉にできればAIハーネスに組み込める
- 例: テスト駆動の徹底、形式手法に基づく仕様検査、サプライチェーン攻撃の経路分析、認可境界の独立レビュー
- 「スピードが上がるから品質を犠牲にする」ではなく、観点を言語化してハーネスに沈めることで品質とスピードを同時に向上させられる
- 前提条件: 組織が自分たちのレビュー観点を言葉にできること。これができなければハーネスに何も入らない
■ 6. 砦を人から仕組みへ: 組織間の新たな格差
- 観点が言語化された組織では、砦がシニアエンジニア個人ではなくCodexやClaude Codeなどのハーネスへと移行する
- 観点が言語化できていない組織は、AIがどれだけ速くコードを生成しても最終的に人間のところで詰まる構造が変わらない
- シニアエンジニアが何を・どんな順番で・どこに照らして確認するかを書き出せる組織と書き出せない組織の間に、品質とスピードの新たな格差が生まれる