VLM on Physical AI Hub

ロボット視覚の語彙設計：オープンボキャブラリー認識とタスク限定認識の使い分け

Thu, 05 Nov 2026 15:22:58 +0900

語彙を広げるほどロボットが賢くなるのか、それとも判断を狭く保つことが安全につながるのかが、このテーマの出発点です。

結論

認識対象が頻繁に変わり、未知物体の発見や自然言語による対象指定が必要なら、オープンボキャブラリー認識を第一候補にする。一方、棚卸しSKUやピッキング対象が固定され、誤検出のコストと再現性が重い場合は、タスク限定認識を基本にするのが妥当だ。

安全性が必要なロボットでは、どちらか一方に任せるより、オープンボキャブラリー方式で候補を発見し、後段のタスク限定モデル、未知拒否、行動ゲートで検証する構成が現実的である。

なぜ語彙設計が重要か

ロボットの視覚認識では、画像中の物体を見つけるだけでは動作を決められない。検出結果が示すのは、主に対象の位置と、指定された語彙との一致である。把持可能性、向き、材質、危険性、作業手順への適合性まで自動的に確定するわけではない。

そのため、認識器の選択は既知クラスの精度だけで決められない。未知物体を誤って受け入れる割合、低信頼度入力を拒否したときのカバレッジ、信頼度の校正、推論遅延、メモリ使用量、カテゴリ追加コスト、最終的な行動成功率を分けて考える必要がある。

用語と仕組み

オープンボキャブラリー認識は、学習時に固定したクラスIDだけでなく、推論時にテキストクエリなどで指定した語彙の対象を認識・検出する方式である。画像と自然言語の対応を学習したモデルでは、テキストラベルを指定したゼロショット分類が可能になる。OWL-ViT、Grounding DINO、ViLDは、この考え方を物体検出へ適用する代表例である。

一方、タスク限定認識は、業務で扱う対象とラベル定義をあらかじめ限定し、その範囲で分類・検出する構成を指す。対象が固定されているなら、必要なクラス、属性、拒否条件を明確に設計しやすい。反復的なピッキングや固定SKUの棚卸しでは、語彙を広げることよりも、定義した対象を安定して扱うことが優先される。

なお、オープンボキャブラリー認識とオープンセット認識は同義ではない。前者は推論時に語彙を拡張・指定する能力であり、後者は既知クラス以外の未知入力を検出し、拒否または未知として扱う能力である。テキストで対象を指定できても、未知物体を必ず安全に拒否できるとは限らない。

オープンボキャブラリー方式の価値と限界

カテゴリ追加のたびに完全な教師データを用意しなくても、長い尾のカテゴリや自然言語で指定した対象を候補化できることが大きな利点である。事前に全カテゴリを列挙しにくい環境理解や、探索段階の棚卸しでは、対象語彙を後から変更できる柔軟性が役立つ。

ただし、ゼロショット性能は、プロンプトの表現、画像ドメイン、照明、視点、遮蔽、対象カテゴリの粒度に左右される。研究論文で示されたベンチマーク結果から、特定の現場でタスク限定モデルを上回ることや、未知物体を適切に拒否することを保証することはできない。同義語、階層カテゴリ、ブランド名、属性語の影響もモデルとデータセットに依存する。

タスク限定方式の価値と限界

対象の種類とラベル定義が安定し、同じ対象を反復して扱うなら、タスク限定認識は評価範囲を明確にしやすい。誤検出が停止、衝突、誤ピッキングにつながる場合には、対象外を受け入れない条件やクラス別しきい値を設けやすい点も有利である。

ただし、限定したモデルでも信頼度をそのまま成功確率として扱ってはいけない。ニューラルネットワークの予測信頼度は、実際の正解率と一致しないことがある。温度スケーリングなどの校正、クラス別しきい値、拒否領域の検証が必要になる。限定方式だから必ず高精度、とは言えない。

flowchart LR
  A["画像入力"] --> B["オープンボキャブラリー候補生成\nテキストクエリで対象を指定"]
  B --> C{"候補の信頼度と対象条件を確認"}
  C -->|"未知・低信頼度、または条件不一致"| D["拒否・再観測・人手確認"]
  C -->|"検証対象として受理"| E["タスク限定分類"]
  E --> F["属性・姿勢・把持可能性を検証"]
  F --> G{"信頼度と安全規則を確認"}
  G -->|"条件を満たす"| H["ロボット動作"]
  G -->|"条件を満たさない"| D

