DDDファーストなAIプロトタイピング——役割と足場で成立させる

• 想定読者： AIに本番品質の技術スタック（Next.js / Spring Boot / Rails 等）でプロトタイプを作らせて、最終的にエンジニアが本番化するワークフローを設計したい人。エンジニアと事業側の両方を意識して書いている
• 前提知識： DDD（ドメイン駆動設計）の基本概念に馴染みがあると読みやすい。なくても本文中で必要分は説明する
• 所要時間： 約14分

概要

AIで高速にコードが書ける時代に、DDDを起点としたプロトタイピングでプロジェクトを成功させるには、何を・誰に・どう揃えればいいか。本記事はその問いに答える。

答えは「手法」「人材」「事前準備」の3つの組み合わせだ。ドメインを先に定義してAIに渡し、本番品質の技術スタックでプロトを作らせる——これが手法。作る人・引き継ぐ人・足場を組む人を分けて配置する——これが人材設計。AGENTS.md・型雛形・テンプレ・MCP・Skillsで「ド素人に近い人でも動かせる」環境を先に組む——これが事前準備。

順序を間違えると事故る。動くプロトタイプを先に作って後からドメインを整理しようとすると、AIが選んだ流暢な用語と統計的に妥当そうな業務ルールがそのまま化石になる。bookingとreservationの取り違えでCFOを刑務所送りにしかねないエージェントを生んだ事例¹は、こうした「ドメイン無きAIプロト」が業務レベルで何を起こしうるかを端的に示している。

逆の順序——DDDでドメインを先に定義してから、その定義をAIに渡してプロトタイプを作らせる——を取ると、構造が変わる。AIは「ゼロから業務を推測する役」ではなく「定義された業務を実装する役」になる。動作確認の速度は維持したまま、ドメインの正確さは人間が握る。

本記事は4つのパートで構成する。何を渡すか（ドメイン定義の5要素）、どう渡すか（4つの実装パターン）、誰が動くか（3つの役割と隠れた4人目）、何を事前に組むか（プロト作成者の能力要件を下げる足場）。最後に、この手法固有の落とし穴を整理する。

なお、「動くプロトを先に作って後でドメインを整理する」ワークフローや、AI生成コード一般の品質・セキュリティ問題、顧客がプロトを本番扱いする問題は、いずれも別の論点なので本記事の射程外として別記事に逃がす。

なぜ順序が決定的に重要なのか

「動くプロトタイプを早く作る」価値は実証されている。要件工学の2025年実証調査では、実務者の58.2%が既にAIを要件定義で使い、その大半が完全自動化ではなく Human-AI Collaboration（協働） 型で運用していた²。20頁のPRDで2週間待つより、その場で動くものを見せて握る方が速い。これは構造的に正しい。

問題はそこからだ。動くプロトを先に作ると、AIが選んだ語彙と業務ルールが既成事実化する。

Khaliliの2025年論考が端的にこう要約している³：

DDD encodes intent; AI discovers correlation.

（DDDは意図をエンコードし、AIは相関を発見する）

LLMは generalist だ。訓練データ全体から「booking ≒ reservation」という統計的相関を抽出する。だが現実の業務では、ある文脈での「booking」は売上計上された予約を意味し、別の文脈での「reservation」は仮押さえを意味する——という峻別が、規制・会計・契約のレベルで生死を分ける。Russ Milesが報告するAIエージェントは、この区別を持たずに動き出した結果、CFOを刑務所送りにしかねない処理を進めかけた¹。これは寓話的に脚色されている可能性は否定しないが、ドメインの境界がない状態でAIが業務に踏み込むと、流暢な誤動作が業務レベルの実害として表面化しうる、という構造を示している。

順序を逆にすると、この事故が起きる経路が断たれる。ドメイン定義が先にあると、AIは「業務を推測する役」ではなく「定義された業務を実装する役」になる。意図は人間が握り、相関の発見はAIに任せない。

これは机上の理想論ではない。DDD Academyは2026年に「LLM × Strategic Design」を正規ワークショップ化しており⁴、Aardling（Mathias Verraes が 2020 年に創業した DDD コンサルタンシー、現 CEO は Thomas Coopman、DDD Europe コミュニティと密接）が「ドメインマッピング、ユビキタス言語の精緻化、境界の定義、設計の統合の各段階でLLMを補助として使う」体系を教材化している。これはコミュニティが集合的に向かっている方向だ。

AIに何を渡すか——ドメイン定義の5要素

AIに本番技術でプロトを作らせるとき、ドメイン定義として最低限渡すべき5要素を整理する。

1. ユビキタス言語（用語集と禁則）

最も基本でありながら、最も省略されがちな成果物だ。

