在庫予測と需要計画のためのWebアプリを作る

作るものと、その重要性

在庫予測と需要計画のウェブアプリは、将来の需要予測と現在の在庫状況に基づいて、ビジネスが「何をいついくつ買うか」を決める手助けをします。

在庫予測は各SKUの将来の販売・消費を予測します。需要計画はその予測を発注点、発注数量、タイミングといった意思決定に変換し、サービス目標やキャッシュ制約に合わせます。

解決する課題

信頼できるシステムがないと、チームはスプレッドシートや勘に頼りがちで、通常は二つのコストのかかる結果になります：

• 欠品（機会損失、急ぎの出荷、顧客不満）
• 過剰在庫（資金の固定、保管費、値引き、陳腐化）

よく設計された在庫予測アプリは、需要予測と推奨アクションの共有された基準を作り、拠点・チャネル・チーム間で意思決定を一貫させます。

シンプルに始め、改善する

信頼と精度は時間とともに築かれます。MVP（最小実行可能製品）の需要計画アプリは次のように始められます：

• コアSKUの小さな集合
• 単純な週次予測
• 基本的な発注推奨

ユーザーがワークフローを採用したら、データ改善、セグメンテーション、プロモーション処理、より賢いモデルで精度を上げていきます。目標は「完璧な予測」ではなく、繰り返せる意思決定プロセスをサイクルごとに改善することです。

主なユーザー

典型的なユーザーは：

• 需要／在庫プランナー：計画作成と例外レビュー
• オペレーション／倉庫チーム：受領と配分の準備
• 購買／調達：発注とサプライヤ管理
• ファイナンス：在庫投資と運転資本の把握

最適化すべき成果

アプリの評価はビジネス成果で判断します：欠品の減少、過剰在庫の削減、明確な購買判断。これらが在庫計画ダッシュボードで見えることが重要です。

MVPの範囲：意思決定、期間、粒度

在庫予測アプリは「何をサポートするか」「誰のためか」「どの詳細度でか」が明確でなければ成功しません。モデルやチャートの前に、MVPが改善すべき最小の意思決定セットを定義してください。

1) ビジネスの問いから始める

機能ではなくアクションとして書き出します：

• 各品目の発注量（推奨数量）
• いつ発注するか（発注日または再発注トリガ）
• どこへ発注するか（どのSKU、どのロケーション／チャネル）

画面がこれらの質問のどれにも結びつかないなら、その画面は後のフェーズに回すべきです。

2) 計画期間と更新頻度を決める

リードタイムや購買リズムに合った期間を選びます：

• 週単位（例：4〜12週間）— 回転の速いSKUや短リードタイム向け
• 月単位（例：3〜6か月）— 輸入品や季節商品向け

更新の頻度も決めます：売上が早く変わるなら日次、購買が決まったサイクルなら週次。これがジョブ実行頻度と推奨更新頻度を決めます。

3) 運用可能な粒度を選ぶ

実際に発注・移動できるレベルが正しい粒度です：

• SKU-ロケーション（最も実行可能でデータ要件大）
• SKUのみ（単一倉庫構成に有効）
• カテゴリやチャネル（データが疎な初期MVP向け）

4) 成功指標を定義する

測定可能にします：サービスレベル／欠品率、在庫回転、予測誤差（例：MAPE、WAPE）。指標は欠品防止や過剰在庫削減と結びつけます。

5) MVPの範囲と後続フェーズ

MVP: SKU（またはSKU-ロケーション）ごとの1つの予測、1つの再発注点計算、簡単な承認／エクスポートワークフロー。

後続: マルチエシェロン最適化、サプライヤ制約、プロモーション、シナリオプランニング。

データソースとデータ品質の要件を特定する

予測は入力データ次第です。モデルや画面を選ぶ前に、どのデータがあり、どこにあり、MVPにとって「十分な品質」とは何かを明確にしてください。

必要なコア入力

最低限必要なのは一貫したビュー：

