Amazon FBAを使う事業者にとって、在庫管理は「売上を伸ばす施策」ではなく「利益を残すか失うかを決める土台」です。同じ商品・同じ広告費でも、在庫の置き方ひとつで保管料、欠品による機会損失、資金拘束の大きさは変わります。本記事では、FBAのコスト構造から在庫設計を逆算する考え方を起点に、需要予測と安全在庫の実務、3PLを併用する二段階在庫モデル、返品オペレーション、そしてKPIとツール選定の判断軸までを順に整理します。いずれも「FBAに何個送るか」という単発の判断ではなく、上流から返品までを一つのループとして設計するための視点です。
FBA在庫管理は「何個送るか」だけでは決まらない
FBA在庫の最適化を納品数量の問題として捉えると、多くの場合で改善は頭打ちになります。納品数量は結果であって、原因は上流の在庫の持ち方にあるためです。
在庫は6つのポジションとして一体管理する
実務で管理対象になる在庫は、実際には複数の状態に分かれています。①需要予測に基づく計画在庫、②仕入先へ発注済みの調達在庫、③自社倉庫・3PLのバッファ在庫、④FBAの販売可能在庫、⑤FBAへ輸送中・受領待ちの在庫、⑥返品・リワーク中の在庫です。
このうち販売機会に直結するのは④だけですが、資金を拘束しているのは①〜⑥のすべてです。逆に、⑤を無視して発注判断をすると二重発注が起きやすく、⑤を販売可能扱いすると欠品が起きやすくなります。したがって発注や補充の判断は、単独の数値ではなく「FBA販売可能＋FBA納品中＋3PLで割当可能−確定引当」という在庫ポジションで行うのが基本です。
仕入ロットとFBA納品ロットは切り離す
仕入先のMOQや輸送効率の観点から一度に大きなロットを仕入れることは合理的です。しかし、その全量をFBAへ一括納品する必然性はありません。仕入ロットは調達の経済性で決まり、FBA納品ロットはFBAの保管コスト・容量制約・受領リードタイムで決まるため、最適な数量は本来一致しないからです。
母在庫を自社倉庫または3PLに置き、FBAへはリードタイム需要と安全在庫に相当する分を短いサイクルで補充する。この分離だけでも、長期滞留と容量圧迫のリスクは下げやすくなります。
FBAのコスト構造が在庫設計を規定する
在庫政策は理想論では決まらず、料金体系から逆算する必要があります。FBAのコストは「アカウント固定費」「販売時に発生する費用」「保有している間に発生する費用」「例外時に発生する費用」に分解すると管理しやすくなります。
保管料は体積・保管日数・季節で変動する
FBAの在庫保管手数料は、日次平均の保管体積と保管日数を基準に算出されます。ここで実務上重要なのは、Amazonが公表している料金表において、通常カテゴリーの保管料単価が1〜9月と10〜12月で大きく異なる点です。同じ在庫水準でも年末商戦期の保有コストは高くなるため、「Q4に備えて早期に大量搬入する」戦略は、販売予測が外れた場合のコスト感応度が高くなります。具体的な単価は改定されるため、計画時には必ず最新の公式料金表で確認してください。
この体系から導かれる示唆は、「単価が安い商品」より「体積当たりの粗利が低い商品」のほうがFBA在庫期間に敏感だということです。大型・低回転の商品ほど、売れるまでFBAに置き続けるより、低コストな保管拠点に母在庫を持ち、必要分だけを短サイクルで移送するほうが有利になる可能性があります。
「減らしすぎ」にもコストがある
一方で、在庫を削れば削るほど良いわけでもありません。Amazonは在庫が過度に少ない商品に対する低在庫レベル手数料を設けており、公式案内では親ASIN単位の「過去在庫日数」を一定水準以上に維持することが回避策として示されています。
つまりFBA在庫管理とは、低在庫ペナルティと長期・過剰在庫コストの間にある、狭い適正在庫帯を制御する問題です。「FBAには1週間分だけ置いて毎週補充する」といった極端なリーン運用は、対象商品では総コスト最小にならない可能性があります。
需要予測と安全在庫の精度が在庫水準を決める
適正在庫帯を狙うには、予測とばらつきの推定が前提になります。「過去30日の平均販売数」をそのまま延長する方法では、トレンド、季節性、販促、価格変更、欠品の影響が混ざったまま補充計画に流れ込みます。
ベースラインと販促上乗せを分離する
推奨されるのは「ベースライン需要 × 季節性 × 販促上乗せ」のように二層以上に分けた予測構造です。通常期の需要は指数平滑法（ETS）やARIMAなど確立された時系列手法で推定し、販促期間は別枠として扱います。
このとき「セールだから2倍」といった勘による一律係数は避けたいところです。割引率、広告費、表示回数、セール種別、曜日、価格、レビュー数などの条件と実績の上振れ幅を蓄積し、条件から上乗せ量を推定できる形にしておくと、再現性が高まります。なお乗算モデルが常に正しいとは限らないため、商品特性によっては加法モデルとの比較検証が必要です。
欠品日を「需要ゼロ」として学習させない
見落とされやすい落とし穴が、欠品日の扱いです。FBA在庫が0だった日の販売0は、需要が0だったことを意味しません。供給制約で観測できなかっただけの需要です。
これをそのまま学習データに含めると、モデルは欠品後の需要を過小評価し、さらに補充量が減り、また欠品するという負の循環が起こり得ます。データ設計の段階で「販売可能／欠品」のフラグを持たせ、欠品期間を除外または補正する処理を組み込んでおくべきです。
安全在庫はリードタイムのばらつきまで含める
安全在庫は、需要変動と供給の不確実性を吸収するためのバッファです。ここで多いのが、リードタイムを固定値とみなす簡易計算だけで済ませてしまうケースです。需要の標準偏差だけを見ると、リードタイム自体が揺れる場合のリスクを過小評価する可能性があります。
FBA特有の事情として、リードタイムには配送会社の輸送日数だけでなく、FC到着から受領・販売可能化までの時間を含める必要があります。繁忙期には受領までの時間が伸びることがあり、その間の在庫は「所有しているが販売できない在庫」になります。平均値だけでなく、受領リードタイムのP90／P95を蓄積し、安全在庫の更新に反映させることが実務的な対策になります。
二段階在庫モデルと返品オペレーション
予測と安全在庫が整ったら、次は「どこに置くか」と「戻ってきたものをどうするか」です。
3PLを母在庫、FBAを高速販売在庫として使う
Amazonは納品された在庫を購入者に近いフルフィルメントセンターへ分散配置する場合があり、販売事業者がFC間の配置を直接設計することはできません。したがって最適化の対象になる「複数倉庫」は、Amazon内部ではなく「仕入先→自社倉庫・3PL→Amazon FC群」という上流ネットワークです。
3PLを母在庫、FBAを高速販売在庫と位置づけると、調達ロットは経済性で、FBA納品ロットは「FBA目標上限−在庫ポジション」「3PLの利用可能在庫」「FBAの容量余力」の最小値で決められます。FBAの保管容量は上限があり、低回転品が容量を占有すると主力商品を補充できなくなるため、容量は個数や金額ではなく体積と粗利／体積で配分する発想が有効です。
返品は「理由別」に分解して商品改善へ戻す
FBAはカスタマーサービスと購入者返品を代行しますが、返品在庫をどう処理するかという経営判断までは代行しません。販売不可在庫については、返送・検品・再梱包・再納品にかかる費用と、再販できた場合の限界利益、そして清算・廃棄した場合の回収額を比較し、期待値の高い方を選ぶ形で判断します。
また、返品分析は「返品率」だけでは不十分です。返品理由をSKU、仕入ロット、FBA受領時期と紐づけて保存し、「商品不良」「説明との不一致」「サイズ」「輸送ダメージ」「購入者都合」などに分解すると、修正すべき対象が仕入品質なのか、商品ページなのか、梱包なのかを切り分けられます。返品オペレーションを外部化しても、原因を商品改善へ戻す閉ループは事業者側に残ります。
KPI設計とツール選定の判断軸
最後に、これらを日常業務として回すための計測とシステムです。
日次・週次・月次の三層でKPIを見る
Amazon公式のIPI（在庫パフォーマンス指標）はFBA在庫の健全性を測るうえで重要ですが、発注残や3PL在庫、仕入原価、返品リワークまでは横断しません。実務では次のように頻度別に分けると運用しやすくなります。
- 日次:在庫ポジション、Days of Cover（販売可能在庫÷予測日次需要）、欠品SKU、過去在庫日数
- 週次:予測精度（WAPE）、予測バイアス、FBA受領リードタイムのP50／P90、欠品率、返品率
- 月次:在庫回転率(個数・金額の両方)、滞留在庫の年齢バケット、物流原価／個、容量利用率
Days of Coverの分母には過去実績平均ではなく将来予測を使うことがポイントです。過去平均を使うと、セール直前に「30日分あるから安全」という誤判断が起こります。予測精度についても、平均誤差だけでなくバイアス（誤差の方向）を併せて監視します。バイアスが継続的にプラスなら過剰在庫、マイナスなら欠品につながります。
滞留在庫は年齢バケットで先回りする
長期在庫追加手数料の料金境界は明確ですが、境界に達してから動くのでは選択肢が残りません。0〜90日は正常、91〜180日は観察、181〜270日は販促計画、271〜330日は処分判断、331日以降は強制アクション、といった自社ルールを先に決めておくと、値下げ・広告・返送・清算のいずれを取るかを余裕をもって判断できます。この区分はAmazonの公式区分ではなく、あくまで先回りするための内部管理ルールです。
ツールは「最強の1つ」より役割分担で選ぶ
Amazonのみ・SKU数が少ない段階なら、Seller Centralの補充通知や発注推奨を基準線とし、自社予測との差分を見るところから始められます。一方、複数モール・複数拠点・3PL併用へ広がると、受注と在庫のシステム・オブ・レコードをOMS／WMSに置き、その上に需要予測を載せる構成のほうが整合性を取りやすくなります。
ツール比較の際は「Amazon連携の可否」だけでなく、需要予測、発注、FBA＋自社＋3PLの在庫統合、倉庫実行、FBA納品、他モール同期、返品、API出力のどこまでを一つのデータフローで処理できるかを軸にすると判断を誤りにくくなります。3PL選定も同様に、保管料や出荷料の単価だけでなく、FBA受領までの総リードタイム、FNSKUラベル精度、期限管理、返品検品、緊急補充への対応力を含めて評価すべきです。
まとめ
FBA在庫管理の目的は、FBA在庫を最小にすることではありません。「追加1個をFBAに置くことで減る欠品損失」と「置くことで増える保管・資本・滞留コスト」が釣り合う点をSKUごとに探すことです。
そのために有効なのが、①需要予測の精度を上げ、②リードタイムのばらつきを含めた安全在庫と発注点を設定し、③調達ロットとFBA納品ロットを分離し、④3PLを母在庫としてFBAへ短サイクルで補充し、⑤返品をリワーク採算で判断し、⑥SKU別の総物流原価（Cost-to-Serve）で検証する、という閉ループです。
導入は段階的で構いません。まずSKUマスターを統一し、FBA・納品中・3PL・発注残を1画面で見える状態にする。次にABC分類とベース予測、安全在庫・発注点の計算を載せる。最後に販促上振れモデル、滞留年齢ルール、返品リワーク採算を組み込む。「人が全SKUを毎日見る」運用から「例外だけを見る」運用へ移行できたとき、在庫回転率・保管費・欠品・配送リードタイムを同時に改善しやすい状態が整います。
なお、本記事で触れた料金や手数料の水準は改定される前提で扱ってください。実際の意思決定では、自社のSKU構成、原価、商品サイズ、仕入先MOQ、3PL料金、資金調達コストを当てはめた自社版の計算に置き換える必要があります。次に検証すべきは、この閉ループのうち自社で最も精度が低い工程はどこか、という点です。多くの場合、それは高度な予測アルゴリズムではなく、入荷精度や受領リードタイムの記録といった、地味なデータ整備の側にあります。
