Claude Code Docker環境の権限管理：NVIDIA OpenShell入門

Claude Code Docker環境でNVIDIA OpenShellが担う役割

OpenShellはオープンソースのランタイムです。エージェントを動かし、そのアクセスを制御する実行環境に当たります。エージェントの推論やツールを置き換えるのではなく、その下層で動作します。

建物の中で作業する外部の業者を想像してください。作業場を用意し、特定の部屋への入室と、指定した取引先への連絡を許可します。依頼書に「慎重に作業すること」と書いたからといって、建物のマスターキーまで渡す必要はありません。OpenShellは、ソフトウェアエージェントに対してこのような境界を用意します。

ランタイムの概要では、ファイルシステム、ネットワーク、プロセスの制限と、プロバイダーの認証情報の保護が説明されています。Landlockはファイルアクセスを制限するLinuxカーネルの機構です。seccompは、プログラムがOSに対して行う低レベルの要求であるシステムコールを制限します。これらの制御はエージェントの推論の外側で強制されます。

ゲートウェイはサンドボックスとアクセスを管理します。サンドボックスの外にあるスーパーバイザーが、送信リクエストをポリシーと照合し、許可された場合に認証情報を供給します。ポリシー証明器は、モデル化した権限が定義済みの境界に収まるかを検証します。これらはエージェントが実行できる操作を制御するものであり、許可された作業の正しさを保証するものではありません。

NVIDIAは、Claude Code、Codex、GitHub Copilot CLI、Hermes、LangChain Deep Agents、OpenClaw、OpenCodeに加え、独自のエージェントやイメージを使う手順を案内しています。ただし、「対応」は各ツールがインストール済みであることを意味しません。現在のデフォルトのワークロードは最小構成のUbuntuイメージで、エージェントの起動に使うコマンドラインプログラム、つまりエージェントCLIは含まれていません。

業務上の変化は、権限設定を再利用できることです。使い回せる境界がなければ、新しいエージェントのワークフローを追加するたびに、どのファイル、シークレット、サービスを公開するかを検討し直すことになりかねません。境界を用意すれば、そうした判断をワークロードとまとめて管理し、変更をレビューできます。効果は、アクセス設定や作業中断への対応に費やしたエンジニアの工数で測ってください。そのまま引用できる、検証済みの普遍的な時間削減率はありません。

現在の対応環境はどこまでか

ホストは、現行のサポート表を見て選んでください。本稿の手順は、2026年11月8日に確認したv0.1.7表記のドキュメントに基づいています。

WSL 2はWindows上でLinux環境を動かします。MXCは、それとは別のネイティブWindows向け分離方式です。「Windows対応」を、相互に置き換えられる単一のインストール手順として扱わないでください。

Windowsに関する協業発表では、MXCを通じてOpenShellをWindowsに展開する方針が説明されています。ただし、その方向性が示されたからといって、現時点でネイティブ版を通常の安定版インストーラーとして導入できるわけではありません。現行のインストールドキュメントには、標準のリリース経路ではネイティブWindowsのバイナリを提供しないと明記されています。

初めて評価するなら、対応済みのLinuxまたはApple Silicon環境を選びましょう。サポート表には、カーネルとランタイムの要件も記載されています。必要なLandlock ABIはLinux 6.2で導入されましたが、カーネルのバージョンだけでは判断できません。ランタイムが所定の検査を通過する必要があります。macOSでDocker Desktopを使う場合、これらのLinux機能は内部のLinux仮想マシンで動作します。NVIDIA Vera CPUは必須ではありません。

CLIを導入し、最初のエージェントを動かす

まずはNVIDIAのドキュメントにあるOpenCodeの例から始めます。この例なら、サービスへのアクセスを担うプロバイダー、エージェントを含むイメージ、実行場所となるサンドボックスという3つの構成要素が見えます。以下はドキュメントに基づく手順であり、筆者のローカル環境で動作確認したという主張ではありません。

1. ホストを準備し、OpenShellをインストールします。 Dockerを使う場合は、Docker Desktopを起動しておくか、Docker Engine 28.0以降を用意します。対応済みのLinuxまたはmacOSでは、インストールガイドでcurl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | shを使っています。実行前にインストーラーの内容を確認してください。CLI、ポリシー証明器、ローカルゲートウェイがインストールされます。openshell statusを実行し、CLIからゲートウェイに接続できることを確認します。

2. モデルサービスを設定します。 この例ではOpenRouterを使います。プロバイダーを作成する前に、ホストの環境変数にOPENROUTER_API_KEYを設定してください。プロバイダープロファイルは許可するサービスのエンドポイントと実行ファイルのパスを定義し、プロバイダーが認証情報を保持します。NVIDIAのサンプルプロファイルは、/usr/local/bin/opencodeからopenrouter.aiへのアクセスを許可します。

