自律AIエージェントの実行基盤にOpenShellが選ばれる理由

コーディングエージェントは、ファイルを読み書きし、パッケージをインストールし、外部 API を呼び出せるようになって初めて実用的になります。しかし能力を広げるほど「どこまで触らせていいのか」の線引きが曖昧になり、気づけばエージェントがリポジトリ全体と手元の認証情報に素通しでアクセスできる状態になりがちです。

厄介なのは、コンテナに閉じ込めるだけではこの問題が解けない点です。コンテナはプロセスを隔離しますが、コンテナ内に置いた API キーの持ち出しや、許可していない宛先への通信を止める仕組みは標準では提供されません。逆に権限を絞り込みすぎると、依存パッケージの取得すら失敗してエージェントが仕事をしなくなります。「安全側に倒すと使えない、使える側に倒すと説明できない」という板挟みは、エージェント運用を任された担当者がほぼ必ず通る場所です。

NVIDIA が公開した OpenShell は、この板挟みに対して「触ってよい範囲を YAML で宣言し、カーネルレベルで強制する」というアプローチを採ります。公式ドキュメントは OpenShell を自律 AI エージェントのフリートのための安全かつプライベートなランタイムと位置づけており、ファイルシステム・ネットワーク・プロセス権限の制限に加えて、エージェントに実際のクレデンシャルを渡さずに通信を成立させる仲介層と、ポリシー変更を形式検証で審査する仕組みを備えています。

本記事では、OpenShell の設計とポリシーモデル、類似 OSS との差分、そして導入前に確認すべき前提条件を、公式ドキュメントと GitHub API から取得したリポジトリ情報に基づいて整理します。

なお本記事は 2026 年 10 月 10 日時点の公開ドキュメントおよび GitHub API 取得値のみを根拠としたドキュメント調査です。インストールや環境構築、実行による検証は行っていないため、動作に関する断定は避け、公式ドキュメントが明記している範囲に記述を限定しています。

OpenShellとは｜NVIDIAが公開した自律AIエージェント向けランタイム

OpenShell は、公式の説明によれば「自律 AI エージェントのための安全かつプライベートなランタイム」です。エージェントがファイルの読み込み・パッケージのインストール・API 呼び出し・クレデンシャルの利用を行えるようにしつつ、データ・シークレット・ネットワークへの無制限なアクセスは与えない、という設計方針が OpenShell の README に明記されています。

実現手段は 2 つの柱に整理されています。1 つはカーネルレベルの強制で、各エージェントを隔離サンドボックス内で動かし、アクセスできるファイルと発行できるシステムコールを制限し、すべてのネットワーク接続がサンドボックスを出る前にポリシーチェックを通過する構造を取ります。もう 1 つは形式検証されたポリシー変更で、ポリシーを緩める変更を承認する前にリスクの高い新規アクセスを検出し、該当する変更を人間のレビュー待ちにします。

リポジトリ基本情報

以下は 2026 年 10 月 10 日に GitHub API（gh api /repos/NVIDIA/OpenShell）で取得した値です。

メンテナンス状況の判断材料としては、取得時点でアーカイブされておらず当日中に push が入っていること、ライセンスが Apache-2.0 として明示されていること、README が 0.1.x 系で安定リリースケイデンス・新しい隔離プリミティブ・拡張サーフェスの拡大・新しい API が追加されたと述べていることが挙げられます。公式ドキュメントの Overview が参照する最新版は v0.1.3 です。バージョン番号のとおり 0.1 系であり、公式ドキュメントも production-ready であるとは明示していないため、評価の際はこの成熟度を前提にする必要があります。

想定されている利用シーン

Overview ページは、自律エージェントを運用しつつそのアクセスを制限する必要があるチームを想定読者として挙げ、具体的なシーンとして次の 3 つを示しています。

• セキュアなコーディングエージェントの実行環境
• セルフホストやプライベートなモデルエンドポイントを使う、企業内のプライベートな開発環境
• ポリシー YAML をセキュリティコントロールとしてバージョン管理したいコンプライアンス・監査チーム

