こんにちは。APOLLO のにゃんこチーム※の、ふるさわです。

※APOLLO の AI ユニットは、最先端テクノロジーチーム、ビジネスアナリティクスチーム、システム開発チーム、にゃんこチームの 4 つからなります。
今回は、直近のプロジェクトでちょっと**「やってしまった」話と、そこから得られた教訓**について書きたいと思います。

案件について

需要予測と在庫最適化の案件で、お客様は食品の卸売会社さんでした。こういう会社さんは、下記のような特徴を持っています。

(a) 数万種類の商品を扱い、商品の改廃も激しい。
(b) 全国に拠点をいくつも持っており、しばしば新設・廃止・統合が行われる。
(c) 商品を切らして欠品させてしまい、顧客に迷惑がかかることは絶対に避けたがる。
(d) 一方で、倉庫の容量も限られていて、持てる在庫量に限りがある。

(c)(d) の板挟みを解決するために、(a) や (b) も考慮しつつ、AI が過去データから商品×営業所（×得意先）別の売れ行きを予測し、倉庫キャパや目標欠品率から逆算して、適切な発注量を算出する仕組みを構築していく必要があります。

進め方とモデルの構造

進め方としては、

3 か月で PoC モデルを構築する

続く 3 か月で、さらなる精度改善を進めつつシステム化する

その後、対象営業所を段階的に拡大しながら運用を開始する

という 3 フェーズで進めました。
構築したモデルの概要は、下図の通りです。

やってしまった話

このように進める中で、「うまくいかなかった」ことがありました。現在に至るまで運用は継続していて、業務効果も上がっているので、結果論としては「どうにかなった」ではあるのですが、そのときはそれなりにつらかったです。
データもきれいで、PoC 時の机上検証では精度も十分に高かった。でも苦戦した。具体的には、次の 3 つです。

失敗①：需要予測の精度が上がり切らない

(a) 現場の人に、情報戦で負けていた

(b) 「例外ケース」で極端な予測値が出てしまっていた

失敗②：発注計算で不備が出る

用語を含めた制約条件の認識合わせが不十分

失敗③：運用ルールの不備

(a) 想定外の値を入力されてしまい、おかしな計算結果が出た

(b) 顧客が予測根拠を理解できず不安になり、お問い合わせが大量に来た

以下では、これらを一つずつ解説していきたいと思います。

①(a) 現場の人に、情報戦で負けていて、需要予測の精度が上がり切らなかった

週次で開催している AI の運用会議において、仕入れ業務を監督している立場の人から、「〇〇営業所での AI の精度がよくない」と指摘が入りました。「AI は、こういうのはわからないのか……」と、やや失望した感じ。
しかし、実際に〇〇営業所の需要波形を見ると、どう考えても当たるようには見えない。特需のような動きがいくつもある。
よくよく話を聞くと、次のような話でした。

「先月、〇〇社から大口の受注が入った」
「来週、店舗でイベントがあるので需要が跳ねる」

こういうことは、当然、現場で仕入れ業務をしている人は知っているので、発注量に反映させることができます。しかし、AI モデルにはそういうことはインプットしていないので、当たりません。結果、現行業務に AI の需要予測が負ける、ということが発生します。
AI モデルは、入力していない情報を予測に反映することはできません（あたりまえですが）。なので、現場が知っている情報の種類を正確に把握し、それを確実に入力させる仕組みが重要なのです。
情報として集めることさえできてしまえば、それを機械学習モデルの変数として組み込むことも、あとで補正に用いることもできます。そうすれば、現場で立てた計画に精度で劣るようなことは発生しなくなります。

【余談】
もっと言うと、未来は予測するだけでなく、作りにいくことも、選択肢になりえます。特売を打てば需要は動きます。定期購入を契約させれば需要は固定できます。
需要予測精度を上げることにこだわるよりも、狙った方向（≒利益が大きくなる方向）に需要を「動かして」しまうことも、選択肢になりえます。結果として、「確定」需要の量が増えて、需要予測の精度も向上します。
AI 単体の話ではないですが、こういうのもありかもしれません。

※筆者の上司の同僚は、コンビニエンスストアの需要予測案件において、おにぎりの需要予測が外れそうになると、（冗談で）「100 個買ってこい！」と言われたそうです。

①(b) 「例外ケース」で極端な予測値が出てしまっていた

運用を開始してから 3 か月くらい経過したのち、お客様から 1 本のメールが届きました。
「GW 中日の予測がおかしい。通常の 10 倍近い発注量が計算されている。」
データを見ると、たしかにおかしい。前年や前々年の GW 中日と比較しても、そんなに売れるはずがない。
アルゴリズムと突き合わせて考えると、GW 前後の補正値が悪さをしているということがわかりました。というのも、GW のような大型連休は 1 年の中での頻度が低いため、完全に機械学習モデルに任せるのではなく、直近の数値を前年の予測値で補正するようなアルゴリズムとなっているのです。

[GW 中予測値] = [前年 GW 週平均] × [予測時点までの 4 週間の平均] ÷ [前年の予測時点までの 4 週間平均]　☆

