【飲食店】予約台帳の一元管理をClaude Code/Codexで自動化する方法
金曜の19時。満席のホールで電話が鳴り、ホールリーダーが配膳の手を止めて受話器を取ります。聞き取った予約はレジ横の紙の台帳へ。同じころ、グルメサイトからは予約通知メールが届き、公式LINEには「明日4名で入れますか?」というメッセージがたまっていきます。どれも大切な予約ですが、届く場所はばらばらです。
予約の入口が増えた今、飲食店の予約管理でいちばん手間がかかっているのは、予約を受けることではありません。あちこちに届いた予約を1冊の台帳に写し、席の重なりを確かめ、前日に確認の連絡を入れるという、受付の後ろ側の作業です。ここが手作業のままだと、転記の時間が営業を圧迫し、二重予約や無断キャンセルが起きやすくなります。
この記事では、予約台帳の一元管理の基本とルールを整理したうえで、予約通知メールやLINEメッセージの受信をきっかけに、台帳への追記・重複チェック・前日確認の下書きまでが自動で走る仕組みをClaude Code/Codexで作る方法を解説します。AIに都度お願いして作業を速くする話ではなく、人が思い出さなくても業務が流れる仕組みの話です。
飲食店の11業務の自動化をまとめた全体像は、親記事の飲食店をClaude Code/Codexで自動化した事例11選で紹介しています。本記事は、そのうち「予約台帳の一元管理」を深掘りした1本です。
この記事でわかること
01 PROBLEM 飲食店の予約管理で起きていること 予約の入口は増えたのに、台帳へは今も手で写している
予約の入口は、電話に加えて、グルメサイト(複数に掲載する店も多くあります)、公式LINE、Googleマップ、自社サイトのフォーム、会計時の次回予約と広がりました。お客様には便利になった一方で、店から見ると予約の情報がそれぞれ別の場所に届くようになっています。
1-1. 予約の情報が「4か所」に散らばる
よくあるのが、電話・グルメサイト2媒体・公式LINEの4経路で予約を受けている店です。電話は受けた人のメモに、グルメサイトは管理画面と通知メールに、LINEはトーク画面に残ります。台帳に1本化されるのは、誰かが手で写した瞬間だけです。この作業が営業の合間や閉店後に後回しにされることで、次の問題が起きます。
1-2. 無断キャンセルは「予約全体の1%弱」でも損失が大きい
経済産業省が2018年11月に公表した「No show(飲食店における無断キャンセル)対策レポート」(有識者勉強会のとりまとめ)によると、無断キャンセルは飲食店の予約全体の1%弱を占めると言われ、業界全体の損害は年間約2,000億円とも言われています。1日前・2日前のキャンセルまで加えると発生率は6%強、被害額は約1.6兆円に及ぶと推計されています。
📚 用語解説
No show(無断キャンセル):予約をしていたにもかかわらず、その日時になっても店に連絡なく、または店からの連絡を無視して来店しないこと。食材費や仕込みの人件費が無駄になるだけでなく、遅れて来るかもしれない客のために席を空けて待つため、予約時間から平均2〜3時間後まで(または閉店まで)の機会損失が生じるとレポートは指摘している。
同レポートには、予約に占めるキャンセルの内訳(株式会社トレタのデータより推計)も載っています。
| キャンセルの種類 | 予約に占める割合 |
|---|---|
| 無断キャンセル(No show) | 0.9% |
| 当日のキャンセル | 3.9% |
| 前日のキャンセル | 1.1% |
| 2日前のキャンセル | 0.6% |
| 3日前以前のキャンセル | 2.8% |
注目したいのは、無断キャンセルが予約管理の穴から生まれやすいことです。前日確認が漏れた、キャンセルの連絡先がわかりにくかった、連絡先を聞けていなかった——どれも台帳の運用の問題です。予約台帳の一元管理は、事務の削減であると同時に、売上の取りこぼしを防ぐ施策でもあります。
02 BASICS 予約台帳の基本と押さえるべきルール 管理方法の比較、予約の成立、無断キャンセル対策、個人情報の扱い
📚 用語解説
予約台帳:来店予約を記録・管理する帳簿。日時・人数・席・コース・連絡先などを1件ずつ記録し、席の割り振り、仕込み量、スタッフの配置を決める元データになる。紙のノートのほか、スプレッドシートや予約台帳アプリ(予約管理システム)で管理する。複数の予約経路の情報を1つの台帳に集めることを「一元管理」と呼ぶ。
2-1. 予約台帳の管理方法は4つ
予約台帳の管理方法は、大きく次の4つに分けられます。
| 管理方法 | 強み | 弱み | 二重予約のリスク |
|---|---|---|---|
| 紙の台帳 | 導入が簡単。電話を受けながらすぐ書ける | 転記ミスや読み違いが起きやすく、店の外からは見られない | 高い |
| エクセル・スプレッドシート | 無料で項目を自由に設計でき、共有すれば本部からも見られる | 入力は手作業。グルメサイトやLINEとはつながっていない | 中〜高 |
| 予約台帳アプリ(予約管理システム) | 連携しているグルメサイトの予約を取り込み、席在庫をそろえられるものが多い | 費用がかかるものが多い。連携外の経路(電話・LINEなど)は手入力が残る | 低い(連携の範囲内) |
| グルメサイトの管理画面中心 | 追加の道具なしでネット予約を受けられる | サイトごとに管理画面が分かれ、電話・LINEとは別管理になる | 高い |
どれが正解かより、予約の入口の数と、台帳に集まるまでの手作業の量で考えるのが実務的です。入口が電話だけなら紙でも回りますが、入口と店舗が増えると「写す」作業が追いつかなくなります。予約台帳アプリでも、連携外の経路の転記や宴会の確定期限の管理は残ります。本記事の自動化は、いまの台帳(スプレッドシートでもアプリでも)を中心に置いたまま、その周りの手作業をなくす考え方です。
2-2. 予約は「電話の口約束」でも成立しうる
前出の経済産業省のレポートでは、飲食の提供契約は予約方法に関わらず、内容が確定していればその時点で成立すると考えられ、口頭のみの電話予約でも契約が成立することがある、と整理されています。だからこそ台帳には「何を約束したか」——日時・人数・席・コースの有無・金額、キャンセルポリシーを伝えたかどうか——を残すことが大切です。走り書きの「◯◯様 4名 19時」だけでは、コース予約だったのかすら後からわかりません。
2-3. 無断キャンセルを減らす4つの取り組み
レポートは、飲食事業者に期待される対策として次の4つを挙げています。
📚 用語解説
リコンファーム:予約の再確認のこと。来店日の数日前・前日・当日朝などに、日時・人数・内容を確認する連絡を入れる。うっかり忘れを防ぎ、行けなくなった人がキャンセルを伝えるきっかけにもなる。電話のほか、SMSやメール、LINEなどのメッセージで行う方法もある。
このうち最初の3つは、予約台帳の仕組みで直接支えられます。連絡先がそろわなければ再確認はできず、ポリシーを伝えたかどうかは記録がなければわかりません。無断キャンセル対策の土台は、予約台帳の一元管理です。キャンセル料の具体的な考え方は、宴会予約の章で詳しく扱います。
2-4. 予約台帳は「個人情報の塊」として扱う
予約台帳には、氏名・電話番号・来店履歴・アレルギーや記念日などの個人情報が集まります。飲食店も個人情報保護法の個人情報取扱事業者として、次のルールに沿って扱います。
AIを使う場合も同じです。個人情報保護委員会は2023年6月2日の注意喚起で、生成AIサービスに個人情報を含むプロンプトを入力する場合は利用目的の達成に必要な範囲内かを十分に確認すること、本人の同意なく入力した個人データが応答結果の出力以外の目的で取り扱われる場合は法の規定に違反する可能性があることを示しています。自動化の前に、どのデータを、どのサービスで、何のために処理するかを決め、入力したデータが機械学習に使われない設定や契約かを確認しておきましょう。
03 AUTOMATION 効率化ではなく自動化:Claude Code/Codexで予約台帳の何を自動化するか AIにお願いするのではなく、予約が届いたら仕組みが動く
📚 用語解説
Claude Code/Codex:Claude CodeはAnthropic社、CodexはOpenAI社が提供するAIエージェント。質問に答えるチャットAIと違い、パソコン上のファイルの読み書きや、作業手順を組み立てて実行できる。日本語の指示で、メールの読み取り、スプレッドシートへの追記、条件のチェック、文面の下書きといった一連の手順を「仕組み」として作れる。
3-1. 「効率化」と「自動化」はここが違う
効率化とは、人が作業するときにAIを使って速くすることです。予約通知メールをチャットAIに貼り付けて「台帳の形式に整えて」と頼めば、転記は少し速くなります。しかし人が思い出してお願いしない限り何も起きないため、忙しい日ほど使われず、担当者が休めば止まります。
一方の自動化は、予約通知メールが届いた・LINEにメッセージが来た・前日の15時になった、といった出来事(トリガー)をきっかけに、決まった手順が人の操作なしで走る仕組みです。人の仕事は、仕組みが用意した結果を確認し、判断が必要なところだけを判断することになります。本記事で扱うのはこちらです。
WORKFLOW
効率化(お願いベース)— 人が起点
WORKFLOW
自動化(本記事のテーマ)— 出来事が起点
📚 用語解説
トリガー:仕組みが動き出す「きっかけ」となる出来事。予約の自動化では、予約通知メールやLINEメッセージの受信、入力フォームへの入力、毎日決まった時刻になることなどがトリガーになる。人が「やろう」と思い出すことを起点にしない点が、効率化との違い。
3-2. 自動化できる作業・人が残る作業
| 作業 | 手作業のとき | 自動化した後 | 人の役割 |
|---|---|---|---|
| ネット予約の転記 | 通知メールを見て台帳へ書き写す | 受信をきっかけに日時・人数・コース・連絡先を読み取り、共通台帳へ追記 | 追記結果の確認 |
| LINE予約の転記 | トーク画面をさかのぼって拾う | 予約内容を読み取り、足りない項目の聞き返しを下書き | 聞き返しの送信と確定 |
| 電話予約の記録 | メモに書いて後で写す | スタッフがスマホのフォームに入れると共通台帳に入る | 聞き取りと入力 |
| 重なりのチェック | 閉店後に台帳を見比べる | 席数・時間帯を自動で照合し、重なれば即時通知 | 優先順位と代わりの案を決める |
| 前日確認 | 1件ずつ電話・メッセージ | 決まった時刻に確認メッセージを下書き | 確認して送信 |
| 集計 | 月末に紙をめくって数える | 経路別の予約数・無断キャンセル件数を自動集計 | 数字を見て対策を決める |
ポイントは、予約を受けるか、お客様に何を送るか、例外をどう扱うかは、最後まで人が決めることです。仕組みが担うのは「集める・写す・照合する・下書きする・知らせる」まで。この線を最初に引けば、店の判断や接客が機械任せになることはありません。
3-3. 仕組みの全体像
Claude Code/Codexは、この仕組みを作る道具であり、仕組みの中でメールやメッセージを読み取るエンジンにもなります。「予約メールから日時と人数を取り出して、共通台帳に1行追加して」と日本語で頼めば、読み取り方、台帳への当てはめ方、読み取れなかったときの扱いまでを手順として組み立てます。メールやLINEとつなぐ接続の設定は最初に一度必要ですが、その進め方もAIに聞きながら進められます。
すでに予約台帳アプリを使っている店でも考え方は同じです。アプリが対応していない電話・LINEの予約を同じ台帳に集めたり、宴会の確定期限や店独自のルールのチェックを足したりできます。台帳を作り直すのではなく、台帳の周りで人が手を動かしている部分を1つずつ仕組みに置き換えるのが基本方針です。
04 MODEL CASE モデル事例:A社(和食居酒屋4店舗)の導入前と導入後 4つの予約経路を1つの台帳へ。転記は確認だけ、二重予約は0件に
ここからは、予約台帳の一元管理を自動化した姿をモデル事例で見ていきます。以下はモデル事例(AI鬼管理が支援を想定した仮名のケース。数値は目安)です。実在する特定の店舗の実績ではなく、和食居酒屋の予約業務で起きやすい状況を想定して設計しています。
4-1. 導入前:店長とホールリーダーが「写す人」になっていた
A社の4店舗は、どれも宴会や団体の予約が売上の柱です。電話・グルメサイト・LINEの予約を、店長とホールリーダーがそれぞれ紙の台帳へ写していました。台帳は1冊でも、そこへ集まる道は4本あったわけです。
二重予約の多くは、この「写す」前の時間差から生まれます。夕方に電話で個室の予約を受け、台帳に書く前に、同じ時間帯の個室予約がグルメサイトから入る。サイト側では在庫がまだ空いていたため、予約は成立してしまいます。気づくのは閉店後の照合か、当日です。前日の確認連絡も、仕込みと重なる時間帯のため忙しい日ほど後回しになり、確認できないまま当日を迎える予約が出ていました。
4-2. 仕組み:予約が届いたら、台帳・重複チェック・前日確認までが流れる
WORKFLOW
A社の予約台帳ワークフロー
起点は、グルメサイトの予約通知メールと公式LINEへのメッセージの受信です。届いた瞬間に仕組みが動き、日時・人数・コース・連絡先を読み取って、4店舗共通の予約台帳に1行追加します。メールの書式はサイトごとに違いますが、項目の位置を最初に教えておけば、以降は同じルールで読み取ります。電話の予約は、受けたスタッフがスマホの入力フォームに入れて同じ台帳に入れます。
追記されると、店舗ごとの卓数・個室・最大人数と利用時間をまとめた「席数マスタ」と照らし合わせて、重なりのチェックが走ります。同じ個室に同じ時間帯の予約が2件入った、宴会の人数が定員を超えた、といった重なりがあれば、その店の店長へすぐに通知します。そして毎日15時には、翌日の予約ごとに確認メッセージの下書き(日時・人数・コース・キャンセルの連絡先入り)が作られ、店長に届きます。
4-3. 人が確認すること・判断すること
責任の所在もはっきりさせます。お客様に届く連絡はすべて店長の確認を経て送られるため、送った内容の責任は店が持ち、仕組みはその準備を担うという関係です。
4-4. 導入前と導入後の比較
| 項目 | 導入前 | 導入後(目安) |
|---|---|---|
| 台帳への転記 | 1店舗1日約40分(店長・ホールリーダーが手で転記) | 約5分(確認のみ) |
| 二重予約 | 月2〜3件(媒体をまたいで発生) | 0件(重なりを即時に検知し、店長が調整) |
| 無断キャンセル | 月6件 | 月2件 |
| 前日の確認連絡 | 1日約20分(1件ずつ電話・メッセージ) | 15時に下書きがそろい、店長は確認して送信 |
| 予約情報の置き場所 | 店舗ごとの紙の台帳 | 4店舗共通の予約台帳 |
転記の時間を4店舗の合計で見ると、1日約160分が約20分になる計算です。浮いた時間は、ピーク前の準備や、予約の電話での丁寧な聞き取りに回せます。
二重予約が0件になるのは、AIが予約を「うまくさばく」からではなく、時間差をなくし、気づくタイミングを前倒しするからです。無断キャンセルが月6件から2件に減るのも、前日の確認が漏れなく届き、行けなくなったお客様が連絡しやすくなるためと想定しています。残る分は、事前決済や預かり金など別の対策と組み合わせて考える領域です。
05 HOW TO START 自社で始める5ステップ 1店舗・1経路から始めて、並走で確かめてから広げる
A社のような仕組みは、いきなり全店・全経路で作る必要はありません。次の5ステップで、小さく始めて広げていきます。
📚 用語解説
席数マスタ:店舗ごとの卓番・席種(カウンター・テーブル・個室)・最大人数・つなげられる卓・利用時間の基準をまとめた一覧表。重複チェックはこの表を物差しに「同じ席に同じ時間帯の予約がないか」「人数が定員を超えていないか」を判定する。改装や臨時の貸切でも内容が変わるため、更新する担当者を決めておく。
5-1. Claude Code/Codexへの頼み方の例
仕組み作りを頼むときは、業務の流れをそのまま日本語で伝えます。
「グルメサイト2つから届く予約通知メールを読んで、店舗名・来店日時・人数・コース名・予約者の氏名と電話番号を取り出し、共通台帳のシートに1件1行で追加する仕組みを作ってください。予約の変更やキャンセルの通知は新しい行を作らず、予約番号が同じ行を探して状態を書き換えてください。読み取れない項目は空欄のままにして、店長に知らせてください。追加したら席数マスタと照らし合わせ、同じ時間帯に重なりがあれば店長に通知してください。」
大切なのは、例外のときにどうするか(読み取れない、変更の通知だった、席が重なっていた)まで伝えることです。うまくいく場合だけを伝えると、例外のときに仕組みが黙って間違えます。
全店・全経路を一度に始めると、うまくいかないときに原因が分からなくなります。予約がいちばん多い店舗の、いちばん件数が多いグルメサイトの通知メールから始め、並走で食い違いがなくなってから次へ広げてください。
06 BANQUET 宴会・コース予約の管理:人数変更・前日確定・キャンセル料の扱い 1回で終わらない予約を、変更履歴ごと台帳で追いかける
宴会やコースの予約は、1回のやりとりで終わらないぶん台帳の管理が難しくなります。「来月の金曜に20名くらいで」という相談から始まり、コースの決定、人数の確定、前日の最終確認、当日の人数変更と、何度も台帳を書き換えます。幹事さんとのやりとりも、最初はグルメサイト、途中から電話やLINEと経路をまたぎがちです。
6-1. 人数変更は「いつ・誰が・何名に」を記録する
宴会で多いトラブルは人数の認識違いです。「25名で確定と聞いていた」「22名に減らすと電話で伝えた」という食い違いは、記録がないと水掛け論になります。台帳には人数だけでなく、変更の履歴(いつ・どの経路で・誰から・何名から何名へ)を残します。仕組みは変更の連絡を読み取ると元の予約の行を書き換えて履歴を残し、定員超過やコースの最少人数割れがあれば店長に知らせます。変更を受けるか、料金をどうするかは店長が決めます。
6-2. 「人数の確定期限」と前日確定を仕組みにする
コース料理は人数に合わせて仕入れと仕込みを進めるため、「人数の確定は◯日前まで」という期限を決めておくと段取りが安定します。期限は店の段取りで決めるもので、法律で決まった日数があるわけではありません。大切なのは、期限を予約時に伝え、期限の前に確認を入れることです。仕組みは台帳の「確定期限」をもとに前日に確認メッセージを下書きし、返事がない予約を一覧で知らせます。確定した人数は、翌日の仕込み量の予測にも使えます(【飲食店】仕込み量の予測をClaude Code/Codexで自動化する方法で解説しています)。
6-3. キャンセル料の考え方:コース予約と席のみ予約
経済産業省のレポートは、無断キャンセルのキャンセル料(損害賠償)の考え方を予約の種類ごとに整理しています。大前提は、無断キャンセルでは空いた席を別のお客様で埋め合わせる(再販する)ことが著しく難しい、という点です。
| 予約の種類 | レポートでの考え方 | 台帳に残したいこと |
|---|---|---|
| コース予約(コース料金が予約内容になっている) | 損害がその全額となることがあり、ポリシーにもとづき全額を請求できる場合がある。ただし転用可能な飲食物の代金や人件費などは除き、店の収益構造を踏まえて算定する | コース名・単価・人数、ポリシーを伝えた日時と方法 |
| 席のみ予約 | 個別の損害の算定は極めて難しいため、客観的な基準で算定した平均客単価の何割か(転用可能な原材料費・人件費などを除いた額)が一つの目安。平均客単価や算定方法は事前に示す | 席種・人数、平均客単価の示し方、ポリシー説明の有無 |
📚 用語解説
平均的な損害:消費者契約法第9条第1項第1号にある考え方。消費者との契約でキャンセル料(損害賠償の額の予定や違約金)を定めても、解除の事由や時期などの区分に応じて、同種の契約の解除に伴い事業者に生ずべき「平均的な損害の額」を超える部分は無効になる。2023年6月1日施行の改正で設けられた同条第2項により、キャンセル料を請求する際に消費者から求められたときは、算定根拠の概要を説明するよう努めなければならないとされている。
キャンセルの時期で区分する考え方の参考として、レポートは他業界の宿泊約款の例も紹介しています。
| 人数 | 連絡なしの不泊 | 当日 | 前日 | 2日前〜9日前 |
|---|---|---|---|---|
| 14名様まで | 100% | 80% | 20% | - |
| 15名様以上 | 100% | 80% | 50% | 10% |
※No show対策レポートに掲載された宿泊約款の例(一部)。飲食店にそのまま当てはまる基準ではありません。
飲食店の宴会については、30〜40名のパーティー予約を開催の2か月前に解約した個人に店が損害賠償を求めた裁判例(東京地方裁判所・平成14年(レ)第12号)も紹介されています。裁判所は、1人あたりの料金4,500円の3割に予定人数の平均35名を掛けた4万7,250円を「平均的な損害」と認めました。
金額は、店の損害(仕入れ済みの食材、仕込みの人件費、他のお客様を断った機会損失など)にもとづき、時期ごとに説明できる範囲で決めます。平均的な損害を超える部分は、消費者契約法第9条により無効になる可能性があります。そして、予約時にポリシーを伝え、伝えたことを台帳に記録し、求められたら算定根拠の概要を説明できるようにしておくところまでが一連の運用です。
6-4. 受け取ったキャンセル料と消費税
国税庁のタックスアンサー「No.6253 キャンセル料」では、キャンセル料のうち逸失利益などに対する損害賠償金の性格のものは消費税の課税対象外(不課税)、解約手続などの事務手数料の性格のものは課税対象とされ、両者を区分せず一括して受け取る場合は全額を不課税として扱うとされています。精算の記録では、キャンセル料を通常の売上と分けておくと会計で迷いません。
お客様との関係や事情(急病・災害など)を踏まえた判断が必要な場面です。仕組みがやるのは、該当予約の抽出、ポリシーに沿った試算、請求文面の下書きまで。請求・減額・免除の判断と送信は、必ず店長か本部の責任者が行います。
07 CHANNELS 予約経路ごとの注意点(電話・グルメサイト・LINE)と台帳の項目設計 入口ごとのクセを知り、1つの台帳に同じ形で集める
一元管理の難しさは、経路ごとに届く情報の形も、予約が確定するタイミングも違うことにあります。経路ごとの注意点を整理します。
7-1. 電話予約:記録が残らない経路は「受けた瞬間に入力」
電話は、常連のお客様や宴会の幹事さんとの細かな相談に向いた大事な入口です。一方で、4つの経路のなかで記録が自動では残らない経路でもあり、聞き間違いやメモの紛失、書き忘れの多くがここで起きます。
レポートも、予約時に連絡先を確実に把握すること、電話予約でも必要最低限のポリシーを説明することを挙げています。電話の自動化は「電話をAIに取らせる」ことより先に、聞いた内容が確実に台帳に入り、文字の確認につながる流れを作ることから始めるのが現実的です。
7-2. グルメサイト:席の在庫は「サイトごと」にある
グルメサイトの予約は通知メールと管理画面で確認できるため、記録の面では安心です。注意すべきは、予約台帳アプリなどで連携していない限り、席の在庫がサイトごとに管理されている点です。電話やLINE、もう一方のサイトで埋まった席を閉じ忘れると、二重予約になります。
サイトによっては、在庫があればその場で確定する方式のほかに、店が承認してから確定する方式(リクエスト予約など)を選べる場合があります。承認が必要な方式では、「承認待ち」の予約を一覧にして店長に知らせ、放置を防ぎます。
7-3. LINE:会話の中から予約を「確定」させる
公式LINEの予約は、お客様には気軽な反面、情報がそろわないまま会話が進む経路です。「明日4人いけますか?」「19時くらいで」「やっぱり5人かも」と内容が数回に分かれて届き、どの時点で確定したのかも曖昧になりがちです。
自動化では、LINE公式アカウントのMessaging APIを使い、メッセージの受信をトリガーにします。仕組みは会話から日時・人数などを読み取り、足りない項目の聞き返しを下書きして、台帳には「仮予約」として入れます。スタッフが確認して確定の返信を送った時点で「確定」に切り替え、AIが自分の判断で「承りました」と返す設計にはしません。
📚 用語解説
Webhook:あるサービスで出来事が起きたとき、あらかじめ指定した送り先へ自動で知らせる仕組み。LINE公式アカウントのMessaging APIでは、お客様がメッセージを送るとその内容がWebhookで指定のサーバーに届く。予約の自動化では、この知らせを受け取ったことをトリガーにして読み取りや台帳への追記を始める。
LINEのやりとりは、スタッフ個人のスマホやアカウントではなく店の公式アカウントに一本化しておきます。また、予約者への確認連絡と、新メニューなどの販促配信は性格が違うため分けて設計しましょう。販促配信の自動化は【飲食店】SNS・LINEの販促配信をClaude Code/Codexで自動化する方法で解説しています。
7-4. 台帳の項目設計:4つの経路を同じ形で集める
経路ごとのクセを吸収するには、どの経路から来ても同じ列に入るように台帳を設計します。持たせたい項目の例です。
| 項目 | 目的 | 主な入力元 |
|---|---|---|
| 予約番号 | 変更・キャンセルを元の予約に結びつける | サイトの予約番号/仕組みが採番 |
| 受付日時・経路・受付者 | 誰がどの入口で受けたかを残し、経路別に集計する | 仕組みが記録(電話は入力者) |
| 店舗・来店日時・利用時間 | 席の重なりを判定する | 通知メール・LINE・電話フォーム |
| 人数(大人・子ども) | 席の割り当て、仕込み、最少人数の判定 | 通知メール・LINE・電話フォーム |
| 席種・卓番 | 重複チェックと当日の案内 | 席数マスタをもとに店長が割り当て |
| コース・席のみ・飲み放題 | キャンセル料の考え方と仕込み量が変わる | 通知メール・電話フォーム |
| 氏名・連絡先・連絡手段 | 前日確認とキャンセル連絡の窓口 | 予約時に必ず確認 |
| アレルギー・利用目的 | 料理長の確認や接客の準備が必要な予約を見分ける | 予約者の申告(相談への回答は人) |
| キャンセルポリシーの説明 | 伝えた日時と方法を残す | ネット予約の記録・電話フォームのチェック欄 |
| 状態 | 仮予約・確定・キャンセル・No showを区別する | 仕組みが更新(確定とNo showは人) |
| 前日確認の結果 | 返信の有無と内容を残す | 仕組みが記録 |
| 変更履歴 | いつ・どの経路で・何を変えたかを残す | 仕組みが記録 |
項目を増やしすぎると入力が負担になるため、電話フォームで必須にするのは日時・人数・氏名・連絡先に絞り、ほかは分かる範囲で入れる運用が続けやすいです。
7-5. 予約の「状態」は誰が変えるかを決める
「状態」欄は、仕組みと人の役割分担がいちばん表れる項目です。
特に「No show」は、仕組みが自動で付けないようにします。遅れて来店されることも、連絡がつかない事情もあり得るからです。来店がなかったと判断するのは人、件数を集計して対策に使うのが仕組み、という分担です。
08 HUMAN JUDGMENT 人が判断すること・よくある落とし穴 仕組みに任せる範囲と、人が責任を持つ範囲を線引きする
8-1. 人が判断すること
| 判断すること | 判断する人 | 仕組みがやること |
|---|---|---|
| 予約を受けるか(貸切・大人数・特別な要望) | 店長 | 他の予約との重なりや人数を一覧にして知らせる |
| アレルギー・食事制限の相談への回答 | 店長と料理長 | 相談があった予約に印を付けて通知する |
| 二重予約の調整(優先順位・代わりの案) | 店長 | 重なりを即時に検知して知らせる |
| キャンセル料の請求・減額・免除 | 店長または本部の責任者 | 該当予約の抽出、ポリシーに沿った試算、文面の下書き |
| お客様への送信(確認・お断り・請求) | 店長 | 下書きを作り、送信を待つ |
| 席数マスタ・ポリシー・文面の変更 | 本部の担当者 | 変更内容の反映と変更の記録 |
| No showの判定 | 当日の責任者 | 件数の集計と傾向の報告 |
このとおり、お客様との約束に関わる判断と、お客様に届く連絡は、すべて人が行います。仕組みは材料をそろえ、判断が必要な瞬間を知らせる役です。万が一読み取りを誤っても、人の確認で止められます。
8-2. よくある落とし穴
落とし穴1:AIに予約を確定させる。LINEに自動で「承りました」と返すと、席の状況や例外を人が見ないまま予約が成立します。自動で返信するとしても「確認してご連絡します」までにとどめます。
落とし穴2:席数マスタを更新しない。改装で個室の定員が変わった、特定の日だけ貸切にした、といった変更が反映されないと、重複チェックは古い物差しで判定を続けます。更新の担当とタイミングを決めておきます。
落とし穴3:変更・キャンセルの通知を新規予約として取り込む。同じ予約が台帳に2件でき、重複の誤った通知が続きます。予約番号で元の行を探して書き換えるルールを最初に決めます。
落とし穴4:通知が多すぎて誰も見なくなる。予約のたびに通知すると、本当に必要な重複の通知が埋もれます。通知は「人が動く必要があるもの(重なり・読み取れない項目・アレルギーや貸切の相談)」に絞り、ほかは1日1回のまとめで十分です。
落とし穴5:個人情報の扱いを決めずに進める。台帳を誰が見られるか、個人のスマホで台帳を撮影していないか、AIサービスにどのデータを渡すか。決めずに進めると、便利になった分だけ漏えいの経路も増えます。
一度動き始めると、人は中身を見なくなりがちです。月に1回は、仕組みが追記した予約と、グルメサイトの管理画面や電話フォームの記録を抜き取りで突き合わせてください。通知メールの書式が変わるなど、外側の変化で静かに壊れることがあります。
09 THE 3 WALLS 独学でつまずく3つの壁と越え方 ツールの使い方より、ルールの言語化・検証・引き継ぎでつまずく
Claude Code/Codexを使えば、予約台帳の自動化はプログラミングの知識がなくても始められます。ただ、独学でつまずくポイントは次の3つに集まります。
壁1:店のルールが言葉になっていない
「個室は4名以上から」「常連さんの電話予約は優先」——予約の現場には、店長の頭の中にしかないルールが多くあります。仕組みは教えられたルールしか守れないため、言葉になっていないルールは黙って無視されます。越え方は、過去1か月の台帳を見ながら「なぜこの席にしたのか」を店長に聞き、答えを文章にしていくことです。その文書が、そのまま仕組みへの指示書になります。
壁2:正しく動いているかを確かめる方法がない
読み取りを1か所間違えていても、台帳には何かしらの値が入るため、誤りは目立ちません。越え方は、並走での突き合わせに加え、わざと難しい予約(変更が続く予約、定員を超える予約、読みにくい書式)を流し、仕組みが期待どおりに止まるか・知らせるかを確かめることです。
壁3:作った人しか直せない
担当者が異動や退職をすると、仕組みを誰も直せなくなる——エクセルの複雑な関数で起きていた属人化が、形を変えて再発します。越え方は、仕組みの全体像(トリガー・処理・通知先・人の判断ポイント)を1枚にまとめ、店長や本部の複数人が「どこを変えれば何が変わるか」を説明できる状態にすることです。
AI鬼管理では、この3つの壁を越えるところまでを、店の実際の台帳や予約データを使って伴走しています。ツールの操作より、店のルールを言葉にし、確かめ、引き継げる形にすることが自動化の成否を分けるからです。
10 SUMMARY まとめと関連記事 予約台帳は「写す」から「確かめる」へ
予約台帳の一元管理とは、入口を減らすことではなく、どの入口から来た予約も、届いた瞬間に同じ台帳へ同じ形で入り、重なりや確認漏れが人に知らされる状態を作ることです。ポイントを振り返ります。
予約台帳が整うと、確定した人数は仕込み量の予測に、時間帯ごとの予約数はシフトの組み方にと、ほかの業務にもつながります。あわせて次の記事もご覧ください。
- 親記事:飲食店をClaude Code/Codexで自動化した事例11選
- 兄弟記事:【飲食店】仕込み量の予測をClaude Code/Codexで自動化する方法
- 兄弟記事:【飲食店】SNS・LINEの販促配信をClaude Code/Codexで自動化する方法
- 関連記事:飲食店のAI導入完全ガイド|解決できる課題と効率化できる業務例
- 関連記事:飲食店のAI活用を全網羅|発注・シフト・販促の効率化と食品表示の線引き
- 関連記事:飲食店のシフト作成を効率化する「モデルシフト」完全ガイド
参考資料
- 経済産業省「No show(飲食店における無断キャンセル)対策レポート」(2018年11月1日、サービス産業の高付加価値化に向けた外部環境整備等に関する有識者勉強会)
- 消費者契約法(e-Gov法令検索)
- 個人情報の保護に関する法律(e-Gov法令検索)
- 国税庁 タックスアンサー No.6253 キャンセル料
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」(2023年6月2日)
予約台帳の自動化、どこから始めるか一緒に整理しませんか
「予約の入口が多すぎて、どこから手を付ければいいかわからない」「予約台帳アプリは入れたが、電話とLINEは手作業のまま」——そんなご相談をお待ちしています。
AI鬼管理は、貴店の実際の予約台帳や通知メールを題材に、ルールの言語化から仕組みの設計・検証・スタッフへの定着までを伴走します。
ここから先の進め方は、大きく2つあります。
自社で回せるようになりたい方は、AI鬼管理でClaude Code/Codexの使い方から業務設計・社内定着まで伴走を受けながら、社内に仕組みを作る道があります。
覚えるより任せたい方は、AI社員AIKATAでこの記事のような定型業務を丸ごと預ける道があります。料金は月30万円の月額定額、追加費用は0円です。
どちらが合うかは、業務量と社内体制次第です。無料相談・無料適合診断で、貴社の場合はどちらが向くかからご相談いただけます。
NEXT STEP
この記事の内容を、あなたのビジネスで
実践してみませんか?
よくある質問
Q. 事例の会社(A社)は実在しますか?
A. A社は実在する特定の会社ではなく、AI鬼管理が支援を想定したモデル事例(仮名のケース。数値は目安)です。和食居酒屋の予約業務で起きやすい状況を想定し、仕組みの流れ、人が判断すること、導入前後の変化がわかるように設計しています。自店に当てはめて考える際の目安としてご活用ください。
Q. 予約台帳アプリを使っていても、Claude Code/Codexで自動化する意味はありますか?
A. あります。予約台帳アプリは連携しているグルメサイトの予約の取り込みや席在庫の調整に強い一方、連携外の電話・LINEの予約の転記、宴会の確定期限の管理、店独自のルールのチェック、前日確認の文面づくりは手作業で残りがちです。アプリを「正の台帳」としてそのまま使い、周りの手作業をClaude Code/Codexで仕組みにするのが現実的です。
Q. AIが勝手に予約を確定したり、お客様にメッセージを送ったりしませんか?
A. そうならないように設計します。AIが担うのは、予約内容の読み取り、台帳への追記、席の重なりのチェック、確認メッセージの下書き、店長への通知までです。予約の確定、お客様への送信、貸切やアレルギー相談などの例外の判断は店長が行います。
Q. 無断キャンセルのキャンセル料は、いくらまで請求できますか?
A. 一律の上限はなく、店に生じる損害にもとづいて考えます。経済産業省のNo show対策レポートでは、コース予約は全額を請求できる場合がある(転用可能な飲食物の代金や人件費などは除く)、席のみ予約は平均客単価から転用可能な原材料費・人件費などを除いた額が一つの目安とされています。平均的な損害を超える部分は消費者契約法第9条により無効となるため、ポリシーを予約時に明示し、根拠を説明できるようにしてください。個別の判断は弁護士などの専門家への相談をおすすめします。
Q. 予約者の個人情報をAIに扱わせても大丈夫ですか?
A. 個人情報保護法に沿った扱いが前提です。利用目的を公表または通知し、台帳の閲覧権限を絞るなどの安全管理措置をとります。AIサービスを使う場合は、個人情報保護委員会の注意喚起(2023年6月2日)も踏まえ、入力するデータを利用目的の範囲に限り、入力したデータが機械学習に使われない設定や契約かを確認してから運用してください。
Q. プログラミングの知識がなくても作れますか?
A. 作れます。業務の流れや例外の扱いを日本語で伝えれば、Claude Code/Codexがメールの読み取り、台帳への追記、席の重なりのチェックといった手順を組み立てます。ただし、メールやLINEとの接続の設定、店のルールの言語化、並走での検証は欠かせません。まずは1店舗・1経路から始めるのが安全です。
Claude Codeで業務自動化を90日で叩き込む
経営者向けの伴走型パーソナルトレーニング
AI鬼管理/AI社員AIKATAへのお問い合わせ
この記事を読んで気になった方へ。
専門スタッフが、御社に最適な
業務自動化・業務代行プランを無料でご提案します。




