宿泊施設のキャンセル返信をClaude Codeで整える: 予約番号と個人情報を渡さない確認表

宿泊施設の予約メールで、キャンセル希望、日程変更、人数変更、返金確認が同じ受信箱に流れ込むと、フロント担当は予約番号と氏名を開いたまま返信文を作りがちです。まず直すのは、予約台帳から個人情報を抜いた「返信前チェック表」を1枚作る作業です。

この記事では、ホテル、旅館、民泊の予約担当が、Claude Codeでキャンセル返信と予約変更返信を整える流れを書きます。AIに返金可否を決めさせず、予約メール、OTA管理画面、キャンセル規定、返信テンプレートを匿名化します。

参照先は、個人情報保護委員会の法令等と観光庁の旅行取引ガイドラインです。

この記事の要点

宿泊施設のOTA管理画面、公式予約エンジン、メール受信箱、キャンセル規定を同時に見ると、返信前に必要な確認が分かれます。予約番号や氏名をAIに渡す前に、作業用のIDへ置き換えます。

• Claude Codeには、匿名化した問い合わせ文、キャンセル規定、返信テンプレートを読ませる。
• 人が見る範囲は、返金、キャンセル料、例外対応、本人確認、予約番号、カード情報、公開承認に残す。
• 3つのUse caseは、キャンセル返信、日程変更返信、OTAと公式サイトの規定差分に絞る。
• 成果は、返信前に止めたミスの数、返信までの時間、再問い合わせ数で見る。
• 主CTAは 研修・相談 に寄せる。複数スタッフで返信ルールと承認フローを見る記事だからです。

宿泊施設の業務フロー: 予約台帳から返信前チェックへ

フロント担当が今見ている具体物は、メール受信箱、OTA管理画面、予約台帳、キャンセル規定、返信テンプレートです。氏名、電話番号、予約番号、カード末尾を全部コピーすると、AI作業用の材料が危なくなります。

先に作るのは、個人情報を落とした返信前チェック表です。guest-001、booking-001のような作業用IDに変え、宿泊日、申出日、規定抜粋、返金確認の要否、返信期限だけを残します。

画面・書類	Claude Codeに渡す列	人が見る列
メール受信箱	申出種別、希望内容、受信日時	氏名、メール、電話
OTA管理画面	チャネル、プランID、規定抜粋	実予約番号、決済状態
予約エンジン	変更可否、返信期限	空室、料金差額、在庫
キャンセル規定	何日前、料率、例外の有無	約款、返金、特別対応

施設側の返信でも、発生日、金額、支払いまたは払戻しの流れが曖昧だと再問い合わせが増えます。

Claude Codeに任せる範囲と人が見る範囲

宿泊施設のキャンセル返信では、Claude Codeに「文章をきれいにして」と渡す前に、何を読ませるかを分けます。読ませるものは、匿名化した問い合わせ、規定の抜粋、返信テンプレート、確認表の列名です。作らせるものは、不足項目表、返信案、担当者確認メモです。

人が止める判断は、キャンセル料の請求、返金可否、決済処理、本人確認、特別対応、約款解釈です。台風、病気、交通機関の停止、団体予約、海外OTA経由の予約は例外が混ざります。

AI作業コピーでは、氏名、メール、電話、予約番号、決済情報、本人確認書類を抜き、必要ならサンプル値に置き換えます。

3つのUse case

宿泊施設の受信箱で多いのは、キャンセル、日程変更、規定差分です。どれも返信文だけを作ると危ないので、入力、出力、人の確認を分けます。

Use case 1: キャンセル希望メールを返信前チェック表へ落とす

• 入力: 匿名化したキャンセル希望メール、宿泊日、申出日、プランID、キャンセル規定の抜粋。
• 出力: 返金確認の要否、キャンセル料発生日、返信案、送信前に見るチェック項目。
• 人の確認: 実予約番号、本人確認、決済状態、キャンセル料、返金方法、例外対応。

読者が今日やる1手は、直近5件のキャンセル希望メールから氏名と予約番号を消し、申出日、宿泊日、規定、返信期限だけを表にする作業です。

Use case 2: 日程変更の返信で空室と料金差額をAIに決めさせない

• 入力: 匿名化した日程変更依頼、希望日、泊数、人数、プランID、公式予約エンジンの表示文。
• 出力: 確認が必要な空室、料金差額、返信文の下書き、代替案の聞き方。
• 人の確認: 空室、料金、割引、決済差額、在庫、特別プランの条件。

日程変更では、空室と料金差額をAIが補うと事故になります。返信文は「確認後に案内します」に留めます。

Use case 3: OTAと公式サイトのキャンセル規定差分を見つける

• 入力: OTA掲載文、公式予約ページ、キャンセル規定、予約確認メールのテンプレート。
• 出力: 表記ゆれ一覧、申込み前に見せるべき文、返信テンプレートの修正候補。
• 人の確認: 約款、請求主体、返金方法、OTAごとの制約、公式表示の承認。

OTAでは「キャンセル無料」が目立ち、公式サイトでは料率表が下にある、というズレが起きます。同じ条件が違う書き方になっている場所を表にします。

コピペで使えるプロンプト

予約担当のプロンプトは、先に「渡してはいけない情報」を書きます。

あなたは宿泊施設の予約返信レビュー担当です。
目的: キャンセル希望・日程変更の問い合わせを、返信前チェック表と返信案に分ける。

入力:
- 匿名化した問い合わせ文:
- 申出日:
- 宿泊予定日:
- チャネル:
- プランID:
- キャンセル規定の抜粋:
- 返信テンプレート:

