AIにレビューさせてもバグが残る｜人が見るべき観点
AIに「レビューして」と頼んで、返ってきた指摘をひと通り直した。テストも通った。安心してマージした。——なのに数日後、本番で「あれ、この条件のとき動きがおかしい」と報告が上がってくる。
指摘は20個も返ってきていたのに、なぜ一番大事なところが抜けていたのか。 これは、あなたのレビューの頼み方が下手だったからでも、確認をサボったからでもありません。AIレビューには、構造的に見えにくい領域がある。そこだけは、最後に人が目を通す。今日は、その「人が見るべき観点」を、コピーして使えるチェックリストにして一緒に整理します。
結論：AIレビューが苦手なのは、コードの外側にある情報を必要とする判断です。具体的には ①仕様・意図（そもそも何を作るはずだったか）、②業務ロジックの正しさ（金額・締め日・権限など「合っていて当然」の計算）、③変更の波及（この差分が別の場所に与える影響）、④状態・並行処理（時間差や同時実行で崩れる不具合）、⑤セキュリティの文脈（この値は本当に信用してよいか）の5つ。AIは「コードとして正しいか」は見られても、「あなたの現場にとって正しいか」は知りません。だから、この5つだけは人が最後に一度見る。それ以外はAIに任せてよい、と割り切ると気持ちがずっと軽くなります。
指摘が多かったのにバグが残ったのは、AIが手を抜いたからではありません。 AIは目の前のコードの中で判断が完結する指摘——命名、書き方、明らかな抜け——は得意です。でも「この計算式、業務的に合ってる？」のように、コードの外にある正解と照らす必要がある指摘は、根拠を持てないので出しにくい。だから、AIレビューを通してもすり抜けるバグには、はっきりした「型」があります。まずはそこから見ていきましょう。
なぜAIレビューを通してもバグが残るのか
AIは、渡されたコードを驚くほど丁寧に読みます。変数名の一貫性、ありがちな抜け（null チェック漏れ、例外処理の欠落）、書き方の癖——このあたりは人間より速く、網羅的に拾ってくれます。
ただ、AIが見ているのは基本的に「今、目の前にあるコード」です。そのコードが「本来こう動くべきだった」という正解や、「この会社では月末締めが20日」といった業務ルールは、コードの中には書かれていません。書かれていない以上、AIは推測はできても、確信を持って指摘はできない。
だから、AIレビューがすり抜けやすいバグは「コードとしては自然に見えるのに、業務や仕様の上では間違っている」ものに偏ります。逆に言えば、AIが得意な範囲はAIに任せ、人は「コードの外を知らないと判断できないところ」に集中すればいい。全部を人が見直す必要はありません。
人が最後に見るべき5つの観点
ここからが本題です。AIレビューを通したあと、人が最後にざっと目を通したい観点を5つに絞りました。全部を毎回じっくりやる必要はなく、「その変更に関係するものだけ」拾えば十分です。
1. 仕様・意図：そもそも何を作るはずだったか
AIは「このコードは正しく動くか」は見ますが、「このコードが作ろうとしていたものは何か」は、指示しない限り知りません。仕様の読み違い——たとえば「未ログインでも閲覧できる」はずの画面をログイン必須にしてしまった、というような取り違えは、コードとしては完璧に動くのでAIは気づけません。
見るポイントはシンプルです。「これ、そもそも作りたかったものと合ってる？」と、コードではなく元の要件に戻って一度だけ確認する。ここは人にしか照合できません。
2. 業務ロジック：合っていて当然の計算ほど自分で検算する
金額、税率、締め日、日数、割引、権限の範囲——「合っていて当然」とされる計算ほど、間違っていても誰も疑いません。AIは計算式が構文的に正しければ通してしまいます。
境界の値だけでいいので、自分で手を動かして検算してみましょう。「月末が31日のとき」「割引後がマイナスになる注文のとき」など、極端な1〜2ケースを電卓で叩く。数字の裏づけは、AIではなく人が持っておきたいところです。
3. 変更の波及：この差分が触っていない場所に響かないか
AIレビューは、渡した差分（変更部分）の中で判断が閉じがちです。でも実際のバグは「変更したAが、離れたBの前提を崩す」形で起きます。共通関数の戻り値の型を少し変えたら、それを使っている別画面が静かに壊れる——という類のものです。
差分の外まで見るには、「この関数・この値を、他にどこが使っているか」を検索して確かめるのがいちばん確実です。ここは、コードベース全体の地図を持っている人の強みが出るところです。
4. 状態・並行処理：時間差や同時実行で崩れないか
「2人が同時に押したら」「通信が途中で切れたら」「同じ処理が2回走ったら」——時間の流れや同時実行が絡む不具合は、1回動かすだけのレビューでは表面化しません。AIも、静的なコードを見るだけでは再現条件を思い描きにくい領域です。
該当しそうな処理（在庫の引き当て、ポイントの加算、二重送信など）があるときだけ、「同時に来たらどうなる？」と一度問い直す。関係ない変更なら飛ばして構いません。
5. セキュリティの文脈：この値は本当に信用してよいか
「この入力値はどこから来たのか」「この利用者にこの操作をさせてよいのか」は、コードの見た目だけでは判断できません。外部から来た値を信用してそのまま使っていないか、権限チェックが抜けていないか。AIは一般論としては指摘できても、「あなたのシステムで、この画面は誰がアクセスできるのか」までは知りません。
外部入力を扱う箇所と、権限が絡む箇所だけ、「この値・この人を信用していい根拠はあるか」を一度確認する。ここも文脈を知る人の担当です。
明日からできる小さな一手
全部を一度に変えようとしなくて大丈夫です。まずは、AIレビューを通したあとに、この5観点を上から眺めるだけの一手を足してみてください。
多くの変更は、5つのうち関係するのは1〜2個です。「今回は金額計算に触ったから②だけ」「共通部分をいじったから③だけ」と、その差分に効くものだけ拾えば、時間はほとんど増えません。AIに任せる範囲が明確になるぶん、むしろレビュー全体は軽くなります。
人が最後に見るチェックリスト
その変更に関係するものだけ、上から拾ってみてください。
- 仕様・意図：作りたかったものと、実際の挙動は合っているか
- 業務ロジック：金額・日付・権限などの計算を、境界の値で自分で検算したか
- 変更の波及：触った関数・値を、他にどこが使っているか確認したか
- 状態・並行処理：同時実行・二重実行・途中失敗で崩れないか（該当する場合のみ）
- セキュリティ：外部入力と権限まわりで、信用してよい根拠があるか（該当する場合のみ）
- 迷ったら「この観点を見落としたら、後で困るのは誰か」を思い浮かべる
AIレビューを通してバグが残っても、それはあなたの怠慢ではありません。AIが見られない場所が、たまたまそこにあっただけです。その場所がどこかを知っていれば、次から人の目を置ける。それだけで、レビューはぐっと安心なものになります。
一度で完璧なレビュー体制は作れません。今日、5観点のうちひとつでも「あ、これは自分が見る場所だ」と分かったなら、それはもう品質を守る仕組みの始まりです。