在庫管理はスプレッドシートから始めてよい。システムに移す境目を商品数と登録先の数で決める

対象と結論

自社サイトとモールの両方に同じ商品を出し始めると、最初にぶつかるのが「売れた商品を、もう片方で下げ忘れる」ことです。下げ忘れれば、無い商品を売ってしまう。そこで一元管理システムを調べ始めますが、料金表を見て手が止まる。この記事は、その手前で「スプレッドシートで足りる範囲」と「システムか自作へ移す境目」を決めるためのものです。

結論は、最初からシステムを入れなくてよい、です。一枚の表で足ります。商品ごとに一意の番号を付け、状態、登録先ごとの掲載の有無と価格、売れた日を列に持つスプレッドシートを一枚作る。売れたら翌朝までに全登録先で下げる。登録先が2〜3で、在庫の動きが日に数件までなら、これで回ります。境目は、商品数が増えて各登録先への登録と在庫の反映が手で追いつかなくなったときで、そこで一元管理システムを入れるか、登録の自動化まで含めて自作するかを決めます。自動化まで組めないなら、システムを選びます。

運営者の時計店 Timeseek（timeseek.net）は、在庫をスプレッドシートで管理しています。一点物なので1商品1行で、売れたら行の状態を変え、各登録先で下げる。商品数が多い店ではこの運用は厳しいと感じていて、その場合はシステムを検討するか、AI を使って登録の自動化まで組む方がよい、というのが運営者の見立てです。ここに商品数や売上は書きません。書くのは列の型と、移す境目の決め方です。

条件を確認

自分の店の状況を五つ書き出します。

1. 登録先: 自社サイト、楽天、Yahooショッピング、Amazon、店頭のうち、同じ商品を出す先がいくつあるか
2. 商品の性質: 一点物（1商品1行）か、同じ商品を複数持つ（数量の列が要る）か
3. 在庫の動き: 売れる、入荷する、状態が変わる、が日に何件起きるか
4. 登録の手間: 新しい商品を各登録先に登録するのに、1商品あたり何分かかるか
5. 担当: 毎日一度、全登録先を見て回れる人がいるか。休みの日はどうするか

在庫シートの列

列は少ないほど続きます。八つで始める。次の列で始めて、足りなくなった列だけ足します。

「状態」の列が在庫の正です。各登録先の在庫数ではなく、この列を見て下げる。登録先の画面で先に在庫を直すと、どれが正しいか分からなくなります。

架空の例で反映の手順を見る

架空の3商品と2登録先（自社サイトとモール）の例です（架空データの例。Timeseek の実データではありません）。

W-001 が失敗の入口です。ここを見る。自社サイトで売れて「売約済み」にしたのに、モールの列が「掲載中」のまま。翌朝の確認でこの行を見つけ、モールで下げて「下げ済み」に変える。これが毎日の作業のすべてで、行ごとに「状態が売約済みなのに掲載中の列がある」を探すだけです。W-003 は返品や仕入れ直後で検品が終わっていない商品で、検品が終わるまでどこにも出しません。

システムか自作へ移す境目

上から順に当てて、最初に当たったところで止めます。件数の境目は運営者の目安です。実測から引いた線ではありません。

無料・標準機能で足りる場合

スプレッドシートは無料の表計算で足ります。列は上の8種類。登録先が増えたら「掲載」と「価格」の列を足すだけです。毎朝の確認は、「状態」が売約済みか発送済みで、「掲載」に掲載中が残っている行を絞り込みで探す。これは表計算の絞り込みだけでできます。

在庫の正はシートの「状態」列に置き、各登録先の在庫数はそれに合わせて手で直します。逆にしない。順番が命です。モールの画面で先に直すと、シートと食い違ったときにどちらが正しいか分からなくなります。

古物商の台帳（取引の記録）は、この在庫シートとは別に要ります。仕入れ日・仕入れ先・売れた日の列があれば、台帳への転記はしやすくなります。

比較

在庫の反映と登録の作業を、スプレッドシート・一元管理システム・自作・依頼のどれでやるかの比較です。料金は公式ページで読んだものを確認日つきで書き、それ以外は書きません。

