マワルくん
・AI時代にDDDは必要か知りたい
・AI生成コードの設計が崩れてきた
・AIに実装を任せる範囲を広げたい
Claude CodeやCodexのようなAIコーディングツールが実装を担うようになり、「AIがコードを書くなら、DDD（ドメイン駆動設計）を学ぶ意味はないのでは」という疑問を持つエンジニアが増えています。一方で現場では、AIに実装を任せるほど用語が揺れ、境界が崩れ、業務ルールが漏れるという問題も起きています。
DDDとは、業務（ドメイン）の理解を中心に据えてソフトウェアを設計する方法論です。先にお伝えしておきたいのは、AI時代にDDDが必要なのは、AIがコードを書けないからではないということです。むしろAIが高速にコードを書けるからこそ、「何をコードにするべきか」を明確にする力の価値が上がります。本記事では、AI時代にDDDの役割がどう変わるか、AIコーディングで起きる問題、重要になるスキル、仕様をAIへ渡す方法、AIと人の役割分担まで解説します。
この記事のゴール（読了目安 約9分）
DDDを「人が複雑なコードを書くための方法論」ではなく「人とAIが業務知識・境界・ルールを共有するための設計言語」として理解し、何を学ぶべきか判断できるようになる。
AI時代のDDDとは
DDDとは
DDD（Domain-Driven Design、ドメイン駆動設計）とは、業務の深い理解をソフトウェアの構造にそのまま反映させる設計方法論です。業務の言葉をコードの言葉と一致させる「ユビキタス言語」、システムを責任範囲で区切る「境界づけられたコンテキスト」、業務ルールを守る単位である「集約」といった考え方で構成されます。これらの用語の定義は、Eric Evans の書籍の内容を要約した公式のリファレンスにまとめられています（Domain Language「DDD Reference」）。従来は、複雑な業務システムを人間が長期にわたって開発・保守するための方法論として使われてきました。
AI時代に役割が変わる
AIが実装を担うようになっても、DDDは不要になりません。役割が変わります。従来のDDDは「人とコードをつなぐ方法」でした。AI時代のDDDは、「人とAIとコードをつなぐ方法」になります。業務の意味・境界・ルールを、人間のチームメイトだけでなくAIエージェントにも伝わる形にする。これがAI時代のDDDの中心的な役割です。
なぜAI時代に重要になるのか
理由は4つあります。
- AIは曖昧さにも従う: 曖昧な指示を渡せば、AIは曖昧さを推測で埋めて、もっともらしいコードを高速に生成する
- コード生成コストが下がった: 書く量に制約がなくなった分、悪い設計のまま大量のコードが生まれうる
- 設計ミスの影響が大きくなる: 生成が速いほど、間違った境界・間違ったモデルが広がる速度も上がる
- 業務知識が差になる: コードを書く能力は誰でもAIで底上げできる。差がつくのは、業務を正しくモデル化できるか
まとめると、コード生成のコストが下がるほど、設計の重要性は上がるという構図です。仕様や境界が悪ければ、AIは間違った設計を高速で大量に実装します。
AIコーディングで起きる問題
実際にAIへ実装を任せた現場で起きやすい問題は、用語が揺れる、責務が混ざる、境界を越えて変更する、業務ルールが漏れる、コード量だけ増える、の5つです。
たとえば同じ概念が「customer」「client」「user」と揺れたまま実装が進む。注文のロジックが在庫のモジュールに書かれる。「キャンセルは発送前のみ」という業務ルールがUI側のチェックだけで実装され、別の経路から破れる。いずれも、AIの能力不足ではなく、AIに渡した文脈（コンテキスト）の不足が原因です。そしてこれらは、DDDが数十年かけて解いてきた問題そのものです。
重要になるDDDスキル7つ
AI時代に重要になるDDDスキルを整理します。以下の表にまとめます。
注目したいのは、7つのうちコードを書くスキルが1つもないことです。上流の理解・定義と、下流のレビューに重心が移ります。以降の章で、中核となる3つを掘り下げます。
ユビキタス言語
ユビキタス言語とは、業務担当者・エンジニア・コードが同じ言葉を使うという原則です。AI時代には、ここにAIも同じ言葉を使うが加わります。
「顧客」「注文」「引当」といった用語の定義と関係を用語集として明文化し、リポジトリに置いてAIに参照させる。これだけで、生成コードの命名の揺れと概念の取り違えは大きく減ります。人間のチームでは会話で補正できた揺れが、AIでは放置されたままコードになるため、明文化の価値は従来より上がっています。
境界設計
境界づけられたコンテキスト（Bounded Context)とは、モデルと用語が通用する範囲を区切る考え方です。同じ「商品」でも、販売コンテキストと在庫コンテキストでは意味も属性も異なります。
AI時代にはこの境界が、そのままAIの作業範囲の定義になります。「このAIエージェントは受注コンテキストのみ変更可能」と限定すれば、別ドメインのロジックへ入り込む事故を構造的に防げます。境界を決めるのは業務の理解に基づく判断であり、AIに委ねられない部分です。
業務ルールの設計
不変条件（Invariant）とは、どんな操作の後でも守られるべき業務ルールです。「注文の合計金額は明細の合計と一致する」「発送済みの注文はキャンセルできない」。集約（Aggregate）は、この不変条件を守る単位としてデータと操作をまとめる設計です。
AIに実装を任せる場合、ルールを集約として設計し「状態変更はこの経路のみ」と明示しておけば、AIが業務ルールを別レイヤーに書き散らすことを防げます。データ構造ではなく業務ルールを中心に置くのがポイントです。
仕様をAIへ渡す方法
モデルができたら、AIへ渡せる形にします。
- 自然言語だけに頼らない: 会話文の指示は解釈の幅が残る。用語集・モデル図・ルール一覧を構造化して渡す
- Event Stormingを起点にする: Alberto Brandolini が提唱した、複雑な業務ドメインを共同で探索するためのワークショップ形式（EventStorming 公式サイト）。業務イベントを洗い出して整理し、その結果を構造化してAIへ渡す
- ルールを明文化する: 不変条件・依存方向の禁止事項・命名規約をリポジトリ内のガイダンスとして配布する
- 受け入れ条件を決める: 「何ができたら完成か」をテスト可能な形で先に定義する
近年は、DDDの思考プロセスを発見・戦略的設計・戦術的設計・検証といった工程に分解し、それぞれをAIエージェントのスキルとして支援させる試みも出ています。いずれの場合も、工程の出力を採用するかどうかは人が判断します。
DDDでAIを制御する
DDDの成果物は、AIエージェントのガードレールとしても機能します。境界づけられたコンテキストで「変更してよい範囲」を限定し、集約で「守るべき状態変更のルール」を定め、アーキテクチャルールで「禁止する依存方向」を明示し、テストでルール違反を機械的に検出する。
この4点をそろえると、AIに任せる範囲を広げても設計が崩れにくくなります。ガードレールは活用を止めるためではなく、安心して任せる範囲を広げるためのものです。自律的に動くAIの基本は、AIエージェントの記事で解説しています。
AIと人の役割分担
役割を整理します。以下の表にまとめます。
学習の順序としては、ユビキタス言語→Event Storming→境界づけられたコンテキスト→集約と不変条件→コンテキストマップ→仕様化→AIレビュー、と業務理解に近い側から進めるのが実務的です。パターンの暗記より、業務をモデル化する経験を優先してください。
【プロの視点】安く書けるほど設計が高くつく
「AIがコードを書くならDDDは不要」という直感は、DDDをコードの書き方の話だと捉えたときに生まれます。しかし実際に起きているのは逆の現象です。
コード生成のコストが下がった結果、設計の誤りが実装されるまでの時間が短くなり、誤った実装が増える速度が上がりました。従来は人間の実装速度がボトルネックで、その間に設計を見直す余地がありました。AI時代はその猶予がありません。「顧客とは何か」「注文はいつ成立するのか」「キャンセルできる条件は何か」。こうした業務上の意味は、コード生成モデルだけでは決められず、誤ったまま渡せば誤ったまま高速に実装されます。
つまりAI時代の生産性は、コードを書く速さではなく、推測の余地が少ない仕様をどれだけ早く用意できるかで決まります。DDDは、その仕様を作るための最も体系化された方法論です。
【waltsu視点】AIの推測範囲を減らす
DDDの各要素は、AIへの「コンテキスト設計」として読み替えられます。ユビキタス言語で用語を統一し、境界づけられたコンテキストで責任範囲を定義し、集約と不変条件で守るべきルールを定義し、コンテキストマップで関係を定義する。これらをAIへ渡すことは、AIが実装時に推測しなければならない範囲を減らすことに他なりません。
waltsuは開発会社ではありませんが、AIによるコンテンツ制作の運用で同じ構造を実践しています。用語の定義、記事ごとの守備範囲、守るべき執筆ルールを文書化してAIに渡し、推測の余地を減らす。ルールを整えるほどAIに任せられる範囲が広がり、確認の手戻りが減って、同じ期間で試せる回数が増えました。
ドメインが違っても原理は同じです。AIに任せる範囲を広げたければ、判断基準を機械可読にする。DDDはソフトウェア開発において、それを最も高い解像度で行うための道具です。
よくある質問
AI時代にDDDは不要になりますか？
不要になりません。むしろコード生成が速くなるほど、何をコードにするべきかを定義する力の価値が上がります。DDDの重心が、コードの書き方から、業務知識をAIへ渡せる形にする方法へ移ります。
DDDの何から学べばいいですか？
ユビキタス言語とEvent Stormingからが実務的です。業務の言葉と流れを整理するスキルは、AIへ渡す仕様の品質に直結します。集約などの戦術的パターンはその後で十分です。
AIにDDD設計を任せられますか？
モデルの候補出しや構造の整理は任せられます。ただし、境界をどこに引くか、何が重要な問題か、トレードオフをどう判断するかは、業務理解に基づく人の判断が必要です。
Claude Codeでも使えますか？
使えます。Claude Code はリポジトリの CLAUDE.md を毎回のセッション開始時に読み込み（Claude Code ドキュメント「How Claude remembers your project」）、Codex は作業を始める前に AGENTS.md を読みます（Codex ドキュメント「AGENTS.md」）。用語集・境界の定義・アーキテクチャルールをそこへ置けば、それを参照して実装します。ツールに依存する話ではなく、渡すコンテキストの設計の話です。
DDDとAIエージェントは相性がいいですか？
相性は良いと考えられます。境界づけられたコンテキストはエージェントの作業範囲の定義に、不変条件はエージェントが守るべきルールの定義にそのまま使えるためです。
まとめ
この記事の要点
・AI時代にDDDが必要なのは、AIがコードを書けないからではない。安く書けるほど設計が高くつくから
・AI生成コードの問題（用語の揺れ・境界侵犯・ルール漏れ）の原因は、渡した文脈の不足
・DDDは「人とコードをつなぐ方法」から「人とAIとコードをつなぐ方法」へ広がる
・ユビキタス言語・境界・不変条件は、AIの推測範囲を減らすコンテキスト設計として機能する
AI時代のDDDは、人が複雑なコードを書くための方法論から、人とAIが業務知識・境界・ルールを共有するための設計言語へ役割を広げています。AIは実装・候補出し・リファクタリングを高速で担えますが、業務上の意味を決めること、境界を引くこと、モデルとの整合を最終判断することは人に残ります。
学ぶべきは、パターンの暗記ではなく業務をモデル化する力です。ユビキタス言語で言葉をそろえ、Event Stormingで流れを理解し、境界と不変条件を定義し、AIへ渡せる仕様に落とす。この流れを作れる人が、AIコーディングの生産性を最も引き出せます。「AIコーディングを導入したが、生成コードの設計品質や一貫性に課題がある」「AIに任せる範囲を安全に広げたい」という場合は、waltsuがAI前提の開発プロセス設計・開発組織のAI活用をご支援します。
