負債の理解: クリーンなAIコードが悪いコードよりも危険な理由

要点:AIからの最も恐ろしい出力は、バグのあるコードではありません。それはクリーンで、正確で、十分にテストされたコードが間違った問題を解決することです。私はこれを理解の負債と呼びます—AIが生成するものと、あなたが実際に理解するものとの間のギャップです。従来の技術的負債は目に見えました：乱雑なコード、失敗するテスト、明らかな匂い。理解の負債は目に見えません：優雅なアーキテクチャ、合格するテスト、そして最終的に爆発したときに誰もデバッグできないシステムです。FableとGPT-5.6を使った重い開発の後、私は新しいワークフローに収束しました：目標 → 仕様 → アーキテクチャ図 → エージェント実行。仕様は新しいソースコードです。エンジニアの価値はもはやタイピングにありません。それは、何がすべきかを知るために十分に明確に考えることにあります。構築される。

ここはジェームズ、マーキュリーテクノロジーソリューションズのCEOです。 東京のオフィスから — 2026年7月

私は先週、2つの最前線モデル、FableとGPT-5.6の集中的な開発に取り組んできました。カジュアルなプロンプトではありません。実際のシステムを構築し、実際のエッジケースをデバッグし、実際の機能を出荷するための深い、数時間にわたるセッションです。

結論は？どのモデルが「優れている」かではありません。どちらも素晴らしいです。どちらも恐ろしいです。そして、どちらも今週まで完全には理解していなかったことを明らかにしました：AIエラーの性質は根本的に変わりました。

旧エラー vs 新エラー

GPT-3.5および初期のGPT-4時代では、AIエラーは明白でした。 コードは乱雑でした。論理に欠陥がありました。テストは失敗しました。出力を読めば、数秒以内に何かが間違っていることがわかりました。AIはスパゲッティを生成し、あなたはその絡まりを見抜ける人間でした。

あなたの役割は明確でした：出力を判断し、ごみを拒否し、書き直しを求める。人間が仲裁者として。人間が品質ゲートとして。AIが生成し、あなたがキュレーションしました。

その時代は終わりました。

FableとGPT-5.6では、コードはクリーン。論理は健全です。テストは合格しています。ドキュメントは存在します。アーキテクチャはシニアエンジニアが期待するパターンに従っています。すべてが...正しいように見えます。

しかし、それは間違っています。根本的に、方向性が間違っています。システムは要求されたことを正確に実行しますが、要求されたことは実際の問題を解決しませんでした。AIは構文を誤解しませんでした。APIを幻覚することもありませんでした。あなたの指示に完璧に従いました—そしてあなたの指示は現実と微妙に、壊滅的に不一致でした。

古いエラーは粗野でした。新しいエラーはエレガントです。古いエラーは目に見えました。新しいエラーは目に見えません。古いエラーはバグでした。新しいエラーはデザインです。

これが私が呼ぶものです理解の負債。

技術的負債 vs. 理解の負債

技術的負債は馴染みのある概念です。迅速に出荷するために、迅速で汚いコードを書きます。コードは動作しますが、保守が難しいです。いつかリファクタリングします。コードが臭うので、誰もが埋まっている場所を知っています。

負債を理解することは異なります。コードは臭いません。それは臭います素晴らしい。それはリンティングされ、フォーマットされ、文書化されています。しかし、ここに重要な違いがあります：誰もなぜそのように設計されたのかを知りません。

それを書いたAIも—AIはプロンプトの文脈を超えた意図の記憶を持っていません。それを依頼した人間も—なぜならその人間はそれを書いていないからで、「私は欲しいものを説明した」と「私は何が構築されたかを理解している」の間のギャップは時間とともに広がっています。プロジェクトに6ヶ月後に参加するエンジニアも—なぜなら推論の痕跡がなく、決定のコミット履歴がなく、なぜこのアーキテクチャが代替案よりも選ばれたのかを示す進化の道がないからです。

