ビル管理DXクラウドの選び方｜複数物件・複数社の運用を標準化する7つの評価軸

管理棟数が増えるほど、ビル管理の業務は標準化されるどころか、物件ごとにバラバラになっていきます。申請書の様式が物件ごとに違う。承認の回し方が担当者ごとに違う。テナントへの連絡手段が、ある物件はメール、ある物件は掲示、ある物件はLINE。

この状態を解消しようとして「ビル管理DXクラウド」の検討を始めると、今度は別の問題にぶつかります。製品によって守備範囲がまったく違い、比較の土俵が揃わないのです。

本記事では、複数物件を管理する事業者がビル管理DXクラウドを選ぶための評価軸を、7つに整理して解説します。特に「標準化」という言葉の意味を取り違えると導入が失敗するため、その点を最初に整理します。

結論：ビル管理DXクラウドは「レイヤー」と「標準化の粒度」で選ぶ

先に結論をまとめます。複数物件を前提としたビル管理DXクラウドの選定は、次の2つの判断に集約されます。

1. どのレイヤーの製品かを見極める — ビル管理DXは1製品では完結しません。設備・保全管理層、テナントコミュニケーション層、契約・会計・資産管理層は別のレイヤーであり、併用が前提です。この見極めを飛ばすと、比較表を作った時点で議論が噛み合わなくなります

2. 標準化の粒度が設計されているかを見る — 「標準化」とは全物件を同じ設定に統一することではありません。 揃えるべきものと、物件ごとに残すべきものを分けられる設計かどうかが、複数物件での成否を決めます

そして、この2つを踏まえた実務的な評価軸は次の7つです。

このうち4が最も見落とされ、最も失敗の原因になります。以降で順に説明します。

そもそもビル管理DXクラウドとは何か — 3つのレイヤーに分かれている

「ビル管理DXクラウド」「ビル管理SaaS」という言葉は、実務ではまったく異なる3種類の製品を指して使われています。まずここを分けないと、選定の議論が成立しません。

レイヤー1：設備・保全管理層

建物の設備そのものを対象とする層です。法定点検・定期点検の記録、修繕履歴、故障対応の受付と手配、設備台帳、エネルギー管理などを扱います。BM会社（ビルマネジメント会社）や設備会社の業務に直結します。

この層の製品としては、たとえば管理ロイドのような、点検・保全業務のデジタル化に特化したサービスがあります。現場作業者がスマートフォンで点検記録を入力し、履歴を蓄積していく使い方が中心です。

レイヤー2：テナントコミュニケーション層

建物の運営者と、そこに入居するテナントとの間で発生するやり取りを対象とする層です。本記事が主に扱うのはこの層です。

• テナントへのお知らせ・緊急連絡

• 館内申請（工事、搬入出、時間外作業、火気使用、鍵貸出など）の受付と承認

• テナントからの問い合わせ受付と対応管理

• 会議室・共用設備の予約

• 入退館の管理

• 館内ルール・各種書類の共有

PM会社（プロパティマネジメント会社）やビルオーナーの業務に直結します。相手が社外のテナントであるという点が、この層の設計を根本的に規定します。

レイヤー3：契約・会計・資産管理層

賃貸借契約の管理、賃料請求と入金消込、水光熱費の按分請求、収支管理、NOI（純営業収益）の把握などを扱う層です。AM会社（アセットマネジメント会社）やオーナーの経営判断に直結します。

1製品ですべてを賄おうとすると失敗する理由

この3層は、業務の主体も、データの更新頻度も、扱う相手も違います。

1つの製品で3層すべてを深く作り込むことは、実務上ほぼ不可能です。結果として、「全部入り」を謳う製品は、いずれかの層が実務に耐えない浅さになります。

現場でよく見られるのは、設備・保全管理層とテナントコミュニケーション層を、それぞれ別の製品で運用している構成です。これは妥協ではなく、合理的な選択です。点検記録を入力するBM会社の作業者と、テナントからの工事申請を承認するPM会社の担当者は、そもそも別の人間で、別の画面を見ています。

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

なぜ複数物件になると運用が破綻するのか

1棟だけなら、Excelとメールでも回ります。破綻は棟数が増えたときに起きます。現場で実際に起きている問題は、おおむね次の6つです。

1. 様式が物件ごとに増殖する 新しい物件を受託するたびに、その物件の様式が持ち込まれます。オーナーが違えば書式も違い、統一の音頭を取る人がいないまま増えていきます。3年後には、同じ「工事作業申請」が10種類存在します。

