モデルベース開発（MBD）とは？メリット・デメリットとIPA実測の工数効果

モデルベース開発（MBD：Model-Based Development／Model-Based Design）は、制御ロジックと制御対象の動きを数式モデルとしてコンピュータ上に作り、そのモデルをシミュレーションで検証しながら設計を進める開発手法です。検証済みの制御モデルからソースコードを自動生成する工程も組み合わせられます。仕様書と実機に頼っていた検証を設計段階へ前倒しできる一方、初回導入ではモデル作成や検証の追加により、設計工程の工数が増える場合があります。この記事では、メリットとデメリットをIPA（情報処理推進機構）の実測データで示し、どこまで導入すれば元が取れるのか、MILS・SILS・HILSの使い分け、ツールの選び方、導入の手順までを扱います。

まとめ：モデルベース開発のメリット・デメリットと導入判断

• MBDは、実行できるモデルを設計の正本にして、シミュレーションで検証しながら設計を進める手法。検証済みのモデルからコードを自動生成する工程と組み合わせて使うことが多い。自動車のECUを中心に、制御ソフトの開発で使われている。
• メリットは、設計段階で不具合を見つけられること、コーディング工数が大きく減ること、モデルを次の製品で再利用できること。IPAの実験では、適合・評価工程と基礎教育工数を除く開発工数が6.41人月から4.39人月へ約32%減った。
• デメリットは、設計工程の工数が増えること、ツール費用と教育の初期投資、プラントモデルの精度と保守への依存、自動生成コードの効率と検証の負担。
• 同じ報告書の試算では、システム設計だけに導入すると全体工数は3%増え、ソフトウェア設計か検証の1工程だけなら削減は12%未満。コード生成を使わずに設計と検証へ導入した場合は4%で、全工程の32%との差はほぼソフトウェア作成工程（コード生成）の短縮分にあたる。
• 向くのは、制御ロジックが複雑で、試作や実機試験が高く、検証を何度も繰り返す製品。UI中心で物理プラントとの検証が不要な案件や、単発・小規模で追加投資を回収できない案件では、導入の優先度は低い。

モデルベース開発（MBD）の定義と従来開発との違い

従来の開発は、仕様書を文章で書き、手でコードを書き、実機を組んでから検証します。仕様の誤りが実機試験で初めて見つかり、設計まで戻る手戻りが起きやすい進め方です。MBDでは、仕様をそのまま動かせるモデルとして書くため、実機ができる前に挙動を確かめられます。

制御モデルとプラントモデルで動く仕様を作る仕組み

MBDで作るモデルは2種類あります。1つは制御ロジックを表す制御モデル（コントローラモデル）、もう1つはモーターやエンジンなど制御される側の物理的な挙動を表すプラントモデルです。2つをつないでシミュレーションすると、制御ロジックが狙いどおりに対象を動かせるかを机上で確かめられます。検証が済んだ制御モデルからC言語などのコードを生成し、組込み機器に載せます。モデルが仕様書・設計書・検証環境を兼ねるため、「仕様書の読み違い」による不具合が入りにくくなります。

MBSE・CAE・1DCAEとの違い

MBDと混同されやすい用語を、扱う対象で分けると次のとおりです。

MBSE（Model-Based Systems Engineering）をINCOSE（国際システムズエンジニアリング協議会）は、要求・設計・解析・検証と妥当性確認の活動を支えるため、概念設計から開発とその後のライフサイクルまでモデリングを形式化して適用することと定義しています。記述にはSysMLが使われ、2025年9月にはOMGがSysML 2.0を正式仕様として公開しました。実務では、MBSEのシステムモデルとMBDの制御モデルを連携させ、要求と設計・検証結果の整合を確認します。CAEの解析結果はプラントモデルの数値に使うことはあっても、CAE自体はソフトを作る手法ではありません。1DCAEは、形状を決める前の機能検討から個別設計後のシステム検証までをつなぐ設計の考え方で、MBDと適用範囲が重なります。提唱した東芝の東芝レビューの解説論文は、「1D」は1次元の意味ではないと説明しています。システムの全体像と機器の挙動をそろえて見る考え方はデジタルツインとシミュレーションの違いでも整理しています。

