リフォーム会社に写真付きで届く問い合わせを、工事の種類・緊急度・現地調査の要否で分類し、担当へ振り分けて初回の返信を下書きする

処理の起点を決める

フォームの通知メールに「Web相談」のラベルが付いたことを起点にします。 ラベルは Gmail のフィルタで、フォームの通知の送信元と件名の決まった文字列を条件に付けます。受付の事務が手でラベルを付ける運用にはしません。 付け忘れが、急ぐ相談の見落としに直結します。

Watch emails の実行の間隔は15分にします。 急ぐ相談を早く拾うのがこの構成の目的なので、1日数回の実行では足りません。1回で扱う件数の上限は20にします。 写真付きの問い合わせは1件ごとの処理が重いので、週明けにまとまって届いても次の実行に分けて拾います。

営業時間の外でも動かします。 夜間や休日の知らせ先は当番表で切り替えます。夜間にどこまで対応するかは会社の決まりで、この構成は知らせるところまでです。

入力データを集める

質を決めるのは、緊急度の定義です。 「急ぎ」をAIの感覚に任せると、本文の言い方の強さで決まります。「至急」と書かれた外壁の見積の依頼が急ぎになり、淡々と書かれた雨漏りが通常になります。 そこで、急ぐと扱う状態を一覧にして渡します。天井や壁から水が落ちている、水が止まらない、給湯器が止まってお湯が出ない、窓やドアが閉まらず施錠できない、といった状態の一覧です。

ガスのにおいや焦げたにおい、電気の火花についての記述は、別の扱いにします。 これらはリフォーム会社が最初に対応するものではないので、AIに対処を書かせず、safety_alert の印だけを付けさせて、当番の営業にすぐ知らせます。 返信の下書きには、ガス会社や電力会社への連絡を促す会社の決まった文を入れます。

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

写真は、上げるときに有効期限を付けます。 Files API では、アップロードのときに expires_in_seconds を付けると、3,600秒（1時間）から7,776,000秒（90日）のあいだで自動的に期限が切れるとされています。処理の最後に Delete a File で消しますが、シナリオが途中で止まったときのために1時間の期限も付けます。 Make の Upload a File でこの項目を指定できない場合は、HTTP のモジュールでアップロードの API を呼びます。

相談者の住所は、担当を決めるために市区町村までを使います。 担当表は市区町村で引くので、番地より先はAIにも担当表の検索にも渡しません。 番地は台帳にだけ残します。

AIへ渡す前に整形する

1. 重複の確認 … メッセージIDで問い合わせ台帳を引き、記録があれば止めます
2. 写真の形式の確認 … JPEG・PNG・GIF・WebP 以外（HEIC など）は Claude に渡さず、台帳に「形式の違う写真あり」と書きます
3. 写真のサイズの確認 … 1枚が大きすぎるものは渡さず、台帳に書きます
4. 写真の枚数を絞る … 1件につき最大8枚までを渡し、それを超える分は台帳に枚数だけ書きます
5. 写真に番号を付ける … 「写真1：」「写真2：」のように短い見出しを付けて、写真の前に置きます
6. 本文の切り出し … 通知メールの決まった前置きと末尾を落とし、入力の内容だけにします
7. 住所を市区町村までにする … AIに渡すのは市区町村まで。番地と電話番号は渡しません

2番目は、スマートフォンの写真でよく起きます。 機種や設定によっては写真が HEIC で保存され、そのまま添付されます。Claude はこの形式を受け付けないので、渡さずに人へ回し、返信の下書きで JPEG での送り直しを頼みます。

5番目は、公式のページの勧めに沿ったものです。 複数の画像を送るときは、それぞれに「Image 1:」のような短い見出しを付けると、指示や応答の中で名前で指せるとされています。AIが「写真3に型番のラベルが写っている」と返せば、人はその1枚だけを開けば済みます。

AIに処理させる

させるのは2つです。 1回目の呼び出しで、本文と写真から分類し、写っているものと足りない写真を返します。2回目の呼び出しで、分類と足りない写真を受けて初回の返信を下書きします。

緊急度を迷ったら urgent にするのは、急ぐ相談を通常に入れる誤りが重いからです。 通常の相談を急ぎに入れても、当番の営業が1件余計に見るだけで済みます。逆は、被害が広がるのを待つことになります。

写っているものは、見た目の言葉で書かせます。 「天井の板にしみがある」「外壁に細い線のようなひびが見える」と書かせ、「雨漏りの跡」「構造のひび」とは書かせません。

1行目が誤りやすいところです。 天井のしみの写真に、AIは「上の階の配管からの漏水と考えられます」と書きがちです。その一文が相談者に届けば、配管ではなく屋根が原因だったときに説明がつきません。

指示内容を固定する

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

あなたはリフォーム会社で、Web の相談を受け付ける事務の担当者です。
相談の本文と写真に見えることだけを使って、項目を埋めてください。
推測で埋めないでください。

【工事の種類】主なものを1つ。迷う場合は other。
- water：浴室・キッチン・トイレ・洗面・給湯器
- exterior：外壁・屋根・雨どい・ベランダ
- leak：天井や壁から水が落ちる、しみが広がる
- interior：床・壁紙・建具・間取りの変更
- outdoor：門・塀・駐車場・庭
- other：上のどれにも当てはまらない

【緊急度】下の状態のどれかに当たれば urgent。迷う場合も urgent。
{urgent_conditions}

