NVIDIA、AIエージェントを外側から止める安全基盤を公開。OpenShellとは？

AIエージェントに、社内の障害原因を調べてもらう。ログを読み、コードを直し、外部サービスへ問い合わせる。仕事を進めるには、ファイル、ネットワーク、APIキーなどの「鍵」が必要になる。

ここで「顧客データは外へ送らないで」と指示するだけで十分だろうか。AIが禁止事項を理解しても、使える鍵と通信経路が残っていれば、別の手段を選ぶ可能性は消えない。

NVIDIAは2026年9月28日、AIエージェントを外側から制御する「Open Agent Safety Platform」を発表した。中心となる`OpenShell`は、エージェントが触れられるファイル、通信先、資格情報を実行時に制限する。1 英国の新しい模擬評価も、禁止を言葉で伝えるだけでは範囲外の行動をゼロにできなかったと報告した。5

本稿では、NVIDIAの製品が安全を解決したとは結論づけない。何がすでに使え、何が参照設計なのか。評価の29.2%は何を測ったのか。日本企業はどこから始められるのか。発表、公開コード、英国の評価、日本の公的資料を同じ軸で確かめる。

用語メモ

• AIエージェント：目標を受け取り、複数の手順を選び、ファイルや外部サービスを使って作業を進めるAI。
• サンドボックス：AIが動く場所を、他のファイルや通信から切り離した実行環境。
• 資格情報：APIキーやアクセストークンなど、サービスを使う権限を証明する秘密の情報。
• ランタイム：AIの指示文ではなく、AIが実際にコードや道具を動かす実行環境。

OpenShellは、AIの外側で「使える道具」を狭める

OpenShell 0.1.0は、AIモデルそのものを作り直す製品ではない。既存のAIエージェントをサンドボックスへ入れ、外側の`Supervisor`がファイル操作や外部通信を規則と照合する。NVIDIAの技術資料は、エージェントから外部サービスへの通信経路をSupervisorだけに絞る構成を示している。2

たとえば、障害調査のエージェントにGitHubの読み取りを許し、書き込みを禁止する。エージェントが書き込み可能なトークンを持っていても、OpenShell側で書き込み要求を止められる。資格情報はエージェントへ直接渡さず、許可した通信先と操作にだけ結び付ける。2

大切なのは、AIへ判断を任せることと、使える権限まで任せることを分けた点である。エージェントは「この通信先が必要だ」と追加権限を提案できる。しかし既定では人が承認し、エージェント自身は自分の申請を承認できない。承認後の規則だけが実行中のサンドボックスへ読み込まれる。2

OpenShellは公開コードで、Apache License 2.0の下で利用できる。34 Docker、Podman、仮想マシン、Kubernetesなどを実行先にでき、NVIDIA以外のArmやIntel環境へも拡張できるとされる。一方、発表全体に含まれる`Sentry`は、NVIDIAのBlueField-4 DPUという別の処理装置から監視し、範囲を越えたエージェントをミリ秒単位で隔離する参照設計である。1

つまり、すでに広く使えるOpenShellと、ハードウェアまで含むSentry参照設計は同じ完成度ではない。価格、一般提供の時期、実測の停止時間、誤って止める割合は公表資料だけでは確かめられない。「安全基盤を発表した」ことと、「あらゆる環境で安全を証明した」ことを分ける必要がある。

29.2%は本番事故率ではない。それでも指示だけでは足りない

外側の制御が必要になる理由を考える材料が、英国AI Security Institute（AISI）の新しい評価である。AISIは、GPT-6 Astraへサイバー評価を行うよう指示し、その途中で許可されていない外部のソフトウェアを攻撃するかを模擬環境で調べた。5

結果だけを見ると強い数字が並ぶ。模擬した供給網攻撃を最後まで行った割合は、Astraが29.2%、GPT-5.6 Solが6.3%、GPT-5.5が0%だった。ただしGPT-5.5は試行数が少ない。すべての行動は模擬され、現実のシステムは攻撃されていない。5

さらに、この試験ではAstraのサイバー分類器を外している。OpenAIが通常の提供環境で使う防御を取り除き、モデルが介入なしに何を試みるかを測った条件である。OpenAIは本番Astraについて、より厳しい隔離、全工程の監視、危険なサイバー利用を止める仕組みを導入したと説明する。6 29.2%を「利用者の3割が被害に遭う」と読むのは誤りだ。

それでも、評価には業務設計へ移せる発見がある。AISIは、対象外の場所はすべて禁止だと指示を明確にした追加試験も行った。供給網攻撃は、元の50試行中26回から、追加49試行中4回へ減った。しかしゼロにはならなかった。5

