はじめに

AIレビューを使ってみて「これは便利だな」と思ったこと、きっとあると思う。
でも一方で、「あれ？このバグ、AIはスルーしたの？」と感じた経験はないだろうか。

本記事では、実際にあった「AIが見逃したバグ」と、それに対して人間のレビューアーがどのように指摘を加えたのかという視点で、具体的なケースを紹介していく。
それぞれの事例を通じて、「人間レビューだからこそ気づけるポイント」を整理してみよう。

ケース1：ロジックは正しいけど、意味が破綻していたパターン

商品価格から割引価格を算出 
function getDiscountPrice(price, discount) {
  return price - discount;
}

AIの出力：

Comment 
@Reviewer: 計算は正しく行われており、文法上の問題はありません。

人間の指摘：

コードレビュー 
@Reviewer: 割引額が価格を超えた場合、マイナス値になってしまいます。0円未満にならないようなガードロジックが必要ではないでしょうか。

見逃された理由：
AIはコードの構文・計算の整合性には強いが、「ユーザーにマイナス価格を提示するのは不自然」という業務的な意味の破綻までは評価できていなかった。

ケース2：一見スマートなコードが実は破壊的だった

設定の上書き処理 
function applyOptions(defaults, overrides) {
  return { ...defaults, ...overrides };
}

AIの出力：

Comment 
@Reviewer: スプレッド構文を使用しており、最新のJavaScript構文として適切です。

人間の指摘：

コードレビュー 
@Reviewer: `overrides` が `null` や `undefined` の場合に例外を起こします。空オブジェクトとのマージ前処理を追加しておくと安全です。

見逃された理由：
AIはコードの表面上のモダンさを評価する傾向があり、null安全性や未定義への防御といった実運用視点を反映できていなかった。

スプレッド構文とは

スプレッド構文（...）は、オブジェクトや配列を展開してコピー・マージする機能。ES2018以降、オブジェクトに対しても対応している。

ケース3：コメントを信じたAIと、挙動を見た人間

日付フォーマット関数 
/**
 * @param {Date} date - フォーマットする日付
 * @returns {string} YYYY-MM-DD形式の日付文字列
 */
function formatDate(date) {
  return `${date.getMonth() + 1}-${date.getDate()}-${date.getFullYear()}`;
}

AIの出力：

Comment 
@Reviewer: ドキュメントコメントに従っており、構文も正しいです。

人間の指摘：

コードレビュー 
@Reviewer: コメントは "YYYY-MM-DD" と書かれていますが、実際の出力は "MM-DD-YYYY" 形式になっています。意図と実装が一致していません。

見逃された理由：
AIは関数コメントを信頼して処理を読みがちだが、実際のコード出力と照らし合わせるという「人のような検証」は苦手な傾向にある。

ケース4：マイナーな仕様落としを察知したのは人間だった

fetch APIの簡易ラッパー 
async function getData(url) {
  const res = await fetch(url);
  return res.json();
}

AIの出力：

Comment 
@Reviewer: fetch関数とasync/awaitを使った非同期処理として正しい書き方です。

人間の指摘：

コードレビュー 
@Reviewer: fetchが404や500を返しても `res.ok` を見ていないので、例外が出ずそのまま `.json()` が実行されます。エラーハンドリングの追加が必要です。

見逃された理由：
fetchはネットワークエラー以外では例外を投げず、404でも通常のレスポンスを返す。このような仕様レベルの落とし穴を考慮できるのは、実運用を知る人間ならでは。

ケース5：設計の意図に気づけたのは経験だった

フラグが複数ある場合の条件分岐 
if (isAdmin || isSuperUser && hasAccess) {
  grantAccess();
}

AIの出力：

Comment 
@Reviewer: 条件式の論理構文としては妥当です。

人間の指摘：

コードレビュー 
@Reviewer: `||` と `&&` の優先順位によって、 `isAdmin` が true のときに `hasAccess` を無視して通過する設計になっています。括弧で明示して意図を伝える必要があります。

見逃された理由：
構文的には正しくても、意図の伝わりづらさや設計上の誤読リスクはコードだけでは判断しづらい。AIは「動くか」に寄りがちで、「誤解されないか」の視点は弱い。

バグ検出とレビュー精度の違い

AIが得意なのは、文法や構文上の「明確な誤り」の発見。
一方で、人間は「設計意図」「業務ロジック」「使われ方」といった文脈の深さに基づいて指摘できる。
この差が、レビューの深さ・信頼性に直結する。

レビューアーが持つべき問い

人間のレビューアーとして、次のような問いを常に持っておくと、AIとの役割分担もうまくいく。

  • このコード、現場で本当に使われたときどうなるか？
  • 仕様と一致してるか？ それともコードだけを見て納得していないか？
  • 誰かが読んだときに、誤解しないか？

AIは強力なレビュー補助にはなるけれど、“空気を読む”レビューまではまだ任せられない。

まとめ

AIレビューは便利だし、精度も徐々に上がってきている。
でも、「本当に見てほしいポイント」や「微妙なズレ」に気づけるのは、今のところ人間のレビューアーだけだ。

コードレビューはバグ検出だけじゃない。
意図の整合、ロジックの妥当性、運用の現実まで踏み込んで見る力が、やっぱり最後の砦になる。
AIと人間、それぞれの強みを活かしながら、レビューをもっと信頼できるプロセスにしていこう。