対応するエージェントとしては Claude Code・OpenCode・Codex・GitHub Copilot CLI が挙げられています。ただし、デフォルトのサンドボックスイメージはエージェントが未インストールの最小 Ubuntu であり、エージェントを動かす手順は別途ドキュメントの「Run Your First Agent」で案内される構成になっています。

自律AIエージェントの実行基盤に必要な制御の3層

OpenShell の中身に入る前に、評価軸そのものを先に用意しておくと比較が楽になります。エージェントの実行基盤に求められる制御は、おおまかに次の 3 層に分かれます。

1. ファイルシステム: どのパスを読めるか、どのパスに書けるか
2. ネットワーク: どの宛先に出られるか、どのメソッドやパスを呼べるか
3. プロセス権限: どのユーザーで動くか、どのシステムコールを発行できるか

この 3 層はコンテナやサンドボックス系のツールであれば何らかの形で扱っています。一方、エージェント特有の論点として次の 2 つが加わります。

4. クレデンシャル: API キーなどの秘密情報をエージェント本体に見せるのか、見せずに通信を成立させるのか
5. ポリシー変更の審査: 権限を緩める変更を誰がどう承認するのか、承認の判断材料は何か

エージェントは実行中に「この宛先に出たい」「このパスを読みたい」という要求を次々に発生させます。そのたびに人間が勘で許可を出すのであれば、最初から広く開けているのと大差ありません。そのため 4 と 5 を評価軸に含めるかどうかで、ツールの見え方が大きく変わります。

以降では、この 5 つの軸に沿って OpenShell の設計を見ていきます。同じ軸は類似 OSS との比較にもそのまま使うので、記事を読み終えたあとに他の候補を自力で評価する際にも流用できます。

OpenShellのアーキテクチャ｜ゲートウェイ・スーパーバイザー・サンドボックスの分離

OpenShell の設計上の特徴は、ポリシーを判断する場所とエージェントが動く場所を明確に分けている点です。公式ドキュメントのアーキテクチャ解説では、4 つのコンポーネントと 1 つのネットワークフェンスで構成されると説明されています。

4つのコンポーネントと信頼境界

ここで重要なのは、サンドボックスがポリシー判断を持たないという点です。サンドボックス側は信頼できる /proc の情報から呼び出し元の実行ファイルを識別し、seccomp の user notification を使って TCP の接続開始と DNS クエリをインターセプトしますが、許可するかどうかは判断しません。Linux では非 root ユーザーかつ capability なしで動作し、ファイルシステムアクセスは Landlock で制限されます。

Compute driver が対応するランタイムは Docker・Podman・Kubernetes・MicroVM の 4 種類です。自社のインフラにどう載せるかを検討する際は、この 4 択のどれを選ぶかが出発点になります。

エージェントの通信が外に出るまで

エージェントが外部と通信する際の流れは、公式ドキュメントで次のように説明されています。

1. エージェントが TCP 接続または DNS ルックアップを行う
2. サンドボックスが呼び出し元のプログラムを識別する
3. リクエストが Sandbox Protocol を越えてスーパーバイザーに渡る
4. スーパーバイザーがポリシーを評価し、許可されたクレデンシャルを付加する
5. 許可されればスーパーバイザーが接続を開き、トラフィックを中継する

この流れにより「どのバイナリがどこへ出られるか」をプロセス単位で制御できます。また 4 のステップでクレデンシャルが付加されるため、エージェント本体は実際の秘密情報を保持しません。エージェントが扱うのは不透明なプレースホルダであり、プロファイルで認可されたエンドポイントに対してのみ解決される設計です。

スーパーバイザーとサンドボックスの通信は、相互認証された単一の HTTP/2 接続を共有し、独立したストリームを持ちます。これにより重いデータ転送が DNS や制御トラフィックをブロックしません。トランスポートはランタイムに依存し、Docker と Podman では Unix socket、Kubernetes では TCP、MicroVM では vsock が使われます。

