Ray、Google と共同でネイティブサンドボックス機能を Ray 2.58 に導入

エージェント型強化学習では、モデルが生成したコードを実行する大量の孤立環境を並列で実行する必要があります。現在、Ray を用いてこうしたワークロードを開発しているチームは、ホスト型のサンドボックスプロバイダを利用するか、Ray クラスターとは別に独自のサンドボックスシステムを構築・運用するかのどちらかを選択しています。

Ray 2.58 から、新たな選択肢として「ネイティブなサンドボックス機能」が Ray に組み込まれました。

Google との共同開発により、gVisor を基盤とした実験的なサンドボックスライブラリを公開しました。これを使えば、OCI コンテナイメージから孤立環境を作成し、その中でコマンドを実行したりファイルの送受信を行ったり、ネットワークアクセスを制御できます。さらに、トレーナーやロールアウトワーカー、評価器など他の分散コンポーネントと同じ Ray のプリミティブを使って、これらの環境をスケジューリング・スケーリングすることが可能です。

この統合は 2 つのレベルで設計されています。単に孤立した実行環境が欲しいユーザー向けには、サンドボックスの配置とライフサイクル管理を自動で行う高レベル API を提供します。一方、独自のサンドボックスサービスを開発したいチーム向けには、gVisor 環境を直接作成・管理するための基盤となるランタイムプリミティブも公開しています。これにより、スケジューリングやリソース管理、オートスケーリング、フォールトトレランスといった機能をゼロから実装する必要なく、Ray をカスタムサンドボックスサービスの背後にある分散制御プレーンとして活用できるようになります。

責任の分担はシンプルです。レイ（Ray）がオーケストレーションとスケーリングを担当し、gVisor が隔離を担当します。

サンドボックスは Ray クラスターの一部としてスケジューリングされるため、他のワークロードと同じリソース管理および自動スケーリングシステムに参加します。Google Kubernetes Engine では、このアーキテクチャを数千のノードにまたがって 20 秒で 10 万個のサンドボックスまで拡張しました。

Ray プリミティブとしてのサンドボックスのリンク

Ray は、ポストトレーニングワークロードのオーケストレーションにおける共通ランタイムとなっています。veRL、NeMo-RL、SLIME、MILES、SkyRL といったフレームワークはすでに、分散トレーナーや推論エンジン、ロールアウトワーカー、その他のコンポーネントを調整するために Ray を活用しています。

Ray Sandboxing の設計において重要な目標の一つは、隔離された実行のための別個の抽象化を導入するのではなく、既存の Ray プログラミングモデルに自然に適合させることでした。サンドボックスには、Ray が管理する他のリソースと多くの共通点があります。つまり、マシンへの配置、リソース割り当て、作成と破棄、障害からの回復、周囲のワークロードとのスケーリングが必要です。このため、各高レベルのサンドボックスを Ray Actor として表現することになりました。

Ray のスケジューラは、どのノードでサンドボックスを実行するかを決定し、対応する CPU およびメモリリソースを予約します。サンドボックスのライフサイクル管理は Sandbox Actor が担当し、各ノード上での隔離された実行環境は gVisor が提供します。

その結果、フレームワーク開発者は、既存の Ray API やパターンを活用して、他の処理と同じようにサンドボックス環境を管理できるようになります。例えば：

import ray
from ray.experimental import sandbox

ray.init()
# Create a gVisor sandbox environment and return an actor handle for a proxy actor
sb = sandbox.create(
    cpu=1.0,
    memory="512Mi",
    image="python:3.12-slim"
)
# Execute code inside the sandbox
result = ray.get(sb.exec.remote("python -c 'import sys; print(sys.version)'"))
print(result.stdout)

これにより、OCI 互換イメージから gVisor のサンドボックスを作成し、Ray Actor のハンドルを取得できます。exec への呼び出しは通常の Ray Actor 呼び出しと同様なので、サンドボックスはクラスター内のどこにでも配置可能です。作成された Actor はプロキシとして機能し、実際の操作を gVisor に転送します。

sandbox API では、エージェントワークロードに必要な基本的なライフサイクルが網羅されています：

