NVIDIA FOX Blueprint の小売店版を VSS Skills と Hermes Agent で考えてみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
前回、NVIDIA Factory Operations Blueprint、通称 FOX を 1 ライン・1 カメラ・1 ユースケースまで小さく切り出して始める「Mini-FOX」という整理を書きました。
FOX は製造業向けの大規模 AI Blueprint で、想定ハードウェアは DGX Station 級です。そこを 1 ラインに縮めて、DGX Spark、PC、Jetson、AWS で組み合わせて始める、という整理でした。書き終わったあとに思ったのが、この発想は工場以外にもそのまま当てはまりそうだな、ということです。
特にスーパーマーケットの店舗運営は、長時間の映像を毎日確認し続けるのが難しい、という意味で工場と似た悩みを持ちますね。棚薄、補充の遅れ、レジ前の混雑、通路に残った台車。POS や在庫データだけでは見えにくい状況が映像の中に積もっていて、それを店長や SV が全部見返すのは、現実にはかなり厳しいです。
この記事では、Mini-FOX の発想を小売店舗に当てはめた「Mini-Retail FOX」という整理を考えてみます。reasoning と自然言語インターフェイスの中核には、NVIDIA 公式の VSS Skills と Hermes Agent の組み合わせを置いてみます。
FOX を小売店舗に置き換えるとどう見えるか
ここからが本題です。
FOX は、工場の機械信号、品質システム、作業手順、運用アラートを統合し、ファクトリーマネージャー AI が専門エージェントや機械をオーケストレーションするリファレンス設計でした。「現場の頭脳」が中央にいて、その下に安全、品質、保全、稼働などのドメイン専門エージェントがぶら下がる構造です。
これを小売店舗に置き換えると、ファクトリーマネージャー AI に相当するのが「店舗運営支援 AI」になりそうです。店舗運営支援 AI の周りに、棚薄や補充を見るエージェント、レジ前の混雑を見るエージェント、通路と動線を見るエージェント、日次レポートを書くエージェントがいて、店長や SV の判断を補助する、というイメージですね。
工場と小売の間で、扱うイベントの粒度はそれなりに違います。工場では機械信号や手順逸脱が中心になりますが、小売では映像と販売データから読み取る「人と棚の状態変化」が中心になります。一方で、「現場の頭脳が長尺データを横断的に見渡し、人が確認すべき候補に絞って渡す」という発想は、どちらにも素直に当てはまります。
工場向けの FOX をそのまま小売店舗に置けるか、というとそうではありません。FOX 公式の構成はかなり重たく、いきなり全店舗・全カメラを対象にしようとすると、PoC として動き出す前に止まってしまう可能性が高いです。そこで Mini-FOX と同じく、まずは小さく切り出して考えます。
いきなり店舗全体を狙わず Mini-Retail FOX として切り出す
Mini-FOX を「フル装備版 FOX のお試し版」と呼んだのと同じ立て付けで、Mini-Retail FOX は「店舗運営支援 AI のお試し版」として整理します。1 店舗、1〜数台のカメラ、1 つのユースケースから始める、という形です。
FOX を小売店舗向けに縮めた対応関係を、ざっくり並べておきます。
| FOX の構成 | Mini-Retail FOX での始め方 |
|---|---|
| 工場全体の Factory Manager Agent | 1 店舗向けの軽量 Store Supervisor Agent |
| 多数の専門エージェント | shelf、flow、checkout、report など 3〜5 個に絞る |
| DGX Station 上の大規模ローカル推論 | DGX Spark、PC GPU、AWS Bedrock、EC2 GPU に分散する |
| Operational twin | 店舗イベントタイムラインと簡易ダッシュボードから始める |
| 自動再学習と本番反映 | 店長・SV の人間レビュー付きの再学習候補キューに留める |
個人的には、この切り出し方が小売でも一番現実的かなと思っています。店舗向け AI は「全部繋ぐ」よりも、本当に困っている 1 つの場面を拾えるかどうかが最初の壁になるからです。最初から棚薄、混雑、通路、安全、販促効果まで並列に取りに行くと、運用とデータ準備の難易度が一気に跳ね上がりますね。
Mini-Retail FOX の最小構成はイベント化から
Mini-Retail FOX の最小構成も、Mini-FOX とほぼ同じ流れになります。映像をそのまま VLM に投げず、エッジで間引いてイベントにしてから、LLM や VLM の reasoning に渡します。雰囲気をつかむために、全体図を置いておきます。
ここで強調しておきたいのが、全フレームを VLM に投げない、という点です。営業時間中の店舗映像をそのまま VLM に流し込むと、推論コストも帯域もすぐに苦しくなります。まずはエッジで間引き、軽量検出やルール判定で「ここは確認候補かもしれない」というフレームだけをイベント化して、そのイベントに対して LLM や VLM が状況説明、確認観点、推奨アクションを返す、という流れにします。
店舗イベント JSON の具体イメージとして、夕方の飲料棚で棚薄候補が出た例を置いておきます。検出器の出力と簡単なルール判定の結果をそのまま JSON に整えて、reasoning 側に渡すイメージです。
{
"timestamp": "2026-06-17T16:20:30+09:00",
"store_id": "store-01",
"camera_id": "store-01-beverage-aisle-01",
"location": "飲料棚",
"event_type": "shelf_low_candidate",
"confidence": 0.78,
"frame_uri": "s3://example-bucket/events/2026/06/17/store-01/frame-001.jpg",
"detected_state": ["partial_empty_section"],
"rule_triggered": "low_shelf_density_over_60s",
"llm_summary": "飲料棚の右側で商品が少なく見える状態が約 60 秒続いています。",
"recommended_action": "夕方ピーク前の補充タイミング確認候補として店長に共有してください。",
"human_feedback": null
}
このくらいの粒度で残しておくと、後から人間レビューの結果を human_feedback に書き込めて、再学習のためのデータセットとしても使えます。最初から細かいスキーマを決め切らなくても、timestamp、store_id、camera_id、event_type、frame_uri、llm_summary、human_feedback あたりが揃っていれば十分かなと思います。
もうひとつ大事なのが、ここで生のイベントをそのまま店長や SV のレビュー UI に流さない、という点です。検出器とルール判定だけを通すと、補充作業中の台車、品出し直後の整列待ち、瞬間的な行列など、業務上は問題ない場面まで「候補」として上がってきてしまいます。レビュー UI に流す前に、生イベントを束ねて重複を消し、業務上問題のない種別をルールや軽量 VLM で落とす「キュレーション層」を 1 段挟んでおくと、レビュー側の体験がずいぶん変わります。届くアラートが 1 日 200 件と 1 日 5 件では、店長や SV の使い方はだいぶ変わってきますね。
NVIDIA 公式 VSS Skills を引き出しとして並べる
Mini-Retail FOX の reasoning 側を組むときに、いちから VSS 連携を作る必要はありません。NVIDIA 公式の NVIDIA-AI-Blueprints/video-search-and-summarization リポジトリ配下に、agentskills.io 仕様準拠の VSS Skills が 10 個公開されています。エージェント側にこの Skills を配るだけで、自然言語で VSS の API を叩けるようになります。
VSS Skills の構造を一段引いて整理すると、Skills は「使う側のインターフェイス」、VSS Developer Profile は「VSS をどう走らせるか」の 2 層構造になっています。エージェントから見ると、Skills は引き出しの取っ手で、VSS Profile は引き出しの中身、という関係です。
公式 Skills は全部で 10 個ありますが、小売店舗の Mini-Retail FOX で最初に触りたいのは、その中の 5 個くらいに絞れます。
| Skill | 主に組み合わせる Profile | 小売店舗での使いどころ |
|---|---|---|
video-search |
search |
棚薄、補充、混雑、台車放置など、自然言語クエリで該当場面を検索する |
video-understanding |
base |
候補場面に対して「ここで何が起きているか」を Q&A 形式で確認する |
alerts |
alerts (verification) / (VLM) |
通路ふさがりや安全確認候補のアラート管理、CV と VLM 検証の組み合わせ |
report |
用途に応じて | 日次・週次の店舗運営レポートを /generate エンドポイントで生成する |
rt-vlm |
alerts (VLM) |
ライブ映像への caption / alert、将来のリアルタイム監視・記録に発展させる |
Skills と Profile はあくまで「引き出しの取っ手と中身」の関係なので、表の対応はよく一緒に動かす組み合わせの目安です。実際の運用では、report のように Profile を選ばずに使う Skill もあれば、alerts のように複数の Profile と組み合わせて使う Skill もあります。
インストール手順も難しくありません。NVIDIA Developer Blog の解説によると、エージェントに自然言語プロンプトを 1 つ投げるだけで、Skill フォルダごとシンボリックリンクで ~/.claude/skills/<name>/ や ~/.codex/skills/<name>/ に張ってくれます。エージェント固有のパスを持たない汎用ホスト向けには agentskills.io 仕様の ~/.agents/skills/<name>/ も用意されていて、シンボリックリンク方式なのでリポジトリ側で git pull すれば、全エージェントの Skill が同時に最新化される設計です。
VSS Skills を自前で実装し直すのは、Mini-Retail FOX の最初の段階ではやらないでよさそうです。公式 Skills の範囲内で「店舗ユースケースに刺さりそうな引き出しを引く」ところから始めると、PoC の立ち上がりが格段に楽になります。
Hermes Agent を自然言語インターフェイスに置く
VSS Skills を呼ぶエージェント側として、ここでは Hermes Agent を置いてみます。Hermes Agent については、NemoHermes 連載で DGX Spark の OpenShell サンドボックスに載せて使うパターンを書いてきました。
Hermes Agent を Mini-Retail FOX の自然言語インターフェイスに置くと、店長や SV からの問い合わせを Hermes が受け、必要な VSS Skill を選んで VSS Profile に投げ、結果を再構成して返す、という流れが組めます。OpenShell サンドボックスの中で動かす形にしておけば、VSS 連携で必要なネットワーク許可、credential、サンドボックス境界の運用も、NemoHermes 連載で押さえた構成をそのまま流用できますね。
Hermes Agent は Profile という単位で人格と役割を分けられます。Mini-Retail FOX 向けに役割分担を例示すると、こんなイメージです。
| Profile | 役割 |
|---|---|
| Store Ops | 店長・SV からの自然言語問い合わせを受けて、VSS Skill を選んで叩く |
| Night Report | 営業時間終了後にバッチで日次レポートを生成し、Slack や日報に流す |
| Triage | 来店者対話やキャンペーン系の問い合わせを店舗業務系から振り分けて捌く |
VSS Skills のインストール先は、Hermes Agent を OpenShell サンドボックスの中に置く構成なら、サンドボックス内で NemoClaw か OpenClaw 経由で ~/.openclaw/workspace/skills/ や ~/.agents/skills/ に展開する形が素直です。Hermes Agent は agentskills.io 仕様の汎用パスを参照できるため、エージェント固有の置き場所を増やさずに、Codex や Claude Code との間で Skill を共有できます。
体験のイメージとして、店長が Hermes Agent に話しかける場面を 1 つだけ書いておきます。実際の運用では、Slack や店内チャットツール、簡易 Web UI など、店舗側の使い慣れた接点から投げられるようにしておく形になりそうです。
[店長]
昨日の 15:00〜19:00 の店舗映像から、店舗運営上気になりそうな場面を 5 件に絞ってください。
特に、商品が少なく見える棚、補充作業の有無、レジ前の混雑、通路をふさいでいる台車を見てください。
[Hermes Agent]
確認候補を 5 件抽出しました。
1. 16:20 飲料棚
一部の商品が少なく見える状態です。補充タイミング確認候補です。
2. 16:37 飲料棚
スタッフが台車で接近し、補充作業を行っているように見えます。
3. 17:45 レジ前
複数人の待機列が形成されているように見えます。応援レジ基準の確認候補です。
4. 18:10 通路
台車または作業物が通路中央付近に残っています。通路確保ルールの確認候補です。
5. 18:30 売場前
顧客が棚前で立ち止まっているように見えます。商品探索性の確認候補です。
各候補には根拠フレームを添付しています。確認したい候補があれば「3 番の根拠を見せて」のように指示してください。
ポイントは、Hermes Agent が「自動判定して指示を返す」のではなく、「人が確認すべき候補に絞って、根拠と一緒に渡す」立ち位置に留まっている点です。Mini-Retail FOX を立ち上げる初期段階では、ここを踏み外さないほうが現場の納得感を得やすいかなと思っています。
ここまでで、エージェント、VSS Skills、VSS Profile という Mini-Retail FOX の構成要素が一通り並びました。次は、これを実際にどのハードウェアとサービスに乗せるか、3 つの構成案で並べて見ていきます。
構成案 A は DGX Spark と Hermes でローカルに寄せる
最初の構成案は、店舗内または店舗近隣のサーバールームに DGX Spark を 1 台置いて、その上で VSS の search profile と Hermes Agent を動かす形です。映像を店舗の外に出したくない、社内ネットワークの中で完結させたい、という要件があるときに馴染みやすい構成です。
この構成の良いところは、店舗映像をローカルに留めたまま NVIDIA スタックの雰囲気を出せる点です。Cosmos 系 VLM、Nemotron 系 LLM、VSS Skills、Hermes Agent といった既存の DGX Spark 検証資産がそのまま積み上がりますし、現場側に「映像はあくまで店舗の中にあります」と説明しやすくなります。
一方で、注意点もあります。DGX Spark 1 台でカメラ台数を増やしたり、長尺映像を常時走らせたりすると、GPU メモリと推論コストがすぐ天井に当たります。Mini-Retail FOX の最初の段階では、1 店舗、1〜3 台のカメラ、1 つのユースケースに絞って組むほうが現実的かなと思っています。スケールアウトの話は、PoC で見えるものが出てきてからで十分です。
構成案 B は PC で軽量検出、reasoning をクラウドに分ける
DGX Spark を入れる前提が難しい場合や、店舗側のハードウェアを極力軽くしたい場合は、エッジとクラウドで役割を分ける構成が現実的です。店舗側は小型 PC で映像取得と軽量検出だけを担い、reasoning はクラウドの LLM や VLM に渡します。
考え方としては、通常時の映像を送り続けるのではなく、異常候補の前後にあたる代表フレームや短いクリップだけをクラウドに送る、という方針になります。帯域、コスト、プライバシーのバランスが取りやすくなりますし、PoC の段階でクラウド請求書が思っていた以上に膨らむ事故も避けやすいです。
役割分担のイメージを、エッジ側とクラウド側で並べておきます。
| 役割 | 店舗側の PC | クラウド |
|---|---|---|
| 映像取得 | RTSP 取得、フレーム間引き | 原則なし |
| 軽量判定 | 棚薄ルール、レジ前混雑カウント、滞留検知 | 原則なし |
| Reasoning | ルール出力をイベント JSON 化 | VSS Skills + Bedrock / OpenAI 互換 API |
| 保存 | 短期キャッシュ | S3、DynamoDB、OpenSearch |
| 通知 | ローカル警告灯、店内ハンディ通知 | Slack、Teams、日報 |
軽量判定までエッジ側で持っておくと、ネットワークが切れたときも 1 段目のアラートは出せます。reasoning だけがクラウド依存になる形にしておけば、停止時の縮退運転も比較的素直に組めますね。Hermes Agent は店舗側に置いてもクラウド側に置いても成立しますが、店舗側 PC のリソースを軽くしたいなら、クラウド側に置いて Bedrock や OpenAI 互換 API と組み合わせる形が扱いやすいです。
構成案 C は AWS IoT Greengrass で複数店舗を見据える
最後の構成案は、複数店舗展開を最初から視野に入れる場合です。AWS IoT Greengrass をエッジランタイムにして、IoT Core 経由でイベントを受け、Bedrock や SageMaker と組み合わせます。Greengrass はエッジデバイス上で Lambda やコンテナを動かせる管理基盤で、IoT Core と組み合わせると、複数拠点のエッジを安全に運用しやすくなります。AWS の公式ブログでも、IoT Greengrass と IoT Core を使って既存 CCTV やエッジゲートウェイから産業安全向けの映像解析を行い、S3 や SageMaker とつなぐ構成が紹介されています。
役割で見ると、Greengrass がエッジアプリケーションの配布と管理を担い、IoT Core がイベントを受け、Lambda や Step Functions がワークフローを進めて、Bedrock と Hermes Agent + VSS Skills が説明文や対応案を生成します。モデル改善は SageMaker に寄せておくと、後から再学習や店長レビュー結果の取り込みを組み立てやすくなります。
複数店舗を見据える前提があるなら、最初から Greengrass を入れておくほうが楽です。1 店舗だけの PoC でも、その後の横展開を視野に入れるなら、ここに統制ポイントを置いておくと後で慌てずに済むかなと思います。逆に、最初の PoC が 1 店舗で完結するなら、構成案 A や B から始めて、横展開が見えてきた段階で構成案 C に寄せ直す、という順序も自然です。
最初のユースケースは 1 つに絞る
Mini-Retail FOX を回す最初の題材としておすすめなのが、「棚薄候補の発見」または「通路ふさがり検知」です。
棚薄候補の発見は、映像だけで説明が完結しやすく、イベント化もしやすく、店長や SV にとっても日常業務の延長で理解しやすい題材ですね。検出側もシンプルな状態判定で動かせますし、「夕方ピーク前の補充タイミング確認候補」という落としどころが現場にも馴染みやすいです。誤検知も「商品が少なく見えるが補充直後で問題ない棚」のような分かりやすい例で議論できます。
乳製品棚の右側が一部薄くなった状態を捉えた生成 AI 素材
棚薄候補は単発のスナップショットだけでなく、補充作業が入って棚状態が回復するまでをセットで確認できると、より店舗運営の文脈に乗りやすくなります。
スタッフが台車で接近して補充作業を行っている場面の生成 AI 素材
通路ふさがり検知は、安全観点で 5S 活動とも繋げやすい題材です。台車や段ボールが通路中央付近に残っている、滞留時間が一定を超えている、というルールで素直に組めます。映像中心で完結する点も、棚薄候補と似ています。
通路の中央に台車が放置されている場面の生成 AI 素材
ここに載せたシーン画像は、実店舗映像ではなく生成 AI で作った疑似 CCTV 風の素材です。Mini-Retail FOX の構想を説明したいときに、実店舗映像をすぐ用意できない段階でも、こうした疑似素材で UX とイベント定義の議論を先に進めておけると、PoC 着手後の手戻りが減らせるかなと思います。
SOP 逸脱、たとえば「レジが時間内に閉鎖されている」「カートが想定外の場所に長時間残っている」のような場面は、Mini-Retail FOX らしさを強く出せます。ただし店舗ごとの運用ルールの整理が必要になるため、初回 PoC としてはやや重たい印象です。まずは棚薄候補や通路ふさがりを本命の例にして、自動で何かを指示する手前の「何を見つけ、どう説明し、店長や SV がどう判断したか」を残す流れに留めておいて、発展形として SOP 照合を載せていく順序が読みやすいかなと思っています。
専門エージェント化は後回しで十分
FOX の構想では多数の専門エージェントが出てきますが、Mini-Retail FOX を始めた直後から分けすぎないほうが運用が楽です。最初は 1 つの Store Supervisor Agent の中に処理を置き、ログを眺めていて役割が明らかに分かれていることが見えてから分割します。
分けるとしても、最初は次の 4〜5 つくらいで十分かなと思います。
| 専門エージェント | 担当範囲 |
|---|---|
shelf_agent |
棚薄候補、補充タイミング、欠品候補の状態説明 |
flow_agent |
通路ふさがり、滞留検知、動線阻害候補の説明 |
checkout_agent |
レジ前の混雑、応援レジ候補、セルフレジ誘導候補の整理 |
report_agent |
日次・週次の店舗運営レポート生成、Slack や日報への配信 |
learning_queue |
誤検知と見逃しの収集、人間レビュー結果のフィードバックループ管理 |
エージェントを分割する判断軸として、店舗ごとの運用ルール差分も意識しておくと後が楽です。チェーン全体で共通のルールは Supervisor Agent 側に置いておき、店舗別の細かな違いは Profile やコンフィグで切り替えられるようにしておくと、後から対象店舗を増やすときの棚卸しがしやすくなりますね。
まとめ
DGX Spark 中心、PC とクラウド分担、AWS IoT Greengrass 中心の 3 構成を、観点別に並べておきます。
| 構成 | 向いている場面 | 初期コスト | 映像の出しやすさ | 主な見どころ |
|---|---|---|---|---|
| DGX Spark ローカル構成 | 映像を外に出しにくい店舗、NVIDIA 文脈の PoC | 中 | 出しにくい店舗でも扱いやすい | ローカル VSS と Hermes Agent の組み合わせ |
| PC + クラウド reasoning | 低コストな技術検証、店舗側ハードを軽くしたい | 低 | 異常候補だけ送る設計にする | 1 店舗・1 カメラから始める軽量構成 |
| AWS IoT Greengrass 構成 | 複数店舗展開を見据える PoC | 中 | AWS 側で統制しやすい | Greengrass、Bedrock、SageMaker の役割分担と統制 |
ここから先に広げるとしたら、DGX Spark 上で実際に VSS の search profile と video-search Skill を install して棚薄検知を 1 ユースケース通す、AWS IoT Greengrass と Bedrock で複数店舗運用を試してみる、Hermes Agent の Profile に応じた店舗業務オートメーションを作ってみる、Cosmos Reason や Cosmos 3 でレジ前混雑解析を掘ってみる、といった展開も考えられそうですね。Mini-FOX の製造業編と並べて、Physical AI が工場以外の現場にもじわじわ広がっていく流れを追いかけていけたらと思います。
参考リンク
- NVIDIA FOX Blueprint を小さく始める Mini-FOX 構成を考えてみた
- NVIDIA VSS + AI Agents + Skills の身近な現場での使いどころを考えてみた
- NemoHermes で Hermes Agent を DGX Spark の OpenShell に載せてみた
- Transform video into instantly searchable, actionable intelligence with AI Agents and Skills (NVIDIA Developer Blog)
- NVIDIA-AI-Blueprints/video-search-and-summarization (GitHub)
- agentskills.io specification
- Improving industrial safety with video analytics, AWS IoT Core, and AWS IoT Greengrass (AWS Blog)
