理解負債とは？｜AIが書いたコードの量に人の理解が追いつかない差

理解負債（comprehension debt）とは、システムの中にあるコードの量と、そのコードを人間が本当に理解している量との差のことです。生成AIでコードを速く書けるようになった結果、動いてはいるけれど誰も中身を説明できないコードが増えていく状態を指します。技術的負債と違って表に出にくく、気づいたときには修正や障害対応が難しくなっているのが特徴です。この記事では語の出どころを確認し、AIを使った開発者の理解度が下がったAnthropicの実験の数字を、効果量という統計の物差しで読みます。

実務では、次の3点を確認すると理解負債を見つけやすくなります。

• AIが書いた部分を、自分の言葉で説明できるか
• エラーが起きたとき、原因を追えるか
• コードを書く時間の短縮分を、読む時間とレビュー時間に回しているか

理解負債はAIコーディングの広がりとともに名付けられました

英語で確認できる早い用例は、ソフトウェア開発者 Jason Gorman さんのブログ（Codemanship（2025年9月30日））です。Gormanさんは「チームが理解できるより速くコードを生み出すと、私が『理解負債』と呼んでいるものが生まれる」と書き、LLMが生成したコードを時限爆弾にたとえました。

よく引用される定義を示したのは、Addy Osmani さんの記事（Addy Osmani（2026年3月14日））です。理解負債を「システムに存在するコードの量と、そのうち誰か人間が本当に理解している量との間で広がっていく差」と定義しました。技術的負債は開発が重くなるという摩擦として表に出ますが、理解負債は偽りの自信を生む、という対比が要点です。

日本語では、@ITの一色政彦さんの記事（@IT（2026年3月12日））が、確認できた範囲で早い紹介です。定義は「コードと開発者の理解との間のギャップ」で、AIが作ったプルリクエストでは検出された問題が約1.7倍だったというCodeRabbitの調査も、@ITの記事を通じて紹介しています。この数字は観察データであり、AI利用だけが差の原因だと証明するものではありません。翌日にはAPC技術ブログ（2026年3月13日）も「AIが生成したコードの仕組みを開発者が理解できない状態」と説明しました。日本語の造語者は特定できません。理解負債は、AIがコードを書く速さに人の理解が追いつかないことから生まれた言葉です。

技術的負債・認知的負債とは負債の宿る場所が違います

理解負債は、似た名前の2つの負債と並べると輪郭がはっきりします。

負債	宿る場所	表に出方
技術的負債	コードそのもの	変更が重くなる、バグが増えるなどの摩擦
理解負債	コードの量と人間の理解の差	動いているうちは見えず、偽りの自信を生む
認知的負債	人の頭、またはチームの共有理解	自分で考えた内容を思い出せない、説明できない

認知的負債は、MITメディアラボの Kosmyna さんらのプレプリント（arXiv（2025年6月投稿））で使われた言葉です。エッセイを書く実験で、LLMを使った群は脳波で測った脳のネットワークの結びつきが最も弱く、第1セッションで自分のエッセイから正しく引用できた人は18人中0人でした。検索エンジン群では失敗が18人中3人、道具なし群では2人です。査読前の研究である点には注意が必要です。

Storey さんは2026年2月9日、速く進んだことで積み上がる負債は「開発者の頭の中に宿る」と書きました。理解負債は、コードの側の量と人の側の理解をつなぐ差として、この2つの負債のあいだに位置します。1回ごとの判断でAIの答えを吟味せずに受け入れる認知的降伏が日々積み重なった結果として、理解負債が溜まると見ることもできます。技術的負債はコードを直せば返せますが、理解負債は人が読み、理解し直さないと返せません。

Anthropicの実験の50%と67%の差はどのくらい大きいのか

Anthropicの研究者 Judy Hanwen Shen さんと Alex Tamkin さんは、主にジュニアの開発者52人を対象に、AIの支援がコーディング技能の身につき方にどう影響するかを調べました（Anthropic（2026年1月29日））。作業後の理解度クイズの平均は、AIを使った群が50%、自分で書いた群が67%でした。差は17ポイントで、手書き群を基準にすると 17 ÷ 67 ≒ 0.254、およそ4分の1低い水準です。

