施設別ソリューション
配送拠点の車両ヤードでゲートと扉を入退連動させる設計の考え方
目次
配送拠点の車両ヤードで、ゲートと建物の扉を入退連動させたい。そんな声が現場から上がってきていないでしょうか。トラックはゲートで受け付けて通しているのに、降りたドライバーが向かう待機所やトイレ、事務所の受付、倉庫の通用口は誰でも開けられる。このような「車両は管理できていても、人の管理が途切れている」状態は、多くの物流拠点で見られます。
車両側と人側の役割分担、予約情報とQRコードで扉をつなぐ構成、ヤード周りの扉の分け方。この3点を押さえると、自拠点で何から手を付けるべきかが見えてきます。
配送拠点の車両ヤードで入退連動が求められる理由
結論から言うと、車両ヤードの入退連動では「車両ゲートの管理」と「人が通る扉の管理」を、同じ受け入れ情報でつなぐことが要になります。ナンバー認識やRFIDは車両側の専用システムに任せ、ドライバーや作業者が通る扉は電気錠と認証リーダーで管理する。この分担で考えると、構成が決めやすくなります。
車両入退場管理システムは、受付手続きや待機時間の管理を自動化・省力化する目的で使われています。参考情報では、物流効率化法への対応に向けて荷役時間や滞留時間を正確に計測・分析する用途も紹介されていました（Metoree）。法令上の具体的な義務の範囲は、最新の公式情報をご確認ください。
一方で、記録が「車両が何時に入って何時に出たか」で止まっていると、ヤードの中で人がどこへ行ったかは分かりません。
現場でよくある例として、朝の入荷ピークに受付が混み合い、待ちきれないドライバーが倉庫側の通用口からそのまま構内へ入ってしまうケースがあります。悪意がなくても、フォークリフトの動線に人が入り込めば事故につながりかねません。夜間に無人の待機所から倉庫へ抜けられる扉が開いたまま、というご相談も少なくないものです。ゲートの記録と扉の記録が別々で、あとから突き合わせられないと感じたことはありませんか？
Q: 配送拠点の車両ヤードでいう「入退連動」とは何ですか？
A: 車両ゲートの受け入れ情報と、ドライバーや作業者が通る扉の入退室を一続きで管理する考え方です。予約や受付の情報を、扉の認証と記録にもつなげます。
トラック予約システムとゲート認証を連動させる流れ
車両ゲートと予約情報の連動は、物流の現場ではすでに一般的になりつつあります。
参考情報では、運送会社が使うトラック予約システムとゲートの認証システムを統合する方法が紹介されていました。予約の段階で車両情報や運転手ID、入庫予定時刻などを登録し、ゲート通過時にナンバー認識や顔認証で得た情報が予約と一致しなければ入庫を拒否して警備員に知らせる、という流れです（ナック電子）。カメラでナンバーを読み取ってクラウドで記録し、未登録の車両を検知したらアラートを出す仕組みもあります（アイエックス・ナレッジ）。
意外に思われるかもしれませんが、つまずきやすいのはゲートより「その先」です。車両の照合ができても、ドライバーが待機所に入るための鍵やカードを受付で手渡ししていては、受付の混雑は解消されません。
人側を連動させるなら、予約情報から扉で使える認証情報を用意しておくのが現実的でしょう。たとえば予約が確定した時点で、御社の予約システムがQRコードを発行してドライバーに送る。ドライバーはゲートを通ったあと、そのQRコードで待機所やトイレの扉を開ける。退場後は登録を消す、という運用です。QRコードの有効期限や再発行の扱いは、一般にシステムによって異なるため、使う予約システムの仕様に合わせて決めてください。
連動させる前に、少なくとも次の情報が予約・ゲート・扉の間で共通に扱えるかを確かめておくと、後戻りが減ります。
- 予約番号や受付番号など、車両と人を結びつける共通のキー
- ドライバーが入ってよい扉と時間帯
- 退場や予約取消のときに扉の登録を消す手順
- 照合が合わなかったときに誰へ知らせるか
御社の予約システムに、外部とデータをやり取りする口（API）はあるでしょうか。ここが連動の範囲を大きく左右します。
Q: トラック予約システムと扉の認証はどうつなぎますか？
A: 予約確定時に予約システム側でQRコードなどの認証情報を用意し、APIで扉の管理システムへ登録する方法が一般的です。退場後は登録を削除します。
車両ヤード周りの扉をどう分けるか：ドライバー動線と構内の境界
扉の管理は、ヤードを「誰が入ってよい場所か」で区切るところから始まります。
一般的な配送拠点なら、ヤードに面した待機所とトイレはドライバーに開放する場所です。事務所の受付は手続きのために入る場所、倉庫の通用口から先は自社の作業者だけが入る場所、という整理になるでしょう。高額品や危険物の保管エリアがあれば、そこはさらに限られた人だけにします。正直なところ、この区分を図面上で決めておくだけでも、どの扉に何の認証が必要かが自然に絞れます。
現場でよくある例として、夜間の着荷で受付スタッフがいない時間帯に、ドライバーが伝票を置きに事務所へ入れてしまい、その奥の倉庫まで素通りできる構造になっているケースがあります。こうした場所では、事務所前に小さな前室を設け、外側の扉が閉まらないと内側の扉が開かない「インターロック」という仕組みを使う方法があります。共連れ（認証した人の後ろについて入ること）を減らす狙いです。
認証した人がいったん出ないと次に入れない「アンチパスバック」や、曜日と時間帯で通れる人を変えるスケジュール設定も、ドライバーと作業者の動線を分けるのに役立ちます。
屋外やヤードに直接面した扉では、雨風の影響も考えなければいけません。防水等級は機種ごとに異なるため、リーダーを選ぶ段階で設置場所の環境を伝えて確認するのが確実です。扉のこじ開けや閉め忘れを警報で知らせる設定も、無人時間の多い拠点では検討の価値があります。
御社のヤードで、ドライバーが「本来入らなくてよい場所」まで歩いて行けてしまう扉は何枚あるでしょうか。
Q: 車両ヤードに面した倉庫の通用口はどう管理すればよいですか？
A: 作業者だけが通れる扉としてカードや指紋で認証し、ドライバー用の待機所の扉とは権限を分けます。前室を設けてインターロックを組む方法もあります。
Lavishで組む配送拠点の扉の入退連動
ここからは、弊社の電気錠ブランドLavishで、ヤード周りの扉を予約情報とつなぐ構成を紹介します。Lavishが担うのは人が通る扉の側で、車両ゲートの機器そのものではありません。既存の車両ゲート設備と信号をやり取りできるかは設備側の仕様によるため、個別にご相談ください。
予約システムと扉をつなぐ方法は2通りあります。
ひとつはクラウド経由の構成です。QRコードリーダー RER-QR3M（QR・バーコード・MIFARE® カード）または RER-QR2M（QR・MIFARE® カード）を、ネットワーク制御器 COA-23F／COA-45F につなぎ、クラウドゲートウェイ GW-2 を追加します。これで弊社のクラウドサービス WatchKey につながり、WatchKey の REST API から、QRコードの値をカード番号として登録・削除できます。QRコード自体は御社の予約システムや運用に合わせて用意していただく形です。同じリーダーでカードも読めるので、自社の作業者はカード、ドライバーはQRコードという使い分けができます。
もうひとつは、API制御のQRコードリーダー RER-QR3M-LAN、RES-QR6M-MQTT（MQTT）を、御社のシステムと直接つなぐ構成です。こちらはAPIプロトコルを公開しており、利用料は無料です。WatchKey・GW-2・COA を経由しない点が、クラウド経由の構成との違いになります。
COA-23F／45F 側では、前のセクションで触れたインターロック、アンチパスバック、曜日・休日スケジュールを設定できます（ネットワーク対応制御器）。WatchKey では入退室履歴を期間・扉・利用者で絞り込めるほか、メールやWebhookで扉ごと・出来事ごとに通知できます。回線が切れても、COA に登録済みのカード・QRコードで入退室は続けられます。
屋外に面した作業者用の扉には、IP66準拠の屋外用リーダー RESCR-SHF3ME（指紋・カード・暗証番号）が候補です。QRコードリーダーを屋外に近い場所へ置く場合は、庇の有無など設置環境も含めてご相談ください。
Q: Lavishの電気錠はトラック予約システムと連携できますか？
A: COA-23F／45F＋GW-2 の構成なら、WatchKey の REST API で予約システムからQRコードの値をカード番号として登録・削除できます。
WatchKey の利用料は月額0円、APIの利用料・連携料も無料です（機器代・施工費・回線費は別途。連携開発を弊社でお受けする場合は有償）。全製品に2年保証が付き、故障時は弊社が修理・交換します。扉への取り付けや機器同士の配線には専門の知識が必要なため、施工は弊社またはお付き合いのある施工店にお任せください。弊社へ直接ご相談いただければ、現地調査・お見積りから施工まで承ります。
工場・倉庫での使い方は工場・倉庫・店舗向けのご案内に、予約システムとQRコードをつなぐ流れは予約・会員システムとつないで、QRコードで入ってもらうにまとめています。待機所、通用口、事務所受付と、まずは扉の一覧と予約システムの仕様をお手元にご用意のうえ、お問い合わせからご相談ください。
