結婚式場に届く問い合わせを、希望の時期・人数・予算・見学の希望で分類し、担当プランナーへ振り分けて見学予約の返信を下書きする

処理の起点を決める

問い合わせの通知メールに「問い合わせ」のラベルが付いたことを起点にします。 ラベルは Gmail のフィルタで付けます。条件は、自社サイトのフォームの通知の送信元と件名、結婚式情報サイトごとの通知の送信元です。受付の担当が手でラベルを付ける運用にはしません。 付け忘れた問い合わせが、そのまま返信の漏れになります。

直接のメールは、送信元が決まっていないのでフィルタで拾えません。 代表アドレスに届いたメールのうち、フィルタに当たらず、社内のアドレスからでもないものに「未分類」のラベルを付け、同じシナリオで「直接のメール」として扱います。 ラベルが2つになっても、シナリオの中では経路の欄で区別します。

Watch emails の実行の間隔は15分にします。 見学の希望は早く返すほど決まりやすく、1日1回の実行では間に合いません。1回で扱う件数の上限は50にします。 大型連休の前にまとまって届いても、次の実行で残りを拾えます。

入力データを集める

質を決めるのは、経路ごとの読み方です。 結婚式情報サイトの通知メールは、入力欄が決まった順に並んでいることが多い一方、どの欄に何が入るかはサイトごとに違います。 「希望時期」「挙式予定」「検討時期」と名前が違うだけのものを、同じ「希望の時期」として読むように、経路ごとの欄の名前を指示に並べます。第3章の（a）で受付の担当の頭の中にあった読み方を、ここに書き出します。

見学枠は、カレンダーの中で「見学枠」と決まった名前の予定として入れておきます。 空いている枠と埋まった枠を、予定の名前で区別できるようにします。例えば、空いている枠は「見学枠（空き）」、押さえた枠は「見学枠：〇〇様」に書き換える運用です。この決まりが無いと、ワークフローが空きを拾えません。

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

成約者の一覧は、送信元のアドレスで引きます。 名前で引くと、旧姓と新姓、ローマ字と漢字の違いで当たりません。アドレスが一致しなかった問い合わせでも、本文に挙式日や担当の名前が書かれていれば、AIに「成約済みの可能性」として印を付けさせ、受付の担当が確かめます。

結婚式情報サイトの通知メールの送信元は、新郎新婦のアドレスではありません。 通知はサイトのシステムから届くので、本文に書かれた連絡先の欄から写した値を返信の宛先にします。 連絡先の欄が無い通知は、下書きを作らず、受付の担当がサイトの管理画面から返す一覧に回します。返信の方法は、各サイトとの取り決めに従います。

見学枠は、希望日の前後7日で探します。 希望日が書かれていなければ、受付日から14日先までを探します。拾うのは最大5件までにします。 候補が多すぎると、新郎新婦が選びにくくなります。

AIへ渡す前に整形する

1. 重複の確認 … メッセージIDで問い合わせ台帳を引き、記録があれば止めます
2. 経路の判定 … 送信元のアドレスとラベルから、自社サイト・情報サイト（サイトごと）・直接のメールを決めます
3. 本文の切り出し … 通知メールの決まった前置きと末尾の案内文を落とし、問い合わせの部分だけにします
4. 引用の除去 … 直接のメールでは、返信に付いてくる過去のやり取りの引用を落とします
5. 電話番号を外す … 分類にも下書きにも電話番号は要りません。問い合わせ台帳にだけ残します
6. 受付日の付与 … 「来月」「再来週の土曜」を読むための基準として、受付の日付と曜日を添えます

6番目は、AIに日付を計算させないための準備です。 AIには「再来週の土曜」を日付に直させず、原文のまま写させます。日付に直すのはワークフローの側で、受付日を基準に計算します。 受付日を添えるのは、計算できなかったときに人が原文と受付日を並べて読めるようにするためです。

AIに処理させる

