先月210個売れたSKUについて、表計算が来月も210個と予測する。一見妥当ですが、実は1週間、商品を購入できない状態だったかもしれません。別の商品では、来月は実施しない販促が販売数を押し上げていた。同じ平均値の計算でも、販売機会の不足と一時的な需要増という異なる問題を見落とすことがあります。

このガイドは、自社のAmazon商品について将来の販売数量を見積もる出品者向けです。必要なデータ、欠品を含む架空の計算例、予測誤差の確認方法を紹介します。資料の確認日は2026年9月10日です。目的は検証できる需要予測であり、販売結果の保証や自動発注ではありません。在庫への投資は、運用・財務責任者が実際の事業条件を踏まえて判断してください。

結論:需要を予測してから補充数量を決める

SKU、マーケットプレイス、数量単位、予測対象期間を定義します。販売数と実際の購入可能な期間を照合し、比較可能な履歴から基準値を計算して、予定された施策による調整を別に記録します。予測の原版を保存し、対象期間の終了後に同じ条件で誤差を確認してください。その結果、前提、未解決事項を責任者に渡してから補充を検討します。

確認基準は、入力の比較可能性、販売可能状況を含む履歴、調整の根拠、学習に使っていないデータでの評価、不確実性の明示、担当者のあるフォローアップの6つです。細かな数字が出るだけでは十分ではありません。その数量が何を表し、どんな条件を仮定し、何が変わると使えなくなるのかを説明できる必要があります。

需要、記録された販売数、補充数量を区別する

数量単位と商品の範囲を固定する

在庫計画が目的なら、売上金額をそのまま数量の代わりにしないでください。値上げで売上が増えても、必要な商品数が増えたとは限りません。1個が販売用パックなのか、構成部品なのか、ケースなのかを決めます。6個入りパックの注文は、販売SKUの単位では1個かもしれません。部品を調達する計画には別の換算が必要です。

マーケットプレイスとSKUの対応も残します。子バリエーションを合算すると、あるサイズの過剰在庫で別サイズの欠品を見えにくくすることがあります。共通在庫を使う複数チャネルの計画では集計が役立ちますが、注文の重複とチャネルの割り当てを確認してから行います。合計の根拠を説明できるよう、元の系列を保持してください。

販売ゼロは必ずしも需要ゼロではない

実際の販売数は、顧客が購入できたか、どのような販売条件を見たかにも左右されます。確認済みの欠品期間に売れなかったことは、欲しい人がいなかった証拠ではありません。一方、通常どおり購入できるのに売れなかった期間は、間欠的な需要を示す重要な情報かもしれません。データ欠損はさらに別の状態です。

履歴の定義自体がそろっていない場合は、先にAmazonビジネスレポート分析で確認してください。注文数量と出荷数量が途中で切り替わっていたり、単一市場と複数市場が混ざっていたりする問題は、予測モデルを導入するだけでは解消しません。

調達に必要な期間と需要そのものを混同しない

今日作る翌週の予測と、今日作る今後12週間の予測は別の課題です。作成日だけでなく、対象となる開始日と終了日を保存します。生産、輸送、受入れに必要な時間は、どこまで先を見通すべきかを決める材料です。入荷が遅れたからといって、顧客需要そのものが同じ割合で増えるわけではありません。

補充には、利用可能在庫、引当済み数量、入荷予定、仕入先の条件、事業上のリスク判断も必要です。妥当な需要予測が280個でも、280個の発注指示にはなりません。資金を投入する判断には原価と商品貢献額の確認も必要になるため、別の論点としてSKU別の商品利益分析を参照してください。

予測式を選ぶ前にデータの出典明細を作る

元のエクスポートは変更せず、日付を付けた作業用データを作ります。以下は計画用データセットで確認したい項目であり、Amazonの1つのレポートにすべて含まれるという意味ではありません。運用担当者の記録から追加する項目にも、担当者と更新時刻を付けます。

