■ 1. 概要・ゴール
- 発表者: 松岡幸一郎（株式会社ログラス / AI基盤開発室）
- テーマ: DDD × 仕様駆動でAI駆動開発の品質を上げるプロセス設計
- 持ち帰り項目:
- sudoモデリング（4つの図のフレームワーク）
- draw.io × AI（図を使ったAIとの協働）
- 仕様駆動との接続（AIに「何を作るか」を正確に伝えるプロセス）
- その他の品質向上のためのプラクティス
■ 2. DDDとは・DDDのアプローチ
- DDDとは:
- ドメイン駆動設計 = プロダクト開発で大きな価値を生むための手法（2003年〜）
- 「ドメイン」= ソフトウェアで問題解決しようとする対象（業務領域）
- 目的: 機能性（役に立つものを作る）× 保守性（長期間作り続けられる）
- DDDの2つのアプローチ（AI時代にも有効）:
- 機能性向上: ドメインエキスパートと共に行うドメインモデリング → 作るものを検討しAIに渡すために活用
- 保守性向上: 頻繁なモデルの更新に耐えられる実装パターン → 実装のガードレールとして活用
- モデルと実装の一致の重要性:
- モデルと実装に乖離があると対応関係が見えにくくなる
- モデルに変更があった時コードのどこに反映すべきかわからなくなる
- コードは極力モデルと同じ形での表現を目指す（変更の反映先が一目でわかる）
- ドメイン知識の位置づけ:
- ドメイン知識があれば役に立つものが作れるわけではない
- ただしドメイン知識がなければ役に立つものは作れない（必要条件）
■ 3. 仕様駆動開発とは
- 定義: 仕様（完了条件・設計・テスト）を先に決め、AIに実装させる開発アプローチ
- 設計で押さえるべき3要素:
- 完了条件（受入基準）
- 技術的な設計
- テスト
- 本質: 上流で品質を作り込み、手戻りを防ぐこと
- DDD × 仕様駆動の組み合わせ:
- DDDのモデリングが最上流で「何を作るか」を明確にする
- 仕様駆動が各フェーズで品質を作り込む
- 作ったモデルが仕様駆動の各フェーズのインプットになる
■ 4. フェーズ①: モデリング
- モデリングの定義:
- モデル = 問題解決のために作る抽象化物
- モデリング = それを議論しながら作る活動
- 成果物だけでなく、作るプロセスでの議論・認識合わせ・意思決定が重要
- モデリングが役立つ理由:
- 複雑な構造を整理しやすい（図なら2次元で関係性を一目で把握できる）
- 「ちょうどいい抽象度」で構造を整理できる（画面の詳細項目だと具体的すぎる）
- これが仕様駆動の各フェーズの精度向上につながる
- モデリングのタイミング:
- 新規機能開発・機能改修時: ドメイン理解を深め、わからないことを明確にして意思決定しやすくする
- 後追いで実施する時: リバースエンジニアリング的に既存コードを理解し、現実と理想のギャップを明確にする
- sudoモデリング（4つの図）:
- S（システム関連図）: システムに関わるアクターと外部システムを明示する
- U（ユースケース図）: ユーザーがシステムでどのような操作を行うか明示する
- D（ドメインモデル図）: 概念と概念の関係を抽象的に描く
- O（オブジェクト図）: 具体的なデータ例で理解を深め、モデルを検証する
- 補足として業務フロー図・状態遷移図・シーケンス図も併用可
- モデリング時のポイント:
- 抽象と具体を行き来し、仮説を回し続ける
- 具体例が出せない = ドメイン理解が足りていないサイン
- 意思決定は常に仮説であると考える（モデル図はホワイトボードのように扱う）
- ドメインモデル図のコツ:
- オブジェクト図（具体例）からドメインモデルに抽象化していく
- ルール/制約（ドメイン知識）を吹き出しに書き出す
- 検討メモも積極的に記述する（疑問点も発見を誘発し認識を残す）
- 多重度を定義する（ルール/制約として重要な意思決定）
- 集約の範囲（リポジトリの範囲を決める）と英語名（ユビキタス言語のマスタ）を決める
- AIとの協働（draw.io × AI）:
- AIがdraw.ioファイルを直接操作できるSkillを作成（claude-drawio-skill）
- draw.ioで描いたモデル図をAIに読み込ませて壁打ちしながらモデルを育てる
- 「具体例を出して」と聞くだけでオブジェクト図（具体例）を生成できる
- 「この図の懸念点は？」と聞くと1人では見落としがちな観点をAIが補完してくれる
■ 5. フェーズ②: 受入基準
- 完了条件が曖昧だと意図と違う実装が進む（AIコードドリフト）
- AIは経験や暗黙知で補完できないため、曖昧な仕様は乖離した実装を生み続ける
- 完了条件を磨き込むことで手戻りを減らせる（AIが自己修正ループを回せ出力品質が上がる）
- モデルで整理した構造が受入基準を書くインプットになる
- 受入基準のアプローチ（4点）:
- AIで磨き込む: 受入基準を決めたらAIによるレビュー（チェックポイント確認）・リファインメント（不明瞭な点を質問）を入れる
- Question-First: 大量ドキュメントをレビューさせるより質問させることで論点を洗い出す（CLAUDE.mdに指示しておく）
- Specification by Example（SBE）: 具体的な実例（Given/When/Then形式）で仕様を定義する
- sudoモデリングのオブジェクト図がそのままこの「具体例」として活用できる
- 具体例を書こうとすると自然にコーナーケースが洗い出される
- AIにとっても具体例 = 入出力が明確 → 意図通りの実装になる
- 図による可視化: draw.ioでSBEを可視化すると考慮漏れの状態遷移やロジックの分岐が一目で見つかる
■ 6. フェーズ③④⑤: 技術設計・テスト・実装
- 技術設計フェーズ:
- 意思決定の前倒し: Question-Firstで設計段階でAIに質問させ実装前に意思決定を済ませる
- 固定観点レビューSkill: プロジェクトで重視する設計観点を言語化してSkillにし、毎回確実に同じ観点でチェックされる状態を作る
- DDDの保守性アプローチ × AIガードレール:
- ドメインモデルをコードで表現するルールをAIに守らせる
- CLAUDE.md / .claude/rules/ にルールを定義（エンティティ・値オブジェクト・リポジトリ等のパターン、設計原則・アーキテクチャ制約・コーディング規約を事前定義）
- AIはルールがあれば従ってくれるため「モデルを守ったコード」が自動的に生成される状態を作る
- ビジュアルで設計を確認:
- 複雑な仕様はテキストだけだとレビューが辛い
- draw.ioでクラス図やデータフローにすると一目で把握できる
- テスト分析設計フェーズ:
- テストを明示的に検討させる: 実装計画と同じタイミングでテスト設計も依頼する（実装前にテストを考えることで仕様の抜け漏れ・矛盾に気づける）
- テスト設計・レビューSkill: テスト観点をSkillとして言語化し毎回確実に同じ観点でレビューできる状態を作る（チームで育てることでQAの観点・過去の不具合パターンが蓄積される）
- 実装フェーズ:
- AIが自律的に実装・検証を回せる環境を整える
- 自動テスト × ブラウザ操作（playwright-mcp等）で画面確認まで任せられると手離れが良くなる
- コンテキストエンジニアリング（AIが必要な情報に確実に辿り着ける設計）:
- FLOWとSTOCKに分ける: FLOW（開発中に書き留める一時的な情報）・STOCK（AIがまず参照する整理済みドキュメント）
- 段階的開示: README.mdにインデックスへのパスを書いておきAIが段階的にたどれる構造を作る（大量のドキュメントを一度に読ませるのではなく必要な時に必要な情報だけ渡す）
■ 7. まとめ
- DDDのモデリングは「ちょうどいい抽象度」で複雑なドメインを整理できる
- その「ちょうどいい抽象度」が受入基準・技術設計・テストのインプットになる
- DDD × 仕様駆動は一本のプロセスとして繋がり、開発全体の品質が上がる