AIエージェントの作業を隔離環境で動かすOSS「OpenSandbox」の仕組みと導入前の注意点

「コード生成のエージェントに検証まで任せたいが、社員の端末やサーバーで直接コマンドを走らせるのは怖い」「隔離環境を使えと言われても、どこまで閉じれば十分なのか判断がつかない」——開発部門からエージェントの導入相談を受けた情報システム担当の方から、こうした声が届いています。多くの場合、論点は「隔離環境があるかどうか」に置かれがちです。しかし本当に問うべきなのは、隔離の強さ、外へ出る通信、中に置く鍵を、誰がどう決めて運用するかという点です。この記事では、エージェントの作業を自社の基盤上の隔離環境で動かすOSS「OpenSandbox」を取り上げ、元の公開元、仕組み、既定の設定のままでは守りが薄くなる点、導入前に決めておくことを整理します。導入や設定の手順は扱いません。

OpenSandboxとは何か。2026年10月時点で確かめられる事実

OpenSandboxは、GitHubで公開されているOSSです。リポジトリの説明は「AIエージェントのための、安全で速く拡張できるサンドボックス（外から切り離した実行の場）の実行基盤」で、READMEの冒頭には「AIエージェントを自社の基盤の上のサンドボックスで動かす」とあります。READMEによると、AIを使う仕組みに対して、コードの実行、コマンドの実行、ファイルの管理、ブラウザやデスクトップの操作を行うための隔離された環境を提供するものです。

このラインの精査を行った2026年10月19日時点で、スターは15,945、派生は1,482、最後の更新は10月18日でした。リポジトリが作られたのは2025年12月17日で、1日あたりのスターの伸びは約52件です。ライセンスはApache 2.0で、商用利用も認められています。

開発の動きも活発です。リリースの一覧によると、9月21日に1.1.0、10月9日に1.1.1が出ており、10月15日には次の版の候補（1.2.0の試験版）が出ています。一方で、10月8日に更新された今後の計画の文書は、仕組みの振る舞いが十分に固まるまで、安定版の約束（第1版の確定）はしないと明記しています。外から使う窓口が今後も変わりうる段階にある、と受け止めておくのが妥当です。

元の公開元はどこか：アリババの組織から移ったリポジトリ

現在の持ち主は、OpenSandboxの名を冠した専用の組織のアカウントで、作られたのは2026年6月4日です。リポジトリは2025年12月作成なので、組織より前からリポジトリがあったことになります。そこで、元の公開元を一次情報で確かめました。まず、GitHub上のアリババの組織の下にあった同名のリポジトリのアドレスは、現在の場所へ恒久的に転送されることを、10月19日に確認しました。GitHubでは、リポジトリを別の持ち主へ移すと旧アドレスが新しい場所へ転送されます。

ほかの記録も同じ方向を指しています。オープンソースの開発体制を審査する団体の認定（OpenSSFのベストプラクティス）では、このプロジェクトは旧アドレスで登録され、三段階のうち中位のシルバーと表示されています。クラウド関連技術の一覧を公開している団体の地図（CNCFの技術地図）でも、リポジトリは旧アドレスで載り、所属先の参照はアリババのクラウド部門になっています。さらに、言語ごとの部品の名前や配布先の一部には、今もアリババの名が残っています。

以上から、OpenSandboxはアリババの組織で公開され、のちに専用の組織へ移されたと判断できます。ただし、移した時期と理由、アリババが今どこまで関わっているかは、確認した一次情報では分かりませんでした。新しい組織のアカウントには会社名の記載がなく、公開リポジトリは関連する3件だけです。なお、地図への掲載は一覧に載ったことを示すもので、その団体が正式に受け入れたプロジェクトであることを意味するものではない点にも注意が要ります。

なぜAIエージェントに隔離環境が要るのか

コード生成のエージェントは、コードを書くだけでなく、そのコードを実行し、ファイルを書き換え、外部の部品を取り寄せます。ブラウザを操作するエージェントは、知らないサイトを開き、その内容を読みます。どちらも、エージェントが何を実行するかを、事前に人が一つずつ確かめることはできないという性質を持っています。

ここで問題になるのが、外から紛れ込んだ指示です。読み込んだ文書やウェブページに仕込まれた指示に従って、エージェントが手元の鍵を外へ送ったり、社内の別のサーバーへ接続したりする危険は、エージェントを使ううえでの代表的な懸念です。OpenSandboxの鍵の扱いの資料も、外から紛れ込んだ指示や信頼できないコードによる鍵の持ち出しの危険を減らすことを目的に挙げています。

