NVIDIAは2026年10月21日、AIエージェントを企業のITシステムやエッジ機器で安全に運用するための「OpenShell Reference Architecture」を発表した。AIモデルの推論、エージェントによるツールの実行、アクセス権限の監視・制御を異なる計算資源に分担させ、既存のOpenShell実行環境を企業向けのインフラへ拡張する構成だ。企業がAIエージェントに任せる業務を増やすなか、従業員のアクセス権限をどこまで委ねるのか、業務データがどこへ送信されるのかが重要な課題になっている。同日に公開されたCiscoの実装例では、エージェントを隔離して動かす仕組みと、企業のID管理や監査機能を組み合わせる方法が示された。
9月に発表した安全基盤を企業向けアーキテクチャへ拡張
今回の参照アーキテクチャでは、Vera RubinがAIモデルの推論を担当し、Vera CPUがエージェントの実行を制御するソフトウェアや各種ツールを動かす。さらに、専用プロセッサーのBlueField-4 DPU上で「Sentry」を稼働させ、エージェントを実行するホストとは独立した環境から、その動作を監視・制御する。エージェントが業務を実行する環境と、その権限を制限する仕組みを分離する設計だ。NVIDIAの発表によると、この構成は企業のデータセンターだけでなく、RTX SparkやDGX Sparkなどを利用するエッジ環境にも展開できるとしている。
ただし、OpenShellとSentryを組み合わせたセキュリティ基盤そのものは、今回初めて発表されたわけではない。NVIDIAは9月28日に発表した「Open Agent Safety Platform」で、ソフトウェアによるエージェントの実行制限と、BlueField-4を使った独立監視の仕組みをすでに紹介していた。今回の発表は、これらをVera Rubinなどの計算基盤や企業向けソフトウェアとの連携まで含め、実際の導入を想定した参照アーキテクチャとして体系化したものと位置づけられる。
OpenShellは、LinuxやKubernetesを使った環境に加え、Microsoft Execution Containersを利用するWindows環境にも対応する。AWS、Google Cloud、Microsoft Azureなどのクラウド環境でも動作するとされており、特定のデータセンターやハードウェアに限定された仕組みではない。一方、OpenShellをソフトウェアとして利用することと、BlueField-4によるハードウェア側の監視機能を組み合わせることは区別する必要がある。
NVIDIAの技術解説では、Sentryを追加のハードウェア保護機構として位置づけている。参照アーキテクチャでは、Vera上で動作するエージェントと利用するAIモデルの間の入出力経路にBlueField-4を配置し、Sentryが要求と応答を監視する。さらに、ネットワーク通信やファイル操作、一部のホストメモリも監視対象に含める。これにより、エージェント自身が報告する実行結果だけに頼らず、ホストの外側から実際の動作を検証・制御することを目指している。
Ciscoの「DefenseClaw」は企業のID管理とエージェントの権限を連携
Ciscoが公開した「DefenseClaw」は、OSへのサインイン情報を利用し、ユーザーや所属グループに応じてAIエージェントの権限を設定する仕組みだ。Ciscoの技術解説によると、ユーザーに適用される設定に基づいて、エージェントが接続できるネットワーク上の宛先や、利用可能な認証情報、連携を許可するMCPサーバーを制限できる。また、管理者は利用を許可するコーディングエージェントを指定し、特定のエージェントについては隔離環境内での実行を必須にすることも可能だ。
こうした制御を担うOpenShellには、役割の異なる複数の機構が組み込まれている。「Gateway」は隔離環境の作成・廃棄とポリシーの管理を担当し、「Sandbox」はファイルやプロセスへのアクセスを制限する。一方、Sandboxの外側で動作する「Supervisor」は、エージェントからの外部へのアクセス要求をポリシーと照合し、認証情報の利用を仲介する。さらに「Policy prover」は、エージェントに設定された権限が組織の定める上限を超えていないことを形式的に検証する。
ネットワーク通信も、エージェントが外部サービスへ直接接続するのではなく、信頼されたSupervisorを経由させる設計だ。Ciscoの説明によると、Supervisorは要求がポリシーに適合しているかを確認し、許可された通信に限って必要な認証情報を付与する。エージェントが動作する隔離環境には本物の認証情報を渡さず、代わりとなる文字列を使用させる。これにより、エージェントが処理中に認証情報そのものを取得するリスクを抑える仕組みとなっている。
この設計では、従業員のアカウントでAIエージェントを起動しても、その従業員が持つすべてのアクセス権限をエージェントに与える必要はない。例えば、管理者が隔離環境での実行を必須とするポリシーを設定した場合、DefenseClawはホスト上でエージェントを直接起動することを拒否し、隔離環境で実行するためのコマンドを案内するという。単にエージェントに禁止事項を指示するのではなく、企業が定めた実行方法やアクセス先をシステム側で制御する点が特徴だ。
利用統計・監査ログ・業務データの検査はそれぞれ異なる
今回の仕組みを企業に導入する際には、セキュリティ機能そのものに加え、運用中にどのようなデータが外部へ送信されるかも確認する必要がある。The Registerの報道では、OpenShellのテレメトリーが初期設定で有効になっており、これを停止しても、連携する第三者サービスにはそれぞれのプライバシー条件が適用される点が指摘されている。ただし、OpenShellが収集する利用統計と、エージェントの業務内容を検査するために送信するデータは同じではない。
具体的には、OpenShellの匿名利用統計、DefenseClawの監査ログ、Cisco AI Defenseによる内容検査では、扱うデータも送信目的も異なる。OpenShellのテレメトリーに関する公式文書（Latest v0.1.5）とCiscoの10月21日付説明を基に、それぞれの違いを整理すると以下のようになる。
| 区分 | 扱うデータと目的 | 送信先・停止範囲 |
|---|---|---|
| OpenShellの匿名利用統計 | 隔離環境の作成結果やポリシー判定の件数など、利用状況に関する集計情報。プロンプト、認証情報、ユーザーのコンテンツは収集しないと説明 | OpenShell自体の利用統計は設定で停止可能。ただし、第三者サービスによるデータ送信には適用されない |
| DefenseClawの監査ログ | 操作の拒否・承認やポリシー判定を、エージェント、隔離環境、適用ルールと関連づけて記録 | SplunkやOpenTelemetryに対応した記録先へ送信可能。ただし、外部転送が初期設定で有効とは説明されていない |
| Cisco AI Defenseの内容検査 | プロンプト、ツール呼び出し、応答内容を検査し、組織のセキュリティポリシーに基づいて判定 | Cisco AI Defenseへ検査対象のデータを送信。エージェントのネットワーク通信すべてを経由させる仕組みではない |
この区別が重要なのは、OpenShellの利用統計を無効にしても、連携先への業務データの送信まで止まるわけではないためだ。OpenShellの公式文書によると、環境変数OPENSHELL_TELEMETRY_ENABLED=falseを設定すれば、OpenShellの利用統計を停止できる。また、Helmを使用して導入する場合は、server.telemetryEnabled=falseで同様の設定が可能だ。一方、Cisco AI Defenseと連携する場合には、セキュリティ検査のためにプロンプトやツールの応答内容を送信することが明記されている。
つまり、エージェントを隔離環境で動かすことは、許可された外部サービスへのデータ送信をすべて防ぐことではない。企業は、エージェントにどの操作を許可するかに加え、セキュリティ検査のために送信される業務内容や、監査ログの保存先・転送先も個別に確認する必要がある。特に機密情報を扱う環境では、各機能が送信するデータの範囲と、自社の情報管理規定が一致しているかを導入前に検証することが重要になる。
参照アーキテクチャの公開と、本番環境での安全性は別問題
NVIDIAはOpenShell Reference Architectureを利用可能と発表しているが、提携企業による導入状況には違いがある。SAPはAIアシスタント「Joule」の開発環境であるJoule Studioの実行基盤への統合を進めており、銀行のBBVAとSantanderは、AIエージェントの安全性やガバナンスを強化するための枠組みとして検討している。こうした企業が提携先として紹介されていても、すべての製品や顧客環境で本番導入が完了したことを意味するわけではない。
Sentryの性能についても、NVIDIAは脅威やポリシー違反を検知した場合、ミリ秒単位でエージェントを隔離できると説明している。ただし、これは同社が示す性能上の特徴であり、あらゆる不正操作や誤動作を確実に検出できるという保証ではない。また、Policy proverによってエージェントの権限が組織の定めた範囲内に収まると確認できても、その権限を使って実行する個々の業務が適切かどうかは別の問題だ。技術的に許可された操作であっても、業務上望ましくない結果につながる可能性は残る。
実際の本番環境に導入する際には、利用するAIモデルや業務システムへの接続経路を確認し、OpenShellが制限する操作と、Sentryが監視・制御できる操作を具体的に照合する必要がある。さらに、従業員の所属や役割に応じたアクセス権限の設定に加え、内容検査や監査のためのデータ送信が社内規定に適合するかも検証しなければならない。参照アーキテクチャの公開は、こうした仕組みを組み合わせるための設計指針を示すものであり、個々の企業環境での安全性を保証するものではない。
今回NVIDIAが示した方向性は、AIエージェントの判断能力を高めるだけでなく、その実行権限を外部から管理できる基盤を整えることにある。エージェントの実行環境と監視・制御機構を分離し、企業のID管理や監査システムと連携できれば、自律的に処理させる業務を増やしながら、操作を制限・停止する権限を企業側に残しやすくなる。今後は、こうした仕組みが実際の業務環境でどこまで有効に機能するか、また導入に伴う性能面や運用面の負担がどの程度になるかが、企業による採用を判断するうえでの重要な材料となる。
