カーシェアの運営会社が利用者から届く傷・汚れ・忘れ物の報告を Make で受け、写真と内容から区分して担当に回し、次の予約の前に確かめる車を拾う

処理の起点を決める

利用者がアプリで報告を送ったことを起点にします。 自社のサーバーが報告を受け取った時点で、Make のカスタム webhook に JSON を送ります。定時にまとめて取りに行く形にはしません。 走行に関わる報告は、次の予約までの時間との勝負だからです。

webhook は即時に処理する設定にします。 公式のページでは、即時の webhook は既定で並行して動くとされています。同じ車の報告が数分の間に2件来ることがある（乗る前の傷と、乗った後の警告灯など）ので、確認待ちの一覧への書き込みは車両の番号で探してから足す形にし、2件目は同じ車の行に追記します。

サーバーからの送信が失敗したときの扱いを決めておきます。 公式のページでは、待ち行列がいっぱいのときは400、上限を超えたときは429が返るとされています。アプリの側では、200以外が返ったら時間をおいて送り直し、一定回数失敗したらサポートの受付の一覧へ直接入れます。 報告が Make に届かないまま消えることを防ぎます。

入力データを集める

質を決めるのは、既知の傷の一覧と区分の決まりです。 既知の傷の一覧が無ければ、外装の傷の報告はすべて「新しい傷」として傷の台帳の担当へ回ります。区分の決まりが無ければ、何を走行に関わる可能性として扱うかがAIの一般的な知識で決まり、運営の考える範囲とずれます。

利用者の名前と連絡先は、Claude に渡しません。 会員の番号もサーバーの側で置き換えた番号にします。区分に要るのは報告の中身と写真だけです。 利用者への返答は、サポートの担当が予約の仕組みの側で行います。

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

予約の仕組みに、車両の番号で次の予約の時刻を返す API を用意します。 自社開発の仕組みなので、次の予約の開始時刻だけを返す、読み取り専用の窓口を作ります。予約者の名前や連絡先は返させません。用意できないときは、時刻の欄を空にして確認待ちの一覧に載せ、担当が予約の仕組みで確かめます。

既知の傷の写真は、多すぎると渡しません。 1台の既知の傷が多い車では、報告の写真と同じ位置（右後ドアなど）の傷の写真だけを選んで渡します。公式のドキュメントでは、1回のリクエストに20枚を超える画像を入れると、1枚ごとの寸法の上限が厳しくなるとされています。報告の写真と既知の傷の写真を合わせて20枚以内に収めます。

AIへ渡す前に整形する

1. 必須の項目の確認 … 報告の番号、車両の番号、文か写真のどちらかがあるかを確かめる。無ければサポートの受付の一覧へ
2. 重複の確認 … 同じ報告の番号が確認待ちの一覧や台帳にあれば処理しない（アプリの送り直しで2回届くことがある）
3. 写真の枚数と形式の確認 … JPEG・PNG・GIF・WebP 以外の写真は、アプリの側で変換して送る決まりにする
4. 既知の傷の絞り込み … 利用者が選んだ位置、または報告の文に出てくる位置の語で、既知の傷を絞る
5. 画像の名前付け … 報告の写真を「報告1」「報告2」、既知の傷の写真を「既知K03」のように名前を付けて並べる
6. 次の予約までの時間の計算 … 次の予約の開始時刻から、報告の日時を引いた時間を出す

5番目の名前付けで、AIの返答と写真を結び付けます。 公式のドキュメントでも、複数の画像を送るときは「Image 1:」のような短いラベルを付けると、プロンプトや返答の中で名前で指せるとされています。「報告2 は 既知K03 と同じ位置の傷に見える」と返させれば、担当は2枚を並べて開くだけで確かめられます。

6番目は、AIには計算させません。 時刻の引き算は Make の関数で行い、確認待ちの一覧の並び順に使います。

AIに処理させる

させるのは、報告ごとに区分を1つ選び、走行への影響の目安と既知の傷との重なりを返し、担当への要点を書くことだけです。

走行への影響を possible にする範囲は、区分の決まりの一覧で決めます。 「警告灯の点灯」「タイヤの空気・損傷」「ガラスのひび・割れ」「ライトの破損」「ブレーキ・ハンドルの違和感の訴え」のように、運営が「次の予約の前に人が見る」と決めた項目の一覧です。AIはこの一覧に当てはまるかを見るだけで、走れるかどうかを判断しません。

1行目と2行目がいちばん大事な線引きです。 報告の写真から「軽い傷なので走行に支障なし」と書かせると、担当はその一文を読んで確認を省きます。 AIの役割は、決まりの一覧に当てはまるかどうかの印までにします。

指示内容を固定する

あなたはカーシェアの運営会社のサポート担当で、利用者から届いた報告を担当に振り分ける立場です。
渡された報告の文と写真、その車の既知の傷の一覧だけを見て、決まった形で返してください。

【区分の決まり】
{category_rules}
※ 走行に関わる可能性として扱う項目：{safety_items}

【報告】
利用者が選んだ区分：{user_category}　乗る前か後か：{timing}
文：{report_text}
写真：報告1〜報告{n}（画像の前に名前を付けています）

【この車の既知の傷（同じ位置のもの）】
{known_damages}（写真は 既知K01 などの名前で付けています）

【すること】
1. category を1つ選ぶ。利用者が選んだ区分ではなく、写真と文から選ぶ
2. safety を選ぶ。走行に関わる可能性として扱う項目に当てはまるものがあれば possible
3. known_match を選ぶ。傷の報告で、同じ位置に似た既知の傷があれば likely_known とし、
   matched_known_ids に既知の傷の番号を書く
