NVIDIA OpenShellとは？特徴やセキュリティ設計、使い方を解説

「AIエージェントを社内で動かしたいが、データ流出や権限昇格のリスクが心配」「Claude CodeやCodexをチームで使うとき、セキュリティポリシーをどう適用すればいい？」
NVIDIA OpenShellは、自律型AIエージェントをサンドボックス環境で安全に実行するためのオープンソースランタイムです。ファイルシステム・ネットワーク・プロセス・推論の各レイヤーにポリシーベースのガードレールを適用し、エージェントに必要なアクセス権だけを付与する設計になっています。
本記事では、OpenShellの基本概念からセキュリティ設計、インストール手順、対応エージェント、NemoClawやAgent Toolkitとの違い、料金・ライセンス、注意点まで、2026年3月時点の公式情報にもとづいて解説します。

NVIDIA OpenShellとは？

NVIDIA OpenShellは、自律型AIエージェントをサンドボックス環境で安全に実行するためのオープンソースランタイムです。2026年3月16日のGTC 2026で発表され、Apache 2.0ライセンスのもとでGitHubに公開されています。コミュニティ向けのエコシステム（サンドボックスイメージ、サンプル等）はOpenShell-Communityリポジトリで別途管理されています。

AIエージェントが自律的にコードを書き、ファイルを操作し、外部APIを呼び出す時代において、「エージェントに何をさせるか」だけでなく「何をさせないか」を制御する仕組みが不可欠になっています。OpenShellは、エージェントとインフラストラクチャの間に入り、カーネルレベルの隔離とYAMLベースの宣言的ポリシーによって、エージェントの行動範囲を明確に制御します。

NVIDIAの公式テクニカルブログでは、OpenShellを「エージェントの実行方法、参照・操作できる範囲、推論の送信先を統制するガバナンスレイヤー」と説明しています。

NemoClaw・Agent Toolkitとの違い

OpenShellは、NVIDIAが展開するAIエージェント関連プロダクトの中でセキュリティランタイムとして位置づけられています。名前が似た製品が複数あるため、ここで関係を整理しておきます。

以下の表で、3つの製品の役割と対象範囲を整理しました。

つまり、Agent Toolkitがエージェント開発の全体フレームワーク、OpenShellがそのセキュリティ実行基盤、NemoClawがOpenClaw向けにOpenShellを組み込んだ特化パッケージ、という関係です。

OpenShellはNemoClawの内部でも使われていますが、OpenShell単体でも利用可能であり、Claude CodeやCodexなどOpenClaw以外のエージェントも実行できます。ただし、公式ポリシーの完成度はエージェントごとに異なり、Claude Codeは即利用しやすい一方、CodexやOpenCodeは追加のポリシー設定が前提になります（詳細は後述）。

なぜNVIDIA OpenShellが必要なのか

AIエージェントの能力が向上するにつれ、セキュリティリスクも急速に拡大しています。ここでは、OpenShellが解決する3つの構造的課題を整理します。

エージェントの自律性がもたらすリスク

Claude CodeやCodex、OpenClawのような自律型コーディングエージェントは、ファイルの読み書き、シェルコマンドの実行、外部APIの呼び出しを自分で判断して行います。これは開発効率を劇的に高める一方で、以下のリスクを伴います。

• データ流出
  エージェントが意図せず機密ファイルを外部エンドポイントに送信する可能性

• 認証情報の漏洩
  APIキーやSSH鍵など、ファイルシステム上の認証情報への不正アクセス

• 権限昇格
  エージェントが自身の権限を超えた操作（root権限の取得など）を試みる

• 不正な推論ルーティング
  プロンプトインジェクション攻撃により、推論リクエストが意図しないモデルやエンドポイントに送られる

従来のコンテナだけでは不十分

「Dockerコンテナで隔離すれば安全」と考えるかもしれませんが、AIエージェントのセキュリティにはコンテナ単体では対応しきれない課題があります。

