団体・法人の宿泊予約の依頼メールを手配表にそろえ、足りない確認事項を返信案にまとめる

処理の起点を決める

団体予約用のアドレスに新着メールが届いたときを起点にします。Make の Watch emails を使い、団体予約用のラベルが付いたメールだけを対象にします。

アドレスを分けていない場合は、Gmail のフィルタで「団体」「合宿」「研修」などを含むメールにラベルを付けます。ただし、旅行会社からは件名に手配番号しか書かれていないメールも届き、フィルタだけでは漏れます。団体予約用のアドレスを1つ作り、ホームページや旅行会社への案内をそちらへ寄せるのが確実です。

Make のシナリオは、スケジュールを設定して有効化しないと動きません。既定では15分ごとに実行される設定です。団体予約なら15分ごとで十分です。 数分の差で困る業務ではありません。営業時間外に届いた依頼は、翌朝までに下書きが並んでいる状態を目指します。

入力データを集める

名簿（参加者の氏名の一覧）は、AIに渡しません。 部屋割りの表に氏名が入っていることがよくありますが、手配に必要なのは部屋ごとの人数と男女の内訳です。氏名の入った添付は、人数の集計だけを取り出すか、担当者が手で扱う経路へ回します。 扱いは第13章で書きます。

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

本文： Watch emails の出力から、本文のテキストを取ります。HTMLのメールは装飾を除いたテキストにしてから渡します。 署名と、過去のやり取りの引用部分も含まれます。引用部分は変更依頼の判断に使うので、捨てずに「引用」として区別して渡します。

PDFの添付： List email attachments で添付を取り、PDFはそのまま Claude API へ渡します。Claude API は PDF を document の内容ブロックとして受け取り、各ページを文字と画像の両方として扱うため、旅行会社の手配書のような表の多い書類も読めます。PDFはパスワードや暗号化のない標準的なものである必要があります。パスワード付きのPDFは「要確認」へ回します。

表計算の添付： 部屋割りの表や人数の内訳は、Excel や CSV で届くことが多くあります。生成AIへは表の中身をテキストにしてから渡します。 Make の中でファイルを読み取れる形に変える方法は、利用環境に応じた個別の設定が必要です。組めない場合は、表計算の添付があるメールを「添付あり・要手動」として手配表に行だけ作り、担当者が表を開いて確かめる形にします。本文だけでも、多くの項目は取れます。

手配表の既存行： Search Rows で、団体名と到着日が近い行を探します。旅行会社の依頼なら手配番号で探せます。見つかった行の内容を、変更の判断のために生成AIへ一緒に渡します。

Router で添付の種類ごとに流れを分けます。Router は条件ごとに複数の経路へ流れを分ける機能で、どの条件にも当たらないものを受ける予備の経路を設けられます。予備の経路には、画像だけの添付や、読めない形式のファイルを流し、「要確認」にします。

AIへ渡す前に整形する

1. 引用部分の切り分け … 「〇〇様 wrote:」や「-----Original Message-----」以下を引用として分けます。引用の中の古い人数を、今回の人数として読まないためです
2. 署名の切り分け … 署名の会社名・部署・電話番号は「依頼者の連絡先」として使います。本文の条件と混ぜません
3. 名簿の除外 … 表計算の添付に氏名の列がある場合、氏名の列を落としてから渡します。 部屋番号・男女・人数の列だけを残します
4. 対象外のメールの除外 … 自動返信、配信停止の案内、請求書の送付だけのメールは取り込みません。件名と送信者で先に落とします
5. 手配表の候補行の取得 … 既存の案件が見つかった場合、その行の全項目を「現在の手配内容」として渡します

AIに処理させる

生成AI（Claude API）にさせること：

機械的に決めること（AIにさせない）：

「原文の根拠」を必ず出させてください。 担当者が確認するとき、抜き出された「夕食18時30分」が本文のどこにあったかがすぐ分かれば、見比べは数秒で済みます。 根拠がないと、結局メールを頭から読み直すことになり、時間が減りません。

不足項目の洗い出しは、条件付きで行います。 すべての項目を毎回必須にすると、夕食なしの依頼にも「アレルギーの有無をお知らせください」と聞くことになります。依頼の中身によって、聞くべき項目が変わります。 その条件は、次の定義表として生成AIへ渡します。

この定義表は施設ごとに違います。 大型バスの駐車場がない施設なら「バスの大きさ」は常に必須です。この表を施設の担当者が作ることが、導入の最初の作業になります。

指示内容を固定する

あなたはホテルの団体予約の窓口担当です。
下のメールと添付から、団体の宿泊の依頼内容を手配表の項目ごとに抜き出し、
手配に必要なのに書かれていない項目を洗い出してください。

