NVIDIAは、自律型AIエージェントがエンタープライズ環境で安全かつ効率的に動作するための新しいオープンソース・ランタイム「OpenShell」を発表しました。
従来のソフトウェア・スタックは、人間が操作することを前提に設計されており、AIエージェントの自律的な動作に対応するには多くのセキュリティ上の課題が残されていました。
OpenShellは、エージェントをOSやネットワークから隔離された「サンドボックス」内で実行することで、インフラの保護とガバナンスの両立を実現します。
本記事では、NVIDIAのジェンスン・ファンCEOとServiceNowのビル・マクダーモットCEOが推進する、AIエージェントのための新しいインフラ・スタックの詳細について深掘りします。
既存のソフトウェア・スタックが抱える限界
現在のエンタープライズ・アプリケーションは、人間が操作する速度や、人間による資格情報の管理を前提に構築されています。
しかし、自律型AIエージェントは人間の数千倍の速度で動作し、24時間365日休みなくタスクを遂行することが可能です。
NVIDIAのAIソフトウェア・シニアディレクターであるアリ・ゴルシャン氏は、従来のスタックをそのままAIエージェントに適用することは、非効率であるだけでなく深刻なセキュリティギャップを生むと指摘しています。
具体的には、人間向けのアイデンティティ管理やアクセス制御モデルでは、自律的に判断を下すエージェントの行動を十分に監視・制御しきれないという問題があります。
OpenShellが提供する「エージェント・ネイティブ」なセキュリティ
OpenShellは、Apache 2.0ライセンスで公開されたオープンソースのセキュアなランタイムです。 このプロジェクトは、NVIDIAが展開する「Agent Toolkit」の核となるコンポーネントであり、エージェントがマシンスピードで動作しながらも、ホストインフラを危険にさらさない信頼された環境を提供します。
開発チームはこの6ヶ月間、エージェントがオペレーティングシステムやネットワークに直接干渉しない「サンドボックス構造」の構築に注力してきました。
サンドボックスとゲートウェイによる二段構えの保護
OpenShellのアーキテクチャは、エージェントごとに独立したサンドボックスを割り当てるレイヤードアプローチを採用しています。
サンドボックスの外部には「ゲートウェイ」が配置され、認証情報やセッション状態の管理を一手に引き受けます。
エージェントがServiceNowやSalesforceなどの外部サービスと連携する際、エージェント自身が認証キーを持つことはありません。
すべての認証処理はゲートウェイが代行し、セッションのみをサンドボックス内に渡す仕組みとなっています。
これにより、万が一エージェントがプロンプト・インジェクション攻撃を受けても、その影響範囲はサンドボックス内に限定され、企業の基幹インフラが侵害されるリスクを最小限に抑えられます。
アプリケーション層以下でのポリシー強制
OpenShellの特筆すべき点は、セキュリティポリシーをアプリケーション層ではなく、Linuxカーネルレベルで強制する点にあります。
具体的には、seccomp、eBPF、LandlockといったLinuxカーネルのプリミティブを利用しています。
これにより、エージェントがいかなる手段を用いても、設定されたポリシーをバイパスしてシステムリソースにアクセスすることは不可能です。
アリ・ゴルシャン氏は、これを「後付けのセキュリティ(Bolted-on)」ではなく「組み込まれたセキュリティ(Baked-in)」であると強調しています。
ServiceNowとの協調によるエンタープライズ実装
ServiceNow Knowledge 2026において、NVIDIAとServiceNowはOpenShellを基盤とした強力なパートナーシップの拡大を発表しました。
ServiceNowは、ナレッジワーカーやIT管理者の業務を自律的に支援するデスクトップエージェント「Project Arc」を導入します。
Project Arcは、OpenShellをセキュアな実行環境として採用し、企業のガバナンス要件を満たしながら高度なタスクを遂行します。
Project ArcとAction Fabric
Project Arcは、ServiceNowの「Action Fabric」と連携することで、すべてのエージェントのアクションに対して監査ログとガバナンスを提供します。
さらに、AIエージェントのライフサイクル全体を監視する「ServiceNow AI Control Tower」により、企業のIT部門はエージェントの挙動を完全に可視化できます。
以下の表は、人間中心のスタックとOpenShellによるエージェント・ネイティブ・スタックの違いを比較したものです。
| 機能 | 従来のスタック(人間中心) | OpenShell(エージェント・ネイティブ) |
|---|---|---|
| 実行速度 | 人間による操作スピード | マシンスピード(高速・継続的) |
| 信頼モデル | 人間を信頼されたアクターとする | エージェントを非信頼のアクターとする |
| 認証情報の保持 | ユーザーが直接入力・保持 | ゲートウェイが隔離・管理 |
| セキュリティ強制 | アプリケーション層での制御 | カーネルレベル(eBPF等)での強制 |
| 主な保護手段 | IDパスワード・MFA | 動的サンドボックス・セッション隔離 |
開発者向けのオープンなエコシステム
OpenShellは、特定のモデルやフレームワークに依存しない非依存型(アグノスティック)の設計となっています。
Claude CodeやOpenAIのCodexなど、既存の多様なAIツールをOpenShellのサンドボックス内で実行することが可能です。
また、開発ツールで大きなシェアを持つLangChainもOpenShellのGitHubリポジトリへの貢献を表明
# OpenShellのセットアップとサンドボックスの起動例
openshell run --image agent-runtime-v1 --sandbox-policy strict \
--gateway-auth-provider servicenow \
--cmd "python agent_script.py"
# eBPFベースのモニタリングを有効化して実行
openshell monitor --trace-ebpf --target-agent-id agent_001
Creating secure sandbox for agent_001...
Gateway session established with ServiceNow.
Applying seccomp and Landlock policies...
Agent process started successfully.
Monitoring active: No unauthorized syscalls detected.
