空調設計にMBSEが必要な理由：SysMLで要求・機能・構造をつなぐ

MBSE導入を判断するための問い

空調設計でMBSEが必要になる理由
SysMLで要求・機能・構造・検証をつなぐ方法
設計レビューで最初に確認する項目

空調機の設計は、以前よりもずっと「システムの設計」になっています。圧縮機、熱交換器、膨張弁、ファン、筐体、冷媒配管、センサ、インバータ、制御ソフト、通信、保守、法規制までが、ひとつの性能結果として現れるからです。

メカ設計の重要性が下がったわけではありません。熱交換器の配置、風路、振動、騒音、結露、霜付き、強度、加工性、保守性は今も空調機の競争力の中心です。ただし、メカ設計だけを最適化しても、製品全体の要求を満たしたとは言い切れない場面が増えています。

例えば省エネ性能を上げたいとき、熱交換器を大きくする、圧縮機効率を上げる、ファンを最適化する、という単品改善だけでは不十分です。低負荷運転、除霜、快適性、騒音、制御安定性、コスト、重量、冷媒量、センサ誤差、現地施工ばらつきまで関係します。さらにAI制御やBEMS連携を入れる場合、データ要件、フェイルセーフ、説明可能性、異常時の責任分界も設計対象になります。

この複雑さに対して、図面、Excel仕様書、会議メモ、個人の経験だけで整合を取り続けるのは難しくなっています。そこで必要になるのがMBSE、つまりModel-Based Systems Engineeringです。MBSEは、設計を「文書中心」から「モデル中心」に変える考え方です。空調設計では、要求、機能、構造、振る舞い、制御、検証、故障モード、データ要件をつなぎ、設計変更の影響を追える状態にすることが目的です。

結論：MBSEは設計判断をつなぐ活動

空調設計にMBSEが必要になる最大の理由は、設計判断の因果関係を見える状態にするためです。

「なぜこの熱交換器サイズにしたのか」「なぜこのセンサを必要としたのか」「なぜこの制御モードでは圧縮機回転数を制限するのか」「なぜこの故障モードをFMEAに入れたのか」「なぜこの試験で要求を満たしたと言えるのか」

こうした問いに対して、担当者の記憶や散在した資料に頼らず、要求、機能、構造、振る舞い、検証をたどって説明できるようにする。これが空調設計におけるMBSEの価値です。

観点	従来起きやすい状態	MBSEで目指す状態
要求	仕様書にあるが設計要素との対応が曖昧	要求と機能、構造、検証がつながる
部門連携	メカ、制御、電気、品質が別資料で動く	共通モデルで接口と責任範囲を確認する
変更影響	経験者が影響範囲を探す	変更対象から関連要求や試験へたどる
品質	FMEAが後工程の帳票になる	機能や構造から故障モードを抽出する
AI制御	PoC精度だけに議論が寄る	データ要件、安全要求、フォールバックまで扱う

MBSEはCADやCAEの代替ではありません。 3D形状、熱流体解析、強度解析、回路図、制御ロジックはそれぞれ必要です。MBSEは、それらを「どの要求を満たすための設計か」という上位の骨格でつなぐものです。

ISO/IEC/IEEE 15288:2023はシステムの構想から開発、製造、利用、支援、廃棄までに適用できるライフサイクルプロセスの共通枠組みを示しますが、特定の開発手法やモデリング技法を指定していません。したがって、MBSEは「規格に書かれた図を描く作業」ではなく、自社のライフサイクルと意思決定へモデルを組み込む実装方法として設計する必要があります。

なぜ空調設計で必要になるのか

空調設計では、ひとつの設計変更が複数領域へ広がります。ファン回転数を変えれば、熱交換性能、騒音、消費電力、制御安定性に影響します。除霜制御を変えれば、暖房能力、快適性、ドレン処理、圧縮機保護に影響します。冷媒を変えれば、圧力、部品選定、冷媒量、漏えい検知、保守手順に影響します。

特に近年は、制御ソフトとデータ活用の比重が大きくなっています。インバータ制御、電子膨張弁制御、ファン制御、異常検知、保護制御、通信制御は、製品の振る舞いそのものです。機械設計が良くても、センサ位置、応答性、制御条件、例外処理が曖昧なら、期待した性能は出ません。

AI制御ではさらに注意が必要です。熱負荷予測や省エネ制御を成立させるには、入力データ、センサ精度、データ周期、欠損処理、推論環境、説明可能性、異常時のフォールバックが必要です。これはAI担当だけの課題ではなく、空調システム設計、制御設計、品質保証、設備運用が一緒に決める要求です。

