AI 駆動開発が積み上げる技術的負債：短期最適化バイアスと、DDD・SOLID・Atomic Design が崩れる構造

🚨 AI に任せると、技術的負債が「高速で」積み上がる

Claude Code、GitHub Copilot、Cursor、Gemini Code Assist。AI コーディングアシスタントの普及はもはや前提です。GitHub Octoverse 2024 によれば 新規開発者の 80% が登録 1 週間以内に Copilot を使い始め¹、Google DORA の 2025 年版では AI 利用率は 90% に到達² しました。Stack Overflow Developer Survey 2025 でも、AI ツールを 使用中もしくは使用予定の開発者は 84%³ です。

ところが現場で実際に起きているのは、こういう光景ではないでしょうか。

• ドメインモデルを通さず、コントローラーから直接 SQL が呼ばれている
• 同じロジックが 4 ファイルに少しずつ違う形で散らばっている
• React コンポーネントの中にビジネス計算式と DOM 操作が同居している
• ダークモードもレスポンシブもアクセシビリティも、なぜか「あとで」に押し込まれる
• 「とりあえず動くコード」が量産され、リファクタリングはほぼ提案されない

本記事は 「AI 駆動開発（実践編）」シリーズの序章 として、これらが偶然ではなく AI コーディングアシスタントが構造的に持つ短期最適化バイアスの帰結 であることを、最新の実証研究・ベンダー公式ドキュメント・業界の権威ソースを引きながら明らかにします。

📉 データで見る「AI が積み上げる負債」

主観論で済ませず、まず数値で押さえます。

1. 重複コードが急増し、リファクタリングが消えた

GitClear が 2 億 1,100 万行のコード変更を 2020〜2024 年で解析した AI Copilot Code Quality 2025 は、業界で最大規模の実証研究です。

ピアソン相関係数で Copilot 普及率と churn 率は 0.98 という極めて強い正相関が観測されています⁴。

つまり、AI 普及後の世界では「動かす」ためのコピペが増え、「整える」ためのリファクタリングは半減した。これは経験則ではなく、数値が裏付ける構造変化です。

2. 開発は速くなっていない（むしろ遅くなる）

非営利の AI 評価機関 METR が、平均 5 年・1,500 commits のベテラン OSS 開発者 16 名に 246 タスクをランダム割付した RCT⁵ では、衝撃的な結果が出ています。

• 開発者の 事前予想: AI で 24% 短縮できる
• 開発者の 事後自己評価: AI で 20% 短縮できた（と思った）
• 実測値: AI 利用時の方が 19% 遅かった（統計的に有意）

主因は「AI 生成コードのクリーンアップに時間を費やした」こと。人間は「速くなった気がする」が、実際は遅くなっている という認知バイアスが、技術的負債の蓄積を加速します。

3. 安定性は確実に下がっている

Google DORA の 2024 年版⁶ では、39,000 名超のエンジニアを対象とした回帰分析で次の結果が出ました。

AI 採用が 25% 増加すると、デリバリ安定性が 7.2% 低下、デリバリ・スループットも 1.5% 低下する。

DORA は仮説として「開発者が AI 生成コードに依存しすぎ、より大きく管理しにくい変更セットを生むため」と説明しています。2025 年版でも結論は再確認され、「AI は amplifier である。強いチームはより強く、機能不全なチームの問題はさらに増幅される」 という有名なメタファが提示されました²。

4. 開発者自身が信頼していない

Stack Overflow Developer Survey 2025 によれば、AI を「強く信頼する」と答えたのは わずか 3%。66% は「ほぼ正解だが正確ではない解」に苦しめられている と回答し、45% は「AI 生成コードのデバッグはより時間がかかる」 と答えています³。Snyk の 2023 年調査では AI 生成コードの 48% に脆弱性が含まれる と報告されている⁷ にもかかわらず、80% の開発者が AI 出力の社内セキュリティポリシーをバイパス しています。

🤖 なぜ AI は「当たり前のコーディング」を避けるのか

データだけ見せて「だから危ない」で終わると啓発になりません。なぜ AI はこの挙動になるのか を、構造的に理解しておく必要があります。

報酬関数：見える成功 vs 見えない設計品質

AI は「動くコードを早く返せた」ことが評価される一方、「DDD の境界づけられたコンテキストを正しく分離した」「OCP に従って既存コードに分岐を足さず拡張した」という 設計品質はトークンレベルでは観測できない 報酬です。結果、AI は 観測可能な短期成功（ファイルが少ない・行数が少ない・テストが通る）に最適化します。

