館内申請をフォーム化して承認を効率化する方法｜業務申請のワークフロー化 実践ガイド

工事、搬入出、深夜・休日作業、火気使用、鍵の貸出——オフィスビルや商業施設の運営には、テナントから日々さまざまな「館内申請」が届きます。多くの現場では、いまだに紙の申請書をFAXやPDFメールでやり取りし、承認は電話と押印で回しているのが実情です。　

本記事では、この館内申請をフォーム化し、承認フローとして仕組み化する具体的な手順を、事業用不動産の現場運用に即して解説します。

結論：館内申請のワークフロー化は3つのステップで設計する

先に結論をまとめます。館内申請のワークフロー化は、次の3ステップで設計します。

1. フォーム設計 — 何を、どの入力形式で聞くかを決める。紙の申請書をそのまま移植しない

2. 承認フロー設計 — 誰が「承認」し、誰が「確認」するだけかを分ける。ステップは3つ以内に収める

3. 例外運用の設計 — ログインしない工事業者、当日の緊急申請、現場への紙持ち出し。ここを設計しないと必ず紙に戻る

多くのプロジェクトは1と2で終わってしまい、3を設計しないために定着しません。館内申請のワークフロー化が一般的な社内申請システムの導入と根本的に違うのは、次の3点にあります。

• 承認者が自社の社員ではない — オーナー、AM、PM、BM、警備会社、清掃会社、設備点検会社と、複数の会社の担当者が一つの承認フローに並ぶ

• 申請者も自社の社員ではない — テナントは入れ替わり、その先の工事業者は案件ごとに変わる

• 申請の記録が建物に紐づく資産である — 申請者が退去しても、工事履歴や火気使用の記録は残さなければならない

一般的な社内ワークフローツールは、この3点をいずれも想定していません。館内申請は社内の稟議ではなく、社外との業務フローです。この前提を最初に押さえておくことが、設計を誤らないための出発点になります。

そもそも館内申請とは何か

館内申請とは、ビルや商業施設に入居するテナントが、館内で通常と異なる作業・行為を行う際に、物件運営者（オーナー・PM会社・BM会社）へ事前に提出する申請の総称です。

代表的なものに次のようなものがあります。

• 工事作業申請 — 内装工事、原状回復、設備更新

• 搬入出申請 — 什器・機材の搬入搬出、引越

• 時間外作業申請 — 深夜・早朝・休日の作業

• 火気使用申請 — 溶接、はんだ付け、グラインダー作業

• 駐車場・荷捌き場利用申請

• 鍵貸出申請

• 看板・掲示物設置申請

• 共用部・イベントスペース利用申請

これらはいずれも、建物の安全・法令遵守・他テナントへの影響に直結します。単なる社内の稟議とは性質が異なり、記録として残すこと自体に意味があります。

なぜ紙とメールの運用は限界を迎えるのか

現場で実際に起きている問題は、おおむね次の5つに集約されます。

1. 申請書がメールボックスに埋もれる テナントごと、担当者ごとにメールが届き、どれが未処理かが一覧できません。「あの申請どうなった？」を探す時間が積み上がります。

2. 承認が誰で止まっているか分からない 紙を回覧している間、承認の現在地が見えません。催促は電話。承認者が出張中なら、そこで止まります。会社をまたぐ回覧であれば、なおさら追跡は困難です。

3. 記入漏れによる差し戻しが多い 自由フォーマットのWordやExcelでは、必須項目が埋まっていない申請が届きます。差し戻しのたびに1〜2日のロスが発生します。

4. 同じことを何度も聞かれる テナント側も「様式はどこですか」「いつまでに出せばいいですか」を毎回問い合わせます。これが管理員・PM担当者の電話対応工数を圧迫します。

5. 過去の申請を集計・検索できない 「昨年度、深夜作業は何件あったか」「このテナントの工事履歴を出して」に答えられません。テナントが退去していれば、なおさら辿れません。

