AIコーディングの「推奨」を盲信しない ― 自動化バイアスとどう付き合うか

Claude Code / Cursor を毎日使っている開発者向け / 読了 10 分

Claude Code や Cursor を毎日使っていて、ふと「いま自分は本当にこのコードをレビューしているんだろうか?」と不安になることがあります。これは何かを説きたい記事ではなくて、最近そんなことを考えていた、というつぶやきに近いものです。

TL;DR

AI ツールが出す「suggest」「recommend」「best practice」という言葉は、それ自体で批判的に読む気持ちを弱くする
「気をつける」「AI リテラシーを学ぶ」みたいな意識面の対策は弱い
効くのは仕組みの方。レビューを別エージェントに任せる、エージェント自身に「何をどう変えたか」を読みやすい形で説明させる、AI を「答え」ではなく「下書き」として扱う
一番こわいのはセキュリティでもコード品質でもなくて、個人としては自分のデバッグ能力、組織としてはコードベースの保守性が、じわじわ落ちていくこと

「推奨」という言葉のひっかかり

Claude Code が「このアプローチをおすすめします」と落ち着いた文体で書いてくると、つい「そうなんだ」と読み流してしまう。これは自分の意志が弱いからではなくて、人間の頭の作りがそうなっているらしいです。

思い返してみれば、軽い気持ちで「このバリデーション追加して」と投げて、返ってきた diff をざっと見て「OK」と通したあとで、別の文脈でそのコードを読み直して必要なチェックが抜けていることに気づきました。読んだはずなのに頭に入っていない。これが今回のトピックです。

航空や医療の世界では昔から automation bias（自動化バイアス） と呼ばれていて、自信ありげなシステムの推奨に、専門家ですら従ってしまう。1999 年の Skitka らの論文では、エラーが2種類に整理されています。

ひとつは、システムが警告しなかった異常を見逃してしまう 見落としエラー（omission error）。もうひとつは、システムが間違ったことを言ったときにそれに従ってしまう 追従エラー（commission error）。AI コーディングのうち「推奨に従う」場面で効いてくるのは後者の方で、AI が推奨した脆弱なコードに従ってしまうのはまさに commission error の現れです。一方で、テストやセキュリティスキャンを AI に委ねる文脈では、「AI が指摘しなかった欠陥を見落とす」という omission 側のリスクも別に存在する、というのは併せて頭に置いておきたいところです。

LLM の落ち着いた口調そのものが信頼を引き出してしまうので、疑い続けるには相当な気力がいる、というのは使っていて素朴に感じるところです。Claude Code の文体が落ち着いていて丁寧であることは、ふつうに使い心地としていいのだけれど、同時にバイアスを加速する装置でもある、ということになります。

いろんな記事を読んでみて

このトピックに関していくつか読んだ記事を紹介します。

1. セキュリティを下げて「上がった」と確信する

Stanford の Perry らが書いた “Do Users Write More Insecure Code with AI Assistants?”（CCS 2023 採択、被験者は学生・若手中心の 47 名）では、AI を使った開発者の方が脆弱なコードを書く、という話だけではなくて、そのコードについて「自分は安全に書けた」と回答した割合が、AI 非利用群より有意に高かった というのがおもしろい点でした。実際には脆弱性が多く混入しているのに、本人の主観だけ「ちゃんと書けた」に振り切れている、ということになります。

似た時期に NYU Tandon の Pearce ら（共著に University of Calgary も入っています）が GitHub Copilot を対象にした “Asleep at the Keyboard”（IEEE S&P 2022）でも、89 のシナリオで生成された 1,689 件のコードのうち、ざっくり 4 割が MITRE CWE Top-25 に該当する脆弱性を含んでいた とのこと。SQL インジェクション、ハードコードされた認証情報、暗号化の弱い実装、入力検証の欠落といった、よくある脆弱性のラインナップです。

主観の自信と客観の品質は、ふつうに考えると同じ向きに動いてくれそうなのに、AI を介すと逆向きにずれていくのは自分にも身に覚えがところどころあります。

