害虫駆除の業者が写真付きの問い合わせを Make で受け、虫の種類の見立てと緊急度で区分して、出動の案と返信の下書きを作る

処理の起点を決める

フォームの送信と、代表アドレスへのメールの2つを起点にします。 フォームは送信のたびに、Make のカスタム webhook の URL へ文・選択の答え・写真の URL を送ります。メールは Gmail の Watch emails で、問い合わせのラベルが付いたものを見ます。

フォームの側は即時にします。 公式のページでは、即時の webhook は届いた時点でシナリオを動かすとされています。ハチの巣の問い合わせは、届いてから受付の担当が気づくまでの時間を縮めることが目的なので、定時のまとめ処理にはしません。 メールの側は15分おきに見ます。

処理が終わったメールには、ラベル「問合せ・処理済」を付け直します。公式のページでは Gmail のアプリに Update email labels があります。付け直すのは、受付の台帳に行を書けたときだけです。

入力データを集める

質を決めるのは、フォームの選択の答えです。 「刺された人がいますか」「巣は地面からどれくらいの高さですか」「お店は営業中ですか」を、自由記述ではなく選択で聞きます。 緊急度を決めるのは、写真よりこの答えのほうです。自由記述にすると、書かれていないのか、いないのかが分かりません。

写真ごとに「何を撮ったか」を選んでもらいます。 虫・巣・フン・被害の跡・その他です。巣の写真なのか、巣の近くを飛ぶハチの写真なのかが分かると、見立ての取り違えが減ります。

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

写真は、問い合わせの文より前に置いて渡します。 公式のページでは、画像を文より前に置くと結果がよいとされています。複数の写真には「Image 1:」のような短い見出しを付けると指せるとされているので、「写真1（巣）：」「写真2（虫）：」のように、依頼者の選んだ種類つきの見出しを付けます。 AIが返す根拠の中で、写真の番号を言えるようにするためです。

写真の URL は、Claude に直接渡さずに Make で取ってから渡します。 フォームの保管先の URL は、外から開けない設定にしておくべきものだからです。

AIへ渡す前に整形する

1. 写真の形式の確認 … JPEG・PNG・GIF・WebP 以外（スマートフォンの HEIC など）は、AIに渡さず、撮り直しか形式の変更のお願いの下書きに回します
2. 写真の大きさの確認 … 10MB を超えるものは渡さず、同じく担当へ回します
3. 写真の寸法の確認 … 公式のページでは、200ピクセルに満たない小さな画像、低画質や回転した画像では誤りうるとされています。小さすぎる写真は見立てに使わず、撮り直しのお願いに回します
4. 重複の確認 … 同じメールアドレスか電話番号で、同じ日に届いた問い合わせには印を付けます
5. 緊急の答えの先取り … フォームで「刺された人・かまれた人がいる」が選ばれていれば、AIを待たずに Slack へ知らせます
6. AIに渡す範囲を絞る … 名前、電話番号、住所は渡しません。区域は住所の市区町村でワークフローが決めます

5番目をAIの前に置くのは、ここだけは一秒でも早く人に届けたいからです。 刺された人がいる問い合わせは、虫の種類の見立てを待つ理由がありません。受付の担当がすぐ電話をかけ、決められた案内をします。

3番目で撮り直しに回すのは、見立てができない写真で無理に見立てさせないためです。 撮り直しのお願いには、「虫から30センチほど離れて、明るいところで、真上から」のような撮り方の例を添えます。

AIに処理させる

させるのは、写真と文から、写っているものと見立ての候補、場所と大きさの手がかりを返すことです。

確かさの段階は、写真の写り方で決めさせます。 特徴が写っていなければ、似た虫が多い区分ほど low にします。区分の一覧に無い虫は その他 にし、名前を作らせません。

3行目と4行目は、とくに守ります。 問い合わせの中には「刺されたのですが大丈夫でしょうか」と書かれたものがあります。AIはそれに答えず、sting_mentioned を true にするだけにします。 案内は、社内で決めた文を受付の担当が電話で伝えます。

指示内容を固定する

あなたは害虫・害獣の駆除の業者の受付の補助です。
依頼者から届いた写真と問い合わせの文から、写っているものと、
虫の種類の見立ての候補を返してください。

【すること】
1. 写真ごとに、写っているものを insect／nest／droppings／damage／
   other／unclear から選ぶ。
2. 下の区分の一覧から、見立ての候補を最大3つ選び、確かさを
   high／medium／low で付ける。
   - high：その区分を見分ける特徴がはっきり写っている
   - medium：特徴の一部が写っている
   - low：形や色が似ているだけ
3. 候補ごとに、根拠にした写真の番号と特徴を evidence に書く。
4. 巣の大きさを比べられる物（手、ペットボトル、窓枠など）が写って
   いるかを書く。写っていなければ no_reference にする。
