第4回　飲食店の発注はAIで変わる｜AI需要予測を現場で使う―Excelで発注管理システムを作る

前回の記事では、飲食店の発注業務において最も難しいのは「需要予測そのもの」ではなく、むしろその先にある発注管理の設計である、という話をしました。売上や来客数をAIがどれほど正確に予測できたとしても、それだけでは「明日、鶏肉を何キロ発注すればよいのか」という問いには答えられません。

商品ごとの販売数がわかったとして、その商品にはどの食材がどれだけ使われるのか、今の在庫はどれくらいあるのか、すでに発注済みの入荷予定はあるのか、安全在庫はどの程度持つべきなのか――こうした複数の要素をつなげて、はじめて「何をどれだけ発注するか」が決まります。

今回は、その考え方をExcelだけで実装したシンプルな発注管理システムとして形にしてみました。大規模チェーン向けの高度なシステムではありません。個人経営の飲食店や小規模チェーンでも理解できる、最小限の発注管理の仕組みです。DXというと大がかりなシステム導入を想像しがちですが、現場で実際に役立つのは、まず「頭の中でやっていた判断を、表として見えるようにすること」です。今回のExcelはまさにその最初の一歩を形にしたものであり、特別な知識やプログラミングスキルがなくても使える構成を意識して設計しています。

このシリーズをお読みいただいている方の中には、「うちはまだAIを導入する段階ではない」と感じている方もいらっしゃるかもしれません。しかし今回お伝えしたいのは、AIの導入そのものよりも、AIを受け入れるための業務の「型」を先に作っておくことの大切さです。発注管理の流れが整理されていれば、将来AIを導入するときにも、そうでなくても、業務の質は確実に上がります。

発注管理の全体構造――「当たり前」を表にする意味

今回作ったシステムは、次のような流れで発注量を計算します。AI需要予測の結果から商品別の販売数を受け取り、レシピマスタを通して食材消費量を算出し、在庫と突き合わせて発注量を決定する、というものです。

言葉にすると当たり前のようですが、実務ではこの流れが明確に整理されていないことが多いものです。現場では店長や料理長が経験的に、「明日は牛丼が30杯くらい出そうだ」「大盛は15杯くらいかな」「そうすると牛肉はどれくらい必要だろう」「白米は在庫で足りるかな」といった判断を頭の中で組み立てています。この暗黙の計算プロセスは、経験豊富な担当者がいる限りは問題なく回りますが、属人的であるがゆえに引き継ぎが難しく、体調不良や休暇のときにカバーしにくいという課題を抱えています。

今回やったのは、その頭の中の計算をExcelの表として可視化しただけです。しかし、この「見える化」がDXの最初の一歩になります。誰がやっても同じ手順で発注量を計算できる状態を作ることが、業務改善の出発点だからです。

Excelファイルの構成はできるだけシンプルにしました。使っているシートは「設定」「商品マスタ」「レシピマスタ」「売上予測」「在庫発注」の5つだけです。それぞれの役割を見ていきましょう。

「設定」シートでは、発注計算の前提条件を管理します。発注対象日、納品日、リードタイム日数、安全在庫日数、既定発注ロットといった項目が並んでおり、発注計算全体の基準となるパラメータをここで一元管理します。発注管理で特に大切なのは「どの日の需要を見ているのか」を明確にすることですが、その基準日もこのシートで設定します。今回のシステムでは納品日を基準に発注量を計算する設計にしており、「この日に届く食材はどれくらい必要か」という視点で発注量を決めます。

「商品マスタ」は、販売するメニューの一覧です。牛丼（並）、牛丼（大盛）、豚汁、サラダ、卵かけご飯といった商品について、商品コード、商品名、カテゴリ、売価などを管理し、発注計算の起点となる「売れるもの」を定義します。

「レシピマスタ」は、このシステムの中心にあるシートです。ここでは「商品1つに対して、どの食材をどれだけ使うか」を定義します。例えば牛丼（並）なら牛肉、白米、玉ねぎといった食材が使われますが、商品1つにつき1行ではなく、「商品×食材」の組み合わせで1行持つ構造にしています。牛丼（並）×牛肉、牛丼（並）×白米、牛丼（並）×玉ねぎ、というように分けることで、商品販売数から食材消費量への変換が数式で簡単に行えるようになります。さらに実務に近づけるために歩留まり係数も入れています。玉ねぎなら皮むきロス、レタスなら外葉ロスなど、調理で使えない部分を考慮した発注ができるようになります。