出力:
1. 返信前チェック表
2. 不足している確認項目
3. キャンセル料・返金・空室・料金差額のうち人が見る項目
4. 返信案
5. 送信前に止める条件

制約:
- 氏名、メール、電話、予約番号、カード情報、住所を扱わない。
- キャンセル料、返金、空室、料金差額を推測しない。
- 例外対応を断定しない。
- 最後に「今日人が見る1行」を1つだけ出す。

動く確認コード

予約返信のチェック表は、列が足りないまま使うと危ないです。次のNode.jsコードは、作業用データに必須列と人の確認ゲートがあるか、直接の個人情報らしき文字が残っていないかを見ます。

const rows = [
  { id: "REQ-001", action: "cancel", channel: "official", guest: "guest-001", stayDate: "2026-08-12", requestDate: "2026-07-23", policy: "7 days before free", text: "Guest asks to cancel.", draft: "Staff confirms fee and refund route.", review: ["identity", "refund", "policy"] },
  { id: "REQ-002", action: "change", channel: "ota", guest: "guest-002", stayDate: "2026-09-04", requestDate: "2026-07-23", policy: "Date changes require room and price confirmation.", text: "Guest asks to move the stay.", draft: "Staff checks room and price before replying.", review: ["identity", "price", "policy"] }
];

const required = ["id", "action", "channel", "guest", "stayDate", "requestDate", "policy", "draft", "review"];
const directPersonalData = /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}|\b\d{10,}\b|booking[-_ ]?\d+/i;
const errors = [];

for (const row of rows) {
  for (const field of required) if (!row[field] || row[field].length === 0) errors.push(`${row.id}: missing ${field}`);
  if (!["cancel", "change"].includes(row.action)) errors.push(`${row.id}: unknown action`);
  if (directPersonalData.test(`${row.text} ${row.draft}`)) errors.push(`${row.id}: direct personal data may remain`);
  if (!row.review.includes("policy")) errors.push(`${row.id}: policy needs human review`);
  if (row.action === "cancel" && !row.review.includes("refund")) errors.push(`${row.id}: refund needs human review`);
  if (row.action === "change" && !row.review.includes("price")) errors.push(`${row.id}: price needs human review`);
}

if (errors.length > 0) {
  console.error(errors.join("\n"));
  process.exit(1);
}

console.log("Hotel cancellation reply checklist is ready for human review.");

このコードは予約システムではありません。作業用の表に、申出種別、宿泊日、規定抜粋、返信案、人の確認ゲートがあるかを見ます。

Pitfall: よくある落とし穴

宿泊施設のキャンセル返信で最初に起きる落とし穴は、問い合わせメールをそのままAIに貼る流れです。原因は、急ぎの返信で氏名、メール、予約番号、カード末尾が本文に残る点です。直し方は、受信文をguest-001へ置き換え、規定と希望内容だけを渡します。

二つ目は、キャンセル料をClaude Codeに補わせる流れです。原因は、規定抜粋が古い、OTAごとに条件が違う、特別プランが混ざる点です。直し方は、キャンセル料と返金を常に「要確認」列へ出し、人が確定するまで返信を止めます。

三つ目は、日程変更を通常返信と同じテンプレートで返す流れです。原因は、空室、料金差額、プラン条件が返信文に抜けるためです。直し方は、日程変更だけ「空室」「料金差額」「代替日」の3列を足します。

四つ目は、OTAと公式サイトの規定差分の放置です。原因は、ページ更新、予約エンジン、OTA掲載文を別々に直している点です。直し方は、週1回だけ規定、予約確認メール、FAQ、公式予約ページを表で照合します。

よくある質問

Q. キャンセル希望メールをそのまま貼ってよいですか。
A. 貼りません。氏名、メール、電話、予約番号、カード情報、住所を消し、guest-001のような作業用IDへ置き換えます。

Q. 返金可否の返信案までClaude Codeに作らせてよいですか。
A. 下書きは作れます。ただし、返金可否、金額、決済処理、例外対応は人が見ます。返信案には「確認後に案内します」と残し、確定文は担当者が入れます。

Q. 公式サイトとOTAで規定が違うときはどちらを使いますか。
A. AIに選ばせません。差分表を作り、施設責任者が正しい表示と修正順を決めます。

研修・相談につなげるなら

宿泊施設で複数スタッフが返信するなら、成果はPVでは測れません。返信前に止めたミスの数、初回返信までの時間、再問い合わせ数を見ます。

この表を1週間だけ使うと、どの質問が戻ってくるかが見えます。返金、日程変更、本人確認のどれで止まったかを残せば、次の研修テーマも絞れます。

この数字が追えると、研修・相談で扱う範囲がはっきりします。匿名化ルール、返信テンプレート、OTA差分表、送信前承認を、施設の運用に合わせて決めます。

予約前FAQは宿泊・観光サイトのFAQと予約導線、個人情報の境界は税理士事務所の顧問先データ安全管理も近いです。

実際に試した結果

この記事では、hotel-cancellation-reply-privacy-check-claude-code というslugで、frontmatter、本文構成、内部リンク、公式リンク、CTA、コードフェンス、最後のh2を確認しました。Node.jsの確認コードでは、2件のサンプル予約返信データに必須列と人の確認ゲートがあることを見ました。

今日まずやる1手は、直近5件のキャンセル希望メールから氏名、メール、電話、予約番号を消し、申出日、宿泊日、チャネル、規定抜粋、返信期限、人の確認列だけの表を作る作業です。その表で、返信前に止めたミスの数と再問い合わせ数を見ます。