スマートビルとは？ビルOSの3層構造とBAS・BEMSとの関係、投資判断まで解説

スマートビルは、設備をIoTでつないだ建物という説明で語られることが多い言葉です。ただ、その説明のままでは、既に中央監視装置が入っているビルと何が違うのか、どこまで投資すればスマートビルと呼べるのかが決まりません。IPAが公開したガイドラインは、この言葉に3つの機能要件という形で線を引いています。この記事では、その定義、中核に置かれるビルOSが担う層と機能、既設のBASやBEMSと重ならない部分、そして既存ビルでどこから手を付けどこで止めるかという投資の順序を、見送るべき条件まで含めて整理します。

まとめ｜スマートビル化に踏み込むビル条件と、ビルOSを持たずに始める順序

結論から書きます。ビルOSまで踏み込んで費用が回収できるビルには、共通する条件が3つあります。竣工後もアプリケーションを足し続ける予算と主体が決まっていること、テナントや来訪者に対して設備制御以外のサービスを出す計画があること、そして複数棟または複数フロアにまたがってデータを横断させる用途があること。この3つのうち2つを欠く単棟の賃貸ビルでは、データ連携基盤を持っても載せるアプリケーションが出てこないまま保守費だけが残る。

逆に、条件を満たさないビルが何もできないわけではありません。順序としては、まず既設の中央監視から計測値を外部へ取り出せる口を作り、次にエネルギーと入退室のデータを1か所に集めて用途を検証し、そのうえで載せたいアプリケーションが2つ以上見えてきた段階でビルOSの導入を判断する。この順序なら、途中で止めても各段階の投資が無駄になりません。

発注の形は、データを集める部分と可視化はパッケージ製品、既存の業務システムとの接続とデータモデルの設計は受託開発、と分けるのが現実的です。ビルOSは製品名で選ぶ前に、自社ビルで何のデータをどこへ渡したいのかを先に決めてください。

スマートビルの定義｜IPAのガイドラインが示す3つの機能要件と設備IoT化の差

スマートビルという言葉には、業界共通の定義が長らくありませんでした。2023年5月31日に情報処理推進機構（IPA）のデジタルアーキテクチャ・デザインセンターがスマートビル関連ガイドラインの第1版を公開し、そこで定義が明文化されています。まずこの定義を確認します。

アセット連携・データドリブン制御・ビル間協調という3つの機能要件

総合ガイドラインはスマートビルを「以下の機能を全て有するビル」と定め、3つの機能を挙げています。第1に、ビル内外のアセットを組み合わせて提供可能な機能を拡張し、新たなサービスの創出や追加を行うこと。第2に、抽象化されたアセットを基にサイバーフィジカルシステムを実現し、データドリブンな制御を可能とすること。第3に、ビル間協調を典型とした外部アセットとの連携により、街の構成要素としてより広域にサービスを提供可能にすることです。

ここでいうアセットとは、物理的・電子的な資産の総称で、ビル内部の空間・機器・センサ・データから、ビル外部のアプリケーション・モビリティ・データまでを広く指します。3つの要件に共通するのは、どれも「ビルの設備が高機能になること」ではなく「ビルの外側とデータをやりとりできること」を求めている点です。

設備をIoT化しただけの建物が定義に届かない理由はデータの所在にある

センサを増やしてクラウドに上げれば、見た目には要件を満たしそうに見えます。ガイドラインが既存ビルの課題として挙げるのは、そこではありません。既存ビルでも多くの領域でデジタル化は進んでいるものの、それぞれのシステムが個別にデータを抱えているため、システム同士をつなぐには個別の調整が必須になる、という構造上の問題です。

空調メーカーのクラウドに空調データがあり、警備会社のサーバーに入退室データがあり、電力の計測値はまた別の管理画面にある。この状態では、どのデータも取り出す先が違い、粒度も名前の付け方も揃っていない。1つの用途を実現するたびに個社間の接続を作り込むことになり、費用が用途の数だけ積み上がります。定義の第2要件が「抽象化されたアセットを基に」と限定しているのは、この積み上がりを避けるためです。

ガイドラインの検討対象はオフィス・商業ビルという前提を先に押さえる

もう1つ、読む前に押さえておく前提があります。スマートビル関連ガイドラインは全4部構成で、検討対象の建種をオフィスビルと商業ビルに定めています。住宅や工場、病院にも同じ考え方を当てはめられる可能性はあるものの、それらへの検討は行われていない、と明記されている。