こうした危険への基本の備えが、エージェントの作業を本来の環境から切り離すことです。隔離環境の中で何が起きても、外の端末や社内の網には届かないようにする。OpenSandboxは、その隔離環境を作り、使い終えたら捨てる、という一連の流れを、手元の一台からクラスタ（複数のサーバーを束ねた基盤）まで同じ窓口で扱えるようにしたものだと説明されています。

仕組み：管理サーバー・隔離環境・通信の出入口

設計の資料によると、OpenSandboxはいくつかの部分に分かれています。中心は管理サーバーで、隔離環境の作成、一覧、延長、一時停止、再開、削除といった依頼を受け、要求の認証を行い、実際の作成は選ばれた実行基盤に任せます。実行基盤は、一台で動かすDockerと、大規模に動かすKubernetesから選べます。

隔離環境の中には、コマンドやファイルの操作を受け付ける常駐の部品が入ります。利用者はこの部品に直接つながってコマンドを実行したり、ファイルを読み書きしたりします。外から隔離環境の中の画面や機能へつなぐ入口として、クラスタ向けにはすべての隔離環境の手前に立つ中継役が用意されています。

もう一つ重要なのが、隔離環境から外へ出る通信の出口です。隔離環境ごとに通信の見張り役が付き、外部のサービスや言語モデルの提供元への通信を、規則に沿って絞り込みます。使い方の窓口としては、五つの言語向けの部品、端末から操作する道具、MCPのサーバーが用意されており、MCPのサーバーは隔離環境の作成、コマンドの実行、文字のファイルの操作をエージェントに開くとREADMEに書かれています。

隔離の強さは選べる：標準のコンテナと、より強い実行環境

隔離の強さは、実行環境の選び方で変わります。資料の比較表によると、既定は通常のコンテナの実行環境で、表では「信頼できる作業や手元の開発向け」とされているものです。これはプロセス単位の切り分けで、立ち上がりの遅れはほぼありません。

より強い隔離として、利用者の側で動く独自の核を挟むgVisor、軽量の仮想マシンを使うKata（仮想化の仕組みを三種類から選べる）などに対応しています。資料はこれらの利点として、コンテナの外への脱出の防止、隔離環境ごとに独立した核、利用者どうしの強い切り分けを挙げています。Firecrackerを使う軽量の仮想マシンでは、READMEによると作成にかかる時間は1件ずつ作る場合の中央値で64ミリ秒とされています。ただし、これは開発元が公表した測定値で、自社の基盤で同じ速さが出るとは限りません。

実行環境の選択は、利用者ではなくサーバーの管理者が一度だけ設定し、そのサーバーのすべての隔離環境に適用される作りです。指定した実行環境が使えない場合、サーバーは起動を拒むとされています。つまり、隔離の強さは、運用者がサーバー単位で決める事項です。信頼できないコードを動かす前提なら、既定のままにせず、どの実行環境を使うかを先に決める必要があります。

外向き通信の制御：許可した行き先だけに出す

通信の出口の資料によると、見張り役は隔離環境と同じ網の区画に置かれ、外へ出るすべての通信がそこを通ります。隔離環境の中の作業は網の設定を変える権限を持たないため、中から見張り役を迂回する手段はないと説明されています。規則は、行き先の名前、名前の一部、アドレス、アドレスの範囲ごとに許可か拒否を決められ、作成時に宣言するほか、動かしながら変更もできます。

ここで押さえておきたいのが、守りの段階が二つあることです。既定の段階は、名前の問い合わせ（DNS）の段階で拒否した行き先の名前を引けなくするもので、資料自身が「名前しか見ない」と書いています。もう一段強い設定では、通信の単位で許可したもの以外をすべて落とします。名前を通さずにアドレスへ直接つなぐ通信まで止めたいなら、この強い設定を選ぶ必要があるということです。

運用者向けの仕組みもあります。運用者が置く「常に拒否」「常に許可」の規則は、利用者がどんな許可を出しても上書きできず、届いてよい通信の窓口の番号に上限をかけることもできます。また、見張り役が規則を組み込めなかった場合は、素通りで動き続けるのではなく停止する作りです。暗号化した名前の問い合わせへの備えや、拒否した件数を外部の監視基盤へ送る機能も資料に載っています。

