モデル・ハーネス — モデルでソフトウェアを記述する

第1回では、AI開発を支えるハーネスの全体像を示しました。モデル・ハーネスは、ソフトウェアをドメイン知識に近い抽象度で記述し、開発と実行の基盤にする役割を担います。第2〜4回でモデル・ハーネスを扱い、第5回のアーキテクチャ、第6回のプログラミング、第7回のランタイムへ進みます。第8回は知識ハーネスを扱い、用語集 (Glossary)で文芸モデル (Literate Model)とオブジェクト・モデル (Object Model)を結び、対応の整合を検査してMCP (Model Context Protocol, モデル・コンテキスト・プロトコル)からAIへ提供します。第9回は実行結果を投影した観測モデル、第10回は検証ハーネスを扱い、結果をモデルへ戻す流れを結びます。

前回シリーズでは、モデルをソフトウェアの記述・開発・実行の基盤にするモデル駆動開発を整理しました。モデルを検査・実行する仕組みは、AIの生成・変更にも制約を働かせます。オブジェクト・モデルは形式的な構造と振る舞い (Behavior)、文芸モデルは文脈・要求・シナリオ・判断、知識モデル (Knowledge Model)は概念の意味関係・根拠・出典を保持します。用語集が名称、意味、同義語、識別子 (Identifier)、適用する文脈を管理し、三つのモデルの対応を支えます。文章に残る業務知識も、開発中に参照・更新し続けます。

この基盤から、目的に応じてドメイン・モデル (Domain Model)、ユースケース・モデル (Use Case Model)、アプリケーション・モデル (Application Model)を組織します。静的・動的という区分は、それぞれの構造と振る舞いを見る観点です。ドメインにも振る舞いがあり、アプリケーションにも構造があります。明示された参照や制約の不整合を機械で検出し、業務上の意味の一致は人間が判断します。知識の整備・提供・受理の仕組みは第8回で詳述します。

前回整理した静的モデルの概念・要素・関係・規則は、ソフトウェアの構造を記述する基盤になります。動的モデルの振る舞い・協調・状態遷移は、状態機械やワークフローとして明示できます。人間とAIが同じ抽象度で構造と振る舞いを扱い、処理系がその記述を検査・実行します。

第2回は、モデルでソフトウェアを記述し、処理系の解釈・検査・実行によって制約を働かせる共通原理を扱います。第3回では静的な構造、第4回では状態機械を含む動的な振る舞いを具体化します。二つは同じソフトウェアの相互に対応する側面として扱います。

モデル駆動開発の動機は、ドメイン知識とのインピーダンス・ミスマッチ、すなわち業務の概念とプログラムの表現の隔たりを小さくしたいという動機です。概念・関係・規則を、実装の都合に合わせた別の語彙や構造へ大きく置き換えるほど、理解と変更の負担が増えます。モデルを用いることで、ドメインの表現に近い抽象度でソフトウェアを記述し、生成・変更の対象にできます。

開発者がモデルでソフトウェアを記述し、不足する実装をAIが補完する構成では、モデルが事実上のプログラミング言語になります。SimpleModeling (シンプルモデリング)では、CML (Cozy Modeling Language)で記述した実行可能モデル (Executable Model)をTextusが直接実行し、モデルだけでは不足する実装をAIがプログラミング言語で自動補完します。開発者は補完部分の実装詳細を直接扱う負担を減らし、モデル上の概念・関係・規則・振る舞いに集中できます。

動的な振る舞いには状態機械を用います。通常のプログラミング言語では、状態 (State)、イベント (Event)、遷移条件、遷移先が変数・条件分岐・イベント処理へ分散しがちです。状態機械は、これらを一つの構造として明示します。人間とAIが許される振る舞いを同じ構造で捉え、処理系が検査・実行できることが利点です。状態機械を含む動的モデルの詳細は第4回で扱います。

モデル駆動開発で記述・開発・実行の基盤とするモデルを、処理系が静的検査し、実行可能モデルを直接実行します。記述した構造・規則・振る舞いが、実際の開発と動作を規定します。この仕組みは、AIが生成・変更するモデルと補完実装にも制約を働かせます。モデルに記述した制約を検査と実行に組み込むことが、モデル・ハーネスとして機能する根拠です。

CMLの文法は、処理系が扱うモデル要素と構造を定めます。BoK (Body of Knowledge)は用語集を管理し、共通の意味と識別子を介して文芸モデル、オブジェクト・モデル、知識モデルを連携させます。AIが生成・変更で参照する意味の基盤を、プロジェクトの外部知識として保持できます。

textus-cbd-supportのレビューは、実行可能モデルとユースケースなどの非実行モデルを対象に、モデル上の矛盾を検証します。ビルド時の静的モデル検査は、構造や規則の矛盾・制約違反を実行前に確認します。Textusは実行可能モデルを直接動作させ、実行時にもモデルの制約を作用させます。レビュー、静的検査、直接実行が重なって働き、検証結果を根拠に人間が修正と採否を判断します。

CMLはモデルを記述する言語、Cozyはモデルからソフトウェアへの変換を担うツール、Textusは実行可能モデルを動作させる実行系です。完全なプログラムに必要な実装のうちモデルだけでは不足する部分を、AIがプログラミング言語で自動補完します。モデルの直接実行と実装の補完を組み合わせることで、開発者がモデルの抽象度で開発を進める基盤を作ります。補完実装にもモデルの構造・規則・振る舞いを反映させます。補完コードの型 (Type)や実装規律は、第6回のプログラミング・ハーネスで扱います。

