権限は、操作を実行する場所で制限する

AIエージェントに障害の原因調査を頼む。ログを読んで原因を探すだけなら、調査対象を読む権限があれば作業できます。しかし、本番環境を書き換える権限まで渡していれば、AIが修復を試みたとき、その操作も実行できてしまいます。依頼文に「調査だけ」と書くことと、システムが更新操作を拒否できることは、別々に設計する必要があります。

2026年9月28日、NVIDIAはOpen Agent Safety Platformを発表しました。ソフトウェアからハードウェア、ロボティクスまでを対象に、AIエージェントの動作に制約を設ける基盤です。

当社がこの発表で注目するのは、AIの判断を受けて操作が実行される経路に、AI自身が変更できない権限の制御を置くという設計です。外部の文章に誘導された場合にも、課題を解く過程で当初の目的から外れた場合にも、実行できる範囲を限定する。この考え方は、業務を自動化するAIにも、物理世界で動くロボットにも関係します。

OpenShellとSentryが担う役割

発表で示された主な構成要素は、実行環境を制御するOpenShellと、独立した監視を加えるSentryです。

構成要素 NVIDIAが説明する役割
OpenShell AIエージェントを隔離した環境で動かし、ファイルやプロセス、外部サービスへのアクセスをポリシーに沿って制限するオープンソースのランタイム
Sentry BlueField-4 DPU上でエージェントの動作を独立して監視・制御する、参照システム設計の追加レイヤー

ランタイムは、プログラムが実際に動くための環境です。ここで制約を適用すれば、AIがシェルや生成したコードを使う場面にも制御を設けられます。Sentryは、エージェントが動く環境の外側に監視を置く構成として説明されています。NVIDIAの技術解説

OpenShellと、特定のハードウェアを使うSentryの参照設計は、導入条件を分けて検討する必要があります。導入を判断する際は、使う版と実行環境について、対応する機能と制約を確認します。

接続先だけでなく、許可する操作を決める

OpenShellのアーキテクチャでは、エージェントを動かす隔離環境と、アクセスの可否を判断するSupervisorを分離しています。外部への通信はSupervisorを経由させ、実際の認証情報もエージェントの外側で扱います。

NVIDIAのOpenShellの技術解説では、検査対象として設定したHTTP・GraphQL・MCP通信について、読み取りを許可し、書き込みを拒否する制御が紹介されています。また、ポリシー変更で許可される範囲を形式的に分析する仕組みも説明されています。その分析が扱うのは、モデル化された権限の範囲です。

ここから企業が考えるべきなのは、「このサービスに接続してよいか」に加え、「このサービスで何をしてよいか」です。次の表は、障害調査を担当するAIを想定した当社の設計例です。

操作 設計例
調査対象のログを読む 対象のシステムと期間を限定して許可する
修正案をつくる 作業用の環境に保存し、本番への反映は別の承認経路にする
本番データを書き換える 調査用のエージェントには許可しない
接続先や権限を増やす エージェントから独立した管理者が、必要性と影響範囲を確認する

権限の設定が広すぎれば、制御が設定どおりに動いても、望ましくない操作を通してしまいます。許可されたAPIへ機密情報を送ることや、許可された更新操作で誤った値を書き込むことも、アクセス制御だけでは判断できない場合があります。操作対象、送信内容、変更内容についての検証も、業務に合わせて設計します。

ロボットでは、動作の条件まで検証する

同じ9月28日、Gecko RoboticsもNVIDIAとの協業を発表しました。OpenShellを使い、AIを搭載したロボットを人が定めた権限の範囲で動かす取り組みです。同社はKomodoロボットについて、AIエージェントとハードウェアの間に独立した制御層を置く構成を説明しています。

ロボットへの適用で当社が重視するのは、操作の許可と、その場での動作の妥当性を両方確認することです。たとえば搬送ロボットに移動命令を出す権限があっても、通行可能な領域、速度の上限、機体の状態との整合は、命令を実行する手前で検証する必要があります。カメラ入力への敵対的な干渉で認識が誤った場合にも、許可された操作の範囲内で危険な動作を選ぶ可能性は残ります。

この検証条件は、用途ごとに定義します。移動先や速度などの制約、センサー情報が古い場合の扱い、監視系との通信が途切れた場合の移行先を、制御設計者と安全担当者が決めます。荷を把持したアームなら、エージェントの処理を止める際にも、荷を安全に保持する制御が必要です。

エージェントの隔離や停止と、機械を安全な状態に移すことは、連動させて設計する課題です。これらは当社の設計上の見解であり、OpenShellやSentryに上記の動作検証機能が備わっているという説明ではありません。役割の分離や異常時の移行については、Physical AIのセキュリティ設計でも整理しています。

最初に確認するのは、許可した操作が通る経路

導入の検討では、まずAIの出力から、APIへの要求や機械への命令が実行されるまでの流れを描きます。制御を通らずに操作できる経路がないか、認証情報やポリシーを誰が変更できるかを確認します。

そのうえで、許可する操作を業務単位で定義し、必要な操作が通ることと、許可しない操作が拒否されることを検証します。ロボットでは、動作条件に反する命令の拒否に加え、監視や通信が失われたときに、事前に定めた状態へ移行できるかも確認します。記録には、実行・拒否した操作と適用したポリシーを残し、変更後も同じ条件で確かめます。

当社は、今回の発表を、AIの利用範囲を実行環境で管理する設計を具体化した動きとして捉えています。導入する製品とともに、何を許可するか、どこで検証するか、異常時にどう振る舞うかを決めることが、現場で使うAIの設計につながります。

AIエージェントやロボティクスの設計・PoCについては、当社のAIシステム受託開発とお問い合わせフォームをご覧ください。

参考資料

資料は2026年10月6日に確認しました。製品構成と取り組みの説明は各社の公表情報に基づきます。障害調査の例、ロボットの検証条件、導入時の確認事項は株式会社U-Recの分析・設計提案です。本記事は、当社によるこれらの製品の実機検証結果を示すものではありません。