新メニューの試作レシピから原価計算表とアレルゲン・栄養成分の表示の下書きを作り、根拠が足りない食材を挙げる

処理の起点を決める

共有シートでレシピの状態を「計算待ち」に変えたことを起点にします。 開発担当は試作の途中で何度もシートを書き換えるので、書き換えのたびに動かすと、書きかけのレシピで計算が走ります。 状態を変えるという1つの操作を、「この版で計算してよい」という合図にします。

試作の版ごとに、別の行として扱います。 版番号をシートに持たせ、ワークフローは「メニューコード＋版番号」で前の版を探します。前の版があれば、その対応づけを引き継ぎ、変わった食材だけをAIに渡します。

計算が終わったら、状態を「確認待ち」に変えて担当者へ通知します。状態が「計算待ち」のまま1時間を超えたものは、失敗として担当者に知らせます。

入力データを集める

質を決めるのは、いちばん下の2つです。 中間品の配合表が無ければ、「自家製デミ」を原材料に展開できず、中に入っている小麦粉やバターが表示から落ちます。 換算表が無ければ、AIは「玉ねぎ1/2個」を自分の知識で重さに直し、その数字が毎回変わります。

単価表の歩留まりは、原価のために持ちます。 玉ねぎは皮をむいて使うので、仕入の重さと使う重さが違います。レシピの量が可食部の重さなら、原価は歩留まりで割り戻して出します。 成分表の値は可食部あたりなので、栄養の計算には可食部の重さをそのまま使います。

データの取得方法を決める

単価表と成分表は、全部をAIに渡しません。 成分表は食品の数が多く、全部を渡すと入力が大きくなるうえ、似た名前の食品から根拠なく選ぶことが増えます。ワークフローの側で食材名から候補を絞り、候補の中から選ばせます。 候補に正解が無いときは、選ばずに「該当なし」と返させます。

規格書は、受け取った日が新しい版だけを渡します。 古い版のアレルゲンの欄を読むと、配合の変わった加工品を古い情報のまま表示することになります。

AIへ渡す前に整形する

1. レシピの行の確認 … 食材名・量・単位が空の行が無いかを確かめます。空の行があれば計算を止めて開発担当に戻します
2. 単位の正規化 … 「g」「グラム」「ｇ」、「cc」「ml」をそろえます。全角と半角もそろえます
3. 中間品の展開 … 中間品の配合表にある名前は、原材料の行に展開してから渡します。中間品の中の中間品も、最後まで展開します
4. 候補の絞り込み … 食材名ごとに、単価表と成分表から上位の候補を引きます
5. 前の版との差分 … 前の版と同じ食材・同じ量の行は、対応づけを引き継ぎます
6. 規格書の確認 … 加工品の品目に規格書があるか、パスワードが無いか、32MB以内かを確かめます
7. 成分表の版の確認 … 索引に正誤表が反映されているかを、取り込んだ日で確かめます

3番目を軽く見ないでください。 「自家製デミ」の中には市販のルウが、ルウの中には小麦粉と乳が入っています。1段だけ展開すると、2段目のアレルゲンが落ちます。 展開できない名前が残ったら、計算を止めて配合表の追加を頼みます。

AIに処理させる

させるのは、食材ごとに単価表の品目と成分表の食品番号を候補から選び、量を重さに直す換算を示し、その理由を書くことです。 加えて、規格書があればアレルゲンの欄を読み取り、最後に計算結果を下書きの形にまとめます。

2行目が、この構成でいちばん判断の要る対応づけです。 消費者庁の資料の例では、日本食品標準成分表の「食パン」の原料配合割合等を確認し、当該食品と類似性が高いことを確認してから値を使っています。AIには、選んだ食品番号と、なぜその状態を選んだかを必ず書かせます。

4行目では、「含まない」と「書かれていない」を分けます。 規格書の欄が「−」なのか空欄なのかで意味が変わることがあり、読み取れないものは読み取れないと返させます。

1行目がいちばん起きやすい失敗です。 成分表の食品名を渡すと、AIはそのおおよその熱量を知っていて、書けてしまいます。 書かせた瞬間、成分表の正誤表を当てた値と、AIが覚えている値の区別がつかなくなります。

指示内容を固定する

あなたは飲食チェーンの品質管理部で、新メニューの試作レシピの食材を
単価表と日本食品標準成分表に対応づける立場です。
渡した候補と換算表だけを根拠にしてください。

【食材ごとにすること】
1. price_item_code ... 単価表の候補から、食材名と規格が最も近い品目を1つ選ぶ
2. food_number ...... 成分表の候補から、食材の状態（生・ゆで・油いため等）まで
                      合わせて食品番号を1つ選ぶ
3. grams ........... 量を可食部の重さに直す。換算表の取り決めだけを使う
4. reason .......... 選んだ理由と、使った換算の行
5. status .......... ok / not_in_price_list / no_composition_match /
                      unit_unknown / spec_missing のどれか

【厳守事項】
- 候補に当てはまるものが無ければ、選ばずに該当の status にしてください。
  候補の外から品目や食品番号を作らないでください。
- 熱量・たんぱく質・脂質・炭水化物・食塩相当量の数値は書かないでください。
  数値は別の工程で成分表から引きます。
