EC在庫管理の自動化。欠品と過剰在庫を「仕組み」で防ぐ

在庫管理は、目視チェックに頼る限り必ず漏れます。欠品は売上機会と検索順位を同時に失わせ、過剰在庫はキャッシュを棚に寝かせます。この記事では、在庫を人の注意力ではなく仕組みで管理する方法を、発注点の決め方から解説します。

監修: 廣瀬正拓(中小企業診断士 / 現役EC事業経営者)

在庫のミスが「二重に」効いてくる理由

在庫管理の失敗には、欠品と過剰在庫という2つの方向があります。厄介なのは、どちらも単なる在庫の問題では終わらず、売上・順位・キャッシュという経営の根幹に波及することです。

そして在庫管理は、EC運営の中でもっとも属人化しやすく、もっとも目視チェックが漏れやすい業務です。「気づいたら在庫が切れていた」「棚卸ししたら想定より大量に余っていた」。この2つの経験がない事業者は、ほとんどいないはずです。だからこそ、仕組み化の効果が最も大きく出る領域でもあります。人は疲れるし、忘れるし、他の業務に追われれば在庫の確認は後回しになります。仕組みは疲れず、忘れず、毎朝同じ精度で在庫を見張ってくれます。

本記事では、在庫を「人の注意力」ではなく「仕組み」で管理する具体的な方法を、発注点の数式化、優先順位づけ、自動アラートの実装という順で解説します。特別なシステムを買わなくても、GoogleスプレッドシートとGASがあれば無料で始められます。まずは考え方の土台から押さえていきましょう。

欠品はキャッシュではなく順位を奪う

Amazonにおける欠品の本当の怖さは、その日の売上を逃すことではありません。積み上げてきた検索順位とレビューの評価が、在庫切れの期間に毀損されることです。

在庫が切れれば販売が止まり、販売実績が途切れれば検索順位は下がります。そして在庫を戻しても、順位はすぐには戻りません。数日の欠品を取り戻すのに、数週間かかることも珍しくない。欠品のコストは「逃した売上」ではなく「順位の再構築にかかる時間」で数えるべきです。

仮に一日あたり10個売れる商品が5日間欠品したとします。逃した売上は50個ぶんですが、痛手はそれだけでは終わりません。欠品中に競合へ流れた顧客はレビューも競合に付け、戻ってきた自社商品は下がった順位から再スタートになります。50個の損失を回収するために、その後の数週間、広告費を上乗せして順位を押し上げ直す。こうして直接損失の何倍もの見えないコストが後から効いてくるのが、欠品の本当の恐ろしさです。

過剰在庫という見えないコスト

欠品が目立つ失敗なら、過剰在庫は静かな失敗です。損益計算書には損失として現れず、貸借対照表の資産として計上されるため、問題が見えにくい。しかし中小企業診断士の視点では、過剰在庫は明確なコストです。

• キャッシュが寝る。在庫は現金が形を変えたもの。売れるまで会社の資金を拘束し続けます
• 保管料がかかる。FBAでは在庫保管手数料、とくに長期在庫には追加の手数料が発生します
• 陳腐化リスク。トレンド商品やシーズン品は、時間とともに価値が下がります

「売り切れるから大丈夫」ではなく、その在庫が何ヶ月分のキャッシュを拘束しているかで見る。これが経営視点の在庫管理です。

目安になるのが在庫回転の速さです。仮に月に100個売れる商品の在庫を1200個抱えていれば、それは12ヶ月分、つまり一年ぶんの資金が棚で眠っている状態です。その資金があれば、別の売れ筋を仕入れて回転させられたかもしれません。過剰在庫のコストは、保管料や値下げロスだけでなく、「その資金で他に何ができたか」という機会費用まで含めて考えるのが経営の目線です。欠品を恐れるあまり在庫を厚く持ちすぎると、今度はキャッシュが回らなくなる。この綱引きのちょうどよい点を、勘ではなく数字で決めるのが次の発注点です。

発注点の決め方: 感覚を数式にする

「そろそろ発注しないと」という感覚を、誰がやっても同じ判断になる数式に置き換えます。基本は次の考え方です。

発注点 = 1日の平均販売数 × 入荷までの日数 + 安全在庫

• 1日の平均販売数。直近数週間の実績から算出。季節性がある商品は同時期の前年も参照する
• 入荷までの日数(リードタイム)。発注から納品・FBA反映までの実日数。ここを短く見積もると欠品します
• 安全在庫。販売の変動やリードタイムのブレを吸収する余裕分。売れ筋ほど厚めに

