2026.10.19 業務システム

入退室管理システムの自作：記録・錠制御・電気錠の3段階で見る作れる範囲と外注の判断

入退室管理システムの自作は、何を自作するかで難しさがまったく違います。ICカードをかざした時刻を記録するだけなら、小型コンピューターとカードリーダー、数十行のプログラムで動かせる構成です。後付けのスマートロックを公開APIで開け閉めする段階になると、認証の安全性と通信の途切れへの備えが要ります。電気錠と制御盤まで自前で組むと、電気工事と建築の法令にかかわる構成です。この記事では自作を3段階に分け、各段階の構成と公式仕様、IDmだけで本人を判定する危うさ、オープンソースを使う前の確認点、自作をやめて外注やパッケージに切り替える条件までを整理します。仕組みや認証方式の基本は入退室管理システムとは？認証方式の種類と選び方・システム連携の判断【情シス向け】で解説しています。

まとめ：入退室管理システムの自作は記録までが現実的で錠の制御は既製品に任せる

自作で無理なく作れるのは、出入りの時刻を記録して一覧にするところまでです。塾や小規模オフィスで「誰がいつ来たか」を残したいだけなら、Raspberry PiとICカードリーダーで十分に実用になります。

扉を開け閉めする部分は、既製品の錠とそのAPIに任せてください。電気錠の配線は資格が要る工事を含み、避難に使う出口には屋内から鍵なしで開ける構造が法令で求められます。セキュリティを担う区画に自作の判定を置くなら、カードの製造番号だけで本人と見なす実装は避けます。社内システムとの連携や独自の管理画面が必要な場合は、錠と認証は買い、ソフトウェアだけを開発する分担が費用と保守の両面で無理がありません。

入退室管理システムの自作で作れる範囲を記録・錠制御・電気錠の3段階で整理

「自作」という言葉の中身は、次の3段階に分かれます。段階が上がるほど、ソフトウェアより機器と法令の比重が増えます。

段階	作るもの	主な機器	自作の可否
1 記録のみ	出入りの時刻と人の一覧	Raspberry Pi、カードリーダー	自作向き
2 錠の制御	解錠の判定と操作	後付けスマートロック、ハブ	APIの範囲で可
3 電気錠	扉と制御盤の一式	電気錠、制御盤、電源	専門業者が必要

検索で見つかる自作の事例の多くは段階1です。段階2と3では、扉が開かない、閉まらないといった不具合がそのまま防犯と避難の問題になります。

段階1：ICカードやQRで出入りの時刻を記録するだけの自作システム

段階1は、扉の鍵には触れず、入口に置いた端末で「誰が何時に来て何時に帰ったか」を残す仕組みです。カードリーダーで読み取った番号を利用者の名簿と突き合わせ、時刻とともにCSVやスプレッドシート、データベースに書き込みます。タブレットのカメラでQRコードを読む方式でも同じことができます。

鍵は従来どおり物理鍵や既存の錠で管理するため、プログラムが止まっても扉の開閉には影響しません。不具合の影響が記録の欠けにとどまる点が、自作に向く最大の理由です。

段階2：後付けスマートロックをAPIで開け閉めする自作システムの構成

段階2では、サムターン（扉の内側のつまみ）に貼り付けるスマートロックを、メーカーが公開するAPIで操作します。自作するのは「この人に開けてよいか」を判定するプログラムと、その結果を受けて解錠を命じる部分です。錠の駆動や電池の管理はメーカーの製品が担います。

機器の工事が要らない一方、判定を誤れば扉が誰にでも開きます。段階1では記録が欠けるだけだった不具合が、ここから防犯上の事故に変わります。24時間無人のジムを例に、会員アプリの認証と会費の決済状態を解錠判定へつなぐ運用は、入退室管理システムのジム導入：24時間無人運営の認証・共連れ対策と会費連携の判断で解説しています。

段階3：電気錠と制御盤まで自前で組む構成が自作の範囲を超える理由

