概念モデリングを習得しよう：概念モデルはなぜ検証できるのか？（第26回）

この連載コラムは長期にわたっているので、これまで解説してきた概念モデリングの道具立てをあらためてリストと図にまとめておきます。

• モデル化対象世界に対し、意味の場ごとに概念モデルを作成する
  ▶意味の場を“概念ドメイン”と呼ぶ
• 概念モデルの構成
  ▶概念情報モデル

  　　▷概念クラス
  　　▷概念クラスにひも付いた特徴値の組
  　　▷概念クラス間のリレーションシップ

  ▶特徴値のデータ型

  ▶概念情報モデルは、モデル化対象世界の、意味の場を通じて認識した写しのモデルのスキーマ（意味構造の定義）である

  　　▷写しのモデルは以下で記述される

  　　　・概念クラスをひな型にした概念インスタンス

  　　　・概念インスタンスには、値が確定した特徴値がひも付いており、
  　　　　特徴値は、その概念インスタンスがひな型とする概念クラスで定義されている

  　　　・リレーションシップをひな型にした概念インスタンス間の意味的なリンク

  　　▷写しのモデルと概念情報モデルは、どちらも圏である

  　　　・前者を圏I、後者は圏Iのスキーマであり圏Cと呼ぶ

  ▶概念クラスにひも付いた状態モデル

  　　▷イベント

  　　　・引数を伴う場合がある

  　　▷状態

  　　　・状態にひも付いたエントリアクション

  　　　・エントリアクションはデータフローモデルで記述する

  　　▷遷移

  　　　・遷移を生起するイベントを添える

  　　▷状態遷移表

  ▶概念情報モデルをもとに圏Iを構成・参照するドメインファンクション

  　　▷ドメインファンクションは、エントリアクションと同様、データフローモデルで記述する

余談になりますが、例示しているモデル図の中の名前付けに違和感を持っている読者が、少なからずいるかもしれません。「図表の状態名やイベント名が、状態や事象っぽくないのでは」などです。
しかし、実際のモデリングにおいては、あまり気にすることはありません。重要なのは、モデラーがどう現実を捉えたか、です。モデルを作っていく初期段階では、クラス名、特徴値名、リレーションシップの両端の意味など、そもそもよく分かっていません。分からないからこそ、モデリングを通じて明確化していくことが重要だったわけです。モデリングの初期から、妥当な名前を付けられる方が、むしろすごいことです。神かよ！って感じです。作成したモデルを他者に見せながらコミュニケーションを行っていく中で、より適切で妥当な名前が出てきたら、躊躇なくそれに変えていく、それで十分でしょう。

ここで、いったん立ち止まって、図表1を改めて眺めてみましょう。随分と細かい理屈を伴う小難しい道具立てだなという印象を持つ読者が多いのではないでしょうか。
なぜ、このような道具立てが必要なのか、ここで改めて振り返っておきます。

概念モデリングは、現実世界を意味の場ごとに分割して、意味の場ごとの言葉の意味の構造を記述し、構造を構成する概念に関して、事象駆動、かつ、データフローの観点で振舞いを明らかにします。これらのモデルのことを、本連載コラムでは、圏Cのモデルと呼んでいました。概念モデリングの道具立てとして使うモデル群が圏Cです。現実世界の意味の場に存在する事柄の存在と振舞い、これを圏Iのモデルと呼んできましたが、これらは圏Cのモデルにより規定されます。モデル図の記法と、図によって表現される意味は、概念モデリングで厳密に規定されています。それにより、その規定を知っている人であれば、記述されたモデルを目にしたとき、正確にその記述内容を理解できることになります。

この連載コラムの記念すべき？第一回目で解説した、問題（現状と理想のギャップ）の記述を思い出してください。

問題を解決するためには、“現状の姿”と“あるべき理想の姿”の両方が、正確に記述されていなければなりませんでした。正確な記述を実現するための道具立てとして、概念モデリングは十分にその役割を果たすであろうことは、読者の皆さんにお判りいただけたと思います。

ここで、一つだけ注意を付け加えておきます。いったん出来上がったリソース割当やリソース不足が考慮されていなかった概念モデルと、その対策がなされた概念モデルは、概念モデリングで記述されたモデルという観点では、どちらも妥当で正しいモデルであるということです。不具合があるのはモデル化対象の現実世界（の意味の場）の方であって、モデルそのものの不具合ではないということです。モデリングの過程で対象世界（の意味の場）の不具合を見つけたら、それを隠蔽せず正確にモデル化することが重要です。そうでなければ、適切な問題解決を、モデリングを通じて行うことはできませんから。

ただし、いくら厳密な基礎付けがなされた道具立てを使ってモデルを記述しても、記述されたモデルの内容自体が現実世界の適切な写しになっていなければ、問題解決はできないでしょう。

