内装工事の会社が完了の写真を Gemini で見て、仕上げ表と照らした手直しの一覧と、施主への完了の報告書の下書きを作る

処理の起点を決める

部屋の写真がそろったときに、部屋ごとに動きます。 写真を入れた人が、部屋の置き場に「そろった」の印のファイルを置くか、チャットで部屋の名前を送ると、サーバーがその部屋を処理します。写真が1枚入るたびに動かすと、まだ撮っていない面を「写っていない」と返し、撮り直しの依頼が無駄に飛びます。

手直しの後の写真は、別の合図で動きます。 職人が候補の番号を付けて後の写真を入れたら、その番号の候補だけを見比べます。番号の付いていない写真は見比べに回さず、現場監督に「どの候補の写真か」を聞く一覧に入れます。

1日に1回、写真がそろっていない部屋を数えます。 引渡しの予定日が近いのに「そろった」の印が無い部屋を、現場監督に知らせます。引渡しの前日に写真が足りないと分かる形を、ここで防ぎます。

入力データを集める

質を決めるのは、写真の撮り方と面の一覧です。 撮り方は「部屋の四隅から全体を1枚ずつ」「天井を1枚」「入口側の壁を1枚」「器具と建具の近くを1枚ずつ」と決め、写真のファイル名か撮る順番で、どの向きから撮ったかが分かるようにします。

面の一覧は、仕上げ表の行をそのまま使います。 壁が4面あっても仕上げ表に「壁：クロス」とだけあるなら、サーバーで東西南北に分けます。分けておかないと、AIは4面のうち1面だけを見て「壁は候補なし」と返せてしまいます。

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

写真と仕上げ表は、サーバーが工事のフォルダとスプレッドシートから読みます。 工事の番号でフォルダと仕上げ表の行を結び付け、部屋の名前は仕上げ表の書き方にそろえます。 写真の置き場の名前が「会議室」で仕上げ表が「会議室A」なら、対応の表で結び付けます。

Gemini API へは、部屋1つにつき1回、写真と面の一覧をまとめて渡します。 全体の写真と近くの写真を一緒に渡すと、近くの写真の傷が、どの面のものかを全体の写真と結び付けて返せます。 写真には番号と撮った向き（北東の隅から、天井、など）を添えます。

手直しの見比べでは、候補1つにつき前後の写真を1組ずつ渡します。 前の写真は候補の枠の付近を切り出したものと元の写真、後の写真は職人が撮ったものです。部屋全体を渡し直さないのは、ほかの面の新しい候補と混ざらないようにするためです。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日、無料の枠で1日）、store=false で保存しない動きにできると案内されています。store=false にすると前の回のやり取りを引き継ぐ使い方はできないので、呼び出しは毎回、必要な写真と一覧をそろえて送ります。

AIへ渡す前に整形する

1. 向きの補正 … スマートフォンの写真の向きの情報で回転しているだけのものは、画素を回転させます
2. 縮小 … 全体の写真は長い辺を1,600ピクセル程度に縮めます。近くの写真は、継ぎ目やすき間が分かるよう大きめに残します
3. 塗りつぶし … 居住中のリフォームで写った住人の顔、机の上に残った書類、表札、窓の外の隣の建物の中を塗りつぶします
4. 暗さとぶれの確認 … 照明が付いていない部屋の写真や、手ぶれの大きい写真は、AIに渡さずに撮り直しの候補にします
5. 大きさの確認 … 部屋1つ分の写真と指示の文を合わせて20MBを超えないかを見ます。超えるときは、全体の写真と近くの写真を2回に分けます
6. 面の一覧の付け足し … 仕上げ表から作った面の一覧と、写真の番号と向きの対応を指示の文に入れます

4番目を軽く見ないでください。 内装の完了のときは照明器具を付けたばかりで、電気が来ていない部屋で撮った写真が混ざります。 暗い写真では継ぎ目もすき間も分からず、AIは「候補なし」と返しがちです。暗い写真で「候補なし」と出ることが、いちばん危ない見落としです。

