Verkadaで既存の電子錠をスマホ自動解錠へ移行する設計・構築ガイド｜Bluetooth・API・ISMSまで安全性重視で考える

情報確認日：2026年9月8日

既存のカード式入退室管理装置をVerkadaへ交換し、社員がスマートフォンを持って入口へ近づくだけでドアが開く。

しかも、建物から出るときには反応しない。

さらに、社員管理やログ収集はクラウド化し、必要な部分はAPIを使って自社でプログラムする。

このような「テスラのスマホキー」に近い入退室環境は、Verkadaを使えばかなり現実的に構築できます。

ただし、入退室管理で最優先すべきなのは便利さではありません。

間違ってドアが開かないことです。

Bluetoothを持った社員が室内を歩いただけで入口が開く。

APIプログラムのバグでドアが開く。

退職者の権限が残っている。

配線を短絡されたらドアが開く。

このような構成では、どれだけ便利でも企業の入退室管理としては危険です。

そこでこの記事では、Verkadaを使って、

「便利だが、1つのミスだけでは不正解錠できない入退室システム」

を作ることを目標にします。

結論
Bluetoothで「入るときだけ開ける」はできるのか？
Verkadaには「Intent Unlock」がある
「完全自動」と「Intent Unlock」は分けて考える
それでも誤解錠が絶対ゼロになるわけではない
誤解錠を減らすための入口設計
AD34とAD64はどう使い分ける？
1. 普通の事務所入口
2. サーバールーム
3. 金庫・重要情報区画
既存の電子錠をそのまま使える可能性は高い
fail-secureとfail-safeを理解する
1. fail-secure
2. fail-safe
可能なら「退室時に電気的解錠を必要としない」構造が強い
REXには注意が必要
DPIは必ず付けたい
DPI・REX配線にも改ざん検知を入れる
火災報知設備との連携を忘れてはいけない
コントローラはどう選ぶ？
おすすめ全体構成
Codexでプログラムを書くなら「解錠」より周辺を作る
APIキーの扱い
解錠APIには2種類あるので注意
自作するならuser_unlockを使う
APIのおすすめ用途
1. 社員入社
2. 異動
3. 退職
Webhookで監視システムを作る
Webhookは解錠制御ではなく監視へ使う
カメラも入口に付ける価値が高い
ISMSを考えるなら「VerkadaがISO認証済み」で終わらせない
Verkada導入で特に見るISMS項目
権限分離も必要
ネットワークも分離する
「ネットが落ちたらドアが開く」は避けられる
本番前に作る「検証用ドア」
必ず実施したい異常試験
1. BLE
2. ドア
3. ネットワーク
4. 電源
5. クラウド
6. ID
最重要テスト「室内のスマホで外から開かないか」
高セキュリティドアではBLEを使わない判断も必要
導入プロジェクトの進め方
1. Phase 1　現状調査
2. Phase 2　セキュリティ要件を決める
3. Phase 3　設計
4. Phase 4　机上PoC
5. Phase 5　自社プログラム開発
6. Phase 6　施工会社へ渡す
施工会社に必ず確認すること
本番移行は一発切替しない
本番判定基準
やってはいけない設計
「便利機能」と「安全装置」を分離する
私ならこう作る
さらにセキュリティを上げるなら
FAQ
1. Verkadaだけでテスラのようなスマホキーを作れる？
2. 自分でBluetoothプログラムを書く必要はある？
3. 出るときにBluetoothで開かないようにできる？
4. 出口側にもReaderが必要な場合は？
5. APIでドアを開けてもいい？
6. ISMS対応になる？
一次情報
この記事で学べることまとめ

結論

おすすめする基本構成は次の形です。

社員スマートフォン
    │
    │ Verkada Pass / BLE
    ▼
【建物の外側】
AD34 または AD64
Verkada Reader
    │
    │ OSDP / RS-485
    ▼
Verkada Access Controller
AC12 / AC43 / AC62
    │
    ├── 電気錠
    ├── DPI ドア開閉センサー
    ├── REX 退室検知
    └── 火災報知設備（必要な構成）