[用語集の最小単位]
- 用語名: 予約 / Reservation
- 文脈: 顧客予約コンテキスト
- 意味: 顧客から仮押さえを受け付けた状態。確定前。
- 関連状態: PendingConfirmation, Confirmed, Cancelled
- 禁則: 「予約」を「予約成立」と同義に使わない。
        確定後は Booking 用語に切り替える。

これをAIに渡すと、生成されるコードの変数名・型名・テーブル名がぶれない。逆に渡さないと、AIは「Reservation」「Booking」「Order」「Appointment」のような類義語を訓練データの分布から選び、コンテキストごとにバラバラに採用する。後から統一しようとすると、命名がすべての層を貫通しているので影響範囲が膨大になる。

Thoughtworks の Liu Shangqi も Spec-Driven Development の議論で「specs should use domain-oriented ubiquitous language to describe business intent rather than specific tech-bound implementations」と明示している⁵。AIに渡す仕様はビジネス意図を表現するドメイン語彙であるべき、というのは現在のAI支援開発の基本原則になりつつある。

2. ドメインモデル（Aggregate / Entity / Value Object）

ユビキタス言語が「単語」だとすれば、ドメインモデルは「文法」だ。

• どのオブジェクトがアイデンティティを持つか（Entity）
• どのオブジェクトが値そのものか（Value Object）
• どのオブジェクトが整合性の境界か（Aggregate Root）
• それらの関係（参照、所有、参加）

これを図と型定義の両方で渡す。図は人間とAIの両方が解釈しやすく、型定義はコード生成時のアンカーになる。具体的には、TypeScript なら interface と type、Java なら record と class、Python なら dataclass や Pydantic でドメインモデルだけ先に確定してAIに渡す。

ここが「本番技術でプロトを作る」前提の効用が出る場所だ。専用プロトタイピングツールの生成コードは独自ランタイムに縛られ、引き継ぎ時に書き換え必須になりがちだが、本番技術なら、ドメイン型は最初から本番のコード資産になる。プロトの実装が捨てられても、ドメイン型は残る。

3. Bounded Context と Context Map

境界づけられたコンテキスト（Bounded Context）は、DDDで最も誤解されている概念のひとつだ。「マイクロサービスの単位」と捉えると本質を外す。本来は意味の有効範囲を定義する仕組みだ。

AIへのコンテキストとしては、こう渡す：

渡す内容	例
コンテキスト名	顧客予約コンテキスト
そのコンテキストでのUL	Reservation（仮押さえ）、Confirmation（確定）など
隣接コンテキストとの関係	在庫コンテキストとは Customer/Supplier、決済コンテキストとは Conformist
Anti-Corruption Layer の位置	在庫境界に ACL を置く

Khaliliは Bounded Context を「認知的ファイアウォール（cognitive firewall）」と呼んでいる³。AIが訓練データの一般的な用法に引きずられて意味的ドリフトを起こす確率は高い。コンテキストごとに語彙と業務ルールを区切ることで、ドリフトを物理的に止める。AIのファイル分割・モジュール分割をこのコンテキストに合わせさせると、後から境界を確認しやすい。

4. 不変条件（business invariants）

「予約は同時に2つの席を抑えられない」「請求書の合計は明細の合計と一致する」「未確定の注文は出荷できない」——こうした業務不変条件は、AIに渡すか渡さないかで生成コードの品質が桁違いに変わる。

渡し方は3層ある。

第1層：自然言語で記述。 仕様書やAGENTS.mdに不変条件を箇条書きで列挙する。最低限のレベル。

第2層：型として表現。 状態遷移を sum type（TypeScript の discriminated union、Rust の enum、Java の sealed class）で表現し、不正な状態をそもそも書けないようにする。

type Reservation =
  | { status: "PendingConfirmation"; reservedAt: Date }
  | { status: "Confirmed"; confirmedAt: Date }
  | { status: "Cancelled"; cancelledAt: Date; reason: string };

第3層：プロパティテストとして渡す。 「どんな入力に対してもこの不変条件が満たされる」というプロパティを property-based test（QuickCheck系）として書いて渡す。AIが生成したコードを実行して、プロパティが破れたら不変条件違反として弾く。

第2層と第3層を併用すると、AI生成コードに混入しがちなビジネスロジック起因の論理欠陥を構造的に防げる。ドメインに直結する不整合を、人間の遵守意志ではなく型システムとテストに守らせる、という構造だ。

5. ユースケース仕様（Given/When/Then）

BDD（Behavior-Driven Development）の Given/When/Then 形式は、AIに業務シナリオを渡す方法として極めて相性がいい。

Feature: 仮押さえからの確定

