鍵の出張サービスの受付で、電話のメモとWebのフォームから症状・鍵の種類・所在地を整理して、本人確認の案内と出動の優先度を決める

処理の起点を決める

受付のフォームと依頼フォームが送られた時点を起点にします。 どちらも送信先を Make の Custom webhook にし、フォームの種類（電話のメモか、Web の依頼か）を隠しの欄で渡します。 経路によって、依頼者への案内の届け方が違うからです。

電話のメモは、電話の途中でも一度送れるようにします。 受付のフォームに「途中で送る」のボタンを置き、症状と場所が分かった時点で送ります。分類と足りない情報が先に返ってくれば、受付はまだ電話がつながっているうちに聞き足せます。 同じ依頼の2回目の送信は、依頼の番号で前の行を書き換えます。

受信の後の返事は、Webhook response のモジュールで返します。 公式のページでは、Webhook response を途中に置くと後のモジュールの誤りが見えなくなることがあり、最後に置くと失敗を知らせられるとされています。この構成では最後に置き、受付のフォームの画面に「受け付けました」とだけ返します。 分類の結果は受付の一覧で見ます。

入力データを集める

質を決めるのは、優先度の表の作り方です。 例えば次のような表です。

いちばん上の行は、AIの分類より先に決まった語で止めます。 命に関わるおそれがあるときに救急への連絡を先に案内するのは、この会社の決まりで、AIの判断ではありません。 表に書いておくことで、夜間に1名で受けている受付も同じ対応をとれます。

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

表はすべて、AIの出力を受けた後に引きます。 AIには表の金額や優先度を渡しません。AIに渡すのは、区分の一覧（症状・鍵の種類・建物の種類・状況）だけです。 金額を見せると、分類を金額に寄せることがあります。

所在地は、AIに市区町村と町名を取り出させてから表を引きます。 電話のメモの住所は「〇〇駅の北口の近くのマンション」のように書かれることがあり、表の形に合わない住所は AI に正規化させ、取り出せなければ「所在地が足りない」として受付に返します。 推測で近くの町名を入れさせません。

AIへ渡す前に整形する

1. 決まった語の確認 … 子ども、赤ちゃん、ペット、具合、倒れて、火、ガス、などの語を依頼の文から探します。あれば最優先の印を付け、AIの結果を待たずに受付と当番へ知らせます
2. 依頼の番号の確認 … 同じ依頼の2回目の送信なら、前の行を引きます
3. 時間帯の判定 … 受付の時刻から、日中・夜間・休日を決めます
4. AIに渡す範囲を絞る … 依頼者の名前と電話番号は渡しません。依頼の文と住所の文だけにします

1番目は、AIの前にも後にも置きます。 前に置くのは、取りこぼしを防ぐためです。後にも、AIが vulnerable_inside を返したときに同じ知らせを出します。 決まった語に当たらない言い方（「息子が中で泣いている」）を、AIの分類で拾うためです。

4番目で名前を外しても、分類には困りません。 症状と場所と状況がわかれば区分は決まります。名前と電話番号は、受付の一覧と出動票にだけ載ります。

AIに処理させる

させるのは、区分への分類と、足りない情報の書き出しです。

状況だけは、迷ったら重いほうに倒させます。 ほかの項目は unknown で受付に聞き足してもらえば済みますが、閉じ込めの見落としは取り返しがつきません。 誤って重く分類したときは、受付が電話で確かめて下げます。

身分証の有無を足りない情報に入れるのは、第3章の（d）を止めるためです。 締め出しの依頼で身分証の話が出ていなければ、「身分証が室内にあるか」を受付が聞くよう、出動票に書きます。 室内にある場合の扱いは、本人確認の決まりの表にあります。

4行目は、防犯の話でもあります。 「友人の家の鍵を開けてほしい」「元の家族の家に入りたい」という依頼を、文から怪しいと判断させることはしません。本人確認の決まりで、確かめられなければ作業しないと決めておけば、AIの判断は要りません。

指示内容を固定する

あなたは鍵の出張サービスの受付の補助として、依頼の文を決まった区分に
分けます。優先度、料金、到着の時刻は決めません。

【すること】
1. 症状、鍵の種類、建物の種類、状況を、下の区分の一覧から選ぶ。
   状況は複数選んでよい。
2. 住所の文から、市区町村と町名だけを取り出す。
3. 出動の手配に足りない情報を missing に並べる。締め出しと閉じ込めで
   身分証の話が無ければ「身分証の有無と置き場所」を必ず入れる。
4. 分類の根拠にした依頼の文の一部を evidence にそのまま写す。

【厳守事項】
- 依頼の文に書かれていないことを推測で埋めない。鍵の種類や建物の種類が
  書かれていなければ unknown にする。
