AI テクノロジー

NVIDIA Open Agent Safety Platformとは?OpenShellとSentryでAIエージェントの権限をどこで止めるのか

2026年9月30日

AIエージェントの実行環境を緑のポリシー境界で囲み、外側の橙色監視モジュールが見守るOpen Agent Safety Platformの図解

AIエージェントに調査、コード修正、ファイル操作まで任せるほど、「何ができるか」と同じくらい「どこまで触れてよいか」が重要になります。想定外の経路へ進んだとき、止める場所が一つだけでは心細いからです。

NVIDIAが9月28日に発表したOpen Agent Safety Platformは、その境界を実行環境と独立した監視側へ分けて置く構想です。OpenShellとSentryが中心になります。

ポイントは「AIを賢くして危険をなくす」話ではありません。渡す権限を先に決め、逸脱したときに記録・停止できる土台を作ろうとしている点です。

Open Agent Safety Platformは何を追加するのか

開発者が緑色の境界で区切られたAIエージェントのサンドボックス作業画面を確認している様子
権限をタスク単位で区切ると、エージェントの実行範囲を見直しやすくなります。

NVIDIAの発表では、Open Agent Safety PlatformはOpenShellのオープンソースソフトウェアと、NVIDIA Sentryの参照システム設計で構成されます。OpenShellは、エージェントの実行をランタイム境界に入れ、行動を追跡しながらポリシーを適用する役割です。

ここでいうポリシーは、抽象的な「安全に動いて」という指示ではありません。接続先、読書きできるファイル、使えるプロセスを実行前から具体的に扱う考え方です。

![境界を設定したサンドボックス内で小さなタスクを実行するAIエージェントの開発画面](inline-01-openshell-sandbox-workspace.png)

エージェントに「必要な権限だけ」を渡すには、目的を小さく切ることが近道です。たとえば文書の要約、テスト結果の収集、下書き作成を、メール送信や本番データ更新と同じ権限で走らせない設計が基本になります。

OpenShellは何を守るための実行環境?

緑色の計算ラックと橙色の監視ラックが離れて配置され、一本のケーブルで接続されたデータセンター
実行環境とは別の監視点を置く構成のイメージです。

OpenShellのセキュリティ指針では、ネットワーク、ファイルシステム、プロセス、推論という四つの層で制御を説明しています。たとえば未許可の外部接続を抑え、資格情報や設定ファイルへ無制限に触れないようにし、危険なプロセス操作を絞る、といった役割です。

資料では、サンドボックスを作る時点で固定される制御と、稼働中に更新できる制御を分けています。後から接続先を足すときも、全面許可ではなく、必要性を確かめて範囲を狭く追加する形が望まれます。

導入前に書き出したいのは、モデル名よりも権限の一覧です。読むファイル、書き込める場所、接続先、使うコマンド、外部へ送ってよい情報、そして人が承認する操作を、タスク単位で並べると設定の穴を見つけやすくなります。

Sentryが「外側で見る」ことに意味がある

運用担当者が許可と停止を示す画面でAIエージェントの権限と実行履歴を見比べている様子
権限の追加と実行履歴を、同じ運用の流れで確認します。

今回のもう一つの要素であるSentryは、NVIDIAの発表ではBlueField-4 DPU上で動く、アウトオブバンドの監視・制御用参照設計です。エージェントが動く側とは別の場所で振る舞いを見て、境界を越えようとしたエージェントをミリ秒単位で隔離できる、と説明されています。

狙いは、エージェント自身やアプリ内部の判断だけへ監視を預けないことです。実行側が想定外の状態になっても、別の監視点が通信、ポリシー判断、ツールやデータへのアクセスを関連付けて追えるようにする。NVIDIAの技術解説では、この二層をランタイムのサンドボックスと独立したハードウェア監視として示しています。

![独立した監視装置がAIエージェントの計算ノードを観察するデータセンターの情景](inline-02-independent-agent-monitoring.png)

「ミリ秒で隔離」は、すでに外部へ送った情報や完了した操作を巻き戻す魔法ではありません。またSentryは、NVIDIA Vera CPUとBlueField-4 DPUを使う参照設計として発表されています。すべてのPCや既存サーバーで同じ構成がすぐ使える、と読み替えないようにしましょう。

監査ログは、失敗後のためだけではない

小規模なテスト環境でチームが承認ボタンとフロー図を確認しながらAIエージェントの段階導入を検討する様子
本番権限を渡す前に、小さな検証環境で運用を確かめるイメージです。

エージェント運用では、止めることに加え、どの権限で何を実行したかを追えることが重要です。失敗後だけでなく、権限を広げるか、人のレビューをどこに置くかの判断材料になります。

OpenShellはGitHubでApache-2.0ライセンスの公開プロジェクトとして提供され、ゲートウェイとコンピュートドライバーを組み合わせる前提が案内されています。アプリへ一つのライブラリーを足せば終わる話ではありません。

![権限リクエストと実行履歴を見比べながら停止判断を行う運用担当者](inline-03-permission-audit-review.png)

ログを残すだけでは判断は速くなりません。誰が見るか、どの操作で通知するか、どの記録を何日保持するか、停止後にどう復旧するかまで決めて初めて、監査記録が運用に役立ちます。

まずは「読める・下書きできる」範囲で試したい

いきなり本番のメール、顧客データ、クラウド設定を操作させる必要はありません。最初は読み取り専用の情報整理、テスト環境でのコード確認、送信前の下書き作成のように、結果を人が確認しやすい仕事から試すのが現実的です。

人が止める経路や責任の置き方は、AIエージェント導入で確認したい「人間による制御」で扱ったテーマともつながります。OpenShellやSentryのような技術は、その判断を代わりに引き受けるものではなく、決めた境界を実行環境で守りやすくする手段です。

![テスト環境でAIエージェントの段階導入と人の承認手順を確認するチーム](inline-04-staged-agent-pilot.png)

強いエージェントほど、境界の設計が価値になる

Open Agent Safety Platformは、AIエージェントの能力を止めるためだけの仕組みではありません。必要な仕事だけを任せ、見える形で記録し、越えてはいけない範囲では別の層から止める。そうした設計があれば、便利さを求めて権限を一括で渡すより、段階的に使える領域を広げやすくなります。

OpenShellは公開ソフトウェアとして試せる一方、Sentryを含む構成には対応するインフラ条件があります。最小権限のポリシー、確認するログ、隔離後の復旧手順を小さな検証環境で確かめる。それが実務に効く安全基盤への第一歩です。

-AI, テクノロジー
-, , , , , , ,