AIに頼めば、コードは一瞬で出てくる。動く。テストも通る。「いける」と思って次に進む。だがその裏で、静かに積み上がるものがある。理解負債（comprehension debt）だ。
この言葉を定式化したのは、GoogleのエンジニアリングリーダーAddy Osmaniだ。彼はこれを、システムに存在するコードの量と、人間が本当に理解している量との差が、広がっていくことと定義した。AIを使えば、コードの「総量」は一気に増える。だが、あなたが「理解している量」はそのスピードで増えない。そのギャップが、負債だ。
技術的負債より、たちが悪い
技術的負債は有名な概念だ。だが理解負債は、もっと厄介だ。
なぜなら、技術的負債は「借金がある」と自覚できる——ビルドが遅い、コードが汚い、といった摩擦で、自分から姿を見せる。ところが理解負債は「借金に気づかない」。コードは綺麗に見え、テストは緑で通り、見た目は何も問題がない。Osmaniはこれを「偽りの自信（false confidence）」と呼ぶ。破綻は、いちばん悪いタイミングで、静かにやってくる。
実際、AIに「丸投げ」した学習者は理解度が下がる、という研究も出ている（AIを“チューター”として使い、なぜそうなるかを説明させた人は、理解度が保たれた）。「Accept All」でAI生成の差分を読まずに承認し続けた結果、自分が作ったはずのプロダクトが「他人の家」になり、どこに何があるか分からなくなった——そんな体験談も珍しくない。
本質は「プロダクトの地図」
理解負債とは、つまりあなたの頭の中にある「プロダクトの地図」の精度に関する負債だ。
地図が狂うと、何が起きるか。AIに正確な指示が出せなくなる。指示が不正確なら、出力も不正確になる。それを受け入れると、地図はさらに狂う。負のスパイラルだ。「70%の罠」で残り30%にハマるのも、この地図を失っているからだ。
でも、理解負債は「悪」ではない
ここが大事なところだ。理解負債そのものは、悪ではない。プロトタイプ、検証フェーズ、スピード最優先の場面では、意図的に負債を背負うのは合理的だ。
問題なのは、2つだけ。「負債を負っている自覚がないこと」と、「返す計画がないこと」。だから、ゼロにするのではなく、コントロールする。
PdMが地図を失わない3つの習慣
コードを「書く」必要はない。コードの「地図」を持っていればいい。そのための3つ。
- 「理解していない」を可視化する。 分かっていない箇所に「※AI生成・未理解」と印を残す。事実を見える化するだけで、負債は管理可能になる。
- 「作る」と「理解する」を分ける。 実装が終わったら、別フェーズでAIに「この処理を中学生に説明して」「壊れやすい箇所はどこ?」と聞く。作るプロンプトと、理解するプロンプトを分けるのが効く。
- 全部は理解しようとしない。 コアロジックは理解する。周辺の細部はブラックボックスで構わない。理解にも優先順位をつける。
AIは強力な武器だ。だが武器だけで防具を持たずに進むと、どこかで致命傷を負う。動くものを作る速さ（武器）と、地図を持ち続ける習慣（防具）。 この往復ができるPdMが、AI時代に強い。
同じテーマのナレッジや、すぐ使える無料テンプレもどうぞ。