AI在庫最適化プラットフォームを外部委託で実現した小売グループの舞台裏

はじめに――在庫の“ムダ”はなぜ生まれるのか

売り逃しと過剰在庫は、どちらも利益を押し下げる大きな要因です。特に全国に店舗網を持つ中堅以上の小売グループでは、店舗ごとの売れ筋や季節波動、キャンペーン施策などが複雑に絡み、勘と経験だけでは最適な仕入れ判断が難しくなっています。本稿では AI を組み込んだ在庫最適化プラットフォーム を、外部のシステム開発会社と協働しながらわずか 8 か月でローンチした実例を取り上げ、予算設定・発注・実装フローまでを具体的に解説します。

ユースケースの全体像――「AI 在庫最適化プラットフォーム」とは

本プロジェクトで構築したシステムは、POS データや気象 API、販促カレンダーをリアルタイムで取り込み、機械学習モデルが翌週の来店客数と SKU 別販売量を予測。自動発注数量を算出して基幹システムへ連携することで、店舗担当者の発注作業時間を 40 % 削減しつつ廃棄ロスを 22 % 低減しました。特筆すべきは 発注アルゴリズムをマイクロサービスとして分離 し、他部門の需要予測にも再利用できる拡張性を備えた点です。

既存業務の課題――人的判断と Excel 管理の限界

プロジェクト開始前、各店舗の発注はバイヤーが Excel で管理するシンプルな構成でした。しかし次のような問題が顕在化していました。

• 属人化：判断根拠が個人の経験値に依存し、担当交代時に予測精度が落ちる

• 情報断絶：POS データと販促計画がシステム的に結合しておらず、勘違いが頻発

• 計算量不足：週次発注に 5 時間以上を費やし、他の戦略業務に時間を割けない
  こうした状況を打破するには、「人が作業する領域」と「AI に任せる領域」を再設計する必要がありました。

システム開発会社の選び方――要件×予算×費用対効果

発注予測アルゴリズムを内製する案も検討しましたが、データサイエンス人材の採用難易度と教育コストを考えると、受託開発 が最適解と判断しました。選定時は次の基準を設定しています。

1. 業務理解力：リテール領域の実績と、要件定義フェーズでのドメイン知識提供力

2. MLops 経験：機械学習モデルを CI/CD に組み込んだ Web システム開発フローの保有

3. 費用透明性：要件定義→設計→ PoC→本開発→保守運用の全工程に明確な見積もり

4. 発注後の体制：データエンジニアとアプリ開発エンジニアが同一組織に在籍すること
   最終的に 3 社で相見積もりを取り、機能別工数やライセンスコストを比較。費用対効果試算を提示できた 1 社と契約しました。
   

   　3分でわかる！スマホアプリ・Web開発の費用感をスピードチェック。　

プロジェクト計画――8 か月を 3 スプリントで走り切る

スプリント 1：要件定義 & PoC

• データ可用性 を洗い出し、モデルに投入可能な特徴量を決定

• 2 か月で PoC を実施し、MAE（平均絶対誤差）15 % 改善を確認

スプリント 2：システム設計 & 実装

• 予測エンジンを Python FastAPI、ダッシュボードを Next.js で開発

• キュー基盤に RabbitMQ、デプロイは AWS ECS を採用

スプリント 3：運用テスト & 本番リリース

• 売上データを用いた A/B テストを 6 週実施し、ロス削減を定量化

• KGI/KPI ダッシュボードを経営層向けに公開し、意思決定の高速化を支援

予算と費用構成――相場観とコスト最適化のポイント

総開発費は約 3,500 万円。その内訳は下記のとおりです。

フィードバックループ――モデル精度を高める運用設計

精度改善は “作って終わり” ではなく、ユーザー行動を学習データに還流させる仕組み を持続的に回せるかで決まります。本プロジェクトでは下記 3 層のフィードバックループを実装しました。

1. オンライン学習レイヤ

   • 当日午前 4 時に前日の POS データを S3 に取り込み、バッチで微調整学習を実行

   • 更新後モデルの推論結果と旧モデルを A/B 比較し、閾値を超えた場合のみ自動デプロイ

2. 業務現場レイヤ

   • 店舗担当が「AI 推奨数量」を上書き修正した場合、その理由をプルダウン選択式で記録

   • 修正理由をカテゴリ変数化し、次回学習時の特徴量に付与

