AIエージェントに作業環境を渡す企業が知っておきたいOSS「AIO Sandbox」の使いどころ

「AIエージェントにブラウザもシェルも使わせたいが、道具ごとに別々の環境を用意するのは手間がかかる」「全部入りの箱に入れておけば、社内の端末は守れるのではないか」——AIエージェントの検証を任された開発部門や情報システムの担当者から、最近よく聞かれる二つの声です。道具をまとめた箱を一つ用意すれば、手間も危険も一度に片づくように見えます。しかし、まとめることと守ることは同じではありません。本当に問われるのは、その箱の中で何が共有され、箱の外へどこまで手が届くのかを、人が把握しているかどうかです。この記事では、AIエージェントの作業環境を一つのコンテナにまとめるOSS「AIO Sandbox」を取り上げ、一次情報で確かめられる事実と、企業が使いどころを決める前に押さえておくべき点を整理します。導入や設定の手順は扱いません。

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

AIO Sandboxは、GitHubの agent-infra という組織のアカウントで公開されているOSSです。リポジトリの説明では、AIエージェントのための「全部入りのサンドボックス（外と切り離した作業の場）」とされ、ブラウザ、シェル（命令を打ち込んで動かす画面）、ファイル操作、MCP、VSCode Serverを一つのDockerコンテナ（アプリを動かすための仕切られた箱）にまとめたものと書かれています。READMEには、このほかにJupyter（対話しながらPythonを動かす環境）も並んでいます。

配布の形を確かめます。リポジトリは2025年8月6日に作られ、ライセンスはApache-2.0です。2026年10月26日時点でスターは6,231、派生は563、最後の更新は9月14日でした。一日あたりのスターの伸びは約14件で、急な水増しを疑わせる数字ではありません。一方、運営する組織のアカウントは2025年3月10日に作られ、公開しているリポジトリは2件、フォロワーは172です。利用は広がりつつあるが、運営元についての公開情報は少ないという組み合わせが、この記事の判定に関わってきます。

開発者が自分のプログラムから呼び出すための部品（SDK）は、Python版・TypeScript版・Go版が用意されています。公式サイトには導入の手引き、機能ごとの説明、運用の手引きがまとまっています。リリースの一覧で確認できた最新の版は1.11.0です。READMEは、再現できる形で使うために版を固定することを勧めています。日本語で仕組みや注意点を整理した資料は、確認した範囲では見つかりませんでした。

なぜ「全部入り」の作業環境が求められるのか

READMEは、従来のサンドボックスが「ブラウザだけ」「コードだけ」「シェルだけ」という単一の目的で作られているため、道具の間でファイルを受け渡したり、機能を連携させたりするのが難しいと指摘しています。AIエージェントの仕事は、ウェブで資料を探し、ダウンロードし、中身を加工し、結果を保存する、というように複数の道具をまたいで進むことが多いからです。

この考え方の背景として、READMEは一本の論文を参照しています。2025年9月に公開された、画面を操作するAIエージェントのモデル「UI-TARS-2」の技術報告です。論文の表紙にはByteDance Seedと記されており、その中で、ブラウザで落としたファイルをそのまま他の道具で扱える「ファイルの共有」を中心に据えた全部入りのサンドボックスが説明されています。論文では、仮想の機械が数千の単位で動く大規模な基盤の一部として位置づけられています。

ただし、論文で説明されている基盤と、公開されているAIO Sandboxが同じものかどうか、また運営組織とByteDanceの関係は、リポジトリには明記されていません。考え方の出どころは論文で確かめられるが、運営元が誰かは確かめられないというのが現時点の整理です。なお、READMEには中国本土の利用者向けの別の配布先も載っています。

一つのコンテナに何がまとめられているのか

READMEと公式サイトの説明から、まとめられている機能を整理します。ブラウザは三つの入り口から操作できます。人が画面を見て操作する遠隔デスクトップ（VNC）、プログラムからブラウザを動かすための通信規格（CDP）、そしてAIエージェント向けのMCPです。加えて、ブラウザで動くコードエディタ（VSCode Server）、Jupyter、ウェブ上の端末画面、内部で動かしたウェブアプリを確かめるための転送の機能があります。

