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

by Koichiro Matsuoka

Embed

Start on current slide

Slide 1

Slide 1 text

AI時代に改めて考える、ドメイン駆動設計モデリングが「AIへの共通言語」になる松岡幸一郎 / ログラス Findy 2026/5/26 1

Slide 2

Slide 2 text

自己紹介 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

今日のゴール DDD × AIで、開発プロセス全体の品質を上げる方法を持ち帰ってもらう持ち帰ってもらえると良いこと: sudoモデリング ── 取り組みやすい4つの図のフレームワーク draw.io × AI ── 図を使ってAIと壁打ちする実践モデルを各プロセスに繋ぐ ── 受入基準・技術設計・実装へ展開 AI活用フェーズの可視化 ── チームの現在地を測る物差し 5

Slide 6

Slide 6 text

アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 6

Slide 7

Slide 7 text

DDDとは DDD（ドメイン駆動設計）= プロダクト開発で大きな価値を生むための手法「ドメイン」 = ソフトウェアで問題解決しようとする対象（業務領域） DDDの目的: 機能性（役に立つものを作る） × 保守性（長期間作り続けられる） DDDは2003年、今から20年以上前からある手法。　　AI時代の今、DDDにはどんな価値があるのか？ 7

Slide 8

Slide 8 text

DDDの目的役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにする ①ソフトウェアの機能性を高めること役に立つものを作る。「作ったけど使えない」を避ける ②ソフトウェアの保守性を高めること長期間開発しても機能拡張が容易でありつづける「技術的負債でどんどん開発速度が低下する」を避ける 8

Slide 9

Slide 9 text

DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング 9

Slide 10

Slide 10 text

DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング「ドメインモデル」にドメインの知識を反映し、役に立つものになる可能性を高めるドメイン知識があれば役に立つものが作れるわけでは無いただ、ドメイン知識がなければ役に立つものは作れない →ドメイン知識は十分条件ではないが、必要条件開発初期だけでなく、各フェーズで発見をフィードバックして改善頻度を上げる → 次のセクション「モデリング」で詳細に紹介 10

Slide 11

Slide 11 text

DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン 11

Slide 12

Slide 12 text

DDDのアプローチ ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターンモデルの形をそのままコードで表現し、頻繁な更新を反映しやすくする保守性の高いデザインパターン（エンティティ、リポジトリ等）を適用する → これをAIのガードレールとして設定する話を後の「モデルを各プロセスに繋ぐ」セクションで紹介 12

Slide 13

Slide 13 text

モデルとコードの「形」を揃える「モデルの形をそのまま表現」とは何か、3枚で具体イメージを掴む「モデルの形をそのままコードで表現」と言われても具体イメージが湧きにくい次の3枚で、モデルとコードの対応関係がどう変わるかを見ていく ① 乖離があるとどうなるか ② 変更時に何が困るか ③ 同じ形にすると何が嬉しいか 13

Slide 14

Slide 14 text

モデルと実装のつながり(1/3) モデルと実装に乖離があると、対応関係が見えにくくなる 14

Slide 15

Slide 15 text

モデルと実装のつながり(2/3) モデルに変更があった時、コードのどこに反映すべきかわからなくなる 15

Slide 16

Slide 16 text

モデルと実装のつながり(3/3) コードは極力モデルと同じ形での表現を目指すモデルとコードを同じ形にすると、変更の反映先が一目でわかる 16

Slide 17

Slide 17 text

モデリングとAI出力の関係モデル＝実装が同じ形だから、モデリング時点で実装の輪郭が固まるモデルが決まれば、実装の構造もほぼ決まる → モデリングは「実装の下書き」を兼ねる AIに渡せば、想定通りの出力が返ってくる確度が一気に上がるモデリングで議論を尽くす = 後段の手戻りを減らす最短ルート 17

Slide 18

Slide 18 text

アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 18

Slide 19

Slide 19 text