これらはすべて、申請という業務が構造化されていないことに起因します。逆に言えば、構造化＝フォーム化と承認フローの整備によって解消できる問題です。

GoogleフォームやKintoneでは実現できないのか

館内申請のワークフロー化を検討すると、まず候補に挙がるのがGoogleフォームやMicrosoft Forms、あるいはkintoneのような汎用のノーコードツールです。

結論から言えば、要件によっては十分に機能します。特に、以下のようなケースでは汎用ツールで始めるのが合理的です。

• 自社が管理する物件が1〜2棟で、テナント数も限られる

• 申請の種類が3〜4種類に収まる

• 承認者が1〜2名で、承認ルートが固定

• まずは紙をやめることだけが目的

一方で、以下の要件が出てきた時点で、汎用ツールでは急速に運用が苦しくなります。

判断基準はシンプルです。「申請書を出す人と承認する人が、自社にログインアカウントを持つ社員だけで完結するか」——ここがNoであれば、汎用の社内申請システムの延長では設計しきれません。

ステップ1：フォーム設計 — 何を、どう聞くか

原則1：紙の申請書をそのままフォームにしない

最も多い失敗が、既存の紙様式をそのまま画面に写すことです。紙の様式には、紙だから必要だった項目が必ず含まれています。

• 押印欄（電子化すれば承認履歴が代替する）

• 受付番号の手書き欄（自動採番できる）

• 「該当するものに○」（選択形式で置き換えられる）

• 同じ情報の二重記入（申請者名を3箇所に書かせる等）

まず項目の棚卸しから始めてください。過去1年分の申請書を10通ほど並べ、「実際に埋まっている項目」「一度も使われていない項目」「後から電話で聞き直している項目」の3つに分類します。3つ目こそが、フォームに追加すべき項目です。

原則2：入力形式を正しく選ぶ

フォーム設計の質は、入力形式の選び方でほぼ決まります。すべてを自由記述にすると、集計も検索もできないデータが溜まるだけです。

事業用不動産の申請フォームで必要になる入力形式は、実務上おおむね次の12種類です。

特に表形式は館内申請で威力を発揮します。入館者名簿や車両ナンバーは、従来は別紙Excelで添付されていた情報です。これをフォーム内の表として受け取れば、警備室への共有や当日の照合がそのままデータで完結します。

また、選択式の項目には「その他（自由記入）」を必ず用意してください。選択肢に無い作業が発生したとき、逃げ道がないと申請者は電話に戻ります。

原則3：条件分岐は「フォームを分ける」で解く

「火気を使用する場合のみ追加項目を表示したい」——こうした条件分岐は、一つの巨大なフォームで実現しようとすると破綻します。

推奨は、申請種別ごとにフォームを分けるアプローチです。「工事作業申請」「搬入出申請」「時間外作業申請」をそれぞれ独立したフォームとして用意し、テナントには申請の入口で種別を選ばせます。

このほうが、

• 各フォームの項目数が10〜15に収まり、記入負荷が下がる

• 申請種別ごとに承認ルートを変えられる（後述）

• 種別ごとの件数集計がそのまま取れる

というメリットがあります。フォームの複製機能があれば、共通項目を持つ新様式は既存フォームを複製して差分だけ編集できます。

原則4：作業日時は本文ではなく専用の項目として持つ

館内申請が他の申請業務と決定的に違うのは、「いつ作業するか」という時間軸を必ず持つ点です。

作業日時を自由記述の本文に書かせてしまうと、

• 申請一覧を作業日順に並べられない

• 「今日の作業」を一覧できない

• カレンダーに載せられない

という致命的な制約が生まれます。作業日時は必ず、開始・終了を持つ独立した項目として設計してください。これにより、申請一覧の並び替え・絞り込み、当日の作業一覧、カレンダー表示がすべて自動で成立します。

現場の管理員が朝一番に見るのは「今日、この建物で何の作業が入っているか」です。ここが1画面で見られるかどうかが、ワークフロー化の体感価値を大きく左右します。

原則5：自由記述欄と添付を「逃げ道」として必ず残す