させるのは2つです。 1回目の呼び出しで、問い合わせから種類・希望の時期・人数・予算・見学の希望を写し出して分類します。2回目の呼び出しで、分類と見学枠の候補を受けて返信を下書きします。

すべての欄で、原文と帯を両方持たせます。 帯だけでは、「80名くらい、増えるかも」の「増えるかも」が消えます。プランナーが見るのは原文で、帯は振り分けと集計に使います。

成約済みの可能性を迷ったら true にするのは、成約者を新規として扱う誤りが重いからです。 成約した新郎新婦に見学の案内を返すと、話が通っていない会場だと受け取られます。

1行目は誤りやすいところです。 予算が書かれた問い合わせに、AIは「そのご予算でしたら〇〇プランが」と書きがちです。金額に触れた一文は、そのまま会場の回答として受け取られます。

指示内容を固定する

1回目の呼び出し（分類）の指示：

あなたは結婚式場で、問い合わせを受け付ける担当者です。
問い合わせの本文に書かれていることだけを使って、項目を埋めてください。
推測で埋めないでください。

【問い合わせの種類】次から1つ選んでください。迷う場合は other。
- visit：会場の見学を希望している
- fair：ブライダルフェアに申し込んでいる
- brochure：資料の請求だけで、見学の希望が書かれていない
- booked_customer：挙式日が決まっている、担当者の名前がある、
  打合せの日程の連絡など、すでに成約した方からの連絡と読める
- sales：業者からの営業・提案
- other：上のどれにも当てはまらない

【項目ごとの決まり】
- 希望の時期・人数・予算は、本文の文をそのまま *_text に写してから、
  帯を選んでください。書かれていなければ not_stated にしてください。
- 「秋ごろ」「来年」のような書き方は、そのまま写してください。
  月や日付に言い換えないでください。
- 見学の希望日は、本文の文をそのまま visit_date_text に写してください。
  「再来週の土曜」のような書き方も、日付に直さずに写してください。
- 経路ごとの欄の名前は、下の一覧のとおりに読んでください。

【厳守事項】
- 見積の金額や目安、特典、割引について何も書かないでください。
- 成約済みかどうか迷う場合は、maybe_booked を true にしてください。
- reply_to には、本文の連絡先の欄のアドレスをそのまま写してください。
  通知メールの送信元のアドレスを使わないでください。
- evidence に、種類を選んだ根拠の文を本文からそのまま写してください。

【経路】{channel}
【経路ごとの欄の名前】{field_names}
【受付の日付と曜日】{received_date}
【問い合わせの本文】{body}

2回目の呼び出し（返信の下書き）の指示：

結婚式場から、問い合わせをくださったお二人への返信を書いてください。
次のことだけを書いてください。
- 問い合わせのお礼
- 見学の候補の日時（下の一覧にあるものだけ。一覧が空なら、
  候補の日時を書かず、ご都合のよい日を尋ねる）
- 担当するプランナーの名前（{planner_name}）
- 候補から選んで返信してほしいこと。返信をいただいてから
  見学の日時を確定すること

【書かないこと】
- 見積の金額や目安、プランの値段、特典、割引
- 一覧に無い日時
- 「ご予約を承りました」のように、見学が確定したと読める言い方
- 問い合わせに書かれていない人数・時期・予算の決めつけ

【分類の結果】{classification}
【見学の候補（ワークフローが拾った空き）】{slots}
【会場の名前と署名】{signature}

「確定したと読める言い方」を禁じないと、「ご予約ありがとうございます」で始まる下書きになります。 新郎新婦はそれを予約の完了と受け取り、返事をせずに当日来場します。 候補を示して返事をもらう、という順番を文面の上でも崩さないためです。

見学の候補は、指示の中で一覧として渡します。 AIに「空いていそうな日」を考えさせると、カレンダーに無い日を書きます。 一覧が空のときの書き方まで指示しておくと、候補の無い下書きが作られても困りません。

出力形式を固定する

1回目の呼び出しは、次の形の JSON を返させます。

