AIに業務を任せる際には、処理の速さとともに、許可した範囲で作業を進められるかも問われます。四半期売上高が前年の2倍を超えたNVIDIAは、エージェントの操作を制限し、活動を監視する「Open Agent Safety Platform」を発表しました。GPUやCPUを供給する同社が、なぜエージェントの管理にも取り組むのでしょうか。NVIDIAは、エージェントを動かす技術と、その活動を管理する技術を拡充しています。
【関連記事】複数エージェントの実行と確認を一元化する「Orca ADE」でAI開発はどう変わる？
急成長するNVIDIAとエージェント基盤の拡大
NVIDIAの成長を支えているのは、AIを動かすデータセンターへの投資です。同社は、その需要に応える計算基盤を拡充しながら、エージェントがコードやツールを使う環境の整備も進めています。業績と製品展開を合わせて見ると、安全性への取り組みも、AIの業務利用を支える事業の一部と捉えることができます。
データセンター事業が支える売上と利益
2026年8月26日に発表した2027会計年度第2四半期決算では、売上高が962億2,100万ドルとなりました。対象は2026年7月26日までの四半期で、前年同期比106％増、前四半期比18％増です。データセンター事業の売上高は890億ドルで、前年同期比117％増となり、全社売上高の伸び率を上回りました。公表値から計算すると、全社売上の約92.5％を占めます。AIを利用するための大規模な計算基盤への投資が、同社の売上拡大を支えています。
利益も拡大しています。米国会計基準であるGAAPに基づく純利益は596億8,800万ドルで、前年同期比126％増でした。売上総利益率は75.0％です。売上が前年の2倍を超えるなかで、高い収益性も維持しています。データセンター事業の規模と利益の拡大から、AI基盤への投資がNVIDIAの主要な収益源となっていることが読み取れます。
次四半期の売上高は1,080億ドル、上下2％の範囲を見込んでいます。この予想には、中国向けデータセンター用計算製品の売上を織り込んでいません。売上総利益率の予想は74.0％、上下0.5ポイントで、直近実績より低い水準です。会社は引き続き売上の拡大を見込んでいます。今後の方向性を考えるうえでは、NVIDIAの計算基盤がどのような処理を担うのかにも目を向ける必要があります。エージェントの利用が広がるにつれ、AIモデルを動かす計算基盤に加え、ツールを実行し、その結果を確認するための環境も求められます。NVIDIAは、こうした処理まで支えるAIシステムの構築に向けて、製品の拡充を進めています。
学習・推論・ツール実行を支えるシステム
NVIDIAのVera Rubinは、GPU、CPU、ネットワーク、ストレージを組み合わせたAI基盤です。GPUはモデルの学習や推論を担い、CPUはコードやツールの実行などを受け持ちます。ネットワークはそれらを接続し、ストレージは処理に使う情報を保存します。NVIDIAは、これらを一体的に設計し、モデルの学習からエージェントの処理までを支える構成を示しています。モデルの性能を生かすには、計算を行う機器に加え、データのやり取りや処理結果の保存を担う仕組みも必要です。各機器の組み合わせまで設計し、システムとして提供しています。
エージェントは、モデルが次の操作を決めた後、ツールやコードを使ってその操作を実行します。コードを生成した場合には、コードを動かし、結果を確認して、必要に応じて再びモデルへ判断を求めます。NVIDIAは、エージェントや強化学習の処理では、GPU上のモデルの出力を試験・検証するために、CPUを使った実行環境も必要になると説明しています。Vera CPUラックは、こうした実行環境を大規模に提供するための製品です。エージェントを動かす基盤には、モデルの計算処理に加え、モデルの判断に従って作業を実行する機能も必要です。
他社が基盤を構築しやすくする取り組みも進んでいます。2026年10月12日、NVIDIAは、データセンター技術の公開や共通化を進めるOpen Compute Project（OCP）に、Vera Rubinのラックと計算トレイの主要な設計を提供しました。機器を収めるラックの構成に加え、電力、冷却、接続も含めた設計です。AI基盤の運用を支えるDSXでは、ネットワーク設定、複数の計算機をまとめたクラスタの検証、ラック管理、機器の初期設定を担うソフトウェアも公開しました。こうした動きからは、計算機を供給しながら、他社によるAI基盤の構築・運用も支える方針が読み取れます。エージェントの処理とAI基盤の維持・管理を、自社の技術で支えようとしています。
安全性をエージェントの運用基盤に組み込む
AIエージェントは、目標に応じてツールやコードを使いながら作業を進めるソフトウェアです。業務では、ファイルの読み取りや外部サービスへの接続、認証情報の利用が必要になる場面があります。利用するシステムが増えるにつれ、参照できるデータが増え、更新できる対象の範囲も広がります。業務で利用するには、作業を進める能力に加え、許可する操作を定め、実行中もその範囲を超えないよう制限する仕組みが求められます。
2026年9月28日に発表されたNVIDIA Open Agent Safety Platformは、こうした権限管理と監視のためのソフトウェアと参照設計を提供します。参照設計は、システムを構築する際に使う構成や実装の指針です。中心となるOpenShellは、エージェントを隔離した環境で動かし、ファイル、通信、認証情報などの利用を制限します。Sentryは、別のハードウェアから活動を監視し、必要に応じて介入します。エージェントが操作できる範囲を、実行環境と監視の仕組みで管理する構成です。
エージェントにシステム操作を任せるには、使用する認証情報、アクセスできるデータ、許可する変更を定める必要があります。NVIDIAがエージェントの実行環境を大規模に提供するには、こうした権限を管理する技術も必要になります。今回の発表からは、計算基盤に加え、エージェントを管理する仕組みも提供していく方針が読み取れます。自社とパートナーの技術を組み合わせ、エージェントを利用できる業務を増やそうとしていると考えられます。
Open Agent Safety Platformはエージェントをどう管理するか
あるツールで禁止した操作が、別の許可済みツールでは実行できる場合があります。ツール、通信、認証情報を個別に制限していても、その組み合わせによって想定外の操作が可能になるためです。NVIDIAが公開した初期デモの事例は、設定した権限のもとでエージェントが実行できる操作を把握するのが難しいことを示しています。
別のツールを使って禁止操作を実行した事例
NVIDIAのOpenShellチームは、初期デモでエージェントがGitHubへ書き込んだ事例を、研究ノートで報告しています。リポジトリは、コードなどを保管し、変更履歴を管理する場所です。OpenShellは、RESTという方式で外部サービスの機能を呼び出す通信を検査していました。エージェントが、書き込みを許可されていないリポジトリへ書き込もうとしたところ、この検査によって要求が拒否されました。
その後、エージェントは、別のプログラムであるgit-remote-httpsとGitHubの認証情報を使って書き込みました。リポジトリを取得するため、このプログラムの利用が許可されていましたが、同じプログラムで書き込みもできました。NVIDIAのチームは、当時、その能力を把握していなかったと説明しています。ある経路で更新を拒否しても、別の経路に同じ更新を行う権限が残っていたのです。許可したツールと認証情報を組み合わせたときに、何ができるかが問題となりました。個々の設定だけを確認しても、こうした組み合わせによる操作を見落とすことがあります。
OpenShellが実行環境の外から操作を制限する
OpenShellでは、Sandbox、Supervisor、Gatewayが役割を分担します。Sandboxは、エージェントのコードやツールを動かす隔離された実行環境です。Supervisorは、その処理の外側で通信要求を確認します。Gatewayは、複数の実行環境と、それぞれに適用する方針を管理します。エージェントは許可された範囲で作業方法を選び、通信の可否は外部の仕組みが判定します。エージェントが指示をどう解釈するかにかかわらず、設定に従って操作を制限します。
ファイルの読み書きやプロセスの権限を制限するために、OSの中核部分であるカーネルの機能を使います。制限は、コマンドを実行するシェル、生成したコード、起動した子プロセスにも適用されます。通信では、接続先だけでなく、設定に応じて通信の内容も検査します。HTTPのほか、データの問い合わせに使うGraphQLや、AIと外部ツールを接続する規格であるMCPの通信も検査対象にできます。同じサービスに対して、参照を許可し、更新を拒否するなどの設定が可能です。公式解説では、GitHub上のデータの読み取りを許可し、書き込みを拒否する例を示しています。
サービスの利用権限を示すAPIキーなどの認証情報も、エージェントの処理の外側で保持・管理します。許可された接続先へ要求を送る際に、代替値を実際のAPIキーへ置き換えます。エージェントはAPIキーを直接扱わずに、必要なサービスを利用できます。接続先のサービスでは、そのAPIキーに与えられた権限によって、実行できる操作が制限されます。
作業中に新しい接続先が必要になった場合、エージェントは権限の追加を要求できます。標準の設定では、この要求は担当者の審査待ちとなり、要求を出したエージェント自身は承認できません。承認後は、新しい通信の設定を動作中の環境へ適用できます。一方、ファイルとプロセスの静的な制限は、実行環境の作成時に固定され、変更には実行環境の作り直しが必要です。OpenShellは、許可と拒否の判断を監査記録として残します。担当者は、作業が止まった際に拒否された要求を確認し、その権限が必要かを判断できます。この実行環境では、権限の要求と担当者による承認を管理し、設定を適用した後の操作も記録します。
Sentryが別のハードウェアで活動を監視する
Sentryは、エージェントが動くホストから独立して監視と制限を行います。エージェントの処理やコード実行をVera CPUが担い、監視機能は、通信などを処理する専用プロセッサのBlueField-4 DPU上で動作します。DOCAは、このDPU上で通信の検査やアクセス制御を実装するためのソフトウェア基盤です。NVIDIAの説明では、通信や権限の判定、ツールやデータへのアクセスを関連付けることで、エージェントがどのように作業を進めたかを確認できます。
ホスト側で問題が起きても監視や制限への影響を抑えられるよう、これらの機能をホストから分離しています。NVIDIAのVera Rubin PODの設計では、BlueField-4を、ノードからモデルへ至る唯一の経路に置き、その経路で活動を観測して方針を適用します。NVIDIAは、許可された範囲を超えて操作しようとするエージェントを、ミリ秒単位で隔離・停止すると説明しています。この速度は、同社が公表する性能です。
OpenShellはBlueField-4なしでも利用できます。Sentryを組み合わせると、ホストから独立した監視と制限も行えます。OpenShellで必要な制御を設定し、ホストから独立した監視が必要な環境では、専用ハードウェアも組み合わせます。
形式検証で確認する権限の範囲
OpenShellのPolicy Proverは、設定した権限が管理者の定めた上限を超えないか、形式検証で確認します。形式検証は、対象を数学的な条件で表し、その条件が成立するか調べる方法です。検証モデルが扱える範囲で、検討中の権限の設定を管理者が定めた上限と比較し、上限を超える操作ができないかを調べます。
2026年10月14日時点の文書では、ファイルアクセス、プロセスの実行主体、ネットワーク接続、REST要求などが検証対象です。この境界検証は、GraphQLやMCPのルールにはまだ対応していません。設定にこれらのルールが含まれている場合は、検証できない旨が返されます。実行時に通信を制限できる範囲と、事前に検証できる範囲は異なります。
検証に合格した場合、対象となった権限が上限内にあると確認できます。それとは別に、設定が業務に適しているか、稼働中の環境で確実に適用されるかも確認する必要があります。権限が上限を超えないかは事前の検証で調べ、エージェントの動作中は操作を制限するとともに、活動を監視します。
AIにどこまで仕事を任せられるか
エージェントが作業を完了できても、その過程でどのデータを読み、何を変更するかは別に管理する必要があります。業務への導入では、能力を評価するとともに、操作権限、追加権限の承認手順、問題発生時の対応方法を定めます。Open Agent Safety Platformは、そうした管理を既存のエージェントへ組み込むための選択肢となります。
既存のエージェントと業務システムに組み込む
OpenShellでは、Claude CodeやCodexなどの既存のエージェントに加え、独自に開発したエージェントも利用できます。オープンモデルと、内部の詳細を公開していない商用モデルの両方を利用できます。利用するモデルやエージェントに応じて、実行環境に適用する権限管理の方針を定められます。必要な能力を持つモデルを選ぶ作業と、利用を許可するファイルや接続先を決める作業を、分けて進めやすくなるでしょう。複数のモデルを使う場合も、どの業務で何を許可するかについて、共通の運用方針を定めておきましょう。
業務システムとの連携も進んでいます。NVIDIAとSalesforceは、OpenShellをSlackと統合しました。担当者はSlack上でエージェントの活動や監査記録を確認し、追加権限の要求を承認・拒否できます。SAPは、SAP Business AI Platformの一部であるJoule StudioのランタイムにOpenShellを組み込み、業務上の管理とエージェントの実行時の制限を連携させる取り組みを進めています。Anthropicとの連携では、エージェントが作業する実行環境へのアクセス制御を強化しています。
モデルやエージェント、業務ソフトウェア、計算基盤の提供元が、それぞれの技術を組み合わせています。こうした連携からは、担当者が確認や承認を行う業務の流れに、エージェントの権限管理を組み込む方向が読み取れます。導入する際には、活動の記録を誰が確認し、追加権限を誰が承認するかを定める必要があります。すでに統合された機能と、組み込みが進められている機能があるため、自社が使うサービスでどの操作を利用できるかも確認しましょう。
利用できる環境と提供状況
OpenShellは、Apache 2.0ライセンスで公開されています。2026年10月14日時点の最新安定版はv0.1.4で、10月13日UTC、日本時間では10月14日に公開されました。公式対応表では、LinuxのDebian/Ubuntuでx86_64とarm64、macOSではApple SiliconとDocker Desktopを使う構成をサポートしています。WindowsのWSL 2とDocker Desktopを組み合わせる構成はExperimentalとされています。
実行基盤には、Docker、Podman、Kubernetes、MicroVMを利用できます。DockerとPodmanはコンテナを動かす基盤、Kubernetesは複数の実行環境を管理する基盤、MicroVMは小規模な仮想マシンを使う方式です。利用する実行基盤に対応した構成とソフトウェアの安定版を選び、隔離に必要なOSの機能も用意します。
実行環境を用意した後は、業務で使う接続先や認証情報、読み書きを許可するファイルを設定します。専用DPUを使わずに導入する場合にも、これらの設定が必要です。追加権限を毎回審査する運用では、作業が止まる場面が生じます。一方、広い権限を最初から与えると、誤操作の影響も大きくなります。業務に必要な操作を整理し、その範囲に合う設定を用意する必要があります。Sentryを組み合わせる場合には、ハードウェアの構成に加え、個別の提供条件や費用も確認します。
作業能力と操作権限を合わせて評価する
エージェントの作業を評価する際には、成果物の質や処理時間に加え、作業中にどのような操作を行ったかも確認する必要があります。読み取りだけを認める業務と、データの更新まで認める業務では、権限の設定も異なります。OpenShellの公式解説でも、データの参照と更新を区別して制限する例が示されています。資料の参照や更新案の作成まで任せ、実際の更新に必要な権限は別に承認する運用も考えられます。エージェントが自ら進めてよい作業の範囲を定めると、担当者の判断が必要な場面も明確になります。
エージェントから権限変更の要求を受けた際は、どこへ接続し、どのような操作を行おうとしているかを確認します。その接続や操作が作業の目的に合っているか、扱うデータをその接続先へ送ってよいかも判断します。公式の運用文書では、許可した接続先がデータの送信経路になり得るため、業務に必要な接続先だけを許可するよう説明しています。許可を追加する前に、記録から拒否された要求の内容を確認し、どこまでの権限が業務に必要かを確かめましょう。活動をどう記録し、必要な場合にどう停止させるかを定めるとともに、担当者がどの段階で介入するかも決める必要があります。業務では、許可された範囲で作業しているかに加え、仕事の結果が正しいかも確認する必要があります。
モデルを変更しても同じ仕組みで権限を管理できる場合は、モデルの性能を比べる作業と、業務で許可する操作を検討する作業を別々に進めやすくなります。高い作業能力を持つモデルを選びつつ、自社のデータやシステムへのアクセスは業務ごとの方針で管理できます。AIへ任せられる範囲は、作業能力と、操作権限を管理する仕組みの両方で決まります。 実行時の操作制限、権限変更の審査、活動の記録を行える基盤が整うと、設定した権限のもとでどの仕事を任せられるか、担当者が判断しやすくなるでしょう。
まとめ
NVIDIAは、データセンター事業の拡大を背景に、AIの学習・推論からエージェントのコード実行、通信、管理までを支える製品とソフトウェアを展開しています。Open Agent Safety Platformは、AI基盤に操作権限の制限と活動の監視を組み込むための仕組みです。製品展開からは、計算機の供給に加え、企業がエージェントに業務を任せるための管理機能も提供していく方針が読み取れます。
計算機の設計や運用ソフトウェアが公開されると、他社はNVIDIAの技術を使った基盤を構築しやすくなります。SlackやSAPなどとの連携も進んでいます。今後は、公開された設計やソフトウェアを使うパートナーが増え、企業の業務システムにも、エージェントの実行環境や活動を管理する機能が組み込まれていくと考えられます。今後は、AIの計算処理に加え、計算基盤の運用でもNVIDIAの技術がさらに使われるようになるでしょう。
AIへ任せる業務を決める際には、モデルの性能に加え、許可する操作の範囲も検討する必要があります。データの参照やシステムの更新をどこまで認めるか、追加権限をどう承認するか、活動をどう記録し、どの条件で停止させるかを定めます。NVIDIAがエージェントの実行と管理を支える製品やソフトウェアを拡充するにつれ、企業が利用する基盤にも、こうした管理機能が組み込まれていくと予測できます。今後は、計算基盤と管理機能を組み合わせ、エージェントに業務を任せる際の運用ルールを定める企業が増えると考えられます。
参考文献
NVIDIA Open Agent Safety Platform
Add Runtime Controls to AI Agents with NVIDIA OpenShell
What we have learned applying formal methods to control AI agents
この記事を書いた人