2. 担当者が毎朝いくつもの画面を確認する 物件ごとにフォルダが分かれ、メールボックスが分かれ、システムが分かれます。担当物件が10棟あるPM担当者が、毎朝10箇所を確認する運用は現実的ではありません。確認漏れは、担当者の注意力ではなく設計の問題として発生します。

3. 担当者が交代すると運用が消える 「この物件はこう回している」という知識が個人に紐づいているため、異動や退職のたびに再構築が起きます。物件数が多いほど、この再構築が常時どこかで発生している状態になります。

4. 承認の現在地が見えない 承認者がオーナー、PM、BM、警備会社にまたがるため、紙やメールで回すと「今どこで止まっているか」が追えません。催促は電話になり、物件数に比例して電話の本数が増えます。

5. 集計ができない 「昨年度、全物件の深夜作業は何件あったか」「このテナントの工事履歴を出してほしい」に答えられません。物件ごとに記録の粒度が違うため、集めても足し算ができないのです。

6. テナント側の入口が複数になる 申請はメール、予約は電話、問い合わせはWebフォーム、というように入口が分かれていると、テナントは結局いちばん確実な手段——電話——に戻ります。

これらはすべて、物件ごとに運用が独立していることに起因します。だから「標準化」が必要だ、という話になるのですが、ここに落とし穴があります。

「標準化」を誤解しない — 揃えるもの、揃えてはいけないもの

複数物件の標準化プロジェクトが失敗する最大の原因は、標準化を「全物件を同じ設定に統一すること」だと解釈してしまうことです。

これをやると、次のことが起きます。全物件共通の申請フォームを1つ作る。しかしA物件には荷捌き場がなく、B物件には共用の電気室があり、C物件は商業施設で深夜搬入が前提です。共通フォームは、どの物件から見ても「使わない項目が並び、必要な項目がない」ものになります。現場は使いません。そして紙に戻ります。

揃えるべきもの

揃えてはいけないもの

標準化の正しい定義

以上を踏まえると、複数物件のビル管理における標準化は、次のように定義できます。

標準化とは、業務の「型」と「記録の形式」を共通化し、物件固有の「体制」と「構成」は物件ごとに保持したうえで、担当者の入口だけを1つにまとめることである。

この定義を持って製品を見ると、評価すべきポイントが具体的に決まります。以降の7つの評価軸は、すべてこの定義から導かれています。

評価軸1：どのレイヤーの製品かを見極める

確認すること： その製品が設備・保全管理層、テナントコミュニケーション層、契約・会計・資産管理層のどれを担うか。既存システムと重複しないか。

デモの前に、次の質問をベンダーにしてください。

• 「この製品を入れた後も、引き続き別のシステムで行う業務は何ですか」

• 「すでに◯◯（既存システム）を使っていますが、どこで役割が分かれますか」

この2問に明確に答えられないベンダーは避けたほうが無難です。 自社製品の守備範囲を説明できないということは、他社製品との併用を前提にした設計になっていない可能性が高いためです。

また、社内稟議の観点でも重要です。既存システムとの重複が説明できないと、「似たものが既にあるのではないか」という指摘で稟議が止まります。レイヤーの整理は、選定のためだけでなく、社内合意形成のためにも必要です。

評価軸2：物件をまたぐ「承認・確認待ち」が1画面で見えるか

確認すること： 担当物件が複数あるとき、物件を切り替えずに「自分の承認・確認が必要な案件」を一覧できるか。

これは複数物件運用における最重要の機能要件です。にもかかわらず、機能一覧には現れにくいため、比較表では見落とされます。

なぜ「要対応すべて」ではなく、承認・確認に絞るのか

横断すべき対象を欲張ると、要件が発散して製品比較ができなくなります。優先すべきは承認・確認です。理由は、業務の性質が違うからです。

問い合わせ対応や設備不具合の対応は、その物件の日常担当者の仕事です。担当者は毎日その物件の画面を開くので、物件単位の一覧でも業務は回ります。

承認は違います。 承認者は、オーナー、AM会社の担当者、別会社の管理職など、その物件の日常業務には関与しない人であることが少なくありません。物件の画面を毎日開く習慣がないため、承認依頼が本人の目に入る場所に届かなければ、そこで止まります。そして複数物件運用でリードタイムが伸びる最大の原因は、この承認の滞留です。

したがって、横断が必要なのはまず承認・確認である——この優先順位で製品を評価してください。なお、問い合わせや不具合まで物件横断で一覧できる製品は多くありません。承認から揃えるのが現実的な出発点です。

