入退室管理システムの発注は、要件整理、RFP作成、提案比較の順に進めると、現場に合う構成と見積もりにつながります。
発注側がRFP（提案依頼書）や要件定義書に書く内容は、総コスト、認証とエリア設計、外部連携の責任分界、非機能要件とSLAの4つに分けられます。全体像は、入退室管理システムの完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・入退室管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ハードウェアと工事費を含む総コストの要件化
ソフトウェアの月額料金だけを比べても、実際の導入費用は見えてきません。そこでRFPでは、ハードと工事を含む総コスト（TCO）を要件に含めます。
リサーチでは、連携配線や設置工事費への言及が手薄だと指摘されています。同様に、タブレットの盗難防止や常時給電の設備投資も手薄な点とされています。これらを明記しないと、見積もりの前提がばらつき、後から追加費用が発生します。
電気錠・ゲート・配線工事の範囲の明示
RFPでは、対象のドアや出入口を一つずつ挙げ、必要な機器と工事の範囲を書き込みます。錠の種類や工事の内容はドアごとに違うため、次の4項目をそろえて書いておくと、ベンダーが同じ前提で見積もれます。
- 錠の種類：電気錠、電磁ロック、サムターン後付け型のどれか
- 認証端末：カードリーダーや顔認証端末を置く場所
- 設備と配線：自動ドアやフラッパーゲートの有無と、接続工事の内容
- 設置条件：既存ドアへの後付けか、新設か
図面や現地写真を添付して設置場所と台数を示すと、ベンダーはより正確に見積もれます。
給電方式は常時給電か電池式か、通信環境は有線か無線かも明記します。特に常時給電は設備投資に関わるため、見積もりの差が出やすい点です。
無人施設やタブレットを置く受付では、盗難防止策と停電・通信障害時の動作も必要です。
前提を揃えておけば、見積もりを比べられます。ソフトの機能だけでなく物理設備も要件に含めることが、入退室管理の発注の第一歩です。
補助金の活用と、初期・ランニングの内訳の提示
総コストを把握するため、ベンダーには初期費用とランニング費用を分けた見積もりを求めます。見積もりは、次の項目に分けて示してもらいます。
- 初期費用：機器代、工事費、初期設定費
- ランニング費用：クラウド利用料、保守費、カード再発行などの変動費
- 補助金：対象構成か、申請サポートがあるか
内訳があれば、数年単位のTCOで比べられます。
月額が安くても保守費が高く、総額では割高になる場合があります。そのため、費用の内訳を必須要件としてRFPに書き込みます。
リサーチによれば、IT導入補助金（デジタル化・AI導入補助金）では、対象経費の最大2分の1から5分の4の補助を受けられるケースがあります。補助金を使えば初期費用を圧縮できる場合があり、ハード費用が大きい入退室管理では、対象になるかどうかでTCOが変わります。
補助金の活用可否も要件に含め、RFPで対象となる構成か、申請支援があるかを確かめます。そのうえで、補助金を含めた実質負担額で比べることが大切です。
各社で前提が異なると、金額だけでは比べられません。そこで、対象ドア数や想定利用者数、導入スケジュールを共通条件として示し、既存設備を流用できるかどうかも併せて伝えます。
共通条件に沿った内訳付きの見積もりを求めると、比較の精度が高まります。
また、追加開発が発生した場合の単価や、将来の拡張費用も提案に含めてもらいます。これにより、導入後の予算計画を立てやすくなります。
認証方式とエリア設計の要件定義
機能要件の中心は、認証方式とエリア設計です。
エリアごとに認証方式と利用者の権限を定めれば、過不足のない構成を提案してもらえます。
曖昧な要件のままだと、全ドアに最高強度の認証を付けるような過剰な見積もりや、重要エリアの保護が手薄な構成になるおそれがあります。そのため、重要度に応じて要件を書き分けることが、コストと安全のバランスを取るうえで欠かせません。
エリアごとのセキュリティレベルの定義
建物内をセキュリティレベルで分け、レベルごとに適した認証方式を割り当てます。たとえば、次のように整理します。
- 一般エリア：ICカードで入るエントランス
- 執務エリア：社員のみが入れる区画
- 書類保管室：特定部署のみが入れる区画
- 機密エリア：サーバルームでカードと顔認証の二要素認証
こうして段階ごとに方式を定めておくと、各エリアの重要度に合った構成を見積もれます。
権限の付与と剥奪について、誰が行い、誰が承認するかも決めておきます。入社、退社、異動の際の手順に加え、来訪者や一時利用者への権限発行の流れも決めます。
また、火災時に避難経路を確保するため、一斉解錠も要件に含めます。火災報知器と連動して自動解錠する仕組みは人命に関わるので、RFPに明記します。
エリア設計と権限の流れを文書にしておくことが、現場で破綻しないシステムの土台になります。
現場の動線とAsIs業務の要件への反映
認証を加えても業務が滞らないかは、場所や時間帯ごとの出入りを見なければ判断できません。そこで、現場の日々の出入り（AsIs）のうち、次のような動線を確かめます。
- 搬入口：両手がふさがる状況
- 受付：来客が頻繁に出入りする動線
- 清掃スタッフ：深夜に出入りする動線
動線の実態（AsIs）を要件に反映しないと、導入後に現場が認証を迂回するおそれがあります。
現場の実態を洗い出してToBeを設計できるかどうかが、システムの定着を左右します。
riplaは、フルスクラッチ受託と国内開発の立場から、要件定義の前に現場の動線をヒアリングします。認証を必須にするエリアと、利便性を優先するエリアを分けたうえで、ToBeの運用を設計します。
RFPには、現場ヒアリングと業務フロー設計を提案に含めるよう求めます。機器仕様だけでなく業務フローまで要件に含めることで、現場で迂回されにくいシステムにつながります。
外部システム連携と責任分界の条項
予約やPMSなど外部システムと連携する場合、RFPで連携の責任分界を詰めます。受付、勤怠、防犯カメラを含む複数システムの障害原因を切り分けられないと、対応が宙に浮いてしまうためです。
リサーチでは、高度なAPI連携の保守リスクと責任分界が、競合解説で深掘りの足りない論点とされています。そのため、原因の切り分けと保守体制は、契約で裏づけておく必要があります。
連携先APIと同期仕様のRFPへの明記
連携先ごとに、相手のシステム名とデータの流れる方向を記載します。さらに、同期のタイミングと連携する項目も書き込みます。予約システムと連携する場合は、次の処理も定義します。
- 予約確定時：解錠権限の発行
- 予約終了時：解錠権限の失効
- 同期方式：リアルタイムとバッチのどちらか
API仕様書がある場合は添付します。ない場合は、連携先APIの調査を提案に含めるよう要件に書きます。
連携が複雑になるほど、想定外の挙動が起きるリスクが高まります。また、仕様変更にどう追従するか、一時的に連携が途切れたときの解錠動作も定めておきます。
障害時に扉を開けるフェイルセーフとするか、閉じるフェイルセキュアとするかも決めます。
曖昧なまま開発すると、リリース後に「予約したのに解錠できない」「退会者の権限が残っている」といった問題が起きます。そのため、正常系だけでなく異常系も要件に含めることが欠かせません。
トラブル時の責任分界と一次対応窓口の決定
連携障害では、入退室側と連携先がそれぞれ原因は相手側にあると主張し、発注側が板挟みになることがあります。復旧の遅れを防ぐため、RFPには次の事項を含めます。
- 一次窓口：トラブル時に最初に受けるのはどちらか
- 原因切り分け：手順と責任範囲
- 復旧目標：障害から元に戻すまでの目標時間
入退室側のベンダーが一次窓口となり、連携先との切り分けまで担う体制が理想です。
riplaは、フルスクラッチ受託の立場から、責任分界を契約時に明確にし、複数システムが絡む場合も一次窓口を担う体制を重視しています。
入退室管理は、解錠できないと業務や事業が止まるため、高い可用性が求められます。誰がどう対応するかを要件と契約で定めることが、発注側のリスクを減らします。
責任分界は、RFPの中でも提案に差が出る項目の一つです。
非機能要件とSLA・保守体制の定義
機能要件と並んで、非機能要件とSLA（サービス品質保証）も欠かせません。入退室管理は、解錠できないと人が建物に入れず、停止すれば業務も完全に止まってしまいます。
RFPでは、稼働率、障害対応、データ保全を定義します。機能の多さだけでなく、停止を防ぎ、障害時に早く復旧できることが重要です。
稼働率・障害対応・停電時の動作の要件化
SLAには、稼働率の目標値、障害連絡から復旧着手までの時間、復旧目標を定めます。発注側の運用時間に合わせて、必要なサポート時間帯を要件として明示します。
必要なサポート体制は、施設の営業時間によって変わります。たとえば、次の条件を確認します。
- 稼働時間：24時間営業の無人施設や宿泊施設の有無
- 対応時間帯：深夜・休日のサポートが必要かどうか
平日日中だけの対応では、深夜に解錠できなくなった際に宿泊客が締め出されても対応できません。
また、停電や通信障害、機器故障のときにどう動くかも決めておきます。停電時に開くフェイルセーフにするか、閉じるフェイルセキュアにするかは、エリアの性質に応じて設計します。
避難経路は開く側に、機密エリアは閉じる側にするのが基本です。要件に書かなければベンダー任せになり、非常時に想定と逆の動きをする危険があります。非常時の動作は人命にも関わるため、RFPで定義します。
多言語・高齢者UDなどユーザビリティ要件
ユーザビリティ（使いやすさ）も非機能要件に含まれます。リサーチでは、多言語UI、海外決済連携、高齢者向けのユニバーサルデザイン（UD）が、競合解説で深掘り不足とされています。
施設の利用者に合わせて、RFPには次の内容を明記します。
- 対応言語：解錠アプリや案内の言語
- 利用者層：想定する利用者と操作習熟度
- 使いやすさ：アクセシビリティの基準
インバウンド客が多い宿泊施設では、英語・中国語・韓国語などへの対応が求められます。一方、デジタルに不慣れな人が多い施設では、操作を簡単にし、文字を大きくするUDが重要です。
ユーザビリティは品質の問題で、明記しないと見落とされがちです。なお、汎用のオフィス向けシステムでは、多言語やUDが標準では十分でない場合もあります。
業態によっては作り込みが必要になります。riplaは、フルスクラッチ受託と国内開発の立場から、非機能要件を含む要件定義を支援し、利用者が無理なく使えるシステムを重視しています。
機能、非機能、SLAをそろえたRFPは、比較しやすく精度の高い提案につながります。
個人情報・生体情報の取り扱いとログ保全の要件
入退室管理は、誰がいつどこに出入りしたかを記録します。そのため、個人情報保護の観点から、慎重な設計が必要になります。
顔・指紋・静脈などの生体認証を使う場合は、次の取り扱いを決めておきます。
- 情報の管理：生体情報の取得、保存、廃棄の方法
- 本人への対応：同意の取り方
- 情報の保護：データの暗号化
生体情報は要配慮個人情報に近い性質を持つため、扱いが曖昧だと、導入後にコンプライアンス上の問題が表面化します。
入退室ログの保存期間と保全方法も、文書で明確にしておきます。監査などに備えて何年分を保持するか、改ざんをどう防ぐかを決めます。さらに、退職者や退去者のデータをいつどう削除するかも決めておきます。
クラウド型の場合は、データを保管するサーバーの場所と、ISMSやプライバシーマークなどの取得状況も確認します。
riplaは、フルスクラッチ受託と国内開発の立場から、個人情報・生体情報の適切な扱いとログ保全を含む要件定義を支援しています。
情報を守る仕組みが別の情報リスクを生まないよう、データの扱いまで要件に含めます。
まとめ
RFPで扱うのは、ハードと工事を含む総コストと、認証・エリア設計です。連携の責任分界や非機能要件、SLAまで含めます。
機器と工事の範囲は図面で示し、補助金を含めた実質負担で比べます。現場の動線や非常時の動作、利用者の使いやすさも、要件に含めます。
連携トラブルに備えて、一次窓口を契約で定めておくことも欠かせません。要件を具体化しておけば、導入後の追加費用やトラブルを防ぎやすくなり、比較可能で精度の高い提案を得られます。
RFPには、機器仕様だけでなく、現場業務の流れと非常時の動作も書き込みます。さらに、ハードを含む総コストや連携の責任分界、多言語UDといった論点も含めます。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからToBeの設計、ハードと連携を含む要件定義まで一貫して支援します。要件項目の全体像と費用感は、完全ガイドで確認できます。
▼全体ガイドの記事
・入退室管理システムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。