通常のコンテナはプロセス・ファイルシステムの隔離を提供しますが、エージェントがどのURLに接続してよいか、どのモデルに推論を送ってよいかを宣言的に制御する仕組みは持っていません。また、エージェント内部のプロンプトインジェクション攻撃でセキュリティ設定そのものが書き換えられるリスクもあります。

OpenShellは、コンテナの上にさらにアウトオブプロセス型ポリシー適用（エージェントプロセスの外側でポリシーを強制する仕組み）を重ねることで、エージェント内部からのポリシー回避を構造的に防いでいます。

企業のコンプライアンス要件への対応

企業がAIエージェントを本番環境に導入するには、「エージェントが何をしたか」を証跡として残し、監査できる体制が求められます。

OpenShellは、すべてのアクション（許可・拒否）の完全な監査証跡を記録する機能を内蔵しています。YAMLポリシーファイルをバージョン管理システム（Git等）で管理すれば、「いつ・誰が・どのポリシーを適用したか」をコンプライアンス監査に使える形で残すことが可能です。

NVIDIA OpenShellのセキュリティ設計

OpenShellの核心は、エージェントの行動範囲を複数のレイヤーで制御する多層防御アーキテクチャにあります。ここでは、OpenShellを構成する4つのコンポーネントと、各保護レイヤーの仕組みを解説します。

4つのコアコンポーネント

OpenShellは、以下の4つのコンポーネントで構成されています。

• ゲートウェイ
  サンドボックスのライフサイクル（作成・停止・削除）を管理するコントロールプレーンAPIです。認証境界を構成し、プラットフォーム全体のリクエストを仲介します。内部実装はK3s Kubernetesクラスタ（単一Dockerコンテナ内で動作）です。

• サンドボックス
  エージェントが実行される隔離環境です。コンテナ監視とポリシー適用型の通信経路制御を含み、エージェントはホスト環境に直接触れることなく動作します。

• ポリシーエンジン
  ファイルシステム・ネットワーク・プロセスの各レイヤーにわたる制約を定義・実施するコンポーネントです。バイナリレベルでの制御が可能で、「検証済みスキルはインストールできるが、未レビューのバイナリは実行できない」といった細かな制御を実現します。

• プライバシールーター
  LLM推論のルーティングを制御するコンポーネントです。機密性の高いコンテキストをローカルのオープンモデル（NVIDIA Nemotronなど）に保持しつつ、必要に応じてClaudeやGPTなどのフロンティアモデルにルーティングする、といったポリシーベースの振り分けが可能です。

保護レイヤーの仕組み

OpenShellは、ファイルシステム・ネットワーク・プロセス・推論の各レイヤーに保護機構を設けています。以下の表で、各レイヤーの保護内容と適用タイミングを整理しました。

この設計で重要なのは、静的ポリシーと動的ポリシーが分離されている点です。ファイルシステムとプロセスの制約はサンドボックス作成時にロックされ、実行中に変更できません。一方、ネットワークと推論のポリシーは実行中にホットリロードが可能で、運用状況に応じて柔軟に調整できます。

デフォルト拒否の原則

OpenShellのセキュリティモデルは**Deny-by-default（デフォルト拒否）**を採用しています。エージェントはゼロ権限の状態から開始し、YAMLポリシーで明示的に許可されたリソースのみにアクセスできます。

この「許可リスト方式」により、設定の漏れが発生した場合でも、エージェントの行動範囲が意図せず広がることを防ぎます。

バックオフィス業務をAIで自動化 AI Agent Hub

Microsoft Teams上でAIエージェントが業務を代行

経費精算・請求書処理をAIが自動実行。Microsoft Teams上でAIエージェントが業務を代行し、金融機関レベルのセキュリティで安心導入。

▶ 無料で資料をダウンロード

NVIDIA OpenShellの使い方

OpenShellの導入は、Dockerが動作する環境であれば2つのコマンドで完了します。ここでは、インストールからサンドボックスの作成、ポリシー設定までの基本的な流れを解説します。

