メインコンテンツにスキップ

NVIDIAがOpenShellをCNCFに寄贈――AIエージェントを安全かつ大規模に動かすKubernetes基盤の全体像

技術
解説
NVIDIA
AIエージェント
結論：2026年11月10日、NVIDIAはAIエージェントの行動を制御する実行環境「OpenShell」をCNCF（Cloud Native Computing Foundation）に寄贈し、あわせてGPUクラスタ向けのオープンソー…
作者

obelos

公開

2026年11月12日

更新日

2026年11月12日

結論：2026年11月10日、NVIDIAはAIエージェントの行動を制御する実行環境「OpenShell」をCNCF（Cloud Native Computing Foundation）に寄贈し、あわせてGPUクラスタ向けのオープンソース部品を公開しました。AIエージェントを安全に、大規模に、GPUを無駄なく動かすための基盤を、Kubernetes上にオープンな部品としてそろえる発表です。

ポイントは次の3つです。

  1. 安全性：エージェントがアクセスできるファイル・通信先・APIをYAMLのポリシーで宣言し、実行環境側で強制する「OpenShell」をCNCF Sandboxに寄贈した
  2. 大規模化：待機時間の長いエージェントを少数のPodで実行する「Agent Substrate」（Google発）との連携を進める
  3. GPUの効率：推論サーバーを数十秒で起動する「Snapshot」、GPUクラスタ向けのマネージドKubernetesを構築する「NVKE／NVKR」、性能の低いGPUノードを検出する「DSX OS」を公開した

この記事では全体像を整理します。個々の部品は、次の記事で詳しく解説しています。

前提：コンテナ、Kubernetes、CNCF

コンテナは、アプリケーションと、その実行に必要なライブラリや設定をまとめてパッケージにしたものです。どのサーバーで動かしても同じように動作します。

Kubernetesは、多数のサーバー上でコンテナを自動的に配置・起動・監視するソフトウェアです。サーバーが故障すれば別のサーバーでコンテナを起動し直し、負荷が増えればコンテナを増やします。Kubernetesでコンテナを動かす最小単位を Pod と呼びます。

CNCFは、Kubernetesを管理している非営利団体で、Linux Foundationの傘下にあります。特定の企業に依存しない形でオープンソースプロジェクトを運営します。プロジェクトは成熟度に応じて、Sandbox → Incubating → Graduated の3段階に分かれます。OpenShellは最初の段階であるSandboxに入りました。

AIエージェントに専用の制御が必要な理由

従来のアプリケーションは、あらかじめ決められた処理を決められた順序で実行します。AIエージェントは、LLMの判断に基づいて次のような操作を自律的に行います。

  • ファイルを読み書きする
  • 外部のAPIを呼び出す
  • コマンドを実行する

悪意がなくても、誤った判断で重要なファイルを削除したり、外部に情報を送信したりするおそれがあります。そのため、エージェントがアクセスできる範囲を、エージェントの外側で制限する仕組みが必要になります。OpenShellはそのための実行環境です。

OpenShellの仕組み

概要

NVIDIAの説明では、OpenShellは自律エージェントを保護し統制するためのオープンソースの実行環境です。エージェントのプログラムを書き換えずに、外側から動作を制限できます。2026年3月のGTCで発表され、9月にはエージェントの安全対策をまとめた「Open Agent Safety Platform」の実行環境レイヤーとして位置づけられました。

4つの制御領域

公式ドキュメントによると、OpenShellは次の4つの領域を制御します。ポリシーはYAMLで宣言します。

領域 制御の内容 実行中の変更
ファイルシステム 読み書きできるパスを制限する 作成時に固定
ネットワーク 許可していない外部への通信を遮断する 実行中に変更可
プロセス 権限昇格や危険なシステムコールを遮断する 作成時に固定
推論 モデルAPIへの呼び出しを、管理下の接続先に振り替える 実行中に変更可

