GUEST PIN OPERATION

鍵の「お伝えしてよい番号」— 運用に載せるためのカルテ

締め出しの夜に番号をお伝えできるようにする件です。受け口(Curtis 側)は完成していて、あとは施設ごとに1つ番号を決めれば解禁されます。調べたところ、詰まっているのは「番号を決めること」ではなく「いま現地にある番号を1回確かめること」でした。台帳に載っているキーボックスの番号は4邸とも記録が古く、そのまま登録できるものが1つもありません。

要判断 3追認 45
このカルテで決まること: ①RemoteLock を Frank に触らせるか ②玄関の暗証しか無い2邸をどうするか の2点だけです。残りは私の設計判断なので、違うところだけ触ってください。番号そのものはこのページに書いていません(公開ページのため)。

要判断3 件

Otakeさんにしか答えが無いものだけ。ここをお願いします。

Q1

RemoteLock の操作を Frank に持たせますか要判断

権限の拡張・不可逆ではないが外部システムに触る

「リモートロックのページを制御できるようになってもらって、番号を作って入れ込む」というお話でした。調べた結果、API は実在し、有効期限つきの本当のワンタイム番号が組めます。ただし日本は構造計画研究所(KKE)扱いで、API の利用申込みと OAuth アプリの登録申請(クライアントID取得)が別途必要です。外部システムへ書き込む権限になるので、推奨は置かずお伺いします。

無回答なら ここだけは無回答で進めません。ご返答をお待ちします(その間、物理側の準備は止めずに進めます)

Q2

玄関の暗証しか無い2邸(逗子葉山・南房総)をどうしますか要判断

2邸ぶん・お金がかかるのは①のみ

この2邸は、玄関そのものが暗証番号で、その後ろに控える錠がありません。玄関の常用暗証をお伝えすると、変えるたびに滞在中の会員様と予約システム側の発行済み番号を巻き込みます。他の4邸のように「ボックスの番号 → 中の鍵 → 玄関」という一段ずれた経路が無い状態です。

推奨 ② 当面は開示対象外のまま(この2邸で締め出しが起きたら人へお渡しする) — ①は要るものですが、まず4邸で1周回してから足したい(回る前に金物を買うと、運用が変わったときに無駄になる)。③は変更のたびに滞在中の会員様と予約システムを巻き込むので採れない

無回答なら ②で始めます。この2邸は当面、鍵の番号を一切お伝えしません

自由記述要判断

追認4 件

私が決めました。違うものだけ触ってください(無操作=この通り進めます)。

A1

番号は「玄関」ではなく「その後ろのキーボックス」に付ける追認

実態館山・京都・軽井沢アトリエ・渋谷の4邸は、すでにこの形を持っています(ボックスのダイヤル → 中の捨てマスターキー → 玄関)。渋谷には障害時にこれを使う運用の記録もありました。
提案この4邸のキーボックスを、お伝えしてよい番号の付け先にします。玄関の常用暗証・予約ごとの番号には付けません。

推奨 ① この線でいい — ②は、番号を変えるたびに滞在中の会員様と予約システムの発行済み番号を巻き込む。キーボックスなら現地でダイヤルを回すだけで、どのシステムにも触れずに失効させられる

無回答なら この線で進めます

A2

番号を変えるのは「使ったときだけ」。次のアウト清掃に1行足す追認

実態清掃は巡回ではなく、チェックアウトのたびに入っています(11:15〜・施設別LINEグループ・写真報告つき)。次のご滞在が終われば必ず人が現地に立ちます。
提案定期のローテーションは作りません。お伝えした日に Slack が鳴る → 次のアウト清掃の連絡に「番号の変更」を1行足す → 清掃が回して新しい番号をLINEに1行 → 私が台帳を直して同期。清掃側の追加負担は1回2分ほど、頻度は締め出しの頻度そのもの(年に数回)です。

推奨 ① この線でいい — ②は、変えても誰も得をしないのに毎回「番号が変わりました」の伝達が発生する。この番号は使われて初めてリスクになる種類のものなので、使われた時だけ変えるのが釣り合う

無回答なら この線で進めます

A3

現地確認から180日を過ぎた番号は、お伝えしない(無言にする)追認

許可リスト方式のため、現地が新しくなって台帳が古いままだと、古い番号が「許可済み」として送られてしまいます。締め出された会員様に違う番号をお渡しするのは、答えないより悪い状態です。
提案台帳に「現地確認: 日付」を持たせ、日付が無い番号・180日を過ぎた番号は同期しないようにしました。運ばれなければ既定どおり全遮断になるので、ローテーション漏れが「間違った番号」ではなく「答えない」に落ちます。180日は施設ファクト健診の要対応ラインと同じ線です。

推奨 ① この線でいい — ②も安全ですが、短くするほど「無言になる夜」が増えます。番号は定期的には変わらない性質なので、まず180日で走らせて、実際に漏れたら縮めます

無回答なら 180日で進めます

A4

まず館山1邸だけで1周回す追認

提案館山で「現地確認 → 台帳へ記入 → 同期 → お伝えできることを確認 → 使ったら変える」まで通してから、京都・軽井沢アトリエ・渋谷へ広げます。館山を選んだのは、捨てマスターキー使用後のLINE報告がすでに運用として存在し、報告の経路を新設せずに済むためです。

推奨 ① 館山から — ②は、段取りに穴があったとき4邸ぶん巻き戻すことになる。1邸で1周回してからのほうが結局早い

無回答なら 館山から始めます

5 件

実装・反映済みの事後報告。読むだけで大丈夫です。

✓1

錠の実態を12邸ぶん洗いました

構想どおりの形(ボックス → 中の鍵 → 玄関)をすでに持っているのは4邸。玄関そのものが暗証なのが2邸。鍵の記録自体が無いのが6邸(河口湖・九十九里・軽井沢コアI/II・晴海・南葉山)でした。

推奨 ① 把握した

✓2

台帳に載っている4邸の番号は、全部が古すぎて使えませんでした

渋谷は1年半前、京都は10か月前、軽井沢アトリエは7か月前、館山は6か月前の記録です。着手条件は「番号を決めること」ではなく「いま現地にある番号を1回確かめること」でした。ここが今いちばん詰まっている場所です。

推奨 ① 現地確認を手配する

✓3

鮮度の関所を実装し、運用を正本に書きました

同期スクリプトに日付の関所を入れ、運用の正本(会員様対応プレイブック)に「どの錠に付けるか」「ローテーションの5段」「RemoteLock の2つの型」を追記。Frank の担当表にも「都度 — 鍵の開示番号」を足しました。現在の状態は 0/13 邸=全遮断(安全側)です。

推奨 ① 把握した

✓4

締め出しには2つの型があり、混ぜないことにしました

①番号を失っただけで錠は生きている → RemoteLock 側で出し直せば済む ②錠が死んでいる/そもそも物理のダイヤル錠 → お伝えしてよい番号の出番。Otake さんが挙げられた場面は②でした。②を先に通します(①だけ自動化しても、肝心の場面が空くため)。

推奨 ① この整理でいい

✓5

Slack の通知先だけ、まだ空のままです

お伝えした瞬間に「番号を変えてください」が飛ぶ先(SLACK_CONCIERGE_CHANNEL)が未設定です。無くても番号はお伝えできますが、変える合図が誰にも届きません。運用を始める前にここだけ埋まっている必要があります。

推奨 ① チャンネルを用意する

回答テキスト(自動生成・差分だけ出ます)

下の枠内で Ctrl+A → Ctrl+C でコピー
コピーしました