ベーカリー向け：賞味期限付き生鮮在庫トラッカー

忙しいベーカリーやカフェで賞味期限管理が壊れる理由

賞味期限管理がうまくいかないのは、たった一つの理由です：情報がチームの実際の動きと合っていないからです。付箋の上の日時、蓋に書かれたマーカー、あるいは「覚えておくよ」という約束は、最初の混雑に耐えられません。

生産が動いているとき、人は一番手に取りやすいものを選びます。トレイが冷蔵庫の奥に押しやられる、納品が早く来る、あるいは「念のため」に余分に準備されることがあります。2日後には問題が見つかります：使うべきだったものが怪しくなり、新しい在庫がすでに開封されている、という状況です。

問題は通常、サービス中の思いがけない腐敗、プレッシャー下の省力（手前にある新しい在庫が開けられる）、シフト間での回転が不一致、日付のない半分使った容器、そしてシート上では在庫があるのに冷蔵庫にはない「幽霊在庫」として現れます。

ほとんどは単純なルールで防げます：「先に使う」。平たく言えば、古い（＝先に悪くなる）ものを先に使い、より新しいものに手を付けないこと。チームによってはこれをFIFO（first in, first out）と呼びますが、生鮮品ではFEFO（first expiry, first out）に近い場合が多いです。昨日作ったクロワッサン用フィリングが明日までしか持たないなら、3日持つ今日作りの新しいバッチより先に使うべきです。

目的は複雑なソフトウェアや完璧なデータではありません。良い生鮮在庫トラッカーは、小さく繰り返せる仕組みです：バッチと賞味期限と保管場所を記録し、適切なタイミングで「次にこれを使う」という明確な合図を出すことです。

これは、同じ人が納品を受け、準備し、提供する小さなベーカリーやカフェ、ケータリングの準備チームで特に重要です。役割が重なると、トラッカーは実際のシフトの習慣に合わないと無視されます。スタッフが守れるシンプルな設定は、誰も更新しない詳細なシステムより優れています。

重要な用語：バッチ、賞味期限、そして「先に使う」ルール

トラッカーは、全員が同じ言葉を同じ意味で使って初めて機能します。そうでないと、ある人は「milk」と記録し、別の人は「milk 2L」と記録してしまい、アラートの意味がぶれます。

多くのチームが必要とする基本は次の通りです：

• Item（品目）：在庫して使うもの（牛乳、クロワッサン生地、ローストチキン、バニラカスタード）
• Batch（ロット）：特定の納品や製造のまとまり。月曜に牛乳を受け取り、水曜にも受け取ればそれは別のバッチです。
• Received date（受領日）：バッチが届いた日。
• Made date（製造日）：社内で作った日（ソースやフィリング、下処理野菜に有用）。
• Expiry date（賞味期限）：販売や使用を避けるべき日（ラベルやキッチンルールに基づく）。

数量はもう一つ重要な点があります：バッチ内に残っている量を追跡してください。カスタードが6リットルで始まり今2リットル残っているなら、トラッカーは2リットルを示すべきです。これがアラートや「先に使う」リストを有用にします。

賞味期限（Shelf life）とBest-by、Use-byの違い

**Shelf life（保存期間）**は通常の保管下でどれくらい持つかです。例えば準備したフィリングは「冷蔵で3日」といった指標があり、トラッカーでは製造日から実際の賞味期限を算出します。

**Best-by（品質保持日）**は品質の目安で、安全性とは別です。期限後も安全であることが多いですが風味や食感が落ちる可能性があります。

**Use-by（消費期限）**は安全性に関わる日です。乳製品、肉類、調理済みのものなど、どれがUse-byかを明確にして、スタッフがすべてを柔軟に扱わないようにしてください。

実務上の「先に使う」ルール：FEFO

FEFOは**first-expiry-first-out（先に賞味期限が来るものを先に使う）**という意味です。これは日常の「先に使う」ルールそのものです：取り出すときは、受領日時ではなく賞味期限が早いバッチを選びます。

バッチ管理が特に重要なのは、期限が一日違うだけで大きなロスやリスクが生じる品目です：牛乳やクリーム、カスタードやフィリング、デリミート、調理したソース、サラダミックス、夜間保存する準備済み品など。

トレース（どのバッチがどの商品に使われたかの記録）は任意ですが便利です。例えばどのカスタードバッチが火曜のペイストリーに使われたか記録する程度で、リコールや監査、再作業が頻繁なら後から追加するチームが多いです。

トラッカーが必ず捕らえるべき項目（そして省くべきもの）

スタッフが数秒でバッチを記録できることが前提です。目的はシンプル：何があるか、どこにあるか、何を先に使うべきかを知ること。

