EC在庫管理スプレッドシートの作り方【テンプレ設計】

在庫管理をいきなり専用システムで始める必要はありません。まずは一枚のスプレッドシートで在庫を掌握するところから始めましょう。この記事では、後から自動化にも耐える在庫管理シートの設計を、列の構造から発注点の考え方まで解説します。在庫はキャッシュそのものです。見える化が手残りを守ります。

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

在庫管理をスプレッドシートで始める理由

在庫管理と聞くと専用システムを思い浮かべますが、売上規模がそれほど大きくない段階では、スプレッドシートで十分です。むしろ最初からシステムに頼ると、自社の在庫の何を見るべきかが分からないまま、ツールに振り回されます。

スプレッドシートで始める利点は三つあります。自由に設計できること、コストがかからないこと、そして後からGASで自動化に発展させられることです。手を動かして自分で作ると、在庫の何が経営に効くのかが体で分かります。この理解が、後にシステムを導入するときの判断力になります。

中小企業診断士として強調したいのは、在庫はキャッシュそのものだという点です。棚に眠る在庫は、現金が形を変えて止まっている状態です。在庫が見えないことは、キャッシュフローが見えないことと同じです。だからこそ、規模が小さいうちから在庫を数字で掴む習慣をつけることが、黒字倒産を防ぐ土台になります。在庫とキャッシュの関係はEC事業の資金繰りと在庫の関係で詳しく解説しています。

商品マスタの設計

在庫管理シートの土台は商品マスタです。すべての商品を一意に管理する台帳で、ここが崩れると全体が崩れます。最低限、次の列を持たせます。

設計で最も重要なのがSKUを社内で一意に決めることです。各モールは独自の商品IDを持ちますが、それらを社内SKUに紐づけることで、はじめて横断的な管理ができます。この紐づけを最初に作っておくと、後の集約や自動化がすべて楽になります。逆にここが曖昧だと、どれだけツールを入れても在庫は合いません。

SKUの付け方のコツ

SKUは、後から見て意味が読み取れる規則で作ると運用が楽になります。例えば「カテゴリ2文字＋連番3桁＋色やサイズの識別子」といった形にすると、AC001-BK のように一目で商品の種類が分かります。避けたいのは、モールが自動発番したIDをそのまま社内SKUに流用することです。モールごとにIDの体系が違うため、同じ商品が複数のIDを持ち、集約できなくなります。社内SKUは一つ、モールIDはそれに紐づく従属情報という関係を最初に固めておくことが肝心です。色やサイズのバリエーションがある商品は、親商品と子商品(バリエーション)を分けて管理できる列を用意しておくと、後で在庫が混ざりません。

発注点と安全在庫の列

在庫管理の目的は、欠品も過剰在庫も防ぐことです。この判断を勘でやると必ず外します。シートに発注点と安全在庫の列を持たせ、機械的に判断できるようにします。

考え方はシンプルです。

• 安全在庫: 欠品を防ぐために最低限持っておく数。需要のブレとリードタイムを考慮して決める
• 発注点: この数まで減ったら発注をかける水準。おおむね「販売スピード × リードタイム + 安全在庫」で求める

たとえば1日平均10個売れ、発注してから入荷まで20日かかる商品なら、20日で200個消費します。ここに安全在庫を50個上乗せすると、発注点は250個です。在庫が250個を切ったら発注という運用にすれば、勘に頼らず欠品を防げます。シート上で現在庫が発注点を下回ったセルに色をつけておけば、一目で発注すべき商品が分かります。

発注点を数式で自動判定する

この計算は、スプレッドシートの数式で自動化できます。まず「1日平均販売数」の列を用意し、直近30日の販売数を30で割った値を入れます。次に「リードタイム(日)」の列に、その商品の入荷までの日数を入れます。発注点の列は「1日平均販売数 × リードタイム + 安全在庫」の式にしておけば、販売実績を更新するたびに発注点が自動で再計算されます。さらに「発注要否」の列を作り、現在庫が発注点以下なら「発注」と表示する条件式を入れると、毎朝そこを見るだけで発注判断が済みます。条件付き書式で「発注」の行を赤く塗れば、見落としもなくなります。判断を数式に落とし込むほど、担当者の勘に依存しない運用になります。

Amazonでは特に欠品が検索順位を直接下げます。この構造はAmazonの売上レポートを自動集計する方法で触れた在庫日数の指標とあわせて追うと、売上と在庫を一体で管理できます。

各モール在庫の集約

