MAS4SysML:自然言語からのSysML v2モデル生成のためのマルチエージェントフレームワーク

Summary

このプロトコルはMAS4SysMLというマルチエージェントアプローチを提示しており、協調したタスク分割を通じて自動的にSysML v2コードを生成し、修復の反復を少なくし、手動モデリング時間を大幅に削減しつつ、システムモデリングの効率を向上させます。

Abstract

自然言語要件から正確なSysMLモデルを自動的に生成することは、複雑なシステム開発におけるモデルベースシステムエンジニアリング(MBSE)の採用を大幅に加速させることができます。しかし、大規模言語モデル(LLM)を使ってモデルコードを生成することは、形式モデリング言語の厳格な構文的制約を満たさず、生成されたモデルと要件間の意味的整合性を一貫して確保することは依然として困難です。これらの課題に対処するため、本論文は、制約された修復予算のもとで構文の正確性と意味的整合性を向上させるSysML v2コード生成のためのマルチエージェント協働フレームワーク、MAS4SysMLを紹介します。このフレームワークはモデリングタスクを階層的なサブタスクに分解し、構造化されたタスクカードとして形式化し、ボトムアップ方式でモデルコードを生成します。生成時には、構文診断のために公式の検証環境が使用されます。完了後、フレームワークはコードとタスクカード間の意味的整合性を検証します。構文やセマンティック検証が失敗した場合、フレームワークは診断フィードバックに基づき、あらかじめ定義された修復予算内でコードを反復的に修復・再検証し、検証基準を満たすか予算が尽きるまで続けます。提案された手法を評価するために、要件、ユースケース、構造、パラメトリクス、状態機械の5つのコアタスクタイプを網羅したSysML v2データセットを構築し、比較実験を実施します。結果は、MAS4SysMLが平均構文エラー率を2.63に減少させ、意味的類似度を0.91に向上させ、既存のコード生成手法を全体的に上回ることを示しています。

Introduction

MBSEは、航空^{や航空宇宙}1などの分野で複雑な機器の開発における要件分析、システムアーキテクチャ設計、検証計画の重要な手法論となっています。SysMLのような統一モデリング言語をモデリングの基盤として用いることで、要件、構造、挙動、制約などの情報を一貫したモデルフレームワークに組織化し、プロセス構造の向上と学際的な協働の効率化に寄与します^。しかし、システム規模が拡大し続けるにつれて、開発すべきモデル数も増加し、手動のSysMLモデリングの作業量は持続的に増加しています。さらに、モデラーは厳格な統文的・方法論的制約の下で作業しなければならず、それには高度な専門知識と強い抽象化能力が求められます。これらの要因はMBSE³のエンジニアリング採用における大きなボトルネックとなっています。

近年、LLMは自然言語理解、構造化情報表現、コード生成において強力な能力を示し、自然言語からモデルコード⁴へのMBSEモデリングの自動化に新たな機会をもたらしています。これまでの研究では、^{LLMs 5}を用いてSysMLモデルコードの直接生成が探られてきました。それでもなお、重大な課題は残っています。構文的には、SysMLの型システム、スコープ機構、参照意味論は厳密な形式的制約によって制御されており、汎用プログラミング言語6よりも複雑である^{ことが多いです。}意味的には、LLMは行動論理、構造的関係、層間制約を完全に捉えきれず、関係の欠如、論理的矛盾、または不^{完全なモデルを引き起こす}ことがあります。これらの制約は、直接生成アプローチの信頼性、制御可能性、解釈性を妨げています。

これらの課題に対応するため、本論文では4つのエージェント役割からなるSysML v2コード生成フレームワークMAS4SysMLを紹介します。本研究は、完全なクロスビューシステムモデルのワンショット生成に直接的とどまるのではなく、複数の代表的なSysML v2モデリングタスクの生成と反復修復に焦点を当てています。タスク分解と構造化タスクカードを基盤とし、コード生成、ツールレベルの構文診断、セマンティック整合性検証を統合し、MAS4SysMLは生成、検証、修復のクローズドループワークフローを確立します。この設計は、制約された修復予算の中で生成コードの構文的正確性、意味的整合性、構造的完全性を向上させます。