モデルとして記述したソフトウェアが何を実現するかは、要求モデルとの対応を通じて確認します。要求、ユースケース、構造・振る舞い、実現先の対応と判断根拠を保持することで、形式的な整合性と利用者の目的への適合をそれぞれ確認できます。追跡性は、モデルによる記述・検査・実行を支える確認の仕組みになります。

要求から直ちに実装へ進むと、AIが補った前提や業務上の選択がコードに分散し、要求との対応を確かめる負担が増えます。前提と選択をモデルに明示し、実現先へ対応付けておけば、変更した理由と影響する範囲を確認できます。

モデル・アップ・ダウンは、SimpleModeling独自のモデル開発の考え方です。モデルダウンは要求やモデルを具体化して実現へつなぎます。モデルアップは、モデルからレビューの目的に応じて抽象化したモデルを導出し、表示します。開発と実行に用いるモデルを、ステークホルダーが理解しやすい表現でも扱えるようにします。

モデルダウンの例として、ユースケースの意図を実行へ具体化します。ドメインの事実・規則とユースケースの目的・シナリオを対応付け、アプリケーション・モデルや受理されるコマンドへ具体化します。識別子と判断根拠を各段階に保持し、要求した意味と実現先との対応を追えるようにします。

自然言語の意図を実行へ接続する際は、型付き意図やコマンドへ変換します。対象、値、事前条件 (Precondition)、認可を検証できる形にすることで、アプリケーションの受理条件を明示できます。

ユースケース・ハーネスでは、ユースケースの目的やシナリオを、対応するモデルの状態・操作や実行確認の結果と照合します。CMLによる構造の検査とAIを活用した意味の照合を併用し、ステークホルダーが要求との一致を判断します。これは、要求と実現の対応を検査する仕組みです。

モデルアップの典型例は、状態機械で記述したワークフローを、フローチャートやアクティビティ図のようなフロー図へ変換することです。状態や遷移 (Transition)の詳細をレビューの目的に応じて抽象化し、業務の流れを確認できるモデルとして表示します。ユースケース・モデルからアクター・ゴール一覧を作り、登場人物と目的の対応を確認することもモデルアップの例です。実行確認を行ったモデルからレビュー用の抽象モデルを導出すれば、ステークホルダーは実行に用いたモデルを起点に要求との適合を確認できます。元のモデルとの対応を保持することで、指摘を開発中のモデルへ戻せます。要求モデルのハーネスでは、この仕組みが実行に用いるモデルとステークホルダーによるレビューをつなぎます。

ドメイン・モデルは対象世界の事実・概念・規則を表します。アプリケーション・モデルは利用者の目的に沿ってドメインの機能を組み合わせます。共通の業務規則と状態管理をドメインに、アプリケーション固有の協調 (Collaboration)と流れをアプリケーションに配置することで、異なるニーズを持つ複数のアプリケーションから共通ドメインを利用できます。

利用者のニーズや利用環境の変化は、アプリケーション・モデルを更新する契機になります。対象世界の新しい事実や業務そのものの変化は、ドメイン・モデルを更新する契機になります。変更の理由をこの区分に対応付け、共通ドメインを変更する場合は、それを利用するアプリケーションへの影響も確認します。

ユースケース群から、利用者に提供するアプリケーション・ケーパビリティを抽出します。個々のシナリオからは、実現に必要なコンポーネント・ケーパビリティを抽出します。ケーパビリティ (Capability)は、提供する働きをモデルとして管理するための中間表現です。実行時には、対応付けられた操作 (Operation)やワークフローが動作します。

ケーパビリティから、実現する操作・ワークフローと検証例への対応を保持します。実現方法を変更しても、提供する働きとその確認方法を追えることが、この中間表現の利点です。

一般的な構造・振る舞い・規則を持つ実行可能モデルを実装へ対応付けます。シナリオや相互作用の具体例を表す実行例モデル (Execution Example Model)は、検証例へ対応付けます。両者と実行結果を照合することで、規則と具体的な動作の関係を確かめ、モデルを改善できます。

モデルとビュー (View)は、明確性・一貫性・妥当性・正確性の四尺度で評価します。同じ意味に解釈できるか、定義や関係が衝突しないか、目的に必要な関心に答えるか、事実と規則が現実に合うかを確認します。構造検査に加えて、利用者やドメインエキスパートの判断、観測・実行結果を用います。

性能・信頼性・セキュリティなどは、実現するソフトウェアの品質属性 (Quality Attribute)です。要求、モデル、アーキテクチャ、実装、実行を横断して確認し、各ハーネスの検査と証拠を後続の検証ハーネスで結び付けます。

目的と関心に応じたビューに、要求との対応、候補の差分、根拠、変更影響、検証結果を投影します。元のモデルと用語集が意味と識別子を保持し、ビューが判断に必要な情報を示します。業務上の意味、優先順位、候補の採否は人間が判断します。

注文確定では、注文・決済・在庫予約の概念と関係を静的モデルで表し、決済の成否に応じた状態遷移を動的モデルで表します。決済失敗後に在庫予約をどう扱い、どの監査記録を残すかを業務規則として明示し、実現する操作と検証例へ対応付けます。実行結果を照合すれば、要求した失敗時の扱いが実現されているかを確認できます。ここでは対応を説明する例として用います。

モデル・ハーネスは、ドメイン知識に近い表現でソフトウェアを記述し、処理系の検査と実行によって生成・変更を制約する基盤です。要求モデルとの対応を保持し、ソフトウェアが果たす目的も確認します。第3回では概念・関係・規則による静的な構造、第4回では状態機械を含む動的な振る舞いを具体化します。