ローカルモデルは、ある種類のリスクを減らします。推論のためにプロンプトや文書をLAN外へ送る必要がなくなります。しかし、別のリスクが減るわけではありません。ツールを使えるエージェントは、依然としてファイルを読み、ネットワーク接続を確立し、意図しない操作を実行できます。
NVIDIA NemoClawは、NVIDIA OpenShellのサンドボックス内でエージェントをより安全に実行するためのオープンソースのリファレンススタックです。ガイド付きオンボーディング、ネットワークポリシー、ライフサイクル管理、推論ルーティングを提供します。サポート対象のDGXプラットフォームでは、現行のインストーラーが管理対象のローカル推論を使うExpress方式を提示する場合があります。
2026年八月10日時点で、NVIDIAの正規のプラットフォーム対応表は、NemoClawをalpha段階の早期プレビューと位置付けています。メンテナーの対応はベストエフォートで、本番運用向けSLAはありません。OpenShellのリポジトリもランタイムをalphaとし、現行の運用モデルを1人の開発者、1つの環境、1つのゲートウェイと説明しています。個別の機能やプラットフォームの行がTestedと表示されていても、両者をこの前提で評価してください。
公式の参照先は次のとおりです。
- Sparkプレイブック：build.nvidia.com/spark/nemoclaw
- ソースコードとIssue：github.com/NVIDIA/NemoClaw
- ドキュメントハブ：docs.nvidia.com/nemoclaw
- OpenShell：github.com/NVIDIA/OpenShell
関連情報：DGX Sparkとは何か、ローカル推論の実情、プライベートAIの導入パターン。
NemoClawとOpenShellは影響範囲を限定しますが、エージェントのリスクをなくすものではありません。どちらもalpha段階のソフトウェアです。NVIDIA自身のSparkプレイブックも、データ漏えい、悪意のあるコードの実行、意図しない操作、プロンプトインジェクションといったリスクが残るデモ用の経路として説明しています。最初のインストールにはクリーンな環境を使ってください。ポリシー、ログ、人による承認ゲートを明確に設計するまでは、本番用の認証情報、顧客データベース、特権付きクラウドアカウントを接続しないでください。
NemoClawの位置付けと限界
| NemoClawの位置付け | NemoClawに該当しないもの |
|---|---|
| サンドボックス化したエージェント向けのリファレンススタックとCLI | コンプライアンス認証 |
| ポリシーフックを備えたOpenShellベースの分離 | プロンプトインジェクションを防ぐ保証 |
| 管理対象のバックエンドへの推論ルーティング（Spark上のローカルvLLMを含む） | 1つのエージェント製品だけを恒久的に使う要件 |
| バージョン付きでリリースされるalpha段階の早期プレビュー用スタック | IAMとDLPプログラムをそのまま置き換える代替品 |
対応エージェント（NemoClaw READMEに基づく。インストール当日に現行ドキュメントを確認してください）：
- OpenClaw：デフォルトのマルチチャネル・エージェントゲートウェイ
- Hermes Agent：ターミナル、メッセージング、ツール、メモリーを備えたNous Researchのセルフホスト型ランタイム
- LangChain Deep Agents Code：サンドボックス内のゲートウェイやダッシュボードを持たない、ターミナル指向のコーディングランタイム
NVIDIAの現行対応表では、3つのエージェントすべてがTestedと記載されています。ただし、本番運用可能という意味ではありません。対応表では、より広範な実行時の受け入れ確認と、Deep Agents Code向けのターミナルエージェント診断が今後の作業として残っています。また、HermesとOpenClawが本番運用で同等とは述べていません。
チャネル体験とツールに対する設計思想に合わせてエージェントを選びます。NemoClawが担うのは、そのエージェントを包むサンドボックス境界とオンボーディング手順です。
DGX Sparkにおける現行のオンボーディング（概念）
現行のOpenClawクイックスタートでは、NVIDIAがホストするスクリプトからインストールし、nemoclaw onboardでセットアップを完了します。現行のDGX OSを搭載したサポート対象のDGX Sparkでは、インストーラーが管理対象のローカル推論を使うExpress方式を提示する場合があります。概念的には、オンボーディングで次の処理を行います。
- 必要に応じて、依存関係（Node.js、OpenShell、NemoClaw CLI）を取得または確認します。
- Spark上に管理対象のvLLM（または現行プレイブックが指定するローカル推論手順）をセットアップします。
- インストーラー推奨のデフォルト・ローカルモデルと、初期ポリシーまたはサンドボックスプロファイルを選びます。
- サンドボックスを作成し、選択したエージェントが対応するインターフェースを公開します。OpenClawとHermesにはダッシュボードの経路があります。Deep Agents Codeはターミナル指向で、サンドボックス内のゲートウェイもダッシュボードもありません。
アーキテクチャドキュメントに特定のモデル名を恒久的な事実として固定しないでください。Express Installが示すデフォルトは、プレイブックの改訂によって変更される可能性があります。「インストーラー推奨のローカルモデル」と記載し、インストーラーの出力に表示された正確なIDを運用手順書に記録して、再構築時にbuild.nvidia.com/spark/nemoclawを再確認してください。
別のエージェント、推論プロバイダー、またはポリシー構成が必要な場合は、カスタムオンボーディングも利用できます。Hermesについては、NVIDIAの現行ドキュメントがnemohermes onboardエイリアスを推奨しており、nemoclaw onboard --agent hermesにも対応しています。ホストされているインストーラーでHermesを選ぶ場合は、NEMOCLAW_AGENT=hermesを設定します。インストール当日にHermesクイックスタートを確認してください。
前提条件（Sparkプレイブック）
- キーボードとモニター、またはSSHで操作できるDGX Spark。
- 新規に導入し、最新状態に更新したDGX OS。
- GPUを正しく認識でき、Dockerが動作する環境（プレイブックは新しいバージョンのDockerを想定しています。NemoClawをデバッグする前に
nvidia-smiとdocker infoで確認してください）。
後から必要に応じて、TelegramなどのメッセージングチャネルやWeb検索APIを追加できます。これらはネットワークポリシーの対象範囲を広げるため、初期設定に含めず、2回目の変更作業として扱ってください。
重要なのはポリシー層
OpenShellのREADMEは、サンドボックスポリシーをファイルシステム、ネットワーク、プロセス、推論の4領域に分けています。NemoClawの現行セキュリティ文書は、ゲートウェイ認証を加えた5つの保護層を説明しています。ゲートウェイ認証は、どのデバイスやクライアントがゲートウェイまたはダッシュボードにアクセスできるかを制御するコントロールプレーン境界です。関連するセキュリティ層ですが、5番目のサンドボックスポリシー領域ではありません。
| 層 | 保護対象 | 現行の変更可否 |
|---|---|---|
| ファイルシステム | 許可したパス外の読み書きと、保護されたランタイム状態 | サンドボックスの再作成が必要 |
| ネットワーク | 許可していない送信接続とデータ流出 | ポリシー変更または運用者の承認によりホットリロード可能 |
| プロセス | 権限昇格、フォークボム、危険なシステムコール | サンドボックスの再作成が必要 |
| 推論 | 認証情報の露出と許可していないモデルへのアクセス | NemoClawの推論切り替えコマンドで変更可能 |
ゲートウェイ認証は、ゲートウェイおよびダッシュボードがある場合に、それらへのアクセスを保護します。NVIDIAの現行文書では、イメージのビルド時またはオンボーディング時に設定するものとされ、ホットリロード可能なサンドボックスポリシーではありません。
設計上の含意は次のとおりです。
- 継続利用するサンドボックスを作成する前に、ファイルシステムのマウントを決めてください。「ホームディレクトリは後から開放する」という方針では、ローカルエージェントからマシン上のすべてのSSH鍵にアクセスできる状態になりかねません。
- ネットワークポリシーは、継続的に更新する許可リストとして使います。メッセージングのWebhook、検索API、内部HTTPエンドポイントを明示的に許可してください。OpenShellゲートウェイと転送したダッシュボードは、ループバックまたは意図的にアクセスを制御した別の境界に置きます。ゲートウェイ認証だけでは、公開されたエージェントダッシュボードを十分に保護できません。
- 管理された経路で推論をルーティングしてください。対象プロバイダーを明示的に許可しない限り、エージェントが機密プロンプトを公開APIへ送るよう勝手に切り替えられないようにします。
- Balancedまたはデフォルトのプリセットを緩める前に、NVIDIAのネットワークポリシーとセキュリティのベストプラクティスを読んでください。
サンドボックス化しても、監査証跡が不要になるわけではありません。エージェントのログを読める人、ツールトレースの保持期間、チャネル上の会話履歴を保持するかどうかを定義してください。ローカル推論でもクラウドチャネルと接続すれば、そのチャネルを通じてデータが外部に送られる可能性があります。
OpenClaw、Hermes、そして「OpenShell単独」の比較
| 選択肢 | 適する場面 |
|---|---|
| OpenClaw（デフォルト） | マルチチャネル・ゲートウェイのUXが必要で、Control UIやチャネルが製品体験に含まれる場合 |
| Hermes | ツール、メモリー、cron、Webhook型の連携に重点を置くセルフホスト型ランタイムが必要な場合（スタックの別の場所でn8n型の連携を使う場合を含む） |
| Deep Agents Code | NemoClawが文書化するTested済みのターミナル専用LangChain経路が必要で、対応表に残る実行時の受け入れ確認に関する注意点を許容できる場合 |
| OpenShell単独 | NemoClawのオンボーディングやブループリントを使わず、alpha段階のサンドボックス・ランタイムだけが必要で、現行の単一利用者向け運用境界を明示的に評価する場合 |
NemoClawは信奉すべき教義ではなく、必要に応じて使う連携レイヤーです。本番環境を想定したデモで譲れないのは、内部で動くエージェントバイナリにかかわらず、ポリシー、推論ルーティング、最小権限のツールを組み合わせることです。
上流のHermesクイックスタートとOpenClawのセキュリティドキュメントは、サンドボックス内でも適用されます。ツールにシェル、ファイル、ブラウザーが含まれる可能性があるため、チャネルの許可リスト、ペアリング、グループでのメンションルールが重要です。OpenShellはホスト上の動作を制約しますが、適切なチャネル運用を代わりに設計するものではありません。インストール当日に、OpenClawドキュメント、Hermes公式ドキュメント、現行のNemoClaw Hermesクイックスタートを確認してください。
障害モードと運用上の制約
| 障害モード | 問題 | 対策 |
|---|---|---|
| 機密情報の残るホストでオンボーディングする | 広範なマウントを通じてエージェントが機密ファイルを取り込む可能性がある | 最初の立ち上げにはクリーンなテスト環境を使う |
| 送信先を広く許可しすぎる | プロンプトインジェクションによりHTTP経由でデータが外部に送られる | 厳格な送信ポリシーを使い、新しい宛先を明示的に承認する |
| 未認証のローカルvLLM | LAN上の他のユーザーがプライベートモデルを呼び出す | 非公開アドレスにバインドし、認証とファイアウォールを使う |
| ペアリングルールのないチャネル | 未知の相手がツールの実行を起動する | OpenClawまたはHermesの許可リスト、ペアリング、メンションルールを使う |
| alpha段階のソフトウェアを完成品として扱う | 更新により動作が壊れたり変わったりする | バージョンを固定し、リリースノートとセキュリティ情報を読み、段階的にアップグレードする |
| 操作に人の承認ゲートがない | エージェントがメールの送信、マージ、削除を行う | 影響の大きいツールには承認を必須にする |
現行のNemoClawリリースノートとSECURITY.mdを確認し、検証したリリースに固定して、セキュリティ問題には文書化された非公開の報告経路を使ってください。
より大きなプライベートスタックにどう組み込むか
1台のSpark上でNemoClawを動かすことは、より大きなアーキテクチャへ進むための第1段階になることがよくあります。
| 層 | 例 |
|---|---|
| 推論 | Spark上のローカルvLLM（Express Installまたは手動構築）。後に2台のSparkでTPを実行 |
| エージェント | NemoClawを介してOpenShell内で動くOpenClawまたはHermes |
| 自動化 | 決定論的な連携処理のため、LAN上のn8n（または同様のツール）からHermesまたはOpenClawのWebhookを呼び出す |
| 人 | CRMへの書き込み、外部へのメール送信、本番シェルを承認ゲートで制御 |
これらの層は、1社のベンダーに閉じたスタックとして必須なわけではありません。長期的に通用する原則は、モデルの外で決定論的に連携し、エージェントに判断を担わせ、両者をポリシーで囲むことです。Sparkのクラスタリング、ローカルのOpenAI互換サービング、n8n、Hermesを組み合わせた総合演習の設計例は、アーキテクチャの選択肢です。初日からすべてのコンポーネントを動かす必要はありません。
Sparkで最初に試す推奨手順
- DGX OSを更新し、
nvidia-smiとDockerのGPUアクセスを確認します。 - SparkプレイブックのExpress Installに従い、インストーラーが選んだモデルIDとポリシープロファイルを記録します。
- ファイルシステムとネットワークのポリシーを確認するまでは、機密性のないプロンプトだけでWeb UIまたはTUIを使います。
- 追加するのは、1つのチャネルまたは1つの内部HTTPツールだけにします。5つを一度に追加しないでください。
- 1ページの運用手順書を作成します。サンドボックスを停止または破棄する方法、チャネルトークンを無効にする方法、対応している状態をスナップショットまたは復元する方法、インストール済みエージェント向けのアンインストールコマンドを安全に使う方法をまとめてください。現行のHermesドキュメントでは
nemohermes uninstallを使います。 - その後で初めて、エージェントにプライベートなコーパスを参照させます。品質が不十分な場合は、推論の実情で説明した制約も考慮してください。
「実データ」の投入前に行う受け入れ確認
- ファイルシステムのマウントが意図した許可リストと一致し、ホームディレクトリが誤って共有されていないこと。
- ネットワークポリシーが想定外の送信を拒否し、許可していないホストへのテストcurlが失敗すること。
- 推論トラフィックが、誤って公開APIキーを使う経路ではなく、構成したルーティング済みローカルバックエンドへ向かっていること。
- チャネルのペアリングまたは許可リストが未知の送信者を拒否すること。
- サンドボックスを停止または破棄し、文書化されたアンインストール手順を実行したうえで、残ったコンテナ、プロバイダー、認証情報、保持された状態を一覧にできること。
NVIDIAの現行アンインストール文書によると、nemohermes uninstall --yesは稼働中のNemoClawランタイムリソースを削除しますが、デフォルトではrebuild-backups/、backups/、sandboxes.jsonを保持します。アンインストールによって、それらが参照していたゲートウェイ、プロバイダー登録、イメージが削除されるため、保持されたレジストリ記録を再インストール後にそのまま利用できるわけではありません。現行のホストファイルと状態に関する文書を確認せずに、保持されたメタデータを復旧計画として扱わないでください。
保持されたバックアップとレジストリのメタデータを削除する意図がある場合に限り、--destroy-user-dataを使ってください。--yesはアンインストールの確認を省略するだけであり、それ自体では保持されたユーザーデータを消去しません。バージョンを固定した正確なコマンドをクリーンな環境でテストし、残存物を確認してください。この記事では、このアンインストール手順を実行していません。
現時点では避けること
- 本番用APIキーは、マスキングルールを定めないまま、「インストールを支援している」コーディングエージェントのチャットに貼り付けないでください。上流のスタータープロンプトがこの点を警告するのには理由があります。
- サンドボックス内で動くからといって、規制対象の医療または法律上の意思決定に安全に使えるとは限りません。
- 「LAN内だけで使うから」という理由でネットワークポリシーを省略しないでください。
- 特定のデフォルトモデル名を、恒久的なアーキテクチャ標準として文書化しないでください。
NVIDIAは、Spark上のNemoClawを、対応エージェントをOpenShellの背後に配置し、推論をルーティングするalpha段階の早期プレビュー方式として文書化しています。導入済みと説明する前に、拒否、アンインストール、復旧のテストを含む経路全体を検証してください。
