滞留在庫検知AIは「データ準備」で9割決まる。汚れたデータを宝に変える前処理と特徴量エンジニアリングの極意

企業のAI導入支援、特にサプライチェーン領域のプロジェクトにおいて、「最新のAIツールを導入したのに、ベテラン担当者の勘の方が当たる」「予測精度が低すぎて、結局エクセルで管理している」といった課題が頻繁に生じています。経営層は「AIを導入すれば魔法のように在庫が最適化される」と期待しがちですが、実際の現場のデータは、AIがそのまま学習できる状態ではない「汚れたデータ」が広がっていることがほとんどです。

在庫管理AIの成功は、モデルの優劣ではなく、データ準備（前処理）で9割決まると言っても過言ではありません。

サプライチェーン最適化のプロジェクトでは、最新のアルゴリズムを追及するよりも、データ整備に時間をかける方が、投資対効果が高いことが知られています。

本記事では、高価なツールを導入する前に、まず手元のデータをどのように「AIが学習可能な状態」にするか、その具体的なエンジニアリング手法を解説いたします。Pythonなどのプログラミング知識が少しある方なら、今日からでも実践できる内容です。データという原石を磨き上げ、ビジネス価値を生み出すプロセスを順を追って見ていきましょう。

なぜ「モデル選び」より「データ準備」が重要なのか

機械学習の世界には、古くから語り継がれる「GIGO（Garbage In, Garbage Out）」という原則があります。これは「ゴミを入れれば、ゴミが出てくる」という真理を表しています。どんなに高性能なディープラーニングモデルを導入したとしても、入力するデータ自体が不正確でノイズだらけであれば、出力される予測結果もまた実務では使い物になりません。

アルゴリズムの性能差よりもデータ品質が結果を左右する

多くのエンジニアやデータサイエンティストは、XGBoostやLightGBMといった強力な手法や、Transformerベースのモデル選定に熱中しがちです。

特に近年、Hugging Face Transformersはモジュール型アーキテクチャへと刷新され、量子化モデルの第一級サポートやキャッシュAPIの統一によるメモリ効率の向上が図られました。その一方で、TensorFlowやFlaxのサポートは終了し、PyTorchを中心とした最適化へと大きく舵が切られています。もしTensorFlowベースで構築された既存のパイプラインがある場合は、公式の移行ガイドを参照しながら、PyTorchへのコード書き換えや、相互運用ツールの活用といった具体的な移行ステップを計画する必要があります。

こうした最新アーキテクチャへの追従やフレームワークの移行作業は確かに重要です。しかし、実務において直面する「精度の壁」は、アルゴリズムの違いによる数パーセントの誤差ではなく、データ品質の低さに起因する数十パーセントの乖離にあることが大半なのです。

小売業界における滞留在庫（デッドストック）の予兆検知モデル構築を例に考えてみましょう。最新のアーキテクチャを導入し、パラメータチューニングに膨大なコンピューティングリソースを費やしても、精度の向上が早期に頭打ちになるケースは珍しくありません。その一方で、データの欠損値をビジネスロジックに基づいて適切に補完し、特異な外れ値を除外するといった地道な「前処理」にリソースを集中させた結果、予測精度が劇的に改善するというのが、データサイエンス業界の共通認識となっています。

滞留在庫検知における誤検知のコスト

在庫管理、特に滞留在庫の検知において、モデルの誤った予測はダイレクトに大きなビジネスリスクへと直結します。

• 偽陽性（False Positive）: 実際には定価で売れるはずの商品を「滞留リスクあり」とAIが誤認し、早まって値下げ処分してしまう。→ 利益率の深刻な低下
• 偽陰性（False Negative）: 実際には売れない商品を「需要あり」と誤認し、倉庫に保管し続けてしまう。→ 保管コストの増大と最終的な廃棄ロス

ノイズの多い汚れたデータで学習したモデルは、このどちらかの致命的なミスを犯しやすくなります。特に、過去の「一時的な特需」や「在庫切れによる機会損失」という背景事情を考慮せずに生の売上データだけを学習させると、AIは誤ったパターンを普遍的な法則として記憶してしまう危険性があります。

成功プロジェクトの多くは前処理に時間を割く

一般的な機械学習プロジェクトでは、システム構築の全工数の大部分を、データの収集・統合・加工（ETL処理や特徴量エンジニアリング）に費やします。純粋なモデルの学習や評価にかける時間は、相対的に見ればごくわずかです。

「データサイエンス」や「AI開発」という言葉の響きは非常にスマートですが、その実態は泥臭い「データのお掃除」と言えるかもしれません。しかし、ビジネスの現場に散らばる不完全なデータを丁寧に整理し、AIが学習しやすい形に整えるこの地道な工程こそが、他社が容易に模倣できない強力な競争力の源泉となります。

Step 1: 収集すべきデータソースと品質定義

では、具体的にどのようなデータを集めればよいのでしょうか。在庫予測において「入出庫履歴（トランザクションデータ）」が必要なのは言うまでもありませんが、それだけでは不十分です。

入出庫履歴だけでは足りない：外部要因データの統合

