ゲストの目に触れない裏側で何が起きているか ― NOT A HOTELのBMSが支える運営の話

この記事は、NOT A HOTELのソフトウェア開発連載「Inside the SOFTWARE TEAM」の企画で書いています。

はじめに

こんにちは！NOT A HOTELのスマートホームチームでテクニカルインテグレーターをしているachangです。

ビルやホテルを運営する上で欠かせないシステムのひとつに BMS（Building Management System） があります。
空調・ボイラー・ポンプ・水処理・防災など、建物のインフラ設備を監視するための“指令塔”のような存在です。

今回の記事ではNOT A HOTELでの安心安全な滞在を裏側から支えているこのBMSというシステムについてお話ししようと思います。

そもそもBMSって何？

BMSとはBuilding Management Systemの略であり、その名の通り、
建物の状態を監視し、異常があれば気づけるようにするためのシステム
です。

それぞれの建物の状況を可視化し集中管理することによって設備の不具合を逸早く検知したり、各種機器から取得しているデータを分析して照明や空調を連動させる省エネ計画を立てたりと、その用途は実に多種多様です。

ですが、これだけ重要なシステムに関わらず一般にほとんど知られていません。その理由は主に次の3つです。

1. 建物オーナーや設備業者しか触らないB2B領域だから
   住人や一般ユーザーの目に触れず、導入企業だけが使う世界です。

2. レガシーなクローズド市場で、情報が外に出にくい
   多くが専用ベンダーの商用製品で、仕様や導入事例も一般公開されにくい構造になっています。

3. UI/UXが複雑で、気軽に触れるようなものではない
   エンジニアや設備担当者向けに作られた機能が多く、モダンなWebサービスほど親しみやすさはありません。

私たちも最初は、
「え、こんなに世の中に情報がないの？」
「実例とか具体的な構築方法はどこに…？」
というところからスタートしました。

NOT A HOTELで必要性に気づいた瞬間

最初の拠点であるNOT A HOTEL AOSHIMAがオープンし、運営が走り始めた頃、私たちはBMSが“あれば便利”なものではなく、“ないと運営に支障が出る” ものだと実感しました。

NOT A HOTELで建物運営に関わるチームは大きく2つあります。

運営チーム
日々のホテル運営を担当し、
ゲスト対応や施設の現場オペレーションを担うチーム。

LCM（Life Cycle Management）チーム
建物設備の保守・点検・メンテナンスを担当する、
いわば“建物の健康管理”の専門チーム。

この2チームにとって、設備の状態は重要な判断材料になります。
具体的には、

• 機器が正常に動作しているか

• 異常が出たときにすぐ気づけるか

• 現地のスタッフがどこに駆けつければいいか

• 温度や電力などの状態が正常に推移しているか

といった情報が必須です。
しかし当時は、

• 状態確認には実機や制御盤を見に行く必要がある

• 異常発生時に通知する仕組みが無い

• 設備の状況を俯瞰できる手段がない

という“手探り状態”でした。

調べても前例や参考になる資料は見つからない。
少なくとも私たちが求める 「ホテル運営にフィットしたBMS」 は存在しませんでした。

このとき、
「じゃあ、自分たちが必要なものを、自分たちで作るしかない。」という結論に至りました。

なぜ他社製BMSではなく、自社で開発したのか？

世の中には立派なBMSがいくつもあります。
ただ、それらを導入するには大きなハードルがありました。

1. 他社製BMSは導入とセットアップが重すぎる

一般的なBMSは導入時に、

• 図面の取り込み

• データベースの設計

• 監視ポイントの大量設定

• 設備ごとのパラメータの登録

など、多くの作業を“エンジニアが”行う必要があります。

新規案件のたびに何百もの設定項目を扱い、
セットアップだけで膨大な時間がかかります。

少人数でスピード感ある開発・運営を回しているNOT A HOTELでは、
この重さは現実的ではありませんでした。

2. BMSを使う主役は現場チーム。複雑なUI/UXはミスマッチ

NOT A HOTELでBMSを一番使うのは、

• 運営チーム

• LCMチーム

の2チームですが、多くのメンバーは BMS未経験者 です。
加えて、現場仕事が多いため、PCの前に座ってずっと画面を監視するわけにもいきません。

