サンドボックスの課題は分離だけでは解決しない

2か月前にAI推論プラットフォームGMI CloudのAgentBox v1を開発・リリースした際、私たちは人が操作することを前提に設計していました。ユーザーが環境を作成し、準備が整うのを待ち、その環境に入り、作業を行うという流れです。

AgentBox v2では、これとは異なる利用者を想定しています。APIを通じてマシンを操作するAIエージェントです。各ワークロードは、それぞれ独自のゲストカーネルを持つmicroVM内で実行されるようになりました。より強固な分離はその第一歩ですが、自律型AIエージェントには、信頼できるライフサイクル状態、明確な実行結果、そして同じ処理を誤って二重実行しないリトライの仕組みも必要です。これこそが、AgentBox v2で解決しようとしている、サンドボックスにおけるより難しい課題です。

操作者がAIエージェントになると、何が変わるのか

v1では、2つの問題からその違いが明確になりました。

1つ目は、環境を作成して利用可能になるまでに、9つのオーケストレーション境界をまたいでいたことです。この実行パスはインタラクティブなワークフローを前提に設計されており、API経由で多数の処理を連携させるAIエージェント向けではありませんでした。

2つ目は、リトライによって処理の重複が見えにくくなる可能性があったことです。あるリトライでは、同じコマンドIDに対して同じ実行IDが3回返され、一見すると1回だけ実行されたように見えていました。しかし実際には、そのコマンドは3回実行されていました。

人であれば、出力の重複に気づくかもしれません。しかし無人で動作するAIエージェントは、同じファイルを再度書き込んだり、同じデプロイを再実行したり、簡単には取り消せない処理を繰り返した後でも、コマンドが1回しか実行されていないものとして処理を続ける可能性があります。

この2つの問題から導き出された結論は同じでした。AIエージェント向けサンドボックスに必要なのは、安全にコードを実行できる場所だけではありません。自律型AIエージェントのために設計されたマシン境界とAPIコントラクトが必要です。AgentBox v2では、まさにそこを再構築しました。

各ランタイムに独立したカーネルを提供

v2では、すべてのワークロードが独自のゲストカーネルを持つmicroVM内で実行されます。ワークロードから見ると、マシンは次のような構成になります。

┌──────────────────────────────────────────────┐

│ ワークロード                                     │

│ イメージ、起動コマンド、ファイル、サービス、    │

│ コマンド                                 │

├──────────────────────────────────────────────┤

│ ゲストカーネル                                │

│ このランタイムのプロセス、ファイルシステム、        │

│ ネットワークスタック                            │

├──────────────────────────────────────────────┤

│ 仮想マシンモニター                     │

│ マシンの起動、分離、破棄    │

├──────────────────────────────────────────────┤

│ ホスト                                         │

│ 物理コンピューティング、ストレージ、ネットワーク    │

└──────────────────────────────────────────────┘

ワークロードは独自のゲストカーネルとやり取りします。ハードウェア支援仮想化により、そのゲスト環境をホストや他のランタイムから分離します。

これにより、信頼できないコードやAIエージェントが生成したコードを実行する際に、各ワークロードにマシンレベルの境界を提供できます。またAgentBoxでは、それぞれのランタイムを独立したマシンとして作成、監視、一時停止、再開、削除できるようになります。

ただし、microVMによる分離だけでは、AIエージェントが必要とする次のような運用上の疑問には答えられません。

• 「Running」は具体的に何を保証するのか？

• リクエストがタイムアウトしたものの、処理自体はまだ進行中かもしれない場合はどうなるのか？

• コマンドをリトライすると二重実行される可能性はないのか？

• 削除が受理された後、遅れて届いたレスポンスによってランタイムが復活することはないのか？

• 使用量の計測はいつ停止するのか？

• APIコマンドとターミナルセッションには同じIDポリシーが適用されるのか？

こうした保証は、マシンを取り巻くプラットフォームによって提供する必要があります。

ランタイムを支える一貫したコントラクト

v2のすべてのランタイムはmicroVMです。インフラの詳細はAgentBox APIの背後に隠蔽されています。AIエージェントが利用するのは、AgentBoxが各ランタイムに対して提供するID、ライフサイクル、ポリシー、コマンド、ファイル、ログ、使用量に関するコントラクトです。

AIエージェントは、次のループで処理を行います。

認証 → 作成 → Running → アップロード → 実行

     → 結果／ログ → ダウンロード → 削除 → 最終使用量

最初のv2リリースでは、この一連のループをエンドツーエンドでサポートします。その中でも特に重要なのが、次の3つの保証です。

「Running」は「使用可能」を意味する

v2における「Running」は、単に下位レイヤーのインフラ状態を示すものではありません。AgentBox APIが定義する状態です。APIがランタイムを「Running」と報告した場合、そのランタイムはコマンドを受け付けられる状態になっています。マシンが準備完了に見えているにもかかわらず、まだexecを使用できないという別の待機時間はありません。

AIエージェントが「準備完了」と表示されたランタイムを本当に利用できるか確認するために、さらにポーリングを行う必要はありません。

実行結果は機械判読可能

