OpenShellは、自律型AIエージェントのための安全でプライベートなランタイムです。データ、認証情報、インフラストラクチャを保護するサンドボックス化された実行環境を提供し、宣言型のYAMLポリシーによって、不正なファイルアクセス、データ流出、制御されていないネットワーク活動を防止します。

OpenShellはエージェントファーストで構築されています。OpenShellの使用と運用のための公開エージェントスキルに加え、コントリビューターとメンテナー向けのリポジトリ対応ワークフローを別途提供しています。

クイックスタート

前提条件

• サポート対象のホスト — Linux、macOS（Apple Silicon）、またはWSL 2を備えたWindows（実験的）。
• ローカルランタイム — Docker、Podman、またはMicroVMベースのサンドボックス用に有効化されたホスト仮想化。

インストール

バイナリ（推奨）:```bash curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

インストーラーはデフォルトで最新の安定版リリースをインストールします。特定のバージョンをインストールするには、`OPENSHELL_VERSION` を設定します。[`dev` リリース](https://github.com/NVIDIA/OpenShell/releases/tag/dev)も利用可能で、`main` 上の最新コミットを追跡します。

PyPI の `openshell` パッケージは Python SDK のみを提供します。`openshell` CLI はインストールされません。[uv](https://docs.astral.sh/uv/) を使用して SDK を Python プロジェクトに追加します:```bash
uv add openshell

Helm chart:

Experimental — Kubernetes デプロイメントパスは活発に開発中です。粗削りな部分や破壊的変更が想定されます。

GHCR に公開されている OCI チャートから、OpenShell ゲートウェイを Kubernetes クラスタにデプロイします:```bash helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart

利用可能なバージョン、dev タグの規則、および設定については [`deploy/helm/openshell/README.md`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md) を参照してください。

OpenShift 上に OpenShell をデプロイするには、[`deploy/helm/openshell/README.md#install-on-openshift`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md#install-on-openshift) を参照してください。

### サンドボックスを作成する```bash
openshell sandbox create -- claude  # or opencode, codex, copilot

サンドボックスコンテナには、デフォルトで以下のツールが含まれています：

詳細については https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base を参照してください。

ネットワークポリシーの実際の動作

すべてのサンドボックスは最小限のアウトバウンドアクセスで開始されます。プロキシがHTTPメソッドとパスのレベルで適用する短いYAMLポリシーを使用して追加のアクセスを開放できます。その際、何も再起動する必要はありません。```bash

1. Create a sandbox (starts with minimal outbound access)

openshell sandbox create

2. Inside the sandbox — blocked

sandbox$ curl -sS https://api.github.com/zen curl: (56) Received HTTP code 403 from proxy after CONNECT

3. Back on the host — apply a read-only GitHub API policy

sandbox$ exit openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait

4. Reconnect — GET allowed, POST blocked by L7

openshell sandbox connect demo sandbox$ curl -sS https://api.github.com/zen Anything added dilutes everything else.

sandbox$ curl -sS -X POST https://api.github.com/repos/octocat/hello-world/issues -d '{"title":"oops"}' {"error":"policy_denied","detail":"POST /repos/octocat/hello-world/issues not permitted by policy"}

[完全なウォークスルー](https://github.com/nvidia/openshell/blob/main/examples/sandbox-policy-quickstart)を参照するか、自動デモを実行してください:```bash
bash examples/sandbox-policy-quickstart/demo.sh

仕組み

OpenShell は各サンドボックスを独自のコンテナに隔離し、ポリシーで強制された egress ルーティングを行います。軽量なゲートウェイがサンドボックスのライフサイクルを調整し、すべての送信接続はポリシーエンジンによって傍受され、次の 3 つのいずれかを実行します:

• 許可 — 宛先とバイナリがポリシーブロックに一致します。
• エンドポイントへの認証情報のバインド — ポリシーがプロファイル承認済みエンドポイントへのリクエストを許可した後にのみ、プロバイダーの認証情報を注入します。
• 拒否 — リクエストをブロックし、ログに記録します。

