Contextual Agentic Vision Platform の実行レイヤを構築する過程で得られた、インフラ面に関する記録である。
Platform をデモから本番運用へと移していく段階で、想定外に荷重を担う部分はモデルではない。実行基盤である。エージェントが発したツール呼び出しが実際に動く場所であり、顧客固有のルールパックや後処理スクリプトがスカウトの出力に対して走る場所であり、個々のアクションの影響範囲が境界づけられる場所である。
我々はその表面の大部分を エフェメラルなクラウドサンドボックス 内で動かす構成に落ち着いた。この選択は Platform の挙動に十分な影響を与えており、その理由と本番運用で得られた知見を書き留めておく価値がある。
実行レイヤがなぜ独自の基盤を必要とするのか
素朴なデプロイメントの形はこうなる。エージェントがツール呼び出しを発し、長期稼働するバックエンドプロセスがそれを受け取り、必要なコードを実行し、結果を返す。これは次のいずれかが成立するまでは動作する。
- ツール呼び出しが顧客提供のコードやクエリを呼び出す場合。 顧客のアセットインテグリティ規程に基づくルール、欠陥分類ロジック、レポートテンプレートは、我々の論理境界ではなく 顧客自身の 論理境界の内側で動作する必要がある。Platform の用語で言えば、これは顧客の内部コンテキスト層が意思決定時に行使されているということだ。
- ツール呼び出しがエージェントの推論ステップから来ており、半信頼の性質を持つ場合。 どれほど厳密にプロンプトを設計しても、モデルが生成したコードやシェルコマンドは、共有プロセスで実行されれば意図しない副作用を持ちうる。
- テナントごとに異なるランタイム環境が必要な場合。 ある顧客は古い Python や特定の CUDA バージョンに固定し、別の顧客は厳格な外向き通信（egress）制御を求める。
- ワークロードがキャンセル可能、時間制限付き、リソース隔離されている必要がある場合。 一つの遅いツール呼び出しが Platform の残りを枯渇させてはならない。
四つのケースに共通する前提は同じである。長期稼働バックエンドの プロセス境界 は、エージェントが起動する作業の隔離単位として適していない。適切な単位は、使い捨ての新規マシンに近いものである。
ここで言う「サンドボックス」とは何か
クラウドサンドボックス とは、オーケストレータがプログラム経由で起動・タスク委譲・破棄を行える、時間制限付きのランタイムを指す（典型的には microVM、あるいは堅牢化されたコンテナ）。我々の用途における中核的性質は以下の通り。
- 呼び出しごとのプロビジョニング。 作業が到着した時点でサンドボックスを割り当て、作業完了時に解放する。デフォルトで永続状態は存在しない。
- 厳格なネットワーク egress 制御。 サンドボックスは outbound 通信なしで起動する。必要に応じてオーケストレータが特定ツール向けに特定の egress 経路を開く。
- 境界づけられた影響範囲。 サンドボックス内で動作するものは、外部に影響を与えない。オーケストレータは協調動作なしに任意のタイミングでこれを終了できる。
- SDK 駆動の制御。 オーケストレータは、エージェントがツールと対話するのと同じ要領でサンドボックスと対話する。ssh やシェル呼び出しではなく、型付きインターフェース経由である。
このパターンは E2B [1] による本番形態、および Firecracker [2] に代表される短命ワークロード向け軽量 VM に関する文献群に記述されている。エンドユーザー保護向けに発展してきたブラウザ隔離システム [3] も、異なる脅威面に対して同じアーキテクチャ的発想を適用している。
サンドボックス内部で動かすもの
我々の Platform では、サンドボックスは三種類の作業の住処となっている。
1. 顧客固有の評価ロジック。 特定の業界規格に基づく腐食グレード判定スケジュールや、特定の図面に由来する幾何公差といった顧客のドメインルールは、スクリプトやルールパックとして符号化され、Platform の共有コードでは実行したくない。各顧客のルールパックは、呼び出しごとのサンドボックス内で実行され、関連するコンテキストパックの該当範囲が読み取り専用でマウントされる。
2. コード実行を伴うエージェント発のツール呼び出し。 エージェントが派生計測値を算出する必要があると判断した場合（例：「この深さ値を図面で指定された公差と比較せよ」）、その計算は小さなプログラムとしてレンダリングされ、サンドボックス内で実行される。当該プログラムはネットワークアクセスを持たず、関連するスカウト出力およびコンテキストレコードへの読み取り専用アクセスのみを持ち、型付きの結果を返す。
3. ワークロード固有の推論環境。 モデルバージョンを固定する顧客、非標準ランタイムを必要とする顧客、規制対象のデータ取扱要件を持つ顧客には、それらの制約に合わせたサンドボックスイメージを提供する。スケジューリング自体は、他のすべてをスケジュールしているオーケストレータと同一のものが担当する。
いずれの場合も、オーケストレータ自体はコードを実行しない。タスクを構成し、イメージを選択し、サンドボックスをプロビジョニングし、タスクを引き渡し、型付き結果を待つ。これはエージェントがリモートツールを呼び出す形と同形であり、この対称性こそが、このパターンが成立する理由である。
デフォルトはエフェメラル、永続化は意図的にのみ
サンドボックスプラットフォームは一般にエフェメラルモードと永続モードの双方をサポートする。我々は次の三つの理由から 呼び出しごとにエフェメラル をデフォルトとしている。
- セッション間のリークが支配的リスクであるため。 永続サンドボックスは、次の呼び出しが意図せず継承しうる状態を蓄積する。一時ファイル、キャッシュされた認証情報、書きかけのログなどである。エフェメラルなプロビジョニングであればデフォルトは空であり、引き継がれる状態があるとすればそれは耐久ストレージへ明示的に書き出されたものに限られる。
- 再現性が無償で得られる。 既知のイメージから起動されたサンドボックスは、構成上、再現可能である。我々はこれに依拠して Platform の出力に監査性を持たせている。すなわち、ある意思決定を生んだランタイムは、イメージハッシュと入力レコードから再構築できる。
- 典型的なワークロード形状ではコスト按分が有利に働く。 プロビジョニングのレイテンシは無視できない（数十～数百ミリ秒）が、これは 呼び出し ごとに一度だけ支払われるコストであり、呼び出し 内のツール呼び出し ごとに支払うものではない。エージェントの推論ループ自体は長期稼働プロセスで動き、個別のコード実行単位のみがサンドボックスに落ちる。
永続サンドボックスにも用途はある（長時間稼働するデータ前処理ジョブ、Platform 自身のエンジニアリング用途における対話的ノートブックなど）が、これはデフォルトではなく例外として扱う。
これを成立させるオーケストレーション層
サンドボックスは単体では役に立たない。周囲の三つの要素が運用上の重みの大部分を担っている。
タスクルーター は、所与のタスクに対してどのサンドボックスイメージを実行するかを決定し、テナンシールールを適用し、時間・メモリ・egress の上限を課す。顧客固有のポリシー（ネットワーク許可リスト、データ所在地制約、GPU クォータ）が具体的なサンドボックスパラメータとして結実するのはこの場所である。
型付き IO 契約 がオーケストレータとサンドボックス内タスクの間に位置する。入力は型付きレコードとしてシリアライズされ、出力はスキーマに対して検証されたうえで Platform の残りの部分に戻ることが許される。サンドボックスがオーケストレータの信頼境界に自由形式テキストを返すことはできない。
実行トレースストア は、何が、どのイメージで、どの入力に対して、どの出力を伴って動作したかを記録する。これがエフェメラルな実行を監査可能な実行へと転換させる仕組みである。サンドボックス内部には何も保持しないが、各実行の完全な記録はその外側に保持する。
この組合せ（サンドボックス + ルーター + 型付き IO + トレース）こそが、我々が「実行基盤」と呼ぶ実体である。
Platform レベルで何が可能になるか
サンドボックスを第一級の構成要素として扱うことで、Platform 層で実現可能な事項が変わる。
- 顧客は我々のリリースを介さずにロジックを Platform に投入できる。 新しいドメインルールパックは、新規サンドボックスイメージと設定エントリの追加であり、コアオーケストレータのコード変更ではない。
- エージェントはコードを書ける。 エージェントが発するものはネットワークを持たず、Platform 内部にアクセスできないサンドボックス内で実行されるため、「エージェントが破壊的コマンドを生成した」という故障モードは、当該サンドボックスのライフタイムとリソースに境界づけられる。
- 監査性が構造として備わる。 Platform が発するすべての意思決定は、入力・出力・イメージハッシュを保持されたサンドボックス実行の連鎖と結び付けられる。監査の物語は「モデルが何を言ったかを記録した」ではなく、「測定値を生んだ正確なコードはこれであり、それを実行したイメージはこれである」となる。
- テナンシーが構成上担保される。 ある顧客のデータが別の顧客のサンドボックスに入らないのは、ポリシーによってではなく、構成によってである。
未解決の課題
実行基盤は解決済みではない。
- コールドスタートのレイテンシ は、サブ秒の対話型ワークロードでは依然として支配的である。イメージの事前ウォーミングやプール化されたサンドボックスで回避しているが、いずれも無償ではない。
- GPU サンドボックス化 は CPU サンドボックス化と比べ、明らかに難度が高い。GPU の分割と隔離の成熟度は改善しつつあるが、運用面の状況は CPU 相当よりも荒い。
- サンドボックス内部の可観測性 は、設計時から織り込む必要がある。デフォルトのサンドボックスは不透明であり、その内部を Platform オペレータに見えるようにしつつ、隔離特性を損なわずに済ませるには注意を要する。
これらは部分的な解を持つ問題群であり、解決済みとは見なしていない。
References
- E2B. Open-source infrastructure for AI-generated code in secure isolated cloud sandboxes. e2b.dev
- Agache, A. et al., Firecracker: Lightweight Virtualization for Serverless Applications. NSDI 2020. usenix.org/conference/nsdi20/presentation/agache
- Cloudflare. What is browser isolation? cloudflare.com