組立工程の後に撮った製品の写真を基準の写真と比べ、部品の付け忘れ・向きの誤り・配線の外れの候補を見分けて、検査の担当に確かめる箇所を示す

処理の起点を決める

製造番号のバーコードを読んだときを起点にします。 組立の作業者が台を撮影台に置き、バーコードを読むと、スクリプトがカメラで2枚を撮ります。写真を撮ってからバーコードを読む順にはしません。 先に番号が決まっていないと、写真と台の対応を取り違えます。

撮影はスクリプトが行い、人がシャッターを押す形にしません。 人が押すと、台を置き直す前や手が写っているときに撮れてしまいます。台の位置の目印に台が収まったことを、写真の明るさの変化か台の下のセンサーで確かめてから撮ります。

1台ずつ、その場で結果を返します。 まとめて夜に処理すると、戻すべき台が通電試験に進んでしまいます。検査の担当が台の前にいる間に、枠が画面に出ていることが前提です。返ってくるまでの時間は、確認箇所の数と画像の大きさで変わるため、最初の1週間で台ごとの待ち時間を測ります。

入力データを集める

質を決めるのは、確認箇所の一覧です。 1行が1つの箇所で、「天面の写真のこの枠の中で、端子台TB3の有無を見る」のように書きます。観点は3つに絞ります。

基準の写真は、機種とオプションの組み合わせごとに持ちます。 組み合わせの数が多い機種は、オプションで変わる箇所だけ別の写真を持ち、確認箇所の一覧で使い分けます。 全部の組み合わせを撮りそろえる必要はありません。

図面の版を一覧に持たせるのは、設計変更に追いつくためです。 生産管理システムの図面の版と一覧の版が違えば、比べる前に止めて、基準が古いことを知らせます。

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

撮影台のPCで動く Python のスクリプトが、次の順に集めます。

生産管理システムからの引き方は、システムによって違います。 照会用のAPIがあればそれを使い、無ければ製造番号と機種・オプションを書き出した表を、毎朝ファイルサーバーに置いてもらう形でも足ります。この部分は、利用している生産管理システムに合わせた作り込みになります。

基準の写真は、毎回の呼び出しで画像として直接渡します。 Gemini API には Files API があり、ファイルを上げておいて URI で何度も使えますが、上げたファイルは48時間で自動で消えます。 基準の写真は何か月も使うので、手元のファイルサーバーを正本にし、呼び出しのたびに切り出して渡すほうが管理が単純です。

AIへ渡す前に整形する

1. 写りの確認 … 明るさとピントを数値で見て、暗すぎる・ぼけている写真は撮り直します
2. 位置合わせ … 台の置き方のわずかなずれを、筐体の四隅か目印で合わせます。ずれたままだと、枠の中に違う部品が入ります
3. 確認箇所ごとの切り出し … 一覧の枠で、基準の写真と今の写真から同じ範囲を切り出します。枠より少し広めに取ります
4. 大きさのそろえ … 切り出した2枚を同じ大きさにそろえます
5. 呼び出しのまとめ方 … 1回の呼び出しに、確認箇所1つ分の2枚か、近い箇所をまとめた数組を入れます
6. 図面の版の照合 … 生産管理システムの版と一覧の版が違えば、比べずに止めます

3番目が、この構成でいちばん効く工夫です。 天面の写真全体を渡すと、小さなコネクタは画像の中の数十ピクセルにしかなりません。 確認箇所ごとに切り出せば、同じコネクタが画像いっぱいに写ります。media_resolution を high にするより先に、切り出しで解像度を稼ぎます。

2番目を省くと、3番目が働きません。 枠は基準の写真の座標で決めているため、今の写真の台が数ミリずれると、枠の端の部品が切れます。 撮影台の目印で置き方をそろえ、それでも残るずれをスクリプトで合わせます。

AIに処理させる

させるのは、確認箇所ごとに、基準の切り出しと今の切り出しを比べて、観点に沿った違いがあるかを答えることだけです。

not_visible を正直に返させるのが要です。 見えない部品を「ある」と答えれば付け忘れを見逃し、「無い」と答えれば誤報になります。どちらに倒しても困るので、見えないと答えさせ、実物の確認に回します。

違いの位置も返させます。 differs のときは、切り出した画像の中の位置を box_2d で返させ、スクリプトが元の写真の座標に直して画面に枠を出します。検査の担当は、枠を見てすぐに実物のその場所に目を向けられます。

3行目を禁じるのは、検査の範囲を一覧で管理するためです。 AIが気まぐれに範囲外を指摘すると、その指摘を見るかどうかが担当ごとに分かれ、範囲が人によって変わります。 範囲を広げたいときは、一覧に箇所を足します。

指示内容を固定する

あなたは制御ユニットの組立後の検査を補助する立場です。
1枚目は正しく組み上がった台（基準）の一部、2枚目は今の台の同じ範囲です。
この範囲について、決められた観点だけで2枚を比べてください。

【この範囲の情報】
箇所の番号：{point_id}
部品の名前：{part_name}
観点：{aspect}（presence / orientation / connection のどれか）

【status の選び方】
- ok .......... 観点について、2枚目が1枚目と同じ状態に見える
- differs ..... 観点について、2枚目が1枚目と違って見える
- not_visible . ケーブル・手・影・反射などで、2枚目の該当部分が見えず判断できない
迷ったときに ok を選ばないでください。見えないときは differs ではなく not_visible です。