オープンボキャブラリー認識を候補発見に使い、タスク限定の検証と信頼度・安全規則による行動ゲートを後段に置く構成。

選択肢の比較

観点	オープンボキャブラリー認識	タスク限定認識	ハイブリッド構成
語彙	推論時にテキストなどで変更・追加	事前に対象を定義	発見は広く、検証は限定
向く場面	未知物体の探索、環境理解、変動するカテゴリ	固定SKU、反復ピッキング、固定部品	安全性と柔軟性を両立したい場面
未知物体	候補化できるが、未知拒否は別機能	対象外として定義しやすいが、未知発見は弱い	候補生成後に拒否・検証できる
データ追加	カテゴリ追加時の教師データ負担を抑えやすい	アノテーションや再学習が必要になりやすい	追加対象だけを段階的に検証できる
主な注意点	プロンプト、視点、照明、遮蔽への依存	校正不良、対象外の誤受理、語彙外への対応	段数増加による遅延と設計複雑化
評価	未知誤受理率、候補再現、拒否性能	既知精度、校正、拒否性能	最終行動成功率と各段の失敗率

実装での使い分け

探索フェーズでは、画像入力に対してテキストクエリを変えながら候補を生成し、未知または低信頼度の候補をそのまま行動へ渡さない構成が考えられる。運用フェーズでは、候補に対してタスク限定の分類、属性確認、姿勢推定、把持可能性判定を行い、最後に信頼度と安全規則による行動ゲートを置く。

ロボットの長期記憶アーキテクチャ：エピソード・意味・手続き記憶をどう設計するか

Mon, 26 Oct 2026 13:28:05 +0900

長時間タスクでは、記憶を増やすことより、記憶をどう疑いながら使うかが設計上の焦点になります。

先に結論

ロボットの長時間タスクでは、エピソード記憶・意味記憶・手続き記憶を、異なる役割を持つ層として分離する設計が妥当です。エピソード記憶は時系列の経験証拠、意味記憶は検証・抽象化された環境知識、手続き記憶は条件付きで再利用できるスキルを担当させます。

オンライン実行では、現在のタスクとセンサー情報から過去の記憶を検索し、現在の状態と照合してから手続きを選択します。実行結果は新しいエピソードとして保存し、反復的に確認された事実や、検証済みで再利用価値のある行動だけを上位の記憶へ昇格させます。過去の記憶を、現在の環境の代わりに無条件で使わないことが設計の基本です。

なぜ記憶を分けるのか

長時間タスクでは、過去の観測や成功した操作を再利用できると、毎回ゼロから推論する必要を減らせます。一方、全履歴をVLMやVLAのコンテキストに入れ続ける方法は、履歴の増加と検索負荷を招きます。MemGPTは、モデルの主要コンテキストと外部アーカイブ記憶を分離し、必要な情報を関数呼び出しで移動・検索する構成を示しました。ロボットでも、実行モデルと長期記憶を分ける際の参考になります。

ただし、3分類はロボット研究で統一された標準仕様ではありません。メモリーストリームと反省を中心に扱う構成や、コンテキストとアーカイブの階層を扱う構成もあります。ここでの3分類は、保存対象、検索条件、更新条件、実行系との接続を整理するための設計上の枠組みです。

3種類の記憶の役割

エピソード記憶：経験の証拠

エピソード記憶には、時刻、場所、対象、観測、行動、成否、環境からのフィードバックを、一つの経験ログとして保存します。現在と似た状況を探す用途に向きますが、検索結果をそのまま事実や命令として扱ってはいけません。現在の知覚と照合するための状況証拠として利用します。

検索キーは意味的な類似度だけでなく、場所、対象、タスク、時刻、成功履歴などを組み合わせます。Inner Monologueが示すように、物体検出やシーン状態、行動の成功・失敗を推論へ戻せば、実行中の計画を更新できます。

意味記憶：抽象化された知識

意味記憶には、複数の経験から抽象化された安定的な事実を保存します。物体と場所の関係、ユーザーや施設の好み、環境の制約などが対象です。個別の観測をそのまま蓄積するのではなく、再利用しやすい知識として扱います。