認証面では、ゲートウェイが唯一のクレデンシャル署名者となり、各クレデンシャルは 1 つのサンドボックスと 1 回の実行（generation）に紐づきます。サンドボックスはゲートウェイの公開鍵のみを保持するため、検証はできても生成はできません。

要件を満たさないときは起動しないという一貫性

OpenShell は fail-closed を徹底しています。スーパーバイザーが境界を確認するまでエージェントは起動できず、スーパーバイザーが切断するとサンドボックスはエージェントをフリーズさせます。再接続して再開できるのは同一のスーパーバイザープロセスのみで、有効なクレデンシャルを持っていても新しいスーパーバイザーが稼働中のサンドボックスを引き継ぐことはできません。

運用の観点では、この性質は「隔離が効いていないまま気づかずに動き続ける」事故が起きにくいことを意味します。一方で、スーパーバイザーの可用性がエージェントの可用性に直結するため、長時間ジョブを走らせる構成では障害時の挙動を事前に理解しておく必要があります。

YAMLポリシーで権限を宣言するOpenShellの仕組み

OpenShell のポリシーは YAML 設定として記述します。ポリシーの概要ページによると、version: 1 を設定し、ほかに最大 5 つのトップレベルセクションを持つ構成です。

5つのセクションと適用タイミング

運用設計で効いてくるのは、この適用タイミングの非対称性です。ファイルシステム・Landlock・プロセスの設定はサンドボックスの起動後は固定され、変更するには作り直しが必要です。対してネットワークルールとミドルウェアは稼働中に変更でき、ホットリロードされます。つまり「作業中にリポジトリ外のディレクトリを読みたくなった」場合はサンドボックスの再作成が必要で、「作業中に新しい API に出たくなった」場合は実行中に対応できます。開発体験を設計するうえで、この違いは早めに把握しておく価値があります。

なお、具体的なフィールド名やルールの書式は Policy Schema Reference 側に定義されています。本記事では公式ドキュメントが概要ページで示している範囲にとどめ、実際のポリシー記述は公式のスキーマ定義を参照することをおすすめします。

ネットワークはデフォルト全拒否・バイナリ単位で許可する

典型的なポリシーの大半はネットワークルールが占めます。OpenShell は network_policies のルールで明示的に許可されない限り、すべての outbound 接続を拒否します。各ルールは許可する宛先と、そこへ到達してよいバイナリをペアで指定し、さらにそのバイナリが送信できるリクエストも制限できます。公式ドキュメントは例として、ある API に対して読み取りは許可するが書き込みは許可しないという制限を挙げています。

「宛先 × バイナリ」をペアで扱うため、たとえばパッケージマネージャにはレジストリへの到達を許可しつつ、エージェント本体には同じ宛先を許可しない、という書き分けが可能になります。HTTP のメソッドやパス単位で許可を絞る仕組みは他のサンドボックス系ツールにもありますが、制御軸に「どのバイナリからのリクエストか」が入る点が OpenShell のネットワークポリシーの性格を決めています。

ポリシーの優先順位とプロバイダによる上乗せ

ポリシーは複数の出どころを持ち、先に該当したものが有効になります。

1. ゲートウェイ管理者が設定したグローバルポリシー
2. サンドボックスの保存済みポリシー（作成時の --policy が環境変数 OPENSHELL_SANDBOX_POLICY を上書き）
3. サンドボックスイメージに含まれるポリシー
4. OpenShell の制限的なデフォルトポリシー

イメージ内のポリシーが不正な場合、デフォルトにフォールバックするのではなくワークロードの起動自体がブロックされます。ここでも fail-closed が一貫しています。

