認知負債 - バイブコーディング時代の新しい負債管理法

Sat, 18 Jul 2026 10:00:00 +0900

「最初のリリースコードを出荷することは、借金をするようなものだ。少しの借金は開発を加速する。期限どおりに返済しさえすれば。」 — Ward Cunningham, OOPSLA ‘92¹

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディングで仕事をしていると、奇妙な瞬間が訪れます。間違いなく自分のプロジェクトなのに、コードを開いてみると他人の家のようです。エージェントが設計し、エージェントが実装し、私は承認ボタンを押しました。仕事は早く終わりました。ところが障害が起きると、こう言うことになります。「この問題はなぜ起きたのでしょう？ AIが作ったものなので、よく分からないんです。」

これが認知負債（cognitive debt）です。コードは積み上がるのに、理解は積み上がらない。その格差が借金です。

この用語は誇張ではありません。2025年、MIT Media Labの研究チームは、エッセイを書く人々の脳をEEGで測定しました。LLMを使ったグループは脳の結合性が最も弱く、自分が書いた文章をきちんと引用できず、自分の文章だという所有感も最も低いという結果でした。このパターンはAIの使用を中断した後も続きました。研究チームはこの現象に「認知負債」という名前を付けました。² コード側のデータも方向は同じです。GitClearが2億行以上のコミットを分析したところ、AIアシスタントが広まった期間に、コピー＆ペーストのコードは増え、リファクタリングは半分以下に減っていました。³ 成果物は速くなりました。理解と整理は後回しにされたのです。

人を挟めば解決するのか

この問題を前にしてよく出てくる処方が human-in-the-loop です。すべての成果物を人がレビューしようというものです。聞こえは良いです。現実には機能しません。

理由は単純です。エージェントは人よりはるかに速く作ります。人が毎回関与すれば、人がボトルネックになります。ボトルネックになった人は時間に追われます。追われていると、中身を見ずに承認ボタンだけを押すようになります。レビューは形式になり、形式になったレビューは錯覚を生みます。「人が見たのだから大丈夫だ」という錯覚です。誰も見なかった場合より悪いこともあります。

これは新しい発見ではありません。自動化研究は40年前にすでに結論を出しています。Bainbridgeは1983年の論文で自動化の皮肉を指摘しました。自動化が進むほど、人は技能を練習する機会を失います。残る仕事は退屈な監視です。ところが実際に人が介入しなければならない瞬間は、最も困難な瞬間なのです。⁴ 後続の研究は、自動化への安住（automation complacency）が初心者だけの問題ではないことも確認しました。専門家も同じように安住し、訓練や指示ではなかなか直りません。⁵

体感も当てになりません。METRが2025年に熟練したオープンソース開発者を対象にランダム化比較試験を行いました。AIツールを使った開発者は実際には19%遅くなっていたのに、本人たちは20%速くなったと感じていました。⁶ 自分が理解しているという感覚と、実際の理解との格差。認知負債はまさにその格差の中で育ちます。

負債はなくすものではなく、管理するものだ

では、どうすればよいのか。私は認知負債を技術的負債（technical debt）と同じやり方で扱おうと主張したいと思います。

技術的負債という言葉を最初に作ったWard Cunninghamは、負債を悪と規定しませんでした。むしろ逆です。少しの借金は開発を加速する。問題は借金そのものではなく、返さずに放置したときに付く利子です。¹ 認知負債も同じです。AIが生成したすべてのコードを人が完全に理解し説明できなければならないという要求は非現実的です。その要求を真に受けた瞬間、AIを使う意味が消えます。負債をゼロにしようとする試みは失敗します。目標はゼロではなく、適正水準です。

適正水準とは何か。いつでも求められれば、一定の深さまでは説明できる状態です。すべての関数を暗記している必要はありません。しかし、システムがなぜこういう形になっているのか、どこが危険なのか、何が観測されれば設計が失敗したことになるのかは言えなければなりません。その線より下に理解が落ちたら、借金を返すべきです。

