ランタイム・ハーネス
SimpleModelingでは、モデル構築・プログラミング・実行にハーネスを重ね、AIの逸脱 (deviation)を抑え、適切な実装へ導きます。ランタイム・ハーネスは、モデル (Model)と部品の契約を実行時に適用する仕組みです。Textus/CNCFの通常の作法に沿って実装することで、品質を支える共通機構の恩恵を受けられます。
ランタイム・ハーネスとは
プログラムを動かす実行基盤(ランタイム)が、使える操作 (Operation)とその実行方法を管理し、動作を定めた規則の範囲に保つ仕組みを、本連載では「ランタイム・ハーネス」と呼びます。
本連載では、AIハーネスの役割を、望ましくない行動を抑える「制約 (Constraint)」、適切な操作や実装へ導く「誘導」、検証結果を修正へ返す「フィードバック」として捉えます。これらを組み合わせ、AIが目的に沿った結果へ収束することを支えます。
ハーネスの役割と実行基盤との関係
| 役割 | 実行基盤との関係 |
|---|---|
|
誘導 |
|
|
フィードバック |
実行結果と記録を検証に用い、問題を修正へ返す。ワークフローで再検証や停止の条件を定め、試行錯誤の範囲を管理する。 |
Textus/CNCFが備える認可、更新管理、状態遷移の管理などは、元々セキュリティ (Security)や信頼性 (Reliability)などの品質属性 (Quality Attribute)を達成するために実行基盤へ導入した仕組みです。SimpleModelingでは、これらをAIのハーネスとしても活用します。共通の仕組みへ制御を任せることで、AIが個別に判断・実装する範囲を減らし、業務固有の処理に集中しやすくします。
ハーネス全体での位置付け
AIによる開発では、モデル構築、プログラミング、実行の各段階にハーネスを重ねます。一つのハーネスでは制約できない範囲を他のハーネスで補い、AIの誤った判断や生成が不適切な動作につながることを抑えます。
モデル構築・プログラミング・実行に重ねるハーネス
| 段階とハーネス | 制約する範囲 |
|---|---|
|
モデル構築:モデル・ハーネス(第2〜4回) |
|
|
プログラミング:プログラミング・ハーネス(第6回) |
|
|
実行:ランタイム・ハーネス(第7回) |
モデルと部品の契約に従って処理を動かし、実行時の権限・状態・更新・資源利用を管理する。 |
例えば、型 (Type)や契約に適合するコードでも、呼出し元の権限や対象の現在の状態 (State)によっては操作を許可できません。ランタイム・ハーネスは、モデルと契約を実際の動作へ適用し、こうした実行時の条件も確認します。プログラミング・ハーネスが実行基盤の管理を受ける構造へ実装を導くことで、AIの補完コードにも共通の制御が働きます。
これらの役割と組合せを定めるのが、第5回のアーキテクチャ・ハーネスです。知識ハーネスはAIが判断に用いる前提を揃え、観測モデルと検証ハーネスは実際の振る舞い (Behavior)を要求と照合するための情報と確認手段を提供します。
実行時の構造と制約点
Textus/CNCFでは、生成モデルと補完コードをコンポーネント (Component)の内部に置きます。部品どうしは、提供する操作を表すAPIと、必要な機能を接続するSPIで連携します。各部品のモデルと操作は、共通の実行管理によって扱われます。