段階3は、扉に電気錠を組み込み、カードリーダーと制御盤、電源装置を配線してつなぐ構成です。ビルの入退室管理システムの多くはこの形をとります。ソフトウェアを書けても、錠の選定、扉の加工、配線、停電時と火災時の動作設計は別の専門領域です。

後述するとおり、電源の配線は電気工事士の資格が要る工事を含みます。自社ビルの設備と連動させる場合は、ビル側の設備業者との調整も避けられません。設備側の範囲はビル管理システム（BAS）とは？中央監視の対象範囲とパッケージ／受託開発の判断で整理しています。

ラズパイとICカードリーダーで入退室の記録を自作するときの構成と手順

段階1の定番構成は、Raspberry Pi、USB接続のICカードリーダー、Pythonの組み合わせです。部品が手に入りやすく、情報も多く出回っています。

Raspberry PiとRC-S380、nfcpyで読み取りから記録までを組む手順

カードの読み取りに使えるのは、PythonのNFCライブラリnfcpyです。nfcpyの公式ドキュメント（1.0.4版）は、Python 2.7または3.5以降で動き、ソニーのRC-S380/S（デバイスパス usb:054c:06c1）を検証済みの機器として挙げています。FeliCaはType 3 Tagとして扱われます。

読み取ったカードの識別子を時刻とともにCSVへ追記する最小構成は次のとおりです。

import csv, datetime
import nfc

def on_connect(tag):
    card_id = tag.identifier.hex()  # FeliCaならIDm（製造番号）
    with open('entry_log.csv', 'a', newline='') as f:
        csv.writer(f).writerow([datetime.datetime.now().isoformat(), card_id])
    return True  # カードが離れるまで待つ

with nfc.ContactlessFrontend('usb') as clf:
    while True:
        clf.connect(rdwr={'on-connect': on_connect})

実務では、識別子と利用者名を対応させる名簿、入室と退室の区別（リーダーを2台にするか画面で選ばせる）、読み取り時の音やランプ表示を足します。Raspberry Piの基本的な組み立て方はラズパイでスマートホームを自作する方法が参考になります。

ICカードのIDmだけで本人を判定する自作システムのなりすましリスク

上のコードが記録しているのは、FeliCaのIDmと呼ばれる番号です。キヤノンMJのICカードの種類の解説では、IDmは製造工程でチップに記録される8バイトの製造番号で、IDmだけを使った認証はエミュレーターなどによるなりすましのリスクがあるため、入退室管理のようにセキュリティが求められる業務では鍵有り認証を推奨すると説明しています。

出席や在室の記録に使うだけなら、IDmで足ります。困るのは、同じ番号を扉の解錠判定に流用する場合です。段階2に進むなら、カードを解錠の鍵にせず、スマートロック側の認証（暗証番号や専用アプリ）を使うか、暗号鍵で守られた領域を読む方式に対応した既製品を選んでください。

スマートロックのAPIで入退室管理システムを自作するときの仕様上の制約

段階2では、APIの仕様がそのまま自作システムの限界になります。ここでは仕様が公開されているSwitchBotを例に確認します。

SwitchBot API v1.1で解錠するリクエストと署名、1日1万回の上限

SwitchBot APIの公式リポジトリによると、v1.1はapi.switch-bot.comに対してリクエストを送り、トークンと時刻、ランダムな値を連結した文字列をシークレットでHMAC-SHA256署名して添えます。呼び出しは1日10,000回までで、超えるとエラーが返ります。

Lockのコマンド仕様では、lock、unlock、deadboltの3つが定義されています。解錠のリクエスト本文は次の形です。

POST https://api.switch-bot.com/v1.1/devices/{deviceId}/commands
{"command": "unlock", "parameter": "default", "commandType": "command"}

1日1万回は、扉1枚の解錠だけなら十分です。ただし状態の確認を1分ごとに回すと、それだけで1日1,440回を使います。状態はWebhookで受け取り、ポーリングは避ける設計にしてください。トークンの取得手順はSwitchBot APIとは？できること・使い方とトークン取得、遠隔操作の仕組みで解説しています。

ハブとクラウドを経由する構成で通信断や電池切れのときに起きること