高機能で複雑なUIを入れても、
“結局使われない”未来が容易に想像できました。

だからこそ、
まずは「気づけること」にフォーカスしたミニマムBMSを作ろう
と決めました。

ミニマム要件での開発がスタート

当時の状況を整理し、まず目指すべきは

• アラートの種類によっては緊急度が高いものもあるため、必要な情報を即座に受け取れる仕組み

• PCだけではなくスマートフォンからも内容が確認出来る簡潔さ

• 対応完了するまでの対応記録を残せる仕組み

• アラートの閾値や通知有無を拠点に合わせて運用しながら変えていける柔軟性

として、実装に取り掛かりました。

まずはすぐに気付けるように

一番大事ですね。

NOT A HOTELでは、ゲストが使うホームコントローラー（照明・空調・カーテンなどを操作するアプリ）だけでなく、
ステータス取得や警報監視のために、建物の裏側にある多くの設備もスマートホーム化 しています。

警報の種類は色々ありどれも重要ですが、中には火災やサウナの非常ボタンが押されたなど、ゲストの安全に関わる警報もある為緊急度を振り分けて2種類の通知方法を実装することにしました。

一つはSlackでの通知。
これは緊急度関係なく、全ての警報をSlackに通知しています。

Slackはすでに社内の共通ツールとして使われており、
運営チームもLCMチームも日常的に確認しています。
そのため、“まず確実に気づける”仕組みとして最適でした。

なるべく一つの通知で必要な情報が分かるようにし、
警報の詳細や対処方法が記されているRunbookのURLも記載しています。

また、対応後に復旧した場合や、自動で復旧した場合、
復旧したこともSlackで分かるように機器から復旧信号が上がってきたら
該当のメッセージのスレッドに自動的に通知が送られるようになっています。

これらの通知は機器から上がってきた信号を受けて、社内の通知基盤を経由して発火する仕組みになっています。

もう一つは電話での通知。

人命やゲストの安全に関わる、極めて緊急度が高く早急に対応するべき警報に関してはSlackでの通知に加えて対象拠点の運営メンバー全員のZoom Phoneに自動で架電するようになっています。

現時点の運用で代表的に電話通知の対象となっているのは

火災警報
火災が発生した際の警報。各ハウスや共用部の火災報知器と連動して発報するもの。

エレベーターの異常警報
エレベーター内の非常ボタンが押された際や、エレベーター自体に異常があった際に発報するもの。

サウナ非常ボタンの押下警報
サウナ利用中にゲストが体調不良などでサウナ室内の非常ボタンを押した際に発報するもの。

の三つです。
なお、対象となる警報は拠点や設備構成に応じて適宜見直しを行っています。

運営チームのメンバー誰か一人が電話に出ると

というような内容が繰り返し読み上げられます。

Slackを見ていなくてもすぐに気づいて現地へ駆けつけられるよう、
発生した 「場所」 と 「警報内容」 を組み合わせてテキストを生成し、
その内容をリアルタイムに電話で読み上げる仕組みにしています。

読み上げにはクラウドの音声読み上げAPIを利用しており、このおかげで比較的簡単に実装することができました。

通知機能の実装によって、運営チームとLCMチームは
「いま何が起きているか」
に即座に気づけるようになりました。

なお、実際の緊急対応はこれらの通知機能だけに依存しているわけではありません。
現地対応フローや複数の連絡経路を含む社内BCP（事業継続計画）に基づき、多層的な体制で運用しています。

それでも、気づいた“その後”をどうスムーズにつなげるかは、まだ改善の余地がありました。

記録という習慣

警報に気づいた後は、運営チームやLCMチームが集まり、
状況を確認して対応を判断します。

ただ、Slack通知だけでは、

• 誰が対応しているのか

• いまのステータスは何か

• 何がすでに試されたのか

• 過去に同じ警報があった時はどう対応したのか

といった情報が分かりません。

そこで私たちは、
Slack通知を“対応プロセスの起点”として機能させる仕組み をつくりました。

気づいた人は気になったかもしれないですが、ここ。

実はここを押すと、
ステータス変更・アサイン・コメント記入ができるアクションモーダル が開きます。

