MBSEとは何か、そしてなぜ今必要なのか——記述モデルとRFLPで読み解く自動車開発の変革

「MBSE」という言葉、最近よく耳にするのではないだろうか。

ものづくり業界のカンファレンスや社内の技術勉強会でポツポツ出てくるようになった言葉だ。だが「なんとなく聞いたことあるけど、正直よくわからない」という人が多いのではないだろうか。かくいう私も、某自動車OEMで働いていた頃はMBSEについてほぼ何も知らなかった。

当時の私が知っていたのはMBD（モデルベース開発）のほうだ。Simulinkを使って制御ロジックをモデルで記述し、シミュレーションで検証しながら開発を進める——そのプロセスに日々向き合っていた。

その後、超大手OEMでMBSEに関わるようになって、初めて気づいたことがある。「モデルベース」という言葉は同じなのに、MBDとMBSEはまったく別の問題を解こうとしている、と。そして、なぜMBSEが今これほど注目されているのかを理解したとき、これは単なるツールの話ではなく、自動車開発の構造そのものを変える話だと感じた。

この記事では、MBSEの概念と、それを支える「記述モデル」「RFLP」という考え方を丁寧に解説する。「なぜMBSEが必要なのか」という問いから始め、「どう機能するのか」という実務の話まで、現場の体感とともに整理していく。

ドキュメントベース開発の限界——何が問題だったのか

MBSEが生まれた背景を押さえておきたい。

自動車1台の開発を想像してみてほしい。エンジン制御、ブレーキシステム、エアコン、ナビ、運転支援機能……それぞれに膨大な要件がある。「何を実現しなければならないか」を記述すると、仕様書は優に何百ページにもなる。

そしてその仕様書を、自社の複数部門（メカ・エレキ・ソフト）と、数十社にのぼるサプライヤーが分担して読み込み、設計を進める。

問題が起きやすいのはここだ。

• 仕様書が更新されたが、全員に伝わっていない

• 「この機能、どの仕様書に書いてあったっけ？」と誰もわからない

• 設計変更をしたら、関連する別の仕様書も直さなければならないのに漏れた

• 上流の要件と、下流の設計がズレていたことに、テスト段階で初めて発覚する

これはドキュメントベース開発の構造的な弱点だ。ドキュメントはいくら丁寧に書いても、「書いた瞬間から古くなっていく」という宿命を持っている。人が読んで解釈するものである以上、伝言ゲームの誤りも生まれやすい。

現代の自動車は、1台にECU（電子制御ユニット）が100個以上搭載される時代だ。さらにEV・HEVの開発では、バッテリー、モーター、熱マネジメント、ソフトウェアが複雑に絡み合う。そのスケールで「ドキュメントを読んで開発する」ことの難しさは、想像に難くない。

なぜ今MBSEなのか——EV×複数プラットフォームでの開発が複雑さを加速させた

EV×複数プラットフォームでの開発は、自動車開発の複雑さを別次元に引き上げた。

従来の内燃機関車では、エンジン・ミッション・シャシーのような機能ブロックが比較的独立していた。長年にわたる擦り合わせ開発で蓄積された設計資産があり、部門ごとに「自分たちの仕様書」と「自分たちのノウハウ」を持って独立して開発を進めることができた。その資産があったからこそ、ドキュメントベースでも回っていた側面がある。

EVはそうではない。バッテリーの温度はモーターの出力に影響し、モーターの出力は車両の走行性能に影響し、走行性能は空調や暖房による電力消費にも影響される。すべてがシステムとして絡み合っている。

しかも開発期間の短縮と、車両モデルの多様化（複数車種・プラットフォーム共用）が同時に求められる個々の車種ごとに独自設計を積み重ねる」やり方では、コストも期間も対応しきれなくなってきた。

MBSEが必要とされる理由はここにある。システム全体を「繋がったモデル」として持つことで、変更の影響を即座に把握し、複数車種間での共通化・最適配分を効率的に行える。ドキュメントでは実現できなかったことが、モデルなら可能になる。

MBSEとは何か——定義と「記述モデル」の役割

では、MBSEとは何かを定義する。

ここで登場する「モデル」は、シミュレーションモデルとは少し違う。MBSEで使うモデルは記述モデルと呼ばれる。

