目次
1. はじめに
前回の記事では、画像と言語を組み合わせて扱うAI技術であるVLM（Vision-Language Model）について整理しました。
VLMによって、画像の内容を自然言語で説明したり、画像について質問したりすることが可能になります。
では、対象が「動画」になった場合はどうでしょうか。
動画には、1枚の画像には含まれていない時間的な情報があります。
AIはどのようにして、このよう時間の流れを含んだ動画の内容を理解できるようになってきたのでしょうか。
本記事では、まず動画理解AIの基本的な考え方を整理し、静止画の画像認識やVLMと比較しながら、動画の時間的な情報をどのように扱うのかを見ていきます。
そのうえで、私が現在注目している技術の一つである、NVIDIAのVideo Search and Summarization（VSS）を取り上げます。VSSがどのような仕組みによって動画の検索・要約・質問応答を可能にしているのかを整理し、大量の動画を「見る」だけでなく「検索・分析できるデータ」として扱うための技術について考えます。
そして最後に、こうした動画理解技術を製造現場ではどのように活用できるのかについて考察します。
動画が「記録」から「活用できるデータ」へ変わるとき、製造現場では何が変わるのでしょうか。
2. 動画理解とは何か
2.1 動画をどのように表現するか
動画理解を考えるうえで、まず重要になるのが、動画をAIがどのような情報として扱うのかという問題です。
画像は、縦・横の2次元の空間情報として表現できます。
一方、動画は画像が時間方向に連続して並んだデータであるため、
画像：空間情報（x, y）
動画：空間情報（x, y）＋時間情報（t）
として考える必要があります。
例えば、1枚の画像から「作業者が工具を持っている」という状態を認識することはできます。
しかし、
「作業者が工具を取った後、どのような動作を行い、その結果ワークの状態がどう変化したのか」
を理解するには、複数のフレームを時間的な順序とともに捉える必要があります。
そのため動画理解では、空間的な特徴に加えて、時間方向の情報をどのように抽出・表現するかが重要な研究課題となってきました。
以下に、動画をTransformerで扱う代表的なアプローチを簡略化して整理します。
図：動画を扱うVision Transformerの主なアプローチ
※筆者作成。各原論文を参考に、各手法の考え方を簡略化して示しています。
図に示したように、動画を扱う方法には、フレームごとに画像特徴を抽出して時間方向に統合する方法、時間情報を特徴に付加する方法、動画全体を時空間的に処理する方法など、さまざまなアプローチがあります。
ViViTでは動画全体を時空間的なTokenとして扱い、
TimeSformerでは空間方向と時間方向のAttentionを分けて処理します。
また、Video Swin Transformerでは局所的な時空間領域にAttentionを適用することで、計算量を抑えながら動画を処理します。
一見すると異なる手法ですが、共通しているのは、
画像の空間情報だけでなく、時間方向の変化をどのようにモデルに取り込むか
という課題に取り組んでいる点です。
そして、動画を時空間的な特徴として扱えるようになると、次に重要になるのが、その動画情報をどのようにLLMへ接続するかという問題です。
2.2 動画とLLMをどのように接続するか
動画を時空間的な特徴として扱えるようになると、次の課題は、
動画から得られた情報を、LLMにどのように渡すのか
という問題です。
代表的には、大きく次のようなアプローチがあります。
① Video Analyzer → LLM
動画
↓
Caption / OCR / ASR / Trackingなど
↓
テキスト
↓
LLM
動画を別のモデルで解析し、その結果をテキストとしてLLMに渡す方法です。
② Video Encoder → LLM
動画
↓
Video Encoder
↓
Video Embedding
↓
LLM
のように、動画そのものをVideo Encoderで特徴量に変換し、LLMに接続する方法も研究されています。
③ ①＋②の混合型
動画のEmbeddingと、CaptionやOCR、音声認識などから得られる情報を組み合わせてLLMに入力するようなアプローチもあります。
こうした研究の発展によって、AIは動画を単に分類するだけでなく、
- 動画の内容について質問する
- 特定の出来事を説明する
- 動画を要約する
- 必要な場面を検索する
といった、より柔軟な動画理解へと発展しています。
2.3 「何が映っているか」から「何が起きているか」へ
動画理解をさらに考えていくと、単に物体や動作を認識するだけではなく、その物体が空間的・時間的にどのように動いているのかを理解することも重要になります。
例えば、
「人が椅子に座った」
という出来事を理解する場合、
Semantics
人・椅子・座る
＋
Geometry
位置・姿勢・距離・接触
の両方が必要になります。
このように、Semantics（意味理解）とGeometry（幾何理解）を統合して動画を理解する方向へ研究が進んでいます。
さらに将来的には、現在の状態を理解するだけでなく、
現在の状態から未来の状態を予測するWorld Modelへと研究が広がっています。
つまり動画理解は、
「動画に何が映っているか」
から、
「世界が現在どのような状態にあり、どのように変化していくのか」
を理解する方向へ広がっていると考えることができます。
2.4 動画理解からVSSへ
ここまで見てきたように、動画理解では、
画像の理解
↓
空間＋時間の理解
↓
動画とLLMの接続
↓
動画の意味理解
という技術が発展してきました。
では、こうした技術を使って、実際の動画データに対して継続的に利用できるシステムとして構築するには、何が必要なのでしょうか。
そこで注目したいのが、NVIDIAが提供するVideo Search and Summarization（VSS）です。
3. NVIDIA VSSとは何か
3.1 VSSの概要
VSSは、単一のAIモデルというよりも、動画を分析する複数のAI・データベース・エージェントなどを組み合わせ、動画分析AIエージェントを構築するためのリファレンスアーキテクチャ／Blueprintとして提供されています。
NVIDIAの公式ドキュメントでも、VSSは「vision agents and AI-powered video analytics applications」を構築するための複数のリファレンスアーキテクチャとして説明されています。
VSSが興味深いのは、単純に
「動画を入力すると、AIが要約してくれる」
という仕組みだけではない点です。
動画からさまざまな情報を抽出し、それを後段の分析や検索に利用できる形へ変換し、最終的にはAgentを介して自然言語で扱えるところまでを、一連のシステムとして構成しています。
概念的には、次のような流れです。
動画
↓
動画から情報を抽出
↓
意味のある情報へ変換・構造化
↓
検索・分析可能な形で蓄積
↓
Agent / LLM
↓
自然言語で検索・質問・要約・分析
つまりVSSは、
「動画を理解するAI」だけではなく、「動画から得られた情報を、人間が後から利用できるようにするための一連の仕組み」
として捉えると分かりやすいのではないでしょうか。
3.2 VSSのアーキテクチャ
本節ではVSSのアーキテクチャをまとめす。
尚本記事では、VSSを構成する各マイクロサービスの内部実装や使用されているモデル・アルゴリズムの詳細には踏み込みません。
VSSは複数のAIモデルやサービスを組み合わせたBlueprintとして構成されているため、今回はそれぞれのコンポーネントが「どのような入力を受け、どのような情報を生成し、それが後段でどのように利用されるのか」というシステム全体のデータフローに着目します。
VSSは複数のマイクロサービスから構成されており、現在の公式ドキュメントでは、大きく以下の3つの領域に分けて説明されています。
- Real-Time Video Intelligence
- Downstream Analytics
- Agentic and Offline Processing
これらは、それぞれ、
動画から情報を取り出す → 取り出した情報を分析する → 人間が利用できる形にする
という役割を担っていると考えると理解しやすくなります。
① Real-Time Video Intelligence
まず動画から、AIが利用できる情報を抽出します。
VSSには本領域の代表的なマイクロサービスとして、
- RT-CV
- RT-Embedding
- RT-VLM
があります。
RT-CVは、物体検出や分類、物体追跡などを行い、物体の位置やID、時刻などの構造化された情報を生成します。
RT-Embeddingは、動画や画像などから意味的なEmbeddingを生成し、動画の検索や類似性の評価に利用できるようにします。
RT-VLMは、VLMを利用して動画から自然言語によるキャプションやイベント、状況などの意味情報を抽出します。
ここで重要なのは、一つの方法だけで動画を理解するのではないという点です。
RT-CV→ 物体・位置・追跡情報(構造的特徴)
RT-VLM→ 状況・イベント・キャプション
RT-Embedding→ 意味的な特徴
のように、異なる方法から動画を捉えることで、後段で利用できる情報を増やしていきます。
② Downstream Analytics
次に、動画から抽出された情報を組み合わせ、より高次の情報へ変換します。
例えば、RT-CVによって、
「作業者Aが時刻t1に位置P1にいた」
「時刻t2には位置P2に移動した」
という情報が得られたとします。
これらを時間的に追跡することで、
「作業者Aがどの方向に移動したのか」
「どの程度の速度で移動したのか」
「特定の領域に侵入したのか」
といった、より意味のある行動・イベントとして扱えるようになります。
VSSには本領域の代表的なマイクロサービスとして、
- Behavior Analytics
- Alerts Microservice
があります。
Behavior Analyticsは、物体の追跡情報などから速度、方向、軌跡などの行動指標を算出し、設定したルールに基づいてイベントを生成できます。
Alerts Microserviceは、発生したアラートに対応する動画区間を取得し、VLMによってそのアラートが実際に発生したものなのかを検証する仕組みも提供されています。
概念的には、
RT-CV / RT-VLM
↓
基礎的な情報
↓
Behavior Analytics
↓
高次のイベント
↓
Alert
↓
関連する動画を取得
↓
VLMで検証
↓
確認済み / 却下 / 未確認
という流れになります。
つまり、Downstream Analyticsは、動画から抽出された情報を組み合わせ、「何が起きたのか」というイベントレベルの情報へ変換する役割を担っています。
③ Agentic and Offline Processing
そして、ここまでで抽出・分析された情報を、最終的に人間が利用できる形へつなげるのが、Agentic and Offline Processingの領域です。
ここでは、動画検索、動画要約、質問応答、レポート生成などの処理が行われます。
現在のVSSでは、Agentが複数の動画分析機能をツールとして利用し、ユーザーの要求に応じて適切な処理を組み合わせる構成も提供されています。
ここで重要なのは、Agentが動画を最初から最後まで人間のように見直しているわけではないことです。
動画からあらかじめ抽出された情報やEmbedding、イベント情報などを利用して、必要な情報を検索し、関連する動画やデータを取得します。
そのうえでLLMが検索結果を利用して、ユーザーの質問に回答します。
ユーザーの質問
例 「昨日、部品を落とした作業を探して」
↓
Agent
↓
検索・Retrieval
↙ ↘
動画情報 イベント情報
↘ ↙
関連する動画・情報
↓
LLM
↓
自然言語で回答
このようにして、動画そのものではなく、動画から抽出された「意味のある情報」を検索・推論に利用することが可能になります。
3.3 動画検索・要約・質問応答の仕組み
ここまでの構成を見ると、VSSがどのようにして「動画を検索・要約できるのか」も見えてきます。
ポイントになるのは、動画をそのまま検索するのではなく、動画を分析して検索可能な情報へ変換しておくことです。
例えば長時間の動画を考えてみます。
1時間の動画を、そのままVLMに入力してすべてを理解させるのは容易ではありません。
そこでVSSでは、動画を一定の区間に分割し、それぞれの区間についてVLMによる分析を行います。
1時間の動画
↓
┌─────┬─────┬─────┬────┐
│Chunk│Chunk│Chunk│ ...│
└─────┴─────┴─────┴────┘
↓
各ChunkをVLMで分析
↓
キャプション・イベントなど
↓
検索・RAG用に蓄積
NVIDIAの説明では、長時間動画を小さなチャンクに分割してVLMで分析し、その結果をCA-RAGなどによって集約することで、動画全体の要約を生成する構成が紹介されています。
また、Graph-RAGでは動画中の物体やイベントなどの関係をKnowledge Graphとして扱い、質問応答などに利用します。
つまり、
動画 → チャンク → VLMによる理解 → 情報の蓄積 → Retrieval → LLM
という流れによって、長時間の動画でも検索や要約を行えるようにしています。
Vector DBとGraph DB
ここで重要になるのが、抽出した情報をどのように保存・検索するかです。
VSSでは、用途に応じてベクトル検索やグラフ構造を利用します。
Vector DBでは、Embeddingなどを利用して、意味的に近い情報を検索できます。
例えば、
「作業者が部品を落とした」
という検索に対して、完全に同じ文章が保存されていなくても、意味的に関連する動画や情報を検索できる可能性があります。
一方、Graph DBでは、
作業者A
↓
部品を持つ
↓
部品B
↓
落とす
↓
作業台
のように、動画中に存在する物体・人物・イベントなどの関係性を構造化して扱うことができます。
NVIDIAは、VSSの動画取り込み時にVLMによる情報を利用してKnowledge Graphを構築し、Graph-RAGによってLLMからその情報を検索できる構成を説明しています。
3.4 VSSの本質は「動画を検索できること」だけではない
ここまで見てくると、VSSの特徴が少し違って見えてきます。
もちろん、
- 動画を自然言語で検索する
- 動画を要約する
- 動画について質問する
- 特定のイベントを検出する
といった機能自体も非常に興味深いものです。
しかし、より重要なのは、その裏側にある
動画 → 多様な情報の抽出 → 情報の構造化・蓄積 → Retrieval → Agent / LLM
という一連の流れです。
VSSは、動画を単なる映像データとして扱うのではなく、動画から意味のある情報を抽出し、それを検索・分析可能なデータへ変換し、最終的にAgentを介して人間が利用できるようにするためのリファレンスアーキテクチャとして見ることができます。
この視点で見ると、VSSは単なる「動画検索AI」というより、
「動画理解AIを実際のシステムとして利用するための設計図」
と捉える方が、その特徴を理解しやすいのではないでしょうか。
4. 製造現場では何が変わり得るのか
VSSのような動画理解技術を製造現場に適用すると、何が変わるのでしょうか。
まず考えられるのは、作業動画を検索・振り返りのために活用することです。
例えば、
「昨日、○○工程で異常が発生した場面を探したい」
「この作業では何が起きていたのか確認したい」
といった要求を自然言語で入力し、関連する動画や場面を探すことができれば、これまで人が大量の映像を確認していた作業を効率化できる可能性があります。
また、動画の内容についてAgentと対話することで、
「この異常が発生する前に何が起きていた？」
「この作業では通常と異なる動作があった？」
といった問いから、トラブル発生時の状況を確認することも考えられます。
このような動画の検索・振り返りや、動画を利用した原因分析は、VSSの分かりやすい活用方法の一つです。
しかし、VSSを製造現場で活用するうえで、私がより重要だと感じているのは、こうした「動画を見るためのAI」にとどまらない点です。
4.1 動画を「製造データ」として扱う
製造現場では、これまでにもさまざまなデータが蓄積されてきました。
例えば、
- 製品情報
- 工程情報
- 設備情報
- 製造条件
- 品質データ
- 作業時間
- センサーデータ
などです。
これらは、後から検索・集計・分析できるように、データベースやログなどの形で管理されます。
一方、作業動画には、こうしたデータだけでは捉えにくい情報が含まれています。
例えば、
- 作業者がどのように動いたのか
- どのような物体を扱っていたのか
- ワークの状態がどのように変化したのか
- 設備や作業者の位置関係はどうだったのか
- いつ、どのようなイベントが発生したのか
といった情報です。
従来、こうした情報を利用するには、人が実際に動画を確認する必要がありました。
しかし、動画理解AIによって、動画から人物・物体・動作・状態・イベントなどの情報を抽出し、構造化して扱えるようになれば、動画は単なる映像ファイルでなく、製品情報や工程情報、設備情報、品質データなどと関連付けて扱えるデータとして利用できるようになります。
ここに、動画を製造DXに活用するうえでの重要なポイントがあります。
例えば
製品
├─ 製品情報
├─ 製造条件
└─ 品質データ
工程
├─ 工程情報
├─ 設備情報
└─ 作業時間
動画から抽出した情報
├─ 作業者
├─ ワーク
├─ 動作
├─ 状態
└─ イベント
といった情報を、全て紐付けて管理することが考えられます。
これにより動画は「必要なときに人が見るための記録」から、他の製造データと組み合わせて検索・分析できる情報源へと位置付けを変えると考えられます。
4.2 構造化された動画データをQCDS改善に活用する
ここまで見てきたように、動画から人物・物体・動作・状態・イベントなどの情報を抽出し、製造データとして扱えるようになると、動画の活用方法も変わってきます。
ポイントは、必要なときに動画を1本ずつ確認するだけではなく、動画から抽出した情報を大量のデータとして蓄積し、継続的に分析できることです。
例えば、ある工程で作業者の動作を継続的に分析するとします。
個々の動画を人が確認するのではなく、
作業動画
↓
動作・状態・イベントを抽出
↓
大量のデータとして蓄積
↓
工程・製品・作業者・設備などと関連付け
↓
統計的に分析
という流れを作ることで、
- どの工程で特定の動作が多く発生しているか
- 標準的な作業と異なる動作がどの程度発生しているか
- 不良が発生した製品群に共通する作業上の特徴はないか
- 作業時間や設備状態と、作業動作にどのような関係があるか
といった、個々の動画を見るだけでは把握しにくい傾向や相関を分析できる可能性があります。
さらに、動画から抽出した情報をリアルタイムに処理できれば、活用方法はさらに広がります。
例えば、
カメラ
↓
動画理解
↓
人物・物体・動作・状態を認識
↓
イベントを検出
↓
設備・製造条件などと組み合わせる
↓
リアルタイムで判断・通知
といった仕組みによって、
- 危険につながる状態の検知
- 標準作業からの逸脱の検知
- 設備やワークの異常状態の検知
- 工程の滞留や異常イベントの検知
などを、発生後の振り返りではなく、発生中に検知することも考えられます。
このように考えると、動画理解AIの価値は「動画を見る作業を効率化すること」だけではありません。
動画を構造化されたデータに変換することで、これまで映像として蓄積されていた情報を、大量データの分析やリアルタイムの現場判断に利用できる可能性があります。
4.3 動画データは将来のAI資産にもなり得る
そして、動画を製造データとして構造化して扱うことには、もう一つ意味があります。
それは、蓄積されたデータそのものが、将来のAI活用につながる可能性があることです。
重要なのは、動画そのものの蓄積ではなく、動画から抽出した意味情報と製造情報を組み合わせることで、現場の状況と製造結果との関係を分析できるデータにしていくことです。
こうしたデータを蓄積しておけば、
- AIによる製造プロセスの分析
- 異常や品質不良の予測
- 作業改善のためのAIモデル
- ロボットやVLAなどのフィジカルAI
- デジタルツイン上での現場再現・分析
など、より高度なAI活用につなげられる可能性があります。
どの動画が、どの製品・工程・設備・製造条件と関係しているのか。そして、動画からどのような意味情報を抽出できるのか。
こうした情報を構造化し、他の製造データと関連付けて蓄積することで、動画を将来のAI活用にもつながるデータ資産として捉えられるようになります。
5. おわりに
今回は、動画理解AIの基本的な考え方を整理したうえで、NVIDIAのVSSを例に、動画を製造現場でどのように活用できるのかを考えてきました。
VSSを調べる中で特に興味深いと感じたのは、動画の検索・要約そのものではなく、動画から得られる情報を製造データと結び付けることで、これまで十分に活用できていなかった「現場で何が起きていたのか」という情報を、製造DXに活用できる可能性です。
動画を単なる映像記録としてではなく、意味情報を抽出・構造化し、製品・工程・設備・品質などの製造データと関連付けて扱うことで、動画は現場を理解するためのデータ源になり得ます。
そして、そのように構造化されたデータの蓄積が、現在のQCDS改善だけでなく、将来のAI、フィジカルAI、デジタルツインなどにつながる可能性があります。
もちろん、目的のないデータ取得を推奨するわけではありません。しかしこうした構造化された製造データを継続的に蓄積し、活用できるかどうかが、今後の企業の競争力を左右する重要な要素になると考えます。