どれほど丁寧に設計しても、想定外の申請は必ず来ます。備考欄（自由記述＋ファイル添付）を用意しておけば、例外的な申請もフォーム経由で受けられます。

逃げ道がないフォームは、使われないフォームです。 逃げ道があれば、少なくとも申請はシステムに乗ります。乗りさえすれば、後から「この例外が多いから項目化しよう」という改善につながります。

参考：工事作業申請フォームの項目例

ステップ2：承認フロー設計 — 誰が何をするか

フォームができたら、次は承認フローです。ここでの設計判断が、リードタイムを決めます。

前提：館内申請の承認フローは、必ず複数の会社をまたぐ

一般的な社内ワークフローと最も異なるのがこの点です。一件の工事作業申請に関与する当事者を並べると、実際には次のようになります。

これがすべて別会社であることが、事業用不動産の標準的な体制です。ここを一つのワークフローに載せられるかどうかが、館内申請のシステム選定における最大の分岐点になります。

「承認」と「確認」を分ける

上の表を見れば分かるとおり、関与者はアクションが必要な承認者と内容を知っておくべき確認者の2種類に分かれます。

• 承認：この人が承認しないと次に進まない（例：BM会社の建物担当、PM会社の物件担当）

• 確認：内容を見るだけでよく、フローは止めない（例：警備会社、清掃会社、設備点検会社）

紙の回覧では、この2つが区別されていません。全員のハンコが必要になり、1社が不在なだけで止まります。承認ルートの設計時に、ノードごとに「承認を求める」のか「確認を求めるだけ」なのかを指定できることが必須要件です。

「本当に承認が必要なのは誰か」を洗い出すと、多くの現場で承認者は想定の半分以下になります。残りは確認で足ります。

さらに、承認ルート全体に対して「閲覧者」を別枠で設定できると運用が安定します。フローには介在しないが内容は把握しておきたいオーナー担当者や、AM会社の管理職といった立場の人がこれに当たります。

AND条件とOR条件を使い分ける

同じ承認ステップに複数人を置く場合、条件の設計が重要です。

• AND条件：全員の承認が必要。責任分界が明確な場合、あるいは法令・安全上の理由で複数者の確認が必須な場合に使う

• OR条件：誰か1人が承認すればよい。リードタイム短縮に最も効く

たとえば「PM担当者3名のうち、手が空いている誰かが承認すればよい」という運用はOR条件で設計します。担当者の休暇・出張でフローが止まる問題は、これで大半が解消します。原則として、承認は可能な限りOR条件で設計してください。

承認者は「個人」ではなく「グループ」で指定する

会社をまたぐ承認フローで最も効くのが、この設計です。

承認ノードに個人を指定すると、その人が異動・退職・休暇に入るたびに承認ルートを作り直す必要があります。BM会社の担当者が交代するたびに、全物件の全申請様式の承認ルートを修正する——これは現実的な運用ではありません。

そこで、「BM会社・設備担当グループ」「PM会社・物件担当グループ」「警備会社グループ」といったグループを作り、承認ノードにはグループを指定します。担当者の交代時は、グループのメンバーを入れ替えるだけで済み、承認ルート側は一切触りません。

グループはOR条件と組み合わせることで、「BM会社の設備担当グループの誰か1人が承認すれば次へ進む」という運用になります。会社単位・役割単位でグループを切っておくのが基本形です。

会社をまたぐなら、承認と同時に「見える範囲」を設計する

ここが見落とされやすく、かつセキュリティ上最も重要な論点です。

警備会社の担当者を承認フローに招くということは、その人にシステムのアカウントを渡すということです。このとき、警備会社の担当者がテナントの賃料情報や、他社とのやり取りまで見えてしまう設計では、そもそも運用に乗せられません。

必要なのは、機能カテゴリ単位での権限設定です。たとえば次のような設計になります。

