在庫再発注提案アプリ：Min/Maxで発注草案を作成する

このアプリが解決すること（としないこと）

店舗運営はたいてい二つの高コストな失敗の間を行き来します：売れ筋が切れて販売機会を逃すか、売れない在庫を買い過ぎて資金が滞るか。日常の問題は「在庫はあるか？」ではなく、「次に何をどれだけ買うべきか？」であり、スプレッドシートで1時間かけたくない、ということです。

Min/Maxの設定はその判断をシンプルにします。各SKUに対して2つの数値を保存します：

• Min：再発注を検討する最低在庫レベル。\n- Max：再発注時に補充したい目標在庫レベル。

例えば、SKUが6個でMinが10、Maxが25なら、提案は19個となります。記憶に頼るのではなく、週ごとに一貫する明確なルールを使っています。

在庫再発注提案アプリは、現在のオンハンド数（任意で発注中数も）を取り込み、SKUごとにMin/Maxルールを適用して**発注草案（draft purchase list）**を作ります。その草案が主な出力です：短くレビュー可能なリストで、「何をいくつ注文するか？」に答えます。誰かが仕入先ポータルを開いたり担当者にメールする前の段階です。

このアプリが自動で発注を出すわけではない点は重要です。実際の発注には例外があり得ます：仕入先が欠品、ケースパックに合わせた丸めが必要、季節商品はスキップ、プロモ来週など。アプリは素早く提案を出し、人が承認・編集・除外できるようにするべきです。

この種のツールは店舗マネージャー、オペレーションリード、購買担当がよく使います。兼任の少人数チームにも、信頼できる出発点が欲しい場合に有用です。

SKUごとに保存すべきデータ

良い提案は地味で一貫したSKUデータから始まります。基本が乱れていると草案はランダムに見え、人々の信頼を失います。

プロセスが進化しても同じ“形”を保てるSKUレコードを目指してください。

コアなSKUフィールド（最低限必要なもの）

初日から使えるようにするには：

• スキャンや入力に使うSKU識別子と、誰もが認識する短い名称
• 単位（個、ボトル、箱、kgなど）— 数量と発注が同じ意味になるため
• ステータス（アクティブ/非アクティブ）— 廃番が表示されないようにするため
• MinとMax（必要なら別の再発注ポイントも）
• 備考と「最終更新」情報（タイムスタンプや更新者）

MinとMaxがガードレールです。再発注ポイントを別に持つのは任意ですが、リードタイムが長い場合や供給が不安定な場合は早めに発注したい時に役立ちます。

可用性と発注詳細（現実的な計算に必要なもの）

次の項目が「どれだけ買えるか」を現実に近づけます：

• オンハンド数量とそのソース（今の手動カウント、後で同期する可能性など）
• 優先仕入先（プライマリベンダー）
• パックサイズ（ケース数量）— 有効な倍数で注文するため
• リードタイム（日数）
• 最低発注数量（MOQ）

“オンハンド”の由来を明確にしてください。手入力から始めるなら最終カウント日を保存し、後でPOSや倉庫ツールと同期する際は最終同期時刻も保存します。その一つの詳細が「なぜこれを提案した？」という多くの疑問を解きます。

Min/Max提案の計算方法

Min/Maxは単純なルールです：在庫が低いときだけ発注し、安全なレベルまで補充します。結果は監査しやすい草案リストになります。

1) いつ発注をトリガーするか？

一つのトリガーを選んで一貫して使ってください。最も一般的なのは：

• On Hand が Min 以下の場合、そのアイテムは対象になります。\n- On Hand が Min より上なら、提案は0で草案リストに載りません。

これにより既に健全なアイテムについてのノイズを避けられます。

2) どれだけ提案するか？

対象になったら基本は「Maxまで補充」です。単純な式は：

base_suggested = max - on_hand
suggested = max(0, base_suggested)

例：Min = 10、Max = 40、On Hand = 14。

• On Hand (14) は Min (10) より上なので suggested = 0。

もし On Hand が 8 に下がれば：

• base_suggested = 40 - 8 = 32\n- suggested = 32

草案を現実的にする簡単な調整

基本計算のあとに、実務に合わせた小さなルールをいくつか足します：

• ケースパック丸め：12個単位でしか買えないなら32は36に切り上げる。\n- MOQ：MOQが50なら36を50に引き上げる。\n- 負の提案を出さない：On Handが55でMaxが40ならbaseは-15だが、suggestedは0にする。\n- 任意の上限：大きな買いすぎを避けたい場合は上限を設定する。

