ホテルの予約データと過去の喫食の実績から翌日の朝食の人数を見込み、食材の発注量と仕込みの量の案を調理の担当に届ける

処理の起点を決める

時間主導型のトリガーを、毎日14時台に1つ置きます。 動いたら決まったフォルダを見て、翌日の日付の名前のCSVがあれば処理を始めます。無ければ10分後に置き直したトリガーで見直し、15時半を過ぎても無ければ、フロントと調理の責任者に「予約データがまだありません」と知らせます。 仕入先の発注の締切が17時なので、16時には案が届いている必要があります。

処理は館ごとに区切ります。 1館分の集計・見込み・読み取り・計算・文面までを1まとまりにし、どの館まで終わったかをスクリプト プロパティに残します。

20時にもう1つトリガーを置きます。 フロントが夜の予約データを書き出していれば読み直し、中央の人数が15時の案から1割以上動いた館だけ、調理の責任者と夜勤の調理の担当に知らせます。翌朝の納品の追加は間に合わないことが多いので、知らせるのは仕込みの量の直しと、当日の朝に調理で吸収できる品目の量です。

入力データを集める

AIに渡すのは、団体の手配書の朝食の欄と、朝食に関わる語を含む予約の備考だけです。 氏名・電話番号・メールアドレスはCSVの段階で書き出しの項目から外します。予約番号も、スクリプトの中で通し番号に置き換えてから渡します。

質を決めるのは、喫食の記録と過去の朝食付きの人数が同じ日で並んでいることです。 喫食率は「その日に朝食会場に来た人数」を「その日の朝の朝食付きの人数」で割って出します。どちらかが欠けた日は、計算から外します。

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

予約データは、決まったフォルダから翌日の日付の名前のファイルを探して読みます。読み込んだ直後に館ごとの予約の件数と人数の合計を数え、ログに残します。 予約システムの画面の数字と照らせるようにするためです。

団体の喫食率は、過去の値を使いません。 団体は朝食の時間と形が手配書で決まっているので、手配書の人数をそのまま見込みに入れます。 喫食率を掛けるのは個人・ビジネス・海外の旅行会社の予約だけです。

Gemini API の鍵はスクリプト プロパティに置き、UrlFetchApp で呼びます。 muteHttpExceptions を true にして、失敗の状態コードでも応答を受け取り、送り直すかを決めます。

AIへ渡す前に整形する

1. 朝食付きの人数の集計 … 館・客層ごとに、朝食付きのプランの大人と子どもの人数を数えます。未就学の子どもは別に数え、品目の量の計算で係数を変えます
2. 喫食率の計算 … 直近8週の同じ曜日について、客層ごとに「来た人数÷朝食付きの人数」を出します。祝日と大型連休は、曜日ではなく「休日」の区分で並べます
3. 幅の計算 … 8つの喫食率のうち、低いほうから2番目を下限、中央の2つの平均を中央、高いほうから2番目を上限とします。記録が5日に満たない区分は、館の全体の値を使い、その旨を印にします
4. 備考の絞り込み … 備考に「朝食」「朝ごはん」「弁当」「アレルギー」「breakfast」などの語を含む予約だけを選びます
5. 伏せる処理 … 備考の中の氏名・電話番号を伏せます
6. 品目の量の計算 … 前日に仕込む品目と当日の追加ができない品目は上限の人数で、当日に追加で作れる品目は中央の人数で、1人あたりの使用量を掛けます
7. 発注量の計算 … 品目ごとの量から在庫を引き、発注の単位に切り上げます

3番目で幅を出すのは、1つの数字だと外れたときに次の手が無いからです。 下限と上限の差が大きい日は、当日の朝に追加で作れる品目を厚めに用意し、前日に仕込む品目は上限に寄せる、という使い分けが責任者にできます。

6番目の使い分けが、廃棄と欠品の両方に効きます。 焼き魚の切り身やサラダの下ごしらえは当日に増やせないので上限で、卵料理やトーストは会場の様子を見て作れるので中央で量を決めます。どの品目をどちらにするかは、品目の設定のシートで責任者が決めます。

AIに処理させる

させるのは2つです。 1つ目は、団体の手配書と予約の備考から、朝食の人数に関わる変更を決まった区分で読み取ること。2つ目は、スクリプトが計算した人数の幅と品目の量について、調理の担当向けに根拠と確かめる点を書くことです。

allergy は人数の調整ではなく、調理の担当への知らせとして扱います。 見込みの人数は変えず、案の文面に「卵アレルギー2名（302号室の予約）」のように並べます。アレルギーの対応の可否を判断させることはしません。

いちばん起きやすい失敗は2行目です。 「週末は観光客が多いため、朝食の利用が増えると考えられます」のような一般論で、AIは案の文面を埋めたがります。喫食率は過去の実績からすでに出ているので、一般論を足すと二重に数えることになります。

指示内容を固定する

1つ目の指示（朝食の変更の読み取り）は次のとおりです。

あなたはホテルの料飲部で、翌朝の朝食の準備のために予約の書き込みを整理する立場です。
団体の手配書の朝食の欄と、個人の予約の備考を読み、朝食に関わる変更を次の区分で答えてください。

【区分】
- no_breakfast .. 朝食付きのプランだが朝食を取らない
- boxed ......... 会場ではなく弁当に替える
- time_change ... 会場の開始（6:30）より早い、または終了（9:30）より遅い時刻の希望
- allergy ....... 食物アレルギーの申し出
- add_breakfast . 朝食なしのプランから朝食を足す
- unclear ....... 朝食に関わるが、上のどれか決められない

