店舗・EC・卸売の販売データを統合して需要予測に使える状態にする方法

複数の販売チャネルを持つ企業では、店舗POSの日次売上、ECモールの注文データ、卸売先への出荷データなど、形式も粒度もバラバラなデータが各システムに散在しています。これらを手作業でExcelに貼り合わせて集計している現場は多く、月次の需要予測レポートを出すだけで担当者が丸2日かかるという状況も珍しくありません。データ整備に時間を取られるほど、予測の鮮度は落ち、在庫の過不足や機会損失につながります。

この記事は、従業員50〜300名規模の小売・卸売業で、販売管理やデータ集計を兼務している情報システム担当者や経営企画の方を想定しています。読み終えると、複数チャネルの販売データを自動で統合し、需要予測AIに投入できるデータパイプラインの全体像と、各ステップで何をすればよいかが分かります。大規模エンタープライズ向けのデータ基盤構築や、個別ツールの網羅的なレビューは扱いません。

なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、各チャネルのデータ取得元・変換ルール・統合先・予測投入までの一連のワークフローを自社に当てはめて設計できる状態になります。

Workflow at a glance: 店舗・EC・卸売の販売データを統合して需要予測に使える状態にする方法

• Step 1: 各チャネルからデータを抽出する (trocco) (BIツール)
• Step 2: データを変換・統合する (trocco) (BIツール)
• Step 3: 統合データをもとに需要予測を実行する (BECAUSE)

なぜ複数チャネルの販売データは統合が難しいのか

データ形式と粒度がチャネルごとに異なる

店舗POSの売上データはJANコード単位の日次集計、ECモールの注文データは注文ID単位のリアルタイム明細、卸売先への出荷データはケース単位の月次まとめ、というように、同じ商品の販売実績でもデータの単位・期間・項目名がまったく違います。たとえば店舗では税込売上が記録され、ECでは税抜価格とポイント値引きが別カラムになっているケースがあります。これらをそのまま並べても、商品Aが今月いくつ売れたのかという単純な問いにすら答えられません。

手作業の変換・統合が属人化している

多くの現場では、各システムからCSVをダウンロードし、Excelで列名を揃え、VLOOKUPで商品マスタを突合し、ピボットテーブルで集計するという作業を特定の担当者が毎月行っています。この手順はその人の頭の中にしかなく、担当者が休むとデータが出てきません。さらに、手作業ゆえに転記ミスや集計漏れが発生しやすく、予測モデルに投入するデータの品質が安定しません。

予測モデルの構築が後手に回る

データ整備に毎月2〜3日かかると、月初に前月データが揃うのは早くても5営業日後です。その間に競合の値下げや季節トレンドの変化が起きても、データが揃わなければ予測を更新できません。結果として、在庫の積み増しや値引き判断が遅れ、廃棄ロスや欠品による機会損失が積み重なります。

重要な考え方：データの変換ルールを人の手から切り離し、パイプラインとして自動化する

手作業の問題は速度だけではありません。最大の問題は再現性です。同じ入力データに対して、誰がいつ実行しても同じ出力が得られる状態を作ることが、予測モデルの精度を安定させる土台になります。

変換ルールをコードとして定義する

Excelの手順書やマクロではなく、ETLツール（データの抽出・変換・読み込みを自動化するツール）上で変換ルールを定義します。たとえば、ECの税抜価格に消費税率を掛けて税込に揃える、卸売のケース数を入数で割ってバラ数に変換する、といったルールをETLツールのフロー上に設定します。こうすることで、ルールの変更履歴が残り、誰でも内容を確認・修正できます。

商品マスタを統合の軸にする

チャネルごとに商品コード体系が異なる場合、統合の軸となる商品マスタが必要です。JANコードが全チャネルで使われていれば理想的ですが、卸売先独自のコードしかない場合は、マッピングテーブル（対応表）を1つ作り、ETLツールの変換処理で自動的に突合します。このマッピングテーブルの整備が、実はデータ統合プロジェクトで最も手間がかかる部分です。最初に時間をかけてでも正確に作り、以降はメンテナンスだけで済む状態を目指します。