モデルベース開発のメリット

主なメリットは、不具合の早期発見、コーディング工数の削減、モデルの再利用です。

設計段階のシミュレーションによる不具合の早期検出

従来開発でも設計レビューで不具合を検出できますが、動的な挙動の問題は後工程の試験まで残ることがあります。MBDでは設計工程の中でモデルを動かして確かめられるため、不具合をその工程の中で検出できます。IPAの実施報告書も、この手戻りの削減と不具合の検出漏れの抑制をMBDの主な効果に挙げています。実機では危険な限界条件や、センサー故障のような異常系も、モデル上なら壊れる部品を気にせず何度でも試せます。

自動コード生成によるコーディング工数の削減

自動生成の対象部分では手書き実装を省けるため、モデルからコードへ転記する際のミスを減らせます。ただし、周辺の手書きコードや統合部分の検証は残ります。IPAの実験（半導体製造装置の制御コントローラの開発を、従来開発とMBDで同じ製品について2回行った比較）では、ソフトウェア作成の工数が従来開発の2.72人月に対し、MBDでは0.94人月と半分以下でした。生成したコードには静的解析もかけ、モデルの検証と組み合わせて品質を確かめます。静的解析と動的テストの使い分けは静的テストとは？レビューと静的解析の違い・動的テストとの使い分けを比較で解説しています。

派生製品の開発におけるモデル資産の再利用

モデルはブロック単位で部品として切り出せるため、似た機能をもつ製品を続けて開発するほど効果が積み上がります。IPAの報告書は、制御対象のモーターのようなプラントモデルを資産として持っておけば、次の制御コントローラ開発で、初回に増えたシステム設計工数（プラントモデルの作成と検証）を減らせると述べています。モデルは構造化された図で書くため、修正箇所の特定やレビューもしやすく、担当者によって成果物の書き方がばらつくことも抑えられます。

モデルベース開発のデメリット・課題

見誤ると導入が止まるのは、設計工程の工数増と初期投資の2つです。

モデル作成・検証による設計工程の工数増加

MBDは検証を設計工程へ前倒しするため、設計工程そのものは重くなります。IPAの実験では、MATLAB/Simulinkを使ったシステム設計とソフトウェア設計に、従来開発よりそれぞれ0.2人月、0.3人月多くかかりました。全体では減っても、設計担当の負荷は上がり、検証担当の仕事は減ります。V字の左側に人を寄せる体制の組み替えが必要になる点は、計画段階で織り込んでおく必要があります。

ツール費用と教育の初期投資

MATLAB/Simulinkは、コード生成や検証のアドオン製品を足していく構成で、必要な製品の組み合わせと契約形態で費用が変わります。製品構成と料金の目安はMATLAB/Simulinkとは？何ができる・違い・料金を初心者向けに解説にまとめています。教育の負担も無視できません。IPAの実験では、MBD経験者がいないチームで、MathWorksの無料E-learning 1.5人日、書籍での学習6人日、MathWorks主催の社外講習5人日の合計12.5人日（約0.63人月）を基礎教育の工数として計上しています。モデル作成の実践はOJTで行うため、この数字には含まれていません。

プラントモデルの精度と保守への依存

シミュレーションの結果は、プラントモデルが実機の挙動をどこまで再現できているかで決まります。摩擦や温度変化が要求精度に影響する場合、それらを省いたモデルでは実機との差を見落とすおそれがあります。MathWorksのParameter Estimatorでは、推定に使ったものとは別の実測データとモデル出力を比較して妥当性を確認します。製品の仕様変更に合わせてモデルを更新し続ける体制がないと、実機とずれたモデルが誤った判断の元になります。プラントモデルの作成には、制御設計に加えて対象機器の物理特性を理解し、実測データとモデルを照合する技能が必要です。

自動生成コードの効率と検証の負担

生成コードは、手で最適化したコードよりサイズや実行速度で劣る場合があり、メモリやリアルタイム性の制約が厳しいマイコンでは生成設定の調整が要ります。Embedded CoderではコードサイズのレポートとPIL実行時のプロファイルを使い、対象マイコンの制約を満たすか確認できます。不具合は生成コードでなくモデル側で直すのが原則で、生成ツールの信頼性を機能安全の要求に応じて示す作業も別に発生します（後述）。