モデリングとはモデリング = モデルを議論しながら作る活動モデル = 問題解決のために作る抽象化物モデリング = それを議論しながら作る活動成果物だけでなく、作るプロセスで議論・認識合わせ・意思決定することが重要 19

Slide 20

Slide 20 text

モデリングの役割ドメインをモデル化し、ソフトウェアで問題を解決する橋渡しになる複雑なドメイン（業務領域）をドメインモデルとして抽象化するそのモデルをもとにソフトウェアを構築し、問題を解決するモデルというワンクッションを置くことで、複雑な問題を解決する精度が上がる 20

Slide 21

Slide 21 text

モデリングの価値「ちょうどいい抽象度」で情報を整理でき、AIに渡す精度が上がる ①複雑な構造を整理しやすいテキストは線形で構造を伝えにくいが、図なら2次元で関係性を一目で把握できる ②ちょうど良い抽象度で構造を整理できる画面項目だと具体すぎる、要件文だと抽象すぎる。モデルが中間で効くこの「ちょうどいい抽象度」が、AIに渡すコンテキストとして最適 21

Slide 22

Slide 22 text

モデリング着手の判断新規開発でも、既存システムの理解でも、モデリングは有効 ①新規機能開発や機能改修を行う時ドメイン理解を深めて、役立つものを作れるようにするわかること、わからないことを明確にして意思決定しやすくする ②モデリングを後追いで実施する時リバースエンジニアリング的に、すでにあるコードについて理解するコードやモデルの現実と、ドメインの理想とのギャップを明確にするすべてが①で実施できれば理想だが、②も現実的には有用。②から①に繋ぐこともできる 22

Slide 23

Slide 23 text

DDDにおけるモデリング手法 DDDのモデリング手法に決まりはない。今回は筆者が複数の現場でモデリングをしてきた中で、最も導入ハードルが低く、効果を出しやすいと考えている手法を紹介します 23

Slide 24

Slide 24 text

sudoモデリング sudoモデリングは、ハードルが低く効果が出しやすいモデリング手法図やること S: システム関連図システムに関わるアクター・外部システムを明示 U: ユースケース図ユーザーがどんな操作をするか描く D: ドメインモデル図概念と関係を抽象的に描き、共通言語を作る O: オブジェクト図具体例で理解を深め、モデルの矛盾・漏れを検証これは「どんな時にもやると良い最低限の4つ」頭文字をとって「sudoモデリング」業務フロー図／状態遷移図／シーケンス図 / ER図などは併用するとよい 24

Slide 25

Slide 25 text

モデリングの題材採用管理システムの開発初期をシミュレーション採用担当者が応募者の進捗管理などを行うシステム 4つの図でこのシステムをモデリングする例を順番に紹介 25

Slide 26

Slide 26 text

モデリングするときのポイント抽象と具体を行き来し、仮説を回し続ける抽象だけではなく、具体例が大切よい解決策を考えるには具体例が必要具体例が出せない＝そもそもドメイン理解が足りてないサインモデリングは、成果物以上にプロセスが大切わからないことを明らかにして、不足している知識や知見を埋めに行く得た情報の中で意思決定をしていく意思決定は常に仮説であると考えるドメインの問題解決には、常に不確実性が存在する初期段階では全ては仮説。いかにフィードバックサイクルを回し、仮説の確度を高められるかを考えるモデル図は仕様書ではなく、ホワイトボードのように扱うただし、メンテするものは明確に決めて最新化する 26

Slide 27

Slide 27 text

システム関連図（System Context Diagram）開発するシステム、関わりのあるアクターや外部システムとの関連を示す図アクター（誰が使うか）、外部システム（何と連携するか）を描く全体を俯瞰することで、スコープの認識を合わせられる 27

Slide 28

Slide 28 text

