ビル管理システムでできること一覧｜機能の全体像と、機能別の選定チェックリスト

「ビル管理システム」という言葉は、実務ではまったく異なる3種類の製品を指して使われています。設備の点検記録を扱うもの、テナントとのやり取りを扱うもの、賃貸借契約と収支を扱うもの。この3つは、使う人も、扱う相手も、更新の頻度も違います。

その結果、比較検討の場で何が起きるか。同じ「ビル管理システム」を名乗る製品を並べたのに、機能表が噛み合わないのです。片方にある機能が片方には存在せず、優劣ではなく守備範囲の違いだと気づくまでに時間がかかります。

本記事では、ビル管理システムで扱われる機能を3層に整理し、各機能で何ができるのか、選定時に何を確認すべきかを網羅的に示します。RFPや社内稟議のチェックリストとしてそのまま使える形にしてあります。

結論：機能は3層に分かれる。層を跨いだ比較は成立しない

先に全体像を示します。ビル管理システムで扱われる機能は、次の3層に整理できます。

選定を始める前に、「今回どの層を埋めるのか」を先に決めてください。 ここが曖昧なまま複数ベンダーの説明を聞くと、機能の多寡だけで判断してしまい、既存システムと重複した投資になります。

そして重要なのは、1製品で3層すべてを深く作り込むことは実務上ほぼ不可能だという点です。「全部入り」を謳う製品は、いずれかの層が実務に耐えない浅さになります。現場でよく見られるのは、第1層と第2層をそれぞれ別の製品で運用している構成です。これは妥協ではなく、合理的な選択です。

ビル管理システムとは何か

ビル管理システムとは、オフィスビル・商業施設・物流倉庫といった事業用不動産の運営業務を、デジタル上で管理するためのソフトウェアの総称です。 「ビル管理SaaS」「ビル管理DXクラウド」「プロパティマネジメントシステム」なども、おおむね同じ意味で使われます。

ただし冒頭で述べたとおり、この言葉が指す範囲は製品によって大きく異なります。総称であって、特定の機能セットを意味する言葉ではないという点が、比較を難しくしています。

誰のためのシステムか — BM・PM・AM・オーナーの違い

層の話を理解するには、事業用不動産に関わるプレイヤーの役割分担を押さえる必要があります。

1つの物件に、これらが同時に関わります。 そして多くの場合、それぞれ別の会社です。加えて、警備会社・清掃会社・設備点検会社といった協力会社も関与します。

これが、一般的な社内向け業務システムとの決定的な違いです。 社内システムであれば利用者は自社の社員だけですが、ビル管理システムの利用者は複数の会社にまたがり、さらに社外のテナントとその先の工事業者まで含みます。 権限設計が重要になるのは、この構造があるためです。

なぜ機能が3層に分かれるのか

上の表のとおり、プレイヤーによって必要な機能が違うからです。BM会社は設備の点検記録を毎日入力しますが、賃貸借契約の条件は見ません。AM会社は収支を月次で見ますが、点検記録は見ません。PM会社はテナントとのやり取りが業務の中心です。

製品が3層に分かれているのは、開発の都合ではなく、業務の分担がそうなっているからです。したがって「1つにまとめたほうが便利では」という発想は、実務の構造と合いません。

全機能マップ

3層に含まれる主な機能を一覧にします。以降の各節で、それぞれ「何ができるか」と「選定時に確認すべきこと」を解説します。

本記事は第2層を最も厚く扱います。第1層と第3層は専用製品が成熟している一方、第2層は製品ごとの守備範囲の差が大きく、比較が最も難しい領域だからです。

第1層：設備・保全管理

建物の設備そのものを対象とする層です。BM会社（ビルマネジメント会社）や設備会社の業務に直結します。

扱う機能

点検・保全記録 — 法定点検（消防設備、建築設備、特定建築物など）と自主点検の記録。現場作業者がスマートフォンで入力し、写真を添付する使い方が中心です。

修繕履歴・設備台帳 — 設備ごとの型番・設置年・保証期間と、これまでの修繕履歴。更新計画（長期修繕計画）の根拠になります。

エネルギー管理 — 電気・ガス・水道の使用量の把握。省エネ法対応やCO2排出量の算定に使われます。

この層を選ぶときの確認事項

• 現場作業者が使えるか。 オフライン環境（地下の機械室、電波の届かない場所）で入力できるか。ここが満たされないと、結局紙に記入して後でシステムに転記する二度手間が発生します

• 点検様式を自社の帳票に合わせられるか。 法定点検の様式は決まっていますが、自主点検は会社ごとに違います。既存の帳票を再現できないと、現場が「前のほうが早い」と言い始めます

