更新日:
30/9/2026

NVIDIA Open Agent Safety Platformとは?AIエージェントを「実行中」に守る新構想

blog header image

目次

この記事のポイント

●
NVIDIAは2026年9月28日、AIエージェントの行動を継続して監視・制御するオープンな参照設計を発表した。
●
OpenShellはエージェントごとにファイル、通信、ツール、認証情報への権限を制限する。
●
追加層のSentryはBlueField-4上で、エージェントが動くホストから独立して監視・制御する構想だ。
●
OpenShellはBlueField-4なしでも利用できる。一方、ハードウェア側の保護は対応環境が必要になる。
●
「安全なAI」かどうかはモデルの回答だけでなく、実際に何を実行できるかで判断したい。

AIに「資料を要約して」と頼むだけなら、主な心配は回答の正確さだ。

‍

しかし、AIエージェントにメール、社内ファイル、コード、外部サービスを渡し、何時間も自律的に作業させると、別の問題が生まれる。

‍

誤った指示を読んだり、作業の途中で方針がずれたりしたとき、実行できる権限そのものを誰が止めるのか。

‍

NVIDIAが発表した「Open Agent Safety Platform」は、この問題をエージェント自身の判断に任せず、実行環境と、その外側に置いた監視層で扱おうとする設計だ。

‍

名称は大きいが、現時点で一般ユーザーが一つのアプリを入れれば全てのAIが安全になるという発表ではない。

‍

使えるソフトウェアと、特定の設備を使う追加保護を切り分けると、狙いが見えてくる。

何を発表したのか:OpenShellとSentryの役割

エージェントの行動を囲む三つの層

NVIDIAはアプリケーション、実行環境、インフラという三層で安全対策を説明する。

‍

アプリケーションにはモデルやツール、データがあり、その下の実行環境が許可された操作を管理する。

‍

さらにインフラ側で独立した監視と制御を加えるのが、今回の構想の特徴だ。

‍

NVIDIAの技術ブログはこれを「参照設計」と呼び、OpenShellとSentryを組み合わせて示している。

OpenShellはApache 2.0ライセンスのオープンソース実行環境で、エージェントを隔離されたサンドボックスで動かす。

‍

運用者はアクセス可能なファイル、ネットワーク、ツール、プロセス、認証情報をポリシーで指定できる。

‍

2026年9月28日公開の技術解説ではバージョン0.1.0が紹介され、既存のエージェントを作り直さずに制限を適用する方法が示された。

モデルの種類に依存しない共通の実行境界を置く発想だ。

‍

Sentryは、より独立性の高い追加層として説明される。

NVIDIAのBlueField-4 DPUとDOCAを使い、エージェントの通信やポリシー判断、ツール・データへのアクセスを関連付けて記録し、逸脱を検知・制御する。

‍

DPUはサーバー内でネットワークやセキュリティ処理を担う専用プロセッサー。

エージェントが走るホストOSとは別の場所で監視できる点に意味がある。

‍

NVIDIAはVera Rubin PODでBlueField-4をモデルへの経路に配置する設計を示している。

‍

‍

「Open」は全構成の無償提供を意味しない

OpenShellのコードは公開されているが、プラットフォーム全体の構成や必要設備まで無料で使えるという意味ではない。

‍

Sentryは希望する組織が加えるオプションであり、OpenShell自体はBlueField-4がなくても対応するローカル、クラウド、Kubernetesなどの環境で動かせるとNVIDIAは説明する。

‍

価格やSentryの個別提供条件は今回確認した公式ページに明示されていない。

モデルの安全対策と、実行時の権限制御はどう違う?

「してはいけない」と「できない」の距離

一般的なAIの安全対策には、モデルへの指示や危険な回答を抑える仕組みがある。

‍

ただし、エージェントが外部ページに書かれた指示を誤って採用したり、許可されたツールを想定外の順序で使ったりすれば、回答のチェックだけでは実際の操作を制御しきれない。

‍

OpenShellが対象にするのは、エージェントが何を試みたかではなく、環境がどの操作を許すかという境界である。

‍

例えば、GitHubの情報を読む仕事であれば、APIへの読み取りは通し、同じAPIへの書き込みは遮断する設定ができる。

‍

NVIDIAの公開手順は、ネットワークを遮断したサンドボックスから始め、読み取り専用のポリシーへ切り替える例を示す。

書き込み権限を持つ認証情報が裏側にあっても、検査対象の通信に別途「読み取りのみ」の制限をかけられるという。

ただし、どの通信を検査できるかは設定や対応プロトコルに依存する。

‍

NVIDIAはさらに、ポリシーが運用者の定めた境界を超えないか形式的に調べる「prover」を説明している。

‍

これはモデルに「安全だと思う?」と聞く仕組みではなく、モデル化された権限の範囲で許される操作を検査するものだ。

‍

モデル化していない経路や複数エージェントを組み合わせた権限まで、現時点ですべて証明できると読むべきではない。

複数エージェントにまたがる分析は継続開発中とされる。

‍

‍

監視を外へ出す理由

エージェントと同じ環境内だけに監視役を置くと、ホストの侵害や設定の破綻が監視にも影響しうる。

‍

Sentryが狙うのは、ホストから独立した経路で活動を見て、必要なら隔離できるようにすることだ。

‍

NVIDIAは自社製品ページでミリ秒単位の隔離をうたうが、公開ページで条件付きの第三者測定結果を確認できたわけではない。

実運用での遅延や検知精度は導入環境ごとの検証が必要になる。

何を防げるのか。利用場面から考える

情報を読む仕事と、変更する仕事を分ける

社内資料から回答を作るエージェントなら、指定された保存先は読めても、別部署の領域や外部送信先へは届かないようにする。