つまり、空調設計で起きている問題は「部品をもっと詳しく設計すれば解ける」だけではありません。要求、機能、構造、制御、検証のつながりが見えていないことが、手戻りや認識齟齬の原因になります。MBSEは、このつながりを設計の早い段階で見える化するために使います。

MBSEで何をつなぐのか

空調設計でまずつなぎたいのは、次の7つです。

つなぐ対象	空調設計での例	目的
要求	冷暖房能力、COP、騒音、信頼性、保守性	何を満たすべきかを明確にする
機能	圧縮する、熱交換する、送風する、検知する	部品名ではなく役割で整理する
構造	圧縮機、熱交換器、膨張弁、ファン、センサ	機能をどの要素が担うか示す
振る舞い	冷房、暖房、除霜、異常停止、復帰	状態や切替条件を整理する
制約	コスト、寸法、重量、冷媒量、施工条件	設計自由度の境界を見える化する
検証	性能試験、騒音試験、異常試験、制御確認	要求を満たした根拠を残す
リスク	冷媒漏えい、凍結、過電流、センサ異常	FMEAや安全要求へ展開する

この7要素に、実務では「根拠」「責任者」「変更履歴」を加えます。要求の出典が顧客仕様なのか、法規・規格なのか、社内設計目標なのかを区別し、変更承認者と有効な版を記録します。これがないモデルは、関係が描かれていても設計ベースラインとして使えません。

ここで重要なのは、最初からすべてを完璧にモデル化しないことです。全製品、全要求、全部品を対象にすると、作業量が膨らみ、モデルが更新されなくなります。最初は、手戻りが多いテーマに絞るのが現実的です。

空調設計なら、除霜運転、騒音要求、冷媒回路変更、AI省エネ制御、圧縮機保護、冷媒漏えい検知などが向いています。これらは複数部門が関係し、要求、構造、制御、検証が絡むため、MBSEの効果を実感しやすい領域です。

SysMLで最初に使いたい図

MBSEを実務に落とす表現方法として、SysMLは有効です。ただし、最初からすべての図法を覚える必要はありません。空調設計では、まず次の5種類で十分です。

要求図

上位要求と下位要求の関係を整理します。例えば「寒冷地暖房性能を確保する」という要求を、外気温条件、暖房能力、除霜復帰時間、室温低下許容、圧縮機保護、検証試験へ分解します。曖昧な要求を、設計と試験に使える形へ変えるための図です。

ブロック定義図

システムを構成要素に分けます。室外機なら、圧縮機、熱交換器、膨張弁、四方弁、ファン、配管、センサ、制御基板、筐体などです。部品表を写すのではなく、設計上の関係が分かる粒度で整理します。

内部ブロック図

構成要素間の接続を整理します。空調機では、冷媒、空気、電力、信号の流れを分けて見ると有効です。どのセンサ値をどの制御に使い、どのアクチュエータへ指令を出すのかが見えます。

状態機械図

冷房、暖房、除霜、停止、保護停止、異常停止、復帰などの状態と切替条件を整理します。特に除霜、センサ異常、通信断、停電復帰、AI制御無効時の振る舞いは、品質や安全に直結します。

パラメトリック図

熱収支、COP、消費電力、風量、圧力損失、騒音、冷媒量などの関係を整理します。厳密なシミュレーションモデルでなくても、どの変数がどの性能指標に効くかを見える化できます。

OMGの現行正式仕様はSysML 2.0です。v1.7も正式仕様として公開され、OMGは移行に数年を要することを想定しています。本記事の「要求図・BDD・IBD・状態機械図・パラメトリック図」はv1系で馴染みのある入口です。新規導入時は、記法の新しさだけで決めず、既存資産、ツール相互運用、API、レビュー参加者の習熟、長期保守を比較し、採用仕様版を構成管理してください。

MBSEを導入すべきか判断する

「複雑だからMBSE」では投資判断になりません。過去の設計変更や不具合を10件程度取り上げ、影響追跡に要した時間、後工程で見つかった接口漏れ、試験やり直し、要求根拠の探索時間を実測します。次の症状が複数あり、同じ関係を繰り返し調べているなら、モデル化の優先度が高いと判断できます。

