ドメインとは？
ITでの意味とAI時代だからこそ重要な理由を図解！

1. ドメインとは？IT・プログラミングでの意味をまずやさしく整理

ドメインは「ソフトウェアが向き合うビジネス領域」

ドメイン（domain）とは、ソフトウェアが解くべき仕事・問題・ルールのまとまりです。ITやプログラミングの文脈では、画面やDBの話よりも先に、「このシステムは誰のどんな業務を扱うのか」を指します。

たとえばECサイトなら「商品・注文・在庫・配送・決済」、家計簿アプリなら「収入・支出・残高・月締め」のように、業務ルールや用語、価値の流れまで含めた世界観そのものがドメインです。

Webサイトのアドレスで使うドメイン名との違い

日常会話では「ドメイン」という言葉がURLやメールアドレスの話で使われることも多いですが、このページで扱うのは別物です。設計の文脈でのドメインは、システムが何を扱い、どう振る舞うべきかを決める土台を意味します。

このページで扱うドメインは、Webサイトのアドレスではなく、システムが向き合うビジネス領域のことです。ここを取り違えると、「意味は分かったつもりなのに設計へつながらない」状態になりやすいので、最初に切り分けておきます。

簡易まとめ

• ドメイン：ソフトウェアが向き合うビジネス領域
• 大事な理由：命名・責務分担・データの持ち方・例外処理まで左右する
• 混同注意：Webサイトのドメイン名とは別の意味
• AI時代：何を作るかを定義するドメイン理解ほど、人間の価値が上がる

2. なぜドメイン理解が設計・実装を左右するのか

ドメイン理解が浅いと、責務分担や命名がぶれやすい

ドメイン理解が浅いまま設計を始めると、同じ概念を「会員」「ユーザー」「顧客」と別々の言葉で呼んだり、本来は注文が持つべき責務を画面やバッチに置いてしまったりしやすくなります。

• 命名が揺れる
  用語の定義が曖昧だと、仕様書・会話・コードの間で別の言葉が混ざり、認識合わせに毎回コストがかかります。
• 責務の置き場所がずれる
  どこにルールを書くべきかが見えず、画面・コントローラ・SQLに業務判断が散らばりやすくなります。
• データの意味が薄くなる
  「金額」「状態」「締め日」などが単なる値になり、業務上の意味や制約がコードに残りません。

業務ルールを外すと「動くけれど合わない実装」になる

技術的には正しく動いていても、業務の例外ルールや禁止条件を外してしまうと、現場では使いにくい実装になります。たとえば「注文は確定後に取消不可」「支出には必ずカテゴリが必要」のようなルールは、UIの都合ではなくドメインの都合です。

この軸を外すと、AIも人間も「それっぽいけれど現場に合わない」コードを作りやすくなります。動くことと、業務に合うことは別なので、設計の最初にドメインをつかむ意味があります。

修正しやすさやシステム寿命まで変わる

逆に、「このシステムのドメインは何か」「どんな概念とルールがあるか」を整理できると、変更の影響範囲が読みやすくなり、アーキテクチャやモジュール分割の軸も安定します。

AI時代では特に、境界が明確なドメインほどプロンプトの文脈がぶれず、「仕様に沿って自然にコードが生える」状態を作りやすくなります。つまりドメイン理解は、保守性と生成精度の両方に効きます。

3. ドメインはどこからどこまで？境界の考え方を図で整理

ドメインは「画面」ではなく「業務上の意味」で切る

ドメインは、画面一覧やAPI一覧を並べただけでは見えてきません。切るべき単位は「商品管理画面」ではなく、「注文とは何か」「在庫引当とは何か」のような業務上の意味です。

同じ画面に表示されていても、意味が違えば別の境界で扱うほうが自然なことがあります。逆に画面が分かれていても、同じルールで動くなら同じドメインとして捉えたほうが設計は安定します。

アプリケーション層・インフラ層との違い

ドメインは「何を守るか」の層で、アプリケーション層は「どういう順番で処理するか」、インフラ層は「どう保存し、どう通信するか」を担います。ドメインを中心に据えると、技術都合の変更と業務都合の変更を切り分けやすくなります。

境界が曖昧だと何が起きるのか

境界が曖昧だと、例外ルールがあちこちへ漏れ、別コンテキストの用語が混ざり、AIに依頼したときも関係ないルールまで一緒に生成されやすくなります。境界づけは設計の整理だけでなく、AIの生成精度を保つための前提でもあります。

