2026.10.19 業務システム

入退室管理システムのクラウド型：オンプレミスとの違いと通信断・ログ分析で選ぶ基準

クラウド型の入退室管理システムは、扉の認証端末をインターネット経由で管理画面につなぎ、権限の発行と入退室履歴の保管をベンダーのクラウドに預ける方式です。サーバーを自社で持たずに済み、複数拠点の扉を1つの画面で扱えるのが利点ですが、選定で差が出るのはその先にある「回線が切れたら扉と履歴はどうなるか」「集まったログを何に使えるか」「ログを社外に置いてよいか」の3点です。この記事では、オンプレミス型との構成の違いを整理したうえで、通信断のときの公式な動作仕様、遠隔管理が効く業務と効かない業務、ログの可視化とデータ分析の前提、個人情報保護法上の確認事項、オンプレミスを残す条件と移行の順序までを、判断できる形でまとめます。

まとめ：入退室管理システムはクラウド型を基本に通信断と保管先で例外を決める

新規導入や多拠点の運用なら、クラウド型を第一候補にします。権限の発行と失効を拠点に出向かずに済ませられる点が、オンプレミス型との最大の差です。
通信が切れても、登録済みの暗証番号やカードは端末側の記憶で使える製品が一般的です。ただし通信断の間に発行・削除した権限は端末に届かないため、退職者の失効を即時に効かせたい区画では回線の冗長化まで含めて設計します。
ログの可視化は管理画面の標準機能で足ります。勤怠や在館管理と突き合わせるデータ分析は、APIで履歴を取り出せる製品を選んだうえで、取り込みの仕組みを別に用意する前提で考えます。
入退室ログは従業員の個人データです。クラウド事業者がそのデータを取り扱う契約かどうかで、委託先としての監督義務の有無が分かれます。
閉域網の中にある区画、常時オンラインを保証できない現場、ログを社外に置けない規程がある組織では、オンプレミス型を残します。全面移行でなく区画ごとの併存も現実的な答えです。

クラウド型入退室管理システムの構成とオンプレミス型との違いが出る場所

入退室管理システムの基本構成（電気錠・認証端末・制御装置・管理サーバー）と認証方式の種類は、入退室管理システムとは？認証方式の種類と選び方・システム連携の判断【情シス向け】で整理しています。ここでは、クラウド型にしたとき何がどこへ移るのかに絞って見ていきます。

端末・中継器・クラウドの3層で解錠判定がどこで行われるかという構成の違い

クラウド型は、扉側の認証端末や錠、端末をインターネットにつなぐ中継器（ゲートウェイ）、権限と履歴を管理するクラウドの3層でできています。解錠するかどうかの判定は、端末が記憶している権限の写しで行うのが一般的です。クラウドは権限の原本を持ち、変更を端末へ配り、端末から上がってくる履歴を受け取る役割を担います。

オンプレミス型では、この原本と履歴の保管を社内の管理サーバーと制御装置が担います。違いが出るのは「判定の場所」ではなく「原本と履歴がどこにあり、誰が保守するか」という点です。この点を押さえると、通信断や情報管理の論点が整理しやすくなります。

クラウド型とオンプレミス型の違いを権限反映・保守・拡張など5観点で比較

定義ハブで扱った費用と規模の比較に、運用で差が出る観点を加えて並べます。

観点	クラウド型	オンプレミス型
権限の反映	管理画面から全拠点へ配信	拠点ごとのサーバーで設定
通信断の影響	新規の発行と削除が届かない	社内網が生きていれば影響なし
サーバー保守	ベンダーが担う	自社または保守会社が担う
扉の追加	端末を足して登録する	制御装置の容量確認が要る
ログの保管先	ベンダーのクラウド	自社内に閉じられる

表のうち、導入後に問題になりやすいのは2行目です。クラウド型は便利さと引き換えに、回線の状態が権限の反映速度を左右します。次の章で確かめるのは、この点に関する公式の仕様です。一般的なクラウドとオンプレミスの比較はオンプレミスとクラウドの違い（コスト・セキュリティ・拡張性の比較）にまとめています。

通信が途切れたときにクラウド型の入退室管理システムが扉をどう扱うか

クラウド型の比較記事の多くは、通信環境が悪いと遠隔操作ができない、と一言触れるだけで終わっています。実際の動作は製品が公開しているFAQや開発者向け資料に書かれており、そこまで読むと設計で手当てすべき範囲がはっきりします。

登録済みの暗証番号は使え新規の発行は届かないという公式FAQの動作