なお、ここで触れた 2 本はどちらも Codex 系モデル（Codex（2021）→ code-davinci-002（2022）→ 一旦廃止（2023 春）→ Codex CLI / Codex agent として再ローンチ（2025）という系譜のうち、初期の GitHub Copilot と OpenAI code-davinci-002）が対象なので、最新世代の LLM では脆弱性率自体は改善している可能性が大いにあります。ただ「自信ありげな推奨が、それを読む人の批判的な気持ちを弱くする」という効きの部分は、モデルが賢くなっても残るのではないかと思っています。むしろ単純な脆弱性が減るぶん、出てくる誤りはより自然で説得力のあるものに寄っていく、というトレードオフすらありそうです。賢くなるほど信じてしまう。ちなみに、現行世代（Claude 4.x、GPT-5 系）でこのセキュリティ実験を独立に追試した結果は、2026 年現在まだ表に出てきておらず、改めて参照できるデータがあると面白そうです。

2. デバッグ能力がじわじわ萎縮していく

Anthropic の Shen と Tamkin が 2026 年 1 月に出した “How AI assistance impacts the formation of coding skills”（arxiv プレプリント v1、査読前）という研究は、もう少し中長期の話です。RCT（ランダム化比較試験。被験者をくじ引きで AI 支援グループと非支援グループに分けて比較する手法） で、エンジニア 52 名に新しい Python ライブラリ（Trio）を学んでもらったそう。あとで理解度テストを受けてもらうと、AI 支援グループは 17% 低スコアでした。論文の言い方では「ほぼ 2 レターグレード差」、成績で言うと A が C、B が D に落ちるくらい の差です。そして 一番大きな差はデバッグ能力に出た らしい。

地味に効いてくるのは、短期の生産性は AI 支援群でも統計的に有意な差はつかなかった こと（点推定としてのタスク時間短縮は約 2 分程度ですが、有意差なしと報告されています）。「使うとめちゃくちゃ速くなる」という肌感より控えめな数字です。今回その場で出るのは生産性ではなく後の理解度・デバッグ能力の差、という非対称が、自分には一番こたえました。

おもしろいのは、AI の使い方によって結果が二極化していたこと。AI を「コード生成」に使った人の理解度は 4 割以下、AI を「概念的な質問」に使った人は 6 割以上。同じツールでも、何を委ねるかで結果が大きく変わるという話です。

ただこの研究はサンプル 52 名・特定ライブラリのタスクで、出てきたばかりの単発のプレプリントなので独立した再現研究はまだなく、そのまま一般化はできない。それでも、自分のチーム・自分の手元でも同じことが起きていないかは、自分ごととして考えないといけないな、と思いました。

3. クリティカルシンキングそのものが消える

そもそも クリティカルシンキング（批判的思考） というのは、与えられた答えを鵜呑みにせず「本当にそうか?」「他の選択肢は?」と立ち止まって検証する思考のことで、コードレビューや設計判断のときに毎回やっているはずのもの、と自分は捉えています。

Microsoft と CMU が CHI 2025 で出した 319 名のナレッジワーカー調査（対象は開発者だけでなくマーケター、コンサル、教員、研究者なども含まれます）では、回答者が AI タスクの 4 割でその批判的思考をまったく働かせなかった、と自己報告 しているらしい。AI への信頼度が高いほど批判的思考の量が少ない、という逆相関も見えているとのこと。これは自己報告ベースの調査なので、実は熟練者がパターン認識で一瞬で判断したケースを「考えていない」と申告しているだけかもしれない、という見方もある。それでも、4 割という数字は読んでいて手が止まりました。