【厳守事項】
- 本文・添付に書かれていることだけを抜き出してください。
  書かれていない値を推測で埋めないでください。
  書かれていない項目は null にし、missing_items に入れてください。
- 引用部分（過去のやり取り）に書かれている値は、今回の依頼の値として扱わないでください。
  引用部分は、既存の案件との差分を判断するときだけ参照してください。
- 抜き出した値ごとに、evidence に項目名と原文の該当箇所（30字以内）をそのまま書き写してください。
  言い換えないでください。添付から取った場合は、添付のファイル名も書いてください。
- 「〜前後」「〜程度」「未定」「できれば」など、幅や迷いのある書き方は、
  値を1つに決めずに、ambiguous_items に原文のまま入れてください。
- 人数の合計は、内訳が書かれていれば内訳の値だけを入れてください。
  合計を自分で計算しないでください。
- 必須かどうかの判断は、下の【項目の定義】の条件に従ってください。
  条件に当たらない項目は、書かれていなくても missing_items に入れないでください。
- 氏名、生年月日、住所など個人を特定する情報が含まれていても、抜き出さないでください。
- 空室があるか、料金がいくらか、予約が取れるかについては、何も書かないでください。
  それを決めるのは担当者です。

【依頼の種類】
新規 / 変更 / 取り消し / 空きの確認のみ

【項目の定義】
{field_definitions}

【現在の手配内容（既存の案件が見つかった場合のみ）】
{existing_row}

【メールの件名・送信者・受信日時】
{mail_header}

【メール本文（今回の部分）】
{mail_body}

【メール本文（引用部分）】
{quoted_body}

【署名】
{signature}

【添付（読み取った内容とファイル名）】
{attachments}

「書かれていない値を推測で埋めない」の1行が最も重要です。 これを書かないと、朝食の時間が書かれていない依頼に「7時00分」が入ります。それらしい値が入った欄は、担当者の目に「聞いた内容」として映ります。 空欄なら聞き返せたのに、埋まっていたせいで聞かずに当日を迎えることになります。

「空室・料金・予約の可否について何も書かない」も必須です。 これがないと、返信の下書きに「ご希望の日程でご用意いたします」と入ることがあります。担当者が見落として送れば、空きを確かめる前に承諾したことになります。

返信の下書きは、抽出とは別の呼び出しで作ります。抽出結果を確かめた上で文章にするほうが、抽出の誤りが文面へそのまま移ることを防ぎやすいためです。

あなたはホテルの団体予約の窓口担当です。
下の抽出結果をもとに、依頼者への返信の下書きを作ってください。

【厳守事項】
- 最初に、受け付けた内容を箇条書きで確認してください（日程・人数・部屋・食事・宴会・駐車）。
  値が null の項目は確認の箇条書きに入れないでください。
- 次に、missing_items と ambiguous_items の項目を「恐れ入りますが、次の点をお知らせください」として
  番号付きで並べてください。1項目につき1行で、答えやすい聞き方にしてください。
  例：「夕食のお時間は、18時・18時30分・19時のいずれがご希望でしょうか」
- 空室の有無、料金、予約の成立を約束する表現を使わないでください。
  「承りました」「ご用意いたします」「確保いたしました」は使わず、
  「内容を確認のうえ、空室と料金を改めてご連絡いたします」と書いてください。
- 相手の書き方（敬語の度合い）に合わせてください。旅行会社には簡潔に、
  学校・企業の担当者には丁寧に書いてください。
- 署名は付けないでください（担当者が付けます）。

【依頼者の種類】
{requester_type}

【抽出結果】
{extraction_json}

質問は選択肢の形にすると、返事が早く返ってきます。 「夕食の時間をお知らせください」より「18時・18時30分・19時のいずれか」のほうが、相手は1語で答えられます。聞き返しが1往復で終わるかどうかが、団体予約の手配の速さを決めます。

変更依頼のときは、変更点だけを確認します。 前回と同じ内容を全部並べ直すと、相手はどこが変わったのかを探すことになります。「人数を20名から22名へ変更。これに伴い、朝食・夕食も22名分に変更してよろしいでしょうか」と、関連する項目への影響を質問にするのが実務的です。

出力形式を固定する