また、アタッチされたプロバイダはベースポリシーの上にネットワークルールを追加でき、その合成結果がサンドボックスで強制される実効ポリシーになります。グローバルポリシーが有効な間は、これらのプロバイダルールが抑止され、サンドボックスのポリシー変更と提案の承認もブロックされます。組織として権限を締める手段が用意されている一方、グローバルポリシーを入れると後述のポリシー提案フローが使えなくなる点は運用上のトレードオフです。

インストール手順の入口

README は、CLI とローカルゲートウェイをセットアップするインストーラと、最初のサンドボックス作成コマンドを次のように示しています。

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

出典: https://github.com/NVIDIA/OpenShell

また、OpenShell の操作方法・サンドボックスポリシーの記述・ゲートウェイと推論ルーティングのデバッグをコーディングエージェント自身に教えるためのスキル配布も用意されています。

npx skills add NVIDIA/OpenShell

出典: https://github.com/NVIDIA/OpenShell

アプリケーションからゲートウェイに接続する場合は Python・TypeScript・Go・Rust の SDK が提供されています。SDK は CLI をインストールしないため、SDK とゲートウェイは可能な限り同一リリースを揃えることが README で推奨されています。

形式検証によるポリシー審査がOpenShell固有の価値

ポリシーを YAML で書けること自体は、他のツールでも設定ファイルという形で実現されています。クレデンシャルをサンドボックスの外に置く仲介層も、後述の比較で見るとおり OpenShell だけの機能ではありません。比較した 4 リポジトリの README と公式ドキュメントで同種の記載が見つからなかったのは、ポリシーの変更を SMT ソルバーで審査する層です。

boundary checkとproposal risk checkの違い

ポリシープローバーのドキュメントでは、性質の異なる 2 つのチェックが説明されています。

Boundary check がカバーする範囲は、ファイルシステムアクセス・プロセス識別・Landlock 設定・ネットワーク接続・REST リクエストです。「このポリシーは自分が引いた境界を越えていないか」を機械的に確認する用途であり、人力のレビューでは見落としやすい組み合わせを拾えます。

Proposal risk check は、Policy Advisor のフローに組み込まれています。Advisor はサンドボックス内のエージェントが拒否されたリクエストに対してネットワークルールを提案できる仕組みで、デフォルトでは無効、対象はネットワークアクセスのみです。提案はルールの追加しかできず、削除やファイルシステム・Landlock・プロセス設定の変更はできません。

提案が出されると OpenShell が検証とリスクチェックを行い、保留中の提案として積みます。既定では人間が一覧を見て承認または却下し、却下時には理由をエージェントに返せます。自動承認を有効にした場合は、リスクチェックで何も検出されず、かつ宛先がフラグ対象でないときに限って承認されます。フラグ対象にはプライベート IP アドレス、ワイルドカードホスト、リスクのある allowed_ips の指定、49152 番より大きいポート、5432 や 6379 といったデータベース・キャッシュのポートが含まれます。

リスクチェックが報告するのは、リンクローカルやメタデータアドレスへの到達、プロバイダクレデンシャルを持つホストへの検査不能なトラフィック、新しいホストでのクレデンシャル利用、クレデンシャルが既に使われている宛先に対する新しい HTTP メソッド、の 4 種類です。いずれかが検出された提案は必ず人間のレビューに回ります。

形式検証が保証しないこと

ここで、過度な期待を避けるために公式ドキュメントが明記している限定事項を押さえておく必要があります。

• 保証はプローバーがモデル化しているポリシー機能に限られます。OpenShell は現在もモデルを拡張中であり、GraphQL や MCP のルールなど未モデル化の機能を使うポリシーは unsupported が返ります。
• boundary check を通過したことは、「ポリシーが可能な限り狭い」「特定のタスクに対して安全」「稼働中のサンドボックスで強制されている」のいずれも意味しません。
• 2 つのチェックは異なる問いに答えるため、一方の通過が他方の通過を意味することはありません。

