コーディングエージェント向けのリモートサンドボックス

コーディングエージェントの普及にともない、エージェントをリモートで動作させるための専用開発環境——リモートサンドボックスが注目されています。ここでいうサンドボックスとは、プロジェクトやエージェントごとに気軽に生成・破棄できるリモートVMのことで、exe.dev、Sprites、Docker Sandbox などのサービス・ツールが登場しています。

本記事ではこれらのリモートサンドボックスの用途を整理し、exe.dev・Sprites・Docker Sandboxの3つを比較します。

なぜ専用の開発環境が必要なのか

コーディングエージェントをリモートで走らせる環境として、これまで一般的だった選択肢を列挙すると以下のようになります。

• Mac miniやRaspberry Piを買って自宅サーバーを立てる
• VPS（Hetzner、さくらVPSなど）を契約する
• Devin、Claude Code on the web、Codex（Cloud）などのマネージドサービスを使う
• GitHub Codespaces、Gitpodなどのクラウド開発環境を使う

これらの手段はそれぞれ有用ですが、リモートサンドボックスにはこれらとは異なる明確なポジショニングがあります。

サンドボックスの最大の利点：自律的に動かせる

これらのサービスに共通する本質的な利点は、承認フローの中断なしにエージェントを自律的に動かせることにあります。Claude Codeの --dangerously-skip-permissions（通称YOLO）やCodexのauto-approveのように、すべてのコマンド実行をエージェントに委ねるモードは開発効率を上げます。しかしホストマシンで無制限に動かすのはリスクが大きいです。サンドボックスなら隔離されたVM内でエージェントがroot権限で自律的にシェルコマンドを叩き、パッケージをインストールし、サーバーを立ち上げても、ホスト環境には一切影響しません。

ファイルシステムの隔離に加え、ネットワークレベルの制御もサンドボックスの重要な要素です。Docker Sandboxはallow/denyリストによるアウトバウンド通信の制限に対応しており、エージェントがアクセスできる外部ホストを明示的に絞れます。exe.devやSpritesにはアウトバウンドの制御機能はありませんが、VM自体がリモートにあるため、ホストのローカルネットワークへのアクセスは遮断されています。

ことは開発作業だけにとどまらず昨今はOpenClawユーザーのように日常的なタスクもコーディングエージェント的にものに実行させる機会が増えています。このときにSkillsによって行っているのが制限のきわめて緩いコマンドの自律実行なため、開発者以外にもサンドボックスのニーズがあります（それを安易に提供してくれるのがClaude Coworkです）。

本記事の読者でホストマシンですべてのコマンドをノーガードで実行しているマッドマックスの世界の住人はいないと思いますが、サンドボックスはこうした隔離を担保したまま同等の自由度を得る手段になります。

VPSとの違い

VPSは基本的に長期間稼働するサーバーとして契約します。一方、リモートサンドボックスはプロジェクトやエージェントセッションごとに数秒で生成し、不要になったら破棄できます。VPSよりも気軽に環境を作れるのが特徴です。環境を汚す心配がないため、並列で複数のエージェントを同時に走らせることも容易になります。とはいえ実際のライフサイクルは「1タスク1VM」というほど短くはなく、プロジェクト単位で数日〜数週間維持して使うケースが多いでしょう。

クラウド開発環境との違い

GitHub CodespacesやGitpod、AWS Cloud9といったクラウド開発環境は、リモートサンドボックスの前の世代にあたるサービスといえます。これらは「開発者がブラウザやエディタからリモートVMに接続して開発する」ための環境で、リモートサンドボックスと表面的には似ています。

しかし設計思想が異なります。クラウド開発環境は人間の開発者がIDEで操作することを前提にしており、環境のカスタマイズ性（Devcontainer定義、dotfiles同期、エディタ拡張など）に力が入っています。一方、リモートサンドボックスはエージェントがCLIで自律実行することを前提にしており、APIやSSH経由でのプログラマティックな生成・破棄、yoloモードでの無人実行、チェックポイントといったエージェント向けの機能が中心になっています。