- 住所が取り出せなければ空にする。近くの町名を推測で入れない。
- 中に子ども・ペット・体調の悪い人がいる可能性が少しでも読み取れたら、
  vulnerable_inside を含める。迷ったら含める。
- 料金、優先度、到着の時刻、作業してよいかを書かない。
- 依頼者が住人かどうか、依頼が怪しいかどうかを判断しない。
- 依頼の文が鍵の依頼でなければ symptom を other にし、notes に
  一言で書く。

【区分の一覧】{categories}
【受付の時刻と経路】{received}
【依頼の文】{request_text}
【住所の文】{address_text}

「迷ったら含める」を状況にだけ書いているのは、ほかの項目では逆だからです。 鍵の種類を迷って dimple と書けば、作業員が違う道具を持って出ます。分からないものは unknown にさせ、受付が聞き足す形にします。 重く倒してよいのは、見落としが重い項目だけです。

「怪しいかどうかを判断しない」を書くのは、AIが気を回すからです。 何も言わなければ、「元の家」という言葉に注意の一文を添えることがあります。判断は本人確認の決まりに置き、AIには区分だけを返させます。

出力形式を固定する

次の形の JSON を返させます。

{
  "request_id": "",
  "symptom": "lockout_home | lockout_car | locked_in | lost_key | key_wont_turn | broken_key | replace | safe | other",
  "key_type": "pin | dimple | electronic | smart_key | unknown",
  "building_type": "owned_house | rental | store | car | unknown",
  "situation": ["vulnerable_inside", "waiting_outside", "elderly", "none"],
  "location": { "city": "", "town": "" },
  "missing": ["鍵の種類", "身分証の有無と置き場所"],
  "evidence": [ { "item": "situation", "text": "" } ],
  "notes": ""
}

構造化出力にする1つ目の理由は、表をそのまま引けることです。 symptom と situation と時間帯で優先度の表を、location で出動エリアの表を、symptom と key_type で料金の目安の表を、symptom と building_type で本人確認の決まりを引きます。Claude API の構造化出力は、スキーマを output_config.format に渡し、オブジェクトに additionalProperties: false を付けます。区分は enum にして、一覧の外の値が返らないようにします。

2つ目は、evidence で受付の確かめが速くなることです。 「中に子ども」と分類した根拠の文が並ぶので、受付はメモを読み直さずに済みます。根拠の文がメモに含まれていなければ、分類を使わず受付に戻します。

3つ目は、応答の終わり方を確かめられることです。 公式のページでは、stop_reason が max_tokens や refusal のときは出力がスキーマに合わないことがあるとされています。その場合は分類を使わず、受付が自分で決めます。

出動票の下書きには、表から引いた次のものを並べます。 優先度、拠点と到着の目安の幅、当番の作業員、料金の目安の内訳（出張料・作業料の幅・夜間の割増・キャンセル料のかかる時点）、本人確認で確かめるもの、受付が聞き足すこと。料金の欄には「作業の前に作業員が金額を伝え、承諾をいただいてから作業します」を必ず入れます。

システムへ連携する

ルーターのルートは、最優先を先頭に置きます。 公式のページでは、ルートは1本ずつ順に処理され、ほかの条件に当たらないデータはフォールバックのルートが処理するとされています。最優先のルートは知らせを出すだけにして短くし、そのあとに出動票を作ります。

Web の依頼者への案内は、下書きにして受付が送ります。 料金の目安と本人確認の案内は会社の約束になる文なので、受付が出動の手配を決めてから送ります。

人が確認する

全件、受付が出動票を確かめてから手配します。

1. 最優先の印を見る … 印があれば、まず依頼者に救急への連絡を案内し、当番に電話します
2. 区分と根拠を見る … evidence を読み、メモと合っているかを確かめます
3. 足りない情報を聞き足す … missing を電話で聞き、受付のフォームで送り直します
4. 料金と本人確認を伝える … 出動票の内訳を読み上げ、身分証の用意を頼みます
5. 手配する … 当番の作業員に連絡し、受付の一覧の手配の欄を埋めます

目安は、出動票を見てから手配までが1件3分です。 電話の依頼では、まだ電話がつながっているうちに3番と4番を済ませます。

例外に対処する

3行目と4行目が大半を占めます。 どちらも電話の聞き取りで減らせるので、missing の項目の多い順に、受付の聞き取りの台本を直します。

記録を残す

• 依頼の文（電話のメモとフォーム）と受付の時刻、経路
• 返ってきた JSON の全文と stop_reason
• 引いた表の行（優先度・拠点・料金・本人確認）と、表の版
• 受付が直した区分と優先度、手配の結果
• 現地で確定した料金と、依頼者に事前に伝えた内訳

最後の行を残すのは、事前の説明と現地の料金を突き合わせるためです。 料金の目安の幅を超えた依頼が続く作業の種類があれば、表の幅の見直しが要ります。