【最新】NVIDIA NemoClaw最新動向｜Nemotron 3.5 LightningとNeMo Switchyard登場

NemoClawとは：OpenClawにガードレールを付けたNVIDIAのエージェント基盤

NVIDIA NemoClawは、2026年3月16日のGTCで発表されたAIエージェント実行スタックです。オープンソースの自律エージェントOpenClawをベースに、NVIDIAが独自のセキュリティ・プライバシー層を重ねた構成で、単一コマンドでインストールできる点が特徴とされています。クラウドからオンプレミス、さらにGeForce RTX搭載PC、DGX Station、DGX Sparkまで、常時稼働型のAIアシスタントを安全に動かすことを狙いとしています。

OpenClaw自体は初期バージョンでセキュリティ上の懸念が指摘されてきた経緯があり、自律エージェントに個人データや社内リソースへのアクセスを与えるリスクが議論されてきました。NemoClawはこの課題に対し、NVIDIA Agent Toolkitのコンポーネントを組み合わせてプライバシーとセキュリティの制御を追加するアプローチを取っています。なお発表時点でNVIDIAはアーリープレビュー／アルファ段階であることを明言しており、本番運用グレードのサンドボックスオーケストレーションに向けて開発を継続中という位置づけです。

ハードウェアはNVIDIA GPU必須ではなくハードウェア非依存で、NVIDIAのAIエージェント向けソフトウェア群であるNeMoと統合されます。エージェントの頭脳として使うモデルも、NVIDIAのNemotronオープンモデルに限らず任意のコーディングエージェントやオープンソースモデルを選択できます。

OpenShell：ネットワーク・ファイルシステム・プロセスの3層で隔離

NemoClawのセキュリティの中核がOpenShellです。エージェント本体を隔離サンドボックス内で実行し、許可されたファイルにしかアクセスできないようにします。ポリシーエンジンがすべてのネットワークアクセスを審査し、許可されていない接続はブロックされます。APIキーやパスワードなどの機微な認証情報はサンドボックスのファイルシステムに保存されず、実行時に環境変数として注入される設計です。

公式ドキュメントでは保護レイヤーが整理されており、ネットワーク層は不正な外向き通信とデータ持ち出しをOpenShellゲートウェイで、ファイルシステム層はシステムバイナリ改ざんや認証情報窃取をLandlock LSMとコンテナマウントで、プロセス層は権限昇格やfork bomb、syscall濫用をコンテナランタイム（Docker/KubernetesのsecurityContext）で防ぐ構成です。ネットワークポリシーはopenshell policy setや運用者承認により実行時に変更可能ですが、ファイルシステムやプロセスの設定変更にはサンドボックスの再作成が必要になります。

セキュリティポリシーはYAML構文で定義し、再起動なしのホットアップデートに対応するルールも用意されています。

推論ルーティング層：APIキーをエージェントに見せない設計

NemoClawはサンドボックス内エージェントからのモデル呼び出しをすべて推論ルーティング層で受け止めます。エージェントはinference.localを呼ぶだけで、OpenShellが運用者の設定したバックエンド、たとえばNVIDIA Nemotron、Anthropic、OpenAI、Gemini、あるいはOllamaやvLLMで動くローカルモデルへ振り分けます。

重要なのは、推論用のAPIキーがホスト側の~/.nemoclaw/credentials.jsonに留まり、エージェント自身は鍵を一切参照できない点です。これによりプロンプトインジェクションでエージェントが乗っ取られた場合でも、認証情報そのものの流出は防ぎやすくなります。ドキュメント上は、Web検索用の認証情報についてもサンドボックススコープのOpenShellプロバイダーに登録し、エージェント設定にはリゾルバのプレースホルダーだけを書き込む方式が採られています（BraveはX-Subscription-Tokenヘッダー経由など）。

NemoClawには、Slack、Jira、Docker Hub、PyPI向けの外向き通信ポリシーがプリセットとして同梱されており、openclaw-sandbox.yamlに宛先と許可アクションを記述する形で経路を開けます。

2026年8月11日発表：Nemotron 3.5 LightningとNeMo Switchyard

