メニュー・エンジニアリングが店舗運営を最適化する
国内外流通トピックス
POSでメニューがデジタルデータ化され、販売・原価・在庫をリアルタイムで把握できるようになったことで、メニューはもはや「紙の一覧表」ではなく、POSデータを多角的に分析し店舗経営を最適化するオペレーティングシステム（以下、OS）の中核機能になりつつあります。
その代表的な考え方が、メニュー・エンジニアリングです。
従来のメニュー・エンジニアリングとは
メニュー・エンジニアリングとは、メニューの中で最も利益を生み出す商品を特定し、その価値を適切に伝えることで、顧客が「選ぶべき商品」を自然に選択するよう導き、収益性を最大化する手法です。
単なる人気商品の把握ではなく、利益構造に基づいて販売戦略を組み立てる点に特徴があります。
この考え方を視覚化するために、従来のメニュー・エンジニアリングでは、メニューを「スター（看板商品）」「プラウホース（農耕馬）」「パズル（問題児）」「ドッグ（負け犬）」の4象限に分類する手法が広く使われてきました。
これは、縦軸に顧客支持度（売れた数量の割合）、横軸に利益貢献度（売価－原価）を置き、各商品の位置づけを可視化するものです。
メニューの強み・弱みを直感的に把握できる点で、現在でも有効な分析手法といえます。
しかし、現代のメニュー・エンジニアリングは次の段階に進んでいます。メニューがデジタル化し、原価・在庫・需要がリアルタイムで把握できるようになったことで、「売れた数」と「粗利（利益）」だけではメニューの実力を十分に捉えきれなくなりました。
図表が示すように、顧客支持度にはチャネル別売上や時間帯別売上、在庫切れによる機会損失など、需要の質を示すデータが必要になります。
また、利益性を判断するためには、原価変動・廃棄ロス・工程負荷といったリアルタイムのデータが欠かせません。
現代のメニュー・エンジニアリングでは、これらのデータを統合するメニューOSの構造が不可欠です。
＜図表＞ メニュー・エンジニアリングに必要なデータ
| 項目 | 縦軸（顧客支持度） | 横軸（利益貢献度） |
|---|---|---|
| 求め方 | 売れた数量の割合 | 売価－原価 |
| 必要なデータの性質 | 需要の質を示すデータ | 原価と工程の質を示すデータ |
| データの具体例 | チャネル別売上（店内／テイクアウト／デリバリー） | 材料の仕入れ価格 |
| 時間帯別売上 | 歩留まり（可食部率） | |
| 在庫切れによる販売機会損失 | レシピ使用量（1食あたりの使用量） | |
| 天候・イベントによる需要変動 | 廃棄ロス | |
| ― | 調理工程のコスト（時間・人件費・設備占有）※準原価 |
原価の計算方法
グリルチキンというメニューの原価を考えてみましょう。メインのチキンにポテト、ブロッコリー、ニンジンを添えた一般的な一皿です。
チキンは部位によって仕入れ価格や歩留まり（ぶどまり）が大きく変わり、下処理や加熱工程の負荷も原価に影響します。
ポテトはカットサイズや調理方法によって歩留まりと工程コストが変動し、ブロッコリーやニンジンのような生鮮野菜は可食部率や廃棄ロスが日々変わります。
このように、グリルチキンという1つのメニューであっても、仕入れ価格・歩留まり・使用量・廃棄ロス・工程負荷といった複数の要素が、常に変動しています。
つまり、一皿の原価は単一の固定値ではなく、複数のデータがリアルタイムに変動する「動的な原価構造」として捉える必要があります。
かつて原価を出すときには、スタッフが紙の納品書を確認し、管理ソフトに手入力して更新し、在庫更新は「閉店後にまとめて」行っていました。
そのため、原価更新は「日次バッチ処理」であり、「日次更新」という言い方が一般的でした。
日次ならまだ進んでいるほうで、週次や月次という店舗も珍しくなかったのです。
原価は「動くデータ」である
米国のハンバーガーチェーンのような現代の飲食DXでは、仕入れ・在庫・POSがクラウド上で自動連携し、次のような処理をリアルタイムで行っています。
- 仕入れ先から電子伝票がクラウドに送信される
- 仕入れ管理システムがデータを取り込み、在庫管理と同期する
- 在庫管理システムが最新の仕入れ価格を基に原価を即座に更新する
- POSと在庫が連動し、レシピ原価が自動で再計算される
- AIが販売データを学習し、需要予測を自動生成する（AI需要予測）
- AIが需要予測と原価変動を基に、メニューごとの粗利を自動評価する
- AIが在庫の減り方と需要予測を組み合わせ、必要な在庫量を算出する（AI在庫管理）
- AIが最適な発注量を自動で提案し、必要に応じて自動発注する（AI発注）
- 廃棄ロスや工程負荷のデータが蓄積され、次回の原価計算と需要予測にフィードバックされる
このような1～9の前提が整って初めて、メニュー・エンジニアリングは正確に機能します。
原価が古い、需要データが偏っている、在庫切れが反映されていない、工程負荷が考慮されていないといった状態では、4象限の分類そのものがズレてしまいます。
日本の飲食店でも、AI需要予測・AI発注・AI在庫管理を導入する店舗が増えており、5～9の領域は自動化が進んでいます。
しかし、1～4に該当する「仕入れ・在庫・原価・レシピ原価」のリアルタイム連携は、まだ十分に整っていません。
特に工程負荷については、米国ではカメラと重量センサーを組み合わせ、仕込み時間・作業手順・使用量・ロス量を自動で計測する仕組みが一般化しつつあります。
こうした基盤が整わないままでは、メニュー・エンジニアリングは静的な分析にとどまり、OSとしての精度を発揮できません。リアルタイムで経営判断を支えるOSへと進化していく必要があります。
メニュー・エンジニアリングの先にあるもの
原価・販売・在庫・発注がリアルタイムで循環する「メニューOS」が実現すれば、次の領域に進むことができます。
- メニュー最適化（Menu Optimization）
どのメニューを強化・縮小すべきかをAIが自動提案する - 価格最適化（Price Optimization）
需要の弾力性・原価変動・競合状況を踏まえた最適価格を算出する - 多店舗最適化（Location Optimization）
店舗ごとの需要特性や原価差を踏まえ、メニュー構成や価格を店舗別に最適化する
これらの最適化は、メニューOSが成立すれば、統合的に機能するようになります。
メニュー・エンジニアリングは、POSなどによってさまざまなデータを取得できるようになり、従来のようにお客様の支持と店への貢献利益のバランスが一目でわかることは勿論、さまざまな角度から分析が可能になり、メニュー戦略など飲食店の経営に欠かせない経営管理ツールとなることでしょう。
（文）経済ジャーナリスト 嶋津典代
発行・編集文責：株式会社アール・アイ・シー
代表取締役 毛利英昭
- 当記事は2026年3月時点のものです。
時間の経過などによって内容が異なる場合があります。あらかじめご了承ください。