先に扱うべきエッジケース

データが悪いと提案も悪くなるので、次の状況を明示的に扱ってください：

• 廃番SKU：在庫が低くても常に提案は0。\n- 負の在庫：赤フラグとして扱い、計算はするがレビュー用の警告を出す。\n- Min/Maxが欠けている：推測せず提案を0にして「設定が必要」と表示する。

ユーザーフロー：在庫カウントから発注草案まで

チームが実際に使うフローが最良です。シンプルに保ちましょう：在庫を記録してから提案を生成します。ラベルやダッシュボード、分析は後から追加できます。

典型的なセッションはこうです：ユーザーが素早くカウントを行い、必要ならロケーションを選び、SKUごとに数量を入力して保存し、ワンボタンで発注草案を作成します。購買担当がその草案をレビューして編集した後に承認します。

画面を落ち着かせるために実用的なフィルタを一つ入れておくと良いです：min未満のみ表示、またはステータス付きですべて表示。忙しい日は「min未満のみ」が速く、漏れ確認したいときは「すべて表示」が役立ちます。

多くの小さなチームに合うシンプルな流れ：

• オンハンド数を入力またはインポート\n- 提案を生成\n- 草案リストをレビュー（min未満のみ、またはステータス付きですべて）\n- 提案数量を編集し、メモを追加\n- 草案を承認してエクスポートや共有で発注へ送る

現実は雑なのでオーバーライドが重要です。買い手はプロモ用に余分に買ったり、資金不足や仕入先遅延で少なくすることがあります。提案数量は出発点であり、絶対値ではないと扱いましょう。

フラストレーションを防ぐ小さな制御：

• 手動オーバーライド数量（誰が変更したかを記録）\n- 「保留」フラグでしばらく発注をスキップ\n- 任意の理由フィールド（季節、ベンダー問題、在庫処分）

最後に、草案生成時のスナップショットを保存してください：タイムスタンプ、使用したオンハンド数、当時のMin/Max、オーバーライド前の提案数量。誰かが「なぜこれを24個注文したの？」と聞いたら、その草案を開けば生成時の入力がわかります。

柔軟性を保つシンプルなデータベース構造

良い再発注アプリは信頼できる少数のテーブルで始まります。目標は完璧なERPではなく、サプライヤーやロケーション、賢いルールを追加していけるクリーンな基盤です。

最初に必要なコアテーブル

単一店舗なら「商品とは何か」を「持っている量」と「再発注方法」から分離してください：

• SKUs：アイテムごとに1行（SKUコード、名称、単位、カテゴリ、アクティブ/非アクティブ）\n- Suppliers：仕入先名と連絡先（リードタイムなどの条件を追う場合はそれも）\n- Reorder settings：SKUごとのMin、Max、再発注点、優先仕入先、パックサイズ\n- Inventory levels：SKUごとの現在のオンハンド（後でロケーション別に拡張）と最終カウント日\n- Draft orders：ヘッダ（仕入先、ステータス、作成者）と行（SKU、提案数、最終数量）

この構成にすると、再発注ルールを変えてもSKUリストを書き換える必要がなく、草案注文を提案と承認の記録として残せます。

今は店舗が1つだけなら、ロケーションを作り過ぎないでください。SKUごとに単一の在庫数で十分です。2店舗目や倉庫を追加する時にLocationsテーブルを導入して、在庫レベルをSKU×ロケーションの形式に切り替えます。

ガードレール、ロール、エクスポート

小さな検証ルールは悪い入力が悪い注文に繋がるのを防ぎます。例：MinはMax未満であること、再発注点は負でないこと、パックサイズは0不可。設定が欠けている場合にどうするかも決めてください：提案をブロックするか、SKUを「設定が必要」にするか。

複数人が在庫カウントや設定を触るならロールを設けます：

• Viewer：SKUと草案注文を閲覧できる\n- Editor：カウントと再発注設定を更新できる\n- Approver：数量を確定し、草案注文を承認できる

注文の送り方も計画してください。将来自動化しても、多くのチームは最初CSVエクスポートや仕入先向けリストのコピーから始めます。

画面とロジックを段階的に作る

