塗装会社がお客様から届く外壁の写真を Gemini で見て、ひび・チョーキング・剥がれの一覧と見積の項目の下書きを作る

処理の起点を決める

写真付きの相談が届いたときに、1件ごとに動きます。 フォームは送信のとき、メッセージは「写真を送り終えたら『送りました』と送ってください」と案内し、その言葉を合図にします。写真が1枚届くたびに動かすと、まだ届いていない面を「写っていない」と返し、追加の写真のお願いが無駄に出ます。

合図が無いまま写真が届いて30分たったら、届いた分で動かします。 お客様が合図を送り忘れることは多く、そのまま返信が止まると、第3章の（c）が残ります。 届いた分で一覧を作り、写っていない面は追加の写真のお願いに回します。

追加の写真が届いたら、同じ案件に足して動かし直します。 前の結果は残したまま、新しく届いた面だけを見て、一覧に足します。

入力データを集める

質を決めるのは、写真の撮り方の案内です。 問い合わせの最初の返信で、「家の四方から全体を1枚ずつ」「気になる所を1メートルくらいまで近づいて1枚」「壁を指でこすった後の指先を1枚」とお願いします。指先の写真があれば、チョーキングに見えるかを写真で返せます。無ければ、チョーキングは「現地で確かめる」に回します。

対応表は、営業たちで書き出します。 候補の種類ごとに、見積に入りうる項目と、現地で測るもの（面積、ひびの長さ、シーリングの長さ）を並べます。単価は対応表に持たせず、見積を作るときに単価の表から営業が入れます。

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

写真は、フォームとメッセージの窓口からサーバーが受け取ります。 フォームは添付のファイルを、メッセージの窓口は公式の連携の機能（Webhook など）で受け取ります。窓口の製品によって写真の受け取り方と保存の期間が違うので、使っている製品に合わせて個別に作り、届いたらすぐ社内に写します。

案件の台帳との結び付けは、問い合わせの番号で行います。 フォームなら送信のときの番号、メッセージならお客様のIDで、案件の台帳の行を引きます。初めてのお客様は、台帳に仮の行を作って番号を振ります。

Gemini API へは、1件につき1回、写真と面の一覧とお客様の文をまとめて渡します。 写真には番号と、分かれば撮った面（お客様が「北側です」と書いていればそれ）を添えます。面が分からない写真は、AIに面の見当を付けさせ、face_guess として返させます。 見当が外れることを前提に、営業が確かめる欄に入れます。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日、無料の枠で1日）、store=false で保存しない動きにできると案内されています。store=false にすると前の回のやり取りを引き継ぐ使い方はできないので、追加の写真で動かし直すときも、前の結果をサーバーから渡し直します。

AIへ渡す前に整形する

1. 向きの補正 … スマートフォンの写真の向きの情報で回転しているだけのものは、画素を回転させます
2. 縮小 … 全体の写真は長い辺を1,600ピクセル程度に縮めます。近くの写真は、細いひびが分かるよう大きめに残します
3. 塗りつぶし … 写り込んだ家族や通行人の顔、表札、郵便受けの名前、車のナンバー、隣の家の窓の中を塗りつぶします
4. 暗さと逆光の確認 … 逆光で壁が黒くつぶれた写真や、夜に撮った写真は、AIに渡さずに追加の写真のお願いの候補にします
5. 重複の確認 … 同じ写真が2回届いていれば1枚にします
6. 大きさの確認 … 1件分の写真と指示の文を合わせて20MBを超えないかを見ます。超えるときは面ごとに分けます

3番目を省かないでください。 お客様の写真には、家族、近所の家、道を歩く人が写り込みます。お客様が同意して送った写真でも、写り込んだ人は同意していません。塗りつぶした写真だけを渡し、現地調査の資料にも塗りつぶした写真を使います。

4番目も同じくらい効きます。 南の面を昼に撮ると、逆光で北の面の写真は暗くなりがちです。暗い写真で「傷みなし」と出ると、第3章の（d）と同じ見落としになります。

