EC在庫管理の方法とコツ|欠品・過剰在庫を防ぐ【AI活用】
Kazuki Endo
EC 在庫管理とは、複数の販売チャネル(自社EC・楽天・Amazon・Yahoo!ショッピングなど)にまたがる在庫を、欠品も過剰在庫も出さない適正な状態に保つための一連の業務です。結論から言うと、方法は大きく「Excel(表計算)」「在庫管理・一元管理システム」「物流代行・在庫管理代行への外注」の3系統で、事業規模とSKU数、扱う店舗数で最適解が変わります。失敗の主因はチャネル間の在庫ズレと手入力のミスに集約されるため、まずは「在庫データを1か所に集約し、更新を自動化する」ことが起点になります。本記事では、EC在庫管理の基本と失敗パターン、適正在庫・安全在庫の考え方、方法別の費用相場、選び方、そしてAIを活用した在庫管理で何が変わるかまでを整理します。
この記事で分かること
- EC在庫管理でよくある失敗(欠品・過剰在庫・チャネル間ズレ)と原因
- 適正在庫・安全在庫の決め方と、方法別(Excel・システム・代行)の費用相場
- 在庫管理システム/代行の選び方チェックリストと、AI活用で変わること
EC在庫管理とは?なぜ実店舗より難しいのか
EC在庫管理とは、注文の受付から出荷、補充までの過程で「今どの商品が、どこに、いくつあるか」を正確に把握し、販売機会の損失(欠品)と滞留コスト(過剰在庫)の両方を抑える業務です。単なる数の記録ではなく、「売れ行きを読み、いつ・いくつ発注するか」を判断するところまでを含みます。
ECの在庫管理が実店舗より難しいのは、主に3つの構造的な理由があります。第一に、販売チャネルが複数に分かれること。第二に、24時間365日いつでも注文が入ること。第三に、色・サイズ違いなどSKU(最小管理単位)が増えやすいことです。実店舗なら棚を見れば在庫が分かりますが、ECでは複数の管理画面と倉庫にデータが分散し、目視での確認ができません。
| 観点 | 実店舗の在庫管理 | ECの在庫管理 |
|---|---|---|
| 販売チャネル | 基本は1店舗 | 自社EC+複数モールで並行販売 |
| 注文の発生 | 営業時間内 | 24時間365日・深夜も発生 |
| 在庫の可視性 | 棚を目視で確認できる | 管理画面・倉庫にデータが分散 |
| SKUの増え方 | 陳列スペースで上限 | 色・サイズ・セットで指数的に増加 |
| ズレの発覚 | その場で気づきやすい | 受注後・棚卸しで初めて発覚しがち |
この「分散」と「常時稼働」という前提を踏まえると、EC在庫管理の目標は明確です。各チャネルの在庫データを1か所に集約し、売れた分を全チャネルに素早く反映して、人の手入力を最小化すること。ここがすべての出発点になります。ECサイト運営全体の流れは、EC運営の全体像を解説したガイドもあわせて参考にしてください。
EC在庫管理の基本フローは?入荷から棚卸までの流れ
EC在庫管理は、「入荷 → 保管・格納 → 引き当て → 出荷 → 棚卸・補充」という一連のサイクルで回ります。まず全体像を押さえておくと、どの工程でミスやズレが起きているかを切り分けやすくなり、システム化や外注の判断もしやすくなります。各工程を簡潔に整理します。
| 工程 | やること | つまずきやすい点 |
|---|---|---|
| ① 仕入・入荷 | 発注・検品して在庫を登録 | 検品漏れ・登録タイミングのズレ |
| ② 保管・格納 | 倉庫やロケーションに格納 | 置き場所が不定で探す手間が発生 |
| ③ 引き当て | 注文に在庫を割り当て、各店舗へ反映 | 反映遅れによるチャネル間ズレ |
| ④ 出荷・梱包 | ピッキング・梱包・発送 | 誤出荷・出荷遅延 |
| ⑤ 棚卸・補充 | 実在庫とデータを突合し発注 | 棚卸し未実施で誤差が蓄積 |
このうち、EC特有の難所が③の「引き当て」です。複数店舗で同じ在庫を売っている場合、注文が入った瞬間に全チャネルの表示在庫を減らさなければ、超過受注が発生します。ここを人手で運用すると反映が遅れるため、後述の一元管理システムで自動化する価値が最も高い工程だと言えます。また、⑤の棚卸しを定期的に行わないと、データ上の在庫と実在庫の誤差(在庫差異)が少しずつ蓄積し、ある日まとめて欠品や誤出荷として表面化します。月次や週次で部分棚卸し(サイクルカウント)を行う運用が有効です。
EC在庫管理でよくある失敗は?欠品・過剰在庫・チャネル間ズレ
EC在庫管理の失敗は、大きく「欠品(売り逃し)」「過剰在庫(滞留コスト)」「チャネル間の在庫ズレ(超過受注・キャンセル)」の3つに集約されます。いずれも根っこは「在庫データが一元化されていない」「更新が人の手作業に依存している」という同じ原因につながっています。まずは自社がどの失敗に近いかを見極めることが、対策の第一歩です。
| 失敗パターン | 主な原因 | 起こる損失 |
|---|---|---|
| 欠品・売り逃し | 発注遅れ/売れ筋の在庫読み違い | 販売機会の損失・検索順位や評価の低下 |
| 過剰在庫・滞留 | 需要の過大見積もり/まとめ発注 | 保管費・キャッシュフロー悪化・値引きロス |
| チャネル間ズレ | 各店舗で在庫を別管理・反映遅れ | 超過受注→キャンセル・低評価・信用低下 |
| 在庫数の誤差 | 手入力ミス/棚卸し未実施 | 誤出荷・返品対応の増加 |
| SKU管理の煩雑化 | 色・サイズ・セット品の増加 | 特定バリエーションだけ欠品/滞留 |
特に見落とされやすいのが「チャネル間ズレ」です。たとえば同じ商品を自社ECと楽天、Amazonの3店舗で在庫10個ずつと表示して売っていると、実在庫が10個しかない場合に最大30個の注文が入り得ます。売れた分を各店舗にすぐ反映できないと、在庫がないのに売れてしまう「超過受注」が起き、キャンセルと低評価につながります。
逆方向の失敗が「過剰在庫」です。欠品を恐れて多めに仕入れると、売れ残りが倉庫を圧迫します。過剰在庫は保管費がかかるだけでなく、仕入れに使った資金が在庫として寝てしまい、キャッシュフローを悪化させます。さらに、季節商品やトレンド商品は時間が経つほど売れにくくなり、最終的に値引きや廃棄でのロスにつながります。欠品と過剰は「どちらかを避けるともう一方が起きやすい」トレードオフの関係にあるため、勘ではなく後述の安全在庫・発注点で最適点を探ることが重要です。
もう一つの盲点が「入力ミス」です。人手での在庫更新は、桁の打ち間違いやコピー漏れが一定確率で発生します。運用でカバーするなら、更新後のダブルチェックと、更新前後の在庫数のスクリーンショット保存を習慣化すると、原因追跡がしやすくなります。ただし件数が増えると人手の限界が来るため、後述するシステム化・自動化への移行を検討する分岐点になります。
在庫・受注・広告までAIでどう効率化する? EC運営の実践ノウハウをまとめました。
関連資料を無料でダウンロード適正在庫はどう決める?安全在庫と発注点の計算方法
適正在庫とは、欠品を避けつつ過剰も抱えない「ちょうどよい在庫水準」で、実務では「安全在庫」と「発注点」の2つの数値に落とし込んで管理します。まず結論として、日々の販売数と、発注してから入荷するまでの日数(リードタイム)が分かれば、両者は概算できます。感覚での発注から、数式ベースの発注へ切り替えることが、欠品と過剰の同時抑制につながります。
もっとも簡易な考え方は次のとおりです。厳密な統計式(需要のばらつきと安全係数を使う方法)もありますが、まずは簡易版で運用を始め、精度が必要になったら高度化するのが現実的です。
1日あたり平均販売数 × リードタイム日数 × 安全係数(1.2〜1.5程度)
1日あたり平均販売数 × リードタイム日数 + 安全在庫
一定期間の売上原価 ÷ 期間中の平均在庫金額(高いほど滞留が少ない)
具体例で考えます。ある商品が1日平均5個売れ、発注から入荷まで7日かかるとします。安全係数を1.3とすると、安全在庫は「5個 × 7日 × 1.3 ≒ 46個」、発注点は「5個 × 7日 + 46個 = 81個」です。つまり在庫が81個を下回ったら発注をかける、という運用ルールになります。数値はあくまで目安で、季節変動やセール、リードタイムのばらつきが大きい商材ほど、安全係数を高めに設定します。
あわせて確認したいのが「在庫回転率」です。回転率が低い(=在庫が長く滞留している)商品は、値引き販売や販促でのはけ方を早める、あるいは発注量を絞るといった判断材料になります。売れ筋・死に筋をこの指標で仕分けると、限られたキャッシュを回転の速い商品に振り向けやすくなります。
実務では、すべての商品を同じ精度で管理する必要はありません。売上や在庫金額の大きい主力商品ほど、需要のばらつきを踏まえて安全在庫を丁寧に設計し、こまめに発注する。一方、売れ行きが安定した定番の消耗品や、少量しか動かない商品は、まとめ発注で発注回数を減らすなど、メリハリをつけると管理の手間を抑えられます。「重要な商品にほど手をかける」という優先順位づけ(いわゆるABC分析の考え方)を取り入れると、限られた時間で在庫管理の効果を最大化できます。
EC在庫管理の方法は?Excel・システム・代行を比較
EC在庫管理の方法は、大きく「Excelなどの表計算」「在庫管理・一元管理システム」「物流代行・在庫管理代行への外注」の3系統に整理できます。結論としては、店舗数・SKU数・出荷件数が少ないうちはExcel、複数モールを横断し始めたらシステム、出荷や人手が逼迫したら代行という順で移行するのが一般的な流れです。それぞれの向き・不向きを押さえておきましょう。
| 方法 | 向いている規模・状況 | メリット | 注意点 |
|---|---|---|---|
| Excel・スプレッドシート | 1〜2チャネル・SKUが少ない立ち上げ期 | 低コスト・自由に作れる | 手入力ミス・チャネル間の反映が手作業 |
| 在庫管理システム | 在庫の可視化・アラートを自動化したい | リアルタイム把握・棚卸し効率化 | 受注や物流との連携範囲を要確認 |
| EC一元管理システム | 複数モール+自社ECを横断運用 | 売れた分を全店舗へ自動反映 | 月額+従量課金・初期設定の工数 |
| 物流代行(3PL) | 出荷が増え保管・梱包が逼迫 | 保管〜出荷を委託し本業に集中 | 保管料+入出荷手数料の総額管理 |
| 在庫管理代行・運営代行 | 人手・ノウハウが社内に不足 | 実務を専門チームに任せられる | 業務範囲と体制を契約で明確化 |
「一元管理システム」は、複数チャネルを運用するEC事業者にとって中核になる仕組みです。ある店舗で商品が売れると、その分を他店舗の在庫数から自動で差し引き、全チャネルの在庫を同期します。これにより、前述のチャネル間ズレによる超過受注を構造的に防げます。多くのサービスが楽天・Amazon・Yahoo!ショッピング・自社カートに対応しており、在庫だけでなく受注・商品情報の一元管理まで担うタイプもあります。
一方、出荷そのものが負担になってきたら物流代行(3PL)や在庫管理代行の検討時期です。保管・梱包・発送を委託すれば、在庫は倉庫側で実数管理され、自社は商品企画や販促に集中できます。委託の考え方はネットショップ運営代行の解説記事、実務全般を任せる場合はEC運営代行の費用と業務範囲もあわせてご確認ください。商品登録まわりの外注を検討する場合は商品登録代行の費用相場が参考になります。
モール別・自社ECで在庫管理の勘所はどう違う?
在庫管理の基本は共通ですが、販売チャネルごとに運用の勘所が少しずつ異なります。複数チャネルを横断する場合は、各モールの在庫更新の仕様に合わせつつ、一元管理システムで足並みをそろえるのが実務的です。代表的なチャネルの特徴を整理します。
- 楽天市場:バリエーション(項目選択肢)の在庫管理が独特で、セット販売や在庫連動の設定が複雑になりやすい。RPP広告などで露出が増えると売れ行きが急変するため、安全在庫を厚めに見ておくと安心です。
- Amazon:FBA(フルフィルメント by Amazon)を使う場合、在庫はAmazon倉庫側で管理され、自社在庫やマルチチャネル出荷分との配分設計が要点になります。納品リードタイムを見込んだ補充が必要です。
- Yahoo!ショッピング:出店ハードルが低く多店舗運用の一角になりやすい分、他モールとの在庫同期を怠るとズレが出やすいチャネルです。一元管理での自動反映が効きます。
- 自社EC(Shopify・MakeShopなど):カートの在庫APIや連携アプリの対応範囲を確認し、モール在庫と同期させる設計が必要です。ブランドの世界観を出せる反面、集客と在庫の両輪を自社で回す負荷があります。
いずれのチャネルでも、「セール・広告で露出が上がる時期」は売れ行きが平常時と大きく変わります。イベント前は安全在庫を引き上げ、終了後は滞留を防ぐために発注を絞る、といったメリハリのある在庫コントロールが、欠品と過剰の両方を避けるコツです。
EC在庫管理システム・一元管理の費用相場は?
EC在庫管理にかかる費用は、方法によって幅があります。目安として、クラウド型の在庫管理・一元管理システムは月額数万円台から、物流代行は保管料+入出荷手数料の従量制、在庫管理代行(人的アウトソース)は月数万円台からが一般的です。いずれも店舗数・SKU数・受注件数・出荷量に連動して増減するため、必ず「自社の件数」を当てはめて見積もりを比較してください。以下はあくまで目安であり、実際の料金は各サービスの体系で確認が必要です。
| 費用の対象 | 相場(目安) | 料金の考え方・根拠 |
|---|---|---|
| 在庫管理システム(クラウド) | 月額1〜5万円程度〜/初期0〜数万円 | 管理SKU数・機能で段階。無料〜低価格プランもある |
| EC一元管理システム | 月額2〜10万円程度+従量(受注件数) | 連携モール数・月間受注件数で変動 |
| 物流代行(3PL) | 保管料+入出荷手数料の従量制 | 保管容積(坪・棚)と出荷件数で月額が決まる |
| 在庫管理代行(人的BPO) | 月数万円〜/作業量ベース | 更新・棚卸し・発注補助など範囲で変動 |
| EC運営代行(在庫含む包括) | 月10〜80万円程度(範囲による) | 在庫+受注+CS+広告など業務範囲で変動 |
費用を判断するときは、金額単体ではなく「削減・防止できる損失」と並べて考えると、費用対効果を見極めやすくなります。たとえば一元管理システムの月額数万円は、超過受注によるキャンセル・低評価・機会損失を防げるなら十分に回収できる可能性があります。逆に、出荷件数がまだ少ない段階で高機能なシステムを入れても、機能を使い切れずコストだけがかかることもあります。自社の「今の件数」と「半年後の見込み」を基準に、段階的に投資する考え方が安全です。
なお、費用の内訳の大半は「人件費(稼働工数)」か「従量課金(件数)」です。つまり、定型作業の工数をどれだけ圧縮できるかが総コストを左右します。ここが、後述するAI活用が効いてくるポイントです。加えて、システムと代行はどちらか一方ではなく、組み合わせて使うケースも多く見られます。たとえば在庫の同期は一元管理システムに任せつつ、出荷は物流代行に委託し、在庫管理システムの運用や発注業務だけを社内で担う、といった役割分担です。自社のどの工程が重いのかを見極め、その部分にコストを集中させると、費用対効果を高めやすくなります。
在庫管理システム・代行の選び方チェックリスト
選定の軸は、機能の多さそのものより「自社のチャネル構成と業務範囲に合うか」です。以下のチェック項目を、複数サービスで並べて比較すると、導入後の「思っていた連携ができない」というミスマッチを防げます。まずは導入目的(在庫の可視化なのか、チャネル同期なのか、出荷の外注なのか)を一つに絞ることが出発点です。
- 対応チャネル:利用中の楽天・Amazon・Yahoo!・自社カートにすべて連携できるか
- 在庫の同期方式:売れた分を全店舗へ自動反映できるか、反映の頻度・タイムラグはどの程度か
- SKU・バリエーション管理:色・サイズ・セット品(同梱・引き当て)に対応するか
- アラート機能:在庫が発注点を下回った際の通知があるか
- 既存システムとの連携:受注管理・会計・物流(WMS)とAPIでつながるか
- 料金体系:月額+従量の内訳、受注件数の上限と超過時の追加費用
- サポート・拡張性:初期設定の支援、店舗追加や出荷増への対応
- (代行の場合)業務範囲と体制:どこまで任せられるか、レポート頻度、解約・引き継ぎ条件
代行を選ぶ場合は、システム選定に加えて「実績のある商材ジャンル・モール」「窓口の一本化」「データやアカウントの引き継ぎ条件」を確認します。複数社から相見積もりを取り、金額だけでなく業務範囲・実績・体制を並べて比較するのが、失敗回避の近道です。
システム化・外注に踏み切るタイミングの目安も持っておくとよいでしょう。判断のサインとしては、①販売チャネルが2つ以上になり在庫の手動同期が追いつかない、②SKUが増えてExcelの更新が日々の負担になっている、③出荷件数が増えて梱包・発送に人手を取られ本業が回らない、といった状態が挙げられます。①②ならまず一元管理システム、③なら物流代行や在庫管理代行、というように、逼迫している工程から段階的に手当てするのが費用対効果の高い進め方です。いきなり全部を外注・システム化するより、ボトルネックを一つずつ解消するほうが、コストと運用の両面で無理がありません。
在庫管理の成果はどう測る?押さえるべきKPI
在庫管理を「なんとなく回す」状態から抜け出すには、数値(KPI)で健全性を測ることが欠かせません。結論として、最初に見るべきは「在庫精度」「在庫回転率」「欠品率」の3つで、これらを定点観測すると、改善の効果が可視化され、発注や販促の判断がぶれにくくなります。いずれも難しい計測ではなく、既存の在庫・受注データから算出できます。
| KPI | 見るもの | 目安・活用 |
|---|---|---|
| 在庫精度 | データ上の在庫と実在庫の一致度 | 低いほど誤出荷・欠品の温床。棚卸しで改善 |
| 在庫回転率 | 在庫がどれだけ効率よく売れているか | 低い商品は発注量の見直し・値引き検討 |
| 欠品率 | 注文に対して在庫切れが起きた割合 | 高いなら安全在庫・発注点の再設定 |
| 滞留在庫比率 | 一定期間動いていない在庫の割合 | キャッシュ圧迫の指標。早めの処分判断に |
| 誤出荷率 | 出荷ミスの発生割合 | ピッキング・検品フローの見直しに直結 |
KPIは「測ること」自体が目的ではなく、打ち手につなげることが目的です。たとえば欠品率が高止まりしているなら安全在庫を引き上げ、在庫回転率が低い商品が増えているなら発注を絞るか販促でさばく、というように、数値を次のアクションに翻訳します。月次でこれらを振り返る習慣が、在庫管理を安定させます。
AI活用でEC在庫管理はどう変わるか
AI活用の要点は、これまで人の勘と手作業に頼っていた「需要の予測」と「データの整形・監視」を効率化し、担当者が発注や販促の判断に集中できるようにすることです。「全自動で人手が不要になる」のではなく、人とAIで分担してスピードと精度を上げる考え方です。EC在庫管理では、次のような場面でAIが役立ちます。
- 需要予測・発注量の下案:過去の販売実績・季節性・セール予定をもとに、商品ごとの発注量やタイミングの案をAIが算出し、担当者が最終判断する。感覚頼みの発注を、根拠のある発注へ近づける。
- 在庫データの整形・突合:各モールからダウンロードした在庫・受注データの形式をAIで揃え、チャネル間のズレや異常値を洗い出す下処理を高速化する。
- アラートの要約・優先順位づけ:欠品リスクや滞留在庫の一覧を、AIが「今週対応すべき順」に要約し、担当者の確認負荷を下げる。
- 売れ筋・死に筋の分析コメント:在庫回転率や販売推移をAIが読み取り、値引き・追加発注・販促などの打ち手候補を言語化する。人はそれを叩き台に意思決定する。
- 商品情報・在庫説明の生成:多SKUの商品ページ更新や、在庫状況に応じた表記(入荷予定など)の草案をAIで用意し、人が事実確認して反映する。
WHITCHは、月間約900万UU規模の自社メディアの運営や他社メディアの運営支援を、1日10〜18本の公開体制で行っており、人とAIの分担で「量と品質を両立する」運用を自社で実践しています。自社業務ではAI活用によって月686時間相当の工数削減、記事制作の一部工程を40時間から1時間規模へ短縮した実績があり、この「定型作業をAIで圧縮し、人は判断に集中する」ノウハウをEC運営支援にも応用しています。数値は自社の運用実績にもとづく目安であり、成果を保証するものではありませんが、在庫管理のような繰り返し作業ほど効率化の余地は大きいと考えています。
具体的な運用イメージは、たとえば次のような分担です。まず、各モールから出力した販売・在庫データをAIで統一フォーマットに整え、前週比・前年同月比の変化と異常値を抽出させます。次に、その結果をもとにAIが「発注を検討すべき商品」「値引きや販促で動かすべき滞留商品」の候補リストと理由を作成します。担当者はそのリストを確認し、仕入れ先の状況や今後のセール予定といった外部情報を加味して、発注量とタイミングを確定します。こうすることで、データ整理と一次分析に費やしていた時間を、判断と交渉に振り向けられます。
重要なのは、AIに任せるのは「下処理・下案づくり」までで、発注量の確定や在庫の最終責任は人が持つ設計にすることです。予測はあくまで確率的な見立てであり、外部要因(急な欠品・物流遅延・トレンド変化)を織り込む最終判断は人の役割として残す。この分担を守ることで、精度とスピードを両立しながらリスクを抑えられます。
まとめ|EC在庫管理は「集約・自動化・AIでの判断支援」で最適化する
EC在庫管理は、複数チャネルにまたがる在庫を、欠品も過剰在庫も出さない適正な状態に保つ業務です。失敗の多くはチャネル間の在庫ズレと手入力ミスに起因するため、まずは在庫データを1か所に集約し、更新を自動化することが起点になります。適正在庫は安全在庫と発注点で数式化し、方法はExcel・システム・代行から自社の規模に合わせて段階的に選ぶのがおすすめです。費用は方法ごとに幅がありますが、防げる損失と並べて費用対効果で判断してください。さらにAIを需要予測やデータ整形、判断支援に活用すれば、定型作業を圧縮しつつ発注の精度を高められます。EC運営全体の進め方はEC運営の全体像ガイド、実務の外注はEC運営代行の費用と業務範囲で詳しく解説しています。