AIが書いたコードを「理解した気になる」4つの瞬間 — ダニング＝クルーガー効果の実務編

TL;DR

「全部わかった」と思った直後に「何もわからない」谷に落ちる感覚は、学習過程で非常によくある
通称ダニング＝クルーガー効果と呼ばれるこの現象、有名な「無知の山→絶望の谷」のグラフは原論文には存在しない俗流図解で、効果自体も統計的アーティファクトだとする批判的再検証がある——という話は、姉妹記事で一次資料まで確認した
本記事はその続き。AIコーディングエージェント時代に、この「わかったつもり」がどう新しい形で発生するかを、筆者自身の失敗談ベースで4パターンに分解する
パターンは: ①AI生成コードのレビューで理解したつもりになる ②絶望の谷を経験しないまま進む ③評価者自身の能力が天井になる ④ハルシネーションと複雑さの不可視性
特に見落とされがちなのは、「AIの出力を正しく評価するには、評価者自身が一定レベルの能力を持っている必要がある」という構造。評価者の能力不足は、AI活用の質の天井になる
対策の骨格は昔から変わらない。「わからない」を受け入れる／耳の痛いフィードバックを積極的に求める／プロセスに集中する。AI時代はこれに加えて**「AIの回答を鵜呑みにせず自分で検証する回路を残す」**ことが要る
「AIのせいでバカになる」という話ではない。AI時代に必要なメタ認知の使い方が変わった、という話をする

目次

この記事は何の続きか
AI時代の「わかったつもり」4パターン
実務での対処 — 谷を意図的に作る
適用限界
まとめ
参考

この記事は何の続きか

先に断っておくと、「ダニング＝クルーガー効果の有名なグラフ、実は原論文に無い」「セットで貼られるラッセルの名言も、実はパラフレーズで原文じゃない」という2つの都市伝説成仏ネタは、姉妹記事「完全に理解した」の例のグラフ、原論文に無いってよですでに一次資料まで確認している。この記事で改めて長々とはやらない。要約だけしておく。

Kruger & Dunning の原論文（Journal of Personality and Social Psychology, 1999）に、あの「無知の山→絶望の谷→啓蒙の坂→持続可能性の高原」という4フェーズの曲線は載っていない。原論文が示したのは4分位の棒グラフ的な結果であって、ドラマチックな旅路の図解ではない
効果そのものにも「統計的アーティファクト（平均への回帰）ではないか」という批判的再検証がある（Gignac & Zajenkowski 2020 ほか）。反論もあり、学術的には未決着
セットで貼られがちなラッセルの名言も、広く出回っている版はパラフレーズ。原文はこちら。

The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt.

— Bertrand Russell, 初出 1933年5月10日 New York American 紙（原題 "Stupidity Rules"。後の再録題が "The Triumph of Stupidity"）

つまり「わかったつもりを説明する図と名言」自体が「わかったつもり」で流通していた、という入れ子構造がある。この皮肉は姉妹記事に譲るとして、本記事が主戦場にしたいのは別のところだ。この俗流モデルの骨格（能力が低いとメタ認知も不足し自己評価を誤りやすい）自体は、批判を踏まえてもなお実務の比喩として使える範囲がある。そして、その比喩が今いちばん刺さるのが、AIコーディングエージェントを日常的に使う現場だと思っている。

以下、筆者自身が実際にやらかした（一般化した形での）失敗談をベースに、AI時代の「わかったつもり」を4パターンに分解する。読者を見下すつもりは一切ない。筆者であるわたしがまさにこうだった、という話である。

本記事の挿絵は特定の作品やミームそのものではなく、日本アニメ風の比喩として生成したものだ。

パターン1: AI生成コードのレビューで「理解したつもり」になる

現象

AIエージェントが生成したコードのdiffを読み、「ロジックは合っていそうだ」「テストも通った」と感じた時点で、レビューを承認してしまう。実際には、なぜその実装が選ばれたのか、エッジケースの扱い、既存コードとの整合性までは追えていないことが多い。筆者にも、LGTMを押した数日後に「なぜあの分岐をああ書いたんだっけ」と自分に説明できず固まった経験がある。

なぜ起きるか