4. ドメイン理解・ドメイン知識・ドメインモデルの違い

ドメイン理解：何を解く世界なのかをつかむこと

ドメイン理解とは、「このシステムは誰の、どんな仕事や課題を扱うのか」をつかむことです。利用者、価値、例外、制約を含めて、世界観を把握する段階だと考えると分かりやすいです。

ドメイン知識：業務ルール・用語・例外条件を知ること

ドメイン知識は、その世界で使われる用語、業務ルール、例外条件、禁止事項を具体的に知っている状態です。「注文確定前だけ編集できる」「月締め後は修正方法が変わる」といった細部がここに含まれます。

ドメインモデル：知識を設計に落とした表現

ドメインモデルは、理解した知識をEntity、Value Object、ルール、状態遷移として設計へ落とした表現です。つまり、理解しただけではドメインモデルにはならず、コードや設計図に変換されて初めてモデルになります。

流れで言うと、ドメイン理解で世界をつかみ、ドメイン知識で細部を集め、ドメインモデルで設計にするイメージです。この3つを混同しないと、どこで詰まっているのかを判断しやすくなります。

5. 具体例でわかるドメイン：ECサイトと家計簿アプリで見る

抽象的なままだとつかみにくいので、既存の具体例を使って「何がドメインなのか」を見ていきます。

例1：ECサイトのドメイン

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

ECサイトで本当に設計を左右するのは、「注文はいつ確定するか」「在庫はどの時点で引き当てるか」「ポイントはどの条件で付くか」といった業務ルールです。ここが曖昧だと、画面をいくら整えてもコードの軸はぶれます。

例2：家計簿アプリのドメイン

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

家計簿アプリでも同じで、重要なのは見た目より「残高はどう増減するか」「月締め後の修正をどう扱うか」「予算超過をどう判断するか」です。データ管理に見えても、背後には業務ルールがあります。

同じ「データ管理」でもドメインが違えば設計も変わる

どちらも一見すると「データを登録して一覧表示するアプリ」ですが、守るべきルールも重要な用語も違います。つまり、同じCRUDに見えても、ドメインが違えば設計の中心は変わるということです。

6. DDD（ドメイン駆動設計）でドメインが重要になる理由

DDDは「ビジネスの複雑さ」を設計で扱う考え方

DDD（ドメイン駆動設計）は、ドメインを中心にソフトウェアを設計するための実践知です。目的は難しい用語を増やすことではなく、ビジネスの複雑さをコードで破綻なく扱うことにあります。

ユビキタス言語が設計と会話をつなぐ

DDDで特に効くのがユビキタス言語です。業務で使う言葉とコードの言葉をそろえると、会話・仕様書・実装がつながりやすくなり、用語ズレによる設計事故を減らせます。

ドメインモデルがコードの判断軸になる

Entity / Value Object / ドメインサービスといった表現は、その業務ルールをどこに置くかの判断軸になります。DDDそのものを完璧に導入しなくても、ドメインを中心に考えるだけで設計の迷いはかなり減ります。

8. AI時代の開発で、なぜドメイン理解がさらに重要なのか

最近は「AI駆動開発」という言葉も広がっていますが、実はAIで実装を速く進めるほど、「何を作るべきか」「どこまでを同じ責務として扱うべきか」を先に定める重要性が増します。つまり、AI駆動開発が進むほど、ビジネス領域を起点に設計するドメイン駆動の考え方は、むしろ再評価されやすくなるのです。

ユビキタス言語はAIへの指示精度を上げる

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

比較例（擬似コード）

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

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

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

ドメインモデルは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 を作る」前提で扱います。

課題発見と境界判断は人間の価値として残る

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

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

図解で見た境界づけが明確なほど、AIは別コンテキストのルールを混ぜにくくなります。ドメインを学ぶほど、AIに代替されにくい「課題設定力」と「意思決定力」が強くなります。

9. 実際に整理して感じた「ドメインレビュー」の迷いどころ

最初は、機能一覧を整理して画面ごとに責務を分ければ十分だと思っていました。ですが実際に詰まりやすかったのは、一覧に出てこない例外ルール、責務分担、用語の差分のほうでした。

特にAIにコード生成を頼むと、用語のズレがそのまま設計のズレになります。「会員」と「顧客」を曖昧にしたまま依頼すると、別のライフサイクルを持つ概念が1つのモデルに混ざりやすく、後からほどきにくくなります。

