※この投稿は 2026 年 4 月 30 日に Digital Engineering De-coded へ投稿されたものの抄訳です。

モデルベース システムズ エンジニアリング (MBSE) は、より適切な意思決定、強力なトレーサビリティ、そしてチーム間のより明確な連携を実現すると期待されています。しかし、多くの組織では、日々の業務は依然として断片化されているように感じられます。

要件はあるツールに、アーキテクチャは別のツールに、解析はさらに別の場所で行われています。検証の証拠は、レポート、スクリプト、専門ツールの中に散在しています。チームはモデルを持っていても、エンジニアリングデータを連携させ、最新の状態に保ち、信頼性を確保することに苦労しています。

このギャップが問題となるのは、デジタルエンジニアリングは単にチームがより多くのデジタル成果物を作成するだけで成功するわけではないからです。デジタルエンジニアリングが本当に成功するのは、エンジニアリング情報が相互に連携し、人々が意思決定を行い、変化を理解し、何が「真実」であるかについて確信を持ち続けられるようになった時です。難しいのは、モデルを作成することだけではありません。難しいのは、それらを分野やツールを超えて連携させることなのです。

システムズエンジニアリングの進化

システムズエンジニアリングは、すでに「ドキュメント（文書）中心」の世界から大きく進化を遂げました。現在、多くのチームがアーキテクチャや振る舞いを定義するために「記述モデル」を活用しており、さらにそれらのモデルをより実行可能で、解析しやすく、設計の意思決定に役立つものにしたいと考えています。

MathWorks は、この移行を促進するために MBSE ワークフローに多大な投資を行ってきました。これらの取り組みの中心となるのが System Composer です。System Composer は、システムの分解、カスタマイズ可能な要素プロパティの定義、インターフェースの確立、および動作図の作成を可能にするツールです。System Composer を開発した主な理由の 1 つは、システムレベルのモデルを設計や解析の成果物と接続することで、より動的なシミュレーションと検証を可能にし、システムズエンジニアリングにおける現代の課題に対応することでした。しかし実際には、組織やチームはさまざまなシステムズエンジニアリングツールに依存していることが多く、協調的な MBSE ワークフローを実現しようとする際に課題に直面してきました。

図 1 – MathWorks におけるモデルベース システムズ エンジニアリング

現代の課題：シームレスな相互運用性

現代のシステムズエンジニアリングでは、高精度で学際的なモデル、単一の情報源、そして堅牢な競合管理が求められます。ここで最大の難関となるのが、異なる分野間でのシームレスな相互運用性を実現し、信頼できる接続されたデータソースを維持することです。システムアーキテクト、制御エンジニア、構造エンジニア、設計エンジニア、安全エンジニアなど、関係者間でデータがやり取りされるため、コラボレーションの複雑さは飛躍的に増大します。MathWorks が最近実施した調査によると、航空宇宙・防衛分野のエンジニアの 94% が、「ツールとデータの相互運用性」をワークフローにおける最大の課題の一つとして挙げています。

従来のソリューションでは、この課題に対して不十分なことがほとんどでした。すべてのニーズを満たせる単一のツールは存在せず、カスタムコネクタは構築と維持に膨大なコストがかかります。これらはデータを転送することはできても、真の情報源を確立できるとは限りません。多くの場合、データのコピーがさらに増え、変換エラーのリスクが高まり、情報が同期から外れて乖離していく機会を増やしてしまうだけでした。

図2 – 分野横断的なデジタル継続性を保証するための従来型ソリューションの落とし穴

SysML v2 API がもたらす変革

SysML v2 が興味深いのはまさにこの点です。単に言語の新しいバージョンだからというだけでなく、その RESTful API によって、よりサービス指向でリポジトリ中心のアプローチでエンジニアリング情報を交換できるようになったからです。