「館内申請だけ閲覧できて、それ以外は一切見えない」というアカウントを発行できること。これが、複数社を一つのワークフローに載せるための前提条件です。汎用の社内ワークフローツールが館内申請に向かない最大の理由が、ここにあります。

承認ステップは3つ以内を目安にする

ステップ数はそのままリードタイムに比例します。4ステップの承認フローは、各ステップが半日で回っても2日かかります。会社をまたぐ場合、1ステップあたりの実所要時間はさらに伸びます。

紙の運用では「念のため」で承認者が積み上がっているケースが大半です。ワークフロー化のタイミングは、この棚卸しの好機です。判断基準は次の2つです。

• そのステップで否認された実績が過去にあるか（なければ確認に降格できる）

• そのステップの承認者が、申請内容を判断できる知識を持っているか（持っていなければ形式的な承認）

差し戻しは「誰に戻すか」を指定できる設計にする

差し戻しの設計は見落とされがちですが、会社をまたぐフローでは特に重要です。

単純な差し戻しは、申請者（テナント）まで一気に戻ります。しかし実際には、「PM会社の承認者が、BM会社の承認者に技術的な確認をしたい」というケースが頻繁にあります。ここでテナントまで戻してしまうと、テナントと工事業者に無用な手戻りが発生します。

差し戻し先を指定できる設計であれば、承認状態を必要なステップまで巻き戻すだけで済みます。テナントを巻き込まずに、物件運営者側だけで調整が完結します。

承認済み申請の修正・取り下げのルールを決めておく

「承認したが、作業日が変更になった」「工事自体が中止になった」——これは必ず起きます。

設計の選択肢は2つです。

1. 軽微な修正は物件運営者側が直接編集する — 日付や担当者名の変更のように、承認判断に影響しない修正。差し戻しの手間を省ける

2. 内容に関わる修正は差し戻してテナントに修正させる — 作業内容や範囲の変更。承認をやり直すべきケース

この線引きを事前にルール化しておかないと、「とりあえず差し戻し」が常態化してリードタイムが悪化します。

ステップ3：例外運用の設計 — 定着の成否はここで決まる

ここが、館内申請のワークフロー化が一般的な社内申請システム導入と最も異なる部分であり、最も多くのプロジェクトが失敗する箇所です。

課題1：ログインアカウントを持たない工事業者からの申請

館内申請の実質的な提出者は、テナント企業の総務担当者ではなく、テナントが発注した工事業者であることが少なくありません。この業者にシステムのアカウントを配るのは現実的ではありません。工事のたびに業者は変わり、同じ業者が二度と来ないことも普通です。

設計の選択肢は3つです。

1. ゲスト申請 — アカウント登録なしで、その申請1件のためだけに申請できる導線を用意する

2. 代筆申請 — テナント担当者や物件運営者が、業者に代わって申請を入力する

3. 物件共通コードによる申請 — 物件ごとの共通コードを業者に伝え、そのコード経由で申請させる

このうち1のゲスト申請には、押さえるべき設計要件が3つあります。

要件A：ただの公開URLにしない 「誰でも開けるフォーム」にしてしまうと、申請者が誰なのか、どのテナントの案件なのかを特定できません。テナントごとに固有の申請コードを発行し、業者にはそのコードを伝える設計にすれば、申請が自動的にテナントへ紐づきます。

要件B：メールアドレスを認証する 会社名・氏名・メールアドレスを入力させ、そのアドレスに認証を通してから申請本体に進ませます。これにより、いたずら申請や誤送信を防ぎつつ、その後の差し戻し連絡先も確保できます。

要件C：テナントの承認を挟めるようにする これが最も重要です。工事業者が直接申請できるということは、テナントが把握していない工事の申請が物件運営者に届く可能性を意味します。

これを防ぐには、ゲスト申請に対してテナント承認を必須にする設定を用意します。

運用は次の3段階になります。

1. 工事業者（ゲスト）が申請する

2. テナントが承認する（自社が発注した工事であることを確認）

3. 物件運営者の承認フローへ進む（BM → PM → …）