• 過去の履歴を設備単位で辿れるか。 「このエレベーターの過去5年の故障履歴」が出せるか。更新判断と長期修繕計画の根拠になります

• 協力会社の作業者にアカウントを出せるか。 点検を外注している場合、ここが制約になります。ユーザー課金の製品では、協力会社の人数分の費用が発生する点も確認が要ります

• 写真の扱いが実用に耐えるか。 点検記録は写真が中心になります。枚数制限、容量、後からの検索性を確認してください

この層とテナント向けの業務を、同じ製品で扱わないほうがよい理由

第1層の利用者は現場作業者で、扱う対象は設備です。入力は現地で、スマートフォンで、短時間に行われます。

一方、第2層（テナントコミュニケーション）の利用者は事務所にいるPM担当者で、扱う相手は社外のテナントです。入力はPCで、文章を伴い、承認や記録の正確性が求められます。

求められるUIも、権限の設計も、まったく違います。 どちらかに最適化すればもう一方が使いにくくなるため、1製品で両方を深く作り込むのは構造的に困難です。両者を別製品で運用し、必要な箇所だけ連携させる構成が、実務では最も安定します。

第2層：テナントコミュニケーション

運営者とテナントの間で発生するやり取りを対象とする層です。相手が社外であるという点が、この層の設計を根本的に規定します。 社内システムのように「今日からこれを使ってください」と強制できません。

館内申請（承認フロー）

何ができるか

工事作業、搬入出、時間外作業、火気使用、鍵貸出、看板設置といった届出を、紙やメールではなくフォームで受け付け、承認の流れをシステム上で回します。

選定時に確認すべきこと

• 承認ルートを「承認」と「確認」に分けられるか。 全員を承認者にすると、否認実績のないステップが滞留の原因になります

• 承認者をグループで指定できるか。 個人指定だと、担当者交代のたびに全ルートの作り直しが発生します

• AND条件とOR条件を使い分けられるか。 「設備担当グループの誰か1人が承認すれば進む」が表現できるか

• アカウントを持たない工事業者から申請を受けられるか。 テナントの先にいる施工業者が申請者になるケースは多く、ここが設計の分かれ目です

• 申請様式を他物件から持ち込めるか。 ただし承認体制まで一緒に複製されないことを必ず確認してください。A物件の承認者がB物件の申請に混入する事故が起きます

館内申請の設計は論点が多いため、館内申請をフォーム化して承認を効率化する方法で詳しく扱っています。

テナントへの通知・お知らせ

何ができるか

工事の案内、断水・停電の予告、館内ルールの変更、防災訓練の通知などを、紙のポスティングではなくシステムから配信します。

選定時に確認すべきこと

• 既読が分かるか。 紙の運用の最大の問題は配布の手間ではなく、読まれたか確認できないことです。確認のために結局訪問や電話が発生しています

• 配信先を分けられるか。 全テナント／特定フロア／個別テナント。関係のない通知が続くと、通知そのものが見られなくなります

• テナント側の「誰」に届くかを選べるか。 総務担当者だけに届けばよい連絡と、そのテナントの全員に知ってほしい連絡は違います

• 未読者だけに追いかけられるか。 全員への再通知は、既読者にとっては重複になります

• 公開期間を設定できるか。 終わった案内が残り続けると、掲示の信頼性が落ちます

• 一方通行になっていないか。 「この工事の時間帯を変更できないか」という相談が、電話ではなくその場で来る導線があるか

問い合わせの受付と管理

何ができるか

テナントからの質問・要望・相談・設備不具合の連絡を受け付け、対応状況を追跡します。

実務上、設備の不具合連絡もこの機能で受けるのが一般的です。 不具合専用の機能を持つ製品もありますが、テナントから見れば「困ったことを伝える」のは1つの行為であり、入口を分けると使われません。入口は問い合わせに集約し、内容による振り分けは受けた後に運営側で行うのが現実的です。

選定時に確認すべきこと

• ステータスで追えるか。 最低限「未対応／対応中／対応済」。担当者本人以外にも状況が見えることが重要です

• 内容ごとに担当を振り分けられるか。 「設備の不具合」「請求について」「館内ルールについて」で、回答する担当者が違うのが通常です

• 回答する人と、見るだけの人を分けられるか。 オーナーは回答しないが内容は把握しておきたい、というケースは多くあります

• 電話で受けた問い合わせも同じ場所に記録できるか。 ここが最重要です。入口を1つにするとは、テナントの連絡手段を1つに縛ることではなく、記録の置き場所を1つにすることです。電話を受けた側が代理で登録できる仕組みがないと、記録は必ず分散します

