WCSデータ保持：機器ログと警報記録をどれだけ長く残すか

結論から：WCSデータ保持は3文に集約される。1つ、生の秒単位データを30〜90日、分単位集計を1年、日次サマリーと重要イベントは永久に残す。2つ、3層に格納する——現場の産業用PCはホットデータだけ、エッジサーバーは集計と1年分の窓、クラウドはコールドアーカイブ専用だ。3つ、警報記録と操作監査ログは別に切り出し、法令と契約の要求で保持する——機器ログとはまったく別の保持ポリシーだ。以下はなぜこうなっているかと、本稼働前に落とし込む手順だ。

なぜWCSデータ保持はこう分かれるのか：探しに来る人から始めろ

WCSデータを照会するのは3種類の人だけだ。1つ目、事故調査員：何かが壊れた、貨物が損傷した、ラインが止まった、「正確に何が起きたか」を再現する必要がある。生の秒単位データが必要だ——集計では現場を再現できない。2つ目、OEEと効率分析：設備総合効率、ダウンタイム分布だ。集計がほしい。秒単位のポイントから月次OEEを計算する奴はいない、自傷行為だ。3つ目、監査とコンプライアンス：「この警報を誰がいつ確認したか」「どのパラメータを誰が変えたか」がほしい。操作記録、全件だ。

保持ポリシーはこの3人から逆算して作る。誰が、どの粒度で、どれだけ遡って照会するかを決めれば、マトリクスはほぼ自動で描ける。逆に「全部残しとけ、いつか役に立つ」と言う奴は現場を回したことがない。誰も照会しないデータは、保存したことのないデータだ。

最初に逆説的な判断を言っておく：永久に残す価値が一番高いのは機器ログじゃない——構成変更記録と警報確認記録だ。機器ログは「何が起きたか」に答える。構成変更は「なぜ起きたか」に答える。私が回した事故レビューの10回中9回は「どのパラメータを誰が変えたか」で終わった。この落とし穴を3回見た：データは全部あったのに、光電センサーの遅延を200msから800msに変えたのが誰か見つからず、レビュー会議が犯人探しになった。

では計算だ。計算式はこれ——自分の倉庫の数字を入れろ：

1日のデータ量 ≈ ポイント数 × 86,400（秒／日）× 1レコードあたりのバイト数

計算例：2,000ポイント、1秒サンプリング、1レコード50バイト——1日あたり約8.6GB、90日で約780GBだ。だから生データを永久に残せない：ストレージが高いからじゃなく、誰も照会しないからだ。残すのはSSDの墓を掘るのと同じだ。現場の産業用PCに780GBのホットデータは、遅いクエリと苦痛なバックアップを意味する——そしていつかディスクが満杯になり、それが下の落とし穴その1だ。

WCSデータ保持、ステップバイステップ：本稼働前の5つ

データ種別を棚卸ししろ。WCSデータはちょうど5つのバケットに落ちる——1バケット1行、抜けなし：PLCポイントログ、警報記録、タスク軌跡、操作監査ログ、構成・プログラム変更だ。棚卸しの際、各バケットの出所（どのPLC、どのサービスが書くか）をメモしろ。後で壊れたとき、テンパらずにまず表を読む。
データ保持マトリクスを描け。この形式を使い、自分のサイトの数字を入れろ：

2つの注意：警報記録の生の保持に固定の日数は書かない——「法令／契約による」と書け。業界と顧客契約は違うし、固定の数字は契約が変わったときに負債になる。操作監査と構成変更は永久だが量はごく小さいから、安心して残せ——これが上のセクションの「永久に残す価値が一番高い」だ。

ストレージ層を決めろ。現場の産業用PCのSSDは7〜30日分のホットデータだけ持つ。ネットワーク障害時もクエリが動くためだ。エッジサーバーは集計と1年分の窓を持つ。クラウドはコールドアーカイブ専用だ。1つのルール：ホットデータをクラウドに置くな——転送とクエリの料金が教えてくれる。迷ったら先にデータ量の計算式を回し、エッジサーバーの一回投資と比べ、勘ではなく計算で決めろ。

