SimpleModelingが目指してきたもの

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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