この新しい標準規格により、ツールが中央リポジトリを介してデータを交換できる統合型エコシステムが実現され、信頼できる情報源が確立されます。MathWorks をはじめとするベンダーは、情報をシームレスに公開・取得できるようになり、真の相互運用性を実現します。API は一見シンプルですが、その変革的な可能性は計り知れません。脆弱な直接統合のネットワークではなく、共通のメカニズムを通じてエンジニアリングワークフロー内のツールを接続できるようになります。

これ自体が自動的にデジタルスレッドを保証するわけではありません。しかし、アーキテクチャ、解析、要件、検証情報をより容易に接続、照会、そして時間とともに進化させることで、デジタルスレッドへの確実な道筋を築くことができます。

図3 – 情報交換と信頼できる情報源を備えたエコシステムの連合を可能にするサービスベースの API

また、oose の CEO であり、SysML v2 の主要開発者の1人である Tim Weilkiens 氏は、この API の概念は革新的であり、ツール間の相互運用性と、すべてのユーザーにとっての単一の情報源を可能にすると強調しています。

実際の例：SysML v2を用いたドローンの構築

クアッドコプター (ドローン) の開発を例に考えてみましょう。ステークホルダー仕様 (要件) は SysML v2 を使用してリポジトリに公開され、システムアーキテクトはミッション解析を実行したりシナリオをシミュレーションしたりできます。バッテリーサイズなどのトレードオフ分析が実行され、その結果がリポジトリにプッシュバックされることで、デジタルスレッドの最初のリンクが作成されます。

図4 – ステークホルダー仕様とミッション分析間のデータフローの例

そこから、ワークフローは様々な分野に拡張されます。ソフトウェア要件は数学的に形式化され、自動的な整合性および完全性チェック、さらに検証テストケースの自動生成が可能になります。

ジオメトリメタデータは、専用ツールでの構造解析のために取得および共有できます。制御、構造、設計、安全に関連するステークホルダーはすべてリポジトリへの読み書きが可能になるため、すべてのデータが孤立したワークフロー内に閉じ込められることなく、相互に連携し、信頼性を維持できます。

デジタルスレッド：クエリ、解析、そして進化

この例で最も興味深い点は、単に「データが移動する」ということではありません。SysML リポジトリが、相互に接続された情報からなる「グラフ（ネットワーク）」を形成する点にあります。要件、アーキテクチャ要素、解析結果、インターフェース、メタデータ、そして検証資産は、チームメンバーが自由に照会できるようになります。エンジニアはコンポーネントや要件、メタデータを抽出できます。これにより、依存関係の追跡、影響の理解、仮説検証解析 (What-if Analysis) の実行が格段に容易になり、変更がシステム全体にどのように波及していくかを把握できるようになります。

図5 – SysML v2 リポジトリからのグラフを活用して、What-if 型の影響解析を実行する例

主なポイント (Key Takeaways)

• • モデルは不可欠ですが、エンジニアリングデータが分野間で分断されたままでは、MBSE は十分に機能しません。
  • 単一のツールですべてをこなす必要はありません。 より良い目標は、脆弱で個別最適な統合に頼るのではなく、連携したワークフローの中で、それぞれのタスクに適したツールを使用することです。
  • SysML v2 は、チームが信頼できる情報源を維持しつつ、関連するエンジニアリングデータを照会し、変更の影響をより効果的に追跡できるようにする点で、最も魅力的なツールとなります。

最後に

もしあなたの組織で SysML v2 の導入を検討している場合、重要なのは単に言語が新しいか、表現力が高いかということではありません。より重要なのは、周囲のエコシステムが、要件、アーキテクチャ、解析、検証を、より信頼性の高い方法で連携させるのに役立つかどうかです。そこにこそ、真の価値が現れるのです。

実際の使用例についてさらに詳しく知りたい場合は、2024 年の SysML v2 Extravaganza ワークショップのブログをご覧ください。そこでは、リポジトリと API がいかにシームレスな情報交換を促進するかが詳しく説明されています。

組織で SysML v2 の評価を進められる際、MathWorks は、その評価を実践的なエンジニアリングの道筋へと導くお手伝いをいたします。