AIエージェントに安全な作業場所を貸すOpenSandboxで隔離できる範囲

AIコーディングエージェントへ作業環境を渡すと、提案だけで終わらない仕事を任せられます。たとえば、次のような作業です。

• リポジトリを取得し、依存関係を入れ、修正後にテストする
• 利用者が送ったCSVをPythonで集計し、表やグラフを返す
• ブラウザを使い、Webテストや画面操作を繰り返す

この便利さには、シェル、ファイル、ネットワーク、APIキーへの接続が必要です。同じ接続があるため、誤った命令や信頼できないWebページを受けたエージェントは、ファイルの削除、社内ネットワークの探索、認証情報の外部送信、許可済みAPIによるデータ変更まで実行できてしまいます。

設計課題は、一件の仕事に必要な範囲だけを貸し出すことです。ファイル、計算資源、通信先、認証情報を絞り、失敗の到達範囲を区切り、仕事が終われば環境を捨てられるようにします。OpenSandboxは、この「作業場所の貸し出し」をアプリから扱う管理面と実行面を提供します。

OpenSandboxは、AIアプリケーションから要求を受け、DockerコンテナまたはKubernetes上のPodを作るソフトウェアです。作成した環境の命令、ファイル、コード実行を外部から操作できるようにします。

ひと言で捉えるなら

AIごとに貸し出す作業用コンピュータの管理システムです。AIモデルそのものでも、仕事を分解して次の行動を考えるエージェントでもありません。

実体が必ず仮想マシンになるわけでもありません。標準構成はホストのカーネルを共有するコンテナで、より強い分離が必要な場合にgVisor、Kata Containers、Firecrackerを組み合わせます。

外部から使うための入口

Python、JavaScript／TypeScript、Java／Kotlin、C#、GoのSDKがあります。さらに、osbというコマンドライン道具と、AIクライアントから操作を呼び出すためのMCPサーバーも用意されています。2026年3月の記事で「追加予定」とされたGo SDKは、すでに公開済みです。

OpenSandboxの役割は、一回の開発作業を追うと明確になります。人がリポジトリ、修正内容、完了条件をエージェントへ渡した後、外側のエージェント実行プログラムが専用のサンドボックスを作ります。

指定するのは利用画像、CPU、メモリ、有効期限で、通信先として許可するのはGit、パッケージ配布元、AIモデルのAPIだけです。リポジトリ用トークンとモデル用APIキーを認証情報保管機能へ登録したら、サンドボックス内でClaude CodeやCodex CLIなどを起動します。

エージェントはリポジトリを取得し、ファイルを読み、修正し、テストします。外側のプログラムが命令の出力、テスト結果、ファイル差分を回収し、人が差分を確認した後に外部リポジトリへ反映する流れです。最後に成果物を保存し、サンドボックスを削除します。

OpenSandboxが主に担うのは、環境の作成、実行経路、通信と認証情報の制限、最後の片付けです。何を修正するか、失敗時にどう計画を変えるか、差分を採用するかは、エージェント、人、外側の業務システムに残ります。

内部は、利用側の道具、作成を管理するサーバー、実際に環境を作る実行方式、サンドボックス内の実行部品に分かれます。ライフサイクルサーバーはPythonのFastAPIで作られ、担当は認証、入力検証、有効期限、状態、接続先です。DockerまたはKubernetesの実行方式が、その要求をコンテナやPodへ変換します。

各サンドボックスには、execdという常駐プログラムが入ります。外側のSDKがAIへ直接OSの接続情報を渡すことはなく、命令、ファイル、対話端末、コード実行、CPU・メモリ指標の操作はすべてexecdのAPI経由です。必要に応じて、外向き通信を制御するサイドカーも同じネットワーク空間へ追加されます。

この分離により、アプリ側は共通APIを使いながら、開発時は一台のDocker、本番はKubernetesへ移れます。一方、停止・再開、保存領域、入口の認証、複数利用組織の分離などは、実行方式ごとの差が残る部分です。『同じAPIならどこでも完全に同じ』とは考えない方が安全です。