鍵を中に置かない「Credential Vault」

OpenSandboxのもう一つの柱が、鍵の扱いです。資料によると、Credential Vaultは隔離環境の外向きの通信に鍵を差し込む仕組みです。本物の鍵は外側の部品から見張り役に書き込まれ、隔離環境の中の作業には、偽の値か空の値しか渡らないと説明されています。外部のサービスへの通信が登録した条件に一致したときだけ、見張り役が認証の情報を付けて送ります。

条件は、通信の方式、行き先、窓口の番号、操作の種類、道筋の五つで照らし、ちょうど一つの登録に一致したときに鍵が付きます。鍵の値は、問い合わせの応答や記録から伏せられるとされています。資料は、鍵を隔離環境の環境変数、ファイル、記録に残さないことで、外から紛れ込んだ指示や信頼できないコードによる鍵の持ち出しの危険を減らせると位置づけています。

ただし条件があります。この仕組みは、通信の単位で絞り込む強い設定でなければ有効になりません。名前の段階だけの絞り込みでは、アドレスへ直接つなぐ通信がすり抜けうるからだと説明されています。また、行き先は既定で拒否にし、鍵を使う相手だけを許可する形が求められ、既定で許可する形は互換のために残されているものの警告が出ます。クラスタで一時停止すると鍵は消えるため、再開のたびに信頼できる場所から入れ直す必要がある点も、運用の負担として押さえておきたいところです。

手元の一台から社内のクラスタまで：使われる場面

READMEは、使われる場面として四つを挙げています。一つ目は、コード生成のエージェントを隔離環境で動かし、ファイルの編集やコマンドの実行をさせることです。例として、他社製の代表的なコード生成エージェントを隔離環境の中で動かす手引きが並んでいます。二つ目は、モデルが生成したコードを実行して、その結果を使うデータ分析です。

三つ目は、ブラウザやデスクトップの操作の自動化です。ウェブの試験や、エージェントにデスクトップの画面を使わせる例が載っています。四つ目は、エージェントの評価で、試行ごとに別の隔離環境を用意する使い方です。READMEによると、隔離環境をまとめて用意する仕組みや一括での作成もあり、評価や学習のために大量の隔離環境を並べて動かす用途も想定されています。

企業の立場から見ると、自社の基盤の上で動かせることが大きな意味を持ちます。READMEの冒頭の一文が示すとおり、隔離環境を提供元の外部サービスに預けるのではなく、自社が管理するサーバーやクラスタの中に置けるということです。逆に言えば、基盤の守り、更新、監視の責任は自社が負うことになります。

似た手段と何が違うのか

エージェントの作業を切り離す方法は、ほかにもあります。確認できた事実をもとに、代表的な手段と比べます。優劣ではなく、どこまでを自社で持つかの違いとして読んでください。

見る点	社員の端末で直接動かす	提供元の外部の隔離サービス	OpenSandbox（自社の基盤）
作業の場所	社員の端末そのもの	提供元の基盤	自社のサーバーやクラスタ
隔離の強さ	ほぼなし	提供元の作りに左右される	運用者が実行環境を選ぶ（既定は通常のコンテナ）
外向き通信の制御	端末の設定しだい	提供元の作りに左右される	隔離環境ごとに行き先を絞れる（強い設定は運用者が選ぶ）
鍵の置き場所	端末の中	提供元の作りに左右される	見張り役に置き、中には偽の値を渡せる
基盤の守りと更新の責任	社員と情報システム部門	主に提供元	自社
データの置き場所	端末の中	提供元の基盤	自社の基盤

表のとおり、OpenSandboxを選ぶことは、隔離環境を自社で持ち、その守りも自社で担うことを意味します。データを社外に出さずに済む利点と、基盤を守る手間は表裏一体です。

また、隔離環境は「エージェントの中で何が起きても外に漏らさない」ための仕組みであり、「エージェントが許された範囲で行う誤った操作」を止める仕組みではありません。本番のデータベースへの操作を一件ずつ判定するような関所の仕組みとは役割が違い、置き換えではなく重ねるものと考えるのが妥当でしょう。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。OpenSandboxの判定は「紹介可」です。

根拠は次のとおりです。ライセンスはApache 2.0です。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下に、取り込んだだけで自動的に動く処理は見つかりませんでした。開発体制を審査する団体の認定ではシルバーと表示され、クラウド関連技術の一覧の地図にも載っています。所有する組織は2026年6月作成と新しいものの、2025年12月にアリババの組織で作られたリポジトリが移されたものであることを旧アドレスの転送で確かめており、新しい組織にありがちな実績の乏しさには当たらないと判断しました。