【厳守事項】
- 書かれていることだけを根拠にしてください。人数や時刻を推測で補わないでください。
- 人数が書かれていなければ persons を null にしてください。
- 1つの書き込みに複数の変更があれば、別々の行に分けてください。
- 宿泊日が翌日でない変更（2日目、最終日など）は、翌朝に当てはまるかを applies_tomorrow で答えてください。分からなければ null です。
- evidence には、区分を決めた語句を原文からそのまま写してください。
- アレルギーへの対応ができるかどうかを書かないでください。
- 入力の row_id をそのまま返してください。

【翌日の日付】{date}
【団体の手配書の朝食の欄（row_id、団体の人数、宿泊日、記載）】{group_rows}
【個人の予約の備考（row_id、人数、プラン、記載）】{remark_rows}

2つ目の指示（案の文面）は次のとおりです。

あなたはホテルの料飲部で、調理の責任者に翌朝の朝食の見込みを伝える文面を書く立場です。
人数と量は、すでに決まった式で計算されています。
来場の人数は「朝食付きの人数 × 直近8週の同じ曜日・同じ客層の喫食率」の下限・中央・上限です。

【書くこと】
1. 来場の人数の下限・中央・上限と、客層ごとの内訳（渡した数字をそのまま）
2. 団体の朝食の形（会場・弁当）と人数、弁当の時刻
3. アレルギーの申し出の一覧
4. 上限と下限の差が大きい客層と、その日の量の決め方で確かめる点（質問の形で）
5. unclear の書き込みの原文

【厳守事項】
- 数字は入力の値をそのまま書いてください。丸めたり計算し直したりしないでください。
- 入力に無い事情（天気、行事、季節の傾向、客の国籍）を理由として書かないでください。
- 発注を決めつけず、「案は○○です。いかがでしょうか」の形にしてください。

【館と翌日の日付】{hotel} {date}
【人数の幅と内訳】{forecast}
【読み取った変更】{changes}
【品目ごとの量の案】{items}

2つ目の指示の冒頭に式を書いておくのが要点です。 式を知らないと、AIは人数を「AIの予測」と言い換えます。式を渡せば、責任者が自分の記憶と照らせる言い方で書きます。

出力形式を固定する

朝食の変更は次の形で受け取ります。 type は6つの区分を enum で列挙し、persons には minimum を0で付けます。

{
  "changes": [
    { "row_id": "G-03", "type": "boxed", "persons": 42,
      "time": "06:00", "applies_tomorrow": true,
      "evidence": "2日目朝食　6:00 お弁当にて（42名）" },
    { "row_id": "R-118", "type": "allergy", "persons": 1,
      "time": null, "applies_tomorrow": true,
      "evidence": "子ども1名 卵アレルギー" }
  ]
}

1つ目の理由は、row_id と persons を予約データと照らせることです。 persons が、その予約や団体の人数を超えていれば、その行は使わず unclear に回します。読み取った人数で、予約の人数より多く減らすことはさせません。

2つ目は、applies_tomorrow で日付の取り違えを止められることです。 3泊の団体の「2日目は朝食なし」を、翌朝の分と取り違えると、40名分の朝食が丸ごと消えます。null のものは人数に反映せず、案の文面の確かめる点に回します。

3つ目は、evidence を原文と照らせることです。 スクリプトは evidence の文字列が渡した原文に含まれているかを確かめ、含まれていなければその行を使いません。

案の一覧のシートには、館と翌日の日付ごとに次の列を並べます。

システムへ連携する

仕入先への発注は、今までどおり責任者が出します。 案の発注量をそのまま送る仕組みにすると、在庫のシートの書き忘れがそのまま過剰な発注になります。宿泊予約システムにも書き込みません。

人が確認する

1. unclear と applies_tomorrow が null のものを先に見る … 団体の手配書なら営業に、個人の予約ならフロントに確かめます
2. アレルギーの一覧を調理の担当に渡す … 対応の可否は調理の担当が決めます
3. 人数の幅を見る … 翌日の地元の行事や会場の事情と照らし、中央と上限のどちらに寄せるかを決めます
4. 品目の量を直して発注する … 在庫のシートが今日の夕方の値かを確かめてから発注します
5. 決めた量をシートに書く … 案と違う量にした品目は、理由を1行書きます

5番目を省かないでください。 責任者が案から量を変えた理由が、翌月に喫食率の決め方を見直す材料になります。理由の無い直しは、次の日の案に生かせません。

目標は、90件をならして1件8分です。 案を読み、確かめる点を片づけ、発注するまでの時間です。

例外に対処する

6行目で、AIが使えなくても案は届きます。 人数の幅と品目の量はスクリプトの式で出るので、変更の読み取りが無い分を「手配書と備考は未確認」と書いて送ります。 発注の締切に間に合うことを優先します。

記録を残す

• 処理した日、読み込んだCSVのファイル名と館ごとの件数・人数
• 客層ごとの喫食率の幅と、そのとき使った幅の決め方
• 読み取った変更（row_id、type、persons、evidence）
• 品目ごとの量の案と、責任者が決めた量と理由
• 翌朝の実際の来場の人数と、下限・中央・上限のどこに入ったか
• 品目ごとの廃棄と欠品の記録

最後の2行を並べて残すのが、この構成を育てる材料です。 実際の人数が上限を超えた日が続く客層は、幅の決め方が低すぎます。下限を下回る日が続くなら、朝食付きのプランの売り方が変わった可能性があります。 販売の担当に、プランの構成を変えていないかを聞きます。

幅の決め方を変えたら、変えた日を記録します。 「高いほうから2番目」を「最大」に変えると、同じ記録から違う上限が出ます。どの日がどの決め方だったかが残っていないと、廃棄や欠品の増減の理由が追えません。