更新頻度を業務サイクルに合わせる

需要予測の更新が月次なら、データ統合も月次で十分です。週次で在庫補充判断をしているなら、週次でパイプラインを回します。リアルタイム連携は技術的には可能ですが、コストと運用負荷が跳ね上がるため、自社の意思決定サイクルに合った頻度を選ぶことが重要です。FitGapでは、まず週次から始めて、必要に応じて頻度を上げることをおすすめします。

販売データ統合から需要予測投入までの実践ワークフロー

ステップ 1：各チャネルからデータを抽出する（trocco）

最初に、店舗POS・EC・卸売の各システムからデータを取り出します。ETLツールであるtroccoを使い、データソースごとに接続設定を作成します。

店舗POSについては、POSシステムがCSVエクスポートに対応していれば、出力先のクラウドストレージ（Amazon S3やGoogle Cloud Storageなど）をtroccoの取り込み元に指定します。ECモールについては、Shopifyを利用している場合はShopifyのAPIコネクタをtroccoで設定し、注文データを自動取得します。卸売データについては、基幹システムからのCSV出力をクラウドストレージ経由で取り込むのが現実的です。

troccoのジョブスケジュール機能で、毎週月曜の早朝に全チャネルのデータ取得を自動実行するよう設定します。取得が失敗した場合はSlackやメールに通知が飛ぶようにしておくと、担当者が朝出社した時点で異常に気づけます。

担当者はデータ基盤担当または情報システム担当です。初回の接続設定に1〜2日、以降は週次で通知確認のみ（5分程度）の運用になります。

ステップ 2：データを変換・統合する（trocco）

取得した各チャネルのデータを、troccoの変換機能で統一フォーマットに揃えます。具体的には以下の処理を行います。

まず、商品コードの統一です。事前に作成した商品マスタのマッピングテーブルをtrocco上に登録し、各チャネルの商品コードをJANコードに変換します。次に、金額の統一です。ECの税抜価格には消費税率を掛けて税込に揃え、卸売の掛率計算後の金額も税込ベースに変換します。そして、数量単位の統一です。卸売のケース数はバラ数に変換し、全チャネルを個数単位に揃えます。最後に、期間粒度の統一です。ECのリアルタイム明細は日次に集約し、店舗POSの日次データとタイムスタンプの形式を合わせます。

変換後のデータは、チャネル名・日付・JANコード・商品名・販売数量・税込売上金額という統一カラムを持つ1つのテーブルとして、Google BigQueryに出力します。troccoはBigQueryへの書き出しコネクタを標準で備えているため、出力先の設定は画面上の操作だけで完了します。

このステップで最も注意すべきは、変換ルールのテストです。初回は過去3か月分のデータで変換を実行し、元データと突合して数量・金額の合計が一致するかを必ず検証します。ここを省くと、予測モデルに不正確なデータが入り続けることになります。

ステップ 3：統合データをもとに需要予測を実行する（BECAUSE）

統合データがBigQueryに蓄積されたら、需要予測AIであるBECAUSEに投入します。BECAUSEはBigQueryとの連携に対応しており、統合テーブルをデータソースとして指定できます。

BECAUSEの予測モデルには、商品単位の週次販売数量を時系列データとして渡します。加えて、天候データやカレンダー情報（祝日・イベント）などの外部要因もBECAUSE側で取り込めるため、精度向上に活用します。

予測結果は、商品ごとの今後4〜8週間の販売予測数量としてCSVまたはダッシュボード上で確認できます。この予測値をもとに、発注担当者が週次の補充数量を決定します。

運用サイクルとしては、毎週月曜にtroccoがデータを取得・変換してBigQueryに格納し、火曜の朝にBECAUSEが予測を更新、火曜午後に発注担当者が予測結果を確認して発注判断を行う、という流れが現実的です。

担当者の引き継ぎとしては、データ基盤担当がステップ1・2の異常監視を担当し、発注担当者がステップ3の予測結果確認と発注判断を担当します。役割が明確に分かれるため、属人化を防げます。

この組み合わせが機能する理由

trocco：ノーコードで複数データソースの統合パイプラインを構築できる

