外観検査AIって本当に自作できるの？現場で試した手順と限界

深夜2時。生産ラインが止まった静かな工場の隅で、あなたは折りたたみ椅子に腰かけてスマホを開いている。

今日も不良品が抜けた。ベテランは来月退職する。残った検査員の疲弊が、ここ数ヶ月で目に見えて増している。

「外観検査 AI 自作」——検索した。出てきたのは、SIerの営業ブログと、MNISTを題材にした初学者向けのPython入門記事だけだった。

それ、あなたの調べ方が悪いんじゃない。製造現場の解像度で書かれた情報が、ほとんど存在しないだけです。

「AIは億円規模のプロジェクトじゃないと無理」——これは嘘。でも「スキルなし・予算なし・データなしで今月から動く」も過大広告です。

今日持ち帰ってほしいのは、「本当に自作できる状況か」を判断する基準と、できるなら最初にやるべき5週間のロードマップ。それだけに絞って書きます。

---

「自作なら安い」という思い込みが最初の落とし穴

「SIerに頼むと高い。だから自作する」——その発想は正しい。でも、コスト計算の起点が間違っていることが多いんですよね。

外観検査AIのコストは、AIモデルそのものより「前段と後段」にかかります。

前段コスト①：撮影環境の整備

工場の蛍光灯のちらつき、窓からの外光の差し込み、シフトごとの輝度変化。

これを揃えないと、どんな賢いモデルも「同じ製品が別の製品に見える」という事態を起こします。

照明ボックスを自作するか、産業用のLEDリング照明に換装するか。小さいワークなら数万円、大型部品になると桁が変わります。

前段コスト②：データのラベリング工数

不良品の画像に「これはキズ」「これはバリ」とタグ付けする作業。

100枚なら半日、5,000枚なら2〜3週間のフルタイム相当です。

ここが一番読みが甘い部分で、プロジェクト遅延の主な原因になります。「AIを動かす前の地味な手作業」こそ、工数の大半を食います。

後段コスト：維持と再訓練

モデルは一度作って終わりではありません。

製品が変わる・ロットが変わる・季節で照明条件が変わるたびに精度が落ちます。

追加データを集めて再訓練する体制が必要で、「誰がいつやるか」を最初に決めていないプロジェクトは、3ヶ月で形骸化します。

自作のメリットは「仕組みを自分でコントロールできること」と「外注費を払い続けなくていいこと」。その対価は時間と、継続的な維持の意志です。

ここを腹落ちさせてから進む人と、そうでない人では、6ヶ月後の結果がまったく違います。

---

モデルより先に整えるべき「3つの土台」

ツールや手法の話に入る前に、この3つが揃っていないと、どんなモデルを使っても精度で詰まります。

土台①：撮影条件の固定

カメラの位置・画角・照明——これを毎回まったく同じにする仕組みが先です。

具体的には、カメラを固定する治具（じぐ：ワークや機材の位置を毎回決めるための専用固定具）を作り、照明を拡散板付きのLEDリング照明に換える。

「だいたい同じ位置」では足りません。ピクセル単位でぶれない固定の仕組みがないと、AIは「ワークが少し動いた」を「異物が付いた」と誤認識します。

土台②：方式の選択

外観検査AIには大きく2つの方式があります。

異常検知型（良品だけ学習する）

良品の画像だけを大量に学習させて、そこから外れたものを「不良かもしれない」として弾く方式。

不良品の画像がなくても学習を始められるのが最大のメリットです。「何かがおかしい」は検知できますが、「どんな不良か」は教えられません。

分類型（良品・不良品・種類まで学習する）

「キズ」「バリ」「合格品」それぞれを種類ごとに学習させて、判定結果まで出す方式。

精度は高いが、不良品の画像を種類ごとに数百〜数千枚単位で集める必要があります。立ち上がりのハードルが一気に上がる。

自作の入口として難易度が低いのは異常検知型です。まず良品だけで動くものを作って、精度を確認してから分類型に発展させていくのが現実的な順番です。

土台③：エッジかクラウドかの決定

推論（学習済みモデルで実際に判定を実行すること）をどこで動かすかを最初に決めます。

• エッジ（現場のPCや小型デバイスで動かす）: ネット不要・リアルタイム判定・ラインを止める指示まで出せる
• クラウドAPI（画像をクラウドに送って判定する）: 立ち上がりが早い・コスト変動型・ネット遅延が発生・画像送信のセキュリティ確認が必要

