AI時代に改めて考える、ドメイン駆動設計 - モデリングが「AIへの共通言語」になる

「AIに指示するときに、詳しく説明しすぎると長くなるし、曖昧だとピントがズレる……」──そうした悩みを解決する鍵が、実は**ドメインモデリング**です。

20年以上前からあるドメイン駆動設計（DDD）という手法を、AI時代に改めて活躍させる方法があります。**モデル＝人間もAIも理解できる共通言語**だからです。

このセッションでは、ドメインモデリングの具体的なやり方（sudoモデリング）から、AIとの壁打ち方法、さらに受入基準・技術設計・テストへの展開まで、ログラスでの実践例をもとに、AI時代の開発プロセスをどう進化させるかをお話しします。

**登壇イベント**: Findy（2026/5/26）

### 今日の結論
**モデルという「共通言語」を作ることで、人間もAIも同じビジョンで開発できる体制を整える**

### 持ち帰っていただけること
- **sudoモデリング** ── 取り組みやすい4つの図（System/UseCase/Domain/Object）のフレームワーク
- **draw.io × AI の壁打ち** ── 図を使ってAIから観点を引き出し、モデルの漏れを埋める実践
- **モデルを各プロセスに繋ぐ** ── 受入基準・技術設計・テスト・実装へ、モデルが活きる展開パターン
- **AI活用フェーズの可視化** ── チームの現在地を測り、次の段階に進むロードマップ

### こんな方におすすめ
- AIで開発を始めたが「指示の精度が心もとない」「モデル品質に左右される」と感じているエンジニア・EM・QA
- ドメイン駆動設計に興味はあるが「大規模開発向けでは？」と思っている方
- AIのガードレール設定を効果的にしたい方
- 既存システムの理解を深めて、AIに正確に伝えたい方

### 関連キーワード
#ドメイン駆動設計 #DDD #AI駆動開発 #AI #生成AI #モデリング #draw.io #共通言語 #ドメインモデル #受入基準 #ユースケース #ドメイン設計 #Claude

Transcript