IPA実測・試算で見る導入範囲別の工数効果と評価の限界

工程別の工数と適用条件を確認できる一次資料の一つが、IPA/SECの「モデルベース開発ツールを活用した際のコストの効果検証」実施報告書（2013年2月、東芝情報システムへの委託実験）です。同じ制御コントローラを従来開発とMBDで開発して工数を比べ、さらにMBDを入れる工程の数で4段階の適用レベルを定義しています。実測したのは適合・評価工程を除く4工程に適用したL3で、L1とL2はL3の工程別データから組み立てた試算です。以下の「全工程」は、この実験対象の4工程を指します。

全工程に通したL3では、従来開発6.41人月に対してMBDが4.39人月で、約32%の削減でした。内訳は、システム設計とソフトウェア設計が増え、ソフトウェア作成とソフトウェア検証の減少がそれを上回るという形です。L1の幅は、どの1工程に入れるかで変わります。システム設計だけに入れた場合は-3%（工数増）、ソフトウェア設計だけなら-5%以上7%未満、ソフトウェア検証だけなら0%以上12%未満という試算です。L2はシステム設計・ソフトウェア設計・ソフトウェア検証に入れてコード生成だけ使わない想定で、それでも4%にとどまります。

この試算からは、システム設計だけへの導入では工数増となる一方、ソフトウェア設計だけへの導入では工数が減る可能性もあると読み取れます。ただし削減幅が大きく開くのはコード生成まで通したときで、従来開発の総工数6.41人月を分母とする削減率への寄与は、システム設計-3、ソフトウェア設計-5、ソフトウェア作成28、ソフトウェア検証12ポイントです。L2との差の28ポイントは、そのままソフトウェア作成工程の短縮分にあたります。試すなら、小さな機能を1つ選び、モデル作成からコード生成、MILS・SILSでの検証までを1回通すパイロットにします。設計工程だけの評価結果を、コード生成を含むMBD全体の効果へ一般化することはできません。設計工程への限定導入が目的なら、その範囲で費用対効果を判断します。

ただし、数字の扱いには限度があります。この実験はV字プロセスを1回だけ実施した結果で、報告書自身も、繰り返したときの効果と実機を使う検証での効果は別途検証が必要としています。対象は1製品で、教育工数0.63人月は全体工数とは別に示されています。この教育工数を加えると5.02人月となり、従来開発6.41人月との差は約22%です。投資回収は、さらにツール購入・保守費と自社の人月単価を含めて判断します。2回目以降は学習効果で削減率が上がると報告書は見込んでいますが、測ってはいません。32%は、この製品・体制・評価範囲で得られた実測結果です。自社の削減率は、対象機能と評価範囲をそろえたパイロットで測定します。

モデルベース開発が向く分野・向かない分野

判断の軸は「制御ロジックの複雑さ」と「試作・実機試験のコストと反復回数」の2つです。両方が高いほど、設計工程の工数増と初期投資を回収しやすくなります。

• 向く：自動車のエンジン・モーター・ブレーキ・ADASの制御、航空宇宙、産業用ロボット、モーションコントローラ、医療機器、電力・エネルギー機器の制御。物理的な挙動をフィードバック制御する製品で、実機試験が高く、派生製品が多いもの。
• 向かない：業務アプリケーション、Webシステム、UI中心のソフト、データベース処理が主体のシステム。物理プラントとの閉ループ検証を必要としない案件では、本記事で扱う制御系MBDの優先度は低い。ただし、UIや通信プロトコルの状態遷移をStateflowで設計・検証することはできる。
• 向かない：単発の小規模開発で、既存モデルや習熟者がおらず、試作・試験費の削減だけではモデル作成と教育の追加費用を回収できない案件。

組込みソフト全体の工程や外注の判断は組み込みソフトウェア開発とは？工程・費用相場と内製・外注の判断基準を解説、ハードの制約がある開発で反復型の進め方をどこまで取り入れられるかはアジャイル開発は組み込みでどこまで使えるか｜ハード制約下の適用範囲と判断基準で扱っています。

V字開発プロセスでの検証手順（MILS・SILS・PILS・HILS）

