製造業の出荷前検査をローカルVLM(Qwen3-VL-8B)にやらせてみた｜抜き取り検査とレイテンシの現実
はじめに
前回、金融業で「社内マニュアルの問い合わせAIをローカルLLMで作った話」を書きました。今回はその画像版です。製造業のお客様から「出荷前の外観検査を少しでも楽にしたい。ただし製品の写真は社外に出せない」と相談を受けて、ローカルで動くVLM（画像も読めるLLM）に検査をやらせてみた、という記録です。
結論から言うと、立ち上がりはめちゃくちゃ速いのに、レイテンシで現実に殴られる、という体験でした。そのあたりの生々しいところを残しておきます。
外観検査の自動化自体は昔からある分野ですが、VLMが出てきて作り方がガラッと変わったな、と感じています。何が一番違うかというと、検査基準を「言葉」で指示できること。従来だと不良品の画像を何千枚も集めて専用モデルを学習させる必要があったのが、VLMなら「バリと欠けと印字かすれがないか見て」と日本語で頼めてしまう。最初にこれが動いたときは、正直ちょっと感動しました。
なぜVLMなのか（従来の検査AIとの違い）
これまでの外観検査の作り方と並べると、VLMの立ち位置が分かりやすいです。
- ルールベースの画像処理：しきい値や輪郭抽出を人が作り込む。速いけど、基準が変わるたびに作り直し
- 専用の画像分類/検出AI：良品・不良品を大量に集めて学習させる。精度は出るけど、データ集めと再学習がとにかく重い
- VLM（Qwen3-VL）：検査基準を自然文で書くだけ。立ち上げが速く、基準変更も柔軟。ただし微細な欠陥はゼロショットだと見逃す
今回の現場は多品種少量で、「この型番は今日からここもチェック」みたいな変更がしょっちゅう入る。専用モデルを都度学習し直すのは現実的じゃない。だから 「基準をプロンプトで書き換えられる」柔軟性 が刺さりました。
ただ後で嫌というほど分かるんですが、この柔軟さと引き換えに「言葉が曖昧だと判定もブレる」という別の難しさが出てきます。
モデルは Qwen3-VL-8B に絞った
画像モデルは Qwen3-VL-8B 一本で進めました。ここでもモデル比較で時間を使わず、早めに決め打ちしています。
理由は、
- 8Bなら工場に置けるGPUに載る。検査サーバを現場に据える前提とサイズ感が合う
- 物体の位置（バウンディングボックス）やJSON出力に強い。「どこに」「何が」あるかを座標で返せるので、検査結果を機械的に扱いやすい
- 製品画像は当然機密なので、社外に出さずローカルで完結できる
- そして例によってコスパ。検査補助として十分な精度が、現実的なGPUで出せる
「一番大きいVLMを使えば精度が上がる」のは分かってるんですが、工場のサーバに載って、後段の処理に流しやすい形で結果を返せる、という現実解として8Bを選びました。
全体の流れ
ラインへの組み込みはこんな感じにしました。
金融のときと同じで、画像はインターネットに出しません。製品の外観写真は立派な機密なので、クラウドの画像APIに投げる選択肢はそもそも無し。カメラで撮った画像を工場内の検査サーバに送って、Qwen3-VL に良否＋根拠＋欠陥の位置をJSONで返させて、NGなら排出するか人が見る、という流れです。
ひとつ補足すると、ここで出させている欠陥の座標は、あくまで「人が確認するときの目印」として使う前提です。ゼロショットのVLMが返すバウンディングボックスは数pxズレることがあり、そのまま物理的に排出する制御に直結させるのは危険でした。座標精度を当てにする自動排出が要るなら、別途位置決め用の画像処理（輪郭抽出など）を噛ませるか、座標はログ・表示用途に割り切るのが現実的です。
検査基準は「プロンプト」で書く。ただし曖昧だと即ブレる
VLMの肝は、検査基準をどう言語化するか。ここが甘いと判定がグラグラします。最終的にはこういう形で、基準を具体的に書いて、JSONだけで返させるようにしました。
あなたは製品の外観検査員です。次の観点で画像を確認してください。
- 表面に傷・打痕がないか
- 角に欠け・バリがないか
- 印字がかすれ・欠落していないか
以下のJSON形式のみで回答してください。推測で欠陥を作らないこと。
{
"judgement": "OK" または "NG",
"defects": [
{ "type": "傷|欠け|印字不良", "location": [x1,y1,x2,y2], "confidence": 0.0-1.0 }
],
"reason": "判定の根拠を簡潔に"
}
reason をわざわざ出させているのは、なぜNGにしたのかを後から人が確認できるようにするためです。検査工程って「なぜ落としたか」を説明できないと後で揉めるので、ここは削れませんでした。
ちなみに最初は指示がふわっとしていて、「きれいに検査して」みたいな雑なプロンプトから始めたんですが、これだと同じ画像でもOKになったりNGになったりする。観点を箇条書きで具体的に列挙して、ようやく判定が安定してきました。プロンプトの書き方一つでこんなに変わるのか、と地味に驚いたポイントです。
VLMで全部やろうとして、レイテンシに殴られる
一番の学びがこれでした。VLMで全数検査をやろうとすると、速度がまったく足りない。
そもそも何が遅いのか
VLMの推論時間は、ざっくりこの3つで決まります。
入力画像の解像度が高いほど重くなるし、JSONを長々書かせても遅くなる。そして何より、GPUがあるかどうかで世界が変わります。
実測して青ざめた
検証用に手元の RTX 4090(24GB) で測ってみました。この環境で、元画像（4000×3000くらい）をそのまま食わせたら、1枚に数秒かかって「これはラインに乗らないぞ」と青ざめました。
- 画像を 1280×960 くらいにリサイズしたら、1枚あたり 体感で1.5〜2秒 に短縮
- 試しにGPUなし（CPUのみ）で回したら1枚に十数秒。検証用ならともかく、ラインでは論外
ここで現実を突きつけられます。ラインのタクトタイム（1個あたりの持ち時間）に、この検査時間が収まるのか？ という問いです。
- 高速ラインで全数検査 → 1個1.5秒とかだとまず間に合わない
- なので、全数をVLMで見るのは諦めて、抜き取り検査に割り切った
「クラウドの速いAPIを使えば？」とも一瞬考えましたが、クラウドはネットワークの往復も乗るし、そもそも画像を外に出せない。ローカルでGPUに載せる以外に道がなかった、というのが実情です。
結局こう使うと現実的だった：抜き取り＋一次スクリーニング
全数をVLMで、という当初の理想は早々に捨てて、こういう位置づけに落ち着きました。
- 抜き取り検査：ロットから決めた数を抜いてVLMで確認。統計的な品質管理の考え方と相性がいい
- 出荷前の一次スクリーニング：人の目視の前に、VLMが怪しいものだけふるいにかけて、疑わしいものだけ人に回す
要は、VLMを人の代わりじゃなくて「一次ふるい」として使う。これで検査員が全部見なくてよくなって、負担がかなり減りました。VLMで全部やろうとせず、人の手数を減らす方向に使うのがコツだと痛感しました。
メリット・デメリット、正直に
一通りやってみて感じた良し悪しをまとめると、
良かったところ
- 立ち上げが本当に速い。検査基準を言葉で書けるので、専用モデルの学習データ集めが要らない
- 型番追加や基準変更が、プロンプト修正だけで済む。現場の「今日から変更」に追従できる
- 画像を社外に出さずローカルで完結できる。機密の面で安心
- 判定根拠(reason)と欠陥の座標が出るので、検査ログとして残しやすい
しんどかったところ
- ゼロショットだと微細な欠陥を見逃す。髪の毛一本レベルの傷は普通にスルーされた
- プロンプト次第で判定がブレる。基準の言語化スキルが要る
- レイテンシ。高速ラインの全数検査には単体では無理
- GPUサーバの初期投資は当然かかる
ざっくり言うと「立ち上げやすくて柔軟だけど、微細欠陥と高速ラインは苦手」。この性格を分かった上で、抜き取り・一次ふるいに寄せると費用対効果が出る、という感触でした。
どんな機材を買うべきか
金融編と同じことを書きますが、製造業はレイテンシ要件がある分、GPUがより明確に必須です。
ノート/個人PC/Macに「置く」のはやめておく
- ノートPCで運用しない。検証には使えても、24時間ラインの横で回し続ける本番機には向かない
- 社員のPCに同居させない。検査が止まる・遅れるのは現場では致命的
- Mac は選びませんでした。VLMはNVIDIA GPU前提で最適化された実行環境の方が扱いやすいし、企業の集中管理・GPU増設を考えてもNVIDIAサーバが素直
製造現場では、工場内ネットワークにGPU検査サーバを1台据えて、カメラからそこへ画像を送る——この形が結局いちばん安定しました。
NVIDIA GPUサーバ。やっぱりVRAMを見る
本番は NVIDIA L40S(48GB) を1枚積んだサーバを検査ラインの近くに置きました。Qwen3-VL-8B を量子化して載せる分には十分余裕があり、解像度を上げたい・同時に複数ラインを見たい、となったときもVRAMにまだ余白があります。
選定のコツは金融編と一緒で、クロックよりVRAM。動かすモデル＋画像処理がVRAMに収まるのが最優先です。加えて製造現場では、粉塵・温度・電源への配慮（防塵・空調・無停電電源）も要りました。オフィスと違って環境が過酷なので、ここは現場と相談しながら詰めました。
本番はコンシューマGPUではなく、データセンター向けを選ぶ
検証フェーズでは手元の RTX 4090 で始めました。Qwen3-VL-8B を量子化して載せる分には十分で、レイテンシの実測やプロンプト調整はこれで済ませられました。
ただ、本番を24時間止まらず回す前提になると、コンシューマ向けのGeForce（RTX 4090）は避けるのが正解です。
- ECCメモリがない。稀に起きるメモリエラーを検出できず、「たまに判定がおかしい」の原因になり得る
- 連続高負荷・長期稼働を前提に作られていない。冷却・電源まわりもゲーミング用途寄り
- 保証・ライセンスの面でも、サーバ運用でのGeForce利用は本来想定外
そこで本番は NVIDIA L40S(48GB) に載せ替えました。ECC付き・連続稼働前提でサーバ運用の実績があり、現場の「止めたら困る」に耐えてくれます。Qwen3-VL-8B の量子化は余裕で載り、解像度を上げたい・複数ラインを見たいという拡張にもVRAMの余白が効いてきます。
補足すると、L40Sは4090より「速い」わけではありません。むしろメモリ帯域は4090（約1000GB/s）よりL40S（約864GB/s）の方がやや低く、8Bモデルの推論は帯域律速なので、載せ替えてもレイテンシは同等かわずかに遅いくらいです。L40Sの価値はあくまでECC・48GBのVRAM余白・連続稼働とサーバ保証のほうにあります。「速くするため」ではなく「止めないため」の選定、というのが正確です。
予算の組み方としては「検証は4090で安く始める → 本番は L4 / RTX A5000 / L40S などのデータセンター向けに載せ替える」の2段構えが、初期投資を抑えつつ本番の安定性を取れる落とし所でした。
精度が足りないとき：LoRAと、人との併用
ゼロショットのQwen3-VL-8Bで微細欠陥を取りこぼす問題、これは打ち手が主に2つでした。
LoRAで、自社の不良品を覚えさせる
LoRAは、モデル全体を再学習せずに、少ない追加パラメータで「自社の不良品の見え方」を覚えさせる手法です。フルの再学習に比べて、要るデータもGPUメモリも段違いに少なくて済む。
今回は、社内で撮りためた不良品・良品の画像を200枚ほど用意してLoRAを当てました。すると、この製品特有の「この向きで光が当たったときのこの傷」みたいな、ゼロショットでは拾えなかった欠陥への感度が上がりました。ちなみに、鉄鋼の表面欠陥をLoRAで学習させて認識精度が上がった、という研究報告もあって、方向性としては間違ってなさそうだ、と背中を押されました。
いきなりフルスクラッチで学習させるより、ゼロショットで8割方カバーして、取りこぼしをLoRAで詰める、という段階的なやり方が、コスト的にも現実的でした。
そして、人と併用する前提にする
一番大事なのはこれで、VLMを人の代替じゃなく補助として設計すること。
- VLMが自信を持って「OK」と言えるものは通す
- 「NG」か「自信が低い」ものだけ人が確認する
- これで人の確認対象をぐっと減らしつつ、見逃しの最後の砦は人が担う
「AIが手を引く境界を決める」という考え方は、金融編でも、その前の音声AIの記事でも、結局同じことを言っている気がします。業務でAIを使うなら、引き際の設計が品質を守る。これは何度やっても変わらない実感でした。
品質保証部門を通すには：妥当性確認（GR&R / MSA）が避けられない
ここまで「補助ツールとして人と併用する」と割り切った話をしてきましたが、それでも検査工程として正式に運用するなら、品質保証部門の壁が立ちはだかります。VLMの判定は確率的で、プロンプトやパラメータでブレる。だから「同じ製品なら毎回同じ判定になる」ことを、数字で示す必要があるんです。
このときに使うのが MSA（測定システム解析） と、その代表的な手法である GR&R（Gauge R&R） です。合否（OK/NG）のような属性データを扱う今回のケースでは、計数値GR&R（属性一致分析） が中心になります。
具体的には、こんな手順で検証を進めました。
-
正解付きの評価用データセットを作る
良品・不良品を、熟練の検査員（できれば複数人）にラベル付けしてもらう。ここで重要なのが、OK/NGの境界ギリギリの「グレーゾーン」画像を必ず混ぜること。判定がブレるのは決まってここなので、ここを外すと評価になりません。 -
繰り返し性（Repeatability）を確認する
同じ画像を、同じプロンプト・同じtemperatureで複数回判定させる。判定（OK/NG）とconfidenceが毎回安定しているかを確認する。 -
再現性（Reproducibility）を確認する
撮影条件を変える——照明の角度、カメラの個体差、撮影タイミング——同じ製品の画像で判定が揺れないかを見る。現場で一番ブレたのは実はここでした。 -
属性一致分析（検査員 vs VLM）で一致率とκ係数を出す
VLMの判定と、検査員の正解判定を突き合わせて、一致率とCohen's κ係数を計算する。ここで特に見るべきは2つです。- 偽陰性率（不良を「OK」と見逃す率）：これが高いと検査の意味がないので、製造では最優先で下げる
- 偽陽性率（良品を「NG」と誤る率）：高すぎると人の再確認が増えて、結局負担が減らない
-
モデル・プロンプト・パラメータを固定し、変更は再評価を伴う運用にする
モデルのバージョン、量子化、プロンプト、入力解像度、temperatureをすべて固定する。どれか一つでも変えたら、上記の検証をやり直す。この運用ルールがないと「いつの間にか判定が変わっていた」が起きます。
率直に言うと、この妥当性確認こそが、PoCと本番の間に立ちはだかる一番の関門でした。VLMの「プロンプトで基準を柔軟に変えられる」という長所と、検査工程が求める「再現性・固定」は本質的に相性が悪い。だからこそ、補助ツールに留めるか、正式な検査装置として通すなら上記の検証と運用ルールをセットで整えるか——この線引きを最初に決めるのが大事だ、というのが実感です。
まとめ
製造業の出荷前検査を、ローカルVLM(Qwen3-VL-8B)にやらせてみた話でした。
- VLMの強みは検査基準を言葉で書ける柔軟さ。立ち上げが本当に速い
- モデルは Qwen3-VL-8B に一本化。座標・JSON出力に強く、工場のGPUサーバに載る
- 画像を社外に出せないので、クラウドじゃなくローカル一択
- レイテンシで殴られる。全数は諦めて、抜き取り・一次ふるいに割り切ると回る
- 機材はノート/MacじゃなくNVIDIA GPUサーバを現場に。まずVRAM、あと粉塵・電源
- 本番のGPUはコンシューマ（4090）でなく ワークステーション/データセンター向け（L4/A5000/L40S） を
- 精度はLoRA＋人との併用で担保する
- 正式な検査工程にするなら 妥当性確認（GR&R / MSA） で再現性を数字で示す
VLMは万能じゃないですが、「基準がよく変わる」「画像を外に出せない」「人の目視を減らしたい」現場には、費用対効果の高い相棒になってくれました。前回の金融編とあわせて、ローカルLLM/VLMを実際の業務に突っ込むときの参考になれば。
💡 ローカルLLM開発について、ご関心やご相談がございましたら、以下よりお気軽にお問い合わせください。
Discussion