AIエージェントに隔離された実行環境を渡すOSS「E2B」とは

「AIエージェントに社内の資料整理を任せたいが、手元の端末でそのまま動かすのは怖い」「生成させたコードを実行させたいが、どこで動かせばよいか決められない」——AIエージェントの社内利用を任された情報システムやセキュリティの担当者から、2026年に入って聞こえることが増えた二つの声です。こうした悩みは、実行の場を切り離す道具を一つ入れれば片づくように見えます。しかし本当に足りていないのは、道具ではありません。AIに実行を任せるときに、何を切り離し、どの権限を渡し、何を記録するかを人が決めていないことです。この記事では、AIエージェントが生成したコードやコマンドを切り離した環境で動かすOSS「E2B」を取り上げ、確かめられる事実と、企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

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

E2Bは、GitHubで公開されているOSSです。READMEの冒頭では「AIが生成したコードを、クラウド上で安全に切り離されたサンドボックス（外と断ち切った実行の場）の中で動かすための、公開された基盤」と説明されています。つまり、AIに文章を作らせるだけでなく、書かせたコードやコマンドを実際に走らせるための土台だという位置づけです。

配布の形を確かめます。リポジトリは e2b-dev という組織のアカウントで2023年3月4日に作られ、ライセンスはApache-2.0です。2026年10月16日時点でスターは1万4,378、派生は1,117、最後の更新は10月14日でした。組織のアカウントは2023年3月30日に作られ、公開しているリポジトリは85件あります。一日あたりのスターの伸びは約10.9件で、作ったばかりのアカウントが急に注目を集めている形ではないと分かります。

ソフトウェアは一つの塊ではありません。開発者が自分のプログラムから呼び出すための部品（SDK）は、JavaScript版とPython版の二つが用意されています。加えて、コードの実行に特化した部品、仮想のデスクトップを操作する部品、コマンドから使う部品が、それぞれ別に公開されています。公式ドキュメントは、これらをまとめてエージェントがコードを実行し、データを処理し、道具を動かすための切り離された場と説明しています。

なぜ今、AIエージェントの実行環境を切り離すのか

AIエージェントに仕事を任せると、生成した文章を返すところで終わりません。ファイルを読んで書き換え、コマンドを走らせ、必要に応じて外のサービスへ問い合わせます。このとき問題になりやすいのは、生成したコードの誤りそのものより、正しく動いた結果として、想定していなかった場所まで手が届くことです。

たとえば、社内の共有フォルダを見に行くつもりの作業が、手元の端末にある別のファイルまで対象にしていたとします。端末でそのまま動かしていれば、影響は端末と、そこからつながる社内の資源に及びます。実行の場を切り離しておけば、同じ作業が起きても影響はその場の中にとどまります。E2BのREADMEが「安全に切り離されたサンドボックス」を前面に出しているのは、この問題意識の表れと読めます。

ただし、切り離せば安全になるわけではありません。何をその中に置くのか、外とどうつなぐのか、動いた結果を誰が確認するのかで、隔離の意味は大きく変わります。隔離は事故の影響を小さくする仕組みであって、事故そのものを無くす仕組みではないと捉えておくのが出発点です。

サンドボックスの中で何ができるのか

公式ドキュメントによると、サンドボックスは要求に応じて作られるLinuxの仮想マシンです。中では、コマンドの実行、ファイルのやり取り、コードの実行、デスクトップの操作ができます。一つの環境が、作業の種類ごとに別々の道具を組み合わせるのではなく、ひとまとまりの場として提供される形になっています。

コードを実行する部品は、渡したコードをその場で走らせ、結果を受け取る作りとされます。仮想デスクトップの部品は、マウスとキーボードの操作、画面の取り込み、アプリケーションの起動、画面の配信を扱うとされています。つまり、文字のやり取りだけでなく、画面を伴う操作まで任せられる設計です。人が画面を見ながら行っている作業を、そのまま置き換えられる範囲が広がります。

サンドボックス側から取得できる情報も、ドキュメントに例として示されています。識別子、使ったテンプレート、付けたメタ情報、開始と終了の予定時刻、状態、割り当てられたCPU数とメモリ量、インターネット接続の可否などです。これらの項目は、後の章で触れる監視と記録の土台になります。実行のまとまりごとに名前と時間が残る形になっている点は、運用を考えるうえで見逃せません。

一時停止と再開、動かし続けられる時間

サンドボックスは動かし続けられる時間に上限があります。公式ドキュメントでは、24時間と1時間という二つの範囲が示されています。上限を超えて長く使いたいときは、一時停止と再開を使います。一時停止すると時間の区切りが戻るため、上限に縛られずに続きを扱えると説明されています。

