原価データの更新頻度｜古い原価表は無いより危ない

この記事の要点（3点）

・原価表は作った瞬間から古くなる。仕入れ単価の変動が反映されない原価表は、誤った意思決定の根拠になる
・実務の型は「主要食材は仕入れの都度、その他は四半期ごと」の二段更新+「値上げ通知をトリガーにした臨時更新」
・更新を回す鍵は単価マスタとレシピの分離。単価を1か所直せば全レシピの原価が再計算される構造にする

※ 仕組みは表計算でも専用ツールでも実現できます。

1. 古い原価表という静かな毒

開業時に頑張って作った原価表が、2年後も同じ数字のまま。この状態は「原価を把握していない」よりたちが悪いことがあります。古い数字を根拠に「このメニューは原価率28%だから大丈夫」と判断し続けるからです。バターが3割、小麦粉が2割上がった世界では、その28%は実際には35%かもしれません。

値上げの判断が遅れる、儲からないメニューを推奨し続ける、セットの割引原資を読み違える。古い原価表は、これらの誤決定の静かな根拠になります。特に食材相場が大きく動く局面では、半年前の原価表は現実と数ポイント単位でずれていると考えるべきです。

2. 二段更新+トリガー更新の型

主要食材（仕入れ額上位10〜20品目）：仕入れの都度、または月次で単価を更新する。この少数が原価の大半を動かす
その他の食材・調味料：四半期に一度のまとめ更新で十分。変動も小さく、影響も小さい
トリガー更新：仕入先からの値上げ通知、規格変更、仕入先の切り替えがあったら、該当単価をその場で更新する。仕入先の選び方で扱った値上げ対応の一部として組み込む

「全部を毎月」は理想ですが続きません。影響の大きい少数を高頻度で、残りを低頻度で。このメリハリが持続する更新の型です。更新した日付を原価表に残しておくと、「この数字はいつ時点か」が常に分かり、古い数字を新しい判断に使う事故を防げます。

3. 単価マスタの分離という構造の工夫

更新の手間は、原価表の作り方で桁が変わります。レシピごとに単価を直書きした表は、バターの値上げのたびに全レシピを開いて直す羽目になります。正しい構造は単価マスタ（食材と単価の一覧）とレシピ（食材と使用量）の分離です。バターの単価をマスタで1回直せば、バターを使う全レシピの原価が自動で再計算される。表計算のVLOOKUP程度で実現でき、原価管理ツールはこの構造を最初から備えています。

この構造はレシピの標準化とセットで作るのが効率的です。レシピをグラムで持っていれば、マスタ分離は一歩の距離です。

4. 更新した原価で何を見直すか

単価更新は、それ自体が目的ではありません。更新のたびに次の3つを軽く見直すことで、数字が行動につながります。

原価率が閾値を超えたメニューの抽出：目標+5ポイント超えをレビュー対象にする等のルール化
値上げ・レシピ調整の判断：値上げの進め方と食材価格変動への対応の実行トリガーにする
理論原価率の再計算：差異分析の理論側を最新化し、差異の解釈を正しく保つ

よくある質問

Q. 単価は税込と税抜どちらで持つべきですか？

A. どちらでも構いませんが全食材で統一してください。軽減税率（食材8%）と経費（10%）が混ざる環境では、税抜統一が混乱を防ぎやすい選択です。

Q. 相場で毎日動く食材（魚・野菜）の単価はどう置きますか？

A. 直近1か月の平均仕入れ単価、または保守的に直近の高値を置くのが実務的です。変動の激しい食材は「原価が読める範囲の値付け」（時価枠、日替わり枠）でメニュー側に逃がす設計も有効です。

まとめ

原価データは、主要食材の高頻度更新とマスタ分離の構造で生きた状態に保てます。古い原価表で正確な判断はできません。更新を値上げ判断・差異分析・メニュー見直しのトリガーに接続し、数字が行動を生む循環を作ってください。

原価計算の基礎はレシピ原価計算の基礎をご参照ください。