ロッカー運用の現場には、
「データ上の状態」と「現実の状態」が一致しない瞬間 が必ず存在します。
今回、荷物回収業務で使用されていたツールは、
この“状態不整合”を見逃しており、
- 誤った荷物を抽出する
- 本来回収すべき荷物が漏れる
- 最終チェックが人手で属人化
という問題が発生していました。
この記事では、
- なぜ抽出ロジックが破綻していたのか
- 荷物ログからどうやって不整合を突き止めたのか
- 時系列のズレをどう修正したのか
- 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的な改善は十分できる
実際の現場では、
小さな非破壊的改善こそ、一番効果を生む
——そんなことを再認識した事例でした。