新人のAIコードにレビュー830件、増える前に任せない領域を決める

新人エンジニアが出したプルリクエストを開く。AIが数分で書き上げたコードに、指摘のコメントを付け始めたら止まらなくなる。気づけば夜9時を過ぎても、まだレビュー欄が埋まり続けている。

flowchart TD
    A[AIで高速執筆] --> B[検証は素通り]
    B --> C[レビュー膨張]
    C --> D[上長へ転嫁]

レビューコメントが830件に膨らんだ現場

#

不動産テック企業のいえらぶGROUPで、実際に起きたことだ。ある開発プロジェクトで、新人エンジニアがAIによる自動コーディングの出力を疑わず実装を進めた。そのコードをプルリクエストでレビューしたところ、レビューコメントは830件に達した（出典: 「AIコーディングで高速開発」が、なぜ企業の弱点に？ 開発部門のAIとの付き合い方、キーマンズネット、2026年9月2日）。コードレビューとしては異例の数だったという。

同社はこの状態を放置せず、一時的にAIの利用を禁止する判断をした。AIの答えを疑わず実装した理由を、自分の言葉で説明できる状態に戻すためだ。基本に立ち返らせてから、約4カ月をかけて段階的にAIの利用を再開している。この事例は、AWSのソリューションアーキテクトが講演で紹介したものだ。

私が見てきた開発チームでも、レビューが止まらなくなる新人は決まって同じ経路をたどる。AIの答えを疑わず、そのまま実装に使ってしまう経路だ。

検証が上長に流れ着くのは、渡す前に線を引かなかったからだ

#

AIコーディングは、実装のスピードを一気に上げる。だが品質を評価し、「ここは違う」とダメ出しする工程が無ければ、その負荷は消えず後工程へそのまま流れ込む。

新人ほど、AIの出力を「正解」だと疑わずに受け取りやすい。判断の主体が自分ではなくAIに移った状態で実装を進めれば、レビューする側が全部の判断を肩代わりすることになる。

自分で考えて手を動かした実感が薄いまま実装が進むと、成果物への責任感も宿りにくい。AIに任せるほど細る判断筋と同じ構造が、新人のコーディングにもそのまま当てはまる。

つまり830件という数字は、新人の能力不足でも、指導する側の力量不足でもない。AIに何を渡し、何を渡さないかを、実装前に誰も決めていなかったという設計の不在が、レビュー工程で表面化しただけだ。検証とコーチングという見えない労働が課長に積み増される構造と、根は同じだ。線を引かなければ、その後の全部をあなたが引き取ることになる。

渡さない領域と、絞り込むレビュー基準を先に決める

#

整えるのは3箇所だけだ。一度に全部やらなくていい。

最初の数週間は、コア機能を渡さないと決める

#

新人が加わった最初の数週間は、外部通信・決済・権限まわりのコア機能だけ、AIに書かせないと決めて渡す。判断の主体を自分の手元に残す領域を、実装が始まる前に1つだけ確保しておく。

レビューを全件精読から絞り込みに変える

#

レビューの全件精読をやめ、リスクの高さで絞り込む基準を渡す。次のような基準を、新人と着手前に共有しておく。

【新人PRレビューの絞り込み基準】
1. 外部通信・権限・決済に関わる部分 → 全件精読
2. 表示・文言・軽微な条件分岐 → 抜き取りで確認
3. コメントが一定数を超えたら → 継続せず設計から見直す

基準を先に渡しておけば、レビューのたびに線引きをゼロから考え直さずに済む。毎回判断を仕切り直すコストは、複数案件の切り替えと同じ脳の負担だからだ。

PRごとのコメント数に、自分の上限を決めておく

#

PRごとのコメント数に、自分なりの上限を決めておく。上限を超えた時点で、細部の指摘を続けるのをやめ、設計そのものを見直す会話に切り替える。件数が増え続けるのは、実装の細部ではなく前提が壊れているサインだ。併せて、チームのコード生成比率を一度数えておくと、上限を決める材料になる。

逃げの一手

#

3つとも整える余力がない週は、判断ラインを一段下げていい。外部公開に関わる部分だけを見て、それ以外は通す。

それでも消耗が続くなら、チーム内のAIコーディングを一時的に止める判断は、あなたの裁量でできることが多い。いえらぶGROUPが実際に取ったのも、この一時停止だった。

まとめ：レビューが膨らむのは、渡す前に線を引かなかった結果だ

#

830件という数字が示すのは、AIの生産性ではなく検証の設計不在だ。渡す前に決めておけば、渡した後にあなたが全部を引き取る必要はない。

本記事は AI が下書きし、管理人が監修しています。