【differs のときの kind】
- missing ........ 1枚目にある部品が2枚目に無い
- orientation .... 部品の向きが1枚目と違う
- disconnected ... コネクタが浮いている、線が外れている
- other .......... 上のどれにも当たらない違い

【厳守事項】
- 合格・不合格、戻すべきかどうかを書かないでください。
- 部品の型番や文字を読み取って答えないでください。
- 決められた観点以外の違い（色味、明るさ、ほこり）は見ないでください。
- 2枚目に、1枚目に無い物（工具、ねじ、線の切れ端）があれば foreign_object を true にしてください。
- differs のときは、2枚目の中で違って見える場所を box_2d で返してください。
- note には、判断の手がかりにした見た目を短く書いてください（例：「コネクタの爪の位置が1枚目より手前」）。

「迷ったときに ok を選ばない」が、見逃しを減らす一文です。 比べる2枚が似ていると、AIは「同じ」に寄りがちです。同じと言い切れないときは、differs か not_visible に倒させ、人の目に回します。 その分の誤報は、検査の担当が実物を見て「問題なし」を押せば終わります。

「色味・明るさ・ほこり」を見ないよう書くのは、撮影の条件の違いで誤報が出るためです。 照明の当たり方が少し違うだけで、2枚の見た目は変わります。観点に関係ない違いを拾わせないことが、誤報を減らすいちばんの手です。

出力形式を固定する

構造化出力で、確認箇所ごとに次の形のJSONを受け取ります。

{
  "point_id": "TOP-07",
  "aspect": "presence | orientation | connection",
  "status": "ok | differs | not_visible",
  "kind": "missing | orientation | disconnected | other | none",
  "foreign_object": false,
  "box_2d": [0, 0, 0, 0],
  "note": ""
}

status と kind を enum にして、決めた値以外を返させません。 Gemini API の構造化出力では、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 スクリプトでは、differs なのに kind が none、box_2d が範囲外、といった組み合わせを弾き、その箇所を not_visible として扱います。

1台分は、スクリプトが次の形にまとめます。 AIの答えをそのまま並べ、台としての結論は付けません。

4行目の「比べていない」を、「枠なし」と見た目で分けます。 どちらも枠が出ませんが、前者は機械が見ていない台です。 画面の色と文言をはっきり変えます。

システムへ連携する

生産管理システムへは書き込みません。 検査の合否を生産管理システムに入れる作業は、これまでどおり検査の担当が行います。 この構成から書き込むと、AIの誤報がそのまま工程の記録になります。

基準の写真のフォルダは、品質保証部だけが書き換えられるようにします。 撮影台のPCからは読み取りだけです。基準を差し替える権限が検査の現場にあると、誤報の多い箇所の基準を、今の台に合わせて撮り直してしまうことが起きます。

人が確認する

この構成は、すべての台で検査の担当の確認を通します。 枠の無い台も、担当が画面の2枚の写真を見て「確認」を押してから次へ進みます。

1. 赤い枠を実物で確かめる … 枠の場所を見て、「戻す」「問題なし」「基準が古い」のどれかを選びます
2. 黄色い枠を片付ける … ケーブルをよけて撮り直すか、実物で確かめます。撮り直しで消えない黄色は、撮影台の照明か一覧の枠の位置を疑います
3. 「比べていない」の台は従来どおり … チェックシートで照合します
4. 「基準が古い」を品質保証部に回す … 設計変更が基準の写真に反映されていない箇所です

目標は、1,800台をならして1台1分です。 枠の無い台は写真を見て押すだけで数十秒、赤い枠のある台は実物を見るので数分かかります。枠の出る台が1割前後という想定でならすと1分です。

最初の1か月は、従来のチェックシートと並べて動かします。 チェックシートで見つけた違いに、AIが枠を出していたかを1件ずつ照らします。枠が出なかった違いは、一覧の枠の位置か観点を直す材料です。

例外に対処する

「従来の検査に戻る」道を、どの行にも用意しています。 撮影台が止まっても、ラインは止めません。機械が見られない台を、機械が見たかのように通さないことが、この構成でいちばん守るべきことです。

記録を残す

• 台ごとの今の写真（天面と正面）、製造番号、撮影の時刻
• 比べたときの基準の写真と一覧の版
• 確認箇所ごとのAIの答え（status、kind、box_2d、note）
• 検査の担当の判断（戻す／問題なし／基準が古い）と、担当者、時刻
• 箇所ごとの戻しの回数と、「問題なし」の回数
• 「比べていない」で従来の検査に回した台と、その理由

基準の写真と一覧の版を台ごとに残すのは、後から遡るためです。 出荷後に付け忘れが見つかったとき、その台がどの基準で比べられ、どの箇所に枠が出て、誰が何を選んだかを引けます。

箇所ごとの集計は、毎月の組立の打ち合わせに出します。

【組立後の確認の月次集計】2026年9月（1,812台）
 戻しの多い箇所
   CU-40 TOP-07 ケーブル固定具（有無）     戻し 23回
   CU-40 FRT-03 ファン（向き）              戻し 11回
   CU-22 TOP-12 アース線（差し込み）        戻し  9回
 誤報の多い箇所（問題なしの回数）
   CU-22 TOP-05 端子台カバー               問題なし 41回 → 枠の見直し
 比べていない台  37台（図面の版の不一致 21台／撮影の不良 16台）

戻しの多い箇所は、組立の手順書を直す材料です。 固定具の付け忘れが続くなら、取り付ける順番か、部品の置き場所を変えるほうが早く効きます。