理解の負債（Comprehension Debt）とは・意味、由来・研究・技術的負債との違い
最終確認日：2026年10月27日
理解の負債とは？
理解の負債とは、AIが作ったコードがチームの理解より速く積み上がり、あとでそのコードを直したり変えたりするときにまず理解するための手間として返ってくる状態のこと。英語では Comprehension Debt という。
ソフトウェア開発の講師で Codemanship の創業者の Jason Gorman 氏は、2025年9月30日に自身のブログでこの呼び名を使った。同氏によると、チームが理解できる速さを超えてコードを作ると、この負債が生じる。負債の大きさは、生成されたコードを自分で直す前に、まずそのコードを理解するために余分にかかる時間だという（※1）。
Google で14年以上、開発者向けの仕事を率いた Addy Osmani 氏は、2026年3月14日に、この語を題にした記事を自身のブログで公開した。同氏は理解の負債を、システムにあるコードの量と人が本当に理解している量との差が広がっていくことだと説明している。同氏はこの語を開発に限らずに使っており、技術者の仕事ではエージェンティックエンジニアリングに最もよく当てはまるという（※2）。
理解の負債と従来の技術的負債では、負債がたまる場所が違う。技術的負債は一般に、早さを優先した設計や書き方の妥協が、あとで変更の手間として積み上がることを指す。
スウェーデンのカールスタード大学の Muhammad Ovais Ahmad 氏によると、技術的負債がコードや設計の判断にたまるのに対し、理解の負債は開発チームの頭の中と共有の理解にたまる。そのため、理解の負債は、コードを動かさずに調べる静的解析の道具や自動のテストでは見つけられないという（※4）。
理解の負債の由来と広まった背景
Gorman 氏は、2025年9月30日の記事で、大規模言語モデル（LLM）が生成したコードを直すのに時間がかかるようになったという報告が増えていると書いた。
同氏によると、他人が昔書いたコードを変える前にまず理解が要るという点では、この問題は新しくない。新しいのは問題の規模で、読まれていないコードが短い時間で大量に作られ、数多くのプロジェクトに入り込んでいるという。Gorman 氏は、だれも読んでいないコードを登録するチームが少なくないと見ている（※1）。
2026年3月の Osmani 氏の記事は、背景に速さの不釣り合いを挙げた。同氏によると、AIは人が見直せるより速くコードを作る。コードを作るのに手間がかかった頃は、上級の技術者は若手が書くより速く見直すことができた。今は、若手が上級の技術者の点検より速くコードを作れるようになり、見直しが品質の関門として働きにくくなったという（※2）。
研究の場でも、この語と近い語が論文に入り始めた。カナダのビクトリア大学の Margaret-Anne Storey 氏は、2026年3月23日に論文の公開サイト arXiv に載せた論考で、生成AIは技術的負債を減らす一方、認知の負債と意図の負債がたまるのを速めるかもしれないと論じた（※3）。Ahmad 氏の2026年4月の論文は、題にこの語を入れ、Gorman 氏がこの語を導入したと紹介している（※4）。
理解の負債に関する主な出来事・ニュース
- 2025年9月30日 Jason Gorman 氏「Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code」を公開：Gorman 氏は自身のブログで、チームが理解できる速さを超えてLLMにコードを作らせると生じる負債を「comprehension debt」と呼び、その危うさを書いた。
- 2026年3月14日 Addy Osmani 氏「Comprehension Debt – the hidden cost of AI generated code.」を公開：Osmani 氏は自身のブログで、AIが生成したコードの見えにくい代償として理解の負債を論じた。
- 2026年3月23日 Margaret-Anne Storey 氏「From Technical Debt to Cognitive and Intent Debt」を公開：Storey 氏は arXiv で、技術的負債に認知の負債と意図の負債を加えてソフトウェアの健全さを考える論考を公開した。
- 2026年4月14日 Muhammad Ovais Ahmad 氏「Comprehension Debt in GenAI-Assisted Software Engineering Projects」を公開：Ahmad 氏は arXiv で、大学のソフトウェア開発の授業で、生成AIの使い方と理解の負債の関係を調べた論文を公開した。
理解の負債と技術的負債・認知の負債との違い
Ahmad 氏と Storey 氏は、どちらも、負債がどこにたまるかで技術的負債と新しい負債を分けている（※3、※4）。
| 語 | たまる場所 | 指すもの | 説明の出典 |
|---|---|---|---|
| 技術的負債（technical debt） | コードや設計 | 早さを優先した妥協が、あとの変更の手間として積み上がること | Ahmad 氏、Storey 氏（※3、※4） |
| 理解の負債（comprehension debt） | 開発チームの頭の中と共有の理解 | チームがコードについて知っていることと、保守や変更に要る理解との差が広がること | Gorman 氏、Osmani 氏、Ahmad 氏（※1、※2、※4） |
| 認知の負債（cognitive debt） | チームの人 | チームで共有する理解が、時間とともに損なわれていくこと | Storey 氏（※3） |
| 意図の負債（intent debt） | 要件の文書やテストなど、コード以外の資料 | 目標や制約、判断の理由が書き残されていないこと | Storey 氏（※3） |
理解の負債と認知の負債の使い分けは、論者によって違う。Osmani 氏は、2つを同じものの別の呼び名として扱っている（※2）。
Storey 氏は関連研究の説明として、理解の負債を、AIで作れるコードと開発者が本当に理解していることとの差だと紹介している。そのうえで同氏は、自身の言う認知の負債を、チーム全体で長い時間をかけて理解が損なわれていく面に目を向けた語だとしている。Storey 氏によると、認知の負債の語は、AIを使った作業で個人の脳の働きが落ちることを指すのにも使われてきた（※3）。
Storey 氏は、認知の負債を生む心の動きとして、Shaw 氏と Nave 氏が「cognitive surrender」と呼ぶものを挙げた。
cognitive surrender とは、AIの出力をほとんど吟味せずに受け入れることだ。同氏によると、これは認知的オフローディングとは違う。認知的オフローディングは、つづりの点検など区切られた作業を道具に任せることで、生産性のための合理的な選択だという（※3）。
理解の負債に関する研究
調査に答えた実務者の82%が理解の負債がたまることに同意
シンガポール経営大学などの Lyu 氏らは、ソフトウェア開発の作業をこなすAIエージェントを作る実務者を調べた。12の組織の20人に話を聞き、その結果を80人へのオンライン調査で確かめた。話を聞いた20人のうち15人は大手のIT企業に属していた。研究が対象にした時期は、2026年2〜5月だ（※5）。
研究者らによると、エージェントは、開発者が理解して見直せるより速くコードを作った。生成されたコード自体も理解しにくかったという。ある参加者は、1週間の変更が以前の数百行から今は1万〜2万行になり、もう読みようがないと話した。チームは、あとで負担になると分かっていても、コードが動いている間は理解を後回しにして先へ進んだ。
研究者らは、こうして分かっていながら先送りした理解を理解の負債と呼んだ。調査では、理解の負債がたまるという課題に82%が同意した。5段階の評価の平均は4.09だった（※5）。
理解の負債への主な対応はAIに直させるか作り直せる形で残すか
チームの主な対応は2つあった。1つは、不具合の原因探しと修正をエージェントに任せ、回帰テスト（変更で、それまで動いていた機能が壊れていないかを確かめるテスト）で確かめるやり方だ。調査では、53.9%がこのやり方を「非常に効果的」か「欠かせない」と評価した。研究者らは、このやり方は負債を返すのではなく迂回するもので、AIへの依存を強めるとしている（※5）。
もう1つは、コードそのものより、コードを作り直して確かめるのに要る仕様やテスト、制約、基盤を残すやり方だ。研究者らは、参加者の1人が描いたこの新しいやり方を「regenerative software」と呼んだ。調査では、67.1%が同じように高く評価した。ただ、理解の負債への対応は、ほかの課題への対応より支持が弱かった。研究者らは、この結果から、課題はまだ解決していないとみている（※5）。
研究者らは限界として、データが参加者の自己申告であることを挙げている。参加者が大手のIT企業に偏っていることや、モデルと道具の移り変わりが速いことも限界だという（※5）。
理解の負債・認知の負債を減らす方法と研究の範囲
Storey 氏は、認知の負債を減らす方法として、次のものを挙げている（※3）。
- 自分が書いていないコードを、知識を共有するために説明し合う場を持つ。
- 不具合や問題が起きたときに振り返りを行い、損なわれた理解をチームで組み立て直す。
- 実装のとき、新しい人を迎えるとき、人が抜けるときに、意識して言葉を交わし、理解の抜けを見つける。
- エージェントに、別のテストや設計で機能を作り直させ、理解を取り戻すきっかけにする。
Storey 氏は、これらに共通するのは、暗黙の知識を開発の進め方の中で言葉や資料にすることだとしている（※3）。テストを増やすことについて、Osmani 氏は、テストは必要だが十分ではないと書いた。想定していない振る舞いには、テストを書けないためだという（※2）。
Storey 氏、Ahmad 氏、Lyu 氏らの論文は、どれもソフトウェア開発を対象にしている（※3、※4、※5）。一方で Osmani 氏はこの語を、AIや自動化に頼りすぎることで人の知性や記憶に生じる代償として、開発に限らない形で定義している（※2）。
理解の負債に関連する用語
- 認知的オフローディング：頭を使う負担を減らすために、体の動きや外の道具を使って、課題に必要な情報の処理を変えること。項目では、生成AIを使った学習の研究を紹介している。
- エージェンティックエンジニアリング：AIエージェントに実装を任せ、人が設計と品質に責任を持つ開発の進め方。
- バイブコーディング：作りたいものを普段の言葉でAIに伝え、AIが書いたコードでアプリやプログラムを作る開発のやり方。
理解の負債に関する出典
※1 Jason Gorman「Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code」（2025年9月30日、Codemanship’s Blog）
※2 Addy Osmani「Comprehension Debt – the hidden cost of AI generated code.」（2026年3月14日）
※3 Margaret-Anne Storey「From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI」（2026年3月23日、4月6日改訂、arXiv）
※4 Muhammad Ovais Ahmad「Comprehension Debt in GenAI-Assisted Software Engineering Projects」（2026年4月14日、arXiv）
※5 Yunbo Lyu ほか「How Do Practitioners Build SE Agents? Insights from a Mixed-Methods Study」（2026年7月12日、7月25日改訂、arXiv）