構造計画研究所のRemoteLOCKは、公式サイトのよくあるご質問で、Wi-Fiが切れてもすでに認証されている暗証番号はそのまま使えると説明しています。一方で、切断中に発行した暗証番号や設定は次にWi-Fiへつながるまで本体に反映されず、一定時間切断した場合は現地での再設定が必要になる場合があるとも明記されています（2026年10月時点の掲載内容）。

この仕様が意味するのは、通信断の間は「開けられない」事故より「止めたはずの権限が生きている」事故のほうが起きやすいという点です。退職者のカードや外部業者の暗証番号を当日中に確実に失効させたい区画では、回線を2系統にする、失効の操作後に管理画面で端末への反映状態を確認する、といった運用を最初から決めておきます。

通信断の間の入退室履歴は端末に残り、復旧後に送られる同期の仕組み

履歴の保存と反映についても、基本となる考え方は同じです。RemoteLOCKのFAQは、暗証番号の新規発行や履歴の反映は通信の復旧後に行われると説明しています。PhotosynthのAkerun Developersも、Akerun Proの履歴はいったん本体に保存されてからサーバーへアップロードされるため、漏れなく取得したい場合は日時ではなくアップロード順のidで並べて取得するよう案内しています。

管理画面に表示される「今日の入室者」は、通信断の間の分が欠けた状態で見えている可能性がある、ということです。在館者の確認や勤怠の締めに履歴を使う場合は、締めの時刻を通信の復旧待ちを見込んで遅らせるか、取り込み側で後から届いた履歴を拾い直す設計にします。

回線を引けない現場で使うオフライン対応の期間限定PINという選択肢

倉庫や工事現場、山間部の施設のように、そもそも常時の回線を用意できない扉もあります。RemoteLOCKは2025年12月にオフライン対応の期間限定PINコード「アルゴリズムPIN」を案内しており、クラウドが暗号アルゴリズムで10桁のPINを生成し、本体が同じアルゴリズムで照合するため、事前のネット同期なしで指定期間内の解錠ができるとしています。

ただし同じ記事は、クラウド上でアクセス情報を削除してもPINは有効期間内なら使えるため、本体での無効化操作が必要だと注意しています。対応機種も2025年11月時点で500iと700iに限られます。期間を短く切って発行し、途中で止める可能性がある相手には使わない。この運用が守れる現場に限って採用します。

遠隔管理で入退室管理システムのクラウド型が効く業務と効かない業務

クラウド型の利点として真っ先に挙がるのがリモート管理です。ただ、遠隔でできることのすべてが運用を良くするわけではありません。効く場面と、むしろ管理を弱める場面を分けておきます。

合鍵の発行と失効を拠点に行かずに済ませる多拠点・無人施設の運用

遠隔管理が最も効くのは、権限の発行と失効の頻度が高く、拠点に管理者がいない運用です。支店や営業所が複数ある企業で入社・退職のたびに各拠点へ連絡していた作業や、レンタルスペースで予約ごとに暗証番号を作って伝えていた作業は、管理画面からの操作に置き換わります。履歴も拠点をまたいで同じ画面で検索できるため、本社の総務が全拠点の入退室を一人で見る体制が組めます。

拠点が1つで扉が2〜3枚、入れ替わりも年に数人という組織では、この利点はほとんど効きません。その規模なら、クラウド型を選ぶ理由は遠隔管理ではなく、サーバーを持たずに済むことと月額で費用が読めることになります。費用の積み上がり方は入退室管理システムの費用相場（初期費用・月額の内訳と扉数別の5年総額）で試算しています。

遠隔解錠を常用すると本人確認の記録が残らなくなるという失敗パターン

管理画面やスマートフォンから扉を開けられる遠隔解錠は便利ですが、常用すると入退室管理の意味が薄れます。履歴に残るのは「管理者が遠隔で開けた」という事実だけで、実際に誰が通ったかは記録されません。来客や配送のたびに受付担当が遠隔で開ける運用を続けると、監査の場面で該当時間帯の入室者を特定できない履歴が積み上がります。

遠隔解錠は、カードを忘れた社員の救済や設備業者の緊急対応など、例外の手段として位置づけます。日常的に人を通す必要がある扉には、来訪者ごとに期限付きの暗証番号やQRコードを発行し、本人の操作で開けてもらう形にすると、誰がいつ通ったかが履歴に残ります。

クラウドに集まる入退室ログの可視化とデータ分析を業務に使う方法

