コードは動く。テストも通る。でも「なぜそう動くのか」を聞かれると、チーム全員が黙る。
これは特定のチームの話ではない。AIコーディングが普及するほど、多くの開発現場で起き始めていることだ。動くコードが存在することと、誰かがそのコードを理解していることは、まったく別の話になった。
「技術的負債」と「認知的負債」は別物だ
「技術的負債」という言葉は聞いたことがあるかもしれない。コードが汚くなっていく問題——重複した処理、読みにくい変数名、テストのないコード。これは「コードの中にある」問題だ。
「認知的負債（cognitive debt）」は違う場所にある。
ブリティッシュコロンビア大学のソフトウェアエンジニアリング研究者Margaret-Anne Storeyが2026年2月に定義した概念によると、認知的負債とは「開発者の頭の中にある」問題だ。コードがどれだけ整理されていても、誰もそのコードの設計意図を理解していなければ、プロジェクトは前に進めない。
「技術的負債はコードの中にある。認知的負債は開発者の頭の中にある。AIのスピードが上がるほど、この負債は蓄積する」——Margaret-Anne Storey
StoreyはMartin Fowlerが主催した「Future of Software Engineering Retreat」からこの定義を持ち帰り、ブログに記した。Simon Willisonも自身の体験を交えて紹介している。バイブコーディングしたプロジェクトのシステム全体像を、いつの間にか失っていたと。
1985年の警告が、2026年に届いた
コンピュータ科学者Peter Naurは1985年に「Programming as Theory Building」（プログラミングは理論構築である）という論文を発表した。そこで彼はこう主張した。
「プログラムの本質的な知識は、コードの中ではなく、開発者の頭の中に存在する」
建物の設計図を思い浮かべてほしい。建物は完成している。しかし設計者が亡くなったあと、残された人間はその建物を正しく改修できるだろうか。「この壁は構造壁か？」「この配管はどこに繋がっているか？」——答えは設計図ではなく、設計者の頭の中にあったのだ。
Naurはこれをプログラミングに当てはめた。コードを書いた人間がチームを去ると、コードは残るが「なぜそう設計したか」という理論は消える。
AIコーディングは、この問題を新しいかたちで再現している。コードを生成したのはAIだ。AIは「なぜそう書いたか」を人間の頭の中に残さない。設計者が最初から存在しないまま、建物だけが建つ。
「AIを取り除いたら77%が失敗した」実験
これは比喩ではない。実験で確かめられた現象だ。
2026年2月にarXivで発表された論文「Mitigating 'Epistemic Debt' in Generative AI-Scaffolded Novice Programming using Metacognitive Scripts」は、78名の初心者プログラマーを対象にした実験を報告している。
3つのグループに分けた実験の構造はシンプルだ。
コードを書いたときは100%完成させた制限なしAIグループが、AIを取り除いたフェーズ2で77%失敗した（χ²(2)=13.8, p=.001）。
コードを書けたのに、何一つ直せなかった。
「脆弱なエキスパート」という問題
この論文が名付けた現象が「Fragile Experts（脆弱なエキスパート）」だ。
AIがあるとき、完璧に見える。タスクを100%こなす。コードレビューを出せる。機能を追加できる。でもAIがないとき——あるいはAIが生成していない予期せぬバグに直面したとき——崩壊する。
さらに論文が記録した「Tautological Loop（同語反復ループ）」という現象がある。制限なしAIグループの62%が、コードの説明を求められたとき、AIが生成したコメントをそのまま繰り返すだけで、因果関係を説明できなかった。
// ❌ Tautological Loop（同語反復ループ）の例
// このコードは非同期でAPIを呼び出して結果を返す
const result = await Promise.allSettled(requests.map(r => fetch(r)));
// コメントがコードの構造をそのまま言い換えているだけ。
// 「なぜallSettledなのか」「失敗した場合どうなるのか」が書かれていない。
// コードを読めているが、理解していない。
// ✅ 理解があるコメント
// 一部のリクエストが失敗しても残りの結果を失わないようallSettledを使用。
// rejectedになった項目はstatus: "rejected"として後の再試行キューに入れる。
const result = await Promise.allSettled(requests.map(r => fetch(r)));
コードが読めることと、コードを理解していることは別だ。
MITの脳波実験が示した「示唆」
2025年6月、MIT Media Labが発表した研究「Your Brain on ChatGPT」は、54名の参加者（18〜39歳）がSATエッセイを「ChatGPTあり / 検索あり / ツールなし」の3条件で書く実験を行った。
EEG（脳波測定）の結果、ChatGPT使用者は最も弱い神経結合を示した。そして83%のChatGPT使用者が、自分の書いたエッセイの要点を思い出せなかった。
この研究はエッセイ執筆タスクの研究であり、コーディングへの直接の一般化はできない。N=54のarXiv preprintで未査読だ。ただし論文自体が「cognitive debt」という用語を使用しており、AIが認知処理に与える影響を考える上での参考にはなる。
コーディングでも同様のことが起きているかどうかは、現時点では証明されていない。しかし「AIに任せた作業は頭に残りにくい」という構造は、前述のarXiv:2602.20206の実験とも整合する。
組織に広がる「認識論的空洞」
個人レベルでは「自分が書いたコードを理解していない」問題だ。これが組織レベルになると何が起きるか。
Storeyのブログが紹介したケースがある。あるチームが学期7〜8週目に身動きが取れなくなった。機能は動いていた。しかしシステム全体の設計を理解している人間がチームに誰もいなかった。一人の問題ではなく、チーム全員が理解していない状態——これが認識論的空洞だ。
LeadDevの「AI Impact Report 2025」（880名超のエンジニアリングリーダー調査）では、54%が「長期的にはジュニア開発者のポジションが減少する」と回答している。ジュニアが採用されなければ、コードを隅々まで読んで理解する「見習い期間」を経た開発者が育たない。5年後、組織の中に「コードを本当に理解している人間」がどれだけ残るか。
Anthropicの研究「AI assistance coding skills」でも、AIに丸投げしたグループのテストスコアは手動グループより17ポイント低かった（Cohen's d = 0.738, p = 0.010）。詳細な実験設計はすでに別記事で解説しているが（AIコーディングはスキルを低下させるか——Anthropic RCT研究の詳細）、ここで注目したいのは個人の話ではなく、組織全体でこの現象が起きているという点だ。
認知的負債の5つのシグナル
自分のチームが認知的負債を積んでいるかどうかを見極めるために、以下を確認してみてほしい。
❌ 認知的負債が蓄積しているシグナル:
1. 自分のPRを「どんな設計判断をしたか」で説明できない
→ 「動いたのでPRを出しました」しか言えない
2. バグが出たとき、どのファイルを直せばいいか見当がつかない
→ コードは読めるが、システム全体像が頭にない
3. Gitのコミットログが1セッションで20件を超えている
→ AIと「動くまで試し続けた」だけで、なぜ動いたかわからない
4. 「このコードを変えると何が壊れるか」が即答できない
→ 依存関係を把握していない
5. コードレビューで「AIが生成したので詳細はわかりません」と言う
→ 知識の委譲が発生している
これらは「能力の問題」ではない。AIとの関わり方の問題だ。
「理解してから統合する」という対処法
前述のarXiv:2602.20206の実験は、問題を提起するだけでなく解決策も示している。
「Scaffolded AI（説明ゲート付きAI）」条件では、AIを使う前に「このコードが何をするか、なぜそう書くかを説明してから統合する」というステップを設けた。結果、制限なしAIの23.1%から61.5%へ、デバッグ成功率が回復した。
72%の参加者が最初「説明を求められるのが面倒だ」と感じた。しかし成功したデバッガーの64%が「事前の説明が修正を可能にした」と報告している。
❌ 認知的負債を積む使い方:
「非同期でAPIを並列呼び出しするコードを書いて」
→ AIがコードを生成 → コピペ → 動いた → 次の機能へ
→ 1ヶ月後: このコードが壊れても直し方がわからない
✅ 認知的負債を減らす使い方:
「非同期でAPIを並列呼び出しするコードを書いて。
各ステップで何が起きているか説明して。
なぜPromise.allではなくallSettledを使うのかも教えて」
→ 理解してから統合 → AIを外しても直せる
→ 1ヶ月後: システムの設計意図が頭に残っている
ポイントは「生成後に読む」ではなく「生成前・生成中に理解する」だ。コードが出てきてから説明を求めるのではなく、生成のプロセス自体に説明を組み込む。
コードレビューのときも同じ問いを使える。「このPRで一番重要な設計判断はどれか」「この部分を変えると何が影響を受けるか」——答えられないなら、まだ統合する準備ができていない。
「動く」の先に何があるか
バイブコーディングの価値は本物だ。アイデアを素早く形にできる。プロトタイプを一晩で作れる。非エンジニアでも機能するものを作れる。これは否定しない。
問題は「動く」を最終地点にしたときだ。
技術的負債はコードを見れば見える。認知的負債は見えない。チームが何を理解していないかは、バグが起きるまで表面化しない。そしてバグが起きたとき、誰も直せない——という状態になって初めて気づく。
Naurが1985年に言ったことは今も変わらない。プログラムの知識はコードではなく、人間の頭の中にある。AIが書いたコードは速く、大量で、動く。でも理解は速くならない。理解は、まだ人間がやる必要がある。