最小限の入力で「次に何を使うか」を即答できる状態にしてください。フォームが事務手続きのように感じられると、スタッフは推測したり記録を飛ばしたり、すべてを一つの大きなバッチにまとめてしまいます。

必要最低限のデータ

次の項目はすぐに効果を発揮します：

• 品目名（「Croissant dough」のように具体的に）
• バッチ／ロットID（DATE＋イニシャルのように自動生成してもよい）
• 製造日／受領日
• 賞味期限（またはベストバイ日）
• 数量と単位（6トレイ、2kg、12ポーション）

物が移動する場合は場所フィールドも追加してください（front fridge、walk-in、freezer、displayなど）。場所がなければスタッフは探し回り、トラッカーを信用しなくなります。

役に立つ追加項目（ただしそれに基づいて行動するなら）

オプション項目は意思決定に使うと有益です。もしそれが運用を変えないなら、単に記録が遅くなるだけです。よく使われる「必要な場合のみ」の追加は、仕入先（発注が仕入先別なら）、コスト（廃棄の価値を追跡するなら）、保管種別（冷蔵／冷凍／常温）、アレルゲンフラグ（ラベル管理に必要なら）、「開封」「解凍した時間」などの短いメモです。

ステータスは単純にしておきましょう：in stock（在庫）、reserved（保留）、consumed（消費済）、wasted（廃棄）、expired（期限切れ）。ほとんどのワークフローで十分で、報告も簡単になります。

調合や分割バッチには一つのルールを設けてください：子容器は親の日時を継承します。バッチが二つのタブに分かれたら、親バッチIDに紐づく二つの容器レコードを作り数量を分けます（例：0142-A、0142-B）。これでFEFOが保たれ、スタッフの再入力も不要になります。

アラートは覚えやすい単純なルールにしましょう。まずは一つの早期警告幅（例：賞味期限の2日前）と、誰が見るか（準備リード、シフトリード等）を決めます。在庫少のアラートを出すなら、まずはインパクトの大きい数品目から始めて、賞味期限アラートが機能してから拡大してください。

構築の前に決めておくとシステムが簡単に保てること

トラッカーはキッチンの動きに合うときに機能します。画面やフィールド、アラートを作る前にいくつかの小さな決定をしておくと、データの混乱や重複、無視される警告を防げます。

1）命名ルールを決める。 品目名は請求書、ラベル、トラッカーで検索しやすく一貫させます。例えば「Milk, whole, 2L」のように。バッチはサプライヤー日付＋短いコード（“2026-01-25 DAIRY”など）を採用して統一します。

2）現場に合う場所名を定義する。 場所名は短く固定し、シフト中に誰もが新しい名前を作らないようにします。チームが「front fridge」「prep line」と呼ぶなら、それを使ってください。

3）アラートルールをシンプルに。 品目ごとに細かく分けるのではなく、まずはいくつかのカテゴリで始めます。例：乳製品は2日、青果は1日、調理ソースは3日。後で調整できますが最初は簡単に。

4）誰が何を変更できるか決める。 誰でも全てを編集できるとカウントがすぐずれます。一般的な構成は：受け取りリードが在庫を追加、監督者が数量を調整、シフトリードが短い理由付きで廃棄を記録、管理者だけが品目名やルールを編集する、という形です。

5）日々の習慣を決める。 トラッカーは既にある瞬間に結びつけます：開店時（アラートを確認し「先に使う」ものを前へ移す）、準備後（新しいバッチを記録）、閉店時（廃棄を記録して短い在庫カウント）。

もしAppMasterのようなツールで作るなら、最初のバージョンは小さく保ってください：Items、Batches、Locations、賞味期限、カテゴリごとの1つのアラートルール。スタッフが使うトラッカーは、誰も更新しない完璧なトラッカーより優れています。

ステップバイステップ：生鮮在庫トラッカーの立ち上げ

チームが仕事をする順に作っていきます：品目を定義し、バッチを記録し、「次に使うもの」を分かりやすくします。

1）基本を設定する（品目とルール）

あまり頻繁に変わらない品目リストを作ります。各品目にはデフォルトの保存期間（時間または日）とアラートタイミングを持たせます。

実用的に：品目名と単位（トレイ、個、リットル）、デフォルト保存期間（マフィン2日、開封済みクリーム24時間）、単純なアラート計画（例：24時間前に警告、4時間前に再警告）。キッチンとバーなど複数チームが使う場合は所有者を記しておくとアラートの送信先が分かりやすくなります。

2）バッチが現れた瞬間に記録する

納品と社内製造のための高速な入力フローを用意してください。すべてのバッチに固有の賞味期限が必要です。

良いバッチ入力画面は次だけで十分：品目、数量、場所、そして賞味期限（保存期間から自動入力され、簡単に編集できる）。