記述モデルとは、「システムの構造と意図を、機械が読み取れる形で記述したもの」だ。

ドキュメント（Word・Excel）は「人が読む」ものだ。検索はできても、中身の構造や関係性は人間が頭で把握しなければならない。

記述モデルは「コンピュータが構造を理解できる」ものだ。要件と機能の間に「この要件を満たすためにこの機能がある」というつながりが、データとして定義されている。だから「この要件が変わったとき、影響を受ける機能はどれか」を自動でリストアップできる。整合性チェックも自動でできる。

ドキュメントが「テキスト」だとすれば、記述モデルは「構造を持ったデータベース」に近いイメージだ。

この記述モデルを書くための標準言語としてSysML（Systems Modeling Language）がある。ブロック図やシーケンス図など、システムの構造・振る舞い・要件をUML風の記法で表現する。ただし、SysMLの記法を詳しく知らなくてもMBSEの考え方は理解できるため、この記事では概念を中心に進める。

RFLPという4層構造——要件から部品まで「つながり」を設計する

MBSEで開発を進めるとき、中心となるフレームワークがRFLPという4層構造だ。

• R（Requirements）：要件層——何を実現すべきか

• F（Functional）：機能層——どんな機能が必要か

• L（Logical）：論理層——機能をどう構成するか（ハードかソフトかを決める前）

• P（Physical）：物理層——実際にどんなコンポーネントで実現するか

これだけ見ると抽象的なので、自動車でおなじみのAEB（自動緊急ブレーキ）を例に説明する。

R（要件）：「前方に障害物を検知したとき、衝突を回避または軽減するよう自動停止すること」

まずこの要件がある。「何をしなければならないか」を定義する層だ。安全法規や車両目標性能がここに入る。

F（機能）： この要件を満たすために必要な機能を分解する。「前方の距離・速度を計測する機能」「衝突リスクを判断する機能」「ブレーキを作動させる機能」——といった抽象的な機能ブロックとして列挙する。この段階ではまだ、「カメラでやるのか、レーダーでやるのか」は決めない。機能の「何を」だけを議論する層だ。

L（論理）： 機能をどう構成するかを決める層だ。「センサ処理ブロック」「制御ロジックブロック」「アクチュエータ制御ブロック」といった論理的なブロック構成を定義する。ここからソフトとハードの割り当てが議論され始めるが、まだ具体的な製品名は登場しない。

P（物理）： 最終的に、実際のコンポーネントに落としていく。「ミリ波レーダー」「統合ECU」「電動ブレーキユニット」という具体的な部品・製品として実装を決定する。

RFLPの本当の価値：「なぜこの部品があるのか」を遡れる

この4層構造の価値は、層をまたいだトレーサビリティ（追跡可能性）にある。

従来のドキュメントベース開発では、「要件書」「機能設計書」「詳細設計書」がそれぞれ別のドキュメントとして存在し、繋がりは人間の頭の中にしかなかった。

RFLPモデルでは、要件→機能→論理→物理のつながりがデータとして定義されている。だから——

• ある要件が変更になったとき、影響する機能・コンポーネントが瞬時にわかる

• ある部品が廃番になったとき、どの機能・どの要件に影響するかが追跡できる

• 「なぜこのコンポーネントが必要か」を、要件まで遡って説明できる

これは特に、複数車種で部品を共通化しようとするとき——EVのファミリー開発で——絶大な力を発揮する。「この部品を共通化すると、どの車種のどの要件に影響するか」が設計段階で見えるからだ。

RFLPを重ねることで実現する階層的な要求割付

さらに重要な点がある。RFLPは1セットで完結するものではなく、複数を階層的に重ねることができる。

車両レベルのRFLPではP層（物理層）にシステムが現れる。そのシステムを今度は次のRFLPのR層（要件層）として受け取り、さらにF・L・Pへと展開していく。

• 車両レベルRFLP：車両要求 → 車両としての機能・システム要求

• システムレベルRFLP：システム要求 → サブシステムの機能・ユニット構成

• 部品レベルRFLP：ユニット要求 → 部品の機能・詳細仕様

RFLPを複数重ねることで、車両要求→システム要求→ユニット要求という、階層を跨いだ要求割付が可能となる。「車両が何を実現すべきか」が、最終的に個々の部品への具体的な仕様として降りてくる筋道がモデルとして可視化されるのだ。

