「完全に理解した」の例のグラフ、原論文に無いってよ — 偏屈エンジニアのための都市伝説成仏ガイド
TL;DR
- エンジニア界隈で「完全に理解した→なにもわからない→チョットデキル」の根拠として貼られる例の曲線は、ダニング＝クルーガーの原論文（1999）に存在しない
- ついでに添えられがちなラッセルの名言も、広く出回っている版はパラフレーズであって原文ではない
- 「ダークモードは省電力」も実測すると、通常輝度では 3〜9% しか変わらない（Purdue 大の実測）。効かせたいなら色より輝度
- 「PHP 8 は JIT で速くなった」— JIT は 8.0 から 8.4 まで一貫してデフォルト無効である（2026年7月執筆時点）
- 「Markdown は AI に優しい」— で、誰か測りました？ 誰も測っていなかったので筆者が測った。結果、Markdown は最適にならなかった（詳細は姉妹記事）
- これらに共通するのは 「よくできた図解・言い切り・デフォルト値の未確認」が検証をスキップさせる構造。そして AI 時代、この構造は加速している（本文に実話あり）
- 結論: 偏屈は美徳。一次資料を出せ。ソースは俺、は禁止
はじめに: この記事は誰向けか
対象読者は 偏屈エンジニア である。
- 勉強会のスライドに例の曲線が出てくると「それ原典あるんですか」と言いたくなるが、空気を読んで言えなかった人
- 「〜らしいよ」で技術選定が進みそうになると胃が痛くなる人
- 「ソースは？」と聞いて「Qiitaの記事」と返され、遠い目をしたことがある人
安心してほしい。この記事は、あなたのその偏屈さを エンジニアリングの中核スキル として全肯定する。以下、筆者が実際に一次資料まで潜って確認した「技術都市伝説」を 5 体、成仏させていく。
本記事の挿絵はすべて、特定の作品やミームそのものではなく、日本アニメ風の比喩として生成したものだ。幽霊になっているのは実在のグラフではなく「出典のない図解」の概念である。
なお筆者も後半で 自分の書いた資料に自分でツッコむ ので、マウント記事ではない。安心して読んでほしい。「それってあなたの感想ですよね」は、この記事では褒め言葉である。
伝説その1: 「完全に理解した」曲線は、原論文に存在しない
通説
「完全に理解した（無知の山）→ なにもわからない（絶望の谷）→ チョットデキル（啓蒙の坂〜高原）」。エンジニアの学習曲線ネタとして愛されすぎて、もはや履歴書に書けそうな例のアレ。根拠としてダニング＝クルーガー効果（1999）が添えられる。
ほんとうのところ
Kruger & Dunning の原論文（Journal of Personality and Social Psychology, 1999, Vol. 77, No. 6）に、あの4フェーズの曲線は載っていない。原論文が示したのは「成績下位群は自己評価が実際より高く、上位群はやや低い」という4分位の棒グラフ的な結果であって、「山→谷→坂→高原」というドラマチックな旅路ではない。あの曲線は後世の誰かが描いた俗流図解が、伝言ゲームで「原論文の図」に昇格したものだ。
さらに偏屈を極めると、効果そのものにも統計的アーティファクト（平均への回帰＋自己相関）ではないかという批判的再検証がある（Gignac & Zajenkowski 2020, Intelligence 誌ほか）。反論もあり、学術的には未決着だ。
つまり「完全に理解した曲線」は、「わかったつもり」を説明する図が、それ自体「わかったつもり」で流通しているという、味わい深い再帰構造になっている。
成仏してくれ。
偏屈ポイント
- 曲線を貼るなとは言わない。「よく知られた俗流図解であり原論文の図ではない」と一言添えるだけで、記事の信頼性は跳ね上がる
- 「みんな知ってる図」ほど出典を確認する価値がある。みんな知ってるからこそ、誰も確認していない
伝説その2: あのラッセルの名言、原文じゃない
通説
例の曲線とセットで貼られがちなバートランド・ラッセルの名言。「この世の問題は、愚か者ほど自信に満ち、賢い者ほど疑いに満ちていることだ」。かっこいい。スライドの締めに最高。
ほんとうのところ
広く流通している英語版（"fools and fanatics are always so certain of themselves..."）はパラフレーズであり、ラッセルの原文ではない。原文はこうだ。
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" は再録時の題である。名言の出典を確認したら、タイトルまで伝言ゲームだった。
「ラッセルはこう言った」と言ったな。あれは嘘だ。
偏屈ポイント
- 名言引用は「誰が・いつ・どこで」の3点セットが揃って初めて引用になる。揃わないなら「〜という趣旨の言葉が伝わっている」と書く
- 皮肉なことに、この名言の誤伝播は伝説その1と完全に同じ構造。わかったつもりを戒める素材が、わかったつもりで運用されている
伝説その3: 「ダークモードは省電力」の実測値、思ってるより渋い
通説
「OLED は黒画素が消灯するから、ダークモードにすればバッテリーが長持ちする」。デバイス設定の話題で必ず湧く、あの定番。
ほんとうのところ
原理は正しい。OLED は自発光なので黒画素は消灯する。問題は程度だ。
Purdue 大学の実測研究（MobiSys '21、Google 製6アプリで検証）によると:
| 条件 | ライト→ダーク切替の節電効果 |
|---|---|
| 輝度 30〜50%（屋内の普通の使い方） | 平均 3〜9% |
| 輝度 100%（真夏の屋外） | 平均 39〜47% |
つまり普段使いの輝度では、戦闘力……たったの 3〜9% か……。一方で輝度そのものの影響は指数的で、100% → 50% に下げるだけで OLED の消費電力は約 1/10 になる。省電力したいなら、色を変える前に輝度を下げろ、という身も蓋もない結論になる。
真の実力者（輝度）は、いつも隣で静かに光っている。
ちなみに筆者はこの検証の過程でスマホをグレースケール運用（色を全部消す）してみたが、省電力目的では推奨しない。効果はあくまで「無意識にスマホを触る回数が減る」系のデジタルウェルビーイングと、自分のアプリの UI が色に依存しすぎていないかを確認するアクセシビリティ検証にある。色を消すと、情報階層が設計できていない画面は一瞬でバレる。おすすめ。
偏屈ポイント
- 「原理的に正しい」と「実用上意味がある」の間には谷がある。原理で語られたら量を聞け
- 「何%変わるんですか」という一言は、会議で最も嫌われ、最も価値のある質問である
- 白状すると、筆者もこの数値を自分では実測していない。一次資料に当たっただけだ。偏屈の最低ラインは**「実測、それが無理なら一次資料」**である。孫引きの孫引きあたりから都市伝説が始まる
伝説その4: 「PHP 8 は JIT で速い」— JIT、デフォルトで寝てるが？
通説
「PHP 8 で JIT が入ったから、もう PHP は遅くない」。PHP vs Go 論争で PHP 側が撃つ定番の弾。
ほんとうのところ
PHP に JIT が入ったのは事実。だが JIT は PHP 8.0 から 8.4 まで、一貫してデフォルト無効である（本稿執筆の2026年7月時点。将来のバージョンで変わったら、この記事が新たな都市伝説の発生源になる。それが一次資料確認という様式美だ）。
- 8.3 以前:
opcache.jit=tracingだがopcache.jit_buffer_size=0→ バッファ0で実質無効 - 8.4 以降:
opcache.jit=disableかつopcache.jit_buffer_size=64M→ 設定そのもので明示的に無効
8.4 で変わったのは「無効化の方法」であって、有効化されたわけではない（PHP.Watch / php.net 公式マニュアル）。つまり php.ini を触っていないあなたのサーバーで、JIT は今日も静かに眠っている。そんな装備で大丈夫か？——大丈夫じゃない、設定を確認しよう。
あなたの本番環境の JIT くん（イメージ）。稼働しているか確認しよう
ここで白状すると、筆者は昔、非エンジニアのクライアント向けに「PHP と Go の比較資料」を書いたことがある。読み返したら、インタプリタ/コンパイルの軸と動的/静的型付けの軸を混同し、PHP が OPcache でバイトコードにコンパイル&キャッシュされている事実を無視し、「Go はメモリ管理が自動で安全」とPHP にも GC があるのに Go 固有の長所みたいに書いていた。完全に理解した顔で書いていた。あの資料は俺が倒すべき無知の山だった（山は原論文に無いが）。
そして重要な対称性がある。「PHP は遅い」を雑に批判する側が「PHP 8 は JIT で速い」と言った瞬間、同じ穴に落ちる。デフォルト無効なのだから。単純化を批判する者は、自分の単純化にも刺される。介錯は一次資料が務める。
偏屈ポイント
- 「機能が入った」と「機能が効いている」は別。デフォルト値を確認するまでが技術選定
- 言語論争で数値を出すときは、実行モデル（I/O バウンドか CPU バウンドか）と設定（JIT の有無、OPcache）を添える。添えられないなら、それは応援演説であって比較ではない
伝説その5: 「Markdown は AI に優しい」— で、測った？
通説
「AI に読ませるなら Markdown。構造化されてて AI 可読性が高い」。AI 駆動開発の文脈で聞かない日はない。かくいう筆者も自分のスライドに「AI可読性の高いデータファイル＝Markdown」と書いていた。
ほんとうのところ
「AI 可読性」を定量的に検証した資料を、通説の流通量に見合うだけ見たことがあるだろうか。 筆者はない。そこで偏屈エンジニアとしては、バズワードを測定可能な軸に分解することになる。
- トークン効率 — 同じデータを JSON / YAML / TOML / Markdown 表 / CSV で書いてトークナイザで実測する（モデルごとにトークナイザが違うので「AI 一般」では語れない）
- 生成エラー耐性 — 「読ませる形式」と「書かせる形式」は要件が違う。YAML はインデント地獄で AI が生成時にコケやすいが、読む分には優しい。JSON は冗長だが構造が壊れにくい
- diff 親和性 — 1行1レコードの形式は差分が読みやすい。JSON は整形次第で diff が壊滅する
- 部分読み込み耐性 — Markdown は見出しで自然に分割できるが、JSON は途中で切ると即死する。コンテキスト長と課金に直結する実務問題
- 言語選定への波及 — 型注釈は AI にとってのドキュメントとして機能する。ただし「AI が読みやすいから」で技術選定を歪めるのは本末転倒。あくまで加点要素
この実測は完了し、結果は姉妹記事として公開している。ネタバレを一つだけ置いておくと——「Markdownが最適」にはならなかった。表形式データを読ませるならCSVが圧勝（トークン x1.00 に対し整形JSONは x2.4）で、生成させたときの危険は構文エラーではなく「md表が改行を <br> に静かに書き換える」類の検知できない内容改変だった。詳細な数表と再現条件は姉妹記事（「AI可読性」は測れるのか）に譲る。測っていない数字は書かないのがこの記事の掟である。
偏屈ポイント
- バズワードを見たら「それはどの軸の話で、どう測るのか」と問う。分解できない概念は、だいたい輸送中に事故る
- 「〜に優しい」系の主張は、優しさの単位を確認する
番外編: AI が「それらしい研究データ」を創作してきた実話
この記事の下調べ中、実際にあった話をする。
グレースケール運用の効果を AI にリサーチさせていたところ、要約の中に「412名を対象とした Journal of Behavioral Addictions の RCT」「マイクロサッケード頻度が37%減少」という、実にそれらしい数値が混入していた。出典 URL を要求したところ——存在しなかった。実在する研究（Holte & Ferraro らの査読研究など）に、実在しない数字が混ざって出てきたのである。
これはもう伝言ゲームですらない。伝言の途中に作話する参加者が常駐するようになったということだ。都市伝説の生成速度は、人力時代より確実に上がっている。
額縁は立派。中身は煙。虫眼鏡（一次資料の突合）を持て。
偏屈エンジニアの出番である。AI の出力に含まれる統計値は、一次 URL と突合できるまで存在しないものとして扱う。「それっぽさ」は真実性の証拠ではない。むしろ AI の「それっぽさ」は人類史上最高水準なので、それっぽいほど疑うくらいでちょうどいい。
都市伝説が生まれる構造 — 4つの共通パターン
5体の伝説と番外編を並べると、共通の生成機構が見えてくる。
| パターン | 事例 | 対策 |
|---|---|---|
| 図解の魔力 | 完全に理解した曲線 | よくできた図ほど出典を確認する |
| 引用の伝言ゲーム | ラッセルの名言 | 誰が・いつ・どこでの3点セットを要求する |
| 原理と量の混同 | ダークモード省電力 | 「原理的に正しい」なら「何%か」を聞く |
| デフォルト値の未確認 | PHP の JIT | 「入った」と「効いてる」を区別する |
そして 5 つ目の「Markdown は AI に優しい」と番外編が示すのは、この 4 パターンが AI によってスケールするという現在地だ。AI は流暢に要約し、流暢に図解し、流暢に「それらしい数字」を補完する。流暢さを正確さの代理指標にした瞬間、負ける。
偏屈エンジニア五箇条
最後に、明日から使える実務プロトコルとして雑にまとめる。
- 一次資料を出せ — 二次記事の孫引きは出典ではない。「ソースは俺」は論外（実測ログがあるなら別。それは一次資料だ）
- 図と名言ほど疑え — 拡散力と正確性は独立変数である
- 原理には量を、機能にはデフォルト値を聞け — 「理論上」「対応済み」は無料で言える
- AI の統計値は URL 突合まで存在しない — それっぽさは証拠ではない
- 自分の過去資料にも適用しろ — 筆者の PHP/Go 資料のように、一番近くにいる都市伝説の発生源は自分である
「知らんけど」で締める関西の知恵は、実は誠実な不確実性表明だったのかもしれない。だが我々はエンジニアなので、「知らんけど」の代わりに出典を貼ろう。
まとめ
- 例の曲線は原論文に無い。名言は原文じゃない。ダークモードは思ったより効かない。JIT は寝てる。Markdown 優位は未実測
- どれも「調べればわかる」ことが、よくできた見た目のせいで調べられずに流通していた
- AI 時代、それらしい情報の生成コストはほぼゼロになった。検証コストを払う者の相対価値は上がり続ける
- つまり偏屈エンジニアの時代である。胸を張って「それ、一次資料ありますか」と言っていけ
参考
一次・準一次資料
- ダニング＝クルーガー効果の原論文はこれ（例の曲線は載っていない） — Kruger & Dunning (1999), J. Pers. Soc. Psychol.
- 「あの効果、ほぼ統計的アーティファクトでは？」という批判論文 — Gignac & Zajenkowski (2020), Intelligence
- ラッセルの原文と初出（1933-05-10）を確認できるページ — WIST Quotations / 本文はこちら — Internet Archive
- ダークモード、思ったほど電池は保たないという実測の話 — Purdue大 公式リリース (MobiSys '21)
- PHP 8.4 で JIT の有効化まわりの INI 設定はこう変わった — PHP.Watch
- PHP 公式マニュアル — OPcache Runtime Configuration
関連記事（筆者）
※ 本記事は個人の見解であり、所属組織の公式見解を代表するものではない。偏屈は筆者個人の資産である。