工場現場映像をAIに解析させてメダリオンアーキテクチャを組んだら、サイクル分割がうまくいかなかった
概要
こんにちは、クラスメソッド製造ビジネステクノロジー部の田中聖也です。
プロセス製造などは大型設備からデータを取得しやすいですが、多品種少量や組立系、設備保全ではどうしても両手がふさがっているため、なかなか正確な作業記録が取れず、どの作業にどれぐらいの時間を要しているか取得できないですよね。
また、生産進捗のデータが取れないため、自動化のために投資したくても採算が取れるか分からないという悩みもあると思います。
作業を動画で撮影して、AIが動画解析をして生産進捗を確認できないかという考えがちょっと前からあり。。。
そこで、今回は撮影した動画をデータとして活かせないかと思い、データレイクハウスの世界でよく使われるメダリオンアーキテクチャ(Bronze/Silver/Goldの3層でデータの精製度を段階的に上げていく設計パターン)を工場の作業映像に当てはめて検証してみることにしました！
リポジトリはこちら
検証を進めていくと肝心の「作業サイクルの分割」のところで色々と試行錯誤があったので、その経緯も含めて記録に残しておきます。
また、動画はbuilddotai/Egocentric-10K（Hugging Face）から実際の作業動画を選択しました。
メダリオンアーキテクチャとは
メダリオンアーキテクチャは、データレイクハウス上でデータの精製度を段階的に上げていく論理設計パターンです。ポイントは、ローカルかクラウドかという置き場所ではなく、データの状態で層を分けるという考え方ですね。
| 層 | 精製度 | データの状態 | 目的 |
|---|---|---|---|
| Bronze | 低い | 生のまま(Raw) | 原本の不変保管。再処理・監査の起点 |
| Silver | 中くらい | 構造化・クレンジング済み | 「何が起きたか」が分かる事実データ |
| Gold | 高い | 業務利用可能 | KPI・可視化・他システム連携向け |
工場映像に当てはめると、こんなイメージになります↓
| 精製度 | 設備保全の動画だと |
|---|---|
| Bronze(低い) | 20260804_プレス機A-78_パッキン交換.mp4(ピクセルの塊) |
| Silver(中) | 14:32 パッキン交換開始／14:58完了(26分)、使用工具:六角レンチ、交換部品:パッキンP/N-4402 |
| Gold(高い) | プレス機A-078 パッキン交換、自動機KI-005 ファイバセンサ交換、MTTR: 50分、購入金額： 28,000円 |
Bronzeのままではダッシュボードにも AI にも渡しにくいですが、やり直しが効く原本として価値があります。Silverまで来れば分析・検索・アラートに使えて、Goldまで来れば現場長や経営が判断に使える形になりますね。
今回の検証の方針
本来、映像からSilverを作る役目はNVIDIAのLocal VLM/VSS(DeepStreamや物体検知、Dense Caption、SOP境界検知などを行うエッジ推論基盤)が担う想定です。ただ検証フェーズでは、Amazon Bedrock Runtime(Nova 2 Lite、Converse API)で代替することにしました。
正直なところ、最初はBedrock Data Automation(BDA)やClaudeでのコンタクトシート方式(FFmpegでフレームを抜き出してConverseのimage入力に渡す方式)も検討したんですが、東京リージョン非対応やコスト面から見送っています。Bronze(生映像)はクラウドに置く方針なので、そこから非同期バッチでSilverを生成する流れは自然に組める、という判断です。
なお、正解データは人手でイチから作らず、Google Geminiに作業動画を解析させて作成し、必要な箇所だけ人手補正するという手段を採りました。
過去の検証時にもGeminiは動画解析の精度が他のモデルと比較して高かった印象です。
検証環境
ざっくりこんな環境です。
| 項目 | 内容 |
|---|---|
| リージョン | ap-northeast-1(Tokyo) |
| 取り込み | S3への手動アップロード(カメラ直結は今後) |
| Bronze | S3(SSE-S3、バージョニングなし、14〜30日Expire) |
| Silver生成 | Bedrock Runtime Converse(jp.amazon.nova-2-lite-v1:0) |
| Gold | Athenaで KPI 相当を確認 |
| 開発端末 | Windows11 |
デモ前提の方針として、すぐ削除できて最小コストであることを優先し、セキュリティ強化や本番ガバナンスは後回しにしています。
やってみた: パイプライン疎通
まずは、「Bronze→Silverはちゃんと繋がるのか」を確認しました。
結果としてS3に動画を置くと、EventBridge→ingest Lambda→analyze Lambda→Bedrock Converse→Silver(S3 Tables/Iceberg)まで自動で流れることを実測で確認できました。
パイプラインの骨組み自体はスムーズに組めたんですが、ここから先の「作業解析」でうまくいかず、色々と試行錯誤しました。
やってみた: 実際にどんな解析をしているのか
各動画は同じパイプラインで、Bedrock Nova 2 Lite(jp.amazon.nova-2-lite-v1:0)による作業工程のチャプター分割を行っています。analyze Lambda が動画をBedrock Converseに渡し、返ってくるJSONの中身を見るとこんな構成になっています↓
| 項目 | 内容 |
|---|---|
| 全体要約 | overall_summary(動画全体の要約文)、作業者数 |
| 工程分割 | 標準作業手順の5つの作業をチャプター分割 |
| 各章の付帯情報 | カテゴリ・標準作業手順通りであるか・PPE(Personal Protective Equipment、保護具)着用状況・異常フラグ・主要物体 |
標準作業手順の順序は以下です
- coil_set(コイル装填)
- stator_mount(スタータ取り付け)
- marking(刻印)
- press_insert(プレス圧入)
- unload_rack(ラックへの荷下ろし)
- idle(どの工程には当たらない)
この5要素をプロンプトに閉じた語彙で固定して、動画ごとにどこまで正しく分割できるかを見ています。
動画ごとの解析結果
同じパイプラインに複数の動画を通した結果がこれです。各動画はすべて同じ作業内容ですが、分割する部分を変更したし、2サイクル分の動画入れたりと変更しています。
| 動画 | 尺目安 | チャプター数 | 検出した工程列 | 備考 |
|---|---|---|---|---|
| 動画1 | 約67秒 | 4 | marking→stator_mount→press_insert→unload_rack | coil_setが欠落 |
| 動画2 | 約67秒 | 5 | coil_set→stator_mount→marking→press_insert→unload_rack | 唯一フル分割成功 |
| 動画3 | 約123秒 | 4 | marking→coil_set→unload_rack→coil_set | 要素マージ＋偽サイクル |
| 動画4 | 約123秒 | 1 | marking(全体) | 2サイクル想定だが1本に潰れた |
同じ約67秒の動画でも、動画1はcoil_setが欠落して4分割、動画2だけがフルの5分割に成功していることが分かりました。尺が同じでもクリップによって分割の成否が変わってしまうんですよね。
いずれの動画もworker_count: 2(作業者2名)、ppe_status: unknown、anomaly_flag: false、sop_deviation: noneという値で、この辺りの付帯情報自体は安定して返ってきています。モデルは要約の時点では「コイル挿入から荷下ろしまで」としっかり工程を認識できているんですが、チャプターへの時間分割はクリップ依存で不安定というのが、この検証で見えてきた実態です。
分割に成功した唯一の例(動画2)
動画2だけがフルの5要素分割に成功したので、その内訳を見てみます↓
| # | 工程 | 区間 |
|---|---|---|
| 0 | coil_set | 0–12秒 |
| 1 | stator_mount | 12–19秒 |
| 2 | marking | 19–25秒 |
| 3 | press_insert | 25–45秒 |
| 4 | unload_rack | 45–67秒 |
きれいに標準作業手順どおり、5要素すべてが検出できています。ただ、この後の「正解データとの比較」で見るとおり、分割自体は成功していても時間の境界には数秒のズレがあって、そこはまだ精度が甘いんですよね。
効かなかった打ち手
サイクル境界をプロンプトで明示的に強化しても、この状況は改善しませんでした。
ここが時間を使った部分なので、失敗の記録として残しておきます。
失敗1: プロンプトに「同じ作業が続くならチャプターは1本」と書いていた
→ これが長尺動画が1チャプターに潰れる主因の一つだったと分かり、削除しました。
失敗2: unload_rack完了(両手が離れた瞬間)をサイクル境界とする制約条件をプロンプトに追記
→ 165800(2サイクル)で再測定しても、チャプター数は依然1のまま。ラベルがcoil_set→markingに変わっただけで、実質的な改善はありませんでした。
失敗3: temperatureを0.2→0.1に下げる
→ こちらも効果なし。生成のランダム性(temperature、値を下げるほど出力が決定的になるパラメータ)を絞っても、分割の壁は崩せませんでした。
失敗4: apac.amazon.nova-pro-v1:0への差し替え
→ 分割精度を上げたくて試したんですが、ValidationException: Provided S3Location not foundで頓挫。同じS3 URI・同じIAMでjp.amazon.nova-2-lite-v1:0(Nova 2 Lite)は成功するのに、Nova Pro系だけこのエラーが出るという不思議な状態でした。AWSドキュメントMCPと読み取り専用APIで調べたところ、apac.のクロスリージョン推論(呼び出しリージョンとは別のリージョンに実処理が飛ぶ仕組み)が東京以外にルーティングされた際、TokyoにあるS3オブジェクトを解決できずにエラーになっている、というのが有力な仮説です。
失敗5(環境固有): PowerShellでpayloadを書き出すとBOM付きUTF-8になり、analyze Lambdaの手動invokeがSyntaxErrorでこけた
→ Windows環境あるあるだと思うんですが、UTF8Encoding($false)を指定してBOM無しで書き出すことで解決しました。細かいところですが、ここでも地味に時間を溶かしましたね。
正解データとの比較
正解データはGoogle Geminiに作業動画を解析させてCSVを作成し、必要に応じて人手補正する方式にしました。
比較結果はこちら↓
| 指標 | 動画1 | 動画2 | 動画3 | 動画4 |
|---|---|---|---|---|
| 要素ラベル一致率 | 0.1 | 0.8 | 0.4 | 0 |
| サイクル数 | 1/2 | 1/1 | 3/1 | 0/2 |
現時点の評価
| 観点 | 判定 |
|---|---|
| メダリオン構成(Bronze→Silver→Gold) | 成立。スキーマ不変性も実証済み |
| 要素作業のラベリング(閉語彙・順序) | クリップ依存。短尺1サイクルのみ成功 |
| サイクル分割(複数サイクルの検出) | 未達。2サイクルが1本に潰れる/偽サイクルも出る |
| 時間局在化の精度 | 良くても±7〜8秒の差はでる |
アーキテクチャの骨組みは確実に組めるし、スキーマを固定しておけば生成主体を差し替えても後段が壊れないことも実証できましたね。ただサイクル分割という一番肝心なところがまだ攻略できていない、というのが今回の検証の結論です。
まとめ
メダリオンアーキテクチャの骨組みとスキーマ不変性は実証できましたが、肝心のサイクル分割ではなかなか上手くできずでした。
モデルが工程の中身を理解しているのに分割だけうまくいかない部分は、複雑な工程や何人も関係する作業はもっと難しくなりそうなので試行錯誤が必要だと感じました。