コンテキスト窓の制約：横断的リファクタを避ける

DDD の Bounded Context、Atomic Design の階層、SOLID の DIP——いずれも 複数ファイル・複数モジュール横断の構造判断 を要します。AI は限られたコンテキスト窓内で完結するタスクを好むため、横断的リファクタリングは 「指示されない限りやらない」 のが既定動作です。

これは Anthropic 公式の Claude Code ベストプラクティス⁸ にも次のように書かれています。

“Without clear success criteria, it might produce something that looks right but actually doesn’t work.” 明確な成功基準がなければ、Claude は「正しく見えるが実際には動かないもの」を出す可能性がある。

”Vibe coding”：人間がコードを読まない事態

「Vibe coding（雰囲気コーディング）」——AI に投げて動けばよしとし、コード本体を読まないスタイル——を、ThoughtWorks Technology Radar Vol.32 は 明確に「Hold（避けるべき）」 に分類しました⁹。

“Vibe coding … While this approach can be appropriate for things like prototypes or other types of throw-away code, we strongly caution against using it for production code.” Vibe coding はプロトタイプや使い捨てコードには適切だが、プロダクションコードに使うことは強く戒める。

CD/DevOps の権威 Dave Farley は 2025 年の講演で 「Vibe coding は 2025 年最悪のアイデア」 と切り捨てています¹⁰。Simon Willison は LLM を 「キッチンナイフの皮を被ったチェーンソー」 と表現しました¹¹。

🏗️ バックエンドで崩れる「当たり前」

短期最適化バイアスの帰結は、レイヤーごとに違う形で表れます。バックエンドではこうです。

1. DDD・Bounded Context が消える

AI は 言われない限りユビキタス言語を尊重しません。Customer と User、Order と Cart、Inventory と Stock——曖昧に同義で扱われ、Bounded Context の境界はモデル名・テーブル名・API パス名のいずれにも現れず、気づけば 1 つの巨大集約に全てが流れ込みます。

ところが DDD 提唱者 Eric Evans は DDD Europe 2024 のキーノートで 逆方向のメッセージ を出しています¹²。

“Training a language model on a ubiquitous language of a bounded context makes it far more useful for specific needs.” Bounded Context のユビキタス言語で言語モデルを訓練することで、特定の用途にとって遥かに有用になる。

つまり Bounded Context は AI 時代に 陳腐化する古い概念ではなく、AI を有用に使うための前提 だと、提唱者本人が明言しています。

2. SOLID が崩れる

特に Open/Closed Principle（OCP）が崩壊しがちです。AI は「動くから OK」で 既存コードに if/switch 分岐を足し続け、改修ではなく拡張せよという原則は無視されます。Single Responsibility Principle（SRP）も同様で、ハンドラ・ユースケース・リポジトリ・ドメインサービスが 1 ファイルに同居する「God Class」が静かに育ちます。

3. UI の都合がドメインに侵食する

CQRS の Read Model がない状態では、画面の都合（並び順・ページネーション・表示用フォーマット）が 集約の中まで侵食 します。AI は「画面に必要な値を集約に足す」のを最短手として選び、ドメインオブジェクトに displayName formattedPrice のような 表示専用の属性 が混入していきます。

🎨 フロントエンドで崩れる「当たり前」

フロントエンドは構造的にもっと脆弱です。

1. Atomic Design の階層が逆転する

AI は 下位コンポーネント（Atom / Molecule）を経由せず、ページ単位で一気に DOM を生成 することを好みます。結果、Page から Organism、Molecule、Atom へと積み上げるはずの依存関係が崩れ、同じボタン・同じカードがページごとに微妙に違う実装 で量産されます。

Atomic Design 提唱者 Brad Frost は逆に 「AI と Design System は強力な組み合わせ」 だと公言しています¹⁴。Figma も Atomic Design を「AI が最も役立つ場所を特定する枠組み」として参照しており、トークンを「UI のサブ原子粒子」に再定義する流れさえあります。AI 時代に Atomic Design はむしろ価値が高まっている のに、現場の AI 利用は逆方向に向かいがちです。

2. UI / UX にドメインロジックが流れ込む