この二段構えにより、「テナントの与り知らぬ工事」が館内で行われるリスクを構造的に排除できます。物件によって運用方針は異なるため、テナント承認の要否は物件単位で切り替えられることが望ましい設計です。

なお、ゲスト（業者）とのやり取りは、物件運営者向けとテナント向けで別々の連絡経路を持てると運用が安定します。「物件運営者から業者への差し戻し指示」と「テナントから業者への社内確認」が混ざらないためです。

また、申請フォームごとに「誰に公開するか」を制御できることも必要です。全フォームを無条件に外部公開すると、本来テナントしか使わない申請様式まで外部から見えてしまいます。

• このフォームは代筆申請時だけ表示する

• このフォームは物件共通コード経由の申請時だけ表示する

• このフォームはテナントの公開範囲に合わせる

といった単位で制御できる設計にしておくと、運用方針の変更にも耐えられます。

課題2：テナントが入れ替わっても運用が破綻しないようにする

ビル管理オペレーションの本質的な難しさは、関係者が固定されていないことにあります。

• テナントは契約満了・移転で入れ替わる

• 同じテナントでも、総務担当者は数年で交代する

• 工事業者は案件ごとに変わる

一般的な社内申請システムは「社員名簿がある程度固定されている」ことを前提に設計されています。館内申請は、この前提が成り立ちません。

ここで設計上の要件になるのが、次の2点です。

要件A：退去テナントは「削除」ではなく「アーカイブ」する

退去したテナントのデータを削除すると、そのテナントが過去に提出した申請も辿れなくなります。しかし、

• 「この区画では過去にどんな工事が行われたか」（原状回復・再工事の判断材料）

• 「この設備にいつ誰が手を入れたか」（不具合発生時の調査）

• 「火気使用・深夜作業の記録」（消防・行政対応）

これらはテナントではなく建物に紐づく資産です。退去とともに消えてよい情報ではありません。退去は削除ではなくアーカイブとして扱い、申請履歴を建物側に残す設計が必要です。

要件B：担当者が交代しても、当時の申請者・承認者が分かる

「3年前のこの工事、誰が承認したのか」を追えることは、トラブル対応や引き継ぎの場面で決定的に重要です。担当者が退職・異動してアカウントが無効化された後も、当時の申請者・承認者の記録は残り続ける必要があります。

あわせて、テナントがアーカイブされた時点で在籍していた担当者の一覧を保持しておけば、退去後の問い合わせにも対応できます。

この2要件は、汎用ツールで自作するのが非常に難しい部分です。ユーザーを消せば履歴が壊れ、ユーザーを残せば現在の一覧が汚れる——このトレードオフを、「現在の運用に出す一覧」と「履歴として残す記録」を分離することで解いている必要があります。

課題3：当日・緊急の申請をどう扱うか

「今日、急な漏水対応で業者を入れたい」——ワークフローは原則として事前申請ですが、緊急対応は必ず発生します。

ここでシステムに例外を作らないと、緊急案件だけ電話に戻り、やがて通常案件も電話に戻ります。

現実的な設計は、緊急用の申請フォームを別途用意し、承認ステップを1つに絞ることです。「事後でも必ず申請は上げる」というルールにすれば、記録は残ります。

なお、逆に「作業日のN営業日前までしか受け付けない」というリードタイム制限を設けたい場合もあります。この場合も、緊急時の例外導線をセットで設計してください。

課題4：現場に紙で持ち出す必要がある

デジタル化しても、紙が完全になくなるわけではありません。

• 工事業者が作業当日に申請書の控えを現場に持参する

• 警備員が入館時に申請書と入館者を照合する

• 消防・行政の立入検査時に記録を提示する

つまり、印刷を前提とした設計が必要です。ここで軽視されがちなのが印刷レイアウトです。コメントのやり取りが増えるたびに申請書が3ページ、4ページに分かれてしまうと、現場では使われません。

• 基本的な申請書が1枚に収まること

• コメントを印刷に含めるか選べること

