はじめに
AIエージェントが自律的にコードを書き、ファイルを操作し、外部APIを呼び出す時代になった。Claude Code、Codex、OpenClawといったコーディングエージェントは生産性を大幅に向上させる一方で、「エージェントが想定外の操作をしたらどうするか」というセキュリティ上の課題が浮上している。
2026年3月16日、NVIDIAはGTC 2026でこの課題に対する回答として OpenShell を発表した。OpenShellは自律AIエージェント向けのオープンソースセキュリティランタイムで、サンドボックス隔離・ポリシーエンジン・プライバシールーターの3つの防御層でエージェントの動作を制御する。Apache 2.0ライセンスで公開されており、既存のエージェントフレームワークをコード修正なしで安全に実行できる。
この記事で学べること
- OpenShellのアーキテクチャと3つの防御層の仕組み
- インストールからサンドボックス起動までの手順
- 宣言的YAMLポリシーによるアクセス制御の設定方法
- プライバシールーターによるLLM推論の制御
- Cisco AI Defenseとの連携によるエンタープライズ展開
対象読者
- AIエージェントを開発・運用しているエンジニア
- エージェントのセキュリティ対策を検討しているチーム
- Claude Code / Codex / OpenClawを業務で利用している開発者
TL;DR
- OpenShellはAIエージェント専用のOSSセキュリティランタイム（Apache 2.0）
- サンドボックス・ポリシーエンジン・プライバシールーターの3層でエージェントを制御
- deny-by-defaultのアクセス制御で、ファイルシステム・ネットワーク・プロセス・推論の4ドメインを防御
- Claude Code / Codex / OpenClawと無改造で動作
- 宣言的YAMLポリシーはネットワーク・推論ルールをホットリロード可能
OpenShellとは何か
OpenShellは、NVIDIAがGTC 2026で発表したAIエージェント専用のセキュリティランタイムである。同じくGTC 2026で発表されたNemoClaw（エージェント開発プラットフォーム）とは役割が異なり、OpenShellは「エージェントが動く環境そのもの」を安全にする基盤ソフトウェアに位置づけられる。
解決する課題
NVIDIAの技術ブログによると、長時間動作する自律エージェントには「安全性」「能力」「自律性」の3つが同時に必要だが、従来のアプローチではこのうち2つしか両立できないという課題がある。
OpenShellのアプローチは out-of-process policy enforcement （プロセス外ポリシー適用）にある。ポリシーの適用をエージェントプロセスの外部で行うことで、たとえエージェントが侵害されたとしてもセキュリティ制約を回避できない設計になっている。
主要コンポーネント
OpenShellは4つのコンポーネントで構成される。
| コンポーネント | 役割 |
|---|---|
| Gateway | コントロールプレーンAPI。サンドボックスのライフサイクル管理と認証境界 |
| Sandbox | 隔離されたコンテナランタイム。ポリシーに基づくエグレスルーティングを適用 |
| Policy Engine | ファイルシステム・ネットワーク・プロセス・推論の4ドメインでアクセス制御を適用 |
| Privacy Router | LLM推論リクエストを制御し、機密データをローカルモデルに、それ以外をクラウドモデルにルーティング |
技術的には、これらすべてのコンポーネントがK3s Kubernetesクラスタとして単一のDockerコンテナ内で動作する。別途Kubernetesのインストールは不要である。
4つの防御ドメイン
OpenShellのポリシーエンジンは、以下の4つのドメインでアクセス制御を適用する。
ファイルシステム制御
許可されたパス以外への読み書きを防止する。ファイルシステムポリシーはサンドボックス作成時にロックされ、実行中の変更はできない。
ネットワーク制御
未承認の外部接続をブロックする。すべてのアウトバウンド接続はポリシーエンジンによりインターセプトされ、以下の3つの判定が行われる。
- Allow — 宛先とバイナリがポリシーに一致する場合、通信を許可
- Route — 推論リクエストの場合、呼び出し元の認証情報を除去し、バックエンドの認証情報を注入して管理されたモデルに転送
- Deny — ポリシーに一致しない場合、リクエストをブロックしてログに記録
ネットワークポリシーはホットリロードに対応しており、サンドボックスを再起動せずに更新できる。
プロセス制御
権限昇格と危険なシステムコールをブロックする。プロセスポリシーもサンドボックス作成時にロックされる。
推論制御
モデルAPIの呼び出しを制御されたバックエンドにリルートする。推論ポリシーもホットリロード可能で、運用中にモデルの切り替えや制限の変更が可能である。
| ドメイン | 保護内容 | 適用タイミング |
|---|---|---|
| ファイルシステム | 許可外パスへの読み書き防止 | 作成時ロック |
| ネットワーク | 未承認の外部接続ブロック | ホットリロード可 |
| プロセス | 権限昇格・危険syscallブロック | 作成時ロック |
| 推論 | モデルAPI呼び出しの制御 | ホットリロード可 |
インストールとセットアップ
前提条件
- Docker Desktop または Docker デーモンが稼働していること
- GPU利用時: NVIDIAドライバ + NVIDIA Container Toolkit
インストール
バイナリで直接インストールする方法と、PyPI経由の方法がある。
バイナリインストール:
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
PyPIインストール（uv必須）:
uv tool install -U openshell
サンドボックスの作成と起動
OpenShellでは、1コマンドでエージェントをサンドボックス内に起動できる。
# Claude Codeをサンドボックスで起動
openshell sandbox create -- claude
# Codexをサンドボックスで起動
openshell sandbox create -- codex
# OpenClawコミュニティイメージを使用
openshell sandbox create --from openclaw
# GPU付きサンドボックスを作成
openshell sandbox create --gpu --from gpu-enabled-sandbox -- claude
サンドボックスにはデフォルトで以下のツールが含まれている。
- Python 3.13, Node 22, git, gh
- vim, nano
- ネットワークユーティリティ（ping, dig, nslookup, nc, traceroute, netstat）
基本的な管理コマンド
# サンドボックス一覧を表示
openshell sandbox list
# サンドボックスにSSH接続
openshell sandbox connect my-sandbox
# ログをストリーミング表示
openshell logs my-sandbox --tail
# ダッシュボードUIを起動
openshell term
ポリシー設定
OpenShellの核となるのが宣言的YAMLポリシーである。サンドボックスはデフォルトで最小限のアウトバウンドアクセスのみ許可される（deny-by-default）。開発者がポリシーファイルで明示的に許可を与える設計になっている。
ポリシーの適用
# ポリシーを適用
openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait
# 現在のポリシーを確認
openshell policy get demo
ポリシーには2種類のセクションがある。
- 静的セクション（filesystem, process）: サンドボックス作成時にロックされ、変更不可
- 動的セクション（network, inference）: 実行中にホットリロード可能
この設計により、ファイルシステムとプロセスの安全性は起動時に確定しつつ、ネットワーク接続先やモデルの切り替えは運用中に柔軟に対応できる。
認証情報の管理
OpenShellでは、認証情報を Provider （名前付き認証情報バンドル）として管理する。Providerはサンドボックス作成時に環境変数として注入される。
| エージェント | 環境変数 |
|---|---|
| Claude Code | ANTHROPIC_API_KEY |
| Codex | OPENAI_API_KEY |
| OpenCode |
OPENAI_API_KEY または OPENROUTER_API_KEY
|
認証情報はサンドボックスのファイルシステムには書き込まれず、環境変数としてのみ注入される。プロンプトインジェクション攻撃によるクレデンシャル漏洩を防ぐ設計である。
プライバシールーター
OpenShellのプライバシールーターは、LLM推論リクエストのルーティングを制御する。
具体的には、機密性の高いコンテキストを含むリクエストをローカルのオープンモデルで処理し、それ以外のリクエストのみをクラウドのフロンティアモデル（Claude、GPTなど）に送信する。ルーティングの判断はエージェントではなく、組織のコスト・プライバシーポリシーに基づいて行われる。
# 推論プロバイダーとモデルを設定
openshell inference set --provider local --model llama-3.3
エンタープライズ統合: Cisco AI Defense
NVIDIAはCisco、CrowdStrike、Google、Microsoft Security、TrendAIなどのセキュリティベンダーと連携してOpenShellとの互換性を構築している。
中でもCisco AI Defenseとの統合は、2層セキュリティモデルとして注目される。
| 層 | 担当 | 役割 |
|---|---|---|
| インフラ制約 | OpenShell | サンドボックス隔離、deny-by-default、ネットワークポリシー、プライバシールーティング |
| 行動検証 | Cisco AI Defense | サプライチェーンリスク管理、MCPツール呼び出し検査、監査証跡 |
Ciscoの公式ブログでは「OpenShellはエージェントが できること を制約し、Cisco AI Defenseはエージェントが したこと を検証する」と説明されている。
具体的な連携機能は以下の通りである。
- サプライチェーン検証: すべてのツール・MCPサーバー・スキルを使用前にスキャン
- MCP呼び出し検査: 悪意あるペイロードやプロンプトインジェクションをリアルタイム検出
- 監査証跡: 推論ステップ・ツール呼び出し・意思決定の完全な記録
対応エージェントとパートナーエコシステム
OpenShellはコード修正なしで以下のエージェントをサポートしている。
- Anthropic Claude Code
- OpenAI Codex
- OpenClaw
- その他の互換コーディングエージェント
また、Adobe、Atlassian、Amdocs、Box、Cadence、Cisco、Cohesity、CrowdStrike、Dassault Systemes、IQVIA、Red Hat、SAP、Salesforce、Siemens、ServiceNow、Synopsysなど16社以上がNVIDIA Agent Toolkitのパートナーとして参加している。
デプロイメント対象
OpenShellは個人開発者からエンタープライズまで、以下の環境で動作する。
- NVIDIA DGX Spark / DGX Station
- NVIDIA RTX搭載PC
- オンプレミスインフラ
- クラウド環境
NemoClawとの違い
同じくGTC 2026で発表されたNemoClawはOpenClawコミュニティ向けのエージェント開発プラットフォームであり、エージェントの構築・デプロイ・管理を担う。一方、OpenShellはエージェントが動作する「ランタイム環境」のセキュリティを担う。両者は補完関係にあり、NemoClawで構築したエージェントをOpenShellのサンドボックスで安全に実行するという組み合わせが想定されている。
まとめ
- OpenShellはAIエージェント専用のOSSセキュリティランタイムで、3つの防御層（サンドボックス・ポリシーエンジン・プライバシールーター）でエージェントの動作を制御する
- deny-by-defaultの設計で、ファイルシステム・ネットワーク・プロセス・推論の4ドメインをカバー
- 宣言的YAMLポリシーにより、ネットワークと推論のルールはホットリロード可能
- Claude Code / Codex / OpenClawなど主要エージェントとコード修正なしで動作
- Cisco AI Defenseとの統合でエンタープライズレベルの監査・検証が可能
- Apache 2.0ライセンスでGitHub上に公開されている
エージェントのセキュリティは今後ますます重要になる。自律エージェントの導入を検討しているチームは、OpenShellによるランタイムレベルの防御を早期に評価することを推奨する。