「不良品が流れてきたらラインを止める」という運用をするなら、エッジ一択です。

「品質記録として後から確認するだけ」なら、クラウドAPIでも十分機能します。

---

Before/After：検査員Aさんの1日 vs Bさんの1日

*架空の人名ですが、構造は外観検査AI補助の一般的な活用パターンを示しています。*

Aさん（AI補助なし）の1日

• 07:00　ライン稼働。全数を目視で確認。午前中の集中力が高い時間はほぼ見逃しなし
• 10:30　疲れが出始める。特に微細なキズの見逃しリスクが上がってくる
• 13:00　昼食後。眠気と判断力の低下が重なる、見逃しが一番多い時間帯
• 16:00　終盤。早く終わらせたい心理が判断に影響する
• 終業後　不良流出の報告。「いつ、どのワークが抜けたか」が追えない

Bさん（AIフラグ確認運用）の1日

• 07:00　カメラが全数を撮影し、AIが異常スコアを付ける。Bさんは「要確認フラグ」の製品だけを見る
• 10:30　疲れても、見るべき対象がフラグ品に絞られている。集中力の消費が構造的に少ない
• 13:00　AIは休まず動いている。Bさんの集中力低下が影響するのはフラグ品の最終確認のみ
• 16:00　AIは変わらず動く。終盤の焦りが全数に影響する構造になっていない
• 終業後　AIのログが時系列で残り「何時に異常が出始めたか」が追跡できる

AIが「人の代わりにすべてを判定する」のではなく、「集中力を使う場所を絞るフィルター」として機能する運用のほうが、現場の受け入れを得やすく、精度の維持もしやすいと思っています。

---

ゼロから5週間で動かす——自作の実際の手順

以下は「異常検知型」をゼロから自作する場合のロードマップです。

Pythonの基本（ライブラリのインストール・ファイル操作）ができる社内メンバーが1〜2名いる前提で書いています。

第1週：撮影環境の構築

カメラ固定治具を設計・制作します（3Dプリンタか板金加工）。照明を産業用LEDリング照明に換装。

完成後、同じ条件で100枚撮影して、背景・輝度・位置のぶれがないことを目視確認します。

「照明が揃うだけで半分終わった」と後から言う人が多いです。それくらい土台です。

第2週：良品データの収集と整理

良品を500〜1,000枚撮影します。日付・ロット・シフトをまたいで撮るのがポイントで、同一条件でしか撮らないとモデルが「その日のその環境」しか覚えません。

フォルダ構成は good/ 以下に日付フォルダを切るシンプルな構造で十分です。後で学習コードに読み込みやすくなります。

目視で見てブレている・照明が外れているものを除外する作業は省けません。ここが地味に大事です。

第3週：モデルの学習

ここで使えるのがオープンソースライブラリ Anomalib です。

Intelが開発・公開している異常検知専用のPythonライブラリで、製造現場の外観検査を想定した実装が揃っています。

先日、このAnomalibのドキュメントと、製造業の外観検査向けに公開されているベンチマークデータセット「MVTec AD」の論文を読んでいて唸ったんですよ。金属・木材・皮革など15カテゴリーの工業製品の表面欠陥を網羅したこのデータセット、自社の学習データがまだ集まっていない段階で「どのアルゴリズムが自分の用途に合いそうか」感触をつかむのに使えます。Anomalibはこのデータセットでの各手法の精度比較も掲載していて、PatchCore・PaDiM・FastFlowのどれを選ぶか判断する材料になります。

pip install anomalib

公式サンプルコードは良品フォルダを指定するだけで学習が走ります。GPUがなくてもCPUで動きますが、学習に数時間かかることは覚悟しておいてください。

第4週：検証と閾値（いきち）の調整

良品・不良品の混在サンプルで動かしてみます。

「見逃し率（不良を良品と誤判定する率）」と「誤検知率（良品を不良と誤判定する率）」のバランスを、閾値（判定の境界となる数値）で調整します。

どのバランスが許容できるかは、AIではなく現場の人間が決める判断です。ここをAIに委ねてはいけません。

第5週：小ラインでのパイロット稼働

まず1台のカメラ・1製品種で本番テストを開始します。

検査員と並走して、AIの判定と人の判定を突き合わせるログを取ります。