「いつ、何個売れたか」という情報だけでは、「なぜ売れたのか（あるいは売れなかったのか）」という文脈（コンテキスト）が見えません。AIに文脈を理解させるためには、以下のようなデータソースを結合する必要があります。

1. トランザクションデータ: 販売実績、入庫実績、在庫移動ログ。
2. 商品マスタデータ: カテゴリ、サイズ、色、定価、原価、発売日。
3. カレンダー情報: 祝日、曜日、給料日、販促イベント期間。
4. 外部要因データ: 気象データ（気温・降水量）、競合店の価格動向（可能な場合）。

特に見落とされがちなのがカレンダー情報です。「売上が落ちた」という事実に対し、それが「商品の魅力低下」なのか、単に「平日だったから」なのかをAIが区別するには、カレンダーの特徴量が不可欠です。

マスタデータの整合性チェック

データ収集の段階で最も大きな障壁となるのが、マスタデータの不備です。以下のような状況は、多くの企業のデータベースで見受けられます。

• 同じ商品なのに、システムによって商品コード（SKU）が異なる。
• カテゴリ分類のルールが途中で変更され、新旧のルールが混在している。
• 「サイズ」のカラムに「L」「Large」「大」といった表記揺れがある。

これらを放置したまま学習させると、AIはそれぞれを別の商品、別の属性として認識してしまい、データの分散が起きて学習効率が下がります。まずは名寄せや表記の統一といった、基本的な正規化が必要です。

「使えるデータ」の3つの条件

機械学習に使用するデータセットとして、最低限クリアすべき品質基準として、以下のような点が挙げられます。

1. 完全性（Completeness）: 必要な期間、必要な項目のデータが揃っているか。特定の期間だけデータが抜けていると、季節性の学習に支障が出ます。
2. 一貫性（Consistency）: データの定義や単位が統一されているか。例えば、ある期間は「税込価格」、別の期間は「税抜価格」で記録されていると、AIは価格変動と誤認します。
3. 正確性（Accuracy）: 実態を正しく反映しているか。手入力による明らかな桁間違い（100円の商品が10000円で登録されているなど）は除外する必要があります。

Step 2: 在庫データ特有のクレンジング手法

データが集まったら、次は「クレンジング（洗浄）」です。在庫データには、一般的なデータ分析とは異なる特有の落とし穴があります。ここでは実務で頻出する課題とその対処法を見ていきましょう。

欠品期間の扱いとゼロ値の意味

在庫データ分析において最も注意すべき点は、「販売数ゼロ」の意味です。

• ケースA: 在庫はあったが、需要がなくて売れなかった（真のゼロ）。
• ケースB: 需要はあったかもしれないが、在庫切れ（欠品）で売れなかった（機会損失）。

この2つを区別せずに「売上0」として学習させると、モデルは「この商品は人気がない」と誤って学習してしまう可能性があります。これが滞留在庫予測の精度を下げる大きな要因です。

対処法: 在庫履歴と照らし合わせ、「在庫数が0だった期間」の販売実績は、学習データから除外するか、あるいは「欠品フラグ」を立ててAIに「これは特殊な状況である」と教える必要があります。より高度なアプローチでは、前後の売れ行きから「もし在庫があったら売れていたはずの数量」を推計して補完することもあります。

返品・キャンセルのマイナス処理

基幹システムから抽出した生データには、返品やキャンセルによる「マイナス売上」が含まれていることがあります。これをそのまま時系列データとして扱うと、ある日の売上がマイナスになるなど、需要予測モデルにとって理解不能なノイズとなります。

対処法: 返品データは、需要予測の観点からは「なかったこと」にするのが基本です。あるいは、返品が発生した元の販売日に遡って数量を減算する処理が理想的です。ただし、返品率そのものを予測したい場合は別のアプローチが必要になりますが、純粋な需要量を予測する場合は、返品によるノイズは除去すべきです。

異常値（特需や入力ミス）の検出ルール

「ある日突然、普段の100倍売れた」というデータがある場合、それが「SNSで話題になった特需」なのか、「入力ミス」なのかを判断する必要があります。

対処法: 統計的な手法を用いて外れ値を検出します。例えば、移動平均から標準偏差の3倍（3シグマ）以上離れた値を異常値とみなすルールなどが一般的です。

ここで重要なのは、異常値を単に削除するのではなく、「異常値フラグ」として特徴量に加えるという考え方です。「特需があった」という事実自体は情報として価値があります。ただし、将来の予測（定常的な需要予測）を行う際には、特需の影響を差し引いてモデルに学習させる工夫が必要です。

Step 3: 予測精度を高める特徴量エンジニアリング

クレンジングできれいになったデータを、さらにAIがパターンを見つけやすい形に加工する工程を「特徴量エンジニアリング」と呼びます。予測精度を高める鍵となります。

時系列データのラグ特徴量と移動平均

「明日の売上」を予測するために最も強力な情報は、「昨日までの売上」です。これをモデルに渡すために作成するのがラグ特徴量（Lag Features）です。