「React.useState 内で価格計算」「onChange ハンドラ内で在庫検証」「useEffect の中で永続化トリガー」——AI が短期で動くコードを書くと、UI コンポーネントが プレゼンテーションでもステートマシンでもない、ドメインロジックの巨大バケツ に育ちます。

ヘキサゴナル / クリーンアーキテクチャは 「コアにフレームワークを混ぜるな」¹³ と言いますが、AI は何もしないとフレームワーク（React / Vue / Angular）の関心事とドメインの関心事を 平気で混ぜます。

3. ダークモード・レスポンシブ・アクセシビリティが「あとで」に追われる

ダークモードもレスポンシブも a11y も、最初から構造に組み込まれていなければ、後から追加するコストは 2〜3 倍 になります。AI は明示されない限り ライトモード・PC ビューポート・WCAG 不問 を既定値として吐き、「あとで対応」を前提にすべてが固まります。

🛡️ ベンダー自身が「人間に依存している」と明言している

「では AI ベンダーはこれを認識しているのか」——答えは 全社が認識しており、ドキュメントで明言 しています。

つまり、全ベンダーが「設計意図・規約・アーキテクチャ判断は人間が AI に明示的に渡す責任があり、検証も人間の責任である」というスタンスで一致 しています。「AI が勝手に良い設計をしてくれる」のは、ベンダー自身が想定していないユースケースなのです。

🧪 規律と組み合わせると、AI は逆に「増幅器」になる

ここまで読むと「AI は使わない方がいい」と感じるかもしれませんが、これは正反対の結論です。規律と組み合わせれば、AI は増幅器として最大の価値を発揮します。

Kent Beck は AI エージェント時代の TDD について 「TDD は superpower（超能力）だ」 と Pragmatic Engineer のインタビューで述べ、彼自身のブログで 「Vibe coding（動けば OK）」と「Augmented coding（複雑度・カバレッジ・保守性に責任を持つ）」を区別 しています²⁰。

Google Chrome の Addy Osmani は 「70% problem」²¹ という言葉でこう整理しました。

“Seniors use AI to accelerate what they already know how to do. Juniors try to use AI to learn what to do.” シニアは既に知っていることを AI で加速する。ジュニアは AI を使って何をすべきかを学ぼうとする。

AI は解決策の 70% を高速で出すが、残り 30%（エッジケース、セキュリティ、本番統合、設計の整合性）は 人間の判断と規律 に依存する。シニアは AI 出力をそのまま受け取らず、小さく集中したモジュールに常時リファクタしている、と Osmani は観察しています。

ThoughtWorks Technology Radar Vol.33 の “AI-friendly code design”²² エントリは、これを最も簡潔に言い表しています。

“Good software design for humans also benefits AI.” 人間にとって良いソフトウェア設計は AI にとっても有益である。

SOLID も DDD も TDD も Atomic Design も、「AI 時代に古びた贅沢品」ではなく、AI に渡すコンテキストを整える土台 だと、業界の最先端がそろって再定義しているわけです。

🐎 ハーネスエンジニアリングだけでは、馬は走らない

最近の AI 駆動開発の議論では、「ハーネスエンジニアリング（Harness Engineering）」 という言葉がやたらと強調されています。CLAUDE.md / AGENTS.md、hooks、sub-agents、skills、permissions——AI を業務投入するための 馬具一式 を整える技術です。Birgitta Böckeler 自身も martinfowler.com で「Harness Engineering — first thoughts」²³ を寄稿し、CTS グループでも Claude Code 7 層ハーネス として体系化してきました。

ただし、忘れてはいけないことがあります。

ハーネス（harness、馬具）は、馬を「操るための」道具であって、馬具を装着しただけでは馬は走らない。

馬具は人間の意思を馬に伝えるための媒介です。操る側に 「どこへ向かうか」「どう曲がるか」「いつ止まるか」 という舵取りの意思 ——ステアリング（steering、操舵）——がなければ、馬具は飾りにすぎません。

Birgitta Böckeler 自身が martinfowler.com で 「常に介入し、修正し、舵取りし続ける（intervene, correct and steer all the time）」²⁴ と書いているのは、まさにこの意味です。「ハーネスを整えれば AI が勝手に走る」のではなく、「整えたハーネスを 人間が舵取りする」のが本筋です。