主な貢献は以下のようにまとめられます:(1) MAS4SysMLフレームワーク。私たちは、自然言語要件から実行可能なSysML v2モデルコードまでのエンドツーエンド生成を可能にするマルチエージェントのLLM駆動フレームワークMAS4SysMLを提案し、モデリングコスト削減と効率向上の実用的な道筋を提供します。(2) タスク解析と二重検証。タスク構造ツリー解析メカニズムと、構文と意味論の二重検証スキームを導入します。タスク解析では、モデリング目標が階層的に分解され、構造化されたタスクカードに形式化されます。検証において、構文診断は公式の^{検証環境8} を活用して生成コードのチェックと修復指向の診断を返します。一方、セマンティック検証はタスクカードのキーフィールドを参照として使用し、生成モデルとモデリング目標間の全体的な整合性を評価します。(3) 実験的評価。構文誤り率と意味的一貫性スコアを主要な指標として比較実験を実施します。結果は、MAS4SysMLが平均構文誤り率を2.63に低下させ、意味的類似度を0.91に向上させ、生成精度と自動化においてベースライン手法を上回ることを示しています。

Protocol

MAS4SysMLフレームワークのコード生成プロセスは 補足ファイル1にまとめられています。本研究は、要件、構造、パラメトリクス、挙動を含む厳密なクロスビュー一貫性を持つ自然言語から完全なシステムモデルをワンショットで生成することを目的としていないことに注意が必要です。代わりに、プロトコルはSysML v2ビューコードの代表的なタイプを生成することに重点を置いています。

フェーズI:課題分析
ワークフローはタスク解析から始まります。このシステムは、タスク構造生成エージェントに自然言語モデリングの意図を提供し、エージェントはタスクカードセットを出力します。後続の世代が実行可能かつ再現可能であることを保証するために、各タスクカードには最低でも、(i) タスク識別子、(ii) 依存関係、(iii) モデリング目的、制約/境界条件、パラメータスロット、インスタンス値、期待出力などの検証用の重要なモデリング情報を含める必要があります。この段階では task_card_setを出力し、これが後のモデルコード生成の統一基盤となります。

フェーズII:反復コード生成
反復生成では、システムはコードコンテキストprev_codeを空の状態に初期化し、依存フィールドによって決まる順序に従って各タスクカードごとにコードを順次生成します。各タスクカードに対して、コード生成エージェントは現在のタスクカードとコンテキストコードを受け取りcandidate_code生成し、すぐに構文検証モジュールを呼び出してチェックを行います。モジュールは公式のSysML v2検証環境を使ってコードを検証し、診断結果を返します。検証が成功した場合、candidate_codeはprev_codeの更新に使われ、次世代をサポートします。検証が失敗した場合、コード修復エージェントがトリガーされ、返された診断に基づいて最小限のターゲットを絞った編集を行い、その後修復されたコードを再検証のために再提出します。この修理再検証ループは最大修理予算Kの_上限に制限されます。検証が予算内で成功した場合、通過されたバージョンはprev_code更新されます。それ以外の場合、_Kmaxの試み後、システムは失敗を記録し、最後に修復されたバージョンをprev_codeとして使用して、ワークフローの妨げを防ぎつつコンテキストの連続性を維持しつつ、その後のタスクカード生成を続けます。

フェーズIII:意味的検証
すべてのタスクカードのコードが生成された後、ワークフローはセマンティック検証に進みます。セマンティック検証エージェントは、 task_card_set のキーフィールドを参照として、最終コードとモデリング意図の整合性を評価し、セマンティック検証結果を出力します。検証が成功すれば、 prev_code が最終的なSysML v2モデルコードとして受け入れられます。それ以外の場合、システムは未達成のタスクカードフィールドと必要な改訂範囲を特定する意味的偏差レポートを生成します。その後、コード修復エージェントはそれに応じてコードを修正し、最終的な結果として改訂されたモデルコードを出力します。

