データ分析基盤構築から予測モデル運用まで：ECサイトの需要予測システム開発

年商50億円のアパレルECが、AI需要予測システムを導入して在庫回転率30%改善、欠品率60%削減を達成。データ基盤構築からMLOps運用まで、プロジェクトの全貌を公開します。

はじめに

「売れ筋商品が欠品して機会損失」「売れない商品の在庫が積み上がる」

EC事業者にとって、在庫管理は永遠の課題です。発注が少なすぎれば欠品で売上を逃し、多すぎれば在庫コストと値下げ処分で利益を圧迫します。

今回ご紹介するのは、年商50億円のアパレルECを運営するB社が、AI需要予測システムを導入して在庫回転率30%改善、欠品率60%削減を達成した事例です。

データ分析基盤の構築から、予測モデルの開発、そしてMLOpsによる本番運用まで、プロジェクトの全プロセスをお伝えします。

プロジェクト背景

クライアント概要

B社プロフィール

業種：アパレルEC（自社ブランド + セレクト）
年商：約50億円
SKU数：約8,000点
月間注文数：約50,000件
倉庫：自社運営（1拠点）
従業員：80名（うちMD・在庫管理5名）

抱えていた課題

課題1：属人的な発注判断

発注量の決定は、ベテランMD担当者の経験と勘に依存していました。担当者によって判断基準が異なり、予測精度にばらつきがありました。

課題2：欠品による機会損失

人気商品の欠品が頻発し、推定で年間1億円以上の機会損失が発生していました。特にSNSでバズった商品や、セール期間中の欠品が深刻でした。

課題3：過剰在庫によるコスト増

一方で、売れ残った商品の在庫が積み上がり、シーズン終了後に大幅値下げで処分。粗利率を5ポイント以上圧迫していました。

課題4：データの分断

販売データ、在庫データ、マーケティングデータが別々のシステムに分散しており、統合的な分析ができていませんでした。

プロジェクトの目標

B社とAlgoboaで協議し、以下のKPIを設定しました：

指標	現状	目標
在庫回転率	4.0回/年	5.2回/年（+30%）
欠品率	8.5%	3.5%以下（-60%）
過剰在庫率	15%	10%以下
予測精度（MAPE）	-	20%以下

フェーズ1：データ分析基盤の構築

現状のデータ環境

プロジェクト開始時、B社のデータ環境は以下の状態でした：

ECプラットフォーム：Shopify（販売・顧客データ）
在庫管理：独自システム（Excelベース）
マーケティング：Google Analytics、各SNS管理画面
基幹システム：発注・仕入れデータ

これらがサイロ化しており、統合的な分析には手作業でのデータ結合が必要でした。

データウェアハウスの設計

まず、すべてのデータを統合するデータウェアハウス（DWH）を構築しました。

技術選定

DWH：BigQuery（Google Cloud）
ETL：Fivetran + dbt
オーケストレーション：Cloud Composer（Airflow）

データモデル設計

【ソースレイヤー】
├── shopify_orders（注文データ）
├── shopify_products（商品マスタ）
├── inventory_levels（在庫データ）
├── google_analytics（Web行動データ）
└── weather_data（天気データ）

【変換レイヤー】
├── dim_products（商品ディメンション）
├── dim_dates（日付ディメンション）
├── dim_customers（顧客ディメンション）
├── fct_sales（販売ファクト）
└── fct_inventory（在庫ファクト）

【分析レイヤー】
├── mart_daily_sales（日次販売集計）
├── mart_product_performance（商品別実績）
└── mart_demand_features（需要予測用特徴量）

ETLパイプラインの構築

各データソースからDWHへのデータ連携パイプラインを構築しました。

更新頻度

販売データ：1時間ごと
在庫データ：1時間ごと
Web行動データ：日次
天気データ：日次

データ品質チェック

欠損値の検出
異常値の検出
遅延の監視

フェーズ2：予測モデルの開発

特徴量エンジニアリング

需要予測の精度は、特徴量の設計に大きく依存します。以下の特徴量を設計しました。

時系列特徴量

過去7日、14日、28日の販売数
前年同週の販売数
曜日、月、季節のフラグ
トレンド成分、季節成分

商品特徴量

カテゴリ、サブカテゴリ
価格帯
発売からの経過日数
新商品フラグ

外部要因

天気（気温、降水確率）
祝日・イベントフラグ
セール期間フラグ
SNSバズ検出（急激なPV増加）

在庫関連

現在庫数
入荷予定
過去の欠品期間

モデル選定

複数のアルゴリズムを比較検討しました。

モデル	MAPE	特徴
LightGBM	18.2%	高速、特徴量重要度が見やすい
XGBoost	19.1%	安定した性能
Prophet	24.5%	時系列特化、解釈しやすい
LSTM	21.3%	長期依存関係を学習可能

最終的にLightGBMを採用。精度と解釈性のバランスが最も良好でした。

予測粒度の設計

予測対象

粒度：SKU × 日
予測期間：14日先まで
更新頻度：日次

階層予測（Hierarchical Forecasting）

個別SKUの予測は変動が大きいため、階層的なアプローチを採用しました。

全社合計（トップダウン調整）
  ↓
カテゴリ別（中間調整）
  ↓
SKU別（ボトムアップ予測）

上位階層の予測との整合性を取ることで、全体としての精度を向上させました。

モデル評価

評価指標

