AIコードレビュー、便利すぎて手放せませんよね。
指摘の精度も高いし、抜け漏れも減る。First Draftの相棒としてはほぼ最強です。
……ですが、たまにこうならないでしょうか？
AI： 「機能Aと機能B、構造似てる。共通化しよ（DRY）」
AI： 「同じロジックが重複してる。抽象化できるよね」
私： 「言ってることは正しい。でも、でも今回はやらない（今は納期優先。ここ共通化すると依存関係が複雑になって型パズルが始まるからあえて分けてるのにぃ……」
この 「一般論としての正しさ」vs「このプロジェクトの文脈における最適解」 のズレ。
これが、AIレビューを“便利”から“しんどい”に変える瞬間だと思ってます。
この不毛な殴り合いを終わらせたのが、PRに Not Doing（今回やらないこと） を書く運用でした。
AIはFirst Draft最強。でも「文脈・設計・負債」は人間必須
AIはベストプラクティス（一般解）を出すのが得意です。
命名・軽微なリファクタ・注意すべき書き方、こういうのはめちゃくちゃ強い。
一方で、現場での意思決定に効くのはだいたいこっちです。
- 期限（今日マージしないと詰む）
- 影響範囲（触ると爆発する）
- 既存負債（直すなら計画が要る）
- 将来設計（今の最適化が後で邪魔になる）
- チームの暗黙知（このPJの流儀）
つまり、AIが出してくれるのは「一般論の正しさ」。
人間が守るべきは「このPJでの最適解」だと考えます。
問題の正体：AIは“前提”がないと一般論しか言えない
AIレビューが一般論に寄るのは、AIがわかってくれないから……ではなく、 PRに前提（コンテキスト）が書かれていない ことが原因だと考えます。
特に足りないのがこの3つ。
- Not Doing（今回やらないこと）
- 制約（期限 / 影響範囲 / 互換性 / 既存負債など）
- 合格ライン（このPRで何が担保されればOKか）
前提がないと、AIは「理想の姿」を語るしかありません。
結果、AIは正しいことを言う。人間も正しい。でもPRは前に進まない。
解決策：PRに「Not Doing（今回やらないこと）」を書こう
Not Doing を書くだけで、レビューの論点が劇的に変わります。
- Before：理想のベストプラクティス議論（無限に盛り上がるが、終わらない）
- After：制約下での合意形成（建設的に終わる）
AIにも人間にも「今回はここまで」というレールを敷ける。
結果、レビューが 殴り合い じゃなく 意思決定 になります。
✅ コピペOK：殴られないPRテンプレ
運用ルールはシンプルに3つだけ。
- Not Doingは最大3つまで
- 理由は1行で添える
- 別PRにするなら「いつ/何を」を一言書く
## Why（背景）
- 何を解決するPRか
## What（変更内容）
- 変更点の要約（箇条書き）
## Constraint（制約・前提）
- 期限 / 互換性 / 影響範囲 / 既存負債 / チームルール
## Not Doing（今回やらないこと）
- ○○はやらない（理由：影響範囲が広い / 検証コスト / スコープ外）
- ○○の共通化はしない（理由：抽象化が過剰になって保守コストが上がるため）
- ○○は別PR（理由：計測/方針決めが先。次スプリントで対応）
## Accept Criteria（今回の合格ライン）
- このPRがマージされたら何が担保されるか（2〜3行）
“殴られがち”3大パターンと Not Doing の書き方
| パターン | AIの指摘内容 | Not Doingの書き方例 |
|---|---|---|
| 共通化しろ / 抽象化しろ | 「機能Aと機能B、構造似てる。共通化しよ（DRY）」 「同じロジックが重複してる。抽象化できるよね」 |
- 機能A/機能Bの共通化はしない 理由：仕様・エラー体系・依存が異なり、無理に共通化すると抽象化が過剰になって壊れやすい。必要になったタイミングでやる |
| ディレクトリ整理しろ / アーキテクチャ整えろ | 「構成が散らかってる。整理しよう」 「レイヤ分離して責務を分けよう」 |
- 構成変更はしない 理由：差分が膨らみレビューが崩れる。安全にやるなら移行計画が必要なので別PR |
| テスト足せ / 型厳格に / 例外統一 | 「テスト足そう」 「strictにしよう」 「例外設計を統一しよう」 |
- 厳格化/統一は見送る 理由：移行計画が必要で工数が読めない。まず現象を止めて、整備は別PRで段階的にやる |
AIレビュー採用基準（マイルール）
AIの提案を全部受けるのではなく、自分の中で基準を持つと楽になります。
- 採用しやすい：軽微なリネーム、単純な漏れ、静的解析で裏取りできる指摘、局所リファクタ
- 保留しやすい：構造変更、抽象化、広範囲な共通化、アーキテクチャ再編、計測なしのパフォ改善
- 必ず人間が判断：ビジネスロジック、データ整合、移行計画、課金/権限、セキュリティの本丸
「今回はどのレンジまでやるのか」をあらかじめ Not Doing に書いておけば、保留しやすくなります。
まとめ：AIを黙らせるんじゃなく、前提を食わせる
AIレビューは敵ではありません。ただ、前提（コンテキスト）が足りていないだけです。
だからPRに Not Doing を書く。
本音を言うと、共通化も整備もしたい。
でも「今日じゃない」を、レビューの場でちゃんと共有するための道具が Not Doing でした。
おまけ：そのまま貼れる！Not Doing 一言テンプレ集
- 共通化しない（理由：仕様が揺れていて手戻りが出るため）
- 共通化しない（理由：抽象化が過剰になり保守コストが上がるため）
- テスト追加は別PR（理由：観点整理/モック方針を先に固めるため）
- 構成整理は別PR（理由：差分が膨らみレビューが崩れるため）
- 全体最適化はしない（理由：まず不具合を止めるのが優先なため）