表を左右にスワイプすると、すべての列を確認できます。

入力 残す情報 利用前の確認
SKUと商品対応 市場、出品者SKU、関連ASIN、包装単位 バリエーション、セット内容、識別子は変わっていないか
数量履歴 日付、数量、注文または出荷の定義 キャンセル、重複、タイムゾーンの処理は統一されているか
販売可能状況 購入可能、購入不可、状態不明の期間 ゼロは販売なし、購入不可、欠損のどれか
販売施策 価格変更、販促、重要な広告変更 実施されたか、予測期間に再び行うのか
カレンダー 曜日、祝日、関連イベント日 月名ではなく比較対象のイベントをそろえたか
供給条件 リードタイムの前提、販売可能予定日 予測期間の条件を需要実績と取り違えていないか
予測履歴 作成時刻、方法、入力、対象期間 実績が出た後も元の予測を確認できるか

パターンを探す前に合計を照合する

対象期間を1つ選び、作業表の合計を採用した出典と照合します。差異があれば、モデルを当てはめる前に調べてください。同じファイルを2回取り込むだけで、実在しない販売急増が作られます。日付の境界が違えば、月間合計が一致していても週別の数量がずれることがあります。

予測対象を明確に純数量と定義していない限り、返品を需要履歴から一律に差し引かないでください。返品された商品にも、最初の購入要求は存在します。再販売可能な在庫へ戻るかは別の状態確認です。キャンセルや返品の調整をするなら、そのルールを記録し、後の評価でも同じ定義を使います。

在庫の断片的な記録を終日販売可能と扱わない

日末に在庫があるという記録だけでは、終日購入可能だったとは言えません。一部の時間のみ販売可能だった期間や、不明な期間は区別します。信頼できる時間単位の記録がなければ、粗い推定を使って制約を明記し、正確そうな販売可能時間を作り出さないでください。

AWSの公式予測サンプルは、購入できない期間を通常の販売ゼロとして扱うと、予測を下方に偏らせる可能性を指摘しています。これはデータ状態を区別するための注意であり、履歴のゼロをすべて削除する理由ではありません。実際の販売ゼロを保持し、欠損の処理は別に記録します。AWSサンプルの説明

他の担当者が再計算できる基準予測を作る

比較可能な販売機会から始める

簡単な基準は、比較可能で正常に販売できた期間の数量を、その期間の長さで割る方法です。将来の条件が合理的に比較できる場合に限り、その販売速度を対象期間へ延ばします。平均値だけでなく、採用した日付と除外した日付を残してください。

これは参照計算であり、すべての商品に対して偏りのない推定方法ではありません。需要の高い日に欠品したなら、残った日が欠品期間を代表するとは限りません。観測期間がすべて販促中なら、通常時より高い速度になる可能性があります。比較に使える期間がなければ計算を止めます。ゼロで割ったり、任意の値を代入したりして続けないでください。

直近の動きと適切な履歴を比較する

安定した商品では、直近の移動平均を出発点にできます。繰り返しのあるパターンなら、同じ曜日や対応する季節の期間も比較します。年単位の季節性を判断するには、その季節を含む適切な履歴が必要です。数週間のデータだけでは年間の周期を証明できません。

短い集計期間は変化に早く反応する一方、一時的な混乱にも反応します。既知の結果にうまく合うという理由だけで期間を選ばず、その後の未使用データで候補を比較してください。複雑な方法が必要な予測期間で単純な基準を上回らないなら、さらに複雑にする前に入力と前提を調べます。

観測値と担当者の調整を分ける

販売実績、基準の計算、計画担当者の調整を別々に保存します。例えば予定された販促による増加は、理由と担当者のある調整欄に記録します。望む予測を得るために、過去の販売数を書き換えてはいけません。

結果が外れた原因は、基準の作り方、施策の仮定、供給中断のいずれかかもしれません。それらを1つの上書きされた値にまとめると、次に何を修正すべきか分からなくなります。数式を残すだけでなく、人が加えた判断も追えるようにします。