- 換算表に無い単位（「ひとかけ」「少々」など）は grams を空にし、
  unit_unknown にしてください。一般的な重さで埋めないでください。
- 調理の工程に「炒める」「ゆでる」とあれば、食品番号はその状態のものを優先し、
  無ければ理由にその旨を書いてください。
- 規格書が無い加工品は spec_missing にしてください。
  アレルゲンを含まないと推測しないでください。
- 「いつもの」「前と同じ」のような書き方は、前の版の対応づけがあれば引き継ぎ、
  無ければ not_in_price_list にしてください。

【レシピ】{recipe_rows}
【単価表の候補】{price_candidates}
【成分表の候補】{composition_candidates}
【換算表】{unit_rules}
【規格書のある品目】{spec_index}

「数値は書かないでください」を明記しないと、親切に書きます。 食品番号を選ぶついでに熱量を添えるのは、AIにとって自然な振る舞いです。禁じるのは、数値を書くことそのものです。 書かれた数値はプログラムが使わなくても、確認の画面に出ると人が信じます。

「一般的な重さで埋めない」も同じ理由です。 「バター ひとかけ」を10gと置くのは、ほとんどの場合それらしい値です。それらしいから、誰も換算表に足さないまま運用が続きます。

出力形式を固定する

対応づけは、次の形のJSONで受け取ります。

{
  "menu_code": "",
  "version": 0,
  "lines": [
    { "line_no": 0, "recipe_text": "", "price_item_code": "", "food_number": "",
      "grams": "", "reason": "",
      "status": "ok | not_in_price_list | no_composition_match | unit_unknown | spec_missing" }
  ],
  "allergens_from_specs": [
    { "price_item_code": "", "spec_version": "", "item": "",
      "mark": "contains | not_contains | not_stated | unreadable", "evidence": "" }
  ]
}

返答の形は、Claude API の構造化出力で固定します。 ドキュメントでは、output_config.format にJSONスキーマを指定すると返答がスキーマに従うとされ、enum が使えるので status と mark の値を限れます。 オブジェクトには additionalProperties: false が必要です。一方、minimum などの数値の制約は使えないので、grams は文字列で受け、数値として読めるかをプログラムで確かめます。

原価と栄養の計算はプログラムが行い、次の表にまとめます。

表示の下書きには、計算で求めた値であることを明記します。 消費者庁の資料では、表示された一定の値が許容差の範囲を超える可能性がある場合、合理的な推定により得られた値として表示することも可能とされ、その場合は「推定値」または「この表示値は、目安です。」のいずれかの文言を含む表示と、表示された値の設定の根拠資料の保管が必要とされています。下書きには「推定値」を入れ、計算表そのものを根拠資料として残します。

システムへ連携する

レシピのシートそのものは書き換えません。 結果は「計算結果」の別のシートに版ごとに書き、開発担当の書いた元のレシピには手を付けません。 元の書き方が残っていないと、対応づけの誤りを後から追えません。

メニュー表やWebの表示には書き込みません。 この構成が出すのは下書きまでで、表示に載せるのは品質管理の担当が承認したものだけです。

人が確認する

人が見るのは、ok 以外の行と、成分表の食品番号の理由です。 原価と栄養の数字そのものは、プログラムが計算しているので検算しません。

1. 根拠の足りない食材を先に見る … spec_missing と no_composition_match は、表示の前に必ず解消します。規格書の取り寄せは、試作の段階で頼みます
2. unit_unknown を換算表に足す … 「ひとかけ」を何gとするかを決め、換算表に1行足します。次の試作からは自動で換算されます
3. 食品番号の理由を読む … 状態の選び方（生か、炒めたものか）が工程と合っているかを確かめます
4. 規格書のアレルゲンを確かめる … not_stated と unreadable は、規格書を開いて目で見ます
5. 原価を開発担当に返す … 目標を超えていれば、どの食材が効いているかを計算表で示します
6. 判定を覆したら記録する … どの食材の対応づけを、何に変えたかを残します

1番目を省かないでください。 根拠の足りない食材を残したまま表示に進むと、アレルゲンの欄の空白が「含まない」として店頭に出ます。 食物アレルギーのお客様にとって、いちばん危ない誤りです。

目標は、1件24分です。 版違いでは確かめる行が数行に減るので、初回の試作に時間を使い、2回目以降は差分だけを見る形になります。

例外に対処する

上の5行で例外のほとんどを占めます。 どれもAIの問題ではなく、レシピの書き方と、配合表・換算表の整備の問題です。 試作を重ねるほど換算表と配合表が育ち、例外は減っていきます。

記録を残す

• 試作レシピの版ごとの写しと、計算を始めた日時
• AIに渡した候補と換算表、そのとき使った成分表の索引の版
• AIが返したJSONの全文と、人が直した後の対応づけ
• 計算表（原価と栄養成分）と、使った規格書の版
• 表示の下書きと、承認した担当者・日時
• 根拠の足りない食材と、解消した日

計算表と使った規格書の版を残すのは、根拠資料として保管するためです。 推定値で表示するときは、表示された値の設定の根拠資料を保管しなければならないとされています。販売を始めた後に「この熱量はどこから来たか」と聞かれたとき、答えられる形で残します。

最後の行は、仕入先との取引の材料になります。 規格書がいつも遅れる仕入先が分かれば、新しい食材を試すときに早めに頼めます。