それが壊れたとき—そして壊れます、すべてのシステムは壊れるからです—誰もどこから始めるべきかわかりません。コードはクリーンなので、明らかな感染点はありません。論理は健全なので、明確な誤謬はありません。問題はより深いです：設計自体は、生成時に完全には理解されていなかったコンテキストに対して微妙に間違っていました。

そして、ここが残酷な部分です：AIの生産速度は今や人間の理解速度を大幅に上回っています。このギャップは静的ではありません。毎日広がっています。AIに構築させればさせるほど、あなたが所有しているものを理解できなくなります。理解が少なくなるほど、あなたのシステムはより脆弱になります。脆弱になるほど、それを修正するためにAIが必要になります—負債のスパイラルを加速させます。

これは、先月INCOSEで私が提示したVモデルのシフトです。従来のVモデルは、理解が実装の副産物であると仮定していました。設計し、コーディングし、テストを行い、そのプロセスを通じて、あなたはシステムを学ぶのです。コードはアーティファクトでしたが、理解は副作用でした。

AIはこの仮定を壊します。AIがコードを書くと、理解はもはや副作用ではありません。それは必ず明示的な入力。AIが構築する前に意図的に理解を構築しないと、その後理解できません。コードは理解なしに存在します。そして、それが理解の負債です。

新しいワークフロー: 目標 → 仕様 → アーキテクチャ → 実行

これにどう対抗しますか？私はFableとGPT-5.6との数十回の反復の後、4段階のワークフローに収束しました。どの段階もスキップすると、理解の負債が蓄積します。

フェーズ1: 目標を定義する

あなたはどの問題を解決していますか？それは成功基準より重要なことは:絶対に壊れないものは何ですか？不変条件、制約、交渉不可能なものは何ですか？

ほとんどのAIプロンプトはこれをスキップします。「機能を作ってください」と飛びつきます。しかし、目標がなければ、AIには北極星がありません。AIはグローバルな意図から漂流しながら、ローカルな正確性を最適化します。あなたはより速い馬を求めましたが、美しい馬を作りました。あなたが必要だったのは車です。

フェーズ2：仕様を書く

これは最も重要なフェーズです。仕様は願望リストではありません。それは契約です。それはシステムが何をするか、何をしないか、完了がどのように見えるか、そして境界が何であるかを定義します。

私は今、仕様を新しいソースコードとして扱っています。比喩的にではなく、文字通りです。仕様は最初にバージョン管理に入るアーティファクトです。仕様はレビューされるものです。仕様はチームが議論するものです。仕様は人間とAIの両方が参照する単一の真実のソースです。

仕様がなければ、AIエージェントに指示を与えることは「北に行け」と言うようなものです。エージェントはできるだけ早く北に走ります。走れば走るほど、実際の目的地からそれていきます—なぜなら、あなたは住所を与えず、方向だけを示したからです。

仕様は住所です。それはGPS座標です。それはAIに、単に何を構築するかだけでなく、構築されたものがどのような文脈で機能しなければならないかを伝えます。

フェーズ3: アーキテクチャダイアグラム

1行のコードが生成される前に、私はAIに仕様に基づいてアーキテクチャダイアグラムを作成させます。漠然としたスケッチではなく、データフロー、インターフェース、依存関係、意思決定ポイントを示す詳細なコンポーネントダイアグラムです。

なぜなら、図は、方向性の整合性を確認するための最も安価な方法です。

図は数分で確認できます。誤った抽象を数秒で見つけることができます。AIが2つのドメイン間の関係を誤解していることを、誤解を実装するコードを生成するのに1時間かかる前に確認できます。図は、AIが人間の理解速度を超えて加速する前の最後の人間のチェックポイントです。

これはVの頂点です。最も広い部分。実装が降下する前に人間の理解を最大化しなければならないポイントです。

フェーズ4：エージェント実行

目標が明確で、仕様が書かれ、アーキテクチャがレビューされた後にのみ、AIエージェントを実行させます。そしてその時でさえ、次のインクリメントが始まる前に仕様に対して出力をレビューできるように、実行を制限されたインクリメントで構成します。

