ハクソク

世界を動かす技術を、日本語で。

認知的負債について私が聞いていること（現時点で）

10時間前原文(margaretstorey.com)

概要

  • Generative AIとAgentic AIの普及がcognitive debt（認知的負債）を増幅させている問題提起
  • cognitive debtはシステムの進化とチームの理解のギャップを指摘
  • 技術的負債と異なり、cognitive debtは人に蓄積される
  • 速さと理解のバランスが崩れることで開発者の負担増加
  • AI時代における高パフォーマンスチームの適応策が問われる

認知的負債（Cognitive Debt）の増大とその影響

  • Generative AIやAgentic AIの導入により、システム構造の進化速度がチームの理解を上回る現象
  • cognitive debt：システムの構造変化と、チームの「なぜ・どう動くか」の共通理解の間に生じるギャップ
  • Simon WillisonやHacker Newsでの議論でも、開発者自身がプロジェクトに迷い、機能追加の自信喪失を経験
  • スピード向上の一方で、意思決定とコード、意図と実装のつながりが希薄化
  • 問題はコード品質だけでなく、「システムの全体像と目的」をチームが把握できるかに及ぶ

認知的負債の痛みは開発者に現れる

  • 技術的負債はコードに蓄積されるが、認知的負債は人間に蓄積
  • 共通理解の喪失による影響
    • 変更時の自信喪失
    • レビュー負担の増加
    • デバッグの難易度上昇
    • オンボーディングの遅延
    • ストレスや疲労感の増大
  • ソフトウェアが「動いている」状態でも、システム理論が把握困難になる体験
  • Siddhant Khareの「AI疲労」、Steve Yeggeの「AI加速開発による燃え尽き」、Annie Vellaの「不確実性の認知的ストレス」など、多様な視点で開発者の体験が強調

認知的負債の返済と知識の再構築

  • Martin Fowlerの指摘通り、認知的負債も最終的には返済が必要
  • 失われた知識の再構築には「分散したシステム理論」の復元が不可欠
    • 意図や意思決定理由、制約条件、アーキテクチャの柔軟性などの記録
  • 知識は「コード」だけでなく、以下に分散
    • 人
    • ドキュメント
    • テスト
    • 会話
    • ツール
    • そしてAIエージェント
  • 返済にはこれら全てのメンテナンスが必要で、単なるリファクタや設計書更新では不十分

工学規律とインセンティブの変化

  • Michael Würschらは「認知的負債は工学規律の欠如」と主張
    • 明確な仕様、厳格なレビュー、十分なテスト、明示的な設計ドキュメントで知識損失は防げる
  • 一方で、AIにより構造生成コストが低下し、進化速度が理解を上回りやすくなる現実
  • どれほど規律あるチームでも「理解と変化のバランス」を意識的に調整する必要性
  • 仕様書やドキュメントは「生きた成果物」としてチームが積極的に関与しなければ不十分

認知的負債への対策事例

  • 読者から共有された対策
    • より厳格なコードレビューの実施
    • 意図を記述するテストの作成
    • 設計ドキュメントの継続的な更新
    • プロトタイプを「使い捨て」として扱う姿勢
    • AIを活用し、認知的作業のコスト削減や依存関係管理、説明支援を実現
  • AIを意図的に使えば、認知的作業の可視化も可能

高パフォーマンスチームの今後の適応

  • これまで高パフォーマンスチームは「技術的負債」管理に長けていた
  • AI普及下で「認知的負債」をどう管理し、意図の外部化や共通理解維持を実現するかが新たな課題
  • Generative AIやAgentic AIを「コード生成加速」だけでなく「集団的理論の維持」に活用する必要性
  • 技術的摩擦が減るほど「共通理解」がボトルネック化する可能性
  • 実際の現場で機能する対策事例の共有を呼びかけ

Hackerたちの意見