現場の症状	先にモデル化する関係	導入前後で測る指標
変更のたびに影響会議が長引く	要求→機能→構造→試験	影響候補抽出までの時間、見落とし件数
制御仕様と機械仕様の接口不整合が多い	信号・単位・更新周期・有効状態	接口起因の差し戻し件数
FMEAで毎回機能を洗い直す	機能→構造→故障→検出→退避	新規故障モードの発見工程、未処置数
試験したのに要求を閉鎖できない	要求→合否基準→試験ケース→証拠	要求に紐づかない試験、証拠欠落率
AI PoCと製品制御がつながらない	データ→推論→制約→フォールバック	PoC後に追加された安全・データ要求数

導入の効果指標は図数やモデル要素数にしません。それらは作業量を増やすほど良く見えるからです。「重大要求の追跡率」「変更影響の確認時間」「レビューで閉鎖できた未決事項」「要求と試験証拠の接続率」など、意思決定と手戻りに結び付く指標を使います。

小さく始める導入手順

MBSE導入は、大きく始めるより小さく始めた方が定着します。

1. 対象テーマをひとつに絞る 2. 上位要求を5から10個に分解する 3. 要求を満たすための機能を洗い出す 4. 機能を構造要素へ割り当てる 5. 運転状態と異常時の例外を整理する 6. 要求ごとに検証方法をつなぐ 7. 設計変更時にモデルを更新する

最初の成果物は、豪華なモデルでなくて構いません。むしろ、要求、機能、構造、状態、検証を1行でつなぐ表から始める方が、設計レビューで使いやすくなります。

要求	機能	構造要素	状態・条件	検証
暖房運転時の快適性を維持する	室内へ熱を供給する	圧縮機、熱交換器、ファン	低外気温、除霜前後	暖房能力試験、除霜復帰確認
異常時に安全側へ停止する	異常を検知し保護する	センサ、制御基板、インバータ	センサ断線、過電流	異常注入試験、保護停止確認
AI省エネ制御を安全に使う	熱負荷を予測し運転を補正する	センサ、通信、AIモデル	データ欠損、通信断	欠損試験、フォールバック確認

この表だけでも、議論は「この部品でよいか」から「この要求に対して、この機能と検証で足りるか」に変わります。

除霜制御で作る最小の影響マップ

起点	直接影響	二次影響	必要な証拠
霜検知ロジック変更	除霜開始条件、誤検知、検出遅れ	暖房能力、消費電力、快適性	センサ時系列、状態イベント、能力・電力ログ
四方弁切替時間変更	圧力遷移、冷媒流れ、運転シーケンス	騒音、保護制御、部品耐久	高低圧、弁指令、音・振動、保護イベント
室外ファン回転数変更	熱交換、着霜、風量	騒音、入力、圧縮機運転点	回転数、風量、温度、入力、騒音条件
温度センサ位置変更	応答遅れ、代表性、配線	除霜判定、故障診断、サービス性	配置図、校正、応答試験、断線・固着試験

ここで数値をモデルへ入れる場合は、必ず単位と適用条件を属性にします。温度`°C`だけでなく測定位置と応答時定数、圧力`MPa`だけでなく絶対圧/ゲージ圧、風量`m³/s`だけでなく測定条件を固定します。単位変換はツール任せにせず、インターフェース試験で確認します。

よくある失敗

MBSEは便利ですが、導入の仕方を間違えると現場に嫌われます。

失敗	起きること	対策
ツール導入が目的になる	図を描く作業だけが増える	最初に解きたい手戻りテーマを決める
全部をモデル化する	工数が膨らみ更新されない	重要要求と重要接口から始める
記法の正しさに偏る	実務者が参加しにくい	判断が伝わることを優先する
メカ担当だけで作る	制御、電気、品質の要求が抜ける	初回レビューから複数部門を入れる
検証へつながらない	説明資料で終わる	要求ごとに試験や確認方法を紐づける
AIを別枠で扱う	PoCと量産設計が切り離される	データ要件とフェイルセーフを要求化する

特に避けたいのは、MBSEを「若手に図を描かせる活動」にすることです。図を描くこと自体は作業ですが、モデルに入れるべき判断は、ベテランや各専門担当の知見が必要です。設計責任者、制御担当、品質担当がモデルレビューに参加して初めて、実務に効くモデルになります。

実務例：室外機の仕様変更を小さくモデル化する

たとえば室外機ファンを変更する場合、形状や取付だけでなく、騒音要求、熱交換性能、消費電力、異常時の保護、保守交換性まで影響します。最初はファン、熱交換器、制御基板、騒音要求、性能試験だけを対象にし、要求IDと検証条件を対応させます。

確認項目	レビューで見ること
対象機種と対象状態を一つに絞る	量産機全体ではなく、ファン変更と暖房運転から始める
要求IDを付けて設計要素へ接続する	変更要求、部品、制御状態、試験項目をつなぐ
試験条件とログ項目を同じ表に置く	設計値だけでなく、実測ログの取得条件を残す
未決事項を責任部門付きで残す	モデル更新の担当とレビュー期限を明記する

