コインパーキングの精算機の故障と利用者の苦情の通報を Make で受け、内容で分けて現地の巡回担当に割り振る

処理の起点を決める

受付のフォームと QR コードの通報フォームが送られた時点を起点にします。 どちらも送信先を Make の Custom webhook にし、経路（電話のメモか QR コードか）と、QR コードなら駐車場の番号と精算機の番号を隠しの欄で渡します。 QR コードのアドレスに番号を入れておくのは、場所の特定をAIに任せないためです。

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

受信の返事は、Webhook response のモジュールで返します。 公式のページでは、このモジュールを途中に置くと後のモジュールでの誤りがシナリオを止めず、通知に気づけないことがあり、最後に置けばどこで誤りが起きても通知されるとされています。この構成では最後に置き、QR コードのフォームの画面には「受け付けました。担当から折り返します」とだけ返します。 利用者の画面に分類の結果は出しません。

入力データを集める

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

いちばん上の行は、AIの分類より先に決まった語で止めます。 事故やけがの通報で警察や救急への連絡を先に案内するのは、この会社の決まりと受付の判断で、AIの判断ではありません。 表に書いておくことで、委託先の受付も同じ対応をとれます。

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

駐車場の特定は、AIより先に表で行います。 QR コードの通報なら番号で1件に決まります。電話の通報で番号が無いときだけ、メモの中の目印の語（駅名、コンビニ、病院の名前）で台帳の「目印」の列を引き、候補を受付に並べます。 候補が2件以上なら、受付が電話で確かめます。AIに「どの駐車場か」を決めさせないのは、近くの別の駐車場に巡回員を出すと、往復の時間がそのまま利用者の待ち時間になるからです。

表はすべて、駐車場が決まった後、AIの出力を受けてから引きます。 AIには優先度の表を渡しません。AIに渡すのは、区分の一覧と、その駐車場の設備の種類（ロック板式かゲート式か、支払い手段）だけです。 設備の種類を渡すのは、「板が上がったまま」という言い方をロック板の不具合として分けるためです。

AIへ渡す前に整形する

1. 決まった語の確認 … 出られない、出庫できない、ロック板、ゲートが開かない、事故、ぶつけ、けが、煙、などの語を通報の文から探します。あれば最優先の印を付け、AIの結果を待たずに受付へ知らせます
2. 受付番号の確認 … 同じ通報の2回目の送信なら、前の行を引きます
3. 駐車場の特定 … 番号があれば台帳を1件引き、無ければ目印で候補を並べます
4. 時間帯の判定 … 受付の時刻から、日中・夜間・休日を決めます
5. AIに渡す範囲を絞る … 利用者の名前、電話番号、車のナンバーは渡しません。通報の文と、駐車場の設備の種類だけにします

1番目は、AIの前にも後にも置きます。 前に置くのは、取りこぼしを防ぐためです。後にも、AIが exit_blocked: true を返したときに同じ知らせを出します。 決まった語に当たらない言い方（「板が上がったままで動かせない」「バーが下りたまま」）を、AIの分類で拾うためです。

AIに処理させる

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

出庫の可否だけは、迷ったら重いほうに倒させます。 ほかの項目は other や none で受付に聞き足してもらえば済みますが、出られない利用者の見落としは、そのまま待ち時間になります。 誤って blocked に分けたときは、受付が電話で確かめて下げます。

料金の苦情の中身を分けるのは、料金の担当の確かめ方が違うからです。 最大料金が適用されないなら入庫と出庫の時刻と最大料金の条件を、アプリの表示と違うならアプリの料金表と精算機の設定を見ます。

4行目は、何も言わないと起きます。 AIは「差額をお返しします」と書きがちなので、区分だけを返させ、返事の下書きは作らせません。

指示内容を固定する

あなたは時間貸駐車場の運営会社の受付の補助として、利用者からの通報の
文を決まった区分に分けます。急ぐ度合い、回し先、料金が正しいかは
決めません。

【すること】
1. 区分、出庫の可否、設備の部位を、下の区分の一覧から1つずつ選ぶ。
2. 区分が fee_complaint か lost_ticket なら、料金の苦情の中身を選ぶ。
3. 出動や確認に足りない情報を missing に並べる。出庫の可否が分からな
   ければ「いま出庫できるか」を必ず入れる。精算機の不具合で支払い手段
   の話が無ければ「ほかの支払い手段（カード・電子マネー）の有無」を
   入れる。
4. 分類の根拠にした通報の文の一部を evidence にそのまま写す。

【厳守事項】
- 通報の文に書かれていないことを推測で埋めない。部位が書かれていな
  ければ none にする。