認知的負債についての記事がAIによって書かれた感じがするのはちょっと気持ち悪いね。
└
それはさておき、この記事はHNスレッドの要約に過ぎないね…
└
同じ反応をしたけど、この記事はAI生成ではないらしいよ、pangramによると、これは一般的に信頼できると思ってる。LLMの言い回しや思考パターンが普通の人間の思考に入り込んでるのかな。
最初の段落を読んだだけで、テスト担当者がテストするための受け入れ基準にAIを適用しようとしたときに、もうその感覚を体験し始めてる。法律の要件のせいでソフトウェアは必然的に複雑になるし、AIがアクセスできる文書のコーパスは、システムや関連プラットフォームの複雑さや微妙なニュアンスを捉えきれてない気がする。受け入れ基準をもっと早く作成できるけど、もしそれを「終わった」として次のことに進んじゃうと、品質が急激に落ちるだろうね。今、最初に生成された受け入れ基準を全部書き直してるんだけど、基本的な前提が間違ってたから。これはプロンプトエンジニアリングと文書のコンテキストの十分さの問題だけど、どちらも学習曲線が長いんだよね。知識管理がうまくできてるところは少なくて、必要な基本情報が不十分なことも多いし、一つの「パッチ」が欠けるだけで多くのコンテキストが変わっちゃう。
└
オーストラリアの税務に関わってるんだけど、規制が複雑で、文書も読者がCPAだと仮定してることが多い。チャットボットに仮定をせずに質問をするように指示したら、まあまあの結果が出たよ。それから、エッジケースを見つけるためにしっかりと質問したりして。CPAの前で実演したとき、彼らの文書を使って、Claudeが彼らが考えもしなかった確認質問をして、古い手動プロセスのギャップを明らかにしたんだ。
こういう記事はなんかバカみたいに思える。AIが役立つところで使って、役に立たないところでは避ければいいんじゃないかな。その境界線は週ごとに変わるかもしれないし。テストを書くのや変更の確認にはいいと思うけど、コアのドライバーコードを書くのは任せたくないな（俺はシステムプログラマーだから、あなたの状況次第だけど）。もしかしたら、1ヶ月後には考えが変わってるかも。
└
ツールをツールとして使うのは難しいよね。市場がそれを新しいスライスパンのように、すべてに使えって言ってるから。
└
>「AIは役立つところで使い、役に立たないところでは避けるべき」 ただのハンマーしか持ってないと… 他の道具の使い方を忘れちゃうよね。
> 質問は、チームが認知的負債をどう管理するかになる それが面白いところなんだよ、彼らは管理しないだろうね。業界全体でメッセージは明確だよ：AIを使ってもっと生産的になれって。経営陣は人を減らして、自分たちの利益を増やすことに夢中になってる。話す相手の多くが、燃え尽き感や仕事を失う恐怖、AIが今のように押し進められていることへの不満を感じてる。仕事を守ることに集中しているってはっきり言う人も多い。認知的負債なんて気にしてないし、負債が返済期に来るのを楽しみにしてる人もいる。悲しいけど、これが現実なんだ。
└
そして、私たちは過去のハイプサイクルから何も学ばなかった。ここでのエンシティフィケーションは変化するだろう。そして、HNには「誰もこれが来るとは思わなかった」といった大きな記事が出るだろう。はい、私たちはそれを見ていた。
└
AIを使って認知的負債を管理することはできるけど、それはスプリントボードには反映されない。全体的に見て、私はまだ人々がもっとシンプルにできるものを過剰に設計するのが好きだと思う。これはLLMの影響であまり変わっていない。LLMは彼らが複雑な実装をもっと早く作れるようにしただけだ。
└
まさに俺もそう感じてる。知ってる開発者たちは、仕事がある限りそれに従ってるだけ。もう誰も品質なんて気にしない、ただできるだけ多くのコードを出すレースになってる。ドキュメントがあっても、マネージャーが読まないから、LLMに出力させた適当なものを使って「仕事をした」ように見せかけるだけ。
残念ながら、認知的負債は自分をエンジニアだと思っていたソフトウェア職人の叫びだと思う。エージェントの下請け業者やエージェント工場、エージェント部品のベンダーと仕事をする中で、彼らはそれを職人技として捉えた。下請け業者のオフィスを回って画面をレビューしたり、工場で部品をチェックしたり、注文した部品の内部設計を確認したくなるのは自然なことだよね。圧倒されるのも当然だ。だからエンジニアには契約書や仕様書、設計図、データシート、特性データが必要なんだ。これらは明確に定義された抽象の境界で渡されて、相手がブラックボックスであることを受け入れるんだ。もちろん、コンパイラやツールもあったけど、それは設計者のための鉛筆と製図板みたいなもんだ。パッケージや依存関係、APIのエコシステムが進化してきたけど、それはしばしばソフトウェアの魔法使いが呪文書を読んだ後に唱える呪文みたいなもんだ。これからは、この混乱を管理するために新しい境界や抽象を構築し、新しい引き渡しプロトコルを作る必要があるね。
└
ウォーターフォール型のソフトウェアエンジニアリングがそんなに成功してるからね、そうだよね？ ;-)
└
引き渡しプロトコルの反対側で責任を持てるパーティーはいないね。
└
>「これがエンジニアが契約、仕様、設計図、データシート、特性データを持っている理由だ。抽象の明確に定義された境界で引き渡し、実際の生産ラインを検査するために。」アップルだって、毎年フォックスコン（人間が作った最も成功した信頼できるアセンブリライン）を現地で監査してるんだよ。
認知的負債は、LLMが主流になるずっと前から存在してたんだよね。技術者たちは仕事が上手くなって、管理職に昇進した。でも、時間が経つにつれて技術的な能力を失っていったんだ。ただ、良いマネージャーなら、技術の進展を追い続けて、エンジニアリングの考え方を使って、部下が最適な効率で働けるようにして、会社の目標を達成させるんだよね。今、私たちは、最新の情報を追わず、考えを使わないひどいマネージャーがいることを知ってる。このことはAIの使用でも同じことが起こると思うよ。さらに、エンジニアにはマネージャーのマインドセットを求めているけど（AIエージェントや製品要件を管理するなど）、多くのエンジニアはこれが苦手で、マネージャーになりたいとも思ってない。そもそも、エンジニアリングを選んだ理由がそれなんだよね。
└
これが独自の視点ではないにしても、もっと多くの人がこれを理解していないのが驚きだよ。みんなが「昇進」してスタッフプラスのエンジニアになって、その現実に気づいているんだ。面白いのは、こういう人たちが、上の方で「何もしない」って文句を言ってる同じ人たちだってこと。
└
そうだね、むしろ私たちは人を王様や女王に昇進させていると言ってもいいかも。AIが私たちの最悪な部分を増幅させるんじゃないかと心配してる。結局、AIはおべっか者だから。AIが一人の人間に10億ドルのビジネスを運営させるって話をたくさん聞いたけど、正しいマインドセットや規律がなければ、どんな技術でも遠くまで行けないと思うんだ。
└
>多くのエンジニアはこれが苦手で、マネージャーになりたいとも思ってない。そもそも、エンジニアリングを選んだ理由がそれなんだよね。ビンゴ。無能なおべっか者を管理するために人生を費やしたいなら、MBAを勉強してマッキンゼーで昇進を目指してたよ。
└
俺が一緒に働いた「ソフトウェアエンジニア」たちが、ナウアの論文（https://pages.cs.wisc.edu/~remzi/Naur.pdf）を読んだことがないっていうのには、いつも驚かされる。エージェンティックコーディングの概念を知らない人も多いし、これは俺たちの分野では現実なんだよね、みんなが気づいてるかどうかは別として。
└
それは本当だね。俺より賢い人たちが言ってるように、ソフトウェアエンジニアリングってのは、時間をかけてプログラミングすることなんだ。その時間の要素ってのは、個々の人がコードベースをどんどん知らなくなっていくことを含んでる。でも、そういう賢い人たちが主張してるのは、コードをメンテナブルに保つためには、いくつかのルールやプロセス、パターンに従う必要があるってことなんだよね。これらを他の開発者やLLMに適用するかどうかはちょっと微妙だと思う。結局、どちらも（自分自身も含めて）システム全体を完全に理解しているとは言えないからさ。
その解決策は「オーナーシップ」だと思う。会社や製品の各部分には、それを所有し、理解し、長期的な健康に責任を感じる人や小さなグループが必要なんだ。彼らは、どのレベルのレビューが必要かを決めたり、変更をレビューしたりする。高機能なチームがうまくいくのはオーナーシップと責任感があるからで、低機能なチームが崩れるのはそれが欠けているから。プライドや意欲、高い基準を持って特定の分野や物事に責任を感じる人が必要なんだ。昔はそのオーナーシップが個人でも集団でも良かったけど、AIや多くの横断的な作業が増えた今は、オーナーシップは小さなグループ（または個人）に向かうべきだと思う。開発者は設計できるけど、デザイナーはそれをレビューする必要がある。デザイナーはコーディングできるけど、そのコードのオーナーがレビューしなきゃいけない。これがゲートキーピングに感じるかもしれないけど、これが唯一の方法なんだ。
└
幸いなことに、LLMの広範な使用によって、企業は各チームが所有するものの数を減らしたり、突然豊富な自由時間を持つエンジニアを多く雇ったりして、自分で学び始めたり、製品の一部に対するオーナーシップを感じたりすることができるようになったんだ。待って…
└
>所有権が解決策だと思う。前にも言ったけど、みんなこの事実を軽視してる。 >プライドや意欲、高い基準を持って特定の分野や物事に責任を感じる人。これも前に言ったけど、AI信者は「プライドや称賛、アイデンティティとのつながりを手放さなきゃならないかもね」って反応するだけ。バイブコードしてるほとんどの人は、自分の仕事なんてどうでもいいと思ってる。どんな解決策でも、機能するならそれが解決策だ。 >これがゲートキーピングに感じるかもしれないけど、これが唯一の方法なんだ。ゲートキーピングは本質的に悪いわけじゃない。私たちはゲートキーピングが必要なんだ。手術を受けるなら、実績のある医者にやってもらいたいしね。ソフトウェアが人を殺さないって言ってる人は、「Therac-25」やテスラの「フルセルフドライブ」で亡くなった65人のことを調べてみてほしい。
└
同意するけど、うまくいくとは思えない。所有権は、ある人やチームが代替不可能になる、または少なくとも代替が難しくなることを意味する。人々はリソースではなく、人間に戻る。経営陣はそれを好まないだろう。私が関わったあるビジネスでは、その実験が試みられたが、ひどく失敗した。実際には、人々がプロジェクト間で入れ替わり、「オーナー」が数ヶ月ごとに変わっていた。結果は技術的負債や政治的な面でもかなり混乱していた（誰が最終的な意思決定者なのかという問題）。
└
必要なのは、コードだけじゃなくて会社の所有権も持つことだよ。自分の仕事なら、他人のものよりもずっと気にかけるようになるからね。
なんか共感できる部分があって、LLMが普及する前にある程度はこれを実現できたと思う。私の主なエディタはvimで、かなりの期間、ほぼ純粋に使ってた。LLMが主流になる前の話ね。ただ、javaを編集するためにvimを使うことはできなかった。言語サーバーがあっても試したけど、結局intellijに戻ってしまった。python、ruby、typescriptのコードベースは普通に問題なかったけど。理由は二つあって、みんながintellijの機能をフル活用してたから、コードもintellijに似た構造になってたし、当時人気のjavaデザインパターンもあったから。すべてがファクトリーやマネージャー、インターフェースを通っていて、純粋なエディタでそれを追跡するのはほぼ不可能だった。IDEがそれを処理してくれたからね。でも、他のことはどうかっていうと、私や他の人がゼロから作らなきゃいけないものは、その認知的制限を考慮して作られてたから、すべてをうまく収めてvimで効率よく編集できたんだ。そういう認知的制限はソフトウェアにとって良いことなんだ。説明が簡単で、デバッグも簡単、追加や削除も楽。今の流行の「動くまでコーディング」っていうのはもう無視するようになった。原則はKISS - 簡単に保て、バカなことをするな。AIがそれをしないなら、自分がやらなきゃいけない。これは今まで以上に重要な哲学的な問いだと思う。残念ながらほとんどの人はそれに気づいてない。彼らは必要ないデザインパターンで次の「機能」を追加して、認知的・技術的な破産に早期に陥ってしまうんだ。
エージェント的に構築すべきでないプロジェクトがたくさんある。エージェントで構築するのが適切なものについては、全力で取り組むべきだという強い意見を持つようになった。エージェントで作ったなら、エージェントで修正し、エージェントでデバッグし、エージェントで変更するべきだ。その場合、ソースコードの管理者だと思わずに「認知的負債」を心配する必要はない。もうそれはあなたの仕事じゃないから。あなたの仕事は仕様の管理とエージェントのケアだ。「自分のためにドキュメントを作るんじゃなくて、エージェントのために作る」とか、「自分が書いてないものをデバッグするために開発スキルを使おうとはしない、エージェントが実行中のコードの状態や活動を理解できるように特定のインターフェースを作る」と考えると、もっと幸せで成功すると思う。エディタでオートコンプリートのためにエージェントを使ってるとか、コードについて質問するために別のチャットウィンドウを開くのは、かなり低レベルなエージェントの使い方で、既存の開発スキルや責任はまだ適用される。もしsuperpowers（スキル）みたいな計画フレームワークを使ってプログラムの仕様を作成しているなら、ソースコードには手を出さず、読む時間を無駄にしないで。エージェントに説明させて、IDEで見せてもらって、エージェントに変更してもらえばいい。
└
これは正しいけど、重要な次元を見落としている。エージェントに哲学を注入して、それを守らせることができる。LLMは十分な訓練を受ければ、しぶしぶそれを実装するだろう。最も重要なのは、すべてのレベルでSIMPLE>COMPLEXであることを監視し続ける必要がある。そうでないと、LLMは小さなコンテキストウィンドウを使って、自分自身が修正できない真のスパゲッティを作り出すことになる。これがデフォルトの道で、あまりにも多くの人がこの道を選んでしまった。
└
まとめ；エージェント的なコーディングはうまくいく。ただ、ちっぽけな人間をリードにつなぐ必要がある。
└
俺の経験とは全然違うな。大規模な「手書き」のプロジェクトでClaude Codeを使ってるけど、バグを見つけたり新しいメソッドやクラスを生成するのが本当に優れてる。ただ、微妙なバグを頻繁に引き起こすから、変更は慎重に確認しなきゃいけない。使いどころを学ぶのがコツだね。自分でやった方が早い作業もあれば、Claude Codeの方が早いものもある。
この改善策には不安を感じる。問題は、AIへの依存が認知的負債を増やしていることで、解決策は意図をよりよく捉えるテストを書いて、設計文書を継続的に更新することだ。でも、AIを使って認知的負債を抱えた人たちも、AIを使って「意図をよりよく捉える」テストを書いたり、設計文書を更新したりするんだよね。それはエージェントの効果を高めるためには良いことだけど、認知的負債のスパイラルから抜け出す助けにはならないと思う。