OpenSandboxを導入しただけで、AIの実行が自動的に安全になるわけではありません。安全性は、通常のコンテナ、強化した実行方式、通信規則、認証情報、入口の認証、利用組織の分離を重ねて作ります。

通常のDockerやKubernetesコンテナはホストのカーネルを共有します。gVisorやKata ContainersはOpenSandboxが内蔵して自動的に有効にする機能ではなく、運用者がホストまたはクラスタへ導入し、利用する実行方式として設定する部品です。互換性と起動時間も変わるため、ブラウザ、パッケージ導入、必要なシステム呼び出しを実環境で検証する必要があります。

外向き通信、サーバーのAPIキー、サンドボックス内サービスへの入口保護も明示設定です。ホストの広いフォルダーを読み書き可能で接続したり、外向き通信を全面許可したりすれば、環境を分けた効果は弱くなります。サンドボックスは製品名ではなく、到達可能な範囲を実際に狭めて初めて防御になります。

Credential Vaultは、本物のAPIキーをサンドボックスへ置かず、通信時だけ認証情報を代理で付ける機能です。外側の信頼できるプログラムが、APIキーを通信制御用サイドカーへ登録します。

サンドボックス内のCLIには偽の値を渡します。許可されたHTTPS要求がホスト、方式、パスなどの条件に一致した場合だけ、サイドカーが本物の認証ヘッダーを加えます。

この仕組みで減らせるのは、環境変数の表示、不審なコードによるファイル探索、ログへの書き出しといった認証情報そのものの漏えいです。ただし、許可されたAPIを操作する能力は残ります。読み書き可能なGitトークンを代理注入すれば、キーを読めなくても、その権限でリポジトリを変更できます。

対策には、通信先だけでなく、HTTPメソッドとパス、外部API側の権限範囲、人の承認を組み合わせます。現行機能は外向きHTTPSの中継と通信の書き換えに依存し、dns+nft方式、原則として既定拒否の通信規則、信頼する証明書の設定が必要です。同じPodへIstioやEnvoyなど別の透過型通信サイドカーを入れる構成は、現在サポートされていません。

長い仕事を扱うために、OpenSandboxは保存領域、スナップショット、停止・再開、事前起動プールを備えます。ただし、似た言葉でも保存対象は異なります。

Dockerの停止はコンテナの処理を止めて戻します。Kubernetesの現行方式は、ルートファイルシステムをOCI画像として保存してPodを解放し、再開時に作り直します。実行中のメモリやプロセスをそのまま凍結する仕組みではありません。認証情報保管機能の内容もメモリ上にあるため、Kubernetesで再開した後は信頼側から再登録します。

大量評価で使えるのは、同じひな型から複数のサンドボックスを作るKubernetes向け機能や、SDK側の事前起動プールです。公式文書には高速な社内測定値もありますが、画像のキャッシュ、クラスタ、実行方式、準備完了条件で変わります。導入時は自社の画像と処理で、初回起動と起動済みの場合を分け、中央値だけでなく遅い側の時間と失敗率を測る必要があります。

Dockerはコンテナを作り、処理、ファイル、ネットワークを分ける土台です。OpenSandboxはDockerを置き換えず、その上へAIアプリケーション向けの作成・削除API、命令・ファイルAPI、有効期限、複数言語SDK、外向き通信制御、認証情報の代理注入、Kubernetesへの切り替えを加えます。

一台で信頼済みの短いスクリプトを数回動かすだけなら、Dockerを直接使う方が部品は少なくなります。複数のアプリから遠隔操作する、利用者ごとに環境を分ける、大量に作る、通信と認証情報を統一規則で制御するほど、OpenSandboxの管理面が効いてきます。

