タイヤ販売店が点検で撮ったタイヤの溝・ひび割れ・偏摩耗の写真を Gemini で見て、交換の目安とお客様への説明文の下書きを作る

処理の起点を決める

1台分の撮影を終えたときに動きます。 スタッフが点検アプリで4本の溝の深さを入れ、決まった順に写真を撮り、「この車の点検を終える」を押すと、写真がサーバーに送られます。溝の深さが4本ぶん入っていないと、終えるボタンが押せないようにします。 写真だけで先に進むと、説明文に数字の入らない点検の結果ができます。

お客様の作業の待ち時間の中で返る必要があります。 オイル交換などの作業が終わるまでの間に、スタッフは点検の結果を確かめ、説明の準備をします。一定の時間を過ぎても返らないときは、アプリが「目で確かめてください」と出し、これまでどおり点検表に書く流れに切り替えます。

点検アプリに入れるのは、18歳以上のスタッフのアカウントだけにします。 Gemini API の規約は、18歳以上であることを利用の条件とし、18歳未満の人に向けた、または使う見込みのあるアプリでの利用を認めていません。高校生のアルバイトが作業場に立つ店舗では、その人の点検はアプリを使わない流れにします。

入力データを集める

質を決めるのは、写真の撮り方です。 作業場の照明の下で、車体に付いたままのタイヤを斜めから撮ると、内側の肩は影になり、ひびは写りません。 撮影の手順書で、トレッドは真上に近い角度から、サイドウォールは横から光を当てて撮る、と決めます。

溝の深さは、AIに渡しません。 渡すと、写真の見え方を数字に合わせて読もうとします。数字は区分の規則と説明文の下書きだけに使い、写真の判定とは切り離します。

店の目安は、JATMA の案内を下限に、店で決めます。 JATMA は使用限度を残り溝1.6mmとし、それ以前に新品へ交換するよう案内しています。また、使用開始後5年以上たったタイヤは販売店などで点検を受けること、製造後10年たったタイヤは交換することを勧め、10年は目安だとしています。「何mmで交換をお勧めするか」は、この下限より上のどこに線を引くかを店で決めます。

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

写真は、点検アプリからサーバーに直接送ります。 アプリは車両の番号と溝の深さを一緒に送り、サーバーは写真を点検の番号のフォルダに置いてから Gemini API を呼びます。写真を先に保存してから呼ぶのは、呼び出しに失敗しても写真が残るようにするためです。

Gemini API へは、1台ごとに1回、まとめて渡します。 タイヤ1本ずつ呼ぶと、4本を比べて「右前だけ内側が減っている」という見方ができません。1台を1回の呼び出しにすると、どの写真がどのタイヤのどの面かを1つの JSON で受け取れます。 写真の並び順は、アプリが「左前のトレッド、左前の外側、左前の内側、右前の…」と決めて付けます。

車両の情報は販売管理から読むだけです。 タイヤのサイズと前回の点検の日を引き、説明文の下書きに使います。前回の点検で記録したひび割れや偏摩耗があれば、その箇所を「前回から続いている箇所」として一覧に出します。

有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し（有料の枠で55日）、store=false で保存しない動きにできると案内されています。写真は自社のサーバーに残すので、AI側に残す必要はありません。

AIへ渡す前に整形する

1. 形式と向き … タブレットの写真の向きの情報で回転しているだけのものは、画素を回転させます。トレッドの写真が横倒しのままだと、内側と外側が入れ替わります
2. 縮小 … 長い辺を1,600ピクセル程度に縮めます。製造年週の表示を写した写真は、文字がつぶれないよう大きめに残します
3. 写真の数の確認 … 4本×3面の12枚がそろっているかを見ます。足りない面は撮り直しを促し、撮れない面はスタッフが「撮影不可」を選びます
4. ナンバープレートの確認 … 車体の写り込みでナンバープレートが入っていれば、その部分を塗りつぶします
5. 車両の情報の付け足し … 夏用か冬用か、タイヤのサイズを指示に入れます
6. 大きさの確認 … 12枚と指示の文を合わせて20MBを超えないかを見ます

