1. 概念情報モデル

Date：2026/2/10 - Version 1.2.0

概念情報モデル  

概念モデリングで作成するモデルのことを、総称して”概念モデル”と呼びます。
概念モデルは、図やテキストで記述します。概念モデルを作成した人達の意図が第三者でも誤解なく理解できるように、モデルを構成する基本要素、および、図やテキストの記述方法にはある程度の厳密さで定義された決まりが必要です。
図による記述は、概念情報モデルの直感的な理解の促進や、対象領域全体を俯瞰する際に役立ちます。テキストによる記述は、詳細で厳密な記述を可能にし、IT技術活用による情報のデジタル化に寄与します。
本編では、図の表記は UML（Unified Modeling Language） を、テキストによる記述は YAML（YAML Ain‘t Markup Language） をベースにした記法を用いることにします。
以下、概念モデルの構成要素と記述方法を、概念モデリングの手順を交えながら解説していきます。

概念モデリングは、

• 概念情報モデル

• 概念振舞いモデル

  • 状態モデル

  • 状態のアクションを記述するデータフローモデル

• ドメインファンクション

  • 概念情報モデルに対する、操作に関するデータフローモデル

• インスタンスモデル

• ドメインチャート

からなります。
この記事では、最初の概念情報モデルについて、その意味と記法を解説していきます。

概念情報モデルは、モデル化対象の現実世界を記述するのに必要な語彙群に関する、意味的な構造を定義するモデルです。
システム開発において、”その対象は何か”を明確にすることは非常に重要です。”明確にする”とは、言葉を用いて、”その対象”を説明することです。その時、もし、その説明の中で使われている語彙の意味が曖昧であれば、”何を作るのか”定めることは不可能です。概念情報モデルは、開発対象に関する語彙の意味を、対象とする現実世界の意味的構造として記述する重要なモデルです。

概念情報モデルの構成要素

 概念情報モデルを構成する要素には、大きく分けて以下の三種類があります。

• インスタンスを分類して抽出した“概念クラス”（Conceptual Class）

• 概念クラス間の“関係”（Relationship）

• 概念クラスの特徴値（Property）

概念情報モデルは、ドメイン（主題領域）ごとに作成します。
概念情報モデルは、モデル化対象のドメインに現象する存在（インスタンス）群が従うべき意味の構造を定義します。概念情報モデルとインスタンスの関係は、”2．概念情報モデルを使う”で詳しく解説しているので、そちらをご覧ください。

ドメイン（主題領域）

 概念情報モデル作成の開始にあたり、まず、モデル化する主題を特定し、名前と概要説明を作成します。主題領域は、概念モデルを作成していく過程で理解が深まっていくものなので、作成開始時点では漠然としたもので構いません。名前は、例えば、“商品販売”とか“装置管理”などといったシンプルなものを選びます。  概要説明はモデルを作成するチームの各メンバーが、モデルを作成しようとしている主題について、漠然と頭に浮かんでいる場面や情報の流れ、処理手順、等々を絵（ラフなスケッチで構いません）に描いて相互に説明しあうなどしてメンバーの合意のもとに、モデル化対象を説明する簡潔な文章を作成します。YAML 形式では以下の様な記述で定義します。

domain:
    name: 主題領域名
      description: 説明文
      sketch: ラフスケッチの数々

繰り返しになりますが、概念情報モデルの開始時点では、チームメンバーが何をモデル化すればいいのかについて同じスタートラインに立つためのベースをつくることが目的なので、厳密な名前や説明文は必要ありません。モデリング作業が進むにつれて明らかになる様々な事項は、YAML の定義に追記していきます。作業中に描いたラフスケッチの数々も保存しておいて、上の YAML の定義で保存場所の URL を記録しておいて、モデリングの最中に参照できるようにしておくことをお勧めします。  

ドメインに関する詳細な定義は、”6．ドメインとITシステム構築”で解説しています。ドメインとは、マルクスガブリエルの新実在論で提唱される、”意味の場（Field of Sense）と同等です。この新実在論によれば、概念モデリングのモデル化対象である存在とは、ある”意味の場”において、その”意味の場”ごとの意味付けにおいて実在・現象するものであるとされています。
意味を伴なった存在（インスタンス）は、ある特定の意味の場で現象するわけですから、その意味の構造を記述する概念情報モデルは、必然的に、ある特定の一つの意味の場に対するモデルであることになります。

概念クラス 

モデル化対象の主題領域名が決まったら、主題領域を構成する概念群を抽出し、“概念クラス”を定義していきます。概念モデリングでは、モデル化対象の実世界に実際に存在する（物理的な存在だけでなく概念的な存在も含む）モノ・コト群に着目した後、それらを分類して概念クラスを定義します。
候補となるモノ・コトの対象は、建物や機器、果物、机、といった、実際に触れて目に見える物だけでなく、契約や販売、商品、組織、役割、ワークフローなど、数学や論理学、物理や化学の法則なども含め、人間が考えだした（あるいは発見した）実際には目にすることも触れることもできないような概念的なモノ・コト、など、頭に浮かべたイメージの中で、それぞれ指さして一つ一つ区別できるものであれば、なんでも構いません。
主題領域の定義で描いたスケッチ等をもとに一つ一つ区別できたり数え上げられたりするものをピックアップします。例えば、“商品販売”という主題領域では“商品”や“注文”などが該当します。これらは“インスタンス”の候補になります。抽出したインスタンス候補について、それぞれを特徴づける値をリストアップします。  
インスタンスの候補となるモノ・コトの対象は、建物や機器、果物、机、といった、実際に触れて目に見える物だけでなく、契約や販売、商品、組織、役割、ワークフローなど、数学や論理学、物理や化学の法則なども含め、人間が考えだした（あるいは発見した）実際には目にすることも触れることもできないような概念的なモノ・コト、など、更には、小説や漫画、映画などに登場する諸概念も含め、それらについて考えをめぐらして頭に浮かべたイメージの中で、それぞれ指さして一つ一つ区別できるものであれば、なんでも構いません。
値には、それぞれのインスタンスを区別するのに必要な “識別子的な値”と、それぞれの“特徴を表す値”の2種類があります。例えば、“商品”には、“商品コード”や“商品名”など、それぞれの商品を区別する値（二つ以上の特徴値が組み合わされる場合もあり）、 “値段”や、“色”、“形”、“購入者評価”、”温度”、”加速度”、”位置”、…、などといった商品の特徴を表す値群です。
リストアップした値それぞれに対して意味を考えて、適切な名前を付けてそれぞれの特徴値を定義します。
次に、抽出したインスタンス候補群を、モデル化対象の主題領域において、同じ意味を持ち、かつ、同じ特徴値のセットを持つものに分類し、その分類ごとに、モデル化対象の主題領域において適当と思われる名前を決め、”概念クラス”の候補とします。”概念クラス”の名前は、ほかの分類につけた名前とは異なるように決定します。  
概念クラスは、下図に示すルールで表記します。  