【建物の内側】
ドアハンドル
または
退室用REX

そして、Bluetooth解錠にはVerkadaのIntent Unlockを使います。

AD34やAD64では、

解錠権限を持ったスマートフォンが近くにある
リーダー正面に人・手・車などの物体がある

という条件を組み合わせて解錠できます。

つまり、

「スマホが近いだけで開く」構成より誤解錠をかなり減らせます。

Verkada自身も、室内側を社員が歩いただけでドアが誤って開く問題をIntent Unlockで防ぐことを目的の一つとして説明しています。

Bluetoothで「入るときだけ開ける」はできるのか？

結論としては、できます。

ただし、ソフトウェアだけで「方向」を判断させるより、物理設計で方向を分ける方が安全です。

おすすめは、

外側
↓
AD34
↓
ドア
↓
内側
REXまたは普通のドアハンドル

という構成です。

つまり、Bluetooth対応リーダーそのものを入口側だけに設置します。

これなら退出側にはBluetooth解錠装置がありません。

そのため、社員が出口へ近づいても、Bluetoothによる解錠判定そのものが発生しません。

これは非常に重要です。

「人が入口側にいるか出口側にいるか」をプログラムで推測するより、

入口にしかBLEリーダーが存在しない

という物理条件を作った方が信頼性が高くなります。

Verkadaには「Intent Unlock」がある

ここが今回の構成で重要な機能です。

AD34やAD64にはBluetoothのIntent Unlockがあります。

単純なBluetooth近接解錠では、

スマホがBLE圏内
↓
解錠

となります。

しかしIntent Unlockでは、

権限のあるスマホがBLE圏内
+
リーダー正面に物体を検出
↓
解錠

という判定ができます。

AD34にはToF（Time of Flight）方式の距離センサーが搭載されています。

これは、光を使ってリーダー正面の物体までの距離を測るセンサーです。

最大約2mまで物体を検知できます。

さらに、

BLEスマートフォンまでの距離
人や手などを検出する距離

を調整できます。

そのため、

スマホ：約50cm以内
+
手：約20cm以内

のような厳しい条件に寄せることもできます。

実際の設定値は現地環境で検証して決めます。

「完全自動」と「Intent Unlock」は分けて考える

便利さだけを優先すれば、

社員が入口へ歩く
↓
BLE検知
↓
自動解錠

にできます。

しかし、外部から入れる玄関ではおすすめしません。

より安全なのは、

社員が入口へ近づく
↓
スマホをBLE認証
↓
リーダー正面で手をかざす
↓
解錠

です。

スマホをポケットから出す必要はありません。

したがって使用感はかなり自動ドアに近いままです。

しかし、人間の「開ける意思」が1つ追加されます。

外部に面したドアでは、この小さな操作を残した方が安全です。

それでも誤解錠が絶対ゼロになるわけではない

ここは重要です。

どのメーカーの入退室管理でも、

「絶対に誤解錠しない」と保証することはできません。

たとえば理論上、

社員
スマホを持って室内側でドア付近に立っている

＋

外側
第三者がAD34へ近づく

という状態では、

BLE電波がドアを越えて到達し、外側の物体検知条件まで成立する可能性を検証する必要があります。

Intent Unlockは誤解錠を防ぐ強力な仕組みですが、

「リーダー前にいる人」と「BLE端末の所有者」が必ず同一人物であることまで証明する仕組みではありません。

だからこそ、導入時の実地試験が重要になります。

誤解錠を減らすための入口設計

外部入口なら、まず次を基本条件にします。

項目	推奨
リーダー	AD34またはAD64
BLE	Intent Unlock
BLE距離	必要最小限
Intent	手をかざす方式を優先
Reader設置	外側のみ
出口	ハンドルまたはREX
DPI	必須に近い扱い
配線監視	EOL監視を検討
カメラ	入口に設置推奨
共連れ検知	可能なら有効化
APIによる通常解錠	原則使わない

特に重要なのがBLE距離です。

「3m離れていても開く」のような便利設定にはしません。

入口前まで来なければ認証できない程度まで短くします。

そして現地試験では、室内側から、