システム要件

OpenShellの動作に必要な環境は以下のとおりです。

GPUはOpenShellの動作自体には必須ではありません。ローカルでの推論にGPUを使いたい場合にのみ、NVIDIAドライバとContainer Toolkitが必要になります。

インストール手順

OpenShellのインストールには、バイナリ（推奨）とPyPI経由の2つの方法があります。

バイナリインストール（推奨）

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

PyPI経由（uv必須）

uv tool install -U openshell

いずれもDockerが起動している必要があります。ゲートウェイは初回使用時に自動で作成されるため、追加の設定は不要です。

サンドボックスの作成と操作

OpenShellの基本操作は、サンドボックスの作成・接続・管理の3つです。以下の表で主要なCLIコマンドを整理しました。

サンドボックスにはデフォルトでPython 3.13、Node.js 22、gh、git、vim、nanoなどの開発ツールが含まれています。サンドボックスイメージは4種類用意されており、base（基本環境）、ollama（ローカルLLM + Claude Code/Codex/OpenCode同梱）、sdg（合成データ生成ワークフロー用）、openclaw（OpenClaw操作用）から用途に応じて選択します。GPU対応のサンドボックスを作成する場合は --gpu フラグを追加します。

openshell sandbox create --gpu --from [gpu-enabled-sandbox] -- claude

YAMLポリシーの設定

OpenShellのポリシーはYAML形式で宣言的に記述します。ポリシー適用前はすべての外部通信がブロックされ、ポリシーで明示的に許可したエンドポイントのみにアクセスが開放される仕組みです。

以下は、ポリシーの適用と動作確認の流れです。

# 1. サンドボックスを作成（この時点では外部通信はすべてブロック）
openshell sandbox create

# 2. サンドボックス内から外部接続を試みる → ブロックされる
sandbox$ curl -sS https://api.github.com/zen
# curl: (56) Received HTTP code 403 from proxy after CONNECT

# 3. ホスト側からポリシーを適用（ホットリロード対応）
openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait

# 4. ポリシー適用後、GETリクエストは許可される
sandbox$ curl -sS https://api.github.com/zen
# Anything added dilutes everything else.

この例のように、ネットワークポリシーはサンドボックスの再作成なしにホットリロードで更新できます。本番運用中にアクセス先を追加・変更する場合も、エージェントを停止させる必要はありません。

NVIDIA OpenShellで何ができるか

OpenShellの技術的な仕組みを理解したところで、実際にどのような場面で活用できるのかを整理します。

対応エージェント

OpenShellは、主要なAIコーディングエージェントをサポートしています。以下の表で、対応エージェントとポリシーカバレッジの関係を整理しました。

ポリシーカバレッジの違いは実務上重要です。Claude Codeは公式ポリシーが完備されており、APIキーを渡すだけで即座にサンドボックス内で動作します。一方、CodexやOpenCodeはデフォルトではポリシーが用意されていないか部分的にしかカバーされていないため、利用するエンドポイントやバイナリパスをYAMLポリシーに追加定義する必要があります。

いずれのエージェントも、既存のコードを変更することなくOpenShell上で実行できます。エージェント側にOpenShell用の改修は不要で、サンドボックスの外側からポリシーが適用される設計です。

デプロイメントモード

OpenShellは、ローカル・リモート・クラウドの3つのデプロイメントモードに対応しています。

• ローカル
  開発者のワークステーション上でDocker内にゲートウェイを実行するモードです。個人の開発環境やPoC（概念実証）に向いています。

• リモート
  SSH経由でリモートホスト上のDocker内で実行するモードです。NVIDIA DGX Spark、DGX Station、RTX GPU搭載のPCなどで、GPUリソースを活用したサンドボックスを構築できます。Brevクラウドインスタンス（CPU-onlyまたはNVIDIA H100）も用意されており、環境構築なしでOpenShellを試すことも可能です。