• ラグ1: 1日前の売上
• ラグ7: 1週間前の売上（曜日による周期性を捉えるため）
• ラグ30: 1ヶ月前の売上

Pythonコードのロジックで説明すると、データフレームの列を1行、7行、30行ずらして（shift）、新しい列として追加するイメージです。

さらに、単日のデータだけでなく、移動平均（Rolling Mean）も有効です。「過去7日間の平均売上」や「過去30日間の平均売上」を特徴量として加えることで、日々の細かな変動（ノイズ）を平滑化し、大まかなトレンドをAIに伝えることができます。

「滞留」を定義する経過日数の特徴量化

滞留在庫を検知するためには、「その商品がいつから倉庫にあるか」という時間経過の情報が必須です。

• 最終入庫からの経過日数: 新鮮な在庫か、古い在庫か。
• 最終販売からの経過日数: 最後に売れてから何日経っているか。

これらの日数を数値として入力することで、モデルは「入庫から○日経過しても×回しか売れていない商品は、将来滞留するリスクが高い」という複雑なルールを学習できるようになります。

カテゴリ変数のエンコーディング（One-Hot vs Label）

商品カテゴリや色、曜日といった文字データ（カテゴリ変数）は、そのままでは計算に使えないため、数値に変換する必要があります。代表的な手法は以下の2つです。

1. One-Hot Encoding: 「赤」「青」「緑」という値を、「赤フラグ」「青フラグ」「緑フラグ」という3つの列に分解し、該当箇所に1を立てる手法。カテゴリ数が少ない場合（曜日や季節など）に適しています。
2. Label Encoding: 「赤=1」「青=2」「緑=3」のように数値に置き換える手法。決定木ベースのモデル（XGBoostなど）では有効ですが、数値の大小関係に意味がない場合（赤より緑が大きいわけではない）は注意が必要です。

在庫データの場合、SKU数が膨大になるため、One-Hot Encodingを行うと列数が爆発的に増えてしまいます。そのため、カテゴリごとの過去の平均売上率などを特徴量にするTarget Encodingという手法がよく使われます。

Step 4: リークを防ぐ検証データの設計

最後に、構築したモデルが本当に実務で使えるかどうかを検証するためのルール設計について解説します。ここで最も犯しやすいミスが「データリーケージ（情報の漏洩）」です。

未来の情報を学習させないための時系列分割

一般的な機械学習（画像の分類など）では、データをランダムに「学習用」と「テスト用」に分けます。しかし、時系列データである在庫予測でこれをやると問題が発生する可能性があります。

なぜなら、ランダムに分けると「明日のデータ」を使って「昨日のデータ」を予測するような状況が発生してしまうからです。これはカンニングと同じで、テストの点数は良くても実力ではありません。

対処法: 必ず「時系列に沿って分割（Time Series Split）」を行います。例えば、2022年のデータで学習し、2023年のデータでテストする。このように「過去のデータだけを使って未来を予測できるか」を検証しなければ、実務での精度は保証できません。

在庫処分アクションの影響分離

過去のデータの中に「滞留しそうだったから半額セールをして売り切った」という実績が含まれている場合、注意が必要です。モデルがこれを「この商品は定価でも売れる」と勘違いして学習してしまうと、将来の滞留リスクを見逃す原因になります。

検証時には、「販売価格」や「割引フラグ」も考慮に入れた評価を行うか、あるいはセール期間を除外して「自然な需要」だけで評価を行う設計が必要です。

モデル評価指標の選び方（Precision vs Recall）

モデルの良し悪しを判断する際、単なる「正解率（Accuracy）」だけを見てはいけません。ビジネスの目的に応じて指標を選びます。

• Precision（適合率）重視: 「滞留する」と予測したものが本当に滞留した割合。無駄な値下げ（利益損失）を防ぎたい場合に重視します。
• Recall（再現率）重視: 実際に滞留したもののうち、どれだけ予測できたかの割合。在庫保管コストや廃棄ロスをどうしても減らしたい（見逃しを許さない）場合に重視します。

多くの企業では、廃棄コスト削減が優先されるため、Recallを高めに設定しつつ、Precisionが許容範囲に収まるバランスを探ることが多いです。

まとめ：データ基盤こそがビジネス資産

ここまで、在庫管理AIにおけるデータ準備の重要性と具体的な手法について解説してきました。

1. GIGOの原則: データの質がAIの質を決める。
2. データ収集: トランザクションだけでなく、カレンダーや外部要因も統合する。
3. クレンジング: 欠品期間や返品データを適切に処理し、ノイズを除去する。
4. 特徴量エンジニアリング: ラグや移動平均、経過日数など、AIが理解しやすい指標を作る。
5. 検証設計: 時系列を意識した分割で、未来情報のリークを防ぐ。

これらは地道で時間のかかる作業ですが、この工程を丁寧に積み上げることでしか、実務で使えるAIは生まれません。「データが汚いからAIは無理」と諦める必要はありません。汚れたデータも、適切な処理を施せば、ビジネスを加速させる「宝の山」に変わる可能性があります。

データという資産を最大限に活用し、在庫リスクのないサプライチェーンを構築する第一歩を踏み出してください。