遺品整理の会社が依頼者から届く見積の依頼（間取り・物の量・写真・希望日）を Make で受け、下見の要否と見積の幅を整理する

処理の起点を決める

自社サイトの見積のフォームの送信と、代表アドレスへの依頼のメールの2つを起点にします。 フォームは送信のたびに Custom webhook の URL へ項目と写真の URL を送ります。メールは Gmail の Watch emails で、「見積の依頼」のラベルを見張ります。ラベルは Gmail のフィルタで、件名か本文に「見積」「遺品」「片付け」が含まれるものに付けます。

フォームの側は即時、メールの側は30分おきにします。 遺品整理の依頼は、数分を争うものではありません。ただ、退去の期限の迫った依頼をその日のうちに拾えることが大事なので、1日1回のまとめ処理にはしません。

処理が終わったメールには、ラベル「見積・処理済」を付け直します。付け直すのは受付台帳に行を書けたときだけです。

入力データを集める

質を決めるのは、下見が要る事情の一覧です。 一覧はこれまで担当の頭の中にあったもので、作業の当日に金額が変わった依頼をさかのぼると、たいていこの一覧のどれかが見落とされています。 例えば次のような表で持ちます。

フォームでは、写真ごとに「どの部屋か」を選んでもらいます。 選ばれていない写真は、AIに部屋を見立てさせますが、間取りの部屋のうち写真の無い部屋を数えるのは、部屋の選択の値でワークフローが行います。

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

写真は、Claude API の画像の入力の条件に合わせて渡します。 公式のページでは、画像は JPEG・PNG・GIF・WebP に対応し、1枚あたり base64 で 10MB まで、縦横 8000 ピクセルまでとされています。1回の要求に20枚を超える画像を入れると、1枚ごとの大きさの上限がより厳しくなるともされているので、1件の依頼の写真はフォームの10枚までに収めます。

写真は、間取りと依頼の文より前に置いて渡します。 公式のページでは、画像を文より前に置くと結果がよいとされています。写真ごとに「写真1：台所（依頼者の選択）」のような短い見出しを付け、AIが返す根拠の中で写真の番号を言えるようにします。

AIへ渡す前に整形する

1. 重複の確認 … フォームは送信の時刻とメールアドレス、メールはメッセージの ID で受付台帳を引きます
2. 写真の形式の確認 … JPEG・PNG・GIF・WebP 以外（スマートフォンの HEIC など）は、AIに渡さず、写真の撮り直しか形式の変更をお願いする下書きに回します
3. 写真の大きさの確認 … 10MB を超えるものは渡さず、同じく担当へ回します
4. 写真の枚数の確認 … メールで10枚を超えて届いたものは、部屋の選択の無いものから後ろを担当に回します
5. 期限の印 … 依頼の文とフォームの期限の欄から、期限の日付をワークフローが拾い、今日から7日以内なら印を付けます
6. AIに渡す範囲を絞る … 依頼者の名前、電話番号、物件の住所は渡しません。区域を決めるのは住所の市区町村だけで、ワークフローが行います

2番目でそのまま渡さないのは、対応していない形式を変換しようとして失敗するより、依頼者に頼むほうが早いからです。 フォームの案内に「写真は JPEG でお願いします」と書いておくと、ほとんど起きなくなります。

6番目で住所を渡さないのは、写真と住所がそろうと、故人の暮らしがそのまま分かる情報になるからです。 区分の分類には、住所は要りません。

AIに処理させる

させるのは、物の量の区分を選ぶことと、下見が要る事情の一覧に1つずつ当たるかを返すことの2つです。

no と unclear を分けるのが、この構成でいちばん大事な区別です。 仏壇が写っていないのは、仏壇が無いからか、仏間の写真が無いからかで意味がまったく違います。写真で部屋が写っていて、そこに無いと確かめられたときだけ no にさせます。 写っていない部屋の事情は unclear で、下見か写真の追加の対象です。

最後の行は、とくに守ります。 亡くなってから時間のたった部屋の片付けの依頼もあります。依頼の文にそのことが書かれていれば、AIは special_cleaning_mentioned を true にするだけで、写真から何も見立てさせません。 その依頼は責任者がすぐに読み、電話で話を聞きます。

指示内容を固定する

あなたは遺品整理の会社の見積の担当です。下に渡す依頼の文と部屋の写真から、
物の量の区分と、下見が要る事情を分類してください。
金額、品物の数、下見に行くかどうかは答えないでください。

【すること】
1. 写真ごとに、部屋の種類（居間・寝室・台所・和室・収納・ベランダ・
   物置・その他）と、その写真から見える物の量の区分を書く。
2. 全体の物の量の区分を few／normal／many／very_many から選ぶ。
   写真の無い部屋が間取りの半分を超えるときは unknown にする。
3. 下見が要る事情の一覧の番号ごとに、yes／no／unclear を書く。
   - yes：写真か依頼の文で、その事情があると確かめられる
   - no：その事情が起こりうる場所が写真に写っていて、無いと確かめられる
   - unclear：その場所が写っていない、または写真から判断できない
