認知負債：AI時代に再浮上した技術的負債の人間側の問題
概要¶
生成AIがコードを大量生成することで「理解せずにリリースする」構造が加速している。この現象は技術的負債と同じ構造を持つため「認知負債」と呼ばれる。Storeyの3層モデルが示す通り、人間側の問題は「チームの共有理解（認知負債）」と「外部化された知識（意図負債）」に分かれる。AI以前から存在する問題だが、AIで速度・量・所有不在の度合いが増幅された。
詳細¶
Storeyの3層モデル¶
| 種類 | 宿る場所 | 問題 |
|---|---|---|
| 技術的負債 | コード | コードの保守性の低下 |
| 認知負債 | 人間・チーム | 共有理解が劣化する |
| 意図負債 | 外部化された知識 | 何のためか分からない |
この区別が重要な理由：AIエージェントに渡せるのは人間の暗黙知ではなく、仕様・ADR・テスト・設計メモ・チケット・ドキュメントだけだから。
認知負債 vs 意図負債の違い¶
// このコードを見たとき
if (customer.isCorporate() && order.totalAmount().compareTo(limit) > 0) {
requireManualApproval(order);
}
コードは読んで理解できる（認知負債ではない）
しかし、「なぜ」がわからない：
→ 法規制によるものか？
→ 社内統制か？
→ 過去障害の再発防止か？
→ 大口顧客向け例外か？
→ もう不要なのか？
→ これは「意図負債」。対策はADRやドメイン制約を残すこと
AIが変えた3つのこと¶
1. コード変更の速度と量の増加¶
Della Porta et al. の分析（302,600件のAIコミット・6,299リポジトリ）:
- AI書いたコミットの15%以上が少なくとも1つの問題を導入
- AI由来問題の22.7%が最新リビジョンまで残存
→ 正確性とセキュリティの観点では「AI生成の問題 > AI修正の問題」
2. メンタルモデルの形成が阻害される¶
Anthropic "How AI Impacts Skill Formation":
単純委任グループ → 新しいライブラリの理解度クイズが17%低下
概念質問・説明要求に使ったグループ → 学習が保たれた
Carmack: 「コピペするときでも自分の手で打て」
→ Naur 1985 "Programming as Theory Building" と同じ筋
→ 実作業を通じて理論（theory）が形成される
3. 責任の所在が曖昧になる¶
AI時代の対策¶
認知負債側¶
1. AI生成の各変更を出荷前に少なくとも1人が完全に理解する
→ 「テストが通ればLGTM」でコードレビューを終わらせない
2. コードオーナーシップを維持する
（Bird et al. 2011: 所有不在コードは障害と最も強く相関する）
3. コードレビューを「欠陥検出」ではなく「知識移転」として運用する
（Bacchelli & Bird 2013 の実証）
4. バス係数を測定する
（Git リポジトリから自動計算可能）
意図負債側¶
- ADR (Architecture Decision Records) の記録
- ユビキタス言語（Evans 2003）
- Living Documentation
- アーキテクチャ適応度関数
AIで認知負債を「解消」しようとする罠¶
「AIで認知負債を作った人が、
その負債を直すテストや設計文書もAIに書かせる」
→ エージェントが効率的に動くためにはなっても、
人間の認知負債そのものは解消しない
Bainbridge 1983 "Ironies of Automation" の現代版:
自動化で人間に残るのは「自動化できなかった残余」
→ 最も負荷が高く曖昧なタスクが残る
→ 監視役に回るとスキルが萎縮
→ 介入が必要な瞬間に最も準備がない
「認知負債」という語の問題点¶
Stepanov 批判: 「すべてがオブジェクトなら、何もオブジェクトではない」
同様に:
ドキュメント不足・オンボーディング失敗・アーキテクチャ理解の欠如・
テスト不足・レビュー疲労を全部「認知負債」と括るのは概念を空洞化させる
→ 「認知負債（チームの共有理解）」と「意図負債（外部化された知識）」に
分けて使うことが重要
なぜ重要か / いつ使うか¶
- AIコーディングエージェントを導入するチームの開発プロセスを設計するとき
- コードレビューの文化や目的をチームに説明するとき
- 「AIでコードが書けるのになぜオーナーシップが必要か」を議論するとき
- ADRやドキュメントの書き方・残し方を整備するとき
- 「認知負債」「意図負債」という言葉の定義をチームで統一するとき