AIコーディングは開発者の判断をどう歪めるか？認知バイアス15分類の実態調査

AIコーディングは開発者の判断をどう歪めるか？認知バイアス15分類の実態調査

GitHub CopilotやCursorのようなAIコーディングツールは、もはや開発の日常に組み込まれています。比較記事の多くは「どのツールが速いか」「どのツールが正確か」を論じますが、見落とされがちな問いがあります。ツールを使う開発者自身の判断は、この協働の中でどう変わっているのか。

ICSE 2026（ソフトウェア工学分野の査読つきトップカンファレンス）に採択された研究が、この問いに正面から取り組み、AIコーディングツールとの協働に特有の認知バイアスを90事例・15カテゴリに整理しました。この記事では、研究の中身と、チームの運用に取り入れられる考え方を整理します。

30秒で要点

• ICSE 2026採択の研究（Zhouほか）が、開発者14名の観察研究と追加開発者22名への調査を組み合わせ、AIコーディングツールとの協働に特有の認知バイアス90事例を認知心理学者とともに検証し、15カテゴリの分類法を構築した
• 調査対象となったプログラマーの行動のうち48.8%が何らかのバイアスの影響を受けており、そのうち56.4%が開発者とAIの相互作用に関連するバイアスだったと報告されている
• 代表的なカテゴリには、AIの提案を無条件に優先してしまう「Suggester Preference（提案者選好）」、最初の提案や計画から発想が離れにくくなる「Fixation（固着）」などがある
• ツール比較記事が扱う「性能」の裏側で、使う側の判断そのものが影響を受けているという視点を、チームの運用設計に反映できる

何が調べられたのか

研究チームは、学生・専門家を含む開発者14名を対象にした観察研究と、追加の開発者22名への調査を組み合わせたmixed-methods（複数の調査手法を組み合わせる）アプローチを取りました。開発者がAIコーディングツールを使いながら実際にコードを書く様子を観察・記録し、そこから収集した90件の認知バイアス事例を、認知心理学者とともに検証しながら15のカテゴリに整理しています。

調査結果として報告されているのは、対象となったプログラマーの行動のうち48.8%が何らかの形でバイアスの影響を受けており、そのうち56.4%が開発者とLLM（AIコーディングツール）との相互作用に特有のバイアスだったという数字です。この分母・分子の関係を整理すると、「観察されたプログラマーの行動全体」を分母に、「バイアスの影響が確認された行動」を分子にした割合が48.8%、さらにその中で「AIとのやり取りに起因するもの」の割合が56.4%、という二段階の集計になっています。

15カテゴリのうち、代表的な3つを見る

15カテゴリすべてを紹介すると散漫になるため、ここでは特に実務に関わりが深い3つを取り上げます。

Suggester Preference（提案者選好）

AIが提示したコードや設計を、その内容を十分に検討する前に「システムが出したものだから」という理由だけで優先してしまう傾向です。一般的な自動化バイアスの知見を土台にしつつ、AIコーディングツールとの相互作用に合わせて再定義されています。レビュー時に「AIの提案だから大きな問題はないはず」という前提で読み流してしまう場面が典型例です。

Fixation（固着）

AIから提示された最初の提案やコード構造に、その後の思考が引きずられ続ける傾向です。この研究では、アンカリング効果に加え、道具の使い方を慣れたパターン以外で発想しにくくなる機能的固着、状況が変わっても最初の計画に固執する計画継続バイアスもまとめて含む、幅広いカテゴリとして定義されています。研究内で報告された反転行動率（一度受け入れた提案を後から考え直して撤回する割合）はこのカテゴリで最も高く、43.4%に達したとされています。最初の提案が結果的に見直されるケースが多いにもかかわらず、その場では強く固着してしまう、という状態です。

Belief Confirmation（信念確認）

もともと自分が想定していた実装方針や仮説を裏づけるように、AIの提案を解釈・選択してしまう傾向です。確証バイアス・偽の事前信念・裏目効果（自分の考えと矛盾する情報を見せられると、かえって元の考えを強めてしまう現象）を包含する形で定義されています。「このコードで動くはずだ」という思い込みがある状態でAIに質問すると、その思い込みを補強するような回答ばかりを拾ってしまう場面が当てはまります。

混同しやすい概念を整理する

ここで扱った3カテゴリは、いずれも心理学で確立した複数の概念をまとめたものであり、元の概念同士も混同されがちなので整理しておきます。

• 自動化バイアスとアンカリング効果は別物：自動化バイアスは「自動化されたシステムを無条件に信頼してしまう」という、情報源の性質に関するバイアスです。アンカリング効果は「最初に見た情報が基準点になる」という、情報の提示順序に関するバイアスです。AIコーディングツールの文脈では両方が同時に起きやすいため混同されがちですが、原因が異なります
• アンカリング効果・機能的固着・計画継続バイアスも、それぞれ独立した概念：アンカリング効果は数値・情報の基準点の話、機能的固着は道具の使い方の話、計画継続バイアスは状況変化への対応の話であり、この研究の「Fixation」というカテゴリは、これら3つの異なる現象を便宜上まとめて扱っている点に注意が必要です