完了したすべてのコマンドは、stdout、stderr、終了コードを返します。人であれば、出力の一行を見て処理が成功したかどうかを判断できる場合があります。しかしAIエージェントには、次のアクションを決定するために利用できる明確な結果が必要です。

最初のv2リリースでは、1回の呼び出しにつき1つの完了済み結果を返します。コマンド出力のストリーミングには、今後のリリースで対応する予定です。

すべてのアクセス経路に同じID境界を適用

組織のIDは、認証済みAPIキーから取得されます。リクエスト内で指定された組織情報がIDとして使用されることはありません。ランタイムでは、個別に認証するSSHサービスを公開せず、長期間有効なSSH認証情報をユーザー側で管理する必要もありません。インタラクティブなターミナルアクセスが有効な場合も、認証済みのAgentBoxコントロールプレーンを通じて確立されます。

これにより、コマンドとターミナルセッションに同じアクセスモデルを適用できます。ランタイムへのすべてのサポート対象アクセス経路について、認証、呼び出し元への紐付け、監査が可能になります。

必要になる前に環境を準備

v1では、作成リクエストを受けてから環境が利用可能になるまで、長いオーケストレーション処理を通過していました。v2では、環境を準備するタイミングそのものを変更しました。

イメージの取得や依存関係の準備は、ビルダーがテンプレートを登録または更新した時点で実行されます。テンプレートを変更するたびにイミュータブルなバージョンが生成され、準備が完了したバージョンはアクティベーション可能になります。公開は1回のアクティベーション操作で完了し、ロールバックする場合は、以前の準備済みバージョンを再度アクティブにします。そのため、AIエージェントがランタイムを要求する時点では、環境の準備はすでに完了しています。ランタイム作成時に、クリティカルパス上で環境を再構築する必要はありません。

今年7月にパブリックネットワーク経由で行った社内テストでは、次の結果となりました。

注目すべきなのは、この2つの差です。APIが応答してからランタイムがコマンドを受け付けられる状態になるまでの差は、約60ミリ秒です。v1では、この間にイメージの取得や依存関係の準備が行われており、数秒単位の時間がかかっていました。

一方、バースト時には依然として性能が低下します。この点についても、数字を丸めずそのままお伝えします。128件のcold createを同時実行したところ、128件すべてが完了し、全体では5.4秒で終了しました。ただし、create-to-Runningのp95は0.26秒から4秒弱まで上昇しました。これはイメージ準備によるものではありません。v2では、その処理を作成パスから完全に切り離しているためです。残っているのはAgentBox独自のオーケストレーションコストであり、その削減が次の課題です。

私たちの目標は、数百のタスクが同時に開始されるAIエージェント環境でも、プラットフォームがボトルネックになることなく、環境作成によるユーザー体感への影響をなくすことです。

これとは別に、パイロット環境では50,000のランタイムを同時に稼働状態で維持しています。これは作成速度ではなく定常状態での同時稼働数であり、この2つの数値を直接比較すべきではありません。

テンプレートはv1からAgentBoxの中核を担っています。ビルダーがテンプレートを公開し、企業が必要に応じてそこからランタイムをプロビジョニングするという製品モデルは変わりません。レジストリ、テンプレート、マーケットプレイス、IAM、課金、コンソールも、新しいランタイムアーキテクチャを取り巻く形で引き続き機能します。新しい実行モデルのメリットを得るために、ビルダーがAgentBoxの使い方を一から覚え直す必要はありません。

コマンドのリトライをより安全に

安定した実行IDだけでは十分ではありません。同じ識別子が返されていても、その裏側でコマンドが複数回実行されていれば、そのIDは重複を防ぐどころか、むしろ隠してしまいます。

v2では、この仕組みを変更しました。呼び出し元が指定するrequest_idをコマンド送信における冪等性の境界としています。AgentBoxコントロールプレーンの一意性制約により、同じrequest_idが実行対象として受理されるのは最大1回です。この保証は、AgentBoxが管理するコマンド送信パス内で適用されます。

コマンドのタイムアウトについても、明確なセマンティクスを定義しています。設定された実行タイムアウトに達すると、AgentBoxはプロセスグループを終了し、それまでに生成された出力を保持したうえで、終了理由とともに結果をtimed_outとして記録します。ランタイム自体は「Running」のまま維持されるため、AIエージェントは結果を確認して次のアクションを判断できます。

この保証の範囲は意図的に限定されています。保証するのは、1つのrequest_idが実行対象として受理されるのは最大1回という点です。任意のコードによって発生するすべての外部副作用までトランザクション化できるわけではありません。コマンドが外部APIを呼び出したり、外部データベースに書き込んだり、デプロイを実行したりする場合、その外部システム側でも独自の冪等性対策が必要です。

サンドボックス自身の挙動は明確に保証すべきですが、ワークロードが接続するすべての外部システムまで制御できるかのように扱うべきではないと、私たちは考えています。

ライフサイクル操作には別のルールを適用