セキュリティ方針の文書があり、弱点の報告はGitHubの非公開の窓口で受け付け、48時間以内に受領を返すとしています。修正の対象は最新のリリースと開発の本流だけです。運営の文書では、隔離、通信、鍵、実行の安全に関わる変更は特に慎重に審査すると定めています。ただし、勧告がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。隔離の仕組みそのものに弱点があれば守りの前提が崩れるため、評価は導入する側でも重ねる必要があります。

導入前の注意点：既定の設定のままでは守りが薄い

第一に、既定の実行環境が通常のコンテナである点です。前述のとおり、資料自身が「信頼できる作業や手元の開発向け」と位置づけています。エージェントが生成した信頼できないコードを動かすなら、より強い実行環境を選ぶことが前提になります。第二に、管理サーバーの認証です。設定の資料によると、認証の鍵を設定しなければ、管理サーバーは認証なしで動くとされ、本番では必ず鍵を設定するよう求めています。

第三に、クラスタの中の隔離環境どうしの通信です。網の切り分けの資料によると、クラスタでは既定で、ある隔離環境から別の隔離環境へ直接つながります。資料は、内部の網の探索、他の隔離環境への無断の接続、利用者をまたぐ情報の漏えいの危険を挙げ、運用者が「常に拒否」の規則でクラスタ内の宛先を閉じる方法を案内しています。標準の網の規則だけでは足りないと資料自身が説明している点は重要です。

第四に、入口と記録です。クラスタ向けの中継役は暗号化した通信を扱わないため、手前に別の中継の仕組みを置く必要があります。一時停止で保存した中身は外部の置き場に送られ、その記録を消しても送った中身は消えないとされています。第五に、版の成熟度です。10月9日の1.1.1は、1.1.0のサーバーの配布物がすべての環境で読み込みに失敗する不具合を直すために出ました。通信の暗号を解いて中身を見る機能も、資料では「試験的だが本番でも使える」とされ、設定の窓口は版ごとに変わりうると書かれています。

悪用されうるリスク

OpenSandboxは守りのための基盤で、攻撃のための道具ではありません。それでも、置き方しだいで生まれうる危険はあります。最も大きいのは、「隔離環境に入れたから何をさせても大丈夫」という安心が独り歩きすることです。既定の設定のままでは、隔離はプロセス単位、通信の絞り込みは名前の段階まで、管理サーバーは認証なしになりえます。

次に挙げるのは推測ですが、検討の材料になります。管理サーバーは、隔離環境を作り、中でコマンドを実行させる窓口です。認証なしのまま社内の網に置かれれば、社内の誰でも、あるいは侵入した攻撃者が、任意のコードを実行する場所として使える可能性があります。また、通信の暗号を解く機能を有効にすると、見張り役が独自の証明書の発行元を隔離環境の信頼の一覧に入れ、暗号化された通信の中身を読める立場に入ります。見張り役の守りが甘ければ、そこが狙われる筋書きも考えられます。

もう一つは、外へ出る通信を緩くしたまま使うことです。行き先を既定で許可にしていれば、紛れ込んだ指示に従ったエージェントが、隔離環境の中で得た情報を外へ送ることは止まりません。隔離は「外の端末に届かない」ことを守っても、「中で得たものを外へ出さない」ことまでは、通信の規則を絞らない限り守れないと考えられます。なお、OpenSandboxが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、既定の設定を前提にせず、守りの水準を一つずつ決めてから動かすことです。OpenSandboxは強い守りを選べる作りですが、選ばなければ働きません。

企業が取るべき対策

一つ目は、エージェントを社員の端末で直接動かしている現状の把握です。OpenSandboxを使うかどうかにかかわらず、どの部署でどのエージェントが、どの権限でコマンドを実行しているかを確かめます。隔離環境を用意する前に、隔離されていない利用を見つけることが出発点です。

二つ目は、隔離の水準の社内基準です。扱うデータの区分ごとに、通常のコンテナで足りるのか、仮想マシンの隔離が要るのかを決めておきます。三つ目は、外向き通信の既定の拒否です。許可する行き先を一覧にし、一覧にない通信は止めることを、隔離環境を使う条件として定めます。