• 販売／受注履歴（SKU、ロケーション、日付ごと）
• オンハンド在庫と在庫ポジション（オンハンド + 入荷予定 − 引当）
• 受領と発注書（何が到着したか、何がいつ来るか）
• リードタイム（サプライヤ、輸送経路、倉庫処理）
• カレンダー（祝日、プロモ、店舗休業、季節性マーカー）

データは通常どこにあるか

多くのチームは複数のシステムから引きます：

• ERP：発注書、サプライヤ、品目マスタ、コスト
• WMS：受領、入庫、移動、在庫調整
• POS／eコマース：需要信号（注文、キャンセル）
• スプレッドシート：現場のナレッジ（オーバーライド、最小数、梱包単位）

更新頻度と遅延変更の扱い

アプリの更新頻度（毎時、日次など）と、データが遅れて到着したり編集されたときの扱いを決めます。実用的なパターンはトランザクション履歴は不変にし、編集は上書きではなく調整レコードで適用することです。

所有権と簡単なデータ辞書

各データセットにオーナーを割り当てます（例：在庫は倉庫オペレーション、リードタイムは調達）。短いデータ辞書（フィールドの意味、単位、タイムゾーン、許容値）を維持します。

よくあるギャップに備える

欠損リードタイム、単位変換（each vs case）、返品・キャンセル、重複SKU、不一致なロケーションコードなどは想定しておき、MVPでは明示的に修正、デフォルト、または除外する方針を示しましょう。

予測と在庫のためのデータモデル設計

アプリの信頼は「何が起きたか」（販売、受領、移動）が曖昧でないことと、「今何が真実か」（オンハンド、オンオーダー）が一貫していることから始まります。

コアエンティティから始める

小さなエンティティセットを定義し全体で統一します：

• SKU（製品） とSKU属性（カテゴリ、梱包サイズ、賞味期限）
• ロケーション（倉庫、店舗、3PLノード）
• サプライヤ（リードタイム、最小発注数量）
• 顧客／チャネル（小売、卸、マーケットプレイス）
• 時間（固定粒度のカレンダー）

単一の時間粒度を選び、すべてを合わせる

日次または週次を正準の粒度に選びます。すべての入力をそれに合わせるルールを明示します（例：「販売は出荷日に帰属し、日でバケット化する」）。

単位と通貨を早めに標準化する

販売が each／case／kg のいずれであっても、元の単位と予測用の正規化単位（例：each）を保持します。収益を予測するなら元通貨と報告通貨の両方を保持し、為替レートの参照を置きます。

在庫をイベントとしてモデル化する（説明可能にする）

SKU-ロケーション-時間ごとに、オンハンドスナップショット、オンオーダー、受領、移動、調整といったイベントの系列を追跡します。これにより欠品の説明や監査が容易になります。

フィールドごとの「単一の真実」定義

ユニット売上、オンハンド、リードタイムなどの主要指標について、どのシステムが権威かをスキーマで決めます。二つのシステムが不一致なら、どちらが勝つか、なぜかを示します。

信頼できるデータパイプライン（ETL）を構築する

予測UIは給餌データの品質次第です。数値が説明なく変わると、モデルが正しくてもユーザーの信頼を失います。ETLは「予測可能で、デバッグ可能で、追跡可能」であるべきです。

パイプラインを計画する：抽出 → クレンジング → 集約 → ロード → 検証

各フィールドの「真実のソース」を書き出し、繰り返し可能なフローを実装します：

• 抽出：API、DB、フラットファイルから不変のランIDで抽出
• クレンジング：型、タイムゾーン、SKU/ロケーションキー、単位変換
• 集約：アプリが必要とする粒度（日次／週次、SKU-ロケーション）に集約
• ロード：予測ジョブが読む分析テーブルへ
• 検証：ダッシュボードに流す前の自動チェック

生テーブルとキュレーションテーブルを分ける（追跡性のため）

2層を保ちます：