デモでは、次のように依頼してください。

「3つの物件で、私の承認待ちの申請がそれぞれ1件ずつある状態を作ってください。ログイン直後の画面で、その3件が見えますか」

物件を選んでから一覧を開く構造の製品では、これができません。担当10棟なら、毎朝10回の物件切り替えが発生します。運用が定着するかどうかは、この1点でかなりの部分が決まります。

あわせて確認したいのが、その一覧を担当者が自分で整理できるかです。長期の工事案件のように何ヶ月も表示され続けるものがあると、一覧はすぐに使われなくなります。個別に非表示にできる、並び替えられる、といった調整機能があるかを見てください。

評価軸3：物件ごとに使う機能を選べるか、段階的に開放できるか

確認すること： 物件ごとに、使う機能を機能単位で有効化できるか。全物件に一律で全機能が展開されてしまわないか。

見落とされやすいのですが、複数物件の展開ではここが定着を大きく左右します。

理由は2つあります。

1つは、物件によって必要な機能が違うこと。 商業施設では売上報告やイベントスペースの予約が必要ですが、単一テナントの物流倉庫ではどちらも不要です。不要な機能がメニューに並んでいると、テナントも運営者も「使わなくていいものが多い、複雑なシステム」という印象を持ちます。

もう1つは、現場の習熟に差があること。 DXに前向きな物件と、紙の運用が長く続いてきた物件では、受け入れ速度が違います。全機能を一斉に開放すると、後者では「何から手をつければいいか分からない」となり、結局使われません。まず館内申請だけ、次に問い合わせ、慣れたら予約、というように順次開放できると、定着率が変わります。

デモでは「A物件では館内申請と通知だけ、B物件ではそれに加えて予約と入退館を使う、という設定は可能ですか」と確認してください。

評価軸4：様式は持ち込め、体制は持ち込まれないか

確認すること： 他物件で作った申請フォームを新しい物件に持ち込めるか。そしてそのとき、承認ルートやテナント・グループの紐付けまで一緒に持ち込まれないか。

7つの評価軸のうち、最も見落とされ、最も差が出るのがここです。

新しい物件を受託するたびに、10種類の申請様式をゼロから作り直す運用は続きません。したがって「他物件の様式を持ち込めること」は必須要件です。

しかし、持ち込みが雑に実装されていると、逆に事故が起きます。 A物件のフォームをB物件に複製したときに、A物件の承認ルート（A物件のオーナー担当者、A物件のBM会社の設備担当グループ）まで一緒についてくると、どうなるでしょうか。B物件の申請が、A物件の関係者に回ります。しかも設定した本人が気づかないまま運用が始まります。

正しい設計は、様式（項目定義）は持ち込み、物件固有の紐付けは持ち込まないというものです。前章で整理した「揃えるべきもの／揃えてはいけないもの」の線が、そのまま実装に現れる箇所だと言えます。

デモでは、この操作を必ず自分で試してください。

「A物件の工事作業申請フォームを、B物件に複製してください。複製後、承認ルートの設定がどうなっているか見せてください」

承認ルートが空になっていて、B物件用に設定し直す画面が出てくれば、設計は正しい。A物件の承認者がそのまま入っていたら、運用に乗せる前に事故を起こします。

評価軸5：機能をまたいで1つの業務として繋がるか

確認すること： 連絡・申請・予約・入退館が、別々の機能としてではなく、1つの業務の流れとして繋がるか。

現場の業務は、機能の区切りでは動いていません。たとえば内装工事の一連の流れは、次のようになります。

1. テナント（または工事業者）が工事作業申請を出す

2. PM・BM・警備が承認する

3. 作業日に業者が来館するため、入退館の手続きが必要になる

4. 資材搬入のため、荷捌き場や共用部の予約が必要になる

5. 作業時間帯について、他テナントへお知らせを出す

これらが別々のシステム、あるいは同じシステムでも繋がっていない別機能だと、同じ情報を何度も入力することになります。作業日時を申請書に書き、入退館の予約にも書き、予約システムにも書く。どこか1つを直し忘れれば、現場で食い違いが起きます。

確認すべきポイントは2つです。

① 予約が承認を経て確定する運用に切り替えられるか 共用設備の予約を「早い者勝ちの即時確定」にできる物件と、「運営者の承認をもって確定」にしたい物件があります。後者に対応できないと、予約だけ別運用になります。