重要なことは、記述したモデルが検証可能であること、です。

これまで解説してきた概念モデリングの厳密な定義が、どのように検証可能性を担保するか列記することにします。

• 現実世界に存在する対象と、概念クラスをひな型とする概念インスタンスが、1：1で存在するか？
• 現実世界に存在する対象の特徴を記述する値群を保持する概念クラスの特徴値が、1：1で存在するか？
• 概念情報モデルで、定義されたリレーションシップの両端の意味を使って組み立てた述語論理文が、現実世界において、真か？
• 現実世界で生起する事象と、状態モデルで定義されたイベントが1：1対応を持っているか？
• 状態モデルを使った動的検証結果と、現実世界における事象の生起をきっかけとした状態変化が等しいか？　※詳細はシミュレーションの説明を参照のこと

これらの検証は、記述されたモデルから導出された命題文を使って行われることになります。逆に言えば、検証可能なモデルとは、論理判定可能な命題文が導出可能でなければならないということです。過去の回で説明した、概念情報モデル、状態モデル、アクション記述、圏Iのモデルは全て命題文が導出可能であることを今一度振り返って確認してみてください。

フレーゲ、ウィトゲンシュタインによって基礎付けされた言語論理学（哲学）を踏まえると、平叙文として表された命題は対象世界の事柄に対応しているか否かによって、 True、Falseのいずれかに判定されます。対象世界の事柄が命題文に対応していればTrue、対応していなければFalseです。この“文の意味”の定義に違和感を抱く読者も少なからずいるかもしれません。私自身もその一人でしたから。この点については、“文の意味がTrueである”とは、“文が対象世界の事柄に対応している”ということであり、それは“文が対象世界の事柄を指し示しているのだ”と解釈すれば腑に落ちることと思います。

この連載コラムの第三回、第四回で解説したように、現実世界をどのような観点で眺めるか、つまり、“意味の場（Field of Sense）”を通じて、人間の思考では、言葉の意味、モノゴトの振舞いを認識・記述することになります。“文が対象世界の事柄を指し示しているのだ”の“対象世界”とは、人間が現実に対して志向的に向き合っている“意味の場”と考えれば、“対象世界の事柄”とは、単に物理学的に存在する物だけでなく、思考上の論理的な事柄も対象として含むと考えて、全く問題ありません。

以上を踏まえれば、対象世界を対象とした、記述された言葉の意味や事柄の振舞いの妥当性は、意味の場を特定しないと検証不可能であると言えるでしょう。

現実世界を、ある特定の意味の場を通じて眺めて拾い上げていくこと、それを前提としているからこそ、概念モデリングは、記述したモデルの妥当性が検証可能である、ということになります。

意味の場を通じて眺めた現実世界の意味（概念）と振舞いの構造を厳密に記述したものが概念モデルです。これまで、意味の場に対する、概念モデリングによる厳密な記述を、概念ドメインと呼んできました。圏Cのモデル（意味の場に対する概念モデル）が、圏Iのスキーマであったように、概念ドメインは、意味の場のスキーマであると定義するのが妥当でしょう。

検証可能性について、最後に数学的な考察を行うことにします。

意味の場を通じて観た現実の世界の状態を圏Rとすれば、

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

ことを、確認することが概念モデリングによる検証に相当すると考えられます。圏Cが意味の場の状態を記述した圏Iのスキーマであることを前提として、圏Rと圏Iの自然同値性を確認しながら検証していくことにより、圏C（概念モデル）が、圏Rのスキーマであることも、同時に確認できます。

この連載コラムの第五回の記事を思い出してください。自然同値の関係にある二つの圏では、どちらか一方で成り立つことは、別の圏でも成り立つことが数学的に証明されていることを紹介しました。これにより、圏Cである概念モデルによるシミュレーション結果は、圏Rの世界でも起こりうること、言い方を変えれば、ある状況が予測可能であることが、数学的に保証されることになります。

力学、電磁気学、量子論、相対性理論などをはじめとする物理学では、対象世界に対するモデルを作り、実験を通じてその妥当性を検証しながら、数式を使ってモデルを精密化します。その結果出来上がった方程式により、対象となる領域の様相を正確に記述できます。現代社会の基盤となっている物理学も、圏論的に見れば、概念モデリングのそれと同じであると言えるでしょう。

“検証可能であること”はとても重要です。それなしでは、何らかの作業の結果、出来上がった成果物が妥当かどうかの判定はできません。最近の話題で言えば、人が手書きで書いたコードであろうと、生成系AIで自動生成したコードであろうと、検証する手段がなければ、それが妥当なコードなのかを判断することはできません。

