動的モデル・ハーネス — 業務の振る舞いを記述する

処理の順序、状態遷移、待機、失敗後の再試行や補償は、通常のプログラミングでも誤りが生じやすい部分です。個々の操作 (Operation)が正常に動いていても、在庫確保と支払い承認より先に注文を確定したり、失敗後に通常経路を続けたりすれば、業務の規則に反します。ワークフローと状態機械でこれらの規則を明示し、処理系が検査・実行するモデル駆動開発は、AIの利用にかかわらず有用です。

AIに振る舞いの実装を任せたとき、局所的に書きやすい手続型コードを積み重ねると、条件分岐、フラグ、コールバック、再試行ループなどへ規則が分散します。その場の処理を成立させる修正でも、全体の順序や状態遷移、失敗時の規則を崩すことがあります。こうした生成・変更の逸脱 (deviation)を抑えるには、AIへの指示に加えて、何らかの仕組みで実装と実行に制約を働かせるハーネスが必要です。

SimpleModelingでは、このハーネスを構成するためにワークフローと状態機械を提供します。業務の規則をドメイン知識に近い抽象度でCMLに記述し、AIが生成・変更したモデルと補完実装を検査します。Textusは定義されたワークフローと状態機械を直接実行し、処理の進行と状態遷移をモデルの規則に従わせます。この定義・検査・実行の枠組みによって、AIが実装できる振る舞いと実行できる経路を制約します。

この枠組みの出発点は、モデルでソフトウェアを記述し、開発と実行の基盤にするモデル駆動開発です。規則を参照用の文書や図に置くだけでなく、CMLで定義し、処理系が検査・実行するため、AIへの指示や注意事項にとどまらない制約になります。人間は業務上の意味をモデルで判断し、AIはその規則に従うモデル案や補完実装を作成します。

第2回では、モデル駆動開発の基盤がAI活用のハーネスとして機能することを扱いました。第3回の静的モデル・ハーネスは、対象の同一性 (Identity)、型 (Type)、分類、所有、関係などの構造を制約します。第4回は、操作の順序、状態遷移、失敗時の進行を制約する動的モデル・ハーネスを扱います。前回シリーズの動的モデルの考え方を、SimpleModelingの検査・実行と要求の実現を確認する枠組みへつなぎます。

静的モデルと動的モデルは構造と振る舞いを表し、ドメイン・モデル (Domain Model)とアプリケーション・モデル (Application Model)は目的と関心によって分かれます。分類の軸は異なりますが、それぞれのモデルには記述の中心があります。ドメイン・モデルは静的モデルが中心で、アプリケーション・モデルはユースケース (Use Case)を起点とするワークフローが中心になります。

ドメイン・モデルは、対象世界の概念、構造、関係、規則を表す静的モデルを中心に構成します。注文の例では、注文・明細・商品の構造や関係を表します。

アプリケーション・モデルは、ユースケースを起点に、利用者の目的を実現するワークフローを中心に構成します。注文確定では、在庫確保、支払い承認、注文確定というドメインの操作や機能を組み合わせます。

SimpleModelingでCMLに記述する動的モデルは、状態機械、ワークフロー、ユースケースの3種類です。ワークフローと状態機械は、一般規則から処理の進行や状態変化を定める演繹モデルです。CMLで定義したこれらの規則をTextusが解釈して直接実行するため、モデルがプログラムとして働きます。

ユースケース・モデル (Use Case Model)は、利用者の目的と具体的なシナリオを記述する帰納モデルです。そのまま動作させることはできませんが、実現すべき要求を表すモデルとして有効です。実例ベースで要求を確認し、対応するワークフローや状態機械との接続をモデル上で検査するために使います。

この違いを知っておくと、実行可能モデル (Executable Model)が振る舞いを制約し、要求モデルとの接続がその振る舞いの目的への適合を確かめる、という役割を理解しやすくなります。以降は、ワークフローと状態機械の定義・実行を先に説明し、ユースケース・モデルとの接続を扱います。