システム関連図（System Context Diagram）実は、重要な意思決定をしている大したことのない図に見えるが・・・応募者がこのシステムを使わない、とすると開発する機能が大きく変わるこの図を作る過程で、「応募者ってここにログインする？」という議論がされ、その意思決定の結果前述の通り「モデリングは、成果物以上にプロセスが大切」 28

Slide 29

Slide 29 text

ユースケース図（Use Case Diagram）ユーザーの要求に対するシステムの振る舞いを定義する図アクターごとに「どんな操作をするか」を描く機能の漏れや優先順位の議論に使える 29

Slide 30

Slide 30 text

オブジェクト図（Object Diagram）抽象的なモデルを「具体例」で検証するための図「田中太郎さんがA社のバックエンドエンジニア職に応募」のように、実際のデータで描く具体例を描くことで、ドメインの理解を深め、モデルの矛盾や漏れが見つかる 30

Slide 31

Slide 31 text

ドメインモデル図（Domain Model Diagram）ドメインの概念と関係性を抽象的に描き、共通言語を作る図オブジェクト図（具体例）から抽象化し、そのままコードで表現できるモデルを作るチームの共通言語になり、コードの設計にも直結する 31

Slide 32

Slide 32 text

ドメインモデル図のモデリングのコツオブジェクト図から抽象化し、ルール・制約を書き出すオブジェクト図（具体例）から、ドメインモデルに抽象化していくルール/制約（ドメイン知識）を吹き出しに書き出すモデリング中に疑問が出たものをその場で議論してメモしていく検討メモも積極的に記述する生じた疑問の結論や疑問点もOK。発見を誘発し、関係者の認識を残す多重度を定義する「採用選考から採用ポジションの紐付けは必須か？」など、ルール/制約として重要な意思決定実装前に主にエンジニアで決めること: 集約の範囲: リポジトリの範囲を決める日本語名の対訳としての英語名: ユビキタス言語のマスタ。表記揺れを防ぐ 32

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

draw.io × AI で壁打ちするドメインモデル図をAIに渡して「具体例を出して」と指示でオブジェクト図のパターン検討ができる 34

Slide 35

Slide 35 text

draw.io × AI で観点を引き出す 1人では見落としがちな観点をAIが補完してくれる「この図の懸念点は？」と聞くと、検討すべきポイントを提示 35

Slide 36

Slide 36 text

アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 36

Slide 37

Slide 37 text

モデルは作って終わりではないモデルが、後続プロセスのインプットになって初めて価値が出るモデリング → 受入基準 → 技術設計 → テスト → 実装モデルで整理した「ちょうどいい抽象度」が、各プロセスで効くここからは、モデルが各プロセスでどう活きるかを見ていく 37

Slide 38

Slide 38 text

ドキュメントの階層化中規模以上の開発は、エピックとPBIの2階層に分けて粒度・記述量を整理する階層単位向き合う不確実性記述するものエピックプロジェクト／機能群 What / Why 要求・要件・大まかな仕様・大まかな技術設計 PBI バックログアイテム How 受入基準・細かい技術設計・PBI単位のテストモデリングはエピックレベルで実施。後続の各プロセスで再利用する 38

Slide 39

Slide 39 text

Specification by Example 具体例で仕様を書くと、人もAIも迷わない Specification by Example（SbE）の利点：共通理解の形成: 抽象仕様だと人によって解釈が分かれる → 具体例で全員が同じ像を持てるコーナーケースの炙り出し: 具体例を書こうとすると、扱いの曖昧な境界が自然に見えてくるテストへの接続: Given/When/Then はそのまま自動テスト（BDD）の形式 AIへの正確な指示: 抽象指示よりブレが少なく、実装が意図通りになりやすい Given: 商品A （1000 円）、商品B （500 円）が存在 When : 「価格: 安い順」で並べ替え Then : 商品B → 商品A の順で表示 sudoモデリングのオブジェクト図がまさにこの「具体例」。モデリングの成果がそのまま受入基準のインプットになる 39

