AI外観検査の精度を左右するのは、実はモデルよりも欠陥サンプルの蓄積と運用です。希少不良の収集、分類体系、版管理、再学習への供給、現場との連携まで、欠陥ライブラリを組織の資産として育てる設計の考え方を、ラベル作業とは切り分けて実務目線で整理します。
AI外観検査の導入相談をいただくと、最初の関心はほぼ例外なく「どのモデルを使うか」「精度は何%出るか」に集まります。もちろんアルゴリズムの選定は重要です。ただ、実際に現場で1年、2年と運用してみると、検査の品質を左右している本当の要因は、モデルそのものよりも「手元にどれだけ質の高い欠陥サンプルが蓄積されているか」であるケースが多いと考えています。良品はラインを流せばいくらでも集まりますが、不良品、とりわけ致命的で稀にしか出ない欠陥は、意図して集めにいかなければ永遠に手元に増えません。
この記事では、個々の画像にバウンディングボックスやマスクを付けるアノテーション（ラベル付け）作業そのものではなく、その手前と後ろにある「欠陥サンプルをどう集め、どう整理し、どう再学習へ供給し、どう現場と連携させるか」という運用設計に焦点を当てます。ラベル作業が"1枚の画像を学習可能な形にする"工程だとすれば、本記事のテーマは"組織として欠陥データを資産に育てる"工程です。役割が異なるため、分けて考える価値が大きいと考えます。
PoC（実証）の段階で「精度が頭打ちになった」「特定の不良だけ見逃す」という相談は珍しくありません。その原因を分解していくと、良品データは数千枚あるのに、問題の欠陥種は学習データに数枚しか入っていなかった、という構図に行き着くことが多いと感じています。モデルは見たことのないパターンを安定して当てることが難しいため、サンプルが極端に少ない欠陥は、どれだけ高性能なモデルを使っても取りこぼしやすくなります。
つまり「精度が出ない」という症状の多くは、アルゴリズムの問題ではなく、欠陥サンプルの収集・蓄積の問題である可能性が高いと考えられます。だからこそ、欠陥ライブラリを最初から運用資産として設計しておくことの価値が大きいわけです。
もう一つ見落とされがちなのが、欠陥データの散逸です。現場で不良が出たとき、その現品（実物）は不良品棚に置かれ、しばらくすると廃棄されるか客先返品されます。画像はオペレータのPCや検査機のローカルに溜まり、担当者の異動とともに所在が分からなくなります。発生時の照明条件やロット情報はメモにすら残らないこともあります。結果として、半年後に「あの不良の画像、もう一度学習に使いたい」と思っても、もう手元にない、という事態が起こります。
欠陥ライブラリの第一の目的は、この散逸を防ぎ、「出た不良を、出た瞬間に、再利用可能な形で確保する」ことにあると考えます。これは技術というより仕組みと運用の話であり、だからこそ早い段階で設計しておく意味があります。NsightではAI外観検査の導入支援において、モデル選定と同じ比重で、この蓄積の仕組みづくりを一緒に検討することを推奨しています。
本記事が扱うのは、欠陥サンプルの「収集・分類・版管理・再学習供給・現場連携」という運用設計です。一方で、個々のラベリングの作業手順やツール選定、教師データの品質基準の細部は別テーマとして外観検査自動化の基本などに譲ります。両者は連続していますが、混ぜて語ると「結局どこから手を付ければいいのか」が見えなくなりがちなので、本記事ではあえて資産運用の視点に絞って整理します。
欠陥ライブラリの成否を最も大きく分けるのが、希少不良（rare defect）の収集です。発生頻度が低く、かつ流出したときの被害が大きい欠陥ほど、学習データに入っていないという皮肉な状況が生まれやすいためです。ここでは、めったに出ない不良を意図的に拾い上げるための考え方を整理します。
希少不良は計画的に発生させられないため、待ち構えるしかありません。鍵になるのは、不良が検出された、あるいは人が不良と判断した瞬間に、自動的に関連データを退避させるトリガーを仕込んでおくことだと考えます。具体的には、検査機が「不良」または「判定保留（確信度が低い）」と出したフレームを、良品とは別の保管領域へ自動で複製・保全する設計です。
このとき確保すべきは画像だけではありません。撮像時刻、ライン名・号機、品種・ロット、照明や露光の設定、検査機が出した確信度（スコア）、そして可能であれば現品の物理的な確保指示までを一連のセットとして残せると、後の再学習や原因究明で大きな差が出ます。画像単体よりも、コンテキスト込みのサンプルのほうが資産価値がはるかに高いと考えます。
明確に不良と判定されたものだけでなく、モデルが判断に迷った境界付近のサンプルは、学習効率の観点で特に価値が高いと考えられます。確信度が0.45〜0.55のような曖昧な帯のフレームを意図的にサンプリングして退避する仕組みを入れておくと、モデルの弱点が集まりやすくなります。これは能動学習（アクティブラーニング）的な発想で、限られた人手のラベリング工数を「効く」サンプルに集中させる助けになります。確信度の見せ方や運用はエッジとクラウドの構成とも関わるため、収集ポイントをどこに置くかは構成と合わせて検討する価値があります。
画像はあくまで特定の照明・角度での記録に過ぎません。後から別の撮像条件で撮り直したい、3D的な変形を確認したい、といった要求が出たときに効いてくるのが現品の保全です。希少不良に該当する現品は、廃棄・返品の前に「ライブラリ用に確保するか」を判断する運用ルールを設けておくことを推奨します。すべてを残すのは現実的でないため、欠陥種ごとに「現品保全の優先度」を決めておくと、現場の負担と資産価値のバランスを取りやすいと考えます。
どうしても実物が集まらない欠陥について、データ拡張（augmentation）や画像合成で補う手法もあります。回転・明度変化といった基本的な拡張は有効な場面が多い一方、合成データは「本物らしさ」の検証が伴わないと、現場で通用しない学習につながる恐れもあります。合成はあくまで実データを補う補助手段と位置づけ、最終的な妥当性は現物での検証で確かめるという前提を崩さないことが大切だと考えます。実データと合成データはライブラリ上で明確に区別して管理し、どちらで学習したかを後から追えるようにしておくことを推奨します。
サンプルをいくら集めても、必要なときに目的のものを取り出せなければ資産とは呼べません。「特定品種の、特定欠陥種の、特定照明条件のサンプルだけを集めて再学習したい」という要求に応えられるかどうかが、ライブラリの実用性を決めると考えます。ここでは分類とメタデータの設計を扱います。
分類体系を設計するとき、いきなりモデル都合のクラス分けから入ると、現場が使えないものになりがちです。まずは現場が普段使っている不良の呼び名（キズ、打痕、異物混入、塗工ムラ、バリ、欠け、印字かすれ等）を棚卸しし、それを土台に整理することを推奨します。現場の語彙に根ざした分類は、収集時のタグ付けが直感的になり、結果として精度の高いメタデータが集まりやすいと考えます。
その上で、欠陥種は階層構造で持つと扱いやすくなります。たとえば「表面欠陥 > キズ > 線状キズ／点状キズ」のように大分類・中分類・小分類を設けておくと、粗い粒度でも細かい粒度でも検索・集計ができます。再学習のときにどの粒度でクラスを切るかは案件ごとに変わるため、データ側は細かく持っておき、学習時に必要な粒度へ畳み込む設計が柔軟だと考えます。
サンプル1件ごとに、少なくとも次の情報を紐づけておくことを推奨します。これらは検索性と再現性の両方を支える基盤になります。
分類基準は運用しながら必ず変わります。当初「キズ」としていたものを後から「打痕」と「線状キズ」に分けたくなる、といった見直しは普通に起こります。このとき、過去のサンプルを破壊的に上書きしてしまうと履歴が失われます。ラベルは差し替え可能でありつつ、いつ・誰が・なぜ変更したかを残せる構造にしておくと、基準の変遷に強いライブラリになると考えます。判定基準の整合は目視検査の限界と判断のばらつきとも通じるテーマで、人によるラベルのゆれをどう吸収するかは設計段階で意識する価値があります。
欠陥ライブラリというと不良ばかりに目が行きますが、良品の正常バリエーション（色味の個体差、許容内の傷、照明変動など）を意図的に集めておくことも同じくらい重要だと考えます。良品の幅を学習に十分含められないと、許容内のばらつきを不良と誤検出する過検出が増え、現場の信頼を損ないます。良品も「正常の代表例」として分類・管理対象に含める設計を推奨します。
ライブラリが育ってくると、「いつのデータで学習したモデルか」「このサンプルを足したら精度はどう変わったか」を追えることが不可欠になります。これはソフトウェア開発でいうバージョン管理に近い発想で、データセットとモデルの対応関係を再現可能にしておくことが、運用の信頼性を支えると考えます。
再学習のたびに最新の全データを使うのは自然に思えますが、それだと「前回より精度が落ちた」ときに原因を切り分けられません。学習に使ったサンプルの集合を、その時点のスナップショットとして固定し、版番号を付けて記録しておくことを推奨します。こうしておくと、データセットv3とv4の差分（どのサンプルが追加・削除・再ラベルされたか）を後から確認でき、精度変化の要因をデータに遡って追跡できます。
モデルを学習・デプロイするときは、「どのデータセット版から」「どの設定で」学習したかを、モデル側のメタ情報として必ず残すことを推奨します。現場で稼働中のモデルがどの版に由来するかが分かれば、不具合が出たときに該当データへ即座に戻れますし、再現実験も可能になります。データ版・モデル版・現場稼働状況が一本の線でつながっていることが、運用資産としての完成度を高めると考えます。
再学習を繰り返すうちに起こりがちな失敗が、評価用データの学習側への混入です。これが起きると「評価上は高精度なのに現場では当たらない」という、最もたちの悪い状況を招きます。サンプル単位で「これは評価用」という固定ラベルを持たせ、再学習のたびに分割を作り直さない運用を推奨します。同一現品から撮った複数枚が学習側と評価側に分かれて入る、といった微妙な漏れも、現品IDで束ねて管理することで防ぎやすくなります。PoCがうまくいかない要因の一つに、この評価設計の甘さがあると考えています。
新しいサンプルを足して再学習したモデルを、いきなり本番へ全面入れ替えするのはリスクが高いと考えます。固定した評価セットで旧版と新版を比較し、狙った欠陥種の見逃しが減ったか、別の欠陥種で過検出が増えていないかを確認したうえで切り替える、という段取りを踏むことを推奨します。とくに「ある欠陥を直したら別の欠陥が悪化した」という副作用は珍しくないため、全体のバランスを評価セット上で見ることが重要です。こうした比較・判断のプロセスは、目視検査をAIへ置き換える取り組みを継続的に育てるうえでの中核になると考えます。
欠陥ライブラリは、一度作って終わりの静的なデータベースではなく、現場の判定結果から不良候補が継続的に流れ込み、再学習へ供給され、改善されたモデルが現場へ戻る——という循環として機能してはじめて価値を持つと考えます。ここでは、その循環を支える現場連携の設計を扱います。
収集の仕組みをどれだけ立派に設計しても、現場オペレータの負担が大きければ続きません。理想は、不良判定や判定保留が出たら自動でライブラリへ退避され、オペレータは普段の作業の延長で必要最小限の確認だけすればよい状態だと考えます。たとえば「AIが見逃した／過検出した」とオペレータが感じたときに、ボタン一つでその場面をライブラリへフィードバックできるような、摩擦の少ない導線を用意することが、データの量と質の両方を支えます。
現場からのフィードバックの中でも、AIの判定と人の判断が食い違ったケース（見逃し・過検出）は、ライブラリにとって最も価値の高い入力だと考えます。これらは「モデルがまだ学べていないこと」を直接示しているからです。誤判定として登録されたサンプルは優先的にラベル確認へ回し、次回の再学習で重点的に取り込む、という優先度設計を入れておくと、改善のサイクルが速くなります。
何を不良とするかの最終判断には、現場や品質保証部門の知見が不可欠です。微妙なサンプルを誰が・どの基準で良品／不良と確定するのか、その責任と手順を曖昧にしないことが、ライブラリの一貫性を保つうえで重要だと考えます。判定が割れるサンプルは「保留」として隔離し、定期的なレビュー会で基準ごと議論する運用にすると、暗黙知だった判断基準が少しずつ明文化され、これは技能伝承の観点でも資産になります。関連して目視検査の技能伝承の論点も参照いただけます。
「いつ再学習を回すのか」「誰がライブラリの番人なのか」を決めておかないと、循環は自然に止まります。月次・四半期といった棚卸しのリズムを決め、収集状況・ラベル進捗・誤判定傾向をレビューする場を設けることを推奨します。あわせて、ライブラリのオーナー（管理責任者）を明確にし、収集ルールやアクセス権限、命名規約を維持する役割を持たせると、属人化と散逸を防ぎやすくなります。製造業DXの進め方の観点でも、こうした運用主体の明確化は定着の鍵になると考えます。
欠陥ライブラリの設計・運用には、経験的に繰り返し見られるつまずきがあります。ここでは代表的なものを挙げます。いずれも事前に意識しておくだけで回避しやすくなると考えます。
これらの落とし穴の多くは、技術的に難しいというより、運用ルールと役割分担の設計で防げるものです。だからこそ、ライブラリの構造を作る初期段階で、収集・分類・版管理・現場連携の流れを一通り通して検討しておく価値が大きいと考えます。
最後に、欠陥ライブラリをどう立ち上げ、育てていくかの現実的な進め方を整理します。最初から完璧な体系を目指すのではなく、小さく始めて運用しながら太らせていくアプローチが現実的だと考えます。
まずやるべきは、立派な分類体系の構築よりも「出た不良を捨てない」収集の確立です。検査機の不良・判定保留フレームを別領域へ自動退避させ、最低限のメタデータ（日時・号機・品種）を一緒に残すところから始めます。分類が粗くても、データさえ確保できていれば後から整理できますが、捨ててしまったデータは二度と戻りません。収集を最優先にするのは、この非対称性ゆえです。
ある程度サンプルが溜まったら、現場の語彙に基づく欠陥分類を整え、検索可能なメタデータを付与し、データセットの版管理を導入します。この段階で、評価セットの固定とデータ版・モデル版の紐づけを入れておくと、以降の再学習が安定します。最初の再学習を回し、固定評価セットで効果を確認するサイクルをここで確立します。
収集・分類・版管理が整ったら、現場の誤判定フィードバックを取り込む導線をつなぎ、定期的な棚卸しと再学習のリズムを定着させます。ライブラリのオーナーを定め、運用ルールを維持する体制まで含めて初めて、欠陥データは「育ち続ける資産」になると考えます。ここまで来ると、検査AIの精度は単発のモデル選定ではなく、組織的な運用の質で決まるようになります。
本記事で述べた設計はあくまで一般的な考え方であり、最適な収集ポイント、分類粒度、再学習の頻度は、製品・工程・欠陥の性質によって大きく変わります。たとえば金属部品と樹脂成形品では、致命欠陥の種類も希少不良の出方も異なり、ライブラリ設計の重心も変わってきます。PoC・導入のご相談では、こうした個別性を前提に、現物・現場での検証を通じて何が効くのかを一緒に確かめていく進め方を大切にしています。
Nsightには、元キーエンス画像処理事業部出身の監修者が在籍しており、照明・撮像条件の作り込みから、何を不良と定義し、どう蓄積し、どう再学習へつなぐかという運用設計まで、現場目線での知見を蓄積してきました。欠陥ライブラリは一朝一夕に完成するものではありませんが、設計の勘所を押さえて小さく始めれば、着実に精度改善の土台として育っていくものだと考えます。まずは現状の収集・蓄積の実態を棚卸しするところから、ご一緒できればと考えます。
アノテーションは個々の画像を学習可能な形にするラベル作業そのものを指します。一方、欠陥ライブラリの管理は、その手前の「不良サンプルをどう取りこぼさず集めるか」と、後ろの「どう分類・版管理し、再学習へ供給し、現場と連携させるか」という運用設計を指します。ラベル作業が点だとすれば、ライブラリ管理は欠陥データを組織の資産として育てる線・面の取り組みだとお考えいただくと整理しやすいと考えます。
希少不良は計画的に発生させられないため、出た瞬間に取りこぼさず確保する仕組みが要になります。検査機が不良・判定保留としたフレームを自動退避し、画像だけでなく撮像条件・品種・ロット・確信度をセットで残すこと、そして該当する現品（実物）を廃棄前に保全することを推奨します。どうしても集まらない場合はデータ拡張や合成で補う手もありますが、これらは補助であり、最終的な妥当性は現物での検証で確かめる前提が大切だと考えます。
あると運用の信頼性が大きく変わると考えます。学習に使ったサンプル集合を版（スナップショット）として固定し、データ版とモデル版を紐づけておくと、精度が変化したときに原因をデータへ遡って追跡でき、不具合時には該当データへ戻れます。とくに評価用データを固定して学習側への混入を防ぐことは、評価上は高精度なのに現場で外すという失敗を避けるうえで重要だと考えます。
作って終わりではなく、現場の判定結果から不良候補が継続的に流れ込み、再学習へ供給され、改善されたモデルが現場へ戻る循環として回してはじめて価値を持つと考えます。そのため、収集導線・誤判定フィードバック・定期的な棚卸し・管理オーナーの設定といった運用の枠組みが必要です。逆に言えば、この循環が回る仕組みさえ整えば、検査AIの精度は運用とともに育っていくものだと考えます。
最適な収集ポイントや分類粒度、再学習の頻度は製品・工程・欠陥の性質によって変わるため、一般論だけで決めることは難しいと考えます。まずは現状の不良データの蓄積・散逸の実態を棚卸しし、現物・現場での検証を通じて何が効くのかを一緒に確かめる進め方を推奨しています。元キーエンス画像処理事業部出身の監修者の知見も踏まえ、PoC・導入のご相談から段階的にご一緒できればと考えます。
希少不良の取りこぼし、画像の散逸、再学習の停滞——欠陥ライブラリの課題は現場ごとに異なります。元キーエンス出身の監修者とともに、現物・現場での検証を前提に、御社の蓄積の仕組みを一緒に設計します。
AI外観検査の導入を相談する