inventory-planner

在庫計画

売れる商品を品切れになる前に仕入れ、売れない商品を仕入れるのはやめましょう。

在庫は、オーナーがすでに支払った現金です。問題は2つあります。顧客が買いに来た商品が品切れになることと、誰も欲しがらない商品のパレットを抱えることです。どちらも問題になるずっと前から販売履歴に表れるため、このスキルでは販売履歴を読み取ります。

ステップ 1 — 販売データと在庫を取得する

推奨： 販売データと在庫レベルには Shopify を使います。Square と NetSuite も同様に使えます。

代替手段として完全対応： 販売履歴の CSV と在庫数を用意します。ファイルは2つでも、両方を含む1つのファイルでも構いません。この方法はコネクターがなくても使え、同じ結果が得られます。クリップボードを使って在庫を数えている事業者も多く、これは正当な入力方法です。

商品ごとに、SKU、商品名、日付別の販売数量、現在の在庫数、単位原価、販売単価、仕入先、判明している場合はリードタイムが必要です。リードタイムが不明な場合は一度だけ確認し、記憶しておきます。reference/data_sources.md を参照してください。

在庫数がいつ時点のものかを伝えてください。 2週間前の在庫数を使うと、品切れ日も2週間ずれてしまいます。

ステップ 2 — 2つの期間の販売速度を計算する

すべての商品について、次の値を計算します。

• 7日間の販売速度 — 直近1週間の1日あたりの販売数量です。現在の動きを捉えます。
• 28日間の販売速度 — 4週間の1日あたりの販売数量です。安定した基準値になります。

どちらも重要で、2つの値の差も有用な情報です。今週、28日間の販売速度の3倍のペースで売れている商品は、人気が上昇しているのか、1回だけ大量注文があったのかのどちらかです。それぞれ必要な対応は異なります。見分け方については reference/velocity_and_reorder.md を参照してください。

特定できる場合は、単発の歪みを基準値から除外します。たとえば、1回だけの卸売注文、返品されたロット、商品が販売できなかった品切れ期間です。在庫がなく販売がゼロだった期間は、需要がゼロだったことを意味しません。そのように扱うと、商品がいつまでも過少発注されることになります。

ステップ 3 — 品切れ日を保守的に予測する

品切れ日は、信頼できる方の1日あたりの販売速度ではなく、2つの期間のうち高い方で在庫数を割って求めます。早めの対応は安く済みますが、遅れると販売機会を失います。

次に、リードタイムと比較します。重要なのは品切れになる時期ではなく、まだ発注が間に合うかどうかです。

• 手遅れ — リードタイムが在庫日数を超えています。すでに品切れになる見込みです。そのことをはっきり伝えます。
• 今すぐ発注 — 在庫日数がリードタイムに安全余裕を加えた期間内です。
• まもなく発注 — まだ余裕はありますが、次の発注サイクルで対応します。
• 問題なし — 対応は不要です。

信頼できる販売速度がない商品については、品切れ日を決して示さないでください。販売履歴が2週間分しかない新商品や、販売が中断されていた商品は、商品名を挙げて「履歴が不十分」として警告します。

ステップ 4 — 発注数量を決める

既定の目標は、リードタイムを加えた60日分の在庫です。数量は28日間の販売速度に基づいて決め、2つの期間のうち速い方は使いません。在庫は、商品が届いた日から次の発注分が届くまで持たせる必要があります。そのため、リードタイムを考慮しないと、毎回ちょうどその日数分だけ在庫が不足します。その後、梱包単位、最低発注数量、発注済みの数量を考慮して調整します。

2つの販売速度は役割が異なるため、どちらも明記します。高い方は品切れの時期を示し、28日間の値は発注数量を示します。1週間の急増を基に60日分を発注すると、現金がパレットの在庫に変わってしまいます。

入荷予定の在庫を差し引かずに、発注数量を決めてはいけません。売れ行きの遅い商品を二重発注すると、3年分もの在庫を抱えることになります。

仕入先の梱包単位に合わせて丸め、どちらの方向に丸めたかを明記します。すべての推奨について金額も示してください。オーナーが判断するのは数量ではなく、現金についてです。

ステップ 5 — 動きのない商品を扱う

販売速度がゼロ、または非常に遅い商品は、目的の異なる別リストに分けます。これらを並べ替え候補にすることはありません。

• 販売速度ゼロ — 28 日間に販売数量がありません。資金がどれだけこれらの商品に拘束されているかとともに、販売低迷商品として報告します。これらの在庫日数は決して計算しないでください — 販売がないため、在庫がなくなることもありません。数値を出せば、誤りか意味のない結果になります。唯一の例外は、オーナーが指定したシーズン中の商品です。この場合は、処分リストではなく、日付付きの要監視リストに記載します。
• 過剰在庫 — 在庫日数が 120 日を超えています。余剰数量と金額を報告します。
• 不動在庫 — 90 日間、動きがありません。処分、セット販売、または値引きを提案します。

これらの商品に拘束されている資金を合計します。この金額は、レポート全体の中で最も意外な数字であることが多く、最も役立つ数字でもあります。

ステップ 6 — 履歴が裏付ける場合に限り、季節性を適用する

少なくとも 1 年分の履歴がある場合は、今後の期間を前年の同じ期間と比較して調整します。