ドア正面
ドア横
壁際
待合スペース
社員が座る席
通路
エレベーター待機位置

などをスマートフォンを持って歩きます。

その状態で、外側から人がリーダーへ近づいても解錠しないことを確認します。

AD34とAD64はどう使い分ける？

基本的なBluetooth Intent UnlockだけならAD34で十分です。

一方で、重要区画ではAD64が有力です。

AD64にはテンキーがあります。

そのため、

カード
+
PIN

という2要素認証ができます。

たとえば、

普通の事務所入口

BLE Intent Unlock

サーバールーム

NFCカード
+
PIN

金庫・重要情報区画

暗号化カード
+
PIN
+
カメラ監視

というようにセキュリティレベルを変えられます。

すべてのドアをBLE化する必要はありません。

既存の電子錠をそのまま使える可能性は高い

Verkada Access Controllerは、さまざまな既存電気錠と接続できます。

まず現在の設備について調べます。

最低限必要なのは、

確認項目	例
錠前メーカー	美和ロック、GOALなど
型番	現地確認
電圧	12V / 24V
消費電流	mA
制御方法	dry / wet
動作方式	fail-safe / fail-secure
ドアセンサー	有無
REX	有無
火災連動	有無
現在のカードリーダー	Wiegand等
配線本数	現地確認
UPS	有無

ここを調べずにVerkadaを購入してはいけません。

fail-secureとfail-safeを理解する

これは入退室管理では非常に重要です。

fail-secure

電源が切れても施錠されます。

つまり、

停電
↓
外からは開かない

という方向です。

防犯には強い方式です。

一方、室内からは機械式ハンドルなどで退出できる構造にする必要があります。

fail-safe

電源が切れると解錠します。

マグネットロックなどでよく使われます。

停電
↓
解錠

となります。

避難安全性には有利ですが、防犯上は違うリスクがあります。

Verkadaも両方式への配線方法を公開しています。

どちらにするかは、防犯だけで決めてはいけません。

避難経路、防火設備、建築条件、消防設備などを含め、施工会社・設備管理者・必要に応じて消防設備関係者と決めます。

可能なら「退室時に電気的解錠を必要としない」構造が強い

セキュリティだけを見るなら、かなり重要な考え方です。

たとえば、

外側
電気錠によるアクセス制御

内側
普通にハンドルを回せば退出可能

という構造です。

これなら退室のためにREXで錠前を電気的に解除する必要がありません。

REXは、

人が退出したことの記録

だけに使えます。

これは安全性を高めます。

なぜなら、REX配線が何らかの原因で誤動作しても、

REX信号だけではドアを解錠しない

設計にできるからです。

REXには注意が必要

REXとはRequest to Exitです。

つまり「退出要求」です。

一般的には室内側の人感センサーやボタンを使います。

Verkadaでは、

REXを検知
↓
ドア解錠

にもできますし、

REXを検知
↓
退出イベントとして記録するだけ

にもできます。

高い防犯性を求めるなら、

機械式ハンドルで退出できるドアでは、REXに解錠権限を持たせない

設計を検討する価値があります。

DPIは必ず付けたい

DPIはDoor Position Indicatorです。

簡単にいうと、

「ドアが実際に開いているか閉じているかを見るセンサー」

です。

これがないと、

システム上は施錠

でも、

実際にはドアが半開き

という状態を把握できません。

DPIを使えば、

ドアが開いた
閉じた
開きっぱなし
こじ開けられた

などを検出できます。

VerkadaではDHO（Door Held Open）などの監視も可能です。

DPI・REX配線にも改ざん検知を入れる

AC43などではEOL抵抗によるSupervised Wiringを利用できます。

通常の配線なら、

ON
OFF

しか分かりません。

しかしEOL監視を行えば、

正常

断線

短絡

センサー作動

を区別できます。

つまり、

誰かが配線を切った

あるいは、

配線を短絡させた

という異常を検出しやすくなります。

抵抗はコントローラ側ではなく、原則としてセンサー側の終端へ設置します。

そうしなければ配線全体を監視する意味が薄れます。

火災報知設備との連携を忘れてはいけない

