需要予測

料理人は毎朝、同じ問いに答えます。何をどれだけ仕込むか。仕入れ担当者は隣の問いに。何をどれだけ発注するか。ふつうは二人とも記憶で答えます。

管理パネル → 在庫 → 「予測」タブ（admin.cenaly.com/inventory）を開きます。このタブは販売履歴を取り、三つの具体的な成果物に変えます。画面上の並びは緊急度順です。上にあるのはその日のうちに切れるリスクがあるもの、下が仕込み計画、さらに下が仕入れ先への発注ドラフトです。リスクのあるアイテムがなければ、一番上のブロックはまったく表示されません。一番下には折りたたまれた参考情報として「料理別予測」の表があります。数字を確認したくなったときだけ見れば十分です。

予測の計算方法#

統計はちょうど二つで、どちらも料理人に口頭で説明できます。

1. この料理がこの曜日にふつうどれだけ売れるか。 履歴のウィンドウは8週間（56日）です。点推定は中央値で、平均ではありません。8回の火曜日のうち1回が40人の誕生日会だった場合、平均なら毎週「40人分仕込め」と言うことになりますが、中央値はその火曜日を無視します。参考表「料理別予測」では、数字の隣に観測値のばらつき（最小–最大）、標本にいくつの観測値があるか、そしてピーク（販売の割合が最も大きい時間帯）が表示されます。タブのヘッダーには計算の根拠が書かれています。「56日間の同じ曜日の中央値 · 履歴の営業日数 N日」。
2. この需要が一日のなかでどう分布するか — 時間帯ごとの割合です。朝（6–11）、昼（11–16）、夕方（16–23）、夜（23–6）。境界はすべての店舗で同じで、プロファイル自体は火曜日ごとではなく、履歴の全日からまとめて計算されます。

何を観測値とするかも意識的に決められています。キャンセルされた注文は履歴に入りません。今日のまだ締まっていない日は標本に入りません。料理の初回販売より前の日はゼロとして数えられません（新メニューがまだメニューになかった週について「販売ゼロ」を受け取ることはありません）。「販売のない日」と「店舗が閉まっていた日」は区別されます。一日は店舗のタイムゾーンで数えます。計算には店舗の売上上位500アイテムが使われ、メニューの長い裾は切り捨てられます。

同じ曜日の観測値が3つ未満なら、数字は出ません。 表では数字の代わりにダッシュが入り、観測値の列には「少」の印が付きます。そのような料理は仕込み計画にも仕入れにもまったく入りません。信じられない予測は、予測がないより悪いのです。それに従って仕込み、仕入れをするからです。

上部の切り替えで、予測をどの日に立てるかを選べます — 今日か明日です。

仕込み計画#

料理別の予測はレシピ原価表を通じて、商品と半製品の必要量に展開されます。展開は現在のレシピ原価表に基づき、タブを開いた時点のものです。シェフが朝にレシピを変えたなら、計画はそれを反映します（隣のウィンドウで行った修正は、ページを更新すると取り込まれます）。

入れ子になった半製品は深くまで展開されます。ソースをブイヨンから作っていて、そのブイヨンも半製品なら、計画には両方が入ります。そうでなければ、ブイヨンがないことを伝えずにソースを作れと料理人に命じることになります。入れ子の深さは5レベルに制限されています（また、互いを循環参照するレシピからも保護されています）。それより深いものはすべて原材料とみなされ、仕込み計画ではなく仕入れに回ります。

計画の表:

期限は「シフトの始まり」ではありません。 ソースが朝には足りても昼に足りないなら、料理人は6:00ではなく11:00に間に合わせる必要があります。時刻は最も近い時間帯の境界（6:00、11:00、16:00、23:00）に丸められ、入れ子になった半製品には期限がまったくありません。そこにはダッシュが入ります。それらは、それから作るものの「前に」煮るものだからです。行は期限順に並びます。締め切りが早いほどリストの上に来ます。仕込むものがなければ、タブはそのまま表示します。残数は予測に足ります。

半製品の残数は一度だけ消費されます。同じブイヨンがソースにもスープにも入る場合、素朴な計算では残数を二度適用してしまい、仕入れが原材料を過少に見積もってしまいます。

**「シフトボードへ」**ボタンは計画をタスクのチェックリストに変えます — シフトのタスクボードを参照。共通タスク「仕込み計画 — <日付>」が一つ作成され、各仕込みがそのサブタスクになり、数量と時刻がタイトルにそのまま入ります（「デミグラスソース — 11:00までに16個」）。共通タスクはすべてのサブタスクが閉じられて初めて閉じられます。もう一度押しても重複は生まれません。その日付の計画がすでにボードにある場合、ボタンはそのように表示します。