各項目には、出典、信頼度、有効期限を付与します。単一の観測だけで固定せず、反復確認や他の観測との整合性を経て更新する方針が適しています。必要な反復回数や信頼度のしきい値に、一般的な数値基準は確立していません。

手続き記憶：実行可能なスキル

手続き記憶には、再利用可能なスキル、プログラム、ポリシー、行動スキーマを保存します。前提条件、引数、期待効果、実行後の検証方法も併せて管理します。

Voyagerは、環境からのフィードバックを用いて、実行可能なコード形式のスキルを蓄積・再利用する構成を示しました。これは手続き記憶の実装例として解釈できます。ただし、未知の物体、照明、配置、摩擦条件へ安全に一般化できる範囲は、スキル表現とロボットに依存します。

読み出しと書き込みの流れ

flowchart LR
  A["現在のタスクとセンサー入力"] --> B["メモリールータ"]
  B --> C["エピソード記憶\n経験証拠"]
  B --> D["意味記憶\n制約・環境知識"]
  C --> E["現在の状態との照合"]
  D --> E
  E --> F["手続き記憶\n前提条件付きスキル"]
  F --> G["実行可能性の再検証"]
  G --> H["実行器"]
  H --> I["行動結果・新しい観測"]
  I --> C

現在の知覚を起点に過去の記憶を検索し、手続きを再検証して実行した結果をエピソード記憶へ保存する流れ。

読み出しでは、現在のタスクと知覚情報をメモリールータへ渡します。エピソード記憶から類似する経験を、意味記憶から関連する制約や環境知識を検索し、それらを条件として手続き記憶から候補スキルを選びます。

SayCanは、言語モデルによる行動選択と、ロボットが各スキルを実行できる可能性を表すアフォーダンスを組み合わせます。この考え方は、手続きの検索と実行可能性の検証を分ける設計に対応します。実行後は、成功・失敗や環境からのフィードバックを取得し、継続または再計画します。

書き込みでは、まず全試行をエピソードとして保存します。反復・整合性・信頼度を確認し、安定した事実を意味記憶へ、再利用価値と安全性を検証できた行動系列を手続き記憶へ昇格させます。

記憶層の比較

記憶	保存対象	検索キー	更新	実行系との接続
エピソード	観測・行動・結果・時刻・場所	類似状況、場所、対象、タスク	試行ごとに保存	状況証拠として提供
意味	事実、関係、制約、好み	対象、場所、関係、制約	反復確認後に更新	手続き選択の条件
手続き	スキル、プログラム、ポリシー	タスク、前提条件、実行可能性	検証済みのものを登録	実行器へ渡すが再検証する

環境再訪での判断基準

再訪時は、場所・対象・タスクで候補を検索し、時刻、位置、信頼度、有効期限で絞り込みます。その後、現在のセンサー情報や状態推定と照合します。整合すれば手続きを候補にできますが、過去の成功履歴だけで実行を確定してはいけません。不一致なら、再観測や再計画へ分岐させます。

ロボット視覚の分布外検知：未知物体を見つけて安全に行動を保留する設計

Sun, 04 Oct 2026 14:37:40 +0900

未知物体を見つけることと、ロボットを安全に止めることは、同じ判定ではありません。この違いが設計の分かれ目です。

結論

ロボットの視覚認識で未知物体や分布外（OOD）入力を扱うには、最大ソフトマックス確率だけで行動可否を決めてはいけません。分類信頼度、OODスコア、物体の位置推定品質、モデル間の不一致、センサ健全性、フレーム間の一貫性を組み合わせた受理ゲートを設け、条件を満たさない入力は行動系へ渡さず、明示的なsafe-hold状態へ送る設計が現実的です。

safe-holdでは、状況に応じて停止または減速し、再観測、再計画、人間確認などへ切り替えます。閾値は一般的な固定値ではなく、危険な誤受理を重く扱うリスク・カバレッジ評価と、照明、遮蔽、反射、モーションブラー、センサ欠損を含む実機シナリオで決める必要があります。

なぜ未知入力への備えが必要か

OOD検知は、学習時のデータ分布から外れた入力を検出する問題です。一方、オープンセット認識は、テスト時に学習時には存在しなかった未知クラスを扱う問題として整理できます。既知クラスの精度が高くても、実環境で未知物体を既知クラスの一つとして誤認すれば、把持や進入などの行動に誤った前提を渡す可能性があります。

