ロッカー運用の現場には、
「データ上の状態」と「現実の状態」が一致しない瞬間が必ず存在します。

今回、荷物回収業務で使用されていたツールは、
この“状態不整合”を見逃しており、

誤った荷物を抽出する
本来回収すべき荷物が漏れる
最終チェックが人手で属人化

という問題が発生していました。

この記事では、

なぜ抽出ロジックが破綻していたのか
荷物ログからどうやって不整合を突き止めたのか
時系列のズレをどう修正したのか
Tampermonkeyで既存システムを崩さず統合した方法
改修で得られた「現場×SRE」的学び

を技術寄りに解説します。

1. 背景：回収ツールが「正しい答え」を出せていなかった

ロッカーサービスでは定期修理のタイミングで残留荷物を回収します。

しかし、既存の抽出ツールは次の課題を抱えていました。

❌ 抽出フィルターが不完全

関係ない荷物が混ざり、最後は人の目で確認が必須。

❌ 状態不整合を扱えない

データ上は「荷物なし」
でもロッカーセンサー上は「荷物あり」
こうした矛盾を検出できない。

❌ 業務フローが分断されていた

抽出 → ダッシュボード検索 → 再チェック → 回収

という往復が発生し、属人化していた。

2. 課題の本質：状態管理が「1つの真実」として扱われていた

抽出ツールは荷物データ（DB）を“絶対的な正”として扱っていました。

しかし現場の実態はこうです。

顧客未受取のまま残留
配達員の誤操作でステータスがズレる
API書き込み失敗
センサーだけが現実を知っている

つまり、複数のシステムが別々の“真実”を持ってしまう。

SRE的に言えば、

Source of Truth が分裂し、整合性が保証されていない状態

この前提が抜け落ちている限り、正しい抽出は不可能です。

3. 本当の原因：荷物ログを追ったら「時系列の崩壊」が見えた

ここからが一番重要な部分です。

僕は不整合の原因を突き止めるために、
ロッカー → スロット → 荷物データ（複数）
という完全な荷物ログを追跡しました。

すると重大な事実が分かりました。

■ロッカーのデータ構造（実態）

ロッカー
    └─スロット1
        ├─荷物A
        ├─荷物B
        └─荷物C（過去分も含む）
    └─スロット2
        └─荷物X, Y …

ここで重要なのは、

スロットには複数の荷物データがあり、正しい順序の再構築が必須

ということです。

API取得の落とし穴：順番が時系列ではない

APIで荷物データを取得すると、

並び順が “内部ID順”
既存ツールはこの順序をそのまま信じていた

これでは正しい時系列が完全に崩れます。

ダッシュボードのソートも“現場の真実”と一致していなかった

ロッカー管理ダッシュボードは
配送開始日時でソートしていました。

しかしこれは荷物がスロットに入った順序とは無関係です。

なぜなら、

スロットが空いていない
実際に入れようとして入らなかった
配達員の操作順が前後する

などの理由で、

配送開始日時＝「スロット内の正しい順序」ではない

という状態が普通に発生します。

真に並べるべきは「配達完了日時」

荷物がスロットに入った“現実の時間”は
配達完了日時によってしか判別できません。

このとき初めて、
スロット内の正しい時系列＝あるべき荷物順
が再構築できます。

まとめると：

既存ツールの破綻理由

API順 → 時系列でない
ダッシュボード順 → 配送開始なので不正確
スロット内の荷物順 → 本来は配達完了日時で並ぶべき

これらのズレが複合的に発生し、
誤抽出／漏れ／異常未検出が起きていました。

4. 改修内容①：抽出ロジックを「現実ベース」に修正

✔ ロッカーセンサー × 荷物ステータスのクロスチェック

DBとセンサーを組み合わせ、“実物ベース”に修正。

✔ 時系列を「配達完了日時」で再構築

正しい荷物順を復元する新ロジックを実装。

✔ 異常パターンを検出

データ：荷物なし
センサー：荷物あり
などの不整合を抽出可能に。

✔ 1クエリで抽出完了するように統合

人手チェックを不要に。

追加改善：既存ツールでは検出できなかった「お化けOccupied」も正しく扱う

荷物ログを深掘りしていく中で、
僕が特に“危険”だと感じたのが「お化けOccupied（Ghost Occupied）」の存在です。（勝手に命名しました）

お化けOccupiedとは？

荷物データ上は「空（Empty）」なのに、
ロッカーセンサー上は「Occupied（荷物あり）」と検知されている状態

この現象は、現場では割と日常的に発生しています。

代表的な原因

センサーの故障（誤検知）
荷物データの書き込み失敗
異常操作（荷物を取り出したが記録されていない）
強制開錠／非常操作の後処理不足
配送員アプリとロッカー本体の状態差分

既存ツールは DBの荷物データしか見ていなかったため、
このような「現実とデータが食い違う状態」を検出できませんでした。

僕が実装した検出ロジック

次のような条件をセットにし、

荷物データ：Empty（＝DB上は空）
センサー：Occupied（＝物理的には何か入っている）

この状態をGhostOccupiedとして抽出するようにしました。

✔ 実際に荷物が残っている場合

→ 回収漏れの防止

✔ センサー故障の場合

→ ロッカー修理の優先度判断に利用
→ 月次修理ルートの最適化にも影響

✔ データ書き込み失敗の場合

→ 配送システム／顧客アプリ側の整合性問題としてエスカレーション

結果：回収業務だけでなく“運用品質”そのものが向上した

Ghost Occupiedを検出できるようになったことで、

誤抽出ゼロ化
回収漏れゼロ化
センサー異常の早期発見
配送側とロッカー側の状態同期バグを早期警戒

と、単なる荷物回収の枠を超えた改善につながりました。

特に、

データ上Emptyのまま放置されていた「実荷物」

これらは定期点検で初めて発見されることも多く、
顧客トラブルに直結しやすい部分です。

5. 改修内容②：Tampermonkeyでダッシュボード統合

✔ 画面内にボタンを追加

抽出
結果表示
該当スロットへのジャンプリンク
を一画面で完結。

✔ ページ往復ゼロへ

従来：ツール → ダッシュボード → 検索 → 再確認
改善後：ダッシュボード1つで完結

6. 成果：属人チェックが消えて、異常荷物の検出率が向上

■技術的な成果

誤抽出がほぼゼロ
時系列の崩壊を修正
異常荷物を確実に検出
抽出〜判定〜確認が自動化

■業務的な成果

手作業チェックが不要に
担当者の品質差が消失
工数が大幅に削減
誰がやっても同じ結果が出る状態へ

7. これは“ただのツール改修”ではなく、SRE的改善だった

以下の点から、今回の取り組みはSREに極めて近いプロセスです。

✔ 状態不整合を検知して仕様として扱った

分散した「真実」を統合。

✔ Toil削減

最後に人がチェックする手作業をゼロへ。

✔ 再現性の向上

UI統合により“誰でも同じ結果”へ。

✔ 安全な変更

既存SaaSはそのまま。Tampermonkeyで非破壊的拡張。

8. まとめ：小さな改修で、運用品質は大きく変わる

今回の改善で得た教訓はシンプル。

実データの順序は、API順・UI順とは限らない
状態管理は常にズレる
不整合を扱ってこそ“現場対応に強いシステム”になる
TampermonkeyでもSRE的な改善は十分できる

実際の現場では、

小さな非破壊的改善こそ、一番効果を生む

——そんなことを再認識した事例でした。