NVIDIAは2026年9月28日、「NVIDIA Open Agent Safety Platform」を発表しました。オープンソースのOpenShellで実行時のサンドボックスとポリシーを管理し、リファレンスシステム設計のSentryでBlueField-4 DPU側からエージェントの活動を監視・強制する構成です。
企業にとってのポイントは、モデルが危険な操作を拒否することだけに頼らず、ファイル、ネットワーク、API、認証情報に触れる経路をエージェントの外側で制限することです。OpenShellはBlueField-4なしでも対応基盤で動くため、ソフトウェアによる統制から検討できます。
Sentryの「ミリ秒単位の隔離」はNVIDIAが示す設計上の説明です。価格や測定条件は提示されていないため、導入時は、許可する操作、変更承認、監査ログ、対応ハードウェアを自社のリスクと運用体制に照らして決める必要があります。
※本記事は2026年10月5日時点の情報です。
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
NVIDIAが発表したOpen Agent Safety Platformとは｜ソフトウェアとハードウェアを分担
AIエージェントは、目標を受け取るとコードを書き、ツールを呼び出し、外部サービスへ接続しながら作業を進めます。便利になるほど、実行環境に与える権限も広がります。NVIDIAは、その権限をランタイムとインフラの層でも制御する設計を示しました。
発表されたプラットフォームは、OpenShellとSentryの2つで構成されます。OpenShellはオープンソースのセキュアなランタイムです。SentryはBlueField-4 DPU上で動くリファレンスシステム設計で、エージェントの実行環境から離れた場所に監視と強制の層を置きます。
対象はソフトウェアだけではありません。NVIDIAは、エージェントを動かすソフトウェア、ハードウェア、コンピュート、ロボティクスシステムにまたがるガバナンスを掲げています。評価用AIの自律侵入事例を解説した記事で扱われるような、許可境界を越える動きを実行環境で止める発想です。
ポイント
OpenShellはソフトウェアの実行境界、SentryはBlueField-4上の追加の独立監視層です。2つは同じ機能ではなく、導入条件も分けて考えます。
OpenShellの仕組み｜サンドボックスとポリシーで権限を外側から制限
OpenShellは、エージェントをサンドボックス内で実行し、宣言的なYAMLポリシーでアクセス範囲を定める設計です。ファイルシステム、ネットワーク、プロセス、認証情報を保護し、ローカルファイルや外部ネットワークへの無制限アクセスを防止します。
構成はGateway、Supervisor、Sandboxの3つです。Gatewayは複数サンドボックスのライフサイクルとポリシーを管理します。Supervisorは外向きのリクエストを照合し、Sandboxはカーネルレベルの制御下でエージェントを実行します。ネットワークはSupervisorを経由する構成です。
ネットワークの制御は、接続先を許可するだけではありません。OpenShellはHTTP、GraphQL、Model Context Protocol（MCP）の通信を検査し、同じAPIでも読み取りを許可し、書き込みをブロックするポリシーを設定できます。判断結果はOpen Cybersecurity Schema Framework（OCSF）の監査証跡に記録されます。
- ファイルシステム：許可したパスの外側への読み書きを制限。
- ネットワーク：接続先やAPI操作をポリシーで制御。
- プロセス：権限昇格や危険なシステムコールを制限。
- 認証情報：認可された送信先にだけ結び付け。
実際の認証情報をエージェントのワークロードに見せず、Supervisor側で許可された送信先に結び付ける点も特徴です。エージェントが別の送信先へ同じ認証情報を送ろうとしても、プロファイルで許可されていなければ拒否されます。
ポイント
自社で先に決めるのは、エージェントに渡すプロンプトではなく、読めるファイル、接続できるホスト、実行できるAPI操作、認証情報を結び付ける送信先です。
SentryとBlueField-4｜エージェントから届かない場所に監視層を置く
OpenShellがエージェントの実行環境を囲うのに対し、Sentryはその外側に置く監視層です。NVIDIAはSentryを、BlueField-4 DPU上で動くout-of-bandのウォッチドッグと説明しています。エージェントやホストのソフトウェアから独立した場所で、活動を継続的に観測し、ポリシーを適用する考え方です。
Sentryは、エージェントがソフトウェア境界の外へ移動しようとしたとき、ミリ秒単位で隔離・停止できるとNVIDIAは説明しています。導入前には、実際の構成での性能検証と、測定条件の確認が必要です。
Sentryの基盤となるNVIDIA DOCAは、BlueField DPU向けのSDK、ライブラリ、マイクロサービス、オーケストレーションフレームワークを提供するソフトウェアプラットフォームです。Sentryでは、エージェントのリクエストとレスポンスの検査、証明付きテレメトリ、エージェントのアイデンティティ検証、データやツールへのゼロトラストポリシー適用に使われます。
この考え方は、ホストやワークロード側の制御が破られたときにも別の境界を残したいシステムに適した設計です。Claudeのサンドボックス脱出事例を解説した記事のように、サンドボックスの内側だけを信頼しない設計を考えると、Sentryの位置付けを把握しやすくなります。
ポイント
SentryはOpenShellの代替ではなく、BlueField-4上に追加する独立監視層です。BlueField-4を使わない環境では、OpenShellによるソフトウェア側の統制から始められます。
モデルの安全策と何が違うか｜実行時の許可・拒否を監査する
プロンプトやモデルの安全策は、エージェントが何を試みるかに影響します。OpenShellは、試みた操作を実行環境で許可するか拒否するかを判定する層です。NVIDIAは、ポリシーを検証可能にすること、強制をout-of-bandにすること、モデルへの経路を制御点にすることなどを、エージェント安全性の原則として挙げています。
ポリシーは見た目だけで判断できません。OpenShellのPolicy Proverは、ポリシーがオペレーターの定めたアクセス境界に収まるか、ネットワークルールの追加が危険なアクセスを生まないかを形式検証します。Policy Advisorで変更を提案できる場合も、既定では人間のレビューが必要で、エージェント自身は承認できません。
この仕組みを運用へ組み込むなら、allowとdenyの判断、ポリシー変更、エージェントのアイデンティティを既存の監査やインシデント対応につなぎます。AgentOpsを解説した記事で扱う可観測性や評価の論点とも重なります。エージェントの稼働時間が長いほど、権限を狭く始めて変更を記録する設計が欠かせません。
| 層 | 主な役割 | 制御する場所 | 導入時に決めること |
|---|---|---|---|
| モデル・エージェントの安全策 | 実行しようとする行動に影響。 | モデルやエージェントの内側。 | 指示、評価、拒否動作。 |
| OpenShell | 実行・ファイル・ネットワーク・認証情報をポリシーで制御。 | ランタイムとサンドボックス。 | 許可パス、接続先、API操作、承認。 |
| Sentry＋BlueField-4 | 独立した監視、脅威検知、ポリシー適用、隔離。 | エージェントとホストの外側。 | ハードウェア分離の必要性、対応構成。 |
ポイント
モデルの安全策、OpenShell、Sentryは競合する機能ではなく、異なる場所で異なる制御を担います。自社の要件では、誰が何を許可し、どのログをどこで確認するかまで決めます。
導入時の判断｜OpenShellから始め、Sentryは保護要件で選ぶ
OpenShellはBlueField-4を必須としません。NVIDIAの説明では、ローカル、オンプレミス、クラウド、Kubernetesで実行でき、ArmやIntelなど第三者のコンピュートにも拡張可能です。公式ドキュメントの最新表示はv0.1.2で、GitHub Releasesには2026年9月28日付の同版が掲載されています。
最初の検証では、読み取り中心のエージェントを対象に、ポリシーと監査ログが想定どおり働くかを確認します。許可するファイル、接続先、API操作、認証情報の範囲を決め、denyになったリクエストの承認者も決める段階です。書き込みや本番データへの接続を広げるのは、その後です。
- 権限の範囲：読み取りと書き込みを分け、許可するファイル・API・ホストを列挙。
- 変更の承認：ポリシー変更の申請者と承認者を分離。
- 監査の接続：allow・deny・変更履歴をログ基盤で追跡。
- 分離の要件：ホスト侵害まで想定するなら対応構成を確認。
OpenShellはApache License 2.0で公開されています。一方、SentryはBlueField-4とDOCAを使うリファレンスシステム設計として説明されています。価格、独立した一般提供版、ミリ秒単位の測定条件は提示されていないため、調達判断ではNVIDIAへの確認と自社環境での検証を分けて進めます。
ポイント
OpenShellはソフトウェア統制のPoCの起点です。Sentryを選ぶかどうかは、BlueField-4の有無ではなく、ホスト侵害から独立した監視・隔離層を自社で必要とするかで判断します。
よくある質問
Q. NVIDIA Open Agent Safety Platformは何で構成されていますか？
OpenShellと、BlueField-4 DPU上のリファレンスシステム設計Sentryで構成されます。
Q. OpenShellを使うのにBlueField-4は必要ですか？
必要ではありません。OpenShellは対応するローカル、オンプレミス、クラウド、Kubernetesの基盤で実行でき、BlueField-4上ではSentryを追加の監視・強制層として使います。
Q. OpenShellはAIモデルの安全性を高める仕組みですか？
モデル自体を変更するのではなく、実行時のファイル、ネットワーク、プロセス、認証情報へのアクセスをポリシーで制御する仕組みです。
Q. Sentryはどのようにエージェントを監視しますか？
BlueField-4 DPU上でout-of-bandに活動を監視し、DOCAでリクエスト・レスポンスやアイデンティティを扱います。NVIDIAは、境界外の挙動をミリ秒単位で隔離・停止できると説明しています。
まとめ
NVIDIA Open Agent Safety Platformは、AIエージェントの権限をモデルの内側だけで扱わず、実行環境の外側で制御するための構想です。OpenShellがサンドボックス、ファイル、ネットワーク、認証情報をポリシーで管理し、SentryがBlueField-4上で独立した監視・強制層を担います。
自社で検討するなら、まずOpenShellで許可するファイル、接続先、API操作、認証情報を具体化し、allow・denyと変更承認を監査できる状態にします。ホスト侵害から独立した保護まで必要になった段階で、SentryとBlueField-4の対応構成、提供条件、検証結果を確認する流れが現実的です。
ポイント
最初に決めるべきなのは、AIエージェントに何をさせるかだけではありません。何を許可せず、誰が例外を承認し、どの記録を監査するかまでが安全な実行境界になります。
関連記事
- 非人間IDを解説｜AIエージェントの権限管理と監視のポイント
- MCPサーバーのセキュリティ実態を解説｜21000台超が露出・92%認証なしの点検ポイント
- シャドーAIエージェント対策を解説｜検出・統制の進め方
- 高リスクAIの人間レビューを解説｜監督体制で確認すべきポイント
- RAGのプロンプトインジェクションを解説｜社内DB参照で必要な防御策
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。