飲食店の無断キャンセルと直前の取消を Make で拾い、事情に合わせて再来店の案内とキャンセル料の案内の文面を作り分ける

処理の起点を決める

シナリオ1は、毎朝9時に1回動かします。 予約台帳の書き出しは前日の閉店後に終わっているので、朝には前日分がそろっています。閉店直後に動かさないのは、来店の状況の付け直しが閉店後に入ることがあるからです。 遅れて来店した予約客を「無断キャンセル」から「来店」に直す作業が、片付けの後に行われます。

シナリオ2は、15分ごとに動かします。 店長が方針を選んだ行を拾って下書きにします。店長が開店前に選び終えれば、遅くとも15分後には下書きがそろいます。 シナリオ2は対応表だけを読むので、方針が選ばれていない時間帯は何もせずに終わります。

店長が方針を選ばないまま2日たった行は、シナリオ1が翌朝に印を付けます。 対応表の「経過日数」の列を毎朝更新し、2日を超えたものは本部の予約担当にもメールで知らせます。 第3章の（a）のように連絡が積み上がるのを、ここで止めます。

入力データを集める

質を決めるのは、電話のメモと店長のひとことです。 「前日夜に電話あり、子どもが発熱」と書かれていれば、方針が「規定どおり案内」でも、文面の最初に「お子さまのご体調はいかがでしょうか」が入るかどうかで受け取られ方が変わります。 店長のひとこと（「いつもありがとうございます、とだけ添えて」）は、方針を選ぶときに対応表の欄に書けるようにします。

キャンセル規定の表には、予約の時に予約客へ示した文言も持たせます。 予約サイトの画面や予約の確認メールで示した規定の文を、そのまま列に入れておきます。キャンセル料の案内の文面には、この文言をそのまま引用させます。 AIに規定を言い換えさせないためです。

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

顧客の一覧は、電話番号で引きます。 名前で引くと、漢字とカナ、旧姓、家族の名前での予約で当たりません。電話番号でも当たらない予約客は「初めての予約客」として扱い、来店の回数を0にします。 来店の回数が分からないまま常連として扱うより、初めてとして店長に見せたほうが誤りが小さく済みます。

規定上の額は、シナリオの中で計算します。 コースの予約なら「コースの単価×人数×率」、席のみの予約なら「1名あたりの額×人数」です。計算に使った単価・人数・率は、額と一緒に対応表に並べます。 店長は額だけでなく、どの数字から出したかを見て方針を選べます。

人数の変更があった予約は、変更後の人数で計算し、「人数変更あり」の印を付けます。 どの人数を基準にするかは店の決まりで、印の付いた行は店長が額を確かめてから方針を選びます。

AIへ渡す前に整形する

1. 重複の確認 … 予約番号で対応表を引き、記録があれば飛ばします
2. 来店の状況の確認 … 無断キャンセル・当日取消・前日取消のどれかを確かめます。それ以外の値は飛ばします
3. 電話のメモの切り出し … 備考の列から、スタッフが書いた電話の内容を取り出し、予約時の要望（アレルギー、記念日）と分けます
4. 規定上の額の計算 … 上の計算式で出し、計算に使った数字を並べます
5. 連絡先の確認 … メールアドレスがあるかを見ます。無ければ「電話のみ」の印を付けます
6. AIに渡す範囲を絞る … 文面に使わない電話番号・予約経路の管理番号は外します。名前と事情のメモ、来店の回数、額だけを渡します

3番目は、文面の取り違えを防ぐための準備です。 備考の欄には「誕生日のケーキあり」と「前日夜に電話あり」が同じ欄に混ざって入ります。混ぜたまま渡すと、AIが記念日に触れた請求の文面を書きます。 予約時の要望は事情のメモから外して渡します。

6番目で電話番号を外すのは、文面に要らないからです。 来店の履歴を引くのには使いますが、引いた後の情報だけを渡せば、AIの側に電話番号が残りません。