コマンドとライフサイクル変更では、異なるルールが適用されます。Create、Suspend、Resume、Snapshot、Deleteはランタイム自体の状態を変更するため、AgentBoxでは、1つのランタイムに対して同時に実行できるライフサイクル変更を1つに制限しています。一方、コマンドはこのライフサイクルロックの対象ではありません。AIエージェントは、実行中のマシンを利用し続けながら、すべてのコマンドを同じ直列ワークフローに入れる必要はありません。

この違いは、複数の処理が重なったときに特に重要です。たとえば、作成処理がまだ進行中のランタイムに対してAIエージェントが削除を要求し、その後、AgentBoxが削除を受理した後に作成処理の結果が届く場合があります。

v2では、削除の意思は永続的に記録されます。AgentBoxが削除を受理・記録した後は、遅れて到着したCreateやResumeのレスポンスによってランタイムが「Running」に戻ることはありません。ライフサイクルはそのまま削除へと進みます。これにより、ユーザーがすでに削除を要求したランタイムが、遅れて完了したCreateやResumeによって復活することを防ぎます。

Deleteを実行した時点で課金を停止

削除には、関連しながらも異なる2つのタイムスタンプがあります。課金の終了時点とインフラリソース解放の確認時点です。

課金の終了時点は、削除リクエストが受理され、永続的に記録された瞬間です。この受理時刻が使用量計算のカットオフとして使用されます。一方、計測停止イベントは、基盤となるリソースの解放が確認された後にのみ発行されます。イベントの配信が遅延したり再試行されたりした場合でも、イベントには元の削除受理時刻が保持されます。

リソース解放の確認を待っている時間は暫定期間として扱われ、請求対象にはなりません。これは意図的な設計です。インフラが解放される前に成功イベントを発行すると、実際には完了していないクリーンアップを完了済みとして記録してしまいます。一方、リソース解放時点を課金終了時点にすると、プラットフォーム側の遅延によってユーザーに追加料金が発生してしまいます。

そのためAgentBoxでは、リソースの解放が確認されるまでクリーンアップ完了とはせず、同時に、ユーザーの課金終了時点として削除リクエストの受理時刻を保持します。

共有されるもの

各ランタイムに独自のゲストカーネルを割り当てるからといって、プラットフォームのすべてのレイヤーが物理的に専有されるわけではありません。デプロイ環境によっては、物理ホスト、ハイパーバイザー、ストレージシステム、ネットワークインフラ、イメージ配信基盤、AgentBoxコントロールプレーンの一部を、複数のランタイムで共有する場合があります。

分離境界は、各ランタイムに独自のマシン境界、ID、ファイルシステムビュー、ネットワークポリシー、認可されたアクセス経路を提供することで確立されます。v2の開発では、特に複数の処理が重なった場合や処理の途中で障害が発生した場合でも、こうした共有プラットフォームサービス上で、各ランタイムを独立したマシンとして管理できるようにすることに多くの工数を費やしました。

今後提供予定の機能

v2の初回リリースには、コマンド出力のストリーミング、Suspend、Snapshotの3つの機能は含まれません。SuspendとSnapshotは、各ランタイムに安定したHTTPS URLを提供するEndpointsとともに、今後のリリースで提供予定です。Endpointsはデフォルトでプライベートに設定されます。

• Suspend：ランタイムIDとディスクは保持されますが、メモリ、実行中のプロセス、アクティブな接続は保持されません。

• Resume：ランタイムを新たに起動します。その際、ランタイムの起動コマンドが再度実行されます。

  

• Snapshot：ファイルシステムの変更不可（イミュータブル）なコピーです。メモリ、プロセスの状態、アクティブな接続、一時的な認証情報は含まれません。1つのSnapshotから10個のランタイムを作成した場合、それぞれが独立した10個のランタイムとして動作します。

  

既存のビルダーについては、移行が実施されるまで現在のデプロイ環境に変更はありません。Templateは、Runtimeを削除した後も保持されます。また、Terminateは、前述のライフサイクル仕様に基づくDeleteに名称変更され、Open ShellはRun Commandに変更されます。現在、移行スケジュールの最終調整を進めており、既存のデプロイ環境に影響が生じる前に詳細をお知らせします。

分離こそがサンドボックスの出発点

AgentBox v2では、すべてのワークロードに専用のカーネルが割り当てられます。これはアーキテクチャ上の明確な変更ですが、より本質的な変化は、マシンの動作を定義する一貫した契約（Contract）にあります。自律型AIエージェントには、Runningであれば実際に利用可能な状態であること、実行結果に終了コード（exit code）が含まれること、同一のrequest_idを持つリクエストが二重に実行されないこと、そして一度受理された削除処理が、遅れて届いたインフラ側のレスポンスによって取り消されないことが保証される必要があります。

分離は、ワークロードがアクセスできる範囲を制限します。一方で、誰も監視していない環境でもエージェントがサンドボックスを信頼して動作するために重要なのが、明確なライフサイクル、タイムアウト、ID管理、リトライのセマンティクスです。

AgentBox v2は、一般提供（GA）に先駆けてプライベートベータを開始します。自分で作成していないコードを実行する方や、人の監視なしで自律的に動作するAIエージェントを開発している方は、ぜひテストにご協力ください：https://discord.gg/mbYhCJSbF6