AC43やAC62にはFAI、つまりFire Alarm Interfaceがあります。

火災報知設備から信号を受けて、必要なドアを安全側へ動かします。

これは便利機能ではありません。

人命に関わる設備です。

したがって、

自分でAPIを書いて
火災が起きたらドアを開ける

のような設計にはしません。

火災連動は可能な限り、

火災報知設備
↓
物理配線
↓
FAI
↓
Access Controller
↓
錠前

というハードウェア経路で構成します。

クラウドや自作プログラムが落ちていても避難できる設計にします。

国土交通省の公共建築工事標準仕様でも、入退室管理には防災設備との連携、停電時の動作、記録などが重要な機能として挙げられています。

コントローラはどう選ぶ？

2026年9月時点の主な構成は次の通りです。

モデル	ドア数	主な用途
AC12	1	独立した1ドア
AC43	4	小～中規模
AC62	16	大規模

単純にドア数だけでは決めません。

たとえば火災連動をしっかり組みたい場合は、FAIを持つAC43やAC62が候補になります。

Codexでプログラムを書くなら「解錠」より周辺を作る

VerkadaにはAPIがあります。

そのためCodexなどを使えば、

社員情報同期
BLE権限付与
BLE権限削除
Pass招待
アクセスログ取得
Webhook受信
異常検知
SlackやTeams通知
SIEM連携
自社ダッシュボード
退職者権限削除確認

などはかなり自動化できます。

APIキーの扱い

Verkada APIでは、

API Key
↓
短時間有効なAPI Token
↓
各API実行

という形になっています。

API Tokenは30分間有効です。

したがって、自作サービスでは、

Secret Manager
    │
API Key
    │
    ▼
Token取得
    │
30分
    ▼
API利用

という構成にします。

APIキーを、

GitHub
ソースコード
Macアプリ
スマホアプリ
Raspberry Pi
ドア横PC

などへ直接保存してはいけません。

解錠APIには2種類あるので注意

ここは非常に重要です。

Verkadaには、ユーザーとして解錠するAPIがあります。

この場合、

ユーザー
↓
そのドアへの権限を確認
↓
許可されていれば解錠

となります。

一方で管理者解錠APIもあります。

こちらは、

ユーザーのドアアクセス権限とは関係なく解錠できます。

したがって、

BLEセンサー
↓
自作Python
↓
admin_unlock
↓
ドア解錠

というシステムを作ってはいけません。

プログラムの条件式が1つ壊れただけでドアが開く可能性があります。

自作するならuser_unlockを使う

どうしても自社システムからユーザー操作でドアを開ける場合は、

本人認証
↓
自社システム
↓
user_id
↓
Verkada user_unlock
↓
Verkada側でも権限確認
↓
解錠

という構成にします。

つまり、

自社システムとVerkadaの両方で許可されないと開かない

形です。

Pythonなら考え方は次のようになります。

import os
import requests

def get_token():
    api_key = os.environ["VERKADA_API_KEY"]
    token_endpoint = os.environ["VERKADA_TOKEN_ENDPOINT"]

    response = requests.post(
        token_endpoint,
        headers={"x-api-key": api_key},
        timeout=5,
    )

    response.raise_for_status()
    return response.json()["token"]


def unlock_as_user(user_id, door_id):
    token = get_token()
    endpoint = os.environ["VERKADA_USER_UNLOCK_ENDPOINT"]

    response = requests.post(
        endpoint,
        headers={
            "x-verkada-auth": token,
            "Content-Type": "application/json",
        },
        json={
            "user_id": user_id,
            "door_id": door_id,
        },
        timeout=5,
    )

    response.raise_for_status()

    return response.json()

ただし、これを通常のBLE入室処理には使いません。

通常入室はAD34などのネイティブ機能へ任せます。

APIのおすすめ用途

自作プログラムは、こちらに使った方が価値があります。

社員入社

人事システム
↓
Entra ID
↓
SCIM / API
↓
Verkada
↓
所属グループ
↓
アクセス権
↓
Pass招待
↓
BLE有効化

異動

