物流拠点「ZOZOBASE」の意思決定を支える注文数の時系列予測

物流拠点「ZOZOBASE」の意思決定を支える注文数の時系列予測

はじめに

こんにちは、AI・アナリティクス本部データサイエンスブロックの大戸徳仁です。普段は、サービスや機能の現状把握・要因分析、施策の効果検証、需要予測モデルの開発・運用などを担当しています。私が所属するチームでは、「データに基づいた意思決定を支援すること」をミッションに、社内の各部門に対してデータ分析サービスを提供しています。

その取り組みの一環として、ZOZOの物流拠点「ZOZOBASE」のデータ活用に取り組んでいます。中でも、出荷計画や人員配置の判断材料となる「注文数の予測」については、予測精度が安定しない、予測工数がかかるといった課題があります。本記事では、これらの課題に対してどのようにアプローチしたのか、そしてプロジェクトを通じて得られた気づきについて紹介します。

目次

背景

ZOZOの物流拠点であるZOZOBASE(以下、BASE)では、毎日膨大な量の注文が処理されています。その中で、日々の注文数をどれだけ正確に予測できるかは、BASEの業務を安定的に運営するうえで非常に重要です。注文数の予測は、次のような多くの意思決定の基盤となります。

  • 日々のピッキング・出荷量の計画
  • 出荷量に応じた人員配置や作業負荷の調整
  • 運営体制の設計

これらの意思決定を適切に行うためにも、日々の注文数をブレなく予測できる状態が望まれます。注文数予測は、物流現場の運営を支えるだけでなく、お客様へ商品を遅延なく届けるための体制づくりにも直結します。

こうした背景から、過去データをもとに注文数を予測するモデルを構築し、現場の業務フローに組み込むプロジェクトを開始しました。
なお、今回のプロジェクトは、毎日決まった時間に、翌日から7日後までの日次の注文数を予測することが要件です。翌日単体の予測だけでなく複数日先を同時に予測するため、トレンド・周期性・イベント影響など複数要因を適切に扱う必要があります。

課題

注文数予測が現場の重要な意思決定の基盤である一方、従来の手動方法にはいくつかの課題がありました。ここでは、モデル構築へ着手する前に明らかとなった課題を整理します。

課題1:予測に工数がかかる
従来の予測は現場担当者が手動で行っており、日々一定の工数が発生していました。予測作業そのものが現場担当者の負担となり、本来の出荷業務へ時間を割きづらい状態となります。

課題2:予測精度が安定しない
注文数は、次のような多くの要因によって日々変動します。

  • 曜日ごとの周期性
  • セールやキャンペーン、クーポン施策の有無
  • 天候や季節変動

これらが複合的に作用するため、担当者が手動で補正し続けるには限界があります。誤差が大きくなるだけでなく、そのばらつきも大きくなり、予測が安定しない状況となっていました。予測値が実績値を上回る(予測>実績)場合は、人員余りによるコスト増につながります。一方で、予測値が実績値を下回る(予測<実績)場合は、人員不足を招き、発送遅延につながる重大なリスクとなります。

課題3:属人的で再現が難しい
手動での予測では、担当者ごとに「こういう日は増えやすい」といった、経験値に基づく判断が行われており、予測プロセスが属人的となっていました。そのため、同じ条件でも担当者が変わると予測値が変わったり、予測を外した場合でもどの判断が影響したのかを振り返りづらくなったりと、改善につなげることが難しくなります。

これらの課題を解決するために、日々の注文数を自動で予測でき、かつ精度や傾向を継続的に評価・改善できる仕組みを構築する必要性が明確になりました。

課題解決アプローチ

本章では、前章で整理した課題を踏まえ、どのような考え方で評価指標を設計し、データを分析したうえで予測モデルを構築・評価したのかを紹介します。

  1. 評価指標の設計
  2. EDA(探索的データ分析)
  3. 予測モデルの構築
  4. 予測モデルの評価

1.評価指標の設計

まず、モデル構築に先立ち、どのような予測であれば「良い」と言えるのかを明確にしました。予測精度の良し悪しは評価指標の設計によって大きく左右されるため、ここを最初に定義することが重要です。 今回は、次の理由からMAE(日別の絶対誤差の平均値)を評価指標として採用しました。

  • 誤差を「件数ベース」で把握でき、現場担当者にとって直感的
  • 外れ値の影響を受けにくく、平常日の誤差が素直に評価できる
  • BASEの業務では「何件ズレるか」がそのまま人員計画や作業負荷に影響する

評価指標

