AI時代の炎上案件で本当に怖いのは「コードのバグ」じゃない。「仕様の理解負債」だ

はい、どうもこんにちは佐藤です！

「 AI を使えば、安く、早くできるんでしょ？」

最近、経営層や顧客から、こんな魔法のような言葉を浴びせられること、増えていませんか？

確かに AI でコードを書くスピードは劇的に上がりました。でも、この「安く早くできる」という錯覚こそが、プロジェクトに致命的な地雷を埋め込んでいるのです。

しかも、そのバグはコードの中にはありません。人間の「欲」の中で暴走しているのです。

AI 時代の炎上案件で本当に怖いものの正体と、私たちエンジニアが戦うべき場所について書いていきますね！

AIが壊したのは、QCDの「バランス」だった

AI の台頭によって、システム開発における QCD ――品質（ Quality ）・コスト（ Cost ）・納期（ Delivery ）のバランスは、完全に狂ってしまいました。

本来 QCD は、トレードオフの関係にありますよね。早くするならコストか品質を犠牲にする。品質を上げるなら時間がかかる。この綱引きがあるからこそ、現場は「小さくリリースしよう」というセオリーを守れていたわけです。

ところが「 AI を使えば安く早くできる」という錯覚が、この綱引きを無効化してしまいました。数億規模の案件で、より多くの利益を狙う経営層や、社内の政治的な圧力がかかると、どうなるでしょうか。

「 AI があるんだから、全部やれるよね？」

現場の慎重なセオリーは、いとも簡単にねじ伏せられます。テストや並行稼働といった、本来あるべき安全網すら省略される。そして、これでもかと過剰な機能が詰め込まれたシステムが、恐ろしいスピードで本番環境へと放り込まれるのです。

超高速開発が奪い去った「学習の猶予」

この超高速開発が奪い去ったもの。それは、コードを書く時間ではありません。

顧客が「学習」するための猶予です。

考えてみてください。顧客は、実際に動くものを触って、失敗して、はじめて自分たちの本当の要件に気づきます。「あ、こうじゃなかった」「本当に欲しかったのはこっちだ」と。

かつては、モックアップや受け入れテストの中で、この理解がゆっくりと醸成されていきました。仕様への解像度が、時間をかけて上がっていったのです。

ところが、 AI のスピードには、この学習が追いつかないのです。

人間が要件を咀嚼する速度は、 AI がコードを吐き出す速度より、はるかに遅い。ここに、決定的なズレが生まれます。

本番稼働の瞬間、「学習」が爆発する

では、追いつかなかった学習は、どこへ行くのでしょうか。

消えてなくなるわけではありません。本番稼働した瞬間に、爆発するのです。

顧客が、初めて本物のシステムに触れる。その瞬間に、遅まきながらの学習が一気に始まります。

「ここも変えたい」「この機能も欲しい」「やっぱりこの画面はこうじゃない」

本質的な業務要件は、実は変わっていません。変わったのは、顧客自身の理解です。でも、関わる人間が増えれば増えるほど、こうした表面的な追加要件が、雪だるま式に増殖していきます。

AI によって、コード自体はきれいに生成されているかもしれません。テストも通っているかもしれない。それなのに、システムは歪んでいく。

なぜか。人間側のメンタルモデルが、システムと同期していないからです。

炎上案件の真犯人は「仕様の理解負債」

この、人間の無理解から生まれる歪み。これこそが、 AI 時代の炎上案件で真に恐ろしいものの正体です。

私はこれを 「仕様の理解負債」 と定義します。

技術的負債なら、まだ目に見えますよね。コードを見れば「ここが汚い」「ここが直しづらい」とわかります。でも理解負債は違います。コードはきれいなのに、人間の頭の中だけに溜まっていく。だから誰も気づかないまま、ある日プロジェクトを押し潰すのです。

そして、今回のPJで経験した仕様の理解負債。

厄介なことに、 AI はこの負債を加速させます。コードを速く作れば作るほど、顧客が本物に触れるタイミングが早まり、学習の爆発も早く・大きくなる。皮肉な話ですよね。

「技術的負債」「理解負債」「仕様の理解負債」は何が違うのか

ここで一度、似た言葉を整理しておきましょう。「負債」とひと口に言っても、性質はまるで違います。