ワークフローは、目的を実現する操作や処理を、順序、分岐、並行処理、待機、完了条件として定義します。注文確定のワークフローは、ユースケースの目的を実現するアプリケーション・モデルです。在庫確保、支払い承認、注文確定を順に進め、先行する結果に応じて次の処理を選びます。個別の注文に共通して適用する進行規則をCMLに記述し、Textusがその規則に従って処理を進めます。

アプリケーション側のワークフローが複数の処理の進行を定め、ドメイン側の注文の状態機械が対象の状態変化を定めます。注文確定のワークフローは、注文の状態機械が許す操作と遷移 (Transition)を利用します。ワークフロー自身も実行中や外部応答待ちといった状態 (State)を持ち得ますが、注文の状態と処理の進行状態は区別し、操作とイベントを通して対応付けます。

状態機械は、対象が取り得る状態と、イベントに応じて許される遷移を記述します。現在の状態、受け取るイベント、遷移条件、遷移先、遷移に伴う処理を対応付けます。状態名だけでなく、その状態で何ができ、どの条件で次の状態へ進めるかをモデルにします。

注文の状態機械は、ドメイン・モデルに含まれる動的モデルです。作成中、確定処理中、確定済みという状態を置きます。作成中は明細0件を認めますが、確定処理を始めるときには明細1件以上を求めます。在庫確保と支払い承認が成立してから確定済みへ進むようにし、必要な処理を飛び越える遷移を認めません。これらは例題の業務規則であり、アプリケーション側のワークフローから利用する際にも適用します。

遷移が該当しない場合、条件を満たさない場合、条件の評価自体が失敗した場合の扱いも定めます。複数の遷移が候補になるなら、排他性や優先順位など、処理系が選択できる規則が必要です。単に状態名を列挙するだけでは、これらの振る舞いは確定しません。

ワークフローと状態機械で扱う対象は、第3回のエンティティ、値、関係と対応します。注文O-101が持つ明細、その明細が参照する商品P-1、数量と金額を、静的モデルと同じ意味で使います。オペレーションには、対象の責務 (Responsibility)と入力・結果の型、事前条件・事後条件を記述します。モデルから利用する操作を、実在する対象と契約へ結び付けます。

処理を求める操作やコマンドと、起きた結果を表すイベントを区別します。「注文を確定してほしい」という要求は、「注文が確定した」という事実とは異なります。必要な条件と処理が成立した結果をイベントとして扱い、その結果に応じて対象の状態を変えます。

同じ注文O-101で、在庫確保後に支払いが拒否された場合を考えます。ワークフローには在庫解放を行う失敗分岐を定義し、注文の状態機械では確定済みへ進めないようにします。補償は実行済みの処理に対して業務上必要な後続処理を行うものであり、外部効果を必ず元に戻せることを意味しません。補償の失敗や人間の対応も扱います。

外部サービスが時間内に応答しない場合、処理が失敗したのか、成功したが応答を受け取れなかったのかを区別する必要があります。結果照会、待機期限、再試行の条件と上限、重複実行への対策、対応を人間へ戻す条件をモデルと実行契約に含めます。結果が不明なまま成功または失敗として先へ進めないことも、動的モデルが示す制約です。

CMLで定義したワークフローと状態機械は、演繹モデルとして処理と遷移の規則を持ち、Textusがそのまま直接実行します。注文確定でも、在庫確保と支払い承認を経て確定する順序と、注文の遷移条件が実行に適用されます。モデルが振る舞いを説明する文書であるだけでなく、実際に動作するソフトウェアの記述になります。

この直接実行が、「モデル＝AI時代のプログラム」という考え方を具体化します。モデルだけでは不足する実装はAIがプログラミング言語で自動補完するため、開発者はドメインの概念と規則によるモデル記述を中心に作業できます。補完する実装にも、モデルで定めた型、操作の契約、実行条件を適用します。