この式を商品ごとに設定しておけば、「在庫がこの数を下回ったら発注」という明確な基準になります。担当者の勘や経験に頼らず、誰が見ても同じ発注判断ができるようになるのが最大の利点です。あとは、その基準を割ったことを自動で検知させるだけです。

具体的に数字を入れてみます。仮に1日の平均販売数が10個、発注から入荷までのリードタイムが14日、安全在庫を30個とすると、発注点は「10 × 14 + 30 = 170個」です。つまり在庫が170個を下回った時点で発注をかければ、入荷までのあいだに欠品しない計算になります。ここで安全在庫を厚くすれば欠品リスクは下がりますが、そのぶん抱える在庫が増えて資金が寝ます。安全在庫の厚みが、まさに欠品リスクとキャッシュ効率のトレードオフを調整するツマミだと理解してください。

ABC分析で「守る在庫」を絞る

すべての商品を同じ熱量で管理するのは、現実的でも効率的でもありません。そこで役立つのがABC分析です。売上や利益への貢献度で商品をA・B・Cの3群に分け、管理の手厚さを変えます。

区分	位置づけ	在庫管理の方針
A(主力)	売上の大半を稼ぐ少数	安全在庫を厚く、欠品を絶対に避ける
B(中間)	そこそこ売れる中位群	標準的な発注点で管理
C(裾野)	点数は多いが売上は小さい	在庫を薄く、過剰在庫を避ける

一般に、売上の大半は一部の商品が稼ぎます。だからこそ、その少数のA商品の欠品だけは何としても防ぎ、逆に数の多いC商品は在庫を絞ってキャッシュを守る。限られた注意力と資金を、効く商品に集中させるのがABC分析の狙いです。発注点の安全在庫も、この区分に応じて厚みを変えると、全体として欠品と過剰在庫のバランスが取れます。

季節性とセールに備える在庫計画

発注点は平常時の販売ペースを前提にしています。ところが実際の需要は、季節やセールで大きく波打ちます。ここを織り込まないと、需要期の直前に在庫が尽きたり、逆にセールを見込んで積んだ在庫が売れ残ったりします。

季節性のある商品は、平常時の平均販売数ではなく、前年同時期の実績を参照して発注点を引き上げます。仮に夏に需要が跳ねる商品なら、需要が立ち上がる前の段階で、平常時より厚めに在庫を仕込んでおく必要があります。リードタイムを考えると、需要期に入ってから発注したのでは間に合いません。需要の山の手前で仕込み、山を越えたら発注を絞るという時間差の設計が要になります。

大型セールも同様です。セール期間は普段の何倍も売れることがあるため、平常時の発注点のままでは確実に欠品します。一方で、セールを見込んで積みすぎれば、終了後に大量の在庫が残ります。過去のセール実績があれば、そのときの販売数を基準に必要量を見積もり、なければ小さめに構えて売れ行きを見ながら追加する。読めない需要ほど、一度に大量発注せず、こまめな追加発注で対応するのが、過剰在庫を避けるコツです。中国からの仕入れは連休で納期が延びるため、セール前の発注はいつもより前倒しで手配しておきます。

自動アラートの作り方

発注点を決めたら、在庫がそれを下回ったときに自動で通知する仕組みを作ります。GoogleスプレッドシートとGAS(Google Apps Script)を使えば、無料で実装できます。基本形はこれだけです。

function checkStock() {
  const sheet = SpreadsheetApp.getActiveSpreadsheet()
    .getSheetByName('在庫管理');
  const rows = sheet.getDataRange().getValues().slice(1);
  const alerts = [];

  rows.forEach(function(r) {
    const name = r[0], stock = r[2], reorderPoint = r[3];
    if (stock <= reorderPoint) {
      alerts.push(name + ': 残り' + stock + '個(発注点 ' + reorderPoint + ')');
    }
  });

  if (alerts.length === 0) return; // 問題なければ何も送らない

  const webhook = 'https://hooks.slack.com/services/xxx';
  UrlFetchApp.fetch(webhook, {
    method: 'post',
    contentType: 'application/json',
    payload: JSON.stringify({ text: '発注アラート\n' + alerts.join('\n') })
  });
}

在庫データを手動で貼り付けても動きますが、SP-APIで在庫を自動取得すれば、貼り付け作業すら不要になります。GASの時間トリガーで毎朝実行すれば、発注判断が遅れることはなくなります。