E2B、Modal、Daytonaのようなマネージドサービスは、計算資源と運用をサービス側が引き受ける形です。OpenSandboxは自社のDockerまたはKubernetesへ配備するソフトウェアで、実行するクラウド、ネットワーク、保存領域、強化実行方式を選べる代わりに、更新、監視、容量、障害対応を自分たちで持ちます。機能数の横並びより、制御と運用負荷のどちらを引き受けるかで選ぶ対象です。

Kubernetes SIG Appsのagent-sandboxはOpenSandboxと完全な競合ではありません。前者はKubernetes上で安定した識別子を持つ一つの作業単位を表すコントローラーで、OpenSandboxはそれを実行先の一つとして利用できます。

2026年3月初めの記事は、約2,200〜3,000スター、server 0.1.4、Go SDKとHelm対応は今後という当時の状態を伝えていました。2026年8月17日時点では、公式リポジトリはopensandbox-group/OpenSandboxへ移り、約1万4,000スター、約1,200フォークになっています。Go SDK、Helmチャート、CLI、Credential Vault、複数利用組織向け機能なども公開されています。

一方、完成した一枚岩の製品版があるわけではありません。サーバー、各言語SDK、execd、外向き通信、入口ゲートウェイは別々に版管理され、serverの最新公開版は0.2.2です。安定版v1 APIの宣言は、ライフサイクルの意味や実行方式、SDKの互換性が成熟するまで現時点の計画外とされています。

server 0.2.2では、入口トークンの検証漏れ、通信サイドカーの設定を悪用して認証情報へ到達できる問題など、具体的なセキュリティ修正も公開されました。これは公開開発の利点であると同時に、導入後もサーバーだけでなく関連部品の更新情報を追い、互換性を検証する必要があることを示します。公式コンテナ画像は署名と来歴情報を伴って公開され、運用向けには内容を固定するダイジェスト指定と署名確認が案内されています。

OpenSandboxが向くのは、AI生成コード、コーディングエージェント、ブラウザ自動化、評価処理を、自社クラウドやオンプレミスで動かしたい組織です。既存のKubernetes、ネットワーク規則、保存領域、監視へ組み込み、利用者や仕事ごとに実行環境を分けたい場合に価値があります。

すぐ使える世界規模の計算サービスを求める組織や、コンテナ、Kubernetes、証明書、ネットワーク、コンテナ画像を運用する担当がいないチームには重い選択です。AIの計画、記憶、承認画面、業務フローまで一製品で完成させたい場合も、別のエージェント実行プログラムと業務システムが必要です。

導入検証では、機能一覧より境界が破られないかを確認します。通信の直接IPや名前解決による回避、ホストと別環境への到達、認証情報のログ露出、許可済みAPIによる誤操作、強化実行方式での互換性が、実環境で試す項目です。さらに、サーバー、SDK、execd、通信部品の版を固定し、初回起動と起動済み、同時実行時の遅延と失敗率を分けて測ります。

OpenSandboxの価値は、AIアプリケーションが作業環境を借りるための共通操作へ、Docker、Kubernetes、命令、ファイル、通信、認証情報、保存をまとめた点にあります。ローカルの一コンテナから、多数の利用者を分けるクラスタまで同じ考え方で拡張できます。

ここからは筆者の見立てです。AIエージェントが増えるほど、モデルの賢さだけでなく、次の四点が運用品質を決めます。

• 一件の仕事へ何を見せるか
• どこへ接続できるようにするか
• どの認証情報を、どの要求だけに使わせるか
• いつ成果物を回収し、環境を捨てるか

OpenSandboxは、この実行境界を自社で持ちたい組織にとって有力な部品です。一方で、各部品の版は分かれており、安定版v1 APIも未宣言です。

採用判断は「Alibaba発だから安全」「コンテナだから安全」という看板ではなく、自社の処理を通常コンテナで十分に分けられるか、強化実行方式が必要か、通信と認証情報をどこまで狭められるか、更新を継続できるかで行うべきです。