造園会社がお客様から届く庭の写真を Gemini で見て、剪定・伐採・除草の作業量を見立て、見積の明細の下地を作る

処理の起点を決める

15分ごとに動く時間主導型のトリガーで、受付のメールを見ます。 Google Apps Script のインストール型のトリガーには、毎分から月1回まで間隔を選べる時間主導型があります。受付のアドレスに届いた、まだラベルの付いていないメールだけを処理し、終わったら「下地済み」のラベルを付けます。 ラベルは、下地を書き終えたときだけ付けます。

インストール型のトリガーは、作った人のアカウントで動きます。 担当それぞれのアカウントで作るのではなく、受付のアドレスを持つ営業の共用のアカウントで1つだけ作ります。 作った人の異動で止まらないよう、作り直しの手順を単価表のシートの隅に書いておきます。

入力データを集める

質を決めるのは、写真の撮り方の案内です。 「木の根元から先までを1枚に入れてください」「2階の窓や塀など、高さの分かる物を一緒に入れてください」と頼んでおくと、高さの区分を目安と比べて返せる写真が増えます。 案内は、ホームページの依頼の受付の欄と、自動の受付の返信に載せます。

区分の一覧は、単価表と同じ区切りにします。 単価表が「3メートルまで」「3から5メートル」「5から7メートル」「7メートルを超えるもの」で分かれていれば、AIにもその4つの中から選ばせます。 区切りがずれると、スクリプトで単価を引けません。

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

受付のメールから、写真と本文を取ります。 スクリプトはラベルの無いスレッドを探し、メッセージごとに添付とインライン画像を Blob として取り出します。差出人のアドレスと届いた日時は、依頼の記録のシートに書き、写真は依頼ごとのフォルダに保存します。 ファイル名は、依頼の番号と届いた順の番号にします。

Gemini API へは、依頼ごとに1回、全部の写真をまとめて渡します。 公式の案内では、1つのリクエストに入れられる画像の数は多く、インラインで送るときは、文の指示と画像を合わせたリクエスト全体が20MBまでです。十数枚の写真をそのまま送ると超えることがあるので、前処理で縮めます。

単価表は、スクリプトがシートから読みます。 AIの返した区分を単価表の行と突き合わせ、単価と数量を掛けた金額は、スクリプトが見積の一覧の欄に書きます。 AIには単価表の金額を渡しません。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日）、保存しないときは store=false を付けると案内されています。お客様の家の写真を、保存させないで使います。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、HEIC などの写真だけを残し、それ以外の添付は外します
2. 向きの補正 … スマートフォンの写真の向きの情報で回転しているだけのものは、画素を回転させます。向きがずれると、返った枠がずれます
3. 縮小 … 長い辺を1,600ピクセル程度に縮めます。リクエスト全体が20MBに収まるようにします
4. 重複の除外 … 同じ写真が二度付いているものは1枚にします
5. 枚数の確認 … 1枚だけ、または全体の写真が無いと分かる依頼には、写真の追加のお願いを先に返す印を付けます
6. 写り込みの確認 … 人の顔、表札、車のナンバーが大きく写っている写真には、担当が見るときの注意の印を付けます
7. 区分の一覧の付け足し … 単価表のシートから、高さ・長さ・広さ・処分の量の区分を読み、指示に入れます

3番目を軽く見ないでください。 縮めすぎると、細い枝や生垣の先が見えなくなります。全体の写真は小さめに、木ごとの写真は大きめに残すと、費用と見分けの両方に効きます。

AIに処理させる

させるのは、写真に写っている木と範囲を拾い、それぞれを区分に当てはめ、比べた目安と、足りない写真と、現地で確かめる事項を返すことだけです。

右端の列の考え方は、区分を決められないものを、決めずに担当に返すことです。 根元が写っていない木の高さを「たぶん中木」と埋めると、見積の数字がそのまま出ていってしまいます。 分からない区分は分からないと返させ、足りない写真のお願いか、現地を見に行く理由にします。

1行目がいちばん起きやすい失敗です。 「この木の高さは何メートルですか」と聞くと、AIはもっともらしい数字を返します。写真の奥行きや撮った角度で、同じ木でも高さは大きく違って見えます。 返させるのは「2階の軒より上で、屋根の棟より下」という比べた事実と、そこから選んだ区分です。

指示内容を固定する

あなたは造園会社の見積の担当を手伝う係です。
お客様が送ってきた庭の写真が {枚数} 枚あります。写真には 1 から順に番号を付けています。
お客様の依頼の本文は次のとおりです。
{依頼の本文}

【区分の一覧】
高さ：高木の区分 {3mまで／3〜5m／5〜7m／7mを超える} 中木・低木 {…}
生垣の長さ：{5mまで／5〜10m／10〜20m／20mを超える}
除草の広さ：{10㎡まで／10〜30㎡／30〜60㎡／60㎡を超える}
処分の量：{少ない／中くらい／多い}
作業の種類：剪定、強い剪定（切り詰め）、伐採、抜根、生垣の刈り込み、除草

【やること】
1. 写真に写っている木を1本ずつ拾い、同じ木が写っている写真の番号をまとめる。
2. 木ごとに、高さの区分を上の一覧から1つ選ぶ。
   選んだ根拠として、比べた目安（2階の軒、塀、物置、人など）と、
   木の先と根元がどの写真に写っているかを書く。
3. 木ごとに、作業の候補を上の一覧から選ぶ。
   お客様の依頼の本文に無い作業を挙げるときは requested を false にする。
4. 生垣の長さと高さの区分、除草の範囲の広さの区分、処分の量の区分を選ぶ。
   広さは、駐車場1台分やブロック塀の長さなど、比べた目安を書く。
