認知負債
生成AIがプロンプトからコードを大量に生成してくれるので、出力されたものを理解する時間と引き換えに早くリリースする。この構造は技術的負債と同じなので「認知負債」と呼ばれることがある。
Margaret-Anne Storey が AI 時代のソフトウェア健全性を技術的負債・認知負債・意図負債の3層で整理している
Addy Osmani は AI 生成コードでこのギャップが急拡大する現象を「理解負債」と呼ぶ
Thoughtworks Technology Radar では "コードベースの認知負債" を Caution に分類している
認知負債と意図負債を分ける
Storey の3層モデルの肝は、コード側の問題 (技術的負債) と人間側の問題を分けただけでなく、人間側をさらに「人の頭の中」(認知負債) と「外部化された知識」(意図負債) に分けたことにある。
table:table
種類 宿る場所 問題
技術的負債 コード コードの保守性の低下を招く
認知負債 人間・チーム 共有理解が劣化する
意図負債 外部化された知識 何のためか分からない
この区別は、AIエージェントに渡せるのが人間の暗黙知ではなく、仕様、ADR、テスト、制約、設計メモ、チケット、ドキュメントだけだから重要になる。たとえば次のコードがあったとき、
code: (java)
if (customer.isCorporate() && order.totalAmount().compareTo(limit) > 0) {
requireManualApproval(order);
}
コードは読んで理解できるが、
法規制によるものか
社内統制か
過去障害の再発防止か
大口顧客向け例外か
一時的な運用回避か
もう不要なのか
はがわからない。コードは理解できているのに変更判断ができない。これは認知負債ではなく意図負債の症状で、対策はチームの共有理解を立て直すことではなく、ADR やドメイン制約を残すことになる。
意図負債の本体は「ドキュメントを書いていない」ことではなく、事業目的・業務ルール・設計判断・制約・テスト・コードの鎖が切れていることにある。テスト名が test_case_17 で期待値だけ固定されているなら、テストはあっても意図はない。ADR があってもコードと接続していなければ機能しない。AI 生成では、アイデアがチケットに圧縮され、プロンプトに圧縮され、コードに変換される過程で文脈が失われる (Forkzero はこれを「ツールの問題ではなく翻訳の問題」と呼んでいる)。
認知負債は何を指すか、を切り分ける
「認知負債」という語の最大の問題は、抽象が広すぎて何でも指せることにあり、StoreyのブログについてのHacker Newsスレッドでも様々な議論が展開されている。
jdw64 は、ドキュメント不足・オンボーディング失敗・アーキテクチャ理解の欠如・テスト不足・レビュー疲労を全部「認知負債」と括るのは、Stepanov の「すべてがオブジェクトなら、何もオブジェクトではない」と同じだと批判している。
同じ拡散は技術的負債自身でも起きていた。Kruchten, Nord, Ozkaya 2012 が「比喩は引き伸ばしすぎると有用な性質を失う」と書いたとおり、技術的負債は当初の「短期的に意図して取った近道」から、コードスメル一般・古いライブラリ・テスト不足まで何でも指す語に膨張した。Tom, Aurum, Vidgen 2013 はこの拡散を multivocal literature review で整理した。認知負債も同じ道をたどっている。
生成AI以前から「認知負債」は存在し、いくつかの研究系譜を持つ。
プログラム理解: von Mayrhauser & Vans 1995 の統合メタモデル (Integrated Metamodel) を中核とする系譜
transactive memory の喪失: Wegner 1986 の理論を組織研究へ拡張した系譜
バス係数: Cosentino et al. 2015、Avelino et al. 2016、Jabrayilzade et al. 2022 の自動測定研究
architectural knowledge vaporization: Capilla et al. 2019 を中心とするアジャイル分散開発文脈の研究
認知負債の対策
問題を切り分けると、AI 以前から積み上がってきた研究で答えが出ているものが多い。
コードレビューを欠陥検出ではなく知識移転として運用する: Bacchelli & Bird 2013 の Microsoft でのフィールド研究は、レビューの主目的は申告では欠陥検出だが、実際には知識移転・チーム認識共有・代替案検討の比重が大きいと示した。AI 生成コードのレビューが「テストが通れば LGTM」になると、この実証された効果が消える。
コードオーナーシップを維持する: Bird et al. 2011 は Windows Vista/7 で、寄与の少ないコントリビュータの数がリリース前後の障害数と最も強く相関することを示した。Greiler et al. 2015 と Thongtanunam et al. 2016 が再現研究で確認している。HN の Ozzie_osman が「解はオーナーシップだ」と言うのはこの実証と整合する。一方で scorpioxy が指摘するとおり、オーナーシップは人を交換可能でなくするので、経営側からの圧力で押し戻されやすい。「AI で人を交換可能にできる」という幻想が、オーナーシップ文化を遠ざける。
新人オンボーディングに社会的支援を入れる**: Begel & Simon 2008 は Microsoft 新人を6ヶ月追跡し、技術より社会・コミュニケーション側の準備不足がオンボーディング苦痛の主因だと示した。AI が増えてもオンボーディングの苦痛は減らない。
バス係数を測定する: Cosentino et al. 2015 以降、バス係数は Git リポジトリから自動計算できる測定可能な指標になっている。
コンウェイの法則を逆手に取る: Colfer & Baldwin 2016 は、組織の結合度がアーキテクチャの結合度に反映されるというミラーリング仮説に強い実証を示している。チーム設計が認知負債のしやすさを決める。
意図負債側に対しては、以下のようなものが対策として挙げられる。
ADR (Nygard 2011)
ユビキタス言語 (Evans 2003)
Living Documentation (Martraire 2019)
アーキテクチャ適応度関数 (Ford, Parsons, Kua 2017)
AI が変えたのは何か
コード変更の速度と量が上がった。Della Porta et al. は AI が書いたコミット302,600件、6,299リポジトリ、5つの AI アシスタントを分析し、AI が書いたコミットのうち各ツールで15%以上が少なくとも1つの問題を導入し、AI 由来問題の22.7%が最新リビジョンまで残存していたと報告している。正確性とセキュリティの観点では、AI による問題の導入数が修正数を上回る。生成は速いが、レビューと検証はそのままなので、未理解のコードが残存する。
生成過程で形成されるはずだったメンタルモデルが形成されなくなった。Anthropic "How AI Impacts Skill Formation" は、AI に単純委任した参加者が新しいライブラリの理解度クイズで17%低下したと報告している。一方、AI を概念質問や説明要求に使ったパターンでは学習が保たれた。HN の techpression が引いた Carmack の「コピペするときでも自分の手で打て」は、Lave & Wenger 1991 の状況的学習 や Naur 1985 "Programming as Theory Building" と同じ筋にある。実作業を通じて理論 (theory) が形成されるのであって、レビューや説明では代替できない。
責任の所在が曖昧になった。AI は下請けのように振る舞うが契約相手 (counterparty) ではない。EU AI Act 第14条 が高リスク AI に「自然人による効果的な監督」を義務づけているのも、Jensen & Meckling 1976 のプリンシパル・エージェント問題 がそのまま当てはまらないのも、AI が結果に対する持ち分 (skin in the game) を持たないからだ。境界・契約で扱う (NIST IR 7417 や COBie のような引き渡しプロトコルの体系化は実在する) としても、境界の人間側に責任主体を明示的に置く必要がある。
出力量を生産性指標とする圧力が強まった。グッドハートの法則 が予言するとおり、コード行数・PR数・ベロシティを目標化すると指標としての意味を失う。Storey 自身が共著者の SPACE 論文 (Forsgren et al. 2021) は、コミット数・PR数・コード行数のような単一の活動量メトリクスを生産性指標にする運用を明示的に批判している。HN の carbonguy と darth_avocado が指摘するように、対策は既知でも、それを実行するインセンティブが組織側にも個人側にもないことが、AI 時代に顕在化している。
AI を緩和に使うときの注意
Storey は緩和策として「AI を使ってプラクティスのコストを下げる」案を挙げているが、HN の CobrastanJorji はこれに懸念を表明している。AI で認知負債を作った人は、その負債を直すテストや設計文書も AI に書かせる。エージェントが効率的に動くためにはよくても、人間の認知負債そのものは解消しない。
これは Bainbridge 1983 "Ironies of Automation" が40年前に定式化した自動化の逆説の現代版にあたる。自動化で人間に残るのは「自動化できなかった残余」であり、最も負荷が高く曖昧なタスクが残る。監視役に回るとスキルが萎縮し、介入が必要な瞬間に最も準備がない、というのが Bainbridge の核である。Lee et al. 2025 (CHI 2025) は生成AIへの信頼が高いほど批判的思考の発揮が減退することを実証している。AIに成果物作成を委ねるほど、人間側の検証努力は減る。
AI時代の対策
Storey
AI 生成の各変更を、出荷前に少なくとも1人の人間が完全に理解することを要求する
「何が変わったか」だけでなく「なぜ変えたか」をドキュメント化する
コードレビュー、ふりかえり、知識共有セッションで、チームが共有理解を再構築する
Thoughtworks Radar
コーディングエージェント向けフィードバックセンサー (Feedback sensors for coding agents) (Trial): エージェントがアクセスできるフィードバックループを置き、人間レビュアーの負荷を下げる。コンパイラやリンターのような決定論的な品質ゲートをエージェント型ワークフローに統合し、失敗時にはエージェントが自己修正する。具体例は専任のレビュー用エージェント、並列で走るチェックをエージェントが問い合わせる仕組み、コミット前にセッション内で清浄性を確認する仕組みなど。Birgitta Böckeler の Harness engineering for coding agent users が概念の原典で、センサーを決定論的な「計算的 (computational)」(eslint、semgrep、coverage、dep-cruiser、ミューテーションテスト) と「推論的 (inferential)」(LLM-as-judge、AI コードレビュー) に分類している
チーム認知負荷 (Team cognitive load) (Adopt): Skelton & Pais の『チームトポロジー』 に基づく組織設計の指標。ストリームアラインド・プラットフォーム・イネイブリング・コンプリケイテッドサブシステムの4チーム型と3つの相互作用モードで組織を設計し、各チームがビルド・テスト・運用にどれくらい困難を感じるかを測る
アーキテクチャ適応度関数 (Architectural fitness function) (Trial): Ford, Parsons, Kua の『進化的アーキテクチャ』 が原典。アーキテクチャ特性を単体テスト・メトリクス・モニターで客観的に整合性チェックし、自動的・継続的に保護する
VirtusLab
AI が一括生成した機能を小さく原子的な変更に分割し、個別に理解する
動かなかったものを頻繁にロールバックする
疎結合なアーキテクチャと高速なフィードバックを持つチームは AI からの生産性向上を得やすい
Osmani は逆方向に、「詳細な自然言語仕様を先に書き、PR では仕様をレビューする」処方箋をウォーターフォールの再来として批判している。仕様から実装への翻訳には依然として暗黙の判断が含まれるから、事前仕様を書けばよいという単純解は成立しない。
複数の論者にまたがって出てくるのは、「なぜ」を残すこと、AI 出力を全受容も全拒否もせず小さく分けて検証すること、設計制約を機械可読な形にすることの3つで、いずれも前節で挙げた既存の対策と整合する。
まとめ
「認知負債」はAI以前から存在するものなので、既知の対策も多い。AIで速度・量・所有不在の度合いが変わったから、これらの古典を AI時代の文脈で再評価する必要が出ているだけで、白紙から処方箋を作る必要はない。
そして、対策が分かっていても実行されない理由は、出力量を生産性指標にする組織と、仕事の安定を優先する個人のインセンティブにある。AI時代の認知負債が深刻に見えるのは、技術問題が新しくなったからではなく、もとからあったインセンティブの歪みがAIで増幅されて見えるようになったからと言える。