V字プロセスの左側の設計でモデルを詳細化し、右側の検証では、検証する対象をモデル、生成コード、実際のマイコン、実機ECUと段階的に本物へ近づけます。V字モデルそのものはウォーターフォール開発とは？工程・V字モデルと契約、向く案件を発注者目線で解説で解説しています。

MILS（Model-In-the-Loop Simulation）では、ハードウェア起因の誤りや実行時間は分かりません。SILS（Software-In-the-Loop）は生成したコードをPC上で動かし、モデルと同じ結果になるかを比べます。PILS（Processor-In-the-Loop）は同じ比較を実際に載せるマイコン上で行い、固定小数点の演算誤差や実行時間を確認します。HILS（Hardware-In-the-Loop）は量産相当のECUをリアルタイムシミュレータにつなぎ、車両がなくても配線や通信、故障時の挙動まで試験します。設計の初期には、制御モデルを試作用の制御装置に載せて実機を動かすRCP（Rapid Control Prototyping）で制御パラメータを詰めることもあります。どの段階でどの要求を確かめたかを示すには、要求からモデル・コード・テストまでを紐付けます。考え方はITのトレーサビリティとは？要件から設計・実装・テストを紐付ける実装手順を参照してください。

MBDツールの選び方と量産コードの品質保証

ツールは「モデリングとシミュレーション」「コード生成」「検証」の3層で選びます。

MATLAB/Simulinkとコード生成ツールの役割分担

商用で事実上の標準になっているのはMathWorksのMATLAB/Simulinkで、2026年10月時点の現行リリースは2026年9月24日に発表されたR2026bです。Simulinkはブロック線図で制御系と物理系をモデル化してシミュレーションする環境で、状態遷移はStateflowで書きます。MathWorksの主なC/C++コード生成製品3つと、dSPACEのTargetLinkを比較します。

Embedded Coderは、MATLAB CoderとSimulink Coderに、生成する関数・ファイル・データを細かく制御する最適化を加えた製品です。Simulinkモデルから量産ECU向けコードを生成する場合は、Embedded CoderとdSPACEのTargetLinkが候補になります。dSPACEの版一覧では、TargetLinkの最新系列は2025-B（25.1）です。Simulinkモデルから生成する場合は両製品が候補になりますが、Embedded CoderはMATLABコードからの生成にも対応するため、Simulinkが常に前提になるわけではありません。

MATLABを使わない選択肢もあります。オブジェクト指向のモデリング言語Modelicaで書くOpenModelicaや、Scilabに統合されたXcosは、オープンソースのモデリング・シミュレーション環境です。異なるツールで作ったモデル同士をつなぐには、モデルを共通形式で受け渡す規格FMI（Functional Mock-up Interface）を使います。FMIの最新版は3.0.2（2024年11月27日公開）です。サプライヤーから受け取ったプラントモデルを自社のツールで動かす場面で効きます。

MISRA C・AUTOSAR・ISO 26262に対応した量産コード

車載ソフトでは、採用する規約・アーキテクチャ・機能安全要求に応じて、C言語のコーディング規約MISRA Cへの準拠、車載ソフトの標準アーキテクチャAUTOSARに沿ったコンポーネントの生成、機能安全規格ISO 26262に対応するためのツールの信頼性の証明が必要です。Embedded Coderの公式ドキュメントはAUTOSAR・MISRA C・ASAP2のサポートを記載しています。ただし、AUTOSARのモデル化とコード生成にはAUTOSAR Blocksetなど、用途に応じた追加製品の構成確認が必要です。ISO 26262のツール認定には、MathWorksがIEC Certification KitでASIL AからASIL Dまでの認定用の成果物やテンプレートを提供しています。TargetLinkも、ISO 26262・ISO 25119・IEC 61508への認証取得をdSPACEが明記しています。

認定キットは成果物やテンプレートを提供するもので、自社のプロジェクトでツールの信頼性を示す作業そのものは残ります。「コードを生成できる」ことと「量産で使える品質を示せる」ことは別の問題なので、ツール選定の段階で適用規格と安全要求を確認し、ISO 26262ではASIL、IEC 61508ではSILに応じた対応範囲を決めておきます。AUTOSARでのツールの受け渡しはAUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説で詳しく扱っています。