② 申請の内容が、後続の手続きに引き継がれるか 工事申請に入力した作業日時や作業範囲が、入退館の手続きに引き継がれるか。二重入力を強いる設計になっていないか。

そしてもう1つ、テナント側の入口が1つになっているかを必ず見てください。テナントから見て、申請はここ、予約はあちら、問い合わせは電話、という状態では、運営者側だけが効率化されてテナントには負担が増えます。テナントが使わなければ、DXとしては失敗です。

評価軸6：会社をまたぐ権限分離ができるか

確認すること： オーナー、AM、PM、BM、警備会社、清掃会社といった別会社の担当者に対し、機能単位でアクセス範囲を分けられるか。

事業用不動産の運営では、1つの物件に複数の会社の担当者が関与します。これが一般的な社内向けワークフローツールとの決定的な違いです。

必要な要件は3つあります。

① 機能カテゴリ単位で権限を設定できること 警備会社の担当者に入退館管理は見せるが、テナントの売上情報や契約関連書類には一切アクセスさせない、といった設定です。「閲覧できる／できない」の2値ではなく、機能ごとに「権限なし／閲覧のみ／編集可」の3段階で設定できると、実務に合います。

② 権限を個人ではなくグループで管理できること 別会社の担当者は交代します。個人単位で権限を設定していると、交代のたびに全物件の設定を触ることになります。「BM会社・設備担当グループ」のようにグループを作り、メンバーの入れ替えだけで対応できる設計が必要です。

③ 承認と閲覧を分けられること 承認フローに並ぶ人と、フローには関与しないが内容は見ておきたい人は違います。「承認を求める人」「確認だけしてもらう人」「フローの外から閲覧する人」を分けられないと、承認ステップが不必要に長くなります。

②が無い製品は、物件数が10を超えたあたりで運用が破綻します。選定時に必ず確認してください。

評価軸7：記録を横断で取り出せるか

確認すること： 蓄積された申請・連絡・問い合わせの記録を、条件で絞り込んで検索・出力できるか。

標準化の目的の1つは、物件をまたいだ集計ができる状態を作ることです。記録が構造化されていなければ、いくら蓄積しても経営judgmentに使えません。

確認したいのは次の3点です。

① 管理番号で特定できるか 申請1件ごとに一意の番号が自動で付くと、電話やメールでの照会が「◯月◯日にお出しいただいた工事の件」から「申請番号◯◯の件」に変わります。物件数・件数が多いほど効果が大きくなります。

② 条件を指定してCSVで出力できるか 申請種別・期間・ステータス・テナントで絞り込んでCSV出力できれば、月次集計はExcelで完結します。この機能の有無は導入前に必ず確認してください。 出力できない製品では、集計のたびに画面を数える作業が発生します。

③ テナントが退去しても記録が残るか 区画の工事履歴、火気使用の記録、深夜作業の記録は、テナントではなく建物に紐づく資産です。退去テナントを「削除」ではなく「アーカイブ」として扱い、履歴を建物側に残す設計になっているかを確認してください。

Kintone・Salesforceで内製するという選択肢をどう評価するか

ビル管理DXの検討では、専用製品の導入と並んで、Kintone や Salesforce といった汎用プラットフォーム上に自社で構築する選択肢が必ず挙がります。開発会社に受託開発を依頼するケースも含めて、ここを正しく評価しておく必要があります。

内製が向いているケース

正直に申し上げると、次の条件下では汎用プラットフォームでの内製も合理的な考えと言えるかもしれません。

• 管理物件が1〜3棟程度

• 申請様式が3種類程度

• 承認者が自社の1〜2名で完結する

• 社内に業務システムを継続的にメンテナンスできる人がいる

この範囲であれば、専用製品を導入するより早く、安く、自社の運用に合ったものが作れます。「まず内製で始める」は悪い判断ではありません。

内製が壁にぶつかる4つのポイント

一方で、次の要件が入ってきた時点で、汎用プラットフォームでの構築は急速に難しくなります。

1. 社外ユーザーの取り扱い テナント、そのさらに先の工事業者は自社の社員ではありません。ライセンスをどう持たせるか、アカウントを持たない業者にどう申請させるか、テナントが退去したらアカウントをどうするか——ここで設計が複雑になります。社内向けプラットフォームは、社外ユーザーが主役になる前提で作られていません。

2. 会社をまたぐ権限分離 評価軸6で述べた「機能カテゴリ単位・グループ単位の権限」を自前で作り込むのは、可能ではあっても保守負担が大きくなります。物件が増えるたびに権限設計を再現する必要があり、設定ミスは情報漏えいに直結します。