コードの「表面的な妥当性（もっともらしさ）」と「深い正当性（本当に正しいか）」を区別するのは、そもそもメタ認知コストが高い作業だ。認知心理学では、処理のしやすさを真実性の手がかりとして使うことがあると整理されている。ここから「流暢なAI説明も正しさと取り違えやすい」と考えるのは筆者の実務上の推論であり、AIコードレビューを直接検証した因果研究の結論ではない。夕方のレビュー疲れも普通に効いてくる。

実務での対策

レビュー時に「このコードを自分の言葉で説明できるか」を自問する。説明できない箇所は理解できていない箇所である
AIに実装意図を逆質問し、自分の理解とズレがないか確認する
重要な分岐だけでも自分で最小再現コードを書いてみる

筆者は別モデルによる多段レビュー体制（Claude Code / Codex / Gemini CLI を役割分担させる運用）を組んでいるが、これも「わかったつもり」を検知する仕掛けの一つとして機能している場面がある。ただし過信は禁物で、レビューを担当するモデル自身の能力次第では、指摘そのものがノイズになることもある。これは後述するパターン3と表裏の関係にある。

LGTMの下には、たいてい何かが潜んでいる。

パターン2: AIに聞けば答えが出るので「絶望の谷」を経験しないまま進む

現象

昔なら試行錯誤や失敗を重ねて初めて「自分は何もわかっていなかった」と気づいていた過程を、AIへの質問一発で最短距離を通ってしまう。結果、表面上は動くコードが書けるのに、深い理解が伴わないまま次のタスクに進んでしまう。筆者自身、新しいライブラリを触るとき「まずAIに聞いて動くコードを出してもらう」を繰り返しすぎて、後で似た問題に自力で対応できないことに気づいた回数は正直に言うと少なくない。

なぜ起きるか

学習研究には、間隔を空ける、課題を交互に扱う、想起テストを使う、といった条件が短期の成績を下げても長期保持を助ける「望ましい困難（desirable difficulties）」という考え方がある。ただし、苦労なら何でも学習に効くわけではない。AIの即答が定着を必ず損なうという直接証拠としてではなく、短期の「できた」と長期の学習を区別するための補助線として使っている。

実務での対策

AIに聞く前に、自分の仮説をまず書いてみる（外れてもいい。ズレの大きさが理解度の指標になる）
AIの回答を受け取った後、なぜその答えになるかを自分の言葉で説明し直す
重要な設計判断は、AIの回答をそのまま採用する前に一度離れて再検討する時間を挟む

これは「AIを使うな」という話ではない。谷を経験せずに坂を登った気になっている自覚があるかどうかが分かれ目で、意図的に自分の足で一歩沼に踏み込む工程を残すかどうかの差だと思っている。

パターン3: AIの出力を評価するにはメタ認知が要る — 評価者の能力が上限になる

現象

AIの出力が正しいか誤っているかを判定する能力自体が、評価者（人間）の既存知識に依存する。自分の専門外の領域でAIを使ったとき、AIの誤りに気づけないまま「AIが自信満々に言っているから正しいのだろう」と判断してしまったことが筆者にもある。

なぜ起きるか

これはダニング＝クルーガー効果の骨格（能力が低い人ほど自分の誤りを認識するメタ認知が不足する）と構造的に相似している。ここは冒頭で触れた「統計的アーティファクト説」の対象になっている俗流モデルそのものというより、評価とメタ認知の一般的な関係として、あくまで比喩的に使っている点は強調しておきたい。AIという「常に自信満々に答える存在」を評価する際、評価者自身のドメイン知識が浅いと、AIの過信気味な出力を検知できない。これは能力の優劣の話ではなく、構造の話だ。

実務での対策

自分の専門外の領域でAIを使うときほど、「検証可能な形に落とす」ことを優先する。テスト、型チェック、実機での挙動確認
「ランタイム挙動はAIの説明を鵜呑みにせず必ず実機検証する」というルールを、レビュー体制に明示的に組み込んでおく
判断がつかない領域では、別モデルや人間のセカンドオピニオンを取る。ただしそのセカンドオピニオンも参考意見であり、最終判断は自分がする、という順序を崩さない

測れる範囲は、測る側の身長までしかない。

パターン4: ハルシネーションを見抜けない — 複雑さの不可視性

現象