モデルベース開発の導入手順

IPAの実験結果を踏まえると、導入は「全工程を小さく1回通す」ことを軸に組みます。

1. 対象を選ぶ：制御ロジックが複雑で、派生製品が見込める機能を1つ選ぶ。既存製品の改良版のように、従来開発の工数実績があるものだと効果を比べやすい。
2. 基礎教育を先に済ませる：ツール操作と制御設計の基礎を学び、基礎教育とOJTの工数を分けて見積もる。
3. モデリング規約を決める：ブロックの配置や命名、使ってよいブロックを規約で揃える。国内の自動車業界では、JMAAB（Japan MATLAB Automotive Advisory Board）のモデリングガイドラインが使われてきた。規約がないと、人によって読めないモデルが量産される。
4. 全工程を1回通す：モデル作成、MILS、コード生成、SILSまでをパイロットで実施し、工程別の工数を記録して従来開発と比べる。
5. プラントモデルを資産にする：パイロットで作ったプラントモデルと制御部品をライブラリとして管理し、次の製品で再利用する。2回目以降の工数削減はここから生まれる。

制御機器のデータをクラウドに集めて分析するところまで含めて構成を考える場合は、AI/IoTソリューションの範囲で、機器側とクラウド側をまとめて設計する進め方もあります。

よくある質問

MBDとは何の略ですか？ほかの意味もありますか？

開発手法としてのMBDは、Model-Based Development（またはModel-Based Design）の略です。製造業では同じ略語が、3次元CADモデルに寸法や公差を書き込んで図面の代わりにするModel-Based Definition（モデルベース定義）や、機構の動きを解析するMulti-Body Dynamics（マルチボディダイナミクス）の意味でも使われます。「MBD 解析」と書かれていれば後者の機構解析を指すことが多く、文脈で区別します。

モデルベース開発の一番のデメリットは何ですか？

設計工程の工数が増えることです。IPAの実験では、設計工程の増加をコード生成と検証の短縮で取り返す構造でした。導入する工程を選ぶときは、この増加分をどの工程で回収するかを先に決めておきます。

Simulinkがなくてもモデルベース開発はできますか？

モデル化とシミュレーションまでなら、OpenModelicaやScilab/Xcosのようなオープンソースの環境でできます。ただし、量産用のコード生成、ISO 26262のツール認定、取引先とのモデルのやり取りまで考えると、MATLAB/Simulinkが前提になる場面が多いのが実情です。量産を予定する場合は、モデルの移行や作り直しの負担を避けるため、コード生成・認定支援・取引先との受け渡し要件を初期段階で確認して環境を選びます。

モデルベース開発の将来性はありますか？

自動車業界では業界ぐるみで普及が進められています。経済産業省の研究会を起点に、完成車メーカーとサプライヤーの間でモデルを流通させる「SURIAWASE2.0」が進められ、経済産業省の調査報告書はモデル作成方法の標準化、モデルとデータの安全な流通、事例と教育の充実を課題に挙げています。2021年7月にはMBD推進センター（JAMBE）が発足し、2023年4月に一般社団法人へ移行しました。業界団体が標準化と教育を担う段階に入っており、自動車の制御ソフト開発での需要は続くと見られます。

モデルベース開発のエンジニアに必要なスキルは何ですか？

制御工学（フィードバック制御、伝達関数、離散化）の基礎、対象機器の物理の理解、MATLAB/Simulinkの操作、生成コードを組込み機器に載せるためのC言語とマイコンの知識です。プラントモデルを作成する際は、制御と物理の両方を理解し、実機の測定結果からモデルの妥当性を判断する力が求められます。

関連記事

• MATLAB/Simulinkとは？何ができる・違い・料金を初心者向けに解説
• AUTOSAR開発の工程とは？ARXMLの受け渡しとツールチェーンを実装目線で解説
• 組み込みソフトウェア開発とは？工程・費用相場と内製・外注の判断基準を解説
• アジャイル開発は組み込みでどこまで使えるか｜ハード制約下の適用範囲と判断基準
• ウォーターフォール開発とは？工程・V字モデルと契約、向く案件を発注者目線で解説