※本当はそこまで単純ではないですが、アイディアとしては似たようなことをしました。
アイディアとしては、そんなに間違っていないような気がしますが、実は特殊なケースで非常におかしな挙動をすることがわかります。たとえば、前年に極端に出荷数量が少なかった商品は、☆ の式の分母が極端に小さくなり、予測値が大きくなってしまうのです。これのせいで、非常に大きな発注値を出していました。
そういうケースに注意して、アルゴリズムを組み立てる必要があります。こうしたことに気づくために、過去データを用いて、とある断面全部のデータについて予測値を出してみて、お客様にもご協力いただきつつ、全件（！）精査していくプロセスが不可欠だったのだと思いました。

② 発注計算で不備が出る

運用開始から 1 か月程度たったころ、突然お客様から電話が来ました。
「ねえ……これ、ちゃんとリードタイム反映されています？もっと早く発注しないと、間に合わないんじゃないの？」
発注計算結果を見ると、正しく計算できているように見えます。確かに、安全在庫を割り込むよりも、リードタイム分余裕をもって発注しています。しかし、お客様は「できていない」と言います。
よくよく話を聞くと、

私たちは「発注日から納品日」で計算していた
現場は「確定日から棚並べ完了まで」だった

同じ言葉なのに、定義が全然違いました。「なんか微妙にズレてるな」が積み重なって、ようやく発覚したのです。
あたりまえではありますが、定義が食い違っていては、正しいアルゴリズムを組むことはできません。認識合わせは丁寧にやる必要があります。
たとえば、Excel で具体例を作って見せながら、「おっしゃっていることは、こういうことですよね？」みたいな感じで認識合わせをしていくと、確実にすり合わせることができます。
※下記みたいに、具体的に数字を入れ、ロジックをエクセルの数式に埋め込んで、エクセルを動かしながら、お客さんに説明していました。

③(a) 運用ルールの不備：想定外の値を入力されてしまい、おかしな計算結果が出た

もっと直接的な「事故」も起きました。普段 30 個くらいしか頼まない牛乳が、600 個くらい発注されてしまっていたのです。
なぜ、こんなことが起きてしまったのか？
実は、お客様が発注の設定を変更できる画面があるのですが、それをお客様側の誰かが、
「牛乳は 600 個以上じゃないと発注できない」
というふうに変更してしまっていたのです。
これは、お客様側の設定を変えてしまった人が問題なのではなく、運用設計を十分にしていなかったことが問題でした。

どのパラメータは、誰が変更していいのか？
現行設定と大幅に異なる値が入力された場合には、どうなるのか？

そもそも入力できないようにするのか？

仕入れ業務を総括している部門に申請しないとだめにしておくべきなのか？

パラメータに限らず、入力データや出力データが通常と大幅に異なる場合には、どうなるべきなのか？

こういったことを十分に設計し、システム的にも組み込まれた状態をつくっておくべきでした。
※こういう話は、またどこかで出てくると思うので、その際に、誰かが詳しく話してくれると思います。

③(b) 運用ルールの不備：顧客が予測根拠を理解できず不安になり、お問い合わせが大量に来た

満を持して試験運用を開始しました。その直後から、お問い合わせが止まりませんでした。
「この商品、なんでこんなに多い／少ないんですか？」「先週と全然違うんですけど？」「なぜ、欠品したんですか？」 ……
いずれも、落ち着いて考えてみると、ちゃんと合理的な理由があるとわかります。

たとえば、「想定よりも多い／少ない」は、発注計算のロット組みの問題で前倒しがあったためであり、「先週と全然違う」のは、大口の取引先から先日付受注が入っていたからであり、欠品が発生した理由としては、システム在庫と実在庫が食い違っていたがゆえに、AI が「まだ発注しなくていい」と誤解してしまったから、などです。
しかし、お客様側には予測値だけしか共有していなかったため、全然理由がわからず、困惑されてしまっていたのでした。

人間、理由がわかれば安心する生き物です。
機械学習モデルは、非常に色々な要素を組み込んで、高い精度での予測をしてくれます。一方で、なぜそんな予測値になったのか？がわかりにくい傾向があります。そこで、予測値を出すだけではなく、その「根拠」に相当するものが出る仕組みが必要と考えられます。

現在では、弊社では、お客様に対して「見える化シート」と「欠品明細」といったものを出して、連携しています。
※SHAP などのアルゴリズムベースで「根拠」を可視化する方法もあると思いますが、ここでは、予測に用いたデータを並べて表示したり、ルールベースで「根拠」を割り振ったりしているだけのものにしています。

幸いなことに、こんないろんなことがありましたが、トラブルがある都度、それを解消してきて、現在では安定運用が実現できており、業務効果も上げ続けています。
トラブルの都度、建設的に、一緒に乗り越えようとしていただいたお客様には感謝です。が……同種の案件があったら、こういうことに最初から気を付けられたらよいなと思ったのでした。

この案件を通じて得られたこと

この案件を通じて得られたことをまとめると、

① 情報戦で負けない
予測精度が上がり切らないとき、技術的な工夫以前に、現場で予測をしている人しか知らないデータ・情報がないか？調査。

② 認識合わせは丁寧に
特に最適化の制約条件は、字面だけで顧客とすり合った気になってはならない。具体例やExcel簡易ツールなどでロジックを再現しながら。

③ AI運用においては精度以外も重要
業務担当者が納得する根拠の提示、想定外の動きを防ぐための運用ルール設計。

最後まで読んでいただき、ありがとうございます！
ぜひ、いいねを押していただけると励みになります🐈

また、アポロでは新たなメンバーを募集しています。皆さまのご応募お待ちしております！