3. 経営ダッシュボードレイヤ

   • 月次で KPI（在庫回転率・廃棄ロス・機会損失）を自動計算

   • 数字が想定外に悪化するとダッシュボードにアラートを表示し、アルゴリズム改修か業務オペレーション改善かを切り分け

この循環により、リリースから 6 か月後には MAE がさらに 8 % 改善し、店舗ごとの発注誤差分布も平準化できました。

店舗現場への浸透――チェンジマネジメントの勘所

テクノロジーが優れていても、現場が信頼しなければ利用定着は望めません。導入時は次の 4 ステップで抵抗感を最小化しました。

• 理解フェーズ：キックオフ時に店舗長向けオンライン説明会を開催し、AI が “脅威” ではなく “味方” であると可視化

• 試用フェーズ：最初の 4 週間は「AI 発注案を閲覧するのみ」で、人が最終決裁する “シャドーモード” を実施

• 協業フェーズ：AI 発注と人の経験値を比較し、追加したいルールをヒアリングしてモデルへ反映

• 定着フェーズ：店舗別 KPI を掲示板に張り出し、成果が出た店を毎月表彰する報奨制度を導入

心理的ハードルを段階的に下げることで、導入 3 か月後には 91 % の店舗が完全自動発注へ移行しました。

セキュリティとガバナンス――外部 API 連携時のリスク低減策

気象 API など外部データを扱う場合、情報漏えいとサービス停止の二重リスク が存在します。本プロジェクトでは、以下の対策を講じました。

• ゼロトラスト・アーキテクチャ：API Gateway でトークン認証、WAF による IP 制限を実装

• サービスレベル契約（SLA）監視：外部 API の稼働率を CloudWatch で 5 分間隔監視し、閾値割れ時にフォールバックロジックを発動

• PII 隠蔽：機械学習パイプライン内で顧客 ID をハッシュ化し、モデル入力では個人を一意に特定できない形式に変換

• 監査ログ：全アクセスログを 7 年間 Glacier に保管し、社内監査・外部監査に対応可能な体制を整備

これにより、リリース後も ISMS・PCI DSS の両認証を維持したまま運用を続けています。

スケーラビリティと多業態展開――プラットフォーム化へのロードマップ

食品・日用品以外の部門 からも「同じ予測基盤を使いたい」との要望が相次ぎ、プロジェクト開始時点でスケール戦略を設計しました。

1. マイクロサービス分割

   • 予測 API は gRPC で公開。商品マスターや価格マスターは別サービスとし、単一障害点を排除

2. テナント概念の導入

   • 業態や店舗リージョンを “テナント” として分離し、モデルパラメータをテナント固有に切り替え

3. 自動オンボーディング

   • 新店舗追加時は Terraform にパラメータを流すだけで VPC・ECS・RDS が 30 分以内に構築完了

4. データ共有基盤

   • Redshift RA3 を導入し、部門横断のデータレイクを用意。BI チームが横串で分析可能に

半年でドラッグストア部門、さらに 3 か月後には EC 事業部へも横展開し、全社在庫回転率を平均 12 % 向上させました。

ROI 最大化――追加開発とデータ活用の拡張シナリオ

初期 ROI（投資回収）は 18 か月で達成見込みでしたが、データ活用の派生案件 によりさらに短縮できました。

• ダイナミックプライシング連携：需要過多が予測された SKU の価格を自動微調整し、粗利を平均 4 % 上乗せ

• サプライヤー交渉資料の自動生成：納入契約更改時に、AI 需要予測を根拠とした発注ボリューム試算を提示し、仕入れ単価を 2 % 引き下げ

• 廃棄ロス削減と ESG レポート：削減されたフードロス量を CO₂ 換算し、ESG 報告書に掲載して企業価値を向上

これら二次的効果を含めると、実質的な回収期間は 11 か月に短縮されました。

プロジェクト総括――ユースケースから得た教訓と次のステップ

• 要件定義で“ビジネス目標”を数値化 したことが、開発優先度のブレ防止に直結

• モデルと UI を疎結合に設計 することで、アルゴリズム刷新をサービス無停止で実施可能

• 現場を巻き込む報奨制度 が、AI への抵抗感を解消し導入スピードを加速

• DevOps＋MLops の両輪 を回す体制投資が、長期的な保守コスト最適化に寄与

今後は、サプライチェーン上流の 物流センター在庫最適化 や、需要予測結果を活用した 広告入札最適化 など、データドリブン経営の横展開を計画中です。ビジネスとテクノロジー双方の視点で ROI を高められるかが、次フェーズの成否を握るでしょう。