次にスタッフが信頼する「先に使う」ビューを作ります。賞味期限の早い順に並べ、場所ごとにグループ化すると、バリスタはバー冷蔵庫の牛乳を、キッチンは今日のペイストリートレイを先に確認できます。

日々の更新は数アクションに絞ります：消費（販売・使用）で数量を引く、移動（冷蔵→ディスプレイ）、調整（カウント誤差）、廃棄（腐敗・破損）、期限切れとしてマーク（多くは自動候補）。

通知は店舗のリズムに合わせて設定します：朝のラッシュ前通知、閉店前のリマインダー、管理者向けの日次サマリなど。

導入前に実際の10バッチでテストしてください：クロワッサンのトレイ2つ（焼き時間違いで別扱い）、牛乳1箱、クリーム1タブ、ソース数種。スタッフが追加・検索・消費を質問せずにできれば、拡張の準備はできています。

AppMasterのようなノーコードツールで作る場合、まずItems、Batches、Locationsをモデル化して、「先に使う」画面とクイックアクションを主要ワークフローに追加します。

スタッフが使いやすくするための機能（マネージャー向けだけでないこと）

トラッカーはラッシュ時に使われて初めて機能します。10秒で片手で操作でき、騒がしいキッチンでも使いやすい設計にしてください。

バッチ入力を速く（サービスを遅らせない）

最大の効果は、バッチ操作をほとんど摩擦なくすることです。可能ならバーコードやQRラベルをバッチごとに付け、スタッフが入力の代わりにスキャンする仕組みを検討してください。必須ではありませんが、通常の準備作業の一部のように感じられるため行動変容に繋がります。

モバイル向けの画面も重要です。受け取り、準備、廃棄記録のためのシンプルなスマホ表示は、マネージャーのラップトップ専用のスプレッドシートより有効です。

デフォルトは現実に合わせます：今日の日付、一般的なバッチサイズ、通常の保存期間、スタッフが実際に使う場所名。もしスキャンしたアイテムにより古いバッチが残っていれば、トラッカーはそれを先に使うよう促すべきです。

店舗の電波が弱い場合はオフラインで入力して後で同期する機能があると、データの欠落を防げます。

データを守りつつ作業を滞らせない

日常作業は誰でもできるが履歴を消せないようにします。権限設定で、誰でも使用時に数量を減らせるが、賞味期限の編集やバッチ削除はリードだけができるようにします。

監査ログも信頼を作ります。誰がいつ数量を変更したか、短い理由（“こぼした”や“焼きすぎ”）を残せれば、口論は素早く解決できます。

管理者向けのビューは行動に紐づけてください：今後48–72時間で期限が近いもの、廃棄理由別の集計、メニュー変更を強いられた欠品、編集・上書きの簡潔な活動ログなどがあれば十分です。

よくあるミスと落とし穴（回避方法）

数字は「正しく見える」けれども現場で期限切れが見つかると信頼は崩れます。多くの失敗は予測可能な落とし穴から来ます。

品目は追うがバッチを追わない。 「milk」を一行で管理すると新旧が混ざり、賞味期限は推測になります。各納品や製造をバッチとして扱い、固有の数量と期限を持たせてください。

賞味期限の安易な編集。 誰でも日付を変えられるとアラートは消えるため役立ちません。編集は可能にするが理由を必須にし（ラベル不明瞭、仕入先修正、少量詰め替え等）、簡単な履歴を残してください。

作り込みすぎ。 カテゴリと項目が多すぎると更新が面倒になり、スタッフは記録をやめます。最初は日々の判断に役立つ項目だけ：品目名、バッチID、数量、単位、賞味期限、場所。

ノイズの多いアラート。 1日中通知が鳴ると無視されます。開店前、ランチ前、閉店前といった実際の瞬間に合わせ、現実的に使える品目に絞って出してください。

現場に合わない場所名。 アプリが“fridge”と表示しているのにチームは「front fridge」「back fridge」「prep line」と呼んでいると、忙しいシフトでアイテムが“消える”ことになります。人々の言葉と動きに合わせて名前を揃えてください。

単純なシナリオで重要性が分かります：カフェが月曜と木曜にほうれん草を受け取るとします。両方を同じアイテムとして記録すると木曜の新しい箱に隠れて月曜の古いバッチが使われず、スタッフはより「いっぱいある」箱を手に取ります。バッチ管理と開店時の「先に使う」アラートがあれば、月曜のバッチがフラグされてその日に使われます。

データを正確に保つための簡単なルーティン

トラッカーはデータが新鮮であることが前提です。すべてを完璧に数える必要はありません。重要なのはスタッフが続けられるルーティンです。

多くのカフェで機能するシンプルなリズム：

