SimpleModelingが目指してきたもの

記事の全体像

第2回の全体像: SimpleModelingが構築してきた実現経路と、AIが実用的にする知識からモデルへの変換を示します。 summary ja

シリーズにおける位置付け

第1回では、ドメインモデルが実装への経路を持つworking abstractionになることで、人間の仕事の中心がコードからモデルへ移り、ソフトウェア開発方法論 (Software Development Methodology)をモデリング中心に再構築する必要が生まれることを説明しました。本稿では、その実現経路をCML、Cozy、AI、Textusの役割に分けて具体化します。

第2回では、SimpleModelingがAI以前から構築してきたModelからExecutable Softwareへの経路と、AIによって変化するKnowledgeからDomain Modelへの工程を整理します。

前回の記事: 📄 なぜソフトウェア開発方法論を再構築するのか

出発点

SimpleModelingの出発点は、モデルを単なる設計文書として扱わないことです。

Model
  ↓
Executable Software

モデルが実装と切り離されていれば、設計時には有用でも、開発が進むにつれてコードとの乖離が生まれます。モデルの変更を実装へ反映し、実装の状態 (State)をモデルへ戻す作業も人間に依存します。その結果、モデルは次第に参照されなくなります。

SimpleModelingは、モデルを実装と実行へ接続された開発上の表現として扱うことを追求してきました。

CMLとDSL

CMLは、SimpleModelingのモデルを記述するための文芸モデル記述言語です。オブジェクト (Object)、型 (Type)、関係、制約 (Constraint)、振る舞い (Behavior)などを、機械が処理できる構造として記述します。

DSLは、特定領域の概念や操作 (Operation)を、その領域に合った語彙で表現します。対象領域の意味を保ち、解釈や変換が可能な表現にします。

CMLとDSLは、モデルをプログラム、設定、技術文書などへ変換できる中間表現にします。

文芸モデリング

形式的なモデル構造は、オブジェクト、型、関係、制約などを明確にします。構造を選んだ理由、根拠となる業務知識、前提の説明には自然言語も必要です。

文芸モデルは、自然言語による語りと形式的なモデル構造を同じ文書で扱います。人間が設計意図と文脈を読み取れる一方で、ツールやAIは文書構造とモデル要素を処理できます。これにより、知識、説明、モデル、生成物を一つの流れへ接続します。

SimpleModelingは、モデルを人間の理解と機械処理の両方へ接続する方法として、AI以前から文芸モデリング (Literate Modeling)を進めてきました。

CozyとTextusによる実現

モデルを実行可能ソフトウェアにするには、モデルを解釈し、必要な成果物へ変換し、実際に動作させる実現経路が必要です。

Cozyは、CMLや各種DSLを処理し、プログラム、設定、文書などを生成して、CMLを実行可能ソフトウェアへ変換します。変換規則だけでは生成しきれない固有の実装部分はAIが補完します。Textusは、得られた実行可能ソフトウェアを動作させるSimpleModelingの実行プラットフォームです。

Textusは、Security (セキュリティ)、Observability、Performance (性能)、Resiliency、Availabilityなどの品質属性 (Quality Attribute)を実行基盤側で提供する方向を取ります。アプリケーションは固有のドメインロジックに集中し、共通の実行品質は実行基盤へ集約します。

このように、SimpleModelingはAI以前から、CML、DSL、文芸モデル、Cozy、Textusによって、ModelからExecutable Softwareへ至る経路を構成してきました。

残されていた工程

一方で、モデルの手前には、もう一つの変換があります。

Knowledge
  ↓
Domain Model

ここでいうKnowledgeは、業務の用語、規則、事例、要求、制約、判断の根拠などです。Domain Modelは、この知識を開発目的に応じて構成した問題領域へのView (ビュー)です。

用語集は言葉の意味と境界を明確にし、ユースケースは業務シナリオに対するモデルの妥当性を確認します。文芸モデルは知識とモデル構造を同じ文書へ置きます。これらの技術はKnowledgeからDomain Modelを構成する作業を支えてきました。

しかし、どの知識を選び、どのViewから捉え、どのオブジェクトや制約として構成するかという変換の主体は、ほぼ人間でした。ModelからExecutable Softwareへの自動化が進んでも、その手前は大きな人手の工程として残っていました。