「入退室管理システムクラウド可視化」「クラウドデータ分析」で調べる読者が期待しているのは、履歴をただ保管するのではなく、業務の判断に使うことです。どこまでが標準機能で、どこからが別の仕組みになるかを分けて考えます。

在館者の把握と区画別の利用状況を標準の管理画面で可視化できる範囲

クラウド型の管理画面では、扉ごと・期間ごとの履歴の一覧、利用者での絞り込み、CSVでの書き出しまでは多くの製品が標準で備えています。在館者の一覧や、会議室・倉庫など区画別の利用回数の把握も、この範囲の機能で対応できる内容です。退室側にも認証端末を置いていない扉では「出た」記録が残らないため、在館者の把握を目的にするなら入室と退室の両方に端末が要る点を、導入前に確認しておきます。

可視化の範囲が管理画面で完結するなら、追加の開発は不要です。履歴を見て判断するのが総務や情シスの担当者だけで、他のシステムへ渡す予定がない場合はここで止めるのが適切な判断になります。

履歴をAPIで取り出して勤怠やBIと突き合わせるデータ分析の前提条件

入退室の時刻と勤怠の打刻の乖離を部署別に見る、拠点の利用率を席数と並べてオフィス縮小の判断に使う。こうした分析は、履歴を勤怠や人事のデータと結合する必要があるため、管理画面のCSV出力を手で加工する方式では続きません。APIで履歴を定期的に取り込み、自社側のデータベースに蓄積する仕組みが前提になります。

その際に効いてくるのが、前の章で見た同期の仕様です。Akerun Developersでは、取得できる履歴は直近2年間、リクエスト制限は1分あたり50回と公開されています（2026年10月時点）。保存期間を超えて分析したい場合は、自社側への複製が必須です。APIの公開状況や確認項目は入退室管理システムの比較（錠の方式・API連携・規模で整理）で製品比較の観点として扱っています。取り込んだ後の集計とダッシュボード化は、BIツールのできることとダッシュボードでの可視化の範囲です。

入退室ログをクラウドに置くときに確認する個人情報保護法上の論点

入退室履歴は、氏名や社員番号と時刻・場所が結び付いた従業員の個人データです。クラウド型を選ぶと、このデータがベンダーのサーバーに保存されます。法務や情報セキュリティの担当者から必ず聞かれる2点を、個人情報保護委員会の公表資料で確認します。

クラウド事業者が個人データを取り扱うかで委託先の監督義務が分かれる判断

個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン」に関するQ&AのQ7-53は、クラウドサービスの利用が個人データの提供に当たるかについて、保存データに個人データが含まれるかどうかではなく、クラウドを提供する事業者が個人データを取り扱うこととなっているかが判断の基準になると示しています。取り扱わない契約とアクセス制御になっていれば提供に当たらず、委託先の監督義務も生じません。

入退室管理のクラウドサービスでは、サポート対応のためにベンダーが履歴を参照できる契約になっている例も考えられます。その場合は委託として扱い、契約書と利用規約で、ベンダーが履歴にアクセスできる条件、保存期間、解約時の削除方法を確認しておきます。

外国事業者のクラウドは国内サーバーでも外国にある第三者への提供になり得る点

同じQ&AのQ12-4は、外国事業者が運営するクラウドについて、サーバーが国内にあっても、その外国事業者が保存された個人データを取り扱っているなら外国にある第三者への提供（法第28条第1項）に当たると示しています。海外製の入退室管理システムを国内代理店経由で契約する場合は、データを実際に扱う事業者がどこの国の法人かまで確認が必要です。

国内の事業者が国内のクラウドで運営している製品なら、この論点は小さくなります。製品の比較表には「データの保管場所」だけでなく「データを取り扱う事業者の所在」の列も足しておくと、法務確認で手戻りが起きません。

オンプレミス型を残すべき条件とクラウドへ移行するときの判断基準

ここまでの論点を踏まえると、クラウド型を選ばないほうがよい場面と、移行するなら守るべき順序がはっきりします。

閉域網の区画や常時オンラインを保証できない現場でオンプレミス型を残す条件

次のいずれかに当たる区画は、オンプレミス型を残します。インターネットに出る経路を持たない閉域網の中にあるサーバー室や研究区画。回線が不安定で、通信断の間に権限の失効が届かない状態を許容できない区画。入退室ログを社外のサーバーに置かないと社内規程や取引先との契約で定めている組織。この3つは、クラウド型の運用上の工夫では解消できません。