Scenario: 在庫があれば確定できる
  Given 顧客 C が商品 P を仮押さえした状態
  And 商品 P の在庫が 1 以上ある
  When 顧客 C が確定操作を行う
  Then 仮押さえは Confirmed に遷移する
  And 商品 P の在庫が 1 減る

Scenario: 在庫がなければ確定できない
  Given 顧客 C が商品 P を仮押さえした状態
  And 商品 P の在庫が 0
  When 顧客 C が確定操作を行う
  Then 仮押さえは PendingConfirmation のまま
  And ドメインイベント StockShortage が発生する

これをAIに渡すと、テストコードが先に書ける状態になる。AIにテストを書かせてから実装を生成させる流れが取れる。実装の正しさは仕様で担保されるという TDD/BDD の構造が、そのままAI支援にも持ち込める。

Liu Shangqi の Spec-Driven Development はまさにこの方向の体系化だ⁵。「specs should still use domain-oriented ubiquitous language to describe business intent (中略) with a clear structure, with a common style to define scenarios using Given/When/Then」と明示している。

AIへの渡し方——4つの実装パターン

「何を渡すか」が決まっても、「どう渡すか」を間違えるとAIは無視する。実装パターンは4つある。

flowchart TB
    A["ドメイン定義<br>(UL/Model/BC/Invariants/UseCase)"]
    B1["Pattern 1: プロンプト貼り付け"]
    B2["Pattern 2: AGENTS.md / システムプロンプト"]
    B3["Pattern 3: コード化されたドメイン型"]
    B4["Pattern 4: MCP / RAG で参照可能化"]
    C["AIによるプロトタイプ実装<br>(本番技術スタック)"]
    A --> B1 --> C
    A --> B2 --> C
    A --> B3 --> C
    A --> B4 --> C

Pattern 1: プロンプト貼り付け。 最低限の渡し方。チャット欄に用語集と Given/When/Then を貼って「これに従って実装して」と指示する。短いタスクには有効だが、コンテキストウィンドウが長くなるとAIが用語集の冒頭を忘れる。

Pattern 2: AGENTS.md / システムプロンプト。 Claude Code、Cursor、Cline などのAIエージェント系ツールは、リポジトリ直下の AGENTS.md（または CLAUDE.md、.cursorrules）を毎ターン自動でロードする。ここにドメイン用語集、Bounded Context マップ、不変条件を書いておくと、AIは毎回それを参照しながら生成する。本記事の文脈で最も実用的なパターンだ。

Pattern 3: コード化されたドメイン型。 ドメインモデルを TypeScript の型、Java の record、Python の Pydantic モデルとして先に確定してリポジトリにコミットしておく。AIはコードを読みながら生成するので、型に違反するコードは「ビルドが通らない」という形で物理的に弾かれる。人間の遵守意志に頼らず、コンパイラに守らせるのが要点だ。

Pattern 4: MCP / RAG で参照可能化。 ドメイン用語集やADR（Architecture Decision Record）、過去の業務ドキュメントをMCPサーバーやRAGの索引として渡す。AIは「Reservation の正確な定義は？」と必要時に検索できる。プロンプトに全部詰め込まずに済むので、ドメインが大きい場合に有効。Russ Milesが紹介する DICE（Domain-Integrated Context Engineering）の発想¹がこれに近い——ドメインオブジェクトを first-class context unit として扱う。

実務上は Pattern 2 + Pattern 3 の併用が中核になる。AGENTS.md でドメイン語彙と Bounded Context を毎ターン渡し、型としてコミットされたドメインモデルで物理的な強制を加える。Pattern 4 はドメインが大きくなってから足す。Pattern 1 は実験用。

本番技術で作ることの効用

ここで「本番技術でプロトを作る」前提が効いてくる。

ドメインモデルがそのまま資産になる。 TypeScript で書いたドメイン型、Pydantic で書いたバリデーション、Java の record は、プロトタイプから本番にそのままコピーできる形をしている。専用プロトタイピングツールが生成する独自フォーマットだと、引き継ぎ時に書き直しが必須になる。本番技術なら、最悪コードは捨ててもドメインを表現するコードだけは確実に残せる。

捨てる/残すの判断が技術的に独立して立つ。 Martin Fowler の Sacrificial Architecture が言うように⁶、初期のコードは捨てて書き直す前提が成立する場合がある。だがそれは「捨てる前提のコード」と「残せるコード」を切り分けられて初めて意味を持つ。本番技術で書かれていれば、エンジニアは部品レベルで「これは残す、これは捨てる」と判断できる。Fowler 自身が「捨てる前提でも内部品質とモジュール境界は維持する」と強調しているのと同じ構造だ。