OpenShell は、設定されたコンピュートドライバーを通じてサンドボックスのライフサイクルを管理するゲートウェイコントロールプレーンを実行します。サポートされるコンピュートプラットフォームには Docker、Podman、MicroVM、Kubernetes が含まれます。

保護レイヤー

OpenShell は 4 つのポリシードメインにわたって多層防御を適用します:

ポリシーは宣言的な YAML ファイルです。静的セクション (ファイルシステム、プロセス) は作成時にロックされます。ネットワークポリシーとプロバイダーアタッチメントは、実行中のサンドボックスで更新できます。

プロバイダー

エージェントには認証情報 — API キー、トークン、サービスアカウント — が必要です。OpenShell はこれらを プロバイダー として管理します: サンドボックス作成時に注入される名前付き認証情報バンドルです。CLI は認識されたエージェント (Claude、Codex、OpenCode、Copilot) の認証情報をシェル環境から自動検出します。または openshell provider create でプロバイダーを明示的に作成できます。認証情報がサンドボックスのファイルシステムに漏れることはありません。実行時に環境変数として注入されます。

推論アクセスも同じプロバイダーワークフローを使用します。推論対応のプロバイダーをサンドボックスにアタッチし、プロバイダーのネイティブエンドポイントを呼び出し、クライアントでモデルを選択します。プロバイダープロファイルはエンドポイントポリシーを提供し、認証情報プレースホルダーを承認された宛先にバインドします。

GPU サポート (実験的)

実験的 — GPU パススルーはサポートされているホストで動作しますが、活発に開発中です。粗削りな部分や破壊的な変更が予想されます。

OpenShell はローカル推論、ファインチューニング、または任意の GPU ワークロードのために、ホスト GPU をサンドボックスにパススルーできます。サンドボックス作成時に --gpu を追加します:```bash openshell sandbox create --gpu --from [gpu-enabled-sandbox] -- claude

Docker ベースの GPU サンドボックスは、利用可能な場合は CDI を自動選択し、そうでない場合は Docker の NVIDIA GPU リクエストパス（`--gpus all`）にフォールバックします。

**要件:** ホストに NVIDIA ドライバーと [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html) がインストールされている必要があります。サンドボックスイメージ自体に、ワークロードに適した GPU ドライバーとライブラリが含まれている必要があります — デフォルトの `base` イメージには含まれていません。GPU サポート付きのカスタムサンドボックスイメージをビルドする方法については、[BYOC の例](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container)を参照してください。

## サポートされているエージェント

| エージェント                                                         | ソース                                                                           | 備考                                                                         |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| [Claude Code](https://docs.anthropic.com/en/docs/claude-code) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | すぐに使用できます。プロバイダーは `ANTHROPIC_API_KEY` を使用します。                      |
| [OpenCode](https://opencode.ai/)                              | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | すぐに使用できます。プロバイダーは `OPENAI_API_KEY` または `OPENROUTER_API_KEY` を使用します。 |
| [Codex](https://developers.openai.com/codex)                  | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | すぐに使用できます。プロバイダーは `OPENAI_API_KEY` を使用します。                         |
| [GitHub Copilot CLI](https://docs.github.com/en/copilot/github-copilot-in-the-cli) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | すぐに使用できます。プロバイダーは `GITHUB_TOKEN` または `COPILOT_GITHUB_TOKEN` を使用します。 |
| [OpenClaw](https://openclaw.ai/)                 | [NemoClaw](https://github.com/NVIDIA/NemoClaw)                                   | NemoClaw ブループリントを使用して、NVIDIA OpenShell 内で OpenClaw をより安全に実行します。       |
| [Hermes Agent](https://github.com/NousResearch/hermes-agent)   | [NemoClaw](https://github.com/NVIDIA/NemoClaw)                                   | NemoClaw ブループリントを使用して、NVIDIA OpenShell 内で Hermes Agent をより安全に実行します。   |
| [Ollama](https://ollama.com/)                                 | [Community](https://github.com/NVIDIA/OpenShell-Community)                       | `openshell sandbox create --from ollama` で起動します。                         |
| [Pi](https://pi.dev/)                                 | [Community](https://github.com/NVIDIA/OpenShell-Community)                       | `openshell sandbox create --from pi` で起動します。                         |

## 主要なコマンド

| コマンド                                                    | 説明                                     |
| ---------------------------------------------------------- | ----------------------------------------------- |
| `openshell sandbox create -- <agent>`                      | サンドボックスを作成し、エージェントを起動します。           |
| `openshell sandbox connect [name]`                         | 実行中のサンドボックスに SSH 接続します。                     |
| `openshell sandbox list`                                   | すべてのサンドボックスを一覧表示します。                             |
| `openshell provider create --type [type] --from-existing`  | 環境変数から認証情報プロバイダーを作成します。     |
| `openshell sandbox provider attach <sandbox> <provider>`   | 実行中のサンドボックスにプロバイダーをアタッチします。         |
| `openshell policy set <name> --policy file.yaml`           | 実行中のサンドボックスにポリシーを適用または更新します。  |
| `openshell policy get <name>`                              | アクティブなポリシーを表示します。                         |
| `openshell logs [name] --tail`                             | サンドボックスのログをストリーミングします。                            |
| `openshell term`                                           | デバッグ用のリアルタイムターミナル UI を起動します。 |

コマンドガイド、チュートリアル、リファレンス資料については、[完全なドキュメント](https://docs.nvidia.com/openshell/latest)を参照してください。

## ターミナル UI

OpenShell には、ゲートウェイ、サンドボックス、プロバイダーを監視するためのリアルタイムターミナルダッシュボードが含まれています — [k9s](https://k9scli.io/) にインスパイアされています。```bash
openshell term