不一致が多い事例が、次の追加学習データの候補になります。パイロット期間はそのデータ収集の場でもあります。

---

使えるプロンプト2つ：詰まったときAIに相談する

プロンプト①：自社の検査AIの方式を選ぶ

あなたは製造業の品質管理と画像AI導入を専門とするエンジニアです。

製品名：[製品名または製品カテゴリー]
主な不良の種類（現場で呼ばれている名前のまま）：[例：キズ、バリ、色ムラ、欠け、異物付着]
現在の検査体制：[例：3名が目視で全数確認、シフト制]
月間の生産数：[例：約50,000個]
不良発生の頻度：[例：おおむね1,000個に1個程度]

上記を踏まえて以下を教えてください。
1. 分類型AIと異常検知型AIのどちらが適しているか（理由つきで）
2. まず集めるべきデータの種類と最低枚数の目安
3. 最初のパイロットに向けた優先順位の高いステップ3つ

使いどころ：データ収集を始める前、「何を集めれば動くのか」が整理できていないとき。

出力を検証する観点：提案された方式が現場のベテランの感覚と一致しているか確認する。AIが「分類型が良い」と言っても、不良品画像を集められる体制がない現場では意味がない。

---

プロンプト②：閾値の調整方針を考える

外観検査AIの検証フェーズにいます。状況を整理して助けてください。

現在の結果：
- 不良品の見逃し率（不良を良品と判定している割合）：[○○%]
- 良品の誤検知率（良品を不良と判定している割合）：[○○%]

現場の許容基準：
- 不良の見逃しは[○○件/日 または ○○ppm]以下にしたい
- 誤検知による再確認作業は[○○分/日]以内に抑えたい

この状況で閾値を調整するときのトレードオフを、現場の担当者にわかりやすく説明してください。
また、閾値調整だけでなく追加学習データで改善できる部分があれば指摘してください。

使いどころ：モデルは動いたが精度が現場の基準に届かないとき。

出力を検証する観点：AIが提案する「閾値の動かし方」が実際にコードで実装できる形か確認する（モデルの出力スコアへのアクセス方法を把握していないと実装できない）。

---

OSSかクラウドAPIかSIer委託か——選ぶ前に知る判断軸

僕が一番多く見る成功パターンは、「OSSベースで自作して、詰まったところだけ外注支援を使う」中間型です。

自分でコードを書いて動かすことで、問題が起きたときに自分でデバッグできる。それが長期的な運用コストを下げる一番の方法だと思っています。

クラウドAPIを選ぶ場合は、利用規約の「提供した画像がモデル学習に使われるか否か」を必ず確認してください。製品画像が機密情報にあたる場合、利用できないサービスがあります。

---

正直な限界：この現場には向かない

外観検査AIは万能ではありません。うまくいかないパターンを正直に書きます。

① 不良品がほとんど出ない現場

月に数個しか不良が出ない製品では、分類型モデルを作るだけのデータが集まるまでに何ヶ月もかかります。異常検知型で対応できるか検討するか、不良品を意図的に再現してデータを増やす「データオーグメンテーション（拡張）」が必要です。

② 多品種少量生産で品種が頻繁に変わる

品種が切り替わるたびに撮影条件とモデルを切り替える仕組みが必要です。品種数が10以上あるなら、最初からSIerと一緒に設計した方が現実的です。自作で対応できる上限を超えています。

③ 撮影環境を構造的に固定できない

屋外作業や大型構造物の現場検査など、照明が固定できない環境では精度の確保が非常に困難です。このケースはAIより先に撮影の標準化を検討すべき段階にあります。

④ 判定理由の説明が監査で求められる

ISO認証や顧客監査で「なぜそれを不良と判定したか」を文書で説明しなければならない場合、深層学習モデルの判断根拠は基本的にブラックボックスです。説明可能AI（XAI：モデルの判断理由を可視化する技術）を組み合わせる必要があり、自作の難易度が一段上がります。

⑤ Pythonを読めるエンジニアが社内にいない

OSSを自作で維持するには、Pythonが読めてDockerを扱えるエンジニアが社内に最低1名いることが前提です。それが難しい規模の会社は、クラウドAPIのUIツール、またはSaaS型の外観検査サービスを選ぶ方が現実的です。

---

ここで一つ、自分の経験を正直に書いておきます。