モデルアーキテクチャと手法
モデルアーキテクチャ
図1に示されるMAS4SysMLフレームワークは、タスク構造生成エージェント、コード生成エージェント、コード修復エージェント、セマンティック検証エージェントの4つの協働エージェントで構成されています。対応するプロンプトテンプレートは図2に示されています。

タスク構造生成エージェントは入力モデリングの意図の意味解析を行い、実行可能な構造化タスクカードを生成します。まず階層的タスク分解メカニズム(階層的タスク分解メカニズムを参照)を適用し、全体のモデリング目標を明確に定義された意味的境界を持つタスクノードに分解し、各ノードに対して構造化されたタスクカードを構築します。その後、タスクカードはモデリング依存フィールドに従って順序付けされ、実行シーケンスが最終的なコード構造と整合するようにされ、グローバルモデリング目標に基づくボトムアップコード生成の基盤が築かれます。

コード生成エージェントは、モデリング依存関係に応じてSysML v2準拠のモデルコードを段階的に生成します。親タスクによって生成されるコードアーティファクトを基に、エージェントは各タスクカードで指定された要件に基づいて対応するコード生成操作を実行し、ローカルコンポーネントから完全なモデルまで段階的に構築プロセスを可能にします。

コード修復エージェントは、構文検証モジュール(構文検証モジュール参照)の結果と意味的検証結果に基づいて生成コードの誤りを訂正します。構文修復では、構文検証器が返すエラータイプ、位置、文脈情報を活用してターゲットを絞った修復戦略を統合し、修正コードを生成します。意味修復では、意味的検証結果に基づいて構造的および論理的関係を調整し、最終モデルにおける意味的整合性と構造的完全性を確保します。

セマンティック検証エージェントは、専用のセマンティック検証機構(セマンティック検証メカニズム参照)を用いて、完全に生成されたコードとタスクカード間のセマンティック一貫性を評価します。定量的な評価を通じて、生成されたコードが元のモデリング意図を正確に反映していることを確認し、モデルコードと指定されたモデリング要件との正確な整合性を実現します。

階層的タスク分解メカニズム
複雑系の形式モデリング言語として、SysML v2は密結合された構文、深く入れ子された階層構造、そしてレベル横断的な意味的制約を特徴としています。例えば、システム構造ブロックは複数のサブパーツ、属性、ポートを含みつつ、同時にクロスレイヤー制約を通じてパフォーマンスや動作要件を表現することがあります。これらの構造と制約は、トップダウンの構造的依存関係とボトムアップの意味的フィードバック関係を生み出します。フラットでワンショット生成のアプローチでは、このような階層的依存関係を正確にマッピングすることが難しく、しばしば関係の欠如、意味の不整合、制約情報の喪失を招きます。

この課題に対応するため、私たちは自然言語モデリングの要件を階層的に分解するタスクツリーベースのモデリング意図解析手法を開発しました。 図3に示すように、複雑なモデリング目標は構造化され追跡可能なタスクノードに分解され、システムはモデリングの意味論をトップダウンで解釈し、依存関係を特定できます。具体的には、タスク構造生成エージェントがユーザー入力を受け取った際、まずLLMのセマンティック解析機能を活用し、コアモデリング目標、主要なエンティティ、それらの依存関係を特定します。その後、最上位目標を意味的に独立したサブタスクに再帰的に分解し、さらに原子的なタスクへと精緻化し、SysML v2のモデリング操作に直接マッピングできる仕組みを形成します。最終的には完全なタスク構造ツリーを形成します。タスクツリーが構築された後、エージェントはあらかじめ定義されたテンプレートに基づいて各タスクノードの構造化タスクカードを生成します。タスクカードのフォーマットは以下の通り定義されています。