- いま車を出せない可能性が少しでも読み取れたら、exit_status を
  blocked にする。迷ったら blocked にする。
- けが、煙、事故、接触の話があれば区分を accident にする。
- 料金が正しいか、返金や減額をするか、どちらに過失があるかを書かない。
- 利用者への返事の文を書かない。
- 駐車場の名前や番号を推測しない。駐車場の特定はしない。
- 通報が駐車場の話でなければ category を other にし、notes に一言で
  書く。

【区分の一覧】{categories}
【この駐車場の設備の種類】{device_type}
【受付の時刻と経路】{received}
【通報の文】{report_text}

「迷ったら blocked」を出庫の可否にだけ書いているのは、ほかの項目では逆だからです。 部位を迷って bill と書けば、巡回員はお札の詰まりを直す道具だけを持って出ます。分からないものは none にさせ、受付が聞き足す形にします。 重く倒してよいのは、見落としが重い項目だけです。

出力形式を固定する

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

{
  "report_id": "",
  "category": "exit_device | payment_device | change_overpay | fee_complaint | lost_ticket | accident | nuisance_parking | facility | other",
  "exit_status": "blocked | ok | unknown",
  "device_part": "lock_plate | gate | bill | coin | card | ticket | display | none",
  "fee_issue": "max_fee_not_applied | special_period | app_mismatch | lost_ticket_fee | other | ",
  "space_no": "",
  "missing": ["いま出庫できるか", "ほかの支払い手段の有無"],
  "evidence": [ { "item": "exit_status", "text": "" } ],
  "notes": ""
}

構造化出力にする1つ目の理由は、表をそのまま引けることです。 category と exit_status に台帳の設備と時間帯を合わせて優先度の表を引きます。Claude API の構造化出力は、スキーマを output_config.format（type: json_schema）に渡し、オブジェクトには additionalProperties: false を付けます。区分は enum にして、一覧の外の値が返らないようにします。 公式のページでは、enum の大文字・小文字は保証されないとされているので、表を引くときは小文字にそろえてから比べます。

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

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

出動の依頼の下書きには、表と台帳から引いた次のものを並べます。 駐車場の名前と所在地、精算機の番号、車室の番号、区分と部位、急ぐ度合い、利用者の折り返し先、拠点からの所要時間、オーナーへの連絡の要否、受付が聞き足したこと。

システムへ連携する

ルーターのルートは、最優先を先頭に置きます。 公式のページでは、ルートは並行ではなく1本ずつ順に処理され、ほかのどの条件にも当たらないデータはフォールバックのルートが処理するとされています。最優先のルートは知らせを出すだけにして短くし、そのあとに出動の依頼の下書きを作ります。 フォールバックには、駐車場が特定できなかった通報と、分類が使えなかった通報が落ちます。

巡回員への依頼は、最優先以外は下書きにして受付が送ります。 遠隔の操作で済む通報に巡回員を出さないためです。受付が遠隔で解決したときは、下書きを送らずに受付の一覧の手配の欄に「遠隔で解決」と書きます。

人が確認する

全件、受付が区分と回し先を確かめてから手配します。

1. 最優先の印を見る … 印があれば、まず利用者に電話をつなぎ、遠隔で操作できる駐車場なら管理画面で操作します。事故やけがなら警察や救急への連絡を案内します
2. 駐車場を確かめる … 候補が並んでいれば、利用者に精算機の番号を読んでもらって1件に決めます
3. 区分と根拠を見る … evidence を読み、メモと合っているかを確かめます
4. 足りない情報を聞き足す … missing を電話で聞き、受付のフォームで送り直します
5. 手配する … 巡回員への依頼の下書きを確かめて送るか、料金の担当へ回し、受付の一覧の手配の欄を埋めます

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

例外に対処する

2行目と3行目が大半を占めます。 前者は QR コードの通報を増やすことで、後者は遠隔の操作の結果を受付の一覧に残すことで減らせます。

記録を残す

• 通報の文（電話のメモとフォーム）と受付の時刻、経路、駐車場の番号と精算機の番号
• 返ってきた JSON の全文と stop_reason
• 引いた表の行（優先度・設備・当番）と、表の版
• 受付が直した区分と回し先、手配の結果（遠隔で解決・巡回・料金の担当・翌日）
• 巡回員の到着の時刻と、現地で分かった原因

最後の行を残すのは、駐車場ごと・精算機ごとの故障の傾向を見るためです。 同じ精算機でお札の詰まりが月に何度も出ていれば、通報を分ける前に、機器の保守会社に点検を頼むべき機械です。