両者は 二者択一ではなく、二段で揃える もの。ハーネスがなければ馬具を着けない裸の馬を操ることになり、ステアリングがなければ立派な馬具を着けた馬が好き勝手な方向に走るだけです。本記事のシリーズが 「ステアリング駆動開発」 という名で組み立てられているのは、この「人間の舵取り」を中核に置く意思表示にほかなりません。

🧭 処方箋①：docs/ の北極星を、開発初期に揃える

本記事の結論を 1 行に圧縮するとこうなります。

AI は短期最適化を志向する道具である。設計規律と検証手順を人間が用意できなければ、AI は技術的負債を「高速で」量産する。

「人間が用意する設計規律」の置き場が、docs/ 配下の北極星ドキュメント です。これがないまま AI に指示を出すのは、海図なしに自動運航船を出航させるのと同じです。CTS グループでは、docs/ 直下に以下の 4 種類を 開発初期にまず揃える ことを必須にしています。

これは Anthropic 公式の Claude Code ベストプラクティス⁸・OpenAI Codex の AGENTS.md ガイダンス¹⁷ と完全に同じ思想です。OpenAI は次のように明言しています。

“AGENTS.md gives Codex durable project guidance that travels with your repository and applies before the agent starts work.” AGENTS.md は、リポジトリと共に持ち運ばれ、エージェントが作業を始める前に適用される 永続的なプロジェクトガイダンス を Codex に与える。

「永続的（durable）」——これが鍵です。セッションが終わるたびに揮発するチャット指示ではなく、リポジトリに刻まれた北極星があるかどうかで、AI が出すコードの品質は桁違いに変わります。

🔄 処方箋②：壁打ちで北極星を継続的に最適化する

docs/ を開発初期に揃えたら終わり、ではありません。北極星はプロジェクトと共に育てる ものです。

CTS グループでは、新規機能・大型改修のたびに AI との壁打ちフェーズ を必須にしています（詳細は 壁打ち・規模判定編）。壁打ちの目的は次の 3 つです。

1. 要件をユビキタス言語で表現する — 業務語彙が glossary に既存か、新規追加か
2. 設計判断を ADR に追記する — なぜその選択肢を選んだか、他の選択肢を捨てた理由
3. 既存の北極星と矛盾しないか検証する — 矛盾があれば旧 ADR を Superseded にする

ThoughtWorks の Birgitta Böckeler が martinfowler.com で繰り返し述べているように、「エージェント型コーディングアシスタントを効果的に使うには、常に介入し、修正し、舵取りし続ける必要がある」²⁴。北極星の最適化はこの「舵取り」の本体です。

OpenAI の Codex ガイダンスには、「Codex が同じミスを 2 度犯したら、レトロスペクティブをさせ AGENTS.md を更新せよ」¹⁷ という具体的な指示があります。これは「北極星に書かれていないルールに AI が従うはずがない」という認識の裏返しです。繰り返される指摘・繰り返される修正は、すべて docs/ への追記候補 だと考えてください。

🔠 処方箋③：命名規則は「ユビキタス言語の射程」と「ACL の責務」を分けて統制する

最後に、AI 駆動開発でほぼ毎回ぶつかり、しかも軽視されがちな落とし穴 ——命名規則 を扱います。

二段で考えると、DDD と整合する

「命名規則 = ユビキタス言語」と単純化したくなりますが、一次情報を辿ると 二段に分けるのが正確 です。

Evans は『Domain-Driven Design Reference』で次のように書いています²⁵。

“Commit the team to exercising that language relentlessly in all communication within the team and in the code.” その言語を、チーム内のあらゆるコミュニケーションと コードの中で、徹底的に使い続けることをチームに約束させよ。

つまり「クラス名・メソッド名にどんな英単語を選ぶか」はユビキタス言語の射程です。一方、PascalCase / snake_case / camelCase の表記スタイルそのものは Evans / Vernon / Fowler のいずれも「ユビキタス言語」とは扱っておらず、Bounded Context 境界での翻訳責務（ACL: Anti-Corruption Layer） に位置づけるのが筋です²⁶。

なぜケースのズレがバグの温床になるのか

CTS-EC のような バックエンド（C#）× フロントエンド（TypeScript）× クラウドサービス（Pub/Sub・Workflow・Job） が混在する構成では、ケース変換が無数の境界で発生します。代表的な事故は次のとおりです。

