AI時代にこそドメイン駆動設計（DDD）が必要な理由｜再入門ガイド

AIがコードを書く時代、ドメイン駆動設計（DDD）は不要になるのか？答えは逆です。ユビキタス言語はLLMのハルシネーションを防ぐ安全機構になり、ドメインモデルは「AIへの設計図」として機能します。DDDの基本から実践ステップまで丁寧に解説します。

---

「AIがコードを書くなら、設計はもう要らない」のか？

GitHub CopilotやCursorを日常的に使い始めたエンジニアから、こんな声を聞くことが増えました。

「プロンプトを打てばコードが生成される。クラス設計なんて考えなくても動くものが作れる」

確かに、コード生成AIの精度は目を見張るほど向上しています。しかし現場では、奇妙な逆説が起きています。AIでコード生成できる量が増えるほど、"場当たりコード"の蓄積も加速しているという現象です。

誰も全体像を把握していない。似たようなロジックが至るところに散在している。仕様変更のたびに影響範囲の調査に丸一日かかる——そんな状態のコードベースが、AIによって驚くべき速度で量産されています。

2026年8月、ソフトウェア設計の第一人者である増田亨氏が公開した講義資料「今こそ問いたいソフトウェア設計 ドメイン駆動設計再入門」は、はてなブックマーク103件という高い注目を集めました。AI時代にあえて設計の原点を問い直すこの資料が注目される背景には、まさにこの逆説的な現実があります。

この記事の結論を先にお伝えします。AIはコードを書けますが、ビジネスの意図は理解できません。

AIが生成するコードの品質は、人間が与える「文脈」の品質に完全に依存します。そしてその文脈を整備する技術こそ、ドメイン駆動設計（DDD）に他なりません。

この記事では以下の4つのテーマを通じて、AI時代のDDDの意義と実践方法を解説します。

1. DDDの基本概念——何を解決する設計思想なのか
2. AIとの接点——なぜ今、DDDが再評価されているのか
3. モデリングの考え方——AI時代に適したモデリング原則
4. これからの設計アプローチ——明日から始める具体的な最初の一歩

---

そもそもドメイン駆動設計（DDD）とは？4つの基本概念をおさらい

ドメイン駆動設計（Domain-Driven Design）は、2003年にEric Evansが提唱したソフトウェア設計の思想です。「ドメイン（業務領域）の知識を中心にソフトウェアを設計する」というアプローチで、特に複雑なビジネスロジックを扱うシステムで高い効果を発揮します。

まずは4つの中核概念を整理しましょう。

ドメインモデル ― ビジネスの知識をコードの形で表現する

ドメインモデルとは、業務の知識・ルール・プロセスをオブジェクトとして表現したものです。

「注文」「在庫」「顧客」といったクラスが単なるデータの入れ物になっていないか、確認してみてください。多くのシステムでは、これらのクラスにはgetterとsetterだけが並び、業務ロジックはサービス層に漏れ出しています。これは「ドメインモデル貧血症（Anemic Domain Model）」と呼ばれる設計上のアンチパターンです。

実際の開発現場では、「注文は出荷済みになってからは金額を変更できない」というルールがどこに書かれているかを追いかけると、その設計の成熟度が分かります。ドメインモデルが適切に設計されているシステムでは、このルールはOrderクラスの中に表現され、呼び出し元がどこであっても必ず制約が適用されます。

ドメインモデルの本質は、業務ロジックと入出力（データベースアクセス、外部API呼び出し、画面表示）を分離し、ビジネスルールを凝集した場所に住まわせることにあります。

ユビキタス言語 ― 開発者とビジネス専門家をつなぐ共通語彙

「ユビキタス言語（Ubiquitous Language）」とは、開発者とビジネス専門家（ドメインエキスパート）が会話・ドキュメント・コードのすべてで使う共通の語彙体系です。

翻訳コストがバグを生む、というメカニズムを考えてみましょう。

ビジネス担当者は「会員」と言う。エンジニアはコードでuserと書く。設計書ではcustomerと表記する。データベースにはmemberテーブルがある——こうした語彙の断絶が、要件定義の食い違いやバグの温床になります。

ユビキタス言語を確立するとは、「会員」と決めたら、会話でも設計書でも変数名でもクラス名でも「会員（Member）」を一貫して使うということです。言葉の統一は、単なる命名規則ではなく、チーム全体の認識を揃えるための設計行為です。

バウンデッドコンテキスト ― モデルが通用する境界線を引く

「顧客」という言葉は、どんなシステムにも登場します。しかし、EC部門が語る「顧客」と、カスタマーサポート部門が語る「顧客」は、同じ言葉でも異なる関心事を持っています。

