物置とロッカー向けソフトウェア

ロッカー向けプログラム — は、誰にどのロッカーを渡すかを決め、必要なときにその電子錠を開け、開放のたびに記録を残すシステムです：誰が、いつ、どのような根拠で開けたのかを。

普通のキャビネットとの違いは、一つの例で分かります。鍵や南京錠であれば、ロッカーに責任を持つのは人です：鍵を渡し、番号を覚え、返してもらう。鍵をなくせばこじ開けることになり、争いになればシフトの記憶で決着をつけ、今いくつ空いているかを知っているのは、そばに立っている人だけです。

自動化されたロッカーに鍵はありません。扉を開ける権利はデータベース上の記録です：このコードは、このロッカーに対して、この時刻まで有効である、と。コードは、キャビネットに近づかずに、発行も、取り消しも、延長も、他の人への引き渡しもできます。そしてすべての施設のすべてのロッカーの使用状況が、一つの一覧で見えます。

例。 商業施設の来館者が荷物をロッカーに預けます：画面でQRコードを読み取ると扉が開き、閉めて立ち去ります。二時間後、同じコードで同じロッカーを開けます。システムには二件の開放の記録、保管の開始時刻、そしてロッカーが空いて次の利用に備えたという記録が残ります。

コインロッカーの自動化 が始まるのは、三つの問いへの答えが係員の頭に収まらなくなったときです：今いくつのロッカーが使われているのか、今日の14:20に特定のロッカーを開けたのは誰なのか、そして二日目になっても置かれたままの荷物をどうするのか。

これはシステムの最も物理的な部分であり、プログラムが真実を語れるかどうかは、ここにかかっています。 電子錠 は短い電気信号で開きます：電圧が来ればかんぬきが引っ込み、扉が自由になります。錠そのものは、人についてもコードについても何も知りません。

コントローラー — はキャビネットの中の機器で、錠とセンサーがつながっています。サーバーから「ロッカー27を開けよ」という命令を受け取り、該当する出力へ信号を送り、結果を返します。一台のコントローラーが数十のロッカーを扱うため、キャビネットは一本の通信回線でシステムにつながります。

扉のセンサー — は推測と事実を分けるものです。これがなければ、システムは命令を送ったことしか知りません。あれば、扉が実際に開いたこと、そして何秒後に閉まったことまで分かります。センサーの有無は個々のキャビネットの型式の問題であり、着手前に確認します。

機器の接続時に考慮すること：

• 錠の種類 — 瞬間通電型か通電保持型か、かんぬきの位置を返すかどうか
• 扉のセンサーの有無 — システムが「開いた」と「開けようとした」を区別できるかどうかは、これによります
• コントローラーのインターフェース — 命令をどのように渡し、状態をどのような形で返すのか
• コントローラーあたりのロッカー数 — いくつの出力が使われ、キャビネットの拡張用にいくつ残っているのか
• 電源 — 停電時に錠がどうなるのか、予備電源が用意されているのか
• 機械的な開放 — 電気なしでロッカーを開ける非常手段があるか、それを誰が管理するのか

特定のメーカーの錠やコントローラーへの対応を、あらかじめ表明することはしません。接続できる機器の構成は、メーカーの資料と、その機器が外部へどのようなインターフェースを提供しているかに基づいて事前調査で決めます。既製のインターフェースがない場合は、互換性を約束するのではなく、着手前に個別に解決します。

決済モジュールはすべての施設に必要なわけではありません：社員用のロッカーやクラブの更衣ロッカーは、お金なしでまったく問題なく動きます。しかしロッカーを貸し出す場合、お金はセッションの一部になり、精算の規則はアクセスの規則と同じくらい厳密に定めなければなりません。

金額はどう計算されるか。 料金はロッカーの寸法区分と時間に紐づきます。よくある方式は：一セッションあたりの定額、切り上げを伴う時間単位（一時間、一日）の料金、最初の一時間が以降より高い段階制、そして長期の定額利用です。

いつ支払うか。 これも案件ごとの選択です。選んだ時間分を前払いし、延長時に追加で支払う方式が、施設にとって最も単純で見通しがよいものです。セッション終了時の後払いは、その人が支払うという保証 — たとえばカードでの事前の与信 — を必要とします。