エンジニアの選択肢が広がる。 引き継ぎ時にエンジニアが「ドメインドキュメントだけ受け取ってゼロから書き直す」「コードもベースに使う」「一部のモジュールだけ流用する」を選べる。独自フォーマットで書かれていると、この選択肢自体が消える。

ただし誤解を避けたい。本番技術で書いたから本番品質、ではない。AI が生成したコード一般の品質問題は、技術スタックによらず別途扱う必要がある。引き継ぎ可能性が高いことと、引き継いだコードが本番に耐えることは別の話だ。後者は本記事の射程外で、AI生成コードのレビューと品質保証の一般論として扱うべき領域になる。

ワークフローを支える役割——3人と「隠れた4人目」

ここまでは手法の話だった。だが手法が成立するには、それを動かす役割が要る。このワークフローには概念的に4つの役割がある。1人で複数を兼ねることはあるが、能力要件が違うので分けて考える。

役割1：ドメイン定義者

やること：

• 業務エキスパートとの対話で、UL・Bounded Context・不変条件・ユースケースを言語化する
• ドメインモデル（Aggregate / Entity / Value Object）を設計する
• DDDの戦略的設計を担う

使えるワークショップ手法：

ドメイン定義を作る手段として、以下のワークショップ手法が有力だ。これらは対立せず、組み合わせて使うのが普通：

• Event Storming（Alberto Brandolini）：ホワイトボード（または Miro / Mural などのオンライン付箋ツール）上で付箋を使ってドメインイベントを時系列に並べる。10〜20人で半日〜2日。業務フロー全体の可視化と Bounded Context の発見に強い
• Domain Storytelling（Stefan Hofer / Henning Schwentner 共著）：エキスパートに業務を「物語」として語ってもらい、アクター・アクション・対象物を可視化する。3〜5人で1〜数時間。暗黙知の引き出しに強い
• Event Modeling（Adam Dymitruk）：Event Stormingの発展形で、UI/コマンド/イベント/ビューまで統合的に設計する。1〜2日で詳細な設計

実務では「Event Stormingで全体を発見 → Domain Storytellingで個別深掘り → ドメイン定義の5要素に落とす」という併用が多い。

これらが本ワークフローと噛み合う最大の利点は、成果物がそのままAGENTS.mdに落ちることだ。Event Stormingのオレンジ付箋（ドメインイベント）はAGENTS.mdの「ドメインイベント一覧」に、紫付箋（ポリシー）は「不変条件」に、引かれた境界線は「Bounded Contextマップ」に、それぞれ自然に対応する。ワークショップが終わった時点で AGENTS.md がほぼ完成する、という効率的な引き渡しが可能だ⁷。

必要なスキル・知識：

• 業務ドメインへの深い理解（または業務エキスパートとの円滑な対話能力）
• DDDの戦略的設計パターン（UL、BC、Context Map）
• ファシリテーション能力——上記のワークショップ手法を回せる
• 言語化能力——曖昧な業務知識を構造化されたモデルに変換できる

典型ペルソナ： ドメインエキスパート寄りのアーキテクト、シニアPM、ビジネスアナリスト出身のエンジニア

役割2：プロト作成者

やること：

• ドメイン定義をAIに渡して、本番技術スタックでプロトを作らせる
• 顧客や関係者と動作確認しながらイテレーションする
• プロト中に発見した業務ルールのズレを定義者にフィードバックする

必要なスキル・知識：

• 業務知識——AIの出力が業務的に妥当かを判断できる
• 最低限のDDD語彙——UL・BC・不変条件の意味を理解できる
• AIプロンプト能力——目的に合わせて指示を出せる
• 出力の妥当性判断——動作とコード両方を見て「これは仕様通り」「これは違う」を区別できる
• 言語化と還流能力——発見をドキュメントに戻せる

典型ペルソナ： PM、ビジネスアナリスト、プロダクトオーナー、業務知見のあるエンジニア

重要な前提： この役割は「ド素人」ではダメだが、フルスタックエンジニアでなくていい。コードが読めるとなお良いが、書けなくてもよい。逆に「業務もよく分からない・出力を判断する目もない」人がやると、AIが出した流暢な誤りに気づけずに「動いてるじゃないですか」で本番化が進む——これが本ワークフローの典型的事故経路だ。

役割3：本番化エンジニア

やること：

• プロトと定義を引き継いで、本番品質に作り直す
• 本番技術スタックの実装、テスト、セキュリティ、運用設計、CI/CDを担当
• プロトコードの「捨てる/残す」を判断し、残す部分は本番品質に持ち上げる

必要なスキル・知識：

