認知的負債：速度が理解を超えるとき

2026年3月1日原文(rockoder.com)

概要

AI支援開発により、コード生産速度と理解速度の乖離が拡大
コードの迅速な出荷が組織的な知識形成を阻害
可視化されない「認知的負債」が蓄積し、組織の長期的リスクに
レビューや評価指標が実際の理解度を反映できていない現状
組織的な測定・評価方法の見直しが急務

コード生産と理解の乖離

AI支援開発 により、エンジニアは短期間で多くの機能を出荷可能
DORAメトリクス やパフォーマンス指標は一見優秀に見える状況
数ヶ月後のアーキテクチャ変更時に、 誰もコードの意図や構造を説明できない問題 が顕在化
コード理解より生産が容易 になり、コードの「認知的負債」が発生

認知的負債の発生メカニズム

手作業による開発では、 生産と吸収（理解） が同時進行
AI支援では、 生産速度のみ加速し、理解速度は人間の限界に依存
出荷速度と理解速度のギャップ が認知的負債として蓄積
認知的負債は、 MTTR（平均復旧時間）やChange Failure Rate などの遅行指標でしか表面化しない

組織が測定しているもの・していないもの

組織の評価指標は 出荷物やストーリーポイント など「見える成果」に偏重
かつては「出荷＝理解」とみなされていたが、 その前提が崩壊
組織的知識の蓄積が不十分 となり、パフォーマンス評価委員会も認知的負債を把握できない

レビュワーのジレンマ

AI支援によりジュニアエンジニアの出力速度がシニアレビュワーのレビュー速度を上回る
結果として レビューの質が低下 し、表面的な確認だけで承認が進む傾向
レビュワー自身も 内容を十分理解せず承認するため、組織的な「理解済みコード」の前提が崩れる

新しいバーンアウトパターン

AIツール利用エンジニア特有の「認知的切断」型疲弊
進捗は早いが、 自分の出力物への理解や自信が希薄
「説明には再構築が必要」「予測が困難」などの症状
可視化された成果主義 がこの傾向を助長し、認知的負債が加速

組織的記憶の喪失

組織知識は 明示的（ドキュメント等）と暗黙的（経験・直感） の2種類
AI支援開発で暗黙知の形成が阻害 され、エンジニアの離脱とともに知識も消失
システムの維持・拡張時に 理解者不在という遅延型の失敗モード が発生

認知的負債の累積による失敗パターン

長期間動いているコードへの信頼が逆転 し、むしろ危険度が増す
インシデント対応時に「ブラックボックス化」 し、復旧コストが増大
ジュニアエンジニアの成長阻害 により、将来のシニア人材不足を招く

組織リーダーの視点と測定問題

AI支援開発は生産性向上として認識されやすい
「理解度」や「説明可能性」を測る指標が存在しない
リーダー層は 可視化されたデータに基づき合理的判断 を下すが、データ自体が不完全
測定できないものは最適化できず、 組織は出荷速度を優先し続ける

モデルの限界と今後の対応

全ての開発業務に認知的負債の問題が当てはまるわけではない
ドキュメントやツールの進化でギャップを補える可能性 も
本質的課題は「測定できるものしか最適化できない」組織構造
理解度の可視化や評価方法の刷新 が今後の課題

Hackerたちの意見

このスレッドは関連性が高いよね: https://news.ycombinator.com/item?id=47194847 「AIの適切な量はゼロじゃないし、最大でもない。」

└

別のスレッドの著者だよ。こんなに似てる点が多いとは驚きだけど、善意で考えれば、これは偶然だと思う。多くの開発者が今後の問題に気づき始めてるからね。

組織の記憶やオンコールデバッグのセクションがこれに触れてるけど、他の部分にも大きな影響があるんだよね。例えば、プロダクトサポートで働いていて、顧客が製品の挙動について質問してきたら、ドキュメントが少なかったり（AIが書いたものだったりすると）、エンジニアが自分の書いたコードの基本をすぐに理解していなかったりすると、答えを見つけるのがすごく難しくなる。たとえドキュメントが素晴らしくて、エンジニアが自分のコードについて話し合えるとしても、アップデートのペースについていくのは他のチームにとって大きな課題になることがある。

└

手動でコードを書く時間が減った分、ドキュメント作成もワークフローの一部にすべきだよね。これから始めようと思う。

大企業に4年間いて、あちこちで進行中の無数のプロジェクトを追いかけていると、彼らがどうやって相互作用しているか（良い場合も悪い場合も）を理解するのが一つの仕事になっちゃった。技術的なスキルが全体像を明確にするのに役立つと思ってたのに、実際にはその逆のことが起こってる。

└

一つの（複雑な）製品を持つ会社にいたけど、50倍の製品を持つ10倍大きな会社に入ったら、全体像を理解するチャンスはゼロだよ。とはいえ、私たちの中にはそれをある程度把握することが期待されている人もいる。かなりの挑戦だし、LLMsがあったら本当に不可能だと思う。

└

知識企業の中で人々がどのようにやり取りして物事を進めるかが、その企業の運営の基盤になってるんだ。最近のSaaS CEOの記事では、これを「言語ゲーム」って呼んでるよ。

投稿の前提、つまりコーダーが6ヶ月前に何を書いたか、なぜ書いたかを覚えているというのは間違ってる。コードを書くときに理解するのは簡単だけど、自分が書いたコードを理解するのは難しいっていう問題はずっとあった。だから、AIが登場する前にJoel Spolskyが「コードを読むのは書くより難しい」と言ったんだよね。

└

「難しい」というのは遅いという意味じゃないよ。自分のコードを読むのと理解するのは、書いたりテストしたりするよりもずっと早いけど、簡単ではない。AIツールは、自分が作っているコードを理解するのを妨げないし、実際にはそんなに時間がかからない。でも、難しい作業を避けようとする自然な傾向があるんだよね。もちろん、AIのコードは一般的にひどいから、プロセスがさらに辛くなるけど、君はそれを生み出したコンテキストを見ていたから、少し有利だよ。

└

初めて学ぶときは、手でコードを書くことが大事だと思う。苦労することで批判的思考が身につくし、どうやって「センス」を持つかっていうと、こういう経験が必要だよね :) これがプロダクションコードになるかはわからないけど、Jupyterノートブックみたいに、段階を追って解決策を作る必要があると感じることが多い。もちろん、コードベースの中で意味のないことを理解する必要はないけど、いくつかのことは慎重に考える必要がある。

└

最近、4年前に触ったコードベースで作業したんだけど、全ての行を覚えてるわけじゃないけど、どうやって組み立てられているかはかなり理解してたよ。（追記：いや、特別な記憶力があるわけじゃないからね）

└

何を書いたか、ロジックがどうなっているかは正確には覚えてないけど、全体の流れは大体覚えてるから、どこにコードがあるのか理解しやすいんだ。

Hacker Newsで議論の続きを見る

ハクソク