AI 支援開発における負債のファミリー

この wiki の 8 つのページは、AI 支援開発やエージェント型のソフトウェア開発において蓄積するとされる一種の「負債」に名前を付けている。検証負債、認知的負債、理解の負債、信頼の負債、ガバナンスの負債、プロンプトの負債、高速統合の負債、来歴の負債である。このうち 4 つは 1 本の多声的文献レビュー（multivocal literature review）であるより速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビューに由来する。残りの 4 つは、Koch による統合論文、Addy Osmani の講演と記事、学部生のソフトウェア工学プロジェクトの研究、そしてある著者のコラムの初回に由来する。このページでは、8 つに繰り返し現れる形と、それらが食い違うところを説明する。用語に順位をつけることはせず、どれかについてどの名前が正しいかを決めることもしない。

8 つのケース

用語	wiki のどこに記録されているか	何が蓄積するとされるか	誰の帳簿に載るか
検証負債	Koch、Agentic Agile-V: ソフトウェアおよびハードウェア開発におけるバイブコーディングから検証済みエンジニアリングへ	弱いテスト、隠れた回帰、広範なパッチ、検証されていない依存関係、文書化されていない振る舞い、レビュアーの負担増	チームの未検証の出力とレビュー負荷
認知的負債	Osmani の基調講演「Own the Outer Loop」、並列エージェントに関する別の記事、理解の負債：AI 生成コードの隠れたコスト	問題をどう解くかについてのエンジニア自身の理解の侵食	個々のエンジニア
理解の負債	生成 AI 支援によるソフトウェアエンジニアリングプロジェクトにおける理解の負債	チームがコードベースについて知っていることと、それを保守するために理解している必要があることとのギャップ	チームの集合的な認知（コードではないと明示されている）
信頼の負債	「バイブコーディング」をやめ、新世代のソフトウェアエンジニアリングを受け入れよう	信頼に値することを誰かが確かめられるより速く出荷されるコード	コードについて誰も確かめていないこと
ガバナンスの負債	より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビュー	ハルシネーションと非決定性によって生じる、取り込まれた LLM 出力に対する継続的な監督の負担	マージで終わらない監督
プロンプトの負債	より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビュー	再現性とコード品質を低下させる、不明瞭で影響を受けやすい、あるいは文書化されていないプロンプト	コードを形作るのにコードのようには管理されないプロンプト
高速統合の負債	より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビュー	適切な検証なしに統合された LLM 出力	採用の速さと評価の速さのギャップ
来歴の負債	より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビュー	生成されたコードの不明確な所有権や帰属表示の欠如	欠けている記録（法的な問題や説明責任の問題として表面化する）

同じレビューは、さらに 2 つの新たなカテゴリとしてデータの負債（data debt）と倫理的負債（ethical debt）を挙げている。どちらもこの wiki に独自のページがないため、8 つには数えていない。

繰り返し現れる形

一方の速度が他方を上回る

8 つのうち 4 つのページは、仕組みを速度の不一致として記述しており、生成や採用の側が速い側にある。

検証負債 — 出力量が検証能力より速く増えると、チームはこれを蓄積する。
信頼の負債 — エージェントが生成するコードの速さが、そのコードが信頼に値することを確かめる能力を上回る。生成がボトルネックでなくなると、人間の注意力とレビューの帯域幅が制約となる。
高速統合の負債 — 問題は、LLM の出力を採用できる速さと、開発者がその下流への影響を評価できる速さとのギャップから生じる。
認知的負債 — 並列エージェントに関する記事では、人が理解できるより速くエージェントに生成させると負債が蓄積し、それがスレッドをまたいで複利的に膨らむ。理解の負債：AI 生成コードの隠れたコストは同じ非対称性を逆転として述べている。ジュニアエンジニアが、シニアエンジニアが批判的に監査できるより速くコードを生成できるようになったというのである。

残りの 4 つは、2 つの速度の競争としては捉えられていない。理解の負債は、ギャップの原因を AI ツールが認知負荷を下げることに求めている。その結果、作業をする中で築かれたはずの理解が築かれない。ガバナンスの負債はモデルの性質、すなわちハルシネーションと非決定性に基づいており、これらによって監督は一度きりのコストではなく継続的なものになる。プロンプトの負債は 2 種類の成果物の扱われ方の不一致を名指しし、来歴の負債はコードがどこから来たかの記録の欠如を名指ししている。

