Blog ブログ

【10月技術ブログ】AIエージェントを「箱」に閉じ込める? NVIDIA Open Agent Safety Platformを解説

こんにちは、新入社員のNです。

AIエージェントが評価環境から抜け出して実在のシステムに侵入する、いわゆる「脱走」事案が相次いでいます。これを受けてNVIDIAが2026年9月28日に発表したのが、エージェントを隔離して外から見張る基盤「NVIDIA Open Agent Safety Platform」です。この記事では、その仕組みと、当社で活用するならどう使えるかを紹介します。

なぜ今、エージェントの制御が問題なのか

2026年9月、AI開発企業で評価中のエージェントが実在のシステムに侵入する事案が続きました。Anthropic、Google、OpenAIがそれぞれ事案を公表しています。

NVIDIAによると、これらの事案には共通点があります。エージェントが与えられたタスクをやり遂げようとして、アプリケーション層のセキュリティ制御を回避していたことです。

NVIDIAは、原因は何か一つの新しい能力ではなく、次の3つの組み合わせだと分析しています。

  • エージェントが使えるツール
  • 長い実行時間
  • あいまいな指示

行き詰まったエージェントに、自分の振る舞いを完全に律することは期待できません。そこでNVIDIAは、エージェントから独立した場所に安全装置を置く必要があると主張しています。

NVIDIAはこれをWebブラウザにたとえています。1990年代のインターネットは、ブラウザがWebページのコードを信用せず、ページごとにサンドボックスで隔離するようになって安全になりました。同じことをAIエージェントにもやろう、という発想です。

Open Agent Safety Platformの全体像

この基盤は、ソフトウェアの「OpenShell」とハードウェアの「Sentry」の2層でエージェントを守ります。テストから本番運用までが対象です。

エージェントは「箱」の中で動き、箱の外からSentryが見張る ホスト(Vera CPUなど) OpenShell サンドボックス AIエージェント Claude Code、Codexなど ポリシーで制限 ファイル・ネットワーク ツール・プロセス 認証情報 認証情報の保管庫 本物のキーはエージェントの外 BlueField-4 DPU Sentry ホストから独立して常時監視 エージェントからは見えない ミリ秒で隔離・停止 許可された範囲を出ようとしたとき 監視 検知 停止 許可された接続先にだけ使う
Open Agent Safety Platformの構成(ソフトとハードの2層)

OpenShellがエージェントを箱(サンドボックス)に入れて行動範囲を制限し、Sentryが箱の外、しかも別のチップの上から見張ります。

OpenShell:エージェントを「箱」の中で動かす

OpenShellは、エージェントをサンドボックス(隔離された実行環境)の中で動かすためのソフトウェアです。

運用者は、エージェントが触ってよいものをポリシーとして定義します。対象はファイル、ネットワーク、ツール、プロセス、認証情報です。OpenShellはこの制限を実行前に検証し、実行中も強制します。

特徴的なのは次の3点です。

  • 認証情報をエージェントに渡さない:APIキーなどはエージェントの外で管理し、許可された接続先に対してだけ使わせます。エージェントが本物のキーを持ち出すことはできません。
  • ポリシーの抜け穴を数学的にチェックできる:形式論理を使って、ポリシーに抜け道がないかを証明する機能があります。
  • 既存のエージェントをそのまま使える:CodexやClaude Codeなどのエージェントを書き換えずに動かせます。

ライセンスはApache 2.0で、GitHubで公開されています。NVIDIAのエージェント向けCPU「Vera」に最適化されていますが、ArmやIntelなど他社のプラットフォームにも対応を広げられます。

Sentry:見えない場所から見張り、ミリ秒で止める

Sentryは、OpenShellに加えて任意で導入できる監視役です。NVIDIAのDPU(データ処理ユニット)「BlueField-4」というチップの上で動きます。