4. rule_ids に、当てはまった区分の決まりの番号を書く
5. summary に、担当が写真を開く前に読む要点を1〜2文で書く。写真の名前を入れる

【厳守事項】
- 車を走らせてよいか、止めるべきかを書かないでください。
- 「軽微」「問題なし」「支障なし」といった、安全を請け合う言葉を使わないでください。
- 前の利用者の責任や、費用の負担について書かないでください。
- 写真が暗い、遠い、ぼけていて判断できないときは、safety を unknown にしてください。
  分からないことを unlikely にしないでください。
- 文と写真が食い違うとき（文は「汚れ」で写真は警告灯など）は、写真に写っているものを優先し、
  summary に食い違いを書いてください。
- 写真に写った人の顔、免許証・カード・書類の文字や番号を書き写さないでください。
  忘れ物は「財布」「カード類」のように品目だけを書いてください。
- 既知の傷と同じだと断定しないでください。likely_known は「重なりそう」という目安です。

「安全を請け合う言葉を使わない」を書いているのは、要点に「軽微な傷で走行に支障なし」と書かれると、担当がそこで判断を終えるからです。 走行への影響は safety の3つの値だけで表し、文章では評価させません。

「分からないことを unlikely にしない」は、この構成の向きを決める一文です。 夜の駐車場で撮った暗い写真の警告灯は、判断できないのが普通です。判断できないものは、走行に関わる可能性と同じ道に流し、人の目に入れます。

出力形式を固定する

構造化出力で、次の形のJSONを返させます。

{
  "report_id": "",
  "category": "exterior_damage | interior_damage | dirty | lost_item | malfunction | other",
  "safety": "possible | unlikely | unknown",
  "known_match": "likely_known | likely_new | not_applicable",
  "matched_known_ids": [],
  "rule_ids": [],
  "summary": "",
  "photo_notes": [
    { "photo": "報告2", "note": "" }
  ]
}

公式のドキュメントでは、Messages API の output_config.format に type: "json_schema" とスキーマを置き、オブジェクトには additionalProperties: false を付けるとされています。category・safety・known_match は enum で縛ります。

1つ目の理由は、Router の条件をそのまま値で書けることです。 自由な文で返されると、Router の条件に「警告灯」「ひび」といった語を並べることになり、言い回しが変わるたびに漏れます。safety が possible か unknown なら確認待ちへ、という条件は値の一致で書けます。

2つ目は、区分の誤りを数えられることです。 担当が直した区分と、AIの category を並べて残せば、どの区分の取り違えが多いかを毎週数えられます。

Router の道と条件は次のとおりです。

公式のページでは、Router の道は1つずつ順に処理され、どの条件にも当たらないものを受けるフォールバックの道を置けるとされています。1番目の道に条件の広い確認待ちを置き、走行に関わる可能性のあるものが清掃や傷の道にだけ流れることを防ぎます。 確認待ちに流れたものも、区分に応じて2〜4の道へ重ねて流します。

システムへ連携する

Slack への投稿には、ボットの接続を使います。 公式のページでは、Send a Message はボットの接続で使え、ボットが投稿先のチャンネルのメンバーでないと「Channel Not Found」のエラーになるとされています。担当ごとのチャンネルに、先にボットを入れておきます。

予約の仕組みには書き込みません。 車を止めると決めたら、運営の担当が予約の仕組みで車を使えない状態にし、次の利用者への連絡を行います。止める操作を自動にしないのは、止めた結果、次の利用者が駐車場で車に乗れなくなるからです。 その連絡と代わりの車の手配は、人が行います。

人が確認する

確認待ちの一覧に載ったものは、運営の担当が全件見ます。

1. 一覧の上から見る … 次の予約の時刻が近い順に並んでいます。予約まで2時間を切った車は、一覧の上で色を変えます
2. 写真を開いて確かめる … summary と photo_notes を読んでから写真を開きます
3. 止めるかを決める … 止めるなら予約の仕組みで手続きし、整備の手配と次の利用者への連絡をします。止めないなら理由を一覧に書きます
4. 区分の誤りを直す … AIの区分が違っていれば、一覧で直します

確認待ち以外の道に流れたものは、回った先の担当が手配のときに見ます。 清掃の担当は汚れの報告を見て清掃を手配し、写真に走行に関わりそうなものが写っていれば、確認待ちの一覧に移します。 確認待ち以外の道に流れたものを、サポートの担当が全件開くことはしません。

利用者への返答は、サポートの担当が行います。 お礼と、対応の目安を伝える定型の返答で足りるものが多く、前の利用者の責任に触れる返答はしません。

例外に対処する

事故やけがの報告は、そもそもアプリの報告フォームではなく電話で受けるべきものです。 アプリの報告に紛れ込んだときに見落とさないよう、語で拾って区分にかかわらず人へ回します。 利用者には、アプリの画面で緊急時の連絡先を示しておきます。

記録を残す

• 受け取った報告の JSON と、受け取った日時
• Claude に渡した入力（報告の文、写真の名前、既知の傷の番号）と、返ってきた JSON の全文
• Router がどの道に流したか
• 確認待ちの一覧での判断（止めた・止めなかった・その理由・判断した人・時刻）
• 担当が直した区分と、AIの区分
• 写真の URL ではなく、写真そのものの保存先（アプリの側の保存の決まりに従う）

4つ目の判断の記録が、いちばん大事なログです。 止めなかった車で後から不具合が分かったとき、いつ誰が何を見て判断したかを追えるようにします。

5つ目は、区分の決まりと指示を直す材料です。 dirty と interior_damage の取り違えのように、同じ取り違えが続くなら、区分の決まりの例を足します。