AI時代のコードレビュー

レビューを減らすのではなく、
役割を分解して再配置する

2026-04-22

ara_ta3 avatar

ara_ta3

Scalaが好きなエンジニア

サポーターズCTO

スプラの最大XPは2630です。

目次

  1. 起: AI Agent開発における課題感
  2. 承: コードレビューの中身について
  3. 転: コードレビューの分解と再配置
  4. 結: 暫定解として言語化

3行まとめ

レビューに時間が集まりやすいのは、レビューが複数の役割を背負っているからだと思っている。

機械で確認できるものや AI に寄せられるものは、できるだけ先に分解して任せたい。

そのうえで人は、ドメイン理解や設計判断のような最後に向き合うべきことへ時間を使いたい。

レビューから切り出した先 主に任せたいこと
機械がやるべきもの テスト、型、lint、CI、静的解析
AIに寄せられるもの 背景や意図の整理、仕様との差分説明、チーム方針の参照
人がやるもの ドメイン理解、設計判断、複雑さの許容、認識共有

起: AI Agent開発における課題感

AI Agent によって実装の初速はかなり上がった

変更を作る速度は、以前と比べ物にならないくらい上がっている
ただ、そのまま安心して本番に出せる状態かというとそうではない

なぜだろう

起: AI Agent開発における課題感

AI が出したものを、そのままはマージしづらい

  • このチームではあまりやらない書き方や設計だなぁ
  • 正しそうだけど、ビジネスの将来を踏まえた設計として妥当なんだっけな
  • その実装は今後やめていきたくて、別の書き方をしてほしいんだよな
  • 正直、どういう意図なのか依頼した自分もようわからん
  • 1つの PR に関心事が入りすぎていて、差分がでかいな

起: AI Agent開発における課題感

なんか違うを説明するのが、けっこう重い

  • まず、でかい差分をちゃんと読まないといけない
  • そのうえで、何が微妙なのかを自分の中で整理しないといけない
  • 「なんか違う」を、設計や保守やチームの書き方の話に分解しないといけない
  • さらに、どう直してほしいかまで書かないといけない
  • これが毎回レビューに乗ると、けっこうしんどい

起: AI Agent開発における課題感

つまりレビューには、差分確認以上の仕事が集まっている

レビューが悪いというより、
レビューにいろいろな役割が集まってきたのだと思う

じゃあレビューやめよう!

でも、やめられるんだっけな……

承: コードレビューの中身について

チームメンバー(人)の PR でも、結局いろいろ見ている

  • このチームで持ちたい書き方か
  • 将来のビジネスを踏まえた設計として妥当か
  • 読む人に無駄な認知負荷をかけていないか
  • この先も育てたい実装か

コードが動くかだけではなく、
その変更をチームとして持ちたいかも見ている

承: コードレビューの中身について

「Googleのソフトウェアエンジニアリング」でも丁寧に整理されている

  • 「コードの正しさをチェックする」
  • 「コードの変更が、他のエンジニアにとって意味を把握できるものであることを保証する」
  • 「コードベース全体での一貫性を強制する」
  • 「知識共有を可能にする」

『Googleのソフトウェアエンジニアリング』第9章より

承: コードレビューの中身について

人間同士では、LGTM だけで進む PR もある

チームのコードベースに深い理解があって、
認知負荷や背景共有まで踏まえた人の PR なら、
短いレビューで自然に進むことがある

AI でもそういう状態を作りたい

差分を出すだけではなく、
背景や判断基準まで踏まえた変更を出せるようにしたい

承: コードレビューの中身について

いまは、そのいろいろを PR レビューでまとめて扱っている

  • 動作確認
  • 設計判断
  • 認知負荷の確認
  • 背景や意図の補完
  • 修正方針の提示

1つの場に載ると、やはり重い

承: コードレビューの中身について

レビューが重いのは、複数の仕事が同じ場に混ざっているから

  • 差分は増えたが、読む速さは同じようには増えていない
  • 違和感を分解し、言葉にし、修正方針まで返す必要がある
  • 設計相談や背景共有まで PR に載りやすい

ではどうするか

転: コードレビューの分解と再配置

レビューで見ている関心事

  • 動作確認
  • 設計判断
  • 認知負荷の確認
  • 背景や意図の補完
  • 修正方針の提示

これらを全部、同じ場所で処理しなくてもよいはず

転: コードレビューの分解と再配置

これらで対応できるのではないかと考えている

  • 動作確認
    • → テスト、型チェック、lint、CI、静的解析
  • 設計判断 / 認知負荷の確認
    • → SKILL として、チーム方針や読みやすさや避けたい複雑さを言語化する
  • 背景や意図の補完
    • → Issue、design doc、PR description
  • 修正方針の提示
    • → 毎回レビューで示さなくてよいように、SKILL をアップデートし続ける

転: コードレビューの分解と再配置

分類すると、だいたい3つになる

  1. 機械がやるべきもの
  2. AI に寄せられるもの
  3. 人がやるもの

今までも 1 は機械に任せてきた
最近は 2 を広げやすくなったのが大きいと思っている

転: コードレビューの分解と再配置

軽くまとめるとこう

1. 機械がやるべきもの
テスト、型、lint、CI、静的解析。ここは今までも仕組みに寄せてきたし、言葉で説明せずに機械的に済ませられるからこそ重要だと思っている。

2. AI に寄せられるもの
背景や意図の整理、仕様との差分説明、チーム方針の参照。最近はここを広げやすくなったし、言語化によって AI に寄せやすくなった領域だと思う。

3. 人がやるもの
ドメイン理解、設計判断、複雑さの許容。レビューにおけるコメント往復より理解を揃える時間かもしれない。今はここが残るが、今後はさらに AI に寄せられるかもしれない。

つまり?

結: 暫定解として言語化

ここまでのあらすじ

  • レビューは、正しさ確認だけの場ではない
  • いろいろな関心事がレビューに集まっている
  • だからレビューは重くなる
  • そのまま全部をレビューで扱わなくてもよいはず

結: 暫定解として言語化 (3行まとめ再掲)

レビューに時間が集まりやすいのは、レビューが複数の役割を背負っているからだと思っている。

機械で確認できるものや AI に寄せられるものは、できるだけ先に分解して任せたい。

そのうえで人は、ドメイン理解や設計判断のような最後に向き合うべきことへ時間を使いたい。

レビューから切り出した先 主に任せたいこと
機械がやるべきもの テスト、型、lint、CI、静的解析
AIに寄せられるもの 背景や意図の整理、仕様との差分説明、チーム方針の参照
人がやるもの ドメイン理解、設計判断、複雑さの許容、認識共有

結: 暫定解として言語化

ここで重要なのは言語化で、いま自分が置いている暫定解もそこにある

  • チームでの設計判断や認知負荷の基準を言葉にする
  • 背景や意図を Issue や design doc に置く
  • 修正方針を毎回レビューで書かなくてよいようにする
  • そのために SKILL を更新し続ける
  • レビューに集まった関心事は分解して再配置したい
  • そのために判断基準や背景を言語化したい
  • それを AI が使える形へ寄せていきたい

結: 暫定解として言語化

変化が著しい今、必要なのは考え続けること。だから仮説を立ててチャレンジしたい

  • 変化が速すぎて、完成された正解は待てない
  • いま見えている足場を使って前に進むしかない
  • その代わり、頭を使って更新し続ける必要がある
  • 記事で書いたことも、現時点での自分の暫定解のひとつである

ご清聴ありがとうございました!

参考