「意図負債」という言葉ができるまで

1985年、Peter Naurは「Programming as Theory Building」という短い論文を発表した1。主張は率直だ。プログラムとは書かれたコードそのものではなく、それを書いた人間の頭の中にある理論だという。コードやドキュメントは、その理論から派生した不完全な副産物にすぎない。理論を持つ人がチームを離れれば、コードは動き続けていても、誰もそれを修正できなくなる。Naurはこの状態をプログラムの「死」と呼んだ。

41年後の2026年7月24日、t-wada（和田卓人）氏が公開した資料「2026年のソフトウェア開発を考える」rev.31に、この論文への言及がある2。ここで語られているのは、AIコード生成の普及によって速度と理解が乖離し、開発者が書いたコードの理論を自分の頭の中に持たないまま次のコードが積み上がっていく状態だ。資料はこれを認知負債と呼び、さらにMargaret-Anne Storeyらの論文（arxiv:2603.22106）を引きながら、理解不足そのものを指す部分と、開発者の意図が反映されない部分とを分けている。後者が意図負債である。

Ward Cunninghamが定義した技術的負債

「技術的負債」という比喩を最初に使ったのはWard Cunninghamで、1992年のことだ3。その比喩では、人間がその時点の理解でコードを書き、あとで得た学びをコードに反映し損なうと利子が積み上がる。人間の理解が先にあり、コードがそれに追いつこうとして追いつけない構図だ。

認知負債は、この構図を裏返す。AIがコードを先に生成し、人間の理解がそれに追いつこうとして追いつけない。負債の発生源が、人間側からコード生成側に移った形になる。t-wada氏の資料はこの反転を対比として明示しており、同じ「負債」という言葉を使いながら、原因の向きが逆になっていることを指摘している点に意味がある。

資料はもう一つ、見過ごしにくい指摘をしている。技術的負債はコードの品質として目に見えるが、認知負債は見えない。設計を理解していなくてもDORAメトリクスは上げられてしまうため、生産性を上げたい組織と、それに応えたい個人のあいだで、理解を飛ばしたまま数字だけを積み上げる構造ができてしまう、という趣旨だ。

これは、PRレビューツールParryが立てている問いそのものでもある。Parryは「confirm, don't write」、つまりAIが書き、人間が確認するという設計思想を取り、PR作成時にWhy（なぜこの変更か）、Risk（影響範囲）、Confidence（自信度）、Context（背景）という4項目を必須入力にしている。埋めなければレビューという次の工程に進めない。この資料が公開されたのはParryの開発が始まって間もない時期であり、Parryが構造として防ごうとしている負債に、資料はすでに名前を与えていたことになる。

意図負債はいつから存在したか

意図負債という言葉を最初に見たとき、これはAIコード生成という2026年固有の現象から生まれた、新しい種類の問題だろうと考えた。人間より先にコードが存在する状況自体、数年前までは珍しかったからだ。

だが系譜を遡ると、この理解は精緻化を要する。Naurが1985年に書いたのは「コードは理論であり、理論を保持する人がいなくなれば負債化する」という構造そのものだった。AIの有無は、理論を保持する人がいなくなる速度を変えているにすぎない。以前は退職や異動という数ヶ月単位の出来事で起きていたことが、いまはコードが生成された次の瞬間に起き得る。意図負債は新しい問題ではなく、41年前に名指しされていた構造が、発生周期を数ヶ月から数秒に縮めて再来したものと見るほうが正確だ。

blog-prod-postsでの検証

この構造を、自分の手元でも確認できた。blog-prod-postsリポジトリで、frontmatterのstatusフィールドを確認したところ、mainブランチにマージ済みの記事のうち4本がstatus: draftのまま放置されていた。もっとも古いものは6月28日に追加された「このブログがどうやって公開されるか」で、直近では7月26日の「なぜ自力実装は続かないか」まで、1ヶ月以上にわたって同じ状態が積み重なっていた。

git履歴を見れば、いつ誰がマージを承認したかは追える。だが「なぜこの記事を公開可能と判断したか」という理論は、コミットログには残らない。それは判断した瞬間の頭の中にしかなく、statusフィールドという運用上の状態に反映されて初めて、あとから見た人が意図を復元できるようになる。今回はそこが更新されないまま積み上がった。マージした判断そのものは正しかったのだろうが、その判断を後から読み取るための手がかりが、コードの外側に残されていなかった。まさにNaurの言う、理論を保持する人が離れたあとに残る「動くが直せないコード」の、記事管理版だった。

ここまでで検証できていないこと

意図負債という言葉が、Tech Debt Conferenceで正式な用語として定着するのかどうかは、まだ分からない。そしてParryの4項目が、この記事で確認したような「意図はあったが記録されなかった」ケースを実際に防げるのかも、Parry自身の運用実績としてはまだ検証していない。今回見つかった4本のdraft放置は、Parryのレビューフローを通過した記事群の話であり、4項目を埋めることと運用状態を正しく保つことは、別の負債として切り分けて見ていく必要がありそうだ。

Footnotes

  1. Peter Naur, "Programming as Theory Building" (1985)。「プログラムとは書いた人の頭の中の理論である」という主張で知られる。 ↩

  2. t-wada「2026年のソフトウェア開発を考える」rev.31（AI DevEx Conference 2026 Findy Edition、2026-07-24公開）。スライド画像主体の資料のため、本文中の引用は取得できた範囲の要約に基づく。 ↩

  3. Ward Cunningham, "The WyCash Portfolio Management System" (OOPSLA 1992 experience report)。技術的負債という比喩の初出とされる。 ↩