ただし、未知物体であること自体が物理的危険を意味するわけではありません。反対に、既知クラスでも遮蔽、異常姿勢、反射、ブラー、センサ故障によって危険な認識が生じる場合があります。そのため、OOD検知は安全性全体の判定器ではなく、視覚認識パイプラインの一つの警告信号として扱います。

信頼度とOODスコアの前提

最大ソフトマックス確率は、誤分類例やOOD例を検出する低コストなベースラインです。しかし、その値を正しさや安全性の確率として直接解釈することはできません。深層モデルでは、予測確率と実際の正解率が一致しない校正不良が起こり得るためです。必要に応じて校正を検討しても、分布シフト下で安全な確信度が保証されるわけではありません。

候補となる方法には、特徴空間での距離、クラス条件付き分布からのMahalanobis距離、複数モデルの予測分散を利用する深層アンサンブルがあります。手法ごとに検出しやすい分布外入力が異なり、画像分類、物体検出、敵対的入力、実環境のセンサ劣化を横断して論文上の数値を直接比較することはできません。

ロボットでは画像全体のOOD判定だけで不十分な場合があります。未知物体が画面の一部にあるなら、その領域を局所化し、既知物体と未知物体を区別するオープンワールド物体検出が必要です。物体検出の信頼度が低い、位置が不安定、未知領域が行動経路に重なる、といった情報を行動判断へ渡せる形にします。

flowchart LR
  A["カメラなどのセンサ入力"] --> B["物体検出・分類"]
  B --> C["物体クラス・位置・物体性・検出信頼度"]
  C --> D["OOD・不確実性の評価"]
  D --> D1["最大確率・校正済み信頼度"]
  D --> D2["特徴距離"]
  D --> D3["モデル間の予測ばらつき"]
  C --> E["未知物体の領域・局所化"]
  A --> F["センサ健全性の確認"]
  B --> G["フレーム間の位置・クラスの一貫性"]
  D1 --> H["多段の受理ゲート"]
  D2 --> H
  D3 --> H
  E --> H
  F --> H
  G --> H
  H -->|"条件を満たす"| I["行動計画へ渡す"]
  H -->|"条件を満たさない"| J["safe-hold"]
  J --> J1["停止または減速"]
  J --> J2["再観測・再計画"]
  J --> J3["人間確認"]

視覚認識の出力を直接アクチュエータへ接続せず、複数の信号を受理ゲートで確認してから行動またはsafe-holdへ分岐させる。

受理ゲートの構成

実装では、認識器の出力をそのままアクチュエータへ接続せず、次のような多段ゲートを置きます。

自然言語からロボット行動へ：3Dグラウンディングと実行制約の設計

Mon, 28 Sep 2026 14:09:11 +0900

自然言語の「右側」や「隣」が、ロボットにとってどの座標と距離を意味するのかが気になるテーマです。

先に結論

ロボットに自然言語を直接モータ指令として渡すのは適切ではありません。「赤い箱を棚の右側へ置く」のような指示は、対象物、参照表現、空間関係、3D目標、座標系、許容誤差、動作前提、禁止条件、完了条件へ分解し、構造化された中間表現に変換するべきです。

VLMやLLMは、指示の意味解釈や操作候補の生成に使います。一方、実行前には物体の再同定、座標変換、到達可能性、衝突、視認性、把持可能性などを別の検証段階で確認します。意味の確信度が高くても、3D測位や軌道計画が成立するとは限りません。不確実性が大きければ、実行せずに確認質問、追加観測、再計画へ切り替える構成が基本になります。

なぜ3Dグラウンディングが必要か

自然言語には、ロボットがそのまま利用できる座標が含まれていません。「右側」は何を基準にした右側か、「隣」はどの距離までか、「それ」はどの物体を指すのかを決める必要があります。さらに、対象を認識できても、把持姿勢やアームの可動範囲、周囲の障害物を考慮しなければ行動には変換できません。

3D-LLMやSpatialVLM系の研究は、3Dシーン理解、視覚グラウンディング、物体間の距離や方向、相対位置の推論を扱います。ただし、3D上の参照対象を得られることは、安全な軌道や実行可能な把持姿勢を得たことと同じではありません。空間推論の評価結果を、そのまま実機操作の成功や安全性として扱うこともできません。

