Claude Managed Agents が NVIDIA OpenShell と統合。エージェントの実行権限を「既定で全部拒否」から組み立てる

要約

Anthropic が2026年9月28日、NVIDIA との連携を発表しました。Claude Managed Agents を、NVIDIA の Open Agent Safety Platform（中核が OpenShell）と統合するという内容です。NVIDIA 側は同日、OpenShell を Apache 2.0 のオープンソースとして公開しています。

OpenShell は、エージェントの実行とアクセスを制御するランタイムです。 方式は既定拒否——公式の表現は「ルールで許可されない限り、すべてを拒否する」。ツールの利用を毎回検査し、ファイルアクセス、ネットワーク接続、データの取り扱いにポリシーを適用します。ログを監査できるほか、エージェントが到達可能な範囲を数学的に検証（証明）できるとされています。

この「数学的に検証」という部分が、この発表のいちばん硬い主張です。 「たぶん大丈夫」でも「テストで確認した」でもなく、到達可能な範囲を形式的に示すというアプローチです。監査部門や規制対応の文脈では、この違いが効きます。

Anthropic 側の設計は、層の分離です。 Managed Agents はエージェントループを、作業が実際に実行されるサンドボックスとは別のサーバーで走らせます。 そして資格情報は別の vault に置き、エージェントからは見えません。 公式の説明は「保護が単一の層に依存しないようにする」。エージェント本体が侵害されても、実行環境と資格情報は別の境界の向こうにあるという構造です。ここに OpenShell が加わることで、サンドボックス経由のアクセス統制をさらに厳格に強制できる、という話になります。

提供状況です。 Managed Agents は顧客管理のサンドボックス、またはマネージドなプロバイダー環境で現在利用可能。OpenShell は GitHub と NVIDIA の開発者向けリソースから即日オープンソースで入手可能です。

想定対象は明確に企業です。 事業部門を横断してエージェントを展開する組織、機微な独自データを扱う組織、アクセス制御と監査可能性が要求される環境。利用企業として Notion、楽天、Asana が挙げられています。

背景として、直近のセキュリティ事案が言及されています。 「長時間動くエージェントに対して、オープンでカスタマイズ可能な統制手段を組織へ渡す必要がある」という文脈です。Anthropic の chief commercial officer である Paul Smith は、**「企業は AI エージェントに最も重要な仕事を任せつつあり、特に機微な環境では、エージェントが何をしたのかを指示し検証する必要がある」**と述べています。

なお報道ベースでは、NVIDIA のこのプラットフォームに100社以上が参画した一方、OpenAI は参加していないとされます。 この点は公式発表本文では確認できていないため、参考情報として扱ってください。

何が変わったか

• Claude Managed Agents と NVIDIA Open Agent Safety Platform（OpenShell）の統合を発表
• OpenShell は既定拒否型のランタイム。「ルールで許可されない限りすべてを拒否」
• ツール利用を毎回検査し、ファイルアクセス・ネットワーク接続・データ取り扱いにポリシー適用
• ログの監査に加え、エージェントの到達可能範囲を数学的に検証できるとされる
• Anthropic 側の層分離: エージェントループと作業実行サンドボックスを別サーバーに分離
• 資格情報は別の vault に格納され、エージェントからは見えない
• OpenShell は Apache 2.0 で即日オープンソース公開（GitHub / NVIDIA 開発者リソース）
• Managed Agents は顧客管理サンドボックス、またはマネージド環境で現在利用可能
• 利用企業として Notion、楽天、Asana を明示
• 報道ベースで「100社以上が参画、OpenAI は不参加」（公式本文では未確認）

業務インパクト（一般企業向け）

この発表の本質は、エージェントの統制をどの層でやるかという設計判断です。 現状、多くの組織はエージェントの振る舞いをプロンプトで制御しています。「本番データベースに書き込まないでください」「この範囲のファイルだけ読んでください」。これは指示であって、強制ではありません。

OpenShell が提案しているのは、ランタイム側での強制です。 ルールで許可されていない操作は、エージェントが何を考えていようと実行されません。プロンプトインジェクションでエージェントが騙されても、ランタイムのポリシーは騙されません。 この違いは、エージェントを機微な環境に入れる際の前提を変えます。

監査可能性が要件になっている業種では、導入判断そのものが変わる可能性があります。 金融、医療、公共。「エージェントがアクセスできた範囲を証明できるか」が稟議の論点になっている組織にとって、「数学的に検証できる」という主張は、従来の「ログを取っています」より強い回答です。ただしこの主張の中身（どの範囲を、どの手法で証明するのか）は、発表本文では詳細まで示されていません。 採用を検討するなら、ここは実装を見て確かめる必要があります。

Apache 2.0 でオープンソースという点は、実務的に大きい判断材料です。 ベンダーロックインを避けたい組織、自社のポリシー体系に合わせて改変したい組織が、外部サービスに依存せず自前で動かせます。 また、セキュリティ製品としてブラックボックスでないことは、検証する側にとって意味があります。

層分離の設計は、自社でエージェント基盤を組む場合の参考にもなります。 エージェントループと実行サンドボックスを分ける、資格情報は vault に置いてエージェントに見せない。これは Managed Agents を使わなくても採れる設計です。 自前で組んでいる組織は、現状の構成がこの2点を満たしているかを点検する価値があります。 多くの内製エージェントは、同じプロセス内で資格情報を持っています。

一方で、過大評価も避けてください。 これはエージェントを安全にする製品ではなく、エージェントができることを絞る仕組みです。何を許可するかは、結局こちらが決めます。ポリシーを緩く書けば、既定拒否型でも広く通ります。 「導入したから安全」にはなりません。

副業・個人活用視点

個人や小規模事業者が直接 Managed Agents を導入する場面は、正直に言って多くありません。 企業向けの層で、想定されているのは事業部門横断の展開です。ただし、この発表から取れるものが2つあります。

1つは、OpenShell が Apache 2.0 で誰でも使えることです。 自分でエージェントを作って動かしている人——自動化スクリプトをエージェントに任せている、受託でエージェントを組んでいる——にとって、既定拒否型のランタイムがタダで手に入るというのは実用的な話です。「うっかり本番を触る」「想定外のネットワークへ出る」を、コードのレビューではなくランタイムで止められます。 個人開発ではレビューする人がいないので、機械的に止まる仕組みの価値は相対的に高くなります。

もう1つは、提案材料としての価値です。 受託でエージェント案件をやっていると、「AI に業務を任せて大丈夫か」という問いが必ず出ます。 ここで「プロンプトで指示しています」と答えるのと、「ランタイムで許可した操作しか実行できない構成にしています」と答えるのでは、通り方が違います。 そして Anthropic と NVIDIA が同じ方向を向いた、という事実そのものが、この設計が業界の標準的な作法になりつつあることの傍証として使えます。

設計の考え方だけでも持ち帰る価値があります。 エージェントループと実行環境を分ける。資格情報をエージェントに見せない。この2点は、OpenShell を使わなくても、個人の小さな自動化にも適用できます。 API キーを環境変数でエージェントのプロセスに渡していませんか、という話です。それはエージェントから「見えている」状態です。

なお、Notion・楽天・Asana という利用企業名が出ている点は、提案時に使える情報です。 特に楽天が入っているのは、国内企業への説明で具体性を持たせやすい材料になります。