Lockの状態情報にはhubDeviceId（親のハブのID）が含まれ、APIからの操作はハブ経由で錠に届きます。自作のプログラム、インターネット回線、メーカーのクラウド、ハブ、錠のどこかが止まれば、APIからは開けられません。Webhookで届くlockStateには、LOCKEDとUNLOCKEDのほかに、モーターが回転中に詰まったことを示すJAMMEDがあります。

自作するなら、JAMMEDと電池残量の低下を管理者に通知する処理は必ず入れてください。APIが使えない間も扉を開けられるよう、物理鍵や錠本体のテンキーを残しておく運用も前提になります。通信断の動作を製品ごとに比べる観点は入退室管理システムのクラウド型：オンプレミスとの違いと通信断・ログ分析で選ぶ基準にまとめています。

電気錠の配線と避難経路の扉で入退室管理の自作が法令にかかる場面

段階3に手を出す前に、2つの法令を確認してください。どちらも「動けばよい」では済まない部分です。

電気工事士法で資格が要る工事と軽微な工事に入る36V以下の二次側配線

電気錠や制御盤の電源を建物の屋内配線から取る工事は、電気工事士の資格が要る電気工事にあたります。電気工事士法施行令第1条は資格なしでできる軽微な工事を列挙しており、その4号は、ベルやインターホン、火災感知器などに使う小型変圧器（二次電圧36ボルト以下に限る）の二次側の配線工事です。

低い電圧で動く機器の配線でも、自分の工事がこの4号に入るかを自分で判断するのは避けてください。電源側の工事は電気工事業者に任せ、自作の範囲はリーダーと制御装置の間の信号線やソフトウェアにとどめるのが安全です。

建築基準法施行令125条の2で屋内から鍵なしで開ける必要がある出口

建築基準法施行令第125条の2は、避難階段に通じる出口や、普段は施錠しておき火災などの非常時に避難に使う出口について、施錠装置を屋内から鍵を用いることなく解錠できるものとし、解錠方法を戸の近くの見やすい場所に表示するよう定めています。

自作の錠でこうした出口を施錠し、屋内側もカードがないと開かない設計にすると、この規定に反するおそれがあります。停電時やプログラムの停止時に扉が閉じたままになる構成も同じ問題を抱えます。避難経路にかかる扉は、自作の対象から外してください。

オープンソースの入退室管理ソフトを業務に使う前に確かめる保守の実態

「入退室管理システムオープンソース」で探すと、GitHubなどで公開された管理ソフトやマイコン用のプログラムが見つかります。無料で使える反面、製品と同じ感覚で導入すると止まったときに困ります。

OSSを採用する前に最終更新日・対応機器・ライセンスを確かめる観点

オープンソースを業務に使うかどうかは、機能の一覧より先に次の4点で判断します。

最終更新日と未解決のissueの数。1年以上更新がなければ、対応機器のファームウェア更新に追従していない可能性があります。
対応しているカードリーダーや錠の型番。手元の機器が対応一覧に無ければ、ドライバーの開発から始まります。
ライセンスの種類。改変して社内で配布するか、顧客に提供するかで守る条件が変わります。
利用者の規模。動作報告が開発者本人だけのソフトは、試作品と考えたほうが無難です。

この4点を満たすソフトは多くありません。満たさない場合は、ソースを参考にしつつ、記録の部分だけを自分たちで書き直すほうが保守の見通しが立ちます。

自作した仕組みを誰が保守するかを決めずに運用を始めて止まる失敗パターン

自作の入退室管理で最も多い失敗は、技術ではなく体制の問題です。作った担当者が異動や退職でいなくなり、カードの追加登録やOSの更新ができる人が社内に残らない。SDカードの破損でRaspberry Piが起動しなくなっても、どこにバックアップがあるか誰も知らない。こうして記録が数か月止まっていたことに、監査や事故の後で気づきます。

自作で運用するなら、手順書、名簿とログのバックアップ先、交換用のSDカードと機器、代わりに対応できる担当者の4つを、稼働の前に決めておいてください。これを用意できない組織では、月額を払ってでも既製品を選ぶほうが安くつきます。