四つ目は、鍵の扱いです。隔離環境の中に本物の鍵を置かない運用を基本にし、鍵を差し込む仕組みを使う場合も、鍵の保管元と入れ直しの手順を決めます。五つ目は、調達のときの確認です。安定版の約束がまだないこと、最新版だけが修正の対象であること、元の公開元から専用の組織へ移った経緯を踏まえ、社内で使える段階かどうかを文書で判断します。配布されている実行用の部品には署名が付けられ、READMEは本番では中身の識別値で固定するよう勧めているので、その確認も手順に含めます。

AIに任せる範囲と、人が決める範囲

OpenSandboxは、AIエージェントに作業を任せるための土台です。MCPのサーバーを通せば、エージェント自身が隔離環境を作り、中でコマンドを実行できます。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、どの実行環境を使うか、どの行き先への通信を許すか、どの鍵を差し込むか、隔離環境にどの情報を持ち込むか。この四つはエージェントにも道具にも委ねず、人が決めて記録に残します。エージェントに規則の追加を提案させる場合も、根拠を書かせ、人が確認する範囲を先に決めておくと、あとから判断を振り返れます。やってはいけない向き合い方を挙げます。

• 既定の通常のコンテナのまま、信頼できないコードを動かす
• 認証の鍵を設定しないまま、管理サーバーを社内の網に置く
• 外向き通信を既定で許可にしたまま、社内の情報を隔離環境に持ち込む
• 許可する行き先の追加を、エージェントの判断だけで決めさせる
• クラスタ内の隔離環境どうしの通信を閉じないまま、複数の部署で共用する
• 版を固定せず、最新版を確かめないまま本番に広げる

裏を返せば、人が決める範囲ははっきりしています。どれだけ強く閉じ、どこへの通信を許し、どの鍵を渡し、誰が基盤を守るか。この四つが決まっていないまま隔離環境を用意しても、守りの厚みは増えません。

よくある質問：隔離環境に入れればエージェントは安全か

答えは「それだけでは足りない」です。隔離環境は、エージェントの作業が外の端末や社内の網に届かないようにする仕組みです。中で得た情報を外へ送る通信や、許可した範囲での誤った操作は、通信の規則と運用で別に備える必要があります。どの守りも、運用者が有効にして初めて働く点は、資料のあちこちから読み取れます。

では使う意味がないのかというと、そうではありません。仮想マシンを使う強い隔離を選べること、外向きの通信を行き先ごとに絞り、規則を組み込めなければ止まる作りであること、本物の鍵を隔離環境の中に置かずに済むことは、エージェントがだまされたときの被害を確かに小さくします。自社の基盤に置けるため、データを社外に出さずに済む点も利点です。

もう一つ、「アリババの組織から移ったことを、どう受け止めればよいか」という問いもありそうです。移した理由は確認した一次情報では分かりませんでした。調達の判断では、運営の文書、修正の窓口、署名の確認方法といった今の運営の仕組みを確かめ、今後の運営体制の変化にも目を配るのが現実的でしょう。

• OpenSandboxの機能・版・設定の既定値・制限は、GitHubのリポジトリとその中の文書（README、セキュリティ方針、運営の文書、今後の計画、設計と使い方の資料）、リリースの一覧を2026年10月19日に確かめた範囲に基づきます。安定版の約束がない段階のため、内容は変わる可能性があります
• 元の公開元は、アリババの組織の下の旧アドレスが現在の場所へ転送されること、開発体制の認定と技術一覧の地図の登録先、部品の名前で確かめました。移した時期と理由、アリババの現在の関わり方は確認できませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

OpenSandboxは、AIエージェントにコードの実行、ファイル操作、ブラウザやデスクトップの操作をさせるための隔離環境を、自社の基盤の上で作るOSSです。隔離の強さを選べ、外向きの通信を行き先ごとに絞れ、本物の鍵を隔離環境の中に置かずに済む仕組みを持っています。元はアリババの組織で公開され、現在は専用の組織に移っています。Apache 2.0で公開され、GitHub上にセキュリティ勧告は登録されていません。

一方で、既定の実行環境は通常のコンテナで、認証の鍵を設定しなければ管理サーバーは認証なしで動き、クラスタの中の隔離環境どうしは既定でつながります。どの守りを有効にするかは、道具ではなく人が決める範囲です。閉じ方、通信の許可、鍵の扱い、基盤を守る担当を先に決めたうえで使うことが、エージェントに作業を任せる時代のOpenSandboxとの付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。