ホテルに届く領収書の宛名変更・再発行・分割の依頼メールから、予約番号・宛名・但し書き・金額の内訳を抜き出して、フロント会計の処理票にする

処理の起点を決める

代表メールへの着信を、15分ごとの Watch emails で拾います。 依頼は日中にばらばらに届くので、1日1回にまとめると、朝に届いた依頼の返信が夕方になります。 出張手配の担当は経費の締めに合わせて依頼してくるので、受付の返信が早いほうが再度の問い合わせが減ります。

拾うメールは、件名か本文に次の語を含むものに絞ります。

「既読にする」を有効にするのは、二重に拾わないためです。 そのかわり、人が先に開いて既読にしたメールは拾われません。 代表メールを見る人には、領収書の依頼は開かずにラベルだけ付けてもらう運用にします。

拾った後で、AIが「領収書の依頼ではない」と判定したメールは、処理票に書かず、別のラベルを付けて人の受信箱に戻します。 絞り込みの語に当たっただけの、予約の問い合わせなどです。

入力データを集める

質を決めるのは、いちばん下の2つです。 依頼の種類の一覧が無いと、AIは依頼ごとに違う言葉で種類を書き、処理票を種類で絞れなくなります。 但し書きの決まりが無いと、依頼された但し書きがホテルとして書けるものかを、担当が毎回判断することになります。

過去の処理票は、同じ依頼の繰り返しを見つけるために引きます。 同じ予約番号ですでに再発行の行があれば、2回目の再発行であることを処理票に書きます。

添付は、AIには渡しません。 照合は基幹システムの記録で行うので、添付があったことだけを記録し、担当が必要なら開きます。

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

Watch emails の Content format で本文をテキストとして受け取ります。 HTML のまま渡すと、装飾のタグが長くなり、依頼の本文がその中に埋もれます。

送信者のメールアドレスは、本人確認の手がかりとして処理票に残します。 予約のときに登録されたメールアドレスと同じかどうかは、担当が基幹システムで確かめます。 違うアドレスからの依頼（会社の出張手配の担当など）は珍しくありませんが、宛名や送付先を変える依頼では、誰からの依頼かが大事になります。

AIへ渡す前に整形する

1. 本文の整形 … HTML をテキストにし、連続する空行をまとめます
2. 署名の除去 … 「-- 」以下や、会社名・電話番号が並ぶ末尾のまとまりを落とします
3. 引用の除去 … 「>」で始まる行と、「〜 wrote:」「〜 のメッセージ:」以下の過去のやり取りを落とします
4. カード番号らしき数字の伏せ字 … 13〜16桁の連続した数字は、AIに渡す前に伏せます
5. 長さの確認 … 整形した本文が極端に長いものは、先頭から一定の長さで切り、切ったことを記録します
6. 重複の確認 … 同じスレッドのIDで処理票にすでに行があれば、追記として扱います

3番目を軽く見ないでください。 引用を残したまま渡すと、前回の依頼をもう一度抜き出し、同じ宛名変更が処理票に2行並びます。

4番目は、宿泊客がカードの番号を書いてくることがあるためです。 「このカードで払った分を」と番号ごと書く人がいます。抜き出しには要らない情報で、外部へ渡す理由がありません。

AIに処理させる

させるのは、依頼メールから処理票の項目を抜き出し、確かめるべき書き方に印を付けることだけです。

右端の列が、この構成でいちばん大事な決めごとです。 予約番号が書かれていないとき、本文の日付や名前から番号を作らせません。 空欄のまま処理票に入れ、担当が基幹システムで探します。

表の1行目から3行目は、AIに判断させません。 「お品代で」が認められるかは、ホテルの決まりと税理士の助言で決めることです。AIが書くのは、その書き方が依頼にあったという事実と、根拠の一文だけです。

4行目は、印紙税の扱いに条件があるためです。 国税庁のタックスアンサーでは、売上代金の受取書は記載金額5万円未満が非課税とされ、消費税額等が区分記載されていれば、その額は記載金額に含めないとされています。質疑応答事例では、クレジットカードの利用である旨を領収書に書かないと第17号の1文書に当たるとされています。分割すると1枚ごとの金額が変わるので、担当が発行のときに決まりに沿って見ます。

指示内容を固定する

あなたはホテルのフロント会計の補助です。
宿泊客や会社の担当者から届いた、領収書についての依頼メールを読み、
処理票の項目を抜き出してください。依頼に応じるかは判断しません。

【入力】
- メール本文（署名と過去のやり取りを除いたもの）：{body}
- 件名：{subject}
- 送信者のメールアドレス：{from}
- 依頼の種類の一覧：{request_types}
- ホテルとして書ける但し書きの一覧：{allowed_purposes}

【してほしいこと】
1. このメールが領収書についての依頼かを判定してください。
   違えば is_receipt_request を false にして、ほかは空にしてください。
2. 依頼が複数の宿泊者に及ぶときは、宿泊者ごとに requests に分けてください。
3. 各依頼について、依頼の種類・予約番号・宿泊者・宿泊日・新しい宛名・
   新しい但し書き・分割の内訳・送付の方法と送付先を抜き出してください。
4. 次の書き方があれば flags に入れ、根拠になった本文の一文をそのまま写してください：
   金額の指定／日付の変更／一覧に無い但し書き／依頼者が宿泊者と違う。

【厳守事項】
- 本文に書かれていない値は空欄にしてください。推測で埋めないでください。
- 予約番号は書かれた文字列をそのまま写してください。
  日付や名前から番号を作らないでください。
- 宛名と但し書きは、書かれたとおりに写してください。
  「株式会社」の位置や略称を直さないでください。