3. プロファイルを取り込み、プロバイダーを作成してイメージを起動します。 ホスト上で次のコマンドを順番に実行します。

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

OpenCodeはイメージに含まれ、--より後ろのコマンドでメインプロセスとして起動します。最初のエージェントを動かすチュートリアルでは、OpenRouterのクレジットが不要な、この無料モデルを使っています。あくまでサンプルで選ばれているモデルの話であり、どのモデルを使っても無料になるという意味ではありません。

4. ホスト側でアクセス要求を確認します。 エージェントが未承認の宛先に接続しようとすると、OpenShellはリクエストを拒否し、範囲を絞ったルール案を作成します。openshell rule get my-agent --status pendingを実行してください。提案が作業に必要なアクセスと合致する場合は、openshell rule approve my-agent --chunk-id <chunk-id>で、その提案だけを承認します。プレースホルダーは実際のIDに置き換えます。ルールが再読み込みされ、エージェントは再試行できるようになります。

5. 実際に付与した権限を調べます。 openshell policy get my-agent --base、続いてopenshell policy get my-agent --fullを実行します。前者は基本ポリシー、後者はプロバイダーが追加するルールを含むポリシーを表示します。実プロジェクトや機密性の高いサービスを追加する前に、実効権限を確認してください。

使い捨ての評価環境での作業が終わったら、openshell sandbox delete my-agentで削除します。

稼働中に変更できるポリシーはどれか

ネットワークアクセスは作業中でも変更できます。ファイルシステムとプロセスの境界を変更するには、サンドボックスを新しく作成する必要があります。

「稼働中に反映できる」といっても、影響がないわけではありません。新しいネットワークルールを適用すると、以前のルールで確立した接続は閉じられるため、クライアントは再接続する必要があります。新しい外部ミドルウェアサービスの登録には、ゲートウェイの設定変更と再起動が必要です。保存済みポリシーにファイルシステムのパスを追加しても、実行中のワークロードにそのアクセス権が付与されるわけではありません。起動後のパス削除や起動設定の変更は拒否されます。ポリシー管理ガイドに、これらの違いが詳しく説明されています。

もう一つの落とし穴は、ポリシーファイルがないからといって、アクセス権もないとは限らないことです。ポリシーはイメージ、環境設定、ゲートウェイ全体のポリシーから与えられる場合があります。接続したプロバイダーがネットワークルールを追加することもあります。ポリシーの選択規則にもあるとおり、グローバルポリシーはサンドボックス自身のポリシーを置き換えます。単に制限を上乗せする層ではありません。

権限の範囲を把握できるコーディングエージェント用ポリシー

不具合修正を任せるエージェントには、まず書き込み可能なプロジェクトディレクトリと読み取り専用のAPIアクセスを与え、変更の公開権限は後から検討します。

以下は、プロジェクトを/workspaceに置き、curlを/usr/bin/curlにインストール済みのコーディング用イメージを想定したポリシー例です。policy.yamlとして保存し、新しいサンドボックスを作成する際に--policy ./policy.yamlを指定します。このイメージ構成向けのひな型であり、どのエージェントイメージにもそのまま適用できるものではありません。

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

エージェントは、プロジェクトと一時ファイルを編集できます。ネットワークルールでは、指定の実行ファイルがGitHub APIにGET、HEAD、OPTIONSリクエストを送ることを許可しています。任意のプログラムにインターネットアクセスを与えるものではなく、パッケージのダウンロードやGit pushも許可しません。モデルプロバイダーは別途設定します。

イメージが必要とする、書き込み可能なエージェントの状態保存用ディレクトリも準備し、意図を持って追加してください。これらのパスはサンドボックス内のファイルシステムを指します。ホスト側に似た名前のディレクトリがあっても、自動的に利用できると考えてはいけません。また、ネットワークを利用するワークロードには基本のファイルシステムパスが追加されます。この短いYAMLに書かれたパスだけが実効的なアクセス範囲に存在する、という意味ではありません。

特に注意したい設定が2つあります。hard_requirementは、ユーザー定義のファイルシステムルールを強制できない場合に起動を停止します。ただし、個々のパスが存在しない場合やアクセス不能な場合には、そのパスがスキップされることがあります。enforcement: enforceは、検査対象のうち許可されないリクエストを遮断します。一方、スキーマのデフォルトであるauditモードは違反を記録しつつ、リクエストを通します。ひな型を変更する前にポリシースキーマのリファレンスを確認してください。