• 繰り返される質問を掲示に変換できるか。 同じ質問に毎回答えている状態は、問い合わせ機能ではなく情報提供の設計の問題です

AIによる一次対応

何ができるか

テナントからの質問に対し、館内ルールや手続き書類をもとにAIが自動で回答します。

任せてよい範囲は明確に限られます。 判断基準は1つ、答えがすでに文書に書いてあるかです。

ここで一つ、数字を共有します。 AI導入前のテナントからの問い合わせの内訳を実際に数えたところ、館内ルールに答えが書いてある一般的な質問が、全体の6割程度を占めていました。 感覚より多いはずです。「判断が必要な相談が大半だ」と思われがちですが、実際には「書いてあることを聞かれている」のが多数派です。

選定を始める前に、直近1か月の問い合わせを内容別に数えてみてください。 自社の比率が分かれば、AIに任せられる範囲の見積もりが具体的になります。

選定時に確認すべきこと

• 回答の根拠を示せるか。 「どの文書に基づく回答か」を提示できないと、間違っていても誰も気づけません

• AIに読ませる文書を運営者が管理できるか。 ファイル単位で「回答に使う／使わない」を指定できないと、古い規則や社内向け資料をもとに回答されます

• 解決しなかったときに人へ引き継がれるか。 「解決しなかった」状態が記録され、通常の問い合わせとして担当者に渡る導線が必要です。AI対応は人の代替ではなく、人に渡る前のフィルタとして設計してください

会議室・共用設備の予約

何ができるか

共用会議室、荷捌き場、搬入用エレベーター、イベントスペースなどの予約を受け付け、管理します。

選定時に確認すべきこと

• 即時確定と承認制を、設備ごとに使い分けられるか。 会議室は早い者勝ちでよくても、荷捌き場は運営側が他の搬入との重複を見たい。同じ物件の中に両方が混在するのが普通です

• 有料設備の利用実績を集計できるか。 有料会議室を運用している場合、テナント別の利用額を出せないと請求が手作業になります

• 予約可能な期間を設定できるか。 何か月先まで押さえられるかは、運用方針によって変わります

• キャンセルの扱いが設計されているか。 誰がキャンセルしたか（テナント都合か運営者都合か）の記録が残るか

入退館管理

何ができるか

来訪者や工事業者の入退館を、事前予約と当日の受付として管理します。鍵やカードキー、備品の貸出を伴うことも多い領域です。

選定時に確認すべきこと

• 訪問先を構造的に持てるか。 「どのテナントを訪問するか」だけでなく、「共用部のどの施設に入るか」「自由入力の行き先」まで扱えると、工事業者の管理まで対応できます

• 退館の記録まで取るか、入館だけか。 運用負荷が変わります。防災上の在館者把握が目的なら退館まで必要です

• 申請と連携するか。 工事申請に書いた作業日時が入退館の予約に引き継がれないと、現場で二重入力になります

• 貸出品を個体で管理できるか。 「鍵を3本貸した」ではなく「鍵番号A-12を貸した」でないと、返却漏れを追えません

• 統計とCSVが出せるか。 月次の来館者数、業者別の入館回数は、警備計画の根拠になります

館内ルール掲示・書類共有

何ができるか

館内規則、使用細則、各種様式といった文書をテナントがいつでも参照できる場所に掲示します。また、契約関連書類や請求関連書類など、個別のテナント宛の書類を授受します。

選定時に確認すべきこと

• 全テナント向けと個別テナント向けを分けられるか。 契約関連の書類が他テナントから見えては困ります

• 個別書類に既読が付くか。 「渡したはず」「見ていない」の争いを防げます

• 新しい書類が置かれたときに通知が飛ぶか。 置いただけでは気づかれません

• テナントから運営者への提出にも使えるか。 一方向だけだと、テナントからの提出書類はメールに戻ります

• AIの回答に使う資料として指定できるか。 前述のAI一次対応を導入する場合、この文書群が回答の根拠になります

アンケート

何ができるか

テナント満足度や要望を定点観測します。

ここで重要なのは、アンケートで取れるものと取れないものが、はっきり分かれることです。

「不満はありますか」に「特にありません」と答えた3か月後に退去通知が来る、というのは珍しい話ではありません。アンケートで全体を測り、人が会って個別を拾う。 どちらか一方では足りません。

選定時に確認すべきこと

• ログイン不要で回答できるか。 回答のハードルが1段上がるだけで、回収率は大きく落ちます

• 結果を集計・可視化できるか。 回答を目視で数える運用では続きません

• テナントの担当者と、そこで働く従業員のどちらにも配れるか。 聞きたい相手によって配信経路が変わります

日程調整

何ができるか