ECの文脈では、顧客の配送先住所や購買履歴が重要です。サポートの文脈では、問い合わせ履歴や感情状態が中心になります。これを無理に一つのモデルで表現しようとすると、肥大化して収拾がつかなくなります。

バウンデッドコンテキスト（Bounded Context）は、「このモデルはここまでの範囲で通用する」という境界線を明示的に引く概念です。コンテキストをまたぐ際には、Anti-Corruption Layer（腐敗防止層）を挟んで、異なるモデルの概念が混入しないよう保護します。

集約（Aggregate） ― 整合性を守るオブジェクトのまとまり

集約（Aggregate）は、常に整合性を保たなければならないオブジェクトの集まりです。集約には必ず「集約ルート（Aggregate Root）」となるエンティティがあり、外部からはこのルートを経由してのみ内部にアクセスできます。

例えば「注文（Order）」が集約ルートであれば、「注文明細（OrderItem）」は注文を経由してしか操作できません。これにより、注文全体の整合性（合計金額の計算、数量の制約など）は必ず注文クラスが責任を持つ構造になります。

ベストプラクティスとして、**集約は「小さく保つ」**ことが推奨されます。集約が大きくなるほど、トランザクションの競合が増え、パフォーマンスと保守性の両方に悪影響が出ます。

【補足】戦略的設計と戦術的設計の違い

DDDには「戦略的設計」と「戦術的設計」という2つの層があります。

• 戦略的設計：バウンデッドコンテキストやユビキタス言語など、システムの大きな構造を決める設計
• 戦術的設計：集約、エンティティ、値オブジェクト、ドメインサービスなど、コードレベルのパターン

初めてDDDに取り組む場合、戦術的パターン（リポジトリ、ファクトリ、ドメインサービス等）にフォーカスしがちです。しかし、まず取り組むべきは戦略的設計です。境界と語彙が曖昧なまま戦術的パターンを適用しても、効果は限定的です。

---

AI時代にDDDが再評価される理由｜3つのパラダイムシフト

では、なぜ今、AI時代にこそDDDが注目されているのでしょうか。2025〜2026年にかけて、ソフトウェア開発の現場では3つのパラダイムシフトが起きています。

シフト①「AIがコードを書くなら、人間はモデルを書く」

AI駆動開発が普及するにつれ、人間とAIの役割分担が明確になってきました。

AIが担うこと	人間（DDD）が担うこと
コード生成・実装	ドメインモデルの定義
統計的パターンの発見	ビジネス意図の構造化
提案（Suggestion）	判定・検証（Validation）
既存パターンの適用	新しい概念の命名と境界策定

この分担を見ると、人間の仕事が「消える」のではなく「抽象度が上がる」のだということが分かります。

実際の開発現場では、AIへの指示品質が、そのまま出力コードの品質に直結します。「注文を保存して」というプロンプトと、「ECサービスの注文ドメインにおいて、注文ルートアグリゲートに新しい注文明細を追加し、在庫確保イベントを発行するコードを書いて」というプロンプトでは、生成されるコードの設計品質がまったく異なります。

後者のプロンプトを書けるエンジニアは、ドメインモデルを理解しているエンジニアです。AIへの指示品質は設計品質に依存する——この事実が、AI時代にDDDスキルの重要性を逆説的に高めています。

シフト②ユビキタス言語は「セマンティック安全機構」になった

ユビキタス言語の役割は、人間同士の認識合わせに留まりません。AI時代において、LLMの解釈を制約する「セマンティック安全機構」として機能し始めています。

LLMは統計的な言語モデルです。入力に曖昧な語彙が含まれると、文脈から最も確率の高い解釈を自動選択します。これがハルシネーション（幻覚）の入口になります。

例を挙げましょう。「アカウント」という言葉は、金融システムでは「勘定科目」を指し、SaaSでは「ユーザーアカウント」を意味し、マーケティングでは「顧客企業」を表します。この語彙が精密に定義されていないまま、AIにコードを生成させると、文脈によって異なる概念が混入したコードが生まれます。

逆に、ユビキタス言語が整備されたプロジェクトでは、用語集（グロッサリー）をコンテキストとしてAIに与えることで、意図した概念の範囲内でのみコードを生成させることが可能になります。言語の精密性がセキュリティとして機能する、という新しい視点です。

シフト③バウンデッドコンテキストは「AIの統治境界」になった

バウンデッドコンテキストの役割も拡張されています。かつてそれは組織構造やチーム間の境界線を反映するものでしたが、AI時代においては確率的推論を許す範囲の定義という新しい意味を持ちます。