• 本番開発の全般スキル（テスト戦略、セキュリティ、性能、可用性、運用設計）
• ドメインモデルからの逆解析——プロトのコードから定義との整合を読み解ける
• 捨てる/残すの判断軸——内部品質、モジュール境界、テストカバレッジで判定できる
• DDDの戦術的設計——Aggregate Root の実装、Repository、Domain Event の扱い

典型ペルソナ： シニアエンジニア、テックリード、アーキテクト

役割4：AI環境を整備するエンジニア（隠れた4人目）

ここが本ワークフローを安定して回す最大の鍵だ。役割2の能力要件を構造的に下げるために、エンジニアが事前に「足場」を組む。

やること：

• プロト作成者が「AIに話しかけるだけで安全にプロトが作れる」環境を事前準備する
• 役割1の定義を、AIが毎ターン確実に参照する形に落とす
• ドメイン型・テンプレ・MCP・Skills・ガードレールCIをセットで用意する

必要なスキル・知識：

• AIエージェントツール（Claude Code、Cursor、Cline等）の運用知識
• AGENTS.md / システムプロンプト設計
• ドメイン型の事前設計と実装
• MCPサーバー構築、RAGパイプライン設計
• CI/CDでのガードレール実装

典型ペルソナ： AI ツールに精通したシニアエンジニア、Developer Experience担当、プラットフォームエンジニア

この4人目を置くか置かないかが、プロト作成者の能力要件を「業務に明るいPM」レベルにまで下げられるか、それとも「エンジニア並みの目利き」を要求してしまうかを分ける。

役割2の能力要件を下げる——事前整備で組む足場

役割4が具体的に何を組むか。役割2を「ド素人に近い人でも安全に動かせる」状態に持っていくための足場を整理する。

AGENTS.md / CLAUDE.md / .cursorrules

リポジトリ直下に置くと毎ターン強制ロードされる。ここに以下を書く：

• ドメイン用語集（UL）と禁則
• Bounded Context マップ
• 不変条件のリスト
• コーディング規約・ファイル構造ルール
• AIへの行動指針（「不明な業務用語は推測せず質問せよ」など）

プロト作成者は AGENTS.md を意識せずに AI に話しかけるだけで、AIは自動的にドメイン定義を踏まえて応答する。役割4 が AGENTS.md の品質を担保する責任を持つ。

ドメイン型の雛形を先にコミット

Entity / Value Object / Aggregate Root の型と状態遷移を、TypeScript・Python・Java で先にリポジトリに置いておく。プロト作成者がAIに「予約機能を作って」と言うと、AIは既存の型を読み込んで、型に従ったコードしか書かない。型違反は型エラーで弾かれるので、プロト作成者の目利きに依存しない品質保証が効く。

テンプレートリポジトリ

ACL、テスト雛形、CI/CD、認証・認可、ログ収集、エラーハンドリングが最初から揃ったテンプレを用意する。プロト作成者は「テンプレを fork して話しかける」だけで始められる。ゼロからの環境構築や、認証・セキュリティの自前実装をAIにさせなくて済む——これが安全性を大きく上げる。

カスタムMCPサーバー

ドメイン用語集、ADR、過去の業務文書、関連DBスキーマを参照可能にする MCP サーバーを役割4 が立てる。AIは「Reservation の正確な定義は？」「過去にこの業務に関するADRはあるか？」と必要時に検索できる。プロンプトに全部詰め込まずに済むので、ドメインが大きい組織で特に効く。

ドメイン特化Skills

Claude Code や Cursor のスキル機能（コマンド化された手順書）を活用して、「予約コンテキストでの実装」「決済コンテキストへの連携」などのお決まりパターンを呼び出せるようにする。プロト作成者は /create-reservation-feature のような形で起動でき、AIは事前定義された手順とドメイン制約に従って実装する。

ガードレール付きCI

CIで以下を自動チェックする：

• 用語の禁則違反（Reservation を Booking に書き換えていないか）
• Bounded Context の境界越境（顧客予約コンテキストに決済処理が混入していないか）
• 認証・認可ミドルウェアの無効化
• ドメイン型違反

CIが fail すれば、プロト作成者は変更が問題であることをAI経由で即座に知る。プロト作成者が間違いに気づけない問題を、CIが代わりに気づく——これが事前整備の本質だ。

足場の効用

これらが揃っていると、役割2 の能力要件はこう変わる：

役割2 が必要とする能力	足場なし	足場あり
ドメイン定義の理解	必須・深いレベル	必須・最低限でOK
AI出力の品質判断	必須・エンジニア並み	必須・業務妥当性のみ
セキュリティ・性能の判断	必須	不要（テンプレとCIが担保）
コーディング規約の遵守	必須	不要（AGENTS.md と型が担保）
用語・境界の遵守	必須	不要（CIが検出）