直近の大きな動きが、2026年8月11日に発表されたNVIDIA Nemotron 3.5 LightningとNeMo Switchyardです。Nemotron 3.5 Lightningは、長時間稼働するエージェンティックAIワークロード向けにクラス最高効率をうたうオープンモデルで、Nemotron 3ファミリーの拡張版にあたります。仕様は300億パラメータ（30B）のMoE（Mixture of Experts）で、アクティブパラメータは30億（3B）。上位モデルであるNemotron 3 Ultraから蒸留され、常時稼働エージェントが延々と処理する定型的・反復的なタスクの高スループット処理に最適化されています。

もう一方のNeMo Switchyardは、エージェントのワークフローの各ステップに対して「どのモデルに任せるか」を決めるオープンソースのモデルルーティングライブラリです。高価な大型モデルへの依存を減らし、トークン消費とコストを抑えることが狙いで、エッジデバイス、PC、ワークステーションを横断してAI・データ・ワークフローの制御性を高めると説明されています。Nemotron 3.5 LightningはHugging Face、ModelScope、OpenRouter、build.nvidia.comでNVIDIA NIMマイクロサービスとして提供され、NVIDIA Cloud Partnerのエコシステム経由でも利用できます。

NeMo Customizerとカスタマイズ基盤の現在地

NeMo Customizerは、GPUノード上でVolcanoスケジューラを使った管理型トレーニングジョブを実行するための軽量APIサーバーです。NVIDIA製またはオープンソースのLLMを取り込み、望ましい応答例を与えることで、以後の出力をその例に沿わせるようモデルを調整（ファインチューニング）できます。テレメトリ送信のためにWeights & BiasesのAPIキーを必要とする点も運用上の前提です。

プラットフォーム側では、NeMo Platform v0.1.0（2026年5月20日）のリリースノートで、Customizerによるファインチューニングワークフロー、差分プライバシー保証付きの合成データ生成「Safe Synthesizer」、Web UI上のStudio agent flow、エンタープライズ向けクラスタ／スケールアウト展開が「Coming soon」として挙げられていました。同バージョンではInference Gatewayのプロバイダー登録や仮想モデル、エンティティ名ルーティング、そしてSwitchyardミドルウェアによる強弱モデル分割のルーティングが盛り込まれています。

なおNeMo Framework本体については、2026年6月のセキュリティ速報でCVE-2026-24155ほか複数の脆弱性が公表され、バージョン2.7.3以降への更新が推奨されています。運用中の環境ではバージョン確認をおすすめします。

リリース状況と、それでも残るリスク

NemoClawの開発ペースは速く、公式ドキュメントのリリースノートによればv0.0.80ではメッセージング基盤HermesがV0.18系へ更新されSlack Block Kitレンダリング（Markdownテーブルのネイティブテーブルブロック化を含む）に対応、OpenRouterのランタイムトラフィックをホストローカルのアトリビューションアダプター経由に変更、ホストの企業プロキシCAをサンドボックスの信頼ストアへ取り込むなどの改善が入りました。さらに2026年8月10日のv0.0.106では、ライフサイクルコマンドのレディネス統一、マネージドOpenShellランタイムのv0.0.101への更新、DGX Spark向けvLLM選択肢の追加、サンドボックスとHermesの復旧強化、ローカル推論診断やエンドポイントポリシーの改善が行われています。

一方でリスクも指摘されています。セキュリティ企業Lasso Securityは、npm install、node実行、git／ghといったエージェントの基本機能上どうしても許可せざるを得ない経路を悪用したデータ持ち出しシナリオを報告しました。同社によれば、これらはポリシー違反ではなくサンドボックスが設定どおりに動作した結果であり、NVIDIAはVDPの対象範囲外と回答したうえで、OpenShellはまさにプロンプトインジェクションの影響範囲を限定するためのサンドボックス実行環境を提供するものだと説明したとされています。

また別の分析では、「エージェントはサンドボックス化されても、そのツール利用は統制されていない」という論点が示されています。Slackなどへの通信経路が開いていること自体は、そこで何をするかを制御することとは別問題だという指摘です。導入時は、ツール権限の最小化、人による承認フロー、読み取り専用ランタイムと実行ランタイムの分離といった設計が引き続き重要になります。