3. 物件ごとの差異の吸収 物件ごとに様式と承認体制が違う、という前提を汎用プラットフォームで表現しようとすると、アプリが物件数だけ増えるか、1つのアプリが条件分岐だらけになるかのどちらかになります。評価軸4で述べた「様式は持ち込み、体制は持ち込まない」を自前で実装するのは、想像以上に難しい部分です。

4. 属人化 構築した担当者が異動・退職した後、誰も触れなくなるケースが頻発します。受託開発の場合も、改修のたびに費用と期間がかかり、現場の細かい改善要望が通らなくなります。

判断の目安

内製を検討する場合でも、項目定義（どの申請で何を聞くか）だけは最初から丁寧に設計してください。 項目設計は、どのツールに移っても資産として残ります。逆に、項目定義が曖昧なまま作られたシステムは、専用製品に移行する際にも作り直しになります。

なお、社内の稟議では「内製のほうが安い」という比較が出やすいのですが、比較すべきは初期構築費ではなく、5年間の保守・改修・属人化リスクを含めた総額です。物件数が増える計画があるなら、その前提で試算してください。

導入の進め方 — 絞るのは物件数ではなく、機能と様式

導入範囲の絞り方を間違えると、標準化は進みません。よくあるのが「まず1棟で試す」という進め方ですが、標準化を目的とする場合、これは適していません。

理由は単純です。1棟で作った型は「その物件のやり方」にすぎず、それが標準として通用するかどうかは検証できません。 共通項と物件固有の差は、複数の物件を並べて初めて見えます。1棟で固めた型は、2棟目を入れた時点でほぼ必ず作り直しになります。

絞るべきなのは物件数ではなく、機能と様式の範囲です。

ステップ1：性格の異なる複数物件を、同時に対象にする 用途・規模・運営体制の異なる複数の物件を選んでください。オフィスビルと商業施設、大型物件と中小物件、といった組み合わせです。違いのある物件を並べることで、「揃えられるもの」と「物件ごとに残すもの」の線が最初から見えます。 何棟を同時に立ち上げられるかは、現場の受け入れ体制と、ベンダーの初期設定支援の有無で決まります。

ステップ2：機能と様式を絞る ここを広げすぎると現場が追いつきません。最初は館内申請と通知だけ、様式は件数の多い1〜2種類だけ、という範囲に絞ります。工事作業申請と搬入出申請から始めるのが一般的です。並行運用の期間を設け、紙も受け付けながら移行します。

ステップ3：共通項と差分を仕分ける 複数物件で同じ様式を運用してみると、「どの項目がどの物件でも必要か」「どこから物件固有か」が具体的に分かります。ここで初めて「標準」と呼べる型が確定します。

ステップ4：確定した型を残りの物件に広げる 様式が確定していれば、物件を増やす負担は逓増しません。他物件の様式を複製で持ち込める製品であれば、この段階の作業はほぼ承認体制の設定だけになります（評価軸4）。

ステップ5：機能を順次追加する 申請が定着したら問い合わせ、次に予約、というように機能を広げます。物件ごとに開放の速度を変えられると、なお進めやすくなります（評価軸3）。

立ち上げ時にベンダーの初期設定支援を受けられるかも確認しておいてください。最初の型づくりに伴走してもらえるかどうかは、同時に立ち上げられる棟数を左右します。

効果をどう測るか

「なんとなく楽になった」で終わらせないために、次の4つの指標を導入前に測っておきます。

1. 申請から承認完了までのリードタイム 最も重要な指標です。会社をまたぐ承認ほど改善幅が大きくなります。物件別に取ると、承認体制の見直しが必要な物件が特定できます。

2. 差し戻し率（差し戻し件数 ÷ 総申請件数） 様式の設計品質を直接表します。差し戻しの多い項目を特定し、説明文の追加や入力形式の変更で改善します。

3. 申請・連絡に関する電話・メール問い合わせ件数 「様式はどこか」「今どうなっているか」という問い合わせの減少が、担当者の工数削減に直結します。

4. 物件あたりの標準様式の数 複数物件の標準化に固有の指標です。同種の申請が物件ごとに何種類存在するかを数えてください。標準化が進めば、この数は減ります。増え続けているなら、標準化ではなく単なるデジタル化に留まっています。

いずれも、記録が構造化され、CSVで取り出せることが前提になります。評価軸7が効いてくるのはここです。

ラクビルTeXでの実装例