この前提は、提案を受ける側にとって実務的な意味があります。工場や物流施設に対して「スマートビルの標準に準拠」と説明された場合、そこで指す標準がどのガイドラインのどの部分かを確認する必要があるということです。工場設備の制御はFA側の系で、参照すべき規格も別になります。IoTという技術そのものの仕組みと適用範囲はIoTの仕組みと身近な例をまとめた記事で扱っています。

ビルOSとは｜3層構造の中央に置かれるデータ連携基盤の位置づけと機能

スマートビルの構成を語るとき、必ず中心に出てくるのがビルOSです。名前からOSと聞くと制御ソフトのように見えますが、担うのは制御ではありません。

フィールド層・データ共有管理層・アプリケーション層という3レイヤー

ガイドラインはスマートビルのシステム構造を3つのレイヤーで整理しています。ビルの躯体や設備、センサなどの物理的な資産を表すフィールド層。ビルOS等のシステムによって、フィールド層から送られたデータを抽象化しデジタルアセットとして管理・保存を行うデータ共有・管理層。そして収集されたデータを用いてサービスを行うアプリケーション層です。

この分け方が効いてくるのは、責任の所在を決めるときです。従来のビルでは、フィールド層のデータをアプリケーションが直接取りに行く構図になるため、データを共有・管理する主体がどこにも存在しませんでした。層を分けると、データの品質や提供範囲を誰が保証するのかを契約に書けるようになります。

通信仕様の変換・データの管理・外部への送受信という3つの機能

ビルOSの用語定義は「建物内のアセットを抽象化されたデジタルアセットとして扱うことでデータ標準化を行うとともに、ビル設備と多様なサービスを連携させ、アプリケーションの開発を加速させるデータ連携基盤」とされています。実装として何を持つかを分解すると、おおむね3つです。

1つ目は通信仕様の変換で、設備ごとに異なるプロトコルの差を吸収します。2つ目はデータの管理で、収集した値に空間や機器の属性を付けて保存する。3つ目は外部への送受信で、上位のアプリケーションに対してAPIの形でデータを渡します。制御そのものは下の層に残るため、ビルOSは既存の制御系を置き換える製品ではありません。

データモデルの標準を採るか自社定義で作るかで後の拡張性が分かれる

3つの機能のうち、後から効いてくるのは2つ目のデータ管理です。「3階東側の会議室の温度」を、どのビルでも同じ構造で表せるかどうかで、アプリケーションの移植性が変わります。建物のトポロジーと設備を記述するデータモデルには、Brick SchemaやRealEstateCore、W3Cのコミュニティグループが公開するBuilding Topology Ontologyなどが知られており、ビルOS製品はいずれかを土台にするか、自社定義のモデルを持つかに分かれる。

自社定義でも動きます。ただし、後から別のビルOSへ移す場面や、複数棟をまたいで同じアプリケーションを動かす場面で、モデルの変換が必要になります。ガイドラインが満たすべき性質として相互運用性・互換性・拡張性を挙げているのは、この移し替えの費用を抑える意図です。提案を比べるときは、機能一覧よりもデータモデルの出どころを聞いてください。

BAS・BEMSとの関係｜監視制御とエネルギー集計に重ならないビルOSの領域

ビル向けのシステムは略語が多く、提案書を並べると同じ画面が何度も出てきます。役割と扱う時間の粒度で切り分けると、重複が見えます。

制御の系がBAS、集計の系がBEMS、共有の層がビルOSという分担

BAS（中央監視）は設備をリアルタイムに監視して制御をかける系です。BEMSはエネルギー使用量を集計して分析する系。ビルOSはどちらの系からもデータを受け取り、外部のアプリケーションへ標準化した形で渡す層で、制御指令を直接出す役割は持ちません。

この分担を踏まえると、ビルOSを入れてもBASは残ることが分かります。空調の停止指令は引き続き中央監視から出す。ビルOSが受け持つのは、その運転状態を人流や会議室予約のデータと突き合わせて、アプリケーション側で判断材料に変える部分です。中央監視が扱う設備の範囲と更新時期の決め方はビル管理システム（BAS）の対象範囲と発注形態を整理した記事で扱っています。

既設の中央監視からデータを取り出す集約型と分散型の2つの構成

既存ビルにビルOSを足す場合、構成は大きく2通りに分かれます。データをビルOSに集約して管理する構成と、データを複数のクラウドシステムで分散管理し、ビルOSは所在と参照方法を持つ構成です。前者は問い合わせが速く、後者は設備メーカー各社のクラウドをそのまま使えるため初期の工事が軽くなる。

どちらを採るかは、既設の中央監視がデータを外部へ出せるかで決まります。BACnetに対応した盤であれば読み出しの口を作れますが、独自伝送で組まれた古い盤ではゲートウェイの追加が要る。既設のプロトコル対応状況の確認手順とゲートウェイで増える工数はBEMSの計装設計とBACnet連携の条件を整理した記事で扱っています。