• 印刷時に物件名・テナント名が明記されること（複数物件を扱う警備室では必須）

この3点を確認してください。

課題5：通知が多すぎて誰も見なくなる

ワークフロー化の副作用として最も多いのが、通知過多です。

承認フローに5社が関与し、1件の申請につき提出・承認・コメント・完了で通知が飛ぶと、1日20件の申請で100通のメールになります。こうなると全員が通知を無視し始め、結局「電話で言ってください」に戻ります。

設計時に必ず決めるべきことは次の2つです。

• 確認者・閲覧者への通知を絞る — アクションが不要な人に、逐一の通知は不要

• 自分のアクションが必要な申請だけを抽出できる画面を用意する — 通知ではなく「要アクション一覧」で運用する

理想は、メールを見なくてもダッシュボードだけで業務が回る状態です。メール通知は補助手段と位置づけてください。

課題6：申請を番号で特定できるようにする

電話やチャットで「先週出した搬入の申請なんですが」と言われたとき、特定に時間がかかります。会社をまたぐやり取りでは、共通の識別子がないと会話が成立しません。

申請に管理番号を自動採番し、テナント・業者・物件運営者の全員がその番号で会話できる状態にしてください。印刷物にも番号が入っていれば、現場での照合も番号一つで済みます。

ワークフロー化の効果をどう測るか

「なんとなく楽になった」で終わらせず、数値で効果を確認します。館内申請のワークフロー化で追うべき指標は3つです。

1. 申請から承認完了までのリードタイム（時間） 最も重要な指標です。紙・メール運用では3〜5営業日かかっていた申請が、承認ステップの棚卸しとOR条件の活用で1営業日以内に収まるケースは珍しくありません。会社をまたぐフローほど、この改善幅は大きくなります。

2. 差し戻し率（差し戻し件数 ÷ 総申請件数） フォーム設計の品質を直接表します。差し戻しが多い項目を特定し、説明文の追加や入力形式の変更で改善します。各項目に説明文を添えられるフォームであれば、記入ミスは大きく減らせます。

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

これらを測るには、申請データをCSVで出力できることが前提になります。申請種別・期間・ステータスで絞り込んでCSV出力できれば、月次の集計はExcelで完結します。導入前にこの機能の有無を必ず確認してください。

ラクビルTeXでの実装例

ここまで述べた要件を、事業用不動産に特化したプラットフォームがどう解いているか、ラクビルTeXを例に具体的に示します。

複数社が並ぶ承認フローを、権限分離とセットで構成する

ラクビルTeXの承認ルートは、ノードごとに「ユーザー」または「グループ」を指定し、それぞれに「承認を求める」「確認を求める」のいずれかを設定します。ノードのまとまりにはAND条件／OR条件を指定できるため、「BM会社の設備担当グループの誰か1人」といった運用がそのまま表現できます。承認ルート全体に対して、フローには介在しない閲覧者・閲覧グループを別枠で設定することも可能です。

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

オーナー・AM・PM・BM・警備・清掃・設備点検——別会社の担当者が一つの承認フローに並ぶという、事業用不動産では避けられない構造に、そのまま対応します。

入れ替わり続けるテナントを前提に設計されている

テナントには「表示」「非表示」「アーカイブ」の状態があり、退去は削除ではなくアーカイブとして扱われます。過去の申請履歴は建物側に残り、退去後も工事履歴・火気使用記録を辿れます。

さらに、テナントがアーカイブされた時点で在籍していた担当者の一覧を保持しており、無効化されたユーザーを含めた担当者情報も参照できます。「3年前のこの工事は誰が申請し、誰が承認したのか」に、担当者交代後でも答えられます。

テナント側の担当者交代、物件運営者側の担当者交代のいずれについても、承認ルートをグループで組んでおけばメンバーの入れ替えだけで対応できます。

ゲスト申請 — 外部のワンタイムユーザーが、アカウントなしで申請できる

ラクビルTeXのゲスト申請は、アカウントを持たない外部の工事業者が、その申請1件のためだけに申請を行える仕組みです。

