【ITニュース解説】E2B sandboxes: pricing, lifecycle and alternatives

システムエンジニアを目指す初心者の皆さん、今回は、ソフトウェア開発で注目されている「サンドボックス」という技術について、特にAIエージェントがコードを実行する環境としての役割と、その選び方、そして利用上の注意点について解説する。

まず「サンドボックス」とは何か。これは、プログラムを実行するための、外部から隔離された仮想的な環境のことだ。他のシステムに影響を与えたり、壊したりする心配なく、安全にコードを実行できる場所と考えると分かりやすいだろう。特に、AIエージェントが自律的にプログラムを生成し、実行しようとする際、実行する場所がなければ意味がない。サンドボックスは、そのようなエージェントに対して、安全にコードを実行し、ファイル操作を行うためのリモート環境を提供する。

このサンドボックス環境では、「コーディネーター」と呼ばれるアプリケーションが、エージェントが生成したコードやコマンドをサンドボックスに送り込み、その実行結果や作成されたファイルを受け取る。そして、その結果に基づいて、次に何をすべきかを判断する。もしコマンドが失敗したり、セッションが時間切れになったりした場合も、コーディネーターが適切に対応し、後片付けを行う必要がある。サンドボックスは高い隔離性を提供してくれるが、機密性の高い認証情報や外部システム、プライベートデータへのアクセスが必要な場合は、別途厳格なセキュリティポリシーを設けることが重要だ。例えば、E2BというプロバイダーのSDKを使えば、コードの実行やファイルアクセスを簡単に行うことができる。最初は小さなタスクで試し、出力やエラーをよく確認してから、より大きなエージェントの処理ループに組み込むのが賢明だ。

次に、サンドボックスのプロバイダーを選ぶ際のポイントを説明する。単に料金の安さだけで選ぶのは危険で、いくつかの重要な要素を比較検討する必要がある。具体的には、「実行APIの使いやすさ」、「セッションの寿命（どれくらいの時間サンドボックスを使い続けられるか）」、「同時実行性（同時にいくつのサンドボックスを動かせるか）」、「ネットワーク制御（外部との通信をどのように管理できるか）」、「保持される状態（サンドボックス停止後もデータが残るか）」、そして「全体のコスト」だ。CPU料金が安いだけでは、エージェントがタスクを確実に完了できるかどうかは判断できない。

例えば、E2Bというプロバイダーの料金体系を見てみよう。E2Bには「Hobby」という無料プランがあり、1回限りの100ドルのクレジットが付与され、セッションは最大1時間、同時に20個のサンドボックスを動かせる。一方、「Pro」プランは月額150ドルの基本料金に加え、使用量に応じた料金がかかり、セッションは最大24時間、同時実行数もHobbyより多く設定されている。重要なのは、月額のプラン料金と実際にコードを実行した時間にかかる「ランタイム料金」が別だという点だ。仮に、合計で1,000時間の実行時間、2つの仮想CPU、4ギガバイトのメモリを使った場合のランタイム料金を計算すると、CPU代が約100.80ドル、メモリ代が約64.80ドルで、合計約165.60ドルとなる。これにProプランの基本料金150ドルを加えると、税抜きで合計315.60ドルになる。これはあくまで計算例であり、実際の利用では試用クレジットや税金、追加の同時実行枠、その他の使用料は含まれていない。

この同じ計算例を、別のプロバイダーであるLizardで見てみよう。Lizardの場合、同じワークロードでのCPU代が約50.0256ドル、メモリ代が約50.0256ドルで、合計約100.05ドルとなる。Lizardには月額の基本料金がないため、この例ではLizardの方がE2Bより計算上のコンピューティングコストは低い。ただし、どちらのプロバイダーも追加のストレージ費用やネットワークトラフィック料金、その他のサービス費用は含まれていない点に注意が必要だ。Hobbyプランで要件が満たせるなら、E2BのProプランの基本料金を考慮する必要はない。

プロバイダーを選ぶ際には、料金だけでなく「契約内容」もよく比較する必要がある。E2Bであればコード実行、テンプレート、セッションプラン、Daytonaであればサンドボックスのライフサイクルやリソース課金、ModalであればサンドボックスのリソースとModal全体との連携、LizardであればSDK、プロジェクトスコープのサンドボックス、一時停止時の動作といった点を詳しく見ていくことになる。「一時停止（pause）」という言葉一つとっても、そのプロバイダーがどのようなストレージ保証をしているかは異なるため、注意が必要だ。

例えば、Lizardのサンドボックスにおける「一時停止」機能は、仮想CPUの動作を停止させ、メモリや実行中のプロセスをホストのRAM（一時記憶装置）に保持する。しかし、マシン全体のディスクスナップショットを作成するわけではない。そのため、サンドボックスを動かしている物理ホストに障害が発生した場合、一時停止中に保持されていた状態が失われる可能性がある。また、一時停止中でもサンドボックスの寿命はカウントされ続ける。Lizard SDKのドキュメントによれば、デフォルトで5分間のタイムアウトが設定されており、この期限切れを解除するには別途設定が必要だ。重要な出力データはサンドボックスの外に保存し、タスクの期間に合わせて適切な寿命を設定することが大切である。「再開するとすべてが瞬時に保存されている」といった謳い文句を安易に信用せず、プロセスが失敗するケース、セッションが期限切れになるケース、ホストが利用不能になるケースなど、実際の様々な障害状況を個別にテストして確認すべきだ。

サンドボックスの利用方法を具体的にイメージしてもらうため、Lizard SDKの簡単な利用例を挙げる。Node.jsプロジェクトでSDKをインストールし、環境変数にAPIキーを設定する。そして、client.createでサンドボックスを作成し、sandbox.process.execでコマンドを実行、最後にsandbox.killでサンドボックスを終了するという流れだ。これはAPIの使い方とクリーンアップの基本的なパターンを示すもので、性能を測定するものではない。本番環境で使うコードでは、クリーンアップ要求が失敗した場合の処理や、終了前に必要な出力を確実に保存する仕組みも考慮する必要がある。

最後に、サンドボックスを使う上で最も重要なのは「ワークフロー全体のテスト」である。単に最初のコマンドが成功したかどうかだけでなく、エージェントが遭遇する可能性のあるあらゆる状況を想定してテストすべきだ。候補となる各プロバイダーで、同じタスク、同じ依存関係を使って、利用可能な環境になるまでの時間、コマンドの実行時間、発生した障害、リソースの消費量、そして最終的に保持される出力などを詳細に記録する。イメージの準備にかかる時間とセッションの起動にかかる時間を分けて測定すれば、同じ段階での比較ができる。さらに、コマンドが失敗した場合、プロセスがハングした場合、複数のセッションが同時に実行された場合、大量の出力が生成された場合、セッションが期限切れになった場合など、エージェントが遭遇しうる様々なシナリオをテストする。そして、コーディネーターが安全にリトライするために十分な情報を記録しているかどうかも確認することが不可欠だ。最終的にそれが本番アプリケーションとして運用されるのであれば、通常のリリースプロセスを通じてサービスとしてデプロイすべきである。サンドボックスのURLやテストが成功したという事実だけでは、デプロイ設定、監視、そしてデータの永続性といった本番運用に必要な要件を満たす代わりにはならない。