YAML による表記

domain: 主題領域名
  class:
    クラス名:
      description: 説明文
      property:
        特徴値名:
          datatype: データ型名
          description: 説明文
        ・・・

参考までに、“商品販売”という主題領域における“商品”と、“装置管理”という主題領域の“装置”を、各主題領域で抽出したクラスの例として挙げておきます。  

“商品販売”における“商品”

domain: 商品販売
  class:    商品:
      description: 販売対象
      property:
        商品コード:
          datatype: 商品コード
          description: 商品を一位に区別するための識別子情報
        商品名:
          datatype: 文字列
          description: 商品の通称
        在庫数:
          datatype: 正の整数
          description: 注文可能な在庫数
        単価:
          datatype: 金額
          description: 販売時の一個あたりの値段

“装置管理”における“装置”

domain: 装置管理
  class:    装置:
      description: 管理対象の装置
      property:
        装置ID:
          datatype: 装置ID
          description: 装置を一位に区別するための識別子情報
        温度:
          datetype: 温度
          description: 装置の槽内温度
        設置日:
          datatype: 日付
          description: 装置をプラントに設置した日付
        状態:
          datatype: 装置の状態
          description: 現時点での装置の状態
        稼働時間:
          datatype: 時間
          description: 設置から現時点までの稼働総時間

モデル化対象の主題領域が複数ある場合は、それぞれに同じ名前の概念クラスがあっても問題ありませんが、名前は同じでも、それぞれの主題領域ごとにその概念クラスが表す意味は全く異なります。

以上、概念クラスの描き方、定義方法を解説しました。  モデル化対象の主題領域から、インスタンスをリストアップし、全てのインスタンスに対して、

• インスタンスに対応する概念クラスがあるか？

• ある場合、対応する概念クラスの特徴値が全て意味を持ち、具体的な値を持つか？

の二点を確認します。一番目の、対応する概念クラスが無い場合は、そのインスタンスの意味を吟味し、新たな概念クラスの候補（名前と特徴値のセット）を抽出します。二番目の場合は、特徴値が適切か見直す、または、本来複数の概念クラスとして抽出するべき分類が一つの分類にごっちゃになって抽出されている可能性があるので、特徴値が意味を持つインスタンス群、持たないインスタンス群に分けて適切と思われる概念クラスの再抽出、整理を行います。抽出した概念クラスの妥当性の検証は、次に説明する関係の抽出・定義作業の間も含めて、概念情報モデルの完成まで続きます。  
概念情報モデルは、その都度様々に構成が変わるインスタンス群ではなく、それらを分類したもの＝概念クラスを使って作業を進めます。この点は非常に重要なので、概念モデリングでは、今扱っているのは、インスタンスの話なのか、概念クラスの話なのかを常に意識することが必要です。オブジェクト指向プログラミングに精通した読者であれば、“概念クラス”と“インスタンス”の関わりは、オブジェクト指向言語の“クラス”と“インスタンス”の関わりと同じと説明すれば納得いただけると思います。ただし、概念モデリングにおける“概念クラス”は、オブジェクト指向の“クラス”ライブラリとは似て非なる別物と思って読み進めてくことをお勧めします。それを踏まえ、以下は敢えて、“概念クラス”、“インスタンス”という言葉は煩雑なので、単にそれぞれ、“クラス”、“インスタンス”という言葉を使う事にします。また、これまで使ってきた“主題領域”も簡便のため、今後は、“ドメイン”と記すことにします。

関係（Relationship）

概念モデリングでは、モデル化対象のドメインは、抽出されたクラスの定義に従って存在するインスタンス群から構成されると考えます。各時点で存在するインスタンスは別のインスタンスと意味的なつながりを持ちます。  
例えば、“販売管理”という主題領域（ドメイン）で、“注文”、“顧客”、“商品”というクラスがあるとして、ある“注文インスタンス”は、“誰が注文したか”という意味において、”顧客インスタンス“のどれかとつながっているでしょうし、”何を注文したか“という意味において、”商品インスタンス“のどれかとつながりを持っています。このようなインスタンスの間のつながりを”リンク”と呼ぶことにします。
このような、異なるクラスを雛形にしたインスタンス間の“意味的なつながり”を、概念クラス間の“関係（Relationship）”として定義します。  
“関係”は、ドメインが扱うシナリオやアイデアスケッチ等を元に、二つのクラスの間で定義します。  
名前が“A”と“Ｂ”という二つのクラスがあるとします。“Ａ”のインスタンスから見た“Ｂ”のインスタンスの“関係”は、- そのつながりの“意味”を表す簡潔なテキスト  - つながっている“Ｂ”のインスタンスの個数  
つながっているインスタンスの個数は、“多重度”と呼びます。  “Ａ”から見た“Ｂ”の“意味”と“多重度“と、逆方向の“Ｂ”のインスタンスから見た“Ａ”のインスタンスの“意味”と“多重度”を合わせたものが、“Ａ”と“Ｂ”の間の“関係（Relationship）”の定義です。図で描くと下図のようになります。

YAML による表記

domain: 主題領域名
  class:
    ・・・
  relationship:
    関係名:
      description: 説明文
      Aのクラス名:
        meaning: シンプルな意味のテキスト
        multiplicity: 0|0..1|*|1...* のどれか
      Bのクラス名:
        meaning: シンプルな意味のテキスト
        multiplicity: 0|0..1|*|1...* のどれか
    ・・・

クラスや特徴値に名前を付けたように、“関係”にも名前を付けておくと便利なので、それぞれの“関係”に対して、ドメインで重複しない名前を決めます。“関係”は、その両端のクラス、意味、多重度で、それがどんなつながりを意味するのか明確に定義されているので、単なる記号的な名前で構いません。テキスト表記の場のみ明記し、図表記の場合は必要なければ記載しなくても構いません。

関係（Relationship）の両端に付与する”意味の記述”は、一般的なデータモデリング技法では全くと言ってよいほど無視されています。しかし、対象とするドメイン（意味の場）の、意味の構造の定義には、この”意味の記述”のとても重要な記述であり、決しておろそかにしてよいものではありません。この記述こそが、モデルに記述された語彙群の意味を定めるものであり、この記述がなければ、モデルに散在する語彙の意味は定まらず、そんなモデルは意味不明な無意味なモデルであるというのが、概念モデリングの見解です。