• 毎日（営業前）： 「先に使う」リストを確認し、3〜5品目をメニューや仕込みに組み込みます。
• 調理中（発生時）： 新しいバッチは作った・開封したその瞬間に記録します。
• 日終わり（2分）： 廃棄と期限切れをすぐに短い理由付きで記録します。
• 週次（15分）： 最も廃棄が多い品目を見直し、注文量・パー在庫・仕込みバッチサイズ・ポーションを一つ変えます。
• 月次（20分）： 高コスト品を数点抜き打ちチェックしてズレを修正します。

廃棄理由は短く保つと使われます：expired（期限切れ）、over-prepped（作りすぎ）、damaged（破損）、wrong temp（温度問題）、returned（返品）。“over-prepped”が頻発するなら、対処は通常バッチサイズを小さくすることです。

実用的なコツ：日次の「先に使う」チェックを開店チェックリストに組み込んでください。オーブンのスイッチを入れる行為と同じように習慣化されます。

ノーコードツールで作るなら、同じ瞬間を通知のトリガーにするのが効果的です：朝の「先に使う」サマリ、日終わりの廃棄プロンプト、週次の廃棄レポートなど。

事例：あるカフェでの1週間（“先に使う”アラート活用）

River Street Cafeは朝食サンド、コーヒー用の牛乳、ペイストリー、自家製ソース2種（チポトレマヨとハーブビネグレット）を販売しています。彼らはバッチ、賞味期限、「先に使う」リストをシンプルに管理しています。

月曜朝、下ごしらえの担当がチポトレマヨを新しく作り、新バッチとして記録します。バッチのエントリはこうです：

• Item: Chipotle mayo
• Made: Mon 9:10
• Expires: Thu 9:10
• Quantity: 3.0 liters
• Location: Walk-in, shelf B

ペイストリーはトレイ単位、牛乳はケース単位で同様に記録します。各バッチに賞味期限と場所があるため、スタッフはどれを取ればいいか迷いません。

水曜午後、トラッカーが「先に使う」アラートを示します：古いビネグレットが明日で切れます。奥のウォークインにあるのを誰も見ていなかったのは、新しいバッチが前に置かれていたためです。

シフトリードは二つの選択肢を持ちます。冷凍が許可されていれば小分けして冷凍しトラッカーにメモを残します。冷凍不可なら、そのバッチを使うメニュー（サラダセットやサンドのトッピング）を即座に仕込んで確実に使い切ります。重要なのは“運任せで売れるのを待つ”のではなく、意図的に使うことです。

閉店時、担当は全面的な棚卸ではなく小さな更新を行います。新しいバッチを確認し、使った分を引き（概算でも一貫して）、廃棄は発生時だけ記録します。

金曜、マネージャーは一つの画面で確認します：何が期限切れになったか、何が廃棄されたか、どの品目が「先に使う」アラートを最も多く出したか。数週間でソースの仕込み量を調整し、「新しい牛乳は古い牛乳の後ろに置く」といった明確な補充ルールを設定して、アラートは稀になり廃棄は減ります。

次の一手：ツールを選び、混乱なく展開する

チームが毎日使う最小のツールを選んでください。賞味期限管理は機能過多なプロセスのせいで失敗することが多く、機能不足が原因で失敗することは稀です。

一拠点で品目が少なく、管理者1人が運用するならスプレッドシートで十分です。複数人が受け取り・準備・廃棄をシフトごとに行うならアプリの方が合っています。FEFOルール、複数の保管場所、権限管理と監査ログが必要ならカスタムワークフローを作る価値があります。

最初のバージョンは小さく保ちましょう。ほとんどのチームが実際に使う開始セットは：

• Add Batch（品目、数量、単位、バッチ日、賞味期限、場所を追加）
• Use First（今日の「先に使う」リスト）
• Inventory by Location（prep fridge、freezer、dry storage別の在庫）
• Waste Log（何を捨てたか理由とともに）

基本が定着したら統合を追加できます。よくある次のステップはPOSから日次合計を取り込んで使用量と販売を突き合わせることや、アラートの送信先をチームが普段使う通信手段（Telegramやメール／SMS）にすることです。

カスタムアプリをノーコードで作りたい場合、AppMaster（appmaster.io）は一つの選択肢です。Items、Batches、LocationsをPostgreSQLでモデリングし、FEFOの「先に使う」ルールを業務ロジックとして組み、受け取りと廃棄記録向けのシンプルなモバイル画面を作れます。AppMasterは実際のソースコードを生成し、要件変更時にアプリを再生成できるため、学びながらフィールドやルールを調整しやすい利点があります。

導入をスムーズにするにはパイロットから始めてください。まずはある準備冷蔵庫だけで2週間トラッカーを運用します。習慣は一つだけ教育します：バッチを受け取ったら記録し、常にUse Firstから取ること。週の終わりにチームと二つの数字を確認します：見逃した期限と廃棄の記録。改善が見られれば冷凍庫、常温保管、フルメニューへと拡張してください。