TC = {ID, O, N, K, P, V, C, D} (1)

idはタスクノードの一意識別子、Oはタスク目標、Nはタスクの自然言語記述であり、Kはタスクに関わるSysML v2の主要な意味要素を表します。主にRequirement def/requirement、part def/part、port def/port、item def、attribute def/attribute、state/transitionなどが含まれます。これらの要素間の関係は主に接続(構造的接続)、ポート上の入出力項目(情報・資材フロー)、状態機械遷移のトリガー/ガード条件(例:コマンド、健康状態、しきい値制約)を通じて表現されます。Cは意味ルールまたは境界条件、Pはタスク内のパラメータ化可能なスロット(属性名、データ型、複合型など)として表されます。 Vは各スロットのインスタンス化された値、Dはタスク間のモデリング依存関係であり、depend_onは他のタスクからの必要な出力を指定し、現在のタスクコードを生成する前に提供はタスク完了後に生成される出力を表し、消費はタスクに必要な外部入力を表します。

構文検証モジュール
構文検証モジュールはSysML v2パイロット実装に基づいて構築されています。パーサーとバリデーターのインターフェースを呼び出すことで、生成されたSysML v2モデルコードの構文的正確性を解析し検証します。モジュールの検証基準は主にSysML v2言語仕様、ならびにPilotツールで実装された文法ルール、スコープ解決ルール、関連する制約チェック機構から派生しています。具体的には、要素宣言が適切に構成されているか、ブロック構造が完全かどうか、型注釈が有効かどうか、名前や参照が正常に解決できるか、ポート、接続、状態、遷移などのモデリング構造が言語の要件を満たしているかを調べます。

コード生成エージェントが現在のタスクのコード断片を生成すると、その出力は構文検証モジュールに転送され、検証スクリプトがコードを解析して構造化診断情報の形で結果を返します。検証結果は以下の通り報告されます。

E₁ = (タイプ_i, pos_i, msg_i) (2)

ここでe_iは現在のモデリングタスクで検出された問題のリストを表し、各エントリにはエラータイプ_i、エラー位置_posi、診断メッセージiが含まれています。

例えば、生成されたコードに「属性定義によって型付けされていない」といった構文エラーが含まれている場合、検証モジュールは以下の診断メッセージを返します。

'type' : 'error'
'message' : 'ERROR: attribute 定義によって属性を型付けする必要があります。'(3)
『位置』:『7行目:3』

検証結果 e_{i ≠が} 0 になると、収集された誤り情報 e_{i は}さらなる修正のためにコード修復エージェントに転送されます。したがって、コード修復プロセスは制約のない修正手続きではなく、パーサーとバリデーターが返す明示的な診断情報に基づいて導かれたターゲットを絞ったリビジョンです。

意味的検証メカニズム
セマンティック検証機構は、モデルコードと明示的かつ追跡可能な対応関係を持つ主要なタスクカードフィールドをセマンティックアンカーとして用います。モデルレベルでの意味的整合性を評価し、その後のモデル修復のための明確かつ実行可能な基準を提供します。具体的には、各タスクカードTC_iに対して、以下のフィールドが主要な意味的参照として用いられます:(i) モデリング目的 O_i、(ii) 意味制約および境界条件 _{C i}、 (iii) インスタンス化されたパラメータスロット値 V_i、および (iv) タスク完了後の期待出力 _{D i}['provide'].これらのフィールドは、モデリング意図の実現、制約の充足、パラメータの一貫性、モデル出力の完全性といった複数の観点から生成されたモデルに補完的な意味的制約を課し、追加の仮定を必要とせずにモデルコードがモデリング要件を満たしているかどうかを原則的に判断できるようにします。

これらのキーフィールドに基づき、多フィールドセマンティック・コンステニクス・ディシジョン決定関数を定義します。

(4)