ネットワークの制御は、接続先のホストだけでなく、HTTPのメソッドとパスの単位まで指定できます。公式のサンプルでは、GitHub APIに対して読み取り（GET）を許可し、書き込み（POST）を拒否するポリシーを示しています。

Gateway・Supervisor・Sandbox

OpenShellは3つのコンポーネントで構成されます。

コンポーネント 役割
Gateway 複数のサンドボックス（エージェント群）を管理する窓口。CLIやSDKから操作する
Supervisor ポリシーを判定し、外向きの通信をポリシーと照合する。信頼される側
Sandbox エージェント本体を隔離して実行する。信頼されない側

重要なのは、ポリシーの判定は常にSupervisor側で行い、エージェントが動くSandbox側では判定しないという分担です。Sandboxはエージェントが実行しようとしている操作をSupervisorに報告するだけで、許可するかどうかはSupervisorが決めます。ファイルシステムやプロセスの制御は、カーネルレベルの機能で強制されます。

ポリシーをYAMLで管理するため、セキュリティ設定をコードと同じようにバージョン管理し、レビューできます。

利用状況

NVIDIAによると、OpenShellはすでに数百の組織が利用し、公開から1年足らずで数万件の貢献を受けています。

同時に発表された部品

OpenShellの寄贈と同時に、Kubernetes上でエージェントとGPUを扱うための部品が発表されました。

部品 内容 状態
Agent Substrate 待機中のエージェントの状態を退避し、少数のPodで多数のエージェントを実行する Google発、CNCF Sandbox
NVIDIA Snapshot 推論サーバーの初期化済みの状態を保存し、数十秒で復元する オープンソース
NVKE／NVKR GPUクラスタ向けのマネージドKubernetesサービスを構築する部品 パブリックプレビュー
DSX OS（AICR／NVCRE／NVSentinel） GPUクラスタの構成管理・認定試験・運用監視 オープンソース（Apache 2.0）

それぞれの役割は次のように整理できます。

  • OpenShell：エージェントが何をしてよいかを制限する
  • Agent Substrate：エージェントを大規模に実行する
  • Snapshot：推論サーバーを速く起動する
  • NVKE／NVKR：GPUクラスタを顧客に提供する
  • DSX OS：GPUクラスタの品質を保証する

数字で目を引くのはSnapshotです。設計パートナーのCrusoeは、HGX B300上でGLM-5.3のワークロードが使える状態になるまでの時間を約8分から31秒に短縮したと報告しています。

考察：NVIDIAがこの領域をオープンにする理由

ここからは筆者の考察です。

NVIDIAの主力製品はGPUですが、GPUの価値は「どれだけ休まず処理させられるか」で決まります。エージェントの時代には、GPUの手前で次のような問題が起きやすくなります。

  • エージェントを安全に動かせないため、本番環境に出せない
  • エージェントの大半が待機状態で、計算資源を確保したまま使っていない
  • 推論サーバーの起動に数分かかり、需要の急増に追いつけない
  • 1台の性能の低いGPUが混ざり、クラスタ全体の学習が遅くなる

今回の発表は、これらの問題に1つずつ対応する部品になっています。しかも自社製品として囲い込まず、CNCFやApache 2.0ライセンスで公開しています。周辺のソフトウェアを業界標準にしておけば、その上で最も性能が出るGPUが選ばれる、という戦略と読めます。

一方で、NVKE／NVKRはパブリックプレビューで本番利用は推奨されておらず、Agent SubstrateもAPIが変わり得る段階です。発表された機能と本番で使える機能は区別して、成熟度を確認しながら導入を検討する必要があります。

まとめ

  • OpenShellは、エージェントがアクセスできるファイル・通信・APIをYAMLで宣言して強制する実行環境で、CNCF Sandboxに寄贈された
  • 同時に、Agent Substrate（大規模実行）、Snapshot（高速起動）、NVKE／NVKR（クラスタ提供）、DSX OS（品質保証）が発表された
  • いずれもオープンソースで、エージェントとGPUを本番運用するための基盤をKubernetes上にそろえる動き

あわせて読みたい

参考