複数チャネルで売るなら、各モールの在庫を商品マスタに集約する仕組みが要ります。Amazonの在庫、楽天の在庫、自社倉庫の在庫がバラバラに存在すると、全体でいくつ持っているのかが見えません。

集約の基本は、先に決めた社内SKUを軸にすることです。各モールの在庫数をSKUごとに合算する列を作り、総在庫を一目で把握できるようにします。FBAに預けた在庫と自社倉庫の在庫を分けて持つと、どちらを補充すべきかも判断できます。

ここまで手作業で更新するのは大変ですが、まずは手動で回して構造を固めることが先です。構造が正しければ、後から自動化できます。逆に構造が曖昧なまま自動化しても、間違ったデータが速く流れるだけです。多チャネルの在庫と価格の整合をどう取るかは自社ECとモール、どちらを優先すべきかの両立設計もあわせて参考になります。

シートを壊さない運用ルール

在庫管理シートは、作り込むほど便利になる一方で、日々多くの人が触ると壊れやすくなります。数式が入ったセルを上書きしたり、列を勝手に増やしたりすると、集計が狂い、気づかないまま間違った在庫で発注してしまいます。長く使えるシートにするには、最初に運用ルールを決めておくことが大切です。

基本のルールを挙げます。第一に、手入力する列と、数式で自動計算する列を分けること。数式のセルには背景色をつけ、触らないと分かるようにします。第二に、入力する列には入力規則を設定し、決まった形式(数値のみ、リストから選択など)しか入らないようにします。第三に、商品マスタと日々の入出庫を記録するシートを分け、マスタは滅多に触らない構造にします。

もう一つ大切なのが、変更履歴とバックアップです。スプレッドシートには変更履歴が残るため、誰が何を変えたかを追えます。加えて、月に一度など定期的に別名でコピーを保存しておけば、シートが壊れても直前の状態に戻せます。在庫シートは事業の生命線なので、壊れる前提で守りを固めておくことが、安心して使い続けるコツです。複数人で運用するなら、編集できる人を限り、それ以外は閲覧のみにすると事故が減ります。

入出庫をその都度記録する

在庫が合わなくなる最大の原因は、入出庫の記録漏れです。商品が入荷したとき、出荷したとき、返品が戻ったとき、その都度シートに反映しないと、実数とシートが少しずつずれていきます。理想は、入出庫が発生したタイミングで記録することですが、忙しいと後回しになりがちです。そこで、記録を作業の流れに組み込むのが有効です。例えば、出荷作業の最後に必ず出庫数を入力するステップを手順に入れておけば、記録漏れが起きにくくなります。在庫管理は「正確な数字を入れ続けること」でしか成り立たないため、記録を特別な作業ではなく日々の作業の一部にしてしまうのがコツです。モールのAPIやCSVから販売数を自動で取り込めるようになれば、出庫の記録は自動化でき、人手による漏れをさらに減らせます。

表記ゆれが在庫を合わなくする

地味ですが在庫が合わなくなる大きな原因が、表記ゆれです。同じ商品なのに「Aキーホルダー」「A キーホルダー」「Aキーホルダー(黒)」と少しずつ違う名前で入力されると、集計上は別の商品として扱われ、総在庫が正しく出ません。これを防ぐのが、先に決めた社内SKUです。人が見る商品名ではなく、必ずSKUを軸に集計するようにすれば、名前のゆれに左右されずに在庫を合算できます。入力の際も、商品名を手打ちさせず、SKUを選べばマスタから商品名が自動で表示される仕組みにすると、ゆれそのものが起きなくなります。

在庫金額と回転を見える化する

在庫数を管理するだけでは半分です。診断士として必ず加えたいのが、在庫が今いくらの現金を縛っているかを映す列です。商品マスタに原価を持たせておけば、「原価×現在庫数」で商品ごとの在庫金額が自動で出ます。これを合計すれば、倉庫に眠っている現金の総額が一目で分かります。

さらに一歩進めて、在庫回転を見える化すると、どの商品が現金を無駄に寝かせているかが見えます。例えば「直近30日の販売数」の列と在庫金額を並べ、在庫が何日分あるか(在庫日数)を計算します。仮に1日平均5個売れる商品の在庫が150個あれば、在庫日数は30日分です。これが同じ売れ行きで在庫300個なら60日分となり、明らかに持ちすぎです。

在庫日数が極端に長い商品を色で目立たせておけば、仕入れを絞るべき商品が毎回すぐに分かります。在庫金額と回転を見える化するだけで、過剰在庫に気づけるようになり、拘束される現金が減ります。在庫とキャッシュの関係の全体像はEC事業の資金繰りと在庫の関係を参照してください。