ある部品仕様が変わったとき、それが車両レベルのどの要求に影響するかを即座にトレースできる——これこそが、ドキュメントでは絶対に実現できなかった世界だ。

MBDとMBSEの違い——「モデルベース」という言葉が生む混乱

「モデルベース」という言葉が共通しているせいで、MBDとMBSEを混同しがちだ。私自身、超大手OEMでMBSEに関わり始めた初期は、両者の違いが腹落ちしていなかった。

整理するとこうなる。

MBD（モデルベース開発） は、制御ロジックをSimulinkなどのツールで記述し、コードの代わりにモデルを使って開発するアプローチだ。某自動車OEMでの経験がまさにこれで、「モデルを動かしてシミュレーション→コード自動生成→テスト」というサイクルで制御ソフトを作っていた。MBDの「モデル」は制御アルゴリズムそのものだ。

MBSE（モデルベースシステムズエンジニアリング） は、システム全体の要件・アーキテクチャを記述モデルで管理するアプローチだ。制御の中身ではなく、「どんなシステムを作るか」という上流設計をモデル化する。

シンプルに言い換えると——

対象レイヤーがまったく違う。MBDが「実装」の話であるのに対し、MBSEは「設計・要件管理」の話だ。

ただし、この2つは連携してこそ本領を発揮する。MBSEで定義した機能・論理アーキテクチャが、MBDの制御モデルへと具体化されていく——その接続が実現できたとき、「要件から実装まで一本の糸でつながった開発」が初めて可能になる。この連成については、後の記事で詳しく取り上げる。

実際の現場でMBSEを使うとどうなるか

超大手OEMでの実務を少し紹介する（社内の具体的な設計内容は省く）。

要件管理とアーキテクチャのモデリング、テストとのひも付にはSystem Composer（MATLAB/Simulinkのアドオン）を使っている。RFLPの各層をモデルとして構築し、層をまたいだトレーサビリティを定義していく。また、「この要件に対してどのテストケースが存在するか」「この要件はどの機能に割り当てられているか」が一元管理されている。

実際に体感した変化でいうと——ある要件が変更になったとき、影響する機能とテストケースが瞬時にリストアップできるようになった。ドキュメントベースの頃なら、複数のエクセルやWordを手で確認して回り、それでも漏れが出る作業だった。

ただし、正直に言う。MBSEは「入れれば万事解決」ではない。

モデルを正確に保つには、変更があるたびにモデルを更新し続ける運用が必要だ。ツールの学習コスト、チーム全体への浸透、組織文化の変革——これらがないとモデルはすぐに「誰も更新しない置物」になる。導入の効果を引き出すには、技術だけでなくプロセスと人の変化が伴う必要がある。

まとめと次回予告

この記事で伝えたことを整理する。

ドキュメントベース開発の限界——仕様書が膨れ上がり、更新が追いつかず、整合性の維持が困難になる——という課題は、EVの登場でさらに深刻になっている。MBSEはその問題に「記述モデルでシステム全体をつなぐ」ことで応えようとしている。

記述モデルとは、システムの構造と意図をコンピュータが読み取れる形で書いたものだ。RFLPという4層構造（要件→機能→論理→物理）は「なぜこの部品があるのか」を要件まで遡れるトレーサビリティを実現する。さらにRFLPを複数重ねることで、車両要求→システム要求→ユニット要求という階層を跨いだ要求割付が可能となる。MBDが「コードの代わり」なのに対し、MBSEは「ドキュメントの代わり」——「モデルで考える」思想の、上流への拡張だ。

次回は、EV開発の現場でこのRFLPを実際にどう使うかを具体的に見ていく。 バッテリー熱マネジメントという「予測が難しい」ドメインで、車両目標をどう分解し、どう部品に割り付けるか。そして「大は小を兼ねる」という設計思想がEVでは通じないケースも、正直にお伝えする。

この記事は、某自動車OEMでMBD（モデルベース開発）を経験し、現在は超大手OEMでMBSEに携わる著者が、現場の視点で書いている。記事内の具体例はあくまで概念説明のためのものであり、各社の機密情報や内部設計は含まない。