一時停止の内容が特徴です。止めるときに、ファイルの中身だけでなくメモリの中身も保存されます。保存したサンドボックスは、自ら消すまで保たれるとされています。作業の途中経過まで含めて止め、続きから再開できるという考え方です。同じ状態を作り直す手間を省ける一方で、止めたまま放置すれば、費用と記録が積み上がることも意味します。

動かしている途中で上限の時間を延ばすこともできます。また、上限に達したときに止めるか一時停止するかを、あらかじめ選べるとされています。予定の終了時刻が取れるため、いつ、どれだけの時間、何が動いていたかを後からたどれる形です。ただし、記録が残ることと、その記録を誰かが見ていることは別の話です。

起動する環境を決めるテンプレート

サンドボックスがどんな環境から始まるかは、テンプレートで決めます。あらかじめ必要な道具を入れた状態を用意しておけば、毎回同じ条件で作業を始められます。検証の再現性を保つうえでは、この考え方が助けになります。

2026年10月9日の更新では、保存の方式に「全体」と「ファイルのみ」の二つが加わったと、リリースノートに書かれています。ファイルのみの場合、保存された内容は小さく、保存にかかる時間も短くなり、再開したときはメモリを復元せずディスクから新しく起動する形になるとされます。軽さと再現性のどちらを取るかを、用途ごとに選べるようになった、ということです。

ここで押さえておきたいのは、テンプレートを作るという作業の意味です。自分で環境を組み立てるということは、その中に入れた道具と設定が、そのテンプレートを使うすべての実行に引き継がれるということでもあります。便利さと引き換えに、入れた覚えのない道具まで一緒に配られていないかを、作るときと更新するときに確かめる必要があります。

クラウド版と自社運用の選び分け

READMEが最初に案内するのは、提供元が運営するクラウドのサービスを使う形です。利用の鍵を用意し、部品から呼び出す流れになっています。この場合、実行の場は自社の外にあります。

一方で、自社の環境に置いて動かす道も示されています。別のリポジトリに手順がまとめられ、構成の管理にTerraformを使い、AWS、Google Cloud、Azure、そして一般的なLinuxの機械に対応するとされています。ソフトウェアが公開されていることと、自分たちで運営できることは、この構成でつながっています。

選び分けの観点を整理します。クラウド版は自社で抱える運用の負担が小さい代わりに、実行の場が社外にあります。自社運用は実行の場を管理下に置ける代わりに、構築と更新の負担が自社に来ます。切り離されていることと、自社の管理下にあることは別です。扱うデータの区分と、割ける人員の両方から決める話になります。

似た手段と何が違うのか

実行の場を分ける方法は、E2B以外にもあります。一次情報で確認できた範囲をもとに、代表的なやり方と比べます。いずれも設定を誤れば効果を失う点は同じで、優劣ではなく、任せる作業と守る対象に合わせて選ぶ話です。

見る点	手元の端末で直接	社内のコンテナ	E2Bのサンドボックス
用意のしかた	端末そのものを使う	自社で機器と設定を用意する	呼び出すと作られ、使い終わると消せる
AIが生成したコードの扱い	端末の権限のまま動く	設定した範囲で動く	切り離された仮想マシンの中で動く
使わないときの状態	常に動いている	常に動いている	状態を保ったまま止められる
画面を伴う操作	人が行う	別の仕組みが要る	仮想デスクトップとして任せられる
運用の負担	小さい	大きい	クラウド版は小さい／自社運用は大きい
後から確認できる情報	端末の記録	自社の監視の範囲	識別子・時刻・状態などを取得できる

表のとおり、E2Bの特徴は「必要なときだけ場を作り、状態を保ったまま止められ、画面の操作まで任せられる」点にあります。既存のやり方を置き換えるというより、AIに実行を任せる前提の運用を足すものと読むのが妥当でしょう。

補足します。手元の端末でそのまま動かすやり方は、確認したい小さな作業には向いています。社内のコンテナは、自社の決めた範囲で道具をそろえられます。どのやり方にも言えるのは、切り離した場を作っただけでは、その中に置いたものの危険は減らないという点です。

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

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

根拠にした事実は次のとおりです。運営は組織のアカウントで、2023年3月に作られ、公開しているリポジトリは85件あります。スターの伸びは1日あたり約10.9件で、不自然な水増しの兆候は見られませんでした。GitHub上にこのリポジトリのセキュリティ勧告は登録されておらず、ライセンスはApache-2.0で商用も含めて使えます。リポジトリの直下に、取り込みのときに自動で動く処理を含む設定は見当たりませんでした。

ただし、勧告がないことや自動実行がないことは、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。加えて、本体だけでなく複数の部品が別々に公開されています。導入する部品ごとに同じ確認が要る点も、この基盤の性格として押さえておいてください。

