NVIDIA OpenShell Reference Architecture、エージェントの強制をインフラへ移行
NVIDIAは10月21日、作業を実行するソフトウェアの管理範囲を超えてエージェントの権限を扱うNVIDIA OpenShell Reference Architectureを発表した。GTC Berlinで公表されたこの設計は、モデルの演算、エージェントの実行、独立したセキュリティ強制を結び付ける。中核となる考え方は実務的だ。エージェントは自律的に作業を続けつつ、自らの制約を書き換える権限を得るべきではない。
これは、より高性能なモデルを選ぶこととは異なる購買判断を生む。企業は、権限をどこに置くか、どのインフラで強制するか、問題発生後に誰がエージェントを停止できるかを決めなければならない。求められる自律性と、正当な作業を妨げずに未承認の行為を防ぐため十分に精密な制約との間には緊張関係がある。
AnthropicのClaude Codeは、動作環境を通じてエージェントを制限する点で、有用な比較対象となる。NVIDIAはこの議論を、エンタープライズインフラと任意のハードウェア強制へと拡張する。開発者、セキュリティチーム、業務ソフトウェアベンダーは今、共通の問いに直面している。組織は業務ルールを、実行中も有効であり続ける境界にどう変換するのか。
NVIDIA OpenShell Reference Architecture、実行と強制を接続
この発表は、作業を行う構成要素とそれを統制する構成要素を分け、エージェントの封じ込めをインフラの責務として位置付けている。
リファレンスアーキテクチャとは、組織やパートナーが導入を構築する際に利用できる、文書化されたシステム設計である。これは、名前が挙がったすべての統合が、同一の機能を備えた完成品として提供されることを意味しない。プロセッサ、オペレーティングシステム、セキュリティベンダー、エンタープライズアプリケーションにまたがる発表を評価する際、この違いは重要となる。
NVIDIAのOpenShell reference architectureによると、Vera Rubinインフラがモデルを実行し、Vera CPUがエージェントハーネス、すなわちモデル呼び出しとツールを調整するソフトウェアを動かす。専用インフラプロセッサであるBlueField-4データ処理ユニットは、独立した監視と強制のためにSentryセキュリティソフトウェアを実行する。
この分担は、異なる運用上の課題を反映する。計画の生成には演算能力が必要だ。それを実行するには、ファイル、サービス、ツールへのアクセスが必要になる。そうした行為を認可するには、制約が任務の妨げになるからといって実行中のエージェント自身が変更できないルールが必要だ。
この発表はまた、ユーザーや機器に近い場所で動作するローカルおよびエッジ導入へも設計を広げている。NVIDIAはRTX Spark、DGX Spark、DGX Stationを挙げている。購入者は、ローカルワークステーションが大規模インフラ導入向けに説明される保護をすべて備えると想定せず、これらの環境を個別に評価すべきだ。
重要な変化は、これらの要素間に提案される関係性にある。開発後に付加されるアプリケーション機能としてセキュリティを扱うのではなく、このアーキテクチャはアプリケーションの下層に強制機構を配置する。エージェントのリクエストは、もっともらしい説明をエージェントが生成したから受け入れられるのではなく、インフラが評価する対象となる。
たとえば説明用のエンジニアリング作業を考えてみよう。エージェントが障害中のサービスを調査し、修復を提案する。診断ファイルの読み取り、依存関係のインストール、設定変更、修正のデプロイは、それぞれ異なる権限を表す。サービスを修復するという単一の指示は、可能なあらゆる手順が認可されていることを意味しない。
この例は、なぜこのアーキテクチャがセキュリティ専門家の範囲を超えて重要なのかを示している。自律的な実行を約束するプロダクトチームも、その実行の境界を説明しなければならない。そうしなければ、顧客が受け取るのは能力の説明だけであり、統制に関する対応する説明は得られない。
可用性についても慎重な解釈が必要だ。NVIDIAはリファレンスアーキテクチャが利用可能だとしているが、これはあらゆるパートナーの組み合わせで本番運用の準備が整っていることを意味しない。文書化された設計、サポート対象の導入、検証済みの顧客環境は、それぞれ異なる問いに答えるものである。
したがって、この発表を評価する読者にとって最初の問いは具体的だ。提案される実行・強制チェーンのどの部分が、提供される構成に実在するのか。その答えによって、購入者が評価しているのがソフトウェア制御なのか、追加のハードウェア保護なのか、あるいは両者を組み合わせるロードマップなのかが決まる。
エンタープライズチームが引き継ぐ権限の課題
強制をインフラへ移すことで企業の統制は強まる一方、ポリシー判断を暗黙のままにしておくことは難しくなる。
直接的な負担は、業務上の権限を技術的な許可へ翻訳する責任を負うチームにかかる。セキュリティチームは制限対象のリソースを定義できるが、業務責任者はどの行為がタスクに属するかを説明しなければならない。その後、インフラチームは、エージェントが触れるシステム全体でその判断を強制可能にする必要がある。
「顧客の更新手続きを準備する」といった指示には、かなりの曖昧さが含まれる。アカウント履歴の閲覧や提案書の下書きを正当化することはあるだろう。しかし、契約条件の変更、顧客記録のエクスポート、確認なしでの提案書送信を自動的に正当化するものではない。
これらは説明のための区別であり、報告されたOpenShell導入の結果ではない。これは、エージェントセキュリティがモデルの特定や、従業員がリクエストを開始したかの確認以上を必要とする理由を示す。権限は、行為、その対象、状況に依存する。
NVIDIAのagent runtime controlsは、ゲートウェイ、スーパーバイザー、サンドボックス、ポリシープルーバーの間で責任を分ける。ゲートウェイはポリシーとサンドボックスのライフサイクルを管理する。スーパーバイザーは、隔離された実行環境であるサンドボックスの外部でリクエストを確認し、認証情報を仲介する。ポリシープルーバーは、組織が定義した上限に照らして権限を確認する。
この分離は強制を行う場所を提供するが、組織はなお、それらの場所で何を許可するかを決める必要がある。形式的に検証された上限は、ポリシー間の関係を確認できる。しかし、業務部門がそもそも過剰なアクセスを与えたかどうかを、独自に判断することはできない。
これは、アプリケーション開発者とセキュリティレビュアーの議論を変える。エージェントが一般的に信頼できるかを問う代わりに、レビュアーは何を読み取り、変更し、呼び出し、送信できるかを検討できる。こうした問いはより実行可能な答えを生むが、より詳細な準備も必要になる。
開発者も関連する設計上の制約に直面する。広範な権限が与えられたときにしか成功しないワークフローは、明示的かつ限定的な要件を持つものより承認が難しい。ツールのインターフェースとタスク説明は、権限をどれほど精密に表現できるかを左右するため、セキュリティ設計の一部となる。
ナレッジワーカーにとって、この区別は情報へのアクセスから始まる。検索可能なナレッジベースは、有用な資料がどこにあるかを把握する助けになる。行為を実行するエージェントは、さらに別の判断をもたらす。情報を見つけられることが、それを共有したり、含まれるシステムを変更したりする権限も与えるのかという判断である。
組織上の負担は継続する。従業員は役割を変え、プロジェクトは終了し、認証情報は失効し、アプリケーションには新機能が加わる。エージェントの権限は、最初のデモを成功させたアクセスをそのまま維持するのではなく、こうした変化を反映する必要がある。
このため、ガバナンスは承認文書だけで終わることはできない。企業には、作業を認可する人物、その権限を表すポリシー、それを強制するインフラの間のつながりが必要だ。このつながりがなければ、独立して強制されるルールであっても、古くなった、または過度に広い判断を維持しかねない。
したがって、この発表はインフラ購入者と同じくらいソフトウェアベンダーにも圧力をかける。ベンダーは、顧客がエージェントを統制できるよう、その行為について十分な詳細を公開しなければならない。すべての操作を区別できない単一のリクエストとして示すシステムは、広範なアクセスか中断かという粗い選択を顧客に残すことになる。
ハードウェア隔離が境界を維持する場所を変える
NVIDIAのハードウェア提案は独立した強制の場所を加える。その価値は、関連する行為が実際にその場所を通るかどうかに左右される。
ソフトウェアによる制約には定義された範囲がある。その保護は、それを強制する構成要素と、それらが置く前提に依存する。別個のハードウェアセキュリティ層を追加すると、エージェントの実行環境の外部に制御を配置することで、こうした前提の一部が変わる。
NVIDIAはSentryを、OpenShellのソフトウェア境界に加わる任意の追加保護として説明している。この違いはよくある誤解を防ぐ。OpenShellを使用することが、導入にBlueField-4による強制が含まれることを自動的に意味するわけではない。購入者はセキュリティに関する主張を比較する前に、実際の構成を特定する必要がある。
NVIDIAのSentry runtime security設計では、BlueField-4がノードからモデルおよび外部システムへ至る通信経路に配置される。Sentryはトラフィック検査と、選択的なホストメモリ分析を組み合わせる。NVIDIAは、エージェントやホストソフトウェアの協力を必要とせず、数ミリ秒以内にエージェントを隔離できるとしている。
アーキテクチャ上の論理は明快だ。侵害されたワークロードに対して、ワークロード自身が無効化できない制御はより有用である。しかし、独立性だけで完全なカバレッジは確立されない。強制点は評価対象の行為を把握し、それをブロックする権限も保持していなければならない。
これは導入レビューにおける具体的な問いを生む。構成は、関連する外部接続をすべて制御された経路へ通しているか。どのローカル操作に個別の制約が適用されるか。ツールが認可済みのリクエストを受けた後、別のサービス上で作業を行う場合はどうなるか。
これらの問いは、発見された障害を記録するものではなく、設計から導かれるものである。エージェントのワークフローは複数の管理境界をまたぐ可能性があるため、重要である。次の接続をブロックしても、別のアプリケーションがすでに受理した行為を必ずしも取り消せるわけではない。
暗号化トラフィックは、別の構成上の判断をもたらす。NVIDIAは、復号・検査するよう構成された接続に対する検査を説明している。したがって企業は、どこに検査が適用されるか、どの情報が可視化されるか、その可視性が機密性要件にどう適合するかを理解する必要がある。
Anthropicとの比較は、設計上の選択を明確にする助けとなる。AnthropicのClaude Code sandboxingは、オペレーティングシステムの機構を用いてファイルシステムとネットワークへのアクセスを制限する。同社が示すアプローチは、事前に定められた境界内ではエージェントに自由を与えつつ、その外部へのアクセスを制御するものだ。
どちらのアプローチも、モデルが生成する指示の外部に制限を設ける。違いは、制限のないソフトウェアと安全なハードウェアの単純な対決ではない。購入者が比較しているのは、強制適用の仕組み、導入要件、そして障害時の前提条件である。
Anthropicの例は、開発者向けの実行環境を対象としている。NVIDIAの発表は、エージェントの実行を、オプションの独立したハードウェア層を含む、より広範なインフラ設計に結び付けている。いずれの説明も、それだけで特定のエンタープライズワークロードに最適な構成を示すものではない。
対象を限定した開発タスクを運用する組織では、既存の環境制御をそれ自体の価値で評価するべきである。ホストソフトウェアからの追加的な独立性を求める機密性の高い導入環境では、NVIDIAのハードウェアアプローチが別の選択肢となる。判断は、対処すべき脅威に沿って行う必要がある。
重要なトレードオフは、より強力な分離と、導入の複雑化の間にある。強制適用層を追加すれば、危険な活動を阻止できる地点が一つ増える。一方で、ポリシー、可視性、更新、運用上の責任分担をシステムの他の部分と整合させ続けなければならないコンポーネントも増える。
パートナー発表が示す、異なる成熟段階
最も有用なパートナー情報は、現在利用可能な機能と、依然として計画段階にある統合を区別する。
ServiceNowは、このアーキテクチャがエンタープライズ製品の議論に入りつつあることを示す具体例を提供している。同社のエンタープライズエージェントガバナンスに関する発表によれば、長時間にわたる業務向けに設計されたパーソナルエージェント「Arc」は一般提供されている。ServiceNowは、Arcのガバナンスされた実行の一部としてOpenShellによる強制適用を説明している。
同じ発表では、AI PassportとOpenShellおよびBlueFieldの強制適用との統合は将来のリリースに位置付けられている。AI Passportは、エージェントの権限を伝達することを目的とした権限記録である。現在のアプリケーションの提供開始は、提案されるガバナンスチェーン全体の利用可能性を示すものではないため、その計画段階という位置付けは重要である。
この区別は、購入者が他のローンチ資料を読む際にも有用な視点となる。現在形で示される利用可能性は、意図された統合、パートナー協業、将来の機能とは分けて評価すべきである。それらを単一の成熟度の印象にまとめると、なお必要な作業が見えにくくなる。
ServiceNowの例は、ビジネス上の問題も具体的に示している。継続的に稼働する職場向けエージェントは、変化する割り当てや権限をまたいで動作しなければならない。特に、タスクがユーザーの直接的な注意の範囲を超えて継続する場合、初回の依頼後もガバナンスが有効であり続ける必要がある。
たとえば、従業員がプロジェクトの引き継ぎを調整するようエージェントに指示するケースを考えられる。プロジェクト文書の閲覧、未完了作業の特定、メッセージの下書き、アクセス権の変更には、それぞれ異なる権限が必要になる。有用なシステムは、タスクの進展に応じてその区別を維持する必要がある。
セキュリティパートナーは、さらに異なる観点をもたらす。F5は、対応するプロンプト、応答、ツール呼び出しを検査することで、ランタイム権限を補完するAIトラフィック検査について説明している。同社の発表は、製品検証を前提とする提案段階の導入トポロジーについても区別している。
これは些細な脚注ではなく、重要な留保である。パートナーはアーキテクチャの方向性を支持できる一方で、特定の構成にはなお検証が必要な場合がある。顧客は、どの導入形態が、どの検査機能を有効にして、どのワークロードに対してテストされたのかを確認すべきである。
F5の説明は、認可とコンテンツ評価も分けている。リクエストが承認済みサービスを対象としていても、機密情報や悪意のある指示を含む可能性がある。接続の許可と、送信されるコンテンツに関する判断は、異なるリスクに対処する。
これは、既存のすべての防御をインフラレベルの強制適用で置き換えるのではなく、ローンチにセキュリティパートナーが含まれる理由の説明にもなる。提案される境界には、アイデンティティ、認可、不審な活動に関する入力が必要である。また、何かがブロックされた後の運用上の対応も求められる。
商業面での論点は、これらの層を一体的に運用しやすくなるかどうかだ。購入者は、一貫したポリシーと理解しやすいインシデント記録を確認すべきである。判断の関係性が明確でないまま別々のコンソールを追加しても、調査担当者は分断されたシステムをまたいで何が起きたかを再構築することになる。
パートナーの広がりは関心を示すが、導入の詳細の方が重みを持つ。顧客は、サポート対象の構成、文書化された制限、提供済みの統合を評価できる。ローンチ一覧に企業名があるだけでは、その顧客が現在安全に運用できる内容についての証拠としては弱い。
安全な境界は依然として正しいルールに依存する
NVIDIA OpenShell Reference Architectureは、認可された行為と適切な判断の違いをなくすものではない。
エージェントは権限の範囲内にとどまりながら、誤った結果を出す可能性がある。文書を読み違えたり、誤ったレコードを選択したり、不適切な推奨を行ったりすることもある。インフラによる封じ込めは行為の範囲を扱うが、すべての結論の正しさを保証するものではない。
この違いは、組織が「安全」という言葉をどう解釈するかを左右すべきである。安全性は幅広い結果である一方、ランタイムでの強制適用は特定の制御を提供する。有意義な評価では、防止しようとする失敗と、その防止が成り立つ前提を特定する。
スケジューリングシステムの更新を許可されたエージェントを想像してみよう。制限によって、給与データへのアクセスを防ぐことには成功するかもしれない。しかし同じエージェントが、許可されたアプリケーション内で誤った予定を登録する可能性は残る。どちらの結果も重要だが、必要となる保護策は異なる。
過度に広い権限も別の限界を生む。エージェントがデータセット全体をエクスポートすることを許可するルールが完全に強制適用されていても、そのデータセットは認可されたエクスポートから保護されない。強制適用が設計どおりに機能している場合でも、ビジネス判断の質が中心的な課題であり続ける。
過度に狭い権限は、反対の問題を引き起こす。日常業務が繰り返し止まれば、ユーザーにはより広いアクセスを求める動機が生まれる。その場合、セキュリティチームには、どのブロックが被害を防ぎ、どのブロックが正当なタスクに合わないポリシーを反映しているのかについての証拠が必要になる。
これは分析上の懸念であり、OpenShellが不必要な中断を引き起こすという判断ではない。自律性のトレードオフを評価するために必要な測定項目を示している。封じ込めの成功は、有用なタスク完了、介入頻度、拒否された操作の結果と併せて考慮すべきである。
検知のタイミングにも文脈が必要である。迅速な隔離という主張は、関連する条件が検知された後の応答を説明している。購入者はなお、どのイベントが検知の契機となるのか、また封じ込めが始まる前に外部システムがすでに動作している可能性があるのかを理解する必要がある。
利用可能なベンダーの説明は、エンタープライズワークフロー全体にわたる独立検証済みの普遍的な保証を確立するものではない。そこでは、意図されたメカニズムと統合ポイントが説明されている。本番環境におけるセキュリティの結論には、権限と有効化された保護機能を含む、導入構成に結び付いた証拠が必要である。
可観測性の拡大には、プライバシーの側面もある。通信内容や実行コンテキストの検査は調査を改善できる一方、機密情報を追加のセキュリティコンポーネントにさらすことにもなる。組織は、検査の範囲、記録へのアクセス、保持に関して明確な判断を下す必要がある。
運用責任にも同等の注意が必要である。誰かがポリシーを維持し、拒否を調査し、例外を承認し、封じ込め後にエージェントを復旧させなければならない。こうした責任が不明確なままであれば、技術的に有効な境界であっても、長期的な混乱や安全でない回避策を生みかねない。
NVIDIAのアプローチは、ルールを独立して強制適用できる場所を特定することで、これらの問いをより具体的にする。これはシステム設計における有用な進展である。ただし、ルール自体やセキュリティ判断を取り巻くワークフローを評価する必要性がなくなるわけではない。
したがって、適切な基準は限定的な主張である。すなわち、特定の制御は、指定された条件下で特定の認可されていない行為を防止する。購入者は、この説明をエージェントが害を及ぼせないという一般的な約束に置き換えるべきではない。
提供済みの統合、セキュリティ証拠、運用適合性を注視する
次に重要となるシグナルは、提供済みの機能、再現可能な検証、そして組織が結果として生じる制御を維持できることを示す証拠である。
今後数カ月における最初のシグナルは、将来の作業として説明された統合が提供されることである。ServiceNowが計画するAI Passportの強制適用は具体例となる。サポート内容と制限が文書化されたリリースがあれば、ビジネス上の権限とインフラレベルの強制適用の間に提案される接続を評価しやすくなる。
それにより、エンタープライズがガバナンス上の判断を実行層全体に持ち運べるという主張は強まる。ロードマップ上の表現が続く場合、この提案のその部分は依然として確立度が低い。購入者は、製品の提供開始と、デモや協業発表を区別すべきである。
2つ目のシグナルは、完全な導入構成に結び付いたセキュリティ検証である。有用な証拠は、ワークロード、ポリシー構成、有効化された検査、試行された認可されていない行為、観測された結果を説明する。また、どの正当な業務が引き続き可能だったかも示すべきである。
エージェントが停止されたことを示すデモは、なぜ停止されたのかを再現可能な形で示す説明よりも確立できる内容が少ない。後者は、顧客が同じ制御が自社アプリケーションにも適用されるかを判断する助けとなる。また、プレゼンテーションでは明示されない可能性のある前提も明らかにする。
検証には攻撃だけでなく、許可されたワークフローも含めるべきである。期待される業務を許可しながら認可されていない活動をブロックする境界は、このアーキテクチャの中心的なトレードオフを支持する。広範な例外への依存が繰り返されるなら、エンタープライズが自律性と精密な制御を両立できるという主張は弱まる。
3つ目のシグナルは、実際のエンタープライズ環境における運用適合性である。組織は、アプリケーション、アイデンティティ、ツールが変化してもポリシーが一貫しているかを知る必要がある。また、要求された行為と強制適用の判断との関係を説明するインシデント記録も必要になる。
管理可能なポリシー更新と理解しやすい調査を示す証拠は、導入の根拠を強める。一貫しないルールや不明確な責任分担の証拠は、別のボトルネックを示す。その状況では、強制適用能力を追加するだけではガバナンス上の問題を解決できない。
この運用評価では、ローカルおよびエッジ環境での導入に特に注意を払う必要がある。読者は、導入される特定のシステムについて文書化された機能を確認すべきである。共通の製品ファミリー名やアーキテクチャ名だけでは、強制適用の対象範囲に関するすべての疑問に答えられない。
開発者にとって実務上の帰結は、より明確な権限要件が求められることである。エンタープライズの購入者にとっては、構成固有の証拠が求められることである。ナレッジワーカーにとっては、エージェントに情報アクセスを与えることと、行動する権限を委任することの違いである。
デプロイを承認する前に、エージェントに完了させたい正確なワークフローと、その権限の範囲外に置くべき行為を特定する。正当な業務が継続することと、権限のない行為が停止されることの両方を、提案される構成で示すようサプライヤーに求める。次に、ポリシーの管理者、アクセス変更の反映方法、そして事後に調査担当者が何を再構築できるかを確認する。特に、ソフトウェアとハードウェアのリリース時期が異なる場合は、現時点の機能と将来予定されている統合を分けて扱う。NVIDIA OpenShell Reference Architectureは、その評価で検討すべき具体的なインフラ設計を提示している。これを用いて、実務上の問いに明確な回答を求めよう。エージェントが独立して稼働する間も、どの意思決定が組織の管理下に残るのか。
