エージェントがサンドボックスを接続する2つのパターン

Witan LabsのNuno Campos氏、E2BのTomas Beran氏とMikayel Harutyunyan氏、RunloopのJonathan Wall氏、Zo ComputerのBen Guo氏に、レビューとコメントをいただき感謝します。 ますます多くのエージェントがワークスペースを必要としています。ワークスペースとは、コードを実行し、パッケージをインストールし、ファイルにアクセスできるコンピュータのことです。サンドボックスはこれを提供します。 エージェントとサンドボックスを統合するためのアーキテクチャパターンには2つあります: パターン1（エージェントINサンドボックス）: エージェントはサンドボックス内で実行され、ネットワークを介して通信します。利点: ローカル開発を模倣し、エージェントと環境の緊密な結合が可能です。 パターン2（ツールとしてのサンドボックス）: エージェントはローカルまたは自社サーバーで実行され、実行のためにサンドボックスをリモートで呼び出します。利点: エージェントロジックの更新が容易、APIキーはサンドボックスの外に保持、関心の分離が明確です。 deepagentsはシンプルな設定で両方のパターンをサポートします ますます多くのエージェントがワークスペースを必要としています。ワークスペースとは、コードを実行し、パッケージをインストールし、ファイルにアクセスできるコンピュータのことです。そのワークスペースは、エージェントがあなたの認証情報、ファイル、ネットワークにアクセスできないように分離されている必要があります。サンドボックスは、エージェントの環境とホストシステムの間に境界を作ることで、この分離を提供します。これらのエージェントを構築するチームが直面する問題は、サンドボックスを使うかどうかではなく、エージェントアーキテクチャとどう統合するかです。 エージェントが実行される場所に基づいて、2つの一般的なパターンがあります: サンドボックス内か、その外かです。各パターンには異なる利点とトレードオフがあります。 注: この記事では、エージェントに完全な「コンピュータ」を提供するサンドボックス、つまりDockerコンテナやVMのような完全な実行環境に焦点を当てます。プロセスレベルのサンドボックス（bubblewrapなど）や言語レベルのサンドボックス（Pyodideなど）は扱いません。 パターン1: エージェントはサンドボックス内で実行 このパターンでは、エージェントはサンドボックス内で実行されます。あなたはネットワークを介してそれと通信します。 実際の様子: エージェントフレームワークがプリインストールされたDockerまたはVMイメージを構築し、サンドボックス内で実行し、外から接続してメッセージを送信します。エージェントはAPIエンドポイント（通常はHTTPまたはWebSocket）を公開し、あなたのアプリケーションはサンドボックスの境界を越えてそれと通信します。 このパターンはローカル開発に非常に近い形を模倣します。例えば、deepagentsを実行する場合、 サンドボックスの境界を越えた通信にはインフラストラクチャが必要です。一部のプロバイダーはこれをSDKで処理します。例えば、OpenCodeのようなエージェントはサンドボックス内でサーバーを実行し、E2BのようなプロバイダーはこれをクリーンなAPIを通じて公開できます。もしプロバイダーがこれを提供していない場合、セッション管理やエラーハンドリングを含むWebSocketまたはHTTPレイヤーを自分で構築する必要があります。 APIキーは、エージェントが推論呼び出しを行うために、サンドボックス内に存在しなければなりません。これは、分離技術の脆弱性を通じてであれ、認証情報を流出させるプロンプトインジェクション攻撃を通じてであれ、サンドボックスが侵害された場合に潜在的なセキュリティリスクを生み出します。注: E2BやRunloopのようなプロバイダーがシークレットボールト機能に取り組んでいるのを見ています。これはこの問題に対処するものです。 更新にはコンテナイメージの再構築と再デプロイが必要であり、開発中のイテレーションサイクルを遅くする可能性があります。 もう一つの欠点は、エージェントがアクティブになる前にサンドボックスを再開する必要があることで、これはしばしば追加のロジックを必要とします。 エージェントのIPを保護することに関心がある人にとっては、エージェントがサンドボックス内で実行されている場合、エージェントのコードとプロンプト全体を流出させることがはるかに簡単になります。 Witan LabsのNuno Campos氏は、別のセキュリティリスクも指摘しています:「エージェントインサンドボックスのもう一つの欠点は、事実上、あなたのエージェントのどの部分も、bashツールよりも多くの権限を持つことができないということだと思います。例えば、bashツールとWeb検索やWebフェッチができるツールを持つエージェントを想像してみてください。すると、LLMが生成するコードはすべて無制限のWebフェッチを行うことができます（これは大きなセキュリティリスクです）。もしツールとしてのサンドボックスであれば、セキュリティ境界がエージェント全体ではなくbashツールの周りにあるので、LLM生成コードに与える権限よりも多くの権限を持つツールを簡単に持つことができます（これは多くのエージェントにとって非常に有用に聞こえます）。」 パターン2: ツールとしてのサンドボックス このパターンでは、エージェントはあなたのマシンまたはサーバー上で実行されます。コードを実行する必要があるとき、APIを介してリモートのサンドボックスを呼び出します。 実際の様子: あなたのエージェントはローカル（または自社サーバー）で実行され、実行が必要なコードを生成すると、サンドボックスプロバイダーのAPI（E2B、Modal、Daytona、Runloopなど）を呼び出します。プロバイダーのSDKがすべての通信の詳細を処理します。あなたのエージェントの視点からは、サンドボックスは単なるもう一つのツールです。 コンテナイメージを再構築することなくエージェントコードを即座に更新できるため、開発中のイテレーションが高速化されます。APIキーはサンドボックスの外に留まります。分離されるのは実行だけです。これにより、関心の分離がより明確になります: エージェントの状態（会話履歴、推論チェーン、メモリ）はエージェントが実行される場所に存在し、サンドボックスとは分離されています。これは、サンドボックスの障害がエージェントの状態を失わないことを意味し、エージェントのコアロジックに影響を与えずにサンドボックスのバックエンドを切り替えることができます。 E2BのTomas Beran氏が指摘する、このオプションの他の2つの利点: 複数のリモートサンドボックスで並行してタスクを実行するオプションがあること プロセス全体の実行時間ではなく、コードを実行している間だけサンドボックスの料金を支払うこと Ben Guo氏は、エージェントのランタイムとサンドボックスのランタイムを分離することの利点について最後のポイントを追加しています:「私たちがパターン2を選んだ理由は、あなたが言及した理由のためですが、また、エージェントハーネスをGPUマシンで実行することが理にかなう未来に備えてでもあります。一般的に、永続的なサンドボックスと推論ハーネスの間では環境要件が分岐するように感じられます」 ネットワーク遅延が主な欠点です。各実行呼び出しはネットワーク境界を越えます。多くの小さな実行があるワークロードでは、これが累積する可能性があります。 多くのサンドボックスプロバイダーは、同じセッション内の呼び出し間で変数、ファイル、インストールされたパッケージが永続するステートフルなセッションを提供しています。これは、必要なラウンドトリップの回数を減らすことで、遅延に関する懸念の一部を緩和することができます。 パターンの選択 以下の場合にパターン1を選択してください: エージェントと実行環境が緊密に結合している場合（例えば、エージェントが特定のライブラリや複雑な環境状態への永続的なアクセスを必要とする場合） 本番環境をローカル開発に可能な限り近づけたい場合 プロバイダーのSDKが通信レイヤーを処理してくれる場合 以下の場合にパターン2を選択してください: 開発中にエージェントロジックを迅速にイテレーションする必要がある場合 APIキーをサンドボックスの外に保持したい場合 エージェントの状態と実行環境の間のより明確な分離を好む場合 実装例 これらのパターンを具体的にするために、組み込みのサンドボックスサポートを持つオープンソースのエージェントフレームワークであるdeepagentsを使用した例を示します。同様のパターンは他のエージェントフレームワークにも適用できます。 パターン1: エージェントINサンドボックス パターン1では、まずエージェントがプリインストールされたイメージを構築します: FROM python:3.11 RUN pip install deepagents-cli 次に、それをサンドボックス内で実行します。完全な実装には、アプリケーションとサンドボックス内のエージェント間の通信を処理するための追加のインフラストラクチャ（WebSocketまたはHTTPサーバー、セッション管理、エラーハンドリング）が必要です。これはこの記事の範囲を超えていますが、これについてより詳細に掘り下げるフォローアップ記事をいくつか用意する予定です。 パターン2: ツールとしてのサンドボックス from daytona import Daytona from langchain_anthropic import ChatAnthropic from deepagents import create_deep_agent from langchain_daytona import DaytonaSandbox # E2B、Runloop、Modalでも同様に実行可能 sandbox = Daytona().create() backend = DaytonaSandbox(sandbox=sandbox) agent = create_deep_agent( model=ChatAnthropic(model="claude-sonnet-4-20250514"), system_prompt="サンドボックスアクセス権を持つPythonコーディングアシスタントです。", backend=backend, ) result = agent.invoke( { "messages": [ { "role": "user", "content": "小さなPythonスクリプトを実行してください", } ] } ) sandbox.stop() このコードが実行されるときに起こること: エージェントはあなたのマシン上でローカルに計画を立てます 問題を解決するためのPythonコードを生成します Runloop APIを呼び出し、それは

エージェントがサンドボックスを接続する2つのパターン

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト