複雑なビジネスルールが絡み合うソフトウェア開発において、アーキテクチャの設計は常に頭を悩ませる課題です。この課題に対する強力な解決策として、ドメイン駆動設計（DDD; Domain-Driven Design）があります。DDDは、ビジネスの関心事を中心に据えることで、保守性の高いシステムを構築できる非常に効果的な手法です。しかし、様々な関係者が集まる長時間のワークショップを実施する必要があるなど、設計の初期段階でかかる時間的コストの大きさがハードルとなっています。

そこで本記事では、近年目覚ましい推論能力を獲得したLLM（大規模言語モデル）を「壁打ち相手（スパーリングパートナー）」として活用し、DDDプロセスの負担を軽減する実践的なフレームワークを紹介します。LLMは設計のすべてを全自動で完了させる魔法のツールにはなり得ませんが、面倒な整理作業を任せることで、開発者が重要なアーキテクチャの意思決定に集中するための強力なサポート役となります。

本記事を通して、LLMが実用的に活躍できる領域と、人間が介入すべき限界について見ていきます。

1. ドメイン駆動設計（DDD）とは？

ソフトウェア開発を進める中で、「ビジネス側の要求と、実際のシステム構造が噛み合っていない」と感じたことはないでしょうか。例えば、営業部門が言う「顧客」と、システム上の「User（ユーザー）」テーブルの役割が微妙にズレており、後から機能追加をする際にコードが複雑化してしまうようなケースです。

このような課題を解決するための強力なアプローチが、ドメイン駆動設計（DDD: Domain-Driven Design）です。本記事の主題に入る前に、前提となるDDDの基本概念と、その特徴についておさらいしておきましょう。

ビジネスの関心事を中心に据える設計

DDDとは、文字通り「ドメイン（Domain：ソフトウェアが解決しようとする対象領域やビジネスの世界）」をソフトウェア設計の中心に据える手法です。

従来の開発では、データベースのテーブル設計や使用するフレームワークといった技術的な詳細から議論を始めることが少なくありませんでした。しかしDDDでは、プログラミング言語やライブラリといった技術的な詳細は「実装の手段」として一旦脇に置き、まずはビジネスのルールや業務のプロセスそのものを深く理解することから始めます。

そのための最も重要な道具となるのが、ユビキタス言語（Ubiquitous Language）です。

共通言語としての「ユビキタス言語」

ユビキタス言語とは、ビジネスの専門家（ドメインエキスパート）と開発者の間で共有される、文字通りの「共通言語」です。

先ほどの例で言えば、ビジネス側が「注文」と呼ぶのであれば、コード上のクラス名も Order とし、データベースのテーブルもそれに合わせます。翻訳作業（「ビジネス側の言う『注文』は、システム上の『Transaction』テーブルのことだ」というような頭の中での変換）をなくすことで、要件のズレを防ぐのです。この言語を用いてドメインのモデルを構築し、そのままソフトウェアの設計や実装へと反映させていきます。

DDDのメリットとデメリット

このように、ビジネスとシステムを密接に結びつけるDDDは、複雑なビジネスアプリケーションを設計する上で最も効果的な手法の一つとして広く採用されています。しかし、その強力さゆえに直面する課題もあります。特徴を整理してみましょう。

• メリット
  • 保守性と拡張性の飛躍的な向上: ソフトウェアの構造が実際のビジネス要件やルールと強く結びついているため、将来ビジネスの形が変わった際にも、コードのどこを修正すべきかが直感的にわかりやすくなります。特に複雑な要件が絡み合うシステムにおいて、その効果は絶大です。
  • コミュニケーションの改善: ユビキタス言語を用いることで、開発者とビジネス担当者が同じ言葉で議論できるようになり、仕様の誤解や手戻りが大幅に減少します。
• デメリット
  • 莫大な時間的コストと労力: 用語の定義を揃えたり、システムの境界を特定したりするためには、様々な関係者が集まる長時間のワークショップ（イベントストーミングなど）、またはそれに準ずるものを繰り返し実施する必要があります。
  • 学習のハードル: 関連する概念やパターンが多岐にわたるため、チーム全体で手法を理解し、実践できるようになるまでには高い学習コストがかかります。

DDDは保守性の高いアーキテクチャを実現できる一方で、「関係者間の議論や合意形成にかかる負担」が最大のネックとなっていました。

「設計の品質は上げたいが、全員が集まる長時間のミーティングを何度も実施するのは現実的ではない」

多くの現場が抱えるこのジレンマに対して、一筋の光をもたらすのが、近年飛躍的な進化を遂げたLLMの推論能力です。

2. LLMを用いたDDD自動化の5ステップ

LLMにDDD（ドメイン駆動設計）をサポートさせる際、最も重要なのは「LLMをどのような存在として扱うか」です。本アプローチでは、LLMを単なるコード生成ツールとして扱うのではなく、「シニアDDDスペシャリスト」であり、人間の開発者に対する「アーキテクチャ設計の壁打ち相手（スパーリングパートナー）」として位置づけます。

前提となる準備: 役割の定義と要件の入力

プロセスを開始する前に、以下の準備を実施します。

• システムプロンプトの設定: まず、LLMに対して厳格な役割を与えます。「あなたは10年以上の経験を持つDDDの専門家です」「技術的な言葉でごまかさず、ビジネス上の価値を追求してください」「曖昧なドメイン概念があれば、必ず質問して明確にしてください」といったルールを定義したシステムプロンプトを入力します。これにより、LLMがただのAIアシスタントではなく、批判的思考を持つ専門家として振る舞うようになります。
• 要件定義書の入力: 次に、システムの要件定義書をテキスト形式（Markdownなど）で入力します。これがすべての設計の出発点となります。

# ロール: シニア・ドメイン駆動設計（DDD）スペシャリスト ＆ アーキテクチャ・スパーリングパートナー

あなたは、全開発チームがDDDの原則を全面的に採用している大企業に所属する、シニアDDDスペシャリストです。複雑なシステムにおける10年以上のDDD実装経験を持ち、ドメインモデリングやアーキテクチャ上の意思決定を行うチームに対して、専門的なアドバイザー兼、思考を刺激する「スパーリングパートナー」としての役割を担います。

## あなたの主な責任

### 能動的なスパーリングパートナーとしての振る舞い
* 思慮深い問いかけを通じて、前提条件や設計上の決定に異議を唱え（チャレンジし）、再考を促します。
* 曖昧なドメイン概念をそのまま受け入れず、必ず明確化を求めます。
* 隠れた複雑性や見落としている機会を明らかにするために、鋭い質問を投げかけます。

### DDDベストプラクティスの徹底
* ドメイン層、アプリケーション層、インフラストラクチャ層、プレゼンテーション層が適切に分離されていることを確実にします。
* ドメインモデルの貧血化（Anemic Domain Model）を避け、豊かなドメインモデル（Rich Domain Model）を推奨します。
* 境界づけられたコンテキスト（Bounded Context）を正しく特定し、定義できるようチームを導きます。
* 集約（Aggregate）間の疎結合を実現するため、ドメインイベントの活用を促進します。
* 集約内での整合性の境界が適切に維持されているかを確認します。

## あなたの仕事のスタイル
* 対話的なモデリングセッションやイベントストーミング（Event Storming）の価値を信じています。
* 単なる技術的な説明には満足せず、常に「ビジネス上の正当性」を求めます。
* ユビキタス言語の使用を徹底し、ドメインに関する議論に技術用語が混ざることを許しません。
* 集約の境界とトランザクションの整合性については、特に厳格な態度をとります。
* 進化的設計を提唱しつつも、初期段階からの戦略的設計（Strategic Design）の重要性を強調します。

## 介入のトリガーとなる「レッドフラグ（警告サイン）」
* ロジックがサービス層に漏れ出している、貧血ドメインモデル。
* 肥大化しすぎた、あるいは境界が不明確な集約。
* 欠落している、または定義が不十分な境界づけられたコンテキスト。
* ドメイン層からの直接的なデータベースやリポジトリへのアクセス。
* データベースのスキーマをそのまま反映しただけのドメインモデル。
* 重要な状態変化に対するドメインイベントの欠如。
* ドメインモデルを汚染している技術的な関心事。

## コミュニケーションのアプローチ
誰かが設計を提示したり、ガイダンスを求めたりした際、あなたは以下の手順を踏みます：

1.  的を絞った質問を通じて、まず相手の現在のモデルを理解することに努めます。
2.  相手の前提に対して、建設的に異議を唱えます。
3.  ソクラテス式問答（問いかけによる気づき）を通じて、相手をDDDの原則へと導きます。
4.  必要に応じて、自身の経験に基づいた具体的な事例を提示します。
5.  技術的な決定は、常にビジネス価値とドメインの複雑性に結びつけて考えさせます。

**重要:** あなたは単に質問に答えるだけではありません。厳格な問いかけと共同の探索を通じて、チームがより優れたドメインモデルを発見できるよう能動的に支援してください。最高のドメインモデルは、技術的な器用さからではなく、ビジネスへの深い理解から生まれると信じて行動してください。

対話しながら進める5つのステップ

準備が整ったら、同じチャットスレッド内で以下の5つのステップを順番に進めていきます。重要なのは、各ステップでLLMから「この用語の定義はこれで合っていますか？」といった質問を引き出し、人間がそれに回答（対話）してから次のステップへ進むことです。

ステップ1：ユビキタス言語の確立

まずは要件定義書を分析し、ビジネス上の重要な概念（名詞や動詞）を網羅的に抽出して用語集を作成します。LLMは用語の定義をまとめるだけでなく、「『注文』と『発注』は同じ意味として扱ってよいですか？」といった質問を人間に投げかけ、チーム内の認識のズレや言葉の曖昧さを初期段階で排除します。

# タスク：要件からのユビキタス言語の抽出と定義

要件定義が提示された際、DDDスペシャリストとしてのあなたの最初の行動は、ドメイン用語を細心の注意を払って抽出し、明確な「ユビキタス言語」を確立することです。以下の構造化されたアプローチに従ってください。

## ユビキタス言語用語集（Glossary）作成の手順

### 1. 初期分析フェーズ
* すべての要件を注意深く読み込む。
* 登場するすべての名詞、動詞、およびビジネス概念を特定する。
* 複数回登場する用語や、ドメインの中心と思われる用語には特に注意を払う。
* 文脈（コンテキスト）によって意味が異なる可能性がある用語をメモする。

### 2. 構造化された用語集テーブルの作成
以下の形式で出力してください：

## ユビキタス言語用語集

| 用語 | 定義 | ビジネス文脈 | 関連用語 | 疑問点・要確認事項 |
| :--- | :--- | :--- | :--- | :--- |
| [用語名] | [明確なビジネス上の定義] | [いつ・どこで使われるか] | [関連する他のドメイン用語] | [曖昧な点や質問] |

#### 各用語に関する遵守事項：
* 技術的ではなく、**ビジネス中心の定義**を提供すること。
* ドメインエキスパートが説明するように解説すること。
* その用語が適用されるビジネス文脈を特定すること。
* 関連用語をリンクさせ、関係性を明示すること。
* 曖昧な箇所や明確化が必要な領域にはフラグを立てること。

### 3. 特に注視すべきカテゴリ
* **エンティティ（Entities）:** 時間の経過とともに変化し、識別子（ID）を持つもの。
* **値オブジェクト（Value Objects）:** 属性によって定義される（計測・表現される）もの。
* **アクション／コマンド（Actions/Commands）:** ユーザーやシステムが行う動作。
* **イベント（Events）:** ドメイン内で発生した出来事。
* **ルール／ポリシー（Rules/Policies）:** ビジネス上の制約や不変条件（インバリアント）。
* **ロール（Roles）:** システム内の異なるアクター（役割）。
* **ステート（States）:** 対象物が取り得る異なる状態。

### 4. 初期用語集作成後の分析
* 異なる「境界づけられたコンテキスト」に属する可能性がある用語を特定する。
* 複数の意味を持ちそうな用語にフラグを立てる。
* コアドメインの用語と、支援的・汎用的な用語を区別して強調する。
* 不明瞭または曖昧な用語に関する質問をリストアップする。

### 5. 行うべきフォローアップ質問
* 「『[用語]』が異なる使われ方をされているようです。〜について詳しく教えていただけますか？」
* 「『[用語A]』と『[用語B]』は同じものですか、それとも異なる概念ですか？」
* 「『[用語]』と言うとき、そこには〜も含まれますか？」
* 「準拠すべき業界標準の定義はありますか？」

---
## 出力例の構造

## ユビキタス言語用語集

提示された要件に基づき、以下の主要なドメイン用語を特定しました：

| 用語 | 定義 | ビジネス文脈 | 関連用語 | 疑問点・要確認事項 |
| :--- | :--- | :--- | :--- | :--- |
| 注文 | 顧客による製品購入の依頼 | 販売プロセス全体で使用 | 顧客、製品、支払い | 「注文（Order）」と「購買注文（Purchase Order）」に違いはありますか？ |
| 顧客 | 注文を行うことができる個人または組織 | すべてのビジネス業務の中心 | 注文、アカウント、支払い方法 | 顧客タイプ（B2B vs B2C）による違いはありますか？ |

### 境界づけられたコンテキストの兆候：
- [コンテキストA] に関連する用語: ...
- [コンテキストB] に関連する用語: ...

### ドメインエキスパートによる確認が必要な事項：
1. [特定の曖昧さや質問]
2. [その他の確認事項]

**リマインド:** この用語集は、理解が深まるにつれて進化していく「生きた文書」です。技術的な専門用語（ジャルゴン）を排除し、ドメインエキスパートが認識し、承認できるビジネスフレンドリーな定義を徹底してください。

ステップ2：イベントストーミングのシミュレーション

ステップ1で定義した共通言語を使い、システム内で「何が起きるのか（ドメインイベント）」を時系列で整理します。本来は様々な関係者が集まって付箋を貼りながら行う時間のかかるワークショップですが、LLMがこれをシミュレーションします。「誰が（アクター）」「何をきっかけに（コマンド）」「どんな結果が生じるか（イベント）」という一連のビジネスの連鎖を可視化します。

確立したユビキタス言語に基づき、以下の手順でイベントストーミング（Event Storming）セッションを実施します。

1. **ドメインイベント（発生した事象）の特定**
   - 発生した出来事をすべて、時系列順に特定してください。

2. **各イベントに関連する要素の特定**
   各イベントについて、以下の要素を明らかにしてください：
   - **コマンド（Command）**: そのイベントを誘発するトリガー。
   - **アクター／ロール（Actor/Role）**: コマンドを実行する主体。
   - **ポリシー／ルール（Policies/Rules）**: 適用されるビジネス制約や不変条件。
   - **集約（Aggregate）**: その処理を担う責任単位。

3. **時間的境界と並行プロセスの探索**
   - 時間的な区切り（フェーズの変化）や、同時に進行するプロセスがないか確認してください。

4. **イベントストリームの可視化**
   - 一連の流れを視覚的なフローとして提示してください。

### 出力フォーマット
以下の形式で記述してください：
`アクター -> コマンド -> 集約 -> イベント -> ポリシー／リアクション -> 次のコマンド`

---
**注意事項:**
フローが不明瞭な箇所や、複数の解釈が成立しそうな箇所があれば、必ずハイライト（強調）して指摘してください。

ステップ3：境界づけられたコンテキストの特定

次に、複雑なシステム全体を、意味や役割のまとまりごとに分割します。これが「境界づけられたコンテキスト」です。LLMは、関連する用語やイベントをグループ化し、それぞれのコンテキストがどのような責任を持つのか、またコンテキスト同士がどのように連携するのか（コンテキストマップ）を整理します。システムを適切なサイズに切り分ける重要なフェーズです。

ご提示いただいた「境界づけられたコンテキスト（Bounded Context）」の特定とマッピングに関するプロンプトを、DDDの戦略的設計の用語を正確に用いて日本語に変換しました。

Python
PROMPT = """
次に、境界づけられたコンテキスト（Bounded Context）の特定とマッピングを行います。

1. **コンテキストのグループ化**
   - 用語集（用語集）から関連する用語を抽出し、潜在的な「境界づけられたコンテキスト」ごとにグループ化してください。

2. **各コンテキストの詳細定義**
   各コンテキストについて、以下を定義してください：
   - **核心となる目的と責務**: そのコンテキストが解決する主要な課題。
   - **主要な集約（Aggregates）**: そのコンテキスト内に存在する中心的な集約。
   - **コンテキスト固有のユビキタス言語**: その境界内だけで適用される特有の用語や意味。

3. **コンテキスト間の関係（コンテキスト・マッピング）の特定**
   以下のパターンを用いて、コンテキスト同士の相関関係を特定してください：
   - 上流（Upstream）／ 下流（Downstream）の関係
   - 共有カーネル（Shared Kernel）
   - 顧客／供給者（Customer/Supplier）
   - 順応者（Conformist）
   - 腐敗防止層（Anti-corruption Layer / ACL）の必要性
   - 公開ホストサービス（Published Language / OHS）

4. **コンテキストマップの作成**
   - これらの関係性を示すコンテキストマップを（図、またはテキスト形式の図解で）作成してください。

5. **コンテキストをまたぐ用語の精査**
   - 異なるコンテキスト間で意味が異なる用語（多義的な言葉）があれば、すべてフラグを立てて明示してください。

---
**注意事項:**
サイズが大きすぎると感じられるコンテキストや、境界が曖昧なものについては、積極的に疑問を投げかけ、再検討を促してください。

ステップ4：集約（Aggregate）の設計

各コンテキストの内部で、データを矛盾なく更新するためのまとまりである「集約」を設計します。ここでは、システムが絶対に守らなければならないビジネスルール（不変条件）は何か、どのエンティティが集約の窓口（ルート）になるのかをLLMとともに定義します。LLMは「この集約は大きすぎて、複数人が同時に操作した際にエラーが起きやすくなりませんか？」といった観点で設計に切り込みます。

各「境界づけられたコンテキスト」について、集約（Aggregate）の設計を行います。

1. **集約のルート（Aggregate Root）の特定**
   - 外部からのアクセスを制御し、整合性を保つ責任を持つエンティティ（集約ルート）を特定してください。

2. **各集約の詳細設計**
   各集約について、以下を定義してください：
   - **整合性の境界（Consistency Boundary）**: 同時に更新されるべき範囲の定義。
   - **内部要素のリスト**: 集約に含まれるすべてのエンティティと値オブジェクト（Value Objects）。
   - **不変条件（Invariants）**: その集約が常に保護しなければならないビジネスルール。
   - **ドメインイベント**: その集約が発行するイベント。
   - **コマンド／メソッド**: 実行可能な操作（振る舞い）。

3. **設計の最適化と検証**
   集約が以下の条件を満たしていることを確認してください：
   - **小さく保たれているか**: 並行性を高めるため、必要最小限のサイズになっているか。
   - **単一の整合性の境界に集中しているか**: 責務が分散していないか。
   - **明確な不変条件を保護しているか**: ビジネス上の整合性が担保されているか。

### テンプレート
各集約について、以下の形式で出力してください：

**集約名: [名称]**
- **集約ルート**: [エンティティ名]
- **含まれる要素**: [エンティティおよび値オブジェクト]
- **不変条件**: [維持すべきビジネスルール]
- **コマンド**: [実行可能な操作]
- **イベント**: [発行されるドメインイベント]
- **サイズの評価**: [肥大化の懸念や評価]

---
**注意事項:**
サイズが大きすぎると判断される集約や、境界が不明確な設計に対しては、積極的に異議を唱え、改善を促してください。

ステップ5：技術的アーキテクチャへのマッピング

最後に、これまでに整理したドメインのモデルを、ヘキサゴナルアーキテクチャなどの具体的な技術構造へと落とし込みます。APIの設計や、データベースとのやり取りを担うリポジトリなど、システムとして実装するための最終的な青写真を描きます。

ご提示いただいた「技術アーキテクチャの設計」に関するプロンプトを、ヘキサゴナルアーキテクチャの文脈と、DDDの技術パターンの意図を汲み取った日本語に変換しました。

Python
PROMPT = """
# DDDパターンに従った技術アーキテクチャの設計

ドメインモデルを支えるための技術的な構造を、以下のガイドラインに従って設計してください。

## 1. ヘキサゴナルアーキテクチャ（六角形アーキテクチャ）の適用
各層に配置すべき要素を明確に定義してください：

* **ドメイン層（Domain Layer）**: 
    - エンティティ（Entities）、値オブジェクト（VOs）、ドメインサービス、およびリポジトリのインターフェース。
* **アプリケーション層（Application Layer）**: 
    - アプリケーションサービス、DTO（データ転送オブジェクト）、およびコマンド／クエリ。
* **インフラストラクチャ層（Infrastructure Layer）**: 
    - リポジトリの実装クラス、外部サービスの各アダプター。
* **プレゼンテーション層（Presentation Layer）**: 
    - 外部に公開するAPI（REST、GraphQLなど）。

## 2. 境界づけられたコンテキストごとの設計
* **腐敗防止層（ACL）の設計**: 外部コンテキストとの連携において、ドメインモデルを守るために必要なACLを定義してください。
* **公開イベント／APIの定義**: 他のコンテキストが利用できるよう、公開するイベントやインターフェースを明確にしてください。

## 3. 適用すべき技術パターン
* **リポジトリパターン**: 集約の永続化を抽象化するために使用します。
* **仕様（Specification）パターン**: 複雑なクエリやビジネスルールの検証に使用します。
* **ドメインイベント**: システム間の結合を疎にし、柔軟性を高めるために活用します。

---
**出力の要件:**
それぞれの技術的な決定（どのパターンをどこに使うか）が、どのようにドメインモデルを保護し、ビジネス上の価値をサポートしているかを具体的に示してください。

このように、単なる用語の整理から実装に向けた構造設計までを段階的に進めることで、開発者は面倒な情報の構造化作業をLLMに任せることができます。結果として人間は、「LLMが提案した設計の妥当性を判断する」という、より高度で本質的な意思決定に集中できるようになるのです。

3. 実用性の高い領域

前述の5つのステップのうち、LLMが特に高い精度を発揮し、実務で今すぐ活用できるのが前半の3ステップです。実際のケーススタディでも、これらの領域においてLLMは「非常に優秀な壁打ち相手」として機能し、設計プロセスを大幅に加速させることが確認されています。

• ステップ1：ユビキタス言語の確立
  • 実施内容: 要件定義書からドメインの主要な語彙を抽出し、ビジネスに焦点を当てた定義の用語集を作成します。
  • LLMの強みと活用法: LLMは言語的な処理を非常に得意としています。単に用語を列挙するだけでなく、要件の曖昧な部分に対して「この言葉の定義はこれで合っていますか？」と明確化のための質問を投げかける能力に長けています。これにより、初期段階で関係者間の認識のズレを排除し、議論の土台を構築する上で非常に有効に機能します。ただし、抽出された用語が少し機械的であったり、汎用的すぎたりする場合があるため、人間による微調整を加えるとより自然になります。
• ステップ2：イベントストーミングのシミュレーション
  • 実施内容: システム内で発生する出来事（ドメインイベント）や、その引き金となる操作（コマンド）、実行するユーザー（アクター）を時系列で整理し、連鎖を可視化します。
  • LLMの強みと限界: LLMは、主要なビジネスフローを的確に抽出することに成功します。対話を通じて鋭い質問をしてくれるため、人間が見落としていたイベントを洗い出すのにも役立ちます。一方で、仕様書に明記されていない運用上の例外処理（エッジケース）や、現場特有の技術的なイベントはどうしても漏れる傾向があります。そのため、現場の運用を知る人間の専門家によるレビューと補完が不可欠です。
• ステップ3：境界づけられたコンテキストの特定
  • 実施内容: 用語やイベントの関連性に基づき、システムを論理的な境界（コンテキスト）ごとにグループ化します。
  • LLMの強みと限界: LLMは、システムを理論上妥当できれいな境界へと切り分けてくれます。しかし、「実務における運用時の負担（オーバーヘッド）」や「機能間の密接な依存関係」までは考慮しきれないため、実務にはそぐわないほど細かすぎる分割を提案する傾向があります。そのため、最終的には人間が「ここは運用上、統合したほうが良い」といった統合・調整の判断を下す必要があります。一方で、LLMが提案する分割案は、「この機能は将来的に独立させたほうが良いかもしれない」と、人間の設計者に新たな気づきを与える効果も確認されています。

4. LLMが直面する課題

前半のステップで素晴らしい壁打ち相手として機能したLLMですが、設計の核心に迫る後半のプロセスでは、現在の技術における限界が浮き彫りになります。ケーススタディでも、ステップ4以降で生成された成果物は、そのまま実務に投入するには厳しい品質であることが報告されています。その具体的な理由をステップごとに見ていきます。

• ステップ4：集約（Aggregate）の設計
  • 実施内容: 各コンテキストの内部で、データを矛盾なく更新するためのまとまりである「集約」を設計します。これは、システムが絶対に守るべきビジネスルール（不変条件）を保護するための、非常に重要な段階です。
  • 直面する課題: ここで最大の壁となるのが、「小さなエラーの蓄積」です。前段までのプロセス（用語の定義やコンテキストの分割）で生じたLLMのわずかなズレが、ステップ4に到達する頃には乗数的に膨れ上がり、現実のシステムに合わない集約を提案してしまいます。また、ここまでの膨大なやり取りによってLLMの記憶領域（コンテキストウィンドウ）が限界に近づき、直近の話題にばかり注意が向いて初期の重要な前提条件を忘れてしまうことも、精度を大きく落とす原因です。
• ステップ5：技術的アーキテクチャへのマッピング
  • 実施内容: これまでに構築したドメインモデルを、APIやリポジトリ、外部サービスとの連携といった具体的な技術コンポーネント（ヘキサゴナルアーキテクチャなど）へと落とし込みます。
  • 直面する課題: 現在のLLMにとって、このタスクは複雑すぎることがわかっています。LLMからの提案は表面的な説明にとどまることが多く、実装に直結するような深い洞察や詳細さを持ち合わせていません。さらに、複雑なシステム構造をPlantUMLなどのコードを用いて図解出力させようとしても、レイアウトが乱れてしまい、直感的に理解できる品質には至りません。

このように、多数の前提条件を矛盾なく保持しながら、抽象的なビジネスモデルを具体的な技術構造へと変換する作業は、現在のLLM単独では荷が重いと言わざるを得ません。したがって、ステップ4およびステップ5をLLM任せにすることは推奨されておらず、ここから先は経験豊富な人間の開発者がしっかりと手綱を握り、設計を進める必要があります。

5. 実務に導入するためのヒント

これまでのステップを通して、LLMがDDD（ドメイン駆動設計）において強力なサポート役となる一方で、いくつかの限界を抱えていることがわかりました。では、実際の開発現場でこのアプローチを成功させるためには、どのような点に気をつけるべきでしょうか。ここでは、実務に導入するためのポイントを3つに分けて紹介します。

詳細なテキスト要件の準備

LLMによるDDD支援を正しく機能させるための大前提として、システムの要件定義書をMarkdownなどのテキスト形式で詳細に準備することが必須となります。

LLMは、入力されたテキスト情報のみを頼りにドメインのモデルを構築します。もし要件の記述が曖昧であったり不足していたりすると、LLMは自身の学習データ（一般的な知識）を元にして推測で補おうとします。その結果、実際のプロジェクトには全くそぐわない用語を生み出したり、事実とは異なる情報（ハルシネーション）を出力したりするリスクが高まります。様々な関係者からヒアリングしたシステムの振る舞いやビジネスのルールを、可能な限り具体的にテキスト化して入力することが、精度の高い出力を引き出す最大の鍵となります。

完全自動化ではなく「協働（コラボレーション）」

LLMを「設計をすべて任せられるツール（アーキテクトの代替）」としてではなく、「対話型のパートナー」として扱うことが重要です。

先ほど触れた通り、LLMはステップを進めるごとに小さな認識のズレを蓄積していく傾向があります。そのため、各ステップで出力された結果を鵜呑みにせず、常に人間の専門家が検証し、ズレがあれば対話を通じて軌道修正を進める必要があります。

LLMの真の価値は、議論の土台となる「叩き台」を素早く作ってくれることにあります。用語集の作成といった面倒な整理作業はLLMに任せましょう。そうすることで、人間の開発者は「この分割で将来の運用に耐えられるか？」といった、より高度なトレードオフの議論や本質的な意思決定に時間を割くことができるようになります。

適用範囲の限定（まずはステップ1〜3から）

エラーの蓄積を避け、実用的な成果を確実に得るためには、全プロセスの自動化を目指すのではなく、適用範囲を思い切って絞ることが推奨されます。

検証においても、集約の設計（ステップ4）や技術アーキテクチャへのマッピング（ステップ5）は、現在のLLMの能力では実用に耐えうる品質に達しないことが確認されています。そのため、まずは非常に高い効果が実証されている以下の前半のステップに限定して、LLMを活用することをおすすめします。

• ステップ1（ユビキタス言語の確立）: 共通言語となる用語集の作成
• ステップ2（イベントストーミング）: システム内の出来事と操作の連鎖の可視化
• ステップ3（境界づけられたコンテキストの特定）: システムの論理的な分割

なお、ステップ3で提案されたコンテキストが「実務に対して細かすぎる」と感じた場合は、実際の運用に合わせて人間が統合の判断を下すことが大切です。

以上、LLMの得意・不得意をしっかりと見極め、適切な範囲で「壁打ち相手」として活用することで、DDDの導入ハードルは大きく下がります。

おわりに

本記事では、LLMを壁打ち相手として活用し、ドメイン駆動設計（DDD）のプロセスを効率化するフレームワークを紹介しました。

このアプローチの最大の魅力は、DDDの初期段階における時間のかかる作業を大幅に削減し、設計プロセス全体を加速させることができる点にあります。用語の整理やイベントの洗い出しといった面倒な初期の構造化をLLMに任せることで、私たちソフトウェア開発者は「様々なアーキテクチャのトレードオフ」や「重要な意思決定」に貴重な時間とリソースを集中させることが可能になります。

一方で、集約の設計や技術的な詳細設計といった、高度な文脈理解が求められる複雑な領域では、依然として人間の専門知識が不可欠です。現在のLLMは人間のアーキテクトを完全に置き換えるものではありません。

LLMという強力なパートナーを適切に迎え入れることで、より保守性が高く、ビジネス要件に寄り添ったシステム設計に、ぜひ取り組んでみてください。

More Information

• arXiv:2603.26244, Tobias Eisenreich et al., 「Automating Domain-Driven Design: Experience with a Prompting Framework」, https://arxiv.org/abs/2603.26244