一元管理システムは、ネクストエンジン、GoQSystem、TEMPOSTAR、助ネコが国内の候補です。ネクストエンジンの対応モール一覧では Shopify は「受注のみ」で、自動連携にはアプリが必要と書かれています（確認日 2026-09-09）。自社サイトの在庫まで一元管理で持てるかは、どのシステムも契約前に確かめる項目で、ここが弱ければ「シート＋自作の登録処理」の方が合う店もあります。比べ方は別の記事（IV01）にあります。各社と運営者の紹介提携は未確認で、この記事に紹介リンクはありません。提携が確認できたら、通常のリンクと区別した紹介リンクをここに置きます。

進め方を選ぶ

• スプレッドシートで始める: 上の列で一枚作り、毎朝の絞り込みを運用に入れる。境目の表に当たるまで続ける
• Claude Code で自分で作る: 最初の範囲は、在庫シートを読んで各登録先の登録用データ（CSV）を作る一処理までに限ります。本番の登録先への書き込みは含めません。指示文と受け入れテストはできしだいこの記事の下に載せます。型は実装資料の一覧にある他の記事の資料が参考になります
• 一元管理システムを入れる: 国内4社の公式ページで、在庫の正をどこに置けるか、対応する登録先、料金の単位を確認日つきで控えてから申し込みます
• 迷う場合だけ相談する: 相談から条件を送れます（任意。受託は初期の範囲外です）

どの進め方でも、この記事の列の型を使うのに登録や紹介リンクは要りません。前提の五つを整理するには店舗の条件を整理する道具も使えます。

導入・検証・戻し方

スプレッドシートで始める順番です。実行ログはなく、運営者の運用に基づく提案です。

1. 商品番号の付け方を決める。登録先が違っても同じ番号にする
2. 上の8種類の列で一枚作り、今ある商品を全部入れる
3. 各登録先の掲載の有無と価格を、シートの列と一致させる。食い違いがあればシートを正にして登録先を直す
4. 毎朝の絞り込み（売約済みなのに掲載中）を運用に入れ、1週間は下げ忘れの件数を数える
5. 新商品の登録にかかる時間を1商品ごとに記録し、週の合計を出す
6. 境目の表に当たったら、自作の一処理か一元管理システムを比べる。切り替えの前に、シートを在庫の正のまま残す

戻し方は、システムや自作の処理を止めてもシートが残るように作ることです。一元管理システムを入れるときも、解約時に在庫を書き出せるかを契約前に確かめ、シートの列に戻せる形にしておきます。

検証と制約

実店舗での検証は未実施です。この記事の列の型は運営者の時計店の運用から起こしたもので、記入例は架空データの例です。境目の件数は運営者の目安で、実測から引いた線ではありません。商品数や売上は書いていません。

一元管理システムについて確認日つきで書けたのは、ネクストエンジンの料金ページの記載と、対応モール一覧で Shopify が「受注のみ」と書かれていることまでです（2026-09-09）。GoQSystem、TEMPOSTAR、助ネコの対応範囲と料金は、この記事では確認していません。

ネクストエンジンの Business Partner 制度が公式ページで公開されていることは確認しましたが、運営者の提携は未確認です。この記事に紹介リンクはなく、置く場合は通常のリンクと区別する属性を付けます。

出典

• P12: ネクストエンジン 料金（ネクストエンジン、確認日 2026-09-09）
• P13: ネクストエンジン 対応モール・カート（ネクストエンジン、確認日 2026-09-09。Shopify は受注のみ）
• G07: ネクストエンジン Business Partner（ネクストエンジン、確認日 2026-09-07。公開ページの確認のみで、本人提携は未確認）
• G01: 役に立つ、人を第一にしたコンテンツ（Google、確認日 2026-09-07）
• G02: Google Web Search spam policies（Google、確認日 2026-09-07）
• V301: Google Search generative AI optimization guide（Google、確認日 2026-09-07）
• V306: Structured data general guidelines（Google、確認日 2026-09-07）
• V308: Qualify outbound links（Google、確認日 2026-09-07）
• S12: Claude Code best practices（Anthropic、確認日 2026-09-06）

紹介関係の開示: この記事で名前を挙げたネクストエンジン、GoQSystem、TEMPOSTAR、助ネコについて、運営者の紹介提携は未確認です。紹介リンクは置いていません。列の型を使うのに登録や紹介利用は要りません。