TUI では、ゲートウェイとサンドボックスの状態をキーボード操作でリアルタイムに確認できます。Tab でパネルを切り替え、j/k でリスト内を移動し、Enter で選択、: でコマンドモードに入ります。ゲートウェイのヘルスとサンドボックスのステータスは 2 秒ごとに自動更新されます。

コミュニティサンドボックスと BYOC

--from を使用して、OpenShell Community カタログまたはコンテナイメージからサンドボックスを作成します:```bash openshell sandbox create --from gemini # community catalog docker build -t my-sandbox:latest ./my-sandbox-dir # Docker gateway openshell sandbox create --from my-sandbox:latest # Docker built image podman build -t localhost/my-sandbox:latest ./my-sandbox-dir # Podman gateway openshell sandbox create --from localhost/my-sandbox:latest # Podman built image openshell sandbox create --from registry.io/img:v1 # container image

ローカルゲートウェイが使用するコンテナエンジンでビルドします。リモート
ゲートウェイの場合は、ゲートウェイがプルできるレジストリにイメージをプッシュします。

詳細については、[OpenShell Community](https://github.com/NVIDIA/OpenShell-Community) カタログと [BYOC の例](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) を参照してください。

## エージェントで OpenShell を使用する

OpenShell は、ユーザーと運用者向けに 4 つのポータブルスキルを提供しています。CLI ワークフロー（`openshell-cli`）、ゲートウェイのトラブルシューティング（`debug-openshell-cluster`）、推論のトラブルシューティング（`debug-inference`）、ポリシー生成（`generate-sandbox-policy`）です。Agent Skills CLI でインストールします。```bash
npx skills add NVIDIA/OpenShell

これらの公開されたインストール可能なスキルは skills/ にあり、インストール済み CLI のヘルプと公開ドキュメントを信頼できる情報源として使用します。OpenShell のソースチェックアウトは必要ありません。

エージェントを用いた開発

OpenShell は、それ自体が実現するのと同じエージェント駆動ワークフローを用いて開発されています。コントリビューターおよびメンテナー向けのスキルは別途 .agents/skills/ にあり、OpenShell リポジトリ上での作業を自動化するもので、ユーザーが公開スキルをインストールする際には含まれません。