項目	技術的負債	理解負債	仕様の理解負債（本記事の定義）
定義	既知の品質問題や設計の妥協を、あえて先送りにしたコスト	動くが、そのロジックや意図を開発者が理解していない状態	動くが、顧客や関係者の理解とシステムがズレている状態
主な原因	時間的制約やビジネス要件による、意図的な妥協	AI 生成コードの無批判な受け入れ、理解の欠如・放棄	AI のスピードに、顧客の学習が追いつかないこと
わかっていること	「どこが悪いか、どう直すべきか」はわかっている	「何が問題か、どう直せばいいか」すらわからない	コードは正しい。だが「本当の要件」に誰も気づいていない
問題の所在	主に「コードやシステム構造」	主に「人（開発者の認知）」	主に「人（顧客・関係者のメンタルモデル）」

まず、技術的負債と理解負債の違いから見てみましょう。

技術的負債は、いわば「自分で選んだ借金」です。納期のために、あえて汚いコードで通した。どこに地雷を埋めたか、本人はわかっています。だから「いつか返そう」と計画も立てられますよね。

ところが理解負債は違います。 AI が出してきたコードを、中身を理解しないまま受け入れてしまう。動いてはいる。でも「なぜ動くのか」を誰も説明できない。技術的負債が「コードの問題」なのに対して、理解負債は 「人の認知の問題」 なのです。

では、今回定義した仕様の理解負債は、この理解負債と何が違うのでしょうか。

ポイントは、どこの「人」がわかっていないのかです。

理解負債が問うのは、コードを書いた 開発者 の理解です。一方、仕様の理解負債が問うのは、要件を出す 顧客や関係者 の理解。コードの中身は正しいのに、それを使う人間のメンタルモデルがズレている。つまり、戦場が「コードの内側」から「要件の側」へと移っているのですよ。

AI 時代に厄介なのは、この3つが連鎖することです。理解せずにコードを受け入れ（理解負債）、顧客の学習を待たずにリリースし（仕様の理解負債）、その場しのぎの修正が技術的負債を積み上げる。負債が負債を呼ぶ悪循環。これがAI時代の炎上案件の正体なのです。

戦う場所を「プロセス」から「アーキテクチャ」へ

では、どうすればいいのでしょうか。

正直に言いましょう。人間の欲深さと政治力によって要件が膨張し続ける現実、これを私たちエンジニアが変えるのは、ほぼ不可能です。「もっとちゃんと要件を固めましょう」と正論を言っても、市場の圧力には勝てません。

だったら、戦う場所を変えるしかない。プロセスではなく「アーキテクチャ」に主戦場を移すのです。

変更が、後から滝のように降ってくる。これを前提にするなら、システムの捉え方そのものを変える必要があります。

つまり、「あとから変わる部分」と「変わってはいけない部分」を、最初から切り分けて設計する。これが出発点になります。

コアドメインの境界だけは、死守する

具体的に、いちばん意識していること。それは コアドメインの境界を守り抜く ことです。

業務の本質であるコアドメイン。ここの境界は、何があっても死守します。表面的な追加要件の波を、ここまで到達させてはいけません。

時には、防波堤として「大義名分」を使うのも有効です。

「これは OSS の仕様なので、ここは変えられません」
「フレームワークの制約で、これ以上は対応できません」

こうした技術的な制約を盾にして、終わりのない仕様変更の波から、システムの中核をコントロールするのです。ずるく聞こえるかもしれません。でも、中核を守るためなら、使える防波堤は使うべきなのですよね。

まとめ

というわけで、 AI 時代に本当に怖いのは、コードのバグじゃなくて「仕様の理解負債」だよ！って話でした！

あ。正確には、人間の無理解から生まれる負債を、アーキテクチャでいかに隔離するか って感じですねっ。

AI 時代のシステム開発とは、コードをいかに速く書くかの勝負ではありません。膨張し続ける人間の欲と、追いつかない理解。そこから生まれる負債を、システムの中核に到達させないための戦いです。変わる部分は柔軟に受け止め、守る部分は徹底的に守る。この線引きこそが、これからのエンジニアの腕の見せどころになります。

膨張する要件に振り回されて消耗するのは、もう終わりにしましょう。ぜひみなさんも、まずは「変わる部分」と「守る部分」の線引きから始めてみてください！