自社製品で自動検査を実証する
実際のサンプルによる実現可能性判定から始めます。視覚タスクの中にはラインの速度では解決できないものがあり、それを1週目に知るほうが安く済むからです。続いて撮像設計、アノテーション済みデータ、検証済みモデル、管理された実ライン試験を行い、欠陥クラスごとに、見逃した不良と誤って弾いた良品を分けて報告します。
外観検査のユースケースを確認する製造エンジニアに相談する解決したい課題はこれでしょうか
- 目視検査が、長いシフトの終わりにある人の集中力に依存している。
- 同じ種類の不良が繰り返し顧客に届いているが、その頻度を誰も把握していない。
- 検査工程がボトルネックとなり、ラインを高速化できない。
- 過去の外観検査プロジェクトは精度の数値で受け入れられたが、本当に重要な不良で失敗した。
主なご担当者: 品質保証責任者 · 製造部門責任者 · 自動化推進責任者 · 技術部門責任者 · 工場長
このPoCで実証すること
推奨するパイロット範囲
- 実際のバリエーションを含む、1つの検査工程と1つの製品ファミリー。
- 「あらゆる不良」ではなく、範囲を定めて命名された欠陥または検証クラスのセット。
- 撮像設計のステップで決定した、選定したカメラ・レンズ・照明。
- 判定が実際のアクションにつながる、1つの弾き出しまたは作業者確認フロー。
- 学習用・検証用・受け入れ用のサンプルを、全工程を通じて厳密に分離する。
PoC期間中に実際に稼働するもの
このPoCの進め方
期間は標準的な目安であり、保証ではありません。日程が延びる要因は、データの欠落や不備、セキュリティおよびネットワークの承認、機器の納期、サンプルの収集、設置のための立ち入り、生産計画、ERPテスト環境へのアクセス、そして結果を評価するために貴社チームが必要とする時間です。
計画外の停止は想定していません。設置のための作業枠や管理された中断が必要な場合は、事前に貴社と合意し、生産計画に合わせて調整します。
成果の測り方
| 指標 | 定義の仕方 | 数値の出どころ | 種類 |
|---|---|---|---|
| クラスごとの適合率 | あるクラスとして判定された部品のうち、実際にそのクラスに属する割合。クラスごとに報告し、1つの数字に平均化しない。 | 検証用に取り分けたデータセット | 技術 |
| クラスごとの再現率 | 実際にあるクラスの欠陥を示す部品のうち、検出された割合。クラスおよび製品バリエーションごとに報告する。 | 検証用に取り分けたデータセット | 技術 |
| 誤良品判定率 | 不良品が良品として通過した件数。ビジネス上のコストが全く異なるため、誤不良判定とは別に集計・報告する。 | 検証用に取り分けたデータセット | 技術 |
| 誤不良判定率 | 良品が不良と判定された件数。作業者がシステムを稼働させ続けるかどうかを左右する数値。 | 検証用に取り分けたデータセット | 運用 |
| 混同行列とサンプル数 | クラスごとのサンプル数を伴う完全なクラス別行列。結果がどれだけ信頼できるかを読者が判断できるようにする。 | 検証用に取り分けたデータセット | 技術 |
| 処理遅延とライン速度適合性 | ワークステーションではなくライン上で測定した、利用可能なサイクルタイムに対する部品ごとの検査時間。 | MSFプラットフォームのデータ | 技術 |
| 不確実分類率 | モデルが自信を持って判定できなかった部品の割合。作業者確認フローが吸収すべき対象。 | 検証用に取り分けたデータセット | 運用 |
| 稼働率と作業者確認行動 | ライン試験中のシステム可用性、および作業者が確認・上書きを実際にどう扱ったか。 | MSFプラットフォームのデータ | 定着 |
実装に入る前に、各指標の算出方法、ベースラインの出どころ、除外するデータ、そしてどの結果であれば展開判断を支持できるのかを、MSFと貴社チームで合意します。本ページに記載しているのは「何を測るか」であり、具体的な目標値は営業的な約束ではなく、書面のPoC範囲に記載します。
ご提供いただくもの
- 範囲内のすべてのバリエーションと欠陥クラスを網羅する、代表的な良品・不良品の部品または画像。
- 欠陥の定義、重大度ルール、許容できる誤良品判定・誤不良判定の水準。
- 検査工程でのサイクルタイム、ライン速度、視野、環境条件。
- PLCまたは弾き出しインターフェースの詳細、およびトレーサビリティ要件。
役割分担
Meta Smart Factoryが提供するもの
- 現状把握ワークショップと範囲決定の進行
- 合意した範囲に合わせたソリューション設定
- その範囲内での連携・接続作業
- ご提案書に記載したMSFのハードウェア
- パイロット利用者向けのトレーニング
- KPIの定義と検証方法
- パイロット期間中の課題管理とサポート
- 最終結果レポートと展開設計
- 実現可能性の判定、撮像設計、評価が再現可能な検証済みモデルバージョン。
- 正しく判定した例だけでなく、誤って判定した画像を含む失敗事例。
貴社にご提供いただくもの
- 指名された業務責任者と技術責任者
- 利用者・ライン・設備・承認済みシステムへの適時のアクセス
- 工程とマスターデータの正確な説明
- ネットワーク・電源・取付け・安全面の立ち入り許可
- ERP・PLC・機器メーカーの資料と、それを把握している担当者
- 代表性のあるサンプルまたは過去データ
- ベースラインが妥当であることの確認
- フィードバックと受け入れ判断
- 各クラスについて十分な実際の不良サンプル。稀な欠陥ほど入手が難しく、また最も重要です。
- 通常の生産速度での管理された試験のためのライン立ち会いアクセス。
書面のご提案で取り決める事項
- パネルPC・タブレット・サーバー・GPUサーバー
- カメラ・レンズ・照明・保護筐体
- スキャナー・プリンター・RFID機器・計器・センサー
- 出張・設置・輸送・輸入関税・現地電気工事
- ハードウェアをレンタルとするか購入とするか
- PoC費用を本展開の費用に充当するかどうか
商用条件、ハードウェアの所有、出張、連携の範囲、本展開への費用充当の有無は、書面のPoC提案書で定めます。これらは製品ごとに同一ではなく、本ページで保証するものではありません。
最終的にお渡しするもの
- 判定の根拠を伴う実現可能性判定。
- 実部品で検証された撮像・照明設計。
- 評価が再現可能な検証済みモデルバージョン。
- 失敗事例を含む、欠陥クラスごとの指標レポート。
- 性能を低下させる条件を網羅したリスク・制約リスト。
- ハードウェア部材数量表、統合アーキテクチャ、展開の推奨事項。
前提条件・対象外・限界
このPoCの前提条件
- クラスごとの十分な実際の不良サンプル — これが外観検査PoC遅延の最も一般的な原因です。
- 検査工程での安定した部品提示、またはそれを実現するための合意した治具。
このPoCに含まれないもの
- 範囲内で命名されていない欠陥クラス、およびサンプルに含まれない製品バリエーション。
- 機械的なハンドリング、治具、弾き出し機構の構築。
全体精度は決して受け入れ指標として使用しません。不均衡な欠陥セットでは、重要な不良をすべて見逃していても優れた数値に見えることがあります。結果はサンプル数とともにクラスごとに報告し、検証済みセットに含まれない欠陥種別・バリエーション・条件については一切主張しません。
継続・修正・中止 — 判断のポイント
よくあるご質問
何個のサンプル部品が必要ですか。
欠陥と製品のばらつきによって異なり、実現可能性判定のステップで貴社の場合の具体的な数字を示します。原則として制約になるのは良品ではなく（それはどこにでもある）、各クラスの実際の不良サンプルです。特にプロジェクトの本来の理由である稀な欠陥ほど重要です。
なぜ精度だけを報告しないのですか。
不良率2%のラインで、すべてを合格と判定するモデルは精度98%を記録しながら何も検出できません。クラスごとの適合率・再現率、そして誤良品判定と誤不良判定を分けた数字だけが、貴社のラインで実際に何が起こるかを描写できる数字です。
実現可能性判定が「不可」となった場合はどうなりますか。
判定理由、撮像に関するエビデンス、そして存在する場合は代替案（別の検査位置、別の照明ジオメトリ、視覚ではなくセンサーベースの検査など）を受け取ります。1週目の明確な「不可」は、9か月目に失敗した検査セルよりも良い結果です。
後で新しい欠陥種別にも対応しますか。
自動的には対応せず、これは曖昧にせず制約リストに明記します。モデルは学習・検証した内容を検出します。新しい欠陥クラスには新しいサンプル、再学習、新たな検証が必要です。これは通常の計画可能な作業ですが、無料ではありません。
関連する製品とPoCプログラム
このPoCを依頼する
ご検討中の範囲をお知らせください。何を接続するのか、貴社に何をご用意いただくのか、成果をどう測るのか、最後にどのような判断を行うのかを、書面のPoC計画としてご返信します。