ドメインとは？
AI時代に必要な「専門性」を、意味・DDDとともに図解！

イントロダクション：ドメインを一言で言うと？ 🌏

「AI駆動開発」が注目される今こそ、その前提となる「ドメイン駆動（DDD）」が重要です。 AIは“どう作るか”を加速しますが、“何を作るべきか”を定義するのは人間のドメイン知識だからです。

ドメインとは、ソフトウェアが向き合っている 「現実世界の仕事・問題・ルールのまとまり」 です。ECサイトなら「商品・注文・在庫・配送・決済」、家計簿アプリなら「収入・支出・残高・月締め」のように、 システムが扱う世界観そのものを指します。

このページでは、ドメインの意味、DDD（ドメイン駆動設計）の基本、 そしてAI時代にドメインをどう整えると生成精度が上がるかをまとめて解説します。

ドメイン駆動：何を作るか（価値・用語・ルール・境界）
AI駆動      ：どう作るか（実装・テスト・リファクタ）
		

1. なぜこの「ドメイン」という考え方が大事なの？ 🎯

ドメインを意識せずにコードを書いていると、 次のような「現場あるある」の原因になりがちです。

• ビジネスルールが散らばる
  重要なルールが画面・バッチ・SQL・コメントなど、あちこちにバラバラに埋め込まれていき、 「このルールってどこで決まってるの？」が分からなくなる。
• 用語がバラバラになる
  同じ概念を、ドキュメントでは「会員」、DBでは「user」、画面では「お客様」など 違う言葉で呼んでしまい、認識合わせに毎回コストがかかる。
• 変更の影響範囲が読めない
  「この仕様変更はどのコードを直せばいい？」が分かりにくくなり、 直してはいけないところまで壊してしまうリスクが高まる。

逆に、 「このシステムのドメインは何か」「どんな概念とルールがあるか」 を整理しておくと、 アーキテクチャやモジュール分割の軸がはっきりします。 AI時代では特に、境界が明確なドメインほどプロンプトの文脈がぶれず、 「仕様に沿って自然にコードが生える」状態を作りやすくなります。

2. どこからどこまでが「ドメイン」なの？（境界のイメージ）

ドメインは、システムの中でも特に 「現実世界のルール・状態・用語」を表す部分 に対応します。

• ドメインに含まれるもののイメージ
  「顧客」「注文」「請求書」「在庫」「支払い」などの 概念（名詞）、 「注文を確定する」「在庫を引き当てる」「請求額を計算する」などの 振る舞い（動詞・ルール）、 「注文はキャンセル済みに戻せない」などの制約。
• ドメインに含まれないもののイメージ
  画面のデザインやボタンの位置、DBのインデックス、ログ出力のフォーマット、 HTTP リクエストのパース処理などは、 ドメインを支える「仕組み側（インフラ・UI）」 であって、 ドメインそのものではありません。

アーキテクチャの文脈で、 「ドメイン層」「ドメインモデル」「ドメインサービス」 といった言葉が出てきたら、それは 「この業務のルールを表現するためのコードを置く場所」 だと捉えると分かりやすくなります。

なお、ここでいう「ドメイン」は インターネットのドメイン名（example.com など）とは別物です。

3. 具体例でイメージする：ECサイトと家計簿アプリ 📦💰

抽象的なままだとつかみにくいので、代表的な例でドメインをイメージしてみましょう。

例1：ECサイトの場合

• ドメインにあたるもの
  商品、カート、注文、在庫、配送、キャンペーン、決済などの概念と、 それらの関係・ルール（在庫数の計算、送料の条件、ポイント付与の計算など）。
• ドメインではないもの
  商品一覧画面のレイアウト、DB接続プールの設定、外部APIクライアントの実装、Webサーバの設定などは 「どう見せるか・どう動かすか」の仕組み側。

例2：家計簿アプリの場合

• ドメインにあたるもの
  収入・支出・カテゴリ・口座・残高・月締め・予算などの概念と、 「支出には必ずカテゴリが必要」「月をまたぐときは締め処理が必要」などのルール。
• ドメインではないもの
  「円グラフで表示するか棒グラフにするか」「ダークモードの色」「CSVエクスポートのUI」などは、 ドメイン情報をどう表示・出力するかという仕組み側の話です。

このように、「何を扱い、どんなルールで動く世界なのか」 に注目すると、 ドメインの輪郭が見えやすくなります。

4. DDD（ドメイン駆動設計）の基本を短く整理

DDD（ドメイン駆動設計）は、ドメインを中心にソフトウェアを設計するための実践知です。全部を一気に導入する必要はなく、 まずは次の3点を押さえると効果が出やすくなります。

• ユビキタス言語：業務とコードで同じ言葉を使い、認識ズレを減らす。
• 境界づけられたコンテキスト：文脈ごとにモデルを分け、用語の衝突を防ぐ。
• ドメインモデル：Entity / Value Object でルールと不変条件を表現する。

5. 図解の補足：AI時代は「境界」がそのまま生成精度になる

図解で示したドメイン層の分離は、AI活用でさらに価値が上がります。境界づけられたコンテキストが明確だと、 AIは「どの用語を」「どのルールで」「どの範囲まで」守るべきかを理解しやすくなります。