一方、「クラウドは不安だから」という漠然とした理由だけでオンプレミス型を選ぶのは見送ります。サーバーの保守、OSの更新、バックアップを自社で担う負担のほうが、多くの中小企業にとって大きなリスクになるからです。

オンプレミスからクラウドへ移す順序と移行でつまずく典型的なパターン

既存のオンプレミス型からクラウド型へ移すときは、扉を一斉に切り替えず、区画ごとに進めます。

扉の一覧に、錠の種類・制御盤の型番・回線の有無・重要度を書き出す
旧システムの利用者と権限、保管義務のある履歴を書き出して保存する
重要度の低い通用口や会議室からクラウド型に切り替え、運用を1か月ほど試す
人事マスタとの同期と失効の手順が回ることを確かめてから、残りの扉を移す

つまずきやすいのは、旧システムの履歴を移さずに切り替え、監査で過去分を求められて出せなくなるケースです。クラウド側へ旧履歴を取り込めない製品も多いため、移行前に書き出したデータを自社側で保管する場所を決めておきます。既存の電気錠や制御盤が新しい製品に対応するかについては、ビル設備側での確認も必要です。設備の範囲はビル管理システム（BAS）の対象範囲が参考になります。

クラウド型パッケージで足りる範囲と連携部分を個別開発する範囲の線引き

扉が十数枚まで、権限の付与と失効を管理画面の操作で回せる、履歴は管理画面とCSVで見られれば足りる。この条件なら、クラウド型のパッケージを設定だけで使い切ります。この範囲で個別開発を持ち込むのは過剰です。

人事マスタから権限を自動で付け外ししたい、通信断の間に遅れて届いた履歴まで漏れなく勤怠と突き合わせたい、保存期間を超えて履歴を分析したい。こうした要件が出た時点で、認証と施解錠はクラウド型のパッケージに任せ、APIで履歴と権限をやり取りする連携部分だけを作る構成が現実的です。錠や端末まで自社で作り直す選択は、機器保守の責任が宙に浮くため採りません。連携部分の切り分けは、扉の一覧と連携先のシステムの一覧を持ち寄って、基幹システム開発の相談として整理できます。

よくある質問

入退室管理システムのクラウド型を検討する段階でよく出る質問に答えます。

クラウド型の入退室管理システムはインターネットが止まると扉が開かなくなりますか？

多くの製品は、登録済みの暗証番号やカードの権限を端末側に記憶しているため、通信が止まっても登録済みの利用者は解錠できます。RemoteLOCKの公式FAQもWi-Fi切断時の動作をそう説明しています。影響を受けるのは、通信断の間に行った権限の新規発行や削除、遠隔解錠、履歴のクラウドへの反映です。停電時の動作は電池式か電源式かで変わるため、製品ごとに確認します。

クラウド型とオンプレミス型はどちらのセキュリティが高いですか？

方式だけで優劣は決まりません。クラウド型はサーバーの保守と更新をベンダーが担うため、自社で保守体制を持てない組織ではむしろ安全側に働きます。オンプレミス型はログを社外に出さずに済み、閉域網の中で完結できる点が強みです。判断の基準は、通信断のときに権限の失効が遅れることを許容できるかと、ログを社外に置けるかの2点です。

入退室管理システムのクラウド型で遠隔管理できることは何ですか？

利用者と権限の登録・変更・削除、暗証番号や合鍵の発行、扉ごとの解錠スケジュールの設定、履歴の閲覧と書き出し、製品によっては遠隔での施錠と解錠です。多拠点の扉を1つの管理画面で扱えるため、拠点に管理者がいない運用で効果が大きくなります。遠隔解錠は誰が通ったかが残らないため、例外の手段に留めます。

クラウドに保存された入退室データはどのように分析できますか？

管理画面での一覧表示、利用者や扉での絞り込み、CSVでの書き出しまでは多くの製品の標準機能です。勤怠や人事のデータと結合して部署別の傾向を見るような分析は、APIで履歴を定期的に取り込み、自社側のデータベースやBIツールで集計する形になります。APIの保存期間や取得の上限は製品ごとに違うため、分析の期間に合わせて確認します。

オンプレミス型からクラウド型へ移行するときに注意することは何ですか？

旧システムの履歴の保管と、既存の電気錠や制御盤が新製品に対応するかの2点です。クラウド側に旧履歴を取り込めない製品もあるため、切り替え前に書き出して自社側で保管します。扉は重要度の低い区画から順に切り替え、人事異動や退職時の失効の手順が回ることを確かめてから全体へ広げると、運用の混乱を抑えられます。