AIに処理させる

させるのは、面ごとに候補を枠で返すこと、写っていない面を返すこと、手直しの前後を見比べることだけです。

面ごとに clear と not_visible を分けて返させるのが、この構成の要です。 写っていない面を「候補なし」と同じに扱うと、第3章の（a）がそのまま残ります。 not_visible と partly_visible が1つでも残る部屋は、サーバーが報告書に進めず、撮り直しの依頼を出します。

1行目がいちばん起きやすい失敗です。 候補を返させると、AIは「早急に補修が必要です」「施工不良です」と書きたがります。その言葉が職人への一覧に入ると、監督が確かめる前に職人に責めの言葉が届きます。 返すのは見え方までにし、手直しにするかは、社内の基準の表とあわせて監督が決めます。

手直しの候補の付け方は、サーバーが次のように振り分けます。

指示内容を固定する

あなたは内装工事の会社で、工事の完了のときに撮った写真を見る手伝いをする係です。
この部屋の写真の番号と撮った向きは次のとおりです。
{1: 北東の隅から全体, 2: 南西の隅から全体, 3: 天井, 4: 入口側の壁, 5: コンセントの近く ...}

【この部屋の面の一覧】
{会議室A-床, 会議室A-北の壁, 会議室A-東の壁, 会議室A-南の壁, 会議室A-西の壁,
 会議室A-天井, 会議室A-巾木, 会議室A-入口の建具, 会議室A-照明・スイッチ・コンセント}
【仕上げ表の材料の種類】{床: タイルカーペット, 壁: ビニルクロス, 天井: ビニルクロス ...}

【やること】
1. 面の一覧の1行ずつについて、candidates / clear / not_visible / partly_visible の
   どれかを選ぶ。一覧にない面を足さない。一覧の面を飛ばさない。
2. 次の種類の候補を探し、写真の番号と枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。面と種類、見え方を短く書く。
   クロスの継ぎ目の開き・浮き・しわ・汚れ・破れ、巾木・見切りのすき間、
   コーキングの切れ・はみ出し、床材の傷・すき間・段差に見える所、
   プレートの傾き、養生テープ・保護シートの残り、汚れ・手あと、
   器具の付け忘れに見える所
3. 仕上げ表の材料の種類と、見た目の種類が違って見える面があれば書く。

【厳守事項】
- 写真に写っていない面を clear にしないでください。not_visible にしてください。
- 暗い写真、ぶれた写真だけで見た面は、partly_visible にしてください。
- 傷か光の反射か分からないものは、kind を unclear にして候補に入れてください。
- 手直しが必要か、施工不良か、補修の方法を書かないでください。
- すき間や段差の大きさを数字で書かないでください。
- 品番や色の番号を書かないでください。
- 職人の腕や責任について書かないでください。
- 人、書類、表札、窓の外については何も書かないでください。

「一覧の面を飛ばさない」「写っていない面を clear にしない」を並べているのは、どちらも同じ失敗を防ぐためです。 何も言わないと、AIは候補のあった面だけを返し、残りの面について何も言いません。 その沈黙をサーバーが「候補なし」と読むと、見ていない天井が報告書に「確認済み」と載ります。

手直しの前後の見比べは、別の指示で呼びます。 候補の番号、面、種類、前の写真の枠、後の写真を渡し、「前の枠の所の見え方が、後の写真で直って見えるか、まだ残って見えるか、比べられないかを選ぶ。後の写真がほかの場所を写していると思えば not_comparable にする」と指示します。「直りました」とは書かせず、見え方の比較だけを返させます。

報告書の文の下書きは、さらに別の呼び出しで作ります。 監督が確かめた結果だけを渡し、「施工した面と材料は仕上げ表の言葉をそのまま使う」「確認した範囲は写真に写った範囲と書く」「問題ありません、完璧に仕上がりました、のような言い切りをしない」を入れます。