入退室管理システムを自作してよい条件と外注やパッケージに切り替える判断基準

ここまでの論点を、自作を続けるか切り替えるかの判断にまとめます。

記録だけの自作で十分な条件と、錠の制御まで自作を見送るべき場面

次の条件がそろうなら、段階1の自作で十分です。目的が出席や在室の記録で、扉の鍵は既存の運用で困っていない。利用者が数十人までで、記録が半日欠けても業務が止まらない。保守できる担当者が2人以上いる。

反対に、サーバー室や個人情報を扱う部屋の扉を自作の判定で開け閉めする計画は見送ってください。取引先の監査で入退室の記録を求められる区画、避難経路にかかる扉、利用者が100人を超えて退職者の権限をその日のうちに止める必要がある拠点も同じです。この場合は既製品を選び、比較の観点は入退室管理システムの比較：おすすめ製品の選び方を錠の方式・API連携・規模で整理で確認できます。製品の費用は入退室管理システムの費用相場で扉数別に試算しています。

既製品の錠とAPIを買い、管理画面と連携部分だけを開発する構成

自作を考える理由が「既製品の管理画面が業務に合わない」「人事や会員の名簿と自動でつなぎたい」であれば、全部を作る必要はありません。錠と認証は、APIを公開している既製品に任せます。開発するのは、名簿と権限を同期する処理、自社の業務に合わせた管理画面、入退室ログを勤怠や会員管理に取り込む処理です。

この分担なら、扉の故障はメーカーの保守、ソフトウェアの不具合は開発側と、責任の境界がはっきりします。APIの呼び出し上限や通信断のときの再送といった設計は、段階2で見た仕様をそのまま前提にした設計が可能です。既製品の錠を前提に、管理画面や社内システムとの連携を個別に作る相談はフルスクラッチ開発で受け付けており、扉と連携先の一覧から開発範囲を切り分けられます。

よくある質問

入退室管理システムの自作について、検討の段階でよく出る質問に答えます。

入退室管理システムは自作できますか？

出入りの時刻を記録するだけなら、Raspberry PiとICカードリーダー、Pythonで自作できます。後付けスマートロックを公開APIで操作する段階までは、ソフトウェアの範囲での自作が可能です。電気錠と制御盤まで組む構成は、電気工事と建築の法令にかかるため、専門業者に任せる部分が出てきます。何を自作するかを先に決めると判断しやすくなります。

入退室管理システムを自作するのと製品を導入するのはどちらが安いですか？

機器代だけを比べれば、記録のみの自作は製品より安く収まります。ただし自作では、保守する担当者の工数、機器の予備、故障時に記録が止まる損失を負うのは自社です。担当者が1人しかいない、監査で記録の欠けが許されないといった条件なら、月額を払って製品を使うほうが総額は低くなります。製品の価格は扉数と年数で比べてください。

オープンソースの入退室管理システムはありますか？

GitHubなどで、入退室の記録や扉の制御を行うソフトが公開されています。業務で使う前に、最終更新日、対応するカードリーダーや錠の型番、ライセンス、ほかの利用者の有無を確かめてください。更新が止まっているものや、開発者本人の環境でしか動作報告がないものは、試作品として扱うのが無難です。

Excelやスプレッドシートで入退室を管理できますか？

記録表としてなら使えます。手入力の表は導入が手軽ですが、記入漏れや後からの書き換えを防げません。QRコードやICカードで読み取った結果をスプレッドシートに自動で書き込む形にすると、入力の手間と誤りが減ります。扉の施錠と解錠は管理できないため、鍵の管理は別に考える必要があります。

自作した入退室管理システムの記録を勤怠管理に使えますか？

使えますが、記録の正確さに責任を持てることが前提です。厚生労働省の労働時間の把握に関するガイドラインは、タイムカードやICカードなど客観的な記録を基礎とする方法を挙げています。自作の記録を勤怠に使うなら、時刻の同期、記録の改ざん防止、欠けたときの補正手順を決めてください。勤怠システムへの取り込みを自動化する場合は連携部分の開発が必要です。