• Rawテーブル：受け取ったまま、追記のみ。上流システムが値を変えてもいつなぜ変わったか確認できる。
• Curatedテーブル：標準化されたカラムとビジネスロジック（例：正味売上、利用可能在庫）。

プランナーが「先週の需要がなぜ変わったか」と聞いたら、rawレコードとそれを変えた変換を指し示せるようにします。

問題を早期に検出する自動チェック

最低限検証する項目：

• 日付、SKU ID、ロケーションIDの欠損
• 負の在庫や不可能な在庫移動
• 外れ値（急激な10×売上スパイクなど）や重複トランザクション

不合格ならランを失敗にする（またはパーティションを隔離）して、悪いデータを黙って公開しないでください。

バッチ vs リアルタイム：計画リズムに従う

購買が週次なら日次バッチで十分なことが多いです。即時性が必要な運用（当日補充、急激なEC変動）の場合のみ準リアルタイムを選びます。これにより複雑さとアラートノイズが増えます。

リトライルール、アラート、ランログ

失敗時にどうなるかを文書化します：どのステップが自動リトライするか、何回までか、誰に通知するか。抽出が壊れた、行数が急減した、検証が失敗したときにアラートを出し、各予測入力を監査できるランログを残します。

現実に合う予測手法を選ぶ

手法は抽象的に「優れている」のではなく、あなたのデータ・SKU・計画リズムに合うかが重要です。優れたアプリはシンプルに始め、測定し、投資効果があるところで高度化します。

ベースラインから始め、必ず残す

ベースラインは高速で説明可能、かつ整合性チェックに最適です。最低限含める：

• 移動平均（安定品向け）
• 季節的ナイーブ（前周期を繰り返す）
• 単純指数平滑法（最近の変化に反応しつつ過学習を抑える）

常にこれらと精度比較を行い、複雑モデルがこれらを上回れないなら本番投入すべきではありません。

測定の裏付けができてから賢いモデルを追加

MVPが安定したら段階的に追加：

• 週次／年次の季節性や祝日を扱うProphet系
• 自己相関が強く履歴が十分ある場合のARIMA
• 価格、プロモ、リードタイムなど有益なドライバがあるなら勾配ブースティング

全SKUで一つのモデル vs SKUごとの選定

1つのデフォルトモデルで早く出すのは速いですが、カタログに安定商品・季節商品・ロングテールが混在するならSKUごとのモデル選択（バックテストに基づいて最適ファミリを選ぶ）が効果的です。

間欠的需要を無視しない

多くのSKUがゼロを多く含むなら、それを第一級ケースとして扱います。間欠需要向けの手法（例えばCroston系）を追加し、ゼロを不当に罰する指標を避けて評価します。

ヒューマンインザループのオーバーライド

ローンチ、プロモ、既知の混乱に対してプランナーがオーバーライドできる仕組みを作ります。理由、有効期限、監査トレイルを残し、手動編集が意思決定を改善するが履歴を隠さないようにします。

特徴量エンジニアリングとエッジケース（欠品、新SKU）

予測の精度は多くの場合、追加する特徴量に左右されます。目標は多数の信号を追加することではなく、ビジネスの振る舞いを反映し、プランナーが理解できる少数の特徴量を加えることです。

カレンダー・イベント信号

需要にはリズムがあります。過学習せずリズムを捉える特徴をいくつか追加します：

• 曜日、月の何週目（給料日効果や週末スパイク対応）
• 月／シーズン（大域的な季節性）
• 祝日や地域イベント（バイナリフラグや小さな「祝日タイプ」カテゴリ）
• プロモーション（開始／終了、割引幅、チャネル）

プロモーションが複雑ならまずはシンプルな「プロモ中」フラグから始めて精緻化します。

製品・供給側の信号

在庫予測は需要だけでなく供給可否も重要です。説明可能な信号としては価格変動、リードタイムの更新、サプライヤ制約の有無などが有効です：

• 現行価格と「前期間比の価格変化」
• リードタイム（およびリードタイムの変化）
• 最小発注数量／ケース梱包（発注行動に影響）
• 在庫ステータス（在庫有、低在庫、バックオーダー）