計算例:210個の販売実績から異なる予測が生まれる理由

架空のSKUを28暦日で考えます。比較可能で通常どおり購入できた21日間に210個売れ、残る7日間は購入不可と確認され、販売はゼロでした。ここでは21日間が参照に適するという前提を置きますが、実際のアカウントでは確認が必要です。

合計だけでなく分母を比較する

210個を28日で割ると、暦日当たり7.5個です。同じ210個を21販売日で割ると、販売日当たり10個になります。将来の28日間がすべて購入可能で、他の条件も続くと仮定すれば、後者から280個を計算できます。

どちらの計算も、欠品中に何人が注文したはずかを直接測っていません。差は販売機会に関する前提の違いであり、70個の機会損失を実測したことにはなりません。翌月も同じ販売速度になるという証拠でもありません。

表を左右にスワイプすると、すべての列を確認できます。

計画上の見方 日次数量 将来の期間 計算数量 意味
全暦日の参照値 7.5 28日 210 購入不可の日も平均へ含める
低い速度の感度分析 8 28日 224 レビュー担当者が置いた仮定
比較可能な販売期間の基準 10 28日 280 参照条件の継続を仮定
高い速度の感度分析 12 28日 336 レビュー担当者が置いた仮定

シナリオを統計的な確実性と取り違えない

224、280、336という値は、日次8、10、12個という仮定から計算しています。校正済みの分位点や信頼区間ではなく、実際の需要がこの範囲に収まる証明でもありません。選んだ販売速度が変わると判断材料がどれだけ変化するかを見るための例です。

それぞれの仮定を支える証拠を確認してください。価格や販促の変更が確定していれば、異なる速度を検討する理由にはなりますが、効果の大きさが自動的に分かるわけではありません。根拠が弱ければ探索的な仮定と明記し、中央の値を検証済みの予測として扱わないでください。

発注前に次の確認事項を決める

この例なら、参照日と将来の期間で曜日構成や販促条件が似ているかを確認できます。新しい期間の販売可能状況も確認対象です。担当者を決め、現在の計算バージョンを保持します。

予測を変更する場合も、原版と改訂版の両方を残してください。新情報による合理的な修正と、古い予測を上書きしたために正確に見えるだけの状態を区別できます。検証には、結果を知る前に何を予測したかが必要です。

季節性と販促の影響を二重計上しない

月名だけでなく比較するイベントをそろえる

繰り返しの需要を検討するには、関連する過去の期間を選びます。イベント日が動くこともあり、同じ月でも曜日構成は異なります。購入可能状況、価格、品ぞろえ、広告などの販売条件も比較してください。

Amazonの在庫管理ガイドは、販売履歴と季節性を計画の関連要素として挙げています。ただし、すべての出品者に同じ在庫目標が適するわけではありません。どの過去パターンが再び起きると考えるのか、その当時から何が変わったのかを説明します。Amazon在庫管理ガイド

通常需要と販促シナリオを分ける

直近平均に販促効果が含まれているのに、さらに販促係数を掛けると同じ影響を二重計上する可能性があります。可能なら通常期間の参照値を作り、施策による調整を別に示します。通常時の証拠が足りなければ、効果を分離できないことを明記します。

広告予算を変えても、数量が同じ割合で変化する保証はありません。価格、競合するオファー、顧客行動が同時に動く場合があります。広告費を追加すれば一定数売れると約束するのではなく、検討に使う前提とその理由を残します。

商品が変わったら古いパターンを見直す

商品改良、入数変更、バリエーションの販売終了には、新しい基準が必要かもしれません。対応履歴を保存し、説明できる換算なしに新旧の数量をつなげないでください。突然の増加も、そのまま通常状態とする前にデータの出典を確認します。