ここでI(·)は括弧内のすべての部分決定関数が成り立つ場合に1となり、そうでなければ0となる指標関数を表します。この二項決定は、モデリング要件を満たす状態とさらなる修復が必要な状態を明示的に区別し、その後の意味修復プロセスの決定論的トリガー条件を提供します。全体の決定は以下の4つのサブ決定関数によって共同で決定されます。

(1) 客観的一貫性のモデリング:

Φ₀ (TC_{i,c f}) = I(consist(c_{f,0 i})) (5)

ここで Consist(c_{f,0 i}) は、モデルコード c_f がタスクカードで指定されたモデリング目標 _{0 i} と意味的に整合しているかどうかを示します。

(2) 意味制約の充足:

Φ_c (TC_{i,c f}) = I(Satisfy(c_{f,C i})) (6)

ここでSatisfy(c_{f,C i})は、モデルコードc_fがタスクカードで指定された意味的制約および境界条件C _iを満たすかどうかを示します。

(3) パラメータの一貫性:

Φ_c (TC_{i,c f}) = I(瞬間 _{(c f,V i})) (7)

ここでInstant(c_{f,V i})は、タスクカードにインスタンス化されたパラメータ値 V_iがモデルコードに一貫して反映されているかどうかを示します。

(4) 出力一貫性:

(8)

ここでArtifacts(c_j)は、タスクカードで期待される出力が最終モデルコードに存在しているかどうかを示し、生成された結果の完全性の指標となります。

これらの整合性判断は、LLMの意味理解能力を活用してセマンティックバリデーションエージェントによって実装されます。エージェントの内部推論過程は、整合性関数の正式な定義や使用を変えません。

この多フィールドセマンティック一貫性チェックを通じて、生成されたモデルはフィールドごとに検証され、各モデリング目的、制約条件、パラメータ構成、期待出力が十分に満たされていることを確認します。このプロセスは、その後の意味修復の明示的なトリガーを提供するだけでなく、生成パイプライン全体にわたって追跡可能な意味的証拠を提供し、生成モデルの信頼性と一貫性を向上させます。

実験データと評価
実験データ
SysML v2モデルコードは普通のソフトウェアコードではありません。生成されるアーティファクトは、形式モデリングの特徴的な特徴を示します。異なるビューは通常、要件、パーツ、ポート、属性、状態、トランジションなどの異なるコアモデリング要素のカテゴリーを含み、宣言スタイル、組織形式、構成構造において大きく異なります。さらに、モデルコードは型参照、階層的なネスト、接続制約、要素間の意味的再利用など複数の制約を満たす必要があります。

提案された手法の性能を異なるモデリング複雑度下で包括的に評価するため、要求、ユースケース、構造、パラメトリクス、状態機械という5つの代表的なモデルビュータイプをカバーするコードデータセットを構築します。これらのモデルビューは、それぞれ要求仕様、機能的相互作用、構造合成、パラメトリック制約表現、およびシステムモデリングにおける振る舞い論理記述に対応します。異なるモデルビュータイプでフレームワークを個別に評価することで、多様なコード構造特性やモデリング制約条件下での適用可能性をより細かく分析できます。

各モデルビュータイプは15の手動作成モデルインスタンスを含み、 N= 75のSysML v2モデルのデータセットとなります。このデータセットは航空宇宙、自動車、医療、スマートホームシステムなど複数のエンジニアリング分野にまたがり、すべてのモデルが公式のSysML v2検証環境をクリアし、厳格な構文準拠を保証しています。

その後、各モデルに対応する自然言語モデリング意図記述を作成しました。建設効率を高めるために、 補足ファイル2 に示されたプロンプトテンプレートを使用し、GPT-4oを使って初期記述を作成しました。GPT-4oは、強い意味理解と情報抽出能力が評価され、幻覚なしにコアモデル要素を正確にキャプチャし、人間に似たモデリング意図記述を生成することが可能^でした。正確性を確保し曖昧さを排除するために、生成されたすべての記述はシステム工学のバックグラウンドを持つ研究者によって手動で確認・洗練されました。異なるモデルタイプの代表例は 表1に示されています。