3番目の「撮影不可」を軽く見ないでください。 内側のサイドウォールは、車体に付いたままでは見えにくい面です。写真が無い面について、AIが「損傷なし」と返す形にしてはいけません。 撮影不可の面は、説明文にも「今回は見ていない面」として残します。

AIに処理させる

させるのは、写真の中の損傷の候補を枠で返して種類を付けることと、製造年週の表示の書き写しの候補を返すことだけです。

右端の列の考え方は、迷ったらスタッフが見る側に倒すことです。 汚れか傷か分からないものは候補に入れます。候補が多いのは、スタッフがタイヤに触れて「汚れでした」と数秒で済みますが、候補から落ちたひびは、次の点検まで誰も見ません。

2行目がいちばん起きやすい失敗です。 ひびの少ないタイヤの写真を渡すと、AIは「問題なく使用できます」と書きたがります。説明文にこの言葉が入ると、スタッフがそのままお客様に伝え、お客様にはそれが店の保証に聞こえます。 返すのは、写真で見える箇所の位置と種類までにします。

3行目は、説明文の下書きにも響きます。 偏摩耗の原因は空気圧やアライメントなどいくつか考えられますが、写真の減り方から1つに決めて書くと、お客様に誤った整備を勧めることになります。 JATMA の案内でも、偏摩耗の兆候があればローテーションを速やかに行うこととされており、何をするかは店の整備の担当が決めます。

説明文の下書きは、別の呼び出しで作ります。 1回目の呼び出しで損傷の候補を受け、スタッフが確かめたあと、確定した箇所と計った溝の深さ、規則で決めた区分だけを渡して、お客様向けの言葉に直させます。確かめていない候補は、2回目には渡しません。

指示内容を固定する

あなたはタイヤ販売店の店頭で、点検の写真から損傷の候補を探す手伝いをする係です。
写真は同じ1台の車のタイヤで、並び順は次のとおりです。
{1: 左前・トレッド, 2: 左前・外側サイド, 3: 左前・内側サイド, 4: 右前・トレッド, ...}
撮影できなかった面: {右後・内側サイド}

【タイヤの種類】{夏用／冬用}

【やること】
1. トレッドの写真で、次の候補を探す。
   スリップサインの露出、ひび割れ、切り傷、えぐれ、ふくらみ、
   釘・ガラス・金属片の刺さり、溝の小石の噛み込み。
2. トレッドの減り方が、内側・外側・中央のどこかに偏って見えるか、
   段差のように減って見えるかを、タイヤごとに返す。
3. サイドウォールの写真で、ひび割れ、切り傷、ふくらみの候補を探す。
4. 候補ごとに、写真の番号と枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。種類と、見え方を短く書く。
5. サイドウォールに見える製造年週の表示を、見えるとおりに書き写す。
6. 影や泥で見えない範囲を返す。

【厳守事項】
- 溝の深さを書かないでください。写真から推し量らないでください。
- 「安全です」「使用できます」「交換が必要です」と書かないでください。
- 減り方や傷の原因（空気圧、アライメント、運転の仕方など）を書かないでください。
- 汚れか傷か分からないものは、kind を unclear にして候補に入れてください。
- 撮影できなかった面と、見えない範囲について「損傷なし」と書かないでください。
- 製造年週の表示は見えるとおりに写し、読めない文字は ? にしてください。
  年数を計算しないでください。
- ナンバープレート、人、車内については何も書かないでください。

「撮影できなかった面について損傷なしと書かない」を入れないと、点検表の空いた面が「異常なし」で埋まります。 内側のサイドウォールは損傷が見つかりにくい面で、見ていないことと、見て何も無かったことが区別できなくなります。

説明文の下書きの指示は、次の形です。

次の点検の結果を、お客様に渡す控えの文にしてください。
【確定した箇所】{スタッフが確認済みにした箇所}
【溝の深さ】{4本の数字}　【店の区分】{規則で決めた区分}
【厳守事項】
- 書かれている箇所と数字だけを使ってください。増やさないでください。
- 「安全」「保証」「まだ大丈夫」と書かないでください。
- 区分の言葉は渡したとおりに使い、言い換えないでください。
- 撮影できなかった面は「今回の点検では見ていない面」と書いてください。