多重度

 二つのクラスの、片方のインスタンスにつながるもう一方のインスタンスの数は、モデル化対象によって千差万別ですが、これまでの経験から、以下の4種類のうちからどれか一つを選択して定義すればよいことが実用上問題ないことが判っています。
1. ”1”  片方のインスタンスがある場合、かならず、もう一方のインスタンスが1個だけ必ずある
2. ”0..1”  片方のインスタンスがある場合、もう一方のインスタンスはない場合もあるが、つながりがある場合は1個だけしかない
3. ”1..*”  片方のインスタンスがある場合、もう一方のインスタンスは1個以上ある
4. ”*”  片方のインスタンスがある場合、もう一方のインスタンスはない場合もあるが、つながりがある場合は複数ある

  関係の多重度に、2 や 3 といった 1 より大きい特定の数の場合もあるのではないかと不思議に思う読者もいるかと思いますが、それは参考にしている状況が偶々そういう値になっていたり、システムの実装上の制約でそうなっているケースが大半です。そうでない場合は、概念モデリング的には、例えば3の場合、ドメインの文脈において、その3つそれぞれに別の意味が見つかることがほとんどです。概念情報モデルを使ったインスタンス構成の自由度を確保する意味でも、上にあげた4種類の多重度のみでモデル化しましょう。  
参考までに、多重度の組合せの一覧を図に示しておきます。

関係は一つのクラスに対して定義することもできます。例えば、何かが順番に並んでいるような事柄をあらわしたいなら、以下のような関係の定義が可能です。

 関係クラス

モデル化対象のドメインには、あるクラスのインスタンスが存在するために二つのクラスを雛形にしたインスタンスが必要なコトや役割があります。例えば、“商品販売”では、“注文”というクラスのインスタンスには、“顧客”クラスと“商品”クラスのインスタンスが必要そうだというのは直感的に間違っていなさそうです。“注文”クラスのようなクラスを、“関係クラス”と呼びます。表記法は以下の通りです。

YAML による表記

domain: 主題領域名
  class:
    ・・・
  relationship:
    関係名:
      description: 説明文
      Aのクラス名:
        meaning: シンプルな意味のテキスト
        multiplicity: 0|0..1|*|1...* のどれか
      Bのクラス名:
        meaning: シンプルな意味のテキスト
        multiplicity: 0|0..1|*|1...* のどれか
      class:
        関係クラス名:
          description: 説明文
          property:
            特徴値名:
              datatype: データ型名
              description: 説明文
        ・・・

例で挙げた、“顧客”、“商品”、”注文“のインスタンスのスケッチとクラスモデルを参考までに図示します。

関係クラスの場合も、両端の多重度は16種類です。念のため、全ての種類をリストアップしておきます。

16種類のうち、0..1、*のように関係する相手方のインスタンスがない場合の多重度を持っている場合、ある特徴値のセットを持つ新たな意味のクラスが抽出可能なことが多いので留意しましょう。

関係クラスを雛形にしたインスタンスは、その関係クラスが点線で紐づいている関係（Relationship）を雛形にしたインスタンスをつなぐリンクと1対1に対応します。モデル化対象の主題領域において、リンクに紐づく値がある場合や、そのリンクが単なる切り貼りではなく、振舞モデルの章で説明する様なダイナミクスを伴っている場合に定義します。

 ”is-a”

概念クラス、概念クラス間の二項関係、関係クラスまでは、リレーショナルデーターベースを設計する際に行う、リレーショナルセオリーに基づいた、ER図（Entity Relationship Diagram）で行うモデルとほぼ同じです。しかし、現実の世界は非常に複雑であり、複雑な主題を可視化するためにもう一つの武器を追加します。次の図に示すような関係の定義です。  

”is-a”の関係（Relationship）は、上図の P、C1、C2 について、

• C1 is a P

• C2 is a P

という述語表現が可能です。

YAML による表記

domain: 主題領域名
  class:    クラス名:
      is_a: [,で区切ったスーパークラスの名前のリスト]
      description: 説明文
      property:
        特徴値名:
          datatype: データ型名
          description: 説明文
        ・・・

オブジェクト指向プログラミングに精通していればしているほど混乱しそうなので、継承（Inheritance）や実装（realize）、多態（Polymorphism）といった概念は一旦忘れてくださいね。  
図に示したモデルの、△の頂点が接している“P”クラスを“スーパークラス”、△の底辺から伸びた線が接している“C1”、“C2”クラスを“サブクラス”と便宜上呼ぶことにします。このような関係がある場合、以下のような意味を表します。

• サブクラスのインスタンスが１つ存在する場合、必ず対応するスーパークラスのインスタンスが1つだけ存在する。

• スーパークラスのインスタンスが１つ存在する場合、関係でつながっているサブクラスのうちどれか１つのクラスのインスタンスが１つ存在する

図に示したモデルの場合は、

• C1クラスのインスタンスが１つ存在する場合、対応するPクラスのインスタンスが必ず1つだけ存在する。C2の場合も同様

• Pクラスのインスタンスが１つ存在する場合、C1かC2どちらかのクラスの対応する1つのインスタンスが必ず存在している

という解釈になります。  
若干数学風に言えば、“概念クラス”は“集合”で、“インスタンス”はその集合に属する“要素”です。この関係は、スーパークラスが“全体集合”、サブクラスが“部分集合”でかつ、その全体集合に属する要素は、必ず、どれかの部分集合の要素ですよ、という定義です。  
図中の△と線の付近に“{complete, disjoint}”と書いてあるのが、この制約を明記するUML風の呪文です。  
誤解のないように、ちょっとだけくどくて詳細な説明をしましたが、世の中、大体同じでちょっとだけ違うモノやコト、役割は山ほどあります。”is-a”の関係はその様なモノ、コト、役割を分類し明記するための道具です。

概念情報モデルにおいては、  
「モデル化対象のドメインにおいて、完全に同じ意味を持ち、同じ特徴値のセットで特徴づけられ、かつ、他のインスタンスと同じ関係を持つ」  
ことが、“インスタンス”が同じ”であることの条件です。概念モデリング中に抽出したインスタンス群から概念クラスの候補を抽出し、関係を定義していく過程で、

• 一部のインスタンスはいくつかの特徴値を持たない、あるいは、別の特徴値を持つ

• 一部のインスタンスだけが、別の概念クラスのインスタンスと関係を持つ

ような場合に遭遇したら、”is-a”の関係を使って、概念クラスを新たに抽出していきます。主題領域によっては、あるクラスが複数のスーパークラスのサブクラスになることも当然あり得ます。

