鋳造工場で撮った鋳物の外観の写真を Gemini で見て、巣・湯じわ・欠けなどの欠陥の候補を拾い、外観検査の記録の下書きにする
仕上げの後に撮影台で撮った鋳物の外観の写真を、限度見本の写真と一緒に Gemini で見て、巣、湯じわ、欠け、砂かみ、割れの疑いの候補を輪郭と面の番号つきで拾います。外観検査の記録の下書きにし、検査員が現物で確かめて合否を決めます。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 製造
- 対象部門
- 品質管理/生産
- 対象業務
- 内容確認・チェック/記録・議事録作成
- 主な課題
- 入力作業が多い/属人化している/確認ミスが多い
- AIで行う処理
- 画像認識
- 主な効果
- 入力漏れ削減/品質標準化/工数削減
- 導入難易度
- ★★★★☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 仕上げの終わった鋳物を検査台に運ぶ
- 検査の基準書と図面を見て、品番ごとの重要な面(シール面、ねじ穴の周り、加工の前の面)を確かめる
- 面ごとに向きを変え、欠陥を目で探す
- 気になる箇所の大きさをスケールで測り、限度見本と見比べる
- 用紙の略図に位置を書き、種類と大きさを書く
- 合否と処置(合格、手直し、再検査、廃却)を決めて用紙に書く
- 夕方に、用紙の内容を表計算に入力する
- 人検査員が鋳物を撮影台に載せ、品番の札を読み取らせて、決まった向きで面ごとに撮る
- 自動撮った写真が共有のフォルダに保存され、処理のプログラムが品番と面の番号を読む
- 自動品番の限度見本の写真と重要な面の情報を添えて、Gemini API に面ごとの写真を渡す
- 自動欠陥の候補の輪郭、種類、限度見本と比べた見え方、写っていない範囲を JSON で受け取る
- 自動プログラムが写真に輪郭を描き、外観検査の記録の下書きの行を作る
- 人検査員が画面で候補を見て、現物で候補の箇所を確かめ、大きさを測る
- 人検査員が、候補ごとに「欠陥」「欠陥でない」を選び、合否と処置を決める
- 人検査員が、画面で候補の無かった面も現物で見て、AIの拾わなかった欠陥があれば足す
各工程の詳しい説明を読む
- 仕上げの終わった鋳物を検査台に運ぶ
- 検査の基準書と図面を見て、品番ごとの重要な面(シール面、ねじ穴の周り、加工の前の面)を確かめる
- 面ごとに向きを変え、欠陥を目で探す
- 気になる箇所の大きさをスケールで測り、限度見本と見比べる
- 用紙の略図に位置を書き、種類と大きさを書く
- 合否と処置(合格、手直し、再検査、廃却)を決めて用紙に書く
- 夕方に、用紙の内容を表計算に入力する
(a)記録に時間がかかる。 5番目と7番目の手順で、同じ内容を二度書いています。1個の鋳物に欠陥の候補が3つあれば、略図に3つの丸、種類と大きさを3行書き、夕方にもう一度入力します。
(b)見落としが疲れで増える。 午後の検査で、小さなピンホールや浅い湯じわの見落としが出ます。後の加工の工程で見つかると、その鋳物はすでに加工の時間をかけた後です。
(c)合否が人によって分かれる。 限度見本の見方が検査員ごとに違い、同じ見え方の欠陥が、ある人は合格、ある人は手直しになります。どの見本と比べたかが記録に残っていないので、後から確かめられません。
(d)記録を後から見返せない。 「ボス部に巣」と書かれていても、どのボスのどの辺りかは、用紙の略図を探さないと分かりません。 同じ品番で同じ場所に欠陥が続いているかを、鋳造の工程に返す材料が作れません。
- 【人】 検査員が鋳物を撮影台に載せ、品番の札を読み取らせて、決まった向きで面ごとに撮る
- 【自動】 撮った写真が共有のフォルダに保存され、処理のプログラムが品番と面の番号を読む
- 【自動】 品番の限度見本の写真と重要な面の情報を添えて、Gemini API に面ごとの写真を渡す
- 【自動】 欠陥の候補の輪郭、種類、限度見本と比べた見え方、写っていない範囲を JSON で受け取る
- 【自動】 プログラムが写真に輪郭を描き、外観検査の記録の下書きの行を作る
- 【人】 検査員が画面で候補を見て、現物で候補の箇所を確かめ、大きさを測る
- 【人】 検査員が、候補ごとに「欠陥」「欠陥でない」を選び、合否と処置を決める
- 【人】 検査員が、画面で候補の無かった面も現物で見て、AIの拾わなかった欠陥があれば足す
6番目から8番目が、この設計の分かれ目です。 AIの候補は、検査員がどの面のどこを先に見ればよいかを示すものです。合否を決めるのも、現物を見るのも検査員です。 8番目を省くと、AIが拾わなかった欠陥がそのまま出ていきます。
5番目で作る下書きの行には、合否と処置の欄を空けておきます。 AIの候補から合否を自動で埋める経路を作りません。
02今回想定するシステム構成
仕上げの終わった鋳物 ▼ 撮影台(照明の向きと距離を固定。面ごとに決まった向きで撮る) 撮影のパソコン ── 品番の札と面の番号をファイル名に入れて保存 ▼【トリガー】共有のフォルダへの保存 処理のプログラム(Python) ├── 品番の検査の基準(重要な面、限度見本の写真の一覧)を読む ├── 限度見本の写真は Files API に上げておき、参照する ▼ Gemini API(画像の理解・輪郭・構造化出力)── 面ごとの写真+限度見本 │ 欠陥の候補の輪郭と枠、種類、限度見本と比べた見え方 │ 重要な面かどうか、写っていない範囲(影、反射、治具) ▼ 処理のプログラム ── 輪郭を描いた写真と、記録の下書きの行 ▼ 【人】検査員が現物で候補を確かめ、合否と処置を決める ▼ 外観検査の記録(表計算)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 処理 | Gemini API(面ごとの写真と限度見本を比べ、欠陥の候補を輪郭で返す) | Claude API、OpenAI API |
| 連携 | Python(フォルダの監視、基準の読み込み、呼び出し、輪郭の描画、下書きの作成) | Google Apps Script |
| 撮影 | 撮影台と固定のカメラ、照明 | - |
| 記録 | 外観検査の記録の表(共有の表計算) | 品質の記録の仕組み |
新しく足すのは、撮影台とプログラム、Gemini API の契約、そして品番ごとの限度見本の写真です。 検査の基準書、図面、限度見本の現物は、すでにあるものです。合否の基準と、手直し・廃却の処置の決め方は変えません。
写真を見る土台は、Gemini API の画像の理解です。 公式の案内では、対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、1つのリクエストに複数の画像を入れられます。 枠は [ymin, xmin, ymax, xmax] の順で0〜1000に正規化され、元の画像の大きさに戻して使います。Gemini は物を見つけるだけでなく、輪郭のマスクを返すとされ、その場合は思考の水準を最小にすると結果が良くなると書かれています。湯じわや砂かみのように広がりのある欠陥は、輪郭で返させます。
限度見本の写真は、Files API に上げて参照します。 公式の案内では、Files API にはプロジェクトあたり20GB、1ファイル2GBまで保存でき、保存は48時間で、その後は自動で消えます。 利用は無料で、上げたファイルは interactions.create の入力から参照します。限度見本は毎朝上げ直し、その日の検査で使い回します。
出力は構造化出力で受けます。 /v1beta/interactions に送り、response_format で mime_type を application/json にし、schema にスキーマを入れます。enum で値を決まった文字列に絞れます。値はアプリ側で検証するよう書かれています。
03どうやって実装するのか
処理の起点を決める
撮影のパソコンが写真を共有のフォルダに保存したときに動きます。 処理のプログラムがフォルダを見張り、1個の鋳物の全部の面がそろったところで処理を始めます。 面がそろったかは、品番の基準に書いた面の数とファイルの数で見ます。
面がそろわないまま5分たったら、撮り漏れとして検査員の画面に出します。 撮影台の上で鋳物を回し忘れた面があれば、その場で撮り直せます。
処理が終わったファイルは、処理済みのフォルダに移します。 移すのは下書きの行を作り終えたときだけです。共有のフォルダに残っている数が、処理を待っている数になります。
撮影台に載らない大物は、台車の上で撮ります。 台車に目印の板を立て、カメラを三脚で決まった距離に置きます。撮る面の数は品番の基準の表で決め、大物だけ面の数を増やします。 面がそろったかの数え方は、撮影台のときと同じです。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 面ごとの写真 | 品番、製造の番号、面の番号、撮った日時 | 撮影のパソコン(ファイル名と写真) |
| 品番の検査の基準 | 面の数、重要な面(シール面、ねじ穴の周り、加工の前の面)、見る欠陥の種類 | 品番ごとの検査の基準書から書き抜いた表 |
| 限度見本の写真 | 欠陥の種類ごとに「合格の限界」「不合格」の見本を、同じ撮影台で撮ったもの | 限度見本のフォルダ(Files API に上げる) |
| 面の略図 | 面ごとの輪郭の図と、部位の名前(フランジ、ボス、リブ など) | 品番の基準の表 |
| 欠陥の種類の一覧 | 巣、ピンホール、湯じわ、湯回りの不良、欠け、割れの疑い、砂かみ、バリの残り | プログラムに持たせる |
質を決めるのは、限度見本の写真を同じ撮影台で撮ることです。 照明の向きが違うと、同じ深さの巣でも影の出方が変わり、見本と比べられません。 限度見本の現物を撮影台に載せ、製品と同じ距離と照明で撮ります。
部位の名前も渡します。 AIが「上の方」と返すより、「2番の面のフランジの内側」と返すほうが、検査員が現物で探す時間が短くなります。 部位の名前は、図面の呼び方にそろえます。
データの取得方法を決める
写真の品番と面の番号は、ファイル名から読みます。 撮影のパソコンは、検査員が品番の札を読み取らせたときの品番と、撮影の順の面の番号をファイル名に入れて保存します。ファイル名の決まりを外れたものは処理せず、検査員の画面に出します。
品番の検査の基準は、表から読みます。 重要な面と見る欠陥の種類、限度見本の写真の一覧を、品番ごとの行から取ります。 基準の表に無い品番は、処理を止めて品質管理の担当に知らせます。
Gemini API へは、面ごとに1回、その面の写真と、その品番の限度見本の写真を渡します。 限度見本は Files API に上げたものを参照し、面の写真はその都度送ります。 面ごとに分けると、撮り直したときにその面だけを見直せます。
1つの面は、照明を変えて2枚撮ります。 正面からの照明の写真と、斜めからの照明の写真です。浅い湯じわや細い割れは、斜めの照明で影ができて初めて見えることがあります。 検査員が現物を手に取り、角度を変えて見ているのと同じことを、2枚の写真で渡します。2枚は同じ呼び出しに入れ、どちらの写真で見えた候補かを返させます。
有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し(有料の枠で55日)、保存しないときは store=false を付けると案内されています。
AIへ渡す前に整形する
- 撮影の条件の確認 … 照明の向きと距離が決まりどおりかを、撮影台の目印が写っているかで確かめます
- ピントと露出の確認 … ぶれや白飛びの大きい写真は、撮り直しの印を付けます
- 切り出し … 撮影台の背景を外し、鋳物の写っている範囲だけを残します
- 大きさ … 小さなピンホールが見えるよう、縮めすぎない大きさで送ります
- 重要な面の付け足し … その面が重要な面か、どの部位があるかを指示に入れます
- 限度見本の参照の付け足し … その品番の、欠陥の種類ごとの見本を参照に入れます
4番目を軽く見ないでください。 公式の案内では、大きな画像は768×768ピクセルの区画に分けられ、区画ごとにトークンが数えられます。 縮めれば費用は下がりますが、直径1ミリのピンホールは、縮めた写真では画素のつぶれと区別できません。 小さな欠陥を見る面は、部分を拡大した写真を別に撮る決まりにします。
1番目の目印は、撮影の条件が崩れたことに気付くためのものです。 照明の位置が少しずれただけで、AIの候補の数が急に増えたり減ったりします。 目印が写真の決まった位置に無ければ、処理をせずに撮影台を直すよう画面に出します。
AIに処理させる
させるのは、面ごとの写真を限度見本と比べ、欠陥の候補を輪郭と枠で返し、種類の候補と見え方と、写っていない範囲を返すことだけです。
| 返すもの | 中身 | 判断できないときの扱い |
|---|---|---|
| 候補の位置 | 輪郭と枠、面の番号、部位の名前 | 部位が分からなければ部位を空けて位置だけを返す |
| 種類の候補 | 巣、ピンホール、湯じわ、湯回りの不良、欠け、割れの疑い、砂かみ、バリの残り | 種類が決まらなければ unclear |
| 限度見本と比べた見え方 | 「合格の限界の見本より小さい」「不合格の見本に近い」「比べる見本が無い」 | 比べられなければ no_reference |
| 重要な面かどうか | 基準の表の重要な面にあるか | - |
| 写っていない範囲 | 影、反射、治具で隠れた範囲、ピントの外れた範囲 | 範囲がはっきりしなければ面ごと「見えない範囲あり」 |
右端の列の考え方は、迷ったら検査員に見せる側に倒すことです。 鋳肌の模様か湯じわか分からないものは unclear として返させます。候補が多いのは検査員の数秒で済みますが、候補から落ちた割れの疑いは、加工の後か、お客様のところで見つかります。
| させないこと | 理由 |
|---|---|
| 合否の判定 | 図面の指定と限度見本で検査員が決める |
| 手直し・再検査・廃却の処置の決定 | 工程と納期を見て検査員と仕上げの係が決める |
| 大きさや深さのミリの値 | 写真からは正確に測れない。検査員がスケールで測る |
| 内部の欠陥の推測 | 外観の写真からは分からない。X線などの検査の領域 |
| 欠陥の原因の断定(ガスか、湯温か、砂か) | 原因は鋳造の工程の記録と合わせて技術の担当が見る |
| 「欠陥なし」の結論 | 写っていない範囲がある限り言えない |
1行目と3行目がいちばん起きやすい失敗です。 写真に巣が写っていると、AIは「直径約2mmの巣、不合格」と書きたがります。記録の下書きにその言葉が載ると、検査員がスケールを当てる前に結論が決まってしまいます。 返すのは「不合格の見本に近い見え方の巣の候補」までにします。
5行目も、記録の使い方を守るためです。 原因が書かれた記録は、鋳造の工程で確かめないまま対策の根拠に使われるおそれがあります。
指示内容を固定する
あなたは鋳造工場の外観検査の記録づくりを手伝う係です。
検査員が合否を決めます。あなたは、検査員が先に見るべき箇所を示してください。
【製品】品番 {品番} 【面】{面の番号}(部位:{フランジ、ボス、リブ ...})
【この面は重要な面か】{はい:シール面/いいえ}
【見る欠陥の種類】巣、ピンホール、湯じわ、湯回りの不良、欠け、割れの疑い、砂かみ、バリの残り
【限度見本】参照の画像のうち、{種類}_limit は合格の限界、{種類}_ng は不合格の見本です。
【やること】
1. 検査の写真(最後の2枚。正面の照明と斜めの照明)で、欠陥の候補を探す。
2. 候補ごとに、正面の照明の写真の上の輪郭と枠を返す。
枠は [ymin, xmin, ymax, xmax] の順で 0〜1000 に正規化する。
どちらの照明の写真で見えたかを seen_in に書く。
3. 候補ごとに、種類の候補を上の一覧から1つ選び、部位の名前を書く。
4. 候補ごとに、限度見本と比べた見え方を
smaller_than_limit/near_limit/near_ng/no_reference から選ぶ。
5. 影、反射、治具、ピントの外れで見えない範囲を返す。
【厳守事項】
- 合格か不合格かを書かないでください。
- 大きさや深さをミリなどの数字で書かないでください。
- 欠陥の原因を書かないでください。
- 鋳肌の模様か欠陥か分からないものは、kind を unclear にして候補に入れてください。
- 割れの疑いは、細い線でも候補に入れてください。
- 見えない範囲について「欠陥なし」と書かないでください。
- 限度見本に無い種類は、見え方を no_reference にしてください。
「割れの疑いは、細い線でも候補に入れる」を別に書くのは、割れがいちばん重いからです。 割れは、鋳肌の筋や研削の跡と見分けにくく、何も言わなければ「模様」として落とされます。 割れの疑いは、多めに拾わせて検査員が消す側に置きます。
「合格か不合格かを書かない」を最初に置くのは、記録の責任の所在のためです。 合否は、図面の指定と限度見本で検査員が決めるもので、記録の上でも検査員の判断として残します。
出力形式を固定する
面ごとに、次の形の JSON で受け取ります。 kind、vs_reference、reason は enum で決まった文字列に絞ります。
{
"part_no": "PC-2210",
"serial": "2026-1026-031",
"face": 2,
"critical_face": true,
"candidates": [
{ "box_2d": [412, 230, 448, 266],
"has_mask": true,
"seen_in": "front | oblique | both",
"kind": "blowhole | pinhole | cold_shut | misrun | chip | crack_suspect | sand_inclusion | fin | unclear",
"location": "フランジの内側",
"vs_reference": "smaller_than_limit | near_limit | near_ng | no_reference" }
],
"not_visible": [ { "area": "右下", "reason": "shadow | glare | jig | out_of_focus" } ]
}
1つ目の理由は、critical_face と vs_reference で検査員の見る順を決められることです。 重要な面で near_ng か crack_suspect の候補が先頭に、鋳肌のままの面の smaller_than_limit が後ろに並びます。検査員は、先頭の候補から現物を確かめます。
2つ目は、box_2d と location で記録に位置が残ることです。 これまで用紙の略図の丸でしか残らなかった位置が、写真の上の枠と部位の名前として記録の行に入ります。 同じ品番の同じ部位に巣が続いているかを、行を並べるだけで見られます。
3つ目は、not_visible で撮り直しの面が分かることです。 反射で見えない範囲が大きい面は、検査員が現物で特に注意して見る面として画面に出します。
記録の下書きの行は、次の形です。
| 製造の番号 | 面 | 部位 | 候補 | 見本と比べて | 検査員の判断 | 大きさ | 合否・処置 |
|---|---|---|---|---|---|---|---|
| 2026-1026-031 | 2 | フランジの内側 | 巣 | near_ng | (検査員が選ぶ) | (検査員が測る) | (検査員が書く) |
| 2026-1026-031 | 3 | リブの根元 | 割れの疑い | no_reference | (検査員が選ぶ) | (検査員が測る) | (検査員が書く) |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 撮影のパソコン | 共有のフォルダへの保存 | 面ごとの写真。品番・製造の番号・面の番号をファイル名に入れる |
| 品番の検査の基準 | 表の読み取り | 重要な面、部位、限度見本の一覧。書き込まない |
| Gemini API | API呼び出し(Files API で限度見本を参照、/v1beta/interactions、store=false) | 候補の輪郭と枠、種類、見え方、見えない範囲 |
| 検査員の画面 | 処理のプログラムが作る一覧 | 輪郭を描いた写真と候補。検査員が判断と大きさを入れる |
| 外観検査の記録 | 表への書き込み | 候補の欄だけ。判断・大きさ・合否・処置の欄には書かない |
合否と処置の欄には、プログラムから何も書きません。 合否は検査員が画面で選んだものだけが記録に入ります。AIの候補から「不合格」の行が作られる経路を作りません。
顧客に出す検査成績書には、この記録から自動で写しません。 成績書は、検査員の判断と測った値をもとに品質管理の担当が作ります。
人が確認する
- 候補を現物で確かめる … 画面の先頭の候補から、現物のその部位を見ます。スケールを当てて大きさを測り、限度見本の現物と比べます
- 候補ごとに判断を選ぶ … 「欠陥」「欠陥でない(鋳肌の模様、研削の跡、汚れ)」を選びます。欠陥でないときは理由を選びます
- 候補の無かった面も見る … 全部の面を現物で見て、AIの拾わなかった欠陥があれば足します。足したものには「AIの候補に無し」の印が付きます
- 合否と処置を決める … 図面の指定と限度見本で合否を決め、手直し・再検査・廃却を書きます
- 迷うものは班長に回す …
crack_suspectとno_referenceの候補で判断に迷うものは、班長か品質管理の担当が見ます
3番目を省かないでください。 AIは、反射や影の中の欠陥、写真の端の欠陥を拾えないことがあります。画面に候補が無いことは、欠陥が無いことではありません。 現物の確認は、候補のある箇所を先に、その後に全体を手早く見る順にします。
目標は、1,200件をならして1件2分です。 候補の無い小さな鋳物は1分ほどで済み、重要な面に候補の多い大きなケーシングは10分を超えます。3番目で足した欠陥が週に何件あるかを数え、多い品番は撮影の向きと照明を見直します。
経験の浅い検査員にとっては、候補と限度見本の見え方が並ぶこと自体が教材になります。 「near_limit と出た巣を、経験の長い検査員は合格にした」という記録が残れば、同じ見え方のものをどう判断するかを、記録を見ながら覚えられます。
例外に対処する
| 起きること | 対応 |
|---|---|
| 面がそろわない(撮り漏れ) | 5分たったら検査員の画面に出し、撮り直す |
| ファイル名の決まりを外れる | 処理せず、検査員の画面に出す |
| 基準の表に無い品番 | 処理を止め、品質管理の担当に知らせる |
| 限度見本の写真が無い種類 | no_reference として返る。見本の撮影を品質管理の担当に頼む |
| 反射や影で見えない範囲が大きい | not_visible として返る。照明の向きを変えて撮り直すか、現物で特に注意して見る |
| 限度見本の参照が48時間で消えている | 毎朝上げ直す。上げ直しに失敗したら、その日は処理を止めて知らせる |
JSON の値が enum に無い | その面の候補を下書きに書かず、検査員に回す |
| Gemini API が応答しない | 共有のフォルダに残し、検査員は従来どおり用紙で記録する |
上から5行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮影と基準の整備の問題です。 撮影台の目印と、限度見本の写真をそろえるほうが、指示の文をいじるより効きます。
記録を残す
- 面ごとの写真と、Gemini API が返した JSON の全文
- そのときの品番の検査の基準と、参照した限度見本の写真の版
- 検査員が「欠陥でない」とした候補と、その理由
- 検査員が足した欠陥(AIの候補に無かったもの)
- 検査員が測った大きさ、合否、処置
- 品番・部位ごとの欠陥の続き方
4つ目の行が、この構成でいちばん大事な記録です。 AIの拾わなかった欠陥が、どの面のどの部位に、どんな照明で出たかが分かれば、撮影の向きと限度見本の写真をどこで足すかが決まります。
最後の行は、鋳造の工程に返す材料になります。 同じ品番の同じ部位に巣が続いていれば、技術の担当が、湯口や押し湯の位置、注湯の条件の記録と合わせて原因を見ます。
04実装レベルの3段階
最小構成では件数がさばけません。 月1,200個の写真を手で渡す時間はありません。確かめるための段階です。 半自動化で、1件5分が3分程度になります。 候補の拾い出しは自動になりますが、記録の用紙と表計算への入力が残ります。本格構成で2分になり、この段階が本記事の想定です。 差が大きいのは、候補の位置と種類が記録の行に入り、用紙と入力の二度書きが無くなるからです。 段階を飛ばさないでください。 半自動化で1か月検査すると、検査員が「欠陥でない」とした候補の多い品番と、足した欠陥の多い面が分かります。そこの照明と限度見本を直してから本格構成に進むほうが、検査員の確認の時間が減ります。
05工数削減シミュレーション
導入後 1,200件 × 2分 ÷ 60 = 40 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 鋳鉄・鋳鋼・アルミの鋳物を多品種で作り、仕上げの後の外観検査を検査員の目視で行っている鋳造工場。製品の大きさが手で持てるものから台車で運ぶものまでで、専用の外観検査の装置を品番ごとに入れるほどの数が無い場合。検査の記録が手書きの用紙か、後からの入力になっていて、欠陥の位置と種類が言葉だけで残っている場合。限度見本はあるが、見る人によって合否が分かれる場合。
- 同じ品番を大量に流し、専用の画像検査の装置ですでに全数を見ている場合。内部の欠陥(引け巣、内部の割れ)を見つけることが目的の場合(X線や超音波の検査の領域です)。なお、鋳物の合否の判定、手直しや廃却の処置の決定、内部の欠陥の有無、顧客に出す検査成績書の記載の判断は、この構成では代替できません。
07最小構成で試す方法
- 先月検査した鋳物から、1品番を選ぶ(欠陥のあったものと無かったものを合わせて20個)
- 撮影台を仮に作り、限度見本と20個を同じ距離と照明で面ごとに撮る
- Gemini API の有料の利用枠で、面の写真と限度見本の写真を渡す
- 「この面の欠陥の候補を輪郭と枠で示し、種類と、限度見本と比べた見え方を付けてください。合否と大きさは書かないでください」と指示する
- 出てきた候補を、当時の検査の記録と突き合わせる
20個は必ずやってください。 撮影台とプログラムを組む前に、「いまの照明と距離で、限度見本と比べた見え方が返るのか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
当時の記録の欠陥の大半が候補に入り、near_ng が不合格だったものに付いた | 撮影台の作り込みとプログラムの作成に進む |
| 合否や大きさを書いた | 指示の書き方で直る。構成は有効 |
鋳肌の模様をほとんど巣として拾う、または not_visible が多い | 撮影の照明と距離が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 失敗ではなく、検査員が照明の角度を変えながら現物で見ていたことの意味が分かったということです。 斜めからの照明を足して、もう一度撮ってください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 合否や大きさのミリの値を書く | 指示で禁じる。 下書きの合否の欄を空ける |
| 鋳肌の模様を巣として大量に拾う | 限度見本を添え、斜めの照明で撮る |
| 割れの疑いを模様として落とす | 細い線でも候補に入れるよう指示に書く |
| 限度見本と撮影の条件が違う | 見本も同じ撮影台で撮る |
| 小さなピンホールが見えない | 縮めすぎない。部分を拡大した写真を別に撮る |
| 限度見本の参照が消える | Files API の保存は48時間。毎朝上げ直す |
| 画面に候補が無い面を見ない | 全部の面を現物で見る手順を、検査の基準書に書く |
| 欠陥の原因が記録に残る | 原因を書かせない。技術の担当が工程の記録と合わせて見る |
| 照明の位置がずれて候補の数が急に変わる | 撮影台の目印で条件の崩れを検知し、処理を止める |
| 品番の基準の表が追いつかない | よく流れる品番から整え、無い品番は用紙の検査に残す |
上の2行が、この構成の失敗のほとんどです。 どちらも、AIに検査員の判断の代わりをさせる失敗と、写真の条件が見本とそろっていない失敗です。合否の欄を空けておき、見本と同じ条件で撮るかどうかで、検査員の判断が守られるかが決まります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 鋳物の写真、品番、製造の番号、検査の基準、限度見本の写真です。個人の情報はほとんどありませんが、取引先の製品の形と図面の情報が写真に含まれます。
- 取引先との取り決めを確かめる … 製品の写真を外部のサービスに送ってよいかは、取引先との秘密保持の取り決めで決まります。始める前に、品質管理と営業の担当で確かめます
- 有料の利用枠で、保存させない … 規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API の
storeをfalseにします - Files API の保存の期間を知っておく … 限度見本は48時間で自動で消えます。上げたファイルは後からダウンロードできないとされているので、元の写真は社内に残します
- 図面を送らない … AIに渡すのは面の写真と部位の名前までです。図面そのものは渡しません
- 合否の責任の所在を変えない … 外観検査の合否は、これまでどおり検査員が決め、記録の上でも検査員の判断として残します
- 顧客への成績書に自動で写さない … 成績書は、検査員の判断と測った値をもとに人が作ります
誤りが起きた場合のリスクは、AIが拾わなかった欠陥がそのまま出荷されることと、AIの候補をそのまま合否にして良品を廃却することの2つです。 前者は候補の無い面を見ないと起き、後者は合否の欄をAIに埋めさせると起きます。どちらも、全部の面を現物で見る手順と、合否の欄を空けておく設計で防げます。
10まず何から始めるか
1週目:品番を1つ選び、撮影の条件を決める
よく流れる品番を1つ選び、仮の撮影台で、照明の向きと距離、面ごとの向きを決めます。撮影台に目印を置き、写真に必ず入るようにします。
2週目:限度見本を撮り、20個で試す
その品番の限度見本を同じ撮影台で撮り、20個の鋳物を面ごとに撮って Gemini API に渡します。当時の記録の欠陥が候補に入るか、合否や大きさを書いていないかを最優先で見ます。
3週目:品番の基準の表を作る
その品番の面の数、重要な面、部位の名前、見る欠陥の種類、限度見本の写真の一覧を表にします。部位の名前は図面の呼び方にそろえます。
4週目:撮影から候補の一覧までをつなぐ
フォルダの監視で呼び出し、輪郭を描いた写真と候補の一覧を検査員の画面に出すところまで作ります。この時点では記録の下書きを作らず、検査員は従来どおり用紙に書きます。
2か月目: 記録の下書きの行と、検査員の判断の入力を足し、用紙をやめます。「欠陥でない」とした候補と、足した欠陥を毎週数えます。3か月目以降: 品番を広げ、1件5分が何分になったかを実測します。足した欠陥の理由が撮影の条件と限度見本に反映され、品番・部位ごとの欠陥の続き方を鋳造の工程に毎月返せるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
対応する画像の形式が PNG、JPEG、WEBP、HEIC、HEIF であること。1つのリクエストに複数の画像を入れられること。枠が [ymin, xmin, ymax, xmax] の順で0〜1000に正規化され、元の画像の大きさに戻して使うこと。物を見つけるだけでなく輪郭のマスクを返すこと。その場合に思考の水準を最小にすると結果が良くなるとされていること。大きな画像が768×768の区画に分けられ区画ごとにトークンが数えられること | Gemini API: Image understanding | 2026-10-26 |
Files API にプロジェクトあたり20GB、1ファイル2GBまで保存できること。保存が48時間で自動で消えること。上げたファイルをダウンロードできないこと。無料で使えること。interactions.create の入力から参照すること | Gemini API: Files API | 2026-10-26 |
構造化出力が /v1beta/interactions に response_format で mime_type を application/json にし、schema にスキーマを入れて送る形であること。enum が使えること。値はアプリ側で検証するよう書かれていること | Gemini API: Structured output | 2026-10-26 |
Interactions API が既定でやり取りを保存し、有料の枠で55日保持すること。store=false で保存しないようにできること | Gemini API: Interactions | 2026-10-26 |
| 有料のサービスではプロンプトと応答が製品の改善に使われないこと。18歳以上であることが利用の条件であること | Gemini API Additional Terms of Service | 2026-10-26 |
鋳物の外観の合否の基準と、検査の記録の残し方は、取引先との品質の取り決めと、自社の検査の基準書に沿って決めてください。 本記事は公開の資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1792)についてのご相談はこちらから。
