設計思想進化論 — なぜ"単独設計"の時代は終わり、AIドリブンDDDが生まれるのか
設計思想進化論
なぜ"単独設計"の時代は終わり、AIドリブンDDDが生まれるのか
— DDD × クリーンアーキテクチャ × AIドリブン、その先へ —
📖 3行の物語：なぜ3つは生まれたか
むかし、業務があまりに複雑で開発者が溺れていた。
そこで DDD が生まれた。「まず業務を正しく表現しよう」と。しかし DDD のコードはインフラと絡まり、保守不能になった。
そこで クリーンアーキテクチャ が生まれた。「依存を一方向に流そう」と。そして AI がやってきた。人間が読む前提の層構造は、AI には冗長すぎた。
そこで AIドリブン設計 が生まれた。「文脈を小さく、意図を強く」と。
3つは対立ではなく、それぞれ違う痛みから生まれた処方箋です。
🏠 一言でたとえると：家を建てる
| 設計 | たとえ | ひとこと |
|---|---|---|
| DDD | 設計士が施主と膝詰めで「この家族にとってのリビングとは何か」から定義する注文住宅 | 正しく建てる |
| クリーン | 配管・電気・内装を完全分離し、水回りだけ後でリフォームできる家 | 壊れない家を建てる |
| AIドリブン | プレハブ工法。部屋ごとにユニット化して短期で組み立てる | 速く建てる |
🔨 もう少し詳しく：家づくりのたとえ
DDD：こだわりの注文住宅
「"玄関"とは何か？」から話が始まる。
施主（業務の人）の言葉を尊重し、「靴を脱ぐ境界空間」という概念を図面に起こす。
美しいが、話し合いが長い。完成まで時間がかかる。
→ 金融、医療、物流のように「概念を間違えると事故る」業界向け。
クリーンアーキテクチャ：モジュラー住宅
配管工が来て工事しても、内装には触らない。電気工も同じ。
「あとで IHコンロをガスに戻したい」と言われても、キッチンユニットだけ交換すれば済む。
ただし、壁と配管の間に「取り外し用の接続口」を何重にも作るので、材料費（コード量）は多め。
→ 10年運用するプロダクト、大人数チーム向け。
AIドリブン設計：プレハブハウス
「リビング」「キッチン」「寝室」をそれぞれ1ファイルのユニットにして、
トラックで運んできて現場で組み立てる。
一部屋ずつ AI が設計・製造できるので速い。
ただし、家全体の設計思想は薄いので、複雑な要求（三世代同居とか）には弱い。
→ スタートアップ、MVP、社内ツール向け。
🏗 構造の違い
DDD：ドメインが王様
┌─────────────┐
│ Domain │ ← 中心。ビジネス概念の塊
│ Entity │
│ Aggregate │
│ VO │
└─────────────┘
↑ 他はドメインに仕える
クリーン：同心円、依存は内向きのみ
Infrastructure
└─ UseCase
└─ Domain ← 最内殻。何にも依存しない
※ 矢印は必ず外→内。内→外は禁止。
AIドリブン：フラット、ユースケース単位
usecases/
createOrder.ts ← これ1ファイルで完結
cancelOrder.ts ← これも1ファイルで完結
infra/
db.ts
ファイル間の行き来が少なく、AIが1ファイル読むだけで仕事できる。
💻 同じ機能を3パターンで書く
お題：「注文を作成する」
🟦 DDDで書くと
// domain/order/Order.ts
class Order {
private constructor(
private readonly id: OrderId,
private readonly customerId: CustomerId,
private readonly items: OrderItem[],
private status: OrderStatus
) {}
static place(customerId: CustomerId, items: OrderItem[]): Order {
if (items.length === 0) throw new EmptyOrderError();
return new Order(OrderId.generate(), customerId, items, OrderStatus.Pending);
}
confirm(): void {
if (!this.status.isPending()) throw new InvalidStateError();
this.status = OrderStatus.Confirmed;
}
}
// domain/order/OrderId.ts (ValueObject)
// domain/order/OrderStatus.ts (ValueObject)
// domain/order/OrderRepository.ts (interface)
// application/PlaceOrderService.ts
👉 6ファイルくらいになる。 業務概念は美しく表現される。
🟩 クリーンアーキテクチャで書くと
// domain/Order.ts
export class Order { /* エンティティ */ }
// application/usecases/PlaceOrderUseCase.ts
export class PlaceOrderUseCase {
constructor(private repo: IOrderRepository) {} // ← interface依存
async execute(input: PlaceOrderInput): Promise<PlaceOrderOutput> {
const order = Order.create(input);
await this.repo.save(order);
return { orderId: order.id };
}
}
// application/ports/IOrderRepository.ts (interface)
// infrastructure/OrderRepositoryImpl.ts (実装)
// interfaces/OrderController.ts
👉 5ファイル程度。 DB差し替えも、テストも楽。ただしインタフェースだらけ。
🟥 AIドリブンで書くと
// usecases/createOrder.ts ← これ1ファイル
import { db } from '../infra/db';
export async function createOrder(customerId: string, items: Item[]) {
if (items.length === 0) throw new Error('Order must have items');
const order = {
id: crypto.randomUUID(),
customerId,
items,
status: 'pending',
createdAt: new Date(),
};
await db.orders.insert(order);
return order;
}
👉 1ファイル。 AIが読むのも直すのも一瞬。ただしOrderという概念は"ただのオブジェクト"。
📊 統一スケールでの比較（★5満点）
| 観点 | DDD | クリーン | AIドリブン |
|---|---|---|---|
| ドメイン表現力 | ★★★★★ | ★★★☆☆ | ★★☆☆☆ |
| 保守性（長期） | ★★★★☆ | ★★★★★ | ★★☆☆☆ |
| 開発速度（初速） | ★☆☆☆☆ | ★★☆☆☆ | ★★★★★ |
| テスト容易性 | ★★★★☆ | ★★★★★ | ★★★☆☆ |
| AIとの相性 | ★★☆☆☆ | ★★★☆☆ | ★★★★★ |
| 学習コスト | ★☆☆☆☆（高い） | ★★☆☆☆ | ★★★★★（低い） |
| 小規模での適合 | ★★☆☆☆ | ★★★☆☆ | ★★★★★ |
| 大規模での適合 | ★★★★★ | ★★★★★ | ★★☆☆☆ |
🧭 どれを選ぶ？判断フロー
┌─────────────────────────────────────┐
│ Q1. ドメインが複雑？ │
│ （金融・医療・物流・保険など） │
└──────────────┬──────────────────────┘
YES │ NO
▼ │ ▼
┌─────────┐ │ ┌─────────────────┐
│ DDDを │ │ │ Q2. 3年以上運用？ │
│ベースに │ │ │ チーム5人以上？ │
└─────────┘ │ └────┬────────────┘
│ YES │ NO
│ ▼ ▼
│ ┌─────────┐ ┌──────────┐
│ │クリーン │ │AIドリブン│
│ │アーキ │ │ │
│ └─────────┘ └──────────┘
迷ったら AIドリブン で始めて、複雑化したら DDD/クリーンに寄せていくのが現実的。
⚠️ よくある失敗
DDD の失敗
「ユビキタス言語」「境界づけられたコンテキスト」という言葉に酔って、
小さな CRUD アプリに Aggregate を10個作る。
→ 誰もメンテできない怪物が完成。
クリーンの失敗
インタフェース地獄。
IUserRepository,IUserService,IUserFactory...
→ 実装が1つしかないのにインタフェースだけ無限増殖。
AIドリブンの失敗
すべてを
usecases/に突っ込んだ結果、
createOrder.tsとcreateOrderV2.tsとcreateOrderNew.tsが並ぶ。
→ ドメインモデルがないので、重複ロジックが分散。
🎯 結論：AI時代のアクション3箇条
① ドメインは「核」だけ残す
全部を Aggregate にしない。本当にビジネスルールがある概念だけをクラス化する。他はただのオブジェクトでいい。
② UseCase を主役にする
ファイル名 = 動詞。createOrder.ts, cancelOrder.ts。
AIが「何をするファイルか」を一瞬で理解できる命名を徹底する。
③ 層は浅く、意味は濃く
ディレクトリは domain / usecases / infra の3層まで。
代わりに関数名・型名を雄弁にする。save() ではなく saveOrderAsConfirmed()。
🔮 未来予測：AIドリブンは一強になるのか？
結論から言うと、「一強にはならない。でも勢力圏は広がる」 というのが現実的な見方です。
なぜ「一強に見える」のか
AIの進化で以下が起きています。
- コンテキストウィンドウの拡大（100万トークン級）→ 大規模コードも読める
- 推論能力の向上 → 複雑な設計も理解できる
- 生成速度の向上 → DDDの冗長さがコストじゃなくなる
これだけ見ると「AIドリブンだけでいいじゃん」となりそうですが、そうはなりません。
❌ AIドリブンが一強にならない4つの理由
① コードは「AIのため」だけに存在しない
コードの読者には3種類います。
| 読者 | 何を求めるか |
|---|---|
| AI | 短く、文脈が閉じていること |
| 人間（開発者） | 論理構造、意図 |
| 人間（業務側） | 概念の正しさ、合意 |
AIドリブンは①に最適化されていますが、②③を軽視すると破綻する領域があります。特に金融・医療・法務では、DDDの「ユビキタス言語」がAI以前に人間社会の要請として必要です。
銀行員と「振込」の定義をすり合わせずに、AIに
transferMoney()と書かせても、
それが法的に正しい振込かは誰も保証できない。
② AIが賢くなるほど「責任」が人間に集中する
逆説的ですが、AIが強くなるほど人間の説明責任は重くなります。
- AIが書いたコードでバグが出ても → 責任は人間
- AIが設計した業務ロジックが違法でも → 責任は人間
- AIが最適化した結果が差別的でも → 責任は人間
DDDやクリーンは説明可能性を構造で担保する設計なので、AI時代にむしろ重要度が上がる。
「AIが作ったから知りません」は通用しない。
だから、人間が後から読んで理解できる骨格が要る。
③ 「複雑さ」は消えない、移動するだけ
ソフトウェア工学には 「本質的複雑性（Essential Complexity）」 という概念があります（Fred Brooks『銀の弾丸はない』）。
| 種類 | 説明 | AIで削れるか |
|---|---|---|
| 偶有的複雑性 | ボイラープレート、設定、ツール由来 | ✅ 削れる |
| 本質的複雑性 | 業務ルール、法規制、ドメインの本質 | ❌ 削れない |
保険の料率計算、医薬品の副作用マトリクス、国際税務——こういった本質的複雑性は、AIがコードを生成しても複雑なままです。そして、本質的複雑性に立ち向かう武器こそが DDD です。
④ AI自身が「良い構造」を好む
ここが面白いところです。AIは構造化されたコードの方が性能が上がることが分かってきています。
- 関心の分離ができている → AIが局所的に修正できる
- 命名が一貫している → AIが推論しやすい
- 依存方向が明確 → AIが影響範囲を特定できる
AIが進化するほど、AIは「きれいに書かれたDDD/クリーン」を好むようになる。
AIドリブンの"雑さ"は、むしろAIの性能を下げる可能性がある。
🌊 起きるのは「淘汰」ではなく「融合」
一強にはならないけど、境界線は溶けると見ています。
現在（2026年）
DDD ── クリーン ── AIドリブン
↑ ↑
伝統 新興
未来（2028〜2030年頃の予想）
┌──────────────────────────────┐
│ AI-Native Domain Design │
│ （AIが扱えるDDD） │
└──────────────────────────────┘
↑
全部が融合した「ひとつの設計論」へ
具体的な変化予想：
| 今までの常識 | これからの常識 |
|---|---|
| DDDは冗長でAIに不向き | AI向けに凝縮されたDDDが標準に |
| クリーンは層が多くて面倒 | AIが層を自動生成するので負担ゼロ |
| AIドリブンは構造が浅い | AIが自動で構造化してくれる |
つまり、「人間が書くDDD」は消えても、「AIが書くDDD」は残る。
設計思想としてのDDDは、むしろAI時代に解放される可能性があります。
🎯 時間軸での予測
短期（1〜2年）
- 小〜中規模：AIドリブン優勢
- 大規模・規制業界：DDD/クリーン継続
中期（3〜5年）
- ハイブリッドが主流（今の「軽量DDD×AIドリブン」の延長）
- AIが設計レビューをする時代に
長期（5年以上）
- 設計思想の区別が意味をなさなくなる
- 人間は「何を作るか」だけを決め、どう作るかはAIが自動選択
- その時、AIは状況に応じてDDD的にもクリーン的にも書き分ける
💡 核心：「書き方」は吸収される、「考え方」は残る
AIドリブンは「書き方」の流派だが、DDDは「考え方」の流派である。
書き方はAIに吸収されるが、考え方は残る。
だから、今DDDを学んでおくのは無駄にならない。
むしろAI時代こそ、「何を作るべきか」を言語化できる人間の価値が上がります。
AIドリブンは銀の弾丸ではなく、新しい銃にすぎません。
どの弾を込めるか（＝何を設計するか）を決めるのは、当分人間の仕事です。
🌱 クリーンアーキテクチャは消えるのか？
ここで一歩踏み込んで考えます。
「AIドリブンDDD」が生まれるなら、クリーンアーキテクチャは消滅するのか？
表面上は消える、でも"魂"は残る
結論から言うと、「クリーン単独」という選択肢は消えるが、クリーンの本質は新思想の骨格として生き残る。
プログラミング史を振り返ると、古い思想は名前を失っても、規律として残ることが分かります。
| かつての思想 | 現在 |
|---|---|
| 構造化プログラミング | 言葉は死語。だが「goto文を避ける」習慣は全員に染み付いている |
| オブジェクト指向 | 単独思想としては弱体化。だが「カプセル化」はどこでも使われている |
| クリーンアーキテクチャ | 単独思想としては消えるかも。だが「依存性逆転」は新思想に埋め込まれる |
つまり、クリーンは可視の思想としては消え、不可視の規律として残る。
これは"死"ではなく、**"浸透"**です。
🚀 新しい設計思想の誕生
名前は何であれ、中身はこうなる
新思想を仮に 「AIドリブンDDD」 と呼びますが、実際の名称は違うかもしれません。
「モダンアーキテクチャ」「AI-Native Design」「コンテキスト駆動設計」 ——呼ばれ方は誰が本を書くかで決まります。
ただし、中身はすでに輪郭が見えています。
新思想の3本柱
┌──────────────────────────────────────┐
│ AIドリブンDDD（仮称） │
├──────────────────────────────────────┤
│ │
│ 🧠 DDDから → 「考え方」 │
│ 継承 ユビキタス言語 │
│ ドメインの中心性 │
│ │
│ 🛡 クリーンから → 「規律」 │
│ 継承 依存性逆転 │
│ 関心の分離 │
│ │
│ ⚡ AIドリブンから → 「書き方」 │
│ 継承 フラット構造 │
│ ユースケース単位 │
│ コンテキスト最小化 │
│ │
└──────────────────────────────────────┘
それぞれの"ONLY"では到達できない場所
| 単独設計の限界 | 新思想が超える点 |
|---|---|
| DDD ONLY → 重い、AIに不向き | 軽量化して、AIが扱える粒度に |
| クリーン ONLY → 層が多い、ドメインが薄い | 層を自動生成化、ドメインを核に据える |
| AIドリブン ONLY → ドメイン不在、規律なし | DDDの思想とクリーンの規律を埋め込む |
単独では限界があった3つが、AI時代だからこそ融合できる。
これは妥協の産物ではなく、「AIという触媒」によって初めて可能になった統合です。
なぜ"今"なのか
融合がAI時代に実現する理由は明確です。
- AIが層を自動生成できる → クリーンの「層の多さ」コストが消える
- AIが用語の一貫性を保てる → DDDの「ユビキタス言語」維持コストが消える
- AIがドメイン分析を補助できる → DDDの「学習コスト」が下がる
つまり、人間にとって重かった部分を、AIが肩代わりする。
そうなれば、3つの良いとこ取りが現実的に可能になります。
🏁 最終テーゼ：単独設計の終わり、融合の始まり
DDDは正しさ、クリーンは強さ、AIドリブンは速さ。
そのどれか一つを選ぶ時代は、終わる。
AI時代に生まれるのは、これまでの全てを踏襲しつつ、どの単独設計とも違う新しい思想です。
🌿 DDDの「考え方」を受け継ぎ、
🛡 クリーンの「規律」を埋め込み、
⚡ AIドリブンの「書き方」で実装する。これが AIドリブンDDD（呼称は時代が決める）。
単独設計の時代は静かに幕を下ろし、
融合によってしか到達できない地平が、目の前に開きつつあります。
名前はまだ誰も決めていません。
でも、輪郭はもう見えています。
"注文住宅の思想で、プレハブを建てる。
その骨格には、壊れない家の設計図が埋め込まれている。"
それが、AI時代の設計です。
Discussion