足場なしのワークフロー だと、役割2 はほぼエンジニアでないと務まらない。足場ありのワークフロー だと、業務に明るいPMやBAでも安全に回せる。

つまり「非エンジニアでもAIプロトを作れる」というのは、暗黙のうちに「役割4 のエンジニアが事前に足場を組んだ上で」を含意している。この前提を明示せずに「AIで誰でも開発できる時代」という言い方をすると、足場を組まないまま役割2 を素人に任せて事故るパターンが量産される。

この手法固有の落とし穴

「AIが用語を意訳する」「不変条件を無視する」「Bounded Context の境界を踏み越える」「セキュリティ脆弱性が混入する」——よく挙がる懸念だが、これらは本手法固有の問題ではない。AIにコードを書かせる全ての場面で発生し、AGENTS.md + 型 + 自己レビューループや静的解析で対処する一般論だ。これらは AI 開発全般の問題として別途扱う。

本記事ではここに紙幅を割かず、DDDファースト × AIプロトというこの手法に固有の落とし穴を4つに絞って整理する。固有である理由は、いずれも「ドメインを先に定義する」という前提から構造的に発生するからだ。

落とし穴1：定義品質が結果にそのまま伝播する

AIは指示を正確に実装する能力が高い。だからこそ、定義が雑だと雑なまま正確に実装される。

例えば、UL の用語集で「Reservation」の状態遷移を Pending → Confirmed → Cancelled の3状態しか書いていないとする。だが実際の業務には「Expired（仮押さえ期限切れ）」と「Refunded（払い戻し済み）」がある。AIはこの不足を気づかずに正確に3状態だけで実装する。プロトは動く。顧客に見せても「動いてる」と言われる。問題は本番運用が始まってから露呈する。

これは「動くプロトを先に作って後でドメインを整理する」フローでは、むしろ起きにくい。AIが業務を推測する余地があると、推測の段階で抜けが顕在化することがある。ドメイン定義を先に固定する手法では、定義者の見落としがそのまま本番化リスクになる。

対処は、定義をAIに渡す前に複数のドメインエキスパートでクロスレビューする時間を確保すること。「定義のドラフト→エキスパート相互レビュー→AIプロト→顧客レビュー」をワークフローに組み込む。AIプロトを早く回したい誘惑に負けて、このレビュー工程を省略しない。

落とし穴2：プロト中の発見が定義側に戻らない

AIにプロトを作らせている過程で、「あ、この業務ルールは仕様書とは違う」「ここに境界が必要だ」と気づくケースは普通にある。問題はその発見がドメイン定義側に還流するかだ。

還流しないと、プロトのコードには新しい知識が反映されているが、AGENTS.md やドメインモデル定義は古いままになる。次のプロトイテレーションで、AIは古い定義に基づいて、せっかく直したはずの箇所をまた元に戻してくる。これは「AIが指示を破る」のではなく、人間側が定義の更新を怠った結果起きる、本手法固有の現象だ。

対処は、プロト→定義への還流を明示的な工程として組むこと。プロトのコミットメッセージや PR に「これに伴う定義の更新」を必須項目として要求する、定期的に「コードと定義のギャップ会」を開く、定義側の変更も Pull Request で扱う、など。ドメイン定義は静的な仕様書ではなく、コードと並んで継続更新される生きた資産として扱う。

落とし穴3：境界の早期固定がドメイン発見を阻害する

DDDの戦略的設計は、本来「学びながら境界を見直す」発想だ。最初の Bounded Context マップは仮説であって、プロジェクトが進むなかで境界を引き直すことを Evans も Vernon も繰り返し強調してきた。

ところが「ドメイン定義を先に固定してAIに渡す」流れを律儀に運用すると、最初に引いた境界が動かしにくくなる。AIはその境界を前提にファイル構造を組み、コードを書く。後から「顧客予約コンテキストと決済コンテキストは実は同じ集約に統合すべきだった」と分かっても、生成済みのコードベース全体に境界の影響が及んでいて、書き直しの心理的コストが高くなる。

対処は、初期の境界を「仮置き」と明示すること。AGENTS.md に「現在の Bounded Context マップは vN（仮）」と書き、プロトのマイルストーン終了時に「境界レビュー会」を入れる。境界を変えたら、それを定義側に反映する作業をコードのリファクタリングよりも先に置く。境界は神聖ではない、と最初から運用に組み込んでおく。

落とし穴4：過剰定義がウォーターフォール化を招く