• OCI コンテナイメージから環境を作成する
• CPU とメモリの制限を設定する
• 環境変数、作業ディレクトリ、ネットワーク構成を指定する
• コマンドを実行する
• ファイルの読み書き、アップロード、ダウンロードを行う
• サンドボックスの状態を確認する
• 環境を終了または削除する

より低レベルなユースケースでは、SandboxRuntime を使用してローカルの gVisor サンドボックスに直接アクセスでき、gVisor に渡す前に OCI 仕様の一部をユーザーが修正することも可能です。以下は、Actor 内部でローカルサンドボックスのプールを構築する際の API 利用例です：

import ray
from ray.experimental.sandbox.runtime import SandboxRuntime

@ray.remote
class SandboxPool:
    def __init__(self, size: int = 3, image: str = "python:3.10-slim"):
        self.runtime = SandboxRuntime()
        self.sandboxes = [
            self.runtime.create(image=image, memory="512Mi")
            for _ in range(size)
        ]

    def run_command(self, index: int, command: str):
        return self.runtime.exec(self.sandboxes[index], command)

    def close(self):
        for sb_id in self.sandboxes:
            self.runtime.delete(sb_id)

# Deploy an actor managing a pool of local sandboxes
pool = SandboxPool.remote(size=3)
result = ray.get(pool.run_command.remote(0, "python3 -c 'print(\"Hello from pool!\")'"))
print(result.stdout)
ray.get(pool.close.remote())

LinkScaling to 100,000 Sandboxes

環境数が膨大に増加した際、Ray へのサンドボックス機能の統合は特に有用となります。

大規模な強化学習（RL）のワークロードでは、ロールアウトが進行するにつれて環境を絶えず作成・破棄しながら、数千もの環境を並行して実行する必要があります。個別のサンドボックスサービスを導入すると、トレーニングシステムと同期してスケールする必要のある、追加のスケジューラと分散制御プレーンが新たに導入されることになります。

Ray Sandboxes を利用すれば、環境の配置は Ray における単なるスケジューリング問題として扱えます。

Google Kubernetes Engine（GKE）上で Ray を実行する際、数千ノードにまたがる 10 万個の gVisor サンドボックスを 20 秒でスケーリングすることに成功しました。

なぜ gVisor を選ぶのか

モデル生成コードを実行するということは、環境内のコードを信頼できないものとして扱うことを意味します。

Ray Sandboxing は、初期のサンドボックスランタイムとして Google のオープンソースアプリケーションカーネルである gVisor を採用しています。gVisor は Linux システムコールインタフェースの大部分をユーザスペースで実装しており、ワークロードとホストカーネルの間に追加の隔離境界を設けます。

OCI 互換であり、標準的なコンテナイメージを使用可能で、サンドボックスに対して Docker デーモンやホストの Docker ソケットを公開する必要もありません。

この組み合わせは、エージェントワークロードにおいて特に有用です。環境は軽量に保ちつつ、通常のコントナー内で生成されたコードを実行するよりも強力な分離性を提供できます。

gVisor はサブ秒単位のサンドボックス起動と、1 つのサンドボックスあたりの低いメモリオーバーヘッドを提供するため、サンドボックスを比較的細粒度の分散リソースとして利用することが可能になります。

リアルワールドのワークロードにおける共通パターン

孤立したプロセスを作成することは、実際のエージェントワークロードを実行する一部に過ぎません。環境によっては異なるネットワークポリシーが必要になる場合があり、ファイルやアーティファクトはエージェントとサンドボックスの間を移動する必要があります。また、外部システムがサンドボックス化された実行を呼び出すための手段も必要です。

Ray Sandboxing には、これらの各パターンに対応するためのプリミティブが含まれています。

リンク1. ネットワーク分離

すべてのサンドボックスが同じレベルの接続性を必要とするわけではありません。エージェントは API を呼び出したりパッケージをインストールしたりするためにインターネットアクセスを必要とする場合がありますが、信頼できないコードを実行する評価用環境は隔離されているべきです。Ray は 4 つのネットワークモードをサポートしています。

• network="none" (デフォルト): ループバックのみ。分離されたロールアウトや信頼できないコードに最適です。
• network="public": ポータブルな /etc/resolv.conf を備えたインターネット出口。API 呼び出しやパッケージインストールに有用です。
• network="host": ノードのネットワーク名前空間を共有し、ノードローカルサービスへのアクセスを可能にします。
• network="sandbox": gVisor の分離されたネットワークスタックを使用し、rootless=False が必要です。