所属部署変更
↓
グループ変更
↓
アクセス可能ドア変更

退職

Entra ID無効化
↓
Verkadaアクセス削除
↓
BLE無効
↓
NFC無効
↓
カード無効

Verkada APIではAccess UserのBLE機能について有効化・無効化も可能です。

Webhookで監視システムを作る

VerkadaはAccess ControlイベントをWebhookで受け取れます。

たとえば、

door_ble_unlock_attempt_accepted

ならBLE解錠成功です。

ほかにも、

BLE認証拒否
NFC認証
カード認証
ドアこじ開け
開けっぱなし
コントローラ停止
配線異常
火災信号

などのイベントがあります。

そのため、

Verkada
↓
Webhook
↓
自社サーバー
↓
SIEM
↓
Teams / Slack / PagerDuty

といった監視ができます。

Webhookは解錠制御ではなく監視へ使う

ここでも考え方は同じです。

Webhookを受信
↓
条件判定
↓
ドアを開ける

より、

Webhookを受信
↓
ログ保存
↓
異常判定
↓
管理者通知

に使います。

VerkadaのWebhookには共有Secretを設定できます。

さらにWebhook処理は、

受信
↓
検証
↓
キューへ保存
↓
すぐ2xx返却
↓
後から処理

という構成にします。

VerkadaはWebhookへの応答時間を短くすることを推奨しています。

カメラも入口に付ける価値が高い

入退室管理では、

社員A
09:03
BLE認証成功

というログだけより、

社員A
09:03
BLE認証成功
+
その瞬間の映像

まで確認できる方が強いです。

Verkadaではドアとカメラを関連付けられます。

さらに共連れ検知もできます。

つまり、

1人認証
↓
2人入室
↓
Tailgatingイベント

を検出できます。

「認証システムを突破された」だけでなく、

正規社員の後ろについて入る

という現実的な侵入方法にも対策できます。

ISMSを考えるなら「VerkadaがISO認証済み」で終わらせない

Verkada Command自体はISO/IEC 27001:2022、ISO 27017、ISO 27018などの認証を取得しています。

しかし、

VerkadaがISO 27001認証を持っていることと、自社のVerkada運用がISMS要件を満たしていることは別問題です。

ISMSでは自社側でも、

リスク特定
↓
管理策選択
↓
実装
↓
記録
↓
監視
↓
内部監査
↓
改善

が必要です。

ISO/IEC 27001:2022では管理策が、

組織的
人的
物理的
技術的

の4分類へ整理されています。

Verkada導入で特に見るISMS項目

今回のシステムでは特に次を意識します。

分野	実装例
アクセス制御	部署・職務ごとのドア権限
ID管理	Entra ID等との同期
アクセス権	入社・異動・退職処理
物理的境界	管理区域の明確化
物理的入退室	Verkada Access Control
物理監視	カメラ＋ドアイベント
配線保護	EOL監視
ログ	Command＋SIEM
監視	Webhook＋アラート
ネットワーク	VLAN分離
変更管理	Command設定変更手順
サプライヤ管理	Verkada・施工会社
インシデント対応	不審入室時の手順

権限分離も必要

Verkada Commandにはアクセス管理用の複数ロールがあります。

全員を管理者にしてはいけません。

たとえば、

情シス
システム設定

総務
社員のアクセス権

受付
限定ドアの遠隔解錠

警備
イベント閲覧

施工会社
工事期間だけ一時管理権限

のように分けます。

施工完了後は施工会社の管理権限を削除します。

Verkada自身の導入ベストプラクティスでも、施工完了後にインストーラーをCommand組織から削除することを推奨しています。

ネットワークも分離する

Access Controllerを普通の社員PCと同じネットワークへ入れる必要はありません。

おすすめは、

Corporate VLAN
社員PC

Security VLAN
Verkada
カメラ
Access Controller

Management VLAN
管理端末

のような分離です。

そしてSecurity VLANから必要な通信だけを許可します。

Verkada自体はクラウドとの通信を基本的にアウトバウンドで行う設計です。Verkadaは公開ネットワーク上の通信についてTLS 1.2以上を使用するとしています。