欠品：モデルに間違った学習をさせない

欠品日にゼロ売上をそのまま学習させるのは危険です。一般的な方法：

• 欠品期間をフラグして学習ターゲットから除外
• 直近の非欠品需要で「失われた販売」を補完
• 欠品日数を特徴量として加える

コールドスタートSKUと代替

新商品は履歴がありません。明確なルールを定義します：

• 最も近い上位レベル（カテゴリ／ブランド）の予測から割り当て
• 類似アイテムマッピング（代替品、前任SKU）を使う
• データが増えるにつれプロキシ信号から自身の履歴へ重みを移す

特徴量セットは小さく保ち、アプリ内ではビジネス用語で名前を付けます（例：「祝日週」）。そうすればプランナーはモデルが何をしているかを信頼し、問いただせます。

予測を発注・補充推奨に変える

予測は「次に何をするか」を明示したときに初めて有用です。アプリは予測を具体的でレビュー可能な購買アクションに変換するべきです：いつ発注するか、いくつ発注するか、どれだけの余裕を持つか。

予測から再発注点、セーフティストック、発注量へ

SKU（またはSKU-ロケーション）ごとにまず三つの出力を用意します：

• 再発注点（ROP）：新しい注文をトリガする在庫ポジション
• セーフティストック：需要やリードタイムの変動に備える追加在庫
• 発注量：今日（または次の購買サイクル）に発注すべき数量

実務的な構成：

• 予測に基づくリードタイム中の期待需要
• • セーフティストック（変動性と目標サービスレベルに基づく）
• = 再発注点

可能ならリードタイムのばらつき（平均だけでなく標準偏差）を使うと欠品が減ります。

サービスレベルはビジネス価値で決める

すべての品目で同じ保護は不要です。ABC分類、マージン、重要性によってサービスレベル目標を選べるようにします：

• 高マージン／ミッションクリティカル：高いサービスレベル → 多めのセーフティストック
• ロングテール／低影響SKU：低めのサービスレベル → 低在庫

実務制約を尊重する

推奨は実現可能でなければなりません。制約処理を追加します：

• MOQや梱包単位（ケース）での切り上げ
• 予算上限（インパクトの高いアイテムを優先）
• 容量制限（倉庫スペース、パレット）

「なぜ」を明示する

推奨する発注には短い説明を付けます：リードタイム中の予測需要、現在の在庫ポジション、選ばれたサービスレベル、適用した制約。これが信頼構築につながり、例外の承認を容易にします。

Webアプリのアーキテクチャ：UI、API、ジョブ、ストレージ

予測アプリは人向けのWeb体験とバックグラウンドで動く予測エンジンという二つの製品に分けると保守しやすくなります。分離はUIを高速に保ち、タイムアウトを防ぎ、結果を再現可能にします。

シンプルでスケーラブルなベースライン

4つの構成要素から始めます：

• Web UI：データアップロード、実行設定、予測閲覧、推奨の承認
• API（バックエンドサービス）：リクエスト検証、データの読み書き、ジョブ起動
• データベース：トランザクションデータ（ラン、設定、ユーザー、承認）と大きな成果物の格納場所
• バックグラウンドジョブ：特徴生成、モデルトレーニング、予測、推奨計算の重い処理

予測はUIリクエスト内で実行してはいけません。ジョブキュー（またはスケジュール）に載せ、run IDを返し、UIで進捗をストリーミングします。

プロトタイプを早く作るには、Koder.aiのようなプロトタイピング支援プラットフォームが有効なことがあります：ReactベースのUI、GoのAPI、PostgreSQL、バックグラウンドワークフローを短期間で試作し、整ったらソースコードをエクスポートして本番化できます。

ストレージ：何をどこに置くか

システム・オブ・レコード（テナント、SKU、ロケーション、ラン設定、ラン状態、承認）は主要データベースに保持します。日別予測、診断、エクスポートなどの大容量出力は分析向けテーブルかオブジェクトストレージに置き、run IDで参照します。