出力形式を固定する

1台ごとに、次の形の JSON で受け取ります。 kind、wear_pattern は enum で決まった文字列に絞ります。

{
  "inspection_id": "S03-20261027-041",
  "findings": [
    { "photo": 4, "tire": "front_right", "box_2d": [120, 610, 260, 700],
      "kind": "wear_indicator | crack | cut | gouge | bulge | foreign_object | stone | unclear",
      "note": "トレッドの内側の肩に細かいひびが並んで見える" }
  ],
  "wear_patterns": [
    { "tire": "front_right", "wear_pattern": "inner | outer | center | stepped | none_seen | unclear" }
  ],
  "date_codes": [ { "photo": 5, "text": "?425", "state": "partly_readable" } ],
  "not_visible": [ { "photo": 9, "area": "下半分", "reason": "shadow | mud | not_photographed" } ]
}

1つ目の理由は、findings をそのまま「確かめる事項」の一覧にできることです。 アプリは findings をタイヤごとに並べ、写真に印を描きます。スタッフは一覧の上から順にタイヤのその箇所に触れ、確かめます。

2つ目は、確定の欄と分けて記録できることです。 顧客の記録には、各候補にスタッフが付けた「確認済み」「該当なし」と、スタッフが足した箇所が別の欄で残ります。後から見ると、AIが出した候補、スタッフが確かめた箇所、スタッフが足した箇所が区別できます。

3つ目は、区分の規則が findings と溝の深さだけを読めばよいことです。 区分はアプリの側で次のように決めます。

お客様に渡す控えは、次の形です。

システムへ連携する

販売管理の見積は、この構成から作りません。 交換を勧めるかどうか、どのタイヤを勧めるかはスタッフがお客様と話して決め、見積はこれまでどおり販売管理で作ります。 点検の結果から自動で見積を作ると、お客様には「交換ありき」の点検に見えます。

お客様への控えは、スタッフが説明を終えてから渡します。 控えを先に渡して説明を省くと、区分の言葉だけが一人歩きします。

人が確認する

1. 候補をタイヤで確かめる … 一覧の上から順に、タイヤのその箇所に触れて見ます。「確認済み」か「該当なし」を選びます
2. 見落としを足す … 指でなでて分かる段差や、写真に写らない溝の底の異物を足します
3. 撮影不可の面を見る … ジャッキで上げる作業がある車は、そのときに内側を見て足します
4. 説明文を読み直す … 区分の言葉と数字が合っているかを見て、お客様に写真を見せながら伝えます
5. 外した候補を記録する … 汚れをひびと言った、模様をふくらみと言った、などの理由を残します

1番目を省かないでください。 AIの候補は写真に写ったものだけで、ふくらみや段差は、写真よりも指で触れたほうが確かに分かります。 確かめずに確定すると、写真の影が「ふくらみ」としてお客様に伝わります。

目標は、900件をならして1件3分です。 損傷の候補の少ない車は、溝を計って撮り、印の箇所を見るだけで済みます。候補の多い車や、撮り直しの多い車は数分かかります。 外す候補が1台で半分を超えるなら、撮影の角度か照明が崩れています。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮る順番と、撮れない面の扱いの問題です。 撮影の手順書を整えるほうが、指示の文をいじるより効きます。

記録を残す

• 点検ごとの写真と、Gemini API が返した JSON の全文
• 候補ごとにスタッフが付けた「確認済み」「該当なし」と、スタッフが足した箇所
• 4本の溝の深さ、計った日時、計ったスタッフ
• そのとき使った店の目安の線と、規則で決めた区分
• お客様に渡した控えの文と、渡した日時

2つ目と4つ目が、次の点検のときの材料です。 前回の写真と溝の深さを並べて見られると、「半年でこれだけ減りました」と数字と写真で伝えられます。

4つ目で「そのときの線」を残すのは、店の目安が後から変わるためです。 線を見直したあとに過去の控えを見ると、当時の線が残っていないと、なぜその区分だったのかが分かりません。