AIREITERファイルを編集し、パッケージをインストールし、APIを呼び出せるコーディングエージェントに必要なのは、システムプロンプトに書いた注意書きだけではありません。NVIDIA OpenShellは、こうした権限をエージェントの外側にあるポリシー適用型サンドボックスへ切り離します。ただし、実際に使えるポリシーを漏れなく設計し、導入環境を検証する作業は、依然として利用者側に残ります。
結論：OpenShellはエージェントフレームワークではなく、実行境界をつくるランタイム
NVIDIA OpenShellは、自律型エージェント向けのオープンソースランタイムです。0.1.xのドキュメントでは、Gateway、サンドボックスごとのSupervisor、カーネルによるファイルシステムおよびプロセス制御、仲介型ネットワーク、認証情報のバインディング、ポリシーのレビュー機能が説明されています。NVIDIAが2026年9月28日に公開した技術ブログによると、CodexやClaude Codeのようなエージェントを、書き換えずにラップして利用する設計です（NVIDIA Technical Blog）。
ここで重要なのは、知能と封じ込めを分けて考えることです。OpenShellは、許可されていないファイル書き込みやネットワーク要求をブロックできます。しかし、ポリシーに抜けがあれば、同じ業務上の操作へ至る別の経路まで理解して防いでくれるわけではありません。私なら、管理されたコーディング環境やエージェント基盤でのパイロットには使いますが、サンドボックスがあることだけを根拠に、本番エージェントを安全だとは判断しません。
OpenShellが実際に制御するもの
OpenShellは、フリート管理とワークロードを分離します。Gatewayがサンドボックスとポリシーを管理し、Supervisorがワークロード外へのリクエストを仲介。Sandboxでは、OSレベルの制限下でエージェントを実行します（NVIDIA Technical Blog）。
| レイヤー | 保護する対象 | 実行中に変更できるか |
|---|---|---|
| ファイルシステム | ファイルとディレクトリ | 不可。サンドボックスの再作成が必要 |
| プロセス | 権限とシステムコールの挙動 | 不可。サンドボックスの再作成が必要 |
| ネットワーク | ホスト、ポート、バイナリ、選択したAPI操作 | 可 |
| プロバイダー認証情報 | 承認済みエンドポイントで使うシークレット | 可 |
OpenShellはアプリケーション層より下でポリシーを適用し、再利用可能な認証情報をエージェントの外部に保持します。そして、承認済みのリクエストにだけ認証情報を付与します（OpenShell README）。
「OpenShellは、自律型AIエージェントのフリート向けに、安全性とプライバシーを確保したランタイムです」— NVIDIA OpenShell README（出典）
強みは境界の制御、弱点はポリシー設計にある
OpenShellのドキュメントにある制御機能が有用なのは、複数のインフラ境界でデフォルト拒否に近い形で動作するためです。ただし、エージェントに許可した操作をどのように組み合わせられるかまでモデル化する代わりにはなりません。
ファイル、プロセス、ネットワークをまとめて制御する
最新のセキュリティガイドでは、ファイルアクセスにLandlock、プロセス制限にseccompと権限降格、外向き通信にOPAポリシー評価付きのCONNECTプロキシを使う構成が説明されています（OpenShell Security Best Practices）。明示されていないファイルパスにはアクセスできず、外向き通信はデフォルトで拒否されます。また、ネットワークルールではバイナリの識別情報に基づいてアクセスを縛ることもできます。
ネットワークルールは、ホストとポートのチェックにとどまりません。RESTポリシーではメソッドやパス、GraphQLポリシーではオペレーションやルートフィールド、WebSocketポリシーではハンドシェイクやメッセージを検査できます。その一方で、運用上のトレードオフもあります。広いルールは動作を維持しやすく、狭いルールは防御しやすい設計です。
ファイルシステムとプロセスの制限は、サンドボックス起動時に固定されます。ネットワーク権限は稼働中のサンドボックスでも更新できますが、承認内容はそのサンドボックスインスタンスに対する永続的なポリシー改訂になります。試行錯誤はしやすい一方、すべての制御が実行中に変更できるわけではありません。
認証情報を仲介しても、危険なエンドポイントが安全になるわけではない
認証情報の仲介によって露出範囲は抑えられますが、権限を広く持つエンドポイントそのものを安全にできるわけではありません。読み取り専用のAPIポリシーなら、技術的には書き込み権限を持つ認証情報の利用範囲を狭められます。しかし、破壊的な操作をすでに許可しているポリシーを修復することはできません。
セキュリティガイドでは、まずL7ルールをauditモードで開始し、実際のリクエストを確認してからenforceへ移行する手順を推奨しています。Auditモードは違反をログに記録しますが、リクエスト自体は転送します。つまり、これは検出のための段階であり、本番環境でのブロック機能ではありません。
デモをセキュリティ検証と取り違えずにOpenShellを評価する
NVIDIAの公式チュートリアルでは、curlと認証不要のGitHub REST APIを使い、アクセス拒否、読み取り専用ルール、実行中のポリシー差し替えを確認できます。ただし、これは学習用の導入手順であり、独立したベンチマークではありません（NVIDIA Technical Blog）。
まずはチュートリアルを使って、次の3点を確認しましょう。
- エージェントをネットワークアクセスなしで起動し、必要なエンドポイントだけを後から与えられるか。
- 利用するAPIについて、読み取りと書き込みの違いをポリシーで表現できるか。
- エージェント自身にリクエストの承認権限を与えずに、運用チームが拒否理由とポリシー改訂を確認できるか。
本格的なパイロットでは、敵対的なケースも追加してください。シンボリックリンクやパストラバーサルの試行、パッケージのインストール、シェルから起動される子プロセス、別バイナリの利用、誤ったホストへ送られる認証情報のプレースホルダー、そして個別には許可された操作の組み合わせが対象です。公開資料には、レイテンシ、起動オーバーヘッド、独立した脱出率の測定結果はありません。製品のアーキテクチャに関する主張をテスト結果として流用せず、自分の環境で数値を集めるべきです。
本番導入の判断を止める可能性がある3つの制約
本番導入を判断する際は、次の3点を前提にしてください。
- 成熟度と互換性。 リポジトリでは、Linux、Apple Silicon版macOS、実験的なWSL 2経由のWindowsがサポート対象として挙げられています。実行方式にはDocker、Podman、ホストの仮想化を利用できます。Kubernetesでは
NetworkPolicyを適用できるCNIが必要です。また、Kubernetesのユーザーネームスペースには、比較的新しいカーネル、Kubernetes、ランタイムのバージョンが必要で、この組み合わせでのGPU互換性は未検証です（OpenShell README；Security Best Practices）。 - ポリシーの組み合わせ。 @liyun0016による実ユーザーテストでは、明示的な拒否テストは通過した一方、リポジトリの編集、CIの変更、CIの起動を組み合わせることで、許可していない本番経路につながる可能性が報告されています（投稿）。OpenShellが適用するのは、利用者が書いたルールです。見落とされた業務レベルのルールまで定義してくれるわけではありません。
- エビデンスの質。 NVIDIAは、保護されたリポジトリへの書き込みなしで長時間の敵対的実験を行ったと報告しています。しかし、引用された技術資料には、モデル数、ベースライン、誤検知率、独立した再現結果は掲載されていません。これはベンダーによるエビデンスであり、認証や保証とは分けて考えるべきです。
「OpenShellが、与えられたルールを適用することに長けているのは明らかです。ただ……本当のボトルネックはポリシー層にあるように感じます」— @liyun0016（出典）
今、NVIDIA OpenShellを使うべきユーザーは誰か
| 状況 | 判断 |
|---|---|
| 機密ファイルを扱うローカルのコーディングエージェント | Linux/macOSのランタイム要件を満たし、ポリシーを狭く始められるなら、パイロットする価値がある |
| 複数のワークスペースを使うチームのエージェントフリート | 分離されたワークスペース、共通のポリシーレビュー、認証情報の仲介が必要なチームに適している |
| GPUを多用するKubernetes環境 | 慎重にパイロットする。ユーザーネームスペースとGPUの互換性を別途検証する必要がある |
| 広い業務権限を持つ無人の本番エージェント | OpenShellだけに依存しない。業務上の承認、操作単位の制御、ログ、ロールバックを追加する |
| Python用のシンプルなコードサンドボックスが必要 | 専用サンドボックスと比較する。OpenShellは必要以上に大きなコントロールプレーンになる可能性がある |
私の推奨は、全面移行ではなく範囲を限定したパイロットです。1つのエージェント、1つのワークスペース、デフォルト拒否のネットワークポリシー、そして可逆性のある少数のタスクに絞ってください。拒否リクエストのノイズ、起動時間、ポリシーの保守負荷、許可された操作の連鎖によって業務上の境界を越えられないかを測定します。
NVIDIA OpenShell FAQ
NVIDIA OpenShellの利用にはNVIDIA GPUが必要ですか？
READMEにはCPUとGPUの実行パスが記載されており、Docker、Podman、ホストの仮想化も利用できます。ランタイムがNVIDIA GPUを必須とする説明にはなっていませんが、必要なドライバーと導入方式の組み合わせは自分の環境で検証してください。
OpenShellは本番運用に対応できる段階ですか？
OpenShell 0.1.xにはドキュメント化されたリリースラインがあります。しかし、公式資料には独立したセキュリティ認証や、広範な性能ベンチマークはありません。万能な本番保証ではなく、自分の脅威モデルに照らして検証すべきインフラとして扱ってください。リポジトリにはApache License 2.0が記載されています。計算リソース、Gatewayの運用、ポリシーの保守、セキュリティテストに必要なコストは、自社で見積もる必要があります（OpenShell README）。
総合評価：合格。
OpenShellでClaude CodeやCodexを実行できますか？
NVIDIAの技術ブログでは、互換性のあるエージェントとしてClaude CodeとCodexが挙げられています。ランタイムは既存のエージェントワークロードをラップする設計で、書き換えを前提としていません。
サンドボックスを再作成せずにファイルシステムのルールを変更できますか？
できません。セキュリティガイドでは、ファイルシステムとプロセスの制御は静的な設定に分類されています。ネットワークポリシーとプロバイダーの割り当ては、サンドボックスの実行中でも変更できます。
OpenShellとDockerの違いは何ですか？
Dockerはコンテナ化の基本機能を提供します。OpenShellはその上に、ファイルシステム、プロセス、ネットワーク、API操作、認証情報、ポリシーレビューを対象とする、エージェント向けのポリシー層を追加します。両者を同じ導入環境で組み合わせることも可能です。