設備点検の立ち会い、内装工事の事前打ち合わせ、定期面談、原状回復の立ち会いなどの日程を確定します。

見落とされやすい領域ですが、意外に工数を食っています。 「来週の火曜か水曜はいかがでしょうか」「火曜の午後でお願いします」「何時からがよろしいですか」——1件あたり3〜5往復は珍しくありません。発生頻度が高いため、積み上がると相当な時間になります。

選定時に確認すべきこと

• 候補日時を提示して相手に選ばせる形か。 メール本文で候補を書く方式では往復が減りません

• 複数テナントとの同時調整ができるか。 全館一斉の点検では、テナントごとに個別調整すると担当者が破綻します

• 関連資料を添付できるか。 「日程と、当日の資料」を一度に送れると、さらに往復が減ります

売上管理（商業施設）

何ができるか

歩合賃料の算定などのために、商業テナントから売上報告を収集し、集計します。オフィスビルでは不要ですが、商業施設では必須の機能です。

選定時に確認すべきこと

• 日次報告と月次報告を、テナントごとに選べるか。 業態によって報告頻度が違います

• 提出期限とアラートを設定できるか。 未提出の督促が手作業だと、担当者の負荷が毎月発生します

• 運営者が代理で入力できるか。 システムを使えないテナントは必ず残ります

• 休業日を設定できるか。 休業日を未提出として検知すると、アラートが意味をなさなくなります

• 証憑を添付できるか。 レジのジャーナルなどの裏付けを紐づけられるか

• 修正依頼を出せるか。 明らかな誤りを差し戻す導線がないと、電話とメールに戻ります

• CSVで出せるか。 合算（テナント単位で1行）と明細（日ごと）の両方、前年比較、そして複数物件を横断した出力ができるか

第3層：契約・会計・資産管理

賃貸借契約の管理、賃料請求と入金消込、収支管理、NOI（純営業収益）の把握を扱う層です。AM会社やオーナーの経営判断に直結します。

扱う機能

賃貸借契約管理 — 契約条件（賃料、共益費、契約期間、更新条件、解約予告期間）、保証金・敷金、連帯保証人や保証会社の情報。更新期日と解約予告期限の管理が実務の中心になります。

請求・入金管理 — 月次の賃料請求書の発行、入金の消込、滞納の検知と督促。歩合賃料がある商業施設では、テナントからの売上報告と連動します。

収支・NOI管理 — 収入（賃料、共益費、駐車場、その他収入）と費用（管理委託費、水道光熱費、修繕費、公租公課、保険料）の把握。NOI（純営業収益）は物件価値の算定に直結するため、区画単位・費目単位で正確に押さえられるかが重要です。

この層を選ぶときの確認事項

• 既存の会計システムと連携できるか。 ここが二重入力になると、導入の意味が薄れます。CSV連携で足りるのか、API連携が必要なのかを先に決めてください

• 契約の更新期日と解約予告期限を管理できるか。 更新交渉の起点であり、見落とすと自動更新や不利な条件での継続につながります

• 区画単位で収支を見られるか。 物件単位の合計だけでは、どの区画が収益を圧迫しているか分からず、改善の打ち手が決まりません

• フリーレントや段階賃料を表現できるか。 実務の契約条件は単純な月額固定ばかりではありません。定期借家、歩合賃料、共益費の実費精算なども扱えるかを確認してください

• 費目の分類を自社の基準に合わせられるか。 NOIの比較可能性は、費目分類の一貫性で決まります

層を跨ぐ共通論点

どの層の製品を選ぶ場合でも、共通して確認すべき論点が4つあります。

権限設計

事業用不動産の運営には、1つの物件に複数の会社が関与します。 オーナー、AM、PM、BM、警備、清掃、設備点検。これが一般的な社内向けシステムとの決定的な違いです。

• 機能カテゴリ単位で権限を設定できるか。 「閲覧できる／できない」の2値ではなく、機能ごとに「権限なし／閲覧のみ／編集可」で設定できるか

• 権限を個人ではなくグループで管理できるか。 別会社の担当者は交代します

• テナント側にも権限の段階があるか。 テナントの総務担当者と、そこで働く従業員に同じ画面を見せると、後者は使いません

複数物件への対応

• 担当物件をまたいで「自分の承認・確認待ち」が1画面で見えるか。 担当10棟で毎朝10画面を確認する運用は成立しません

• 設定を物件ごとに持てるか。 物件ごとに様式も承認体制も違います。全物件を1つの設定に統一しようとする製品は、棟数が増えた時点で現場に拒否されます

• 物件ごとに使う機能を選べるか。 商業施設では売上管理が必要でも、単一テナントの倉庫では不要です