概念情報モデルのクラスの特徴値と関係の抽出においては、この”is-a”の関係と、リレーショナルセオリーの正規化をベースにしています。これらは、モデル化対象のドメインに対して、クラスやその特徴値、関係の適切な抽出されているかを判断する手段の一つです。以上で、概念モデリングで扱う、全ての”関係“が出そろいました。  念のために加えておきますが、関係を定義できるのは、同じドメインのクラスの間だけです。

”インスタンス”が”概念クラス”を雛形として定義されるのと同様に、”リンク”は”関係（Relationship）”を雛形に定義されることになります。ひとつの”リンク”が存在する時、その両端には必ず、それぞれ一つづつの”インスタンス”が、”関係（Relationship）”の両端に定義された”意味”で存在します。関係クラスが定義されている場合には、その二つのインスタンスに加えて、更に、その関係クラスのインスタンスが一つ存在することになります。
主題領域（ドメイン）のコンテキスト、シナリオは、モノ（インスタンスに相当）が存在するだけでは意味を成しません。モノとモノの間に存在するリンクがあって初めて、コトや役割を示すことができます。概念情報モデルは、一見すると、”概念クラス”が主役に見えますが、現実世界の理解には、むしろ、関係（Relationship）の方が重要なので、”概念クラス”の抽出と同様、”関係（Relationship）”の抽出も気合を入れて行わなければなりません。

特徴値

概念クラスの抽出で、特徴値には、“識別子的な値”と、それぞれの“特徴を表す値”の二種類があると説明しました。ここでは更に特徴値について更に詳しく解説することにします。特徴値は、その変数名と存在しているインスタンスごとにその時々の値を持ちます。変数がどんな値をとりうるのかの定を“データ型”と呼びます。  モデル化対象のドメインで扱う“データ型”を定義することも概念モデリングの重要な作業の一つです。概念モデリングの過程で、様々なデータ型の、“名前”、“値域”を明らかにし、“概要説明”を加えて定義していきます。データ型の“名前”は、クラスの名前と同様、ドメイン内で重複しないように名付けていきます。  
データ型には、“単純型（Simple Type）”と“複合型（Complex Type）の二種類があります。  
まずは、“単純型”です。“単純型”は、“数”、”文字列“、”列挙“の3種類のうちのどれかで定義します。

数

数は、1個、２個、3個、…、1番目、2番目、3番目、…といったように数えられるもの、いわゆる、自然数や負の数も含めた整数（integer）と、28.32℃、52.81km/hといった実数（real）の、二つに分類されます。数の単純型の定義では、“種別”（整数|実数）と“単位”、そして、最小値や最大値がある場合は、“値域”として明確に定義します。

文字列

文字列は、英数字や記号文字の連続した並びです。特徴値の値として使われる文字列において任意の並びの文字列もあつかうことも当然ありうるわけですが、概念モデリングにおいては、それぞれのクラスの特徴値の意味に基づいたある特定のパターンの並びを持つものが多いです。例えば、“顧客”の“名前”は、“姓” と “　”（空白文字）と“名”（あくまでも日本人の名前を扱うドメインの場合だけですが）というパターンだったり、”商品“の”商品コード“であれば、その会社で決められた特定の英数字のパターンになっているはずです。  文字列の単純型の定義では、その文字列のパターンを、正規表現や、プロトコル構文規定言語のASN.1などを使ってパターンを明確に定義します。

列挙

例えば、装置の状態が、“電源OFF”、“初期化中”、“稼働中”、“テスト実行”、“故障中”の5つの中のどれかの値をとるといったような、それぞれの項目がドメイン内で明確な意味を持つ複数の項目のうちのどれか一つを値として持つようなデータ型を“列挙型”と呼びます。列挙は、それぞれの項目の名前と意味を定義したリストで定義します。

繰り返しになりますが、特徴値のデータ型は、“名前”、“概要説明”と、数の場合は、「“種別”、“単位”、“値域”」、文字列の場合はパターン、列挙の場合は、項目名と意味のリスト、により定義します。定義されたデータ型は、モデル化対象のドメインのあるクラスの特徴値と別の特徴値のデータ型がそのドメインにおいて同じ意味を持つならば再利用してかまいません。  しかし、同じように見えてもそのドメインにおいて意味的に異なるようなら、面倒くさがらずに別のデータ型として定義することをお勧めします。

真偽値型

論理演算に出てくる、“真(True)”か、“偽(False)”の値をとる型です。

複合型

次に複合型です。複合型は、複数の、単純型の変数、または、あらかじめ定義された複合型の変数からなるデータ型です。例えば、一般的な加速度センサーは3軸であり、一度に“距離/時間の二乗”を単位とする、x方向、y方向、z方向の3つの実数から構成されていたり、地球上の位置は、角度を単位とする、緯度、経度の二つの実数から構成されている、といったような変数は、単純型の変数に分割してしまった場合意味を失ってしまいます。この様な特徴値は組として扱うのが妥当です。複合型は、“名前”と“概要説明”、“構成する下位のデー型名のリスト“で定義します。

これは見ようによっては、リレーショナルセオリーの一次正規化のルールに反するように見えないこともないですが、加速度や角速度など同じセンサーである時点で複数の値を計測するようなものや、位置等はもともとひとまとまりにして意味がある値なので、一つの組の値として扱うほうが自然でしょう。  ただし、あまり複合型を定義しすぎると、本来概念クラスとして抽出すべきものまで複合型にしてしまう恐れがあります。概念情報モデルの作成中は、なるべくなら、複合型は単純型のデータ型のみで構成されるものにとどめておくことを推奨します。
データ型の定義は、テキストのみで記述します。 

YAMLによる表記

domain: 主題領域名
  datatype:
    データ型名:
      description: 説明
      schema: integer, real, string, enum, boolean のどれか、もしくは、複合型の場合は構成するデータ型をリストで定義
      unit: 数の場合、その単位名
      domain: 数の場合、その値域
      pattern: 文字列の場合、その正規表現や構文木
      enumvalue: 列挙の場合その値の名前と説明文のリスト

クラスの特徴値には、以下で説明するような特殊なものがあります。クラスや関係の抽出の際、意識してモデリング作業を進めましょう。

識別子の意味を持つ特徴値

クラスの個々のインスタンスを区別するような“識別子的な値”で、モデル化対象のドメインにおいて明確に意味を持つような場合には、何らかの慣例に基づく英数字と記号で構成された一定のパターンの文字列が決められていることが多いです。一方で単に区別できればよいというような識別子的な特徴値の場合は、あえてその特徴値向けのデータ型を定義する必要はありません。識別子の意味を持つ特徴値を図で表す場合、その特徴値の名前の先頭に”*”を付けます。テキストでの定義の場合は、それが識別子であることを明記します。