1. AI時代に改めて考える、ドメイン駆動設計 モデリングが「AIへの共通言語」になる 松岡 幸一郎 / ログラス Findy 2026/5/26 1
2. 自己紹介 2
5. 今日のゴール DDD × AIで、開発プロセス全体の品質を上げる方法を持ち帰ってもらう 持ち帰ってもらえると良いこと: sudoモデリング ── 取り組みやすい4つの図のフレームワーク draw.io × AI ── 図を使ってAIと壁打ちする実践 モデルを各プロセスに繋ぐ ── 受入基準・技術設計・実装へ展開 AI活用フェーズの可視化 ── チームの現在地を測る物差し 5
6. アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 6
7. DDDとは DDD（ドメイン駆動設計）= プロダクト開発で大きな価値を生むための手法 「ドメイン」 = ソフトウェアで問題解決しようとする対象（業務領域） DDDの目的: 機能性（役に立つものを作る） × 保守性（長期間作り続けられる） DDDは2003年、今から20年以上前からある手法。 　　AI時代の今、DDDにはどんな価値があるのか？ 7
8. DDDの目的 役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにす る ①ソフトウェアの機能性を高めること 役に立つものを作る。 「作ったけど使えない」を避ける ②ソフトウェアの保守性を高めること 長期間開発しても機能拡張が容易でありつづける 「技術的負債でどんどん開発速度が低下する」を避ける 8
9. DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング 9
10. DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング 「ドメインモデル」にドメインの知識を反映し、役に立つものになる可能性を高める ドメイン知識があれば役に立つものが作れるわけでは無い ただ、ドメイン知識がなければ役に立つものは作れない →ドメイン知識は十分条件ではないが、必要条件 開発初期だけでなく、各フェーズで発見をフィードバックして改善頻度を上げる → 次のセクション「モデリング」で詳細に紹介 10
11. DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン 11
12. DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン モデルの形をそのままコードで表現 し、頻繁な更新を反映しやすくする 保守性の高いデザインパターン（エンティティ、リポジトリ等）を適用する → これをAIのガードレールとして設定する話を後の「モデルを各プロセスに繋ぐ」セクシ ョンで紹介 12
13. モデルとコードの「形」を揃える 「モデルの形をそのまま表現」とは何か、3枚で具体イメージを掴む 「モデルの形をそのままコードで表現」と言われても具体イメージが湧きにくい 次の3枚で、モデルとコードの対応関係がどう変わるかを見ていく ① 乖離があるとどうなるか ② 変更時に何が困るか ③ 同じ形にすると何が嬉しいか 13
14. モデルと実装のつながり(1/3) モデルと実装に乖離があると、対応関係が見えにくくなる 14
15. モデルと実装のつながり(2/3) モデルに変更があった時、コードのどこに反映すべきかわからなくなる 15
16. モデルと実装のつながり(3/3) コードは極力モデルと同じ形での表現を目指す モデルとコードを同じ形にすると、変更の反映先が一目でわかる 16
17. モデリングとAI出力の関係 モデル＝実装が同じ形だから、モデリング時点で実装の輪郭が固まる モデルが決まれば、実装の構造もほぼ決まる → モデリングは「実装の下書き」を兼ねる AIに渡せば、想定通りの出力が返ってくる確度が一気に上がる モデリングで議論を尽くす = 後段の手戻りを減らす最短ルート 17
18. アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 18
19. モデリングとは モデリング = モデルを議論しながら作る活動 モデル = 問題解決のために作る抽象化物 モデリング = それを議論しながら作る活動 成果物だけでなく、作るプロセスで議論・認識合わせ・意思決定することが重要 19
20. モデリングの役割 ドメインをモデル化し、ソフトウェアで問題を解決する橋渡しになる 複雑なドメイン（業務領域）をドメインモデルとして抽象化する そのモデルをもとにソフトウェアを構築し、問題を解決する モデルというワンクッションを置くことで、複雑な問題を解決する精度が上がる 20
21. モデリングの価値 「ちょうどいい抽象度」で情報を整理でき、AIに渡す精度が上がる ①複雑な構造を整理しやすい テキストは線形で構造を伝えにくいが、図なら2次元で関係性を一目で把握できる ②ちょうど良い抽象度で構造を整理できる 画面項目だと具体すぎる、要件文だと抽象すぎる。モデルが中間で効く この「ちょうどいい抽象度」が、AIに渡すコンテキストとして最適 21
22. モデリング着手の判断 新規開発でも、既存システムの理解でも、モデリングは有効 ①新規機能開発や機能改修を行う時 ドメイン理解を深めて、役立つものを作れるようにする わかること、わからないことを明確にして意思決定しやすくする ②モデリングを後追いで実施する時 リバースエンジニアリング的に、すでにあるコードについて理解する コードやモデルの現実と、ドメインの理想とのギャップを明確にする すべてが①で実施できれば理想だが、②も現実的には有用。②から①に繋ぐこともできる 22
23. DDDにおけるモデリング手法 DDDのモデリング手法に決まりはない。 今回は筆者が複数の現場でモデリングをしてきた中で、 最も導入ハードルが低く、効果を出しやすいと考えている手法を紹介します 23
24. sudoモデリング sudoモデリングは、ハードルが低く効果が出しやすいモデリング手法 図 やること S: システム関連図 システムに関わるアクター・外部システムを明示 U: ユースケース図 ユーザーがどんな操作をするか描く D: ドメインモデル図 概念と関係を抽象的に描き、共通言語を作る O: オブジェクト図 具体例で理解を深め、モデルの矛盾・漏れを検証 これは「どんな時にもやると良い最低限の4つ」 頭文字をとって「sudoモデリング」 業務フロー図／状態遷移図／シーケンス図 / ER図などは併用するとよい 24
25. モデリングの題材 採用管理システムの開発初期をシミュレーション 採用担当者が応募者の進捗管理などを行うシステム 4つの図でこのシステムをモデリングする例を順番に紹介 25
26. モデリングするときのポイント 抽象と具体を行き来し、仮説を回し続ける 抽象だけではなく、具体例が大切 よい解決策を考えるには具体例が必要 具体例が出せない＝そもそもドメイン理解が足りてないサイン モデリングは、成果物以上にプロセスが大切 わからないことを明らかにして、不足している知識や知見を埋めに行く 得た情報の中で意思決定をしていく 意思決定は常に仮説であると考える ドメインの問題解決には、常に不確実性が存在する 初期段階では全ては仮説。いかにフィードバックサイクルを回し、仮説の確度を高められ るかを考える モデル図は仕様書ではなく、ホワイトボードのように扱う ただし、メンテするものは明確に決めて最新化する 26
27. システム関連図（System Context Diagram） 開発するシステム、関わりのあるアクターや外部システムとの関連を示す図 アクター（誰が使うか） 、外部システム（何と連携するか）を描く 全体を俯瞰することで、スコープの認識を合わせられる 27
28. システム関連図（System Context Diagram） 実は、重要な意思決定をしている 大したことのない図に見えるが・・・ 応募者がこのシステムを使わない、とすると開発する機能が大きく変わる この図を作る過程で、 「応募者ってここにログインする？」という議論がされ、 その意思決定の結果 前述の通り「モデリングは、成果物以上にプロセスが大切」 28
29. ユースケース図（Use Case Diagram） ユーザーの要求に対するシステムの振る舞いを定義する図 アクターごとに「どんな操作をするか」を描く 機能の漏れや優先順位の議論に使える 29
30. オブジェクト図（Object Diagram） 抽象的なモデルを「具体例」で検証するための図 「田中太郎さんがA社のバックエンドエンジニア職に応募」のように、実際のデータで描く 具体例を描くことで、ドメインの理解を深め、モデルの矛盾や漏れが見つかる 30
31. ドメインモデル図（Domain Model Diagram） ドメインの概念と関係性を抽象的に描き、共通言語を作る図 オブジェクト図（具体例）から抽象化し、そのままコードで表現できるモデルを作る チームの共通言語になり、コードの設計にも直結する 31
32. ドメインモデル図のモデリングのコツ オブジェクト図から抽象化し、ルール・制約を書き出す オブジェクト図（具体例）から、ドメインモデルに抽象化していく ルール/制約（ドメイン知識） を吹き出しに書き出す モデリング中に疑問が出たものをその場で議論してメモしていく 検討メモ も積極的に記述する 生じた疑問の結論や疑問点もOK。発見を誘発し、関係者の認識を残す 多重度 を定義する 「採用選考から採用ポジションの紐付けは必須か？」など、ルール/制約として重要な意思 決定 実装前に主にエンジニアで決めること: 集約の範囲: リポジトリの範囲を決める 日本語名の対訳としての英語名: ユビキタス言語のマスタ。表記揺れを防ぐ 32
33. draw.io × AI スキル AIが .drawio ファイルを直接操作できる無料スキルが既に存在する claude-drawio-skill（筆者作のプラグイン）: https://github.com/little-hands/claude-drawio-skill 公式スキル（drawio-mcp）: https://github.com/jgraph/drawio-mcp/tree/main/skill-cli 「この処理をシーケンス図で整理して」などと指示するだけで .drawio が完成 Claude Code のスキルとして、プロジェクトに導入するだけで使える モデリングだけでなく、仕様設計・技術設計など幅広く活用できる 33
34. draw.io × AI で壁打ちする ドメインモデル図をAIに渡して「具体例を出して」と指示でオブジェクト図 のパターン検討ができる 34
35. draw.io × AI で観点を引き出す 1人では見落としがちな観点をAIが補完してくれる 「この図の懸念点は？」と聞くと、検討すべきポイントを提示 35
36. アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 36
37. モデルは作って終わりではない モデルが、後続プロセスのインプットになって初めて価値が出る モデリング → 受入基準 → 技術設計 → テスト → 実装 モデルで整理した「ちょうどいい抽象度」が、各プロセスで効く ここからは、モデルが各プロセスでどう活きるかを見ていく 37
38. ドキュメントの階層化 中規模以上の開発は、エピックとPBIの2階層に分けて粒度・記述量を整理 する 階層 単位 向き合う不確実性 記述するもの エピック プロジェクト／機能群 What / Why 要求・要件・大まかな仕様・大まかな技術設計 PBI バックログアイテム How 受入基準・細かい技術設計・PBI単位のテスト モデリングはエピックレベルで実施。後続の各プロセスで再利用する 38
39. Specification by Example 具体例で仕様を書くと、人もAIも迷わない Specification by Example（SbE）の利点： 共通理解の形成: 抽象仕様だと人によって解釈が分かれる → 具体例で全員が同じ像を持てる コーナーケースの炙り出し: 具体例を書こうとすると、扱いの曖昧な境界が自然に見えてくる テストへの接続: Given/When/Then はそのまま自動テスト（BDD）の形式 AIへの正確な指示: 抽象指示よりブレが少なく、実装が意図通りになりやすい Given: 商品A （1000 円） 、商品B （500 円）が存在 When : 「価格: 安い順」で並べ替え Then : 商品B → 商品A の順で表示 sudoモデリングのオブジェクト図がまさにこの「具体例」 。モデリングの成果がそのまま受入基 準のインプットになる 39
40. 受入基準は「AIで磨き込む」 ドキュメントレビューはAIに質問させる形にすると効果的 大量のドキュメントを見て改善点を出すのは難しい AIに質問させる = 論点を洗い出す 重要な論点が最初に出ると、検討が進めやすい Claude Code は AskUserQuestion ツールで選択式回答 選択肢に推奨度＋理由を書かせると、 「こう思うけどどう？」と議論しやすい 勝手に聞いてくれない場合: 「現時点で検討すべき重要なことを優先して質問して」と指定 40
41. 技術設計：モデル＝コードをAIのガードレールにする DDDの実装パターンを、AIに守らせるルールとして定義する CLAUDE.md / .claude/rules/ にドメインモデルをそのままコードで表現するルールを定義 エンティティ・値オブジェクト・リポジトリ等のパターンを明文化 アーキテクチャ制約・コーディング規約も事前定義 AIはルールがあれば従ってくれる。毎回同じことを言わなくていい状態を作る 静的解析でカバーできる範囲は決定論的にチェック、AI判断はそれ以外に絞る 「モデルを守ったコード」が自動的に生成される状態を目指す 41
42. 図でレビューする テキストだけより、図で確認する方が圧倒的にレビューしやすい SDDライブラリの出力はテキスト中心 → 複雑な設計はレビューが辛い draw.ioでクラス図／データフローにすると、一目で妥当性を判断できる 42
43. アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 43
44. 観点は分かった。でも、全プロセス一気にはできない どこから着手するか ─ チームの現在地を測ることから始める ここまでで、モデリング → 各プロセスへの繋ぎ方を見てきた でも、全プロセスを一気にスキル化・再設計するのは現実的じゃない 「検査と適応のサイクル」を、どのプロセスから設計し始めるか の選択が必要 まずは 各プロセスの現在地（成熟度）を測るところから始める 44
45. AI活用フェーズで現在地を測る プロセスごとに「現在地 → 目標」を可視化する フェーズ 内容 1. 個人利用 コーディングエージェントを個別に使う 2. スキル共通化 チームで特定プロセス用のスキルを定義（点としてのスキル） 3. プロセス再定義・スキル 連結 AI前提でプロセスを再定義し、スキル同士のアウトプット／インプットを設計（線 になる） 4. AIによる自律的開発 各プロセスでAIが自律的に判断する割合を増やす 参考: ELEKS「AI SDLC Maturity Model」 （https://eleks.com/blog/ai-sdlc-maturity-model/) 　　をベースにカスタマイズ どのプロセスから検査と適応のサイクル設計に着手するかを決める 45
46. アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 46
47. まとめ AI時代にも、DDDのプラクティスはそのまま活用できる ドメインモデリングは、AIに渡す「共通言語」になる 「ちょうどいい抽象度」が、受入基準・技術設計・実装のインプットになる DDDの実装パターンは、AIの「ガードレール」になる モデル＝コードのルールを定義し、AIが守れる状態を作る 各プロセスで検査と適応のサイクルを設計し、アジャイルの基礎をAIで高速に回す まずは現在地を測り、1プロセスからDDDを試してみよう 47
48. ログラスからのお知らせ ─ 他メンバーも登壇します！ AI Engineering Summit Tokyo 2026 / AWS Summit Japan 6/9 AI Engineering Summit Tokyo 2026 AI Ops Mgr 荒木 (@shim_surprise) 6/26 AWS Summit Japan SRE 中井 (@elmodev09) 48
49. 書籍 & 匿名質問はこちらから ドメイン駆動設計の書籍 / Xの質問箱で匿名質問受け付け中！ 書籍「ドメイン駆動設計 モデリング/実装ガイド」 https://little-hands.booth.pm/items/1835632 書籍「ドメイン駆動設計 サンプルコード&FAQ」 https://little-hands.booth.pm/items/3363104 X（質問箱で匿名質問OK！） https://x.com/little_hand_s 一緒にモデリングする勉強会: https://little-hand-s.notion.site/DDD-22429f7110574439a4c3e126c20fa9a2 49
50. ご清聴ありがとうございました 松岡 幸一郎 X(Twitter): @little_hand_s 50