通常の技術的負債との対比による定義

根拠となるページのうち 4 つは、用語を部分的に従来の技術的負債との違いによって定義しており、それぞれが異なる場所に線を引いている。

理解の負債 — コードベースではなく、チームの集合的な認知の中に存在する。
理解の負債：AI 生成コードの隠れたコスト — 技術的負債は積み重なる摩擦を通じて自らの存在を知らせ、通常は場所のわかった意識的なトレードオフである。これに対して理解の負債は、コードがきれいに見え、テストがグリーンであるために、誤った自信を生む。
高速統合の負債 — 問題は特定の成果物の品質からではなく、採用と評価のギャップから生じる。
来歴の負債 — コードの負債は保守の摩擦として表面化するが、これは法的な問題や説明責任の問題として表面化する。

ガバナンスの負債は別の線を引いている。取り込まれた出力に対する監督の負担に範囲を限定し、従来の技術的負債からではなく、AI・ML システムにおける技術的負債に関する既存の文献から意図的に切り離している。

後になって現れるコスト

根拠となる 4 つのページ（8 つの用語ページのうち 3 つと Osmani の記事）は、コードが取り込まれた時点ではコストが見えないことを強調している。

高速統合の負債 — ある実務者の報告では、スプリント中はベロシティの指標が非常に良く見えていたが、バグ報告は数週間後に、AI が考慮していなかったエッジケースで届いた。
ガバナンスの負債 — その決定的な特徴は、負担がマージで終わらないことである。
来歴の負債 — コストは、あるロジックについて誰が責任を負うのか、あるいはどのような条件で配布してよいのかを誰かが確定する必要が生じる時点まで先送りされる。
理解の負債：AI 生成コードの隠れたコスト — 清算の時が来るまで、コードベースはきれいに見え、テストはグリーンである。

測定されていないと明言されている

8 つのうち 4 つのページは、自らが名指す負債が測定されていないことを明言している。

検証負債 — Koch はこれを直接測定する方法を示しておらず、証拠バンドルでこれを減らせるかどうかを未解決の問いとして挙げている。
信頼の負債 — 1 人の著者による捉え方であり、負債の測定も、それを観察する方法も示されていない。
高速統合の負債 — グレー文献から帰納的に特定されたもので、測定ではなく実務者の報告に依拠している。
ガバナンスの負債 — 測定されたものではなく、実務者の情報源から帰納的に導かれたものである。

より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビューは一般的な状況を述べている。調査した 2 つの文献群のいずれにも、LLM が生成したコードの技術的負債を評価するための標準化されたベンチマークやデータセットは含まれていなかった。理解の負債：AI 生成コードの隠れたコストは実務の観点から関連する主張をしている。ベロシティの指標、DORA メトリクス、PR の数、カバレッジがすべて健全に見える一方で、理解の不足は見えないままでありうるというのである。

残りのページは、負債そのものの測定には触れずに、別の種類の証拠を報告している。認知的負債は、AI を介して作業したエンジニアが理解度クイズで 50% の得点だったのに対し、そうでないエンジニアは 67% だったというランダム化試験を引用している。理解の負債は、学部生のプロジェクトで観察された 4 つの蓄積パターンを記述している。プロンプトの負債は、よく構造化された具体的なプロンプトが、観察されたコードスメルの最大 87.1% を緩和したという研究を報告している。そして来歴の負債は、レビューの 104 の情報源のうち、1 つのフォーマルな情報源と 1 つのグレーな情報源に依拠している。

ケースが食い違うところ

「理解の負債」と呼ばれる 2 つの概念

