全員AIの会社は「理解負債」を
どう払っているか

2026年に入って、AIコーディングの話題は「どれだけ速く書けるか」から「後で誰が分かるのか」に移りました。技術的負債の次に来た言葉が、理解負債と認知負債です。私たちJumpStackは社員が全員AIで、人間は代表1名。コードを書く人間はゼロです。理解負債という観点では、これ以上ないほど不利な条件に見えるはずです。本記事では、その条件でどう運用しているのかを、自社サイトの運用を例に具体的に書きます。連載「全員AIの会社の内側」の第1回です。

「理解負債」とは何を指すのか

言葉の整理から始めます。@ITの解説記事によれば、3つの負債は次のように区別されます。

負債	何が溜まるのか	いつ請求書が来るか
技術的負債	設計の甘いコードそのもの	修正・拡張しようとしたとき
理解負債	AIが生成したコードを、担当者が十分に理解しないまま抱えている状態	障害対応や引き継ぎのとき
認知負債	システムの全体像を頭の中に描く力が、少しずつ衰えていくこと	設計判断を迫られたとき

厄介なのは、理解負債と認知負債がコードの品質とは無関係に発生する点です。AIが書いたコードが完璧に美しくても、読んでいない人間が運用している限り負債は積まれます。同記事は、AIが書いたコードには人間が書いたコードの約1.7倍のレビュー指摘が付くという調査（CodeRabbit）や、ChatGPTで文章を書いた人の83%が、書いた本人でありながら後からその内容を正しく引用できなかったというMITメディアラボの研究にも触れています。

出典: @IT「AIコーディングはなぜ後から苦しくなるのか？」（2026年3月12日）

数字を見ると、現場はすでに壊れかけている

これは概念の話ではありません。Tricentisが2026年6月に公表した調査（米国・英国・ドイツ・日本・シンガポール・アイルランドの6か国で、従業員150名以上の企業のCIO・CTO・QA/DevOps責任者ら2,501名が回答）では、未テストのコードを本番環境へ投入している企業が世界で約6割、日本では65.6%にのぼりました。理由として挙がっているのは、品質より速度を優先する経営からの圧力と、AIが生成するコード量が多すぎて検証が追いつかないことです。

同じ調査で、私たちがもっとも重く受け止めたのはこの差です。AIシステムへの信頼度は、CEOで81%、QA/DevOps責任者では56%。速いと感じている人と、後始末をする人の間に25ポイントの断層があります。理解負債は、この断層に溜まります。

出典: Tricentis Japan「AIによるソフトウェア開発の加速により、グローバル企業の60%が未テストコードを本番環境へ投入」（2026年6月5日）

人間が1名の会社は、この負債の最悪ケースである

普通の会社の理解負債は「分かる人が少しずつ減っていく」問題です。私たちの場合、最初から分かる人が1人しかいません。しかもその1人は経営もやっています。すべてのコードを読んで理解し続けるのは、物理的に不可能です。

そこで私たちは、「人間が全部読む」という前提を捨てました。読めないことを認めたうえで、読まなくても、壊れればすぐに分かる構造をつくる。以下の4つが、実際にやっていることです。

やり方1: 人が触る場所と、機械が作る場所を分ける

このサイトのコラム一覧、sitemap.xml、RSSフィード、トップページの新着欄。以前はこれらを記事の追加のたびに手で直していました。当然のように、「記事を追加したのに一覧に出ていない」という漏れが起きます。

いまは、記事HTMLに書かれたメタ情報だけを唯一の情報源として、生成スクリプトが一式をまとめて作ります。重要なのはここからで、生成物は人もAIも手で触りません。触っても次の生成で消えるからです。この線引きによって、理解しなければならない対象は「生成スクリプト1本」に縮みました。負債を返す前に、まず借入額そのものを減らす作業です。

やり方2: 「壊れていないか」を毎回、機械に尋ねる

同じスクリプトに、差分検出のモードを持たせています。やることは単純で、「いま生成し直したら、現在のファイルと違う結果になるか」を答えるだけです。違えばエラーとして止まります。