MCPについては、ブラウザ操作、ファイル操作、命令の実行、文書の変換を担うものが、あらかじめ組み込まれていると説明されています。リリースの記録では、組み込みの道具の数を60から30に減らした更新もありました。さらに1.10.0の版では、別の会社のコード生成AI「Codex」の命令用の道具が同梱されるようになったとされます。一つの箱に入っている道具の数が多いほど、AIエージェントにできることは広がり、点検すべき入口も増えるという関係は押さえておく必要があります。

リリースの記録には、運用に関わる変更も並んでいます。JupyterやVSCode Serverを使わない設定で止められるようにした更新、ブラウザの安全装置を外す指定を取り除いた「安全面の強化」、ウェブページからファイル選択の画面を開かせるかどうかを選べるようにした更新などです。これらは、使わない機能を止め、開ける範囲を絞る余地が用意されていることを示しています。逆に言えば、何も決めずに使うと、すべての機能が動いた状態になりえます。

ファイルを共有する設計が意味すること

AIO Sandboxの一番の特徴は、すべての道具が同じコンテナの中で動き、ファイルの置き場を共有している点です。READMEは、ブラウザでダウンロードしたファイルが、すぐにシェルやファイル操作から使えると説明しています。道具の間で受け渡しの仕組みを作らずに済むため、AIエージェントの作業はなめらかに進みます。

守りの目線で見ると、同じ事実は別の意味を持ちます。ブラウザで開いたウェブページ、命令を実行するシェル、コードエディタ、ファイル操作の道具が、同じファイルの置き場を見ているということは、どれか一つの入口から入ったものが、他のすべての道具に届くということです。たとえば、ウェブから取り込んだファイルの中身が、そのままシェルで扱われる経路が最初から開いています。

公式サイトの説明を読む限り、道具どうしの間に仕切りがあるとは書かれていません。仕切りはコンテナの外側にあると読むのが自然です。箱の中は一つの部屋であり、部屋の中に置いたものは、どの道具からも見えると考えて、置く情報を決める必要があります。これは欠陥ではなく、便利さと引き換えにした設計の性格です。

認証の仕組みと、既定で開いている点

READMEは、認証の鍵を設定すると、操作用の窓口、Jupyter、遠隔デスクトップを守れると説明しています。そのうえで、鍵を設定しなければ各機能は開いたまま動くとはっきり書いています。以前の版との互換を保つための扱いとされています。手元の端末で一人が試す分には問題になりにくくても、ほかの機械から届く場所に置いた瞬間に、誰でも命令を実行できる状態になりえます。

認証の手引きには、公開鍵で署名を確かめる方式（JWT）も示されています。業務側のサービスが秘密鍵で署名した通行証を発行し、サンドボックス側が公開鍵で確かめる形です。ブラウザから直接開く画面のように通行証を付けにくい場面向けに、使い捨ての短い引換券を発行する仕組みもあり、既定の有効期間は30秒とされています。長く使える鍵を渡さず、短く切った通行証で入らせる考え方が用意されている点は評価できます。

一方で、鍵の渡し方の一つとして、接続先の住所（URL）の後ろに鍵を付ける方式も挙げられています。住所に付いた値は、閲覧の履歴や中継の機器の記録に残りやすい性質があります。確認した範囲では、この方式の扱いについて特段の注意書きは見当たりませんでした。社内で使う場合は、どの渡し方を認めるかを、運用の決まりとして先に絞っておくのが無難です。

待ち受けの口と、公開の手引きが求めていること

READMEによると、サンドボックスはコンテナの中で、すべての通信の受け口で待ち受けます。そのため、READMEの起動の例は、外から届く口を手元の機械だけに限っています。クラウドに置く場合の手引きは、待ち受けの口をそのまま公開せず、暗号化の通信を終える中継の機器を前に置き、そこからだけ届くようにすることを求めています。

同じ手引きは、利用者の認証を前段で行う方法として、社内の統合認証を中継の機器に入れる、管理者だけが使う環境では接続元の住所で絞る、サンドボックス自体の通行証の確認を有効にする、の三つを挙げ、少なくとも一つを使うよう求めています。また、遠隔デスクトップ、コードエディタ、MCP、説明書のページを外に見せる前に認証を必須にすること、資源の上限を決めること、記録と稼働状況を見張ることも並べています。