概念クラスによっては、複数の特徴値が組み合わさって、インスタンスの一意性を表現する場合があります。更には、インスタンスの一意性を表現する複数の特徴値の組を持つ概念クラスも存在し得ます。その様な場合は、”*1”、”*2” の様に添え字をつけて区別できるよう定義を行います。

計算可能な特徴値

抽出した特徴値の中には、あるクラスの特定のインスタンスを起点にして関係でつながったインスタンスの数や、そのインスタンス群の特徴値から算出できる値を持つものがあります。これらを“計算可能な特徴値”といい、図で表す場合は、特徴値の名前の後ろに“(M)”をつけ、テキストの定義の場合は、算出方法を記載します。

関係を表す特徴値

クラスと関係の定義による制約のもとにインスタンスをリスト表現する場合、後で詳しく説明するように、便宜的に関係している他のインスタンスを示すための特徴値が必要になる場合があります。リレーショナルデータベースに詳しい読者であれば、外部キーと同等といえば理解できるでしょう。
この様な特徴値は、概念情報モデルの図表現においてはクラスの特徴値として記載しなくても判るので、不必要です。
しかし、存在するインスタンス群の全特徴値を表形式で表現する場合には、どのインスタンスと、どのインスタンスがリンクされているのかを示す値が、必ず必要になります。そのため、ここで解説している概念モデリング体系においては、そのようなリンクの値を保持する為の特徴値を概念クラスに明示的に定義し、特徴値の後ろに“(R)”をつけることにします。
このような特徴値を、”参照特徴値”と呼ぶことにします。前のセクション”概念クラス”では、特徴値は2種類と説明しましたが、”参照特徴値”が加わるので、結果的には3種類という事になります。
 関係を表す特徴値のデータ型は、“参照型”で、関係でつながっている相手のクラスの識別子と同じ型になります。また、相手側の多重度が、“0..1”の場合は、インスタンスのリンクがない場合があるので、リンクがない場合はNULLとします。
参照特徴値は、多重度によって、どちらの概念クラスに定義するかが変わります。以下に全ての多重度に関する参照特徴値の定義側を列挙しておきます。

NULL許容の特徴値

“関係を表す特徴値”は、リンクがない場合はNULLであると説明しました。場合によっては、他の型を持つ特徴値の値が主題領域の状態によって意味を持たない時がでてきます。その様な状況がモデル化対象主題領域であり得る場合は、その特徴値が、“NULL許容(Nullable)”であると定義します。  参考までにこれらの特殊な特徴値の表記法を紹介しておきます。

YAMLによる表記

domain: 主題領域名
  class:
    クラス名:
      property:
        プロパティ名:
          description: 説明
          unique: true  # 必ず異なる値を持つ場合
          relationship: 関係名  # 関係を表す特徴値の場合
          mathematical: 計算式  # 計算可能な特徴値の場合
          nullable: True|False　# NULL許容な特徴値の場合はTrue

概念情報モデルのまとめ

 以上で、概念情報モデルを構成するための全てのピースが登場しました。復習もかねて、ここでそれらを列記しておきます。  - “ドメイン”- ドメインを構成する“クラス”- “クラス”を雛形にしたインスタンスが持つべき特徴値のセット- クラスを雛形したインスタンス間が満たすべき、意味と多重度が定義された“関係”- 特徴値の“データ型”  
モデル化対象を吟味してこれらを抽出し明確に定義していく過程を“概念モデリング”といい、成果物が“概念情報モデル”になるわけです。  物事を分析してその本質を抽出することを抽象化といいますが、概念モデリングでは二段階の抽象化を行います。  
一段目の抽象化は、皆さんのビジネスにおいて、様々な、モノ、コト、役割といった、その時々の状態や時間の経過に従ってどんどん変化していくインスタンスとインスタンス間のつながりの抽出です。二段目の抽象化は、抽出したインスタンスとインスタンス間のつながりが存在する際の従うべきルールの抽出です。多くの人にとって概念情報モデルが難しいと感じさせる理由が、この二段階の抽象化にあるように思えます。何かを構築する場合、なるべく安定していて変化しにくいものを基盤として使うというのは非常に重要なことです。一段階目の抽象化の結果が時間とともにどんどん変わっていく非常に不安定であるのに対して、二段階目の抽象化はとても安定しています。概念情報モデルの作成は、ビジネスシステムを構築する為の安定した基盤造りであるともいえるでしょう。  
ソフトウェアエンジニアリングにおいて、“抽象化”はよく使われる用語ですが、多くの人が“抽象的”という言葉と混同しているように思えます。“抽象的”の反対語は“具体的”なであり、“抽象化”というと曖昧な記述というイメージを持ってしまいがちです。“抽象化”の元の英語は、“Abstraction”であり、この訳を調べると、“抽出”という意味があり、実は“抽象化”は“抽出”の誤訳なのではないかと、筆者は長年考えています。“抽象化”の反対語は“具象化”です。特に本稿での概念モデルの作成の目的は、ビジネスをデジタルトランスフォーメーション可能なシステムを開発するための基盤を構築することなので、曖昧なモデルをなんとなく作るのではなく、ビジネスで扱う様々なエンティティをもれなく抽出し、厳密なモデルを構築することが重要なのは言うまでもありません。  

ここまでで、読者は二つの疑問を持つのではないでしょうか。  
一つ目の疑問は、“概念情報モデルはいつ完成するのか？”だと思います。これはモデル化対象のビジネスに関わるステークフォルダー達の頭で思い描くビジネスの描像に登場するモノやコトが全て概念情報モデルで定義したルールに従って配置できたとき、が回答になります。  加えて、概念情報モデルを作成しているプロジェクトに関係する全員が、配置できたことを合意していなければなりません。

二つ目の疑問は、“複雑怪奇な現実の世界を、こんな簡単な道具立てで本当に定義できるのか？”だと思います。
詳しくは、玉石混交のコラム集の、

• モデリングとは ～ 現象学からの考察

• 概念モデルの言語論理学からの考察