CodespacesはDevcontainerベースなのでエージェントを動かすこと自体は可能ですが、起動が遅く（数十秒〜数分）、課金体系も開発者1人が1つの環境を長時間使う前提の設計になっています。エージェントごとに気軽にVMを立てて並列に走らせる用途には向きません。

サーバーレスPaaSとの違い

VercelやCloudflare Workersのようなサーバーレス系PaaSが提供しているSandboxサービスもあります。これは実行環境としてのリクエスト単位のサンドボックスであり、使えるリソースに制約が多く短命ですです。開発環境としてのサンドボックスではaptでパッケージをインストールでき、ヘッドレスChromeを起動してE2Eテストを走らせたり、PostgreSQLやRedisを立ち上げたりといった「普通のLinuxマシンでできること」がそのままできます。

一方で、サンドボックスとPaaSの境界が曖昧になるケースもあります。Fly.ioのブログ「Code And Let Live」では、SpritesをそのままHTTPSエンドポイント付きの本番サーバーとして公開しデプロイ後にデバッグをするという使い方が紹介されています。変則的ではありますが、プロトタイプレベルの公開には便利でしょう。

リモートサンドボックスでのWeb開発スタイル

リモートサンドボックスでWeb開発をする場合、開発サーバーの実行時のプレビューはローカルホストにポートフォワーディングしてアクセスします。これをそのまま外部公開することができ、https://vmname.exe.xyz のようなURLで認証付きのHTTPSエンドポイントでアクセスできるようにできます。これが許容できるプロジェクトでないと使えません。たとえばソースコードが社外に出せないプロジェクトや、ローカルネットワーク上のデバイスとの連携が必要なモバイル開発では難しいです。筆者もプライベートプロジェクトでしかまだ使っていません。

exe.dev

exe.dev - ssh exe.dev

Build apps or SSH into a persistent Linux VM. ssh exe.dev.

exe.dev

exe.devはSSHベースのシンプルなリモートVMサービスで、コーディングエージェント向けサンドボックスとしては現状もっともProduction Readyな印象があります。

特徴

• ssh exe.dev new でVMを即座に起動。通常のLinux環境として使えます
• サービス全体がSSHプロトコルの上に構築されています。VM操作（new、ls、rm、cp、restart）、共有設定（share）、インテグレーション管理（integrations）、Shelleyという内蔵エージェントの操作（shelley prompt）まで、すべてが ssh exe.dev <command> で完結します。認証はSSH公開鍵、招待はメールアドレスベースで、専用CLIのインストールが不要です。SSHクライアントさえあればどの環境からでも操作できます
• 各VMにHTTPSエンドポイントが自動で付与されます（TLS証明書、DNS、リバースプロキシ込み）。VPSのようにnginxやCaddyを自分で設定する必要がなく、VM内でポートを開けるだけで外部からアクセスできます
• ディスクはリブートしても永続します。PostgreSQL、SQLite、Redisなどをそのまま運用できます
• VMのクローンが1秒で作れるため、新しいアイデアごとに環境を複製できます
• VM作成時にClaude CodeとCodexがプリインストールされています。加えて各VMにShelleyエージェントが組み込まれており、https://vmname.shelley.exe.xyz/ からWebブラウザ上でリサーチやプロトタイピングが可能です。ShelleyはVM料金に含まれており追加課金なしで使えるため、Claude Code契約なしでもエージェント駆動の開発を試せます。VM自体のプロビジョニングにも使えます。

料金

個人プランは月額20ドルで、25台のVM、2 CPU、8GB RAM、25GBディスクが利用できます。毎月の利用料金が固定なのが分かりやすいです。チームプランや本番ワークロード向けの従量課金プランも用意されています。

Sprites（Fly.io）

Sprites - Stateful sandboxes

Persistent, hardware-isolated execution environments for arbitrary code. Run AI agents, untrusted code, and more in secure sandbox environments with checkpoint & restore.

Sprites

SpritesはFly.ioが2026年1月にローンチしたステートフルなサンドボックスサービスで、チェックポイント＆リストア機能を備えた永続VMを提供します。筆者が現在メインで使っている環境です。