図1 実行時の構造と制約点(Bの内部は簡略化)。枠は部品の境界、実線は契約・操作の接続、破線はモデル参照を表します。①〜④は下表の制約点に対応します。
この構造がハーネスとして働く理由
ハーネスとして働くのは、使える接点や操作が構造によって限定され、その経路に実行時の検査と管理が組み込まれているためです。図の各制約点は、次の範囲を受け持ちます。
構造上の制約がハーネスとして働く理由
| 図の制約点 | 制約が働く理由 |
|---|---|
|
コードと実行基盤が同じモデルの定義・型・操作を使うため、補完コード側に別のデータ構造や進行規則を作る範囲が限定される。 |
|
|
② 外部接続はAPI・SPIのみ |
他の部品の非公開実装を利用側へ渡さず、公開された契約で接続するため、内部処理を直接呼ぶ実装を抑えられる。 |
|
③ 内部の作用はUoW経由 |
保存・参照・外部呼出しを基盤が提供する操作で記述するため、個別コードが実行管理を迂回する範囲を限定できる。 |
|
④ 実行時に規則を適用 |
基盤が操作を実行する際に、認可、許される状態遷移、更新の確定、資源利用の規則を適用する。コードから要求されても、規則に適合しない操作は拒否される。 |
モデルに記述した規則を実行する
CML (Cozy Modeling Language)には、業務データとその操作を構造モデルとして、処理の進行を動的モデルとして記述します。Textus/CNCFはその定義を実行に用いるため、AIがモデルとは別にデータ管理や進行管理を作り直す範囲を減らせます。
CMLから生成したモデルを実行の定義にする
Entityを基盤にAggregateとViewを構成する
構造モデルでは、Entityを業務データの基盤とし、更新系をAggregate、参照系をViewで記述します。Aggregateは業務上の更新と不変条件 (Invariant)を扱い、Viewは参照に必要な情報を構成します。Viewの外側にはDisplayを配置し、参照結果を表示に適した形へ投影します。
例えば、注文の状態変更はAggregateの業務操作、一覧に必要な情報はView、項目の表示はDisplayで扱います。表示の都合で業務状態を書き換えたり、一覧表示の処理に更新規則を重ねて実装したりする必要がありません。
振る舞いと判断もモデルに従って実行する
Textus/CNCFでは、状態機械 (StateMachine)を振る舞いの実行管理の基盤としています。状態・イベント・遷移条件をモデルに明示し、基盤が許された遷移 (Transition)を実行します。AIが状態管理や分岐を個別に実装する範囲が減り、条件の扱い漏れや不正な状態変更を抑えられます。
その上に、アプリケーション寄りの動的モデルとしてワークフローを構成します。開発者やAIは業務の順序や分岐を記述し、進行に伴う状態管理を基盤へ委ねます。業務に近い抽象度で処理を表しながら、状態機械による定型的な実行管理を利用でき、モデルに沿った安定した動作を得やすくなります。
ワークフローの各処理をコンポーネントの公開操作へ接続します。更新や参照を伴う操作では、AggregateやViewのモデル操作を使います。これにより、業務の進行とデータの操作が、それぞれのモデルと部品の契約に従って実行されます。
業務規則をルール・エンジンで評価する場合も、判断結果と実行する操作を分けます。評価から得たActionPlanは、コンポーネントの公開OperationやEvent (イベント)、Jobの実行へ接続します。モデル化した判断を使いながら、部品の契約と基盤の実行管理も維持する構成です。
部品の接続と内部の操作を実行基盤が管理する
外部との接点をAPIとSPIに限定する
コンポーネントが外部と接点を持つのは、APIとSPIを通してです。APIは部品が提供する操作の契約を表し、SPIは部品が必要とする機能を提供者へ接続する契約を表します。相手の内部実装を呼び出したり、接続先の処理を利用側へ複製したりせず、定められた入出力と意味で連携します。
業務固有の外部連携も、この接点として実装します。通信方式や提供者の詳細をSPIの実装側へまとめることで、業務処理は同じ契約を利用できます。AIが変更する範囲が、契約に従う利用側か、契約を実現する提供側かに分かれます。
実行時にも公開契約と内部実装を分ける
CARはモデルに対応する部品の契約、実装、依存関係をまとめます。利用側へ渡すのは公開契約のAPIであり、提供側の内部実装は利用側のライブラリーにしません。実行時にも契約APIの型を共有し、実装はコンポーネントごとに保持します。
基盤は宣言された依存関係と契約を使って部品を構成します。必要なAPIがない場合や契約が適合しない場合に、内部実装を探して代わりに接続することはしません。型と部品検査によって定めた利用範囲が、実行時の部品構成でも維持されます。
公開操作を使うことで、利用側は部品の内部実装に依存 (Dependency)せずに処理を再利用できます。基盤はこの接続関係を実行時にも維持するため、部品の独立性を保ったまま共通の制御を適用できます。
入力の検査とエラー処理を統一する
プロパティとアプリカティブな合成で入力を扱う
パラメタはCNCFが提供するプロパティ経由で扱い、必要な値の取得と検査の結果をConsequenceとして組み合わせます。入力項目が互いに独立している場合はアプリカティブ (applicative, アプリカティブ・ファンクター)な合成を使い、各項目の結果を集約します。例えば、注文番号の不足と数量の不正を同じ入力の問題としてまとめて扱えます。
各項目の取得と検査をConsequenceとして合成するため、AIが独自のパラメタ解析やエラー収集の制御を組み立てる範囲が減ります。検査を通った入力を業務処理へ渡し、入力の問題は共通の結果体系で返すことで、検査と処理の接続を統一できます。
ハーネスに沿う実装で品質を支える
モデルと部品の標準操作には、認可、更新管理、資源管理、観測、障害対応が結び付いています。開発者が対策を一つずつ選んで実装しなくても、業務処理の実行とともにこれらの制御が働きます。それぞれが支える品質属性は次のように整理できます。
ハーネスの共通機構が支える品質属性
| 品質属性 | ハーネスとの関係 |
|---|---|
|
データ整合性・正確性、信頼性、予測可能性・再現性 |
|
|
セキュリティ、観測可能性、監査可能性・追跡可能性 |
標準の実行経路で保護と記録を適用し、操作の主体・対象・結果を把握できるようにする。 |
|
性能・応答性、拡張性・弾力性 |
参照・表示のモデルと共通の実行管理を使い、負荷に応じた処理と容量の制御を利用する。 |
|
可用性・耐障害性、回復可能性 |
部品の境界と状態・進行の管理によって、障害の影響を限定し、復旧につなげる。 |
|
保守性・変更容易性、検証容易性、再利用性・組合せ容易性、相互運用性・接続先の変更容易性 |
型付き契約と業務・実行制御の分離によって、部品の変更、検証、再利用、外部接続を共通の構造で扱う。 |
|
導入・運用容易性、資源効率・運用コスト |
標準設定と共通の資源管理を使い、用途に必要な構成と負担を調整する。 |
一つの共通機構が複数の品質に寄与し、複数の機構が同じ品質を支えます。メッセージによる処理の分離に、進行管理、容量制御、障害対応を組み合わせることで、応答性・耐障害性・弾力性・メッセージ駆動というリアクティブな四特性も支えます。
必要な処理量や可用性の水準は、用途に応じた配備と設定で調整します。
AIの作業をワークフローの管理下で実行する
AI自身が業務や開発の実行に参加する場合にも、同じ構成を適用できます。担当する判断や生成をワークフロー内の処理として位置付け、AIは定められた入力・制約・完了条件に従って結果と根拠を返します。全体の順序と継続・再開は基盤が管理する分担です。
実行基盤は、Consequence/Conclusionによる構造化された結果と実行記録を、検証へ渡す情報として提供します。検証側で要求や完了条件と照合し、問題の箇所と理由をAIへ返すことで、修正する範囲を絞れます。結果を伝える仕組みと、その結果が要求を満たすかを判定する検証を組み合わせます。
このフィードバックを収束へつなぐには、修正と再検証の手順、再試行の上限、停止や人による確認へ移る条件をワークフローに定めます。結果の型や実行管理だけで正解が得られるわけではありません。検証と継続判断を組み込むことで、修正を際限なく繰り返すことを抑え、必要に応じて方法を見直せます。
参照
用語集
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework(CNCF)は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server(REST / OpenAPI)、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- Textus
-
Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。
- シンプルモデリング (SimpleModeling)
-
SimpleModelingは、KnowledgeからDomain Modelを構成し、CMLで形式化し、CozyとAIによって実行可能ソフトウェアへ実現し、Textus上で動作させる、モデリング中心のソフトウェア開発方法論と技術体系です。
- 逸脱 (deviation)
-
計算値や観測値が、基準値や真値から外れている状態。観測可能な量的ずれを表す。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- 制約 (Constraint)
-
UMLにおけるConstraintは、一つ以上のModel ElementのSemanticsの一部を宣言するため、自然言語または機械可読言語で表した条件または制限です。評価結果はBooleanであり、評価は副作用を持ちません。
- 妥当性確認 (validation)
-
Validation(妥当性確認)とは、システムや機能が利用目的や要求仕様に対して妥当であるかを確認する行為である。
- モデル関係 (Relationship)
-
Undefined
- 仕様確認 (verification)
-
Verification(仕様確認)とは、規定された設計仕様や要求仕様に対して、実装が一致しているかを確認する行為である。
- エラー (error)
-
汎用的な表現として用いられる用語。ソフトウェア工学では多義的に使われ、バグや障害全般を指す。SimpleModeling では広義のラベルとして使用し、個別には Mistake・Defect・Fault・Failure・Deviation に整理する。
- セキュリティ (Security)
-
Securityとは、情報と機能を正当な権限に従って保護し、不正な閲覧、利用、変更、破壊、否認を防ぐ性質です。Confidentiality、Integrity、Authenticity、AccountabilityなどのConcernを含みます。
- 品質属性 (Quality Attribute)
-
Quality Attributeとは、ソフトウェアが機能を実行できることに加えて、どの程度の品質で要求を満たすかを表す特性です。Security、Performance、Availability、Reliability、Resilience、Observability、Maintainabilityなどが含まれます。
- 信頼性 (Reliability)
-
Reliabilityとは、指定された条件と期間のもとで、システムが要求された機能を一貫して遂行する性質です。Availability、Fault Tolerance、Recoverabilityなどを含む観点から評価します。
- 状態 (State)
-
UMLにおけるStateは、ある不変条件が成立している状況をモデル化したものです。Objectの現在のStateによって、受け付けられるEventやOperation、成立するConstraint、次に可能なTransitionが変わります。
- 型 (Type)
-
Undefined
- 振る舞い (Behavior)
-
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- Cozy Modeling Language (CML)
-
CML(Cozy Modeling Language)は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
- 永続化 (Persistence)
-
Undefined
- ビュー (View)
-
Viewとは、Modelを特定のPurposeとConcernに応じて選択し、理解、判断、検証、利用できる形で投影した表現です。ViewはModelの一部を見せるものであり、元のModelとは別に意味を所有しません。
- 不変条件 (Invariant)
-
Invariantとは、対象が有効である間、観測可能な安定点で常に成立しなければならないConstraintです。Object、Type、または複数要素からなる構造に適用できます。
- 遷移 (Transition)
-
UMLにおけるTransitionは、StateMachine内のSource VertexからTarget Vertexへ進む有向関係です。Trigger、Guard、Effectなどによって、いつ遷移し何を実行するかを定めます。
- 状態機械 (StateMachine)
-
UMLにおけるStateMachineは、Eventの発生によって起動されるTransitionでStateのグラフをたどり、システム要素のevent-driven Behaviorを表すBehaviorです。
- イベント (Event)
-
UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
- 通信 (Communication)
-
Undefined
- 依存 (Dependency)
-
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。
- アプリカティブ (applicative, アプリカティブ・ファンクター)
-
アプリカティブ(applicative)は、文脈内の関数と文脈内の値を組み合わせて評価する抽象です。 pure と ap または mapN などの操作によって、依存関係のない複数の計算を並列的・独立的に合成するスタイルを提供します。
- 観測記録 (observation, オブザベーション)
-
対象の現象を捉えて記録した結果。
- オブザーバビリティ (observability, 可観測性)
-
Observabilityは、システムやドメインの内部状態を外部からの観測を通じて推論・理解できる性質を表します。 単なるモニタリング可能性を超え、現象(Phenomenon)や観測記録(Observation)を一貫して収集・関連付け、ドメイン・イベント(Domain Event)として意味づけられることで、システムの挙動を総合的に把握できる状態を指します。
- 性能 (Performance)
-
Performanceとは、指定された条件と資源のもとで、システムが処理時間、応答時間、Throughput、容量などの時間的要求を満たす性質です。
- 障害要因 (fault, フォルト)
-
システム内部に存在する技術的な欠陥。Defect が具現化したもので、実行時に Failure を引き起こす可能性がある。IEEE 610.12 に基づく。
- 障害 (defect)
-
成果物(設計書、仕様書、コードなど)に存在する不完全さや不足。要求や仕様を満たさず、修正や置換が必要となる状態。ISO/IEC 24765 に基づく。