ホテルの代表メールアドレスに届くメールを、予約・問い合わせ・営業・請求・苦情に分類して担当の部署へ回し、返事が止まっているものを拾う

処理の起点を決める

代表アドレスの共有メールボックスにメールが届いたことを起点にします。 トリガーは「When a new email arrives in a shared mailbox (V2)」で、Original Mailbox Address に代表アドレスを、Folder に受信トレイを指定します。1通ごとにフローが動くので、届いてから振り分けまでが数分で済みます。

定時にまとめて処理する形にはしません。 1時間ごとにまとめると、苦情が届いてから責任者に知らせるまでに最大1時間かかります。この構成の価値は、受信箱を開く人がいない時間帯にも振り分けが進むことにあります。

返事の止まりの確認は、別のフローで2時間ごとに動かします。振り分けと同じフローに入れると、メールが届かない時間帯に確認が止まります。深夜は止め、朝7時から夜10時までに限ります。 夜中に「止まっている」と知らせても、読む人がいません。

トリガーには、50MBか管理者が決めた上限のどちらか小さいほうを超えるメールを飛ばすこと、保護されたメールや本文・添付が壊れたメールを飛ばすことがあるとされています。飛ばされたメールは受付台帳に載らないので、受信箱に残った未読の数と台帳の件数を毎日比べます。

入力データを集める

質を決めるのは、2つ目と5つ目です。 除外する送り主の一覧が無ければ、予約サイトの通知がすべてプロンプトに渡ります。取引先のドメインの一覧があれば、旅行会社からの団体の相談を、本文の書き方に関係なく営業へ回せます。

Conversation Id は必ず受付台帳に残します。 同じやり取りの続きのメールを、別の受付として数えないためです。同じ Conversation Id の2通目以降は、新しい受付にせず、既存の行に「続報あり」と付けます。

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

メールの本体は、トリガーの出力からそのまま取ります。本文は HTML で届くことが多いため、プロンプトに渡す前にテキストにします。

返事の確認は、「Get emails (V3)」で共有メールボックスの送信済みのフォルダを見ます。 このアクションには Original Mailbox Address があり、共有メールボックスのメールを取れます。ただし、宛先・送り主・件名などの絞り込みは、フォルダの最初の250通に対して行われるとされています。 送信済みが多いと絞り込みから漏れるため、フォルダ全体を探せる Search Query（Outlook の検索と同じ書き方）で、送り主のアドレス宛てのものを探します。

部署の担当者が、共有メールボックスから返事を出す運用にそろえます。 個人のアドレスから返事を出すと、共有メールボックスの側に返事の記録が残らず、返事が出ているのに「止まっている」と知らせ続けることになります。 共有メールボックスから送った返事がどのフォルダに残るかは、最初に試して確かめます。

AIへ渡す前に整形する

1. 自動の通知を除く … 送り主のアドレスが除外の一覧に当たるものは、プロンプトに渡さず「自動通知」のフォルダへ移します
2. 続報をまとめる … 受付台帳に同じ Conversation Id の行があれば、新しい受付にせず「続報あり」を付けて、その行の部署へ回します
3. 本文をテキストにする … HTML のタグを除き、引用された過去のやり取り（「-----Original Message-----」以降など）を切り落とします
4. 長さをそろえる … 本文の先頭から決めた文字数までを渡します。署名と免責の文言は、長さを食うので切り落とします
5. 取引先のドメインを当てる … 送り主のドメインが取引先の一覧にあれば、「取引先」の印を付けてプロンプトに渡します
6. 添付の有無を渡す … 添付の中身は渡しません。「添付あり」と、ファイル名だけを渡します

3番目を軽く見ないでください。 返信の繰り返しで、本文の下に過去のやり取りが何通分も付いていることがあります。そのまま渡すと、過去の苦情の文面に引きずられて、お礼のメールを苦情と判定します。

6番目で添付の中身を渡さないのは、請求書や旅券の写しが付いていることがあるからです。 振り分けに中身は要りません。

AIに処理させる

させるのは、1通ごとに種類・急ぎか・苦情か・言語・要点を判定することだけです。 返事の文面は作りません。

種類の中身は、対応表と同じ言葉で決めておきます。

苦情の「迷えば含む」は、片側に倒した判断です。 苦情でないものを苦情として支配人に知らせても、支配人が1通読むだけで済みます。苦情を苦情でないとして流すと、翌日の電話になります。

指示内容を固定する

あなたはホテルの代表メールアドレスに届いたメールを、担当の部署へ回すために
仕分ける係です。返事は書かないでください。

【種類（category）】次のどれか1つ
- reservation ... 宿泊の新規・変更・取消、人数や日程の相談
- inquiry ....... アクセス・駐車場・設備・館内のサービス・忘れ物の問い合わせ
- sales ......... 団体・法人の宿泊、宴会・会議室、旅行会社からの相談
- billing ....... 請求書・領収書の発行、支払・返金の確認、仕入先からの請求
- complaint ..... 滞在や応対への不満、改善の求め
- other ......... 求人への応募、取材の依頼、売り込み
- unknown ....... 上のどれとも決められない

【厳守事項】
- 本文に書かれていることだけで判断してください。推測で補わないでください。
- 不満の表明が少しでも含まれていれば、is_complaint を true にしてください。
  丁寧な言葉づかいでも、不満が書かれていれば true です。
  種類が reservation や billing でも、不満が含まれていれば is_complaint は true です。
- 本文に宿泊日・来館日が書かれており、それが今日（{today}）か明日なら
  is_urgent を true にしてください。日付が書かれていなければ false です。
  日付を推測しないでください。
