AI時代の新バイアス3選 — 自動化バイアスで見逃したバグと3ヶ月の実測対策

Claudeが返してきたSQLを、私は8秒で承認しました。LIMITが抜けていることに気づいたのは、本番で40万行のレコードがクライアントに返って、Slackが赤くなった30分後です。自分がバイアスの塊であることを、私は3ヶ月かけて再確認しました。しかもAIのせいではなく。AIを信じすぎた自分のせいで。これはAI時代に新しく顕在化した3つのバイアスと、私が3ヶ月測って見逃した3つのバグ、そしてレビュー時に3つのチェックポイントで抑え込んだ話です。

自動化バイアスは航空業界の話ではなくなった

自動化バイアスは、自動化されたシステムの出力を過度に信頼する認知の癖です。1990年代の航空計器の話だと私は思っていました。そう思っていたのは、私がCopilotの補完を8秒で承認する前までです。METRが2025年に発表したRCTで、経験豊富なOSS開発者がAIツールを使うと生産性が 下がる という結果が出ました。ただし本人は「速くなった」と感じています。この主観と客観のズレが、自動化バイアスの一番わかりやすい症状です。

私自身の3ヶ月ログを振り返ると、こんな失敗が並んでいます。

バグ1: Claudeに書かせたSQLの LIMIT 欠落を無批判にmerge。本番で40万行のレスポンスが返る
バグ2: Copilot補完の catch ブロックが空 pass になっていた。エラーは3週間silentに握り潰されていた
バグ3: 「このコードはthread-safeですか」とClaudeに聞いて「はい」と返ってきた。race conditionで週末に呼び出された

3件とも、私が30秒立ち止まっていれば防げたバグです。

しかし私は立ち止まりませんでした。

この30秒を跳ばさせるところに、自動化バイアスの効き目があります。

3つのバイアスとチェックポイント

バイアス1: 自動化バイアス

LLMの出力は、百科事典のような文体で自信満々に情報を提示します。この語り口が検証のハードルを無意識に下げます。AIの提案を人間が無批判に受け入れる癖は、Georgetown大学CSETの2024年の報告書がコード生成の範囲まで広げて調べています。OWASP Top 10 for LLM Applicationsも、LLMへの過度な依存 (Overreliance) を主要リスクとして並べています。

対策: レビュー30秒ルール

私は「LLMの出力を受け入れる前に30秒だけ自分で書いてみる」を導入しました。

全文書く必要はありません。関数のシグネチャと、想定される主要な分岐だけメモします。これだけで、LLMの提案が「自分が書こうとしていた形」に近いかどうか判断できます。近ければ安心して採用します。遠ければ「なぜLLMはこの形を選んだのか」を一度確かめておきたい。

LIMIT欠落SQLは、30秒メモしていれば私は必ず LIMIT 1000 と書いていました。書いていない出力が返ってきた瞬間に違和感を持てたはずです。

バイアス2: アンカリング効果

Copilotが最初に出してくるコードは、こちらの思考のアンカーになります。ICSEの研究では、LLM支援開発で開発者がAIの最初の提案に引きずられ、より良い代替案を検討しなくなる傾向が報告されています。自分で一から書けば思いつくはずの別解が、AI提案を見た瞬間に選択肢から消える。私はエラーハンドリングでこれをやりました。Copilotが空 pass を提案した瞬間、そこに「ログを出す」「例外を再送出する」「メトリクスを送る」という別解があったことに気づけなかったのです。

対策: 反論プロンプト

LLMに提案を出させたら、同じLLMに「この提案の弱点を3つ挙げてください」と続けて聞きます。システム2的な検証を、LLM自身に外へ吐き出させる格好です。面白いことに、LLMは自分の提案の弱点をわりと正直に並べます。「エラーハンドリングが不十分」「並行アクセス時に破綻」「メモリ効率が悪い」など、レビュー観点のヒントが出てきます。反論プロンプトを走らせるコストは10秒とAPIコール1回。バグ1件のPost-mortemに比べれば無料に等しいです。