「売上予測」シートには、商品別の販売数予測を入力します。例えば牛丼（並）30杯、牛丼（大盛）15杯、豚汁40杯、サラダ20個、卵かけご飯25杯、といったデータです。この数値は人が経験で入力してもよいですし、AI需要予測の結果を貼り付けても構いません。この表が、今回のシステムとAIとの接点になります。

「在庫発注」シートが最終的な出力です。食材ごとに、現在庫、入荷予定、予測消費量、安全在庫、必要在庫量、発注必要量、発注量を表示し、「実際に何をどれだけ発注するか」を判断するための表になっています。

計算ロジック――シンプルな数式で発注量を導く

今回のシステムでは、計算をできるだけシンプルにしています。現場で使ってもらうには、ブラックボックスにしないことが大切だからです。

まず、商品販売数とレシピを掛け合わせて食材消費量を求めます。食材消費量は「使用量×歩留まり係数×商品販売数」で計算します。例えば牛丼（並）の牛肉使用量が120g、歩留まり係数が1.05（5%のロスを見込む）、販売予測が30杯であれば、牛肉の消費量は120g×1.05×30＝3,780gとなります。

次に、同じ食材をすべての商品について合算します。牛肉は牛丼（並）だけでなく牛丼（大盛）にも使われますから、それぞれの消費量を足し合わせて、食材ベースの総消費量を出します。

そのうえで安全在庫を加えます。安全在庫量は「消費量×安全在庫日数」で算出します。安全在庫日数を1日に設定していれば、1日分の消費量を余分に持つ計算です。急な来客増や納品遅延に備えるバッファですが、生鮮食品の場合は過剰在庫がそのまま廃棄ロスにつながるため、ここの設定は慎重に行う必要があります。

次に「必要在庫量＝消費量＋安全在庫」を計算し、現在庫と入荷予定を差し引いて「発注必要量＝必要在庫−現在庫−入荷予定」を求めます。最後に発注ロット単位で切り上げて、最終的な発注量を出します。例えば発注必要量が3.2kgで発注ロットが1kgなら、発注量は4kgになります。

この一連の計算はすべてExcelの標準関数（SUMIFS、CEILING、IFなど）で実装しています。VBAやマクロは使っていません。現場のスタッフが数式を確認できる状態にしておくことで、「なぜこの発注量になったのか」を誰でも追跡できるようにしています。

なお、この計算の流れを一度理解してしまえば、商品数や食材の種類が増えても同じロジックで対応できます。新メニューを追加するときはレシピマスタに行を追加するだけですし、仕入れ先が変わって発注ロットが変わった場合も、該当する食材の設定を書き換えるだけで済みます。シンプルな構造にしておくことの利点は、変更が必要になったときにどこを直せばよいかが明確である、という点にもあります。複雑なシステムは作るときよりも、直すときのほうが大変なものです。

発注管理で最も見落としやすいポイント

今回のExcelを作る中で、実は一番大きかった修正があります。それは「どの日の需要を見て発注しているのか」という点に関わるものです。

最初の版では、売上予測を商品コードだけで集計していました。SUMIFS関数の条件に商品コードだけを指定していたため、売上予測シートに複数日分のデータがあると、それを全部合算してしまうという問題が起きました。つまり、3月12日の納品分を計算したいのに、3月13日や3月14日の販売予測まで混ざってしまうのです。

一見すると些細なミスに思えるかもしれませんが、発注管理においてこのズレは致命的です。2日分の需要を合算して発注すれば、1日分の余剰在庫が発生します。生鮮食品であれば、それはそのまま廃棄ロスになる可能性があります。逆に、本来2日分見るべきところを1日分しか見ていなければ、翌日の営業で欠品が起きかねません。

そこで修正版では、SUMIFS関数の条件に納品日（＝設定シートで指定した日付）を加え、納品日1日分の需要だけを基準に発注量が計算されるようにしました。この修正によって、売上予測シートに何日分のデータが入っていても、計算対象となるのは指定した納品日に対応する分だけになります。

この経験から改めて感じるのは、発注管理の本質は「どの商品が売れるか」を予測することよりも先に、「いつの需要を見るのか」を明確にすることにある、ということです。日付の基準があいまいなまま精緻な需要予測を行っても、発注量の精度は上がりません。むしろ、予測が正確であればあるほど、集計期間のズレが結果に大きく影響してしまいます。

飲食店に限った話ではありませんが、発注業務の設計で最初に確認すべきは「いつからいつまでの需要をカバーする発注なのか」という時間軸の定義です。リードタイムが1日なのか2日なのか、納品は毎日あるのか隔日なのか、こうした条件によって発注の考え方は大きく変わります。今回の修正は技術的にはSUMIFS関数に条件を1つ追加しただけですが、業務設計としては最も本質的な部分に関わる変更でした。