from ray.experimental import sandbox

sb = sandbox.create(
    image="python:3.12-slim",
    network="public",
    dns=["10.0.0.2"],
    readonly=False,
)
ray.get(sb.exec.remote("pip install requests"))

リンク 2: ファイルと状態の移動

実際のワークロードでは、コマンド文字列だけでなく、より多くのデータをサンドボックスへ移す必要があります。小規模なファイルであれば、アクターを通じて直接バイト単位で読み書きが可能です。一方、大規模なディレクトリツリーを扱う場合は、アーカイブ形式を用いて権限、シンボリックリンク、空のディレクトリなどを保持しながら転送しましょう。ファイル転送は Ray を経由して行われるため、サンドボックスが異なる物理ノード上で動作している場合でも問題なく機能します。

script_source = "print('Training complete')"
ray.get(sb.write_file.remote("/app/train.py", script_source))
metrics = ray.get(sb.read_file.remote("/app/metrics.json"))

ray.get(sb.upload_file.remote("bundle.tar.gz", "/tmp/bundle.tar.gz"))
ray.get(
    sb.exec.remote(
        "mkdir -p /app && tar -xzf /tmp/bundle.tar.gz -C /app"
    )
)

リンク 3: MCP を通じたサンドボックス実行の公開

Ray Sandboxes は MCP ツールの背後に配置することもでき、MCP 互換のエージェントに対して、ホスト環境を露出させることなく安全に信頼できないコードを実行する手段を提供します。エージェントはツールとのみ対話を行い、Ray と gVisor がその下で分離処理を担当します。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("sandboxed-python")
isolated_sb = sandbox.create(
    image="python:3.12-slim",
    network="none",
)

@mcp.tool()
def run_python(code: str) -> str:
    """Run untrusted Python inside a gVisor sandbox."""
    result = ray.get(
        isolated_sb.exec.remote(
            ["python", "-c", code],
            timeout=30,
        )
    )
    return result.stdout if result.exit_code == 0 else result.stderr

リンク 4: サンドボックスの権限を制限する

より厳格な隔離を実現するには、capabilities=[] を指定して Linux の権限をサンドボックスから削除できます。これにより、内部でルートユーザーとして動作していても、chown や mknod、生ソケットの開放といった操作を実行できなくなります。より低レベルな制御が必要な場合は、gVisor に到達する前に OCI 仕様を変更できる _oci_spec_transform_fn を利用します。例えば、権限の削除やプロセス制限の適用を行うには以下のように記述できます。

from ray.experimental.sandbox.runtime import SandboxRuntime

def harden_spec(spec):
    # Limit process creation to reduce fork-bomb risk.
    spec["process"]["rlimits"] = [
        {"type": "RLIMIT_NPROC", "hard": 64, "soft": 64}
    ]
    # Remove all Linux capabilities.
    if "capabilities" in spec["process"]:
        for cap_type in spec["process"]["capabilities"]:
            spec["process"]["capabilities"][cap_type] = []
    return spec

runtime = SandboxRuntime()
sb_id = runtime.create(
    image="python:3.12-slim",
    _oci_spec_transform_fn=harden_spec,
)

Harbor と Ray Sandboxes の連携

Harbor は、Claude Code、OpenHands、Codex CLI といったコーディングエージェントを SWE-Bench や Terminal-Bench などのベンチマークで評価するためのフレームワークです。各試行は隔離されたタスク環境内で実行されます。

Ray のネイティブサンドボックス機能は、Harbor 環境として利用可能です。Ray クラスター上で Harbor を実行すれば、タスクイメージは gVisor 上で各ノード上で動作し、ネットワークポリシーもサンドボックスによって強制されます。

LinkInstall and Run

Harbor と Ray のサンドボックスを連携させるには、Ray 2.58 以上と、Ray ベースイメージに runsc を インストール しておく必要があります。

# Install Harbor with the Ray backend
pip install 'harbor[ray]'

# Run an evaluation on Ray
harbor run --dataset terminal-bench@2.0 \
 --agent claude-code \
 --model anthropic/claude-opus-4-1 \
 -e ray \
 --n-concurrent 32