実装のポイントは、スプレッドシートを「在庫データの一元台帳」にすることです。商品名・現在庫・発注点・リードタイムを列で持たせておけば、上のスクリプトは発注点を割った商品だけを拾って通知します。人は毎朝スプレッドシートを開く必要すらなく、通知が来たときだけ発注を判断すればよくなります。属人化していた「在庫を気にかける」という作業そのものを、仕組みに肩代わりさせるわけです。

欠品予測: 「あと何日で尽きるか」を出す

発注点アラートの一歩先が、欠品予測です。現在庫を1日の平均販売数で割れば、「あと何日で在庫が尽きるか」が計算できます。

これを一覧化しておくと、複数商品の発注優先順位が一目で分かるようになります。残り3日の商品と残り30日の商品では、当然対応の緊急度が違う。人が頭の中でやっていた優先順位付けを、数字が肩代わりしてくれます。売れ行きが加速している商品ほど「残り日数」が急に縮むので、その変化を捉えられるのも利点です。

さらに一歩進めるなら、平均販売数を「直近7日」と「直近30日」の両方で出しておくと、需要の変化を早く掴めます。仮に直近7日の平均が30日平均を大きく上回っていれば、その商品は今まさに伸びている最中で、従来の発注点では間に合わない可能性があります。過去の平均だけでなく、直近の勢いを見て発注点そのものを引き上げる。この一手間が、伸びている商品の欠品という「一番もったいない欠品」を防ぎます。

複数チャネルの在庫をどう束ねるか

Amazonだけでなく楽天やShopify、Qoo10と販路が増えると、在庫管理は一段難しくなります。同じ商品を複数のモールで売っている場合、どこかで売れたぶんを他のチャネルの在庫にも反映しないと、実際には在庫がないのに注文を受けてしまう「売り越し」が起きるからです。売り越しはキャンセルや評価低下に直結する、避けたい事故です。

対策の考え方はシンプルで、物理在庫を一つの台帳で一元管理し、各チャネルの販売可能数はそこから割り振ることです。FBAとその他モールを併用しているなら、FBA在庫とは別に自社出荷ぶんの在庫を分けて持ち、それぞれの発注点を管理します。チャネルが増えてスプレッドシートでの手管理が限界にきたら、在庫連携ツールの導入を検討する段階です。ツールは費用がかかりますが、売り越しによる信用の損失や、目視管理にかかる人件費と天秤にかければ、投資に見合うことが多いものです。まずはスプレッドシートで仕組みの型を作り、規模がツールを必要とする水準に育ったら移行する。この順序なら、無駄な投資をせずに済みます。

在庫管理でよくある失敗

最後に、在庫の仕組み化でつまずきやすい点をまとめます。どれも一度は通る道なので、先に知っておくと回避しやすくなります。

• リードタイムを短く見積もる。連休や繁忙期の遅延を織り込まず、入荷前に在庫が尽きる
• 安全在庫を全商品一律にする。売れ筋で欠品し、裾野商品で過剰在庫になる
• 正常通知を毎日送る。アラートが日常に埋もれ、肝心の警告を見逃す
• 季節性を無視する。平常時の平均で発注し、需要期に間に合わない
• 過剰在庫を放置する。資金拘束と保管料に気づかず、キャッシュが回らなくなる

共通する処方箋は、発注点を数式で持ち、区分ごとに安全在庫の厚みを変え、異常時だけ自動で知らせること。この3点を仕組みにするだけで、在庫のミスの大半は防げます。仕入れのリードタイムや連休の影響については、アリババ仕入れの記事もあわせて参考にしてください。

まとめ: 在庫は経営の縮図

在庫管理は、単なる作業ではなく経営そのものです。欠品を防いで順位と売上を守り、過剰在庫を防いでキャッシュを守る。その両立を、人の記憶や勘ではなく仕組みに担わせる。それが在庫管理の自動化です。

• 商品ごとに発注点を数式で決めているか
• 発注点を割ったことを自動で検知できているか
• 通知は異常時だけに絞られているか
• ABC区分に応じて安全在庫の厚みを変えているか
• 各商品の「残り何日」を把握しているか
• 過剰在庫を「拘束されたキャッシュ」として見ているか

まずは発注点の数式化から。それだけで、欠品の多くは未然に防げるようになります。完璧な仕組みを一度に作ろうとする必要はありません。主力商品の発注点を数本引き、通知を一つ動かす。そこから少しずつ対象を広げていけば、気づいたころには在庫のミスが起きにくい体制ができています。在庫を人の記憶から解放することは、そのまま経営者の時間を、より価値の高い判断へ振り向けることにつながります。