1 年未満の場合は、その旨を伝え、調整しないでください。 9 か月分のデータからでっち上げた季節性倍率は、スーツを着た当てずっぽうです。代わりにオーナーに尋ねてください。短い履歴よりも、オーナーのほうが自社のシーズンをよく知っています。reference/seasonality.md では、どちらのケースも説明しています。

ステップ 7 — 発注リストを提示する

まず、購入総額と、まもなく在庫切れになる商品の数を示します。次に、今すぐ発注、近日中に発注、販売低迷商品、判断するには履歴が少なすぎる商品を並べます。

各行には、根拠となる数値をすべて記載します — 販売速度、在庫日数、リードタイム、数量、原価です。根拠が見えれば、オーナーは 1 分で承認できます。見えなければ、すべて手作業でやり直すことになります。

ハウススタイルのアーティファクト（../../shared/artifact-style.md）に従って、発注リストを HTML アーティファクトとして表示します。在庫切れ日順で並べた在庫切れテーブルには、等幅の表形式数字と、緊急度を示すステータスピル（今すぐ発注／近日中に発注／問題なし／手遅れ）を使用します。また、数量と金額の合計を記載した再発注パネル、および拘束されている資金を示す販売低迷商品セクションも含めます。チャットの要約も残します。アーティファクトは全体像を示すものであり、それだけですべてを伝えるものではありません。

ステップ 8 — 承認を得て、発注書と仕入先メールの下書きを作成する

発注書は資金の支出を確約し、仕入先メールはオーナーの名前で送信されるため、どちらも明示的な承認を待ちます。

確認を求める前に、仕入先、明細、合計金額を伝えます。共通のボイスプロファイルに従い、オーナーの口調で仕入先メールの下書きを作成します。まだプロファイルがない場合は、そのファイルの「サンプルがない場合」の指示に従ってください — 仕入先にすでに送ったメールを 3 通提示してもらいます。提示したくない場合は、平易で中立的なメールを作成し、オーナーの口調ではないことを伝えます。誰かの仕入先との関係について、性格を決めつけてはいけません。

Google Calendar が接続されている場合は、再補充の判断を行う定期的な予定を提案します。緊急対応に追われるよりも、定期的な習慣にするほうがはるかに効果的です。承認済みの発注書はここに保管します。このスキルが管理します。QuickBooks または NetSuite が接続されている場合は、それぞれの請求書が到着した際に実際の記録と三者照合できるよう、コード化したメモを各発注書について ap-processor に渡します（仕入先、PO 番号、合計金額、予定日、勘定科目、クラス、案件）。ap-processor は発注書を読み取りますが、作成はしません。

締めくくりの提案

決定内容（購入総額と、まもなく在庫切れになる商品）を 1 行で締めくくります。その後、最も関連性の高い次のステップを、正確なトリガーフレーズとともに提案します。オーナーが発注書の作成から送信までを希望する場合は、「reorder」（/restock）です。さらに、ルーターの表にある候補から最大 2 つまで提案できます。たとえば「cash forecast」（cash-flow-snapshot）や「pay the bills」（/pay-the-bills）です。提案は最大 3 つまでとし、このセッション中にオーナーがすでに断ったものを再び提案してはいけません。

やってはいけないこと

• 販売速度、リードタイム、在庫切れ日を推測してはいけません。 履歴が少なすぎる場合は、SKUごとに報告し、平滑化してはいけません。
• 在庫切れの期間を需要ゼロとして扱ってはいけません。 需要が抑制された状態であり、その後のすべての分析に偏りが生じます。
• 販売速度がゼロの商品について、再発注を推奨してはいけません。 売上がないなら、追加購入ではなく購入を停止します。
• すでに入荷予定の数量を差し引かずに、再発注数量を決めてはいけません。
• 1年分の履歴がない状態で季節性を適用してはいけません。 代わりに担当者に確認してください。
• 承認なしに発注書を送ったり、ベンダーにメールを送ったりしてはいけません。 どちらも支出を伴うか、信頼を損なうおそれがあります。
• 金額を示さずに数量だけを報告してはいけません。 担当者は資金のことを考えています。

参考ファイル

• reference/data_sources.md — Shopify、Square、NetSuite、CSV の保存先と必須フィールド
• reference/velocity_and_reorder.md — 7日間／28日間の計算、歪みへの対処、再発注数量の決め方
• reference/seasonality.md — 調整するタイミング、確認するタイミング、実施した内容の伝え方
• reference/po_drafting.md — 発注書の構成とベンダー宛てメールの作成
• reference/gotchas.md — 人気商品を在庫切れにしたり、パレット在庫に資金をつぎ込んだりする失敗

記載されていないツールを使う場合

このスキルで指定されているコネクターは、テスト済みの接続方法であり、利用可能なツールのすべてではありません。担当者が、接続されていない、または記載されていないツールをこのワークフローで使いたい場合は、build-connector を提案してください。まずコネクターディレクトリを確認し、該当するものがなければ Zapier 経由で接続します。生の API に直接接続するものを手作業で構築することはありません。接続が確立されたら、そのツールは他の任意のコネクターと同様に、このスキルに組み込まれ、同じ承認ゲートの対象になります。