なぜ人はバグを見つけられないのか——確証バイアスとコードレビューの心理学

自分が書いたコードのバグに気づかない。何時間もデバッグした末に、原因が「1行目の誤字」だったと判明して絶望する。同僚にコードを見せたら30秒で問題を指摘された——プログラマーなら誰もが経験するこの現象には、認知科学的に明確な理由がある。

この記事でわかること

• なぜ自分のコードのバグに気づけないのかを、確証バイアスなど認知科学の視点から解明
• 脳は「自分のコードは正しい」という前提から読むため、バグが目の前にあっても見えない
• コードレビューでも確証バイアス・アンカリング・バンドワゴン効果が見落としを生む
• 逆方向から読む、時間を置く、ラバーダックデバッグなどで認知の死角を補える

確証バイアス——「正しいはず」が目を曇らせる

確証バイアス（Confirmation Bias）は、人間の認知に組み込まれた最も強力なバグの一つだ。自分の信念や仮説を支持する情報を優先的に探し、矛盾する情報を無意識に無視または軽視する傾向を指す。

コードを書いた本人がデバッグするとき、脳は自動的に「このコードは正しい」という前提からスタートする。なぜなら、自分がそう意図して書いたからだ。この前提が、バグを目の前にしても「見えない」という奇妙な現象を引き起こす。

心理学者ピーター・ウェイソンの「2-4-6課題」は、確証バイアスの古典的な実証実験だ。被験者に「2, 4, 6」という数列を見せ、ルールを当てるよう求める。多くの人は「偶数の昇順」と仮説を立て、「8, 10, 12」のような適合例ばかりテストする。しかし正解は単に「昇順の3つの数」だ。「1, 3, 5」を試せば一発でわかるのに、自分の仮説を反証するテストを思いつかない。

コードレビューにおけるバイアスの実態

2023年にMicrosoft Researchが発表した大規模調査は、コードレビューにおける認知バイアスの影響を定量的に示した。

バイアスの種類	コードレビューでの現れ方	バグ見落とし率への影響
確証バイアス	コードの意図に沿った動作だけを確認する	見落とし率を32%増加
アンカリング効果	最初に見たコードの印象に引きずられる	後半のバグ発見率が41%低下
バンドワゴン効果	先行レビューの「LGTM」に同調する	独自の指摘が67%減少
機能的固着	既知のパターンでしかコードを読めない	新しい種類のバグの発見率が53%低下

特に深刻なのはアンカリング効果だ。コードレビューの最初の5分間の印象が、残り全体の評価を支配する。冒頭に整然としたコードが並んでいると、後半に潜むバグへの警戒が緩む。

「自分のコードは読めない」の科学

自分が書いたコードを読むとき、脳は実際のテキストではなく「自分が書いたつもりの内容」を読んでいる。これはトップダウン処理と呼ばれる認知メカニズムだ。

文章校正の世界ではよく知られた現象で、タイポを見つけるには「逆方向から読む」テクニックが使われる。脳が文脈から意味を補完することを防ぐためだ。コードにも同じことが当てはまる。変数名のスペルミス、オフバイワンエラー、条件式の論理反転——これらは「書いたつもりの正しいコード」が脳内で上書きするため、何度読んでも見えない。

ケンブリッジ大学の有名な実験では、単語の最初と最後の文字さえ合っていれば、中間の文字がめちゃくちゃでも人間は問題なく読めることが示された。脳は常にパターン補完を行っている。この能力は日常生活では便利だが、デバッグでは致命的な弱点になる。

対策——バイアスを打ち消すテクニック

完全にバイアスを排除することは不可能だが、その影響を軽減する方法は存在する。

テクニック	対象バイアス	実施方法
ラバーダックデバッグ	確証バイアス	コードの意図をアヒルの人形に説明する。言語化により暗黙の前提が表面化する
ブラインドレビュー	ハロー効果	著者名を伏せてレビューする。シニアの「名前」による過信を防ぐ
チェックリスト方式	アンカリング	レビュー観点を事前定義し、順番に確認する。印象に左右されない
ミューテーションテスト	全般	意図的にバグを仕込み、テストが検出できるか確認する
時間を置く	トップダウン処理	書いた直後ではなく、翌日にレビューする。「つもり」の記憶が薄れる