‍

開発支援なら、コードの参照とテストは許し、本番環境への変更や保護されたリポジトリへの書き込みには別の承認を求める。

‍

こうした境界を実際のファイル操作や通信に適用できれば、エージェントが誤解した指示の被害範囲を小さくできる。

‍

これは設計から導く利用例であり、どの組織でも同じ設定で直ちに実現するという意味ではない。

‍

認証情報の扱いも具体的だ。

OpenShellの解説では、エージェントには仮のキーを渡し、許可された宛先への通信だけで外部の管理層が本物の認証情報を差し込む構成が示される。

‍

エージェントが本物のキーを直接読めないようにしても、接続先サービス側の権限設定は引き続き必要だ。二つの制御を重ねて、誤操作の経路を減らす考え方である。

‍

NVIDIAは導入例として、Cadenceの半導体設計、Slackのオンデマンド型エージェント基盤、Gecko Roboticsのロボット向け管理を挙げている。

‍

これらはNVIDIAによる紹介で、各社で同一のSentry構成が稼働していることや、事故率がどれだけ下がったかを示す独立した比較試験ではない。

現段階ではOpenShellの用途の幅を示す材料として読むのが妥当だ。

‍

‍

一般ユーザーにも関係する理由

今日の一般利用者がBlueField-4を購入する場面は限られる。

‍

それでも、AIにメール送信、予約、購入、ファイル編集などを任せるサービスが増えるほど、利用者が確かめるべきことは変わる。

‍

「賢いモデルか」に加えて、「どの操作を許したか」「許可外の操作を遮断できるか」「後で履歴を調べられるか」が重要になる。

今回の発表は、その機能をサービス提供者の基盤側で整備する動きとして捉えられる。

過信できない点と導入上の制約

監視できる範囲は構成で変わる

OpenShellの利用と、Sentryを加えたBlueField-4上の監視は同義ではない。

‍

前者はオープンソースとして試せる一方、後者の独立したハードウェア層は対応設備が前提となる。

プラットフォームが他社ハードウェアとも互換とする説明は、Sentryの全機能がどの構成でも同じように提供されるという保証ではない。

‍

発表図の一部だけを見て「既存のPCでシリコン監視が始まる」と解釈するのは早い。

‍

また、アクセス制御は許可した操作の中身を常に正しくするわけではない。

‍

読み取りを許した資料が古い、許可先へ機密情報を過剰に送る、正規の権限で誤った変更を行う、といった問題には別の対策がいる。

‍

ポリシーが広すぎれば、その範囲内で誤操作が起こる余地も残る。承認設計、出力確認、バックアップ、監査を合わせて考える必要がある。

‍

OpenShellはポリシー変更の提案を受けられるが、公式解説では人による承認が初期設定とされる。

‍

ネットワークのルールは稼働中に更新できる一方、ファイルシステムやプロセス制限の変更には新しいサンドボックスが必要だ。

制御の厳しさと作業の進みやすさの間には運用上の調整が要る。

導入や利用を判断するには

まず一つの仕事で「許可する操作」を書き出す

導入側は製品名から選ぶ前に、エージェントに任せる仕事を一つ決め、読むデータ、変更してよい対象、接続先、使う認証情報、承認が必要な操作を分けたい。

‍

例えば「問い合わせを分類して下書きを作る」なら、参照する受信箱と回答履歴は指定できても、送信や顧客情報の更新は人の確認まで禁止できるか。

‍

業務上の境界が曖昧なまま高度な監視を導入しても、何を逸脱と判定するかは定まらない。

‍

次に、OpenShellのような実行時制御で拒否した操作の記録を見られるか、許可の追加を誰が承認するかを試す。

‍

ハードウェア側の監視が必要かは、その後の判断でよい。

ホストが侵害された場合の独立性、監査の要求、エージェントの規模といった条件によって、追加層の価値が変わる。

‍

価格や提供条件が不明な段階では、既存設備で得られる保護と追加投資の差を見積もるのが先だ。

‍

サービスを使う一般利用者なら、アクセス権限を細かく選べるか、送信や購入などの最終確認を要求できるか、操作履歴を後から確認できるかをチェックしたい。

‍

NVIDIAの発表自体が、普段使うAIアプリに直ちに新しい設定を増やすわけではない。しかし、安全性を見極める質問の仕方は具体的にしてくれる。

NVIDIA Open Agent Safety Platformが示した方向は、AIエージェントの能力を抑えることではなく、任せる仕事に合わせて実行可能な範囲を定め、その境界を実行中も確認することにある。

‍

現時点で手を動かして確かめやすいのはOpenShellのポリシーと監査で、Sentryを含む独立監視は対応設備と提供条件の確認が必要だ。

‍

利用者は「AIが安全と言うか」より、許可、承認、記録の三点が実際に働くかを確認したい。

‍

参照資料

NVIDIA技術ブログ:https://developer.nvidia.com/blog/nvidia-open-agent-safety-platform-a-reference-for-continuous-in-silicon-agent-monitoring/

NVIDIA製品ページ:https://www.nvidia.com/en-us/solutions/ai/agent-safety/

OpenShell技術解説:https://developer.nvidia.com/blog/add-runtime-controls-to-ai-agents-with-nvidia-openshell/

OpenShell公開リポジトリ:https://github.com/NVIDIA/OpenShell

他の記事も読む

X account logo
Xアカウントをフォロー!
最新の情報をいち早くゲット!
フォローする
back to article page
記事一覧に戻る
シェア
share link icon
‍無料会員登録
支持投票やブックマークなど、すべての機能にアクセスできます。
登録はほんの数秒で完了します!
無料会員登録
ログイン