バイアス3: 確証バイアス

これが一番厄介です。「このコードはthread-safeですか」と聞くと、LLMは「はい」と返しやすい。「thread-safeじゃないですよね」と聞くと「そうです」と返しやすい。質問のフレームに沿った回答を返す傾向があるためです。

私はrace conditionのバグでこれを踏みました。

「thread-safeですか」と聞いた。「はい、Mutexで保護されているので安全です」と返ってきました。実際は Mutexが取れていないパスが1本あった。そこで壊れました。

対策: 反証を明示的に要求

質問のフレームを反転させます。

「このコードがthread-safeでない可能性のあるシナリオを3つ挙げてください」
「このコードがproduction環境で壊れる条件を教えてください」
「別のアプローチと比較して、このアプローチが劣るケースは？」

これで、確証を求めるフレームからLLMの回答が引き剥がされます。反証を求めると、LLMはこちらが困るくらい鋭い反例を返してきます。thread-safeの件も、反証プロンプトを事前に走らせていれば「取得順序が逆になるパスがある」と自分で指摘してくれたはずです。

3ヶ月の実測: 3つのチェックポイントは効いたか

3つの対策を組み込んだ3ヶ月間 (2026年5月から7月まで) の記録です。

LLM由来のバグ検知タイミング: レビュー段階で7件、本番到達0件
対策導入前の3ヶ月 (2026年2月から4月): レビュー段階で2件、本番到達3件

サンプルサイズは小さいので統計的検定には耐えません。ただ、私自身の肌感としては、本番到達を止められている感触があります。特に反証プロンプトは、LLM出力の危ないところを表に出す効き目が大きい。Microsoftの2024年の研究は、生成AIに対する「適切な依存」 (appropriate reliance) という考え方を出しています。全否定でも全肯定でもなく。タスクの性質に合わせて信頼度を上げ下げする。

この温度調整こそが、AI時代のエンジニアに要る技だと私は思います。

Vibe Codingの罠

「動けばOK」で回すVibe Codingは即座のフィードバックがドーパミンを出します。「自分は生産的だ」という錯覚が生まれます。しかし、「動く」と「正しい」と「保守可能」は別の基準です。私のLIMIT欠落SQLも、Copilot空passも、Vibe Codingで書いていれば全部commitされていました。

動いていたので。

METRの実験結果は主観的には「速くなった」と感じるが、客観的には速くなっていないというものでした。認知的な楽さを「速さ」と勘違いしていた、というのが素直な解釈だと思います。私も自分がそうであることに、3ヶ月かかって気づきました。

AIは「同僚」ではなく「ツール」として扱う

AI時代の認知バイアスに一番効く対策は、AIをツールとして扱う意識を持ち続けることです。同僚の意見は尊重するもの。ツールの出力は検証するもの。LLMの出力を同僚の意見のように扱うと、社会的な礼儀 (反論しにくい、否定しにくい) が邪魔をして、批判的な検証がすっと働かなくなります。私自身、Claudeに「ありがとうございます」と返しそうになったことが何度もあります。ツールに礼儀を尽くしそうになった時点で、たぶんすでにバイアスに片足を突っ込んでいます。

まとめ

自動化バイアスに対しては、LLM出力を受け入れる前の 30秒メモ で自分の想定形と照合する
アンカリング効果に対しては、同じLLMに 弱点3つ を続けて聞く反論プロンプト
確証バイアスに対しては、「壊れる条件は？」の 反証要求 で質問フレームを反転させる
3ヶ月の実測で、LLM由来バグの本番到達は3件から0件に減った
AIはツールとして扱う。礼儀を尽くすより、出力を確かめる方を優先する

もっと踏み込んだ認知バイアス20種類とエンジニア心理学の全体像は書籍にまとめました。

エンジニアの心理トリック大全