中間表現に含める情報

実装上は、言語理解の結果を一つの曖昧な文字列として保持せず、次の情報を分けて管理します。

対象物の同一性、検出された物体の候補、参照表現
「右側」「隣」などの空間関係と、その基準となる物体・座標系
目標となる3D位置、3D領域、または物体姿勢
許容誤差、把持や配置に必要な動作前提、禁止条件
言語解釈の確信度、対象同定の確信度、3D測位の不確実性
完了条件と、条件を満たさなかった場合の再計画方針

これは業界標準として確立した形式ではありません。実際にはロボット、センサ、タスクに合わせて設計する必要があります。重要なのは、意味解釈、幾何情報、実行可否を分離し、どの段階で不確実性が生じたかを追跡できることです。

変換の仕組み

処理は、おおむね次の段階に分けられます。まずVLMやLLMが、指示から対象物、操作、空間関係、候補となるスキル列を生成します。SayCanは、LLMによる言語的なタスク分解に、現在のロボット状態で各スキルを実行できるかを示すアフォーダンス値を組み合わせる方式です。言語的にもっとも自然な手順ではなく、環境で実行可能な候補を選ぶ点に意味があります。

次に、画像、点群、深度、ロボット状態などから作られた3Dシーンへ、対象と関係を接地します。VoxPoserは、物体や空間関係を3Dボクセル上の価値マップとして表現し、複数の価値マップを合成して操作や経路計画へ利用する枠組みを示しています。3D目標を一点だけでなく領域や価値として持てるため、配置や経路の条件を計画器へ渡しやすくなります。

その後、カメラ座標系などで得た情報をロボット基準の座標系へ変換し、目標位置・姿勢と動作条件を検証します。到達できるか、衝突しないか、対象を視認し続けられるか、把持できるか、速度や力の制約を満たすかを確認してから、モーションプランナーへ渡します。実行中も観測を更新し、状態が想定から外れれば停止、再観測、再計画へ分岐させます。

flowchart LR
  A["自然言語指示"] --> B["対象物・操作・空間関係・スキル候補の生成"]
  B --> C["候補集合の作成と参照表現の解決"]
  C --> D{"対象が一意か"}
  D -- "いいえ" --> Q["確認質問または追加観測"]
  Q --> C
  D -- "はい" --> E["3Dシーンへグラウンディング"]
  E --> F["構造化中間表現の生成"]
  F --> F1["対象・基準物体・座標系・3D目標・許容誤差・禁止条件"]
  F1 --> G["座標変換と状態統合"]
  G --> H["到達可能性・衝突・視認性・把持・速度・力の検証"]
  H --> I{"実行条件を満たすか"}
  I -- "いいえ" --> R["停止・再観測・再計画"]
  R --> E
  I -- "はい" --> J["モーション計画"]
  J --> K["ロボット実行"]
  K --> L["実行中の観測更新"]
  L --> M{"完了条件を満たすか"}
  M -- "はい" --> N["完了"]
  M -- "いいえ" --> R

言語モデルの出力を直接モータ指令に接続せず、3D目標と実行制約を検証してからロボットへ渡す処理の流れ。

参照表現は候補集合として扱う

「赤い箱の隣」「それを持ち上げて」のような表現を、最初から単一の物体へ決め打ちするのは危険です。検出された物体、過去の行動履歴、3Dシーン内の空間関係を使って候補集合を作り、候補が一意になるかを確認します。

不確実性を扱うロボット把持計画：成功確率に応じて実行と再観測を切り替える

Sun, 23 Aug 2026 01:51:41 +0900

把持の「自信あり」という数値が、実際の成功確率と同じ意味を持つのかが気になるテーマです。

はじめに

ロボットが物体を正しく認識できたように見えても、その把持が成功するとは限りません。姿勢推定の誤差、隠れた形状、摩擦や接触状態のばらつき、照明や視点の変化が、実行結果を左右します。ここで必要なのは、認識モデルのスコアを単純なしきい値で分類することではなく、「いま動く価値があるか」「追加観測で判断が改善するか」「安全のために中止すべきか」を分けて決める層です。

先に結論