余談ですが、この「日付の条件漏れ」は、Excelで業務システムを組むときに非常によくあるミスです。テストデータが1日分しかない段階では問題が見えず、複数日分のデータを入れた途端に計算結果がおかしくなる。データが少ないうちは正常に動いているように見えるため、発見が遅れがちです。今回のケースでは開発段階で気づきましたが、実運用に入ってから発覚すると、なぜ発注量が急に増えたのか原因がわからず、現場が混乱する可能性があります。Excelで業務の仕組みを作るときは、必ず複数日分のテストデータを入れて検証することをお勧めします。

AIはどこで使われるのか――予測と業務の役割分担

ここまで読むと、「AIはどこに出てくるのか」と思われるかもしれません。今回のExcelにはAIは直接組み込まれていません。しかしAIは、このシステムの入り口で使われます。

AIが担当するのは「商品別販売数の予測」です。POSデータ、曜日、祝日、天候、気温、給料日、周辺イベントといったデータをもとに、「明日は牛丼（並）が30杯、豚汁が40杯売れそうだ」という予測を作るのがAIの役割です。その結果を売上予測シートに入力すると、Excelが自動的に食材消費量、在庫差分、発注量を計算します。つまり「AIが予測し、Excelが発注する」という役割分担です。

この分離には実務上の大きなメリットがあります。まず、予測の精度が低い段階でも発注管理の仕組みは使えるということです。AI需要予測の導入には、データの蓄積やモデルの調整に時間がかかります。しかし発注管理のExcelは、人間が「明日は30杯くらいだろう」と入力するだけで機能します。つまり、AIの導入を待たなくても、発注業務の標準化は今日から始められるのです。

もう一つのメリットは、予測と発注の問題を切り分けて改善できることです。発注量がおかしいとき、「予測が外れたのか」「在庫の数え間違いか」「レシピの登録ミスか」といった原因の切り分けが容易になります。すべてが一体化したブラックボックスでは、どこに問題があるのかわかりません。予測と業務ロジックを分離しておくことで、改善のサイクルが回しやすくなります。

最近は「AIがすべて自動化する」という話もよく聞きますが、実際の現場では、AIが予測を出してくれても、それをどう業務に落とし込むかという設計がなければ使いものになりません。今回のExcelは、売上予測、レシピ、食材消費量、在庫、発注という流れを一つにつなげたものですが、この構造が理解できていれば、POS連携やAI需要予測の本格導入、さらには発注の自動化といった拡張も段階的に進めることができます。AI時代だからこそ、こうした業務ロジックの設計が必要になるのです。

もう少し具体的に言えば、今回のExcelのような構造を先に持っておくと、AIを試すハードルが格段に下がります。例えば、最初の1か月は人間の経験値で売上予測シートを埋め、2か月目からはAIの予測値と人間の予測値を並べて比較してみる、といった段階的な検証ができます。AIの予測精度が人間を上回ったと確認できた段階で、売上予測シートの入力をAIに切り替えればよいのです。こうした移行が滑らかにできるのは、予測と発注ロジックが分離されているからにほかなりません。

まとめ――発注管理のDXは「見える化」から始まる

今回の記事では、飲食店の発注管理をExcelで実装してみました。AIが需要予測を作り、Excelがそれを発注量に変換する。このシンプルな構造だけでも、発注業務はかなり整理されます。

ポイントを振り返ると、まず発注管理の全体構造として「予測→レシピ→消費量→在庫→発注」という流れを5つのシートで表現しました。計算ロジックはExcelの標準関数だけで組んでおり、誰でも中身を確認できます。そして最も見落としやすい落とし穴として、「どの日の需要を見て発注しているのか」という時間軸の問題を取り上げました。日付条件を正しく設定することが、発注精度に直結するという話です。AIと業務の役割分担については、予測と発注ロジックを分離しておくことで、段階的な導入と問題の切り分けが容易になるというメリットをお伝えしました。

DXというと大がかりなシステムを想像しがちですが、実際には「頭の中の判断を表にすること」から始まります。属人的な経験値を、誰でも使える仕組みに変えていく。その最小構成が、今回のExcelです。まずはこのExcelを使って1週間ほど発注業務を回してみると、日ごろ無意識にやっている判断がどれだけ複雑なものだったか、改めて実感できるはずです。そしてその実感こそが、次のステップであるAI導入や業務自動化を検討する際の、最も確かな土台になります。

次回は、このExcelをベースに、AI需要予測をどのように組み込んでいくかを具体的に見ていきます。予測モデルの入力データとして何を使うのか、予測結果をどうやってExcelに渡すのか、そのあたりの実装イメージをお伝えする予定です。