を読んでいただきたいのですが、人間が、現実世界を対象として、明確かつ明晰な論理を思考するには、まず言葉が必要だということが出発点になります。言葉は語の連なりです。語を連ねて現実世界を記述すると複数の文ができあがります。文は、語が適当に連なったものではなく、主語と述語、形容詞、副詞から構成される文法に基いて語が並べらています。皆さんご存じの通り、語は、多義性を持っています。ウィットゲンシュタインなどの言語哲学によれば、文の意味は、意味が確定した語が文脈に従って並んでいるから確定するのではなく、文脈において語と語の関連において決まるだけでなく、さらには、文全体、もっと言えば、使用可能な語と文法からなる言語全体から決まるものだとされています。
一方、概念情報モデルは、語を、以下のような、概念情報モデルの文法によって関連付けていきます。

• 名前（語）を持ち、かつ、単位や値域が紐づけられた、データ型

• データ型によって規定される名前（語）をもった特徴値

• 特定の特徴値の組で状態を記述する、名前（語）をもった概念クラス

• 双方向で、多重度と意味（語、あるいは、語の連なり）を持って、二つの概念クラスを紐づける関係（Relationship）

これらの道具立てにより、語と語の間の関連を記述するという、人間が言葉によって思考を巡らしながら記述していくのと本質的に同等な流れで、自然文で書いた文章よりも、厳密、かつ、複数の文の関連も明確な記述を可能とします。
そもそも、人間が現実世界を記述することにおいて、人間の思考パターンを超えることはできません。これらの事実を合わせれば、

• モデル化対象となる、複雑怪奇な現実の世界を、人間の思考可能な範囲で記述できるならば、概念情報モデルの道具立てで十分である

と考えて良いでしょう。
ものを主体に抽出するモデリングにおいては、モデル作成者は概念クラスに相当するようなものの抽出に注意が行きがちです。しかし、ここに書いたように、概念クラスは、紐づけられた特徴値の組と関係（Relationship）があって初めて意味をなします。曖昧な語で名前が書かれた四角形と両端に何も書かれていない線を描いただけでは、概念情報モデルを作ったことにはなりません。語の意味が、語と語の関連で確定するのであれば、概念情報モデルの主役は、概念クラスではなく、むしろ、関係（Relationship）であると感がながら、概念情報モデルを作成するとよいでしょう。

概念モデルは、モデル作成者が「私はこのビジネスをこう理解しましたよ！」という表明です。一つ目の疑問に対する回答を基準にして、自信をもって表明しましょう。

普通の開発で作られる仕様書との関係

ソフトウェア開発においては、要求仕様書など、いわゆる”仕様書”と呼ばれるドキュメントが作成されるものです。それら一般的な仕様書と概念情報モデルの関係について、補足しておきます。

仕様書では、そのソフトウェアが何を対象としたもので、何をなすのかが書いてあるはずです。そこでは、様々な単語、語彙があふれている事でしょう。そして、それらの単語、語彙の意味は何なのかが記載されていなければ、そんな仕様書はその後の工程では何の意味もなさないので作るだけ無駄だということになります。

では、単語、語彙の意味を定義するにはどうしたらよいでしょう？
ご存じの通り、言葉とは多義的なものであり、あなたが、ある単語に込めた意味を、別の誰かが正しく咀嚼してくれる保証は一切ありません。
別の誰かには、その単語を含む文章を書いたあなたの三か月後も含まれます。
仕様書の内容を誤解なくみんなで共有するためには、単語や語彙の意味を実用レベルで明確に記述しておかなければなりません。そのためには、

• 意味の場ごと（一般的には視点・観点とも呼ばれる）に分割

• 概念の名前、その概念が備えるべき特徴値、概念間の意味的つながり

という基本構造が結果的に必要になるわけです。この基本構造を基にした記述、それが概念情報モデルです。

日本語の特性もありますが、日本語の自然文で書かれた文章は、分類の話（概念クラス）なのかインスタンスの話なのか、関係する概念は一つなのか複数なのか、など曖昧になりがちだし、厳密に書こうとすると、とんでもなくくどい文章になってしまうものです。
いらぬ苦労をするよりも、素直に概念情報モデルを描くことをお勧めするのは、そんな理由からです。

とはいえ、概念情報モデルをみんなが読めるわけではないので、自然文で書かれた仕様書が必要だという人も多くいることと思います。
概念情報モデルに描かれた内容から、

• 概念クラスと、その特徴値の組

  • 概念クラスの名前

  • その名前が指す分類・概念が備えるべき特徴の羅列

• 概念クラス間のリレーションシップ

  • 一方の概念クラスの名前、他方の意味の記述・多重度、他方の概念クラスの名前から機械的に生成された述語文

  • 逆も同様

と、文章に変換していけば、自然文で書かれた文章による仕様書が自動的に得られます。これは、”変換による実装”を活用すれば、アプリケーションとして実装できるので、そんな環境を用意して、読みたい人に提供すれば十分でしょう。
もちろん、あなたが描いた概念情報モデルが妥当であることが前提条件ではありますが。

最近では、生成系AI にモデル図を読み込ませて、問い合わせれば、知りたいことを教えてくれるようにもなっているので、活用するのも良いでしょう。

概念情報モデルの基礎付けについて

哲学的な観点からの基礎付け

概念情報モデルは、モデル化対象のドメイン（意味の場）の意味の構造を記述するための道具です。
あなたが、あなたしか知らないモノを他の人に説明して理解してもらう場面を考えてみましょう。
その時、そのモノを対象として、

• その対象が持つ、一つ、あるいは複数の特徴

• その対象に関連する何か別のモノとの関係

について語って説明するのが自然な流れなのは間違いありません。更に、そのモノに名前があるならば、その名前にも言及するでしょう。また、その対象に関連するモノとして挙げられた別のモノが、説明を受けている人にとって未知のモノならば、その未知のモノを対象として、上の二つが語られていくことになるでしょう。そうして、モノの特徴とモノ間の関係というネットワークモデルが出来上がることになります。
この形式が、モノの意味を説明する、難しく言い換えれば、モノの意味の構造を記述する、基本形式です。
こうして出来上がったネットワークモデルで記述されたモノの特徴・モノ間の関係が、概念情報モデルをひな型（スキーマ）として、モデル化対象のドメイン（意味の場）に存在する対象群を記述したモデル（インスタンスモデル、と仮に言っておきましょう）に相当します。

ここで、もう一度、あなたしかしらないモノを、それを何か知らない別の人に説明している過程を振り返ってみましょう。
あなたが知っていた、その対象の特徴や、その対象が別のモノと関連している、という知識は、あなたの理解において、そのモノを見た時点で考え出したものでしょうか？また、先程、”名前があるならば、その名前にも言及する”と例示しましたが、その”名前”とは何なのでしょう。
説明しようとしている対象が、”ハチ”という”犬”だったとします。この場合、

• ハチ ⇒ 対象となっている犬の名前