把持計画では、生の把持スコアを成功確率として扱わず、対象・センサー・把持条件に合わせて校正した確率と、別々に評価した不確実性・安全信号を使います。実行、再観測、中止の切り替えは、成功確率だけでなく、成功時の価値、失敗や破損の損失、追加観測の時間・移動リスク、ロボットや周辺設備への安全リスクを含む期待効用、または明示的なリスク制約で設計します。

さらに、実行後も視覚などの観測で把持状態を検証し、必要なら再計画します。固定しきい値は実装の出発点にはなりますが、対象の価値やサイクルタイム、安全条件が異なる環境にそのまま移植できる普遍的なしきい値は確認されていません。

なぜ単一の信頼度では足りないのか

把持モデルの出力は、訓練データ、センサー、把持品質の定義、対象分布に依存するモデル出力です。たとえば解析的な把持品質指標から学習した予測値と、行動選択や方策価値を直接学習した出力では、数値が似ていても意味は同じではありません。高いスコアを「実際の成功確率」と解釈するには、別途検証が必要です。

また、不確実性には少なくとも二つの側面があります。観測ノイズや接触ばらつきのように、データ自体に固有の aleatoric uncertainty と、データ不足やモデルの知識不足に由来する epistemic uncertainty です。前者は同じ条件でも結果が揺れる要因、後者は未知の対象や条件に出会ったときに予測が不安定になる要因と考えられます。対応策が異なるため、合計値だけでなく内訳を保持する設計が有用です。

belief として状態を保持する

部分的にしか観測できない物体姿勢、形状、接触状態、摩擦などを、単一の推定値だけで表すと、計画は誤った前提に固定されます。そこで、状態についての信念、すなわち belief として候補や確率分布を保持し、行動と観測によって更新します。把持計画と観測計画を同じ枠組みで扱えば、把持を急ぐべきか、別の視点から見直すべきかを比較できます。

ただし、完全な belief-space 計画は計算量やモデル化の負担が大きくなります。実機では、候補生成、校正、実行ゲート、監視、検証、再計画、中止を状態機械として分離し、必要な範囲で近似する構成が扱いやすいでしょう。

確率校正と分布ずれの確認

意思決定に確率を使うなら、検証用データで校正します。予測確率をいくつかの信頼度ビンに分け、各ビンの平均予測値と実際の成功率を比較する reliability diagram を確認します。ECE や Brier score も、確率の整合性を評価する指標になります。分類精度が高くても、予測確率が実際の成功率と一致するとは限らないためです。

校正データは、学習時と同じ分布だけでなく、実行時に想定される対象、照明、視点、センサー、把持条件を含めて評価します。分布外やデータシフト下では不確実性の品質が変化し、アンサンブル、ベイズ近似、校正手法のいずれかが常に優れるとは限りません。校正済みの値であっても、安全リスクを十分に表すとは限らない点にも注意が必要です。

flowchart TD
  A["観測・状態推定"] --> B["把持候補を生成"]
  B --> C["成功確率を校正し、不確実性を分離"]
  C --> D["期待効用と安全制約を評価"]
  D --> E{"安全制約を満たすか"}
  E -- "いいえ" --> X["中止・退避"]
  E -- "はい" --> F{"追加観測で判断が改善する見込みがあるか"}
  F -- "はい" --> G["再観測"]
  G --> A
  F -- "いいえ" --> H{"実行の期待効用が許容範囲か"}
  H -- "いいえ" --> X
  H -- "はい" --> I["把持を実行"]
  I --> J["実行中の観測と状態監視"]
  J --> K["把持状態を検証"]
  K --> L{"検証に成功したか"}
  L -- "はい" --> M["完了"]
  L -- "いいえ" --> N{"別候補や別経路に価値があるか"}
  N -- "はい" --> O["再計画"]
  O --> A
  N -- "いいえ" --> X

把持候補の評価から再観測、実行、実行後の検証、再計画、中止・退避までを状態機械として示す。成功予測と安全制約は別々の判断信号として扱う。

実行・再観測・中止の判断

候補ごとに、校正済み成功確率、二種類の不確実性、把持余裕、接触や衝突に関する安全信号をまとめます。そのうえで、候補を実行したときの成功時の価値から、失敗・破損・落下・設備損傷などの損失を差し引きます。再観測については、観測によって候補順位や安全判定が変わる見込みと、観測時間、移動リスク、処理コストを比較します。これは「信頼度が低ければ必ず見る」という規則ではありません。