逆に境界が曖昧だと、AIは別コンテキストのルールを混ぜた“それっぽい実装”を返しがちです。 つまり、ドメインを整えること自体がAIを迷子にしない設計になります。

6. AI時代に必須の3つの視点

6-1. ユビキタス言語は最強のプロンプト

DDD（ドメイン駆動設計）の核心であるユビキタス言語は、そのままAIとの対話品質を上げる道具です。 ドメイン用語を定義してから依頼すると、AIは曖昧推測ではなく、定義済みの文脈で実装できます。

比較例（擬似コード）

曖昧な依頼:
「注文確定の処理を作って」

用語定義済みの依頼:
「注文(Order)は Confirmed / Cancelled のみ。
Confirmed 後は Cancelled に戻せない。
在庫引当(AllocateStock)成功時のみ Confirmed に遷移。
OrderId / Money / StockQuantity を Value Object として実装して」
		

後者は、価値・用語・ルール・境界がそろっており、生成コードの精度とレビュー効率が大きく上がります。

6-2. ドメインモデルはAIの暴走を防ぐガードレール

AIは実装速度が高い一方、業務の禁止ルールを見落とすことがあります。 そのため、ルールをドメイン層に閉じ込め、不正な状態を作れない設計にしておくことが重要です。

不変条件の例（擬似コード / JS風）

// 擬似コード（JS風）
// Value Object：金額は「正の値」しか作れない（不正状態を入口で遮断）
class Money {
  constructor(value) {
    if (!Number.isFinite(value)) throw new Error("金額は数値");
    if (value <= 0) throw new Error("金額は正");
    this.value = value;
  }
}

// Entity：状態遷移などの業務ルールを閉じ込める
class Order {
  constructor(id, totalAmount, status) {
    // totalAmount は Money を前提にする（＝不正な金額はそもそも渡せない）
    if (!["Draft", "Confirmed", "Cancelled"].includes(status)) {
      throw new Error("不正な状態");
    }
    this.id = id;
    this.totalAmount = totalAmount;
    this.status = status;
  }

  // 状態遷移も、ドメイン（業務）のルールで守る
  confirm(stockAllocated) {
    if (this.status !== "Draft") throw new Error("Draftのみ確定可能");
    if (!stockAllocated) throw new Error("在庫未引当では確定不可");
    this.status = "Confirmed";
  }
}

このようにEntity / Value Objectに不変条件を置くと、AIがどれだけコードを生成しても「破ってはいけない業務ルール」はドメイン層で守れます。 たとえば金額は Money を通さないと作れないため、負の値などの不正状態を入り口で防げます。 さらに Order の confirm のように、状態遷移の条件もドメインで固定できるため、“それっぽい誤実装”が入り込みにくくなります。 Money は値そのものを表す Value Object なので、変更ではなく「新しい Money を作る」前提で扱います。

6-3. AIに教えられない「課題の発見」こそ人間のドメイン

AIは解法の探索は得意ですが、「何を解くべきか」の発見は苦手です。 顧客価値、業務の痛み、現場の例外、責任分界点の設計は人間が担うべき領域です。

人間が主導する領域: 何を（課題定義・価値設計・境界設計）
AIが加速する領域  : どうやって（実装・テスト・リファクタ）
		

ドメインを学ぶほど、AIに代替されにくい「課題設定力」と「意思決定力」が強くなります。

まとめ：AI駆動の前にドメイン駆動

• AIは断片（コード）を素早く作れますが、 何を作るべきか（価値・用語・ルール・境界）は人間が定義する必要があります。
• ユビキタス言語を整えるほど、AIへの指示は精密になり、生成物のレビューコストは下がります。
• ドメインモデルに不変条件を閉じ込めるほど、AIの“それっぽい誤実装”を防ぎやすくなります。
• AI時代に伸ばすべき中核スキルは、実装速度そのものより 課題発見とドメイン設計です。

結論として、AI駆動の前にドメイン駆動です。 人は秩序（意味・ルール・言葉・境界）を作り、AIは実装を加速する。 ドメインを整えるほどAIは賢く使えます。

おまけ：AI時代のドメイン設計チェックリスト

• 課題定義を1文で言語化できる（誰の、どの痛みを、どう減らすか）。
• ユビキタス言語の用語集があり、仕様書とコードで同じ語を使っている。
• 境界づけられたコンテキストを図示し、責務の越境を防いでいる。
• Entity / Value Object に不変条件を置き、不正状態を生成できない。
• AIへのプロンプトに「価値・用語・ルール・境界」を必ず含めている。

関連リンク

• 原則の全体像から復習したい人向け：101の原則はこちら
• AI生成でも崩れない土台を作る『アーキテクチャ』の要点を図解で理解する
• AIに“正しい意図”を伝える『凝集度（高凝集）』の作り方を学ぶ
• AI時代に必須の密結合↔疎結合！『結合度』の判断軸を掴む
• AIに依存しすぎないコードを書くための『疎結合』のコツはこちら
• AIが書いたコードを整理して育てる『リファクタリング』の実践術

関連原則 🔗

• 名前重要(Name is important)
• コンテキスト(Context)