まずはSKUカタログと仕入先の2つのシンプルなリストから始めてください。各SKUには誰もが認識する名前、デフォルトの仕入先、購入単位（個、ケース、カートン）を持たせます。これがスタッフが毎日検索するリストになります。

次にSKUレコードに再発注設定を追加します。MinとMaxが基本ですが、パックサイズとリードタイムがあればより良い提案ができます。同じ商品を複数仕入先から買うならデフォルトを1つ設定し、草案で変更できるようにします。

在庫カウントは速度を優先する高速な画面を作ってください。クイック編集グリッドが有効です：通路やカテゴリでフィルタして数量を入力し保存する形です。

ほとんどのチームに必要なコア画面：

• SKUリストとSKU詳細（Min、Max、パックサイズ、リードタイム含む）\n- 仕入先リストと仕入先詳細\n- 在庫カウント入力（グリッド＋フィルタ）\n- 再発注提案（結果テーブル＋簡単な操作）\n- 発注草案（編集可能な行＋承認）

その後、提案ロジックを実装します：各SKUについて「on hand（必要ならon orderも）」と再発注ルールを比較し、Maxへ戻すための提案数量を計算し、パックサイズで丸めて供給側の単位に合わせます。

レビュー用に草案注文を生成し、それをDraft、Approved、Sentなどのステータスを持つドキュメントとして扱います。草案作成時に提案ラインを仕入先別にグループ化して注文ラインにコピーし、数量編集や仕入先変更、アイテム除外を許可します。

最後に出力を整えます。印刷して手動で発注するチームもいれば、ファイルをエクスポートするチームもあります。承認されたものを保存しておけば「提案と実際の発注」を比較してルールを改善できます。

再発注提案を信用できなくするよくあるミス

再発注の計算自体は単純です。信頼を壊すのは設定の乱れです。ほとんどの問題は式が正しくても草案が「おかしい」と感じられるところに現れます。

典型的な問題は単位の混在です。棚は“個”で数え、発注は“ケース”単位、受領は“パック”単位という場合、SKUの単位が不明確だとアプリはあなたが意図したものと違う24を提案するかもしれません。SKUごとに1つの基準単位（多くは“個”）を選び、「1ケース=24個」のような換算を保存して、最終発注数量が正しく翻訳されるようにしてください。

MinとMaxが推測で設定されるのも問題です。販売速度や仕入先のリードタイムを無視すると、見た目は整っていても実務で失敗します。動きの遅い商品でMaxが高過ぎると資金が滞り、動きの早い商品でMinが低過ぎると欠品します。

他のよくあるミス：

• ロケーションを追跡していない（バックルームと棚、店舗Aと店舗Bを区別していない）\n- 誰でもMin/Maxを編集できるようにして承認プロセスがない\n- 過去の値を上書きしてしまい、先週の発注が説明できない\n- 破損や引当中、輸送中の在庫を利用可能として扱っている\n- 数日前のカウントを使って提案し、後でそれを提案のせいにする

簡単なシナリオ：コーヒーポッドを売っているとします。棚に6箱、バックルームに18箱、別店舗に12箱あります。オンハンドを1つの数だけで管理していると誰かが6とカウントしたときにシステムは発注を提案してしまいますが、実際は36箱あります。ロケーションフィールドでこれを簡単に直せます。

草案リストを信用する前の簡単チェック

Min/Maxシステムはシンプルですが、草案はそれを支えるデータ次第です。仕入先に送る前に、提案を自信満々に見せながら実は間違っている静かなエラーを見つけるために少し時間を使ってください。

まず設定を確認します：再発注対象の全SKUに最小値、最大値、適切なパックサイズが必要です。どれかが欠けている場合、アプリはそのSKUをフラグにするかスキップするべきです。一つの空欄が巨大な注文や注文ゼロを生むことがあります。

次にオンハンド数量の妥当性をチェックします。負の在庫は起きます（返品処理漏れ、受領未記録、単位混在など）が稀であるべきです。遅い商品で-12のような値が見えたら、それは「調査」扱いにし、再カウントかトランザクション確認を促します。後で余分を解消するより安上がりです。

チェックリスト：

• 設定：各再発注SKUにMin、Max、パックサイズ、仕入先が入っているか\n- 数量：オンハンドが妥当か（500が50の入力ミスなどがないか）\n- 梱包：提案がケースパックやMOQに従って丸められているか\n- ポリシー：全員がMaxまで補充するのか、より保守的なターゲットにするのかを知っているか\n- 追跡性：編集が誰でいつ行われたかがわかるか