これは遅くありません。これは持続可能です。代わりに、AIに何千行ものクリーンでエレガントな誤ったコードを生成させることは、チームを数週間麻痺させる理解の負債を生み出します。

エンジニアの新しい価値

重要なのはこの再定義です：エンジニアの価値はもはや良いコードを書くことにはありません。良いコードが何をすべきかを明確に考えることにあります。

AIはコードを書くことができます。95%のエンジニアよりも速く、より良いコードを書くことができます。しかし、AIができないのは、どのコードが存在すべきかを決定することです。ビジネスの文脈を保持することはできません。トレーニングデータに含まれていないトレードオフを評価することもできません。「これを構築すべきか？」と尋ねることもできません—なぜなら、その質問はコードベースの外にある戦略的理解のレベルを前提としているからです。

古い世界では、コーディングスキルがボトルネックでした。優雅で効率的なコードを書くことができるエンジニアは希少なリソースでした。新しい世界では、思考の明確さがボトルネックです。目標を明確に定義し、仕様を正確に記述し、アーキテクチャ図を批判的にレビューできるエンジニアは希少なリソースです。それ以外はアウトソース可能です。

これは、私がINCOSEで議論したVモデルのシフトです。Vの左側—要件、仕様、アーキテクチャ—は重要な経路となりました。右側—実装、統合、テスト—はますます自動化されています。重心は「どうやって構築するか？」から「何を構築するかをどう知るか？」に移っています。

そして「何を構築するかを知ること」は技術的なスキルではありません。それは統合スキルです。ドメイン知識、ビジネスコンテキスト、戦略的判断、AIが忠実に実行できるように制約を伝える能力が必要です。

速度の非対称性

内面化すべき最終的な危険：AIは機械の速度で生産します。人間は人間の速度で理解します。これらの速度は乖離しています。

毎日、最前線のモデルはより速く、より能力を高めています。毎日、単一のエンジニアが委託できる出力の量が増加しています。しかし、人間の理解はスケールしません。コードを読むこと、アーキテクチャを理解すること、データフローを追跡すること—これらは認知的に高コストなタスクであり、ムーアの法則の恩恵を受けません。

その結果、非対称性が生じます：AIは人間が完全に理解するのに1週間かかるシステムを1時間で生成できます。そして、人間がそれを理解した時には、AIはすでに3つのイテレーションを生成しています。人間は常に遅れています。人間は常に負債を抱えています。

この非対称性を管理する唯一の方法は、理解を前倒しすることです。プロセスの最初に人間の時間を投資すること—目標、仕様、アーキテクチャ—それによってAIの実行が人間の理解に制約されるようにします。事後にAIに追いつくことはできません。事前にAIを制約しなければなりません。最初プロセスの—目標、仕様、アーキテクチャ—それによってAIの実行が人間の理解に制約されるようにします。事後にAIに追いつくことはできません。事前にAIを制約しなければなりません。

仕様は制約です。仕様は理解です。仕様は新しいソースコードです。

結論

FableとGPT-5.6との1週間を経て、私は一つの確固たる信念を持ち帰りました：AI駆動の開発におけるボトルネックはもはやAIではありません。それは人間が仕様を定義し、レビューし、理解する能力です。危険なのは、AIが悪いコードを書くことではありません。AIが間違った問題に対して優れたコードを書くことです—そして誰もそれが手遅れになるまで気づかないということです。

債務を理解することは新しい技術的負債です。それは検出が難しく、測定が難しく、返済が難しいです。そして、それはあなたが求めたものと実際に必要だったものの間のギャップで静かに蓄積されます。

解決策はAIを使うのを減らすことではありません。AIを使用する前にもっと考えることです。仕様を書くこと。図を描くこと。目標を知ること。AI生成コードの時代において、エンジニアの技術はタイピングではなく、明確さです。

マーキュリー・テクノロジー・ソリューションズ：デジタリティを加速する。

発行者：マーキュリー・テクノロジー・ソリューションズ | mtsoln.com | システミック・グロース・アーキテクチャ