AIが実用的にするもの

AIは、構造化された知識と自然言語の両方を読み、用語の整理、関連知識の探索、矛盾や不足の発見、モデル案の構成を支援できます。これによって、KnowledgeからDomain Modelへの変換を、人間だけの作業から協業の工程へ変えられます。

ドメインモデルの精度は、ドメインエキスパート、開発者、AIの協業によって高めます。ドメインエキスパートは業務上の妥当性を確認し、開発者は構造、制約、整合性、実現可能性を確認します。AIは知識の整理とモデル化を支援します。三者が結果を確認し、知識とモデルへフィードバックします。

さらにAIは、CozyによるCML変換を補完します。Cozyがモデル変換規則に基づいて実行可能ソフトウェアを生成し、その規則だけでは表現しきれない固有の実装詳細をAIが補います。方法論におけるAIの役割は、知識からモデルを構成する協業と、Cozyの変換結果に残る実装部分の補完です。

橋渡しとしてのBoK

この協業には、ドメインエキスパート、開発者、AIが参照できる共通の知識基盤が必要です。SimpleModelingでは、この役割をBoK (Body of Knowledge)が担います。

BoKは、知識をHTML（Web）として人間へ公開し、AIにはMCP (Model Context Protocol, モデル・コンテキスト・プロトコル)を通して提供します。また、実行可能な知識や機能はコンポーネント (Component)として開発者とAIが利用できます。これにより、同じ知識を起点に議論し、モデルを更新できます。

BoKは、文芸モデリングが接続してきた知識とモデルの関係を、AIとの協業へ拡張する橋渡しです。RDF、Embedding (埋め込み)、RAG (Retrieval-Augmented Generation, 検索強化生成)、MCPなどの内部構成はKnowledge Modeling (知識モデリング)の回で扱い、ここでは方法論の歴史上の役割に焦点を当てます。

つながった開発経路

これまでの流れを一つにすると、SimpleModelingが対象とする開発経路は次のようになります。

Knowledge
  ↓  Domain Expert + Developer + AI
Domain Model
  ↓  Expressed as CML
CML
  ↓  Cozy Transformation + AI Completion
Executable Software
  ↓  Runs on Textus
Execution

Knowledgeは何を作るべきかの根拠を提供します。Domain Modelは問題領域を開発目的に応じたViewとして表し、CMLとして記述されます。CozyはCMLを実行可能ソフトウェアへ変換し、AIはCozyが変換しきれない実装部分を補完します。Textusは、その実行可能ソフトウェアを動作させます。

この経路では、実行結果、テスト (Test)、利用者の評価から得られた知見を、ユースケース、用語集、BoK、ドメインモデルへ戻し、反復的に精度を高めます。

変わらないことと変わったこと

観点	変わらないこと	変わったこと
目標	モデルを実行可能ソフトウェアへ接続します。	Knowledgeから実行までを一つの協業的な経路として扱えます。
モデル	モデルをCMLとして記述し、開発の中心的な表現として扱います。	AIが知識整理とCozyの変換結果の補完へ参加します。
人間の仕事	目的、意味、責務、制約を判断します。	知識整理と実装の一部をAIと分担します。
実現	CozyがCMLを実行可能ソフトウェアへ変換し、Textusが実行します。	AIによる実装部分の補完がCozyの変換経路へ加わります。

観点

変わらないこと

変わったこと

目標

モデルを実行可能ソフトウェアへ接続します。

Knowledgeから実行までを一つの協業的な経路として扱えます。

モデル

モデルをCMLとして記述し、開発の中心的な表現として扱います。

AIが知識整理とCozyの変換結果の補完へ参加します。

人間の仕事

目的、意味、責務、制約を判断します。

知識整理と実装の一部をAIと分担します。

実現

CozyがCMLを実行可能ソフトウェアへ変換し、Textusが実行します。

AIによる実装部分の補完がCozyの変換経路へ加わります。

SimpleModelingは、CMLをCozyで実行可能ソフトウェアへ変換し、Textusで実行する技術を継続して開発してきました。AIは、従来ほぼ人間が担っていたKnowledgeからDomain Modelへの工程を協業可能にし、Cozyが変換しきれない実装部分を補完します。これにより、KnowledgeからExecutable Softwareへの経路を実務的な開発方法論として構成できます。