• クラウド
  リバースプロキシの背後にOpenShellゲートウェイを置く構成です。現行ドキュメントでは、主に個人ユーザーがクラウドVM越しにOpenShellを利用する想定であり、共有チームアクセス向けの用途はまだ前提とされていません。現時点ではローカル・リモートが主な選択肢です。

# リモートモードの例：DGX Spark上にサンドボックスを作成
openshell sandbox create --remote spark --from openclaw

活用シナリオ

OpenShellの代表的な活用シナリオは以下のとおりです。

• セキュアなコーディングエージェント環境
  Claude CodeやCodexを社内の開発チームに展開する際に、ファイルアクセスやネットワーク通信を制限した状態で運用できます。sdg（合成データ生成）サンドボックスを使えば、エージェントにデータ生成ワークフローを安全に実行させることもできます。

• プライベート推論ルーティング
  機密性の高いソースコードを扱う場合に、推論リクエストをローカルのNemotronモデルやOllama経由で処理し、外部クラウドへのデータ送信を防ぐことが可能です。

• コンプライアンス監査
  YAMLポリシーファイルをGitで管理し、すべてのエージェントアクションの監査証跡をログとして保持することで、社内のセキュリティ監査要件に対応できます。

• 既存セキュリティ統制との組み合わせ
  OpenShellはポリシー適用・サンドボックス隔離・推論ルーティングを担うため、企業の既存セキュリティツールと組み合わせやすい設計になっています。YAMLポリシーとログをSIEMやセキュリティ監視基盤に連携すれば、エージェントの行動をセキュリティ運用の中に組み込むことが可能です。

NVIDIA OpenShellの料金体系とライセンス

OpenShellはオープンソースソフトウェアであり、Apache License 2.0のもとで公開されています。商用利用を含め、無償で利用できます。

ソフトウェアコスト

OpenShell自体に課金は発生しませんが、Dockerのライセンス条件は組織規模によって異なる点に注意が必要です。

推論コスト

OpenShellで実行するエージェントが外部のLLM APIを利用する場合、そのAPI利用料は別途発生します。

• Claude Code Anthropic APIの利用料（入力・出力トークン単位の従量課金）、またはClaude Pro/Maxプランの月額料金
• Codex OpenAI APIの利用料
• Ollama / Nemotron（ローカル推論） API利用料は不要だが、GPU搭載マシンの電力・ハードウェアコストが発生

プライバシールーターを活用して機密性の低いタスクをローカルモデルに振り分ければ、外部API利用料を削減しつつデータの外部送信も防ぐことができます。

ハードウェアコスト

GPUを利用する場合、NVIDIAが対応環境として挙げているのはDGX Spark、DGX Station、RTX GPU搭載PCです。ただし、GPU はOpenShellの動作自体には必須ではなく、ローカル推論を行わない構成であればGPUなしの環境でも利用可能です。

バックオフィス業務をAIで自動化 AI Agent Hub

Microsoft Teams上でAIエージェントが業務を代行

経費精算・請求書処理をAIが自動実行。Microsoft Teams上でAIエージェントが業務を代行し、金融機関レベルのセキュリティで安心導入。

▶ 無料で資料をダウンロード

NVIDIA OpenShellの注意点と現時点の制限

OpenShellは2026年3月に公開されたばかりの製品であり、導入を検討する際にはいくつかの制約を理解しておく必要があります。

バージョンとステータス

2026年3月18日時点では、GitHubのlatest releaseはv0.0.10です。公式には**Alpha software（アルファ版）**であり、シングルプレイヤーモード（1人の開発者が1つの環境で使う想定）とされています。APIやCLIインターフェースの仕様は今後変更される可能性があるため、プロダクション環境への導入は慎重に判断する必要があります。

公開直後のプロジェクトであり、コアエンジン（NVIDIA/OpenShell）・コミュニティエコシステム（NVIDIA/OpenShell-Community）ともに実績はまだ限定的です。長期的な安定性については蓄積を待つ段階です。

プラットフォーム対応の差異