「完璧に定義してからAIに渡す」が癖になると、定義作成にかける時間が無限に伸びる。これは BDD や形式仕様が歴史的に陥った「仕様書を書きすぎる」罠と同じ構造だ。AIに渡す前にユビキタス言語を100語、Bounded Context を10個、ユースケースを50個書く——という方向に進むと、プロトに到達する前に数週間が消える。AIの早い動作確認価値が完全に消える。

これは Sacrificial Architecture の議論⁶が示唆する「捨てる前提でも内部品質は維持する」の裏返しでもある。定義は完璧でなくていいが、捨てるつもりで書くわけでもない——という微妙なバランスが必要だ。

対処の指針は「最小起動セット」を決めること。例えばこう：

• ユビキタス言語：最重要な5〜10語、それぞれ1〜2行の定義と禁則
• ドメインモデル：1〜2個の Aggregate Root とその直接の Entity / Value Object
• Bounded Context：1〜3個、それらの関係（仮）
• 不変条件：「絶対に違反してはならない」を3〜5項目
• ユースケース：核となる1〜3シナリオを Given/When/Then で

これだけ揃ったらAIに渡してプロトを始める。残りは落とし穴2の還流ループで育てる。「全部書いてから渡す」を断つことが、AIプロトの速度メリットを守る唯一の方法だ。

引き継ぎとプロトタイプ本番扱い問題（軽く）

本記事の主軸は「DDDを先に置いてAIに作らせる」構造と「役割設計＋足場づくり」なので、引き継ぎとプロトタイプ本番扱いの2論点は軽く触れるに留める。

引き継ぎ。 本番技術でドメイン型を先に固定していれば、役割3（本番化エンジニア）は（a）ドメインドキュメントだけ受け取って一から書く、（b）コードもベースに使う、（c）モジュール単位で取捨選択する、を選べる。判断軸は「テストカバレッジ」「セキュリティスキャン通過状況」「コードの内部品質」など複数あるが、選択肢があること自体が DDD ファースト × 本番技術プロト × 役割4 の足場の恩恵だ。判断軸の詳細は別の議論。

プロトタイプを本番扱いされる問題。 「動いてるならそのまま使えるじゃないですか」と顧客や経営層に詰められる現象は、本ワークフローでも起きうる。だがこれは本ワークフロー固有ではなく、Mock-up でも β版でも常に起きる古典的問題だ。Retoolが指摘するように⁸、同じSQLインジェクションでもプロトタイプなら影響範囲は小さいが、本番Postgresに繋がれば情報漏洩になる。プロトと本番を運用上どう区切るかは別途扱うべきテーマで、本記事の射程ではない。

まとめ

「動くものを早く見せる」と「業務を正しく理解したシステムを作る」は両立できる。条件は3つ。

1つ目は順序——手法。 DDDでドメイン定義を先に作り、それをAIに渡してから本番技術でプロトを書かせる。逆の順序を取ると、AIが選んだ語彙と業務推測が既成事実化して、後から戻せなくなる。AIに渡すべきは5要素——UL、ドメインモデル、Bounded Context、不変条件、ユースケース仕様。渡し方の中核はAGENTS.md（毎ターン強制ロード）とコード化された型（コンパイラに強制させる）の併用だ。

2つ目は役割——人材。 ワークフローには4つの役割がある。ドメイン定義者（業務を言語化する人）、プロト作成者（定義をAIに渡してプロトを作る人）、本番化エンジニア（プロトと定義を本番品質に作り直す人）、そしてAI環境を整備するエンジニア——「隠れた4人目」だ。この4人目がいるかどうかが、プロト作成者の能力要件を業務担当者レベルまで下げられるかを決める。

3つ目は足場——事前準備。 4人目が組むのは、AGENTS.md・ドメイン型雛形・テンプレートリポジトリ・カスタムMCP・ドメイン特化Skills・ガードレールCIのセット。これらが揃って初めて「業務に明るいPMでも安全にAIプロトを作れる」が成立する。「非エンジニアでもAIで開発できる」は、暗黙のうちに「エンジニアが事前に足場を組んだ上で」を含意している——この前提を曖昧にしたまま素人にAIを渡すと、流暢な誤動作が本番化する。

本手法に固有の落とし穴は4つ——定義品質の前倒し責任、プロト中の発見の還流ループ、境界の早期固定、過剰定義によるウォーターフォール化。いずれも「ドメインを先に定義する」前提から構造的に発生するので、定義者の責任を重く見ること、定義側の更新を継続工程として組むこと、境界を仮置きと明示すること、最小起動セットから始めることで対処する。なお、AIがコードを書く際に一般に発生する問題（用語意訳・不変条件無視・境界越境・セキュリティ脆弱性）はAI開発全般の論点で本記事の射程外だ。