MBSEの導入効果は、図の枚数では測れません。変更前後の要求、影響部品、試験結果、未決事項が同じ台帳で追えるかを、最初の評価指標にします。

モデルを更新し続ける運用ルール

タイミング	更新対象	完了条件
要求ベースライン	要求ID、根拠、適用範囲、検証方法	未根拠・未検証方法の重大要求がない
方式選定	機能分解、構造割当、トレードオフ	不採用案と判断根拠も参照できる
設計変更	影響先、接口、FMEA、回帰試験	変更審査で再検証範囲が承認される
試験完了	試験ケース、構成、ログ、結果	要求ごとに客観的証拠または逸脱承認がある
市場不具合	故障モード、検出、退避、保守情報	恒久対策が要求・設計・検証へ逆反映される

ISO/IEC/IEEE 29148:2018は要求の識別、文書化、維持、伝達、追跡をライフサイクル全体で扱います。ただし、2026年9月1日時点でISOページは同版を現行表示しつつ「改訂予定」としています。適合性を主張する案件では、契約で指定された版と最新改訂状況を別途確認してください。

参考資料・確認先

ISO, ISO/IEC/IEEE 15288:2023 System life cycle processes（システムライフサイクルの共通プロセス枠組み、確認日：2026-09-01）
ISO, ISO/IEC/IEEE 29148:2018 Requirements engineering（要求工学と要求情報項目。2026年時点の改訂状況を含む、確認日：2026-09-01）
Object Management Group, OMG Systems Modeling Language (SysML) Version 2.0（2025年採択の現行正式仕様、確認日：2026-09-01）
Object Management Group, OMG Systems Modeling Language (SysML) Version 1.7（v1系モデル資産を扱う場合の正式仕様、確認日：2026-09-01）
NASA, Systems Engineering Handbook: Fundamentals of Systems Engineering（境界、要求配分、トレードオフ、接口、V&Vを含む公開SE手引き、確認日：2026-09-01）
NASA Office of the Chief Engineer, NASA-HDBK-1009A Systems Modeling Handbook for Systems Engineering（SysMLを要求・V&V成果物へ接続する公開例、確認日：2026-09-01）

これらはプロセスとモデリングの参照資料であり、個別空調製品の性能値、安全要求、法規適合を自動的に決めるものではありません。対象市場の法規、契約、製品規格、自社標準を別途確認してください。

次に読むなら

次に読むなら、SysMLで空調システムを設計するとは何か？初心者向けに実務視点で解説がおすすめです。このテーマの全体像を整理する柱記事です。

関連テーマとして、機械設計者がSysMLを学ぶべき理由：制御・電気・ソフトウェアとの接点も参照すると、設計判断の前提をつなげて確認できます。

空調メーカーにおけるMBSE導入の第一歩: このテーマの全体像を整理する柱記事です。
空調室外機をSysMLでモデル化する基本手順: 前提を押さえると、この設計判断の位置づけがつかみやすくなります。
空調設計における要求定義の失敗事例とSysMLによる防止策: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。
CAD中心設計とSysML中心設計の違いを実務視点で比較する: 次に読むと、要求から構造・制御・検証へ論点を進めやすくなります。

まとめ

空調設計にMBSEが必要になる理由は、製品が複雑になったからだけではありません。空調機の価値が、部品単体の性能ではなく、要求、機能、構造、制御、検証、運用、データのつながりで決まるようになったからです。

メカ設計は今も重要です。しかし、メカ設計だけでは、制御ソフト、AI、法規制、保守、品質、データ活用まで含めた全体最適を説明しきれません。冷凍サイクルの物理、制御の振る舞い、AIのデータ要件、故障モード、検証方法をつなぐ必要があります。

MBSEは、図をきれいに描くための活動ではありません。設計判断をつなぎ、変更影響を追い、部門間の認識齟齬を減らし、設計レビューを強くするための活動です。最初は、除霜制御、騒音要求、冷媒回路変更、AI省エネ制御など、手戻りが多いテーマをひとつ選び、要求、機能、構造、状態、検証をつなぐ小さなモデルから始めるのが現実的です。

次に読む記事としては、次の3本が自然です。

SysMLで空調システムを設計するとは何か？初心者向けに実務視点で解説
空調室外機をSysMLでモデル化する基本手順
空調設計で活用するSysML図の優先順位：最初に習得すべき5種類