そのうえで、医療の文脈でも似たような話があるみたいで、AI リテラシー訓練を受けた医師ですら誤った LLM の診断提案に引っ張られて精度が落ちた、という系統の研究がいくつか出ているそうです（NEJM AI 2025 などで 14〜18 ポイント程度の精度低下が報告されているケースもあります）。Springer の AI & Society のシステマティックレビュー（35 研究、2025）でも、訓練や AI リテラシー教育では automation bias を有意には防げない、と結論されているらしい。一方で、同レビューが唯一効果を確認したのが Interface nudge（「この提案を検証しましたか?」のような UI 上の小さな割り込み）だった、というのも書いてあります。意識面ではなく仕組みの側に、ささやかな関所を仕込む方が効く、ということになりそうです。

コードベース全体も静かに腐る

GitClear（コードレビュー支援ツールのベンダーが運営している、コードチャーンや重複度などを長期で追っているサービス）の 2.1 億行縦断分析（2020-2024）の数字も気になりました。

指標	変化
コードチャーン（2 週間以内修正）	+84%
重複コードブロック	8 倍
リファクタリング比率	25% → 10% 以下

「とりあえず推奨されたものを貼る」をみんなで続けると、コードベース全体の保守性がじわじわ下がっていく。一人の開発者の認知の問題ではなく、組織のコード資産の問題に変質していく、という話だと思いました。

日本の現場感でいうと、PR レビューがそもそも形骸化しがちな組織では、AI 出力をそのまま PR に乗せて、レビューも「LGTM」で流れる、という二段構えで腐敗が進みやすい構造があるな、と読みながら思っていました。レビュアーがレビュイーよりはるかに忙しい、品質保証プロセスが「テストが通っていれば OK」に寄っている、駆け込み PR が「リリースに間に合わせたい」という空気で押し通されるあたりは身に覚えがある人も多そうです。他にも急成長期に入った新人が「AI が言うので」とレガシーコードに整合しない実装をマージする、といったパターンがあるあるかなと思います。AI 出力の「もっともらしさ」は、こういう読み流すインセンティブが既にある場所で一番悪さをします。

ただ GitClear はそもそも AI コードに対して批判的な立場のベンダーが自社レポートとして出しているもので、独立追試はまだ少ないらしい。指標自体（コードチャーン、重複ブロック）も同社独自のメトリクス定義で、たとえばコードチャーンは GitClear 側で「authorship 後 2 週間以内に書き直された行」として定義されており、GitHub Insights や CodeClimate の churn 定義とは厳密には一致しません。さらに AI 普及と並行して別の要因（リモートワーク化、新人比率、レイオフ後の体制変化など）も走っているはずなので、相関と因果は分けて読む必要がありそうです。数字が大きいぶん、そこは差し引いて読むくらいでちょうどいい気がしています。

では何が効くのか ― 意識ではなく仕組みで

意識ではどうにもならないらしい、というのなら、残るのは仕組みの方です。自分が実際に取り入れているもの、これから入れていきたいと思っているものを並べておきます。

レビューを別のエージェント / 別のモデルに分ける。コードを書くエージェントとレビューするエージェントを別にする。同じ「推奨」を出した存在に自己レビューさせても、バイアスは取り除けません。また、同じベースモデル同士でレビューさせると共通バイアスが残るので、できれば違うモデル系統（Claude と Codex、Gemini など）を混ぜたい、という補足もあります（このモデル混合の効果自体は、まだ実証研究が乏しい領域なので、感覚的な期待値として書いています）。
AI の出力を「下書き」として扱う。これは Addy Osmani が “Avoiding Skill Atrophy in the Age of AI” で書いていた「ジュニア開発者のコードとして扱え」という処方が一番しっくり来ました。ジュニアの PR は、信頼はするけど通読はする。ということです。プロンプト側でもこれは効きやすくて、たとえば最初に「これは下書きです。実装の選択肢を 2 つ並べて、それぞれの不安点を 3 つずつ挙げてください。私が選びます」と言うだけで、出てくるアウトプットの質感がだいぶ変わります。
エージェントに「何をどう変えたか」をコード上で語らせる。完了報告をテキストで読むより、エージェント自身に PR の中で、コードの大枠の流れと、トリッキーなポイントにインラインコメントを残してもらう ほうが、結果として自分が立ち止まる場所が増える、というのが最近の落としどころです。# ここはバリデーション後にロックを取るので、上の早期リターンと順序が入れ替わると壊れる のような注記が要所だけに付いていると、それをさらっと辿りながら、引っかかったところだけエージェントに「ここなんでこうしたの?」と問い返せる。一字一句読む方式は実際には維持できないので、読まなければいけない場所を、書いた本人に印付けさせる ほうが現実的でした。これも結局のところ、意識で頑張る代わりに、自分が止まる場所を仕込む Springer のレビューが言うところの Interface nudge の手元実装にあたります。
「実装して」ではなく「このアプローチは適切?」と聞く。さっきの Shen & Tamkin の研究で出ていた数字どおり、実装を委譲するより概念的な質問をするほうが理解度が圧倒的に残るらしいし、実際それは実感もあります。雑に「やって」と投げる回数を、自分の中で意識的に減らしています。
AI を「答え」ではなく「仮説の提示者」として扱う。「これが正解です」ではなく「一つの仮説です」として受け取る。文脈やドメインの判断は自分が持つ、と毎回頭の中で言い直すくらいでちょうどいい気がしています。