MAPEやRMSEといった他の指標もありますが、「日々の作業量を安定的にコントロールする」という目的に対しては、MAEが最も適していると判断しました。
また、BASEの業務では、日別の誤差は小さくても、予測値が実績値を下回る状態(予測<実績)が連続すると発送遅延につながる重大なリスクとなります。そのため、単なる誤差の大小だけでなく、どの方向に外れたかも含めて評価する方針としました。

2.EDA(探索的データ分析)

評価指標を定義したうえで、次に取り組んだのがEDA(探索的データ分析)です。ここでは、目指す精度水準を達成するうえで、注文数データの特徴や構造を把握することを目的としています。EDAの結果、注文数の変動には「曜日による周期性」「セールやキャンペーンなどのイベント影響」「直近の注文動向」といった要因が絡み合っていることが分かりました。

※本記事のグラフは、構造を説明するための仮想データを用いており、実際の注文データではありません。

時系列データの変動成分
時系列データは、3つの変動成分で構成されています。

  • トレンド成分
  • 周期成分
  • 残差(ノイズ)成分

変動成分を分解する方法はいくつかあり、代表的なものとしては次のようなものがあります。

  • 移動平均法を利用した分解(加法モデルを仮定)
  • 移動平均法を利用した分解(乗法モデルを仮定)
  • STL分解(Seasonal Decomposition Of Time Series By Loess)

今回は、日次データを1週間周期(period=7)でSTL分解し、各成分を確認しました。STL分解は外れ値に強く、周期性の強さが時期によって変化するようなデータにも柔軟に対応できるためです。

■トレンド
年間を通じた大きな波が見られ、中長期的な需要変動を確認できます。
トレンド

■周期性
曜日による周期性が強く、1週間のリズムが明確に現れています。また、夏から冬に向けて周期成分の振れ幅が徐々に大きくなっている構造も読み取れます。
周期性

■残差(ノイズ)
ランダムな揺らぎに加えて、イベント時には大きな変動が生じており、トレンドや周期性だけでは説明できない要素も存在します。
残差

自己相関(ACF)と偏自己相関(PACF)

  • 自己相関(ACF):現在の値と過去の値との相関
  • 偏自己相関(PACF):間接的な影響を除いたうえでの、直接的な相関
    • 例:今日の値が一昨日の値と相関しているように見えても、実際には「一昨日 → 昨日 → 今日」という形で、昨日を介した間接的な影響による相関の場合がある。偏自己相関では、こうした間接的な影響を取り除いた相関を確認できる。

■自己相関(ACF)
注文数は「同曜日(ラグ7の倍数)」で強い相関が見られます。
自己相関

■偏自己相関(PACF)
間接的な影響を除いた場合、「同曜日(ラグ7,14,21,28)」の影響が顕著なため、週次の周期性を明示的に扱えるモデル構造が、予測精度の安定化に重要だと考えられます。
偏自己相関

3.予測モデルの構築

予測モデルの構築では、前節までで整理した評価方針とEDAの結果を踏まえ、「どのモデルを採用するか」「どのように学習・検証するか」という2つの観点を中心に検討を進めました。ここでは、実際に行ったモデル選定と学習・検証のアプローチを紹介します。

モデル選定
今回はProphetを採用しました。主な理由は以下のとおりです。

  • 週次や年次の周期性を標準機能として扱える
  • トレンドの変化点を検出できる
  • 休日やイベント情報を組み込みやすい
  • モデル構造がシンプルで、予測根拠を現場担当者へ説明しやすい
  • 1週間先までの複数日予測を、特別な工夫を加えずに自然に扱える

これらの特性は、ZOZOの注文数データの構造と業務要件の双方と相性が良いと判断しました。

モデル構築
時系列予測では、「過去データで学習し、未来データで評価する」ことが重要です。ランダム分割すると未来情報が混入し、実運用に近い精度を正しく評価できなくなるため、今回は、学習期間を伸ばしながら評価するエクスパンディング型のクロスバリデーション法を採用しました。具体的には、次の流れでデータを扱っています。

  • データを時系列順に分割し、前半を学習+検証データ、後半を最終評価用データとして使用
  • 前半データに対して、学習期間を伸ばしながら、「学習 → 直後1週間の予測 → MAE算出」を1年分(52週分)繰り返す
  • 52週分の評価結果を平均し、年間を通した頑健性を評価

この枠組みのもとで、Prophetの性能を最大限引き出すため、Optunaを用いて次のハイパーパラメータを最適化します。

  • changepoint_prior_scale:トレンド成分の柔軟性
  • seasonality_prior_scale:季節成分の柔軟性
  • seasonality_mode:季節成分の種類(加法/乗法)
  • changepoint_range:トレンド変化点候補のレンジ
  • n_changepoints:トレンドの変化点の数