Jetson上でVLMと物体検出を組み合わせる推論パイプライン設計

Mon, 05 Jan 2026 23:57:34 +0900

JetsonでVLMを使うとき、毎フレーム処理させるべきか、それとも役割を分けるべきかが設計上の分岐点になります。

先に結論

Jetsonでカメラ認識システムを構築するなら、物体検出モデルを高頻度で動かす一次視覚ループ、VLMを必要時だけ呼び出す二次推論ループとして分離するのが基本です。検出器は物体の位置、既知クラス、信頼度、追跡情報を継続的に供給し、VLMは未知物体の説明、属性や関係性の解釈、自然言語による確認を担当します。

VLMを毎フレーム実行すると計算量やメモリ使用量、レイテンシが増えやすくなります。一方、検出器だけでは説明や文脈理解が難しい場合があります。両者を同期処理で直列化するのではなく、検出器とトラッカーを継続させたままVLMを非同期実行することが、リアルタイム性と柔軟な認識を両立する判断になります。

なぜ分担が必要なのか

物体検出器は、既知クラスについて画像中の位置、クラス、信頼度を取得する処理に向きます。ロボットが周囲の物体を追跡し、制御系へ一定間隔で位置情報を渡す用途では、検出器を一次ループに置くのが自然です。

VLMは画像と言語を組み合わせ、画像の説明、質問応答、属性理解、物体間の関係性の解釈などを扱います。したがって、両者は完全な代替ではなく補完関係です。ただし、テキストでカテゴリを指定するオープンセット検出器もあるため、境界は固定的ではありません。必要な出力が「どこに何があるか」なのか、「どのような状態で、何と関係しているか」なのかを先に分けます。

基本用語と内部の仕組み

一次ループは、カメラ入力から前処理、物体検出、トラッキングまでを高頻度で処理する経路です。ここで座標、クラス、信頼度、追跡ID、時刻情報を更新します。二次ループは、一次ループが発生させたイベントを契機に、VLMへ画像と質問や指示文を渡す経路です。

呼び出し条件には、検出信頼度の低下、未知クラス候補、属性や関係性の確認要求、シーン変化、一定間隔の再評価を使えます。毎フレームではなく、不確実性や変化が生じたときに実行することで、VLMの処理量を抑えられます。

VLMへは毎回フルフレームを渡す必要はありません。検出器が得たROI、クラス候補、信頼度、追跡ID、時刻情報を優先し、周囲との位置関係など空間的文脈が必要な場合だけフルフレームを追加します。ROIは対象を絞れますが、周辺情報を失う可能性があるため、質問の内容に応じて切り替えます。

flowchart LR
  A["カメラ入力"] --> B["前処理"] --> C["物体検出"] --> D["トラッカー"]
  D --> E["検出メタデータ更新\n座標・クラス・信頼度・追跡ID・時刻"]
  E --> F["結果統合"]
  E --> G["イベント判定"]
  G --> G1["信頼度低下・未知物体候補\n属性や関係性の確認・シーン変化"]
  G1 --> H["非同期キュー"]
  E --> I["ROI・クラス候補・信頼度\n追跡ID・時刻情報"]
  A -. "空間的文脈が必要な場合" .-> J["フルフレーム"]
  I --> H
  J --> H
  H --> K["VLM推論\n画像またはROI＋質問・指示文"]
  K --> L["VLM結果をメタデータとして追加"]
  L --> F
  F --> M["安全監視"] --> N["制御系・状況理解・オペレーター向け情報"]
  D -. "VLM処理中も継続動作" .-> E

物体検出器とトラッカーを高頻度で継続動作させ、イベント発生時だけVLMを非同期実行する構成。VLMの出力は検出結果を置き換えず、メタデータとして統合します。

VLMの結果は検出結果を置き換えるのではなく、メタデータとして統合する設計が扱いやすいでしょう。VLM処理中も検出器とトラッカーを動かします。DeepStreamのようなGStreamerベースの基盤では、映像入力、前処理、推論、トラッキング、メタデータ処理を接続できます。キューで検出経路とVLM経路を分離すれば、VLMの遅延が検出器や制御系を停止させにくくなります。ただし、特定のVLMプラグインが標準提供されることや、VLMを毎フレーム処理できることを意味しません。