AI時代のコードレビュー、どうあるべきか？

 (flowkater.io)
13 ポイント 投稿者 flowkater 2026-03-09 | 4件のコメント | WhatsAppで共有
  • 15年のCTO経験から出発し、AI時代のコードレビュー論を正・反・合で整理したエッセイ
  • コードレビューは常に問題だった — 時間も人もプロセスも、すべて不足している
  • AIがコード生産量を爆発的に増やした一方で、レビュー能力はそのまま → ボトルネックはさらに大きくなる

正 — 人間レビュー必須論

  • Simon Willison: "レビューしていないコードを協業者に押しつけるな"
  • Kent Beck: 生成コストが0に近づくほど、価値は生成ではなく検証へ移る
  • Addy Osmani: "未解決の問題は生成ではなく検証だ"
  • AIがどれほど優秀でも責任は人間にある → 検証しなければならない → レビューしなければならない

反 — 人間レビュー時代終焉論

  • Bryan Finster: ナイキスト・シャノンの定理を適用 — 生産周波数だけを高め、フィードバック周波数がそのままなら、体系的に見落としが発生する
  • SmartBearのデータ: 400行を超えると欠陥検出率が急落、AIは一度に600行を生成
  • StrongDM「ソフトウェアファクトリー」: 人間はコードを書かず、読まない。意図定義とシナリオのキュレーションだけを行う
  • Stanford CodeX: "エージェントが作ってテストしたなら、誰がそれを信頼できるのか？"
  • Salesforce Prizm: diff中心のレビュー・モデル自体がAI時代には機能しない → 意図の再構成へ

合 — 何をレビューすべきか

  • latent.space: コードレビュー → 意図レビュー(Intent Review)へ転換
  • 仕様が真実の源泉であり、コードは成果物
  • 信頼を5層のレイヤーで積み上げる（スイスチーズモデル）
  • Qodoパターン: コンテキスト優先、重大度ベース、専門家エージェントによるレビュー
  • Bryan Finster: 人間によるブロッキングが必要なのは、知識不足と規制対応経路の2つだけ

おわりに

  • 著者はAIコードを直接レビューしない → QAの役割へ転換
  • AIネイティブエンジニア = 以前の時代のPMの役割を自ら担わなければならない
  • "あなたは自分のコードに責任を持てるか？"

関連記事

4件のコメント

 
kgcrom 2026-03-09

https://app.devin.ai/review

中間点の誤りのように、これもまた一つの通り過ぎる手法なのかはまだ分かりませんが、
AIと一緒にPRレビューをしながらコードの理解やバグ修正ができるツールがあるので共有します。

サイドプロジェクトをしながら、AIが行ったコード修正の意図が理解できないときに使っています。
 
pencil6962 2026-03-09

中間地点の誤謬（Argument to Moderation）: 2つの極端な主張（AとZ）があるとき、その中間地点（M）が真実または最善の解決策であると決めつける論理です。
 
overthinker 2026-03-09

一方の立場では、人間によるレビューが結局ボトルネックになる
 
vk8520 2026-03-09

半々というのは、まだ非現実的だという気がします。コードは継続して使われるものであり、LLMは確率的なので、人が自分で書いたコードを（まだは）すべて読む必要があります。レビューをしやすくするために、コンテキストや意図のようなものを理解できるよう、PRを自動テンプレートで書いてくれたり、ADRとして書く必要はあります。