長い予測期間では、近い将来の証拠と遠い将来の仮定を分けます。予定がほとんど決まっていなくても、細かな週別曲線は作れます。小数点や滑らかなグラフで不確実性を隠さず、どの部分を後で更新する必要があるかを示してください。

新商品と間欠的に売れる商品は分けて考える

新SKUには架空の履歴ではなく類似商品の根拠を用意する

販売履歴のない商品では、比較対象を意図的に選びます。価格、包装、ポジショニング、発売時の支援条件の違いを記録してください。レビューが蓄積し、安定して購入できる既存商品が、そのまま新商品の代理になるとは限りません。

類似商品を使って限定的なテストの仮定を作り、実績が得られたら更新します。そもそも市場に需要があるかを調べる段階なら、先にAmazonの商品需要分析を参照してください。カテゴリへの関心や競合商品の推定値は、自社新SKUの将来販売数を測ったものではありません。

低頻度商品の本当の販売ゼロを残す

間欠的な商品は、購入可能でも数日間注文が入らないことがあります。そのゼロを削除すると販売速度を過大にします。注文が発生する間隔と、発生時の数量を両方確認し、週別集計がパターンの理解に役立つかを検討します。ただし、意思決定に必要な時期の情報を失わないようにしてください。

少ない観測から安定した日次需要を作り出さないでください。適した専門手法を検討する場合も、単純な基準との公平な比較が必要です。有用な推定を支える履歴がなければ、正確そうなモデル出力より、不確実性を示したシナリオの方が判断に役立ちます。

一時的な中断と販売終了を区別する

在庫切れ、出品上の問題、意図した販売終了では意味が異なります。分かる範囲で中断理由を記録してください。スクリプトが日付の空白を埋めたというだけで、終了商品の需要継続を仮定してはいけません。

商品の範囲、販売可能状況、出典品質が未解決なら、該当する自動提案を止めます。調査依頼としては有用でも、実行可能な発注指示へ変えるべきではありません。対象を増やす前に、解決すべき問題を特定します。

実績が出る前に保存した予測で誤差を測る

必要な予測期間に合わせて評価する

対象期間の開始前に予測を保存し、その後の観測を同じ単位と日付の定義で比較します。1週間先の予測が良かったことを、12週間先の調達判断が信頼できる証拠として使わないでください。可能なら複数の過去時点で検証し、それぞれの時点で入手できた情報だけを使います。

『Forecasting: Principles and Practice』は、学習履歴への適合ではなく、未使用のデータで予測を評価する重要性を説明しています。また、実績がゼロやゼロに近い場合、百分率の誤差指標には問題があるとしています。低頻度SKUでは特に注意が必要です。予測評価の参考資料

平均の偏りがゼロでも外れは残る

以下は別の架空例です。4期間とも終了しており、通常の販売可能条件がありました。この表の符号付き誤差は「予測値−実績値」と定義し、正なら過大予測です。逆の符号を使うシステムもあるため、計算の約束を明記します。

表を左右にスワイプすると、すべての列を確認できます。

期間 保存した予測 観測数量 符号付き誤差 絶対誤差
1 100 90 10 10
2 110 120 -10 10
3 100 80 20 20
4 90 110 -20 20

符号付き誤差の合計はゼロですが、絶対誤差の合計は60です。平均絶対誤差MAEは60÷4で、1期間当たり15個となります。完全に当たったのではなく、過大と過小が相殺された結果です。在庫判断では、総予測数量と総実績数量が一致しても、外れが生じた時期が重要になります。

数値評価と運用結果を分ける

方法の比較には同じ期間と対象を使います。購入できなかった期間を記録し、都合の悪い結果を黙って除外しないでください。販売が制約された場合、観測数量だけでは制約のない需要が分からないことを示します。失われた需要を別途推定するなら、実際の観測系列と分けて残します。

どの商品でも発注を任せられる共通の正解率はありません。誤差の大きさ、方向、予測期間、判断を誤った場合の影響を確認します。予測が合理的でも入荷遅延で欠品は起こり得ます。逆に、大量在庫で欠品を防いだからといって、予測が優れていた証明にはなりません。

