- エージェントごとにファイル・システムコール・通信をポリシーで制限
- 資格情報は実物を渡さず、承認済みエンドポイント宛てにだけ付与
- ポリシー変更は形式検証でリスクを検査し、人間のレビュー待ちに
公開されたもの
NVIDIAのリポジトリで公開されているOpenShellは、複数の自律型AIエージェントをまとめて運用するための実行基盤(ランタイム)です。ライセンスはApache License 2.0で、0.1.x系では安定したリリース周期、新しい分離機能(isolation primitives)、拡張ポイントの追加、新しいAPIが打ち出されています。0.1.0へのアップグレードガイドも用意されています。
READMEでは、エージェントはファイルを読み、パッケージを導入し、APIを呼び、資格情報を使えるときに最も役立つと説明されています。一方でそれは、データ・シークレット・ネットワークへの無制限アクセスと隣り合わせでもあります。OpenShellは、エージェントごとに「何に触れてよいか」をポリシーとして宣言させ、それを強制する立場を取ります。
カーネルレベルで権限を絞る
各エージェントはサンドボックス内で動作し、カーネルの制御によってアクセスできるファイルと発行できるシステムコールが制限されます。ネットワーク接続は、サンドボックスを出る前に必ずポリシーチェックを通ります。つまり権限の判断は、エージェントのプログラム側の作法に頼らず、実行環境の側で行う設計です。
資格情報については、エージェントに実物を渡さず、承認済みエンドポイント宛てのリクエストにだけOpenShellが付与します。サンドボックス内に実物の資格情報を置かない構成と読めます。エージェントが誤動作した場合でも、盗める資格情報がそこに存在しない形になります。
ポリシー変更を形式検証で確認
ポリシーを変更して新しい権限を与える前に、OpenShellは形式検証(formal verification)を使って「その変更で何が許可されるようになるか」を検査します。新しいホストへ資格情報付きで到達できるようになる、新しいAPIメソッドを呼べるようになる、といったリスクの高い追加を検出し、該当する変更は人間のレビュー待ちになります。
設定ミスや意図しない権限拡大を、適用後の事故ではなく適用前のレビューで止める発想です。ポリシー管理には、変更を確認するためのadvisor(助言役)とprover(証明器)が用意されていると説明されています。
動かすための前提
対応環境はLinux、Apple Silicon上のmacOS、WSL 2上のWindows(実験的)で、Docker、Podman、またはホスト仮想化のいずれかが必要です。インストーラはCLIとローカルゲートウェイをセットアップします。既定のサンドボックスイメージはエージェントを含まない最小構成のUbuntuです。
実際のエージェントを動かすチュートリアルでは、無料のOpenRouterモデルに対してOpenCodeを走らせ、エージェントが必要とした権限を承認する流れが示されています。ゲートウェイはHelmでKubernetesに配備できますが、CNIがNetworkPolicyを強制できることが条件として明記されています。
注意点と未公表の部分
テレメトリは運用カテゴリと件数に限定した匿名収集で、サンドボックス名、ホスト名、ファイルパス、プロンプト、資格情報、プロバイダ名やモデル名、ユーザーコンテンツは収集しないとされています。ゲートウェイの設定またはHelmの設定で無効化でき、コンパイル時に完全に除外することも可能です。
READMEには性能値やオーバーヘッドの記載はなく、形式検証が扱えるポリシーの規模や適用時間も示されていません。また、外部から取得した素材の利用条件や安全性は利用者の責任で確認するよう求める免責事項が置かれています。Windows対応は実験的とされており、実運用での成熟度は現時点では判断できません。
| 観点 | カーネルレベル強制 | 形式検証 |
|---|---|---|
| 目的 | 実行時のファイル・システムコール・通信を制限 | ポリシー変更で増える権限を適用前に検査 |
| タイミング | エージェント実行中に常時 | ポリシー変更の承認前 |
| 対象 | ファイルアクセス、システムコール、ネットワーク接続 | 新たに許可されるホストやAPIメソッドなど |
| 関与 | 機械的に強制 | リスクを検出し人間のレビューへ |
OpenShell gives them that capability without giving them unrestricted access to your data, secrets, or network.
OpenShellは、データ・シークレット・ネットワークへの無制限のアクセスを与えることなく、エージェントにその能力を付与します。
今後の見通し
0.1.x系で安定したリリース周期が打ち出されたばかりで、今後は分離機能や拡張ポイント、APIの拡充が進むとみられます。判断材料になるのは、形式検証がどの程度のポリシー記述を扱えるのか、実際のエージェント運用で誤検知やレビュー負荷がどの程度出るのかという点です。対応環境ではWSL 2上のWindowsが実験的とされており、正式対応に移るかも注目されます。KubernetesではCNIがNetworkPolicyを強制できることが前提となるため、自社クラスタの構成を確認したうえで検証を始めるのが現実的です。
日本の開発者・IT企業にとっての意味
日本のIT企業がエージェントを社内業務に広げる際の壁は、「どこまで触らせるか」の統制です。OpenShellは、ファイル・システムコール・通信をポリシーで宣言させ、実行時に強制する枠組みをOSSとして提供します。自前でサンドボックスやプロキシを組み、資格情報の受け渡しを設計する作業を置き換えられる可能性があります。ポリシー変更を適用前に検証し、人間のレビューに回す仕組みは、変更管理や監査を重視する日本の企業文化と相性が良いと考えられます。一方、Kubernetesで使う場合はCNIがNetworkPolicyを強制できることが前提で、既存クラスタのネットワーク設計を確認する作業が発生します。まずは読み取り中心の狭いポリシーから試し、権限拡大の手順をレビューとセットで運用できるかを見極めるのが現実的です。
気になる点
- 日本企業のオンプレミスやクラウドで使えますか
- 対応環境はLinux、Apple Silicon上のmacOS、WSL 2上のWindows(実験的)で、Docker、Podman、またはホスト仮想化が必要です。KubernetesではゲートウェイをHelmで配備できますが、CNIがNetworkPolicyを強制できることが条件です。ライセンスはApache License 2.0で、原文に地域制限の記載はありません。
- 既存のエージェント実装をそのまま移せますか
- 既定のサンドボックスイメージはエージェントを含まない最小構成のUbuntuなので、利用するエージェントは自分で用意します。チュートリアルではOpenCodeを無料のOpenRouterモデルで動かす例が示されています。任意のフレームワークからの移行手順は原文になく、現時点では公表されていません。
- 利用に費用はかかりますか
- ソフトウェアのライセンスはApache License 2.0で、原文に有償版や価格の記載はありません。ただし推論に外部プロバイダを使う場合の利用料は別途発生するとみられます。商用サポートの有無は現時点では公表されていません。
用語解説
- サンドボックス
- プログラムを隔離された環境で実行し、ファイルやネットワークなど外部への影響を制限する仕組み。
- 形式検証
- 数学的な手法で、システムや設定が意図した性質を満たすかを網羅的に検査する方法。
- システムコール
- アプリケーションがOSのカーネルに対してファイル操作や通信などを依頼するための入口。
- CNI
- KubernetesのPodにネットワークを構成するための標準的なプラグイン仕様。NetworkPolicyの強制力は実装依存。
- Helm
- Kubernetes向けのパッケージ管理ツール。アプリケーションの配備設定をまとめて管理・適用できる。
- ゲートウェイ
- 本記事ではサンドボックス、ポリシー、アクセスを制御するOpenShellのコントロールプレーンを指す。
出典
OpenShell – A safe, private runtime for fleets of autonomous AI agents
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する