【安全の印】ガスのにおい、焦げたにおい、火花、煙についての記述があれば
safety_alert を true にしてください。対処の方法は書かないでください。

【写真】写真ごとに、写っている場所と見えるものを、見た目の言葉で書いてください。
- 「しみがある」「ひびのような線が見える」のように書き、
  「雨漏り」「漏水」「構造のひび」など原因を表す言葉を使わないでください。
- 写真から読めない場合は unclear にしてください。

【足りない写真】工事の種類ごとに要る写真の一覧と照らし、
写真に無いものを missing_photos に入れてください。
{required_photos}

【厳守事項】
- 原因、工事の要否、見積の金額、建物の安全について書かないでください。
- evidence に、分類の根拠にした本文の文と写真の番号を入れてください。

【相談の本文】{body}
【市区町村】{city}

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

リフォーム会社から、相談をくださった方への最初の返信を書いてください。
次のことだけを書いてください。
- 相談のお礼と、内容と写真を受け付けたこと
- 担当する営業の名前（{sales_name}）と、担当から連絡すること
- 足りない写真があれば、何をどう撮ってほしいか（下の一覧のものだけ）
- 形式の違う写真があった場合は、JPEG での送り直しのお願い
- safety_alert が true の場合は、下の決まった文をそのまま入れる

【書かないこと】
- 原因の見立て、工事が要るかどうか、見積の金額や目安
- 建物が安全かどうか
- 「すぐに伺います」のような、訪問の日時を約束する言い方

【分類の結果】{classification}
【足りない写真】{missing_photos}
【安全についての決まった文】{safety_text}
【署名】{signature}

「原因を表す言葉を使わない」を写真の項目に書くのは、写っているものの欄が台帳に残り、人がそのまま返信に写すことがあるからです。 台帳の段階で原因の言葉が入っていなければ、下書きにも、人が書き足す文にも入りにくくなります。

「すぐに伺います」を禁じるのは、急ぐ相談ほどAIがこの言い方を選ぶからです。 当番の営業がその日に伺えるかは、その日の現場の予定で決まります。

出力形式を固定する

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

{
  "work_type": "water | exterior | leak | interior | outdoor | other",
  "urgency": "urgent | normal",
  "safety_alert": false,
  "site_visit": "needed | photos_first | unsure",
  "photos": [
    { "photo_no": 1, "location": "", "observation": "" }
  ],
  "missing_photos": [""],
  "evidence": { "text": "", "photo_nos": [1] }
}

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

2つ目は、写真ごとの所見を台帳に並べられることです。 photos の配列を「写真1：浴室・床のタイルに黒い線が見える」のような行にして台帳に書けば、担当の営業は写真を開く前に、どれを開けばよいかが分かります。

3つ目は、応答の終わり方を確かめられることです。 公式のページでは、stop_reason が max_tokens のときや拒否のときは、出力がスキーマに合わないことがあるとされています。通常の終わり方でなければ、急ぎの扱いにして当番の営業に知らせ、下書きは作りません。

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

システムへ連携する

ルーターのルートは、安全の印、急ぐもの、通常の順に並べます。 ルートは1本ずつ順に処理されるので、安全の印が付いたものを最初に知らせます。 フォールバックには、stop_reason が通常でないものと、どの条件にも当たらなかったものが落ち、受付の事務へ回ります。

Claude API は Make an API Call で呼びます。 Make のアプリの説明には構造化出力の設定が書かれていないため、Messages API の本文に、画像のブロック（file_id）と output_config.format を自分で書きます。

相談者への返信は、自動では送りません。 下書きを置くまでです。知らせのメールを送るのは社内の当番だけで、相談者には送りません。

人が確認する

担当の営業（急ぐものと安全の印のものは当番の営業）が、すべての下書きを送る前に確かめます。

1. 急ぐものと安全の印のものを先に見る … 当番の営業は知らせを受けたら、下書きを待たずに相談者へ電話してよいことにします。安全の印のものは、ガス会社や電力会社への連絡を促します
2. 分類の根拠の写真を開く … 台帳の所見と根拠の写真の番号を見て、その写真だけを開きます
3. 足りない写真の依頼を確かめる … 現地調査の前に本当に要る写真かを見て、要らないものは下書きから外します
4. 送る … 文面を整えて Gmail の画面から送り、台帳の状態を「送信済み」にします

受付の事務が見るのは、フォールバックと、形式の違う写真が付いたものです。 フォールバックの件数を毎週数え、多い型があれば定義を直します。

例外に対処する

上の4行が大半を占めます。 どれもAIの誤りではなく、写真の撮り方と送り方の問題です。フォームの説明に「明るいところで、全体と近くの両方を」と書き足すほうが、指示を直すより効きます。

記録を残す

• 元の通知メールのメッセージIDと、受信日時・市区町村
• 1回目の呼び出しの JSON の全文と、stop_reason
• 渡した写真の番号と、渡さなかった写真とその理由（形式・サイズ・枚数）
• Files API に上げた file_id と、削除した日時
• 下書きの本文と、担当の営業が送る前に直した箇所
• 緊急度と工事の種類を人が直した記録

4つ目を残すのは、写真を消し忘れていないかを確かめるためです。 Files API に上げた写真は、消すか期限が来るまでワークスペースに残ります。相談者の住まいの写真なので、残っているものを毎朝の点検で洗い出します。

最後の行は、緊急度の定義の見直しの材料になります。 urgent から normal に直された相談が続くなら、定義の状態の一覧が広すぎます。 逆の直しは、一覧に足りない状態があるということです。