コラム ｜ 物流データ収集入門 第6回 ｜ 2026年8月21日

倉庫データは全部クラウドへ送るべきか？
—現場で処理するデータと、送るデータの分け方

データ収集の仕組みを検討していると、よく出てくる問いがあります。「倉庫のデータは、全部クラウドに送っておけばいいのではないか」

後から何を分析したくなるかわからないのだから、とりあえず全部集めておく——考え方としては理解できます。しかし実際にこの方針で設計すると、通信量とコストの問題に突き当たります。そして多くの場合、送ったデータの大半は分析に使われません。

本記事では、何を現場で処理し、何をクラウドに送るのか、その分け方を整理します。なお本記事では、倉庫内のゲートウェイや制御用PCなど、現場でデータ処理を行う領域を「エッジ」と呼びます。

1. 「全部送る」と何が起きるか

まず、データ量の感覚を持っておくことが重要です。設備のセンサーデータを例に、取得間隔ごとの1日あたりの件数を見てみます。

倉庫には、コンベアの稼働状態、ソーターの通過検知、温湿度、AGVの位置情報など、多数のセンサーが存在します。これらをすべて高頻度で取得し、そのままクラウドへ送る設計にすると、次のような問題が生じます。

たとえば、人時生産性を改善したいだけなのに、ソーターの全センサーログを保存しているケースもあります。取得すること自体は技術的に可能でも、そのデータが改善の判断に使われていなければ、コストだけが積み上がることになります。

「とりあえず全部」という設計は、初期は動いても、拠点数やセンサー数が増えたときに運用コストとして跳ね返ってきます。

2. 現場で処理するか、クラウドで処理するか

「物流DXのシステムはどこに置くべきか」で整理したとおり、設備制御のようなリアルタイム処理は現場（エッジ）に、大量データの蓄積と分析はクラウドに置く構成が基本です。

データ転送の設計も、この考え方の延長線上にあります。処理の性質によって、現場で完結させるべきものと、クラウドに送るべきものが分かれます。

ポイントは、クラウドで行う分析に必要な粒度まで、現場側でデータを整理してから送るという発想です。

たとえば、コンベアの稼働状態を1秒間隔で監視している場合、その全データをクラウドに送る必要があるかを考えます。KPI分析で使うのが「1時間あたりの稼働時間」や「停止回数と停止時間」であれば、現場側で集計してから送ることで、転送量を大幅に減らせます。

3. 生データを送るか、集計データを送るか

ここで判断が難しいのが、「生データ（取得したままのデータ）を送るか、集計してから送るか」という選択です。

重要なのは、集計は不可逆であるという点です。1秒間隔のデータを1分平均に集計して送った場合、後から「10秒単位で見たい」と思っても、元のデータは残っていません。

なお、集計する場合も平均値だけにするのではなく、最大値・最小値・件数・異常フラグなど、後の分析で必要になる情報を残す設計が重要です。

実務では、次のような組み合わせで設計するケースがあります。

4. 転送設計を決める4つの問い

どのデータをどう送るかを判断するときは、次の4点を確認すると整理しやすくなります。

これらは、第1回から第3回で整理してきた「何を・どの粒度で・どの頻度で集めるか」という設計の考え方を、転送の場面に当てはめたものです。収集設計と転送設計は、本来は同じ問いから導かれます。

5. データ転送設計は、分析の自由度とコストのバランス

「全部クラウドに送る」も「必要最小限だけ送る」も、どちらか一方が正解ではありません。分析の自由度を取ればコストが上がり、コストを抑えれば後から分析できる範囲が狭まります。

実務的には、KPI算出に直結するデータは、分析に必要な粒度で確実にクラウドへ届け、それ以外の高頻度データは現場で集計する——という切り分けから始めるのが現実的です。運用しながら「このデータも見たい」という要望が出てきた段階で、対象を広げていく進め方であれば、初期投資を抑えつつ必要な分析を実現できます。

まとめ：送るデータは、分析目的から決める

倉庫のデータをすべてクラウドに送る必要はありません。一方で、送らなかったデータは後から取り戻せません。この2つの制約の間で、何を送るかを決めるのが転送設計です。

判断の基準は、技術的な可否ではなく「そのデータをどのKPIに使うか」です。使い道が明確なデータは確実に届く設計にし、それ以外は現場側で集計する——この切り分けが、コストと分析の自由度を両立させる出発点になります。