導入前に知っておきたい注意点

第一に、版の動きが速い点です。2026年10月13日の更新で、JavaScript版の実行環境の下限が22.19.0以降、Python版が3.11以降に上がったとリリースノートにあります。以前の環境で動いていたものが動かなくなる可能性があるため、版を固定して検証し、更新の予定を先に決めておく必要があります。

第二に、部品が多い点です。本体、コード実行、デスクトップ、コマンド、環境の定義用の部品が、それぞれ別に版を上げます。10月13日の更新でも、複数の部品がまとめて公開されました。どれを組み合わせて使っているかを把握していないと、更新の影響範囲を追えません。導入時に一覧を作り、更新のたびに更新する運用が要ります。

第三に、既定では提供元が運営するサービスにつながる形である点です。実行するコードや扱うデータが、社外の環境に置かれることになります。契約や社内の取り決めの観点から、事前の確認と承認が必要になります。自社運用にすればこの点は変わりますが、その分の構築と更新の負担が自社に移ります。

第四に、日本語での紹介がまだほとんど見当たらない点です。確認した範囲では、日本語で仕組みや注意点を整理した資料は見つけられませんでした。社内で検討するときは、公式の英語の資料を読める担当者を決めておくか、確認した内容を記録に残す進め方が現実的です。

悪用されうるリスク

E2Bは守りのための基盤で、攻撃に使うための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「切り離してある」という安心が、安全の証明として独り歩きすることです。切り離しは外への影響を抑える仕組みであって、中で起きたことの正しさを保証するものではありません。

次に挙げるのは推測ですが、検討の材料として無視できません。実行の場を切り離しても、その中に社内の鍵や個人情報を置けば、持ち出しの入り口になります。エージェントが外部から受け取った文章に命令を紛れ込ませ、許された操作の範囲内で情報を外へ送る、という筋書きは考えられます。切り離しの強さだけを見て、中に何を置くかの設計を後回しにすると、この経路が残ります。

もう一つ、実行の場を作る権限そのものが新しい入口になる点です。何らかの方法で利用の鍵を得た第三者に、自社の費用で大量の環境を作られたり、社内への足がかりに使われたりする可能性が考えられます。使い終わった場を確実に消す運用と、鍵の管理が前提になります。なお、E2Bが実際に悪用された事例は、2026年10月16日時点で確認した一次情報からは見つけられませんでした。

何を切り離し、どの権限を渡すか

切り離しの効果は、中に何を置き、外とどうつなぐかで決まります。まず、中に置いてよい情報と、置かない情報を分けます。検証であれば、見本のデータや公開されているデータから始めるのが基本です。実データを使う必要があるなら、個人情報や契約に関わる情報をそのまま置かず、必要な項目だけを抜き、人を特定できる値を置き換えたうえで渡す形にします。

次に、外へ出る経路です。取得できる情報の項目にはインターネット接続の可否に関するものがあり、設定できると読めます。確認した範囲では既定値の説明までは見つけられませんでしたが、必要な接続先だけを許す方針が取れるなら、持ち出しの経路を絞れます。逆に、外へ出られる状態のままにしておくと、切り離しの意味は大きく損なわれます。

権限は二種類に分けて考えます。一つは、エージェントに渡す鍵です。作業に必要な最小限にとどめ、読み取りだけで足りる作業に書き込みの権限を与えないようにします。もう一つは、実行の場を作る鍵です。これは環境をいくつ、いつまで作れるかという費用と、濫用の両方に直結します。人に任せず、仕組みで上限を決めておく対象です。

監視と記録をどう設計するか

切り離した場であっても、何が起きたかを後からたどれるようにしておく必要があります。ドキュメントに例として示されている情報のうち、運用で使えるものを整理します。いずれも実行のまとまりごとに取得できるとされている情報です。

記録する対象	何が分かるか	気にすべき兆候
実行の識別子	どの作業がどのまとまりか	身に覚えのない識別子が増えている
開始と終了の予定時刻	いつ、どれだけ動くか	想定より長く動き続けている
状態の変化	作られ、止まり、消された順序	消し忘れが積み上がっている
割り当てた資源	CPU数とメモリ量	想定より大きい資源が確保されている
付けたメタ情報	誰の、何の用事の実行か	持ち主が分からない実行がある
接続の設定	外へ出られる状態だったか	不要なのに外へ出られる設定になっている

表に挙げた情報は、取れるだけでは意味を持ちません。誰が、いつ、何のために作ったのかをメタ情報として必ず付ける決まりにしておくと、後から異常を拾いやすくなります。付け忘れを防ぐには、道具の側で入力を必須にするのが確実です。