• スパイクとビルド: create-spike で問題を調査します。人間が state:accepted またはロードマップへの配置によって承認するか、却下します。承認された作業は人間が所有したままにすることも、任意の人間ゲート付き agent:* 計画・実装ワークフローに進めることもできます。
• トリアージとルーティング: コミュニティの issue は triage-issue で評価されます。エージェントが技術的な妥当性と影響を確立し、人間がプロジェクトとして対応すべきか、またロードマップ上のどこに位置づけるかを決定します。
• セキュリティレビュー: review-security-issue が重大度評価と修復計画を作成します。fix-security-issue がそれを実装します。
• リポジトリメンテナンス: sync-agent-infra、update-docs-from-commits、その他の内部ワークフローが、コード、ドキュメント、エージェントインフラストラクチャの一貫性を保ちます。

エージェントによる実装は人間が指示します。ユーザーがフェーズを直接要求することも、メンテナーが任意の agent:* ワークフローを用いて計画と実装をキューに入れて承認することもできます。ワークフローチェーン全体のドキュメントについては AGENTS.md を参照してください。

ヘルプの入手

• 質問とディスカッション: GitHub Discussions
• バグ報告: GitHub Issues — バグ報告テンプレートを使用してください
• セキュリティ脆弱性: SECURITY.md を参照してください — GitHub Issues は使用しないでください
• エージェント支援によるヘルプ: npx skills add NVIDIA/OpenShell で公開 OpenShell スキルをインストールしてください

さらに学ぶ

• 完全なドキュメント — 概要、アーキテクチャ、チュートリアル、リファレンス
• クイックスタート — 詳細なインストールと最初のサンドボックスのウォークスルー
• GitHub サンドボックスチュートリアル — エンドツーエンドのスコープ付き GitHub リポジトリアクセス
• アーキテクチャ — 詳細なアーキテクチャドキュメントと設計上の決定
• ロードマップ — 計画中の作業とプロジェクトの優先事項
• RFC ボード — rfc ラベルを付けて OpenShell ロードマップで追跡される RFC 提案
• サポートマトリックス — プラットフォーム、バージョン、カーネル要件
• Brev Launchable — ローカルセットアップなしでクラウドコンピューティング上で OpenShell を試す
• エージェント指示 — エージェントコントリビューター向けのシステムプロンプトとワークフロードキュメント

コントリビューション

OpenShell はエージェントファーストで構築されています。Issue にはユーザーストーリー、問題提起、影響、受け入れ基準を含める必要があります。影響では、現在の動作の結果と、既存の回避策では不十分な理由を説明する必要があります。機能リクエストにはさらに、ワークフローレベルの提案設計と代替案が必要です。バグ報告には再現手順、環境の詳細、関連ログを追加します。プロジェクトワークフローまたは直接の要求を通じて作業が承認されたら、コントリビューターは .agents/skills/ のスキルを使用して現在のコードと動作を調査し、変更を実装し、検証する必要があります。Issue に以前の診断が含まれている場合は、それに依存するのではなく検証してください。エージェントスキルの完全な表、コントリビューションワークフロー、開発セットアップについては CONTRIBUTING.md を参照してください。

テレメトリ

OpenShell は、開発者にとってプロジェクトを改善するために匿名のテレメトリを収集します。このデータは個々のユーザー行動を追跡するためには使用されません。サンドボックス、プロバイダー、ポリシーのワークフローの集計利用状況を把握し、製品改善の優先順位付けや利用トレンドのコミュニティへの共有に役立てます。

ゲートウェイデプロイメントで OPENSHELL_TELEMETRY_ENABLED=false を設定することで、実行時にテレメトリを無効にできます。Helm インストールの場合は server.telemetryEnabled=false を設定します。OpenShell はこのデプロイメント設定をサンドボックススーパーバイザー環境に伝播するため、サンドボックス側のテレメトリ収集も無効になります。

