NVIDIA OpenShell とは？AIエージェントを安全に動かすサンドボックスのクイックスタート
リード
NVIDIA OpenShell（オープンシェル）とは、AIエージェントをサンドボックス内で安全に動かすためのオープンソースの実行環境（ランタイム）である。エージェントにホストのファイルや認証情報を直接触らせず、外部ネットワークへのアクセスを宣言的なポリシーで制御し、許可・拒否された操作をログで追跡できる。
本記事は、Claude Code などのコーディングエージェントを安全に試行錯誤させたい開発者・情シス担当に向けて、OpenShell のインストールから最初のサンドボックス作成、ポリシーによるアクセス制御までを、公式ドキュメント（github.com/NVIDIA/OpenShell、Apache 2.0 ライセンス）に沿って手順で解説する。読み終えると、エージェントをホスト環境から隔離して動かす最小構成を、自分の環境で再現できるようになる。
OpenShell は「自分の作業環境を書き換えながら動くエージェント」を前提に設計された、ポリシー駆動のサンドボックスだ。 まずは通常のコンテナとの違いと、何を守ってくれるのかを整理する。
通常のコンテナとの違い
Docker などの通常のコンテナは、アプリケーションを隔離して動かすことを主目的とする。一度ビルドしたイメージを起動し、その中でアプリを実行する——環境はおおむね静的だ。
一方で AIエージェントは、コードを書き、パッケージをインストールし、設定ファイルを書き換えながら、自分の作業環境そのものを変えていく。OpenShell はこの「環境を変えていくエージェント」を前提に、安全に試行錯誤できる隔離空間を用意する点が異なる。
具体的には、エージェントが必要とする操作だけを許可し、それ以外（ホストのファイル読み取り、認証情報へのアクセス、許可外への通信）を OS レベルで遮断する。コンテナが「アプリの隔離」に主眼を置くのに対し、OpenShell は「エージェントの権限の最小化」に軸足を置いている。
4つの保護ドメイン（ファイル・ネットワーク・プロセス・推論）
OpenShell の最大の特徴は、プロンプト（行動指示）でエージェントを律するのではなく、エージェントが動く環境そのものに制約を課す「アウトオブプロセス」の強制にある。制約はエージェントの外側で効くため、たとえエージェントが侵害されても自分で上書きできない。
公式ドキュメントは、防ぐべき脅威を4つ挙げ、それぞれに保護ドメイン（policy domain）を対応させている。
- Filesystem（ファイルシステム）: SSH 鍵やクラウド認証情報などの読み取り（認証情報の窃取）を防ぐ。Linux カーネルの Landlock で許可パス以外の読み書きを遮断し、サンドボックス作成時にロックされる。
- Network（ネットワーク）: ソースコードや社内ファイルの外部送信（データ持ち出し）を防ぐ。許可した宛先以外への外向き通信を拒否し、稼働中にホットリロードできる。
- Process（プロセス）:
sudoや setuid による権限昇格を防ぐ。非特権のプロセス ID と seccomp で危険なシステムコールを制限し、作成時にロックされる。 - Inference（推論）: 未承認のモデルプロバイダーへの送信を防ぐ。機密コンテキストをローカルのオープンモデルで手元に留め、ポリシーが許可したときだけ Claude や GPT などのフロンティアモデルへ振り向ける「privacy router（プライバシールーター）」として働く。
ポリシーは宣言的な YAML で記述し、静的な領域（filesystem・process）は作成時に固定、動的な領域（network・inference）は再起動なしで更新できる。
対応エージェントとライセンス
OpenShell は、特定のエージェントに依存しない汎用の実行環境として設計されている。公式のクイックスタートでは、起動対象として「Claude Code」「Codex」「OpenCode」などを選べる。CLI は認識済みエージェントの認証情報をシェル環境から自動検出するため、多くの場合はコードを変更せずに、そのままサンドボックス内で動かせる。
ライセンスは Apache 2.0 のオープンソースで、ソースコードは github.com/NVIDIA/OpenShell で公開されている。本記事執筆時点では 0.0.x 系の初期段階にあり、コマンド体系やポリシースキーマは今後更新される可能性がある。実際に使う際は、必ず公式ドキュメント（docs.nvidia.com/openshell）で最新の仕様を確認してほしい。
事前に必要なもの — 4つの前提を整える
OpenShell を試すには、対応OS・コンテナ実行環境・CLI・エージェントの資格情報の4点が必要になる。 それぞれを順に確認する。
対応OSとコンテナ実行環境
OpenShell を動かすには、次の環境が必要だ。
- macOS / Linux / Windows + WSL 2 のいずれか
- Docker / Podman / MicroVM のいずれかが使える状態
- OpenShell CLI と OpenShell gateway
ファイルシステムの隔離は Linux カーネルの Landlock を使うため、本来の保護機能をフルに活かせるのは Linux 環境（および Linux カーネル上で動く WSL 2・コンテナ）である。macOS では仮想化レイヤを経由して動作する。エンタープライズ向けには、長時間稼働するエージェントを DGX Spark 上で動かす構成も案内されている。
まずは手元の OS でコンテナランタイム（Docker など）が起動しているかを確認してから、次のインストールに進むとつまずきにくい。
エージェントのアカウントとAPIキー
サンドボックス内で動かすエージェント（Claude Code など）のアカウントや API キーは、別途用意しておく必要がある。OpenShell 自体はエージェントを安全に隔離するための器であり、エージェントの利用権限までは提供しない。
OpenShell CLI は、認識済みのエージェント（Claude・Codex・OpenCode・Copilot など）の資格情報を、シェルの環境変数から自動検出する。つまり、ホスト側で普段使っている認証情報をそのまま引き渡せる。明示的に資格情報（プロバイダー）を登録することも可能だ。
ここで重要なのは、こうした認証情報がサンドボックスのポリシーによって保護される点である。エージェントには「使うために必要な範囲」だけが渡り、ポリシー外のファイルや通信からは隔離される。
手順1 — OpenShellをインストールして導通を確認する
インストールは公式スクリプト一発で、CLI とゲートウェイがまとめて入る。 入った後は status と help で導通を確認する。
CLIとゲートウェイのインストール
公式のインストールスクリプトを実行する。
1curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | shこのスクリプトは「OpenShell CLI」と「OpenShell gateway」をインストールし、ローカルのゲートウェイを自動起動する。CLI が操作の窓口、gateway がサンドボックスとネットワークポリシーを実際に enforce（強制）する常駐コンポーネントだ。公式ドキュメントでは、uv tool install -U openshell でインストールする方法も案内されている。
なお、curl | sh 形式のインストールには、スクリプトの内容を実行前に確認できないという一般的なリスクがある。気になる場合は、URL を一度エディタで開いて中身を読んでから実行する、あるいは uv 経由のインストールを選ぶとよい。
statusとhelpで導通を確認する
インストール後、ゲートウェイの状態を確認する。
1openshell status正常なら、ゲートウェイ名・サーバー URL（例: https://127.0.0.1:17670 のようなローカルアドレス）・接続状態（Connected）・バージョンが表示される。Connected が出れば、CLI からゲートウェイへ到達できている。
利用できるサブコマンドの一覧は help で確認する。
1openshell --helpstatus が Connected にならない場合は、ゲートウェイのプロセスが起動しているか、ローカルのポートが他プロセスと衝突していないかを疑う。ここで導通を確認しておくと、後のサンドボックス作成でつまずいたときに「CLI の問題か、ポリシーの問題か」を切り分けやすくなる。
手順2 — 最初のサンドボックスを作成する
OpenShell の基本操作は、openshell sandbox create でサンドボックスを作り、その中でエージェントを起動することだ。 実際に Claude Code を隔離環境で動かしてみる。
claudeをサンドボックス内で起動する
名前を付けてサンドボックスを作成し、その中で Claude Code を起動する。
1openshell sandbox create --name demo -- claude--name demo でサンドボックスに「demo」という名前を付け、-- の後ろに渡した claude がサンドボックス内で実行される。起動すると、Claude Code がサンドボックス内で動き始める。
-- は「ここから先はサンドボックス内で実行するコマンド」という区切りだ。Claude Code 以外にも、Codex や OpenCode など CLI が対応するエージェントを同じ形で起動できる。エージェントの認証情報はホスト環境から自動検出されるため、多くの場合は追加設定なしでそのまま使い始められる。
サンドボックス内で動いていることを確認する
起動したエージェントが、ホストではなくサンドボックス内で動いていることを確かめる。たとえば Claude Code に対して、現在のディレクトリを尋ねてみる。
カレントフォルダの絶対パスは？
OpenShell の標準構成では、作業ディレクトリは /sandbox になっている。エージェントが /sandbox を返せば、ホストのファイルシステムそのものではなく、OpenShell が管理する隔離空間の中で動作していることがわかる。
この「どこで動いているのか」の確認は地味だが重要だ。エージェントにファイル操作やコマンド実行を任せる前に、ホスト環境と切り離されていることを自分の目で確認しておく。ここを飛ばすと、隔離されているつもりで実はホストを触っていた、という事故につながりかねない。
エージェントに作業を依頼して生成物を確認する
サンドボックスが起動したら、エージェントに簡単な作業を頼んでみる。たとえば次のように指示する。
hello_world.py を作成してください。
エージェントはサンドボックス内にファイルを作成する。生成されたコードを確認するには、/exit で Claude Code を抜け、サンドボックスのシェルで中身を見る。
1sandbox@xxxx:~$ pwd
2/sandbox
3sandbox@xxxx:~$ ls
4hello_world.py
5sandbox@xxxx:~$ cat hello_world.py
6print("Hello, World!")作業が終わったら exit でサンドボックスのシェルを抜け、ホストの PC のシェルに戻る。エージェントが作ったファイルは /sandbox 配下に隔離されており、ホストのファイルツリーを汚さない。この「生成物がサンドボックス内に閉じている」状態が、安全に試行錯誤できる土台になる。
手順3 — サンドボックスを操作する（一覧・再接続・削除）
作成したサンドボックスは、一覧表示・再接続・削除で管理する。 試行が終わったら、不要なサンドボックスは削除して環境を整理する。
list・connect・deleteの使い分け
サンドボックスの一覧は次のコマンドで確認する。
1openshell sandbox list名前（NAME）・作成日時（CREATED）・状態（PHASE）が表示され、起動済みなら PHASE が Ready になる（このほか Provisioning・Error・Deleting などの状態がある）。-o json や -o yaml を付ければ機械可読な形式でも出力できる。
既存のサンドボックスに入り直すには connect を使い、その中でエージェントを再起動する。
1openshell sandbox connect demo
2claude不要になったサンドボックスは delete で削除する。削除時には、プロセスの停止とリソース解放に加えて、注入された認証情報も破棄される。
1openshell sandbox delete democonnect はサンドボックスのシェルに接続するだけで、エージェントの起動は別操作になる点に注意したい。稼働状況をまとめて確認したいときは openshell term のダッシュボードも使える。サンドボックスは作りっぱなしにせず、検証後は sandbox delete で片付けると、古い状態やポリシーが残って挙動の切り分けが難しくなるのを防げる。
手順4 — ポリシーでネットワークアクセスを制御する
OpenShell の真価は、ネットワークアクセスを宣言的なポリシーで制御できる点にある。 ここでは、既定で許可されない URL がブロックされることを確認し、ポリシーを編集してアクセスを許可するまでを通しでやってみる。
既定で許可されないURLは弾かれる
サンドボックスは「最小の外向きアクセス」から始まる。既定のポリシーで許可されていない URL には到達できない。
まずサンドボックスに接続する。
1openshell sandbox connect demo許可されていない URL に curl でアクセスしてみる。
1curl -I https://example.com/some-path既定ポリシーに含まれないホストへの通信は、ゲートウェイのプロキシによってブロックされる。エージェントが勝手に外部へデータを送り出す（データ持ち出し＝exfiltration）リスクを、設定で塞いでいるわけだ。「デフォルトは拒否、必要なものだけ明示的に許可する」という最小権限の考え方が、ネットワーク層でも貫かれている。
ポリシーを取得して中身を読む
現在のポリシーをファイルに書き出す。
1openshell policy get demo --full > current-policy.yaml書き出したファイルの先頭には Version Hash Status Active Created といったメタ情報があり、その下に --- の区切りを挟んで YAML 本体が続く。YAML 本体からは、次のことが読み取れる。
- どのホスト・URL にアクセスできるか（network_policies）
- どのコマンド（バイナリ）からネットワークアクセスを許すか（binaries）
- どのフォルダを読み取り/書き込みできるか（filesystem_policy）
- どのユーザー/グループでプロセスを動かすか（process）
YAML 本体は、おおまかに次の構造になっている（抜粋）。
1version: 1
2filesystem_policy:
3 include_workdir: true
4 read_only:
5 - /usr
6 - /etc
7 read_write:
8 - /sandbox
9 - /tmp
10landlock:
11 compatibility: best_effort
12process:
13 run_as_user: sandbox
14 run_as_group: sandbox
15network_policies:
16 claude_code:
17 name: claude-code
18 endpoints:
19 - host: api.anthropic.com
20 port: 443
21 protocol: rest
22 tls: terminate
23 enforcement: enforce
24 access: full
25 binaries:
26 - path: /usr/local/bin/claudeポリシーを編集して適用する
アクセスを許可したいホストを network_policies に追記する。openshell policy set はポリシー全体を置き換えるため、既存の network_policies を消さずに、新しいポリシーを「追記」するのが鉄則だ。たとえば任意のホストへの読み取りアクセスを足すなら、次のようなブロックを既存のポリシーの下に加える。
1 example_site:
2 name: example-site
3 endpoints:
4 - host: example.com
5 port: 443
6 protocol: rest
7 enforcement: enforce
8 access: read-only
9 binaries:
10 - path: /usr/bin/curl各エンドポイントの enforcement は、違反を実際にブロックする enforce と、ブロックせず記録だけ行う audit から選べる。まず audit で挙動を観察してから enforce に切り替えると安全だ。OpenShell はバイナリ・宛先・HTTP メソッド・パスの粒度でアクセスを評価するため、「curl からこのホストの GET だけ許す」といった細かな制御もできる。
適用前に、ファイル先頭の --- より上のメタ情報（Version / Hash / Status など）を必ず削除する。policy set に渡すのは --- より下の YAML 本体だけだ。
1openshell policy set demo --policy current-policy.yaml --wait--wait は適用完了まで待つオプション。ネットワークポリシーは稼働中のサンドボックスにホットリロードされるため、サンドボックスを作り直さずに反映される。適用後、再接続して同じ URL に curl すると、今度は到達できるようになる。
よくある失敗と回避策
OpenShell を使い始めたときにつまずきやすいポイントを、回避策とあわせて挙げる。
policy setで既存ポリシーを丸ごと上書きしてしまう:policy setはポリシー全体を置き換える。既存のnetwork_policiesを消すと、エージェントが本来必要とする通信（モデル API など）まで止まる。必ずpolicy getで取得した内容に追記する形で編集する。- メタ情報を付けたまま
policy setに渡す:---より上のメタ情報（Version / Hash 等）を残すと適用に失敗する。本体だけにしてから渡す。 - 静的ポリシーを稼働中に変えようとする: filesystem と process は作成時にロックされ、稼働中は変更できない。これらを変えたい場合はサンドボックスを作り直す。ホットリロードできるのは network と inference だけだ。
- macOS で Landlock の保護を期待する: Landlock は Linux カーネルの機能で、
compatibility: best_effortの設定からもわかるように環境によって挙動差がある。どこまで保護されるのかを正確に把握しておく。 - サンドボックスを作りっぱなしにする: 古いサンドボックスやポリシーが残ると、挙動の切り分けが難しくなる。検証後は
sandbox deleteで片付ける。
FAQ
OpenShell についてよく寄せられる疑問をまとめた。
Q. OpenShell は普通の Docker と何が違う？ Docker はアプリケーションの隔離を主目的とするのに対し、OpenShell は「自分の環境を書き換えながら作業する AIエージェント」を安全に動かすことに特化している。ファイル・ネットワーク・プロセス・推論の4領域をポリシーで制御し、ネットワークと推論は稼働中でも更新できる点が大きな違いだ。
Q. 既存のエージェントのコードを書き換える必要はある？ 多くの場合は不要だ。CLI が認識済みエージェント（Claude・Codex・OpenCode など）の認証情報を自動検出し、コードを変更せずにサンドボックス内で動かせる。
Q. 本番運用で使える？ ライセンスは Apache 2.0 のオープンソースだが、執筆時点では 0.0.x 系の初期段階で、仕様変更の可能性がある。本番導入を検討する場合は、最新の公式ドキュメントとリリースノートで対応プラットフォームや既知の制限を確認したうえで、小さな検証から始めるのが安全だ。
まとめ
NVIDIA OpenShell は、AIエージェントをサンドボックス内で安全に動かし、ホストのファイルや認証情報を守りながら、ネットワークアクセスを宣言的ポリシーで制御できるオープンソースの実行環境だ。本記事では、インストールと導通確認、最初のサンドボックス作成、エージェントへの作業依頼、そしてポリシーによるネットワーク制御までを手順で追った。
要点は3つ。第一に、OpenShell は「環境を変えていくエージェント」を前提に、ファイル・ネットワーク・プロセス・推論の4領域を最小権限で守る。第二に、サンドボックスは作成・接続・削除のシンプルな操作で管理でき、生成物は /sandbox に隔離される。第三に、ネットワークポリシーは「デフォルト拒否、必要なものだけ追記」で運用し、稼働中でもホットリロードできる。
エージェントに自律的な作業を任せるほど、隔離と権限制御の重要性は増す。当社でも AIエージェントの活用を進める際は、まず小さなサンドボックスで挙動を確認し、ポリシーを少しずつ広げる進め方を基本としている。OpenShell のような実行環境を土台に、安全な試行錯誤の場を整えることから始めてほしい。
著者・監修者
Yusuke Ishihara
13歳でMSXに触れプログラミングを開始。武蔵大学卒業後、航空会社の基幹システム開発や日本初のWindowsサーバホスティング・VPS基盤構築など、大規模システム開発に従事。 2008年にサイトエンジン株式会社を共同創業。2010年にユニモン株式会社、2025年にエニソン株式会社を設立し、業務システム・自然言語処理・プラットフォーム開発をリード。 現在は生成AI・大規模言語モデル（LLM）を活用したプロダクト開発およびAI・DX推進を手がける。