匠座では毎朝、記事生成のAIパイプラインを運用しています。ある週から、品質ゲート（自動チェックの仕組み）が静かに精度を落とし始めたことがありました。ログを見るまで気づかなかった。原因を追うと、テキスト入力の前処理ルーティングの設定が、バージョン更新の際にわずかにずれていた。「動いているから大丈夫」と思っていた部分が少しずつ劣化していたんです。

外観検査AIでも同じことは起きます。「作ったら終わり」ではなく「作ってから維持が本番」——これは自分で回して初めて実感できることです。

---

よくある質問に先に答えます

Q1. Pythonが書けなくても自作できますか?

「コーディングなし」で始めるなら、月額課金のSaaS型外観検査ツールを選ぶのが現実的です。

Anomalibなどのオープンソースを使う場合は、Pythonの基礎（ライブラリのインストール・ファイルパスの操作）ができるメンバーが社内に必要です。「ゼロから書く」必要はなく、公式サンプルコードを手元で動かせるレベルで入門できます。

Q2. 学習データは最低何枚必要ですか?

異常検知型なら良品画像200〜500枚で学習を試し始められます。分類型はカテゴリーごとに最低100〜300枚が目安です。これは「動かし始める最低ライン」であり、実運用の精度には追加学習が必ず必要になります。

Q3. 撮影カメラは何を買えばいいですか?

スマートフォンで試作するのはありですが、フレームレートの安定性と固定のしやすさの点で、早めに産業用USBカメラに切り替えた方が後が楽です。Basler・FLIR・HIKROBOTあたりが外観検査AIの自作での実績が多いです。ただし価格は解像度・インターフェース・フレームレートで大きく変わるため、メーカーカタログを見て要確認です。

Q4. 製品画像を社外に送ってよいか不安です

クラウドAPIを使う場合は、利用規約の「ユーザーが送信した画像をモデル改善に使用するか否か」を必ず確認してください。そうした条項があるサービスでは、機密性の高い製品画像を送るべきではありません。社外に出せない場合は、ローカル推論（エッジAI）を前提にOSSで組む一択です。

Q5. 費用対効果はいつ頃出てきますか?

一次情報シートに確定した統計がないため、断定はしません。自社で「不良流出1件あたりのコスト（クレーム対応・廃棄・再製造費）」と「AIシステムの維持費（人件費含む）」を試算して比較するのが正直な答えです。試算表を作らずに動かし始めてしまうのが、プロジェクトが途中で止まる最も多いパターンです。

---

---

ここまで読んで「自社だけでやるには手が足りない」と感じた方は、『AI鬼管理｜Claude Code業務自動化トレーニング』（Claude Codeで日々の業務を自動化する実践トレーニング（無料の業務効率化診断あり））のような外部サービスという選択肢もあります。急ぎでなければ、まずは無料のチェックリストで足元を固めるのがおすすめです。

AI鬼管理｜Claude Code業務自動化トレーニング ↗

今日やること：今夜30分でできる3ステップ

ステップ1（5分）：自社の不良の名前を紙に書き出す

「外観検査の不良」と一口に言っても、現場で実際に呼ばれている名前で書き出してください。

キズ・バリ・欠け・色ムラ・異物付着——この一覧が「分類型か異常検知型か」を選ぶための判断材料になります。ここから先のすべての会話が変わります。

ステップ2（15分）：Anomalibのリポジトリを眺める

Anomalib GitHub を開いて、READMEと対応手法の一覧を見てみてください。

「PatchCore」「PaDiM」「FastFlow」といった手法名と、製造業向けベンチマーク MVTec AD での精度比較が載っています。

購入も申し込みも不要。「何ができそうか」の感触をつかむだけで今夜は十分です。

ステップ3（10分）：現在の撮影条件をスマホで撮っておく

今の検査台のカメラ位置・照明・背景を写真に撮っておいてください。

後でエンジニアに相談するときも、AIに照明改善のアドバイスを求めるときも、この写真があるだけで会話の質が全然変わります。

まず3ステップ。それだけで、明日からの動き方が変わってきます。

---

編集長メモ：ヘリックス（執筆者について）

深夜に検索して、この記事にたどり着いた人へ。完璧な手順書ではないけれど「明日から動けるか」がすべてです。現場で詰まったら匠座へ声をかけてください。

▶ あわせて読みたい：物流 ai エージェント 物流の実務ガイド（2026-08）

▶ あわせて読みたい：物流 ai 活用事例の実務ガイド