NVIDIA OpenShell入門 — 自律型AIエージェントをカーネルレベルでサンドボックス化する安全なランタイム徹底ガイド

OpenShell は、NVIDIAが公開した自律型AIエージェント向けのサンドボックスランタイムです。GitHub Trending でも注目を集めており、「エージェントにファイル操作・パッケージインストール・API呼び出し・認証情報の利用を許可しつつ、やりすぎを防ぐ」という、エージェント運用で誰もが一度は悩む課題に正面から取り組んでいます。普段 Claude Code を使い倒している身として、エージェントに社内APIの認証情報を渡すときの不安をどう解消するかに興味があり、実際に試してみたので、アーキテクチャから実務での活用パターンまで整理します。

OpenShellとは — 自律型AIエージェントのためのセキュアなサンドボックスランタイム

OpenShell は公式に “the safe, private runtime for fleets of autonomous AI agents” と説明されている通り、AIエージェントを隔離された実行環境で動かすためのOSSランタイムです。リポジトリは github.com/NVIDIA/OpenShell で公開されており、ライセンスは Apache-2.0。本稿執筆時点ではまだ活発にメジャーアップデートが続く段階（0.0.x系のビルドが複数観測できる）のソフトウェアで、公式ドキュメントでも「alpha software」「single-player（1人の開発者・1環境・1ゲートウェイ）を想定した段階」と位置づけられています。

エージェントに自律的な作業を任せる以上、ファイルアクセス・パッケージインストール・外部API呼び出し・認証情報の利用は避けて通れません。しかし、その権限をそのまま渡すと、プロンプトインジェクションや単純な実装ミスから機密情報の漏洩や意図しない外部通信につながるリスクがあります。OpenShell は「権限を奪う」のではなく、「宣言的なポリシーで権限を制御する」というアプローチでこの課題に取り組んでいます。

アーキテクチャ — カーネルレベル制御と形式検証によるポリシー変更

OpenShell の中核は大きく2つの仕組みで構成されています。

• カーネルレベルの権限制御: 各エージェントは隔離されたサンドボックス内で動作し、Landlock（Linuxのセキュリティモジュール）などのカーネル機構でファイルアクセスとシステムコールを制限します。ネットワーク通信はすべてポリシー検証を行うゲートウェイ経由にルーティングされ、許可されていない宛先への通信はそもそも成立しません。
• 認証情報の非公開化: APIキーやトークンはエージェントのプロセスから直接見えない形で管理され、ポリシーで許可されたエンドポイント宛てのリクエストにのみ、OpenShell側がヘッダーとして注入します。エージェント自身は生の認証情報を一度も目にしません。
• 形式検証されたポリシー変更: ポリシーを変更する際、新しいホストへの到達や新しいAPIメソッドの呼び出しなど「リスクが上がる変更」を形式的に検証し、人間のレビューが必要な変更として検知します。

ここで重要なのは、ポリシーの実行主体（ポリシーエンジン）がエージェントのプロセスの外側に完全に分離されている「out-of-process governance」という設計です。Claude Code や各種エージェントフレームワークの権限設定は、多くがエージェント自身のコンテキストやツール呼び出しルールの中で解釈されるため、巧妙なプロンプトインジェクションによって権限を迂回される懸念が指摘されてきました。OpenShell はOSプロセスとカーネルの境界で強制するため、エージェントがどう「説得」されても、ポリシーで許可されていない操作はそもそも実行できません。

インストールとクイックスタート

インストールはシェルスクリプト1本です。CLIと、ローカルで動くゲートウェイがセットアップされます。

# OpenShell CLI とローカルゲートウェイをインストール
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

# 動作確認
openshell --version

# デフォルトのサンドボックスを作成（最小構成のUbuntuイメージ、エージェントは未導入）
openshell sandbox create --name demo

動作要件は Linux、Apple Silicon 搭載の macOS、または WSL2 上の Windows（experimental）で、いずれの場合も Docker・Podman・ホスト側の仮想化機能のいずれかが必要です。社内プロキシ配下で検証する場合は、他のCLIツールと同様に HTTPS_PROXY 環境変数がそのまま効きます（この点は以前の記事「開発ツール別プロキシ設定まとめ」も参照してください）。

ポリシーYAMLを書く — filesystem_policy・landlock・network_policies

OpenShell のポリシーファイルは、次のようなトップレベルのフィールドで構成されます。

フィールド	役割	変更タイミング
filesystem_policy	読み書き可能なディレクトリを定義	サンドボックス作成時に固定（静的）
landlock	Landlockによるカーネルレベルの互換性モードを設定	サンドボックス作成時に固定（静的）
process	実行可能なプロセス・権限まわりの制御	サンドボックス作成時に固定（静的）
network_policies	バイナリ単位で到達可能なエンドポイントを定義	実行中でも反映可能（動的）
network_middlewares	ネットワーク通信に挟むミドルウェアの設定	実行中でも反映可能（動的）

filesystem_policy・landlock・process はサンドボックス作成時にロックされる「静的セクション」、network_policies・network_middlewares は稼働中のサンドボックスにもホットリロードできる「動的セクション」という違いを押さえておくと、運用設計がしやすくなります。

実際に GitHub API への読み取り専用アクセスだけを許可する最小構成のポリシー例は次の通りです。

# policy.yaml
version: 1

filesystem_policy:
  include_workdir: true
  read_only:
    - /usr
    - /lib
    - /etc
  read_write:
    - /tmp
    - /sandbox