Slide 40

Slide 40 text

受入基準は「AIで磨き込む」ドキュメントレビューはAIに質問させる形にすると効果的大量のドキュメントを見て改善点を出すのは難しい AIに質問させる = 論点を洗い出す重要な論点が最初に出ると、検討が進めやすい Claude Code は AskUserQuestion ツールで選択式回答選択肢に推奨度＋理由を書かせると、「こう思うけどどう？」と議論しやすい勝手に聞いてくれない場合: 「現時点で検討すべき重要なことを優先して質問して」と指定 40

Slide 41

Slide 41 text

技術設計：モデル＝コードをAIのガードレールにする DDDの実装パターンを、AIに守らせるルールとして定義する CLAUDE.md / .claude/rules/ にドメインモデルをそのままコードで表現するルールを定義エンティティ・値オブジェクト・リポジトリ等のパターンを明文化アーキテクチャ制約・コーディング規約も事前定義 AIはルールがあれば従ってくれる。毎回同じことを言わなくていい状態を作る静的解析でカバーできる範囲は決定論的にチェック、AI判断はそれ以外に絞る「モデルを守ったコード」が自動的に生成される状態を目指す 41

Slide 42

Slide 42 text

図でレビューするテキストだけより、図で確認する方が圧倒的にレビューしやすい SDDライブラリの出力はテキスト中心 → 複雑な設計はレビューが辛い draw.ioでクラス図／データフローにすると、一目で妥当性を判断できる 42

Slide 43

Slide 43 text

アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 43

Slide 44

Slide 44 text

観点は分かった。でも、全プロセス一気にはできないどこから着手するか ─ チームの現在地を測ることから始めるここまでで、モデリング → 各プロセスへの繋ぎ方を見てきたでも、全プロセスを一気にスキル化・再設計するのは現実的じゃない「検査と適応のサイクル」を、どのプロセスから設計し始めるかの選択が必要まずは各プロセスの現在地（成熟度）を測るところから始める 44

Slide 45

Slide 45 text

AI活用フェーズで現在地を測るプロセスごとに「現在地 → 目標」を可視化するフェーズ内容 1. 個人利用コーディングエージェントを個別に使う 2. スキル共通化チームで特定プロセス用のスキルを定義（点としてのスキル） 3. プロセス再定義・スキル連結 AI前提でプロセスを再定義し、スキル同士のアウトプット／インプットを設計（線になる） 4. AIによる自律的開発各プロセスでAIが自律的に判断する割合を増やす参考: ELEKS「AI SDLC Maturity Model」（https://eleks.com/blog/ai-sdlc-maturity-model/) 　　をベースにカスタマイズどのプロセスから検査と適応のサイクル設計に着手するかを決める 45

Slide 46

Slide 46 text

アジェンダ 1. なぜ今、ドメイン駆動設計（DDD）か 2. モデリング ─ AIへの「共通言語」を作る 3. モデルを各プロセスに繋ぐ 4. チームの現在地を測る 5. まとめ 46

Slide 47

Slide 47 text

まとめ AI時代にも、DDDのプラクティスはそのまま活用できるドメインモデリングは、AIに渡す「共通言語」になる「ちょうどいい抽象度」が、受入基準・技術設計・実装のインプットになる DDDの実装パターンは、AIの「ガードレール」になるモデル＝コードのルールを定義し、AIが守れる状態を作る各プロセスで検査と適応のサイクルを設計し、アジャイルの基礎をAIで高速に回すまずは現在地を測り、1プロセスからDDDを試してみよう 47

Slide 48

Slide 48 text

ログラスからのお知らせ ─ 他メンバーも登壇します！ 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

Slide 49

Slide 49 text

書籍 & 匿名質問はこちらからドメイン駆動設計の書籍 / 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

Slide 50

Slide 50 text

ご清聴ありがとうございました松岡幸一郎 X(Twitter): @little_hand_s 50