業者は、会社名・氏名・メールアドレスと、テナントごとに発行された申請コードを入力して申請を開始します。入力されたメールアドレスには認証が通るため、匿名の申請にはなりません。申請コードによって、その申請がどのテナントに紐づくものかも自動的に確定します。

加えて、物件単位でゲスト申請にテナント承認を必須とする設定が可能です。これをONにすると、工事業者からの申請はまずテナントの承認を経てから、物件運営者の承認フローに進みます。テナントが把握していない工事の申請が館内で通ってしまうリスクを、運用ルールではなく仕組みで防げます。

やり取りについても、ゲストと物件運営者、ゲストとテナントで別々の連絡経路を持ちます。物件運営者から業者への差し戻し指示と、テナントから業者への社内確認が混ざりません。

申請フォームごとの公開範囲も、「テナントの代筆申請時に公開」「物件共通コードで申請時に公開」といった単位で制御できます。テナント専用の様式が外部から見えてしまうことはありません。

よくある質問

Q. 館内申請のワークフロー化には、どのくらいの期間がかかりますか？

A. 申請様式が5種類程度であれば、フォーム設計に2〜3週間、承認フロー設計に1〜2週間、テナントへの周知と並行運用に1ヶ月程度が目安です。すべての様式を一度に移行せず、件数の多い1〜2様式から始めることを推奨します。

Q. オーナー・PM・BM・警備会社など、複数の会社が承認に関わります。1つのシステムで回せますか？

A. 回せます。ただし2つの条件を満たすツールを選ぶ必要があります。①承認ノードごとに「承認を求める人」と「確認だけしてもらう人」を分けられること、②会社ごとに、機能カテゴリ単位で「権限なし／閲覧者／編集者」を設定できること。②が無いと、警備会社の担当者にテナント情報まで見えてしまい、そもそも運用に乗りません。汎用の社内ワークフローツールは②を持たないことが多いため、事前確認が必須です。

Q. 承認者の会社の担当者が交代するたびに、承認ルートを作り直す必要がありますか？

A. 承認ノードを個人ではなくグループで指定できるツールであれば不要です。「BM会社・設備担当グループ」のようにグループを作り、担当者交代時はグループのメンバーを入れ替えるだけで済みます。承認ルート側は一切触りません。物件数・様式数が多いほど、この差は大きくなります。

Q. テナントが退去したら、そのテナントの申請履歴は消えてしまいますか？

A. 消えてはいけません。区画の工事履歴、設備への手入れ記録、火気使用・深夜作業の記録は、テナントではなく建物に紐づく資産です。退去テナントを「削除」ではなく「アーカイブ」として扱い、申請履歴を建物側に残す設計になっているかを、導入前に必ず確認してください。

Q. アカウントを持たない工事業者に、どうやって申請させますか？

A. 主な方法は3つです。①ゲスト申請（アカウント登録なしで、その1件のためだけに申請できる導線）、②代筆申請（テナントや物件運営者が代わりに入力）、③物件共通コードによる申請。①を採用する場合は、単なる公開URLにせず、テナント別の申請コードとメールアドレス認証を組み合わせてください。誰の、どのテナントの案件かが特定できない申請は、結局電話での確認が必要になります。

Q. 工事業者が直接申請できると、テナントが知らない工事が通ってしまいませんか？

A. その懸念は正当です。対策は、ゲスト申請にテナント承認を挟むことです。「業者が申請 → テナントが承認 → 物件運営者の承認フロー」という二段構えにすれば、テナントの与り知らぬ工事が通ることを仕組みとして防げます。物件によって運用方針が異なるため、この要否を物件単位で切り替えられるかも確認しておくとよいでしょう。

Q. テナントが使ってくれるか不安です。

A. テナント側にとっての利点を明示することが重要です。具体的には、①24時間いつでも提出できる、②承認状況が自分で確認できる、③過去の申請を複製して再利用できる、の3点です。特に③は、定期的に同種の申請を出すテナントに強く響きます。並行運用期間を設け、紙も受け付けながら移行するのが現実的です。

