AI が「この方針で実装します」と計画を出す。私はそれを読み、承認する。実装が進む。そして後になって、あれはどういう仕様だったっけ、と振り返る。コーディングエージェントを毎日使っていて、私にはこういうことがよくある。
先に結論を書く。認知負債は、AI がコードを書いた瞬間ではなく、人が考えずに承認した瞬間に生まれる。AI は書く負荷を引き受けた代わりに、読む負荷を人に残した。読むのは重いので、AI の計画や差分は流し見のまま承認される。そこで、コードの中身が人の頭に戻ってこなくなる。
ただ、承認には 2 つの段階がある。考えずに承認すれば、負債は確実に生まれる。そして、理解したうえで承認しても、後で残っていないことがある。冒頭の場面は後者だ。前者には打てる手がある。後者については、私はまだ答えを持っていない。
認知負債（cognitive debt。認知的負債とも書く）は、ソフトウェア工学の研究者 Margaret-Anne Storey が「チームの共有理解が時間とともに侵食されること」と定義した言葉だ。実務の記事では「理解負債」と呼ばれることも多い。
私は 6 月の記事「AIは人を減らさない、守備範囲を広げる」で、技術的負債と意図負債は自動レビューや品質ゲート、ADR でかなり潰せる、厄介なのは AI 以前からある認知負債だ、と書いた。今はそこを一部改めたい。変わった点は 2 つある。意図負債は ADR を書くだけでは潰しきれない。認知負債は AI 以前からある問題だが、AI がその溜まる速さを上げている。一方で、技術的負債は AI のレビューと品質ゲートでかなり減らせるという見立ては変わらない。ただし AI のレビューで減るのはコードの問題で、人の理解は増えない。Storey 自身も論文で「生成 AI は技術的負債を減らしながら、認知負債と意図負債の蓄積を速めうる」と書いている。
AI コーディングで認知負荷と認知負債が同時に増えている
AI は書く負荷を下げたが、読む負荷と、理解が抜けていく速さを上げた。いま現場で起きていることの多くは、この 2 つの組み合わせで説明できる。
私自身、AI に実装を任せた部分は頭に入ってきにくい。それで困った、あるいは困りそうだと感じたのは、変更や障害対応のとき、人に説明しようとしたとき、レビューで承認するとき、設計の選択を迫られたときだ。
この記事で「承認」と呼ぶのは、AI が出してきた計画や差分を受け入れることだ。Plan Mode で実装方針に「はい」と答えるのも、差分を見てマージするのも、どちらも承認である。
承認が形だけになる
コードの生成速度が人の読む速度を超えた。twada さん（和田卓人さん）の講演「負債のメタファと2026年」でも、レビューが形骸化し始めていると指摘されていた。Addy Osmani は「Comprehension Debt」で、「レビューされたコードは理解されたコードだ」という前提はもう成り立たない、と書いている。承認のボタンは押されている。だが、中身を読んで判断した結果とは限らない。
チームの誰もシステムを説明できなくなる
認知負債は、人が辞めなくても溜まる。以前は、メンバーが抜けて理解が失われるのが典型だった。いまは全員がそろったまま、誰も説明できない部分が増えていく。そうなると、変更は当てずっぽうになり、障害対応は博打になる。twada さんの講演の言葉を借りれば、AI も直せない障害が起きたとき、直せる人がいない。責任の空白である。
理解が欠けても速度の指標には表れない
技術的負債はコードを開けば見える。認知負債は見えない。理解の欠け具合を測る指標もまだない。一方で、デプロイ頻度やリードタイムのような速度の指標は、設計の理解を置き去りにしても上げられる。twada さんはこれを「『生産性』を上げたい組織と個人の共犯関係が成り立ってしまう」と表現していた。評価が速さを褒め続ける限り、理解に時間を使う理由は生まれない。
若手にとってはなお厳しい。6 月の記事「AIは若手を奪わない、判断の回数を増やす」で書いたとおり、判断の基礎は自分で判断した回数で育つ。AI の案を承認するだけの毎日では、その回数が増えない。
3 つの負債を「下り」と「上り」で整理する
意図負債は、人の意図がコードになるまでの「下り」でずれる。認知負債は、コードの中身が人の頭に戻る「上り」で抜ける。こう分けると、2 つの負債の重なりと違いが見えやすい。
Storey は負債を 3 層に分けた（arXiv:2603.22106）。
| 負債 | 宿る場所 | Storey の定義（筆者訳） |
|---|---|---|
| 技術的負債 | コード | コードの層にある問題 |
| 認知負債 | 人 | チームの共有理解が時間とともに侵食される |
| 意図負債 | 要求・ADR・計画・テストなどの記録 | 目標・制約・根拠が外に書き出されていない |
なお、MIT の Kosmyna らも「認知的負債」という言葉を使っている。こちらは LLM に頼ったときの個人の思考力の話で、Storey とは系統が別だ（最後の章で少し触れる）。
意図負債は「下り」でずれる
人の意図が AI を経てコードになるまでに、意図は 3 か所でずれる。
- 指示の足りない部分を、AI がもっともらしく埋める
- 実装の途中で、小さな判断を AI が黙って下す
- 後で読むと、ADR や計画に書かれた意図が、自分のものか AI のものか分からない
3 つ目が特に厄介だ。たとえば、AI に書かせた ADR の「この方式を選んだ理由」の欄を考えてみる。読めば筋は通っている。だが、それが自分で考えて決めた理由なのか、AI が後から補った理由なのかは、もう区別できない。twada さんも、AI が生成したドキュメントに残る「意図」の多くは AI が行間をもっともらしく埋めた結果で、人の判断と見分けがつきにくい、と指摘していた。
だから、ADR を書くだけでは意図負債は潰しきれない。記録は残る。だが、それが人の意図だという保証がない。ここが、6 月に私が楽観しすぎていた点だ。
認知負債は「上り」で抜ける
上りはコードの中身が人の頭に戻ってくる流れだ。自分で書いていた頃は、書くこと自体がこの流れを作っていた。AI に任せると、その流れは承認の場面にしか残らない。承認は、理解が人に戻る最後の関所になる。そこを流し見で通れば、理解は戻らない。
承認で負債が生まれる理由
AI は書く負荷を引き受けた。その分、人には読む負荷が残った。自分で書いていないコードを読んで正しさを確かめるのは、書くより重いことが多い。だから承認は流し見になる。
ここで言う認知負荷は作業中に頭にかかる負担のことだ。負荷はその場の負担で、負債は時間とともに溜まっていくもの。読む負荷が重すぎて流し見になり、流し見の承認が積み重なって負債になる。この記事では負荷と負債の関係をそう捉えている。
書くことは理解する手段でもあった
AI 以前は、自分でコードを書くことで、そのコードを理解できた。Peter Naur は 1985 年の論文「Programming as Theory Building」で、プログラミングの本質は、問題がどう解かれるかという「理論」をプログラマが頭の中に築くことだと論じた。その理論はコードや文書だけでは表しきれない。書く手間と摩擦を通して、この理論が頭の中にできていた。
twada さんは講演で、技術的負債という比喩が生まれた 1992 年と今とを対比していた。1992 年は「人間達の理解が先行し、コードがついてきていない状態」だった。2026 年は「AI によるコード生成が先行し、人間の理解がついてきていない状態」だ。34 年で構図が逆転した。
6 月の記事との線引き
6 月の若手の記事では「手を動かす基礎は AI に任せていい」と書いた。今もそう思っている。シンタックスや定型コードを書く力は任せてよい。
ただ、書くことにはもう一つの役割があった。そのシステムを理解する手段だ。任せてよいのはスキルとしての「書く」で、理解の手段としての「書く」は、任せた時点で失われる。その穴は別の方法で埋める必要がある。
6 月には、AI と壁打ちすれば判断の回数を増やせる、とも書いた。この回数は自分で判断した回数のことだ。AI の推奨を承認しただけの回は、数に入らない。
認知的降伏
AI の出力は流暢で、自信ありげに見える。そのため人は自分で考えずに判断を委ねてしまう。Shaw と Nave は 2026 年のワーキングペーパー（未査読）で、この傾向を「認知的降伏（cognitive surrender）」と呼んだ。twada さんのスライドでは、判断・労力・責任を AI の出力に委ねてしまう傾向と説明されている。
二人は人の思考を速い直感（システム 1）と遅い熟慮（システム 2）に分ける考え方に、AI という外の認知を「システム 3」として加えた。twada さんのスライドの説明では、熟慮は自動では動かない。直感が「何かおかしい」と引っかかったときに、はじめて動き出す。ところが AI の流暢な出力は、この引っかかりを生まない。読み手はそれを詳しい人の意見のように受け取り、AI の答えがそのまま自分の答えになる。
Addy Osmani の紹介によれば、研究は 3 つの実験、参加者 1,372 人で行われた。厄介なのは、AI が間違っていたときでさえ人の自信が上がることだ。だから本人は降伏していることに気づけない。
Osmani は「Cognitive Surrender」で、任せることと明け渡すことを分けている。AI に作業を任せても、答えを自分のものとして持っているなら、それは任せただけ（offloading）だ。AI の出力が気づかないうちに自分の出力になり、自分で答えを組み立てるのをやめたとき、それが降伏（surrender）だという。この区別は次の章で書く線引きに近い。実装の細部は任せてよい。意図と設計の判断まで明け渡すと、降伏になる。
twada さんのスライドには「AI が選択肢を作って人が選ぶだけでは理解は育ちにくい」とある。私にも覚えがある。AI が推奨つきの選択肢を出してくると、私はその推奨を選ぶだけになる。計画も同じで、AI が「この方針でいきます」と出したものを、割とそのまま承認する。この流れで理解のステップを踏まないと、AI の出力を流し見しただけになり、自分のインプットにならない。
承認には 2 つの段階がある
- 考えずに承認すると、負債は確実に生まれる。この記事の対策は主にこの段階に効く。
- 理解して承認したのに、後で残っていない。この段階は最後の章で扱う。
反論: 理解を手放して要るときに作り直せばいいのでは
実装の細部についてはこの反論に賛成する。意図と設計については賛成しない。
人の理解に頼るのをやめようという立場がある。型・テスト・監視で振る舞いを守り、必要になったら AI に説明させて理解し直せばいい、という考え方だ。James Phoenix の「Comprehension Debt Is Refinanceable」は、理解を増やすより、理解を作り直すコストを下げるほうがよいと論じている。
実装の細部なら、私も手放してよいと思う。関数の中身を全部覚えておく必要はない。振る舞いはテストが守ってくれる。euglena1215 さんの「理解をどこまで手放すかは、リスク許容度と仕組みで決まる」も、実装の理解は手放してよく、意図は人の記憶に頼らず残すべきだとしていて、私の立場に近い。
それでも、意図と設計の理解は手放せない。理由は 2 つある。
1 つ目は意図が判断した瞬間にしか残せないことだ。twada さんも、意図を捉える一番よいタイミングは重要な判断を下す瞬間で、後から取り戻すのは難しい、時には不可能だと述べていた。後から AI に説明させても、出てくるのはコードから逆算したもっともらしい理由で、当時の判断そのものではない。
2 つ目は作り直した説明が正しいかを判断する人が要ることだ。その人がいなければ、最初の章で書いた責任の空白に戻る。
ただし、最後の章で書く問題が本当なら、この反論の側に分がある。
個人でできること
下りでは意図を先に書く。上りでは承認する前に自分の言葉で出す。私が一番効いていると感じているのは後者だ。
意図と完了条件を先に書く
AI に渡す前に、何をしたいのか、何ができたら終わりなのかを、自分の言葉で書く。Qiita の記事「【未来を解説】AIでエンジニア格差を生み出す質とスピードの考え方」も、まずこの 1 つを勧めている。
書く形は何でもいい。例を置いておく。最後の欄は下りで起きる「途中の小さな判断を AI が黙って下す」を減らすためのものだ。
## やりたいこと
- 何を、なぜ変えるか（1〜2 行）
## 完了条件
- 何ができたら終わりか。どう確かめるか
## 決めていること / 決めていないこと
- 決めている: 使う方式、触らないファイルなど
- 決めていない: AI に提案してほしいこと。勝手に決めずに聞いてほしいこと大きい変更のときは計画を図解させる
私は大きい変更だと感じたときや ADR を書くときに、計画が何をしようとしているのかを AI に図解させ、それを読んでから進めている。基準は決めておらず、自分の感覚で判断している。毎回やると重いからだ。twada さんも講演の口頭で、毎回の理解度チェックは運用コストが重く、図解に寄せていった、という趣旨の話をしていた（スライドには載っていない。私の聞き取りによる）。
頼み方の例を置いておく。
実装に入る前に、この計画を図で説明してください。
- 変更前と変更後で、モジュールどうしの関係がどう変わるか
- データがどこから来て、どこへ行くか
- この計画の中で、私に確認せずに決めたことがあれば列挙する
図は Mermaid で。説明は図 1 枚につき 3 行まで。ただし、図は分かった気にさせやすい。twada さんのスライドにも、豊かな形式のほうが理解は進むが、同時に認知的降伏のリスクも高まる、と注意がある。図を読んで終わりにしない。
承認する前に自分の言葉で説明する
図を読んだら、承認する前に、計画が何をするのかを自分の言葉で書いてみる。3 行でいい。書けなければ、まだ理解していない。
twada さんのスライドはこれをプロテジェ効果として紹介している。他者に説明しようとすると、自分の理解の足りなさがはっきりし、知識が定着して本当の理解につながる。私はアウトプットが認知負債を埋めるのに一番有効な方法だと感じている。
チームでできること
個人の対策をチームの仕組みに移す。理解を関門にする、説明し合う場を作る、評価の物差しを変える、の 3 つだ。
理解を関門にする
大きい変更はマージする前に、変更した人が中身を説明できるかを確かめる。twada さんのスライドでも、Plan Mode を抜けるときに理解をチェックする試みが紹介されている。全部の PR でやると回らないので、対象は大きい変更に絞る。個人の図解と同じ考え方だ。
説明し合う場を作る
設計の説明会でも、ペア作業でもいい。誰かに説明する機会をチームで用意する。個人のアウトプットと同じ効果があるうえに、一人の頭の中にあった理解がチームのものになる。認知負債はチームの共有理解の問題なので、ここが一番効くはずだ。
評価の物差しを変える
速度を上げても、理解が欠けていれば意味がない。理解は測りにくいが、速さだけを褒めるのはやめられる。たとえば振り返りで「何件出したか」と一緒に「その変更を説明できるか」を聞く。それだけでも、理解に時間を使う理由ができる。
最初の章の課題とこの章の対策はこう対応する。関門と説明の場は理解を人に戻す上りに効く。評価の物差しは意図を書く時間と理解する時間を作るので、上りと下りの両方に効く。
理解して承認しても残らない問題
最後に、答えの出ていない問題を書いておく。
図解させて AI の出力を読み、その場では理解したうえで承認する。それでも後になって、あれはどういう仕様だったっけ、と振り返ることがよくある。ここまでの対策は承認の時点の理解には効く。だが、時間がたっても残ることまでは保証しない。
これは私だけの話ではないかもしれない。MIT の Kosmyna らの研究（arXiv:2506.08872）では、LLM を使ってエッセイを書いた群の 83.3%（18 人中 15 人）が、書いた後に自分の文を正しく引用できなかった。検索エンジンを使った群と、何も使わなかった群では、どちらも 11.1%（18 人中 2 人）だった。未査読のプレプリントで、被験者は 54 人、課題は短いエッセイなので、そのまま開発に当てはめることはできない。ただ、自分で関わったはずのものが手元に残らないという点は、私の感覚に近い。
これが本当なら、前の章の反論の側に分がある。理解は守っても残らないのだから、作り直せるようにしておくほうが現実的だ、と。それでも私は、意図と設計は手放せないと考えている。では、残らない理解をどう残すのか。あるいは残らない前提で意図をどう守るのか。そこはまだ分からない。
まとめ
認知負債は、AI がコードを書いた瞬間ではなく、人が考えずに承認した瞬間に生まれる。意図は下りでずれ、理解は上りで抜ける。実装の細部の理解は手放してよいが、意図と設計の理解は手放せない。
次に大きい変更を AI に任せるとき、2 つだけ試してほしい。
- 渡す前に、意図と完了条件を 3 行で書く
- 承認する前に、計画を自分の言葉で 3 行で説明する
どちらも考えずに承認するのを防ぐためのものだ。理解して承認しても残らない方は、私もまだ悩んでいる。
参考文献
- 和田卓人「負債のメタファと2026年」技術的負債に向き合うConference 2026、2026-09-17
- Margaret-Anne Storey, "From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI", arXiv:2603.22106, 2026（ACM Queue 版）
- Steven D. Shaw, Gideon Nave, "Thinking—Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender", 2026（ワーキングペーパー、未査読）
- Nataliya Kosmyna ほか, "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task", arXiv:2506.08872, 2025（プレプリント、未査読）
- Peter Naur, "Programming as Theory Building", Microprocessing and Microprogramming 15(5), 1985
- Addy Osmani, "Comprehension Debt", 2026
- Addy Osmani, "Cognitive Surrender", 2026-05-05
- James Phoenix, "Comprehension Debt Is Refinanceable", 2026
- euglena1215「理解をどこまで手放すかは、リスク許容度と仕組みで決まる」2026-09-27
- Watanabe Jin「【未来を解説】AIでエンジニア格差を生み出す質とスピードの考え方」Qiita