システムにAIコンポーネントを組み込む際、「どこまでのAI判断を許容するか」という統治（ガバナンス）の問題が生じます。バウンデッドコンテキストの境界は、そのまま「AIが確率的判断を行える範囲」を区切る境界になり得ます。

Anti-Corruption Layerは、異なるモデル間の変換層として機能するだけでなく、AI出力を常時検証するバリデーション層としても機能します。AIが推論した結果が、ドメインモデルの制約を満たしているかどうかをここで検査します。

グローバルトレンドとして注目されているのが「Agentic Mesh」パターンです。ドメインを所有するサービスと、そのサイドカーとしてAIエージェントを組み合わせる構成で、AIの判断がドメインの境界を越えないよう制御します。

増田亨氏が提示する2つの設計軸

増田亨氏のスライドが提示する2つの設計軸は、AI時代の設計スタイルを選択する際の実用的なフレームワークです。

• 軸1：「大きな事前設計」vs「小さな設計の反復」
• 軸2：「自動化」vs「人の活動支援」

この2軸を組み合わせると、4つの象限が生まれます。

	大きな事前設計	小さな設計の反復
自動化	規制業界向け基幹系（厳密な仕様が先行）	CI/CDパイプライン、MLOps（継続的な改善）
人の活動支援	ERPカスタマイズ（大規模要件定義）	SaaS・BtoC（UXを試行錯誤しながら改善）

重要なのは、どの象限が「正解」かではなく、自分のプロダクトがどの象限にいるかを意識して設計スタイルを選ぶことです。

増田氏が強調するもう一つの視点は、エンジニアを「実装者」ではなく「事業の当事者」として捉え直すことです。事業活動は本質的に不確実で複雑であり、その不確実性を構造化して扱えるエンジニアこそが、AI時代に価値を発揮できます。

---

AI時代のモデリング3原則

AI時代のモデリングには、従来のDDDの原則に加えて、LLMの特性を踏まえた新しい考え方が必要になります。

原則①自己完結モジュール設計 ― コンテキストウィンドウを境界の基準にする

LLMには「コンテキストウィンドウ」という制約があります。一度に処理できる情報量の上限です。これは設計原則として活用できます。

LLMが一度に読み切れる単位でモジュールを切る、という現実的な制約をバウンデッドコンテキストの参考基準にするのです。

依存が至るところに散らばったコードは、人間にとっても読みにくいですが、AIにとっても同様です。自己完結したモジュールは、AIへの指示に渡す「文脈の塊」として機能します。単一ファイルを渡すだけで、そのモジュールの責務と制約が理解できる構造を目指しましょう。

段階的に理解を深めていきましょう：まず「このファイルだけ読めばこの機能が理解できる」という状態を作ることが第一歩です。

原則②意図の明示化 ― 「なぜこの設計か」をコードに残す

AIはコードの"意図"を読めません。これは重大な前提です。

コードが何をするか（What）は、AIは読めます。しかし、なぜそのように設計されているか（Why）は、コメントや型定義、命名に表現されていない限り、AIには分かりません。

意図を明示化する主な手法は3つです。

1. 型による表現：stringではなくCustomerIdという値オブジェクト型を使い、「これは顧客IDである」という意図をコードに埋め込む
2. 命名による表現：processData()ではなくconfirmOrderAndReserveInventory()という名前にして、業務上の意味を明示する
3. ドメインオブジェクトによる表現：プリミティブな値の集合ではなく、業務概念を表すオブジェクトを使い、制約と振る舞いをそこに閉じ込める

これらはいずれも、AIへのプロンプトに渡す「文脈の品質」を高める設計行為でもあります。

原則③段階的・進化的設計 ― 「変化を前提とした余白」を残す

AI時代には、過剰な事前抽象化が特に危険です。

LLMを使えば、高度な抽象化やデザインパターンの適用はあっという間に生成できます。しかし、「理解されていない抽象化」は、後続の変更を妨げる最大の障壁になります。

最小構造から始めて、実際の変化に応じて育てていく——この進化的設計アプローチは、AI時代においてより重要性を増しています。最初から完璧な設計を目指すのではなく、変化を前提とした余白を残すことが、長期的な保守性につながります。

LLMを使った戦略的設計の加速（5ステップ）

DDDの戦略的設計プロセスをLLMで加速するフレームワークが、「ddd.academy」が提唱する5ステップです。

ステップ1：ユビキタス言語の確立 ドメインエキスパートとの会話録音や議事録をLLMに読み込ませ、業務用語の候補リストを生成させます。ただし、LLMが生成した用語は必ずドメインエキスパートと検証すること。自動生成された用語をそのまま使うと、技術者視点の言語が紛れ込みます。