問題は方法です。私は三つを使う、あるいは提案します。

第一に、小テスト

設計や実装が終わったのに、自分が今何を作ったのかよく分からない、という感覚に襲われることがあります。その瞬間が借金を返す瞬間です。私はこういうとき、エージェントに小テストを要求します。アイデアレベルの話ではありません。実際にスキルとして作って使っています。

核心となる原則は一つです。答えは常に自分の口から出なければならない。エージェントが説明してくれれば楽です。そして役に立ちません。説明を聞くと理解したと錯覚するからです。錯覚したまま負債はそのまま残ります。だからこのテストは採点ではなくインタビューです。エージェントはオープンな質問を一つ投げます。「なぜ代替案Xではなくこの方式なのか？」「この部分がなければ何が壊れるのか？」私の答えを聞き、ギャップが露わになった地点を選んで追加質問を投げます。次の質問はあらかじめ決まっていません。直前の私の答えが決めます。同じギャップが2回の追加質問でも解けなければ、そのとき初めて解説が出てきます。

抜け落ちたものをすぐには教えてもくれません。「もう一段階あるのですが、何が抜けているでしょうか？」と想起を要求します。居心地が悪いです。居心地が悪いのが正常です。借金を返す仕事が楽だったことはありません。

第二に、文芸的コードdiff

Knuthは1984年に文芸的プログラミング（literate programming）を提案してこう述べました。プログラム作成の主たる任務を、コンピュータに指示することではなく、コンピュータに何をしてほしいのかを人間に説明することへと変えよう。⁷ この観点をディフ（diff）に適用したのが文芸的コードdiffです。

一般的なコードレビュー画面は、変更されたファイルの羅列です。ファイルの順序はアルファベット順で、変更の論理的な順序とは無関係です。レビュアーは断片化された変更を頭の中で再組み立てしなければなりません。エージェントが作った大きな変更を前にすると、この再組み立てはしばしば放棄されます。そして承認ボタンが押されます。

文芸的コードdiffは順序をひっくり返します。変更を概念の順序に並べ、各段階に説明を付けます。「まずリポジトリのインターフェースを変えた。なぜなら。次に呼び出し側を直した。なぜなら。」読む人は変更を一つの物語として追っていきます。私はこの文書をリリースノートのように保守するのも良いと考えています。PRごとに文芸的diff文書を一つずつ作り、READMEにインデックスを置いてアクセス性を保つ、という具合です。コードベースの歴史が「誰がいつ何を変えた」ではなく「なぜこうなった」として残ります。

第三に、叙述型の文書

AIが吐き出す文書はほとんどが箇条書きです。ビュレットポイントが整列した文書は一目で頭に入ります。それが長所であり、罠でもあります。一目で入ってくるがゆえに、読んだと錯覚しやすく、論理が抜けている箇所も目に留まりません。そしてすぐに忘れられます。

Amazonはこれを会社レベルで実験しました。ベゾスは2004年の役員会議でパワーポイントを禁止し、叙述型のメモを導入しました。理由が的確です。良い叙述型メモを書くのが難しいのは、叙述の構造が、何がより重要でどう繋がっているのかについてのより良い思考を強制するからです。⁸ 読む側も同じです。叙述型は箇条書きより読むのに時間がかかります。その代わり物語として読むので、論理の切れ目が露わになり、読んだ内容が長く残ります。

ADR（Architecture Decision Record）で比較してみましょう。箇条書きのADRはこんな形です。

## 決定: セッションストアをRedisへ移行
- 現状: DBセッションテーブルのボトルネック
- 代替案: Memcached, DynamoDB, Redis
- 選択: Redis
- 根拠: TTLサポート、運用経験あり

すっきりしています。そして何も検証できません。ボトルネックがどれほど深刻だったのか、Memcachedはなぜ脱落したのか、「運用経験あり」が決定を正当化するほど重要な条件だったのか、この文書は何も語りません。同じ決定を叙述型で書くとこうなります。