「ネットが落ちたらドアが開く」は避けられる

Verkada Access Controllerはエッジ側でも処理を行います。

そのためインターネット接続が失われても、通常の入退室処理を継続できる設計です。

これはかなり重要です。

Internet障害
↓
全員入れない

というクラウド依存構成にはしない方がよいためです。

ただし、本番導入前には必ず実際にWANを切断して試験します。

本番前に作る「検証用ドア」

いきなり会社の玄関を交換するのはおすすめしません。

Verkada自身もステージング環境で事前検証する方法を案内しています。

まず、

AC43
+
AD34
+
テスト用電気錠
+
DPI
+
REX
+
管理スイッチ

を机上で組みます。

ここで全部壊してみます。

必ず実施したい異常試験

正常系だけ試してはいけません。

BLE

正常な社員が近づく
権限のない社員が近づく
退職ユーザー
スマホ画面ロック
Bluetooth OFF
Pass停止
スマホを室内側へ置く
スマホをドア横へ置く
外から第三者だけ近づく

ドア

DPI断線
DPI短絡
REX断線
REX短絡
ドア開けっぱなし
ドアこじ開け

ネットワーク

Internet切断
LAN切断
DNS障害
DHCP障害

電源

停電
UPS動作
Controller再起動

クラウド

管理者アカウント停止
API停止
自社APIサーバー停止

ID

入社
異動
休職
退職
一時利用者
契約社員

全部試します。

最重要テスト「室内のスマホで外から開かないか」

今回の構成では、この試験が特に重要です。

社員のスマートフォンを持って、

室内
ドアから10cm

30cm

50cm

1m

2m

3m

通路

待合スペース

と移動します。

その状態で別のテスターが外側のリーダーへ近づきます。

1回でも意図しない解錠が起きたら本番導入しません。

BLE距離、Intent距離、リーダー位置を変更します。

それでも安定しなければ、その入口ではBLEを採用せずNFCへ変更します。

高セキュリティドアではBLEを使わない判断も必要

便利だからといって、全部Bluetoothにする必要はありません。

たとえば、

区域	認証
オフィス玄関	BLE Intent Unlock
一般会議室	BLE
社内倉庫	NFC
サーバールーム	カード＋PIN
個人情報保管庫	カード＋PIN
重要設備	2FA＋カメラ

という設計ができます。

セキュリティレベルによって認証方法を変えること自体がISMS的にも自然です。

導入プロジェクトの進め方

実際には次の順番がおすすめです。

Phase 1　現状調査

現在の、

電気錠
制御盤
カードリーダー
DPI
REX
火災連動
UPS
配線
ネットワーク

をすべて調査します。

写真、型番、配線図を残します。

Phase 2　セキュリティ要件を決める

「何をしたいか」ではなく、

「何が起きてはいけないか」

から決めます。

たとえば、

室内スマホによる誤解錠禁止

退職者の入室禁止

Internet障害でも通常入室可能

火災時は安全に退出可能

管理者の操作は全部記録

API障害で通常入室へ影響しない

などです。

Phase 3　設計

決めるものは、

Controller
Reader
電気錠
DPI
REX
FAI
カメラ
VLAN
Entra ID
SCIM
API
Webhook
ログ
権限
監視

です。

Phase 4　机上PoC

工事前にテスト環境を作ります。

ここでBLEやAPIを全部試します。

Phase 5　自社プログラム開発

Codexなどを使って、

社員同期

アクセスログ保存

Webhook

SIEM連携

異常通知

権限監査

退職者チェック

を作ります。

Phase 6　施工会社へ渡す

施工会社には「Verkadaを付けてください」ではなく、設計書を渡します。

最低限、

機器一覧

配線図

電源仕様

錠前仕様

fail-safe / fail-secure

DPI

REX

EOL

FAI

ネットワーク

設置位置

テスト仕様

まで決めます。

つまり、

設計はこちら、物理施工は専門業者

という役割分担です。

これはかなり現実的です。

施工会社に必ず確認すること

特に、

電気錠メーカー保証
Verkada対応
電圧
電流
ケーブル
接地
FAI
防火設備
避難経路
非常解錠
UPS
電源断時の状態