- 送り主が取引先（{is_partner}）でも、種類は本文の内容で決めてください。
- summary は「誰が、何を求めているか」を60字以内の日本語で書いてください。
  氏名・電話番号・予約番号・カード番号を summary に書かないでください。
- language には本文の言語を書いてください。
- 迷ったときは category を unknown にしてください。それらしい種類を選ばないでください。
- 回答に JSON マークダウンを含めないでください。

【件名】{subject}
【送り主のドメイン】{sender_domain}
【添付】{attachment_names}
【本文】{body_text}

「丁寧な言葉づかいでも true」を書かないと、苦情を拾い損ねます。 ホテルに届く苦情は「大変残念に思いました」のような穏やかな書き方が多く、何も言わなければ、言葉の強さで苦情かどうかを決めてしまいます。

「種類が reservation でも is_complaint は true」も同じ理由です。 「予約の変更をお願いしたいのですが、先日の電話の対応が不十分で」というメールは、種類としては予約で、同時に苦情です。種類と苦情を別の項目にしているのは、この重なりを落とさないためです。

summary に氏名や予約番号を書かせないのは、要点を Teams のチャネルに投稿するからです。 チャネルは部署の全員が見ます。詳しい中身は、共有メールボックスのメールそのものを開いて読みます。

厳守事項の最後の1行は、JSON の検証が通らないときの対処として公式に挙げられているものです。 モデルが JSON をマークダウンで囲むと、形式の検証が通らないことがあります。

出力形式を固定する

次の形の JSON で受け取ります。

{
  "category": "reservation | inquiry | sales | billing | complaint | other | unknown",
  "is_urgent": false,
  "is_complaint": false,
  "language": "ja",
  "summary": ""
}

1つ目の理由は、受付台帳の列にそのまま入れられることです。 種類・急ぎか・苦情か・言語・要点がそれぞれ1つの列になり、部署ごと・種類ごとの件数を台帳から数えられます。

2つ目は、形式を固定できることです。 プロンプトの出力を JSON にし、JSON の例を自分で書き換えると形式が「カスタム」になり、プロンプトをもう一度テストしても形式が変わりません。 保存すると、フローではその形式が使われます。台帳の列に入れる前提なので、ここは「カスタム」で固定します。 なお、キーの無い配列のような形は使えないとされています。

3つ目は、is_urgent と is_complaint を種類と別にしていることです。 フローはこの2つを見て責任者への通知を足すだけで、種類による部署の振り分けとは独立に動きます。

受付台帳の1行は、次の列を持ちます。

システムへ連携する

フォルダへの移動は「Move email (V2)」で行います。 同じメールボックスの中のフォルダへ移すアクションで、Original Mailbox Address に共有メールボックスのアドレスを入れます。受信トレイには、まだ振り分けの済んでいないものと「要確認」だけが残ります。

予約管理システムには触れません。 予約の変更のメールを読んでも、予約そのものを変えるのは予約課の担当者です。この構成が予約に書き込む経路はありません。

コネクタには、接続ごとに60秒あたり300回という呼び出しの上限があります。繁忙期に1時間で数十通が届いても収まる量ですが、止まりの確認のフローで送信済みを1件ずつ探すと回数が増えます。 確認は未返信の行だけに絞ります。

人が確認する

人が全件を確かめる必要はありません。 部署の担当者は自分のフォルダに入ったメールを読んで返事を書くだけで、振り分けが違っていれば、そこで気づきます。

1. 「要確認」のフォルダを見る … フロント・予約の担当が、1日に数回見て、正しい部署へ移します
2. 振り分けの違いを直す … 部署の担当者が、自分宛てでないメールを受付台帳の上で正しい種類に直します。フローは直された種類の部署へ移し直します
3. 苦情の通知を受ける … 責任者は、苦情と判定されたものを読み、誰が返すかを決めます
4. 止まりの知らせを受ける … 部署の責任者が、期限を過ぎたものの担当を決め直します

2番目の記録を必ず残してください。 どの種類からどの種類に直されたかがたまると、プロンプトの種類の説明のどこが曖昧かが分かります。 宴会と宿泊の団体の境目は、たいていここで見つかります。

目標は1,800通をならして1通1分です。 振り分けが合っていれば、部署の担当者がフォルダを開いた時点で仕分けは終わっており、人が使う時間は「要確認」と直しと止まりの対応だけです。

例外に対処する

上から3行目は、ホテルではよく起きます。 種類の判定は外国語のメールでも行えますが、要点は日本語で書かせます。 部署の担当者が、本文を訳す前に何の用件かを知るためです。

最後の行が、運用の最初の1か月で最も多い問い合わせになります。 止まりの知らせを受けた担当者が「もう返した」と言うときは、たいてい個人のアドレスから返しています。

記録を残す

• 受付台帳（1通1行。種類・急ぎか・苦情か・要点・回した部署・返事の状態）
• プロンプトに渡した件名と本文の長さ、返ってきた JSON
• 振り分けを直した記録（どの種類からどの種類へ、誰が）
• 止まりの知らせを出した日時と、その後に返事が出た日時
• 除外の一覧で除いたメールの件数（送り主ごと）
• フローの実行の履歴（失敗した実行と、その理由）

3つ目の「直した記録」が、プロンプトを直す材料になります。 月に1回、直された件数を種類ごとに数え、多いところの説明を足します。

4つ目は、部署ごとの返事の速さを見る材料になります。 止まりの知らせが特定の部署に集中するなら、その部署の人手か、返事の期限の決め方に理由があります。