チケットを起票して、アサインを決めて、ステータスを管理する。
コメントには対応内容を残す。
そういったイメージで作った機能で、ここでSubmitした内容はスレッドに通知されます。

これにより、関係者がスレッドを追っていけば、
「今どこまで対応されているか」をリアルタイムに把握できます。

そして実はもう一つ

起票されたチケットを一覧で見るためのWebアプリもあります。

Slack通知だけでは複数発生した警報の状況を俯瞰することができません。
そこで、Slackから飛べるWebアプリとして、チケットの一覧管理画面 を作りました。
対応漏れがないかを定期的に棚卸するのに使われています。

ここまでの仕組みによって、

1. 設備の異常に即座に気づく（Slack）

2. 対応状況をSlack上で管理できる（アクションモーダル）

3. さらにWebアプリで一覧化して追跡できる（チケット一覧）

という流れが完成しました。

「いつもと違う」を見つける、知らせる

Slack通知とチケット管理の仕組みで、
“異常が起きたら気づける” ところまではできました。

しかし、実際の設備運用ではもう一つ重要なことがあります。

「異常の原因を把握できること」
「異常が起きる前に予兆に気づけること」

そのために次に取り組んだのが、
時系列データベースを使ったデータ蓄積と、Grafanaによる可視化・条件付きアラート です。

設備から上がってくるステータスは種類も頻度もまちまちです。

• 温度

• 湿度

• 光度

• 音量

• 人感

• 流量

• 電流値／電力

• ON/OFF状態

といった、これらをすべて 時系列データベースに保存 しています。

これにより、

• 劣化傾向の可視化

• 異常発生前の挙動の把握

• 事後分析／再発防止

• 新規設備の正常稼働確認

• 将来的なAI予兆検知の土台化

が可能になりました。

さらに、GrafanaのAlerting機能を使い、
条件を満たしたらSlackへ通知する仕組み を追加しました。

使用水量が基準値から外れていたり、
お風呂や水風呂が設定された温度にちゃんと到達するかなど、
柔軟な条件が設定できます。

これらの条件設定は、都度LCMチームと運営チームに相談しながら
細かく調整しています。

可視化とアラートの組み合わせで“予兆検知の入り口”に

Slack通知（警報）
＋
Grafana可視化（状態）
＋
Grafana Alert（条件）

の組み合わせにより、NOT A HOTELでは

“発生した異常に気づく”から“異常の予兆に気づく”へ
運用レベルが一段アップしました。

これは自社開発だからこそ実現できたアプローチであり、
現場の声に応じて柔軟に改善し続けられる点が大きな強みです。

作ってわかったこと

ミニマムBMSのおかげで、

• 運営・LCMが異常にすぐ気づけるようになった

• 設備状態がデータとして把握できるようになった

という大きな進歩が得られました。

ただ、実際に運用を続けていく中で、
新しく見えてきた課題 もあります。

現状は “ミニマム版” としては十分機能していますが、
NOT A HOTELの運営フロー全体を考えると、
さらに改善したいポイントがいくつか浮かび上がってきました

■ 図面上での位置情報可視化が必須
設備のある場所が瞬時にわかれば、駆けつけや復旧が大幅に早まります。

■ 警報管理（Webアプリ・Slack）と Grafana（監視）が分離している
警報の発報状況や対応管理と状態監視を統合されたUIになれば、
状態や原因の把握がしやすくなる。

■ アラート条件設定をLCM自身が行えるようにしたい
現場の判断をそのまま仕組みに反映できるようにするのが理想です。

今後：BMSの大幅リニューアルへ

私たちのBMSはまだ始まりに過ぎません。
今後は以下のようなアップデートを予定しています。

• 図面マッピングによる直感的なUI

• 管理・監視の統合

• LCMが自走できる設定管理

• 長期データを使ったAIによる予兆検知

運用していく中でまた理想の形は変わって行くと思いますが、
NOT A HOTELらしい、現場に寄り添うBMSを目指し続けます。

スマートホームチーム、仲間募集中！

建物、IoT、クラウド、UI/UXなどが交差する面白い領域で、
自社開発だからこそゼロから仕組みを作れます。

まだまだやりたいことはいっぱいあるので、
興味のある方はぜひカジュアルにお話ししましょう！

herp.careers カジュアル面談

NOTA株式会社

募集要項をみる