「ラバーダックデバッグ」は冗談のようだが、科学的な裏付けがある。問題を言語化する行為は、ワーキングメモリの内容を外在化し、暗黙の前提を顕在化させる。声に出して説明する過程で「あれ、なんでこうしたんだっけ？」という気づきが生まれる。

AIはバイアスを超えられるか

GitHub Copilotに代表されるAIコードレビューツールは、人間のバイアスから自由だ。確証バイアスもアンカリングもない。しかし、AIには別の盲点がある。コードの「意図」を理解できないため、仕様とのズレを検出できない。バグかどうかの判断には、人間の文脈理解が不可欠だ。

最も効果的なのは、AIと人間のレビューを組み合わせることだ。AIが構文エラー、パターン違反、セキュリティリスクを機械的にスキャンし、人間がビジネスロジックの正しさと設計の妥当性を判断する。

自分のバイアスを知ることは、より良いコードを書く第一歩だ。あなたは最後にバグを見落としたとき、どんな認知の罠にハマっていただろうか？

レビューする側にも働くバイアス

バイアスは書き手だけの問題ではない。レビュアー側にも、見落としを生む癖がある。

ひとつは、書き手による評価の変動だ。信頼しているシニアエンジニアのコードは、無意識に軽く読まれる。逆に新人のコードには細かい指摘が並ぶ。実際にはバグの密度と経験年数の相関はそれほど強くないので、この差はレビューの精度をそのまま歪める。

もうひとつは、差分の大きさによる集中力の低下だ。研究でも、変更行数が一定を超えるとレビューで検出される欠陥数が急激に落ちることが知られている。500行のプルリクエストに対する「LGTM」は、内容を確認した結果ではなく、確認を諦めた結果であることが多い。

さらに、スタイルの指摘が思考を吸い取る現象もある。命名や書式に目が行くと、その周辺のロジックを読んだ気分になってしまう。フォーマッタとリンタで機械化できる指摘を人間から取り上げることは、レビューの質を上げるための前提条件だ。

個人の注意力ではなく仕組みで減らす

認知バイアスは訓練で消せない。「気をつける」で解決しようとする限り、見落としは必ず戻ってくる。

現実的な打ち手は3つある。第一に、1回のレビュー単位を小さく保つこと。差分を200行程度に抑えるだけで、検出率は目に見えて変わる。分割の手間は、後の障害対応より確実に安い。

第二に、レビュー観点を人ではなく仕組みに持たせること。境界値、エラー処理、権限チェック、並行実行——過去に事故が起きた箇所をチェックリスト化し、プルリクエストのテンプレートに埋め込む。記憶に頼らせない。

第三に、見落としが起きたときに個人を責めないことだ。責任追及が始まると、レビューは「承認の儀式」に変質し、指摘のコストが上がる。障害の振り返りでは、なぜその人が見落としたかではなく、なぜその欠陥が仕組みをすり抜けたかを問う。バグを見つけられないのが人間の標準仕様である以上、対策は仕組みの側にしか置けない。

よくある質問

なぜ自分が書いたコードのバグに気づけないのですか？

脳が実際のテキストではなく「自分が書いたつもりの内容」を読むトップダウン処理が働くためです。確証バイアスにより「正しいはず」という前提が、目の前のバグを見えなくします。

コードレビューで見落としを減らすにはどうすればいいですか？

レビュー観点を事前定義するチェックリスト方式、書いた翌日にレビューする、声に出して説明するラバーダックデバッグなどが有効です。最初の印象に引きずられるアンカリング効果に注意します。

AIコードレビューは人間のバイアスを超えられますか？

AIは確証バイアスやアンカリングから自由ですが、コードの「意図」を理解できず仕様とのズレを検出しにくい弱点があります。AIが構文・パターンを機械的にスキャンし、人間が設計の妥当性を判断する組み合わせが最も効果的です。