出力形式を固定する

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

{
  "job_id": "K-2026-1043",
  "room": "会議室A",
  "surfaces": [
    { "surface": "会議室A-北の壁", "status": "candidates | clear | not_visible | partly_visible", "photos": [1, 4] }
  ],
  "findings": [
    { "photo": 4, "box_2d": [210, 640, 330, 700], "surface": "会議室A-北の壁",
      "kind": "seam_gap | lifting | wrinkle | stain | tear | baseboard_gap | caulk_break | caulk_excess | floor_scratch | floor_gap | step_looking | plate_tilt | tape_left | handprint | fixture_missing_looking | unclear",
      "note": "窓の右の縦の継ぎ目が、上の方で線のように見える" }
  ],
  "material_mismatch": [ { "surface": "会議室A-床", "note": "表はタイルカーペットだが、木目に見える" } ]
}

1つ目の理由は、surfaces をそのまま「見た面の記録」にできることです。 面の数がそろっていなければサーバーが呼び直し、not_visible と partly_visible の面は、撮り直しの一覧に自動で入ります。

2つ目は、findings に番号を振れば、手直しの指示と前後の見比べの鍵になることです。 サーバーは候補に「K-2026-1043-07」のような番号を振り、職人への一覧と後の写真の受け取りに同じ番号を使います。前後の写真が番号でつながるので、第3章の（c）がなくなります。

3つ目は、報告書の表をそのまま組み立てられることです。

システムへ連携する

職人への一覧は、監督が選んだ候補だけを送ります。 AIの候補をそのまま送ると、光の反射や家具の影まで手直しとして届き、職人の手間と監督への信頼が両方減ります。

施主への報告書は、下書きまでにします。 監督と上長が読み直してから送ります。写真に写っていない所まで「確認済み」と読める文が、施主の手元に残らないようにします。

人が確認する

1. 候補を写真で確かめる … 一覧の上から順に、印の所を見て「手直しする」「該当なし」を選びます
2. 撮り直しを頼む … not_visible、partly_visible、unclear の残る面について、撮る向きを添えて頼みます
3. 仕上げ表と見た目の違いを確かめる … 材料の種類が違って見える面は、納品書と現地の残りの材料で確かめます
4. 手直しの前後を確かめる … fixed_looking も含めて前後の組を見て、済んだかを決めます
5. 報告書を読み直す … 施工した面と材料、手直しの記録、確認した範囲の書き方を見て、上長に回します

4番目で fixed_looking を素通りしないでください。 後の写真の角度が違えば、継ぎ目の開きは見えなくなります。見比べの結果は、監督が前後の写真を開く順番を決めるためのもので、済んだかを決めるものではありません。

目標は、80件をならして1件15分です。 候補の少ない小さな原状回復は数分で済み、店舗の改装のように部屋と器具が多い工事は30分を超えます。

例外に対処する

上から2行目までが大半を占めます。 どれもAIの精度の問題ではなく、写真の撮り方と、面の一覧の作り方の問題です。 7行目は、note に「必要」「不良」や寸法の数字が入っていないかをサーバーで見ます。

記録を残す

• 部屋ごとの元の写真と、塗りつぶして AI に渡した写真
• 渡した面の一覧と、Gemini API が返した JSON
• 候補ごとに監督が付けた「手直しする」「該当なし」と、足した箇所
• 手直しの前後の写真の組と、見比べの結果、監督が「済み」とした日
• そのときの社内の手直しの基準の版、送った報告書

3つ目と4つ目が、基準を直す材料になります。 監督が「該当なし」にした候補の種類を数えると、どの見え方をAIが拾いすぎているかが分かります。協力会社ごとの手直しの件数も出せますが、職人の評価に使うかどうかは、協力会社と話してから決めます。