前述のシステム要件で触れたとおり、**Windowsサポートは実験的（Experimental）**です。WSL 2 + Docker Desktopの構成で動作しますが、Linux / macOSと同等の安定性は保証されていません。

また、LinuxカーネルのセキュリティモジュールであるLandlock LSMは推奨要件であり、対応していないカーネルバージョンではファイルシステム保護の一部が制限される可能性があります。

Docker依存

OpenShellはDocker上で動作するため、Dockerの導入が前提条件です。企業によっては、セキュリティポリシー上Dockerの利用が制限されているケースがあり、その場合はOpenShellの導入自体が困難になります。

GPU利用時の追加要件

GPU対応のサンドボックスを構築する場合、NVIDIAドライバに加えてNVIDIA Container Toolkitのインストールが必要です。ドライババージョンの互換性やContainer Toolkitのセットアップに追加の作業が生じる点は留意しておくべきでしょう。

ポリシー設計のスキル

OpenShellのセキュリティはYAMLポリシーの設計に大きく依存します。ポリシーが甘すぎればセキュリティが確保できず、厳しすぎればエージェントの動作に支障が出ます。効果的なポリシー設計には、エージェントの動作パターンとネットワーク通信先を理解した上での設計スキルが求められます。

公式ドキュメントにはクイックスタート用のポリシー例が用意されていますが、本番運用向けのポリシーテンプレートやベストプラクティスの充実は今後の課題です。

まとめ

本記事では、NVIDIA OpenShellの基本概念からセキュリティ設計、インストール手順、活用シナリオ、料金・ライセンス、注意点まで解説しました。

OpenShellが提供する価値は、以下の3点に集約されます。

1. AIエージェントのためのセキュリティランタイム
   ファイルシステム・ネットワーク・プロセス・推論の各レイヤーにカーネルレベルの隔離とポリシー制御を適用し、Deny-by-defaultの原則でエージェントの行動範囲を制御します。

2. エージェント非依存のオープン設計
   Claude Code・Codex・OpenCode・OpenClawなど主要エージェントをOpenShell上で動かせますが、公式ポリシーの完成度にはエージェントごとに差があります。エージェント側のコード変更は不要で、Apache 2.0ライセンスにより商用利用も無償です。

3. 既存セキュリティ体制との親和性
   ポリシー適用・サンドボックス隔離・推論ルーティングの各機能が分離されているため、企業の既存セキュリティ統制と組み合わせやすい構造になっています。

次のステップ

AIエージェントのセキュリティ対策を検討している企業には、以下のアプローチを推奨します。

• ステップ1 Docker環境を準備し、OpenShellをインストール。まずはClaude CodeやCodexの小規模なサンドボックスで動作を確認
• ステップ2 自社のセキュリティ要件にもとづいてYAMLポリシーを設計。アクセス可能なファイルパス・ネットワーク先・推論エンドポイントを定義
• ステップ3 開発チームのパイロット運用を開始し、監査ログの蓄積とポリシーの調整を実施
• ステップ4 自社のセキュリティ監視基盤との連携（ログ連携・SIEM統合等）を検討し、本格展開へ移行

OpenShellはまだv0.0.10のアルファ段階にありますが、NVIDIAがGTC 2026で正式発表し、Agent ToolkitやNemoClawのセキュリティ基盤として位置づけている点は、AIエージェントのセキュリティランタイムという新しいカテゴリが立ち上がりつつあることを示しています。早期に技術を理解し、PoC環境で検証を始めておくことが、今後のAIエージェント本番運用への備えになるでしょう。

【関連記事】

• NVIDIA NemoClawとは？特徴や導入手順、料金を解説
• NVIDIA Agent Toolkitとは？主要機能や導入事例、料金を解説
• OpenClaw（旧Clawdbot）とは？初期設定・使い方・料金・セキュリティを解説
• Claude Codeとは？主な特徴や使い方、料金体系・拡張機能まで徹底解説
• DevContainerとは？Claude Code開発を安全かつ効率的に始める方法を解説