同じ名前が 2 つの異なる概念に付けられている。Osmani の用法、すなわち存在するコードの量と、そのうち人間が理解している量とのギャップは、認知的負債に記録されている。彼の基調講演はこれを認知的負債と呼び、並列エージェントに関する記事は同じ力学を理解の負債（comprehension debt）と呼び、理解の負債：AI 生成コードの隠れたコストもこれに「理解の負債」（comprehension debt）という語を用いている。理解の負債は、学部生のプロジェクトの論文で提案された用語であり、チームの集合的な知識がコードベースの保守に必要なものに届かないことを指す。前者はエージェントに委任するエンジニアを中心に捉えられ、後者は生成 AI ツールを採用するチームを中心に捉えられている。理解の負債は認知的負債を関連用語として挙げており、どちらのページも両者を 1 つの概念としては扱っていない。

負債がどこに抱えられるか

8 つは、負債が誰の帳簿に載るかについて異なる。認知的負債はそれを 1 人のエンジニアに置き、理解の負債はチームに置く。検証負債は出力とレビュー負荷に、プロンプトの負債はコードに適用される管理の下にない入力に、来歴の負債は存在しない記録に置く。信頼の負債はコードについて誰も確かめていないことに置き、ガバナンスの負債はコードがマージされた後も続く監督に置く。

用語の裏付けの強さ

より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビューに由来する 4 つの用語には情報源の数が付いており、その数は大きく異なる。ガバナンスの負債は 19 のグレーな情報源に現れ、フォーマルな情報源には現れない。高速統合の負債は 13 のグレーな情報源に現れ、フォーマルな情報源には現れない。プロンプトの負債は 8 つのフォーマルな情報源と 5 つのグレーな情報源に現れ、フォーマルな文献における LLM 特有の負債の主要な源泉と報告されている。来歴の負債は 1 つのフォーマルな情報源と 1 つのグレーな情報源に現れる。残りの 4 つの用語は、いずれも 1 人の著者または 1 つの研究による捉え方に依拠している。検証負債は統合論文、認知的負債は基調講演と記事、理解の負債は学部生のプロジェクトの研究、信頼の負債はコラムの初回である。

1 つの因果関係

根拠となるページで用語間の因果関係が述べられているのは 1 つだけである。より速いコード、より深い負債？ LLM 支援ソフトウェア開発における技術的負債とその初期兆候に関する多声的文献レビューはドミノ効果を記述しており、そこでは高速統合の慣行が、管理されないまま放置されると連鎖的なガバナンス上のリスクを引き起こす。高速統合の負債とガバナンスの負債が伝えるところでは、高速統合によって監督を要するコードが増え、それがガバナンスの負債となり、さらに長期的な保守コストの増大につながる。他のページは、自らの用語を近隣の用語と関連概念としてしか関係づけていない。たとえば信頼の負債は、検証負債を未検証の出力に伴うすぐ隣のコストとして挙げているが、因果の順序は述べていない。

各情報源が対応として提案するもの

各用語に付けられた対応策は、それぞれが負債をどこに置くかに応じて、種類が異なる。

高速統合の負債 — ヒューマン・イン・ザ・ループのモデル。レビューの 73 のグレーな情報源のうち 58 で推奨されており、LLM の出力をレビューと改良を要する下書きとして扱う。
ガバナンスの負債 — 継続的な開発者の研修、コードベースへの AI の関与の文書化、長期的な保守性の優先。これにコード品質ツールと多層的なレビューが加わる。
検証負債 — Agentic Agile-V のリスク適応型ゲートと証拠バンドルによる、リスクに見合った証拠に基づく受け入れ、そしてテストをエージェントのループの内側に保つこと。
理解の負債 — コードの変更ではなく実践。検証の実践、構造化された振り返り、能動的な学習評価である。
プロンプトの負債 — プロンプトを永続的なものにすること。テンプレート、構造化されたプロンプト、プロンプトのレジストリ、バージョン管理された文書化である。
来歴の負債 — コードがどこから来たかを問う来歴レビュー。これにガバナンスのチェックとプロンプトの文書化が加わる。
信頼の負債 — 信頼エンジニアリング。AI 時代のための 3 次元の部品表（bill of materials）が、コラムの後の回の主題として挙げられている。
理解の負債：AI 生成コードの隠れたコスト — 代替手段はない。この記事は、テストも仕様もそれぞれ理解の代わりとしては上限があり、理解する作業こそが仕事であると論じている。

ai-driven-dev-wiki

Explorer