専用システムに移行するタイミング

スプレッドシートは強力ですが、万能ではありません。取扱商品が数百を超え、チャネルも増えてくると、手動更新の負担やGASのメンテナンスが重くなり、シートの限界が見えてきます。専用の在庫管理システムを検討する目安は、いくつかあります。日々の在庫更新に多くの時間を取られている、在庫のずれによる欠品や売り違いが頻発している、複数人での同時運用でシートが壊れやすくなっている、といった状態です。スプレッドシートで在庫の何を見るべきかを体得した後なら、システム選びで迷いません。自分で設計した経験があるからこそ、システムに求める機能が具体的に分かり、過剰な機能に振り回されずに済みます。逆に、シートで基礎を固めないままシステムを入れると、何を管理したいのかが曖昧なまま高い費用を払うことになります。まずシートで掌握し、限界が来たら移行する。この順序が結局は失敗が少ないやり方です。

棚卸しとシートを合わせる運用

どれだけ精緻なシートを作っても、実際の在庫数と合っていなければ意味がありません。出荷や入荷を記録し忘れると、シート上の数字と倉庫の実数が少しずつずれていきます。これを防ぐには、定期的な棚卸しでシートを実数に合わせる運用が欠かせません。例えば、売れ筋の主要商品は毎月、その他は数か月に一度、実際に数えてシートと突き合わせます。ずれが見つかったら、なぜずれたか(記録漏れ、破損、返品の未反映など)を確認し、記録のどこに穴があるかを潰します。シートは作って終わりではなく、実数と合わせ続けてはじめて経営の道具になるのです。

GASで自動化する第一歩

手動運用で構造が固まったら、Google Apps Script（GAS）で自動化に踏み出します。いきなり全部を自動化せず、効果の大きい一箇所から始めるのがコツです。

最初の一歩として効果が高いのは次のあたりです。

1. 発注点を下回った商品の自動通知。毎朝チェックしてSlackやメールに発注リストを送る
2. 各モール在庫の自動取得。APIやCSVから在庫数をシートに書き込む
3. 在庫金額の自動集計。原価×在庫数でキャッシュ換算を毎日記録する

特に発注アラートの自動化は、欠品を防ぎつつ発注忘れをなくす効果が大きく、実装も比較的簡単です。手動で回していた判断を、そのままGASのロジックに移すだけだからです。例えば、毎朝9時にトリガーで発注要否の列をチェックし、「発注」の行だけを抜き出してメール本文に並べて送る。この一つを作るだけで、発注忘れによる欠品が目に見えて減ります。

よくある失敗

• SKUを決めずに始める: モールIDを寄せ集めたまま管理し、同じ商品が二重に並んで総在庫が合わない。
• 原価列を持たない: 在庫数だけ管理し、在庫が今いくらの現金を縛っているかが見えない。
• 発注点を勘で決める: 数式にせず担当者の感覚に頼り、繁忙期に欠品と過剰在庫を繰り返す。
• 構造が曖昧なまま自動化: 土台が整う前にGASを組み、間違ったデータが速く流れるだけになる。

在庫管理は地味ですが、EC経営の生命線です。一枚のスプレッドシートで在庫を掌握し、段階的に自動化していく。この積み上げが、在庫に縛られない身軽な事業を作ります。

• 社内で一意のSKUを決め、各モールIDと紐づけたか
• 原価を持たせ、在庫をキャッシュ換算できるようにしたか
• 発注点と安全在庫を数式で機械的に判断できるか
• 各モールの在庫をSKU軸で総在庫に集約したか
• 効果の大きい一箇所からGAS自動化を始めたか
• 販売実績を更新すれば発注点が再計算される設計か

この記事の監修者

廣瀬 正拓

中小企業診断士 / EC事業経営者

自社ECブランドを企画から販売まで手がけ、累計10万個以上を販売。取り扱いIP・版権元は30社以上、年商1億円超のEC物販も複数支援。Amazon・楽天・Shopify・Qoo10の4チャネルを現役で運営しながら、EC事業者向けの戦略コンサルティングと業務効率化ツールの開発支援を行う。実務の知見はコラムで公開中。

監修者のコラムを読む →

あわせて読みたい

業務効率化Amazonセラーの業務効率化ツールは「買う」より「作る」。現役セラーが自社開発を勧める理由業務効率化EC運営の定型業務はGASで自動化する。現役セラーが毎日使っている実例5選【コード付き】業務効率化多店舗の出品作業を10分の1にする。商品マスタ一元管理という設計