landlock:
  compatibility: best_effort

network_policies:
  github_api:
    binaries:
      - /usr/bin/curl
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        access: read_only

ポイントは、OpenShell がデフォルトですべてのアウトバウンド通信を拒否し、network_policies に明示したルールだけを許可する「許可リスト方式」を採っていることです。素のDockerコンテナがデフォルトブリッジネットワークで外向き通信を広く許可しているのとは対照的な考え方です。

ポリシーの適用は次のコマンドで行います。

# ポリシーファイル全体を丸ごと反映
openshell policy set -f policy.yaml --sandbox demo

# network_policies など動的セクションだけを追記的に更新
openshell policy update --sandbox demo --add-endpoint api.github.com:443

比較検証 — Docker / gVisor・Firecracker / E2Bとの違い

「サンドボックス」や「隔離実行環境」という文脈では既存の選択肢も多いため、代表的なものと比較してみます。

観点	OpenShell	素のDocker	gVisor / Firecracker	E2B / Daytona
隔離レイヤー	カーネル制御（Landlock）+ ネットワークゲートウェイ	namespace / cgroup	ユーザー空間カーネル・軽量VM（システムコール単位の隔離）	クラウド上のマイクロVM/コンテナ
ネットワーク制御	バイナリ単位の宛先許可リスト（デフォルト全拒否）	デフォルトで広めに許可、別途iptables等が必要	自前で制御ロジックを組む必要あり	プロバイダー側の設定に依存
認証情報の扱い	エージェントに生の値を見せず、許可エンドポイントにのみ注入	コンテナ内の環境変数等で直接保持するのが一般的	同左（隔離自体はセキュアだが認証情報管理は範囲外）	サービスごとに異なる
ポリシー変更の安全性	リスクのある変更を形式検証してフラグ付け	なし（自前でレビュー運用を組む）	なし	サービス依存
想定ユースケース	AIエージェント専用の実行制御	汎用コンテナ実行全般	マルチテナントな汎用サンドボックス実行基盤	クラウドホスト型のコード実行環境
ホスティング形態	セルフホスト（OSS、ローカル/自社インフラ）	セルフホスト	セルフホスト	SaaS

以前の記事「Rootless Docker 完全ガイド」で紹介した権限分離の考え方や、gVisor・Firecracker が実現する軽量VM相当の隔離は、いずれも「任意のワークロードを安全に動かす」ための汎用的な技術です。それに対してOpenShellは、「エージェントが自律的に何をするか事前に予測しきれない」という前提に立ち、宛先とバイナリの組み合わせ単位で許可リストを宣言するという、AIエージェント実行に特化した設計になっている点が最大の違いです。汎用的な隔離技術の上に、エージェント向けのポリシー層を重ねたものと理解すると位置づけがしやすいと思います。

実務での活用パターンと導入時の注意点

実際に触ってみた範囲での活用パターンと注意点です。

• ポリシーをコードとして管理する: policy.yaml をリポジトリにコミットし、新しいツール・宛先ホストを許可する変更はPRレビューを通す。「エージェントに何を触らせているか」がdiffとして残るのは、口頭やチャットでの申請ベースの運用より監査性が高い
• 長時間の自律タスクほど効果が大きい: 夜間に走らせるコード移行作業やバッチ的なリファクタリングなど、人間が張り付いて見ていられないタスクほど、サンドボックスとポリシーで事前に行動範囲を縛る意味が大きい
• CI組み込み時はdelegateモードのツールと相性がよい: 以前紹介した Open Code Review の delegate モードのように、外部エージェントに処理を委譲する構成では、委譲先のエージェントをOpenShellでラップし、社内プロキシ配下の許可ホストのみアクセスさせる構成が組みやすい
• 既存のDevcontainer運用と無理に一本化しない: 開発環境そのものは従来通りDevcontainerやrootless Dockerで整え、「エージェントが自律実行するタスク」だけをOpenShellでラップするハイブリッド運用のほうが、現時点のalpha段階のソフトウェアとしては現実的
• 本番のマルチテナント運用はまだ時期尚早: 公式も「single-player」想定と明言している通り、まずはローカル環境や個人の検証用途から始め、エンタープライズ向けのマルチテナント対応が進むのを待つのが無難

自分もpicoCTFでセキュリティを学び直している最中の身ですが、「許可する宛先とプロセスを宣言的に書き、デフォルト拒否から積み上げる」というOpenShellの設計は、CTFのサンドボックス問題でseccompやケーパビリティ制限を読み解く感覚に近く、学びの多いツールでした。

まとめ

項目	ポイント
正体	NVIDIA製OSSの自律型AIエージェント向けサンドボックスランタイム（Apache-2.0、alpha段階）
アーキテクチャ	Landlockによるカーネルレベル制御 + ネットワークゲートウェイ + 認証情報の非公開化 + ポリシー変更の形式検証
インストール	curl ... install.sh | sh → openshell sandbox create
ポリシー構造	静的セクション（filesystem_policy/landlock/process）と動的セクション（network_policies/network_middlewares）に分かれる、デフォルト全拒否の許可リスト方式
既存技術との違い	Docker/gVisor/Firecrackerなど汎用隔離技術の上に、エージェント専用のポリシー層を重ねた設計
導入の勘所	ポリシーをコードとして管理し、長時間の自律タスクから優先的に適用。本番マルチテナント運用はまだ時期尚早