SimpleModelingにおける知識処理モデル
本稿では、SimpleModeling (シンプルモデリング)における知識を現実世界へ落とし込むメカニズムとして、知識から実行への変換過程を簡潔に定義します。Embedding・RDF・Type・DSL・Interpreter・Effectを経て現実への作用に至り、全体はContextにより横断的に制御されます。
知識処理モデル
SimpleModelingでは、知識は単なる情報の蓄積ではなく、実行可能な構造へと変換される対象です。本モデルは、その変換過程を明示的に定義します。
この図は、知識が現実世界に作用するまでの全体構造を表しています。
Type
Typeは意味を厳密な構造として定義します。
-
Entity / Value
-
制約 (Constraint)（invariant）
-
型安全性
CML (Cozy Modeling Language)で記述します。
文脈
アプリケーションの文脈によって各層の処理が影響を受けます。
例えば、同じユーザー登録処理でも、開発環境ではメール送信を行わずログ出力に置き換え、本番環境では実際にメールサービス（SES等）を利用する、といった振る舞いの違いがContextによって制御されます。また、B2BアプリケーションではorganizationIdが必須となる一方、個人向けアプリでは不要になるなど、Typeの構造自体もContextに依存 (Dependency)して変化します。
Contextはこの目的で使用する全ての層に作用する横断的要素です。
圏論的基盤
モデルを圏論の観点で整理することで、構造の一貫性やシンプルさを検証できます。特に、オブジェクト (Object)と射の分離、合成の自然さ、変換の一貫性といった観点で、設計の健全性を確認する補助線として機能します。
圏論でモデル化することで直接のメリットがあるわけではありませんが、筋のよいモデルであることを担保するため補助線になると考えています。
本モデルは圏論的に一貫した構造として理解できます。ここでは関手・自然変換・随伴の観点から整理します。
自由構造とDSL
Type → DSL(AST)（Free）
function : Type → Type（Morphism）
procedure : Type → Effect[Type]（Kleisli Morphism）自然変換
Interpreterは自然変換として理解されます。DSLからEffectへの写像です。
Interpreter : DSL ⇒ Effect自然変換とは、構造を保ったまま意味を与える写像です。
随伴
随伴は構造を付与する操作 (Operation)と、それを忘れる操作の最適な対応関係です。
F : Concept → Program
G : Program → Concept
F ⊣ Gここで：
文脈の役割
Contextは自然変換を決定するパラメータとして理解できます。
Context → (DSL ⇒ Effect)つまり、Contextによって異なるInterpreter（自然変換）が選択されます。
対応関係
本節では、各要素の対応関係を簡潔に整理します。
本モデルは以下の圏論的対応として整理できます。
Contextはこの全体に作用するメタレイヤーです。
この構造により、SimpleModelingは「意味→構造→実行」の変換を理論的に一貫した形で扱うことができます。
圏論は実装のための必須知識ではありませんが、この観点で自然に記述できる構造であることは、モデルがシンプルかつ一貫していることの強い指標となります。
まとめ
SimpleModelingの知識処理モデルは、意味（Embedding/RDF）から構造（Type）、さらに計算（DSL）を経て実行（Interpreter/Effect）へと至る一貫した変換体系です。
このモデルにおいて、Typeはオブジェクトとして意味を固定し、DSLは射として計算を構成します。Interpreterは自然変換としてDSLに意味を与え、Effectとして実行可能な計算に変換します。
そして、Effectの評価（run）によって初めて現実世界に作用が現れます。
Contextはこの全体を横断して作用し、各層の解釈と実行のあり方を決定します。
この構造により、SimpleModelingは知識を単なる記述としてではなく、構造化され、合成可能で、実行可能なモデルとして扱うことができます。
参照
用語集
- 埋め込み (Embedding)
-
埋め込み（Embedding）とは、文章、用語、モデル要素などを、その意味上の近さを計算できる数値ベクトルへ変換した表現です。類似検索や候補抽出に利用します。
- RDF
-
W3C により標準化された、情報を「主語–述語–目的語」の三つ組（トリプル）で表現するための知識記述モデル。
- 型 (Type)
-
Undefined
- DSL (Domain Specific Language)
-
DSL（ドメイン固有言語）は、特定の領域（ドメイン）に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。 一般的な汎用プログラミング言語（GPL）に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- 制約 (Constraint)
-
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
- 型安全 (type safety)
-
型安全とは、プログラムにおける型の整合性をコンパイル時または実行時に保証する性質を指します。 型安全性が保たれているとき、ある型に対して定義されていない操作を実行しようとした際にエラーとして検出され、 意図しない動作やバグの発生を防ぐことができます。 Scalaは強い静的型付けと型推論を併用することで、高い型安全性を維持しつつ柔軟なプログラミングを可能にしています。
- Cozy Modeling Language (CML)
-
CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
- 振る舞い (Behavior)
-
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
- 依存 (Dependency)
-
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- オブジェクト (Object)
-
Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。
- モデル上の相互作用 (Interaction)
-
Undefined
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。