MAPE（平均絶対パーセント誤差）：18.2%
RMSE（二乗平均平方根誤差）
欠品予測の適合率・再現率

バックテスト

過去6ヶ月分のデータでバックテストを実施し、季節性やセール期間での精度を確認しました。

フェーズ3：MLOpsによる本番運用

システムアーキテクチャ

┌─────────────────────────────────────────────────────────┐
│                    データパイプライン                      │
│  Shopify → Fivetran → BigQuery → dbt → 特徴量テーブル    │
└─────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────┐
│                    予測パイプライン                        │
│  特徴量取得 → モデル推論 → 予測結果保存 → 発注推奨算出     │
│            （Vertex AI Pipelines）                        │
└─────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────┐
│                    アプリケーション層                       │
│  発注推奨ダッシュボード（Looker Studio + カスタムUI）       │
└─────────────────────────────────────────────────────────┘

自動化されたワークフロー

日次バッチ処理

05:00 - データ取り込み・変換
06:00 - 特徴量生成
07:00 - 予測実行
08:00 - 発注推奨計算
08:30 - MD担当者へメール通知

リアルタイム更新

急激な販売増（バズ検出）
大幅な天気変動 → 予測の臨時更新をトリガー

モニタリングとアラート

予測精度のモニタリング

日次で予測と実績を比較
精度が閾値（MAPE 25%）を超えたらアラート
カテゴリ別、価格帯別の精度トラッキング

データ品質のモニタリング

データ遅延の検知
欠損値の急増検知
異常値の検知

モデルドリフトの検知

特徴量の分布変化
予測値の分布変化
定期的な再学習トリガー

再学習パイプライン

定期再学習

頻度：週次
直近データを追加して再学習
A/Bテストで新旧モデルを比較
精度向上が確認できたら本番適用

臨時再学習

大きなイベント後（大型セール後など）
精度劣化が検知された場合
新カテゴリ追加時

発注推奨システム

安全在庫の自動計算

需要予測に加えて、適切な安全在庫水準を自動計算しました。

計算式

安全在庫 = Z × σ × √(リードタイム + 発注間隔)

Z：サービス水準に対応する安全係数（95% → 1.65）
σ：需要の標準偏差

動的調整

予測不確実性が高い商品は安全在庫を多めに
安定した定番商品は安全在庫を少なめに

発注推奨ロジック

推奨発注量 = (予測需要 × リードタイム) + 安全在庫 - 現在庫 - 発注残

制約条件

最小発注単位（MOQ）
発注上限
倉庫キャパシティ

ダッシュボードUI

MD担当者向けのダッシュボードを構築しました。

主な機能

本日の発注推奨リスト
SKU別の需要予測グラフ
欠品リスク商品のハイライト
過剰在庫商品のハイライト
予測精度のトラッキング

人間の判断を支援

AIの推奨はあくまで参考情報。最終判断はMD担当者が行う設計としました。

推奨値の根拠（どの特徴量が効いているか）を表示
調整理由を記録できる機能
過去の調整履歴から学習

プロジェクト成果

定量的成果

導入から6ヶ月後の成果を測定しました。

指標	導入前	導入後	改善率
在庫回転率	4.0回/年	5.2回/年	+30%
欠品率	8.5%	3.2%	-62%
過剰在庫率	15%	9.5%	-37%
予測精度（MAPE）	-	17.8%	目標達成

金額換算

機会損失削減：推定年間6,000万円
在庫コスト削減：推定年間3,000万円
値下げ損失削減：推定年間2,000万円
合計：年間約1.1億円の効果

定性的成果

MD担当者の声

「勘に頼っていた発注が、データに基づいて判断できるようになりました。特に新商品の初期発注で大きなミスが減りました」（MD担当・30代）

「ダッシュボードで欠品リスクが一目でわかるので、先手を打った対応ができます」（在庫管理担当・40代）

経営者の声

「在庫を圧縮しながら欠品も減らせたのは大きい。何より、データに基づく意思決定の文化が社内に根付いてきました」（経営企画室長・50代）

成功要因の分析

1. データ基盤への投資

予測モデルを作る前に、データ基盤を整備したことが成功の土台となりました。クリーンなデータなしに高精度な予測は実現できません。

2. 現場との協働

MD担当者を巻き込み、彼らのドメイン知識を特徴量設計に反映しました。現場が使いたくなるシステムを作ることが重要です。

3. 段階的な導入

最初は一部カテゴリでパイロット運用し、成果を確認してから全社展開しました。小さな成功を積み重ねることで、社内の信頼を獲得しました。

4. MLOpsへの投資

モデルを作って終わりではなく、継続的なモニタリングと改善の仕組みを構築しました。予測精度は運用しながら向上し続けています。

今後の展望

B社では、需要予測システムを基盤として、さらなる高度化を計画しています。

短期（6ヶ月以内）

価格最適化との連携
自動発注への段階的移行

中期（1〜2年）

複数倉庫への展開
新規出店計画への活用
サプライヤーとのデータ連携

まとめ

B社は、データ分析基盤の構築からMLOpsによる本番運用まで、一貫したアプローチで需要予測システムを構築し、大きな成果を上げました。

成功のポイント

データ基盤への先行投資
現場との協働による特徴量設計
段階的な導入とフィードバック
MLOpsによる継続的改善

需要予測・在庫最適化についてのご相談は、Algoboaまでお気軽にお問い合わせください。御社のデータ環境と課題に応じた最適なソリューションをご提案いたします。