Advisor 側にも限定事項があります。エージェントは protocol: tcp や tls: skip、GraphQL / MCP のツールルール、クエリマッチャー、クレデンシャル設定などを提案できず、これらは管理者が自分で追記する必要があります。自動承認モードは、プロバイダクレデンシャルが関与しない新しい公開ホストへのアクセスをリスクとみなさないため、レビューなしで許可が広がる余地があります。ループバック・リンクローカル・クラウドメタデータのアドレスは常にブロックされ、承認もできません。

つまり形式検証は「人間のレビューを置き換えるもの」ではなく、「レビューすべき対象を絞り込み、危険な変更を取りこぼさないための仕組み」として位置づけられています。ポリシー変更を誰がどう承認するかという運用設計は、依然として自分たちで決める必要があります。

類似OSSとの比較｜OpenSandbox・E2B・CubeSandbox・sandbox-runtime

AI エージェント向けのサンドボックス・実行環境は 2026 年時点で選択肢が増えています。以下は 2026 年 10 月 10 日に GitHub API で取得した基本情報です。

先に挙げた 5 つの評価軸で整理すると、差分は次のようになります。各セルは 5 リポジトリそれぞれの README と公式ドキュメントで確認した内容に基づいており、確認できなかった項目は「未確認」と明記しています。

上表の出典は、言語・スター数・ライセンス識別子が GitHub API（2026 年 10 月 10 日取得）、それ以外のセルが各リポジトリの README および公式ドキュメントです。具体的には OpenSandbox の README・Credential Vault ガイド・egress の解説、E2B の README、CubeSandbox の README・セキュリティプロキシガイド、sandbox-runtime の README を参照しています。

一方で、起動時間や同時実行数といった性能数値の横並び比較は行っていません。計測条件が各プロジェクトで異なり、同一条件の比較として扱える一次情報が揃わないためです。

一次情報で確認した範囲で「OpenShell 固有」と言えるのは、次の 3 点です。

1. YAML による宣言的ポリシーの 5 セクション構成と、適用タイミングの非対称性（ファイルシステムは起動時に固定、ネットワークは実行中に変更可能）
2. SMT ソルバーによるポリシー変更の審査（boundary check / proposal risk check）。比較した 4 リポジトリの README・公式ドキュメントでは同種の機能を確認できませんでした
3. generation 単位のクレデンシャル署名と、境界が確立するまでエージェントを起動しない fail-closed の信頼境界

逆に、OpenShell の独自性として語られやすい「エージェントに実クレデンシャルを渡さない仲介」は、固有の機能ではありません。OpenSandbox は Credential Vault を、CubeSandbox は Credential Vault と L7 プロキシによる自動注入を公式ドキュメントで明示しており、いずれも「キーをサンドボックスの中に入れない」という同じ方向を向いています。OpenShell の差分は機能の有無ではなく実装の粒度で、呼び出し元のバイナリをプロセス単位で識別してからスーパーバイザーが注入し、クレデンシャルを 1 サンドボックス × 1 generation に紐づけて署名する点にあります。候補を絞る際は「クレデンシャルを隠せるか」では差が出ず、「どの粒度で誰に渡すかを宣言し、監査できるか」まで踏み込むと差が見えてきます。

したがって「とりあえずエージェントにコードを実行させる場所が欲しい」「クレデンシャルを隠せれば十分」という要件であれば、より軽量な選択肢で足ります。OpenShell が効いてくるのは、権限範囲そのものを宣言物として管理し、その変更を審査プロセスに載せたい場合です。軽量性と起動速度を重視する選択肢については、AIエージェント用OSS「CubeSandbox」の仕組みと特徴で別途取り上げています。

ライセンスの観点では、CubeSandbox のみ GitHub API が NOASSERTION を返します。これはライセンスが不明という意味ではなく、CubeSandbox の LICENSE ファイルが Apache-2.0 を基本としつつ、同梱する第三者コンポーネントのライセンスを個別に列挙する構成を取っているため、GitHub 側が単一の SPDX 識別子を特定できていないものです。企業で採用する場合は第三者コンポーネントの条項まで確認する必要があります。OpenShell は API が Apache-2.0 を返すため、この確認コストはかかりません。