• Protobuf → JSON の自動変換で user_id が userId になる proto3 仕様²⁸ に「アンダースコアを取り除き、次の文字を大文字化する」と明記されている挙動。Pub/Sub の publisher と subscriber でシリアライザの設定が違うと、同じスキーマから出てくる field 名が一致しない事故 が起きる。
• System.Text.Json は PropertyNameCaseInsensitive のデフォルトが false Newtonsoft.Json から移行した瞬間、API 層では動いていたのに JsonSerializer.Deserialize<T> 直叩きに切り替えた瞬間に値が null になる、という症状²⁹。
• .NET 8 で JsonNamingPolicy.SnakeCaseLower が標準追加 逆に言えば .NET 7 以前で書かれたコードは、Stripe / Slack / Twilio のような snake_case API と連携するためにカスタム JsonNamingPolicy を実装しなければならず、漏れによる「一部フィールドだけ取れない」事故が頻発する³⁰。
• Jackson @JsonNaming(SnakeCaseStrategy.class) が Java record で効かない 記録済みの Issue（FasterXML/jackson-databind #2992 ほか）³¹。リファクタで record 化した瞬間に静かに壊れる典型例。
• Pub/Sub の Avro はフィールド名でマッチング Protobuf は tag 番号で encode されるため命名変更に強いが、Avro は フィールド名でマッチング されるため、命名スタイルを途中で変えると subscriber が破綻する³²。

CloudEvents v1.0.2 仕様も明確に 「属性名は小文字 a-z または数字 0-9 のみ」³³ と要求しており、これに合わせない自社命名はマッピング層が必須になります。

境界別の推奨ケース（北極星に書く内容）

docs/specs/naming-conventions.md などに 境界ごとに「推奨ケース＋出典」を明記 しておくと、AI も人間も同じルールで動けます。CTS グループの推奨デフォルトは以下です。

Google AIP-140 が 「Protobuf フィールドは lower_snake_case、JSON と生成コードでは適切な命名規則にマッピングされる」³⁴ と明記しているとおり、境界ごとにケースは違ってよい——ただし 境界そのものに翻訳層が存在することを明示 する、というのが現代のデファクトです。「BE と FE で表記が違うのが気持ち悪いから片方に揃える」のではなく、境界の存在を認め、ACL で翻訳責務を集中させる のが正解です。

🛤️ ステアリング駆動開発（実践編）への接続

ここまでの 3 つの処方箋を 1 枚にまとめると、CTS グループのステアリング駆動開発の本質が見えてきます。

実践編シリーズ では、本記事で示した「崩れる構造」と「3 つの処方箋」を踏まえ、CTS-EC の本番運用から得られた具体的な対処法を順に解説します。バックエンド（DDD・SOLID・CQRS）でどう AI に境界を渡すか、フロントエンド（Atomic Design・Storybook・テーマトークン）でどう AI に階層を守らせるか、ACL でどう命名のケース変換を集中させるか、ADR と CLAUDE.md でどう「同じ過ちを 2 度繰り返さない」仕組みを作るか——それぞれ独立した記事として続きます。

技術的負債は 誰のミスでもない構造的帰結 です。だからこそ、北極星・壁打ち・命名規則という「構造」で対処する しかありません。

🔗 関連記事

• ステアリング駆動開発とは：AI コーディング時代の新しい開発ワークフロー — 本シリーズの土台となる方法論
• 壁打ち・規模判定編 — 北極星を継続最適化する壁打ちフェーズの進め方
• 開発手法ガイド：概要 — AI に渡すべき設計原則の体系（全 11 本シリーズの導入）
• 開発手法ガイド：DDD 編 — Bounded Context・ユビキタス言語・集約・ACL
• 開発手法ガイド：SOLID 原則編 — AI 生成コードのレビューチェックリスト
• 開発手法ガイド：TDD 編 — Kent Beck が「AI エージェントの superpower」と呼ぶ手法
• 開発手法ガイド：アトミックデザイン編 — AI に粒度を指定して UI を量産する
• Claude Code ベストプラクティス — CLAUDE.md・hooks・skills の統合運用

📖 関連用語

• ハルシネーション — AI が「もっともらしい嘘」を返す失敗モード
• コンテキストエンジニアリング — AI に渡すコンテキストを設計する技術
• コンテキスト腐敗（Context Rot） — 長いコンテキストで品質が低下する現象
• ADR — 設計判断の永続記録
• SOLID — オブジェクト指向設計の 5 原則
• DDD — ドメイン駆動設計
• Clean Architecture — 依存方向を内向きに固定する設計