竣工後にアプリを足せる体制を持つかどうかが実際の差になっている

構成の議論より結果を左右するのは、竣工後の運用体制です。従来のオフィスビルは、竣工から大規模リニューアルまで設備とソフトウェアが固定され、利用者が受けるサービスも変わらないのが一般的でした。ビルOSを入れた建物の公表例では、ここが変わっています。

2024年11月に開業したTODA BUILDINGは、建物内の設備とサービスをつなぐビルOSを導入し、自社でソフトウェアを改善し続ける体制を整えた例として公表されています。館内のロボットサービス、トイレ清掃業務の効率化、サイネージの機能改善が竣工後も続いている。ゼネコン各社が自社のビルOSやビル管理サービスを提供しており、選択肢としては製品を買う形と、開発体制ごと組む形の両方があります。

誰が組むのか｜MSIという主体と、発注プロセスに開きやすい担い手の空白

層構造を採ると、従来の建築の発注プロセスでは担当が決まらない領域が出ます。ガイドラインはここに新しい主体を置いています。

企画から運用・更新までを通して見るMSIが担う機能と現実の分担

構築・運用ガイドラインは、ビルの設備システムからデジタル技術まで広い専門知識を背景に、ビル全体のサービスを企画・設計・運用・更新する主体をMSI（マスターシステムインテグレーター）と呼んでいます。MSIが独立した会社として立つ場合と、その機能の一部を他のステークホルダーが分担する場合の両方が想定されており、どちらでも機能を担う主体をMSIと表す、という整理です。

実務では後者になることが多くなります。ゼネコンが設計施工の枠でフィールド層を、ビルOS提供者がデータ共有・管理層を、システム会社がアプリケーション層を担う。このとき空白になりやすいのが、竣工後にデータモデルを更新し続ける担当と、テナントからのデータ提供依頼に応答する担当です。どちらも建築工事の請負範囲には入りません。

ステークホルダーの分類とデータ提供の責任範囲を契約で先に決める

ガイドラインはステークホルダーを、フィールド層事業者（設計者・施工者、設備システムメーカー）、データ共有・管理層事業者（ビルOS提供者）、アプリ層事業者に大別しています。あわせて、データをビルOSに提供するフィールド層事業者やテナント、オーナー・管理者は、用途に応じた適切なデータ品質の保証範囲を利用規約や契約で取り決め、自身が提供するデータの信頼性を担保する必要が生じる、と述べている。

この一文は発注実務に直結します。人流カメラの検知精度が仕様に届かなかったとき、責任を負うのは機器を納めたメーカーか、データを載せたビルOS提供者か、それを使ったアプリ事業者か。層をまたぐ以上、精度の保証値と測定条件を先に書面へ落としておかないと、運用開始後に誰も直せない状態になります。

既存ビルの投資判断｜スマートビル化を採用する条件と見送るべき場面の線引き

ここまでを踏まえて、自社のビルで何をどこまでやるかを決めます。判断は製品比較からではなく、載せたいアプリケーションの有無から入ります。

ビルOSまで踏み込む条件は竣工後の予算・非設備サービス・横断用途

データ連携基盤への投資が回収できるのは、次の3条件のうち2つ以上を満たす場合です。第1に、竣工後もアプリケーションを追加・改善し続ける年間予算と担当が決まっていること。第2に、設備制御以外のサービス（ロボット、来訪者案内、会議室や共用部のサービス、テナント向けデータ提供）を出す計画があること。第3に、複数棟・複数テナント・複数系統をまたいでデータを突き合わせる用途が具体化していること。

3条件のいずれも、設備の性能ではなく運用の体制を問うています。スマートビルの定義が「機能を拡張し新たなサービスの創出や追加を行う」ことを第1要件に置いている以上、追加する主体が不在なら定義を満たしません。ここを空白のまま基盤だけ入れると、監視画面が1つ増えただけの結果になります。

単棟の賃貸ビルでスマートビル化を見送る条件と先に着手する打ち手

見送るべきなのは、延べ面積が中規模までの単棟で、テナントが自社で空調と照明の制御権を持ち、常駐の管理員がいないビルです。この構成では、ビル側が制御できる範囲が共用部に限られ、データを集めても打ち手が出てこない。ロボットやサイネージのサービスも、来訪者の絶対数が少なければ費用が見合いません。