評価指標
生成されたSysML v2モデルコードの品質を評価するために、以下の3つの主要な指標を用いています。

平均統語誤差率(SER)
この指標は、生成されたモデルコードが公式のSysML v2構文ルールに照らされて検出された構文エラーの割合を定量化します。計算は次の通りです:

(9)

ここで E_i は、生成された第 i個モデルで特定された構文誤りの数を表します。この指標は、生成されたモデルコードが正式なSysML v2構文仕様にどの程度適合しているかを反映しています。

意味的一貫性スコア(SCS)
この指標は、生成されたモデルコードが自然言語モデリング仕様で表現された意味的意図をどれだけ正確かつ包括的に捉えているかを評価するものです。具体的には、モデリング意図からシステムエンティティ、参加コンポーネント、コア機能や行動シナリオ、主要な条件や制約などの意味単位を抽出し、生成されたモデルコード内の意味単位と比較します。意味的整合性は次のように計算されます:

(10)

ここで U はモデリング意図から抽出された意味単位の集合を表し、 は生成されたコード内で特定された意味単位の集合を表します。 は生成されたモデルコードによって正しく捕捉された単位の数を示します。SCS値が高いほど、より強い意味論的カバレッジとアラインメントを示します。

人間の品質評価
従来の自動化指標であるBLEUやCodeBLEUは主に表面的な類似性やコード実行可能性を評価しますが、モデルが意図されたモデリングの意味論を真に理解しているか、正しく表現しているかを捉えきれません。これらの指標は、意味的一貫性、主要要素の完全性、モデリング意図との整合性の評価に限^{られています。}これに対し、人間の評価は意味要素の欠落、論理的矛盾、構造的冗長性、裏付けのない幻覚などの問題をより正確に特定できるため、より信頼性の高い評価^{を提供します。}これらの制約を踏まえ、生成されたSysML v2モデルに対して、以下の3つの基準からなる人間的評価フレームワークを設計します。(1) 正確性:生成されたモデルはモデリング意図を正確に反映し、タスク目標との構造的かつ論理的整合性を維持し、意味上の曖昧さ、欠落要素、誤った拡張を含まないこと。(2) 可読性:モデルコードは明確で理解しやすく、一貫した命名、一貫した構造、そして点検とその後の保守を支援するよく組織された階層構造を持つべきです。(3) 整合性:モデルは完全な構造論理、一貫した要素間参照、未定義のタイプや依存関係の断絶がないこと、これにより下流の分析や統合に利用しやすくなるべきです。SysMLモデリングの経験を持つ研究者に、生成された各モデルを3点スケールで評価してもらいました。1は最低品質、3は最高を示します。評価中、評価者は生成されたモデルコードをグラウンドトゥルースモデルと比較し、より正確かつ包括的な評価を確実にすることが認められました。

基準線
提案された方法と比較して複数の評価ベースラインを選択し、以下のものを比較しました。
CodeCoT¹²:思考連鎖推論と自己チェック機構を組み合わせ、モデルが生成時に明示的に推論し、構文エラーを自己訂正することでコードの品質と意味的整合性を向上させます。

セルフプランニング¹³:モデルがまず解法ステップを計画し、その後計画に従ってコードを生成する2段階のコード生成パイプラインを導入し、複雑なタスクに対して論理的一貫性と解釈性を効果的に強化します。

セルフ編集¹⁴:生成コードを実行し、実行時のフィードバックに基づいて自動的にエラーを修正し、出力を継続的に洗練させる反復的な生成・編集パラダイムを採用します。
CodeChain¹⁵:複雑なタスクを独立した機能モジュールに分解し、複数回の最適化ラウンドを通じて構造の健全性と全体的な品質を向上させることで、モジュール生成と反復的修正を使用します。

