小規模 Shopify ストアを運営する DTC オペレーターで、在庫状況が「スプレッドシートを持って祈っている」状態なら、この記事はあなたのためのものです。良いニュース：小規模 DTC ブランドが抱えるほとんどの痛みのある在庫問題は、Shopify を適切な質問をして適切なシグナルを監視できるエージェントに接続することで解決できます。新しい ERP なし。月額 400 ドルの在庫 SaaS なし。
これは実際の運営者が Tablize を使って構築するのを見てきたプレイブックです。盗んでください。
3 つの問題
私たちが見てきたほぼすべての DTC 在庫ミスは、3 つのバケツのいずれかに入ります：
1. トップセラーの欠品。 最高の SKU が売り切れ、再注文を待つ間 2 週間の収益を失う。原因はしばしば「速度変化を見るのを忘れていた」。
2. デッドストック。 週 5 個売れる SKU を 500 個注文した。その注文を 100 週間かけて解消することになる。原因はしばしば「ローンチ数値が良く見えたので注文を続けた」。
3. 補充計算が間違っている。 前月の売上に基づいて注文するが、リードタイムは 6 週間。新在庫が到着する頃には需要がすでにシフトしている。原因はしばしば「そのモデルを構築していない」。
良い在庫モニタリングセットアップは、3 つすべてが当たる前に捕捉します。Tablize で各々を配線する方法。
セットアップ：Shopify（および理想的には Amazon SP）を接続
まだ接続していなければ、Shopify → Tablize は OAuth で 2 分。エージェントが orders、order_line_items、products、customers テーブルを読みます。履歴バックフィルが一度起き、それから増分同期。
Amazon でも販売しているなら、同じ方法で Amazon Selling Partner を接続。これでエージェントは両チャネルを横断する合算売れ行きを計算できます — 1 つのチャネルの在庫を引くと他方に影響するので、これが予測に実際必要なもの。
1 つのアップロードもしたいでしょう：COGS シート。何でも構いません。Google シート、Excel ファイル、CSV。ドラッグインしてください。エージェントは後で SKU 別の真のマージンを計算するためにこれを使います。
問題 1：欠品防止
ほとんどの人がやるバージョン：週に 1 回ダッシュボードを開き、在庫レベルを目視し、何が少ないか頭で推測。これは ~5 SKU で機能し、20 で破綻します。
Tablize 版：ウォッチ。
"Shopify の在庫を監視してください。直近 30 日収益で上位 50 の各 SKU について、
過去 30 日の速度に基づいて在庫日数を計算してください。それらのいずれかが
14 日分の供給を下回ったら、SKU 名、現在の在庫、日次速度、予測欠品日、
30 日分のカバーを仮定した推奨再注文数量を Slack で通知してください。"これがするもの：
- 動的に速度を計算。 売上構成が変わるとトップ 50 も変わる；急に売れた SKU は自動的に含まれる。
- 実在庫日数を計算。 単に「100 単位以下」ではない — この SKU の現在の売れ行きで、いつ欠品するか。
- 行動に必要なものすべてで通知。 SKU 名、現在の在庫、予測欠品日、推奨再注文。行動するのに Tablize を開く必要がない — Slack の DM から決定して行動できる。
- ノイズをスキップ。 月 1 個売れる SKU は 14 日アラートを必要としない。「収益で上位 50」フィルターが信号対ノイズ比を高く保つ。
このウォッチは忙しいストアで平均数時間ごとに発火します。1 週間後、どの SKU が熱く、どれが安定しているかの感覚が得られます。トップセラーへの欠品が起きなくなります。
このパターンのスターターパック：/templates/inventory-below-threshold-alert。
問題 2：デッドストック検出
反対の問題。倉庫に動かないユニットが座っています。
Tablize 版：週次レポート。
"毎週月曜日、以下の SKU を見つけてください：
- 現在の速度で 60 日以上の在庫を持つ
- 定期的なケイデンスで再注文している
- 速度がピークから 30% 以上下落
現在の在庫、ピーク速度、現在の速度、在庫日数、推奨事項
（再注文を停止、ディスカウントで促進、または評価減）付きでリストしてください。"月曜のブリーフが受信箱に到着。90 秒でスキャン。ほとんどの週、リストは空か行動すべき 1〜2 SKU。四半期に一度、もう四半期分のデッド資本のコストになっていたはずの在庫ドリフトを発見します。
ここでの Tablize 特有のもの：エージェントは ピーク速度 vs 現在速度 を見ます。かつて よく売れたが減速した SKU を捕捉 — 最も一般的なデッドストックパターン。単に現在の速度を見るとそれを見逃します。SKU はまだ多少動いているからです。
問題 3：リードタイムを考慮した補充計算
naive な補充計算式：
再注文数量 = 予測売上 × カバー期間
しかしこれはリードタイムを無視します。再注文が到着する頃には需要がシフトし、考慮すべき新しい売上があり、「予測売上」の仮定が古くなっています。
正しい式はこちらに近い：
再注文数量 = （リードタイム + カバー期間にわたる予測売上）−（現在の在庫 + 在途在庫）+ 安全在庫
スプレッドシートでこれをやるのは痛い。Tablize でやるのは 1 プロンプト：
"在庫補充アプリを構築してください。私の上位 100 SKU の各々について、
曜日とトレンド要素付きの過去 90 日データで次の 90 日の日次売上を予測。
以下を表示：
- 現在の在庫
- 在途（Shopify metadata.in_transit フィールドが存在すればそれを仮定、なければ 0）
- リードタイム（SKU 別に指定しない限り 30 日を仮定）
- リードタイム + 30 日カバーにわたる予測需要
- 推奨再注文数量（14 日の安全在庫を考慮）
- 推奨再注文日（現在 + 在途が 14 日カバーに達したとき）
各再注文を承認 / スキップするチェックボックスを与え、私の決定をログしてください。"エージェントが小さなアプリを構築します。週 1 回開いて、テーブルをスキャンし、再注文する SKU のボックスをチェックし、決定をサプライヤーに送る（Tablize はメールまたは PO PDF を生成可能）。決定ログにより、次四半期に「再注文判断は正しかったか」を振り返るのが簡単になり、それがモデル改善にフィードバックします。
スターターパック：/templates/inventory-replenishment-app。
これが置き換えるもの
現在使っているもの：
- スプレッドシートだけ： より多く、速く、より少ない労力で捕捉。
- Shopify 組み込みの在庫レポート： Shopify のレポートは現状を伝える — Tablize はこれから起こることを伝える。
- 月額 $100〜200 の在庫 SaaS（Cogsy、Inventory Planner、Brightpearl）： 専用 SaaS はより洗練された UI とより多くの機能を持つ。Tablize は月額 $60 で 80% の価値を提供、おまけに SaaS の作者が考えた質問だけでなく好きな質問ができる。
年商 ~$5M 超で複雑な複数倉庫 + B2B 運用を持つ DTC ブランドは、専用 SaaS か実 ERP が欲しいでしょう。それ以下のすべて — 件数ではほとんどの DTC ブランド — にとって Tablize は正しいコスト / 価値ポイント。
それがしないこと
ギャップについて明確に：
- ベンダーシステムへの PO 生成なし。 Tablize は PO 内容を起草できますが、メールやベンダーポータルで送信します。
- 受領のためのバーコードスキャンなし。 それには既存の倉庫プロセスが必要。
- 複数倉庫の在庫配分ロジックなし。 3 つの倉庫を持ち、再注文受け取りをどこに出荷するか最適化が必要なら、それは別問題。
- 外部シグナルからの需要予測なし。 予測は自分の売上履歴を使う。Google Trends や有料トラフィック予測を組み込みたければ可能ですが、自分で構築する。
今週何をするか
DTC オペレーターでここまで読んだなら、30 分のセットアップ：
- Shopify を Tablize に接続（2 分）。
- COGS スプレッドシートをドロップ（1 分）。
- 欠品ウォッチ をセットアップ（2 分）。
- 月曜朝の売上ブリーフ をセットアップ（2 分）。
- すべてのコスト後の SKU 別利益 を一度実行して、実際に儲かっているものを見る（5 分）。
- 補充アプリ：来週まで残す。最初にウォッチを動かしてから、何が発火するかの数日のデータが揃ったらアプリを構築。
それが順序。ウォッチが緊急のもの（欠品）を捕捉。週次ブリーフがパターン（デッドストック）を捕捉。補充アプリはより深い投資だが、他の 2 つが整ってから初めて有用。
自分の Shopify ストアで Tablize を無料で試す →
関連記事：