- 金額を計算しないでください。分割の内訳は「客室料と朝食で1枚」のように、
  依頼者が書いた分け方を写してください。
- 依頼に応じてよいか、応じるべきでないかを書かないでください。
- 印紙が要るかどうかを書かないでください。
- カード番号、暗証番号に当たる文字列があっても写さないでください。

「書かれたとおりに写す」を宛名と但し書きに明記しないと、表記を整えてしまいます。 「(株)山田商事」を「株式会社山田商事」に直すのは親切に見えますが、依頼者が会社の経理に合わせて指定した表記を変えることになります。

「応じてよいかを書かない」を明記しないと、「会議費」の依頼に「不可」と書いて印を付けず、担当が依頼者に確かめる機会がなくなります。

出力形式を固定する

Make an API Call で Messages API を呼び、構造化出力で次の形のJSONを受け取ります。 Claude API の構造化出力は、output_config.format に type: "json_schema" でスキーマを渡す形で、制約付きのデコードでスキーマに沿った応答を返すとされています。

{
  "is_receipt_request": true,
  "requests": [
    {
      "request_types": ["addressee_change", "split"],
      "reservation_no": "",
      "guest_name": "",
      "stay_dates": { "check_in": "", "check_out": "" },
      "new_addressee": "",
      "new_purpose": "",
      "split_instruction": "",
      "delivery": { "method": "mail | pdf | unknown", "address": "" },
      "flags": [
        { "type": "amount_specified | date_change | purpose_not_allowed | requester_differs",
          "evidence": "" }
      ]
    }
  ]
}

request_types は addressee_change ／ purpose_change ／ reissue ／ split ／ delivery ／ other から選ばせ、スキーマの enum で縛ります。

1つ目の理由は、宿泊者ごとに処理票の行を分けられることです。 5名分のまとめての依頼も、requests の要素ごとに Add a Row を実行すれば5行に分かれます。

2つ目は、flags を処理票の列に出せることです。 印の種類と根拠の一文が列に並ぶので、担当は処理票を印のある行から順に並べ替えて開けます。

注意が2つあります。 構造化出力でも、出力がトークンの上限で切れた場合はスキーマに合わないことがあるとされています。stop_reason を見て、max_tokens で終わったものは処理票に書かず、担当へ回します。また、enum の値は大文字小文字だけが違って返ることがあるとされているので、比べるときは大文字小文字を区別しません。

処理票の1行は次の形です。

システムへ連携する

基幹システムには、つなぎません。 予約と会計の記録を読むのも、領収書を発行するのも担当の仕事です。ワークフローから基幹システムに書き込む経路を作らないことで、誤った領収書が自動で出る道を塞ぎます。

受付の返信は、下書きまでにします。 下書きの文面は、受け付けたことと、確かめたうえで発行すること、発送の目安だけを書いた定型文に、宿泊者名と依頼の種類を差し込んだものです。 AIに文面を書かせず、Make の側で組み立てます。

処理票の行は消さずに、状態の列で管理します。 Watch New Rows は空行があるとそれ以降を処理しないとされているので、後で処理票を見るシナリオを足すときに困らないようにします。

人が確認する

処理票の全行を、担当が開きます。 発行の前に必ず基幹システムで照合するので、確認を省く行はありません。減るのは、メールを読んで項目を拾う時間と、書き写す時間です。

1. 印の付いた行から開く … 金額の指定、日付の変更、一覧に無い但し書き、依頼者の違いのいずれか。根拠の一文を読み、依頼者に確かめるかを決めます
2. 予約番号で宿泊を探す … 空欄なら、宿泊者と宿泊日で探します。見つかった宿泊の会計の内訳を見て、分割の内訳が実際と合うかを確かめます
3. 元の領収書の扱いを決める … 宛名変更や分割で作り直すときは、元の領収書をどう扱うかを処理票に書きます
4. 返信の下書きを直して送る … 応じられない依頼には、理由を担当が書きます
5. 発行して、領収書の番号を処理票に書く

3番目を省かないでください。 宛名を直した領収書を出し、元の領収書がそのまま宿泊客の手元に残ると、同じ宿泊に宛名の違う領収書が2枚ある状態になります。 再発行である旨の表示、元の領収書の回収、無効にした記録のどれをとるかは、ホテルの決まりとして先に決めておきます。

印の付いた依頼に応じるかは、担当が1人で決めない運用にします。 判断に迷うものは、フロント会計の責任者に回します。

例外に対処する

上から3行目までが、最初の1か月の大半です。 どれもAIの抜き出しの問題ではなく、依頼の書き方の問題です。 ホテルのWebサイトや確認メールに、領収書の依頼に書いてほしい項目（予約番号、宿泊日、宛名、但し書き、送付先）を載せると、この3行は減ります。

記録を残す

• 元のメールのリンクと、受信日時・送信者
• AIに渡した本文（整形と伏せ字の後）と、返ってきたJSONの全文
• 処理票の行（抜き出した値と、担当が直した値の両方）
• 印の種類と、担当がどう対応したか（応じた／確かめて応じた／応じなかった）
• 元の領収書の扱いと、新しく発行した領収書の番号
• 受付の返信を送った日時と、発行して送った日時

5つ目が、この構成で最も大事な記録です。 1つの宿泊に、いつ、どの番号の領収書を、どの宛名で出したかが、再発行の依頼のたびに追えるようになります。 後から宿泊客の会社の経理や税務の確認があったとき、どの領収書が有効かを答える材料になります。

4つ目は、但し書きの決まりを見直す材料です。 同じ但し書きの依頼が毎月何十件も届くなら、一覧に足すか、断り方の定型文を作るかを責任者が決めます。