畳店がお客様から届く畳の写真を Gemini で見て、表替え・裏返し・新調の目安と見積の下書きを作る
お客様や管理会社から届く畳の写真から、色あせ・すり切れ・シミやカビのように見える箇所・縁のほつれ・へこみの候補と、写っている畳の枚数の候補を拾います。店の決まりで表替え・裏返し・新調の目安を付け、概算の見積の下書きを作ります。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- その他/不動産/建設
- 対象部門
- 営業
- 対象業務
- 内容確認・チェック/書類作成
- 主な課題
- 人手が足りない/属人化している/書類作成に時間がかかる
- AIで行う処理
- 画像認識
- 主な効果
- 品質標準化/対応スピード向上/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 受付の担当が、ホームページの受付の欄とメールに届いた依頼を見て、顧客の台帳に書く
- 写真を職人に回し、職人が夕方に写真を見て、傷みと工事の種類の見立てを口で伝える
- 受付の担当が、写真の部屋の畳の枚数を数え、お客様の書いた枚数と比べる
- 単価表を見て、工事の種類と等級ごとの概算を見積の書式に書く
- お客様に聞くべきこと(前回の工事、家具の移動、日程)を書き添えて、返事のメールを書く
- お客様の返事を待ち、訪問の日程を決める
- 訪問した職人が畳を見て、金額を確定する
- 自動ホームページの受付の欄とメールに届いた依頼を、Python のサーバーが受け取り、写真と依頼の内容を依頼ごとのフォルダに保存する
- 自動サーバーが写真を Gemini API に渡し、傷みの候補と位置、写っている畳の枚数の候補、写真で見えない範囲を受け取る
- 自動傷みの候補と、お客様が書いた前回の工事の時期から、店の決まりで工事の種類の目安を付ける
- 自動お客様の書いた枚数と、写真の枚数の候補を比べ、食い違いがあれば「確かめる事項」に入れる
- 自動単価表から、目安の工事と等級ごとの概算を計算し、見積の下書きと返事の文の下書きを作る
- 人受付の担当が写真と下書きを見比べ、候補ごとに「確認済み」「該当なし」を選び、枚数を確かめる
- 人目安が新調、または写真で見えない範囲が多い依頼は、職人が写真を見る
- 人受付の担当が返事の文を直して送る
- 人訪問した職人が畳を見て、金額を確定する
各工程の詳しい説明を読む
- 受付の担当が、ホームページの受付の欄とメールに届いた依頼を見て、顧客の台帳に書く
- 写真を職人に回し、職人が夕方に写真を見て、傷みと工事の種類の見立てを口で伝える
- 受付の担当が、写真の部屋の畳の枚数を数え、お客様の書いた枚数と比べる
- 単価表を見て、工事の種類と等級ごとの概算を見積の書式に書く
- お客様に聞くべきこと(前回の工事、家具の移動、日程)を書き添えて、返事のメールを書く
- お客様の返事を待ち、訪問の日程を決める
- 訪問した職人が畳を見て、金額を確定する
(a)見立てられる人が限られる。 写真を見て「これは表替えで足りる」「床が沈んでいそうだから新調も出しておく」と言えるのは、店主と古参の職人だけです。2人が現場に出ている日は、写真が夕方まで誰にも見られません。
(b)返事が遅れる。 職人が見立てを伝え、受付の担当が見積を書き、返事を出すまでに1〜2日かかります。お客様は複数の店に写真を送っていることがあり、最初に返事をした店に決めます。
(c)枚数の数え違い。 部屋の写真で畳の枚数を数えるのは、慣れていないと間違えます。お客様の書いた「6畳」が、実際は半畳の畳を含む並びだったということもあります。
(d)聞き忘れ。 前回いつ裏返しをしたかを聞き忘れると、裏返しで出した概算が、訪問してから表替えに変わります。 お客様には、値上げされたように見えます。
- 【自動】 ホームページの受付の欄とメールに届いた依頼を、Python のサーバーが受け取り、写真と依頼の内容を依頼ごとのフォルダに保存する
- 【自動】 サーバーが写真を Gemini API に渡し、傷みの候補と位置、写っている畳の枚数の候補、写真で見えない範囲を受け取る
- 【自動】 傷みの候補と、お客様が書いた前回の工事の時期から、店の決まりで工事の種類の目安を付ける
- 【自動】 お客様の書いた枚数と、写真の枚数の候補を比べ、食い違いがあれば「確かめる事項」に入れる
- 【自動】 単価表から、目安の工事と等級ごとの概算を計算し、見積の下書きと返事の文の下書きを作る
- 【人】 受付の担当が写真と下書きを見比べ、候補ごとに「確認済み」「該当なし」を選び、枚数を確かめる
- 【人】 目安が新調、または写真で見えない範囲が多い依頼は、職人が写真を見る
- 【人】 受付の担当が返事の文を直して送る
- 【人】 訪問した職人が畳を見て、金額を確定する
6番目と7番目が、この設計の分かれ目です。 写真を見る人を、全件の職人から、受付の担当の一次の確認と、職人が見るべき依頼だけに分けます。職人が全件を見る設計のままだと、返事の遅れは縮まりません。
3番目の目安を規則で付けているのも、意図してのことです。 どの傷みで表替えを勧め、どこから新調も出すかは、店の方針です。AIには工事の種類を決めさせず、決まりはプログラムの側に置きます。
02今回想定するシステム構成
ホームページの受付の欄 / 管理会社からのメール ▼【トリガー】依頼が届いたとき Python のサーバー ├── 写真と依頼の内容を依頼ごとのフォルダに保存 ├── 写真の向き・大きさを整える ▼ Gemini API(画像の理解・構造化出力)── 依頼1件分の写真 │ 色あせ・すり切れ・シミやカビのように見える箇所・縁のほつれ・へこみの候補と枠 │ 写っている畳の枚数の候補、見えない範囲 ▼ Python ── 店の決まりで工事の種類の目安 → 単価表から概算 ▼ 見積の下書きと返事の文の下書き(スプレッドシートとメールの下書き) ▼ 【人】受付の担当が確かめる(必要なら職人)→ 返事を送る
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 処理 | Gemini API(畳の写真から傷みの候補と枚数の候補を返し、返事の文の下書きを作る) | Claude API、OpenAI API |
| 連携 | Python(受付の受け取り、前処理、呼び出し、目安の規則、概算の計算) | Google Apps Script |
| 単価表 | 店の単価表と見積の書式(スプレッドシート) | - |
| 受付 | ホームページの受付の欄、受付のメールアドレス | - |
新しく足すのは、Python のサーバーと Gemini API の契約です。 単価表と見積の書式は今のものを使い、受付の欄の送り先をサーバーに変えます。
写真を見る土台は、Gemini API の画像の理解です。 公式の案内では、対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、1つのリクエストに複数の画像を入れられます。 画像を直接入れる場合は、指示の文と合わせたリクエスト全体が20MBまでです。
位置は枠で返させます。 枠は [ymin, xmin, ymax, xmax] の順で、画像の大きさに対して0〜1000に正規化されます。傷みの場所を写真に印で示し、受付の担当が写真のどこを見ればよいかを分かるようにします。
出力は構造化出力で受けます。 /v1beta/interactions に送り、response_format で mime_type を application/json にし、schema にスキーマを入れます。enum で値を決まった文字列に絞れ、数値には minimum と maximum を付けられます。値はアプリ側で検証するよう公式に書かれています。
03どうやって実装するのか
処理の起点を決める
依頼が届いたときに動きます。 ホームページの受付の欄から送られた依頼は、サーバーが直接受け取ります。管理会社からのメールは、受付のメールアドレスに届いたものをサーバーが定期的に見て取り込みます。どちらの経路も、取り込んだら依頼の番号を付け、そこから先は区別しません。
写真が1枚も無い依頼は、AIに渡しません。 写真の無い依頼は、これまでどおり受付の担当が電話かメールで写真を頼みます。写真が届き直した時点で、同じ依頼の番号のまま動かします。
見積の依頼を受け付けるのは、18歳以上の方に限ります。 受付の欄に「工事を依頼する18歳以上の方」と書き、年齢の確認の欄を置きます。Gemini API の規約は、18歳以上であることを利用の条件とし、18歳未満の人に向けた、または使う見込みのあるアプリでの利用を認めていません。AIの結果を見るのは店の担当だけで、お客様に返すのは担当が確かめた返事だけです。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 畳の写真 | 部屋全体の写真と、傷みの近くの写真 | 受付の欄・メールの添付 |
| 依頼の内容 | 畳の枚数(お客様の申告)、前回の工事の時期と内容、希望の時期、部屋の使い方 | 受付の欄・メールの本文 |
| 間取り | 管理会社から届く間取りの図 | メールの添付 |
| 候補の種類の一覧 | 色あせ、すり切れ・ささくれ、シミ、カビのように見える箇所、焦げ跡、縁のほつれ・すり切れ、へこみ・段差、すき間 | サーバーに持たせる |
| 店の決まり | 工事の種類の目安の付け方、単価表、等級の一覧 | スプレッドシート |
質を決めるのは、写真の頼み方です。 受付の欄に、「部屋の入口から全体を1枚」「傷みの気になる所の近くを1枚」「縁と縁の継ぎ目を1枚」と例の写真を載せておきます。部屋全体の写真が無いと、枚数の候補が出せません。
前回の工事の時期と内容は、必ず聞く欄にします。 裏返しは畳表の裏側を使う工事なので、前に裏返しをした畳は、裏返しの目安を付けられません。 写真では裏側の状態が分からないため、ここはお客様の申告に頼ります。分からないときは「分からない」を選べるようにします。
等級の一覧は、店の単価表の名前をそのまま使います。 たとえば、熊本県の八代市などで作られる「くまもと県産い草畳表」は、地理的表示として農林水産省に登録されています。見積の下書きに書く等級の名前は、AIに作らせず、単価表の名前だけを使います。 お客様の今の畳の産地や等級を写真から言い当てさせることもしません。
データの取得方法を決める
受付の欄からの依頼は、写真と項目をサーバーが直接受け取ります。 写真は依頼の番号のフォルダに置き、項目は依頼の記録のシートに書きます。写真を先に保存してから AI を呼ぶのは、呼び出しに失敗しても写真が残るようにするためです。
管理会社のメールは、本文と添付を取り込みます。 管理会社ごとに、物件名、部屋番号、退去日の書き方が決まっていることが多いので、管理会社ごとの書き方の例を持たせて、項目を取り出します。 取り出せなかった項目は、受付の担当が埋めます。
Gemini API へは、依頼1件ごとに1回、写真をまとめて渡します。 部屋全体の写真と近くの写真を一緒に渡すと、近くの写真の傷みが、部屋のどの畳かを全体の写真と結び付けて返せます。
有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し(有料の枠で55日)、store=false で保存しない動きにできると案内されています。写真は自社のフォルダに残すので、AI側に残す必要はありません。
AIへ渡す前に整形する
- 形式と向き … スマートフォンの写真の向きの情報で回転しているだけのものは、画素を回転させます
- 縮小 … 長い辺を1,600ピクセル程度に縮めます。近くの写真は、すり切れの細かさが分かるよう大きめに残します
- 写り込みの確認 … 人の顔、表札、郵便物、家族の写真などが写っていないかを見て、写っていればその部分を塗りつぶします
- 写真の種類の振り分け … ファイル名や順番から、部屋全体と近くの写真を分けて、指示の文で番号を伝えます
- 依頼の内容の付け足し … お客様の申告の枚数、前回の工事、部屋の使い方を指示の文に入れます
- 大きさの確認 … 写真と指示の文を合わせて20MBを超えないかを見ます。超えるときは縮め直します
3番目を軽く見ないでください。 住まいの写真には、家族、表札、郵便物、子どもの持ち物が写り込みます。AIに渡す前に塗りつぶし、塗りつぶした写真だけを渡します。 元の写真は店のフォルダにだけ残します。
AIに処理させる
させるのは、写真の中の傷みの候補を枠で返して種類を付けることと、写っている畳の枚数の候補、見えない範囲を返すことだけです。
| 返すもの | 中身 | 判断できないときの扱い |
|---|---|---|
| 畳表の傷み | 写真の番号、枠、種類(色あせ、すり切れ、シミ、カビのように見える、焦げ跡) | 汚れか模様か分からなければ unclear として候補に入れる |
| 縁の傷み | ほつれ、すり切れ、はがれの位置 | 写真の角度で分からなければ unclear |
| へこみ・段差・すき間 | 家具の跡のへこみ、畳と畳の段差、すき間の位置 | 影で分からなければ unclear |
| 畳の枚数 | 部屋全体の写真に写っている畳の枚数と、半畳の畳の数の候補 | 家具で隠れて数えきれなければ uncountable |
| 見えない範囲 | 家具や敷物で見えない範囲 | 範囲がはっきりしなければ写真ごと「見えない範囲あり」 |
右端の列の考え方は、迷ったら人が見る側に倒すことです。 枚数を数えきれないときに、ありそうな枚数を返させません。数えきれないことが分かれば、受付の担当がお客様に聞く事項に入ります。
| させないこと | 理由 |
|---|---|
| 工事の種類(表替え・裏返し・新調)を決めること | 店の決まりで、規則の側で決める |
| 畳床の状態の判断 | 写真では分からない。踏んで確かめる |
| 裏返しができるかの判断 | 裏側の状態と前回の工事による。申告と現地で確かめる |
| カビやダニの種類、健康への影響 | 写真では分からず、店が答える事柄でもない |
| 今の畳の産地や等級を言い当てること | 写真では分からない。等級の名前は単価表だけを使う |
| 金額の計算 | 単価表とプログラムで行う |
1行目と2行目がいちばん起きやすい失敗です。 色あせの強い畳の写真を渡すと、AIは「新調をお勧めします」「床が傷んでいる可能性が高い」と書きたがります。見積の下書きにこの言葉が入ると、お客様にはそれが店の見立てに聞こえます。 返すのは、写真で見える傷みの位置と種類までにします。
4行目は、返事の文の下書きにも響きます。 カビのように見える箇所があったとき、「健康に害があります」とも「心配ありません」とも書かせません。 返事の文には、写真にそのように見える箇所があったことと、訪問のときに職人が見ることだけを書きます。
工事の種類の目安は、プログラムが次のように付けます。
| 目安 | 付け方の例(店で決める) |
|---|---|
| 裏返しも候補 | 確認済みの傷みが色あせと軽いすり切れだけで、前回の工事が表替えまたは新調で、裏返しをしていない |
| 表替え | すり切れ・シミ・焦げ跡・縁の傷みが確認済み、または前回が裏返し、または前回の工事が分からない |
| 新調も候補 | へこみ・段差・すき間が確認済み、またはお客様が「踏むと沈む」と書いている |
| 共通 | unclear が残る、見えない範囲がある、枚数が食い違う場合は「確かめる事項」に入れる |
指示内容を固定する
あなたは畳店の受付で、お客様から届いた畳の写真を見る手伝いをする係です。
写真の番号と種類は次のとおりです。
{1: 部屋全体, 2: 傷みの近く, 3: 縁の継ぎ目 ...}
【お客様の申告】
畳の枚数: {6枚} 前回の工事: {7年前に表替え/分からない}
部屋の使い方: {寝室、ベッドなし}
【やること】
1. 次の傷みの候補を探す。
色あせ、すり切れ・ささくれ、シミ、カビのように見える箇所、焦げ跡、
縁のほつれ・すり切れ・はがれ、家具の跡のへこみ、畳の段差、すき間。
2. 候補ごとに、写真の番号と枠を [ymin, xmin, ymax, xmax] の順で、
0〜1000 に正規化して返す。種類と、見え方を短く書く。
3. 部屋全体の写真で、写っている畳の枚数と、半畳の畳の数を数える。
数えきれないときは uncountable とし、理由を書く。
4. 家具や敷物で見えない範囲を返す。
【厳守事項】
- 表替え・裏返し・新調のどれがよいかを書かないでください。
- 畳床の状態や、裏返しができるかを書かないでください。
- カビやダニの種類、健康への影響を書かないでください。
「カビのように見える」までにしてください。
- 今の畳の産地や等級を書かないでください。
- 金額を書かないでください。
- 汚れか模様か分からないものは、kind を unclear にして候補に入れてください。
- 数えきれない枚数を推測で埋めないでください。
- 見えない範囲について「傷みなし」と書かないでください。
- 人、表札、郵便物、写っている持ち物については何も書かないでください。
「数えきれない枚数を推測で埋めない」を入れないと、6畳の部屋なら6と返します。 お客様の申告の数字に引っ張られて数え、食い違いを見つけるための数が、申告の写しになります。 申告と比べる数は、写真だけから数えた数にします。
返事の文の下書きは、別の呼び出しで作ります。 受付の担当が候補を確かめたあと、確定した傷み、目安、概算の金額、確かめる事項だけを渡し、お客様向けの言葉に直させます。指示には「渡した金額と目安の言葉を変えない」「健康への影響を書かない」「金額は訪問のあとに確定すると書く」を入れます。
出力形式を固定する
依頼1件ごとに、次の形の JSON で受け取ります。 kind、count_state は enum で決まった文字列に絞り、枚数には minimum を付けます。
{
"request_id": "R-20261027-018",
"findings": [
{ "photo": 2, "box_2d": [340, 220, 520, 410],
"kind": "fading | wear | stain | mold_like | burn | edge_fray | dent | step | gap | unclear",
"note": "窓側の畳の中央に、表がすり切れて筋が浮いて見える箇所" }
],
"tatami_count": { "full": 6, "half": 0, "count_state": "counted | uncountable", "reason": "" },
"not_visible": [ { "photo": 1, "area": "右奥の畳", "reason": "furniture | rug | shadow" } ]
}
1つ目の理由は、findings をそのまま受付の担当の確認の一覧にできることです。 サーバーは写真に印を描き、一覧を傷みの種類の順に並べます。受付の担当は一覧の上から順に写真のその箇所を見て、「確認済み」「該当なし」を選びます。
2つ目は、tatami_count を申告と機械的に比べられることです。 申告の6枚と写真の数が合えばそのまま、合わなければ「確かめる事項」に入ります。uncountable のときは、比べずに確かめる事項に入れます。
3つ目は、目安の規則と概算の計算が、確定した findings と申告だけを読めばよいことです。 概算の下書きは次の形で、スプレッドシートの見積の書式に書き込みます。
| 工事 | 等級(単価表の名前) | 枚数 | 単価 | 概算 |
|---|---|---|---|---|
| 表替え | 単価表の等級A | 6 | 単価表の値 | 計算 |
| 表替え | 単価表の等級B | 6 | 単価表の値 | 計算 |
| 新調(参考) | 単価表の等級A | 6 | 単価表の値 | 計算 |
| 確かめる事項 | 前回の工事の内容/踏むと沈む箇所の有無/家具の移動 | - | - | - |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| ホームページの受付の欄 | サーバーが受け取る | 写真と依頼の項目 |
| 受付のメールアドレス | サーバーが定期的に取り込む | 管理会社からの本文と添付 |
| Gemini API | API呼び出し(/v1beta/interactions、store=false) | 傷みの候補、枚数の候補、見えない範囲。2回目で返事の文の下書き |
| 単価表と見積の書式 | 読み取りと書き込み | 単価を読み、概算の下書きを書く |
| メール | 下書きの作成 | 返事の文の下書き。送信は人が行う |
| 顧客の台帳 | 書き込み | 依頼の番号、受付の日時、返事の日時 |
返事のメールは、下書きまでにします。 受付の担当が写真と下書きを見比べてから送ります。概算の金額が自動で届くと、写真の見落としがそのまま金額の約束になります。
単価表は読むだけです。 単価の見直しは店主が行い、この構成から単価表に書き込む経路を作りません。
管理会社の依頼は、部屋ごとに1件として扱います。 1通のメールに複数の部屋の写真が入っていても、部屋番号ごとに依頼の番号を分けて呼び出します。部屋をまとめて1回で渡すと、どの写真の傷みがどの部屋かが混ざり、見積の下書きが部屋をまたいでしまいます。 返事は、管理会社の求める形に合わせて部屋ごとの概算を1通にまとめます。
人が確認する
- 候補を写真で確かめる … 一覧の上から順に、写真のその箇所を見ます。「確認済み」か「該当なし」を選びます
- 枚数を確かめる … 申告と写真の数が食い違うときは、間取りの図と見比べ、分からなければお客様に聞く事項にします
- 職人に回す依頼を選ぶ … 目安が「新調も候補」の依頼、見えない範囲が多い依頼、カビのように見える箇所が広い依頼は、職人が写真を見ます
- 返事の文を読み直す … 金額と目安の言葉、確かめる事項がそろっているかを見て、直して送ります
- 外した候補を記録する … 木目の影をすり切れと言った、敷物の柄をシミと言った、などの理由を残します
3番目を省かないでください。 新調の見立ては、金額が大きく変わる見立てで、写真から畳床の状態は分かりません。 職人が写真を見て、訪問のときに見る点を書き添えます。
目標は、240件をならして1件5分です。 傷みの少ない部屋は、候補を見て返事を読み直すだけで済みます。職人に回す依頼と、管理会社の複数の部屋がまとまった依頼は、時間がかかります。 外す候補が1件で半分を超えるなら、写真の頼み方が伝わっていません。
例外に対処する
| 起きること | 対応 |
|---|---|
| 写真が暗い・ぶれている | 撮り直しのお願いを返事の下書きに入れる |
| 部屋全体の写真が無い | 枚数は uncountable。全体の写真を頼む |
| 家具で畳の大部分が隠れている | 見えない範囲として、訪問のときに見る事項にする |
| 前回の工事が「分からない」 | 裏返しの目安を付けず、表替えから出す |
| 申告の枚数と写真の数が合わない | 確かめる事項に入れ、概算は申告の枚数で出して注記する |
| 縁の無い畳、琉球畳の並び | 店の単価表の品目に合わせ、職人が写真を見る |
| 写真に人や表札が写っている | 塗りつぶしてから渡す。塗りつぶせないときは渡さない |
| 管理会社のメールの項目が取り出せない | 受付の担当が埋める |
JSON の値が enum に無い | 候補を出さず、受付の担当が写真を見る流れにする |
上から3行目までが大半を占めます。 どれもAIの精度の問題ではなく、写真の頼み方の問題です。 受付の欄の写真の例を直すほうが、指示の文をいじるより効きます。
記録を残す
- 依頼ごとの元の写真と、塗りつぶして AI に渡した写真
- Gemini API が返した JSON の全文
- 候補ごとに受付の担当が付けた「確認済み」「該当なし」と、足した箇所
- そのときの店の決まりと単価表の版、付けた目安、概算
- 送った返事の文と、訪問のあとに確定した工事と金額
最後の行が、目安の決まりを直す材料です。 写真で付けた目安と、訪問のあとに確定した工事を並べると、「裏返しで出したが表替えになった」依頼がどの傷みのときに多いかが分かります。 その傷みのときの目安を、決まりの側で直します。
04実装レベルの3段階
最小構成では、返事は速くなりません。 手で写真を渡す手間があります。確かめるための段階です。 半自動化で、1件15分が10分程度になります。 候補の拾い出しは自動になりますが、見積の書式への書き写しと返事の文が残ります。本格構成で5分になり、この段階が本記事の想定です。 差が大きいのは、単価表からの計算と、毎回同じ質問を書き添える作業が無くなるからです。 段階を飛ばさないでください。 半自動化の一覧を1か月見ると、外す候補の多い部屋の様子と、職人に回す依頼の割合が分かります。それを見てから目安の決まりを作るほうが、訪問のあとに金額が変わる依頼が減ります。
05工数削減シミュレーション
導入後 240件 × 5分 ÷ 60 = 20 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- ホームページや電話で畳の張り替えの依頼を受け、見積の前にお客様に写真を送ってもらっている畳店。賃貸の管理会社から退去のたびに部屋の写真付きで表替えの依頼が届く店。写真を見て見積を出せるのが店主や古参の職人だけで、返事が数日遅れることがある場合。見積の依頼を受けるのを18歳以上の方に限れる場合。
- 依頼のほとんどが寺社や旅館の大口の新調で、必ず現地で採寸してから見積を出す場合。依頼が月に数件で、店主がその場で見て返せば足りる場合。写真での概算を出さず、必ず訪問してから金額を伝える方針の店。なお、畳床の傷みの程度、裏返しができるかの最終の判断、カビやダニの健康への影響、工事の金額の確定は、この構成では代替できません。
07最小構成で試す方法
- 過去に写真付きで届き、訪問して工事を確定した依頼から30件を選ぶ(うち10件は、概算と確定の金額が大きく違ったもの)
- 写真の人や表札を塗りつぶす
- Gemini API の有料の利用枠で、1件ずつ写真をまとめて渡す
- 「色あせ、すり切れ、シミ、カビのように見える箇所、縁のほつれ、へこみの候補を写真の番号と枠で返し、畳の枚数を数えてください。工事の種類、金額、畳床の状態は書かないでください。数えきれないときは数えきれないと書いてください」と指示する
- 出てきた候補と枚数を、訪問した職人の記録と突き合わせる
30件は必ずやってください。 サーバーを組む前に、「お客様の撮る写真で、傷みと枚数が拾えるのか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
| 職人の記録の傷みが候補に出て、枚数が合った | サーバーと目安の規則の作成に進む |
| 工事の種類や床の状態を書いた | 指示の書き方で直る。構成は有効 |
| 部屋全体の写真が無く、枚数がほとんど数えられない | 写真の頼み方が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 失敗ではなく、受付の担当が電話で枚数を聞き直していた理由が1つ分かったということです。 受付の欄に写真の例を載せてから、次の30件で試してください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| AIが工事の種類や床の状態を書く | 指示で禁じる。 目安は規則で付ける |
| 枚数を申告に合わせて数える | 写真だけで数えさせ、数えきれないときは uncountable |
| 前回の工事が分からないのに裏返しで出す | 分からないときは表替えから出す決まりにする |
| カビについて健康への影響を書く | 「カビのように見える」までにさせ、返事の文でも禁じる |
| 等級の名前をAIが作る | 単価表の名前だけを使う |
| 概算が確定の金額として受け取られる | 返事の文に「訪問のあとに確定」を必ず入れる |
| 家具で隠れた畳が「傷みなし」になる | 見えない範囲として返させ、訪問のときに見る |
| 写真に家族や表札が写る | 塗りつぶしてから渡す |
| 管理会社ごとに書き方が違う | 書き方の例を持たせ、取り出せない項目は人が埋める |
上の2行が、この構成の失敗のほとんどです。 どちらも、写真では分からないことを、分かったように書く失敗です。写真で見える位置と数だけを返させ、目安と金額は店の決まりで出すかどうかで、概算と確定のずれが小さくなるかが決まります。
下から3行目の「概算が確定の金額として受け取られる」も、早く効いてきます。 返事が速くなるほど、お客様はその数字で家族と相談し、訪問の日を決めます。訪問のあとに金額が上がる依頼が続くと、速く返事を出したことが裏目に出ます。 概算の幅と、上がりうる理由(床の傷み、前回の工事の内容、家具の移動)を返事の文に必ず添えます。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 住まいの部屋の写真、お客様の名前と住所と連絡先、管理会社の物件名と部屋番号、退去日です。写真には家族、表札、郵便物、家の中の持ち物が写り込むことがあります。
- 依頼を受けるのを18歳以上の方に限る … Gemini API の規約は、18歳以上であることを利用の条件とし、18歳未満の人が使う見込みのあるアプリでの利用を認めていません。受付の欄で年齢を確かめ、AIの結果は店の担当だけが見ます。 線引きが難しい場合は、代替候補の Claude API などで同じ構成を組むことを検討します
- 写り込みを塗りつぶしてから渡す … 塗りつぶした写真だけを渡し、お客様の名前、住所、物件名、部屋番号は AI に渡しません
- 有料の利用枠で、保存させない … 規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API の
storeをfalseにします。禁止された使い方の検知のために限られた期間記録されることは書かれています - 健康への助言をしない … カビのように見える箇所について、健康への影響を AI にも返事の文にも書かせません。Gemini API の規約は、医療の助言に使うことを認めていません
- 概算を約束にしない … 返事は下書きまでで、人が送ります。金額は訪問のあとに確定すると、毎回書きます
- 写真の保存の期間を決める … 工事を終えたあとの問い合わせに要る期間を決め、過ぎたら消します。工事にならなかった依頼の写真は、早めに消します
誤りが起きた場合のリスクは、写真で見えない傷みを見落として概算が安すぎることと、写真から推した「新調が必要」や「健康に害がある」がお客様への見立てとして伝わることの2つです。 前者は見えない範囲を「傷みなし」にすると起き、後者は工事の種類や健康への影響を書かせると起きます。どちらも、写真で見える位置だけを返させ、目安と金額を店の決まりで出す設計で防げます。
10まず何から始めるか
1週目:写真の頼み方を直す
受付の欄に、部屋全体・傷みの近く・縁の継ぎ目の3枚の写真の例を載せ、前回の工事の時期と内容を聞く欄を足します。管理会社には、同じ3枚を頼む案内を送ります。
2週目:30件で試す
過去の依頼から30件を選び、Gemini API に渡します。職人の記録の傷みが候補に出るかと、工事の種類や床の状態を書いていないかを最優先で見ます。
3週目:目安の決まりを店主と決める
どの傷みのときに裏返し・表替え・新調を出すかを、店主と職人で大づかみに決めます。前回の工事が分からないときの扱いと、職人に回す依頼の条件も決めます。
4週目:受付から確認の一覧までをつなぐ
依頼が届くと候補の一覧が出るところまで作ります。この時点では見積と返事はこれまでどおり手で書き、一覧と見比べます。
2か月目: 目安の規則と概算の計算、返事の文の下書きを足します。外した候補の理由と、職人に回した依頼の数を毎週数えます。3か月目以降: 訪問のあとに確定した工事と目安を並べて、決まりを直します。写真で付けた目安と訪問のあとの確定のずれが小さくなり、返事が当日に出せるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
対応する画像の形式が PNG、JPEG、WEBP、HEIC、HEIF であること。画像を直接入れる場合に、指示の文などを含むリクエスト全体が20MBまでであること。1つのリクエストに複数の画像を入れられること。枠が [ymin, xmin, ymax, xmax] の順で画像の大きさに対して0〜1000に正規化されること。大きな画像が768×768の区画に分けられ、区画ごとに258トークンであること | Gemini API: Image understanding | 2026-10-27 |
構造化出力が /v1beta/interactions に response_format で mime_type を application/json にし、schema にスキーマを入れて送る形であること。enum、数値の minimum・maximum が使えること。値はアプリ側で検証するよう書かれていること | Gemini API: Structured output | 2026-10-27 |
Interactions API が既定でやり取りを保存し、有料の枠で55日保持すること。store=false で保存しない動きにできること | Gemini API: Interactions | 2026-10-27 |
| 18歳以上であることが利用の条件で、18歳未満の人に向けた、または使う見込みのあるアプリでは使えないこと。有料のサービスではプロンプトと応答が製品の改善に使われないこと。禁止された使い方の検知などのために限られた期間記録されること。臨床の場で使うことや医療の助言に使うことが認められていないこと | Gemini API Additional Terms of Service | 2026-10-27 |
| 「くまもと県産い草畳表」が地理的表示(登録番号第9号)として登録され、生産地が熊本県八代市・八代郡氷川町・宇城市であること。栽培から加工・製織までを一貫して行い、泥染めしたいぐさを使う畳表とされていること | 農林水産省: 登録産品 くまもと県産い草畳表 | 2026-10-27 |
工事の種類の目安、等級の勧め方、概算の出し方は、店の方針と職人の判断で決めてください。 本記事は公開の資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1951)についてのご相談はこちらから。