今は、機能の数よりも「どの例外が誰の責任か」「どこまで同じドメインとして扱うか」を先に確認するようにしています。ドメインレビューは大げさな儀式ではなく、設計のズレを早めに見つけるための会話だと捉えると進めやすいです。

もちもちみかんの体験談

実運用で特に感じたのは、最初に「機能がそろっていれば作れる」と見積もってしまう危うさです。実際には、注文の確定条件や、月締め後の修正ルールのような細部を詰めるほうが、あとからの改修コストに強く効きました。

AIに頼るほど、その差は大きくなります。曖昧なままでもコードは出ますが、あとから見ると「動くけれど、この業務には合っていない」実装が混ざりやすいです。逆に、用語・境界・禁止ルールが整理されていると、AIはかなり頼れる相棒になります。

FAQ：ドメインでよくある疑問

ドメインとはITでどういう意味ですか？

ITでいうドメインは、システムが向き合うビジネス領域のことです。Webサイトのアドレスではなく、業務ルールや用語、価値の流れを含んだ「扱う世界」を指します。

ドメインとドメイン知識の違いは何ですか？

ドメインは対象となる世界そのもの、ドメイン知識はその世界にある用語・ルール・例外条件についての知識です。対象と、その中身を理解した状態を分けて考えるイメージです。

ドメインとドメインモデルは同じですか？

同じではありません。ドメインは現実の業務領域で、ドメインモデルはそれを設計やコードへ落とし込んだ表現です。理解した内容をどう形にするか、という段階が違います。

ドメインとビジネスロジックはどう違いますか？

ビジネスロジックは、ドメインの中にある業務ルールを実装したものです。ドメインのほうが広く、ロジックだけでなく用語、概念、境界、価値の流れまで含みます。

AIにコード生成させるときもドメイン理解は必要ですか？

必要です。AIは「どう書くか」は得意ですが、「何を守るべきか」は与えられた文脈に強く依存します。ドメイン理解があるほど、プロンプトもレビューも精度が上がります。

まとめ：ドメインはビジネスと実装をつなぐ設計の根幹

ドメインは、Webサイトのアドレスではなく、ソフトウェアが向き合うビジネス領域です。そして、この理解が深いほど、命名・責務分担・データ設計・例外処理まで一貫しやすくなります。

AI時代でも重要性は下がるどころか、むしろ上がっています。人は「何を作るべきか」を定義し、AIは「どう作るか」を加速する。だからこそ、ビジネスと実装をつなぐドメイン理解が設計の根幹になります。

最近よく言われるAI駆動開発も、土台にあるのは「何を作るべきか」を定義するドメイン理解です。だからこそ今、ドメイン駆動の考え方が改めて見直されつつあります。

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

• [　] 誰の、どんな業務や課題を扱うシステムかを1文で言えるか？

  対象ユーザーと業務目的を短く説明できないと、設計の軸がぶれやすくなります。まずは「このシステムは何のためのものか」を言葉にしましょう。

• [　] 重要な用語が仕様書・会話・コードでそろっているか？

  同じ意味なのに呼び方がバラバラだと、人間同士でもAIとの協働でも認識ずれが起きます。ユビキタス言語をそろえることが設計の第一歩です。

• [　] 業務ルールとUI都合の処理を混ぜていないか？

  画面の見せ方の都合がドメインルールに入り込むと、仕様変更に弱くなります。「業務として正しいこと」と「画面上の都合」は分けて考えましょう。

• [　] 例外条件や禁止ルールがドメインとして整理されているか？

  正常系だけでなく、「こういう場合はできない」「この条件では無効」といった制約こそドメインの重要部分です。例外ルールまで含めて整理できているか確認します。

• [　] AIへの依頼文に「価値・用語・ルール・境界」を含めているか？

  AIはコードを書けても、ビジネス上の前提までは自動で補えません。何を大事にするのか、どこまでが責務かを依頼時に明示すると精度が上がります。

おみやげ：ドメイン整理用AIプロンプト

以下の業務内容をもとに、このシステムのドメインを整理してください。

- 主要な利用者
- 扱うデータ
- 守るべき業務ルール
- 発生する例外
- 重要な用語
- どこからどこまでを同じドメインとして扱うべきか

そのうえで、
1. ドメイン理解
2. ドメイン知識
3. ドメインモデル候補
4. アプリケーション層へ逃がすべき処理
5. AIに実装依頼する前に人が確認すべき点

を箇条書きで整理してください。

関連リンク

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

関連原則 🔗

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