{
  "request_type": "新規 | 変更 | 取り消し | 空きの確認のみ",
  "requester_type": "企業 | 学校 | スポーツ団体 | 旅行会社 | その他",
  "organization": "",
  "contact": { "phone": "", "email": "", "agent_reference_no": "" },
  "check_in": "",
  "check_out": "",
  "arrival_time": "",
  "guests": { "male": null, "female": null, "escorts": null, "total_stated": null },
  "rooms": [ { "room_type": "", "count": null, "occupancy": null } ],
  "meals": [ { "date": "", "meal": "朝食 | 昼食 | 夕食", "count": null, "time": "" } ],
  "dietary_note": "",
  "banquet": { "needed": false, "headcount": null, "time": "", "style": "" },
  "transport": { "mode": "", "bus_size": "", "bus_count": null, "car_count": null },
  "billing": { "payee_name": "", "send_to": "", "payment_method": "" },
  "evidence": [ { "field": "", "source": "" } ],
  "changes": [ { "field": "", "before": "", "after": "" } ],
  "missing_items": [ { "field": "", "reason": "" } ],
  "ambiguous_items": [ { "field": "", "raw": "", "question": "" } ],
  "personal_data_detected": false,
  "unreadable_attachments": []
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema として JSONスキーマを渡すと、応答がスキーマに沿った形になります。必須の項目が欠けたり、型が違ったりする応答が返らないため、Make 側で手配表の列へそのまま割り当てられます。 ただし、minimum maximum のような数値の制約はスキーマで指定できないため、人数が0や負の値になっていないかは Make の側で確かめます。

evidence で全項目の根拠を持たせている点が、この形式の要です。 personal_data_detected は、本文に氏名などが混ざっていたかの印で、true の行は保管の扱いを確かめます。 手配表では、各項目の隣に根拠の列を置きます。担当者は値と根拠を並べて見るだけで、メールを開かずに確かめられます。

changes は変更依頼のときだけ中身が入ります。 既存の行の値と、今回の依頼の値が違う項目を並べます。人数が変わったのに食事の数が書かれていない場合、changes に人数が入り、missing_items に「食事の数を人数に合わせてよいか」が入るのが正しい出力です。

システムへ連携する

手配表は1案件1行にします。列は次の構成です。

「変更候補」の列を別に持つことが重要です。 変更依頼の読み取りを誤っても、元の値は残ります。担当者が変更候補を確かめてから、元の列を書き換えます。書き換えは人が行うので、誤った変更が確定した手配に入り込みません。

新規の依頼は Add a Row で行を足し、変更は Search Rows で見つけた行に Update a Row で「変更候補」の列だけを書き込みます。既存の案件が2件以上見つかった場合は、どちらにも書き込まず「要確認」にします。 同じ学校から同じ月に2回の合宿の依頼が来ることがあるためです。

返信の下書きは Create a draft で作り、元のメールのスレッドに紐づけます。件名の先頭に【下書き・未送信】のような印は付けません。 担当者が消し忘れたまま送ると、相手に届いてしまいます。代わりに、手配表の状態が「確認中」の間は送らない運用にします。

宿泊管理システムへの連携は、この構成では行いません。客室の在庫は、人が宿泊管理システムの画面で確かめて押さえます。 手配表には、押さえた後の予約番号を人が書き込みます。

人が確認する

すべての依頼を、担当者が確認します。 手配の内容は当日の食事や部屋割りに直結し、誤りを当日まで持ち越すと取り返しがつきません。

確認を速くするため、手配表を次の順に並べます。

• 状態が「要確認」の行 … 既存の案件が複数見つかった、添付が読めない、パスワード付きのPDF。最初に見る
• 依頼の種類が「取り消し」の行 … 仮押さえの解除が遅れると、売れたはずの部屋が空いたままになる。当日中に処理する
• 変更候補がある行 … 変更前と変更後を並べて確かめる
• 新規の依頼 … 値と根拠を見比べ、返信の下書きを直して送る

確認の手順は次のとおりです。

1. 値と根拠の列を横に見て、根拠に書かれていない値がないかを確かめる
2. 人数の合計の列が、AIが読んだ「合計」と一致しているかを見る（一致しなければ、本文の読み直しが必要）
3. 不足項目が、依頼の中身から見て妥当かを確かめる
4. 返信の下書きを開き、約束の表現が入っていないかを確かめてから送る

例外に対処する

記録を残す

この記録は、項目の定義表と、返信の聞き方を直す材料になります。

• 取り込んだメールごとの抽出結果（JSON）と、そのときの項目の定義表の版
• 担当者が手配表で書き直した項目（AIの値と、直した後の値）
• 不足項目として聞き返した内容と、相手からの回答が1往復で済んだか
• 「要確認」になった理由の件数
• 依頼の受信から、最初の返信を送るまでの時間

「担当者が書き直した項目」を必ず残してください。 書き直しが多い項目は、項目の定義表の書き方が曖昧か、依頼者の書き方にくせがあるかのどちらかです。旅行会社ごとの手配書の形に合わせて前処理を足すなどの手を打つ根拠になります。