詳しくはビル管理DXクラウドの選び方で扱っています。

記録の取り出し

• 管理番号で特定できるか。 「◯月◯日の工事の件」が「申請番号◯◯の件」に変わります

• 条件を指定してCSV出力できるか。 できないと、集計のたびに画面を数える作業が発生します

• テナントが退去しても記録が残るか。 区画の工事履歴や火気使用の記録は、テナントではなく建物に紐づく資産です

テナント側の入口

• テナントが開く場所が1つか。 申請はこのフォーム、予約は電話、問い合わせはメール、という状態では、迷ったときに必ず電話が選ばれます

• 専用アプリのインストールが必須か。 必須の場合、そのテナントで働く一般の従業員には浸透しにくく、物件による差も大きくなります。インストールした人にもしていない人にも届く二重の経路があるかを確認してください

導入形態・セキュリティ・サポートの確認事項

機能の比較に集中すると抜けがちですが、稟議の最終段階で問題になるのはこちらです。 特に大手のビルマネジメント会社やオーナーが関わる案件では、ここで止まることが少なくありません。

導入形態

• クラウドか、オンプレミスか。 事業用不動産向けの製品はほぼクラウドですが、オーナーの情報管理方針によってはオンプレミスを求められることがあります

• カスタマイズができるか、設定の範囲で収めるか。 カスタマイズは一見魅力的ですが、バージョンアップに追随できなくなるリスクがあります。設定の範囲で自社の運用を表現できる製品を選ぶほうが、長期的には安定します

• 初期セットアップの支援があるか。 最初の物件の型づくりに伴走してもらえるかは、その後の展開速度を左右します

• 試用・パイロットができるか。 全社導入の前に、1〜数棟で実運用を試せるか

セキュリティ

テナントの企業情報や契約内容を扱うため、オーナーやテナントから説明を求められる前提で確認してください。

• 第三者認証を取得しているか。 ISO/IEC 27001（ISMS）やSOC 2など。オーナーへの説明資料としてそのまま使えます

• 通信とデータの暗号化。 保存時・転送時の両方

• アクセス権限の粒度。 前述の権限設計に加え、退職者のアカウント無効化が確実に行えるか

• ログが残るか。 誰がいつ何を見たか。情報漏えいが疑われたときに追跡できるかは、事後対応の可否を決めます

• データの所在と、解約時の扱い。 解約後にデータをどう返却・削除するかを契約前に確認してください

サポート体制

• 問い合わせの窓口と応答時間。 現場が困ったときに当日中に返答が来るか

• マニュアルが整備されているか。 担当者が交代するたびにベンダーに聞く運用は続きません

• 機能追加の頻度と、要望の反映プロセス。 リリースノートが公開されているかは、開発が継続しているかの判断材料になります

選定でよくある5つの失敗

1. 層を決めずに比較を始める 守備範囲の違う製品を機能数で比べ、「多いほうが良い」で決めてしまいます。結果、既存システムと重複した投資になります。

2. 全機能を必須要件にする RFPに全機能を並べると、どの製品も部分的にしか満たさず、比較が成立しません。件数の多い上位2〜3機能に絞ってください。

3. 運営側の効率だけで設計する テナントから見ると手間が増えただけ、という状態になります。電話1本で済んでいたものが、ログインしてフォームを探して入力する作業に変わる。テナント側の利点を設計に織り込んでいないと、必ず電話に戻ります。

4. 機能の有無だけを見て、実装の粒度を見ない 「承認フローがある」は、ほとんどの製品が該当します。差が出るのは、承認と確認を分けられるか、グループで指定できるか、他物件から様式を持ち込んだときに承認体制まで複製されないか——といった粒度です。デモで自分の手を動かして確認してください。

5. 現在の棟数で判断する 物件数が増えたときに破綻する設計かどうかは、1〜2棟の段階では分かりません。「設定は物件ごとに持てるか」「担当者の入口は横断できるか」を、いまの棟数にかかわらず確認してください。

自社に必要な機能をどう絞り込むか

全機能が必要な物件はありません。次の3ステップで絞り込みます。

ステップ1：直近1か月の業務を数える

テナントからの電話、メール、来訪を1か月分記録します。内容別に分類すると、自社で本当に件数の多い業務が分かります。感覚で決めないでください。 「館内申請が大変」と思っていたが実は問い合わせ対応のほうが多かった、というのはよくあります。

ステップ2：件数の多い上位2〜3機能に絞る

上位に入った機能だけを必須要件とし、それ以外は「あれば良い」に分類します。全機能を必須にすると、どの製品も部分的にしか満たさず、比較が成立しません。

ステップ3：将来必要になる機能が、同じ製品で追加できるかを確認する