exe.devがSSHベースなのに対し、SpritesはHTTP APIベースで設計されています。CLIツール（sprite コマンド）として提供されていますが、裏ではHTTP APIを叩いてTTYセッションを確立する仕組みになっています。

特徴

• FirecrackerベースのmicroVMで、1〜2秒で起動します
• チェックポイントの作成は約300msでトランザクショナルに完了します
• 非アクティブ時に自動アイドル化します。アイドル中は課金されず、状態は保持されます
• ストレージはext4ファイルシステムです。内部的にはカスタマイズされたJuiceFS＋SQLiteメタデータバックエンドで構成されています（詳細は「The Design & Implementation of Sprites」を参照）
• MCPサーバーとして動作し、Claude CodeなどのMCPクライアントからSprite上のファイル操作やコマンド実行をMCPプロトコル経由で呼び出せます
• VS Code拡張も提供されていますが、こちらはリモートファイルシステムのビューワーとしての位置づけです

料金

従量課金制です。CPUが$0.07/時間、メモリが$0.04375/GB・時間で、アイドル中は課金されません。

注意点：レイテンシとファイルシステムの問題

ただし現時点ではいくつか課題があります。まずレイテンシです。exe.dev・Spritesともに現時点ではVMリージョンが北米に限定されており、アジアから使うと物理的な距離による遅延が避けられません。加えてSpritesはHTTP APIレイヤーを経由する分、コマンド実行やファイル操作で体感的な遅延があります。エージェントに自走させるだけなら人間が待つわけではないので実用上は許容範囲ですが、東京リージョンを選べるVPSと比べるとレスポンスの差は感じます。

もう1つはファイルシステムの安定性です。Spriteが突然クリーンな状態にリセットされ、チェックポイントごと消失するという不具合がFly.ioのフォーラムで報告されています。

筆者も実際にこの問題に遭遇しました。ある日、Sprite上でClaude Codeを起動しようとしたところ exec: Input/output error で実行できなくなりました。調査するとoverlayfsのlowerdir（/mnt/languages-image）を構成するloop0デバイスでI/Oエラーが多発しており、EXT4ジャーナルが停止してread-onlyに再マウントされていました。dmesgには overlayfs: failed to get redirect (-5) が大量に出力されています。lowerdirにあるClaude Codeのバイナリ、/etc/profile.d/languages_env、/var/log/ 以下のファイルがすべて「no read permission」状態になり、chmodでの修復もI/Oエラーで不可能でした。Claude Codeの ~/.claude/projects に保存されたセッション履歴もlowerdir上にあり、tarでの救出もできませんでした。

結局、sprite checkpoint restore で前日のチェックポイントに復元して解決しました。チェックポイントがなければ環境の再構築が必要になるところで、この復元機能に救われた形です。逆にいえば、こまめにチェックポイントを取っていないとデータを失うリスクがあるということでもあります。

Fly.ioチームはWebSocketの多重化やキャッシュの改善などパフォーマンス最適化を進めており、本番データを置くにはまだ不安があるものの、チェックポイント＆リストアの体験やアイドル時の課金停止は魅力的です。使い捨て環境として割り切って使う分には十分に実用的だと感じています。

Docker Sandbox

Docker Sandboxes

Run AI coding agents in isolated environments

Docker IncDocker Inc

Docker Sandboxは、Docker Desktopに統合されたローカル実行のサンドボックスで、microVMベースの隔離環境でコーディングエージェントを安全に動作させます。リモートサービスではなくローカルツールですが、本記事で紹介したリモートサンドボックスと同じ思想——隔離されたVM内でエージェントを自律実行させる——をローカル環境で実現するものとして、併用する価値があります。

特徴

• microVM上で独自のLinuxカーネルが動作し、ホストのDockerデーモンやコンテナとは完全に分離されています。
• Claude Code、Codex、Gemini CLI、Copilot、Kiroなど主要エージェントをサポートしています。Claude Codeは --dangerously-skip-permissions がデフォルトで有効になります
• ネットワーク隔離（allow/denyリスト）に対応しています
• サンドボックス内でDockerコンテナのビルドと実行が可能です（ホストとは独立したDockerデーモンを持ちます）
• エージェントの認証情報（Claude Code、Codexの認証など）を専用領域に保存して使いまわせます