troccoは日本発のETLツールで、国内のクラウドサービスやデータベースとの接続コネクタが豊富に用意されています。SQLやプログラミングの知識がなくても、画面上の操作でデータの抽出・変換・書き出しの一連の流れを構築できる点が、情報システム担当者が兼務で運用する現場に適しています。

強みは、ジョブの実行スケジュール管理とエラー通知が標準機能として備わっていることです。手作業の場合に起きがちな実行し忘れやエラーの見落としを防げます。また、変換処理の履歴が残るため、数値がおかしいときに原因を遡って調査できます。

弱みとしては、非常に複雑な変換ロジック（たとえば複数テーブルを何段階も結合するような処理）はGUI上での設定が煩雑になる場合があります。その場合はSQL記述モードに切り替える必要があり、多少の技術知識が求められます。また、データ量が非常に大きい場合（月間数千万行を超えるような規模）は処理時間とコストに注意が必要です。

Google BigQuery：統合データの蓄積先として拡張性が高い

BigQueryは統合後のデータを蓄積するデータウェアハウス（大量データを格納・分析するための専用データベース）として使います。troccoからの書き出し先として設定が容易で、BECAUSEからの読み込み先としても対応しているため、パイプラインの中間地点として最適です。

強みは、データ量が増えてもクエリ（データの検索・集計命令）の実行速度が大きく落ちない点です。チャネルが増えたり、日次から時間帯別に粒度を細かくしたりしても、同じ仕組みのまま対応できます。

トレードオフとしては、従量課金のため、頻繁に大量データを検索すると費用がかさむ可能性があります。週次の需要予測用途であれば、月間のクエリ量は限定的なので、コストは抑えられます。FitGapでは、まず無料枠の範囲で検証し、本番運用時のコスト感を掴んでから拡大することをおすすめします。

BECAUSE：外部データも加味した需要予測を専門知識なしで実行できる

BECAUSEは、販売データに天候やイベント情報などの外部要因を組み合わせて需要予測を行うAIサービスです。統計モデルや機械学習の専門知識がなくても、データを投入すれば予測結果が得られる点が、データサイエンティストを社内に抱えていない企業にとって大きな利点です。

強みは、予測結果の根拠（どの要因が販売数量にどの程度影響しているか）を可視化できることです。単に数字が出るだけでなく、なぜその予測になったのかを発注担当者が理解できるため、予測値を信頼して意思決定に使いやすくなります。

制約としては、予測精度はあくまで投入データの品質に依存します。ステップ1・2でのデータ統合が不正確だと、予測も不正確になります。また、新商品など過去データが少ない商品については予測精度が低くなるため、類似商品のデータで補完するなどの工夫が必要です。

Recommended tool list

結論：データ統合の自動化が需要予測の精度と速度の両方を決める

複数チャネルの販売データ統合は、手作業で行う限り属人化・遅延・品質低下の三重苦から逃れられません。troccoでデータの抽出と変換を自動化し、Google BigQueryに統合データを蓄積し、BECAUSEで需要予測を回すという3ステップのパイプラインを構築することで、毎週安定した精度の予測が得られる状態を作れます。

最初の一歩として、まず自社の各チャネルからCSVを1回ずつ手動でダウンロードし、商品コードの対応表（マッピングテーブル）を作成してください。この対応表がパイプライン全体の土台になります。対応表ができたら、troccoの無料トライアルで1チャネル分の取り込みと変換を試し、動作を確認するところから始めることをおすすめします。

Mentioned apps: trocco, Google BigQuery

Related categories: BIツール

Related stack guides: 監査時にガイドライン対応の証跡をすぐ提出できる体制を4つのツールで構築する方法, KPI改善と現場の不満が食い違うとき定量データと定性フィードバックを統合して施策の真の効果を判断する方法, AIエージェントの開発データと本番データの乖離を防ぎ精度低下と手戻りをなくす方法, AIの判断結果を人が検証・承認してから業務に反映する仕組みをつくり誤判定トラブルを防ぐ方法, マスタデータの重複登録を登録時点で防ぎ請求ミスと在庫差異をなくす方法