4. 事情ごとに、根拠にした写真の番号か依頼の文を evidence に書く。
5. 依頼の文から、期限、希望の時期、残したい物、探してほしい物、
   買取の希望を写す。

【厳守事項】
- 写っていない場所の事情を no にしない。unclear にする。
- 品物の数を数えない。区分だけを選ぶ。
- 写真に写った書類、通帳、手紙、郵便物の文字を読み取らない。書き写さない。
- 写真に写った人、遺影、写真立ての中の人について何も書かない。
- 部屋の汚れや傷みから、亡くなった状況を推し量らない。
- 依頼の文に、亡くなってから時間がたって見つかった、特殊清掃を
  頼みたい、などの申し出があれば special_cleaning_mentioned を true にし、
  それ以上は何も書かない。
- 確かめたいことは questions に、依頼者への質問の形で書く。

【下見が要る事情の一覧】{reasons}
【間取りと建物の条件】{layout}
【依頼の文】{request}
【写真】（写真1〜写真n。それぞれに依頼者が選んだ部屋の名前を付けて渡す）

「写っていない場所を no にしない」を最初に書くのは、AIが写真の範囲だけで答えを閉じようとするからです。 寝室の写真が無い依頼で、R2（大型の家具）を聞かれると、写っている居間にだけ目を向けて no と答えがちです。no が並んだ依頼は概算に回り、作業の当日に寝室の箪笥が見つかります。

書類の文字を読ませないのは、写真の端に通帳や年金の通知が写っていることが多いからです。 読み取らせなければ、出力にも台帳にも残りません。

出力形式を固定する

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

{
  "request_id": "",
  "photos": [
    { "no": 1, "room": "living", "volume": "many" }
  ],
  "volume_overall": "few | normal | many | very_many | unknown",
  "reasons": [
    { "id": "R1", "result": "yes | no | unclear", "evidence": "写真3：和室の奥に仏壇" }
  ],
  "deadline_text": "賃貸の退去が11月30日",
  "keep_items": ["アルバム"],
  "search_items": ["実印"],
  "buyback_wanted": false,
  "special_cleaning_mentioned": false,
  "questions": ["寝室の写真をお送りいただけますか。"]
}

1つ目の理由は、分類と金額・振り分けを別の層に置けることです。 見積の幅は、間取りと volume_overall で料金の表を引き、建物の加算を足してワークフローが出します。振り分けの規則は次のとおりです。

2つ目は、概算の案内の幅に根拠を添えられることです。 下書きには「1DK・物の量はふつう・エレベーターあり」のように、幅を出した区分をそのまま書きます。 依頼者が「思ったより物が多い」と感じたら、区分のところで話ができます。

3つ目は、選んだ値の照らし方を決めておけることです。 公式のページでは、構造化出力は文字列の enum の大文字・小文字までは保証しないとされています。ルーターで比べる前に、result と volume_overall を小文字にそろえます。

システムへ連携する

ルーターのルートは、責任者がすぐ見る→下見の案内→写真の追加のお願い→概算の案内→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータはフォールバックのルートが処理するとされています。特殊清掃の申し出のある依頼が、概算の案内のルートまで流れないように、責任者のルートを先頭に置きます。

下見の案内の下書きには、下見の予定表から空いた日を3つ添えます。 依頼の区域で空いている日を選び、期限が近い依頼は期限より前の日だけを選びます。

概算の案内の下書きには、作業の当日に確定することと、幅が変わりうる理由を書きます。 写真に写っていなかった物、建物の条件、処分に手間のかかる品物です。

人が確認する

見積の担当が、すべての下書きを確かめてから送ります。

1. 責任者がすぐ見る依頼を先に見る … 特殊清掃の申し出、期限の迫った依頼、区域の外です。特殊清掃の申し出は、責任者が電話で話を聞きます
2. 写真と分類を見比べる … volume_overall と事情の yes・unclear が、写真に合っているかを見ます。概算の案内に回ったものは、no の事情の根拠の写真を必ず開きます
3. 幅と下書きを確かめる … 区分と加算が依頼の条件に合っているかを見ます
4. 送る … 下書きを送り、受付台帳の送り方を書き換えます

2番目で no の根拠を開くのは、no が概算に回る理由そのものだからです。 yes と unclear は下見で確かめられますが、no の誤りは作業の当日まで分かりません。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、写真の撮り方と送り方の問題です。 フォームの案内に「部屋ごとに、入口から1枚、反対側から1枚」「押し入れは開けて1枚」と書くと、unclear がはっきり減ります。

記録を残す

• 依頼の元の項目とメールの本文、写真のファイルの保管先
• AIに渡した事情の一覧の版と、返ってきた JSON の全文と stop_reason
• ワークフローが出した見積の幅と、そのときの料金の表の版
• 送った下書きの本文と、担当が直した箇所
• 下見の結果と作業の当日の確定の金額（後から受付台帳に書き足す）

最後の行が、この構成を育てる材料です。 概算の幅と確定の金額の差が大きかった依頼をさかのぼると、見落とされた事情か、区分の見立てのずれが分かります。 事情の一覧に新しい行を足すのは、たいていこの振り返りからです。