マルチテナントは初めから（MVPでも）

複数事業部や顧客を相手にするなら、APIとDBスキーマでテナント境界を強制します。簡単な方法は全テーブルに tenant_id を付け、UIでロールベースのアクセスを実装することです。単一テナントのMVPでも将来的なデータ混在防止のために有益です。

最小限のAPIを定義する

API表面は小さく明確に：

• POST /data/upload（またはコネクタ）、GET /data/validation
• POST /forecast-runs（実行開始）、GET /forecast-runs/:id（状態）
• GET /forecasts?run_id=...、GET /recommendations?run_id=...
• POST /approvals（受諾／オーバーライド）、GET /audit-logs

コストを予測可能に保つ

予測はコストがかかります。特徴のキャッシュ、設定不変時のモデル再利用、週次のフル再学習＋日次の軽量更新などで重い処理を減らし、UI応答性と予算の安定化を図ります。

UXとダッシュボード：予測を使いやすくする

良いUXは「表の数字」を「次にすべきこと」に変えます：何を買うか、いつ買うか、今注視すべきことは何かがすぐ分かることが重要です。

実務に合うコア画面

日々のプランニング課題に対応する少数の画面から始めます：

• 概要：KPI（サービスレベル、欠品リスク、カバー週数）、上位の例外、今日の推奨アクション
• SKU詳細：一画面で履歴、予測、オンハンド、入荷予定、リードタイム、再発注推奨を確認
• 例外：レビューが必要な項目キュー（欠品見込み、過剰、予測誤差の急増、サプライヤ遅延）
• 発注案：ドラフトPO（数量、到着見込み日、予算合計）

ナビゲーションは一貫させ、例外からSKU詳細へ、戻る操作をコンテキストを失わずに行えるようにします。

高速なフィルタと実用的なパフォーマンス

プランナーは頻繁にデータをスライスします。日付範囲、ロケーション、サプライヤ、カテゴリでのフィルタを即時にし、賢明なデフォルト（例：過去13週、主要倉庫）を用意し、ユーザーの最後の選択を記憶します。

分かりやすい説明性（Explainability）

予測が変わった理由を示して信頼を築きます：

• 主要な需要ドライバ（プロモ、チャネル比率、価格変化）
• シンプルな季節性ビュー（週次パターン、祝日）
• 最近の異常フラグ（一度きりの大口注文、データ欠損）

UIで複雑な数理を見せるのではなく、平易な括弧やツールチップで説明します。

協業と責任の所在

軽量なコラボ機能を追加します：インラインノート、高影響発注の承認ステップ、変更履歴（誰がいつオーバーライドしたか、なぜ）を残すことで監査性を保ちつつ日常の意思決定を遅くしません。

エクスポートと印刷向け発注ビュー

多くのチームはファイルを共有します。きれいなCSVエクスポートと印刷向けの発注サマリ（品目、数量、サプライヤ、合計、希望納期）を提供し、購買が再フォーマットせずに実行できるようにします。

統合、権限、監査性

予測はそれを更新できるシステムと、それを信頼する人がいて初めて運用に移ります。統合、アクセス制御、監査トレイルは早期に設計してください。

ERP／WMSとの統合（運用の真実）

在庫意思決定を動かすコアオブジェクトから始めます：

• 品目マスタ（SKU、単位、リードタイムデフォルト、サプライヤ、ステータス）
• 発注書（オープン／クローズ、数量、約束日）
• 受領（何がいつどこに到着したか）
• 移動（倉庫間移動、輸送中在庫）

各フィールドの真実のソースを明示します（例：SKUステータスとUOMはERP、予測オーバーライドはあなたのアプリ）。

複数のインポート方法をサポートする

今すぐ動く道筋と将来スケールする道筋を用意します：

• API連携（準リアルタイム同期）
• SFTPドロップ（レガシーERP向けの夜間ファイル）
• 予定されたCSVアップロード（MVP向けテンプレートと検証）