ソフトウェア開発では、要求仕様やアーキテクチャ設計、詳細設計など、工程ごとに沢山のドキュメントを作成するのが一般的な作法です。これらのドキュメントにおいて、作成した図やテキストも、検証可能な形式で記述されなければ、それらの妥当性を判断することはできません。妥当性を検証できない成果物を積み重ねた開発プロセスの結果として、出来上がるシステムがどのような末路を迎えるのか、想像してみてください。

出典：BusinessBalls「Tree Swing Cartoon Pictures」 より抜粋

極論すると、そんなドキュメントは作るだけ無駄…と言いたいところですが、それ以上を言うのは、やめにしておきます。見た目のコスパが重視される現代、真のコスパの良い作業とはどんなものか、ある程度の時間をかけて考えてみるのも良いでしょう。

ここまで検証可能性の重要性を説明してきて、何なのですが、筆者が考えるに、検証可能性が重視されない工程も、実践の場では、あるように思えます。それは、“あるべき理想の姿”を考える初期の段階です。この姿は、初期の段階では全くの五里霧中の状態なのが普通でしょう。

そのため、検証の根拠となるべき現実世界も、明確な姿では理解されていません。まったく新しい仕組みなどを考える時には、個々人の創発的なアイデアが重要です。この段階では、厳密さよりも、観た人が様々な意味の場を思い描いて想像を膨らませられるようなスケッチが適しているのは間違いありません。このような状況では、厳密さにはあまりこだわらずに、対象世界のスケッチやブレーンストーミング、アイデア出しを繰り返し、意味の場の候補をリストアップしながら、理想像を具体化していきます。その後で、意味の場の候補に対して、おもむろに概念モデルの作成を開始して、アイデアの厳密化を行います。作成したモデルによるシミュレーションを行って、それが本当に理想なのか、あるいは、抜け漏れはないかを検証します。そのような概念モデリングの活用を、是非試してみてください。

これまで解説してきたモデリング技法は、ソフトウェア開発における一般的な開発プロセスの用語で言えば、主に、システム開発の基礎となる開発対象の分析や要求定義のフェーズに相当するものです。また、複数の意味の場を洗い出すことはアーキテクチャ設計の一部に相当します。

開発対象としてわれわれが遭遇する世界は、本来は独立して並立している複数の意味の場が、複雑に織り込まれた混沌とした状態です。概念モデリングは、その混沌とした状態を丁寧にひも解き、一つずつ意味の場を切り出して、それぞれの意味構造と状態変化のスキーマを概念モデルとして構築するのが基本です。概念モデルで厳密に定義した意味の場のスキーマ、それを概念ドメインと呼びます。

システム構築は、複数の概念ドメインを組み合わせることによって行います。ITテクノロジーを使って、実際に動くシステムを構築するには、問題の核心である意味の場に対するモデルだけでなく、UIやOS、Middleware、プログラミング言語など、多彩な概念ドメイン群を相手にすることになります。

しかし、これらを概念ドメインとして扱うとはどういう意味なのか、ピンとこない読者は多いと思います。また複数の概念ドメインを組み合わせることが実システムの設計・実装だと言われても、「なんのこっちゃ」でしょう。

今回で、一つの意味の場をモデル化するために必要な、概念モデリングの基本的な道具立てについての解説は一区切りとなります。

しかし、現実のシステムは、一つの概念ドメインだけで成り立つものではありません。実際に動くシステムを設計・実装するためには、対象となる業務の意味の場群に対して、UI、OS、ミドルウェア、プログラミング言語など、概念モデルを動かすために必要な概念ドメイン群（実行プラットフォーム）の選択と対応付け、プログラムコードへの編み込み方法を考えなければなりません。加えて、設計・実装を支援する、実際に使える開発環境が必要です。

「実践編」スタートのお知らせ

2027年4月からは、これまで学んだ概念モデリングの考え方に加えて、概念ドメイン間の対応付け、実行プラットフォームの選択、業務の意味の場群からの実行プラットフォームの意味の場へ変換方法に関する話を交えながら、具体的な設計・実装にどのように活用するのかを解説する「実践編」をスタートします。AIも含む最新のソフトウェア開発技術を使って、概念モデルを実際のシステムづくりへどうつなげるのか、より具体的な例を交えながら考えていきます。どうぞお楽しみに。

さらに詳しく知りたい方へ

本連載で解説している内容に関連して、筆者は概念モデリングや圏論に関する研究・考察を継続しています。近年は、本稿で触れた検証可能性についても、数学的な観点からさらに整理を進めています。

こうした内容に興味のある方に向けて、筆者のnoteでも関連記事やディスカッションを公開していますのでご覧ください。

※なお、リンク先には無料で閲覧できる記事のほか、一部会員向けコンテンツも含まれます。

https://note.com/kae_made/membership