知識ハーネス
SimpleModelingでは、BoKという、CMLや自然文の文書で記述した知識の格納庫を用意しています。知識ハーネスは、このBoKに定義した用語・関係・ルールによって、要求・設計を制約 (Constraint)する仕組みです。作成時に定義に沿って組み立て、レビューで不一致を見つけ、解消するまで採用を止めます。
BoKの紹介
BoKは、CMLや自然文の文書で記述した知識を蓄え、人間とAIが共有・再利用するための格納庫です。自然文の文書には、業務用語の意味、業務規則、要求、シナリオ、設計意図、判断理由などを記述します。CMLには、自然文の説明と一体でオブジェクト・モデル (Object Model)の定義を記述します。
文書、用語集 (Glossary)、モデル定義を、用語や識別子 (Identifier)、参照関係で結び付けて蓄えます。人間はその内容をHTMLとして読み、AIはMCP (Model Context Protocol, モデル・コンテキスト・プロトコル)などを通じて必要な知識を参照します。文芸モデル (Literate Model)とオブジェクト・モデルを知識モデル (Knowledge Model)へ変換し、元の記述との対応を残すことで、同じ知識を複数の開発や成果物へ引き継げます。
BoKに蓄える知識を、共通の開発知識と顧客固有の業務知識に分けて示します。
-
共通の開発知識：用語定義、モデル (Model)の考え方、設計方針、開発パターンなどを共有する。
-
顧客固有の業務知識：用語の意味、業務規則、適用条件、合意した判断理由を蓄える。注文Aの例では、与信承認の意味や全数出荷の規則がこれに当たる。
BoKの知識を活用した開発の枠組み
BoKに蓄えた知識を起点に、人間とAIが要求を具体化し、設計やモデルを組み立て、実装へ展開します。自然文の業務説明やシナリオから必要な条件を読み取り、対応するモデル定義や部品の契約を参照します。CMLの実行可能なモデルはCozyでプログラム、設定、文書へ具体化し、部品と必要な補完実装を組み合わせます。
図1 BoKの知識を使った開発の流れ
表1 BoKに蓄えた知識から開発を展開する
| BoKに蓄える記述 | 開発での使い方 | 展開する成果 |
|---|---|---|
|
自然文の業務説明・用語・規則 |
意味と適用条件を確認し、必要な条件を導く |
要求仕様・受入条件 |
|
要求・シナリオ・判断理由 |
設計・オブジェクト・モデル |
|
|
CMLのモデル定義 |
Cozyでプログラム・設定・文書へ変換する |
実装・設定・マニュアル |
表1の枠組みを受注・出荷に適用するときの、各段階の確認点を示します。
一つの格納庫に蓄えた知識を、要求の検討、モデルの作成、実装、ドキュメントの生成などへ繰り返し使います。顧客との確認で得た要求や判断理由もBoKへ戻し、次の開発の土台にします。次節では、この展開が元の知識から外れないようにするハーネスの働きを説明します。
文芸モデルで共有・記述し、知識モデルへ変換する
文芸モデルで、顧客と用語の意味、業務規則、意図、判断理由を共有します。CMLも、自然文の説明とオブジェクト・モデルの定義を一体化した文芸モデルです。自然文で顧客と情報を共有しながら、同じ文芸モデルの中でオブジェクト・モデルを記述します。
図2 文芸モデル・オブジェクト・モデル・知識モデルの連携
文芸モデルで顧客と情報を共有し、CMLでは自然文とオブジェクト・モデルの定義を一体化します。文芸モデルとオブジェクト・モデルの両方を知識モデルへ変換し、同じ用語・識別子で元の記述と対応付けます。
表2 文芸モデル・オブジェクト・モデル・知識モデルの関係
| モデル | 主に表すもの | 「与信承認」の例 |
|---|---|---|
|
自然文・図・例で顧客と情報を共有する。CMLも自然文とオブジェクト・モデルの定義を一体化した文芸モデル |
承認の意味や判断理由と、そのモデル定義を一緒に記述する |
|
|
受注の承認状態、承認操作、出荷に必要な条件を定義する |
||
|
文芸モデルとオブジェクト・モデルを変換し、概念・意味関係・規則・根拠・出典をAIが参照できる形にする |
承認の説明、モデル要素、規則と根拠の対応を保持する |
文芸モデルの自然文と、CMLに記述したオブジェクト・モデルの両方を知識モデルへ変換します。用語・対象・適用範囲をそろえて、自然文の規則とモデル定義の条件の矛盾も変換時に検出できます。元の記述への対応を残すことで、顧客との合意とモデル定義の整合を確認し、修正へ戻せます。
連携の軸は、用語集で定義した概念の意味と安定した識別子です。「与信承認」を入口に、顧客が確認した自然文、CMLの承認状態や操作 (Operation)、知識モデルの規則や根拠をたどります。文芸モデルの意図や経緯も残し、同じ用語を軸に記述と変換結果をつなぎます。
関連記事：AI協業を支える知識モデリング (Knowledge Modeling)：三つのモデルと用語集の関係、モデル定義・レビュー・問い合わせへの利用は「AI協業を支える知識モデリング」を参照してください。参照先：関連記事
知識ハーネスとして働かせる仕組み
BoKから要求・設計・モデル・実装へ開発を展開するとき、元の業務知識に反する判断や、必要条件の抜けが入り込むことがあります。知識ハーネスは、蓄えた知識を作成時の制約とレビューの基準として働かせ、矛盾や不足を解消するまで案の採用を止めます。
BoKと矛盾する要求・設計を採用できなくする
BoKに「全数を引き当ててから出荷する」という規則があるなら、要求・設計もそれを基に組み立てます。それでもAIが「与信承認済みなら出荷できる」と提案した場合は、レビューで規則との矛盾と、全数引当の条件の抜けを見つけます。作成時に知識を使うことと、できた案を確かめることの両方が必要です。
表3 BoKを基に作り、レビューで矛盾・抜けを見つける
| 段階 | BoKの使い方 | ハーネスとしての働き |
|---|---|---|
|
要求・設計の作成時 |
BoKの用語・関係・ルールに沿って案を作る |
知識に沿って要求を具体化し、モデルや部品の選択肢を絞る |
|
レビュー時 |
できた要求・設計を、元の知識へ戻って照合する |
意味の取り違え、規則との矛盾、必要条件の抜けを見つける |
|
指摘への対応時 |
該当する規則と対象箇所を対応付ける |
要求・設計を修正する。知識自体の変更が必要なら、顧客と合意してBoKを更新し、再レビューする |
表3の作成とレビューを組み合わせ、知識に反する案の採用を防ぎます。
BoKを土台に、要求・設計を組み立てる
BoKの知識は、レビューのときだけ参照するものではありません。要求を具体化し、モデルや部品を選ぶ段階から土台にします。業務で採用する意味を定め、型・状態・規則・公開契約へ具体化することで、AIが案を作る際の選択肢を制約できます。
採用する意味・規則・適用範囲を確定する
ユースケース (Use Case)のシナリオやAIに提示する仕様の文章で使う問題領域の用語は、BoKで定義した用語に限定します。用語間の関係と業務ルールもBoKの定義に従います。適用する業務・版・時点と合意の記録を定め、AIが案を作る際の基準として渡します。
シナリオと仕様をBoKに揃えるため、用語・関係・ルールを照合します。
未定義の用語・関係・ルールは、要求・仕様だけに追加せず、顧客と合意してBoKを更新します。更新後に要求・設計を再確認し、不一致が残る案は採用しません。
注文Aで採用する意味・規則・適用範囲を、次のように固定します。
-
意味：「与信承認」は与信枠の超過を認める判断であり、在庫の確保を表さない。
-
規則：注文Aは10個をそろえて出荷する。6個だけの先行出荷は認めない。
-
適用範囲：この案件で採用した規則と版を指定し、他案件や旧版の条件を混ぜない。
用語と規則を、モデルの型・関係・条件へ結ぶ
要求・設計を作るときは、合意した規則から必要な条件を導き、モデルの状態 (State)や制約、利用する部品の公開契約へ具体化します。文芸モデルに判断理由を残し、CMLなどで形式化できる条件をモデルへ表します。この対応は、Cozyによる具体化の土台になるとともに、後のレビューで元の規則へ戻る手掛かりになります。
表4 注文Aの業務知識を要求・設計の制約へ具体化する
| BoKの知識 | 要求で満たす条件 | 設計へ具体化する制約 |
|---|---|---|
|
与信承認と在庫引当は別の判断 |
二つの状態を区別して確認できる |
承認状態と引当状態を別に持ち、混同しない |
|
全数がそろうまで出荷を保留 |
10個の注文を6個だけで出荷しない |
全数引当を出荷の前提条件にする |
|
引当は注文のための在庫確保 |
在庫数の照会だけで引当済みとしない |
注文と必要数を受け取り、引当結果を返す操作を選ぶ |
レビューで、BoKとの矛盾・条件の抜けを見つける
図3 用語・関係・ルールによる要求・設計の制約
表5 レビューで見つけた問題を、修正と採用判断へつなぐ
| レビューの結果 | 扱い | 次に行うこと |
|---|---|---|
|
業務規則との矛盾・必要条件の抜けがある |
受理しない |
該当規則と対象箇所を示し、修正して再レビューする |
|
根拠・適用条件が足りない |
受理を保留する |
顧客や知識の責任者に確認する |
|
指摘を解消し、必要な確認が済んだ |
受理へ進める |
採用した規則と判断の対応を残す |
レビューでは、シナリオとAIに提示する仕様を含む要求・設計を、採用したBoKの用語・関係・ルールへ対応させ直します。未定義の用語、定義と異なる関係、ルールの矛盾や条件の抜けを指摘し、該当するBoKの定義と対象箇所を示します。モデル・部品への具体化による食い違いも確かめ、未解決の指摘がある案は採用しません。
知識やモデルが変わったら、対応する要求・設計を確かめ直す
一度適合した要求・設計も、その根拠が変われば確認し直す必要があります。ハーネスは、知識を使った時点だけでなく、変更後も同じ意味と条件を保つために働きます。
参照切れと条件の欠落を、修正箇所へ返す
用語や規則と、要求・モデル要素・受入例の対応を識別子で保持すると、変更の影響をたどれます。例えば引当状態のモデル要素を変更したときは、旧要素を参照する出荷条件と受入例を確認対象へ戻します。RDFは、この対応を表し、参照をたどるために使えます。
変更した知識が使われている箇所を特定し、再確認するまでの対応を整理します。
-
特定する：変更した規則から、影響する要求・モデル・部品の接続・受入例をたどる。
-
戻す：未解決の参照切れや条件不足がある対象の受理を保留する。
-
確かめ直す：修正後に対応と制約を検査し、必要な受入例を再確認する。
知識そのものを変えるときは、顧客と合意してBoKを更新する
要求・設計との矛盾を調べた結果、BoKの知識そのものを更新する必要が分かることもあります。その場合は、文芸モデルの自然文をHTMLで顧客と確認し、合意しながら更新します。さらに、文芸モデルとオブジェクト・モデルを知識モデルへ変換する処理で、記述した知識自体の矛盾を検出します。
図4 顧客との合意と矛盾検出を経たBoK更新
顧客と自然文をHTMLで確認し、文芸モデルとオブジェクト・モデルを知識モデルへ変換します。知識内部の矛盾と、自然文とモデル定義の間の矛盾を検出し、元の記述へ返します。解消後に知識の更新を受理することがハーネスとして働きます。
文芸モデルの自然文をHTMLで顧客と確認する
顧客は、BoKに蓄えた知識を文芸モデルの自然文記述としてHTMLで確認できます。業務の言葉で規則や判断理由を読み、具体例と照らして、新しい理解や変更内容を合意していきます。知識モデルの内部表現を直接編集することを、顧客の確認の前提にはしません。
更新内容を顧客に提示し、確認・合意を文芸モデルへ残す手順を示します。
-
自然文で示す：何が変わるか、なぜ変えるか、どの業務や時点へ適用するかを記述する。
-
顧客と確かめる：HTMLで用語の意味と業務規則を読み、注文Aなどの具体例で条件を確認する。
-
合意を反映する：確認した意味・規則・変更理由を文芸モデルに残す。
変換時に、自然文とモデル定義の矛盾も検出する
文芸モデルとオブジェクト・モデルを知識モデルへ変換する処理では、記述した知識の内部の矛盾に加え、自然文の説明とモデル定義の間の矛盾も検出できます。同じ用語・識別子、対象、適用範囲へ対応付けた規則を照合することで、顧客と共有した説明と実行可能な定義の食い違いを確かめます。
例えば自然文で「全数引当が済んでから出荷する」と合意しているのに、CMLの出荷操作が「与信承認だけで出荷を許可する」と定義されていれば、在庫6個で10個の注文を出荷できるかについて矛盾します。両方を知識モデルへ変換するときに同じ出荷操作の条件として照合し、矛盾する自然文とCML定義を修正箇所として返します。
表6 自然文とモデル定義の矛盾を変換時に見つける
| 対象 | 出荷の条件 | 変換時に確認すること |
|---|---|---|
|
顧客と共有した自然文 |
与信承認と全数引当が必要 |
合意した出荷条件を、同じ用語と適用範囲へ対応付ける |
|
CMLのオブジェクト・モデル定義 |
与信承認だけで出荷を許可 |
全数引当前の出荷を許し、自然文の規則と矛盾する |
|
知識モデルへの変換 |
両方の条件を照合する |
該当する自然文とモデル定義へ返し、解消するまで更新の受理を止める |
合意と検査を反映し、BoKと要求・設計を更新する
顧客の確認・合意と、変換時に検出した知識内部および自然文とモデル定義の間の矛盾の解消を、知識更新の受理条件にします。未解決のままBoKの更新を確定させず、修正と再変換へ戻します。整合を確認した文芸モデル・オブジェクト・モデル・知識モデルを反映し、影響する要求・設計を更新した知識で作り直してレビューします。
検査できる条件と、受理を止める仕組みをそろえる
表7 知識ハーネスを成立させる三つの役割
| 役割 | 具体的に行うこと | 成立に必要な条件 |
|---|---|---|
|
知識を提供する |
BoK・モデル・部品契約を参照可能にする |
出典・版・適用範囲を保って参照する |
|
レビュー・検査する |
要求・設計の不一致と知識の矛盾を検査 |
形式化した条件はツール、意味は人間が確認 |
|
受理を制御する |
不一致の案は採用しない |
検査・確認を必須にする |
表7の役割を実現する前提として、検査の分担と採用制御の接続を確認します。
この回では要求・設計を確定するまでを中心に扱いました。確定した条件を業務状態の変更時にも守らせる役割は、第7回のランタイム・ハーネスへ接続します。実行結果の観測と評価は、第9回・第10回へ続きます。
参照
用語集
- Cozy Modeling Language (CML)
-
CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
- BoK (Body of Knowledge)
-
SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- 制約 (Constraint)
-
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
- オブジェクト・モデル (Object Model)
-
Undefined
- 用語集 (Glossary)
-
Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。
- 識別子 (Identifier)
-
Identifierとは、Identityを持つ対象または相関対象を参照し、他の対象から区別するために使用する値です。IdentifierはIdentityを表現できますが、対象が時間を通じて同じ対象であるというIdentityの意味そのものではありません。
- モデル・コンテキスト・プロトコル (MCP, Model Context Protocol)
-
モデル・コンテキスト・プロトコル（Model Context Protocol、MCP）とは、生成AIを利用するアプリケーションと外部のデータ源やツールを接続し、コンテキストと機能を標準化された形で提供するためのオープンプロトコルです。
- 知識モデル (Knowledge Model)
-
知識モデル（Knowledge Model）とは、SimpleModelingモデルに含まれる概念、意味関係、分類、規則、根拠、出典などを、主として生成AIが参照、探索、関連付け、解釈できる形で構造化したモデルです。
- 文芸モデル (Literate Model)
-
Undefined
- オブジェクト (Object)
-
Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- Cozy
-
Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
- 状態 (State)
-
UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
- 責務 (Responsibility)
-
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- 知識モデリング (Knowledge Modeling)
-
Undefined
- 協調 (Collaboration)
-
UMLにおけるCollaborationは、専門化された機能を担う参加要素のRoleが共同して、目的とする機能を達成する構造を記述するClassifierです。
- ユースケース (Use Case)
-
UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
- RDF
-
W3C により標準化された、情報を「主語–述語–目的語」の三つ組（トリプル）で表現するための知識記述モデル。