この記事の結論

NVIDIAのエージェント実行基盤NemoClawが8月23日にv0.0.114へ更新。Nemotron 3.5 LightningとNeMo Switchyardによるコスト削減効果、Oasis Securityが公表した脆弱性への対応状況までを整理します。

NemoClawとは何か：OpenShellサンドボックス上の常時稼働エージェント基盤

NVIDIA NemoClawは、常時稼働型のAIエージェントをより安全に実行するためのオープンソースのリファレンススタックです。公式ドキュメントによれば、NemoClawはOpenShellコンテナ内でのオンボーディング、ライフサイクル管理、エージェント運用を提供し、NVIDIA Agent Toolkitの一部であるOpenShellランタイムをインストールしたうえで、追加のセキュリティおよび推論ルーティング機能を備えた実行環境を構築します。

基盤となるOpenShellは、単一のDockerコンテナ内でK3s Kubernetesクラスタを動かし、ファイルシステムアクセスやネットワーク通信を宣言的なYAMLポリシーで制御する設計とされています。NemoClawはOpenShellやエージェントランタイムを置き換えるものではなく、バージョン管理されたブループリント、エージェント固有の設定、マネージド推論、ネットワークポリシー、ライフサイクル運用を含む再現可能なセットアップとしてパッケージ化する役割を担います。ホスト側の操作権限はオペレーターが握り、サンドボックス境界の強制はOpenShellが担当するという責任分界が特徴です。

直近リリース：v0.0.102からv0.0.114までの更新ラッシュ

NemoClawは2026年8月に入ってから極めて高頻度でリリースを重ねています。8月4日のv0.0.102では、オペレーター管理のllama.cppサーバーを認証付きで接続する機能と、2台のDGX Spark構成向けの実験的なマネージドvLLMプロファイルが追加され、DGX StationおよびWindows環境でのインストール、ゲートウェイとサンドボックスの復旧処理も改善されました。

8月7日のv0.0.105ではWindows、Linux ARM64、DGX Spark、Ollama、vLLM、マネージドllama.cppにまたがるローカル／マネージド推論経路が復旧され、8月10日のv0.0.106ではライフサイクルコマンド全体でレディネス判定が統一されるとともに、マネージドOpenShellランタイムがv0.0.101へ更新されました。そして8月23日のv0.0.114では、LangChain Deep Agents Code向けに決定論的な読み取り専用MCPツール呼び出しと、ステージごとの起動レディネスプローブ計測が追加されています。破壊的操作に対する警告、セッションエクスポートのクリーンアップ、封印済み構成の復旧、インストール検証も強化されました。

Oasis Securityが公表した脆弱性とその対応状況

2026年8月25日、セキュリティ企業Oasis Securityの研究者がNemoClawに関する脆弱性を公表しました。報道によれば、ローカルマシン上で動作するNemoClawに対しDNSリバインディングを悪用した乗っ取りが成立し得るというもので、攻撃者が用意した悪意あるWebページによって、エージェントに推論を提供しているローカルのOllamaインスタンスを認証なしで操作し、モデル自体に隠れた指示を埋め込むことが可能になると説明されています。

ただし、この研究にはCVE識別子は付与されていません。Oasis Securityの研究責任者Elad Luz氏はThe Hacker Newsに対し、macOSおよびLinuxではNemoClaw v0.0.35で本問題が修正済みであると述べています。また2026年8月25日時点で、実際に悪用された事例は報告されていません。とはいえ既にパッチが提供されている以上、ローカル環境でNemoClawを運用しているユーザーは、機微なアカウント情報を守るためにも速やかに最新版へ更新することが推奨されます。前述の通りリリース間隔が非常に短いため、更新運用そのものを自動化しておくことが実務上の要点になります。

Nemotron 3.5 Lightning：実行レイヤーに特化した30B MoEモデル

NVIDIAは2026年8月11日、オープンモデルNemotron 3.5 Lightningを公開しました。総パラメータ30B、アクティブパラメータ3Bのmixture-of-experts（MoE）モデルで、Mamba-2とMoE、Attentionを組み合わせたハイブリッドアーキテクチャと100万トークンのコンテキストウィンドウを備えます。狙いは明快で、長時間稼働するエージェントはトークン予算の大半をツール呼び出し、出力の検証、サブエージェントへの委譲に費やしており、そのすべてをフロンティア級の推論モデルに投げるのはコストと遅延の両面で不合理だという問題意識に基づいています。