許可と拒否の両方をテストします。NVIDIAのネットワークポリシーのチュートリアルでは、読み取り専用ルールの下でcurl -s https://api.github.com/zenが成功することを確認し、その後POSTが拒否されることを検証します。ホストからopenshell logs my-agent --since 5m --source sandboxを確認してください。自分のプロジェクトでは、想定したファイルへの書き込みと、範囲外のファイルへのアクセスもテストします。エージェントが起動できただけでは、セキュリティポリシーの受け入れテストを通ったことにはなりません。

最初に試したい5つのワークフロー

初期導入に向くのは、作業範囲が明確で、人が成果物を判断できる用途です。運用面で期待できる価値の順に並べると、次のようになります。

どの用途でも、生成コードの正しさやインシデント診断の信頼性が保証されるわけではありません。価値は、エージェントが作業している間に起こり得ることを限定できる点にあります。ツール選びを広く検討するなら2026年のAIサンドボックス・セキュリティツール比較、実行基盤を選ぶなら2026年のAIエージェント向けコードサンドボックス比較も参照してください。

OpenShellを軸に考えられる2つの事業案

最も有望なのは、チーム向けのコーディングエージェント導入キットです。 想定する購入者は、承認済みの環境で開発者が生産的に働けるようにしたいプラットフォーム責任者です。DataForSEOは、この実行のクエリで返された市場について、「claude code sandbox」の月間検索数を1,300と推定しています。これは環境設定への関心を示すもので、見込み客が1,300人いるという意味ではありません。また、検索者の中にはOpenShellではなく、エージェント自身のサンドボックス機能を求めている人もいます。

最小限の商品なら、対象を一つのエージェントと一つの承認済みホスト構成に絞れます。準備済みのイメージ、レビュー済みポリシー、プロバイダー設定のチェックリスト、繰り返し実行できる許可・拒否テストをそろえます。更新の責任範囲を明確にしたうえで、チームで実際に使える導入一式として提供する形です。課題は保守です。イメージ内のパス、エージェントの挙動、実験的なインターフェースは変わる可能性があります。ホスト型サービスを開発する前に、プラットフォーム責任者に保守負担について聞いてください。

もう一つは、ポリシーレビューの作業環境です。 セキュリティチームが、実効ポリシーで許可される操作を確認し、変更を比較し、承認を記録するために使えます。DataForSEOの推定では、「ai agent security」は月間480件、「ai agent security tools」は70件検索されています。別々のクエリによる幅広い需要の手掛かりなので、足し合わせて重複のない購入者数として扱ってはいけません。

MVPでは、基本ポリシーと実効ポリシーを取り込み、追加された宛先やリクエスト権限を強調し、レビュー記録にテスト結果を添付できるようにする案が考えられます。課題は差別化です。OpenShellにはすでにポリシー分析、提案、ログの機能があります。既存コマンドをダッシュボードで包むだけでなく、チームのレビュー工程を改善する必要があります。購入者と納品物を定義しやすい導入キットから始めるのがよいでしょう。

OpenShellだけでは解決できないこと

OpenShellはアクセスを制限しますが、許可された操作が業務上適切かどうかまでは判断しません。プロジェクトファイルへの書き込みを許されたエージェントは、不適切なパッチも書けます。承認済みの外部宛先にも、ポリシーで送信を許したデータは届きます。ファイルアクセスとエンドポイントの承認には、実際に何を公開するつもりなのかを反映させる必要があります。

また、ID管理、シークレットストア、監視、ガバナンスを置き換えるものでもありません。NVIDIAのランタイム制御に関する発表では、制御の強制をエージェントのワークロードの外側に置いています。周辺システムを構成する一要素として扱い、ほかの仕組みをなくす理由にしないでください。

現在のプロジェクトには、サポート表の範囲内で本番利用を想定した安定版リリースがあります。したがって、OpenShell全体を実験的なデモと呼ぶのは誤解を招きます。制約はもっと具体的です。実験的なインターフェースはパッチリリースでも変わる可能性があり、ネイティブWindowsは引き続き開発中です。またNVIDIAは、現在の適格性検証プロファイルが、リリース適格性検証ポリシーの全体を網羅していないとしています。導入するバージョンを固定し、実際に使うワークロードとホストの組み合わせを検証してください。

月曜日に始めるなら： プラットフォーム責任者に、機密性のないリポジトリとエージェントを一つずつ選んでもらいます。対応済みのホストにインストールし、イメージを準備し、ファイルとネットワークのアクセス範囲を定義してから、許可する操作と遮断する操作をテストします。最初の週は、設定にかかった時間と、作業中断への対応に費やしたエンジニアの工数を記録してください。付与したすべての権限をチームで説明できるようになってから、対象を広げます。

チームのワークフローにこの仕組みを組み込みたい場合は、本番運用に必要な制御の整備を支援します。