予約API /bookings の自動判定
直前の予約にも、
プールPINなら間に合う。
プールPINなら間に合う。
予約が確定した瞬間、新しいアクセスキーを発行するか、あらかじめプールしておいたPINを払い出すか。RemoteLOCKクラウドは、受け取った
POST /bookings だけを見て、その場で自動的に判断しています。連携サービス側のリクエストは、いつもとまったく同じままです。対応機種 9モデル
設定目安 宿泊 2〜3個 / デバイス
1デバイスの上限 30個
払い出し名 pool_guest_xyz
プールPINが活きる場面
通信を待っていられない瞬間がある
いずれもRemoteLOCKヘルプセンターが利用を推奨しているケースです。共通するのは「発行してからPINが使われるまでの時間が短い」こと。
フロント・受付での即時発行
お客様の来訪その場でカギを発行する施設では、通信を待つ数秒が体感を左右します。
直前予約が多い施設
予約から入室までが短いほど、デバイスとのPIN同期が間に合わないリスクが高まります。
夜間無人での運営
スタッフが不在の時間帯ほど、通信トラブル発生時のリカバリーが難しくなります。
Wi-Fi環境が不安定な施設
ハートビート間隔を広めに設定している施設ほど、あとで出てくる閾値が大きくなり、プールPINが使われる場面が増えます。
プールPINの正体
予約が来る前から、プールは静かに補充され続けている
プールPINは、予約のたびに作られるものではありません。RemoteLOCKクラウドは設定した保有数を保つようプールPINをあらかじめ生成し、ハートビートのたびにデバイスへ同期しています。連携サービスからの予約が無くても、プールPIN自体は定期的に更新され続けます。
① ハートビートでプールPINがデバイスに入る。② 直前予約が届くと、クラウドは③でプールPINをその場で払い出して在庫が1つ減る。④ 減った分はクラウド側で補充され、
rapid_mode が false なら即時、true なら12時間ごとの定期メンテナンス時です。⑤ 補充されたPINがデバイスに届くのは次のハートビート。
「補充」と「デバイスへの同期」は別のタイミングです。在庫が戻るのはクラウドの中で、デバイスがその新しいPINを受け取るのは次のハートビートです。プールPINが直前予約に間に合うのは、使う分がすでにデバイス側にあるからです。
個別の予約が来た瞬間
同じリクエストなのに、返ってくる鍵が自動で変わる
POST /bookings を受けたRemoteLOCKクラウドがどちらの経路を選ぶかは、予約開始時刻（starts_at）が「現時刻 ＋ 閾値」より前かどうかで決まります。連携サービス側の実装や送るデータは、どちらの場合も変わりません。
閾値より後
新規アクセスキーを発行
まだ余裕があるので、クラウドはその場で新しい暗証番号を発行し、デバイスへ同期してからレスポンスします。
閾値より前
プールPINを払い出し
間に合わないので、クラウドはあらかじめデバイスに同期済みのプールPINをそのまま返します。デバイスへの新規同期は発生しません。
| ハートビート間隔 | ハートビート間隔 × 3 | 閾値 = MAX(左, 2時間) |
|---|---|---|
| 5分 | 15分 | 2時間 |
| 15分 | 45分 | 2時間 |
| 30分 | 90分 | 2時間 |
| 1時間 | 3時間 | 3時間 |
| 2時間 | 6時間 | 6時間 |
| 4時間 | 12時間 | 12時間 |
| 8時間 | 24時間 | 24時間 |
| 12時間 | 36時間 | 36時間 |
ネットワーク切断と判定されたデバイスは、この表にかかわらず閾値が一律36時間になります。ハートビート間隔が長いほど閾値も大きくなり、プールPINが使われる場面が増えます。そのかわり、通常発行したPINがデバイスに届くのは遅くなります。
プールPINが使われたかどうかは、レスポンスで分かります。予約のJSONレスポンスに
"meta": "pooling" が入っていれば、プールPINが採用されています。クラウド管理画面でも、プールPINゲストの名前が予約したゲストの名前に変わることで見分けられます（PINやQRコードの値は変わりません）。プールPINが採用されない場合
PINかQRコードを指定した リクエストで値を指定すると通常発行になります
プールPINが未同期 デバイスにまだプールPINが入っていない
同期済みのプールゲスト期間外 同期されているプールPINの有効期間から外れている
いずれも プールPINの仕様について に記載があります。
対応範囲
対象デバイスと発行できる形式
プールPINの対象は、RemoteLOCK主要機種と予約API
/bookings から発行される暗証番号です。機種によっては、PINだけでなくQRコードにも対応しています。| 対応デバイス | PINコード | QRコード |
|---|---|---|
| RemoteLOCK 5i | ○ | ― |
| RemoteLOCK 7i | ○ | ― |
| RemoteLOCK 8j | ○ | ― |
| RemoteLOCK 8j-F | ○ | ― |
| RemoteLOCK 8j-Q | ○ | ○ |
| RemoteLOCK 9j | ○ | ― |
| RemoteLOCK 9j-Q | ○ | ○ |
| RemoteLOCK 500i | ○ | ― |
| RemoteLOCK 700i | ○ | ― |
| RemoteLOCK 900j-F | ○ | ― |
| RemoteLOCK 900j-Q | ○ | ○ |
| TOBIRA | ○ | ○ |
※TOBIRAで利用できる暗証番号の詳細はTOBIRAでのQRコード・カードキーを利用する際の設定（APIの予約エンドポイント利用時）を別途ご確認ください。
igloohomeとSADIOT ROOMは対象外です。 igloohomeはデバイス側の計算で暗証番号を決める方式のため、クラウドが先に配っておくという形をとれません。SADIOT ROOMはURL解錠の製品で暗証番号を使いませんので、プールしておく対象がありません。予約APIから使えるデバイスのうち、対象外はこの2つで、それ以外は上の表のとおりです。
利用開始までの流れ
設定はRemoteLOCKクラウド側だけで完結
連携サービス側の予約API実装を変更する必要はありません。有効化はクラウド管理画面から行います。
RemoteLOCKクラウド管理画面「システム連携 → Bookings API設定」の実際の画面。この画面でプールPIN数やハートビート間隔を設定し、右側の「プールピンメンテナンス情報」でプールPINが実際にいつ補充されたかを確認できます。
STEP 1
予約システムとのAPI連携を設定
予約API
/bookings に対応した連携サービスであることを確認し、事前にAPI連携を設定します。STEP 2
「Bookings API設定」で有効化
RemoteLOCKクラウド管理画面の「システム連携 → Bookings API設定」からプールPIN機能にアクセスし、有効化します。
STEP 3
保有するプールPIN数を設定
1日1部屋あたりに利用される最大数を目安に設定します。設定値はアカウント内の各デバイスに適用されます。デフォルトは0で無効、1デバイスあたりの上限は30個です。
STEP 4
ハートビート間隔もあわせて設定
同じ画面の「ハートビート間隔」に、アカウント内のデバイスの最大ハートビート（分）を入れます。デバイス側の設定（「デバイス」→「設定」）と両方そろえておくと、閾値が想定どおりに効きます。
設定数の目安
ホテル等の宿泊施設 2〜3個 / デバイス
時間貸しの施設 3〜7個 / デバイス
1デバイスあたりの上限 30個
発行されたプールPINは、管理画面上に
pool_guest_xyz のような名前で表示され、有効な暗証番号として機能します。
プールPINは、通信環境そのものを不要にする機能ではありません。 直前の利用や一時的な通信トラブルに備えるための仕組みであり、デバイスの設置環境にWi-Fi等の通信環境は引き続き必要です。
連携サービス側の実装は、変わらない。
予約が入るたびに、新規アクセスキーかプールPINかをRemoteLOCKクラウドが自動で選んでいます。連携サービス側はこれまで通り
POST /bookings を送るだけで構いません。社内共有・パートナー説明用資料