Komlock lab VPoE阿部(@takupeso)です。
僕はリリース初期からOpenClawエージェントを並列稼働させ、
開発、情報収集、読書サポート、習慣化などなど色々な用途で使ってきました。
おかげでインプット、アウトプット量が圧倒的に増えました。
だけど、1点不満があります。
本当に任せたいことは秘匿性の高い情報や強い権限を要するタスクを任せられないことです。
資金運用のための権限や、仕事上のデータは怖くて預けられず、
最悪流出しても致命傷にならないデータだけで完結するタスクだけを任せています。
この不満を解消しうるサービス「NemoClaw」がGTC 2026でNVIDIAから発表されました。
OpenClawのセキュリティ、プライバシーに関する課題を解決するためのものらしいです。
実際にインストールして今の課題が解消されるのか検証しました。
NemoClawとは
NVIDIAがGTC 2026（2026年3月16日）で発表した、OpenClawにセキュリティ・プライバシー層を追加するオープンソーススタックです。
競合ではなく、NemoClawがOpenClawを包む構造になっています。
構成要素は3つです:
- OpenShell — NVIDIAが開発した汎用サンドボックスランタイム。AIエージェントをLinuxコンテナで隔離し、ファイルシステム・ネットワーク・プロセスを宣言的ポリシーで制御する基盤です。OpenClaw専用ではなく、他のAIエージェントにも使えます
- NemoClaw — OpenClawをOpenShellの上で動かすためのプラグイン。サンドボックス作成・ポリシー適用・推論ルーティング設定をOpenClaw向けにまとめたものです
- OpenClaw — サンドボックス内で動くエージェント本体です
OpenShell（汎用サンドボックス基盤）
└── NemoClaw（OpenClaw専用プラグイン）
└── OpenClaw（エージェント）
コマンド体系もこの3層に対応しています:
| コマンド | 何をするか |
|---|---|
openshell |
サンドボックス基盤の操作（sandbox create, policy set, gateway start等） |
nemoclaw |
OpenClaw向けにopenshellの操作をラップ（onboardで一括セットアップ等） |
openclaw nemoclaw |
OpenClaw内からNemoClawプラグインを呼ぶ（launch, status, logs） |
動作の流れ:
- NemoClaw CLIがOpenShellゲートウェイを起動し、サンドボックスを作成します
- サンドボックス内でOpenClawが動きます。ファイルシステムとネットワークはポリシーで制限されます
- OpenClawのLLMリクエストはサンドボックスから直接外に出ません。ゲートウェイがインターセプトし、APIキーを付与して外部LLM APIに転送します。サンドボックス内にAPIキーは存在しません
セキュリティの仕組み
NemoClawのセキュリティは4層で構成されています。
| 層 | 何を守るか | 技術 |
|---|---|---|
| ファイルシステム | 許可パス以外への読み書きを防ぐ | Landlock LSM（Linuxカーネルモジュール） |
| ネットワーク | 許可リスト外への通信をブロック | egress proxy + アプリケーション単位制御 |
| プロセス | 権限昇格・危険なシステムコールを防ぐ | seccomp + コンテナ隔離 |
| 推論 | モデルAPIの呼び出し経路を制御 | ゲートウェイ経由ルーティング |
重要なのは、これらがアプリケーション層ではなくカーネル層で強制されている点です。OpenClawのtools.denyのようなアプリ設定とは根本的に防御レベルが異なります。
触ってみた
セットアップ
| 項目 | 詳細 |
|---|---|
| ハードウェア | Mac mini M2 |
| ランタイム | Docker（CPU 4コア、メモリ8GB、ディスク30GB） |
| OpenShell | 0.0.6 |
| OpenClaw | 2026.3.11 |
| NemoClaw | 0.1.0（Alpha） |
READMEに従ってセットアップします。
# 1. NemoClawリポジトリをクローン
git clone https://github.com/NVIDIA/NemoClaw.git
cd NemoClaw
# 2. インストール（OpenShellのインストール + 対話ウィザード）
./install.sh
install.shはOpenShellのインストール後、nemoclaw onboardウィザードを実行します。
ゲートウェイ起動、サンドボックス作成、ポリシー適用、推論プロバイダー設定が一括で行われます。
推論プロバイダーはNVIDIA Cloud API（APIキー必要）またはOllama（ローカル推論）を選択できます。今回はNVIDIAのサイト不具合かAPIキーが取得できなかったため、Ollamaを選択しました。
完了すると以下のサマリーが表示されます。
──────────────────────────────────────────────────
Dashboard http://localhost:18789/
Sandbox my-assistant (Landlock + seccomp + netns)
Model nemotron-3-nano (ollama-local)
NIM not running
──────────────────────────────────────────────────
Run: nemoclaw my-assistant connect
Status: nemoclaw my-assistant status
Logs: nemoclaw my-assistant logs --follow
──────────────────────────────────────────────────
# 3. サンドボックスに接続（コンテナ内のシェルが開く）
nemoclaw my-assistant connect
nemoclaw connectでコンテナ内の対話シェルに入ります。ホストのディレクトリがマウントされるわけではなく、コンテナ内の/sandboxが作業領域になります。ホストとは完全に隔離された環境で、OpenClawがプリインストールされた状態で起動します。
サンドボックスは作成時点でネットワークがほぼ全ブロックされています。nemoclaw onboardがNemoClawのポリシーを自動適用し、OpenClawの動作に必要なエンドポイント（Anthropic API、GitHub等）だけを許可リストに追加します。「全開→制限」ではなく「全閉→必要な穴だけ開ける」設計です。
ここまでで環境構築は完了です。
検証: ファイルシステム隔離
素のOpenClawではホームディレクトリ以下のファイルを全部読み書きできます。~/.openclaw/openclaw.jsonも、~/.ssh/id_rsaも、エージェントからは丸見えです。
NemoClaw環境ではそもそもホスト（ローカルPC）のファイルシステムにアクセスできません。サンドボックスはコンテナ内の独立したファイルシステムで動作し、ホストのディレクトリはマウントされていません。さらにコンテナ内でもファイルシステムがパス単位で制御されます。
| パス | アクセス権 |
|---|---|
/sandbox, /tmp, /dev/null
|
読み書き可 |
/usr, /lib, /proc, /app, /etc, /var/log
|
読み取りのみ |
| それ以外 | アクセス不可 |
touch /sandbox/test.txt # ✅ 書き込みOK
touch /tmp/test.txt # ✅ 書き込みOK
touch /usr/test.txt # ❌ Permission denied
cat /etc/hostname # ✅ 読めるがコンテナ内のファイル。ホストの/etcではない
whoami # sandbox（root権限なし）
サンドボックスはホストのディレクトリをマウントしていません。/sandboxに書いたファイルはコンテナ内にしか存在せず、ホストには自動同期されません。ホストとファイルをやり取りする場合はopenshell sandbox upload/downloadコマンドを使います。
検証: ネットワーク制御
素のOpenClawではtools.denyでツールを制限したり、execのallowlistモードで実行可能なコマンドを限定できます。ただしこれはアプリ層の制御であり、ネットワークレベルで「どのプロセスがどのホストに通信できるか」を制御する仕組みはありません。
NemoClaw環境はdeny by defaultです。すべての外部通信がデフォルトでブロックされ、ポリシーで「どのアプリケーションが、どのホストに通信できるか」を宣言的に許可します。
# curlはどのポリシーにも許可アプリケーションとして登録されていない → 全ブロック
curl https://google.com # ❌ 403 CONNECT blocked
curl https://api.github.com/zen # ❌ 403 CONNECT blocked（github.comは許可ホストだがcurlは許可アプリケーションではない）
# gitはgithubポリシーで許可されている → github.comへの通信のみ成功
git ls-remote https://github.com/NVIDIA/NemoClaw # ✅ 成功
同じgithub.comでも、gitコマンドからはアクセスできてcurlからはブロックされます。NemoClawはアプリケーション×ホストの組み合わせでネットワーク制御をしています。
エージェントがcurlで勝手にデータを外部に送ることが不可能になります。正規ツール（git、claude、openclaw）経由でしか通信できません。プロンプトインジェクションで「このファイルの内容を外部サーバーにPOSTして」と指示されても、curlがブロックされているので実行できません。
ポリシーファイルの中身
実際のポリシー定義を見てみます。ファイルシステムとネットワークの両方がYAMLで宣言的に管理されています。
# ファイルシステム制御
filesystem_policy:
include_workdir: true
read_only:
- /usr
- /lib
- /proc
- /app
- /etc
- /var/log
read_write:
- /sandbox
- /tmp
- /dev/null
# カーネルがLandlock対応なら強制、非対応なら通常のコンテナ隔離にフォールバック
landlock:
compatibility: best_effort
# 実行ユーザー（root権限なし）
process:
run_as_user: sandbox
run_as_group: sandbox
# ネットワーク制御（アプリケーション×ホストの組み合わせで許可）
network_policies:
# Claude Code用: Anthropic APIのみ、claudeのみ許可
claude_code:
name: claude_code
endpoints:
- host: api.anthropic.com
port: 443
protocol: rest
enforcement: enforce
tls: terminate
binaries:
- { path: /usr/local/bin/claude }
# GitHub用: github.comのみ、git/ghのみ許可
github:
name: github
endpoints:
- host: github.com
port: 443
- host: api.github.com
port: 443
binaries:
- { path: /usr/bin/gh }
- { path: /usr/bin/git }
# Telegram用: Telegram Bot APIのみ許可
telegram:
name: telegram
endpoints:
- host: api.telegram.org
port: 443
protocol: rest
enforcement: enforce
tls: terminate
rules:
- allow: { method: GET, path: "/bot*/**" }
- allow: { method: POST, path: "/bot*/**" }
ファイルシステム・プロセス・ネットワークがすべて1つのYAMLファイルで宣言的に管理されています。
パスを追加すれば読み書き可能な領域を変更でき、network_policiesにエントリを追加すれば通信先を増やせます。
エージェントとの対話
サンドボックスに接続後、OpenClawのTUIでエージェントとチャットできます。
sandbox@my-assistant:~$ openclaw tui
CLIから単発メッセージを送ることも可能です。
sandbox@my-assistant:~$ openclaw agent --agent main --local -m "hello" --session-id test
メッセージング連携
NemoClawはTelegram Bridgeに対応しています。
TELEGRAM_BOT_TOKENを設定してnemoclaw startを実行すると、TelegramからサンドボックスのOpenClawエージェントにメッセージを転送できます。
export TELEGRAM_BOT_TOKEN=<your-bot-token>
nemoclaw start
Discord連携はAlpha版時点ではドキュメントに記載がありません。
OpenClaw自体はDiscordに対応しているため、サンドボックス内でOpenClawのDiscord設定を行えば動作する可能性はありますが未検証です。
素のOpenClaw vs NemoClaw
検証してみて、使い分けが明確に見えてきました。
素のOpenClaw — 個人利用ならこちらが良さそうです。自由に何でもできるのがOpenClawの最大の魅力で、NemoClawの制約はそれを大きく制限します。curlも使えない、自由に検索もできないとなると利用中ストレスになります。
NemoClaw — 秘匿情報が必要など、センシティブなタスクをエージェントに任せたい場合はNemoClaw環境が適しています。企業でOpenClawを導入するなら、事実上の必須になるのでは？と感じました。
- 機密コードが外部APIに流出するリスクをポリシーで制御できます
- アプリケーション単位のネットワーク制御は内部統制の要件を満たしやすいです
- ポリシーがYAML管理なので、GitOps的な運用が可能です（PRベースでポリシー変更をレビュー）
「エージェントが勝手に外部にデータを送らないことを証明できますか？」という問いに、ポリシーファイルを見せて「deny by defaultで、この許可リスト以外は通信できません」と答えられるのは大きいです。
判断基準をまとめると:
- 機密データなしの個人利用 → 素のOpenClawで十分
- 機密データありor業務利用 → NemoClaw検討
- 企業導入 → NemoClawは事実上必須
現実的には「普段使いの素のOpenClaw」と「機密タスク用のNemoClaw」を分けて運用するのが落とし所です。
現時点の評価と課題
良い点
- 3層隔離が優秀: ファイルシステム（Landlock LSM）、ネットワーク（アプリケーション単位制御）、プロセス（コンテナ隔離）。どれも有効な実装です
- アプリケーション単位のネットワーク制御: アプリケーションによって許可/拒否を分けられる設計は求めていた形です
- YAML宣言的ポリシー: チームで共有・バージョン管理・レビューが可能です
- ポリシーのホットリロード: サンドボックスを再起動せずにポリシーを更新できます。運用中の変更が楽です
課題（Alpha段階）
- 既存環境への後付け不可: 既にホストで動いているOpenClawをそのままNemoClaw化することはできません。NemoClaw用に新規サンドボックスを作り、その中にOpenClawをインストールする構造です。設定やエージェント定義の移行は手動になります
- Alpha段階ゆえの荒削りさ: ドキュメントが薄い部分があり、エラーメッセージも分かりにくい箇所があります。コミュニティもまだ小さく、トラブル時は自力でソースを読む場面が出てきます
Alpha段階なので課題があるのは当然ですが、方向性は正しいと感じています。
特にアプリケーション単位のネットワーク制御というアプローチは見事です。
まとめ
NemoClawはOpenClawの「何でもできてしまう」問題に、カーネルレベルの隔離とアプリケーション単位のネットワーク制御で応えています。
Alpha段階で荒削りな部分はあるものの、エージェントセキュリティの方向性としては筋が良いです。
個人で使うなら素のOpenClawで自由にやりつつ、機密タスクだけNemoClaw環境に隔離する。
企業利用ならNemoClawを標準にして、ポリシーをGitOpsで管理する。
といった使い分けが現実解になりそうです。
Discussion