手作業、標準ツール、自動化、エージェント支援を選び分ける

手作業の表計算:レビュー可能な規模から始める

保護した元データ、計算シート、版管理された予測記録を用意します。1SKUを照合し、例外を付け、次の期間の予測を保存してください。作成者の記憶に頼らず、他の人が再現できる状態を目指します。

少数で理解しやすい系列には適しています。一方、コピーした数式、記録のない調整、対応関係の変更がレビュー能力を超えると不安定になります。その場合は、まず繰り返しのデータ準備を自動化します。表計算を別の製品へ置き換えても、前提まで自動的に正しくなるわけではありません。

標準ツール:自分のアカウントで使えるものを確認する

AmazonのFBAページは、在庫計画のためのダッシュボードや補充ツールを案内しています。利用できる提案をレビューの材料とし、日付と関連設定を保存してください。独自の予測課題をすべて解決するものと決めつけないことが重要です。Amazon FBAのツール案内

レポートの権限も区別します。SP-APIの文書ではVendor Forecasting Reportの対象がVendorsとされています。一般のSeller Central出品者が同じ予測エンドポイントを使える証拠ではありません。連携を設計する前に、具体的なレポートと必要な役割を確認します。Amazon分析レポートの文書

スクリプトによる自動化:例外を明示してから拡張する

承認されたデータ処理は、取り込みの統一、重複の検出、再計算可能な基準作成に利用できます。受け入れる項目、タイムゾーン、対応表の版、鮮度の要件を定義します。入力不足や照合失敗では該当出力を止め、古い結果を最新として出すのではなく、エラー記録を残してください。

ソフトウェアの選定では、原予測、修正理由、出典、例外、必要な予測期間の評価を残せるかを確認します。機械学習を使うというだけで自社SKUの予測改善は証明されません。同じ入力条件と期間で、保存済みの基準に対して試用結果を比較します。

エージェント支援:判断を渡さずレビューを整理する

エージェントは、許可された証拠の整理、説明案の作成、未解決事項の振り分けなど、予測を取り巻く作業で検討できます。数量計算は明確な方法へ追跡できる状態を保ちます。流暢な説明ができても、入力やモデルの正しさは証明されません。

担当者が古いデータを見つけ、根拠のない調整を拒否し、旧版を回復できることを確かめてから範囲を広げます。購買、広告、出荷の変更は、別途権限と管理方法が合意されていない限り試行の対象外にします。適切な次の行動が、追加発注ではなく証拠の追加依頼になる場合もあります。

OpenMaxを予測レビューにどう組み込めるか

引き継ぎが課題なら協業の仕組みを検討する

OpenMaxは、人とエージェントが協業するプラットフォームとして製品を紹介しています。関連する相談例は、在庫、マーケティング、運用の間で予測レビューを整理することです。この位置づけだけで、Amazon専用の需要モデルや自社アカウントへの接続が確認されたことにはなりません。

提案する流れは、許可された予測資料を渡し、前提の変更点をまとめ、例外を明確な担当者へ送るというものです。実装前にアクセス、保存期間、権限、必要な連携を確認します。言語モデルに欠けた数量を作らせず、計算と出典を確認できるようにしてください。

持ち運べるレビュー記録を1つ作る

まず既存の文書で以下の構造を使えます。編集用のテンプレートであり、OpenMaxのインポート形式を表すものではありません。レビューに必要な情報に絞り、この集計例には不要な顧客識別情報を含めないでください。

判断:次の需要予測を確認する。発注はしない
範囲:市場、SKU、包装単位、チャネル
作成:日時、タイムゾーン、予測の版
対象:予測日付と集計単位
出典:エクスポート名、取得日時、担当者
販売状況:購入可能、購入不可、状態不明の期間
基準:計算式、採用日、除外日
調整:理由、証拠、担当者
シナリオ:仮定した速度と計算数量
検証:原予測、実績の定義、誤差の符号
例外:不足する証拠、次の調査
レビュー:責任者、期限、採用した変更