運用の手引きは、手元のサンドボックスは「信頼できる手元の開発」のためのものだと位置づけ、認証のない操作用の窓口をインターネットに公開しないよう明記しています。秘密の値は実行時に渡すか秘密情報の管理の仕組みを使い、コンテナの元になる型や生成されたファイルに含めないこと、作業ごとに短い期間だけ使える鍵を優先することも求めています。提供元自身が「外に出すなら守りを足せ」と言っている点を、導入の判断の出発点にしてください。

外への通り道：転送の機能と上流の中継

ネットワークの手引きによると、サンドボックスの中で動かしたウェブアプリは、主たる受け口を通して外から確かめられます。転送先の番号を住所の一部で指定する方式と、通信に付ける目印で指定する方式の二つがあります。後者について手引きは、目印は信頼できる中継の機器だけが付けたり上書きしたりすべきで、利用者側が付けてきた値を信用してはいけないと注意しています。目印を自由に付けられる人は、中で動いている別の受け口に届いてしまうからです。

転送の対応表や上流の中継の設定は、動いている途中でも操作用の窓口から読み書きできるとされています。対応表を変えれば、外から見える範囲が変わります。確認した範囲では、これらの窓口に個別の認証が必要かどうかは書かれていませんでした。全体の認証を有効にしていることが前提になると読めますが、外から見える範囲を変えられる窓口は、誰が触れるかを特に絞る対象です。

外へ出る通信については、ブラウザや道具の通信を上流の中継の機器に通す設定と、中継に通す宛先・通さない宛先の一覧が用意されています。ただし、手引きが扱うのは主に入ってくる通信で、出ていく通信を許可した宛先だけに絞る方法は、確認した範囲では説明されていませんでした。持ち出しの経路を絞りたい場合は、コンテナの外側のネットワークの設定で手当てすることになります。

使いどころ：向いている場面と向かない場面

ここまでの事実を踏まえて、企業にとっての使いどころを整理します。AIO Sandboxが力を発揮するのは、ブラウザとシェルとファイル操作をまたぐ作業を、AIエージェントにまとめて試させたい場面です。道具ごとに別々の環境を用意する手間を省き、作業の様子を遠隔デスクトップで人が見ながら確かめられます。

場面	向き・不向き	理由
AIエージェントの試作と評価	向いている	道具がそろい、作業の様子を画面で確かめられる
公開情報だけを扱うウェブ調査の自動化	向いている	社内の情報を置かずに済み、影響を箱の中に収めやすい
開発者が手元で一人で試す	条件付きで向いている	外から届かない設定と、置く情報の仕分けが前提
社内の複数人で一つの箱を共用する	慎重に	箱の中は一つの部屋で、利用者の間に仕切りがない
顧客情報や契約書を扱う本番の業務	向かない	隔離の範囲と運営元の確認が十分でないまま重要な情報が集まる
外部の利用者に開放するサービスの基盤	向かない	利用者ごとの分け方が手引きで扱われていない

表のとおり、使いどころは「何でも入っている箱を社内の共通基盤にする」ことではなく、公開情報と見本のデータで、AIエージェントの動きを確かめる検証の場から始めるのが現実的です。手引きは複数の利用者で共用する場合の分け方を扱っていないため、共用するなら利用者ごと・作業ごとに箱を分け、使い終わったら消す運用を自社で決める必要があります。

安全性の評価：注意付きとした根拠

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

問題が見つからなかった点から挙げます。ライセンスはApache-2.0で、商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、確認した範囲で、このOSSに関わる脆弱性の番号も見つかりませんでした。リポジトリの直下に、取り込みのときに自動で動く処理を含む設定は見当たりませんでした。スターの伸びにも不自然さはありません。注意を付けた理由は二つです。一つは、運営する組織が2025年3月に作られたばかりで、公開リポジトリが2件と少なく、運営元の情報が乏しいこと。もう一つは、ブラウザ・シェル・ファイル・MCP・コードエディタを一つの箱にまとめる設計のため、隔離の範囲を正しく理解しないまま使うと、守れていると思い込みやすいことです。

加えて、リポジトリには弱点を見つけたときの報告の窓口を定めた文書（セキュリティの方針）が置かれていません。勧告がないことは、弱点がないことを意味しません。問題が見つからなかったことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