レシピ原価表のない料理は計画に入らず、別の警告として列挙されます（最大20件）。それらについては予測は何も言えず、発注が完全であるふりをするより、声に出して言うほうがよいのです。

発注先への発注明細ドラフト#

計画の下に、選択した補充期間（「補充期間（日）」フィールド：通常は納品期間に余裕分を加えたもの。既定値は3日、1〜30日の範囲で指定可能）の仕入れドラフトがあります。

各商品について2つの値が計算され、大きい方が採用されます。

• 期間内の予測需要から現在の在庫を差し引いたもの；
• 目標在庫までの補充（商品に目標在庫が設定されていない場合は発注点まで）— 通常の在庫管理ロジックです。

なぜ一方ではなく大きい方なのか：安全在庫は明日の金曜日に来客が倍になることを知りません。また予測は、レシピ（テクニカルカード）に一切関与しない商品（梱包材、消耗品）を知りません — それらにとって在庫基準が唯一の指標です。2番目のルールでリストに入った行には「発注点による」と表示されます。注意：このルールは目標在庫を見るため、発注点より上でも目標在庫より下の商品もドラフトに入ります — 「発注が必要」タブではそのような商品はまだ表示されません。

予測によって仕入れるのは最終原材料のみです：半製品は予測による発注先への発注には含まれません（それらは仕込み計画によって生産されます）— 在庫基準によってのみドラフトに入る可能性があります。

数量は、商品に梱包単位の倍数が設定されている場合、その倍数に切り上げられます。行は発注先ごとにグループ化され（発注先が割り当てられていない商品は別グループ）、ボタンは発注先ごとに個別の発注を作成します — 以降は在庫セクションの通常の仕入れです。

「19:00までに売り切れる」#

タブの最上部のブロックは本日中に在庫が尽きるリスク、つまり今まさに危ないものです。現在の在庫を、時間帯プロファイルから算出した残り時間の予想消費量と比較し、在庫がゼロになる時刻を示します。時刻を特定できない場合、その行は正直に「本日中に不足します」と表示し、でっち上げの時刻は出しません。

このブロックは今日についてのみ計算されます：「明日」に切り替えると消えます — 明日に「19:00までに売り切れる」リスクは存在しません。

今日のペースによる補正：昼までに通常より多く消費している場合、残り時間の予想が比例して引き上げられ、行に「今日のペース ×1.4」のような表示が出ます。ペースは実際の売上から計算され（廃棄、損耗、従業員の食事は含まれません）、最もリスクの高い十数行について測定されます — 残りは通常のプロファイルで計算されます。係数は×0.5…×2の範囲に収められています — 「今日は混んでいる」という補正は必要ですが、1件の会計からの予測は不要です。ペースを測定する材料が全くない場合、タブは曜日の通常プロファイルを採用したと正直に表示します。

予測が表示されるために必要なもの#

履歴の集計はサーバーで約30分ごとに再計算されます（現在稼働中のアカウントのみ）。レシピの展開と在庫の差し引きは、タブを開いた時点の現在のデータで計算されます。

関連セクション#

• 在庫 — レシピ、在庫、入荷、仕入れ
• シフトのタスクボード — 仕込み計画の行き先
• メニューエンジニアリング — 需要と利益率の両方が見えるとき、料理をどうするか
• 分析 — 料理と期間ごとの売上

よくある質問#

なぜ半分の料理に「少ない」と表示されるのですか？#

これらの料理について、その曜日の履歴に3件未満の販売しかないためです — 例えば、2週間前にメニューに登場した料理などです。観測数が十分になれば数字は自然に表示されます。それまでは、その料理は仕込み計画にも仕入れにも参加しません。

なぜ平均ではなく中央値が使われるのですか？#

中央値は外れ値に強いからです。40人の宴会が1回あると平均がずれ、店舗が何週間も余分に仕込むことになります。インターフェースに平均は一切表示されません — 中央値、ばらつき、観測数のみです。

予測は天気、祝日、サッカーを考慮しますか？#

いいえ。曜日と時間帯しか知りません。祝日の週や近隣での試合は、依然として店長が頭の中で考慮します — それは、考慮したふりをするモデルよりも誠実です。

1週間先の予測を立てることはできますか？#

タブは今日と明日を表示します。仕入れでは期間は別途「補充期間（日）」フィールドで指定します：1日の予測にその値を掛けます。

仕入れドラフトはすぐに発注先へ発注を送信しますか？#

いいえ。これはまさにドラフトです：不要な行はチェックを外して削除し、その後に作成を押します — 「在庫」セクションの通常の仕入れドラフトが発注先ごとに1つずつ生成されます。数量は作成された発注内で、通常と同じ場所で修正できます。