理解負債とは?|AIが書いたコードの量に人の理解が追いつかない差
公開日
2026年9月27日
更新日
2026年10月13日

理解負債(comprehension debt)とは、システムの中にあるコードの量と、そのコードを人間が本当に理解している量との差のことです。生成AIでコードを速く書けても、人が仕組みを説明したり、必要な変更を加えたりできなければ、この差が広がります。この記事では具体例から意味を確認し、AIが書いたコードを説明・修正できる状態を保つための確認方法を紹介します。
この記事のポイント
- 理解負債は、コード量と、それを人が説明・修正できる範囲の差です。
- コードが動くことと、人が仕組みを理解していることは別に確かめます。
- 自分で説明する、小さく変更する、エラーの原因を追うことが、理解を確かめる手がかりになります。
この記事の主な内容
動くコードでも、説明や変更ができなければ理解は追いついていません
仕組みを説明する例として、AIに売上データを集計するコードを書いてもらう場面を考えます。手元のデータでは集計結果が出たものの、「どの行を対象にしているか」「空欄をどう扱っているか」を自分で説明できないとします。さらに、集計条件を変えたいときや、結果が合わないときに、どこを直せばよいか分かりません。
この例では、コードは手に入りましたが、それを変更・点検するための理解は十分ではありません。動いている間は見えにくいこの差が、修正や障害対応の場面で問題になります。これは理解負債を説明するための例であり、実際の事例ではありません。
なぜAIが書く速さに、人の理解が追いつかないのか
AIがコードを生成する工程と、人がその処理を読み、意図や前提を理解する工程は別です。生成されたコードを動かすことだけで作業を終えると、人が読む量や確かめる量よりも、システムに加わるコードの量が先に増えていきます。
見た目が整っていてテストが通っても、なぜその処理が必要なのかを説明できるとは限りません。完成したかどうかに加えて、人が説明・変更・原因追跡できるかを見る必要があります。
理解負債を溜めないために、説明・変更・原因追跡を試します
AIが書いたコードを取り込む前に、次のように自分の理解を確かめます。
- 説明する:入力から出力までの処理を、自分の言葉で説明します。何を前提にしているかも確認します。
- 小さく変更する:集計条件を変えるなど、小さな仕様変更に対応できるか試し、コードとテストで確かめます。
- 原因を追う:エラーや想定と違う結果が出たとき、どこから調べるかを確認します。
AIの説明を読んで納得するだけでなく、自分で手を動かして確かめることが大切です。生成で短縮できた時間の一部を、読むこととレビューに回すとよいでしょう。
Anthropicの実験では、新しい技術を学んだ直後の理解度に差が出ました
Anthropicの研究者 Judy Hanwen Shen さんと Alex Tamkin さんは、主にジュニアの開発者52人を対象に、未経験のPythonライブラリを使った課題に取り組む実験を行いました。同社の解説(2026年1月29日)では、作業後の理解度クイズの平均はAIを使った群が50%、自分で書いた群が67%と報告されています。特に差が大きかったのは、コードの誤りを見つけ、原因を調べる問題でした。
ただし、少人数が特定の課題を学んだ直後の成績です。長期的な技能の変化や、職場での障害対応力をそのまま示す数字ではありません。コードを完成させられたことと、その仕組みを理解できたことは、分けて確かめる必要があります。
同じ実験のやりとりの分析では、AIにコード生成だけを任せる使い方と、説明や概念への質問を交えて理解を確かめる使い方で、成績に違いが見られました。ただし、この使い方別の分析は、特定の質問方法が成績を改善したという因果関係まで示していません。自分の理解を確かめる工程を残すための手がかりとして読めます。
補足:言葉の由来と、似た「負債」との違い
英語で確認できる早い用例には、Jason GormanさんのCodemanship(2025年9月30日)があります。Addy Osmaniさんの記事(2026年3月14日)も、コードの量と人の理解との間に広がる差として説明しています。日本語では@IT(2026年3月12日)などが紹介しましたが、日本語の造語者は特定できません。
技術的負債は、コードの構造などに由来する変更しにくさとして現れます。一方、理解負債は、人がコードを理解していないことに焦点があります。コードがきれいに動いていても、人が読み、理解し直す必要は残ります。
関連する認知的負債は、MITメディアラボのKosmynaさんらのプレプリント(2025年6月投稿)でも論じられています。ただし、これはAIを使ったエッセイ執筆と記憶・認知的な関与の研究であり、ソフトウェア開発の理解を直接測ったものではありません。また、AIの答えを吟味せずに受け入れる認知的降伏は、一回ごとの判断に着目した考え方です。関連はありますが、同じ意味として扱わないようにします。
よくある質問
理解負債と技術的負債はどう違いますか?
技術的負債はコードそのものに宿り、変更しにくさやバグとして開発者に摩擦を感じさせます。理解負債はコードの量と人の理解の差で、コードがきれいに動いていても溜まります。一見すると問題がないため、気づくのが遅れやすい点が厄介です。
エンジニアでなくても関係がありますか?
語が生まれたのはソフトウェア開発の文脈です。ほかの仕事でも、AIが作った資料の根拠や分析の手順を説明できるかを確かめることは役立ちます。ただし、開発者の実験結果を、そのまま別の職種の理解度に当てはめることはできません。
AIを使った人はみな理解度が下がるのですか?
そうとは限りません。Anthropicの実験では群の平均に差がありましたが、AIを使いながら高い成績を示した参加者もいました。AIが書いたものを受け取るだけで終えず、自分で説明や修正ができるかを確かめることが大切です。
和からの生成AI研修では、AIの出力を業務で確かめながら使う方法を扱っています。
<監修/和から株式会社 堀口智之>
同じことを生成AIに頼むなら、どう書けば思ったとおりに返ってくるのか。そのまま貼って使える「話しかけ方」を30個、A4・7ページにまとめました。資料づくり・メール・数字の整理・学び直しの、4つの場面別です。
和からのメルマガに登録すると、この資料を含む3本をまとめてお送りします。登録はメールアドレスだけ、30秒で終わります。
新着記事
同じカテゴリーの新着記事
同じカテゴリーの人気記事
この記事に関連する教室: 数学教室 → 社会人の学び直し講座 →