コールドアーカイブのもう1つの隠れコスト：取り出しだ。コールドアーカイブは安いが、データを取り戻すのに数時間〜1日かかる——緊急の事故調査では永遠だ。だから「永久に残す」は「いつでもオンライン」じゃない。データ保持ポリシーを決めるとき、監査人と顧客と先に取り出しSLAを確認しろ：翌日の取り出しで耐えられるものはコールドアーカイブへ、耐えられないものはエッジサーバーに残す。このトレードオフは本稼働前に決めろ——後からアーカイブデータを移すのは、思っているよりずっと大変だ。

クリーンアップとアーカイブを自動化しろ。定期ジョブ＋ディスクの水位アラート：80%で警告、90%で古いデータから自動アーカイブだ。水位アラートは人間が本当に読むところに送れ——当番のチャットグループ、当番電話だ。誰も開かない公開メールボックスじゃない。アーカイブの実行ごとにログを書く：どれだけアーカイブし、どれだけ削除したか。帳簿は合わせろ。
引継ぎ文書だ。運用チームへの成果物3つ、全部必須：保持マトリクス（ステークホルダーの署名付き——署名は「このポリシーは合意済み」の意味）、クリーンアップ・アーカイブのジョブリスト（スケジュール、責任者、障害時の手順書）、アーカイブ復元ドリルの記録1件（アーカイブしたデータが本当に読み戻せることの証拠——やったことのないドリルは、紙の上にしか存在しないアーカイブだ）。

制御盤のあるWCSコンベアライン

よくある失敗モード：4つとも見た

1つ目：本稼働時に保持ポリシーがない。2024年10月、中国東部の大手EC倉庫：独身の日ピークの2週間前、WCS産業用PCのローカルディスクがログで満杯になり、システムがフリーズした。復旧：4時間のダウンタイム、緊急エクスポートとアーカイブ、定期クリーンアップの追加、水位アラートの後付けだ。この落とし穴を3回見た。回を追うごとに高くついた——1回目はテスト環境、2回目は閑散期、3回目はピーク目前だ。1文の教訓：保持ポリシーは本稼働チェックリストに載せろ。運用の「後で考える」リストじゃない。

2つ目：集計ロジックがコードに固まり、生データが削除される。あるサイトは90日で秒単位データを削除した。半年後、経営層が違うOEE計算式を求め、原材料は消えていた。古い集計から逆算するしかなかった——全方向に間違っていた。教訓：生データを削除する前に、集計の定義が凍結されていることを確認しろ。迷ったら生の保持を180日に延ばせ。ストレージコスト2倍で後悔保険が買える。安い保険だ。

3つ目：警報記録が操作ログと混ざる。ある3PLは警報記録を30日しか残さなかった。4か月後、顧客が貨物損傷を主張し、その日の警報記録とタスク軌跡を求めた——なくて、顧客の言い値で払った。警報記録の保持は顧客契約を結ぶ前に決め、契約に添付しろ。後から直すのは、事前に計画する10倍かかる。

4つ目：誰も見ていないクリーンアップジョブだ。水位アラートは3年前に辞めた人のメールボックスに届いていた。誰も気づく前にディスクが満杯になり、アーカイブジョブは3か月エラーに気づかれずにいた。引継ぎリストにはアラートの受信者を名指しし、退職時は後任を名指しし、後任の署名をもらえ。古臭い。効く。

本稼働の夜のチェックリスト——最後にこの3行を足せ：ステークホルダー承認済みの保持マトリクス、クリーンアップジョブを手動で1回実行し、アーカイブと削除のログを確認、3か月前のアーカイブをランダムに1件引いて読み戻すアーカイブ復元ドリル1件だ。この3行が終われば、データはクローズドループと言える。終わってなければ、今やれ。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。