AIが提示したAPI仕様や挙動の説明が、もっともらしいのに実際には存在しない、あるいは間違っている。表面上の説明が整っているため、経験の浅い開発者ほど疑わずに受け入れてしまう。姉妹記事の番外編でも書いたが、筆者自身、AIにリサーチさせた要約の中に、実在する研究に紛れて実在しない数値が混入していたのを一次資料と突き合わせて初めて気づいた経験がある。

なぜ起きるか

基本ルールは簡単に見えても、その背後の例外は学習が進まないと見えてこない、という「複雑さの不可視性」と相似の構造がここにもある。AIの出力も「一見シンプルで一貫した説明」に見えるため、背後にあるバージョン差異や環境依存、そもそも存在しない仕様を検証しない限り見抜けない。

実務での対策

AIの説明が具体的すぎる・自信満々すぎる箇所ほど、一次資料で裏取りする、という逆説的な習慣を持つ
公式ドキュメントやソースコードでの確認を、AI活用のワークフローに明示的な工程として組み込む
統計値や固有名詞を伴う主張は、URLと突合できるまで存在しないものとして扱う

実務での対処 — 谷を意図的に作る

4パターンに共通する対策を一段抽象化すると、結局は「意図的に谷を作る」という一点に集約される。

AI時代以前から言われてきた「わからないという状態を受け入れる」「耳の痛いフィードバックを積極的に求める」「結果でなくプロセスに集中する」という骨格は、AIエージェント時代にもそのまま通用する。ただし、AIが谷そのものを覆い隠してしまいやすいぶん、意識的にやらないと谷が存在したことにすら気づけない。

具体的には次のようなプラクティスに落とし込んでいる。

AIの提案を一度自分で再実装してみる。 特にコアロジックは、写経ではなく「見ないで再現できるか」を試す
多段レビュー体制を谷の検知装置として使う。 別モデル・別視点によるレビューは、自分一人では気づけない「わかったつもり」を炙り出す場面がある。ただしレビュー結果はあくまで参考意見であり、最終判断は自分がするという原則は崩さない
コードレビュー時に「なぜこの実装なのか」をAIに説明させ、自分の理解とズレがないか突き合わせる
見積もり時に「AIがすぐ答えを出したから簡単」と錯覚しない。 早く答えが出ることと、その答えの射程が正しく理解されていることは別問題である

これらは目新しい話ではない。目新しいのは、AIエージェントが「簡単そうに見せる」精度と速度が、これまでのどんなツールよりも高いという一点だけだ。だからこそ、谷を自分で掘る意識がこれまで以上に必要になっている。

適用限界

本記事はダニング＝クルーガー効果をAI利用の直接的な因果説明や、個人を評価する診断ラベルとして用いるものではない。4パターンは筆者の経験を一般化した実務上の比喩であり、チームの熟練度、対象領域、利用モデルによって現れ方は変わる。また、多段レビューや自己説明は補助線であって、テスト、一次資料の確認、専門家レビューを置き換えない。

まとめ

ダニング＝クルーガー効果の有名なグラフとラッセルの名言の「実は違った」問題は、姉妹記事ですでに成仏済み。本記事はその先の実務接続に集中した
AIコーディングエージェント時代の「わかったつもり」は4パターンに分解できる。①レビューで理解したつもりになる ②絶望の谷を経験せず進む ③評価者の能力が天井になる ④ハルシネーションと複雑さの不可視性を見抜けない
どのパターンも「現象→原因→対策」で扱える。原因の多くは、AIの出力が持つ流暢さ・即答性・もっともらしさが、人間側の検証コストを構造的に下げてしまうことに由来する
対策の骨格は昔から変わらない。谷を意図的に作り、フィードバックを求め、プロセスに集中する。AI時代はこれに「AIの回答を鵜呑みにせず自分で検証する回路を残す」ことが加わる
「AIのせいでバカになる」という話ではない。AI時代に必要なメタ認知の使い方が変わった、というだけの話だ

「わかった」ではなく「わかっていないことがわかった」を目指す。AIエージェントがどれだけ賢くなっても、この態度だけは自分の側に残しておきたい。

参考

一次資料（姉妹記事で裏取り済み・詳細はそちらを参照）

関連記事（筆者）