- URL: AI時代に改めて考える、ドメイン駆動設計 - モデリングが『AIへの共通言語』になる
- 著者: 松岡幸一郎（@little_hand_s）
- 公開日: 2026-05-26
関連動画
いつ読むか？
- AI駆動開発のプロセスを設計・再定義したいとき
- Agent Skill（スキル）の粒度や入出力フォーマットを検討しているとき
- DDDのモデルをAIへの指示にどう活かすか考えているとき
- Gherkin記法や受け入れ基準の書き方を整理したいとき
読書メモ
モデルが後続プロセスのインプットになって初めて価値が出る
「モデリング → 受入基準 → 技術設計 → テスト → 実装」という流れで、モデルが各ステップへ橋渡しされる。
AIに各ステップを担わせる場合、AI の作業は非決定性が高い。これを下げるには：
- 入力・出力を定型フォーマットや Agent Rules で縛る
- AI に任せる単位でステップを切り出す
→ 予測可能で期待通りのアウトプットが得られる構造になる。
具体例で仕様を書くと、人もAIも迷わない
Gherkin 記法は受け入れ基準として有効。Scenario Outline でパターンをまとめると、ケースの網羅性も上がる。
DDDの実装パターンをAIに守らせるルールとして定義する
自分が取り組んでいる方向と一致。ドメインモデルをそのままコードに反映し、AIへの命令（Agent Rules）として定義することで一貫性を保つ。
プロセスを「点のスキル」から「線になるスキル」へ
- 点: チームで特定プロセス用の Agent Skill を定義する
- 線: AI前提でプロセスを再定義し、スキル同士のアウトプット／インプットを設計する
→ ステップごとに Agent Skill を定義し、前後をつなぐ設計が AI駆動開発プロセスの効果的な構造。この考え方が頭の中でクリアになった。