導入前に確認すべき前提条件と制約

OpenShell は要件が厳しめです。サポートマトリクスで明示されている条件を満たせるかどうかが、採用判断の実質的な分岐点になります。

対応プラットフォームとコンピュートドライバ

ホストプラットフォームは、Linux（Debian / Ubuntu）の x86_64 と aarch64、および Apple Silicon の macOS（arm64、Docker Desktop との組み合わせ）がサポート対象です。Windows x86_64 は WSL 2 と Docker Desktop の組み合わせで Experimental 扱いです。CLI は Linux では静的な musl バイナリとして提供され、実行時に glibc を必要としません。

コンピュートドライバは 4 種類で、それぞれ要件が異なります。

Kubernetes を選ぶ場合、CNI が NetworkPolicy を強制できる必要があります。ネットワーク制御を CNI 側の機能に依存する箇所があるため、既存クラスタの CNI 構成を事前に確認しておく必要があります。なお Kubernetes デプロイでは Helm チャートとゲートウェイイメージを使い、スタンドアロンのゲートウェイバイナリは使いません。

Linuxカーネル要件

カーネル側の要件は次の 4 点です。

• Landlock ABI 3 以降（Linux 6.2 以降）が有効であること
• ランタイムの seccomp プロファイル下で、追加の capability なしに動作する seccomp user-notification フィルタ
• 同一 UID のワークロード子プロセスへの task-memory アクセス（process_vm_readv または /proc/<pid>/mem）
• SO_BINDTODEVICE によるソケットバインド

Landlock ABI 3 の要件は Linux 6.2 以降を意味するため、長期サポート版の古いカーネルを使っている環境では満たせない可能性があります。要件が欠けていたりブロックされていたりする場合、OpenShell は隔離を弱めて動作するのではなく、サンドボックスの起動自体を失敗させます。「動いたが実は制限が効いていない」という状態を避けられる設計ですが、PoC の段階で環境要件に気づかず詰まる典型的な箇所でもあります。macOS では、これらの要件は Docker Desktop の Linux VM 内で適用されます。

バージョンサポート方針とライセンス・免責事項

成熟度に関する記載も、採用判断に直結します。

• Experimental とマークされたインターフェースは、パッチリリースで変更・削除される可能性があります
• Dev ビルドはリリース品質の検証を通っていません。プレリリースは安定した機能セットであっても品質検証を通っていない場合があります。本番環境では stable リリースを使うことが明記されています
• セキュリティおよび重大な信頼性の修正は、最新のマイナーリリースとその 1 つ前のみが対象です。それより古いパッチには修正が入りません

最後の項目は特に重要です。サポート対象が 2 マイナーリリース分しかないため、採用するならマイナーバージョンへの追従を運用計画に織り込む必要があります。0.1.x 系で機能追加が進んでいる段階であることを踏まえると、追従コストは小さくない前提で見積もるのが妥当です。

ライセンスは Apache-2.0 です。一方 README には Notice and Disclaimer として、本ソフトウェアが外部素材を自動的に取得・アクセス・相互作用するものであること、取得した素材のライセンス遵守とセキュリティ検証は利用者の責任であること、そしてソフトウェアが "AS IS" で提供されることが明記されています。エージェントが外部リソースを取得する性質上、この責任分担は導入前に組織内で共有しておく価値があります。

なお、テレメトリは匿名で収集され、操作のカテゴリとカウントに限定されます。サンドボックス名・ホスト名・ファイルパス・プロンプト・クレデンシャル・プロバイダやモデル名・ユーザーコンテンツは収集されません。ゲートウェイの環境変数 OPENSHELL_TELEMETRY_ENABLED=false、Helm では server.telemetryEnabled=false で無効化でき、コンパイル時に完全に除去することも可能です。

自律AIエージェントの実行基盤にOpenShellが向くケース・向かないケース

ここまでの内容を、採用判断の形に整理します。