この差の大きさを表すのが、報告されている Cohen’s d = 0.738 です。Cohen’s d は、2群の平均の差を、得点のばらつき（標準偏差）で割った値です。逆算すると、標準偏差は 17 ÷ 0.738 ≒ 23.0 ポイントになります。検算すると 0.738 × 23.0 ≒ 17.0 で元の差に戻ります。つまり、17ポイントの差は、1人ひとりの得点が平均の周りで上下するふつうの幅の4分の3ほどに当たります。慣例では d が0.5で中程度、0.8で大きいとされるので、0.738は中程度から大きめの効果です。

両群の得点が正規分布に従い、ばらつきも同程度だと仮定すると、d からもう少し直感的な数字が出せます。手書き群から1人、AI群から1人を無作為に選んだとき、手書き群の人のほうが高得点である確率は、標準正規分布の累積確率で Φ(0.738 ÷ √2) = Φ(0.522) ≒ 0.70 です。また、手書き群の平均はAI群の分布の Φ(0.738) ≒ 0.77、つまり上位23%の位置にあります。どちらも、差がはっきりある一方で、AIを使っても手書き群の多くより理解している人がいることを示しています。

ただし52人という人数は多くありません。p = 0.01 は偶然だけでこの差が出る可能性が小さいことを示しますが、効果の大きさそのものは推定の幅が広く、0.738という値をそのまま職場に当てはめるのは早計です。50%と67%の差は、2群の分布がはっきりずれるほどの大きさですが、少人数の実験なので方向を示す数字として読むのが妥当です。

理解負債を溜めないAIの使い方

Anthropicの実験で見逃せないのは、AIを使った人の中でも差があったことです。AIにコードを書かせるだけでなく、説明を求める用途で使った人は、理解度の落ち込みが小さかったと報告されています。AIを使うかどうかより、AIとのやりとりの中で自分が理解する工程を残しているかどうかが分かれ目になります。

カールスタード大学の Ahmad さんは、学部生207人の振り返り日誌621件を質的に分析し、理解負債が溜まるパターンを4つ、和らげるパターンを1つ見出しています（arXiv、2026年4月14日）。現場で取れる手としては、AIが書いたコードをマージする前に、なぜその書き方なのかを自分の言葉で説明できるかを確かめることが基本になります。AIが作ったプルリクエストで検出された問題が約1.7倍だったという@ITの紹介を踏まえると、AI生成分のレビューには人の時間を多めに見積もっておくほうが実態に合います。コードを書く時間が短くなった分を、読んで理解する時間に回すことが、理解負債の返済にあたります。

よくある質問

理解負債と技術的負債はどう違いますか？

技術的負債はコードそのものに宿り、変更しにくさやバグとして開発者に摩擦を感じさせます。理解負債はコードの量と人の理解の差で、コードがきれいに動いていても溜まります。一見すると問題がないため、気づくのが遅れやすい点が厄介です。

エンジニアでなくても関係がありますか？

語が生まれたのはソフトウェア開発の文脈ですが、AIに作らせた資料や分析を中身を理解しないまま積み上げていく構造は、ほかの仕事にも当てはまります。MITのエッセイの実験で、第1セッションでLLMを使った18人のうち、自分の文章から正しく引用できた人がいなかったのは、その一例と見ることができます。

AIを使った人はみな理解度が下がるのですか？

そうとは限りません。Anthropicの実験でも、AIに説明を求める使い方をした人は落ち込みが小さく、効果量から計算しても両群の得点分布はかなり重なります。AIの使い方しだいで結果が変わる余地があると読むのが自然です。

理解負債は、数字で見えにくいからこそ、どのくらいの差なら気にするべきかを見積もる必要があります。和からでは、AIの答えの確かめ方を統計の見方とあわせて考える生成AI研修を行っています。チームでのAIの使い方を考える材料の1つとして、目を通してみてください。

<監修／和から株式会社 堀口智之>