製造現場の動画と工程文書をつないで作業の異常候補を検索できるようにしてみた
こんにちは！クラスメソッド製造ビジネステクノロジー部のtanaka-takeruです。
製造現場では、設備信号や品質記録、標準作業書、日報などの多くの情報がある中で、常に生産が進み状況が変わる工程を、横断して統合的に把握することは簡単ではありません。
- 安全性は問題ないか？今日の生産数は確保できそうか？規定から逸脱していないか？
こういった現状に対して、NVIDIA は Factory Operations Blueprint、通称 FOX を発表しています。 設備信号、品質情報、作業手順、現場アラートなどをつなぎ、Factory Manager AI が現場の状況を理解して支援する構成です。
一方で、いきなり工場全体のデータ基盤や自律化を目指すのは現実的ではないことから、弊社の森茂が紹介している Mini-FOX は、1ライン・1カメラ・1ユースケースから小さく検証を始める考え方です。
はじめに
今回はこの Mini-FOX の考え方を参考に、1工程・1本の作業者視点動画・「標準作業以外で起きていた異常について知りたい」という1つの問いに絞り、製造データを用いた統合検索・確認デモを作ってみました。
この記事では、作業動画から確認候補を抽出し、文書情報と結びつけ、自然言語で質問するまでのパイプラインと、デモ動画をご紹介します。
データ
動画には、 Egocentric-10K の factory001_worker001_00002.mp4 を使いました。
作業者視点で記録されたプレス機作業の動画で、今回使用したファイルは約20分、1920×1080、30FPS です。魚眼に近いレンズで広角に撮影しており歪曲収差も見られます。
Egocentric-10K は工場内の第一人称動画を収録したオープンデータセットです。今回の動画には、工程名、作業標準、異常ラベルといったアノテーション情報は付属していません。そのため、動画だけを見て「何が正しい作業か」を判断するのではなく、工程文書を作成して組み合わせることにしました。
パイプライン
次の流れで処理します。
- 作業動画を5FPSでサンプリングして、フレーム差分から、前のフレームからどれくらい動いているかを定量化します。あわせて金型領域・手の動きを検出します。
- 動きの量の時系列を自己相関で分析し、普段の繰り返し動作から外れた区間を「確認候補区間」として抽出します。この時点では異常と確定しません。
- 確認候補の区間だけを10FPSで抽出し直し、ローカルで動かした VL M （Qwen3-VL-4B-Instruct）に渡します。ここでは、見えている動きを観察メモとして記録します。
- 必要に応じて人間がレビューして異常か否かを確定します（非同期）。未確認の候補はそのまま残します。
- 時系列データ、VLM の観察メモ、人手確認、工程 に関する文書を、イベントJSONに集約します。
- ユーザーから質問を受けたら、質問に関係するイベントJSONと文書チャンクを選び、LLM（Claude Sonnet 5）に渡します。Claude は根拠とともに回答を組み立てます。
最初の段階では、動画全体を大規模モデルに渡しません。動画を5FPSで処理して、画面全体の動きの量、金型領域の追跡、手の位置・動きを時系列データ化し、そこから、通常の繰り返し動作と異なる区間を確認候補として抽出することで注目すべき情報に絞ります。
Mini-FOX の「まずイベント化し、必要な候補だけを深く見る」という段階的な構成に近い形です。
インプットした情報
動画データ
動画側では、以下の情報を検出して、同じ時刻軸で扱えるようにしました。
| 情報 | 取得方法 | 今回の使い方 |
|---|---|---|
| 動きの量 | フレーム差分 | 繰り返し動作の乱れ、動きの停滞の検出 |
| 金型領域 | SAM2 による追跡 | 金型付近にいるか、領域が隠れているかの補助情報 |
| 手の動き | MediaPipe Hand Landmarker | 手の位置、速度、左右の動きの補助情報 |
前提として、いかに早く安く他工程・他製品に水平展開できるかが非常に重要なため、基本的にファインチューニングや最適化は行わず、ゼロショットもしくはワンショットで構築可能なパイプラインとしています。
動画に抽出した情報をオーバーレイした様子を示します。
- 動きの量について、一人称視点の映像は作業段階に伴って画角が変わることが多いため、映像全体の動きの量を抽出することで、ざっくりと周期性を捉えることが期待できます。デモ動画の下部分にプロットしています（フレーム間変化量、無次元）。30秒窓で自己相関を取り、映像全体で安定している繰り返し動作から外れた箇所を見つけます。フレーム差分の算出自体は非常に軽量で、Raspberry Pi などのエッジデバイスでも扱いやすいです。
- 金型領域は付加価値時間に最も関連すると考えMetaの SAM2 でトラッキングしています。動画中央の緑色の領域です。この金型領域の変化を抽出することで、サイクルタイムや生産個数をカウントできます。
https://github.com/facebookresearch/sam2?tab=readme-ov-file - 手の動きは MediaPipe Hand Landmarker で検出しています。なお、実際の現場で手袋をしている場合はその色や膨らみ、油・汚れなどの付着によって精度は低下します。
https://developers.google.com/edge/mediapipe/solutions/vision/hand_landmarker#models
文書データ
次のデモ用文書を作成しました。
| 文書 | 主な役割 |
|---|---|
| 安全作業標準規定書 | 上位の安全ルール |
| 標準作業手順書 | 作業手順と安全上の注意 |
| 標準作業組合せ票 | P-040 の標準タクトと要素作業 |
| QC工程表 | ワークセット時の品質基準 |
| 日常点検・生産日報 | 実績・警告・遅延の記録 |
一例を示します。
工程に関する文書の種類や数は非常に多くありますが、大きく3種類に分かれていることを想定しました。
- まず、会社や事業部単位で定められている情報です。規則や規定、業務分掌などですが、今回は、全社で定められている「安全作業標準規定書」とします。
- 次に、工程を定義している情報です。QC工程表・標準作業組合せ票・標準作業手順書を用意しました。
- 最後に、工程を日々流れる情報です。生産計画から人員配置などですが、今回は日常点検・生産日報を用意しました。
仮想的に決めた工程コード P-040 と文書番号をキーにして、イベントと関連文書をたどれるようにしています。
イベントJSON
「いつもの動きと違うかも」と切り出された区間の情報を、後段のLLMで扱いやすい単位に集約します。
次に表に示すように、5種類の情報をまとめています。
| 層 | イベントJSONの項目 | 何が入るか |
|---|---|---|
| 1. 計測値 | time_series_evidence |
動きの量、金型領域、手の位置などの時系列データ |
| 2. ルールによる候補抽出 | candidate_detection |
同じ入力・条件なら同じ結果になる抽出シグナルと集計値 |
| 3. VLMによる映像観察 | visual_evidence |
映像で見える動きの説明と、見え方の注意点 |
| 4. 人手確認 | human_review |
人が動画を確認して記録した事実 |
| 5. 文書根拠 | document_links |
標準作業書、QC工程表、日報などへの参照 |
例として、人のレビュー情報を持つ確認候補イベントのJSONは次の様になっています。読みやすさのため、集計値・VLMメモ・文書リンクは抜粋しています。
{
"entity_type": "tact_deviation_candidate",
"event_id": "P040-CAND-001",
"process_id": "P-040",
"time_range_sec": [335.0, 394.8],
"focus_sec": 370.0,
"status": "要確認",
"candidate_detection": {
"signals": ["繰り返し動作の消失", "通常サイクルからのずれ"],
"metrics": {
"observed_period_sec": [7.6, 7.8, null],
"period_strength_range": [0.147, 0.304]
}
},
"time_series_evidence": {
"motion": {"source": "motion.jsonl", "motion": {"mean": 0.1115}},
"die_roi": {"source": "tracks.jsonl", "present_ratio": 0.91},
"hands": {"source": "hands.jsonl", "by_side": {"Left": {}, "Right": {}}}
},
"visual_evidence": {
"sampling": {"fps": 10, "max_frames_per_inference": 16},
"llm_excerpt": [{
"range_sec": [368.6, 370.1],
"visual_observation": "右手が治具に置かれた金属部品を調整している。",
"caveat": "手の動きは微小であり、詳細な動作の判断は困難。"
}]
},
"human_review": [{
"event_id": "P040-TD-002",
"severity": "minor",
"category": "workpiece_set_failure",
"summary": "カシメ機へのワークセットがうまくいかず、再セットが発生している。"
}],
"document_links": [
{"document_id": "STD-WI-P040-001", "section": "基本情報"},
{"document_id": "QC-PR-2026-042", "section": "ワークセット"}
]
}
少し項目が複雑に見えますが、計測値、ルールによる候補抽出、VLMの観察、人手確認、文書根拠を混同しないように分けて保持しています
- 確認候補であるにもかかわらず、異常と断定することがないようにする
- イベントの根拠をトレースしやすくする
- 適切に人間のレビューを挟めるようにする
たとえば、「手が治具を調整しているように見える」は VLM の出力であり、それが本当なのかは人が動画を確認して初めて分かることです。これらを1つの要約文にしてしまうと、後から見た人や処理するLLMが、どこまでが計測結果でどこからが解釈なのかを判断しにくくなると考え、上記の構造としました。
デモ
デモ画面では、左側に作業動画と時系列グラフ、右側に質問UIを配置しています。動画には、SAM2 で追跡した金型領域と MediaPipe で検出した手をオーバーレイしています。動画の再生時刻とグラフ上の位置は常に連動します。
グラフにある確認候補区間をクリックすると、その区間に関するVLM出力を中心に、検出シグナルや金型・手の時系列情報、人手確認の有無を確認できます。
今回は、動きの量のグラフを目視して、次の2件を人手で確認しました。
| 人手確認イベント | 時刻 | 内容 |
|---|---|---|
| P040-TD-002 | 6:05 前後 | カシメ機にワークをうまくセットできず、再セットが発生 |
| P040-TD-001 | 12:39〜14:21 頃 | 作業を中断して他の作業者のところへ移動 |
自動抽出はこの2件を含む4区間を確認候補として出しました。人手確認済みの2件と、まだ確認していない候補を明確に分けてイベントJSONへ記録しています。
たとえば「標準作業以外で起きていた異常について知りたい」と質問すると、LLM は人手確認済みのワークセット不良と作業中断を中心に回答し、未確認の区間については「候補検出のみ」として区別します。映像観察メモだけで原因や安全違反を断定しない制約も入れています。
実際に画面を動かすと、時系列の変化を見て、気になった区間の映像に戻り、文書の根拠を参照しながら質問するサイクルで、20分の作業記録を見ることに比べて、格段に多面的に情報をキャッチアップできると思いました。
VLMに渡すフレーム数
確認候補区間の映像は、ローカル環境の Qwen3-VL-4B-Instruct に渡して観察させました。ここでは、1区間につき数枚の代表フレームだけを渡す方法と、動画の全フレームを渡す方法の間をどう取るかが課題になります。
この区間の長さはなかなか読みづらいです。固定閾値で縛ることもできますが、なるべく素朴に情報を得たいところです。デモで実際にアラートされた区間は、約60秒から約195秒と長さに幅がありました。前者は比較的短い候補区間ですが、後者は作業場所を離れて別の作業者のところに移動するケースです。
この時、たとえば開始・中間・終了の3枚だけをVLMに入力しては、手元の微小な調整や作業者が離脱するまでの変化を取りこぼす可能性があります。一方で、数分の動画をそのままVLMに渡すのは、入力サイズ・推論時間・コストの面で現実的ではありません。
そこで、次のようにしました。
- 候補区間を 10fps で画像列にする
- 1回の推論には最大16フレーム（1.6秒換算）だけを渡す
- 16フレーム単位の観察メモを残し、イベントJSONにはその抜粋と元データへの参照を保存する
つまり、1回の推論で長尺の候補区間全体を理解させるのではなく、時間順に小さく分割して観察させています。今回の実行では、約60秒の候補で38回、約195秒の候補で122回の推論になりました。フレーム数はすべての工程で固定の正解があるわけではないため、候補区間の長さと確認したい粒度に応じて変える前提です。
10FPSは、映像を完全に連続理解させるためではなく、治具付近の手の調整のような短い変化を見落としにくくする程度に選びました。
また、VLM の役割は、区間内で見えている動きの記述までです。異常の確定、原因の推定、安全違反の判定はさせていません。
RAGについて
質問時には、まず質問と工程コードに関連するイベントJSONを選びます。
次に、そのイベントが参照する文書チャンクを集め、イベント・文書・人手確認をまとめて LLM に渡します。
回答のプロンプトには次の制約を入れています。
- 候補検出と人手確認済みのイベントを混同しない
- VLM の観察メモを原因や違反の断定根拠にしない
- 根拠となるイベントID・文書番号を回答に含める
- データにない原因は「不明」とする
今回は、ベクトル検索基盤は用意せず、文書を意味のまとまりごとにチャンク化し、工程コード・文書ID・タグ・キーワードで関連するものを選びました。
最後に
今回は、製造動画と工程文書を使って、Mini-FOX として小さな統合検索・確認デモを作ってみました。
動画をすべて VLM に渡すのではなく、軽量な映像メタデータから確認候補を抽出し、候補をイベント化してから文書とつなぐことで、処理コストと人の確認しやすさの両方を意識したパイプラインにできました。
前工程や後工程はもちろん、生産技術や生産管理、品質保証など機能軸の情報も追加することで、大きな価値につながると思います。
さらに、営業・調達の情報連携といったSCM軸への展開や、開発・FEへのフィードバック、改善要望といったPLM軸への展開など、夢が広がります。
こういった技術の実現性を小さく始められるところが Mini-FOX の魅力だと思います。まずは1工程・1カメラ・1つの問いから始めて、映像を現場で参照できる情報に変えることを体験してみることが重要だと思います。