microVM APIについて

Docker Sandboxの内部では、各microVMに /vm APIが提供されています。RivetのブログがこのAPIをリバースエンジニアリングして解説していますが、各VMは ~/.docker/sandboxes/vm/<name>/docker.sock に専用のDockerソケットを持ち、ホストとは完全に独立したDockerデーモンが動作します。これはDevcontainerでDocker-in-Docker（DinD）を使う場合のように特権モードでホストのDockerソケットをマウントするアプローチとは根本的に異なります。サンドボックス内のDockerはVM OSのネイティブな機能として動作するため、DinDの複雑さやセキュリティリスクがありません。

このAPIは公式にはドキュメント化されていませんが、Docker公式がサポートするエージェント以外のワークロード——AIコーディングアシスタントの自作や、マルチテナントのコード実行環境など——にも応用できる可能性があります。

技術的制約

利点は多いものの、現時点ではいくつかの制約があります。

• ポートフォワーディング非対応：サンドボックス内で起動したWebサーバーに対してホストのブラウザから直接アクセスできません。つまりSandbox内でWebアプリを開発しても、localhost:3000 をホストのブラウザで開いてDevToolsでデバッグする、といったことができません。UIの確認はVM内部でPlaywrightやエージェントのブラウザツールを使ってヘッドレスに描画し、スクリーンショットや動画として確認するスタイルになります。socat＋netcatを使ったワークアラウンドはあるものの、これはmacOSのVirtualization.framework（VM API）レイヤーの制約であり、Docker側だけでは解決できない可能性が高いです。ロードマップ上の未実装項目にはなっていますが、対応時期は不透明です
• ディスク消費：Ubuntu VMイメージのため、ベーステンプレートだけで数GBのディスクを消費します。これがワークスペースごとに作成されるため、複数プロジェクトを並行して扱うとディスク使用量が急増します（なお、このアーキテクチャはClaude Coworkなども同様です）
• Linuxサポートは実験的：Docker Desktop 4.40時点でLinux向けの実験的サポート（シングルユーザー、UID 1000のみ）が追加されましたが、macOS/Windowsに比べて機能が限定的です。レガシーなコンテナベースのサンドボックスはDocker Desktop for Linuxで利用可能ですが、microVMベースの完全版は未提供です

比較まとめ

使い分け

現時点での筆者の運用では、コストと用途で大まかに3つを使い分けています。

実際の筆者のコストはexe.devの$20/月のみです。Spritesはサインアップ時の$30トライアルクレジット＋500 Spriteまで無料で作成できるため、まだ課金が発生していません（課金開始後の最小プランは$20/月）。

並列開発について補足すると、Docker Sandboxの場合はgit worktreeでブランチを分離してからVMを作成する運用になります。VMごとにセットアップコストとストレージ消費がかかるのが難点ですが、ヘッドレスでの確認のみで完結するタスクなら十分に実用的です。

なお、どちらのリモート環境でもDockerは使わず、プロジェクトの依存パッケージはaptで直接システムへインストールして運用しています。サンドボックス自体が隔離環境なので、ホストを汚す心配がなく、Dockerでさらに隔離する必要性が薄いためです。

まとめ

コーディングエージェント向けのリモートサンドボックスは、VPSやクラウドIDEの次の世代にあたる実行環境として急速に立ち上がりつつあります。承認フローの中断なしにエージェントを自律実行させるには隔離された環境が不可欠で、exe.dev・Sprites・Docker Sandboxはそれぞれ異なるアプローチでこの問題を解いています。

どれか1つで完結するものではなく、用途に応じて併用するのが現実的な運用でしょう。このカテゴリ自体がまだ新しく、各サービスとも機能追加や安定性改善が続いています。半年後にはまた状況が変わっているかもしれません。

また、業務利用においてはエンタープライズ契約を備えたCodex（Cloud）やClaude Code on the webのようなマネージドサービスが現実的な選択肢になる可能性もあります（Julesは知らない）。