を確認します。

電気錠は防犯設備であると同時に、状況によっては避難設備にも関係します。

この部分だけは自作DIYの延長で扱わない方が安全です。

本番移行は一発切替しない

おすすめは、

既存システム
+
Verkada PoC

で先に確認し、

その後、

1ドアだけVerkada
↓
1週間～数週間検証
↓
問題なし
↓
他のドア

と段階展開する方法です。

本番判定基準

少なくとも私は次を満たさない限り本番化しません。

□ 室内スマホで外部リーダーが誤解錠しない

□ 無権限ユーザーで開かない

□ 退職者で開かない

□ Internet切断でも想定通り動く

□ 電源断時が設計通り

□ 火災時が設計通り

□ DPI断線を検出

□ REX異常を検出

□ ドア開放を検出

□ API停止でも通常入室可能

□ 管理操作を監査可能

□ 管理者権限が最小化されている

□ 施工会社権限を削除済み

□ 復旧手順が文書化されている

□ 緊急時手順が文書化されている

やってはいけない設計

特に避けたいのが次です。

市販BLEセンサー
↓
Raspberry Pi
↓
Python
↓
Verkada admin_unlock
↓
ドア

一見すると簡単です。

しかし、

BLE誤検出
Linux障害
Pythonバグ
APIキー漏えい
ネット障害
条件式ミス

のどれか1つが解錠につながる可能性があります。

今回の目的には向きません。

「便利機能」と「安全装置」を分離する

今回の設計で一番大切な考え方はこれです。

安全装置

Reader
Controller
Lock
DPI
REX
FAI

と、

便利機能

API
Webhook
自社アプリ
ダッシュボード
Teams通知
分析

を分離します。

便利機能が全部壊れても、

ドアの基本的な安全性は変わらない

ようにします。

私ならこう作る

一般的な企業玄関なら、

AD34
+
AC43
+
既存電気錠
+
DPI
+
必要に応じてREX
+
FAI
+
入口カメラ
+
Verkada Pass
+
Entra ID
+
Webhook

を基本形にします。

BLEは、

短距離
+
Intent Unlock

です。

完全ウォークスルー方式にはしません。

社員はスマホをポケットに入れたまま、

リーダーへ手をかざして入る。

これなら利便性はかなり高いまま、誤解錠を減らせます。

さらにセキュリティを上げるなら

外部玄関では、

BLE Intent Unlock
+
DPI
+
カメラ
+
Tailgating Detection
+
Webhook監視

まで入れます。

そしてサーバールームなどは、

AD64
+
カード
+
PIN

へ切り替えます。

このように、

場所によって認証強度を変える

方が合理的です。

FAQ

Verkadaだけでテスラのようなスマホキーを作れる？

かなり近い体験にできます。

Verkada PassとAD34/AD64のBluetooth Intent Unlockを使えば、スマートフォンをポケットに入れたまま入室できます。

自分でBluetoothプログラムを書く必要はある？

基本的にはありません。

BLE認証と解錠判断はVerkadaに任せる方が安全です。

自作するなら社員同期、ログ、Webhook、監視などがおすすめです。

出るときにBluetoothで開かないようにできる？

最も確実なのは、Bluetooth Readerを入口側だけに設置することです。

出口側は機械式ハンドルまたはREXにします。

出口側にもReaderが必要な場合は？

Verkadaには2リーダーを使うIn/Out Door構成があります。

ただし、出口側だけBLEを完全に無効化できるかなど、現在のCommand・ファームウェアで必要な粒度の設定ができることをPoCで確認します。

希望する動作が保証できなければ、出口側にはBLE Readerを使いません。

APIでドアを開けてもいい？

限定用途なら可能です。

ただし通常社員の入室処理には使わない方が安全です。

特にユーザー権限を無視する管理者解錠APIを自動化へ組み込む場合は極めて慎重に扱います。

ISMS対応になる？

Verkadaを入れただけではISMS対応にはなりません。

リスク評価、アクセス権管理、ログ、監視、変更管理、インシデント対応、内部監査などを自社ISMSへ組み込む必要があります。