テレメトリを完全にコンパイルから除外することもできます。テレメトリサポートはデフォルトで有効な telemetry Cargo フィーチャーであり、これを備える各クレートは他のすべてのデフォルトフィーチャーをカバーする defaults-without-telemetry エイリアスも定義しています。--no-default-features --features defaults-without-telemetry でテレメトリなしのアーティファクトをビルドします:```shell cargo build --release -p openshell-gateway --no-default-features --features defaults-without-telemetry cargo build --release -p openshell-sandbox --no-default-features --features defaults-without-telemetry cargo build --release -p openshell-driver-vm --no-default-features --features defaults-without-telemetry

生成されるバイナリには、テレメトリのエンドポイント、テレメトリ HTTP クライアント、および送信コードが含まれません。テレメトリがコンパイルから除外されると、ゲートウェイは何も送信せず、起動するサンドボックスに対してテレメトリが無効であることを報告します。Cargo には単一のデフォルト機能を差し引く方法がないため、`defaults-without-telemetry` は `--no-default-features` と組み合わせる必要があります。単独で指定するとデフォルトがそのまま残り、依然として送信を行うバイナリを生成するのではなく、ビルドが失敗します。

ゲートウェイはまた、組み込みのコンピュートドライバ用に個別の Cargo 機能を公開しています: `compute-driver-kubernetes`、`compute-driver-docker`、`compute-driver-podman`、`compute-driver-vm`、および `compute-driver-mxc`。デフォルトの機能セットを無効にし、対象のバイナリに必要なドライバとテレメトリモードのみを有効にします。例えば:```shell
# Docker only, with telemetry support.
cargo build --release -p openshell-gateway --no-default-features --features telemetry,compute-driver-docker

# Docker and VM only, with telemetry compiled out.
cargo build --release -p openshell-gateway --no-default-features --features compute-driver-docker,compute-driver-vm

# Windows MXC only, with telemetry support and bundled Z3.
cargo build --release -p openshell-gateway --no-default-features --features telemetry,compute-driver-mxc,bundled-z3

通常のビルドでは、デフォルトの in-tree-compute-drivers 互換機能を通じてプラットフォームドライバセットを保持します。Windows では、compute-driver-mxc が MXC を選択し、残りの4つの機能はサポート対象外のドライバスタブをインストールします。その他のプラットフォームでは、MXC は除外されます。

テレメトリイベントは、サンドボックスのライフサイクル結果、プロバイダプロファイルのバケット、ポリシー決定数、集計されたネットワークアクティビティ拒否カテゴリなど、匿名の運用カテゴリとカウントに限定されています。OpenShell のテレメトリは、サンドボックス名や ID、ホスト名、ファイルパス、バイナリパス、プロンプト、認証情報、プロバイダ名、モデル名、ユーザーコンテンツを収集しません。

オプトアウトは、OpenShell が発行するテレメトリにのみ適用されます。OpenShell と共に設定して使用するサードパーティサービス、モデルプロバイダ、推論エンドポイント、エージェント、またはツールには、独自の利用規約とプライバシー慣行が存在する場合があります。

当社はこのテレメトリから集計された利用傾向を2週間ごとに公開しています。最新の概要については、コミュニティテレメトリレポートをご覧ください。

通知および免責事項

本ソフトウェアは、外部の素材を自動的に取得、アクセス、または操作します。取得された素材は本ソフトウェアと共に配布されるものではなく、専ら別個の利用規約、条件、およびライセンスに従います。適用されるすべての利用規約、条件、およびライセンスを見つけ、確認し、遵守すること、ならびに特定のユースケースに対して取得された素材のセキュリティ、完全性、および適合性を検証することは、お客様の単独の責任です。本ソフトウェアは「現状有姿」で提供され、いかなる種類の保証も伴いません。作者は、取得された素材に関していかなる表明も保証も行わず、本ソフトウェアまたは取得された素材の使用または使用不能から生じるいかなる損失、損害、責任、または法的結果についても一切の責任を負いません。本ソフトウェアおよび取得された素材は、お客様自身の責任で使用してください。

ライセンス

本プロジェクトは Apache License 2.0 の下でライセンスされています。