性能面では、同クラスのモデル比で最大4倍の出力速度、エージェントタスクベンチマークPinchBenchで86%の精度を示しつつ、1万タスクの完了をQwen3.6 35B比で30%高速に処理したと報告されています。BF16でのベンチマーク値としてSWE-bench Verified 51.56、GPQA Diamond 75.44、MMLU Pro 81.94なども公表されました。ライセンスはOpenMDW-1.1で、重み・データ・レシピが併せて提供され、JetsonからDGX Spark、データセンターまで幅広いハードウェアで動作します。配布先はHugging Face、ModelScope、build.nvidia.com、OpenRouterなどです。

NeMo Switchyard：モデルルーティングでコストを最大74%削減

Lightningと同時に公開されたNeMo Switchyardは、エージェントワークフローの各ステップを最も適切かつ効率的なモデルへ振り分けるオープンソースのルーティングライブラリです。セッションアフィニティを持つLLM分類器、直近のツール利用状況を読み取るステージルーター、安価なモデルから始めて必要に応じて昇格させるエスカレーションルーターなど、チューニング不要のルーターが用意されています。アプリケーション側を書き換えることなく、自前のオープンモデル・商用モデル・NVIDIAモデルの混成環境に適用できる点が特徴です。

効果は具体的な数字で示されています。NVIDIAの内部ベンチマークでは、Claude Opus 4.8単独運用と比較してタスク完了コストをおよそ3分の1に抑えつつフロンティア級の精度を維持したとされます。LangChainによる145件のマルチターンDeep Agentsタスクの検証では、フロンティアモデルへのルーティングをわずか7%に絞ることでコストを74%削減し、精度低下は約6ポイントにとどまりました。またRampの事例では、Ramp SWE-Benchでフロンティアモデル同等の性能を保ちながらコストを58%、実行時間を33%削減したと報告されています。

NeMo Customizerでの独自チューニングと実践ポイント

公開されたモデルを自社ドメインに適合させる役割を担うのがNeMo Customizerです。これはGPUノード上でVolcanoスケジューラを用いたマネージドな学習ジョブを実行する軽量なAPIサーバーで、NVIDIA製・オープンソース問わずLLMを自社ユースケースに合わせてカスタマイズできます。作成した学習済みモデルはNVIDIA NIMと容易に統合でき、単一ノードからマルチノード・マルチGPU構成までスケールします。

対応する手法は幅広く、LoRAによるPEFTを用いた教師ありファインチューニング（SFT）が推奨される出発点とされ、全重みを更新するフルSFT、選好に沿わせるDPO、教師モデルと生徒モデルを用いる知識蒸留、埋め込みモデルのLoRAチューニングなどが提供されています。モデルはCustomization Targetとして登録・管理し、事前構築済みのレシピであるCustomization Configを選ぶ運用になります。実際、Nemotron 3.5 LightningはCrowdStrike（サイバーセキュリティ）、Harvey（リーガル）、CodeRabbit（コードレビュー）、Lila Sciences、Fastino Labsなどによってドメイン特化のカスタマイズが進められており、オープンな重みと公開レシピを前提とした業務特化が実運用の主流になりつつあります。

まとめ：導入検討時に押さえるべき3つの視点

ここまでの動きを整理すると、NVIDIAのエージェントスタックは「安全な実行環境（NemoClaw／OpenShell）」「安価で高速な実行モデル（Nemotron 3.5 Lightning）」「賢い振り分け（NeMo Switchyard）」「自社適合（NeMo Customizer）」という4層で構成されていることが見えてきます。単一の万能モデルにすべてを任せるのではなく、専門化したモデル群のシステムとしてエージェントを設計するという思想が一貫しています。

導入を検討する際の視点は3つです。第一に更新運用。8月だけでv0.0.102からv0.0.114まで版が進んでおり、脆弱性修正も含まれるため追随体制が不可欠です。第二にコスト設計。Switchyardの検証結果が示す通り、精度をわずかに譲るだけでコストが半分以下になる領域が存在します。第三にデータ境界。OpenShellは認証情報をサンドボックス外に保持し、プライバシールーターによってローカル推論とクラウド推論を使い分けられるため、データ所在地要件から逆算した構成設計が有効です。