AIに処理させる

させるのは、面ごとに傷みの候補を枠で返すこと、写っていない面と写真では分からないことを返すこと、返信の文の下書きを作ることだけです。

面ごとに none_seen と not_visible を分けて返させるのが、この構成の要です。 写っていない面を「候補が見えない」と同じに扱うと、第3章の（d）がそのまま残ります。 not_visible と partly_visible が残る件は、サーバーが返信の下書きに追加の写真のお願いを入れます。

「写真では分からないこと」を必ず返させるのは、返信と現地調査の両方で使うためです。 返信では「現地で確かめます」と書く材料になり、現地調査では確かめる事項の一覧になります。

1行目と5行目が、いちばん起きやすい失敗です。 色あせやひびを見せると、AIは「早めの塗り替えをおすすめします」「放置すると雨漏りの原因になります」と書きたがります。その言葉が返信に入ると、写真1枚で工事を急がせる文になります。 返すのは見え方までにし、工事が要るかは現地で確かめてから営業が話します。

指示内容を固定する

あなたは外壁の塗装会社で、お客様から届いた写真を見る手伝いをする係です。
写真の番号と、お客様が書いた面は次のとおりです（書かれていない写真もあります）。
{1: 全体（面の記載なし）, 2: 南側, 3: 南側の窓の下の近く, 4: 指でこすった後の指先 ...}
お客様の文：{壁に線のようなひびがあり、触ると白い粉が付きます。築15年、前の塗装は不明}

【面の一覧】
{南の面, 東の面, 北の面, 西の面, ベランダの内側, 付帯部（雨どい・破風・軒天・水切り）, 屋根}

【やること】
1. 面の一覧の1行ずつについて、candidates / none_seen / not_visible / partly_visible
   のどれかを選ぶ。一覧にない面を足さない。一覧の面を飛ばさない。
2. 面の記載が無い写真は、どの面に見えるかを face_guess に書く。分からなければ unknown。
3. 次の種類の候補を探し、写真の番号と枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。面と種類、見え方を短く書く。
   ひび、チョーキングに見える粉、塗膜の剥がれ・膨れ、シーリングの切れ・すき間、
   こけ・かび・藻、さび、色あせ、汚れの筋
4. 写真では分からないことを、cannot_tell にすべて書く。

【厳守事項】
- 写真に写っていない面を none_seen にしないでください。not_visible にしてください。
- 遠くからの写真だけ、暗い写真だけで見た面は partly_visible にしてください。
- ひびか汚れの筋か分からないものは、kind を unclear にしてください。
- チョーキングは、指先の写真に白い粉が見えるときだけ候補にしてください。
  指先の写真が無ければ cannot_tell に入れてください。
- ひびの幅や深さ、面積を数字で書かないでください。
- 劣化の程度、塗り替えが必要か、工事の項目、金額を書かないでください。
- 急いだほうがよい、放置すると危ない、のような言葉を書かないでください。
- 人、表札、車、近所の家については何も書かないでください。

「一覧の面を飛ばさない」「写っていない面を none_seen にしない」を並べているのは、どちらも同じ失敗を防ぐためです。 何も言わないと、AIは写真のあった面だけを返し、残りの面について何も言いません。 その沈黙をサーバーが「傷みなし」と読むと、北の面について何も書かない返信になります。

チョーキングの条件を書いているのは、写真で言い切らないためです。 白っぽく色あせた壁は、遠くの写真ではチョーキングと見分けがつきません。第3章の（b）の「写真で言い切って現地で食い違う」は、ここから起きます。

返信の文の下書きは、別の呼び出しで作ります。 営業が確かめる前の一覧と cannot_tell を渡し、「写真で見えたことは『〜に見えます』と書く」「写真では分からないことは『現地で確かめます』と書く」「写っていない面は撮影をお願いする」「工事の要否、金額、急ぐべきかを書かない」を入れます。営業はこの下書きを、確かめた結果に合わせて直してから送ります。

