倉庫・工場のフォークリフトの始業点検で撮った写真から、異常のおそれと撮り漏れを拾い、点検記録の確認に回す

処理の起点を決める

5分ごとの定時の実行を起点にします。 Apps Script のインストール型トリガーのうち、時間主導型のものは1分ごとから月1回までの間隔で動かせます。公式の説明では、実行の時刻は少しずれることがあるとされているので、5分ごとに設定して、1回の実行でその時点までに届いた点検をまとめて処理します。

始業点検は朝の作業の前の30分ほどに集中します。 届いた点検を5分ごとに処理すれば、職長は朝礼の後に一覧を開いた時点で、ほとんどの車両の結果を見られます。 交代の時刻にも点検が集中するので、2交代の始まりの前後は同じ間隔で動かし続けます。

フォームの入力と写真の両方がそろった車両だけを処理します。 入力から15分たっても写真が届かない車両は、写真なしとして一覧に「撮り直し」の印で出します。写真を待ち続けると、写真を上げ忘れた車両が一覧に出てこなくなるからです。

入力データを集める

質を決めるのは、基準の写真です。 タイヤの溝の深さやチェーンの色は、その車両の正常な状態と比べないと、異常かどうかが分かりません。 整備の業者が月次の自主検査をした直後に、職長が同じ箇所を同じ向きで撮って基準にします。基準の写真を更新した日付も台帳に残します。

撮影箇所の一覧は、型式ごとに変えます。 リーチ型とカウンター型では、タイヤの位置と数も、計器盤の形も違います。台帳に型式ごとの撮影箇所を書いておき、それを AI に渡して照らさせます。

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

Apps Script が、フォームの回答のスプレッドシートと、写真のフォルダを読みます。

運転者の点検の入力は、AI には渡しません。 「否」を付けた項目や自由記入の「左前輪に傷」を見せると、AI はその箇所に候補を寄せて返し、ほかの箇所を見なくなることがあります。 写真から出した候補と運転者の申告は、後段の規則で同じ行に並べます。どちらが見落としたかを、後から切り分けられるようにするためです。

写真は、入力の時刻の前後15分の範囲だけを取ります。 運転者が前日の写真を消し忘れていても、今日の点検に混ざらないようにするためです。範囲の外の写真は、処理せずに古い写真のフォルダへ移します。

写真のファイル名に撮影箇所を書かせることはしません。 朝の忙しい時間に運転者にファイル名を付けさせると、付け間違いがそのまま撮り漏れの誤判定になります。撮影箇所は AI が写真の中身から見分けます。 運転者の仕事は、決められた箇所を撮って上げることだけです。

AIへ渡す前に整形する

1. 形式の確認 … JPEG・HEIC などの対応する形式かを確かめます。それ以外は撮り直しの印にします
2. 大きさの縮小 … 1枚の長い辺を決めた大きさまで縮め、点検の写真と基準の写真を合わせて20MBに収めます
3. 向きの補正 … 写真の向きの情報に従って回転させます。公式の説明も、画像が正しく回転しているか確かめるよう勧めています
4. 重複の除去 … 同じ時刻にほぼ同じ写真が何枚もあるときは、1枚を残します
5. 枚数の確認 … 撮影箇所の数より極端に少ないときも、そのまま AI に渡します。撮り漏れは AI の判別と規則で数えます

2番目と3番目を軽く見ないでください。 スマートフォンの写真は1枚で数MBあり、縮めずに14枚並べると上限を超えます。横倒しのタイヤの写真は、AI が撮影箇所を取り違える原因になります。

AIに処理させる

させるのは、写真ごとに「どの撮影箇所の写真か」「写り具合はどうか」「異常のおそれのある箇所はどこか」を返すことだけです。 異常の候補は、基準の写真と比べて何が違うかを、位置と一緒に返させます。

写り具合の行が、この構成でいちばん大事な区別です。 ぶれた写真で「異常なし」と返すと、見えていないことが「問題が無い」に化けます。 写り具合が悪い写真では異常の判定そのものをさせず、撮り直しに回します。

灯火は、点いて写っているかだけを見ます。 前照灯が点いているかは写真で分かりますが、方向指示器や警報装置の機能が正しく働くかは、写真では確かめきれません。 写っていないものは not_visible とし、機能の確認は運転者の入力のほうで記録します。

1行目がいちばん起きやすい失敗です。 異常の候補が無い写真について、AI は「使用に問題ありません」と書き添えがちです。一覧にその一文が並ぶと、運転者の点検よりも AI の一文が信じられるようになります。 使用の可否に触れる文は出力の項目に置かず、指示でも禁じます。

指示内容を固定する

あなたは工場の構内でフォークリフトの始業点検の写真を確認する補助をします。
運転者の点検の代わりではありません。写真に写っていることだけを答えてください。

【車両】{vehicle_id}（型式：{model_type}）
【撮影箇所の一覧】{positions}
  例：fork_mast／chain／tire_front_left／tire_front_right／tire_rear／dashboard／lamps
【写真】点検の写真（P1〜）と、同じ車両の基準の写真（R-箇所名）を順に渡します