ユースケース・モデルには、利用者が達成したい目的とシナリオを要求として記述します。注文確定の例では、在庫と支払いの条件を満たす注文を確定することを目的とし、作成中の注文、確定を求める操作、期待する結果を記述します。ユースケース自体を実行するのではなく、その要求を実現するワークフローと状態機械へ対応付けます。

ユースケースのシナリオには、注文確定の要求に続いて在庫確保を求め、その成功後に支払い承認を求め、承認された結果を受けて注文を確定する流れを記述します。誰がどの対象に操作を求め、どの結果を受け取るかを具体化すると、必要な操作と、その操作を受け持つ対象が明らかになります。

ユースケース・モデルと実行可能モデルの接続も、モデルとして記述します。注文確定のユースケースを起点に、アプリケーション側の注文確定ワークフローが要求を実現し、そのワークフローがドメイン側の操作と注文の状態機械を利用する対応を明示します。シナリオ中の操作を各オペレーションへ、前提と期待する結果を対象の状態と遷移条件へ結び付けます。失敗時や待機時のシナリオにも、対応する分岐・状態・結果を定めます。

要求モデルからアプリケーション側のワークフロー、ドメイン側の状態機械・構造・操作への接続も、ハーネスとして機能します。実行可能モデルが内部的に整合していても、利用者の目的を実現するとは限りません。要求に対応する経路や結果があるか、ドメインの規則と矛盾しないかを検査し、AIの生成・変更が要求から外れることを検出します。この対応をモデル化・検査することで、ユースケースの実現、すなわち要求の実現を担保します。要求と実現の接続は、モデル・アップ・ダウンとは別の概念です。

注文確定のユースケースを、実例ベースで検証します。正常系、支払い拒否、外部応答待ちのそれぞれについて、シナリオの目的・前提・結果と操作順序が対応しているかを確認します。実例で不足する条件が見つかったら、一般規則へ反映する対象を整理します。

次に、ワークフローと状態機械の規則で、これらの実例を照合します。オペレーションの契約とエンティティの構造・不変条件も組み合わせ、各実例の入力と状態から期待する処理と結果が導かれるかを確認します。対応しない場合は、実例の前提と一般規則の双方を見直します。有限の実例への適合だけで、全経路の正しさが証明されるわけではありません。

注文O-101のユースケースのシナリオを、まずオペレーションとエンティティへ突き合わせます。シナリオに登場する対象が存在し、その対象が操作の責務を持つか、注文・明細・商品の識別子や関係が整合するか、数量と金額、操作の入力・結果が型と不変条件 (Invariant)を満たすかを確認します。

接続モデルを使って、同じ実例をワークフローと状態機械へ突き合わせます。正常系の操作順序と遷移が対応付けられているか、支払い拒否時には在庫解放の経路があり、注文を確定済みにしないかを確認します。結果不明の実例も待機・照会の規則へ対応付けます。不整合があれば、要求の前提、実現先の規則、両者の接続を見直します。

これらはCMLで記述したモデル上で行う検査です。型、参照、入出力、処理間の接続の機械的な検査に加え、textus-cbd-supportによるレビューで、ユースケースと静的モデル、ワークフロー、状態機械の対応を確認し、ビルド時のモデル検査へ接続します。直接実行する対象ではないユースケースも、要求と実現の接続を検査することでハーネスとして機能します。AIによる意味の照合と人間による妥当性の判断も組み合わせます。

モデルの規則を処理系が解釈し、検査と実行に適用することで、AIが生成・変更できる範囲に制約が働きます。モデル検査をビルドに組み込み、状態変更や操作を契約に従う実行境界へ通します。モデル駆動開発のためのこの基盤が、AI活用にも有効なハーネスになります。規則を文章や図として参照するだけの場合とは、処理系が規則を適用する点で異なります。