「何を使うか」の比較記事とは、問いの立て方が違う

AIコーディングツールを扱う記事の多くは、料金体系・エディタ統合・プライバシーといった軸で「どのツールを選ぶか」を比較します。この記事はそれとは異なる問いを扱っています。ツールをすでに選び、使い始めたあとに、使う側の判断がどう変化するかという問いです。

どちらの問いも実務上重要ですが、混同すると対策を誤ります。「どのツールが優れているか」という問いへの答えは、より高性能なツールへの乗り換えを促します。しかし今回扱った研究が示すのは、バイアスの多くがツールの性能そのものではなく、人間とAIの相互作用のパターンから生まれるという点です。ツールを乗り換えても、レビュー設計や運用ルールを変えなければ、同じ種類のバイアスが形を変えて残る可能性があります。

なぜこのリスクは見落とされやすいのか

AIコーディングツールの導入判断は、「精度が上がるか」「速度が上がるか」という指標で語られがちです。この指標のわかりやすさそのものが、判断リスクを見落とす一因になっていると考えられます。

生産性の指標は、コード生成の速度や補完の採用率のように、数値として測定しやすいものが選ばれやすい傾向があります。一方、開発者の判断がどう歪んだかは、その場では自覚しにくく、数値としても可視化しづらいものです。測定しやすい指標が意思決定を支配し、測定しにくいリスクは後回しにされる、という構図がここにも当てはまります。

さらに、AIの提案がもっともらしく整った形で出力されることも、Suggester PreferenceやFixationを強めます。人間同士のレビューであれば違和感を持って質問できる場面でも、整然としたコードとして提示されると、疑う手がかりそのものが減ってしまいます。

確かなことと、まだ確立していないこと

確かなこと

• ICSE 2026という査読つきの国際会議に採択された研究として、AIコーディングツールとの協働に特有の認知バイアス90事例が、認知心理学者の検証を経て15カテゴリに分類されている
• 観察対象となった行動のうち48.8%がバイアスの影響を受けており、そのうち56.4%が開発者とAIの相互作用に起因すると報告されている

まだ確立していないこと

• 観察研究の対象は開発者14名、追加調査は22名という規模であり、業種・言語・経験年数の異なる開発者全体に、同じ比率がそのまま当てはまるかは今回の研究だけでは分からない
• バイアスの影響を受けた行動が、実際にコードの品質・バグの発生率にどの程度の実害をもたらしたかまでは、この記事で参照した情報の範囲では確認できていない

判断軸の提示：チーム運用でできる対策

バイアスの存在を前提に、レビュー設計へ反映できる考え方を挙げます。

• AIの提案を「検討済みの結論」ではなく「たたき台」として扱うルールを明文化する：Suggester Preferenceを弱めるには、提案を受け取った直後に「なぜこの実装なのか」を一言で説明させる運用が有効です
• 最初の提案を一度離れて再検討する機会を作る：Fixationの反転行動率の高さは、後から見直せば違う判断に至るケースが多いことを示唆します。レビュー前に一晩置く、別の担当者が独立にレビューするなど、最初の提案から距離を取る工程を挟みます
• 自分の仮説を検証する質問と、仮説を確かめるだけの質問を分ける：Belief Confirmationを避けるには、AIへの質問時に「この実装で合っているか」だけでなく「この実装が間違っているとしたら、どこが怪しいか」も尋ねる習慣が助けになります

自分のチームでも試せる、最小の検証

大がかりな調査をしなくても、自チームの状況を点検する最小の一歩があります。

直近1週間分のAIコーディングツールの利用ログ・プルリクエストのレビューコメントを見返し、AIの提案がそのまま承認されたケースの件数を分母に、修正・議論を経てから承認されたケースの件数を分子にして、割合を数えてみてください。そのまま承認された割合が極端に高い場合、Suggester PreferenceやFixationが働いている可能性を疑う材料になります。

判断の土台として押さえておくこと

• AIコーディングツールの評価軸は「性能」だけでは足りない：使う人間の判断がどう変化するかも、導入判断に含めるべき論点になる
• 代表的なバイアスは、既存の心理学概念の組み合わせとして理解できる：自動化バイアス・アンカリング効果・確証バイアスなど、それぞれ性質の異なる現象が背景にある
• 対策は「気をつける」ではなく「仕組み」に向ける：たたき台として扱うルール・独立レビュー・反証を促す質問など、運用設計で補う発想が現実的

次の一手：AIコード生成ツール比較：GitHub Copilot・Cursor・Windsurfの選び方／AIエージェント導入が効果を出せないときに見るべき3つの失敗パターン／AIはWeb開発をどう変えるか？

この記事で扱わなかったこと

15カテゴリすべての詳細な定義や、研究チームが用いた分類手法の統計的な検証プロセスには、この記事では踏み込んでいません。扱ったのは、代表的なカテゴリの内容と、チーム運用に反映できる考え方です。分類法の全体像に関心がある場合は、一次論文にあたることをおすすめします。

この記事で扱ったような、AI活用を含む開発体制のレビュー設計を自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。