ここまで述べた要件を、事業用不動産に特化したプラットフォームがどう解いているか、ラクビルTeXを例に具体的に示します。ラクビルTeXは、前述のレイヤー2（テナントコミュニケーション層）を担う製品です。

横断するのは「承認・確認待ち」だけ、設定は物件ごとに持つ

ラクビルTeXでは、承認・確認を求められている申請が、物件を切り替えずに1つの画面に集まります。 ログイン後に最初に開く画面が、特定の物件ではなく担当者個人のダッシュボードになっており、担当している複数の物件の案件が物件名とともに並びます。作業日時が当日の申請や、作業予定のカレンダーも同様に物件をまたいで表示されます。長期の工事案件のように表示され続けて邪魔になるものは、利用者が自分の判断で個別に非表示にできます（非表示にしても削除はされず、一覧や詳細では引き続き確認できます）。

一方で、申請フォーム、承認ルート、テナントへのお知らせは、すべて物件ごとに持ちます。全物件共通の1フォームに寄せる設計にはなっていません。物件ごとにオーナーが違い、承認体制が違い、テナント構成が違うという前提に立っているためです。

さらに、物件ごとに使う機能を有効化できます。 商業施設では売上報告や共用部の予約まで使い、単一テナントの倉庫では館内申請と通知だけを使う、といった構成が取れます。現場の習熟に応じて、使う機能を順次広げていく進め方も可能です。

「担当者の入口は1つに、設定は物件ごとに」という、標準化の定義がそのまま構造になっています。

様式は別物件から持ち込め、承認体制は持ち込まれない

新しい物件を立ち上げる際、別の物件で使っている申請フォームを複製元として選び、その物件のフォームを作成できます。 10種類の様式をゼロから組み直す必要はありません。

重要なのはその挙動です。別物件から複製するとき、持ち込まれるのは申請フォームの項目定義（＝様式）だけで、承認ルートやテナント・グループの紐付けは持ち込まれません。 複製先の物件で、その物件の体制に合わせて設定し直す形になります。

これは制約ではなく、意図された設計です。A物件のフォームを複製した結果、A物件のオーナー担当者やA物件のBM会社の設備担当グループが、B物件の承認フローに紛れ込む——という事故を、運用ルールではなく仕組みとして防いでいます。揃えるべきものは様式、揃えてはいけないものは体制という線が、そのまま実装の境界になっています。

なお、添付ファイルも複製されません。複製元の様式に添付されていた資料が、複製先の物件にそのまま当てはまるとは限らないためです。テナントへのお知らせについても、同様に複製から作成できます。

申請・予約・入退館を1つの業務として繋ぐ

ラクビルTeXでは、テナント申請・ゲスト申請（アカウントを持たない外部業者からの申請）・物件運営者申請という3種類の申請を、1つの一覧で扱います。誰から出された申請かによって画面が分かれることはありません。

会議室や共用設備の予約については、設備ごとに承認制のON/OFFを設定できます。 承認制をONにすると、テナントからの予約は「予約リクエスト」として申請され、物件運営者の承認をもって確定します。早い者勝ちで確定させたい設備と、運営者の判断を挟みたい設備を、同じ物件の中で使い分けられます。

また、工事・搬入・点検のように作業日時を伴う申請では、申請フォームに「作業日時」を持たせることができ、その項目を入退館の予約と対応づけて連携させられます。 登録された作業日時は、申請一覧の並び替えや絞り込み、ダッシュボードの「本日の申請」やカレンダーにも反映されます。工事申請と当日の入退館手続きが別管理になり、現場で二重入力が発生する、という事態を避けられます。

会社をまたぐ権限分離を、承認と閲覧の両面で設計する

物件運営者のアカウントには、機能カテゴリごとに「権限なし／閲覧者／編集者」を設定できます。 館内申請、テナント管理、承認フロー、問い合わせ、売上管理、入退館管理、不具合管理、館内ルール、Webアンケートなどが、それぞれ独立した権限単位です。警備会社の担当者には入退館管理の閲覧権限だけを与え、テナント情報や売上情報には一切アクセスさせない、といった設計が標準機能として行えます。

権限は個人にも、グループにも付与できます。物件運営者グループはユーザー管理から、テナントグループはテナント情報から編成します。別会社の担当者が交代しても、グループのメンバーを入れ替えるだけで済み、承認ルート側を触る必要はありません。