いま不要でも、1〜2年後に必要になる機能は「後から有効化できるか」を確認します。別製品の追加になると、テナント側の入口がまた増えます。

機能別チェックリスト

選定時にそのまま使える形にまとめます。ベンダーへのRFPや、デモで確認する項目として利用してください。

ラクビルTeXでの実装例

第2層（テナントコミュニケーション）を担う製品として、ラクビルTeXがこれらの要件をどう満たしているかを示します。

館内申請と承認ルート — 承認ルートのノードごとに「承認を求める」「確認を求める」を分けて設定でき、AND条件・OR条件を指定できます。承認者はユーザー個人でもグループでも指定でき、フローに介在しない閲覧者を別枠で設定することも可能です。アカウントを持たない外部業者からのゲスト申請にも対応しています。申請様式は別物件のフォームを複製元にでき、そのとき承認ルートやテナント・グループの紐付けは持ち込まれません。

通知・お知らせ — 配信先を全テナント／テナントグループ／個別テナントから選べ、さらにそのテナントの管理者だけに届けるか、テナントポータルを使う全員に届けるかを切り替えられます。既読は記録され、誰が読んだかを一覧で確認できます。未読者への自動リマインドを設定でき（付けない選択も可）、公開期間の開始・終了も指定できます。お知らせについてそのままやり取りできる導線があり、テンプレート保存と複製にも対応しています。

問い合わせ — 「未対応／対応中／対応済」で管理します。問い合わせルートを設定でき、ルートごとに回答する担当者・グループと、見るだけの閲覧者を分けて指定できます。ルートの表示順も並べ替えられるため、「まずここに」という意図を画面の順序で示せます。そして電話で受けた問い合わせを運営者が代理で登録でき、テナントから直接来たものと同じ場所に記録されます。

AIによる一次対応 — 回答にはどの館内ルールの、どのファイルを参照したかが引用情報として付きます。AIの回答に使う資料はファイル単位で指定でき、古い規則や社内向け資料が使われることを防げます。やり取りは「解決した／解決していない」の状態を持ち、未解決のものは通常の問い合わせとして担当者に引き継がれます。

予約 — 会議室・設備ごとに承認制のON/OFFを設定できます。承認制をONにすると、テナントの予約は「予約リクエスト」として申請され、運営者の承認で確定します。有料会議室については、テナント別の売上をCSVで出力できます。

書類共有 — 個別テナント宛の書類授受に対応し、既読が分かります。新規作成時・更新時の通知設定も持ちます。テナントからの提出書類の確認にも使えます。

アンケート — ログイン不要で回答できます。 結果はグラフ形式で確認でき、LINE公式アカウント経由での配信にも対応しています。

日程調整 — 候補日時を提示してテナントに選んでもらう形で確定します。複数テナントとの日程調整にも対応し、関連資料を添付できます。

売上管理 — 日次報告と月次報告をテナントごとに選択でき、提出期限の設定、未提出アラートのON/OFF、代理入力、休業日設定、証憑ファイルの添付、修正依頼に対応します。CSVは合算モードと明細モード、期間指定、前年比較、複数物件の横断出力が可能です。

共通 — 機能カテゴリごとに「権限なし／閲覧者／編集者」を設定でき、権限は個人にもグループにも付与できます。テナントポータルは「管理者」と「一般ユーザー」に分かれ、一般ユーザーには機能ごとのアクセス可否を設定できます。物件ごとに使う機能を有効化できるため、必要な機能だけを使い、現場の習熟に応じて順次広げられます。申請には管理番号が自動付番され、条件を指定したCSV出力に対応します。ユーザー数に制限はなく、課金は物件単位です。

よくある質問

Q. ビル管理システムは、1製品ですべての業務を賄えますか？

A. 実務上は困難です。設備・保全管理、テナントコミュニケーション、契約・会計・資産管理の3層は、使う人も扱う相手も更新頻度も異なります。1製品で3層すべてを深く作り込むことはほぼ不可能で、「全部入り」を謳う製品はいずれかの層が実務に耐えない浅さになりがちです。設備管理とテナントコミュニケーションを別製品で運用する構成は、妥協ではなく合理的な選択です。

Q. 既存の設備管理システムがあります。テナント向けのシステムを追加すると重複しませんか？

A. 層が違えば重複しません。点検記録や修繕履歴を扱う第1層と、テナントとの連絡・申請・問い合わせを扱う第2層は、使う人も相手も違います。選定前にベンダーへ「この製品を入れた後も、引き続き別システムで行う業務は何ですか」と質問し、明確に答えられるかを確認してください。答えられないベンダーは、併用を前提にした設計になっていない可能性があります。

