AIがコードを書く時代、最後に不足するのは人間の「理解」かもしれない
プロンプトを入力する。数十秒後、数百行のコードが生成される。
画面は動く。テストも通る。少し修正してPRをマージする。これまでなら数日かかった機能が、数時間で完成したように見える。
ところが3か月後、その機能に小さな変更が必要になる。
「なぜこの状態管理になっているのか」
「この条件分岐を消すと、どこが壊れるのか」
「このリトライ処理は何から守っているのか」
コードはそこにある。コミット履歴もある。AIとの会話ログも残っている。それでも、チームの誰もシステムを自信を持って説明できない。
これは単なる技術的負債ではない。
認知負債──cognitive debtである。
AIによってコードを書くコストが急速に下がる一方、生成された仕組みを理解し、批判し、変更できる状態を維持するコストは下がっていない。むしろ、コードの増加速度に人間の理解が追いつかなくなることで、そのコストは見えない場所に積み上がっていく。
AI時代の開発速度を決めるのは、モデルがコードを生成する速度ではない。
チームが変化を理解し、吸収できる速度である。
「書くこと」から「理解すること」へ
NotionのデザインエンジニアGeoffrey Littは、2026年7月に公開した「Understanding is the New Bottleneck」で、AI時代のソフトウェア開発には二種類の理解があると整理している。
一つは、AIの仕事を検証するための理解だ。
コードが正しいか。要件を満たしているか。セキュリティ上の問題はないか。テストは十分か。これは、成果物を承認するための理解である。
もう一つは、プロジェクトに参加するための理解だ。
現在の仕組みを頭の中で組み立て、そこから次のアイデアを思いつき、設計の選択肢を比較し、「そもそも別の問題を解くべきではないか」と問い直すための理解である。Littが重視するのは後者だ。ソフトウェア開発は一度きりの依頼と納品ではなく、実装を見て考え、考えた結果をまた実装へ戻す、長い反復の連続だからである。(geoffreylitt.com)
テストや静的解析が十分に発達すれば、AIが書いたコードを人間が一行ずつ読む必要は減るかもしれない。
しかし、検証を自動化できることと、人間がプロジェクトの主体であり続けられることは同じではない。
AIの出力に対して「通すか、戻すか」だけを判断する人間は、レビュー担当者ではあっても、次の設計を生み出す共同設計者ではなくなっていく。
コードを理解しなくてもマージできる。しかし、理解しないままでは、次の良い問いを作れない。
ここに、新しいボトルネックがある。
🧠 認知負債とは何か
ThoughtWorksはcodebase cognitive debtを、実装されているシステムと、それがどのように、なぜ動くのかについてチームが共有している理解との隔たりとして説明している。
AIが変更を量産するほど、その隔たりは大きくなりやすい。複数の開発者やエージェントが並行してコードを変更すると、設計意図、暗黙の制約、隠れた依存関係をチームが吸収する前に、次の変更が積み重なるからだ。(Thoughtworks)
ここで、三つの負債を区別すると分かりやすい。
技術的負債は、主にコードやアーキテクチャに存在する。重複、密結合、壊れやすい境界、テスト不足などが将来の変更を難しくする。
認知負債は、人間とチームの頭の中に存在する。コードはきれいでも、誰もその前提や振る舞いを説明できなければ、認知負債は大きい。
意図負債（intent debt）は、なぜその設計が選ばれたのか、何を守ろうとしているのか、どの代替案を捨てたのかが外部化されていない状態を指す。Margaret-Anne Storeyらは、AI時代の問題を技術的負債だけでなく、認知負債と意図負債を含む三層の問題として捉えている。(arXiv)
たとえば、AIが複雑な処理を美しくリファクタリングしたとしよう。
コードの重複は減り、関数名も改善され、テストも増えた。技術的負債は減っているように見える。
しかし、その抽象化を採用した理由も、境界条件も、どの要件を優先したのかも、人間が理解していないなら、認知負債は増えている。
つまりAIは、技術的負債を返済しながら、認知負債を増やすことさえできる。
概念的には、認知負債の増加を次のように表せる。
認知負債の増加 ≒ システムに実装された変化量 − 人間が吸収した変化量
生成量そのものが問題なのではない。
変更の速度と、理解の速度の差が問題なのだ。
認知負債には「利息」がつく
認知負債は、コードが動いている間は見えにくい。
ビルドは成功する。デプロイもできる。ユーザーも使えている。そのため、負債が存在しないように感じられる。
だが、次の変更時に利息が発生する。
小さな修正なのに影響範囲が読めない。レビューで設計上の議論ができず、表面的な差分確認に終始する。バグを直すたびに別の回帰が起きる。「よく分からないから触らない」という領域が増える。新しいメンバーはコードを読んでも、システムの理論を再構築できない。
ThoughtWorksは、こうした状態が進むと、軽微な変更で予想外の障害が起き、修正が別の回帰を生み、クリーンアップ自体が危険になる転換点が訪れると警告している。さらに、理解が弱まるほどAIに適切な指示を与えにくくなり、エッジケースやアーキテクチャ上の落とし穴も予測しにくくなる。(Thoughtworks)
ここでは、負の循環が発生する。
理解が減る → AIに与える文脈が粗くなる → AIの出力が局所最適になる → 例外処理や補修コードが増える → システム全体をさらに理解しにくくなる → ますますAIへ判断を委ねる
AIに詳しくないからAIを使えないのではない。
コードベースを理解していないから、AIをうまく操れなくなるのである。
数字が示す、三つの「速度の錯覚」
AIコーディングの研究を見ると、認知負債そのものを直接測定した研究はまだ多くない。
それでも、いくつかの研究から、AIが生む「速さ」と、実際の生産性や学習、出荷価値との間にあるズレが見えてくる。
ただし、以下の研究は証拠の性質が異なる。METRとAnthropicの研究は限定された環境でのランダム化比較試験、NBERの研究は大規模な観察研究、CodeRabbitはベンダーによるPR分析である。数字を一つの普遍的な結論として混ぜるのではなく、異なる角度から同じ構造を照らしていると読むべきだ。
1．体感上の速さと、実測された速さは違う
METRは2025年、経験豊富なオープンソース開発者16人を対象に、実際の成熟したリポジトリ上の246件のタスクを使ったランダム化比較試験を行った。
その結果、当時のAIツールを利用した開発者は、利用しなかった場合より平均で19％遅くなった。
興味深いのは、開発者自身の認識とのズレだ。実験前にはAIによって24％速くなると予想し、実験後でさえ20％速くなったと感じていた。実際には遅くなっていたにもかかわらず、本人たちは速くなったと認識していたのである。(arXiv)
もちろん、これは「AIを使うと必ず19％遅くなる」という話ではない。
対象は大規模で成熟したOSS、20分から数時間程度のタスク、そしてCursor ProとClaude 3.5／3.7など、2025年前半のツールである。METR自身も2026年時点で、この結果が現在のAIツールの能力をそのまま表すものではないと明記している。後続調査についても、参加者の選択バイアスや並行エージェント利用時の計測問題があり、確実な速度向上を推定できる段階ではないとしている。(Metr)
この研究の重要な教訓は、AIが遅いことではない。
コードが目の前で高速に出現する感覚は、プロジェクト全体の速度を測る信頼できる指標ではないということだ。
プロンプトの試行錯誤、生成結果の確認、既存コードとの整合、テスト、手戻り、コンテキスト切り替えは、生成アニメーションほど目立たない。そのため、人は「書く時間が減った」ことを強く感じる一方、「理解と修正に費やした時間」を過小評価しやすい。
2．タスクを終えることと、能力を獲得することは違う
Anthropicは、Python経験者52人をAI利用群と非利用群に分け、参加者に未経験の非同期ライブラリTrioを使った課題へ取り組ませた後、理解度を測るランダム化比較試験を行った。
AI利用群は、課題を終えるまでの時間が平均で約2分短かった。ただし、この差は統計的に有意ではなかった。
一方、理解度テストの平均点は、AI利用群が50％、非利用群が67％だった。17ポイントの差である。特に大きな差が生じたのは、コードを読んでバグの原因を推論するデバッグ問題だった。(Anthropic)
ただし、AI利用者が一様に理解を失ったわけではない。
結果を分けたのは、AIを使ったかどうかよりも、AIとどう対話したかだった。
低得点になりやすかったのは、課題全体をAIへ委譲した人、生成コードへ次第に依存した人、エラーが出るたびにAIへ修正を丸投げした人だった。こうした利用者の理解度は40％未満にとどまった。
対して、生成後にコードの仕組みを質問した人、コード生成と概念説明を組み合わせた人、最初からライブラリの概念について質問した人は、65％以上の高得点を取る傾向があった。なかでも「概念について質問する」使い方は、高得点群の中で最速であり、全体でも完全委譲に次いで速かった。(ar5iv)
つまり、速度と理解は必ずしもトレードオフではない。
AIに答えを作らせるのではなく、AIを理解の足場として使えば、速さと学習を両立できる可能性がある。
さらに興味深いのは、非AI群のほうが多くのエラーに遭遇していたことだ。中央値では、AI群が1件、非AI群が3件だった。非AI群はエラーを読み、仮説を立て、修正しながら新しいライブラリの挙動を学んだ可能性がある。(ar5iv)
エラーは単なる障害ではない。
ときに、エラーこそが教材になる。
また、AIが生成したコードをコピー＆ペーストせず、手で打ち直しただけでは、概念理解はほとんど改善しなかった。重要だったのは指を動かした時間ではなく、説明を求め、予測し、意味を考えた認知的努力だった。(ar5iv)
理解を守ることは、手打ちを守ることではない。
この研究は一つのライブラリ、一時間程度の課題、チャット型インターフェースに限定され、長期的な技能形成を直接追跡したものではない。参加者の動機やプロンプト能力にも現実の職場との差がある。そのため、50％対67％をあらゆる開発に当てはめるべきではない。(ar5iv)
それでも、AIへの委譲方法によって理解の残り方が変わるという結果は、認知負債を考えるうえで重要だ。
3．コード量と、出荷される価値は違う
NBERの2026年のワーキングペーパー「Writing Code vs. Shipping Code」は、10万人を超えるGitHub開発者とAI利用テレメトリを用いたマッチド・イベントスタディから、AI導入後の変化を分析している。
推定では、オートコンプリートの利用はコミットを約40％、対話型エージェントは約140％、自律型エージェントは約180％増加させた。
ところが、自律型エージェントによる約180％のコミット増加は、プロジェクト数では約50％、リリース数では約30％まで減衰した。論文は、AIと人間の労働の代替弾性を0.25と推定しており、両者が簡単に置き換えられるのではなく、強く補完し合う関係にあると解釈している。(NBER)
0.25という数字は、「AIが人間の25％を置き換える」という意味ではない。
コード生成だけを増やしても、レビュー、統合、テスト、仕様判断、リリース、運用といった人間側の工程が同じ速度で伸びなければ、成果は減衰するということだ。
AIによってコードの到着速度が上がっても、チームの処理能力が変わらなければ、未レビューの変更、理解されていない抽象化、統合待ちのブランチが列を作る。
ボトルネックは消えない。後ろへ移動する。
CodeRabbitが470件のオープンソースPRを分析したレポートでも、AI共著と分類されたPRでは、1件あたりの指摘事項が平均10.83件、人間のみと分類されたPRでは6.45件だった。約1.7倍である。ロジックや正確性に関する指摘は75％多く、可読性やセキュリティなどでも差が報告された。(CodeRabbit)
もっとも、これはベンダーによる観察的な分析であり、AI利用の判定にも推定が含まれる。AIが問題を1.7倍発生させるという普遍的な因果効果として読むべきではない。(CodeRabbit)
それでも示唆は明確だ。
生成速度が上がるほど、レビュー負荷まで自動的に下がるとは限らない。場合によっては、人間が理解しなければならない変更の流入量だけが増える。
問題は「正しいか」だけではない
AIコードをめぐる議論では、しばしば「テストが通れば、人間が中身を理解する必要はない」という意見が出る。
限定された範囲では、その通りだ。
計算結果を検証でき、入出力の契約が明確で、失敗しても容易に隔離・ロールバックできるなら、内部のすべてを理解する必要はない。私たちはOSやデータベース、暗号ライブラリの全実装を理解せずに利用している。
だが、既存のライブラリと、いま自分たちのプロダクト内部へ生成されたコードには違いがある。
ライブラリには、境界、バージョン、公開API、保守主体、利用実績がある。自分たちのコードベースに生成されたコードは、多くの場合、そのプロダクト固有の要件、データ、例外、歴史的制約と密接に結びついている。
そして、将来それを変更する責任は自分たちに残る。
AIに実装を委譲しても、運用責任まで委譲できるわけではない。
検証のための最低限の理解だけを残した開発チームは、現在の変更を承認できても、次の状況変化に対応できない。ユーザー行動が変わったとき、要件が衝突したとき、障害が複数の境界をまたいだとき、必要になるのは「テストを通した知識」ではなく、システムについての生きた理論だからだ。
コードは、その理論の完全な記録ではない。
コードには「何をしているか」は書かれている。しかし、「なぜそれをしているか」「どの現実をモデル化しているか」「何を壊してはいけないか」「どこなら変更できるか」は、必ずしも残っていない。
AIは成果物としてのコードを生成できる。
しかし、そのコードを生み出す過程で人間が獲得していたはずの理論まで、自動的に頭へ転送してくれるわけではない。
半世紀近く前、Papertが見ていたもの
この問題を考えるうえで、Geoffrey LittはSeymour Papertの構築主義に接続する。
Papertの考えでは、学習者は知識を受動的に受け取るのではなく、何かを作り、動かし、試し、失敗しながら、自分の頭の中に知識の構造を組み立てていく。構築主義は、頭の中で知識を構成するという構成主義に加え、外の世界で意味のあるものを作ることが、その学習を強く促すと考える。(papert.org)
Papertが重視したのは、単に正解を提示する教材ではない。
学習者が対象を操作し、仮説を試し、結果を観察できる「マイクロワールド」だった。
この視点から見ると、AIには二つの使い方がある。
一つは、答えの自動販売機として使うことだ。
「この機能を作って」「このエラーを直して」「テストを追加して」と頼み、完成品だけを受け取る。人間は摩擦から解放されるが、同時に、対象について考える機会も失う。
もう一つは、思考するための環境生成器として使うことだ。
内部状態を可視化するデバッガーを作らせる。複雑なデータフローを操作できる小さなシミュレーターを作らせる。失敗条件を再現するサンドボックスを作らせる。理解を確認するクイズを作らせる。設計案ごとの挙動を比較する実験環境を作らせる。
Littは、コード解説、理解度クイズ、インタラクティブなマイクロワールドを、AI時代に人間の理解を深める具体的な方法として提案している。完成したコードを説明させるだけでなく、自分で操作し、予測し、結果を確かめられる環境をAIに作らせるのである。(geoffreylitt.com)
AIに摩擦をすべて消させる必要はない。
消すべきなのは、文法の暗記、ボイラープレート、検索の往復、単純な変換といった非生産的な摩擦だ。
残すべきなのは、仮説を立てる、失敗を読む、設計を比較する、自分の言葉で説明するといった理解を生む摩擦である。
🔧 認知負債を増やさない「理解ループ」
AIコーディングを禁止する必要はない。
必要なのは、コード生成のループに理解を組み込むことだ。
基本形は次のようになる。
意図を言語化する → 小さく生成する → 説明する → 反証する → 自分で再現する → チームへ共有する
1．コードより先に「守るべきもの」を書く
AIに実装を頼む前に、最低限、次の情報を明示する。
何を実現したいのか。何を今回は実現しないのか。必ず維持すべき不変条件は何か。どのような失敗があり得るか。問題が起きたとき、どうロールバックするか。
これはプロンプトを上手にするためだけではない。
設計意図を人間側に残し、意図負債を防ぐためである。
「ユーザーを削除するAPIを作る」では足りない。
関連データを物理削除するのか、論理削除するのか。監査履歴は残すのか。課金契約がある場合はどうするのか。操作は取り消せるのか。
こうした判断こそがプロダクトの知識であり、AIへ渡す前に人間が所有すべき部分だ。
2．一度に生成する「概念の数」を減らす
巨大な変更を一度に生成すると、差分の行数だけでなく、同時に理解しなければならない概念の数が増える。
認証、キャッシュ、キュー、DBスキーマ、エラーハンドリング、UI状態管理を一つのPRに詰め込めば、各部分が正しくても全体の因果関係を追いにくい。
一つの差分では、一つの設計判断を中心にする。
小さな差分はレビューしやすいだけではない。人間が仮説を持ち、変更前後を比較し、メンタルモデルを更新しやすい。
AIは一度に大量生成できる。
だからこそ、人間側が意図的に生成単位を制限する必要がある。
3．「何を変えたか」ではなく、「なぜそうしたか」を説明させる
Littは、背景と直感を先に示し、その後で詳細へ進む“literate diff”の考え方を提案している。単なるファイル一覧や行単位の説明ではなく、変更を理解するための物語を差分に持たせる。(geoffreylitt.com)
AIに説明させる際も、「このコードを説明して」だけでは弱い。
次のような問いのほうが、設計の構造を露出させる。
- この変更が解決している根本的な問題は何か
- 採用した設計と、捨てた代替案は何か
- このコードが暗黙に仮定していることは何か
- どの入力やタイミングで壊れる可能性があるか
- 既存システムのどの部分と強く結合しているか
- 要件が変わった場合、最初に変更すべき場所はどこか
大切なのは、AIの説明文を保存することではない。
説明を材料に、人間が自分のモデルを作ることだ。
4．マージ条件に「説明できること」を加える
テストが通ること、lintが通ること、レビュー承認があることに加え、重要な変更では次の質問に人間が答えられることをマージ条件にする。
- 何が変わったのか
- なぜこの設計を選んだのか
- 守るべき不変条件は何か
- どこで、どのように失敗し得るか
- 問題が起きたら、どう切り離し、戻すのか
答えられない場合、コードが間違っているとは限らない。
しかし、その変更はまだチームのものになっていない。
Littが提案する理解度クイズは、この確認を自動化する一つの方法だ。エージェントにコードを生成させるだけでなく、変更内容に関する質問も作らせ、人間が説明できる速度まで実装速度を調整する。(geoffreylitt.com)
これは試験を増やすためではない。
「分からないまま先へ進む」ことを検知する速度制限装置である。
5．AIにコードではなく、観測手段を作らせる
理解できないシステムに対して、さらに説明文を増やしても限界がある。
ときには、説明より観測のほうが強い。
状態遷移を可視化する画面、イベントの時系列表示、依存関係グラフ、失敗を再現するテストハーネス、ネットワーク遅延やタイムアウトを注入する環境、データ変換を段階的に表示するツールをAIに作らせる。
「答えを教えて」ではなく、「自分で答えを発見できる環境を作って」と頼む。
さらに、アーキテクチャ上の制約を自動確認するfitness function、契約テスト、プロパティベーステスト、可観測性の指標を整備すれば、チームの理解を支えるセンサーになる。ThoughtWorksも、認知負債への対策としてフィードバックセンサー、チームの認知負荷の追跡、アーキテクチャ適合性を継続的に確認する仕組みを挙げている。(Thoughtworks)
6．理解を個人の頭から、チームの共有物へ移す
一人だけが理解している状態は、認知負債を返済した状態ではない。
それは単に、負債を一人の記憶へ移しただけだ。
重要なAI生成変更には、少なくとも一人の明確な人間の所有者を置く。認証、課金、データ移行、権限管理などの重要領域では、二人以上が説明・変更できる状態を目指す。
設計判断は、完成後のコード説明ではなく、選択理由、代替案、トレードオフ、将来見直す条件として残す。ペアレビュー、設計ウォークスルー、リファクタリング、テスト駆動開発、定期的な知識共有は、共有された理解を再構築する手段になる。Storeyも、少なくとも一人の人間がAI生成変更を十分に理解すること、「何を」だけでなく「なぜ」を記録すること、レビューや振り返りを通じて共有理解を維持することを勧めている。(Margaret-Anne Storey)
AIとの会話ログを保存するだけでは十分ではない。
長い会話ログは、意図が外部化されているように見えて、実際には必要な判断を検索・再利用しにくい。判断の要点を、人間とAIの双方が参照できる短い設計記録へ変換する必要がある。
認知負債をどう測るか
コード生成量を測るのは簡単だ。
コミット数、変更行数、PR数、完了チケット数。AI導入前後の比較もしやすい。
しかし、それらは生産量であって、理解の量ではない。
認知負債を直接測る完全な指標はまだない。それでも、次の兆候は観測できる。
変更内容を担当者が説明するまでの時間。レビュー中に発見される設計上の手戻り。似た原因による障害の再発率。特定の一人しか変更できない領域の数。新しいメンバーが安全に変更できるまでの時間。「理由は分からないが、エージェントがこう書いた」という説明の頻度。小さな変更に対する見積もりの不確実性。
中でも重要なのは、変更へのためらいだ。
コード量は少ないのに、誰も触りたがらない。変更すると何が起こるか予測できず、毎回AIへリポジトリ全体を読み込ませて判断を委ねる。
これは、コードの複雑さだけでなく、チームから理論が失われているサインである。
開発組織がAI導入の成果を評価するなら、「どれだけ多くコードを書いたか」だけでなく、少なくとも次の三つを分けて見る必要がある。
生成速度──コードや変更案を作る速さ。
出荷速度──レビュー、統合、リリースを経て価値を届ける速さ。
吸収速度──チームが変更を理解し、次の判断へ利用できるようになる速さ。
この三つのうち最も遅いものが、長期的な開発速度を決める。
vibe codingは悪なのか
vibe codingそのものが悪いわけではない。
捨てる前提のプロトタイプ、短期間の検証、失敗しても影響が限定される内部ツール、一度限りのデータ処理では、理解を深めるコストをあえて払わない判断も合理的だ。
負債は、必ずしも避けるべきものではない。
問題は、借りていることを認識せず、長期運用する資産へそのまま組み込むことだ。
認証、権限、課金、個人情報、データ移行、並行処理、公開API、セキュリティ境界のように、失敗の影響が大きく、将来の変更可能性が高い領域では、認知負債の金利も高い。
だから、実装前に決めておくべきなのは「AIを使うか」ではない。
このコードに、どの程度の人間の理解が必要かである。
実験用コードなら、「理解しないまま捨てる」という返済方法がある。
本番コードなら、マージ前に理解を吸収する。
将来重要になる可能性があるなら、期限を決めて設計レビューや書き直しを行う。
借金をすることより、借金と知らずに資産だと思い込むことのほうが危険だ。
AIを、人間をループから外すために使わない
AI時代のソフトウェア開発で希少になるのは、タイピング能力ではない。
システムを頭の中で動かす能力、設計の背景を説明する能力、異常から原因を推測する能力、複数の選択肢から未来に耐えるものを選ぶ能力である。
コード生成を自動化すればするほど、人間の役割は実装の外側へ移る。
だが、それは人間がループから消えることを意味しない。
むしろ、要件、設計、検証、観測、学習という、より深い場所へ入ることを意味する。
AIの最も価値ある役割は、コードを書くことだけではない。
説明者になること。反対意見を出すこと。理解度を試すこと。失敗を再現すること。シミュレーターを作ること。人間がシステムについて考えるための新しい道具を作ることだ。
AIがコードを安くした結果、コードそのものは競争優位になりにくくなる。
代わりに重要になるのは、安価に生成されたコードを、どれだけ速く共有された理解へ変換できるかである。
大量のコードを生成したチームが勝つのではない。
生成物を理解し、批判し、変更し、プロダクトの価値へ変換できるチームが勝つ。
コードは数秒で生成できる。
しかし、所有権は自動生成できない。
人間の所有者がいないコードは、マージされた瞬間からレガシーになり得る。