DDDが20年磨いてきた成果物——ユビキタス言語、ドメインモデル、Bounded Context——は、そのままAIへの最良のコンテキストになる。AIが入ったからDDDが古びるのではなく、AIが入ったからこそDDDの戦略的設計が現場で生きる。さらに、役割設計と足場づくりを含めれば、DDDは「AI時代に成果を出すための組織設計」にまで射程を広げる。これがおそらく、Khalili が整理する Eric Evans の Explore DDD 2024 講演の示唆³と、DDD Academy が2026年にワークショップ化した方向⁴の、実務側からの応答だ。

思考実験編もあわせてどうぞ： 本記事は手法・役割・足場の「設計論」に焦点を当てた。これを具体的な架空シナリオで動かす思考実験編 ホテル予約システムで思考実験する——DDDファーストなAIプロトタイピングをNext.js 16 + OpenNextで実装する を同時公開している。Event Storming セッションの進め方、生成される AGENTS.md の実例、ドメイン型の TypeScript 実装、Claude Code での対話例、CIのガードレール例、本番化エンジニアによる引き継ぎ判断——を1つのシナリオを通して示している。本記事と併せて読むと、設計論と実装の両側が揃う構成だ。

関連記事

このテーマに関連する他の記事もご覧ください：

• ホテル予約システムで思考実験する——DDDファーストなAIプロトタイピングをNext.js 16 + OpenNextで実装する - 本記事の思考実験編。同時公開、合わせて読むことを推奨
• VSAとDDDをAI開発でどう組み合わせるか - 同シリーズ。VSAとDDDをAI開発文脈で組み合わせる戦略的議論
• VSA×DDD×ハーネスの3層統合設計 - 同シリーズ。「分けろ」と「共用化」の矛盾を境界づけられたコンテキストで解く
• 若手のためのバイブコーディング実践ガイド - 個人レベルでのAIプロトタイピング。本記事の組織版に対する個人版
• シンプルに作るが一番速い - ドメインを先に決める発想と、設計レベルでの予防戦略

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

1. Domain Driven Agent Design - Russ Miles (2025). bookingとreservationを取り違えたAIエージェントの寓話。Rod JohnsonのDICE（Domain-Integrated Context Engineering）フレームワーク紹介。【信頼性: 中】（実務家ブログ） ↩︎ ↩︎² ↩︎³

2. AI for Requirements Engineering: Industry Adoption and Practitioner Perspectives - arXiv preprint 2511.01324 (2025). 実務者55名対象の84日間調査。58.2%がREでAI使用、Human-AI Collaboration が49-60.5%で支配的。【信頼性: 高】（プレプリント、方法論明示で実証性高い） ↩︎

3. Domain Driven Design in the AI Era: From Models to Meaning - Alireza Rahmani Khalili (2025). UbiquitousLanguageを人間・ソフトウェア・AIの三者間意味契約、BoundedContextを cognitive firewall として再定義する論考。Eric Evansの Explore DDD 2024 講演を冒頭で引用しているため、本記事中の Evans 言及はこの Khalili 論考経由。【信頼性: 中】（個人ブログだが論理展開が明快） ↩︎ ↩︎² ↩︎³

4. Accelerate your Strategic Design with Large Language Models - DDD Academy / Thomas Coopman (Aardling) (2026). LLM × 戦略的設計の正規2日間ワークショップ。【信頼性: 中〜高】（DDDコミュニティ公式の教育機関） ↩︎ ↩︎²

5. Spec-driven development: Unpacking one of 2025’s key new AI-assisted engineering practices - Liu Shangqi, Thoughtworks APAC (2025). 仕様駆動開発がドメイン指向ユビキタス言語をBDD/DDDから継承。Given/When/Then 形式の有効性を明示。【信頼性: 中〜高】（Thoughtworks公式ブログ） ↩︎ ↩︎²

6. Sacrificial Architecture - Martin Fowler (2014). 「数年後に捨てる前提で設計する」概念。捨てる前提でも内部品質とモジュール境界は維持。【信頼性: 高】（業界権威） ↩︎ ↩︎²

7. Designing Scalable Multi-Agent AI Systems: Leveraging Domain-Driven Design and Event Storming - Kaustav Dey, Kunal Nandi, DZone. マルチエージェントAIシステムの設計にDDDとEvent Stormingを組み合わせる7ステップのワークフロー、サプライチェーン事例。【信頼性: 中】（業界メディア記事） ↩︎

8. The Risks of Vibe Coding: Security Vulnerabilities and Enterprise Pitfalls - Retool. プロトタイプ脆弱性は影響範囲が小さいが、本番Postgresに繋がれば情報漏洩になる、と影響度の差を明示。【信頼性: 中】（ベンダーブログだが論点は妥当） ↩︎