AIに処理させる

させるのは1つだけです。 店長が選んだ方針に沿って、予約客への文面（件名と本文）を書きます。方針を選ぶこと、額を決めること、規定を解釈することはさせません。

事情のメモがあるときは、方針にかかわらず最初にそれに触れさせます。 「お電話をいただいていたにもかかわらず」「お子さまのご体調は」のように、予約客が店に伝えたことが、店の中で伝わっていることを示します。 第3章の（c）のすれ違いを、文面の側でも防ぎます。

来店の回数は、言い回しの丁寧さだけに使わせます。 来店が10回を超える予約客には「いつもご来店いただき」と添えますが、回数を理由に額を変えたり、免除をほのめかしたりはさせません。 額と免除を決めるのは店長の方針です。

最後の行は、起きやすい失敗です。 事情のメモが無い無断キャンセルに、AIは「急なご事情があったのではと存じます」と書きがちです。一般的な気づかいとしては自然でも、予約客に何かを決めつけた文に読まれることがあります。 メモの無いときは、事情に触れずに確認だけを書かせます。

指示内容を固定する

あなたは飲食店の予約担当として、予約の日に来店されなかったお客さまへの
メールを書きます。店長が選んだ方針に沿って、件名と本文を書いてください。
方針・金額・規定の文言は、下に渡したものをそのまま使ってください。

【方針ごとに書くこと】
- policy が charge のとき：
  予約の日時と人数、予約の時にお示ししたキャンセル規定（下の文言を
  「」でそのまま引用）、規定上の金額（下の値をそのまま）、
  支払の方法の案内（下の文をそのまま）、問い合わせの先。
- policy が waive のとき：
  予約の日時、来店されなかったことへの気づかい、今回はキャンセル料を
  いただかないこと、次回のご予約の方法。金額は書かない。
- policy が confirm のとき：
  予約の日時、ご来店が確認できなかったこと、ご事情を伺いたいこと、
  返信の方法。金額と規定は書かない。

【厳守事項】
- 金額は amount の値をそのまま書いてください。計算し直さないでください。
- 規定の文言は policy_text の文をそのまま引用してください。
  要約・言い換えをしないでください。
- 割引・特典・次回の優遇を書かないでください。
- 支払の期限を新しく書かないでください。payment_note にある場合だけ写す。
- event_note（事情のメモ）がある場合は、本文の最初の段落でそれに触れて
  ください。event_note が空なら、ご事情を推し量る言葉を書かないでください。
- visit_count は言い回しの丁寧さにだけ使ってください。金額や免除の理由に
  しないでください。
- 「無断」という言葉を本文で使わないでください。
- 責める言い方、催促の言い方をしないでください。
- manager_note（店長のひとこと）があれば、その趣旨を本文に入れてください。
- 書けない、または情報が足りない場合は、needs_attention を true にして、
  理由を attention_reason に書いてください。

【予約】{reservation}
【事情のメモ】{event_note}
【来店の回数】{visit_count}
【方針】{policy}
【規定上の金額と計算の根拠】{amount} / {amount_basis}
【予約の時にお示しした規定の文言】{policy_text}
【支払の方法の案内】{payment_note}
【店長のひとこと】{manager_note}
【店名と署名】{signature}

「無断」という言葉を使わせないのは、店の側から見た言葉だからです。 予約客が電話をしたつもりで伝わっていなかった場合、「無断キャンセル」と書かれた1通は、それだけで店への不信になります。 店の対応表の中では無断キャンセルと呼んでも、文面には出しません。

金額と規定の文言を「そのまま」と2か所に書いているのは、AIが整えたがるからです。 「料金の100％」を「全額」と書き換え、規定の文を短くまとめます。言い換えた1語が、予約の時に示した規定と食い違う原因になります。

出力形式を固定する

次の形の JSON を返させます。

