AI協調のためのBoK生成アーキテクチャ
SmartDoxサイトの構造
SmartDoxサイトは、SmartDox文書によって構成される体系的な知識空間です。各文書はディレクトリ階層上に体系的に配置され、相互にリンクすることで知識ネットワークを形成します。
現在、SmartDox文書には次の三つの種類があります。
-
SmartDox: 一般的な記事や解説を記述します。
-
LoxiDox: 用語集に掲載される用語を定義します。
-
CML (Cozy Modeling Language): オブジェクト情報モデルを定義します。
通常のSmartDox文書は、対象ドメインに関する概念・規則・制約などのドメイン知識を記述します。
SmartDoxはまた、DSL (Domain Specific Language)のメタ言語として機能し、概念的および構造的知識を一貫して表現できるようにします。
このメタ言語としてのSmartDoxを基盤に構築された文芸DSLが、用語定義のためのLoxiDoxと、ドメインモデル定義のためのCMLです。LoxiDoxとCMLはいずれもSmartDox文書の一形態であり、SmartDoxコマンドを用いてBoKの成果物へ変換できます。
SmartDoxはLoxiDoxで定義された用語から自動的に用語集を生成し、記事間の関連をクロスリファレンスとして構築します。この仕組みにより、サイト全体が意味的に接続された知識体系となります。
CML文書は、エンティティや状態機械などを用いてソフトウェアで操作可能なドメインモデルを定義します。このモデルはコード生成やモデル駆動型アプリケーション設計の基盤として機能します。
| 種類 | 内容 | 出力 | 備考 |
|---|---|---|---|
|
SmartDox |
解説・設計・理論 |
HTML / Web Metadata |
読解・索引対象の知識表現 |
|
LoxiDox |
用語定義 |
HTML / Web Metadata |
用語の知識表現 |
|
オブジェクト関数モデル定義 |
HTML / MCP / Web Metadata |
モデル定義＋行動仕様の基盤 |
BoKの構成
SmartDoxコマンドは、SmartDoxサイト全体を解析し、 全ての文書から構造化HTMLと意味メタデータを生成し、 さらにCML文書からは追加的にMCP定義を生成します。 これらを統合したものがBoKです。
| 出力層 | 主形式 | 内容・役割 | 主な利用対象 |
|---|---|---|---|
|
MCP |
JSON / YAML |
モデルやエンティティの操作・実行インタフェースを定義し、AIやツールが行動できるようにする。 |
AI / Agent |
|
HTML |
HTML5 |
SmartDox文書を人間とAIが読むための構造化された理解表現を生成する。 |
Human / AI |
|
Web Metadata |
JSON-LD / RDF |
AI / Search System |
また、CMLから生成したコンポーネント (Component)はコンポーネント資産としてBoKに登録されます。 この場合、BoKはコンポーネント・リポジトリとしても機能することになります。
BoKの生成
以下の図は、SmartDoxのリソースからBoKのリソースへの変換の様子を示しています。
SmartDox文書はSmartDoxコマンドによってHTML文書とWebメタデータに変換されます。 現時点ではWebメタデータとしてJSON-LDを作成しており、HTML文書内に埋め込まれます。
またCML文書はSmartDox文書の一種でもあるため、 SmartDoxコマンドによって通常のSmartDox文書と同様にHTML文書とWebメタデータに変換されます。
加えて、CML文書はソフトウェア的な特徴を持つ文書でもあるため、 ここからMCPを生成します。 MCPによって、BoKが記述するドメイン知識の振る舞い情報をRAG経由で生成AIに伝えることになります。
CML文書は、SmartDoxコマンドによる記事や用語の生成とは別に、 Cozyコマンドによってプログラムが自動生成されます。 生成されたプログラムはコンポーネントとしてパッケージングされ、アプリケーションの部品として活用されます。
用語は、LexiDoxによる用語定義と、 CMLによるオブジェクト情報モデル上の定義をマージしたものとして定義されます。 各記事には、使用している用語から用語集内の定義へのリンクが自動的に貼られ、 BoK内の意味ネットワークが補強されます。
Example
以下では、BoK内に格納されるWebメタ情報の具体的なイメージを例示します。
CMLで記述したエンティティモデルです。 この情報に対応するMCPとJSON-LDをそれぞれ見ていきます。
# Entity
## Person
This entity represents a person. It serves as a basic unit for identifying users, operators, or staff members within an application. It holds personal information such as identifiers, names, and ages.
### Attributep
| name | type | mul | description |
|---------+------------+-----+--------------------------------|
| id | identifier | 1 | A unique identifier assigned within the system |
| name | name | 1 | The person's full name |
| age | age | ? | Age, an optional attribute |
### Rule
1. The id must be unique.
2. The name must not be empty.
3. If age is specified, it must be a non-negative integer.
### Description
This entity is a fundamental domain object used across the entire application.
The Person entity is related to other entities (such as Order or Account) and serves roles like creator, assignee, or requester.
Additionally, the Person entity may synchronize with external systems.
In such cases, its identifier may be assigned externally—via an external directory service (e.g., LDAP or IDaaS)—rather than generated internally.MCPの例
前述のCMLによって定義されたエンティティに対するMCPの例を以下に示します。
{
"name": "person-manager",
"version": "1.0",
"entity": "Person",
"tools": [
{
"name": "create-person",
"description": "Create a new person entity.",
"input_schema": {
"type": "object",
"properties": {
"id": { "type": "string", "description": "A unique identifier assigned within the system." },
"name": { "type": "string", "description": "The person's full name." },
"age": { "type": "integer", "minimum": 0, "description": "Age, an optional non-negative integer." }
},
"required": ["id", "name"]
},
"output_schema": {
"type": "object",
"properties": {
"status": { "type": "string", "enum": ["success", "error"] },
"person": { "$ref": "#/definitions/Person" }
}
}
},
{
"name": "update-person",
"description": "Update the information of an existing person.",
"input_schema": {
"type": "object",
"properties": {
"id": { "type": "string", "description": "The ID of the person to update." },
"name": { "type": "string" },
"age": { "type": "integer", "minimum": 0 }
},
"required": ["id"]
}
},
{
"name": "delete-person",
"description": "Delete an existing person entity.",
"input_schema": {
"type": "object",
"properties": {
"id": { "type": "string", "description": "The ID of the person to delete." }
},
"required": ["id"]
}
}
],
"definitions": {
"Person": {
"type": "object",
"properties": {
"id": { "type": "string" },
"name": { "type": "string" },
"age": { "type": ["integer", "null"] }
},
"required": ["id", "name"]
}
}
}意味メタデータ(JSON-LD)の例
前述のCMLによって定義されたエンティティに対するJSON-LDの例を以下に示します。
{
"@context": {
"@vocab": "https://www.simplemodeling.org/vocab#",
"schema": "https://schema.org/"
},
"@type": "schema:Person",
"@id": "https://www.simplemodeling.org/ja/domain-modeling/person.html",
"name": "Person",
"description": "An entity representing a person, used to identify users, operators, or staff members within an application.",
"schema:identifier": {
"@type": "schema:PropertyValue",
"name": "id",
"description": "A unique identifier assigned within the system."
},
"schema:additionalProperty": [
{
"@type": "schema:PropertyValue",
"name": "name",
"description": "The person's full name."
},
{
"@type": "schema:PropertyValue",
"name": "age",
"description": "Age, an optional attribute.",
"valueReference": {
"@type": "schema:Integer",
"minValue": 0
}
}
],
"schema:isPartOf": {
"@id": "https://www.simplemodeling.org/ja/domain-modeling/"
}
}知識循環とAI協調
SimpleModelingでは、生成AIのリファレンス・アーキテクチャとして以下のものを定義しています。 生成AIに関する用語もここで定義したものを用います。
生成AIリファレンス・アーキテクチャが示すAI Collaboration Architecture（AI協調アーキテクチャ）は、AIがどのように知識を活性化し、内化し、表現し、そして人間との協働によって知識を循環させるかを示す概念構造です。
AIの内部では、まずKnowledge Activationが行われます。 ここでは、外部のBoKをRetrieval Knowledge Baseとして、さらに内部のPretrained Parametric Knowledgeを参照し、与えられたプロンプト (Prompt)に関連する知識を呼び出します。 RAGなどの仕組みを通じて、AIは処理のための文脈を形成します。
次にKnowledge Assimilationでは、呼び出された知識をAI内部で統合し、意味構造を再構成します。 この段階でAIは知識を「理解」し、自身の内部文脈に適合させます。
続くKnowledge Expressionでは、内化された知識をもとに、文章・コード・構造化データなどの形で表現を生成します。 このプロセスの結果として生まれる表現がAIの出力（Generated Output）です。
生成された知識はその後、二つの方向へ分岐します。 第一はKnowledge Promotionであり、AI内部での自律的な学習・成長のプロセスです。 生成結果のうち有用な部分がAIの内部構造に統合され、Pretrained Parametric Knowledgeとして定着します。 これは外部には直接現れない「暗黙知の蓄積」であり、AIの知的基盤を強化する経路です。
第二はKnowledge Circulationです。 こちらは人間が介在し、AIの生成物を評価・再構造化してBoKへ還流させるプロセスです。 生成された成果物は人間によってSmartDox文書やCMLモデルとして整理され、BoKに統合されます。 これにより、AIが生み出した知識は共有可能な明示知として再び体系に戻ります。
このように、AI内部では「Activation → Assimilation → Expression」の三段階で知識が処理され、 その後「Promotion」と「Circulation」という二つの異なる経路で知識が昇格または共有されます。 AIは内的に知識を成長させると同時に、人間と協働してBoKを発展させる存在になります。
このアーキテクチャは、AIが単なる生成エンジンではなく、 知識を内化し、表現し、昇格・環流させることで人間の知的活動と循環的に結びつく存在であることを示しています。 AIは内部昇格（Promotion）を通じて暗黙知を蓄積し、 人間は環流（Circulation）を通じてその成果を明示知として体系化します。 両者の協働によって、BoKは常に更新され、AIはより深い知識理解を獲得していきます。
展望
SimpleModelingでは、SmartDoxサイトが人間の文書とCMLモデルを統合し、 SmartDoxコマンドによってそれらをBoKへと変換します。 AIはRAGを通じてこのBoKを内化し、人間が記述した構造とAIが学習した知識を結びつけ、共有知識空間を形成します。
内化と環流を繰り返すことで、知識は人間とAIの協働の中で発展し、 BoKは拡張され、AIはより深い理解を獲得していきます。
この協調的な進化は、ソフトウェア開発と知識開発が融合するAI時代の 文芸モデル駆動開発 (LMDD, Literate Model-Driven Development)の未来を形づくるのではないかと期待しています。
参照
用語集
- BoK (Body of Knowledge)
-
SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。
- CML (Cozy Modeling Language)
-
CMLは、Cozyモデルを記述するための文芸モデル記述言語です。 SimpleModelingにおける分析モデルの中核を担うDSL（ドメイン固有言語）として設計されています。 モデル要素とその関係性を自然言語に近い文体で記述できるよう工夫されており、AIによる支援や自動生成との高い親和性を備えています。 CMLで記述された文芸モデルは、設計モデル、プログラムコード、技術文書などに変換可能な中間表現として機能します。
- DSL (Domain Specific Language)
-
DSL（ドメイン固有言語）は、特定の領域（ドメイン）に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。 一般的な汎用プログラミング言語（GPL）に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。
- RDF
-
W3C により標準化された、情報を「主語–述語–目的語」の三つ組（トリプル）で表現するための知識記述モデル。
- 知識グラフ (knowledge graph)
-
現実の概念・事物・出来事をノードとし、その関係をエッジとして表す意味的グラフ構造の知識ベース。
- 知識内化 (knowledge assimilation)
-
RAGを通じてBoKから取得した知識を、一時的にAIの推論内部で取り込むプロセス。 セッション内の推論を強化するが、AIモデルのパラメトリック知識を恒久的に変更するものではない。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- 検索強化生成 (RAG, Retrieval-Augmented Generation)
-
生成AIが内部（パラメトリック）知識だけでなく、外部の知識ソースを検索してから応答を生成する技術。 RAGはまずデータベースや知識グラフなどから関連情報を検索し、それを文脈として取り込み、より正確で最新の応答を生成する。
- 生成AIリファレンス・アーキテクチャ (Generative AI Reference Architecture)
-
生成AIが内部で実行する知識活性化・内化・表現・昇格・循環の構造を整理したアーキテクチャ。
- 検索知識基盤 (Retrieval Knowledge Base)
-
検索知識基盤（Retrieval Knowledge Base, RKB）とは、RAG（検索強化生成）が利用できるように最適化された非パラメトリック知識（Non-parametric Knowledge）の構造化サブセットである。 SmartDox文書・用語集・セマンティックメタデータを索引化して保持し、生成AIが明示的知識を文脈として参照できるようにする。 RAGとの相互作用を通じて、外部明示知識をAI内部の中間知識（Assimilated Knowledge）へと同化させる橋渡しの役割を果たす。
- パラメトリック知識 (Parametric Knowledge)
-
パラメトリック知識（Parametric Knowledge）とは、ニューラル・ネットワークのパラメータ（重み）に埋め込まれた暗黙的な知識を指します。 大規模言語モデル（LLM）などが事前学習（pretraining）を通じて獲得した統計的・分布的情報を内包しており、外部知識ベースに明示的に記述されていない知識を表現します。 RAG（Retrieval-Augmented Generation）においては、外部の非パラメトリック知識（non-parametric knowledge）と対比され、LLM自身が持つ「暗黙値」として機能します。
- プロンプト (Prompt)
-
RAGによって取得された知識を、AIモデルの推論プロセスに橋渡しするための構造化指示または文脈表現。 BoKに格納された構造化知識を、モデルが理解し行動・内化できる物語的／命令的形式に変換する。
- 内化知識 (assimilated knowledge)
-
知識活性化によって生成された文脈をもとに、AI内部で意味的に統合された知識状態。AIにおける「理解」に相当する。
- 知識昇格 (Knowledge Promotion)
-
BoKの構造化知識を再学習・ファインチューニングによりAIモデルのパラメトリック知識（PPK）へ恒久的に統合するプロセス。
- 文芸モデル駆動開発 (LMDD, Literate Model-Driven Development)
-
文芸モデル駆動開発（Literate Model–Driven Development, LMDD） は、自然言語による語りと形式的なモデル構造を統一されたテキスト基盤上で統合するソフトウェア開発手法です。従来のモデル駆動開発（MDD）を拡張し、ドキュメントとモデルを単一の整合的ソースとして扱います。 LMDDでは、開発成果物の記述要素と構造要素をSmartDox言語を用いて同時に表現します。この統合的な表現から、ModelDoxが構造データを抽出し、CML（Cozy Modeling Language）がドメイン固有モデルを定義し、Cozyが実行可能なコード、ドキュメント、構成情報などの成果物を生成します。 人工知能（AI）は、語りの文脈を解析し、構造の整合性を検証し、モデルおよび生成成果物の改良を支援することでLMDDプロセスに関与します。すべての成果物はテキスト形式で表現されるため、トレーサビリティ、バージョン管理、標準的な開発環境との相互運用性が確保されます。 ドキュメント、設計、実装の間に形式的かつ機械可読な関係を定義することにより、LMDDは人間による記述と機械による推論が同一の表現層で機能する、AI支援型モデル駆動開発の基盤を提供します。