出力形式を固定する

1件ごとに、次の形の JSON で受け取ります。 status、kind は enum で決まった文字列に絞り、faces は面の一覧と同じ数を minItems・maxItems で求めます。

{
  "inquiry_id": "Q-2026-1187",
  "faces": [
    { "face": "南の面", "status": "candidates | none_seen | not_visible | partly_visible", "photos": [2, 3] }
  ],
  "photo_faces": [ { "photo": 1, "face_guess": "東の面" } ],
  "findings": [
    { "photo": 3, "box_2d": [480, 220, 700, 260], "face": "南の面",
      "kind": "crack | chalking_looking | peeling | blister | sealant_break | moss_mold | rust | fading | stain_streak | unclear",
      "note": "窓の下の角から斜め下へ、線のように見える" }
  ],
  "cannot_tell": ["ひびの幅と深さ", "北の面と西の面の状態", "塗膜の浮き", "塗る面積"],
  "material_looking": "siding | mortar | unknown"
}

1つ目の理由は、faces をそのまま追加の写真のお願いにできることです。 not_visible と partly_visible の面を、サーバーが「北の面を全体から1枚お願いします」のような文にします。

2つ目は、findings の種類から見積の項目の候補を機械的に引けることです。 サーバーは対応表で次のような下書きを作ります。

数量の欄は、すべて「現地で測る」にします。 写真から面積や長さを出さないのは、その数字が見積の金額にそのまま入るからです。 単価も下書きに入れず、現地調査の後に営業が単価の表から入れます。

3つ目は、cannot_tell をそのまま現地調査の確かめる事項の一覧にできることです。 営業は現地で、この一覧の上から確かめます。

システムへ連携する

お客様への返信は、営業が送ります。 AIの下書きをそのまま自動で送ると、営業が確かめる前の見立てがお客様に届きます。写真の見え方を言い切った文が一度届けば、現地で違っても取り消せません。

見積の書式へは書き込みません。 見積は現地調査の後に営業が作り、写真の段階の下書きは案件の台帳の欄にとどめます。

人が確認する

1. 写っていない面と face_guess を先に見る … 面の見当が合っているかを確かめ、追加の写真のお願いを決めます
2. 候補を写真で確かめる … 印の所を見て、「候補として残す」「該当なし」を選びます
3. 見積の項目の下書きを確かめる … 対応表から引いた項目を、お客様の文と写真に合わせて足し引きします
4. 返信の下書きを直す … 見えたことと現地で確かめることが分かれているか、急がせる言葉が無いかを見ます
5. 返信を送り、現地調査の日を決める

4番目を省かないでください。 返信はお客様が最初に受け取る会社の言葉で、写真で言い切ったり、急がせたりした文は、そのまま会社の印象になります。

目標は、150件をならして1件8分です。 写真の少ない相談は数分で済み、アパートのように面と付帯部が多い相談は10分を超えます。

例外に対処する

上から2行目までが大半を占めます。 どれもAIの精度の問題ではなく、お客様の撮り方と、撮り方の案内の問題です。 6行目は、note と返信の下書きに「必要」「危険」「早め」「放置」の言葉や数字が入っていないかをサーバーで見ます。

記録を残す

• お客様の元の写真と、塗りつぶして AI に渡した写真、届いた日時
• 渡した面の一覧と相談の文、Gemini API が返した JSON
• 候補ごとに営業が付けた「残す」「該当なし」と、直した返信の文
• 対応表から引いた見積の項目の下書きと、そのときの対応表の版
• 現地調査で確かめた結果（写真の見立てと違った点）

最後の行が、撮り方の案内と対応表を直す材料になります。 写真で「ひびに見える」としたものが現地で汚れだった件を数えると、AIが拾いすぎている種類が分かります。写真の見立てと現地の結果の違いは、営業の評価ではなく、案内と指示を直すために使います。