承認ルートについては、ノードごとに「承認を求める」と「確認を求める」を分けて設定でき、ノードのまとまりにAND条件・OR条件を指定できます。さらに、承認ルート全体に対して、フローには介在しない閲覧者・閲覧グループを別枠で設定できます。「BM会社の設備担当グループの誰か1人が承認すれば進む。オーナーの担当者は承認者ではないが内容は見える」といった運用が、そのまま表現できます。

なお、ユーザー数に制限はなく、管理者ユーザー・テナントユーザーとも自由に増減できます。ユーザー数による課金体系の変化はなく、課金は物件単位です。複数の会社の関係者を必要なだけ登録するという使い方が、費用面でも前提になっています。

よくある質問

Q. ビル管理DXクラウドは、1製品ですべての業務を賄えますか？

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

Q. 「標準化」とは、全物件を同じ運用に統一することですか？

A. 違います。全物件共通の申請フォームを1つ作ると、どの物件から見ても「使わない項目が並び、必要な項目がない」ものになり、現場は使いません。標準化とは、用語・ステータスの定義・記録の粒度・様式の骨格を共通化し、承認体制やテナント構成といった物件固有のものは物件ごとに保持したうえで、担当者が毎朝見る入口だけを1つにまとめることです。

Q. 担当物件が10棟あります。毎朝10画面を確認する必要がありますか？

A. その必要がない製品を選んでください。ただし横断の対象を欲張ると要件が発散するため、優先すべきは「自分の承認・確認が必要な案件」です。問い合わせや不具合の対応はその物件の日常担当者の業務なので物件単位の画面でも回りますが、承認者はその物件の日常業務に関与しない人であることが多く、本人の目に入る場所に届かないと止まるためです。デモでは、3物件で承認待ちを1件ずつ作ってもらい、ログイン直後の画面に3件とも表示されるかを試してください。

Q. 他物件で作った申請フォームを、新しい物件に持ち込めますか？

A. 製品によります。持ち込めない製品では、物件を受託するたびに全様式を作り直すことになり、運用が続きません。ただし持ち込み方が重要で、承認ルートやテナント・グループの紐付けまで一緒に複製されてしまう製品は危険です。B物件の申請がA物件の関係者に回る事故が、設定者の気づかないうちに起こります。様式（項目定義）だけが持ち込まれ、承認体制は複製先で設定し直す設計になっているかを、デモで必ず確認してください。

Q. 物件ごとに申請様式も承認体制も違います。統一すべきですか？

A. 様式の骨格は統一を目指し、承認体制は統一しないでください。承認ルートは物件の契約構造そのもの——オーナーが誰で、PM・BM・警備がどの会社か——を反映したものであり、物件をまたいで揃えることはできません。無理に揃えると、実際の意思決定と乖離した承認フローになり、現場が形骸化させます。

Q. 全物件に同じ機能を展開すべきですか？

A. 物件ごとに使う機能を選べるほうが定着します。理由は2つあり、1つは物件によって必要な機能が違うこと（商業施設では売上報告が必要でも、単一テナントの物流倉庫では不要）、もう1つは現場の習熟に差があることです。全機能を一斉に開放すると、紙の運用が長かった物件では「何から手をつけるか分からない」となって使われません。館内申請から始めて順次広げられる構成が理想です。

Q. 設備管理システムをすでに導入しています。重複しませんか？

A. レイヤーが違えば重複しません。点検記録や修繕履歴を扱う設備・保全管理層と、テナントとの連絡・申請・問い合わせを扱うテナントコミュニケーション層は、使う人も相手も違います。実際、両者を別製品で併用している運営者は多くあります。選定前にベンダーへ「この製品を入れた後も、引き続き別システムで行う業務は何ですか」と質問し、明確に答えられるかを確認してください。

Q. 会議室・共用設備の予約と館内申請は、別々のツールで管理すべきですか？

A. 分けないほうがよいと考えます。理由はテナント側にあります。申請はここ、予約はあちら、と入口が分かれると、テナントは結局いちばん確実な手段である電話に戻ります。運営者側だけが効率化され、テナントには負担が増える状態です。また、予約を「承認制」に設定できるかも確認してください。早い者勝ちで確定させたい設備と、運営者の判断を挟みたい設備が同じ物件に混在するのが通常です。

Q. オーナー・PM・BM・警備など複数の会社が関わります。権限はどう分けますか？

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

Q. Kintoneや Salesforceで自社構築するのと、専用製品を導入するのはどちらがよいですか？