ステップ2：イベントストーミング 「このシステムで起こるビジネスイベントを列挙して」というプロンプトでドラフトを作成し、ワークショップのたたき台として使います。

ステップ3：バウンデッドコンテキストの識別 「以下のビジネスイベントをコンテキストでグルーピングして」という指示でコンテキスト候補を生成。ただし、組織の権力関係や既存システムの制約は、LLMには分からないため、最終判断は人間が行います。

ステップ4：集約設計 各コンテキストの整合性境界をLLMに提案させ、集約候補を得ます。生成された集約が「大きすぎないか」「責務が混在していないか」は人間がレビューします。

ステップ5：技術アーキテクチャへの落とし込み コンテキストマップをもとに、サービス間の通信方式（REST/イベント）やデータ所有権をLLMに設計させます。

各ステップで重要なのは、LLMの出力は「出発点」であり、ドメインエキスパートとの検証なしに採用しないという姿勢です。

---

実践事例｜DDDがAI活用の土台になったケース

理論だけでなく、実際にDDDがAI活用の基盤として機能した事例を見てみましょう。

パーソルキャリア：データ構造改革がAI/MLの品質を決めた

パーソルキャリアでは、AI/MLを活用した求人マッチングの精度向上を目指す中で、学習データの品質という根本的な課題に直面しました。

複数のシステムにまたがって分断されていたデータ構造を、DDDの考え方で整理し直したことが転機になりました。「将来にわたって価値を持つか」を判断基準として、段階的にデータ構造を統一化。その結果、AI/MLモデルの学習データ品質が大幅に改善され、マッチング精度が向上しました。

この事例が示すのは、AI/MLの品質を決めるのは、アルゴリズムよりもデータ構造の品質だという事実です。そしてデータ構造の品質を決めるのは、その背後にあるドメインモデルの明確さです。

推進にあたっては、経営層と現場エンジニアの両輪からの推進が不可欠でした。技術的な改善が事業価値に直結することを、ビジネス言語で経営層に伝える能力——これもユビキタス言語の実践に他なりません。

グローバルトレンド：ドメイン特化モデル（DSLM）への移行

グローバルでは、汎用LLMからDomain-Specific Language Models（DSLM）への移行が加速しています。

医療、法律、金融、製造といった分野では、汎用モデルの確率的推論では精度が不足する場面があります。ドメイン特化モデルは、その領域の知識を構造化して学習させることで、より信頼性の高い推論を実現します。

ここで重要なのが、ドメイン知識の構造化がモデルの資産になるという事実です。DDDで整備されたドメインモデルとユビキタス言語は、ドメイン特化モデルの学習データとして直接活用できます。今、DDDに投資することは、将来のAIモデル資産への投資でもあります。

---

明日から始めるDDD｜最初の3ステップ

「DDDは難しい」というイメージから、なかなか踏み出せないエンジニアも多いでしょう。しかし、段階的に理解を深めていきましょう。最初の一歩は、思っているより小さくていいのです。

ステップ1：チームの用語集（ユビキタス言語）を1枚にまとめる

明日できる最初のアクションは、チームで使っている業務用語を1枚のドキュメントにまとめることです。

やり方はシンプルです。チームで頻繁に使う業務用語を10〜20個ピックアップし、それぞれについて「この言葉が指すものは何か」「何を指さないか」「別名・類義語はあるか」を書きます。

Googleスプレッドシート1枚で構いません。完璧な用語集でなくていいのです。「チームで認識が揃っていない用語が1つ見つかった」だけで、DDDを始めた価値があります。

この用語集は、後でAIへのプロンプトの前提情報として渡すこともできます。

ステップ2：バウンデッドコンテキストの境界を粗く描いてみる

次のステップは、システムの境界を粗く描くことです。図の精度は問いません。

ホワイトボードに現在のシステムを書き、「ここから向こうは別のビジネス関心事」という境界線を引いてみます。「注文管理」「在庫管理」「顧客管理」という区分けだけでも、立派なコンテキストマップの出発点になります。

境界を意識して描くだけで、「この機能はどのコンテキストに属するべきか？」という問いが生まれます。この問い自体が、設計の質を上げます。

ステップ3：業務ロジックと入出力を分離し、ルール特化クラスを作る

最後のステップは、コードレベルでの小さな改善です。

既存のサービスクラスやコントローラーに業務ロジックが混在している場合、一つのビジネスルールを取り出してクラスに切り出してみましょう。「注文金額が5000円以上なら送料無料」というルールがあれば、ShippingFeePolicyクラスに閉じ込めます。