システムの決済にかかわる部分：

• 料金 — 寸法区分、施設、時間帯、曜日ごとに
• 金額の計算 — 実際のセッションの長さに基づき、切り上げの規則を伴って
• 延長 — セッションを終えずに、追加の時間分を支払うこと
• 期限超過 — 支払い済みの時間を超えた分に対する別の料金
• 返金 — ロッカーの割り当てが成立しなかった場合、代金は施設に残らず返金されます
• 支払いとセッションの結び付き — 双方向です：セッションから支払いが見え、支払いからロッカーと時刻が見えます
• 突き合わせ — 決済サービスの台帳との毎日の照合

境目ははっきり示します。 具体的な支払い方法 — カード、非接触決済、QR、アプリでの支払い、キャビネットの紙幣識別機での現金 — は、接続する決済サービスとキャビネットの機器によって決まります。これは、どの案件でも使える組み込みの機能ではなく、構成を事前調査で決める連携です。会計にかかわる要件は、その国の法令と機器の型式によって定まります。

キャビネットは無人で置かれています。それがこの設備の最大の特徴です。つまり、故障はシステムが自ら知らなければなりません — さもなければ、荷物の入ったロッカーが開かなかった来館者から知らされることになります。

常に監視されるもの：

• キャビネットとの通信 — コントローラーが時間どおりに通信に出てくるか、許容の間隔より長く沈黙していないか
• 錠の応答 — 命令でロッカーが開くか、センサーが結果を確認するか
• 扉の状態 — 閉、開、規定より長く開いている、命令なしに開いた
• 電源 — キャビネットに電圧があるか、どの時点で失われたか
• 周辺機器 — 読み取り機、画面、カードリーダー、決済部が動いているか
• コントローラーのエラー — 型式が対応していれば、コントローラー自身が知らせるコード

沈黙もイベントです。 通信に出てこないキャビネットは「異常なし」を意味しません：二百のロッカーと中の荷物の状態について、何も分からないことを意味します。そのため通信の途絶は、監視に空白を残すのではなく、錠の故障と同じイベントを生みます。

故障したロッカーはどうなるか。 自動的に選定から外れます：次の人には提示されません。キャビネット番号、ロッカー番号、故障の内容を添えて、保守部門への作業が作られます。ロッカーを運用に戻せるのは、作業完了の記録によってのみです — ひとりでに「治る」ことはありません。

機器の監視の考え方は、私たちが IoT監視のシステムで採るものと同じです：指標、規定値、待機時間、イベント、責任者。違いは、ここで測るのが温度ではなく、錠の応答と通信の有無だという点だけです。

システムがためるデータは多いものの、役に立つのはそのうちのわずかです。実務的に意味を持つのは四つの問いです：ロッカーは足りているか、どの大きさが必要か、どこで時間が失われているか、どの機器がそろそろ保守を要するか。

利用状況が示すもの。 月の平均値ではなく、時間帯と曜日の分布です：施設の平均利用率が45%でも、毎週土曜の14時から18時には小型ロッカーが一つも空いていない、ということがあり得ます。答えは、キャビネットを丸ごと増やすことではなく、必要な大きさのロッカーを足すことです。

施設ごとに集計される指標：

• 利用率 — 時間帯、曜日、寸法区分ごとの使用中のロッカーの割合
• 回転 — 期間中に一つのロッカーを通過するセッションの数
• セッションの平均の長さ — 寸法区分ごと、曜日ごとに分けて
• 貸出の失敗 — 必要な大きさの空きがなく、人がロッカーを得られなかった回数
• 期限超過 — 期限を過ぎたセッションの割合と、それがロッカーを占めていた時間
• 機器の稼働状況 — ロッカーが運用から外れていた時間と、その理由
• 売上 — 有料保管の場合：施設別、寸法区分別、期間別に

貸出の失敗は、最も過小評価されている指標です。 使用状況は誰の目にも見えますが、来てみて空きロッカーが見つからず帰った人は、通常の統計にはまったく残りません。しかし、キャビネットを増やすべきかどうかに答えるのは、まさにこの数字です。

レポートはファイルに出力でき、スケジュールで作成することもできます — たとえば毎月一日に、すべての施設について一度に。