パッケージングルールには特に注意してください。仕入先が24個入りケースで販売し、草案が13を提案したら、システムはポリシーに基づき切り上げるべきです。MOQがある場合は元の提案と調整後の提案を両方見せてレビュアーが変更点を理解できるようにします。

また、チームにとって「十分に良い」基準を決めてください。Maxまで注文するのは攻めの戦略で現金を縛ります。より保守的なターゲット（例：上位商品はMaxまで、遅い商品は中間点まで）を採ると過剰在庫を減らせます。

最後に監査記録を残してください。各行に「最終変更者」と「最終変更日時」があるだけで信頼は高まりますし、後で揉めたときに役立ちます。

例：小さな店舗の週次再発注

30SKUを扱う近所の小さな店を想像してください。オーナーは毎週月曜に実地カウントを行い、短時間で確認できる発注草案を作りたいと考えています。

仕入先は2つ：仕入先A（スナック・飲料）と仕入先B（日用品）。

3つのSKUと提案計算

SKU 1：スパークリングウォーター12パック（仕入先A）

On hand: 8パック。Min: 10。Max: 30。Pack size: 6。

8はMin（10）未満なので、Maxまで補充する提案になります。

Max到達に必要 = 30 - 8 = 22パック。

パックサイズ（6）に丸め：22は24になる。

提案：24パック。

SKU 2：ポテトチップス（仕入先A）

On hand: 14袋。Min: 12。Max: 36。Pack size: 12。

14はMinより上なので、提案は0。Maxに達していなくても今は健康的で、今週の補充は不要。

SKU 3：食器用洗剤500ml（仕入先B）

On hand: 3本。Min: 6。Max: 18。Pack size: 6。

3はMin未満なのでMaxまで補充。

Max到達に必要 = 18 - 3 = 15本。

Pack size（6）に丸め：15は18になる。

提案：18本。

買い手の調整（予算と常識）

草案は出発点です。今週は予算が少し厳しく、雨の日はスパークリングの売れ行きが落ちることも分かっています。

オーナーはスパークリングウォーターを24パックから18パックに下げます（6の倍数のまま）。チップスは0のまま。食器用洗剤は安定して売れるので18のまま。

このレビューと微修正の工程こそが草案が自動発注より有用な理由です。

仕入先別にグループ化したクリーンな草案リスト

仕入先A

• スパークリングウォーター12パック：18パック（24から調整）\n- ポテトチップス：0

仕入先B

• 食器用洗剤500ml：18本

SKUが30個なら、この週次ループは約10分で済みます：カウント、提案レビュー、数箇所の編集、仕入先ごとに草案を共有。

次のステップ：小さく始めてルールを改善する

最速で価値を得るには狭く始めてください。1店舗（または1ロケーション）と、管理しやすいSKU群の仕入先グループを選びます。きれいにレビューされた草案から学ぶことは、初日からすべてのエッジケースを網羅するよりはるかに多いです。

オンハンドの取り方を早めに決めてください。手入力は最初は問題ありませんが、一貫性があることが重要です。「注文前の木曜に必ずカウント更新する」といった単純なルールが複雑な設定よりも効果的です。

実行プラン例：

• まずは数えやすく売上に影響する20～50SKUで始める\n- 草案リストを2～3サイクルはマネージャーとレビューしてから発注に使う\n- SKUごとに短いメモ欄を保つ（例：「季節商品」や「ケースパックは12」）\n- 最初のグループが安定したら次の仕入先へ拡大

基本が機能したら、ルールはゆっくり改善してください。すぐに効果が出るアップグレードが2つあります：平均需要の推定（例：直近4週間の平均週次販売）とリードタイムに基づく安全在庫の追加。仕入先の納期が10日なら、再発注点を一週間分の需要で引き上げると遅延に対応しやすくなります。

ルールを健全に保つための頻度も決めてください。週次で草案を見て明らかなミスを修正し、月次でMin/Maxをチューニングします。上位商品と過剰在庫リスクが高い商品に重点を置いてください。

もしノーコードでこれを作るなら、AppMaster (appmaster.io) はワークフローに合う選択肢です：SKUと仕入先をデータベースでモデル化し、Min/Maxロジックをビジュアルプロセスに入れて、スタッフがレビュー・承認できる発注草案を生成します。