Q. 紙の申請書は完全になくせますか？

A. 完全になくすことは推奨しません。工事業者が現場に持参する控え、警備室での照合、行政検査への対応など、紙が必要な場面は残ります。目的は「紙をなくすこと」ではなく「申請データを構造化すること」です。データさえ構造化されていれば、紙は必要なときに印刷すればよいだけです。

Q. 承認者が出張や休暇で不在のときはどうしますか？

A. 設計上の解は2つです。①承認ステップをOR条件にして、複数名のうち誰かが承認すれば進むようにする。②承認フローに含まれる担当者を、個人ではなくグループで指定する。両方を組み合わせるのが最も安定します。

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

A. 物件ごとに申請様式や承認体制が異なるのが通常なので、フォームと承認ルートは物件単位で持つのが自然です。一方で、物件をまたいで「自分のアクションが必要な申請」を一覧できる画面は必須です。担当物件が10棟あるPM担当者が、毎朝10画面を確認する運用は成立しません。

Q. GoogleフォームやMicrosoft Formsから始めても良いですか？

A. 1〜2棟・申請様式3種類程度・承認者が自社の1〜2名、という範囲であれば有効な第一歩です。ただし、外部業者からの申請、複数社にまたがる承認、テナントの入れ替わり、印刷を前提とした運用が要件に入った時点で作り込みの限界が来ます。移行を見据えて、フォームの項目定義だけは最初からきちんと設計しておくことをお勧めします。項目設計は、どのツールに移っても資産として残ります。

Q. 承認フローは何ステップまでが適正ですか？

A. 3ステップ以内を目安としてください。判断基準は「そのステップで過去に否認された実績があるか」です。否認実績のないステップは、承認ではなく確認に降格できる可能性が高いです。会社をまたぐフローでは1ステップあたりの実所要時間が伸びるため、この基準はより重要になります。

Q. 会議室や共用設備の予約も同じ仕組みで管理できますか？

A. 可能です。予約を「承認制」に設定すれば、テナントからの予約が予約リクエストとして申請され、物件運営者の承認をもって確定する運用になります。申請と予約を別々のツールで管理するより、テナント側の入口が一本化される利点があります。

まとめ

館内申請のワークフロー化は、以下の順序で設計します。

1. フォーム設計 — 紙様式を棚卸しし、入力形式を正しく選び、申請種別ごとにフォームを分ける。作業日時は必ず専用項目として持たせる

2. 承認フロー設計 — 「承認」と「確認」を分け、承認者はグループで指定し、OR条件を活用してステップは3つ以内。会社ごとの権限分離をセットで設計する

3. 例外運用の設計 — 外部業者のゲスト申請導線、テナント入れ替わりへの対応、緊急申請、印刷、通知量、管理番号。ここが定着を左右する

そして最も重要な視点は、館内申請が社内ワークフローではなく、複数の会社と外部の当事者をまたぐ業務フローであるという点です。

• 承認者は、オーナー・AM・PM・BM・警備・清掃・設備点検と複数の会社にまたがる

• 申請者は、入れ替わり続けるテナントと、案件ごとに変わる工事業者である

• 記録は、申請者が去った後も建物に紐づく資産として残す必要がある

この3つの前提に立てば、一般的な社内申請システムの延長では設計しきれない理由が見えてきます。まずは件数の多い1様式から着手し、リードタイム・差し戻し率・問い合わせ件数の3指標で効果を確認しながら、対象様式を広げていくのが確実な進め方です。

ラクビルTeXについて

ラクビルTeXは、オフィスビル・商業施設・物流倉庫など事業用不動産の運営者とテナントをつなぐWebプラットフォームです。本記事で解説した館内申請のフォーム化・承認フロー化に加え、テナント向け通知、館内ルール掲示、問い合わせ管理、会議室・共用設備の予約管理、入退館管理などを一つのプラットフォームで提供しています。

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

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

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