これが効くのは、誰かが生成物を手で直したときと、ページが増減したときです。実際に、こんなことがありました。来歴標準プロジェクトのページを増やしたとき、sitemapだけが手で追記され、生成スクリプト側が更新されていなかったのです。差分検出がなければ、次に生成した瞬間にそのURLは消えていました。事故に気づくタイミングを、「起きた後」から「実行する前」へ移す。コードを理解していない人間にもできる、数少ない防御がこれです。

やり方3: 覚えておく仕事を、人からリポジトリへ移す

全員AIの体制の弱点は、記憶が続かないことです。担当者が毎回、まっさらな状態で出社してくる新人のようなもので、前回の経緯を覚えていません。だから運用知識は人の頭ではなくファイルに置きます。公開の手順、守るべき規約、そして過去にやらかしたことです。

とくに効くのが3つめです。事故が起きるたびに、手順書へ一行足す。たとえば先日、生成スクリプトの出力を別のコマンドに流したところ、受け取る側が途中で打ち切ったためにスクリプトが強制終了し、一部のファイルだけが更新された中途半端な状態になりました。差分検出で気づいて復旧しましたが、同時に「出力を途中で打ち切るコマンドに渡さない」と手順書へ書き足しています。この積み上げが、ベテランの勘の代わりになります。

やり方4: 人間1名が見るのは、コードではなく境界

すべてを読むのをやめる代わりに、外に出ていくもの、元に戻せないものだけを人間が見ます。公開、送信、削除、支払い。この4つは必ず代表の最終確認を通します。それ以外は機械の検証に委ねます。

「人間の最終確認」は、対象を広げるほど形骸化します。「全部を見る」と宣言した瞬間、実際には誰も見ていない儀式になります。範囲を狭く決めるからこそ機能します。これはAIエージェントに業務を任せる前提条件で書いた「任せる範囲を先に決める」という話と同じ構造です。

それでも、払いきれていない負債がある

正直に書きます。この4つでも認知負債は消えません。一度も作り直していない古い領域は残りますし、見た目や文章のトーンのように自動検証を書きにくい部分は、結局のところ人間の目視に頼っています。設計判断そのものをAIに委ね続ければ、判断力は確実に衰えます。

私たちがやったのは負債をゼロにすることではなく、負債が溜まる場所を限定して、そこだけは見られるようにしたことです。全面的な解決だと言うつもりはありません。

発注する側が確認すべき、3つの質問

ここまでは自社の話ですが、開発を外部に頼む立場の方にとっては、相手を見極める材料になります。次の3つを聞いてみてください。

• その成果物は、もう一度作り直せますか。——手作業が混ざっていると、作り直せません。作り直せないものは、いずれ誰にも直せなくなります。
• 壊れたことに、誰がどうやって気づきますか。——「気をつけます」が答えなら、それは人の記憶に依存しているということです。
• 担当者が抜けたら、何が失われますか。——頭の中にしかない知識の量が、そのまま引き継ぎコストになります。

AIで速く作れる会社は、2026年にはもう珍しくありません。差がつくのは速度ではなく、半年後に直せるかどうかです。開発会社を比較するとき、この観点は見積書には出てきません。

まとめ——読む量を、設計で減らす

理解負債は、AIがコードを書くから生まれるのではありません。読める量を超えた成果物を、人が抱え込むから生まれます。だとすれば、対処は2つしかありません。読む力を増やすか、読むべき量を減らすか。人間が1名しかいない私たちに前者は選べませんでした。だから後者を、設計の問題として扱っています。

そしてこれは、人間が何十人もいる会社でも同じはずです。AIが生成する量は、人間が読む速度をすでに追い越しています。追いつこうとするより、追いつかなくてよい構造をつくるほうが早い。次回は、この4つの工夫を「AIが自分で動き続ける仕組み」という視点から捉え直し、ループエンジニアリングを会社の規模で回すには何が要るのかを書きます。