運営元の情報が乏しいことをどう扱うか

運営元が分からないOSSを使ってはいけない、ということではありません。ライセンスが明確で、コードが公開されていれば、自社で確かめたうえで使う道はあります。問題は、何かあったときに誰に連絡し、どれだけの速さで直されるかが読めないことです。弱点の報告の窓口が定められていないことも、この読みにくさを強めています。

確かめられる材料はあります。更新は続いており、リリースの記録には安全面の変更も含まれています。READMEは大手の技術報告を参照し、中国本土向けの配布先まで用意しています。大きな組織の関わりをうかがわせる材料ではありますが、関わりをうかがわせることと、運営の責任を負うと明記していることは別です。調達の判断では、推測で埋めずに「確認できなかった」と記録に残すことを勧めます。

実務の手当てとしては、版を固定して使い、更新のたびに変更の記録を読んでから取り込むこと、配布されるコンテナの元になる型を自社で点検してから使うこと、弱点の報告が上がっていないかを定期的に見に行く担当を決めることが挙げられます。運営元の顔が見えない分を、自社の確認の手順で補う考え方です。

隔離の範囲をどう理解するか

サンドボックスという名前から、外とは完全に切り離されていると受け取りがちです。しかし、AIO Sandboxの隔離はコンテナの仕組みに頼っています。コンテナは、同じ機械の上で動く他のものと土台の部分を共有するため、仮想の機械を丸ごと分ける方式より、仕切りは薄くなりやすいと一般に言われます。

さらに、READMEの起動の例には、コンテナが使える低い階層の命令を絞る既定の安全装置（システムコールの制限）を外す指定が含まれています。READMEはその理由や影響を説明していません。ブラウザを動かすために必要とされることが多い指定だと推測されますが、確認はできていません。いずれにしても、例のとおりに動かすと、コンテナの既定の守りの一部が外れた状態になることは、利用する側が理解しておくべき点です。

運用の手引きも、サンドボックスが元の機械や他の仕事から何を切り離すのかは説明していません。したがって、このOSSを「切り離しの仕組み」として当てにするのではなく、道具をまとめる作業場として使い、切り離しは外側で用意すると整理するのが安全です。たとえば、専用の仮想の機械の中で動かす、社内のネットワークから届かない区画に置く、といった外側の手当てです。

悪用されうるリスク

AIO Sandboxは攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、認証を設定しないまま、他の機械から届く場所に置かれることです。READMEが明記しているとおり、その状態では各機能が開いたまま動きます。遠隔デスクトップ、コードエディタ、命令の実行の窓口に、誰でも届く可能性があります。

次に挙げるのは推測ですが、検討の材料として無視できません。AIエージェントがブラウザで読んだウェブページに命令が紛れ込んでいた場合（プロンプトインジェクションと呼ばれる攻撃）、エージェントがその命令に従ってシェルやファイル操作の道具を使う筋書きが考えられます。ファイルの置き場を共有しているため、箱の中に置いた鍵や資料は、こうした誘導の先で読まれうる対象になります。箱の中に置いたものは、持ち出されうるものとして扱うのが前提です。

もう一つ、転送の機能や上流の中継の設定を操作できる窓口が、外から見える範囲を変える入口になりうる点です。前段の中継で目印を上書きしていない構成では、意図しない受け口に届く可能性があります。なお、AIO Sandboxが実際に悪用された事例は、2026年10月26日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、「全部入り」の便利さを受け取る前に、箱の壁と出入り口を自社で決めておくことです。道具がそろった箱は、入れた瞬間からすぐ使えます。だからこそ、使い始める前の決めごとが後回しになりやすいのです。

企業が取るべき対策

一つ目は、AIエージェントを動かす場所の決まりを作ることです。手元の端末、社内の機器、切り離した作業場のどれを、どの作業に当てるかを決めます。AIO Sandboxのような作業場は、その中の検証用の選択肢として位置づけます。二つ目は、置く情報の仕分けです。箱の中は一つの部屋だという前提で、個人情報や契約に関わる情報、長く使える鍵を置かない決まりにします。