この場合に先へ進める打ち手は2つあります。1つは、既設の中央監視やデマンド監視から計測値をCSVやAPIで取り出せる状態を作ること。もう1つは、エネルギー・入退室・設備の保全履歴を1か所に集め、半年ほど運用して実際に見る指標を絞り込むことです。設備台帳と保全履歴の側から整える進め方は設備管理システムの機能とExcel台帳との違いをまとめた記事で扱っています。この段階を踏むと、ビルOSに何を求めるかが要件として言語化できます。

ビルOS製品で足りる範囲と受託開発へ切り替える境界の見極め方

製品を買うか作るかの分かれ目は、外側の接続先の数です。設備データの収集・蓄積・可視化までなら、ビルOS製品やIoTプラットフォームのパッケージで足ります。テナント課金や勤怠、予約、会計といった既存の業務システムとの接続が要件に入った時点で、データモデルの設計と接続部分は個別開発の領域に入る。

もう1つの境界は、複数拠点の横断です。本社ビルと支店、あるいは店舗網まで含めてデータを扱うなら、拠点ごとに設備構成が違うため、共通のデータモデルを定義する作業が先に立つ。当社では、既設設備からのデータ収集と業務システム側への接続を含めてIoTを使った設備データ連携の受託開発を承っています。小規模拠点を多数抱える場合のセンサー構成と費用の考え方は店舗管理のIoTシステムの構成と導入判断をまとめた記事が参考になります。

よくある質問

スマートビルとビルOSの検討で、オーナー側・情報システム側から出ることの多い質問をまとめます。

スマートビルとスマートビルディングは違うものですか？

指している対象は同じです。IPAのガイドラインは「スマートビル」を用い、業界団体や不動産系の資料では「スマートビルディング」と書かれることが多い、という表記の違いです。提案書を比べるときに注意したいのは語ではなく中身で、データ連携基盤を持つ構成を指しているのか、設備を個別にIoT化した状態を指しているのかを図で確認してください。

ビルOSを入れると既存の中央監視装置は不要になりますか？

不要にはなりません。ビルOSはデータを共有・管理する層で、設備への制御指令は引き続き中央監視（BAS）が担います。既設の中央監視が古く、外部へデータを出す口が無い場合は、更新のタイミングでプロトコル対応を条件に入れるか、ゲートウェイを追加して読み出す構成になる。中央監視の法定耐用年数は15年で、更新時期とビルOSの導入時期を合わせると盤の停電工事が1回で済みます。

既存ビルを後からスマートビルにできますか？

できます。ただし、新築のように設計段階でデータモデルを決められないため、既設設備が何を出せるかの調査が先に立つ。既設の中央監視がBACnetに対応していれば読み出しは組めますし、対応していなくてもゲートウェイを追加すれば読み出せます。費用が跳ねるのは、計測点そのものが足りず計器の追加工事が要る場合で、この工事は大規模修繕の時期に寄せると単独発注より抑えられます。

スマートビルの導入に使える補助金や制度上の後押しはありますか？

省エネ側の制度が中心になります。改正建築物省エネ法は2025年4月に施行され、原則すべての新築建築物へ省エネ基準への適合が義務付けられました。既存ビルの改修では、省エネ関連の補助事業が計測機器や制御機器を対象にする場合があります。ただし、データ連携基盤そのものを対象にする制度は限られるため、補助金を前提に計画を組むより、省エネ改修の工事に計測点の追加を相乗りさせる進め方が現実的です。

ビルOSの選定では何を比較すればよいですか？

機能一覧よりも、データモデルの出どころ、外部へ提供するAPIの仕様が公開されているか、対応プロトコルの一覧、そして契約終了時にデータを取り出せるかの4点です。建物は数十年運用するため、途中でアプリケーションもビルOSも入れ替わる前提で選びます。相見積りでは、自社ビルの設備リストを各社へ同じ形で渡し、どの設備からどの粒度でデータを取れるかを表で回答してもらうと比較できます。

関連記事

• ビル管理システム（BAS）とは？中央監視の対象範囲とパッケージ／受託開発の判断：設備の監視制御を担う側の対象範囲と更新時期を扱っています
• BEMSとは？ビル設備の計装設計とBACnet連携・中央監視との役割分担で判断する：エネルギー計装と既設設備への接続条件を扱っています
• エネルギーマネジメントシステム（EMS）とは？BEMS・FEMSの違いと導入判断：EMS全体の分類と投資回収の考え方を扱っています
• 設備管理システムとは？CMMS・EAMの機能とExcel台帳との違い・導入判断：設備台帳と保全履歴を整える側の機能を扱っています
• 店舗管理のIoTシステムとは？センサー連携の仕組みと費用・導入判断の基準：小規模拠点を多数抱える場合のセンサー構成と費用を扱っています