そもそも技術的負債とは何か？
原義と巷の認識がズレている点から踏まえる必要があります。
原義
原義は Ward Cunningham が提起したもので、問題領域との理解のズレを指します。問題を正しく捉えた「理想」と、今現在の理解（特にコードに落とし込まれた「現状」）とのズレです。ですので、コードの綺麗さや拡張性といった目線よりも、顧客の声やドメインを理解しているかどうかが争点になります。
難しいのは、顧客の声が正しいといった単一不変な正解が無いことです。むしろ顧客の声が正しいとも限りません。終わりのない旅のようなもので、理想をどこに据えるかは未解決問題だと思います。どちらかといえば理想とは「継続的な学習プロセスと、そこから生み出されたその時点での最適解」だと考えます。
※余談ですが、理想が変わればズレてしまうので、世の中が変わったり顧客の意識が変わったりするだけでもズレることになります。だからこそ、継続的に学習してズレを詰めていくのが最適だと思います。
巷の認識
次に巷の認識ですが、コードの綺麗さや拡張性の「無さ」という狭義な方に向いています。Martin Fowler は内部品質の欠陥を指す比喩と位置づけています。新機能追加にかかる労力がその負債の利子にあたる、というたとえです。
コードが汚いと、それだけ改造に労力がかかる（返す利子が多くなる）――つまり汚いほど負債が増えるという比喩です。
「原義」は「巷の認識」も含む
原義の方が広義であり、汚いほど負債が増えるという狭義も含んでいます。なぜなら、「理想」に近づいて「現状」に反映していくためには、継続的にコードを変えねばならないからです。変える労力の少なさがモノを言います。
もう少し言えば、以下の 4 層で整理できると考えます。
- 理解の層：理想を理解する
- 表現の層：理解をコードに落とし込む
- 構造の層：落とし込みやすくする
- 運用の層：変更を継続的に届ける
AI時代で技術的負債がどう変わるか
前提を押さえたので本題に入っていきます。
この問いは、AI 時代で上記の 4 層がどう変化したかを論じれば良いでしょう。
理解の層：理想を理解する
理解の層については、プロトタイプレベルでは早くつくれるようになりました。顧客やメンバーに 早く実物を見せられるようになった と言えます。
一方で、つくったものをそのとおりに受け取って採用するほど単純でもなく、説明責任や採用に向けた調整は引き続き生じます。プロトタイプを使ってもらえるならそれでいい（結果を計測すればいい）ですが、そう単純でもないでしょう。現実はプロトタイプを使ってもらうことさえ困難ですし、プロト以上の PoC、PoC 以上の本番適用となると、さらに困難です。
この問題は、以下ページがうまく言っていると思います。
U理論の文脈ですが、イノベーションに限らず言えることだと考えます。
- これまで: 泥臭く皆と対話しながらつくっていた。つくるのも遅かったが対話も多かった
- これから: AI で早く作れるようになったおかげで、対話の量自体も減った
現実は複雑であり、機械ではない人間が回している以上、そこにソフトウェアやプロセスを差し込むには相応の会話や調整、場合によっては儀式を要します。また日本含む一部の国では、文化として信頼が関係ベースなので「一緒に過ごして関係を育む」営みそのものが求められます（Erin Meyer の異文化理解力）。早くつくれるだけではカバーできません。
まとめ: プロトタイプレベルという実物を早くつくれるようになっただけで、あまり変わっていない。
表現の層：理解をコードに落とし込む
表現の層については、上記でも書いたとおり、AI ですぐつくれるようになりました。
一方で、AI の出力が正しいとは限らず、人間によるレビューも必要です。レビューできるだけの力がないと、思考停止して捨てるか受け入れるかしかできません。
求められるスキルや能力も変わってきています。プロンプトのチューニングや、AI を意図通りに安定して動作させるためのハーネスとコンテキストの制御、さらには（クラウドもそうですが）コスト管理やセキュリティまで、より高級な問題を扱わなければならなくなりました。AWS の仕様と動向を把握しにいくように、Claude Code のそれらを把握しなければならなかったりしますし、プロンプトについては「自然言語によるプログラミング」とたとえられたりもします。
別の潮流として、人間の不介入――AI エージェントによる自律性を増やす潮流も盛り上がっています。Ralph を始めとするフレームワークも多数ありますし、AutoAgent のように自己改善を備えたものも出てきています。
まとめ：人間のレビューは必要だが、AI につくらせることができるので従来より早い。
構造の層：落とし込みやすくする
拡張性の話です。
従来は人間がコードを読み書きしていたので、人間が読めるコードでないとそもそも拡張できませんでした。技術的負債の認識が狭義になるのも納得です。優れたエンジニアなら汚いまま書いていけますが、頭の中には綺麗なモデルがあります。拡張性を自身の頭の良さで補っているだけです。
そう考えると、拡張性を司る「綺麗さ」には設計（モデル）と実装（コード）があることがわかります。設計は少なくとも綺麗でないといけない。しかし、コードは設計を表現できるなら汚くてもいい。
コードがどれだけ汚くても許容できるかは、人次第でしょう。ある種の頭が良い人は相当汚くてもなんとかなります。変数名を a, x, y1 など適当に短くつけたコードで 10KL 以上をつくれる人もいますし、私のように関数名一つ考えるのに一時間以上使うような潔癖な人もいます。もちろん、皆で一つのコードを触るチームプレイの場合は、皆が理解できないといけないので許容は狭くなります。
話を AI に戻すと、AI によりコードの汚さを気にしなくてもよくなりました。実際、私も AI につくらせるときは汚さなど気にしません。必要なら中身を追ったり一部書き換えたりもしますが、普段はブラックボックステスト的に振る舞いが良さそうならそれでいいよスタンスです。
しかし、これはコードの話にすぎず、綺麗な設計をつくる部分は何も変わっていません。理解の層と同じ議論になりますが、人間が泥臭く書きながら試行錯誤することで設計も洗練されるところがありました。AI 出力だとその過程がなく、設計の洗練ができません。できないというか、全く違ったやり方になります。
- これまで: 人間が書きながら探索し、人間が書いて反映する
- これから: AI の出力を見て把握し、AI に指示を与えて反映させる
まとめ：コードの汚さは気にしなくても良くなったが、設計の汚さは引き続き気にする必要がある。
運用の層：変更を継続的に届ける
キーワードで言えばテスト、ビルド、デプロイ、またそれらに継続性を与える CI/CD やモニタリングといった話のことです。原義を踏まえるなら、実際に顧客に届けて、その様子や感触をフィードバックしてもらって――まで考えることになりますが、さすがに広すぎるので割愛します。デプロイするところまで、としておきましょう。
いくら理解も表現も構造も完璧だとしても、届けるのが半年に一回だと遅すぎます。逆に第三層までが雑だったとしても、一日一回届けられるなら、フィードバックループもそれなりに回せるのでズレも埋めていけます。
運用も AI の恩恵が大きい層です。テストコード、設定ファイル、コマンドラインを AI に書かせればいいからです。もちろん正しいとは限らないため、人間によるレビューが要ります。
まとめ：人間のレビューは必要だが、AI につくらせることができるので従来より早い。
まとめ
- プロトタイプレベルの実物を早く見せられること → 理解の層で効くが、プロトタイプだけで理解が完結するわけではなく限定的
- コードの実装と運用の省力化を早く行えること → 表現の層と運用の層が楽になるが、人間のレビューは必要
- コードの汚さを気にしなくても良くなったこと → 構造の層で効くが、設計の綺麗さとは引き続き向き合う必要がある上、向き合い方も変わる
AI時代で技術的負債を減らすには
上記を踏まえると、以下の戦略が考えられます。
- 1: AI 出力前提で設計を綺麗に保つ
- 2: 人間によるレビューの配分と役割を再考する
- 3: プロトタイプを対話の道具に昇格させる
以下、それぞれ詳しく見ていきます。
1: AI 出力前提で設計を綺麗に保つ
現在の主流は仕様駆動開発（Spec-Driven Development, SDD）だと思います。
ソフトウェアの本体はコードではなくドキュメント であり、AI には常にドキュメントからコードを書かせるようにします。こうすれば AI が出力したコードも（ドキュメントに基づいているという意味で）一貫していますし、ドキュメントは人間にとっても読みやすく書きやすいため、レビューや調整もしやすい。
一方で、すでに書いたとおり、開発体験としては従来と変わる点に注意したいところです。これまではコードを書いて動かしてを繰り返す中で設計についても考えていましたが、仕様駆動開発ではコードを書くことがなくなり、動かしながら設計も考えることになります。「コードを書きながら」という体験を伴わない のです。
アーリーアダプター的に新しいものを「使う」のが得意なエンジニアには慣れたことですが、そうではなく、自身で書きながら学んでいくタイプのエンジニアにとっては苦戦を強いられます。たとえるならプレーヤーとして設計をするのではなく、マネージャーとして設計をすることになるわけです。とはいえ、コードを書かないだけで、ドキュメントは書くので、本当に何も書かないわけではない。プログラミング言語が自然言語になった、という言い方もよくしますね。
2: 人間によるレビューの配分と役割を再考する
AI が出力したソフトウェアや運用向けコードをそのまま使うわけにはいかないので、人間がレビューをします。また出力量が多い上に速いので、レビューにかける手間も多くなります。
この レビュー比重の上昇は、仕様駆動開発に並ぶインパクト だと思います。従来の発想ではとてもじゃないですが捌ききれないので、発想を転換――具体的には配分と役割を再考せねばなりません。
まず配分については、以下の二点です:
- レビューに費やす比重を増やす。例: 週 4 時間 → 週 20 時間
- レビュー観点の配分を変える。例: 構文や実装の詳細を見る → アーキテクチャ、ビジネスロジック、保守性を見る
比重の数字は適当な例ですが、レビュー時間が 5 倍になったと言われても違和感はありませんし、リードやスタッフなど上級でない場合は 10 倍以上もありえると思います（2 時間 → 20 時間とか）。
観点については、従来でも静的に解析・統一出来る部分は Linter や Formatter で自動化してしまうのが筋でしたが、AI 時代は一部の動的な部分――もっと言えば「どうつくるか」は任せてしまえます。その分、人間は何をつくったか、なぜそうなったのかのレビューに注力したいです。
次に役割については、たとえば以下が考えられます:
- AI エージェントを立ち上げて、レビューの一部を担わせる
- レビュー対象物の見せ方は、事前に構造化して指定する
- 修正戦略を AI に任せる
従来はレビュアー側が実力者であり、レビュアーが導く構図になりがちでしたが、AI 時代では AI にどれだけ委譲できるかが鍵になります。たとえば PR を AI エージェントに一次処理させたり、修正戦略を人間が全部考えるのではなくまずは AI にやらせてみたりといったことはすでに現場で採用されているかと思います。
個人的に最も効くのはレビュープロセスとフォーマットの整備だと思います。人間のレビュアーにとってやりやすく、読みやすく、過不足のない形で PR してもらえるよう、人間側でチューニングしていくのです。特にフォーマットは人によって最適解が異なるので、レビュアーの数だけ用意しても良い。A さん用フォーマット、B さん用フォーマットがあって使い分ければいいのです。そうすることで A さん、B さんそれぞれのレビューが行われて、レビュー全体が多角的になります。
3: プロトタイプを対話の道具に昇格させる
理解の層はプロトタイプだけで済むほど単純ではないが、AI でプロトタイプを早くつくれるのは事実――ならばプロトタイプを使う比重を増やせばいいのです。もっと言えば、デフォルトの選択肢に据えます。その意味で "道具に昇格" と書きました。
Teams や Slack といったビジネスチャットは、すでに道具化していると思います。基本的に社員全員が問題なく使えるはずですし、使えない人は採用されないか、使えるまでトレーニングされるはずです。これと同じだと考えてください。つまり 社員全員が（プロトタイプをつくれるよう）AI を使えるようになる のがスタートラインです。
無論、これが現実的に厳しいことは承知していますが、昇格させるとはそういうことです。すでに社員全員が使えるビジネスチャットですら、（使えはするが）まだまだ定着していないのが実情のはず。まして全員使える環境ですらないなら、定着など絶望的です。これは DX と同じ構図であり、予算と権限を握る経営層が投資できるか（スタートラインに立てるか）どうかがすべてです。
現実的には、まずは小さな範囲で昇格していくことになります。チーム内全員、部門内全員などですね。この場合はマネージャーや部門長が投資できるかどうかがすべてと言えます。
そうしてスタートラインに立った後も、プロトタイプを日頃から使えるようになるまでの道のりは遠いですが、このあたりも取り上げると書籍になってしまうので割愛します。かんたんに書いておくと、
- プロトタイプをつくる素養を身につけるには？
- トップダウンでつくりかたや見せ方を教育して鍛える
- 自由時間と余裕を確保して好きに遊ばせて慣れさせる
- ...
- コミュニケーションにおいてどう使うか？
- 資料様式の追加。資料として「文書」「スライド」だけでなく「プロトタイプ」が追加される
- プロトタイプ作成時間の確保。資料作成：会議 = 2：8 が、資料作成：プロトタイプ作成：会議 = 1：4：5 になるなど
- ...
- ...
私はプロトタイプ・ベースド・コミュニケーションと呼んでいますが、カジュアルなコミュニケーションの中で「プロトタイプ」が登場するモデルを描いています。現時点でわかりやすいたとえは、LT で使うような軽いスライドと同じ感じでプロトタイプを出す、というものです。
一方で、プロトタイプ偏重に懐疑的な自分もいます。関係ベースの信頼という日本の文化は変わらずありますし、U 理論その他様々な理論が述べているとおり、つくって見せるだけで済むほど単純な営みでもない。また、普段言語化や構造化を生かす私としては、AI 時代だからこそ濃い言語化をつくって読み書きするコミュニケーションの仕方も重要と考えています。
このあたりはまだ答えが出ていない領域と考えます。今現在も、世界中で様々な学際的アプローチが動いているかと思います。本記事としては、論理的に「プロトタイプを使う比重を上げればいいのでは」との前提に立った上で、まずはスタートラインに立つのが最重要とのスタンスで、この書き方にしました。
おわりに
AI 時代の技術的負債について考えてみました。
まず原義をおさらいしました。単にコードの汚さや拡張性の問題ではなく、理想と現状のズレを扱うものでした。
次に技術的負債を 4 層で整理しました。理解して（理解の層）、コードに落とし込んで（表現の層）、落とし込みやすくして（構造の層）、届けやすくする（運用の層）。各層について、AI 時代にどのように変化したかを見ていきました。
そして最後に、負債を減らすためのアプローチを 3 点ご紹介しました。コードではなくドキュメントが原典になること、レビューの配分と役割が変わること、また現時点での有効性はまだ見えないがプロトタイプを対話の道具として当たり前に使えるようにすること――いずれもパラダイムシフトと呼べるほどの、大きな転換だと思います。
転換に適応していくことで、負債とも付き合っていけるということでしょうか。私自身も答えなどなく、日々楽しみつつ苦しみながら模索する日々ですが、本記事が何かしら参考になりましたら幸いです。