アラートは1分以内、生産性は翌朝でいい
—物流データの処理タイミングを用途から決める
・取得頻度と処理タイミングが別の設計である理由
・リアルタイム／準リアルタイム／日次／月次を用途から決める考え方
・「全部リアルタイム」にすると何が起きるのか
この2つは、しばしば同じものとして扱われます。しかし別の設計です。そして混同すると、こういう状態が生まれます。
「設備データは1秒ごとに取得しています。でも、稼働率が画面に出るのは翌朝です」
センサーは1秒ごとに値を送っています。データは基盤に届いています。しかし、それを集計してKPIにする処理が1日1回しか動いていない。結果として、現場が見られる数字は前日までのものです。
取得が細かいことと、分析が早いことは、別のことです。
日次処理ならリアルタイム分析にはなりません。
1. 取得頻度と処理タイミングは、別の設計
8月の「物流データ収集入門」では、何秒ごとにデータを取得するかという取得間隔を扱いました。何秒ごとに測るか、という設計です。細かく取れば短時間の事象を捉えられますが、その分データ量が増えます。
今回考えるのは、その先です。取得したデータを、いつ「見られる状態」にするか。
| 観点 | 取得頻度（8月シリーズ） | 処理タイミング（本記事） |
|---|---|---|
| 問い | 何秒ごとに測るか | いつ分析可能な状態にするか |
| 決め手 | 捉えたい事象の長さ | その数字を見て何をするか |
| 影響 | データの細かさ、通信量 | 判断できるまでの時間、処理の負荷 |
| 足りないと | 短い事象が記録に残らない | 記録はあるが、間に合わない |
両者の関係は一方向です。取得頻度より細かい時間単位で、新しい状態を分析することはできません。しかし、細かく取得したデータを後からまとめて処理することはできます。1時間ごとにしか取得していないデータを1分単位で分析することはできませんが、1秒ごとに取得したデータを日次でまとめて処理することは、いくらでも起こります。
1分後に止めなければ被害が広がるものと、翌朝までに把握できていればよいものは、同じ仕組みで扱う必要がありません。
2. 用途から4つに整理する
物流現場で扱うデータの用途は、判断までの許容時間で大きく4つに分けられます。
今すぐ止める・呼ぶ
今日の残りを組み替える
明日以降の計画を変える
体制・契約を見直す
それぞれ、具体的に見ていきます。
設備の異常停止、庫内温度の逸脱、危険を伴う状態の検知。「知ってから動くまで」が短いものです。
この区分の条件は、受け取った人がすぐ動けることです。深夜に通知が飛んでも対応する人がいなければ、リアルタイムにする意味がありません。技術的にできるかではなく、対応する体制があるかで決まります。
出荷の進捗、工程間の滞留、ピーク時間帯の人員の偏り。今日のうちに配置を変えれば間に合うものです。
物流現場ではこの区分が実用的な場面が多くあります。10分前の状況が分かれば、応援を回す、順序を変える、といった判断ができます。1秒ごとの精度は必要ありません。
人時生産性、工程別の所要時間、出荷遅延の件数、設備の稼働率。前日の結果を見て、シフトや工程の組み方を見直すものです。
ここで重要なのは、翌朝でよいものを無理に速くしても、判断のタイミングは変わらないことです。人時生産性が5分ごとに更新されても、シフトを5分ごとに組み替えることはありません。
拠点間の比較、季節変動の傾向、荷主別の採算、設備投資の判断材料。時間をかけて精度を上げるべきものです。
この区分では速さより確定していることが重要になります。締め処理が済んでいない数字で比較しても、後から変わります。
3. 「全部リアルタイム」にすると何が起きるか
処理タイミングの設計で、もっともよくある失敗は「できるだけ速くしておこう」という判断です。速い方が良いように見えるため、明確な反対理由が出にくいのです。
しかし、すべてをリアルタイムにすると、次のようなことが起こります。
誰も見ない画面が増えます。
「リアルタイムダッシュボードを作ったが、結局誰も見ていない」という状態は、技術の失敗ではありません。その数字を見て動く場面が、そもそも存在しなかったということです。処理タイミングは、動く場面から逆算して決める必要があります。
4. 処理の方式は、用途が決まった後に決まる
処理タイミングの実現方法には、いくつかの型があります。ここでは名前だけ整理しておきます。
これらは選択肢であって、出発点ではありません。用途と許容時間が決まっていれば、方式は自然に絞られます。逆に、方式から考え始めると「まずストリーム処理の仕組みを入れる」という話になり、何に使うのかが後回しになります。
どれか1つを選ぶ話ではありません。同じ基盤の中で、異常検知はリアルタイム、進捗把握は準リアルタイム、生産性は日次、拠点比較は月次——という組み合わせになるのが通常です。
大切なのは、どのデータをどのタイミングで処理するかを整理しておくことです。整理がないまま「とりあえず全部日次」あるいは「とりあえず全部リアルタイム」になっている状態が、いちばん判断を難しくします。
5. 実際に決めるときの順序
処理タイミングを決める手順は、収集の設計と同じです。用途から入ります。
| 順 | 決めること | 具体的な問い |
|---|---|---|
| 1 | その数字を見て何をするか | 設備を止める／人を動かす／明日のシフトを変える／来期の体制を考える |
| 2 | いつまでに知る必要があるか | その行動が有効なのは、何分後までか。何時間後までか |
| 3 | 誰が受け取るか | その時間帯に、実際に対応できる人がいるか |
| 4 | 確定していなくてよいか | 途中の数字で判断してよいのか、揃ってから見るべきか |
| 5 | 処理タイミングを決める | 1〜4の結果として、リアルタイム／準リアルタイム／日次／月次のどれか |
この順序で考えると、リアルタイムにすべき対象はかなり絞られます。多くのKPIは、翌朝で足ります。そして絞れた分の労力を、本当に速さが必要な部分に回せます。
最初から全部を速くする必要はありませんが、後から変えられない作りにしてしまうと困ります。第3回で触れたとおり、細かい単位のデータを残しておけば、集計の頻度は後から変えられます。
逆に、取得の段階で粗くまとめてしまうと、後から速くすることも細かくすることもできません。処理タイミングは変更できる余地を残しておく、という構えが有効です。
まとめ：速さは目的ではなく、判断のための条件
データを何秒ごとに取得するかと、そのデータをいつ分析可能にするかは、別の設計です。細かく取得していても、処理が日次なら現場が見るのは前日までの数字です。
処理タイミングを決めるのは、技術的な可否ではありません。その数字を見た人が、いつまでに動く必要があるか。アラートは1分以内に届く必要があり、人時生産性は翌朝で足ります。この違いを整理せずに「できるだけ速く」を目指すと、使われない画面と、無視される通知が増えます。
「その数字で何をするか」で決まります。
今回、リアルタイム処理に使うデータ、分析に使うデータ、長期に残すデータという用途の違いが見えてきました。次回は、それぞれをどこに置くかを扱います。生ログ、整形済みデータ、KPIの集計値——用途が違えば、保存の考え方も変わります。なぜ保存先が一つとは限らないのか、という問いから始めます。
どのデータをリアルタイムにすべきか、どこまで日次で足りるかは、その数字で何をするかによって変わります。改善したいKPIと、それを見て動く場面を洗い出し、必要な処理タイミングを整理するところからご一緒できます。
「リアルタイムにすべきか判断できない」という段階からでもご相談いただけます。
お問い合わせはこちら