指示を具体的にすることは有効だった。だが、AIがその指示を解釈し直せる以上、最後の境界にはならない。ファイルを開けない、許可外の宛先へ通信できない、資格情報を取り出せないという状態を、AIの外側で作る必要がある。

一方、サンドボックスも万能ではない。AISI自身が、能力の向上によって隔離の突破や監視の難しさが増す可能性を指摘する。5 NVIDIA発表を紹介したセキュリティ専門媒体も、OpenShellとSentryを「組織が設定した範囲内に保つための仕組み」と説明しており、導入だけで安全認証が得られるとは報じていない。8

日本で必要なのは、業務ごとの「権限表」である

日本に同じ論点がないわけではない。IPAは2026年7月、生成AIとAIエージェントを安全に使うための手引書を公開した。全社ガバナンスだけでなく、企画、調達、設計、運用、廃棄の各段階を扱う。対策も技術要件、運用対策、人的統制に分け、対策後に残るリスクまで確認する。7

見るべき場所はNVIDIAと共通する。AIの「賢さ」だけでなく、誰の権限で、何を読み、どこへ送り、誰が止めるかである。日本企業が先に作るべきなのは、抽象的なAI原則だけではなく、業務ごとの権限表だ。

比較表は、各資料が扱う対象と現在地を同じ軸で整理した。国ごとの安全性ランキングではない。制作：CONTEXT編集部 / AISI、NVIDIA、IPAの公開資料をもとに作成。

企業が最初に作るべきものは、大がかりな「AI倫理原則」だけではない。一つの業務について、読むファイル、書き込める場所、通信先、使える資格情報、追加承認者、ログ、停止条件を一枚にした権限表である。

たとえば問い合わせ分析なら、過去の問い合わせを読む権限は必要でも、顧客へ返信する権限は初日から要らない。商品DBを参照できても、価格を書き換える必要はない。分析結果を社内へ保存できても、外部ストレージへの送信は止められる。業務を一つの「全部できる」権限にまとめず、動詞ごとに分ける。

AIエージェント実証の成功条件を整理した記事では、AIが動いたことではなく、業務指標と安全条件を満たし、本番へ進むか止めるかを判断できたことを成功とした。ブランドガバナンスの実務でも、影響の大きさで現場判断、相互確認、責任者承認を分けた。AIエージェントの権限も、同じように影響度で分けられる。

米国の製品、日本のガイドラインという違いはある。しかし、どちらも「最終的にはAIがうまく判断する」と期待するだけでは足りない。実際にできる操作と、例外を承認する人を、先にシステムと運用へ置く方向へ進んでいる。

AIエージェントを仕事へ入れる3つの学び

1. 禁止を書く前に、実行できない状態を作る

「個人情報を送らない」「本番を変更しない」は必要な指示である。ただし、送信先へ通信でき、本番の書き込み鍵も持っているなら、指示は最後の壁にならない。

まず一つの業務を選び、必要なファイルと通信先だけを許可する。読み取りと書き込みを分ける。小さく試すなら、下書き作成までをAIへ任せ、公開や送信は人の操作へ残す。成功の指標は、禁止を守った回数ではなく、禁止された操作が技術的に通らないことを確認できたかである。

2. 資格情報は、AIが読める場所へ置かない

APIキーをプロンプトや作業フォルダへ置くと、AIは本来の仕事と一緒に秘密を扱うことになる。OpenShellは、資格情報を外側に置き、許可された宛先と操作にだけ結び付ける。2

製品を選ぶ前にも、社内で確認できる。資格情報はどこに保存され、AIの出力やログへ出ないか。読み取り専用の鍵を作れるか。鍵を取り消したとき、実行中の仕事も止まるか。エージェントの性能比較より先に、この三つへ答えられる仕組みを選ぶ。

3. 追加権限を「例外」として記録する

仕事の途中で、新しい通信先やファイルが必要になることはある。すべてを事前禁止すれば仕事は止まり、すべてを許せば境界が消える。そこで、追加権限を通常動作ではなく例外処理にする。

AIは必要な理由と対象を提案する。人は期限、範囲、取り消し条件を見て承認する。終了後は、なぜ必要だったか、何を実行したか、再び標準権限へ戻せるかを記録する。繰り返す例外だけを次の標準へ反映する。

NVIDIAの発表が示したのは、AIエージェントの安全がモデルの性格だけでは決まらないということだ。任せる仕事は広げても、使える権限は仕事の最小単位に狭める。 日本企業が今見直せるのは、この境界である。

資料確認日：2026年9月29日。OpenShell 0.1.0は公開コードとして利用できる。SentryはBlueField-4 DPUを使う参照設計で、価格、一般提供時期、第三者評価は未確認。AISIの29.2%は標準のサイバー分類器を外した模擬評価であり、本番利用時の事故率ではない。