一次情報

Verkada Access Controlの製品構成は公式ページで確認できます。
Verkada Access Control公式情報

AD34のBluetooth Intent Unlockはこちらです。
Verkada AD34 Door Reader

Access Controllerの比較はこちらです。
Verkada Access Controllers

Verkada APIについてはこちらです。
Verkada API Documentation

セキュリティとISO認証についてはこちらです。
Verkada Trust・Security

ISMSについてはJIPDECの情報も確認しておくと安心です。
JIPDEC ISMS関連情報

この記事で学べることまとめ

Verkadaを使えば、既存の電子錠を活用しながらスマートフォン中心の入退室管理へ移行できる可能性があります。

そしてAD34やAD64のIntent Unlockを使えば、単純なBluetooth近接解錠よりも誤解錠を抑えた構成を作れます。

しかし、本当に重要なのは、

「Bluetoothで開けられること」ではありません。

重要なのは、

誤検出しても開かない

自作サーバーが壊れても安全

Internetが落ちても安全

配線がおかしくても検知

退職したらすぐ止まる

火災時には安全に避難できる

誰が何をしたか後から確認できる

というシステム全体の設計です。

そのため、Verkadaのネイティブ機能に安全性の中心を置きます。

そしてAPIやCodexで作る自社プログラムは、認証の中心ではなく、

自動化・監視・監査を強化するために使う。

この役割分担にすると、Verkadaの便利さと企業向け入退室管理に必要な信頼性を両立しやすくなります。

結論

Bluetoothで「入るときだけ開ける」はできるのか？

Verkadaには「Intent Unlock」がある

「完全自動」と「Intent Unlock」は分けて考える

それでも誤解錠が絶対ゼロになるわけではない

誤解錠を減らすための入口設計

AD34とAD64はどう使い分ける？

普通の事務所入口

サーバールーム

金庫・重要情報区画

既存の電子錠をそのまま使える可能性は高い

fail-secureとfail-safeを理解する

fail-secure

fail-safe

可能なら「退室時に電気的解錠を必要としない」構造が強い

REXには注意が必要

DPIは必ず付けたい

DPI・REX配線にも改ざん検知を入れる

火災報知設備との連携を忘れてはいけない

コントローラはどう選ぶ？

おすすめ全体構成

Codexでプログラムを書くなら「解錠」より周辺を作る

APIキーの扱い

解錠APIには2種類あるので注意

自作するならuser_unlockを使う

APIのおすすめ用途

社員入社

異動

退職

Webhookで監視システムを作る

Webhookは解錠制御ではなく監視へ使う

カメラも入口に付ける価値が高い

ISMSを考えるなら「VerkadaがISO認証済み」で終わらせない

Verkada導入で特に見るISMS項目

権限分離も必要

ネットワークも分離する

「ネットが落ちたらドアが開く」は避けられる

本番前に作る「検証用ドア」

必ず実施したい異常試験

BLE

ドア

ネットワーク

電源

クラウド

ID

最重要テスト「室内のスマホで外から開かないか」

高セキュリティドアではBLEを使わない判断も必要

導入プロジェクトの進め方

Phase 1 現状調査

Phase 2 セキュリティ要件を決める

Phase 3 設計

Phase 4 机上PoC

Phase 5 自社プログラム開発

Phase 6 施工会社へ渡す

施工会社に必ず確認すること

本番移行は一発切替しない

本番判定基準

やってはいけない設計

「便利機能」と「安全装置」を分離する

私ならこう作る

さらにセキュリティを上げるなら

FAQ

Verkadaだけでテスラのようなスマホキーを作れる？

自分でBluetoothプログラムを書く必要はある？

出るときにBluetoothで開かないようにできる？

出口側にもReaderが必要な場合は？

APIでドアを開けてもいい？

ISMS対応になる？

一次情報

この記事で学べることまとめ

コメント

Phase 1　現状調査

Phase 2　セキュリティ要件を決める

Phase 3　設計

Phase 4　机上PoC

Phase 5　自社プログラム開発

Phase 6　施工会社へ渡す