記録は作るだけでなく、見る人がいなければ意味を持ちません。費用の点検、消し忘れの点検、想定外の接続の有無の確認を、決めた頻度で行います。そのとき、一次の点検はAIに任せ、人の判断が要るものだけを人に上げる形にすると、人が見る量を現実的な範囲に収められます。

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

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

この手順の要は、動かす前に「何を置かないか」と「誰が見るか」を決めておくことです。切り離す道具は、入れた瞬間から「切り離した」という安心を生みます。その安心が何を意味するのかを先に決めておかないと、置いてはいけない情報が中に残ったまま、確認されない日が続きます。

企業が取るべき対策

一つ目は、社内でAIエージェントを動かす場所を決めることです。手元の端末で動かす、社内の機器の上で動かす、切り離した場で動かす、のどれをどの作業に当てるかを決めます。E2Bのような基盤は、その選択肢の一つとして位置づけます。

二つ目は、鍵の棚卸しです。エージェントに渡している鍵を一覧にし、作業に不要なものを外します。長く使える鍵を一つ渡すのではなく、作業ごとに短く切って渡す考え方に寄せます。三つ目は、外へ出る経路の把握です。切り離した場から社内のシステムへ届く道があるか、外へ出られるかを、実際に確かめます。

四つ目は、記録と消し忘れの点検です。使い終わった場が残っていないか、想定していない時間帯に動いていないかを見る運用を決めます。五つ目は、調達のときの確認です。運営の体制、更新の頻度、弱点の報告への窓口、データの扱いを、導入前に文書で確かめます。自社運用を選ぶ場合は、更新に追いつく人員がいるかどうかも判断の材料になります。

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

E2Bは、AIに実際の道具を使わせるための基盤です。任せる範囲が広がるほど、何が起きたかを人が把握しにくくなります。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、どの情報を中に置いてよいか、どの接続先を許すか、どの鍵を渡すか、実行の場をいくつまで作れるか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。道具に任せてよいのは、決めた範囲の中で作業を速く回す部分です。やってはいけない向き合い方を挙げます。

• 「切り離してあるから」を理由に、中に置く情報の仕分けをしない
• エージェントに渡す鍵を、作業の内容を確かめずに使い回す
• 使い終わった実行の場を消さずに残し、費用も記録も点検しない
• 接続の設定を既定のままにし、外へ出られる状態かどうかを確かめない
• 更新の速い部品を使いながら、使っている版を一覧にしない
• 記録は取っているが、それを見る人と頻度を決めていない

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

よくある質問：切り離した場に入れれば安全なのか

答えは「それだけでは足りない」です。切り離しは、中で起きたことが外へ及ぶのを抑える仕組みです。中に置いた情報が外へ出る経路をふさぐものではありません。中に何を置いたかによって、危険の大きさは変わるという点が抜け落ちやすいところです。

では入れる意味がないのかというと、そうではありません。AIに実行を任せるときに、手元の端末や社内の中核の機器へ直接触れさせずに済むことは、事故が起きたときの影響を確かに小さくします。実行のまとまりごとに識別子と時刻が残るため、後からたどれる形にもなります。

もう一つ、「クラウド版と自社運用のどちらが安全か」という問いもありそうです。確認した範囲では、どちらが安全かを一次情報で比較できる説明は見つけられませんでした。違いは、実行の場が自社の管理下にあるかどうかです。管理下に置ける代わりに、更新と監視の負担は自社に来ます。どちらを選ぶかは、扱うデータと体制から決める話になります。

• E2Bの機能・版・対応環境・運用の考え方は、GitHubのリポジトリとその中の文書、公式ドキュメント、リリースノートを2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• サンドボックスの既定の設定、料金、データの扱いの詳細は、確認した一次情報の範囲では十分に確かめられませんでした。導入の判断では提供元の最新の資料を確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

E2Bは、AIエージェントが生成したコードやコマンドを、切り離されたLinuxの仮想マシンの中で動かすための基盤です。必要なときだけ場を作り、状態を保ったまま止め、画面を伴う操作まで任せられる点が特徴です。Apache-2.0で公開され、運営は組織のアカウントで、GitHub上にセキュリティ勧告は登録されていません。実行の場を社外に置く形と、自社で運営する形の両方が示されています。

一方で、切り離しは安全の同義語ではありません。中に何を置くか、どの接続先を許すか、どの鍵を渡すか、誰が記録を見るかは、道具ではなく人が決める範囲です。部品が分かれ、更新も速いため、使っているものを一覧にして更新に追いつく運用が要ります。この四つを先に決めたうえで使うことが、AIに実行を任せる時代のE2Bとの付き合い方です。

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