Q. 機能が多い製品を選んでおけば安心ですか？

A. 逆効果になることがあります。使わない機能がメニューに並ぶと、テナントも運営者も「複雑なシステム」という印象を持ち、定着しません。重要なのは機能の多寡ではなく、物件ごとに使う機能を選べるかです。必要な機能だけを有効化でき、現場の習熟に応じて順次追加できる構成が理想です。

Q. 自社に必要な機能をどう絞り込めばよいですか？

A. 直近1か月のテナントからの電話・メール・来訪を記録し、内容別に分類してください。そのうえで件数の多い上位2〜3機能だけを必須要件とし、残りは「あれば良い」に分類します。全機能を必須にすると、どの製品も部分的にしか満たさず比較が成立しません。感覚で決めると外します。「館内申請が大変」と思っていたが実際は問い合わせ対応のほうが多かった、というのはよくあることです。

Q. 設備の不具合連絡は、専用の機能が必要ですか？

A. 実務上は問い合わせ機能で受けるのが一般的です。テナントから見れば「困ったことを伝える」のは1つの行為であり、不具合専用の入口を別に用意しても使われません。入口は問い合わせに集約し、内容による振り分けは受けた後に運営側で行うほうが現実的です。確認すべきは専用機能の有無ではなく、内容ごとに担当を振り分けられるかです。

Q. テナントからの問い合わせは、どのくらいAIに任せられますか？

A. 想像より大きい可能性があります。AI導入前の問い合わせの内訳を実際に数えたところ、館内ルールに答えが書いてある一般的な質問が全体の6割程度を占めていました。「判断が必要な相談が大半」と思われがちですが、実際には「書いてあることを聞かれている」のが多数派です。まず直近1か月の問い合わせを内容別に数えて、自社の比率を確認してください。判断基準は「答えがすでに文書に書いてあるか」の一点です。

Q. 電話でくる問い合わせはどう扱えばよいですか？

A. 電話をやめる必要はありません。入口を1つにするとは、テナントの連絡手段を1つに縛ることではなく、記録の置き場所を1つにすることです。電話を受けた側が代理でシステムに登録できる仕組みがあれば、記録は一本化されます。この代理登録の機能があるかどうかは、選定時に必ず確認してください。ないと、記録は必ず分散します。

Q. 承認者が複数の会社にまたがります。権限はどう設計しますか？

A. 3つの要件を満たす製品を選んでください。①機能カテゴリ単位で「権限なし／閲覧のみ／編集可」を設定できること、②権限を個人ではなくグループで管理できること、③承認フローに並ぶ人と、フロー外から閲覧する人を分けられること。特に②がないと、担当者交代のたびに全物件の設定を触ることになり、物件数が10を超えたあたりで運用が破綻します。

Q. 複数物件を管理しています。物件ごとに設定が必要ですか？

A. 物件ごとに様式も承認体制も違うのが通常なので、設定は物件ごとに持つのが正しい設計です。全物件を1つの設定に統一しようとする製品は、棟数が増えた時点で現場に拒否されます。一方で、担当物件をまたいで「自分の承認・確認待ち」が1画面で見えることは必須です。担当10棟で毎朝10画面を確認する運用は成立しません。「設定は物件ごと、担当者の入口は横断」が原則です。

Q. テナントに専用アプリを入れてもらう必要がありますか？

A. 専用アプリには通知の確実性などの利点がありますが、インストールが想定どおり進むとは限りません。テナントで働く従業員にとってビルは職場の場所であり、業務で必須でないものを入れる動機は弱いためです。しかもこの浸透率は物件によって大きく変わります。重要なのはアプリを避けることではなく、アプリだけに依存しない構成にすることです。インストールした人にも、していない人にも届く二重の経路を持たせてください。

Q. アンケートでテナント満足度は測れますか？

A. 全体の傾向を定点観測する用途には向いています。満足度の水準と変化、共用部や設備への具体的な不満、要望の傾向は、アンケートでなければ取れません。一方で、退去の予兆や、まだ言語化されていない不満は出てきません。「不満はありますか」に「特にありません」と答えた3か月後に退去通知が来ることは珍しくありません。アンケートで全体を測り、人が会って個別を拾う——両方が必要です。

Q. 導入は全物件同時に行うべきですか？

A. 「物件数を絞る」のではなく「機能と様式を絞る」と考えてください。1棟だけのパイロットは、標準化を目的とする場合には適していません。1棟で作った型は「その物件のやり方」にすぎず、標準として通用するかを検証できないためです。用途や運営体制の異なる複数物件を同時に対象にし、機能と様式のほうを絞るのが確実です。

Q. カスタマイズできる製品と、設定の範囲で使う製品では、どちらがよいですか？