{
  "inquiry_type": "visit | fair | brochure | booked_customer | sales | other",
  "season_text": "",
  "season_year": "",
  "season_band": "spring | summer | autumn | winter | month | not_stated",
  "guests_text": "",
  "guests_band": "under20 | 20_59 | 60_99 | 100plus | not_stated",
  "budget_text": "",
  "budget_band": "under200 | 200_299 | 300_399 | 400plus | not_stated",
  "visit_date_text": "",
  "visit_time_text": "",
  "fair_name": "",
  "reply_to": "",
  "maybe_booked": false,
  "evidence": ""
}

構造化出力にする1つ目の理由は、ルーターの条件にそのまま使えることです。 inquiry_type の値で分岐させるので、決まった値の外の文字が返ってくると、問い合わせがフォールバックに落ちます。 Claude API の構造化出力では、スキーマを output_config.format に渡すと、その形の JSON が応答の本文に入ります。

**2つ目は、原文の欄（*_text）と帯の欄（*_band）を分けられることです。 帯は振り分けと月ごとの集計に使い、プランナーには原文を見せます。** 帯の分け方を変えても、原文が台帳に残っていれば、過去の問い合わせを分け直せます。

3つ目は、応答の終わり方を確かめられることです。 公式のページでは、stop_reason が max_tokens のときは出力が途中で切れてスキーマに合わないことがあり、拒否のときもスキーマに合わないことがあるとされています。stop_reason を見て、通常の終わり方でなければ下書きを作らずに受付の担当へ回します。

問い合わせ台帳には、次の列を持たせます。

システムへ連携する

ルーターのルートは、次の順に並べます。 1本目は成約済みの可能性があるもの、2本目は見学とフェアの希望、3本目は資料の請求、4本目は売り込み、最後にフォールバックです。ルートは1本ずつ順に処理されるので、成約済みを先に置きます。 見学の希望を書いた成約者の連絡が、見学のルートで当番に回るのを防ぐためです。

カレンダーには書き込みません。 見学枠を押さえるのはプランナーです。ワークフローが枠を押さえる設計にすると、返事の来ない新郎新婦のために枠が埋まり続けます。

人が確認する

担当のプランナーが、すべての下書きを送る前に確かめます。 下書きのまま送られることはありません。

1. 候補の枠がまだ空いているか … カレンダーを開き、下書きの候補が埋まっていないかを見ます。下書きを作ってから送るまでに、電話で埋まることがあります
2. 分類が合っているか … 台帳の原文の欄と本文を見比べます。特に成約済みの可能性の印が付いたものは、成約者の一覧で確かめます
3. 文面を整える … 新郎新婦の書き方に合わせて、お祝いの言葉や一言を足します
4. 送る … 送信はプランナーが Gmail の画面から行い、台帳の状態を「送信済み」にします

受付の担当が見るのは、フォールバックと、連絡先の欄が無い経路のものだけです。 フォールバックに落ちた問い合わせは、種類を決めて担当に回します。フォールバックの件数を毎週数え、多い経路は欄の名前の一覧を直します。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、経路の書式とカレンダーの空きの問題です。 連絡先の欄が無い経路が多ければ、その情報サイトの通知の設定を見直すほうが効きます。

記録を残す

• 元の通知メールのメッセージIDと、受付日時・経路
• 1回目の呼び出しの JSON の全文と、stop_reason
• ワークフローが直した見学の希望日と、その計算の基準にした受付日
• 候補に出した見学枠と、その時点のカレンダーの予定の名前
• 下書きの本文と、プランナーが送る前に直した箇所
• 分類をプランナーが直した記録（種類・成約済みの可能性）

4つ目を残すのは、「候補に出した枠が実は埋まっていた」ときに原因を追うためです。 予定の名前の付け方が守られていなかったのか、送るまでに埋まったのかで、直すところが変わります。

最後の行は、指示の見直しの材料になります。 同じ経路で同じ種類の直しが続くなら、その経路の欄の名前の一覧が足りていません。