• 犬 ⇒ その対象の分類名

なのは明らかです。”ハチ”という”犬”について、説明する際、その対象に関連するものとして、”誰が飼い主か”に言及する可能性は高いでしょう。
この関連に関する言明も、”飼い主”という分類と、その誰かを指す”人の名前”という、犬の場合と同じ形式で構成されています。
日常的な会話では、説明する対象そのものと、その対象の分類とが明確に分けては語られてはいないのが一般的です。それが明確でないがために、たまに誤解が生じたりもするでしょう。

この、対象となっている”モノそのもの”と、”その分類”を明確に区別して、あなたの説明しようとしたときの、あなたの心のうちに分け入ってみると、

• 説明の対象となっている”モノ”が属している”分類”の名前

• その”分類”に属するモノならば共通に持っているはずの特徴群

• その”分類”に属するモノならば共通に持っているはずの別の”分類”に属しているモノとの関連

という物差し（スキーマ）を使って、説明していることになるでしょう。
ここまで、ハチという名前の犬の例を使って説明してきましたが、説明対象が、例えば、税金とか、売上という一般的な概念＝分類を対象にして説明する時も、全く同じ形式になります。
また、税金や法律、規則など、小難しい概念を理解する時のことを思い浮かべてください。
この時、ある分類と別の分類が持っているとされる関連において、片方の分類に属するモノにとって、関連する別のモノがどんな意味を持っているのか、だけでなく、その別のモノが存在することが必須なのか、必須ならば、それは、ただ一つなのか少なくとも一つなのか、複数あるのか、によって、その対象の意味合いが大きく違ってしまうでしょう。

あるモノを対象とし、それがなんであるかを”分類”のレベルで、他者に説明する場合には、これらの言明が必要であり、それらが、対象とするドメイン（意味の場）の”分類のレベルにおける意味の構造を記述する基本形式になるわけです。
そして、この基本形式をモデルとして記述したものが、”概念情報モデル”である、ということになります。

• 概念クラス

  • 分類の名前

  • その分類が持つべき特徴値の組

• 関係（Relationship）

  • 分類と分類の間の、双方から見た意味的つながりに関する記述

  • 双方から見た多重度

この辺りのトピックについて詳しく知りたい方は、“玉石混交コラム 8. 概念モデルの言語論理学からの考察 ～ Frege、Russel、Wittgenstein｜Knowledge & Experience”をご一読ください。

特徴値について、付け加えておきます。
また、ハチという犬に登場してもらうことにします。
ハチは、茶色い毛色をしていて、中型犬、犬種は柴犬だったとしましょう。
この時、”犬”という分類（概念クラス）を定義すれば、この分類に相当するモノは、以下の特徴値の組でその特徴が示されるものであり、

• 毛色

  • ハチの毛色は茶色である

• サイズ

  • ハチのサイズは中型犬である

• 犬種

  • ハチの犬種は柴犬である

対象となるハチは、全ての特徴値が決まっていることになります。
ここで、”毛色”という特徴値が”茶色”だということについて考えてみましょう。あえて、”ハチ”の”毛色”が、”茶色”だということは、”犬”の分類に属する対象の”毛色”は、白や黒、薄ピンクなど、他の色の値もあることを暗示していることになります。しかし同時に、緑やラベンダー色の犬は遺伝学的にはいないようですから、他の色はあれど、全ての色が許されているわけではなく、”毛色”として指せる色にはある一定の範囲があることになります。その他の特徴値の”サイズ”、”犬種”についても同様なことが言えるのは間違いないでしょう。
以上から、

• 分類（概念クラス）が備えるべき特徴値（の組）は、変数である

• その分類（概念クラス）に属する対象（インスタンス）は、その変数の値が確定している

• 変数がとりうる値は一定の制限がある

であると言えることになります。変数がとりうる値に対する一定の制限を規定するものが、概念モデリングでは、”データ型”と呼ばれるものに相当します。

また、説明対象を説明する時の意味付けは、ドメイン（意味の場）に立ち現われた存在に対してなされているので、ある特定のドメイン（意味の場）に対してのみ、意味の構造の形式による記述が成り立つことになります。言い換えれば、意味の構造の形式による記述は、それぞれのドメイン（意味の場）ごとに行う必要があるということです。

本稿で解説してきた概念情報モデルは、これまで述べてきたような我々人間が普段行っている思考の流れを、以下の哲学的言説を基にした道具立したものであるとご理解ください。

• フッサールの現象学

• フレーゲ、ウィトゲンシュタインの言語哲学・論理学

• マルクスガブリエルの新実在論

• カントの総合的演繹

これまで、モノ、対象、分類、といった用語を使って解説してきました。
モデル化対象のドメイン（意味の場）の状態を、概念情報モデルを意味の構造（スキーマ）として、そこで定義された分類（概念クラス）をひな型（スキーマ）としたインスタンス（モノに対応）の集まりとして、その対象群を表現することになるわけです。対象の英訳を”Object”とするならば、擁護官の関係は、

An Object is an Instance of Conceptual Class

と言えるでしょう。

ここからは、著者の私見で恐縮ですが、これまでの解釈を総合すると、マルクスガブリエルの新実在論における”意味の場”は、

• 意味の構造を規定するスキーマが一つ対応する

• そのスキーマによって意味付けされたものが実在である

• 意味の場は、複数（もしかすると無限に）同時に立ち現われている

• 考えを明確化すること＝一つの意味の場に意識を向けることと（＝言語化すること）

との解釈がなりたつのだと考えられます。ウィットゲンシュタインによれば、言葉は思考の乗り物であり、考えることは言語化することなので、その原理に従って組み立てられた概念モデリングは、人間が思考できるものであれば、なんでもモデル化できると考えてよいでしょう。

数学的な観点からの基礎付け

概念情報モデルは、前節で解説した哲学・論理学的なバックグラウンドから導き出された形式を数学的な観点からも補強しています。

一つ目は、数学の基礎付けで近年活用の度合いが高まっている圏論（Category Theory）です。
90年代から2000年初頭にかけて、概念モデリングの基になっている Shlaer-Mellor 法の習得に勤しんでいたころ、オブジェクト情報モデル（Object Information Model ＝ 概念情報モデル）の解釈は集合論が基本だと考えていました。しかし、ちょっと詳しい方ならご存じの通り、（素朴な）集合論は、バートランドラッセルによって矛盾を抱えていることが指摘されているため、矛盾を抱えた数学を基礎とするのはいかがなものかと考えていたものです。数学の基礎付けの分野も同様の問題を抱えていたのですが、近年では、圏論という分野を適用して、無矛盾な数学の公理系を打ち立てようという試みが進んでいます。
圏論は、圏という概念を使って論理を構成していく数学の一分野です。
圏は、対象（object）と射（morphism）という二つの概念について、