モデル上の照合に使った注文O-101の実例を、実装を動かす検証にも引き継ぎます。正常系では必要な処理の後に確定済みとなるか、支払い拒否時には在庫解放が行われ確定済みとならないかを、実行結果から確かめます。モデル間の整合性と実装の動作は、別の確認対象として扱います。

第2回で扱ったモデル・アップ・ダウンは、モデルを具体化して実現へつなぐことと、目的に応じて抽象化したモデルを導出することです。ユースケースとワークフロー・状態機械の接続は要求と実現の対応を表し、モデル・アップ・ダウンは具体化・抽象化を表します。モデルの種類が異なることや、両者を対応付けることだけでモデルダウンとは扱いません。

モデルアップでは、実行するワークフローや状態機械から、業務の流れを確認しやすい抽象モデルや図を導出します。レビューの目的に応じて詳細を整理し、元のモデルとの対応を保つことで、人間が目的や業務規則への適合を確認し、指摘を開発中のモデルへ戻せます。第4回では、実行可能モデルをレビューに活用する方法として位置付けます。

相互作用図やアクティビティ図などのUML (Unified Modeling Language)由来の図は、必要に応じて参考資料として作成できます。CMLモデルからレビュー用に抽象化して導出する場合は、モデルアップの表現としても利用できます。任意に作った参考図がすべてモデルアップになるわけではありません。これらの図は、SimpleModelingの主フローでCMLに記述する3種類の動的モデルには含めず、元のモデルとの対応を明らかにして使います。

AIが実行のたびに次のツール、分岐、再試行、終了を選ぶ構成では、規則を継続して守るために、その都度の推論と確認が必要になります。決定済みの手続きはワークフローと状態機械へ記述し、AIは利用者の意図の解釈、計画の提案、許可されたワークフローの選択、例外の分析を担う構成にできます。通常処理の進行は、受理されたモデルに従ってランタイムが制御します。

ここでの決定的な実行は、受け取った入力やイベント、現在の状態、明示した規則に基づいて実行判断を行うことです。外部サービスの結果やイベントの到着順まで常に同じになるという意味ではありません。入力の扱い、競合、再試行などの実行契約を定め、失敗イベントや補償要求をAIと人間が判断する境界へ返します。

注文確定のような意味のあるワークフローを、エージェントから利用できるまとまりのある操作として公開します。入力、事前条件 (Precondition)、結果、失敗時の意味を契約に含めると、エージェントは内部の細かな操作を一つずつ組み立てずに利用できます。通常経路が定まった処理では、ツール選択と再推論の回数を減らせます。削減量は処理の内容と構成によります。

依存 (Dependency)コンポーネント (Component)のワークフローをサブワークフローとして組み合わせる場合も、呼出しと結果の契約を通して接続します。ケーパビリティ・モデルは提供する能力と実現の対応を保持し、ワークフローはその能力をどう編成するかを表します。実行するのは対応付けられた操作、ワークフロー、状態機械であり、ケーパビリティ (Capability)の中間表現そのものではありません。

振る舞いを変更するときは、業務上の意味をモデルで確認し、対応する実装と検査も更新します。例えば注文確定の条件を変える場合は、状態機械、ワークフロー、ユースケースの実例を照合し直します。人間は許す操作、失敗時の対応、人間へ戻す条件を判断します。実行記録をモデルの操作・イベント・遷移へ対応付けると、期待した経路と実際の進行を比較できます。図も同じモデルから目的に応じたビュー (View)として作ります。

長時間処理の途中でモデルを変更する場合には、進行中の処理がどの版に従うかも実行契約に含めます。既存の版で完了させるのか、条件を定めて移行するのかを判断し、モデルの変更だけで実行中の状態が自動的に新しい意味へ移るとは扱いません。具体的な版管理や移行の実装はランタイムの責務へ接続します。