検査AI導入の成否は要件定義でほぼ決まると考えられます。対象・欠陥定義・許容基準・タクト・撮像環境・出力連携の6軸をどう詰め、現場と何を握るか。要件漏れの典型と防止策を、元キーエンス出身の知見を交えて整理します。
検査の自動化やAI化のプロジェクトでつまずく場面を整理していくと、その多くは画像認識アルゴリズムそのものの限界ではなく、「何を検査したいのか」「どこからを不良とするのか」という要件が曖昧なまま動き出したことに起因していると考えられます。要件が固まっていないと、データを集めても何を正解ラベルとすべきか定まらず、評価しても合否の基準が人によってぶれてしまいます。
現場でよく見られるのが、まず画像を撮影してAIに学習させ、結果を見ながら基準を後付けで決めていく進め方です。一見スピーディですが、欠陥の定義や許容範囲が後から動くと、それまで付けたラベルややり直しが必要になり、かえって時間とコストがかかる可能性が高いと考えられます。検査要件は「先に言葉と現物で握ってから、データと検証で詰める」順序が望ましいと考えます。
要件定義は、データ収集・アノテーション・モデル選定・照明や撮像系の設計・判定ロジック・上位システム連携といった下流の工程すべての前提になります。前提が揺れると、各工程で個別に解釈が入り込み、最終的に「現場の合否感覚と装置の判定がずれる」という最も避けたい状態に至りやすいと考えられます。逆に言えば、要件定義に時間を投じることは、後工程の手戻りを減らす最も費用対効果の高い投資の一つだと考えています。
本記事は、特定の業種や欠陥に限定せず、検査AI・自動検査の要件定義に共通する「詰めるべき項目」と「現場と握るべき論点」を横断的に整理することを狙いとしています。導入前のトライアル評価の設計そのものについてはPoCが失敗する理由もあわせてご覧ください。本番運用後の指標管理とは切り分けて、まず「導入の入口で何を定義するか」に焦点を当てます。
検査要件は無数の論点を含みますが、抜け漏れを防ぐために、まず大きく6つの軸に分けて整理することをおすすめします。どれか一つでも曖昧なまま進むと、後工程で必ずと言ってよいほど跳ね返ってくると考えられます。
この6軸は独立して決められるものではなく、互いに制約し合う関係にあります。例えばタクトを上げれば露光時間が短くなり、必要な照明強度や撮像系が変わります。許容基準を厳しくすれば、より高解像度の撮像や安定した照明が要求される可能性が高いと考えられます。したがって要件定義は、一度6軸を並べたうえで、相互の整合を取りながら何度か往復して詰めていく作業になると考えています。
各軸には主たる責任者が異なります。欠陥定義や許容基準は品質保証部門、タクトや搬送は生産技術部門、現場の運用は製造現場が最も実態を把握しています。要件定義の場には、この三者がそろっていることが望ましいと考えます。誰か一人の解釈だけで決めた要件は、後で別部門から覆される可能性が高いためです。次のセクションから、各軸で具体的に何を詰めるかを順に見ていきます。
最初に固めるべきは「何を見るか（対象）」と「何を不良とするか（欠陥定義）」です。ここが曖昧だと、以降のすべての軸が砂上の楼閣になりかねません。
同じ製品名でも、実際のラインには品種・型番・色・ロット差・経時変化など、想像以上のバリエーションが流れていることが少なくありません。要件定義では、検査対象とする品種の範囲、サイズや形状の公差、表面の状態（光沢・梨地・透明など）、そして「正常品の中に許される個体差」をできる限り具体的に書き出すことをおすすめします。特に自然物や成形品では正常品自体のばらつきが大きく、これを欠陥と取り違えないための線引きが重要だと考えられます。
欠陥定義は、品質保証の規格書だけでなく、現場の検査員が実際に何を見て弾いているかをヒアリングして洗い出すことが有効だと考えます。傷・打痕・異物・汚れ・欠け・色differ・ムラなど、欠陥の種類ごとに「どう見えるか」「なぜ発生するか」「どの工程で混入するか」を整理します。同じ「キズ」でも、線状か点状か、深さがあるか表面だけか、で見え方も撮像条件も変わるため、呼称を統一し粒度をそろえることが後のラベリング品質に直結すると考えています。
欠陥定義では、絶対に見逃してはならない致命欠陥（流出すると重大なクレームや安全問題になるもの）と、機能上は問題ないが過検出すると歩留まりを落とす外観差を分けて整理することをおすすめします。この優先順位が、後の許容基準や評価指標の重み付けの根拠になります。目視検査の限界と対策でも触れているように、人の検査員でも判断が割れる欠陥は、AIにとっても難所になりやすいと考えられます。
意外に見落とされがちなのが、「定義した欠陥の実物サンプルが手元にあるか」という点です。発生頻度の低い欠陥はサンプルが集まらず、学習も評価も難しくなります。要件定義の段階で、各欠陥について現物がどれだけ確保できそうかを棚卸ししておくと、後のデータ戦略の判断材料になると考えています。サンプルが乏しい欠陥は、良品基準からの逸脱として捉える設計や、発生時に追加収集する運用を検討する余地があります。
欠陥の種類を定義できたら、次は「どこからを不良とするか」という合否ラインを決めます。検査要件定義の中でも、最も合意形成が難しく、かつ最も重要な部分だと考えられます。
合否ラインを言葉だけで定義しようとすると、「軽微な傷はOK」のような曖昧な表現になりがちで、人によって解釈が割れます。可能な限り、合格・不合格の境界を示す限度見本（実物または画像）を用意し、それを基準とすることをおすすめします。限度見本があると、現場・品質保証・装置の三者が同じ物差しを共有でき、「この見本より目立てば不良」という合意がぶれにくくなると考えられます。
傷の長さ、欠けの面積、異物のサイズ、色差など、定量化できる項目はできる限り数値で合否ラインを定義することが望ましいと考えます。「○mm以上の傷はNG」のように数値化すると、評価の再現性が高まり、装置の判定パラメータにも落とし込みやすくなります。一方で、ムラや質感のように数値化が難しい欠陥は、限度見本との比較や等級判定で扱う設計が現実的だと考えています。寸法系の詰め方は寸法検査のガイドもご参照ください。
現実の検査では、明確な良品・不良の間に必ずグレーゾーンが存在します。要件定義では、このグレーゾーンを「不良側に倒す（安全側）」のか「良品側に倒す（歩留まり優先）」のか、あるいは「人による再判定に回す」のかを先に決めておくことをおすすめします。ここを曖昧にすると、過検出と見逃しのトレードオフの落としどころが現場でぶれ、装置への不信感につながる可能性が高いと考えられます。
同じサンプルを複数の検査員に判定してもらうと、判定が一致しないことは珍しくありません。要件定義の段階で、人間の検査基準自体にどれだけのばらつきがあるかを把握しておくと、AIに求める精度の現実的な目標設定に役立つと考えます。人が割れる判断をAIだけに完璧を求めるのは妥当でない場合が多く、ここの認識合わせが期待値調整の出発点になると考えています。
見るべき対象と基準が固まったら、「どの速度で・どんな条件で撮るか」という物理的な制約を詰めます。ここはアルゴリズム以前のハードウェア・設置の問題であり、後から変更しにくいため早期の確認が重要だと考えられます。
1個あたり何秒で処理する必要があるのか、ラインの搬送速度はどれくらいか、ピーク時の処理量はどの程度かを、現場の実数で押さえることをおすすめします。タクトは撮像のシャッター速度・必要照明・処理ハードの選定すべてに効いてくる前提条件です。「速ければ速いほどよい」ではなく、ラインの実態に合わせて必要十分なところを握ることが、過剰投資を避ける鍵になると考えています。
検査AIの性能は、画像の質に大きく左右されます。撮像環境では、照明の方式（同軸・ドーム・ローアングル・偏光など）、ワークの姿勢のばらつき、設置スペースの制約、そして外乱光や振動・粉塵といった環境要因を整理することが重要だと考えます。特に金属光沢面のハレーションや透明体の撮像は照明設計が成否を分けやすく、要件定義の段階で「撮れる絵が得られそうか」を現物で確かめておく価値が高いと考えられます。ハードウェア面の検討はハードウェア統合の観点も役立つはずです。
多くの現場では、新規ラインを一から作るのではなく、既存ラインへ後付けで検査装置を組み込みます。カメラや照明を設置できる空間、配線・電源、メンテナンス時のアクセス性といった物理制約を要件として書き出しておくと、後の設計で「物理的に置けない」という事態を避けやすくなると考えます。既存設備への後付けの考え方はエッジAIレトロフィットもご参照ください。
タクトや通信環境、データの機密性によって、推論をエッジ（現場の装置側）で行うかクラウドで行うかの判断が変わります。リアルタイム性が求められるライン検査では、エッジ処理が現実的な選択になる場面が多いと考えられます。判断の整理にはエッジとクラウドの比較が参考になるはずです。要件定義では、レイテンシ・通信・機密性の3点から置き場所の方針を握っておくことをおすすめします。
検査は「判定して終わり」ではありません。判定結果をどう使い、どう記録し、どう運用し続けるかまで含めて初めて要件が完結すると考えられます。ここを後回しにすると、装置はできたのに現場のオペレーションに組み込めない、という事態になりかねません。
不良判定をどう扱うかを具体的に定義します。ラインから自動で排出するのか、アラートを出して人が抜くのか、マーキングするのか。排出機構やPLCとの連携が必要であれば、そのインターフェース（信号のタイミング・形式）も要件に含めます。判定から物理アクションまでの遅延が許容範囲に収まるかは、タクトとあわせて確認すべき点だと考えています。制御連携はPLC・AI連携の観点が参考になります。
不良画像や判定ログをどこまで残すか、製品やロットと紐づけて追跡できるようにするかは、品質保証上の重要な要件です。後から「なぜこれを不良と判定したか」を振り返れるよう、画像と判定根拠を保存する設計を検討する価値があると考えます。データの保存先・保存期間・アクセス権限は、機密保持の観点ともあわせて握っておくことをおすすめします。製品画像の取り扱いについては機密保持・オンプレ設計の検討も必要になる場面があると考えられます。
要件定義で見落とされやすいのが、導入後の運用体制です。新しい品種が追加されたとき、欠陥の傾向が変わったとき、誰がパラメータを調整し、必要なら再学習を回すのか。この継続運用の負荷を誰がどう担うかを最初に握っておかないと、導入直後は機能しても時間とともに精度が形骸化する可能性があると考えられます。内製と外注の切り分けは体制設計の重要な論点で、現場のスキルと負荷を踏まえて決めることをおすすめします。
装置が判定不能になったとき、想定外のワークが流れてきたとき、照明が劣化したときに、ラインを止めるのか・人手検査に切り替えるのか・とりあえず良品扱いにするのか。こうした例外時の挙動を要件として定義しておくと、現場が安心して運用できると考えます。検査装置は「正常時に正しく動く」ことと同じくらい「異常時に安全側に倒れる」ことが重要だと考えています。
最後に、これまでの軸を踏まえて、実際の現場で起きやすい要件漏れの典型と、その防止策を整理します。多くは「軸の存在は知っていたが、解像度が足りなかった」ことに起因すると考えられます。
これらの漏れを防ぐには、6軸を網羅したチェックリストで一つずつ潰していく地道な作業と、何より現物・現場での検証が有効だと考えます。仕様書の文言だけでは欠陥定義や撮像条件の解像度は上がりません。実際のワークを撮り、限度見本と照らし合わせ、「この絵でこの欠陥が見えるか」を確かめることで、初めて要件が現実と接続すると考えています。
要件定義は一度で完成するものではなく、トライアルや撮像検証を通じて見えてきた事実で更新していく前提で進めることをおすすめします。最初の要件はあくまで仮説であり、現物で検証して初めて確からしさが上がります。目視検査をAIに置き換える進め方でも、この「仮説→検証→更新」のサイクルが重要だと考えられます。
ここまでの内容を踏まえ、検査要件定義をどのような順序で進め、本番運用につなげるかの大まかな道筋を整理します。あくまで一般的な目安であり、現場の状況に応じて往復しながら進めるものと考えてください。
要件定義は地味で、すぐ成果が見えにくい工程です。しかし、ここでの解像度が後工程の手戻りを大きく左右すると考えられます。急いでデータ収集や装置選定に進みたくなる場面でこそ、6軸を丁寧に握り直すことが、結果的に最短ルートになる可能性が高いと考えています。要件定義の進め方や評価設計に不安がある場合は、第三者の視点を入れるPoC・導入コンサルティングを活用する選択肢もあります。
本記事は、キーエンスの画像処理事業部で実際の現場の検査要件と向き合ってきた監修者の知見をもとに整理しています。検査要件は業種・ワーク・ラインによって千差万別であり、一般論だけで詰めきれるものではないと考えています。だからこそ、最終的な要件は仕様書の上だけでなく、現物・現場での撮像検証を通じて、私たちと一緒に確かめながら固めていくことをおすすめします。現物を見れば、机上では気づけなかった個体差や撮像の難しさ、現場の運用実態が必ず見えてくると考えています。
特定の一部門が単独で決めるよりも、品質保証・生産技術・製造現場の三者で握ることをおすすめします。欠陥定義や合否基準は品質保証、タクトや搬送は生産技術、現場の運用実態は製造現場が最も把握しているためです。いずれかが欠けると、後で要件が覆る可能性が高いと考えられます。第三者として導入支援が入る場合は、この三者の論点を引き出し整理する役割を担うことが有効だと考えています。
一概には言えませんが、要件の解像度が後工程の手戻りを大きく左右するため、急がず丁寧に詰める価値が高いと考えられます。ポイントは一度で固めようとしないことです。最初の要件は仮説と位置づけ、現物の撮像やトライアル評価で見えた事実をもとに更新していく前提で進めると、結果的に無駄が少なくなる可能性が高いと考えています。
限度見本がない、または整備されていない現場は少なくありません。その場合は、現場の検査員が実際にどこで弾いているかをヒアリングし、合格・不合格の境界に近いサンプルを集めて暫定的な限度見本を作ることから始めることをおすすめします。基準を実物で可視化する過程そのものが、現場と品質保証の認識合わせになると考えています。
発生頻度の低い致命欠陥はサンプルが集まりにくく、要件定義でも悩ましい点です。良品の基準から逸脱したものを検出する設計を検討したり、発生時に追加でサンプルを収集する運用を組み込んだりする方向が考えられます。いずれにせよ、サンプルの確保状況を要件定義の段階で棚卸ししておくことが、現実的なデータ戦略の前提になると考えています。
目標は決めるべきですが、人間の検査基準自体にばらつきがあることを踏まえた現実的な値にすることをおすすめします。同じサンプルでも検査員によって判定が割れることは珍しくありません。人が割れる判断にAIだけ完璧を求めるのは妥当でない場合が多く、まず人間の判定ばらつきを測り、それを出発点に期待値を調整することが、後の認識齟齬を防ぐと考えています。
対象・欠陥・許容・タクト・環境・出力——どこが曖昧かは、現物を撮ってみると見えてきます。元キーエンス画像処理事業部出身の監修者とともに、要件の詰め方から現場での検証まで伴走します。
要件定義の相談をする