• どんな射に対しても、域（domain）と呼ばれる対象と余域（codomain）と呼ばれる対象とがただ一つ存在する。
  射fの域がA、余域がBであることを、
  B ← f － A
  と書き、[fはAからBへの射である]という。また射fの域をdom(f)、余域をcod(f)と記す。

• 射f、gについて、cod(f)=dom(g)であるならf,gの合成（composition）と呼ばれるdom(f)からcod(g)への射が一意に存在する。この射をg・fと書く。
  B ← f － A、C ← g －B、C ← g・f － A

• 射f、g、hについて、cod(f)=dom(g) かつ cod(g)=dom(h) であるなら、
  h・(g・f) = (h・ｇ)・ｆ
  であり、f，g，hは可換である。この関係式を結合律（associative low）と呼ぶ。

• どんな対象Aに対しても、恒等射（identity）と呼ばれる特別な射 1Aがただ一つ存在し、余域をAとする任意の射f、域をAとする任意の射gに対して、1A・f ＝ f、および、g・1A  = g が成り立ち、可換である。これを単位律（identity law）と呼ぶ。

が成り立つ、対象と射の集まりで定義されます。
※ ”圏論の道案内” より一部改変して抜粋。
モデル化対象のドメイン（意味の場）の、意味を伴なった存在群の状態を表現するインスタンスモデルと、そのスキーマたる概念情報モデルは、意味的リンクや関係（Relationship）の扱いをどうするか、一部技術的な課題はあっても、それぞれの形式の定義から、圏として記述できることは明らかでしょう。
これ以降、前者を圏I、後者を圏C と呼ぶことにします。

圏として記述することのメリットは、圏論において使用される語彙や、導き出された定理を、概念モデリングにおける様々な言説に活用できる点にあります。
詳しくは、“玉石混交コラム 5. 概念モデリングに関する圏論的考察 ‐ 議論のとっかかりとして｜Knowledge & Experience”をご一読いただきたいのですが、圏論の用語を使えば、圏C が圏I のスキーマになっていることを、

• 圏Iと圏C は圏同値である

と簡潔に述べられます。また、圏C をスキーマとして、モデル化対象のドメイン（意味の場）の状態を、圏C をスキーマとして圏I のモデルとして表現するという事は、元々のモデル化対象のドメイン（意味の場）の状態を圏W とすると、

• 圏W と 圏I は自然同値である

という状況にあると述べられます。自然同値という専門用語を使うと、なんとなく難しいことを言っているようですが、単純に圏Wの構成と圏Iの構成が一対一対応しているというだけの当たり前のことを言っているだけなので、安心してください。
当たり前のことのように思えるかもしれませんが、これは、作成した圏C（概念情報モデル）をスキーマとした圏I のモデルが圏W と一対一対応するかを確認すれば、作成した概念情報モデルの妥当性が検証できることが数学的に保証されていることを意味します。
また、自然同値の関係にある二つの圏があると、片方の圏で成り立つことは別の圏でも成り立つことが圏論的に証明されています。これにより、圏Wと自然同値な圏I であれば、圏I 側での（振舞いも含めた）動的シミュレーションの結果が、圏W 側つまり現実世界と合致することが数学的に保証されることになります。
これは、相対性理論や量子力学などで、方程式で記述される数理モデルの計算結果が実験結果と一致することの原理でもあると、筆者は考えているのですが、いかがでしょう。

二つ目はの数学的基礎は、リレーショナルデータベースの基礎付けでもある関係理論（リレーショナルセオリー）です。
前節で示した、人間の思考内容を表現するための基本形式は、結果的に、関係理論の正規化と一致します。
よって、概念クラスの特徴値の分類として、インスタンスの一意性を示す識別子特徴値や、関係（Relationship）を定式化する参照特徴値の定義方法は、そのまま、関係理論のそれを採用しています。

私見ですが、関係理論に厳密に従ったリレーショナルデータベースのテーブル設計がなかなか難しいのは、概念モデリングで取り入れている、”意味の場ごとにモデルを作る”という概念が欠けた単なる数学理論だからではないでしょうか。正規化が成り立つような意味構造を定義するデータモデルがつくれるのは、ある一つの意味の場に対してだけのはずです。”6．ドメインとITシステム構築” で詳細は述べていますが、異なる意味の場にある二つのデータ要素間は、単なる対応付けしかできません。本質的にそうなのですから、データベースとして保持するデータ要素が、何の意味の場で現象するものなのか、明確に意識せずに設計したリレーショナルデータベースが破綻するのは、論理的帰結であると思えます。
ただし、言い方を変えれば、対象とする意味の場を明確に一つに限定してリレーショナルセオリーを適用すれば、適切なリレーショナルデータベースが設計できると言っても過言ではないでしょう。

バートランドラッセルが指摘した（素朴な）集合論に潜む矛盾も、集合の要素が、同一の意味の場に現象するものではないことに起因するように思えます。

以上、ここまで、哲学、論理学、数学による位置づけを解説してきましたが、最後に、意外と重要かもしれない観点を加えておきましょう。
それは、”ゲーデルの不完全性定理”です。数学の公理系には、その公理系の中では証明できない公理が存在するという、無矛盾な体系を作りたい人たちにとっては絶望的な定理です。概念モデリングも、このモデリングにおいて記述する複数のモデルそれぞれについても、この定理の影響は避けえません。
しかし、この厳然とした事実は、概念モデリングにとってはあまり影響はありません。なぜなら、概念モデリングで作成するモデルは、（意味の場ごとの）現実世界の意味構造を記述するモデルであって、説明するモデルではないからです。説明するモデルであれば、無矛盾に、”なぜそうなっているか”を厳密に説明することを要求されるでしょう。しかし、対象をありのままに記述するモデルであれば、現実世界が本来抱えている矛盾をそのまま記述しるのですから、全く問題は無いでしょう。
また、ゲーデルの不完全性定理は、あくまでも、一つの系の中の話であって、その系の外側からの説明を加えれば、解消されるそうです。概念モデリングは、複数のドメイン（意味の場）のモデルを作って、組み合わせるので、そちらからも影響はないと考えても良いのではないでしょうか。

最後に

概念情報モデルの基礎に関する解説は以上です。次は、「概念情報モデルを使う」で、概念情報モデルの使い方を解説します。

ただし、概念モデリングは形式にすぎない。文法の誤用もまたあり。