特に 1 番目のレビュー分離は、個人的に効きそうだなと思っているところで、kawasima さんが Scrapbox に整理している Decision Quality と設計判断失敗パターン（日次 500 件のデータに Kafka を推奨する、30 人規模の管理画面をマイクロサービス化する、など）も、AI が文脈を見ずに「よくある best practice」を持ち込むことで起きている、と読んでいます。AI は自分が「いまどの失敗パターンに入っているか」に気づけない。だから、その気づき役を別のエージェントに分けて持たせておいたり、自分でも気付けるように仕組みを作っておく、というのが大事だと思っています。

「疑うこと」は使えていないことではない

おもしろいのは、AI に振れすぎる automation bias の対極に algorithmic aversion（一度間違えた AI を全拒否してしまう現象。Dietvorst, Simmons, Massey が 2015 年の論文 “Algorithm Aversion: People Erroneously Avoid Algorithms After Seeing Them Err” で命名した概念）という別の罠があることです。HCI の世界ではさらに古く、Lee と See が 2004 年に書いた論文 “Trust in Automation: Designing for Appropriate Reliance”（Human Factors, 46(1), 50-80）で 校正された信頼（calibrated trust） という考え方が提示されていて ―― AI の確率的な性質を踏まえたうえで、信頼していい部分と疑うべき部分を、自分の中で線引きしていくことが大事、という話です。

要するに「全部信じる」でも「全部疑う」でもなくて、どこを任せてどこを自分でやるかを毎回意識的に決めていく、ということなのかなと思っています。「推奨」を疑うことは、AI を使えていないわけじゃなくて、AI を持続的に使い続けるための大事な条件なのかもしれないと思い始めています。これはこれで疲れるのですが、AIエージェントとの付き合い方が（きっと良い方に）変わります。

おわりに

AI コーディングの怖さは「AI が間違える」ことではなくて、「AI が間違えても気づけなくなっている自分」の方にあると思っています。そして、そのとき静かに削れていくのは、個人としては自分のデバッグ能力であり、組織としてはコードベースの保守性の方です。どちらも、削れている瞬間にはまったく痛くないので厄介で、半年経ってからじわっと効いてくるはずです。

気をつける、という個人技ではどうにもならない領域なので、レビューを別のエージェントに任せたり、エージェント自身にコードの要点をインラインで語らせて自分が止まる場所を作ったり、仕組みの方で疑う場所を確保していく、というのが今の自分の落としどころです。

とかなんとかいろいろ言っておきながらClaude Codeに「ブログ書いて」と言ってこのブログを書いてしまっているのもまたいろいろなことを考えさせられてはいるのです。書きながら自分の勉強にしているので、一定は意味のあることをしているのかな、という気持ちはありますが、まぁこれは自分のブログなのでよしとしましょう。