5. 足りない写真を挙げる。
6. 電線の近く、隣地へのはみ出し、道の幅、建物や塀との近さ、
   枯れや傾きのように、現地で確かめるべき事項を挙げる。

【厳守事項】
- 高さ・長さ・広さをメートルや平方メートルの数字で書かないでください。
  区分を選び、比べた目安を書いてください。
- 木の根元か先が写っていないときは、高さを height_unknown にしてください。
  推測で区分を選ばないでください。
- 区分の境に近いときは near_boundary を true にしてください。
- 金額、単価、作業の日数を書かないでください。
- 倒木の危険、病気、作業できるかどうかの結論を書かないでください。
  気になるものは現地で確かめる事項に入れてください。
- 電線が写っていなくても、写真の範囲で分からないときは
  「電線の有無は写真の範囲では分からない」と現地で確かめる事項に入れてください。
- 写っている人、家、車、表札については何も書かないでください。

「根元か先が写っていないときは height_unknown」を明記しないと、区分が埋まってしまいます。 埋まった区分は、写真を開かなければ根拠のある区分と見分けがつきません。

電線の一文を別に書いているのは、写っていないことを「無い」と読ませないためです。 写真の上の端が木の途中で切れていれば、その上に電線があるかは分かりません。分からないという事実を、毎回返させます。

出力形式を固定する

依頼ごとに、次の形の JSON で受け取ります。 height_class、work、length_class、area_class、volume_class、check_item は enum で、区分の一覧と同じ文字列に絞ります。

{
  "request_id": "R-2026-1103",
  "trees": [
    { "tree_no": 1,
      "photos": [2, 5],
      "box_2d": { "photo": 2, "box": [120, 300, 980, 520] },
      "height_class": "tall_3_5 | tall_5_7 | tall_over_7 | tall_under_3 | mid | low | height_unknown",
      "near_boundary": false,
      "compared_with": "2階の軒より上、屋根の棟より下",
      "work": ["prune", "hard_prune", "fell", "stump_removal"],
      "requested": true,
      "species_guess": "",
      "note": "" }
  ],
  "hedge": { "length_class": "10_20", "height_class": "under_2", "sides": "one | both | unknown" },
  "weeding": { "area_class": "30_60", "compared_with": "駐車場2台分ほど" },
  "disposal": { "volume_class": "medium" },
  "missing_photos": ["裏庭の全体", "1番の木の根元"],
  "site_checks": [
    { "check_item": "power_line | neighbor_overhang | access_road | near_building | dead_or_leaning", "detail": "" }
  ]
}

1つ目の理由は、区分の文字列で単価表を機械的に引けることです。 height_class が tall_5_7 なら、単価表の「高木 5〜7メートル」の行を引きます。AIの返した文字列が単価表に無ければ、スクリプトはその行に金額を入れず、担当に回します。

2つ目は、compared_with で見立ての根拠を残せることです。 担当が区分を直したとき、「2階の軒より上」を見て直したのか、別の写真を見て直したのかを、後から見直せます。第3章の（b）の、見立てが人によって違う理由を確かめる材料になります。

3つ目は、missing_photos と site_checks を明細と分けて持てることです。 返事の最初に写真のお願いや、現地を見に行く理由を書けます。

見積の一覧の下地の行は、次の形です。

システムへ連携する

お客様へのメールは、スクリプトから送りません。 概算を返すか、写真のお願いをするか、現地を見に行く日を伝えるかは、担当が決めて自分で送ります。下地の金額がそのままお客様に届く経路を作らないためです。 単価表も、共用のアカウントには閲覧だけを許します。

人が確認する

1. 担当が区分を直す … 下地の行と写真を並べ、木ごとに区分を確かめます。height_unknown と near_boundary の付いた木を先に見ます
2. 担当が作業の候補を確かめる … requested が false の作業は、お客様の依頼に無いものです。勝手に明細に入れず、提案として返事に書くかを決めます
3. 担当が現地を見に行くかを決める … site_checks に電線、隣地へのはみ出し、枯れや傾きがあれば、写真の概算では返さず、現地を見に行きます
4. 迷うものは社長に回す … 高木の伐採、重機の要りそうな抜根、管理会社の物件のまとめての依頼は、社長が見ます
5. 担当がお客様に返す … 概算、足りない写真のお願い、現地を見に行く日の候補を、自分の言葉で送ります

3番目の決まりは、AIの結果より先に会社で決めておきます。 「電線の近くの木は必ず現地を見る」「高木の伐採は必ず現地を見る」のような決まりがあれば、担当ごとに判断が分かれません。 第3章の（d）の漏れも、この決まりで防ぎます。

目標は、150件をならして1件10分です。 担当が直した区分が1件で半分を超えるなら、撮り方の案内か区分の一覧が崩れています。

例外に対処する

上から3行目までが大半を占め、どれも写真の撮り方と届き方の問題です。

記録を残す

• 依頼ごとの写真と、Gemini API が返した JSON の全文
• 指示に入れた区分の一覧（そのときの単価表の区切り）
• 担当が直した区分と、直した理由（別の写真を見た、現地で見た、など）
• 現地を見に行ったかどうかと、現地で分かった高さの区分
• お客様に概算を返した日時と、受注したかどうか
• 依頼が届いてから最初の返事までの時間

4つ目の行が、見立ての答え合わせになります。 写真の下地で tall_3_5 だった木が、現地で tall_5_7 だったなら、どの写真のどの目安で見誤ったかを、compared_with と並べて見直せます。 これを月に一度まとめると、撮り方の案内のどこを直すかが分かります。