5. 依頼者に確かめたいことを、質問の形で questions に書く。

【厳守事項】
- 区分の一覧に無い名前を作らないでください。当てはまらなければ
  その他にしてください。
- 写真が暗い、ぼけている、遠い、小さいなどで見分けられないときは、
  候補を unknown にしてください。無理に選ばないでください。
- 虫の種類を言い切る書き方をしないでください。「〜の可能性」と
  書いてください。
- 急ぐかどうか、出動するかどうかを書かないでください。
- 刺された、かまれた、体調が悪いという記述があれば
  sting_mentioned を true にし、手当てや受診について何も書かないで
  ください。
- 薬剤の名前、使い方、自分で駆除する方法を書かないでください。
- 料金を書かないでください。
- 写真に写った人について何も書かないでください。

【区分の一覧】{categories}
【依頼者が選んだ場所と答え】{answers}
【問い合わせの文】{text}
【写真】（写真1〜写真n。それぞれに依頼者が選んだ種類を付けて渡す）

「無理に選ばないでください」を入れないと、AIは暗い写真でも候補を出します。 出された候補は、確かさが low でも、受付の担当には「AIがそう言った」と見えます。unknown を返せることを、はっきり許しておきます。

「自分で駆除する方法を書かない」を入れるのは、返信の下書きに入り込むのを防ぐためです。 一般的な駆除のしかたを書いた返信は、依頼者に危ない作業をさせることになりえます。

出力形式を固定する

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

{
  "inquiry_id": "",
  "photos": [
    { "no": 1, "content": "nest", "chosen_by_customer": "巣" }
  ],
  "candidates": [
    { "category": "アシナガバチ類", "confidence": "medium",
      "evidence": "写真1：下向きに開いた巣穴が並び、外側の覆いが無い" }
  ],
  "size_reference": "no_reference | 写真2：手と並んでいる",
  "indoor_outdoor": "outdoor | indoor | unclear",
  "sting_mentioned": false,
  "questions": ["巣は地面からどれくらいの高さにありますか。"]
}

公式のページでは、構造化出力は output_config.format に type: "json_schema" を指定し、オブジェクトの additionalProperties を false にします。区分の一覧は enum で渡します。文字列の enum の大文字・小文字は保証されないとされているので、英字の値は Make の側で小文字にそろえてから比べます。

1つ目の理由は、緊急度の決まりの表に機械的に当てられることです。 例えば次のような表で持ちます。

2つ目は、Router で道を分けられることです。 公式のページでは、Router の道は1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックの道で受けられるとされています。道の順番を上の表の順にし、normal をフォールバックにします。

3つ目は、返信の下書きを区分ごとの文型から作れることです。 same_day なら「本日〇時ごろ伺える見込みです。お電話でご都合をうかがいます」、retake なら撮り方の例を添えたお願い、normal なら見積の案内と候補日です。下書きの文の中に、AIの見立ては「写真からは〜の可能性があります」とだけ入れます。

システムへ連携する

Slack のボットは、受付のチャンネルに入れておきます。 公式のページでは、ボットがチャンネルに入っていないと Channel Not Found のエラーになるとされています。急ぎの知らせが届かないことに、エラーを見るまで気づかない作りにしないでください。

返信は下書きまでです。 Gmail の Send an email は使いません。送るのは、受付の担当が見立てと緊急度を確かめてからです。

人が確認する

1. call_now を最初に見る … すぐ電話をかけ、社内で決めた案内をします
2. same_day を見る … 写真で見立てを確かめ、作業の責任者と出動を決めます
3. ask と retake を見る … 電話をかけるか、撮り直しのお願いを送ります
4. normal の下書きを直して送る … 見立ての書き方が言い切りになっていないかを見ます
5. 見立てを直したら記録する … どの候補を、どの区分に変えたか

2番目で写真を見るのは、same_day が作業員の手配を動かすからです。 見立てが外れていれば、ハチの巣の高所の作業の準備をした作業員が、アリの巣の前に立つことになります。

目標は、360件をならして1件4分です。 normal の多くは下書きを読んで送るだけで2分ほど、same_day と ask は写真を見て電話をかけるので10分ほどかかる想定です。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、写真の撮り方の問題です。 フォームに撮り方の例の絵を置くと減ります。

記録を残す

• 問い合わせの文と答え、写真、受け取った日時
• 見立ての JSON の全文と、決まりの表で決まった緊急度
• 受付の担当が見立てや緊急度を直した記録
• 返信と電話の記録、出動の日時
• 作業員が現場で確かめた虫の種類

最後の行が、この構成を育てる材料です。 写真での見立てと、現場で確かめた種類を並べると、どの区分の取り違えが多いかが分かります。 取り違えの多い区分は、確かさの段階の付け方を厳しくするか、決まりの表で ask に回します。