どの方法でもインポートログ（行数、エラー、タイムスタンプ）を保存し、ユーザーがエンジニアリングの助けなしに欠損データを診断できるようにします。

アイデンティティ、ロール、承認

ロケーションや部門に沿った権限を定義します。一般的なロールは Viewer、Planner、Approver、Admin です。パラメータ編集やPO承認といった重要操作は適切なロールで保護します。

信頼できる監査トレイル

誰が何をいつ変更したかを記録します：予測オーバーライド、再発注点編集、リードタイム調整、承認決定。差分、コメント、影響を受けた推奨へのリンクを残します。

予測KPIを公開する場合は、アプリ内で定義にリンクするか /blog/forecast-accuracy-metrics を参照できるようにします。導入計画には /pricing に基づく段階的アクセスモデルが役立ちます。

テスト、バックテスト、予測品質の測定

予測アプリは「コードが動くか」だけでなく「予測と推奨が成果を改善するか」を証明できなければなりません。テストは精度の証明と、性能低下を検知する仕組みを含みます。

ビジネス意思決定に合う指標を選ぶ

小さな指標セットで始めます：

• MAE（単位での平均絶対誤差）
• MAPE／WMAPE（販売量に対する相対誤差、WMAPEはSKU間で安定）
• バイアス（系統的な過大／過少）
• サービスレベルへの影響（充足率、欠品率）

これらをSKU、カテゴリ、ロケーション、予測期間（次週 vs 来月）ごとに報告します。

現実的な時間分割でバックテストする

本番運用を模したバックテストを行います：

• 履歴ウィンドウで学習し、その後の週／月でテスト（ランダムシャッフルはしない）
• 複数のローリング期間で繰り返し評価して「たまたま当たった」ケースを避ける
• 単純ベースライン（先週、移動平均）と比較する

ガードレールと監視

精度が急落したとき、入力が不正なとき（売上欠落、重複注文、異常スパイク）にアラートを出す監視パネルを /admin に用意しておくと数週間分の誤発注を防げます。

パイロットとフィードバックループ

本格展開前に小規模プランナー／購買担当でパイロットを行います。推奨が採用されたか、拒否されたかとその理由をトラッキングし、そのフィードバックをルール調整やデフォルト改善に使います。

セキュリティ、プライバシー、運用準備

予測アプリは販売履歴、サプライヤ価格、在庫状況、今後の購買計画など機密情報に触れることが多いです。セキュリティと運用は製品機能として扱ってください。1つの漏洩や夜間バッチの破綻が信頼を失わせます。

アクセス制御は地味に厳格に

最小権限の原則で保護します。Viewer、Planner、Approver、Admin などのロールでページだけでなくアクション（コスト閲覧、パラメータ編集、推奨承認、エクスポート）をゲートします。

SSOを導入する場合はグループをロールにマッピングしてオフボーディングを自動化します。

暗号化とシークレット管理

可能な限り通信と保管の暗号化を行います。HTTPSを徹底し、APIキーのローテーション、環境ファイルではなく管理されたシークレットボールトの利用、DBの保存時暗号化とアプリ／ジョブランナーのみが接続できるネットワーク制限を実施します。

監査性：誰が何をしたかを答えられるように

アクセスと重要操作（エクスポート、編集、承認）をログに残します。構造化ログで：

• データインポートとソースファイル
• 予測ラン（手法、パラメータ、コードバージョン）
• 推奨の編集／オーバーライドと承認

これは書類仕事ではなく、在庫計画ダッシュボードのサプライズをデバッグする方法です。

保持、バックアップ、インシデント対応

アップロードと履歴ランの保持ルールを定義します。多くは生データを短期間（30〜90日）、集約結果は長期保持します。

インシデント対応とバックアップ計画を用意します：オンコールは誰か、アクセス撤回の方法、DB復旧手順。API、ジョブ、ストレージの復旧時間目標を文書化し、定期的に復元テストを行っておきます。