Optunaでは、学習期間を伸ばしながら1年分(52週分)の評価で得られた平均MAEを最適化指標とし、値が最も小さくなるパラメータセットを採用しました。

クロスバリデーション

4.予測モデルの評価

事前に定義した評価方針をもとに、構築したモデルが業務で利用可能かどうかを、テストデータを用いて確認します。BASEの業務では、日別の誤差は小さくても、予測値が実績値を下回る状態(予測<実績)が連続すると発送遅延につながる重大なリスクとなります。そのため、日別の誤差に加えて、次の観点でもモデルを評価しました。

  • 週単位での誤差Σ(日別の誤差)を確認
  • 予測値が実績値を下回る(予測<実績)ケースが少ないモデルを評価
  • 特定曜日・特定イベント期間に偏りや弱点がないか

これらの観点をもとに、BASEの担当者と誤差の傾向を確認しながら、「特徴量の調整→再学習→評価」の改善サイクルを繰り返し、日々の運用で活用できる水準へとモデルをブラッシュアップしました。
ここから、次章で紹介する仮運用フェーズへ進みます。

リリース・仮運用

予測モデルが業務で利用できる水準まで仕上がったため、評価時に分割していたテスト期間も含めた全データでモデルを再学習し、日次で予測値を更新できる環境を整えました。こうして、モデルが現場で実際に活用できるかを確かめる仮運用フェーズへ移行しました。本章では、仮運用を通じて得られた気づきと、次の改善に向けた取り組み内容について紹介します。

課題解決への第一歩

仮運用を進める中で、手動予測と比較して日々の誤差のばらつきは小さくなり、予測の安定性が向上していることが確認できました。注文数を「自動で」かつ「一定の精度で」予測できるようになったことで、現場担当者は本来の出荷業務へ集中しやすい環境に近づいています。一方で、仮運用を通じて、予測対象の捉え方まで含めて精度を高めていく必要があることも見えてきました。

仮運用を通じて見えた新たな課題

BASEの業務では、注文が受注順に発送されるとは限りません。日付指定・取り寄せ・予約注文など、お客様からの注文日とBASEからの発送タイミングがずれるケースは多くあります。その結果、次のような日が発生します。

  • お客様からの注文数は少ないのに、発送すべき注文が多い
  • お客様からの注文数は多いのに、発送すべき注文が少ない

こうした特性を踏まえ、BASEでは「お客様から入る注文数」をそのまま扱うのではなく、「お客様へ発送可能な状態の注文数」へ変換したうえで出荷計画や人員配置をしています。仮運用を通じて、「お客様へ発送可能な状態の注文数」へ変換するロジックが従来のままでは、改善効果を十分に引き出せないことが分かってきました。現場で最終的に必要としている数字は、「何件注文が入るか」ではなく「何件発送できるか」という視点です。そのため、変換ロジックを含めた一連のプロセスとしての見直しが必要となります。

次の改善フェーズに向けて

前節で見えた新たな課題を踏まえ、現在は次のような取り組みを進めています。

  • 日付指定・取り寄せ・予約注文などの比率分析
  • 注文が「発送可能」になるまでのリードタイム分析
  • お客様からの注文数予測と発送可能な注文数の統合

お客様から入る注文数の予測モデルの高度化にとどまらず、現場の業務判断にそのまま活用できる形へつなげる仕組みとして、改善を継続しています。

まとめ

本記事では、BASEにおける注文数予測の課題に対して、「業務で使える予測とは何か」という観点から、モデル構築プロセスと仮運用を通じて得られた気づきを紹介しました。まだ改善半ばではありますが、従来は手動で行われていた注文数予測をモデル化することで、予測精度のばらつきや属人性といった課題を解消し、日々の注文数を安定して予測できる環境へと近づいています。

今回の取り組みを通じて改めて感じたのは、データ分析や予測モデルは「高い精度を出すこと」自体が目的ではなく、データに基づいた意思決定を支援して初めて価値を発揮するという点です。予測精度が高くても、業務特性上のリスクが高まってしまったり、そもそも現場が必要としている指標と一致していなければ、実務での効果は限定的になります。事前に課題やビジネス要件を整理し、実務に即した形で改善を重ねていくことが、結果としてお客様価値やビジネスインパクトにつながると考えています。今後もBASEと連携しながら、現場の意思決定に使える予測を目指して、継続的に改善を進めていきます。

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com


参考文献

Pythonによる時系列分析

カテゴリー