次回

ここまでで、方法論を再構築する理由と、SimpleModelingが目指してきた歴史的な方向性を確認しました。次回は「モデリング技術体系 (Modeling Technology System)」として、既存のソフトウェア工学技術をどのような設計判断に基づいて方法論へ組み込むのかを説明します。

参照

サイト内

📄 なぜソフトウェア開発方法論を再構築するのか

外部参照

用語集

Cozy Modeling Language (CML): CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
Cozy: Cozyは、CMLと各種DSLで記述されたModelを解析し、プログラム、設定、文書などの実現成果物へ変換するSimpleModelingのツールチェーンです。
Textus: Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。
シンプルモデリング (SimpleModeling): SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
モデル (Model): Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
DSL (Domain Specific Language): DSL（ドメイン固有言語）は、特定の領域（ドメイン）に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。一般的な汎用プログラミング言語（GPL）に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。
文芸モデル (Literate Model): Undefined
依存 (Dependency): UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
用語集 (Glossary): Glossaryとは、対象領域で使用する用語について、名称、意味、境界、同義語、識別子を管理する知識資源です。関係者が同じ用語を同じ意味で扱うための共通基盤になります。
ユースケース (Use Case): UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
ソフトウェア開発方法論 (Software Development Methodology): Software Development Methodologyとは、ソフトウェア開発で使用するモデル、モデル変換、技術、設計原則、判断規則を一つの体系として定める方法論です。何をモデル化し、モデルをどのように構成し、実行可能ソフトウェアへ接続するかを定義します。一般的な用法では、Software Development MethodologyがDevelopment Processを含む場合もあります。SimpleModelingでは、モデルとモデル変換を定めるMethodologyと、それを開発実務で運用するDevelopment Processを分離して扱います。
状態 (State): UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
オブジェクト (Object): Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。
制約 (Constraint): UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
振る舞い (Behavior): UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
型 (Type): Undefined
操作 (Operation): UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
文芸モデリング (Literate Modeling): Undefined
セキュリティ (Security): Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。
品質属性 (Quality Attribute): Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。
性能 (Performance): Performanceとは、指定された条件と資源のもとで、システムが処理時間、応答時間、Throughput、容量などの時間的要求を満たす性質です。
ビュー (View): Viewとは、Modelを特定のPurposeとConcernに応じて選択し、理解、判断、検証、利用できる形で投影した表現です。ViewはModelの一部を見せるものであり、元のModelとは別に意味を所有しません。
BoK (Body of Knowledge): SimpleModelingでは文脈共有の核となる知識体系をBoK (Body of Knowledge)と呼んでいます。 BoKの構築は、知識の共有、教育、AIによる支援、自動化、意思決定支援を可能にするための基盤です。
モデル・コンテキスト・プロトコル (MCP, Model Context Protocol): モデル・コンテキスト・プロトコル（Model Context Protocol、MCP）とは、生成AIを利用するアプリケーションと外部のデータ源やツールを接続し、コンテキストと機能を標準化された形で提供するためのオープンプロトコルです。
コンポーネント (Component): 責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
RDF: W3C により標準化された、情報を「主語–述語–目的語」の三つ組（トリプル）で表現するための知識記述モデル。
知識モデリング (Knowledge Modeling): Undefined
埋め込み (Embedding): 埋め込み（Embedding）とは、文章、用語、モデル要素などを、その意味上の近さを計算できる数値ベクトルへ変換した表現です。類似検索や候補抽出に利用します。
検索強化生成 (RAG, Retrieval-Augmented Generation): 生成AIが内部（パラメトリック）知識だけでなく、外部の知識ソースを検索してから応答を生成する技術。 RAGはまずデータベースや知識グラフなどから関連情報を検索し、それを文脈として取り込み、より正確で最新の応答を生成する。
テスト (Test): Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。
アスペクト (Aspect): アスペクト(Aspect)とは、複数のモデル要素や振る舞いを横断して確認する条件、性質、関心事です。品質属性を中心とし、必要に応じて品質属性だけでは表し切れない横断的な条件も含みます。
責務 (Responsibility): Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
実現関係 (Realization): Undefined
モデリング技術体系 (Modeling Technology System): Undefined