協業が問題でなければ簡単な方法を保つ

安定した少数のSKUなら、確認済みの表計算と短いレビュー会議で足りるかもしれません。高度に見せるためだけにOpenMaxを追加する必要はありません。また、観測されなかった需要をエージェントが確実に復元できると期待しないでください。

引き継ぎを改善する必要があるなら、Amazon出品者のワークフロー自動化を使って小さな試行を定義します。1つの資料をレビューし、説明を元データと照合し、制約を解消してからアクセスや責任範囲を広げます。

FAQ:Amazonの在庫予測でよくある質問

どれくらいの販売履歴が必要ですか?

すべてのSKUと予測期間に当てはまる固定日数はありません。基準を作り、その後の期間で評価できる比較可能な観測が必要です。年間の季節性には関連する季節の履歴が必要で、短い発売直後の記録では証明できません。履歴が少なければ仮定を明示し、証拠の蓄積に合わせて更新します。

欠品日は需要ゼロとして計算しますか?

いいえ。購入できなかったことが確認された日は、誰も欲しがらなかった証拠ではありません。観測販売数と販売可能状況を残し、修正は記録します。ただし、購入可能でも売れなかった本当のゼロは需要パターンの一部なので、すべての販売ゼロを削除してはいけません。

販売履歴のない新商品はどう予測しますか?

理由を説明できる類似商品と発売時の仮定を使い、商品、価格、販売条件の違いを明記します。限定的に確認するテストのシナリオとして扱い、需要を実測した系列とは呼びません。自社商品の実績が得られたら、類推の前提を更新します。

季節性や販促はどう反映しますか?

月名だけでなく、関連イベントと販売条件を比較します。通常時の基準と施策の調整を分け、観測速度に含まれる効果をもう一度加えないようにします。なぜ同じイベントが再現すると考えるのか、どの変化で前提が無効になるのかを記録します。

在庫予測ソフトウェアは必須ですか?

必須ではありません。管理できる範囲なら、レビュー済みの表計算で対応できる場合があります。データ準備、版管理、例外処理が現在の方法を超えたときにソフトウェアが役立ちます。AIという名称だけではなく、必要な予測期間で保存済み基準と比較してください。

需要予測の数量をそのまま補充すればよいですか?

いいえ。需要予測は定義した条件下で将来の数量を見積もるものです。補充には利用可能在庫、引当、入荷時期、仕入先ルール、事業上の制約も必要です。それらを別に確認してから、発注や出荷の判断へ進みます。

予測精度は何パーセントなら十分ですか?

SKU、予測期間、誤差の影響によって異なります。絶対誤差と方向の偏りを、比較可能な基準とともに確認します。実績がゼロに近いと百分率指標は誤解を招き、全体の誤差が小さくても各期間の大きな外れを隠すことがあります。ツールを比べる前に評価方法を定義してください。

予測はどのくらいの頻度で更新しますか?

データの鮮度と意思決定の周期に合わせ、販売可能状況、販促、商品識別に重要な変更があれば追加レビューを行います。頻繁に修正しても原版は残してください。数字の更新回数は、その前提がまだ成立しているかの確認に代わるものではありません。

次の一歩:1つの予測を保存し、次の終了期間をレビューする

出典の分かるSKUを1つ選びます。単位と対象期間を定義し、販売可能状況を照合して基準を記録し、対象期間が始まる前に予測を保存してください。次のレビュー日と差異を調べる担当者を決めます。

レビューでは、データの問題、前提の変更、本当の予測誤差を分けます。まだ説明できない部分があれば、SKUを増やす前に記録を改善します。協業が課題なら、同じ資料をOpenMaxの相談へ持ち込み、どの証拠を整理するか、誰が確認するか、どの行動を人が管理し続けるかを具体化してください。