AI協業を支える知識モデリング
第5回では、オブジェクト・モデルがSimpleModelingモデルへ実行可能な形式構造と実行例を与えることを説明しました。形式構造だけでは、概念がなぜその意味を持つのか、どの資料に基づくのか、別の文書やモデル要素とどう関係するのかを、生成AIが安定してたどることはできません。
生成AIをモデルの理解と開発に活用するには、まず知識を整える必要があります。知識モデル (Knowledge Model)は、CMLによるモデル定義、ドメイン・モデル (Domain Model)のレビュー、ユースケース・モデル (Use Case Model)の作成とレビュー、ドメイン理解のための問い合わせを支えます。用語、概念、分類、意味関係、規則、根拠、出典を対応付け、生成AIが探索し説明できるようにします。人間は生成AIとの対話を通じて、説明と根拠を確認し、妥当な更新だけを正本へ反映します。
本稿では、知識モデルの内容と、それを表現、検索、提供する技術を分けて扱います。RDF、オントロジー (Ontology)、知識グラフ (knowledge graph)は意味構造を明示し、埋め込み (Embedding)とRAGは関連情報を見つけ、MCPは選択された知識を生成AIへ渡します。これらは同じ役割ではありません。
記事の全体像
知識モデルの位置付けと、整えた知識を生かす四つの開発用途を図で確認します。 
シリーズにおける位置付け
第3回では、SimpleModelingモデルをオブジェクト・モデル、知識モデル、文芸モデル (Literate Model)の三つの構成要素として整理しました。第4回では、目的と関心事に応じて三つから必要な要素を選び、ビュー (View)として扱う方法を説明しました。第5回では、形式構造を担うオブジェクト・モデルを扱いました。
第6回は知識モデルを扱います。知識モデルは、オブジェクト・モデルの説明資料や出典一覧ではなく、同じ対象の知識的な側面を表す構成要素です。次回の文芸モデリングでは、人間が理解できる自然言語を中心に、文脈、意図、要求、判断、シナリオを保持する文芸モデルを扱います。
前回の記事: 📄 構造基盤としてのオブジェクトモデリング
SimpleModelingモデルにおける知識的な側面
オブジェクト・モデル、知識モデル、文芸モデルは、同じ対象の異なる側面を、それぞれの利用者と用途に適した形式で表すSimpleModelingモデルの構成要素です。知識モデルは、オブジェクト・モデルの説明資料や出典一覧ではありません。概念、分類、意味関係、規則、根拠、出典を対応付け、生成AIが探索し、人間へ説明できる知識的な側面を表します。
| 構成要素 | 表すもの | 主な利用 |
|---|---|---|
|
実行可能な形式構造と実行例 |
開発者、プログラミング言語、実行基盤、生成AIで共有します。 |
|
|
概念、分類、意味関係、規則、根拠、出典 |
主として生成AIが探索、関連付け、解釈し、人間へ説明します。 |
|
|
自然言語による文脈、意図、要求、判断、シナリオ |
開発者、非開発者、生成AIで共有します。 |
三つは別々の資料を後から束ねる分類ではありません。用語集 (Glossary)に定義された用語を通じて、形式構造、知識構造、自然言語の記述を相互に対応付けます。目的と関心事に応じて三つから必要な要素を選ぶことで、ドメイン・モデル、ユースケース・モデル、アプリケーション・モデル (Application Model)を構成します。
知識モデルの四つの開発用途
ここまでの位置付けを開発の作業へ接続すると、知識モデルは次の四つの場面で使われます。この一覧は本稿の論点を増やすための別の構造ではなく、以後に説明する用語、対応、意味構造、検索、アクセス、承認がどこで役立つかを示す地図です。
| 開発作業 | 知識モデルの使い方 |
|---|---|
|
CMLによるモデル定義・更新 |
用語、規則、関係、根拠をもとに、生成AIがCMLの候補を作り、人間が確認・承認します。CMLはオブジェクト・モデルの実行可能な表現であり、知識モデルがそれを置き換えるわけではありません。 |
|
ドメイン・モデルのレビュー |
構造、制約、用語の整合性を、定義と根拠に照らして確認します。 |
|
ユースケース・モデルの作成・レビュー |
シナリオの語彙、目的、業務規則を整え、文芸モデルとオブジェクト・モデルの対応を作成時にも確認時にも扱います。 |
|
ドメイン理解のための問い合わせ |
「この概念は何か」「なぜこの条件が必要か」に、関連情報と根拠を添えて答えます。 |
レビューと問い合わせを支える共通の入口
ここでいう用語は、用語集の中で定義された用語です。用語集は、名称、意味、境界、同義語を管理し、内部では安定したIDで各用語を参照します。表示名や文字列の近さではなく、この定義された用語を対応の入口にすることで、ドメイン・モデルをレビューする時にも、ドメインについて問い合わせる時にも、同じ表記の別の意味を区別し、名称が変わっても同じ概念を追跡できます。
オブジェクト・モデルの要素、知識モデルのノード、文芸モデルの記述は、同じ用語集の用語へ対応付けられます。たとえば「状態 (State)」は、業務上の状態、画面の状態、処理の進行状態を指すことがあります。用語集が意味の境界を定め、知識モデルが文書、状態機械 (StateMachine)、イベント (Event)、業務規則との関係を保持することで、生成AIはどの状態を説明しているかを確認できます。
四つの用途を通じて整備する知識
知識モデリング (Knowledge Modeling)は、文章を細かく分割して検索可能にするだけではありません。CMLによるモデル定義、ドメイン・モデルのレビュー、ユースケース・モデルの作成とレビュー、ドメイン理解のための問い合わせのどれでも、生成AIと人間が「何が同じ概念で、何が異なり、どの関係と根拠があるか」を確認できるようにします。
| 知識要素 | 答える問い |
|---|---|
|
用語と同一性 |
用語集に定義された、どの用語を指すか。 |
|
分類 |
この概念はどの種類に属し、どの概念を具体化するか。 |
|
意味関係 |
二つの概念は、どの意味で結び付くか。 |
|
規則と境界 |
どの条件で成立し、どこまで適用されるか。 |
|
根拠と出典 |
なぜそう言えるか。どの資料と判断に基づくか。 |
|
対応関係 |
用語、文書、オブジェクト・モデル要素、文芸モデルの記述はどう対応するか。 |
知識モデルに規則を記述しても、それだけで実行可能な規則になるわけではありません。実行可能な構造はオブジェクト・モデルとCMLが担います。知識モデルは、規則の意味、分類、根拠、関連する資料やモデル要素を、生成AIが探索できる形で保持します。
用途2: ドメイン・モデルのレビュー
ドメイン・モデルをレビューする時は、構造、制約 (Constraint)、用語を、定義、規則、根拠に照らして確認します。知識モデルがこの対応を保持していれば、生成AIは不整合の候補と根拠を示せます。候補の妥当性をドメインの意味に照らして判断するのは人間です。
意味構造・検索・アクセスを分ける
知識モデルの内容と、検索や提供の仕組みを区別すると、各技術の役割が明確になります。これらは一方向の処理段階ではなく、互いに異なる責務 (Responsibility)を持つ仕組みです。
| 役割 | 技術 | 寄与 |
|---|---|---|
|
意味の同一性 |
用語の名称、意味、境界、安定IDを定めます。 |
|
|
明示的な意味構造 |
概念、分類、関係、根拠を明示します。 |
|
|
検索用の派生表現 |
Embedding / text index |
意味の近い候補や関連文書を効率よく探します。 |
|
文脈の検索 |
問いに必要な外部知識を検索し、生成時の文脈へ加えます。 |
|
|
アクセス境界 |
選択された知識資源や操作を生成AIへ標準化された形で提供します。 |
用途4: ドメイン理解のための問い合わせ
第5回に例として挙げた「注文確定」を、知識モデルの側から見ます。オブジェクト・モデルには、注文、在庫確保、支払い承認、注文確定イベント、状態機械などの形式構造があります。文芸モデルには、「注文を確定する」というユースケースシナリオ (Use Case Scenario)、例外、判断理由があります。
知識モデルは、用語集に定義された「注文確定」という用語から、ユースケースシナリオ、状態機械、イベント、業務規則、根拠・出典への対応を保持します。これにより、生成AIは、何が必要か、成功すると何が起きるか、なぜその条件が必要かを、一つの概念から説明できます。
| 問い | 知識の経路 |
|---|---|
|
注文を確定するには何が必要か。 |
注文確定 → 在庫確保 / 支払い承認 → 関連する業務規則 |
|
成功すると何が起きるか。 |
注文確定 → 注文確定イベント → 注文の状態遷移 |
|
なぜその条件が必要か。 |
業務規則 → 根拠資料 / 承認記録 → 対応する制約 |
開発方法における知識モデリング
四つの用途は、独立した工程ではありません。ドメイン・モデリング (Domain Modeling)では意味、構造、規則、境界をたどり、アプリケーション・モデリング (Application Modeling)ではユースケースシナリオと、サービス、オペレーション、イベント、状態機械などの実行可能な要素との対応を説明し、確認します。同じ用語、規則、根拠、対応を整備しておくことで、CMLの更新、レビュー、問い合わせで一貫して利用できます。
参照
用語集
- オブジェクト・モデル (Object Model)
-
Undefined
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- Cozy Modeling Language (CML)
-
CML(Cozy Modeling Language)は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
- ユースケース (Use Case)
-
UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
- RDF
-
W3C により標準化された、情報を「主語–述語–目的語」の三つ組(トリプル)で表現するための知識記述モデル。
- モデル・コンテキスト・プロトコル (MCP, Model Context Protocol)
-
モデル・コンテキスト・プロトコル(Model Context Protocol、MCP)とは、生成AIを利用するアプリケーションと外部のデータ源やツールを接続し、コンテキストと機能を標準化された形で提供するためのオープンプロトコルです。
- 検索強化生成 (RAG, Retrieval-Augmented Generation)
-
生成AIが内部(パラメトリック)知識だけでなく、外部の知識ソースを検索してから応答を生成する技術。 RAGはまずデータベースや知識グラフなどから関連情報を検索し、それを文脈として取り込み、より正確で最新の応答を生成する。
- ドメイン・モデル (Domain Model)
-
Undefined
- 知識モデル (Knowledge Model)
-
知識モデル(Knowledge Model)とは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる形で構造化したモデルです。
- ユースケース・モデル (Use Case Model)
-
ユースケース・モデル(Use Case Model)とは、利用者や外部主体がシステムを利用する目的と、その目的を達成するシナリオおよび期待する結果を、Actor、Goal、Use Case、Scenario、Outcomeによって表す目的別のモデルです。
- 埋め込み (Embedding)
-
埋め込み(Embedding)とは、文章、用語、モデル要素などを、その意味上の近さを計算できる数値ベクトルへ変換した表現です。類似検索や候補抽出に利用します。
- オントロジー (Ontology)
-
オントロジー(Ontology)とは、対象領域の概念、分類、関係、制約を明示し、知識を一貫して解釈するための意味構造です。
- 知識グラフ (knowledge graph)
-
現実の概念・事物・出来事をノードとし、その関係をエッジとして表す意味的グラフ構造の知識ベース。
- ビュー (View)
-
Viewとは、Modelを特定のPurposeとConcernに応じて選択し、理解、判断、検証、利用できる形で投影した表現です。ViewはModelの一部を見せるものであり、元のModelとは別に意味を所有しません。
- 文芸モデル (Literate Model)
-
Undefined
- オブジェクト (Object)
-
Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。
- 用語集 (Glossary)
-
Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。
- アプリケーション・モデル (Application Model)
-
アプリケーション・モデル(Application Model)とは、ユースケースをアプリケーションがどのように実現するかを、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作、結果によって表す目的別のモデルです。
- 制約 (Constraint)
-
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
- 状態 (State)
-
UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
- イベント (Event)
-
UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
- 状態機械 (StateMachine)
-
UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。
- 知識モデリング (Knowledge Modeling)
-
Undefined
- 同一性 (Identity)
-
Identityとは、値やStateが変化しても、ある対象を他の対象と区別し、時間を通じて同じ対象として追跡するための同一性です。IdentifierはIdentityを表現または参照する値であり、Identityそのものと同義ではありません。
- 責務 (Responsibility)
-
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
- IRI (Internationalization Resource Identifier)
-
RDFにおけるリソース識別子。Web上で一意に識別できるIDとして利用され、概念・文書・プロパティなどあらゆるノードの基盤となる。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- ユースケースシナリオ (Use Case Scenario)
-
Undefined
- ドメイン・モデリング (Domain Modeling)
-
Undefined
- アプリケーション・モデリング (Application Modeling)
-
アプリケーション・モデリング(Application Modeling)とは、ユースケースをアプリケーションが実現する振る舞いとして具体化し、アプリケーション・モデルを構成する活動です。ユースケースシナリオから、参加者、役割、責務、協調、相互作用、状態遷移、イベント、サービス、操作への対応を明らかにします。
- BoK (Body of Knowledge)
-
SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。