AI時代のコードレビュー再定義 —— 「納品」するのはコードではなく「理論」である
導入：私たちは「文字」を打っているのではない
GitHub Copilotなどの台頭により、コードを書くスピードは劇的に上がりました。しかし、AIが生成した「動くコード」をそのままマージし続けると、いずれそのプロジェクトは「誰も中身を正しく理解していないブラックボックス」へと変貌します。
ピーター・ナウアの言葉を借りれば、プログラミングの本質はコードという「記録」を残すことではなく、「頭の中にそのシステム専用の理論（メンタルモデル）を構築すること」にあります。
1. 「理論」とは何か？ —— なぜ try-catch ではなく事前チェックなのか
例えば、在庫を減らす処理を書くとき、あなたは try-catch で例外を拾うか、事前に if 文でチェックするかを選択します。
- 単なるコード: 在庫が減ればどちらでもいい。
- 理論（メンタルモデル）: 「このシステムは秒間数万アクセスが来る。例外処理のオーバーヘッド（スタックトレース生成など）でサーバーを落とさないために、入り口で弾くのがこのシステムの『正解』だ」
このように、「なぜその設計を選んだのか」という背景にある意図やトレードオフの判断こそが「理論」です。
2. コードレビューは「モデルの同期」という儀式
コードレビューを「バグ探し」だと思っているなら、それは非常にもったいないことです。
レビューの真の目的は、作者の頭の中にある「理論（メンタルモデル）」を、レビュアーの頭の中にコピー（同期）することにあります。
- 同期できている状態: 「なるほど、将来の拡張（通知先の追加など）を考えて、あえて今は Facade（ファサード） で隠蔽しているんだな」と、設計意図が伝わっている。
- 同期できていない状態: 「このクラス、メソッドが1つしかなくて無駄じゃない？ 消しちゃおう」と、良かれと思って「理論」を破壊してしまう。
3. AIに奪われない「エンジニアの主権」
AIは過去のパターンから「もっともらしいコード」を提示してくれます。しかし、以下のことは人間にしかできません。
- 文脈に合わせた「理論」の選択: 岩槻区の農地転用ルールのように、複雑な現実世界の制約をどうコードの構造（ドメインモデル）に落とし込むかという意思決定。
- 責任の保持: AIはバグを出しても謝りませんし、運用保守もしてくれません。システム全体の「理論」を理解し、その正しさに責任を持つのは、常に「メンタルモデル」を保持している人間です。
結び：レビューを通じて「生きたシステム」を守る
コードはいつか古くなり、リプレイスされます。しかし、チームが共有した「設計の理論」は、次の開発やリファクタリングの際の強力な武器になります。
これからのコードレビューでは、「ここを直して」という指摘だけでなく、「この設計の背後にある君の理論（メンタルモデル）を教えて」という対話を大切にしたいものです。