NemoClaw — NVIDIAがOpenClawにエンタープライズセキュリティを実装した

nemoclaw init --model local:nemotron-3-nano-4b --policy strict

先週のGTC 2026キーノートで、ジェンスン・ファンがこの1行をライブで実行しました。「ダウンロードすればAIエージェントが作れます」という説明とともに。188Kスターを獲得したOpenClawをNVIDIAがエンタープライズ向けにラップしたプロジェクト、NemoClawの登場です。

正直、最初に聞いた時の反応は「またラッパーか」でした。OpenClawの上にセキュリティレイヤーを1つ載せてNVIDIAブランドを貼っただけではないかと思いました。しかし実際の構造を見てみると、思った以上に企業環境で必要な部分を的確に押さえていました。

OpenClawのエンタープライズ課題

OpenClawをチームで使ったことがある方なら分かると思いますが、個人利用には優れていても、企業で使おうとするといくつかの壁にぶつかります。

第一に、データ漏洩リスク。OpenClawエージェントが外部APIを呼び出す際、内部データがモデル提供者のサーバーに送信される可能性があります。第二に、ポリシー制御の欠如。エージェントが何をしてよくて何をしてはいけないかというガバナンスが事実上ありません。第三に、監査ログ。エージェントがどのようなアクションを取ったかを追跡するのが困難です。

私たちのチームでもOpenClawを内部ツールとして検討しましたが、セキュリティチームから「外部モデル呼び出し時にデータがどこに行くか保証できない」という理由で保留になったことがあります。同じような経験をしたチームは少なくないでしょう。

NemoClawが追加するもの

NemoClawの核心は3つです。

1. ローカルモデル優先アーキテクチャ

エージェントが使用するLLMをローカルで実行できます。Nemotron 3 Nano 4BやNemotron 3 Super 120BといったNVIDIA独自モデルだけでなく、Qwen 3.5やMistral Small 4もサポートしています。クラウドモデルを使う場合も、プロキシレイヤーを経由することで内部データが外部に露出しないよう隔離されます。

2. ポリシーエンジン（Policy Engine）

エージェントの行動範囲をYAMLで定義できます。

# nemoclaw-policy.yaml
agent:
  allowed_tools:
    - file_read
    - web_search
    - code_execution
  blocked_tools:
    - file_delete
    - system_command
  data_policy:
    pii_detection: true
    external_api_allowlist:
      - api.github.com
      - api.slack.com
  audit:
    log_level: detailed
    retention_days: 90

これは私としてはかなり実用的だと思います。エージェントに「これはやっていい、これはダメ」と宣言的に定義できるということは、セキュリティチームとの会話をはるかに具体的にしてくれます。「エージェントを導入したいのですが大丈夫でしょうか？」より「このポリシーファイルに基づいてエージェントが動作します」の方がはるかに説得力があります。このような宣言的なガバナンスはNemoClawだけの動きではなく、ADL（Agent Definition Language）のように業界全体でエージェントガバナンスの標準化が進んでいる点も合わせて注目しておきたい。

3. 監査ログとオブザーバビリティ

すべてのエージェントアクションが構造化されたログとして残ります。誰が（どのエージェントが）、いつ、どのツールを、どのデータとともに呼び出したか。既存のSIEMやモニタリングシステムとの連携もサポートしています。

ハードウェアアグノスティックという主張

NVIDIAが興味深いポジショニングを取りました。NemoClawはNVIDIAハードウェアが必須ではないとのことです。AMD GPUでもCPUでも動作するとされています。

私はこの部分が少し疑わしいと思っています。もちろん技術的には可能でしょうが、ローカルモデルの性能最適化がCUDAベースで行われているはずなので、非NVIDIA環境で実用的な性能が出るかどうかは様子を見る必要があります。「サポートする」と「うまく動く」は別の話ですから。DGX SparkでNemoClawのデモを見せたのも偶然ではないでしょう。

OpenClaw vs NemoClaw 比較

項目	OpenClaw	NemoClaw
対象ユーザー	個人・開発者	企業・チーム
モデル実行	ローカル + クラウド	ローカル優先、クラウドはプロキシ経由
ポリシー制御	なし	YAMLベースのポリシーエンジン
監査ログ	基本的	構造化された監査ログ + SIEM連携
PII検出	なし	内蔵
インストール	openclaw install	nemoclaw init（OpenClaw含む）
成熟度	プロダクション利用中	アルファ段階
ライセンス	Apache 2.0	Apache 2.0

アルファという現実

最も重要なのはこれです。NemoClawはまだアルファ段階であり、NVIDIAもこれを明示しています。

GTCキーノートの華やかなデモと「1行でエージェント作成」というメッセージに興奮しがちですが、プロダクションにすぐ投入できる状態ではありません。ポリシーエンジンのエッジケース処理、大規模エージェントフリート管理、マルチテナンシーサポートといったエンタープライズ必須機能がまだロードマップ上にあります。

個人的にはポリシーエンジンの方向性に期待しています。今はシンプルなallowlist/bloclistレベルですが、これが「特定の条件でのみ特定のツールを許可」といった条件付きポリシーに発展すれば、実務でかなり強力になり得ます。たとえば「業務時間内のみ外部API呼び出しを許可」や「シニアエンジニアのエージェントのみプロダクションDBへのアクセス可能」といったシナリオです。

エンジニアリングチームにとっての意味

NemoClawが成熟すれば、エージェント導入の最大の障壁だった「セキュリティチームの説得」がかなり楽になる可能性があります。ポリシーファイル1つでエージェントの行動範囲を定義し、監査ログで事後追跡が可能だということは、コンプライアンス要件を満たす明確な道筋ができるということです。

ただし、今すぐNemoClawを導入すると決めるよりは、ポリシーファイルの設計を先に始めることが現実的です。AIエージェント導入の実際のコストを考えると、ガバナンス不備による事故一件が数ヶ月分の費用を超えることもあります。チームのエージェントがどのツールにアクセスすべきで、どのデータには触れてはいけないかを整理しておけば、NemoClawであれ他のソリューションであれ、導入時にすぐ適用できます。Anthropicのエージェントスキル構造化アプローチはツール権限設計を考える上で実践的な参考になります。

ジェンスン・ファンがエージェントを「次のコンピューティングプラットフォーム」と呼んだのは誇張かもしれません。しかし、エージェントが個人ツールから企業インフラへ移行するにはNemoClawのようなガバナンスレイヤーが必ず必要だというのは正しい指摘です。問題はスピードで、アルファからプロダクションレディまでNVIDIAがどれだけ速く到達できるかが鍵です。