LinkStatus and Performance

公開された [environment].docker_image（例：MedAgentBench）を持つタスクは、特別な設定なしで動作します。Terminal-Bench や SWE-Bench のようなベンチマークでは、各タスク用のイメージを到達可能なレジストリに公開する必要があります。現在、Compose、GPU、またはホワイトリストベースのタスクは拒否されます。

14 コア CPU の開発 VM 1 台でのパフォーマンス計測結果：

• シングルトライアル: 29 秒
• 並列度 4 で 8 個のトライラン: 8/8 が報酬 1.0、例外なし、合計 3 分 02 秒（トライごとの p50 は 45 秒）

スループットは通常ノードあたりのメモリ制約に左右され、Ray オートスケーラーを通じてクラスター単位で水平方向に拡張可能です。

LinkHow it works

Harbor の環境モデルは Ray Sandbox に直接マッピングされます：

• 権限: タスクイメージは Docker 互換の機能で実行されるため、既存のベンチマーク画像は期待通りに動作します。
• 実行: ストリングコマンドは、Harbor の bash -c セマンティクスを維持します。
• ファイル転送: ディレクトリアップロードは tar アーカイブとしてパッケージ化され、サンドボックスファイル API を経由して転送されます。
• リソース: Harbor でのリソース要求は Ray のスケジューリング予約に変換され、ランタイム制限はサンドボックス内部で強制されます。
• ネットワーク: Harbor の「ネットワークなし」ポリシーは network="none" にマッピングされます。より広範なアクセス権限を持つオーバーライドを試みると、サンドボックス作成前に拒否されます。

次のステップ

Ray のサンドボックス機能は現在実験的な段階にあり、コミュニティと協力してさらに発展させたい領域がいくつかあります。

REST API サービス: 今後、Ray を依存関係として必要とせずにユーザーがサンドボックスと対話できる REST API の実装を計画しています。これにより、トレーニング用クラスターとサンドボックスクラスターの分離が可能になり、サンドボックスをサービスとして実行できるようになります。プロトタイプは こちらの PR で利用可能です。

GPU サポート。 Ray はすでに CPU と GPU の混合ワークロードのスケジューリングに広く使用されており、gVisor も GPU に対して良好な動作 を示しています。カーネル生成や RSI（リアルタイム信号処理）などのワークロードが重要性を増す中、GPU ベースのサンドボックスを特別な設定なしで即座に利用できるようにしたいと考えています。

サンドボックス内での Docker サポート

一部のエージェントタスクでは、Docker へのアクセスが前提となっています。gVisor はサンドボックス内で Docker を実行できる サポート を提供しており、Ray のサンドボックス機能と自然に連携する設定について文書化し、検証したいと考えています。

ネットワークとファイルシステムの機能強化

ファイルシステムのスナップショット取得や、ホストとサンドボックス間、あるいはサンドボックス同士のポート公開など、新たな機能を追加する予定です。

セキュリティガイドラインの策定

gVisor は 成熟したセキュリティアーキテクチャ を提供していますが、システム全体のセキュリティ特性は、サンドボックスと周辺インフラの構成次第で大きく変わります。モデルが積極的にサンドボックスからの脱出を試みるようなワークロード向けに、推奨設定や具体例を含む明確なガイドラインを開発したいと考えています。

これらのプロジェクトに関心がある場合や、ご意見・ご感想をお持ちの場合は、ぜひご連絡ください（GitHub の Issue や PR 作成などを通じて）。

実際に試す

Ray 2.58 から、Ray Sandboxing は実験的に利用可能です。

エージェント型 RL システムの構築や、コーディングエージェントの評価、大規模な隔離実行が必要なその他のワークロードに取り組んでいる方は、ぜひご試用いただき、不足している機能などをご報告ください。

Kubernetes での利用を開始するには、Ray Sandboxing Guide をご覧ください。

フィードバックや機能リクエスト、コントリビューションについては、GitHub のディスカッションに参加してください。

私たちの目標は、サンドボックス環境を Ray の他の分散プリミティブと同じように扱えるようにすることです。作成もスケーリングも容易で、エージェントワークロードの他の要素との組み合わせもスムーズに行えます。