自己デバッグ¹⁶:モデルに自律的なデバッグおよび説明能力を付与します。生成、実行、デバッグのクローズドループプロセスを通じて、人間の介入なしに複雑なプログラミングタスクの正確性を大幅に向上させます。

MapCoder¹⁷:取得、計画、コーディング、デバッグの4つのエージェントからなる多段階の協働フレームワークを構築し、人間のプログラミングワークフローを密接にシミュレートし、タスク理解から結果検証までのクローズドループ生成を可能にします。

セルフコラボレーション¹⁸:アナリスト、プログラマー、テスターなどの役割を持つ仮想プログラミングチームとしてシステムを組織し、役割ベースの協働と反復的フィードバックを通じて複雑なコード生成の全体的なパフォーマンスを向上させます。

実験装置
実験間の公平性と比較可能性を確保するため、まずいくつかの主流のLLMを直接コード生成手法で評価し、ベースライン性能を確立しました。これらの初期結果に基づき、最も性能の良いLLMがすべての実験の統一バックボーンモデルとして選ばれました。その後、提案されたMAS4SysMLフレームワークを複数の代表的なコード生成手法と比較しました。すべてのLLM相互作用は、生成中のランダム性を最小化するために固定温度設定(T = 0.2)で実施されました。各モデリングタスクに対して、MAS4SysMLの最大修復反復数はK最大=3に設定されました。すべてのベースライン手法は、結果の一貫性と実験的公平性を確保するため、MAS4SysMLと同じ実験構成で実行されました。MAS4SysMLメソッドのPythonスクリプトは補足ファイル3として提供されています。

Results

ベースラインモデル評価
まずいくつかの主流LLMを選定し、CodeX(175B)¹⁹、CodeGen-Mono(16.1B)²⁰、PaLM Coder(62B)²¹、Alphacode(1.1B)²²、Incoder(6.7B)²³、code-davinci-002(175B)²⁴など、モデルからコードへの直接生成を用いた予備的な性能テストを実施しました。 表2に示すように、code-davinci-002(175B)²⁴ はSERおよびSCS指標の両方で最良の性能を示しました。したがって、本研究における様々なコード生成戦略の評価の基礎LLMとしてcode-davin...

Discussion

私たちは、半自動化されたSysML v2モデルコード生成のためのマルチエージェント協働フレームワークMAS4SysMLを提案します。この枠組みは、機能的に補完的な4つのエージェントで構成されています。生成過程では、(i) タスクツリーベースの構造を用いて自然言語モデリングの要件を階層的に分解し、構造化されたタスクカードに形式化し、(ii) これらのカードで指定された制約や依存関係に基づいてボトムアップ方式でSysML v2モデルコードを生成します。生成過程を通じて、公式のSysML v2検証環境を基に構築された構文検証モジュールが構文診断を行い、修復志向のフィードバックを返します。コード生成後、フレームワークは主要なタスクカードフィールドとの意味的整合性をさらにチェックし、生成コードの実行可能性と意図された要件との整合性を向上させます。

MAS4SysMLは、自然言語モデリングの意図をSysML v2モデルコードに変換する実践的な道筋を提供します。複雑な機器開発における手動モデリングのコストと学習負担を軽減し、クロ...

Materials

List of materials used in this article

Name	Company	Catalog Number	Comments
ラングチェイン	LangChain(オープンソースプロジェクト)	v1.0.8;https://github.com/langchain-ai/langchain	LLMインタラクションおよびエージェントオーケストレーションのためのフレームワーク
ランググラフ	LangChain(オープンソースプロジェクト)	v1.0.3;https://github.com/langchain-ai/langgraph	マルチエージェントワークフロー実行フレームワーク
パイソン	Pythonソフトウェア財団	3.10.x;https://www.python.org/downloads/release/python-3100/	MAS4SysML実装のメインプログラミング言語
SysML v2パイロット実装	オブジェクト管理グループ(OMG)	(リリース/タグバージョンの提供);https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation	構文検証およびモデル解析に使用