{
  "reservation_id": "",
  "policy": "charge | waive | confirm",
  "subject": "",
  "body": "",
  "quoted_policy_text": "",
  "amount_in_body": "",
  "mentions_event_note": true,
  "needs_attention": false,
  "attention_reason": ""
}

構造化出力にする1つ目の理由は、ルーターの条件にそのまま使えることです。 policy と needs_attention の値で分岐させるので、決まった値の外の文字が返ると、下書きがフォールバックに落ちます。 OpenAI API の Structured Outputs は、Responses API の text.format に type: "json_schema" と strict: true を付けてスキーマを渡す仕組みです。

2つ目は、文面の中身をワークフローが確かめられることです。 quoted_policy_text に引用した規定の文、amount_in_body に本文に書いた金額を別の欄で返させ、ワークフローがキャンセル規定の表の文言と、計算した額とに一致するかを比べます。 一致しなければ下書きを作らず、対応表に「要確認」と書きます。policy が waive や confirm なのに amount_in_body が空でなければ、それも止めます。

3つ目は、応答が途中で切れたときに気づけることです。 公式のページでは、拒否のときは refusal が返り、出力が上限で止まったときは status と incomplete_details で分かるとされています。どちらのときも下書きを作らず、対応表に「未作成」のまま残します。

対応表には、次の列を持たせます。

システムへ連携する

ルーターのルートは、次の順に並べます。 1本目は needs_attention が true のもの（対応表に「要確認」と書くだけ）、2本目から4本目は方針ごとの下書き、最後にメールの連絡先が無いもののフォールバックです。公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが受け持つとされています。要確認を先に置くのは、問題のある文面が下書きのルートに流れるのを防ぐためです。

予約システムには書き込みません。 予約客の記録に「無断キャンセル1回」を足すかどうか、予約の受付を止めるかどうかは、店の判断で、予約システムの画面で人が行います。

人が確認する

店長が、すべての下書きを送る前に確かめます。 下書きのまま送られることはありません。

1. 方針を選ぶ … 対応表で、来店の回数・事情のメモ・規定上の額と計算の根拠を見て選びます。「人数変更あり」の印が付いた行は、額を確かめてから選びます
2. 額と規定の文言を見る … 下書きを開き、本文の金額と引用した規定が対応表と同じかを見ます
3. 事情の書き方を見る … 電話のメモに触れた一文が、予約客が言ったことと合っているかを見ます
4. 送る … Gmail の画面から送り、対応表の状態を「連絡済み」にします
5. 電話のみの予約 … 対応表の文面を見ながら電話をかけ、話した内容を備考に書きます

本部の予約担当が見るのは、要確認の行と、経過日数が2日を超えた行だけです。 店長が休みの日の分を引き取り、方針は店長に電話で確かめてから選びます。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、予約台帳と規定の表の整え方の問題です。 規定の無い行が多い店は、コースの追加のたびに規定の表を足す決まりを作るほうが効きます。

予約サイト経由の予約では、店から予約客へ直接連絡してよいか、どの手段で連絡するかが予約サイトとの取り決めで決まっていることがあります。 経路の列を持たせているのは、その取り決めに合わせて経路ごとに扱いを変えられるようにするためです。

記録を残す

• 対応表の行（予約番号、規定上の額、計算の根拠、方針、状態）
• AIに渡した入力と、返ってきた JSON の全文
• ワークフローが比べた結果（規定の文言と金額が一致したか）
• 下書きの本文と、店長が送る前に直した箇所
• 方針を選んだ店長の名前と日時
• 予約客からの返信と、その後の支払・取り消しの記録

5つ目を残すのは、店ごとの扱いのばらつきを見るためです。 月ごとに、店長ごと・来店の回数ごとに「規定どおり」「免除」の割合を並べると、第3章の（b）のような扱いの違いが数字で見えます。 扱いをそろえるかどうかは本部が決めます。

4つ目は、指示の見直しの材料になります。 同じ直しが続くなら（「規定の文言の前置きが長い」など）、指示の書き方か、規定の表の文言そのものを直します。