戦術的パターン（リポジトリ、ファクトリ等）は後回しで構いません。まず「業務ルールがどこに書いてあるか分かる」状態を作ることが最優先です。

このクラスができたら、Copilotに「このクラスのユニットテストを書いて」と指示してみてください。意図が明示化されたクラスには、AIも適切なテストを生成できます。ドメインモデルを「AIへの文脈」として渡す運用の、最初の体験になります。

---

よくある質問（FAQ）

Q. AIがコードを書くなら、DDDは不要になりませんか？

A. むしろ逆です。 AIへの指示品質が設計品質に直接依存するため、DDDスキルの重要性は従来より高まっています。

AIは優れた「実装者」ですが、「何を実装すべきか」は人間が定義しなければなりません。ドメインモデルとユビキタス言語を整備するスキルは、AI時代における「AIを正しく使うスキル」と表裏一体です。

Q. CopilotやCursorとDDDの相性は？

A. 非常に相性が良いです。 ただし、使い方を工夫する必要があります。

AIツールは文脈を与えれば与えるほど、出力の品質が上がります。ドメインモデルを定義したファイル、ユビキタス言語の用語集、バウンデッドコンテキストの境界図——これらをプロジェクトに用意し、AIが参照できる状態にすることで、場当たりコードの量産を防げます。

特にCursorのRules for AI機能（.cursorrules）は、ユビキタス言語の定義を常時参照させるのに有効です。

Q. 小規模チームでもDDDは必要ですか？

A. はい、ただし全部やる必要はありません。 戦略的設計（ユビキタス言語・バウンデッドコンテキストの策定）だけでも、十分に価値があります。

3〜5人のチームであっても、用語の認識ズレはバグを生みます。エンティティ、値オブジェクト、リポジトリといった戦術的パターンは、チームの規模と複雑さに応じて段階的に取り入れれば十分です。

Q. 何から始めるべき？

A. ユビキタス言語の整備と、バウンデッドコンテキストの境界策定が最初の一歩です。

「ステップ1：チームの用語集を1枚にまとめる」から始めてください。コードを一行も変えなくても、チームの認識が揃うだけでDDDの恩恵が始まります。

Q. 既存のレガシーシステムにも適用できますか？

A. 適用できます。 Anti-Corruption Layerを挟んで、価値の高い領域から段階的に切り出すのが定石です。

レガシーシステム全体を一気にDDD化しようとすると失敗します。「最も変更頻度が高い業務ロジック」「最もバグが多い領域」から始め、そこだけ新しいドメインモデルで実装します。レガシーとの境界にはACLを置いて、古い概念が新しいモデルを汚染しないよう保護します。

---

まとめ：問い直すべきは「誰のためのソフトウェアか」

AI時代のソフトウェア開発において、エンジニアの役割は変わっています。コードを書く労力は劇的に下がりました。しかし、何を作るかを決める知的労働の価値は、むしろ上がっています。

この記事でお伝えしてきたポイントを整理します。

1. AIはコードを書けるが、ビジネスの意図は理解できない。意図を構造化するのは、依然として人間の仕事です。

2. ドメインモデルは「AIへの設計図」として機能する。明確なモデルがあれば、AIへの指示は具体的になり、出力の品質は上がります。

3. ユビキタス言語はハルシネーション防止のセマンティック安全機構になった。言語の精密性は、AI時代においてセキュリティの機能を持ちます。

4. 戦略的設計から始めれば、小規模チームでも価値を得られる。完璧なDDD導入でなくても、用語集一枚が最初の投資になります。

増田亨氏が問いかけるのは「誰のためのソフトウェアか」という根本的な問いです。AIがコードを書く速度が上がるほど、この問いに答えられるエンジニアの価値は高まります。

まず今日、自分のチームの「用語のズレ」を一つ見つけることから始めてみてください。「注文」と「受注」を同じ意味で使っているメンバーと、違う意味で使っているメンバーが混在していないか——そこから、ドメイン駆動設計は始まります。

---

参考リンク・出典

• 今こそ問いたいソフトウェア設計 ドメイン駆動設計再入門（増田亨 / Speaker Deck）
• なぜ今、ドメイン駆動設計（DDD）なのか――AI時代の競争力を左右するデータ構造改革（techtekt）
• Domain Driven Design in the AI Era: From Models to Meaning（nidly.substack.com）
• DDDスキルが必要なのか？ #AIエージェント（Qiita）
• Software Architecture in the AI Era: What Doesn't Change, What Does（ionutbalosin.com）
• Accelerate your Strategic Design with LLMs（ddd.academy）