三つ目は、公開の点検です。社内のどこかでこうした作業場が動いていないか、認証のないまま他の機械から届く状態になっていないかを、定期的に確かめます。開発者が手元で試したものが、そのまま共用の機械に移されることはよくあります。遠隔デスクトップやコードエディタの画面が認証なしで開く機械がないかを、点検の項目に入れておくと拾いやすくなります。

四つ目は、記録の設計です。手引きはコンテナの記録、中継の記録、稼働状況を見張るよう求めています。どの記録をどこに残し、誰が見るかを決めます。五つ目は、調達のときの確認です。運営元、弱点の報告の窓口、更新の頻度を文書で確かめ、確認できなかった点は判断の記録に残します。

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

AIO Sandboxは、AIエージェントにブラウザやシェルといった実際の道具を渡すための作業場です。渡す道具が多いほど、AIにできることは広がり、何が起きたかを人が追いにくくなります。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、箱の中に置いてよい情報、外へ出てよい宛先、渡す鍵とその期間、作業場を外から届く場所に置くかどうか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。AIに作業を任せる場合も、何をしたのか、なぜその操作を選んだのかの根拠を書かせ、結果を人が確認する範囲を先に決めておきます。やってはいけない向き合い方を挙げます。

• 「サンドボックスだから」を理由に、箱の中に置く情報の仕分けをしない
• 認証の鍵を設定しないまま、共用の機械や社内のネットワークから届く場所で動かす
• 使わないコードエディタやJupyterを止めず、すべての機能を開けたままにする
• 外へ出る通信を絞らず、AIエージェントがどこへでもつなげる状態にする
• AIエージェントの操作の根拠を残させず、結果を誰も確かめない
• 運営元について確認できなかったことを記録せず、推測のまま導入を決める

裏を返せば、人が決める範囲ははっきりしています。何を置かないか、どこへつなぐか、誰の鍵を渡すか、誰が記録を見るか。この四つが決まっていないまま全部入りの作業場を入れても、守りの厚みは増えません。

よくある質問：箱に入れればAIエージェントを自由に動かしてよいのか

答えは「それだけでは足りない」です。AIO Sandboxの箱は、道具をまとめて使いやすくするためのものです。中に置いた情報が外へ出る経路をふさぐ仕組みでも、元の機械から完全に切り離す仕組みでもありません。隔離の強さは、箱の外側にどんな仕切りを用意したかで決まるという点が抜け落ちやすいところです。

では使う意味がないのかというと、そうではありません。AIエージェントに社員の端末を直接触らせずに、道具のそろった場で動きを確かめられることには、検証の段階で大きな価値があります。作業の様子を遠隔デスクトップで人が見られる点も、AIの振る舞いを理解する助けになります。もう一つ、「同じ種類の他の道具とどちらが安全か」という問いもありそうです。確認した範囲では、一次情報で比べられる説明は見つけられませんでした。仮想の機械で切り離す道具と比べるなら、仕切りの方式と、自社が外側でどこまで補うかを並べて判断することになります。

• AIO Sandboxの機能・版・認証・公開の手引きは、GitHubのリポジトリ、README、リリースの一覧、公式サイトの手引きを2026年10月26日に確かめた範囲に基づきます。内容は変わる可能性があります
• 運営組織とByteDanceの関係、論文で説明された基盤との同一性、既定の安全装置を外す指定が必要な理由は、確認した一次情報の範囲では確かめられませんでした
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

AIO Sandboxは、ブラウザ・シェル・ファイル操作・コードエディタ・MCPなどを一つのコンテナにまとめ、AIエージェントの作業場として提供するOSSです。道具どうしがファイルを共有するため、複数の道具をまたぐ作業をなめらかに試せます。Apache-2.0で公開され、GitHub上にセキュリティ勧告は登録されていません。一方で、運営組織は新しく公開情報が少なく、弱点の報告の窓口も定められていないため、判定は「注意付き」としました。

使いどころは、公開情報と見本のデータでAIエージェントの動きを確かめる検証の場です。認証は既定では有効でなく、箱の中は一つの部屋で、仕切りの厚さはコンテナと外側の設計しだいです。置く情報、外への経路、渡す鍵、記録を見る人を先に決め、切り離しは外側で用意する。この順序を守ったうえで使うことが、全部入りの作業場と付き合うときの基本です。

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