A. 1〜3棟・様式3種類程度・承認者が自社で完結する範囲であれば、汎用プラットフォームでの内製は合理的です。壁になるのは、社外ユーザー（テナント・工事業者）の取り扱い、会社をまたぐ権限分離、物件ごとの差異の吸収、そして構築者が異動した後の属人化の4点です。内製を選ぶ場合でも、項目定義だけは丁寧に設計してください。項目設計はどのツールに移っても資産として残ります。また、比較すべきは初期構築費ではなく、5年間の保守・改修・属人化リスクを含めた総額です。

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

A. 「物件数を絞る」のではなく「機能と様式を絞る」と考えてください。標準化が目的であれば、1棟だけのパイロットは適していません。1棟で作った型は「その物件のやり方」にすぎず、標準として通用するかを検証できないためです。用途や運営体制の異なる複数物件を同時に対象にすると、共通項と物件固有の差が最初から見えます。一方で、最初から全機能・全様式を開放すると現場が追いつきません。広げるのは物件、絞るのは機能と様式です。同時に立ち上げられる棟数は、現場の受け入れ体制と、ベンダーの初期設定支援があるかで決まります。

Q. 選定時、デモでは何を試せばよいですか？

A. 次の5つを実際に操作させてもらってください。①3物件それぞれの承認待ちが、ログイン直後の1画面に出るか。②A物件の申請フォームをB物件に複製し、承認ルートがどうなるか。③別会社の担当者に、特定機能だけ閲覧権限を与える設定。④承認者をグループで指定し、メンバーを入れ替える操作。⑤条件を絞り込んでの申請データのCSV出力。機能一覧を見るより、この5つを触るほうが製品差がはっきり分かります。

Q. 過去の申請・連絡履歴は横断で検索・集計できますか？

A. 製品によります。確認すべきは3点で、①申請1件ごとに管理番号が自動付番されるか、②申請種別・期間・ステータス・テナントで絞り込んでCSV出力できるか、③テナントが退去した後も履歴が残るか、です。特に③は重要で、区画の工事履歴や火気使用・深夜作業の記録は、テナントではなく建物に紐づく資産です。退去テナントを削除ではなくアーカイブとして扱う設計になっているかを、導入前に確認してください。

Q. 費用は物件単位ですか、ユーザー単位ですか？

A. 製品によって異なり、複数物件・複数社での運用ではこの違いが総額に大きく影響します。ユーザー課金の製品では、オーナー・PM・BM・警備・清掃の担当者を必要なだけ登録すると費用が膨らみ、「必要な人を登録しない」という本末転倒な運用に陥りがちです。ラクビルTeXの場合、ユーザー数に制限はなく、課金は物件単位です。見積もり時には、5年後の想定物件数と関係者数で試算してください。

まとめ

複数物件を前提としたビル管理DXクラウドの選定は、次の順序で進めます。

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

2. 標準化の定義を揃える — 用語・ステータス・記録の粒度・様式の骨格は揃える。承認体制・テナント構成・使う機能の範囲は物件ごとに残す

3. 7つの評価軸で製品を見る — 特に「様式は持ち込め、体制は持ち込まれないか」を、デモで自分の手で確認する

4. 絞るのは物件数ではなく、機能と様式 — 性格の異なる複数物件を同時に対象にし、機能と様式を絞って始める

そして最も重要な視点は、複数物件の標準化とは「全物件を同じにすること」ではなく、「揃えるものと残すものを、意図をもって分けること」であるという点です。

• 揃えるのは、業務の型と記録の形式

• 残すのは、物件ごとの体制と構成

• 1つにまとめるのは、担当者の入口

この3つの線引きができている製品は、物件が増えても運用が破綻しません。逆に、全物件を1つの設定に統一しようとする製品や運用は、棟数が増えた時点で必ず現場に拒否されます。

進め方としては、性格の異なる複数の物件を同時に対象にし、機能と様式を絞って始めるのが確実です。1棟だけで型を固めても、それが標準として通用するかは分かりません。共通項と物件固有の差は、違いのある物件を並べて初めて見えてきます。

ラクビルTeXについて

ラクビルTeXは、オフィスビル・商業施設・物流倉庫など事業用不動産の運営者とテナントをつなぐWebプラットフォームです。本記事で解説した館内申請の受付・承認、テナントへの通知、問い合わせ管理、会議室・共用設備の予約管理、入退館管理、館内ルール掲示などを、一つのプラットフォームで提供しています。複数物件・複数社での運用を前提に設計されており、国際セキュリティ規格 ISO/IEC 27001 の認証を取得しています。

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

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

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