OpenShell が向くケース

• 権限範囲を Git 管理された YAML として残し、監査やレビューの対象にしたい
• ポリシーを緩める変更に審査ステップを挟み、危険な変更だけを人間のレビューに回したい
• クレデンシャルを隠すだけでなく、どのバイナリにどの宛先で渡すかをプロセス単位で宣言したい
• セルフホストが要件になっている（プライベートな推論エンドポイントの利用を含む）
• Linux 6.2 以降の実行環境を自前で用意でき、カーネル要件を満たせる
• 複数のエージェントをフリートとして運用し、横断的にポリシーを管理したい

OpenShell が向かないケース

• マネージドでコード実行環境だけを素早く用意したい
• クレデンシャルをサンドボックスに入れないことが目的で、ポリシーの宣言・審査までは必要としない
• 起動速度や同時実行数の高さが最優先の要件である
• Windows のネイティブ環境が前提である
• Landlock や seccomp の要件を満たせない古いカーネルを使っている
• 単一プロセスのファイルシステム / ネットワーク制限で十分で、ゲートウェイやフリート管理の層が不要
• 最新マイナーリリースへの追従コストを運用に織り込めない

手元のコーディングエージェントに付属するサンドボックス機能で足りるかどうかを先に確認したい場合は、Claude Code ネイティブ Sandbox 入門やclaude sandbox と Docker Sandboxes の違いが出発点になります。Docker ベースの隔離から入りたい場合はClaude Code × Docker Sandbox 入門も参考になります。OpenShell はこれらより一段上のレイヤー、つまり「組織としてエージェントの権限を宣言し強制する」領域を扱うため、まず手元の隔離機能で要件を確認し、対象が組織レベルに広がった段階で検討するという順序が無理のない進め方です。

採用を検討する場合、公式ドキュメントが示している確認の流れは次のようになっています。サポートマトリクスと自環境を照合し、デフォルトポリシーでサンドボックスが起動するかを確認し、Policy Advisor でエージェントからのルール提案と承認フローを設計し、境界ポリシーを記述してプローバーで検証する、という順序です。本記事はドキュメント調査であり実機での確認は行っていないため、各ステップの所要時間や詰まりやすい箇所については、自環境での確認結果に基づいて判断してください。

まとめ

自律 AI エージェントの実行基盤を評価する際は、ファイルシステム・ネットワーク・プロセス権限の 3 層に加えて、クレデンシャルの扱いとポリシー変更の審査という 2 つの軸を見ると候補の性格が見えてきます。このうちクレデンシャルを隠す仲介層は OpenSandbox や CubeSandbox も公式ドキュメントで明示しているため、候補を絞る決め手にはなりません。一次情報で確認した範囲で OpenShell を他の選択肢から分けていたのは、ポリシー変更の審査でした。デフォルト全拒否のネットワークを「宛先 × バイナリ」のペアで宣言する YAML ポリシーと、その変更を SMT ソルバーで審査する層が、その具体的な現れです。

一方で、Landlock ABI 3（Linux 6.2 以降）を含むカーネル要件、サポート対象が最新マイナーとその 1 つ前に限られるバージョン方針、公式ドキュメントが production-ready を明示していない 0.1.x という成熟度は、採用判断で避けて通れない制約です。要件を満たさない場合に隔離を弱めず起動自体を失敗させる設計は安心材料ですが、その分だけ環境側の準備が求められます。

本記事は 2026 年 10 月 10 日時点の公式ドキュメントと GitHub API 取得値に基づくドキュメント調査です。0.1.x 系は機能追加が進行中であるため、評価する際はサポートマトリクスと自環境の照合から始め、最新の仕様は公式ドキュメントで確認することをおすすめします。

関連情報

AI エージェントを前提とした開発環境の設計や、権限・セキュリティ要件の整理についてご相談がある場合は、お問い合わせフォームからお気軽にお声がけください。要件が固まる前の段階からご相談いただけます。