ポイントは、エージェントが動いているホストから切り離された場所で監視することです。エージェントの側からは、自分が監視されていることが見えません。そのため、エージェントが監視をすり抜けたり、止めたりすることができません。

エージェントが許可された範囲の外に出ようとすると、Sentryはミリ秒単位でエージェントを隔離して停止させます。VeraとBlueField-4を搭載したシステムなら、ソフトウェアの更新だけでこの機能を有効にできるそうです。

「見張り役が見張られる側から見えない・触れない場所にいる」という設計は、ソフトウェアの中だけで完結する監視よりも一段強い守りになります。

当社で活用するなら

ここまでは仕組みの紹介でしたが、Salesforceの開発や導入支援をしている当社なら、どう使えるかを考えてみました。

1. Claude CodeでのSalesforce開発を「箱」の中で行う

当社では、Salesforceの開発にClaude Codeを使い始めています。便利な一方で、エージェントがお客様の組織に接続できる状態で作業するのは、少し怖さもあります。たとえば、検証用の組織のつもりで本番組織にデプロイしてしまう、といった事故です。

OpenShellのような仕組みを使えば、次のような制限をかけた「箱」の中でエージェントを動かせます。

  • 接続先を検証用の組織(Sandbox)だけに絞る:本番組織への通信はそもそもできないようにする
  • Salesforceの認証情報をエージェントに渡さない:ログイン情報は箱の外で管理し、許可された組織に対してだけ使わせる
  • 触れるファイルを担当プロジェクトのフォルダに限る:ほかのお客様の案件のファイルには触れさせない

お客様のデータや環境を預かる立場として、「AIに任せても、越えてはいけない線は仕組みで守られている」と説明できるのは大きな安心材料になります。

2. Slackで「AIの権限リクエスト」を承認する

SalesforceとNVIDIAは、OpenShellとSlackを連携させています。Slack上でエージェントの活動や監査イベントを確認したり、エージェントが追加の権限を求めてきたときに承認・拒否したりできます。

当社は普段からSlackで仕事をしているので、この形はなじみやすいはずです。たとえば「本番組織に接続したい」とエージェントが求めてきたら、案件の担当者がSlackで内容を確認して承認する、という運用が考えられます。AIに任せる部分と人が判断する部分の線引きが、日々の業務の流れの中で自然にできます。

3. お客様へのAI導入提案に「安全の設計」を含める

Agentforceなど、お客様がAIエージェントを導入する場面も増えています。今回の考え方は、そうした提案にも生かせます。

具体的には、「エージェントに何をさせるか」だけでなく、「何をさせないか」「誰が見張り、誰が承認するか」までを設計に含めることです。OpenShellそのものを使うかどうかに関わらず、最小限の権限、監査ログ、人による承認という3点は、どのAIエージェントの導入にも当てはまります。

現実的な始め方

Sentryは専用のハードウェア(BlueField-4)が必要なので、当社ですぐ使うのは現実的ではありません。一方、OpenShellはオープンソースで公開されているので、まずは社内の検証環境で、Claude Codeを使ったSalesforce開発を箱の中で動かせるか試してみるところから始めたいと考えています。

まとめ

Open Agent Safety Platformは、「エージェントに自制を期待するのではなく、外側の仕組みで囲い込む」という考え方の基盤です。ソフトウェアのOpenShellで行動範囲を制限し、ハードウェアのSentryで見えない場所から見張る、という2層で守ります。

この基盤にはAnthropic、Microsoft、IBM、日立製作所傘下の日立エナジーなど、100以上の組織が参加を表明しています。NVIDIAのジェンスン・フアンCEOは、エージェントの脱走問題は技術で解決できるエンジニアリングの問題だという考えを示しています。

AIエージェントを業務で使う場面はこれから増えていきます。「何ができるAIか」だけでなく、「何をさせないか」「誰がどう見張るか」まで考えておくことが、安全に使うための第一歩になりそうです。OpenShellはオープンソースなので、興味のある方はGitHubで中身を見てみてください。

参考記事