A. 設定の範囲で自社の運用を表現できる製品を優先してください。カスタマイズは一見魅力的ですが、バージョンアップに追随できなくなるリスクがあります。改修のたびに費用と期間がかかり、現場の細かい改善要望が通らなくなる状態に陥りがちです。確認すべきは「カスタマイズできるか」ではなく、「カスタマイズなしで自社の運用を表現できるか」です。物件ごとに設定を持てる製品なら、多くの差異は設定で吸収できます。

Q. オーナーやテナントからセキュリティについて説明を求められます。何を確認しておくべきですか？

A. 5点です。①ISO/IEC 27001（ISMS）などの第三者認証を取得しているか、②通信時・保存時の両方でデータが暗号化されているか、③権限の粒度と、退職者のアカウント無効化が確実に行えるか、④誰がいつ何を見たかのログが残るか、⑤解約時にデータをどう返却・削除するか。特に①は、オーナーへの説明資料としてそのまま使えるため、認証の有無を早い段階で確認しておくと稟議が進みやすくなります。

Q. 稟議が通りません。何が原因になりがちですか？

A. 最も多いのは「既存システムとの重複が説明できない」ケースです。「似たものが既にあるのではないか」という指摘で止まります。対策は、層の整理を先に示すことです。「この製品は第2層を担い、既存の設備管理システム（第1層）とは使う人も相手も違う」と説明できれば、重複の議論は解消します。次に多いのが効果の説明で、ここは導入前に現状を測っておくしかありません。直近1か月の電話件数と内容の記録があるだけで、稟議の説得力は大きく変わります。

Q. 費用はどのように決まりますか？

A. 課金の単位を必ず確認してください。ユーザー課金の製品では、オーナー・PM・BM・警備・清掃の担当者やテナント側のユーザーを増やすほど費用が上がり、「費用を抑えるために必要な人を登録しない」という本末転倒が起きます。テナントとのやり取りを扱うシステムは、関係者が全員登録されて初めて効果が出る性質のものです。見積もり時には、5年後の想定物件数と関係者数で試算してください。

まとめ

ビル管理システムの選定は、次の順序で進めます。

1. どの層を埋めるのかを先に決める — 設備・保全管理、テナントコミュニケーション、契約・会計・資産管理。1製品では完結せず、併用が前提です

2. 直近1か月の業務を数え、件数の多い上位2〜3機能に絞る — 全機能を必須要件にすると比較が成立しません

3. 機能別チェックリストで、実務に耐えるかを確認する — 機能の有無ではなく、実装の粒度を見ます

4. 層を跨ぐ共通論点を確認する — 権限設計、複数物件、記録の取り出し、テナント側の入口

特に見落とされやすい確認事項を3つ挙げておきます。

• 電話で受けた問い合わせを代理登録できるか。 記録の一本化は、テナントの行動を変えずに実現できます

• 他物件から様式を持ち込めるか。そのとき承認体制まで複製されないか。 標準化の成否と、事故の有無がここで決まります

• 物件をまたいで「自分の承認・確認待ち」が1画面で見えるか。 機能一覧には現れませんが、複数物件運用では最重要です

そして最後に、選定の前提として押さえておきたいことがあります。システムで効率化すべきなのは手続きであって、テナントとの関係ではありません。 申請の受付、お知らせの配布、問い合わせの記録に人が時間を使う必要はありません。一方で、テナントの状況を把握し、困りごとがクレームになる前に拾う——これは人にしかできず、更新率と稼働率に直結します。手続きの効率化で生まれた時間を何に使うかを決めておくことが、導入を成功させる最後の条件です。

ラクビルTeXについて

ラクビルTeXは、オフィスビル・商業施設・物流倉庫など事業用不動産の運営者とテナントをつなぐWebプラットフォームです。本記事の第2層（テナントコミュニケーション）にあたる領域を担い、館内申請と承認フロー、テナントへの通知、問い合わせ管理、AIによる問い合わせ自動応答、会議室・共用設備の予約、館内ルール掲示、個別テナント宛書類の共有、アンケート、日程調整、売上管理などを一つのプラットフォームで提供しています。複数物件・複数社での運用を前提に設計されており、国際セキュリティ規格 ISO/IEC 27001 の認証を取得しています。

• サービスサイト：https://tex-lp.rakbil.com

また、「どの層から手をつければよいか分からない」「社内の合意形成から相談したい」という段階のご相談には、事業用不動産に特化したDX・AI活用コンサルティングサービスをご用意しています。約30分の無料相談で、現状の課題整理からお手伝いします。

• ご相談はこちら：https://tex-lp.rakbil.com/consulting