【返すこと】
- 点検の写真ごとに：position（撮影箇所の一覧から1つ、当たらなければ unknown）、
  quality（good／poor）と、poor の理由（blur／dark／cut_off／obstructed）
- quality が good の写真について、基準の写真と比べて異なる点を findings に：
  category（tire_damage／tire_wear／foreign_object／fork_or_mast／chain／oil_trace／
  warning_lamp_on／lamp_not_lit／other）、box_2d、何が見えるかの説明、confidence（high／medium／low）
- missing_positions：撮影箇所の一覧のうち、どの写真にも写っていない箇所

【厳守事項】
- quality が poor の写真では findings を返さないでください。
- 写っていないものについて、異常の有無を推測しないでください。
- ブレーキ、ハンドル、方向指示器、警報装置の機能は写真から判断しないでください。
  灯火は「点いて写っているか」だけを答え、写っていなければ not_visible としてください。
- 「使用して問題ない」「使用を止めるべき」など、使用の可否を書かないでください。
- タイヤの交換時期や修理の要否を書かないでください。
- 床の汚れと油の染みを区別できないときは、oil_trace として confidence を low にしてください。
- 人の顔が写っていても、人について何も書かないでください。

「quality が poor の写真では findings を返さない」を明記しないと、ぶれた写真にも判定を付けます。 ぶれた写真の判定は、たいてい「目立った異常なし」です。それが一覧に並ぶと、撮り直しを頼む理由が消えます。

「基準の写真と比べて異なる点を」と書くのは、新品のタイヤとの比較を避けるためです。 基準を渡さずに聞くと、AI は一般的な新品の見た目と比べ、使い込んだ正常なタイヤにまで摩耗の候補を付けます。 その車両の正常な状態と比べさせると、候補が実際の変化に絞られます。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "vehicle_id": "FL-12",
  "inspection_id": "",
  "photos": [
    {
      "photo": "P3",
      "position": "tire_front_left | ... | unknown",
      "quality": "good | poor",
      "poor_reason": "blur | dark | cut_off | obstructed | ",
      "findings": [
        { "category": "tire_damage", "box_2d": [412, 380, 655, 590],
          "description": "", "confidence": "high | medium | low" }
      ]
    }
  ],
  "missing_positions": ["chain"],
  "lamps": { "headlight": "lit | not_lit | not_visible", "rear_light": "lit | not_lit | not_visible" }
}

スキーマでは position・quality・category・confidence を enum にし、box_2d は4つの整数の配列にします。required で photos と missing_positions を必ず返させます。

1つ目の理由は、印を規則で決められることです。 Apps Script は次の規則で車両ごとの印を決めます。AI の出力がどう揺れても、印の決め方は表のとおりです。

2つ目は、box_2d で職長の確認が速くなることです。 座標を元の写真の大きさに戻して枠を描いた画像を一覧に貼るので、職長は写真のどこを見ればよいかを一目で分かり、現物でもその場所に直行できます。

3つ目は、運転者の入力と同じ行に並べられることです。 運転者が「良」を付けた車輪の行に、写真から tire_damage の候補が出ていれば、点検と写真の食い違いとして職長がすぐ気づけます。

システムへ連携する

修理の依頼と使用の停止は、この構成からは行いません。 要確認の車両を現物で見て、使用を止めるかを決めるのは職長です。AI の候補から自動で修理を依頼すると、床の汚れの写真で整備の業者が呼ばれます。

人が確認する

職長が開くのは「要確認」と「撮り直し」の車両です。 印の無い車両は、一覧で運転者の入力と写真の枚数を流し見て、確認の印を入れます。

1. 「要確認（運転者の申告）」を先に見る … これまでどおり現物を確かめ、使用を止めるかを決めます
2. 「要確認（写真）」の枠を見て現物に行く … 枠の場所を自分の目で見ます。写真の候補が誤りなら、一覧に「誤り」と記録します
3. 「撮り直し」の運転者に声をかける … 撮り漏れの箇所か、写り具合の悪い写真を撮り直してもらいます
4. 全車両の行に確認の印を入れる … 印を入れた時刻が残ります

2番目の「誤り」の記録を省かないでください。 同じ車両で同じ誤りが続くなら、基準の写真が古いか、撮る向きがずれています。誤りの記録が、基準の写真を撮り直す合図になります。

目標は、600件をならして1件1分です。 印の無い車両は数秒、要確認の車両は現物を見るので数分です。要確認が全体の1割を大きく超える月は、基準の写真が古くなっているか、撮影の向きがそろっていません。

例外に対処する

最後の行で、API が止まっても一覧から車両が消えないようにします。 写真の確認が止まっても、運転者の点検と職長の確認は止めません。

記録を残す

• 点検の入力の全項目と、写真のファイルの場所
• Gemini API に渡した写真の一覧と、返ってきたJSONの全文
• 規則で決めた印と、その根拠になった項目
• 職長の確認の印、現物を見た結果、写真の候補を「誤り」とした記録
• 使用を止めた車両と修理の依頼との対応
• 車両ごと・撮影箇所ごとの撮り漏れの回数

最後の行は、点検のやり方を見直す材料になります。 特定の運転者や特定の箇所で撮り漏れが続くなら、撮りにくい位置にあるか、点検の手順そのものが伝わっていません。