■ 1. sandboxdの概要
- AIアプリビルダーの基盤エンジン:
- オープンソースであり、自分のサーバー上で動作する
- 各アプリを専用の隔離サンドボックス内で実行する
- サンドボックスの構成要素:
- 専用コンテナ、ファイルシステム、メモリ制限
- 組み込みのAIコーディングエージェント、ライブプレビューURL
- 用途の広がり:
- 大半の利用者はアプリビルダーとして構築する
- 同一エンジンがエージェント基盤、プレビュー環境、80以上のワンクリックOSSアプリも動かす
- 提供形態:
- セルフホスト、オープンソース、1コマンドでインストール完了
■ 2. 1回のHTTPリクエストで起きる3つの動作
- サンドボックスの作成:
- プライベートで隔離されたLinuxコンテナを生成する
- あるユーザー、エージェント、ブランチのコードが他のものを参照したり破壊したりできない
- コードまたはAIエージェントの実行:
- 任意のコマンドのexec、API経由でのファイル書き込みが可能
- プロンプトを渡してエージェントに構築させることもできる
- OpenCodeとClaude CodeのCLIがプリインストール済み
- ライブURLの付与:
- サンドボックス内で動くdevサーバーが共有可能なプレビューリンクで即座に到達可能になる
- ルーティングとTLSは自動で処理される
- エンドポイントの対応関係:
- POST /sandbox でプライベートな隔離コンテナが起動する
- POST .../tasks でAIエージェントがその中にアプリを書く
- http://
.preview... でそのアプリが専用URLで公開される ■ 3. 低コストな運用
- アイドル時の自動スリープ:
- 誰も使っていないサンドボックスは停止し、メモリを解放する
- リンクアクセス時の即時復帰:
- 誰かが再びリンクを開いた瞬間に起動する
- ファイルはその間ずっとディスク上に保存されている
- 収容密度の向上:
- 1台の通常のサーバーで多数のユーザー、エージェント、ブランチを保持できる
- それぞれに仮想マシンを1台ずつ用意する必要がない
■ 4. 意図的に小さいアーキテクチャ
- 構成技術:
- Dockerに指示を出す1つのGoプログラム
- TraefikがURLを担当し、SQLiteがデータベースを担当する
- 採用しない技術:
- Kubernetes、独立したデータベースサーバー、メッセージキューを使わない
- 可読性の高さ:
- 全体を半日で読み通せる規模
- ホスト側の全体像:
- ホストに必要なものはDockerのみ
- ブラウザからTraefik経由でサンドボックス内のコーディングエージェントとdevサーバー(:3000)へ到達する
- API/CLIはsandboxdを呼び、workspaceディレクトリが永続化される
- SQLiteが信頼できる唯一の情報源となり、アイドルで停止、リクエストで起動する
■ 5. sandboxd上で動かすもの
- 単一目的の製品ではなく構成部品:
- 作成、構築、プレビュー、スリープ、起動という同じループが多様な用途を支える
- AIアプリビルダー製品:
- ユーザーが「todoアプリを作って」と入力すると動くWebサイトが専用リンクに現れる種類の製品
- Lovable、Bolt、v0、Replitに相当するものを自分のサーバー上で実現するOSSバックエンド
- エージェント基盤と社内エージェント実行:
- すべてのコーディングエージェントに隔離ワークスペースと実際のライフサイクルを与える
- プロンプト送信、SSEによる進捗ストリーミング、永続的な結果の取得が可能
- プロバイダを一度接続すれば認証情報注入プロキシが鍵をサンドボックス外に保ち、何も自社インフラの外に出ない
- ユーザー単位・ブランチ単位のプレビュー環境:
- 開発者、ブランチ、プルリクエストごとに共有可能なライブURLを与える
- 再起動しても存続し、アイドル中はコストがかからない
- コーディングプレイグラウンド:
- 使い捨てでリソース上限付きの環境を配布する
- 1人のユーザーが他の全員を巻き込んで停止させることがない
- チーム向けのマルチアプリホスティング:
- 多数の小規模な社内アプリを1台のマシンで運用する
- 各アプリが専用の整ったURLを持ち、アイドルで停止し次のリクエストで起動する
- SaaS型サンドボックスとの違い:
- セルフホストかつMITライセンスのため、SaaSでは満たせない場所に適合する
- コード、データ、APIキーが自分の管理下のハードウェアに留まる
- 月20ドルのVPSでも社内ネットワーク内のサーバーでも成立する
■ 6. 対象となる利用者
- 多数のサンドボックスを運用する場合は採用すべき:
- 製品のユーザー向け、チーム向け、エージェント向けの運用が該当する
- AIアプリビルダー、エージェント基盤、コーディングプレイグラウンドが該当する
- ユーザー単位やブランチ単位のプレビュー環境、チーム向けマルチアプリホスティングも該当する
- 自分用のコンテナが1、2個なら採用不要:
- シェルスクリプト、docker run、lxdの方が単純
■ 7. 本当に難しいのはインフラ
- 難所はプロンプトでもアプリでもなくその下の基盤:
- AI製品を出す場合でも社内プラットフォームを作る場合でも同じ
- 必要となる要素:
- あるユーザーのコードが他に触れないマルチテナント隔離
- 自動ルーティングとTLSを備えたユーザー単位のプレビューURL
- アイドル環境がメモリを解放しなければ請求額が爆発するためのコスト制御
- ワークスペースに対してエージェントを走らせ、進捗を流し、結果を捕捉するオーケストレーション
- 永続化、オンデマンド起動、クラッシュや再起動後の再調整
- 開発規模:
- これらは数ヶ月分のプラットフォーム開発に相当する
- sandboxdはそれを1コマンドに凝縮したもの
■ 8. 主要な特徴
- ワンラインインストール:
- curl -fsSL …/install.sh | bash だけでAPIとプレビューが動く状態になる
- エージェント同梱:
- OpenCodeとClaude Codeがすべてのサンドボックスに同梱され、プロンプトを渡せば構築が始まる
- 認証情報はサンドボックスに一切入らず、プロキシが通信経路上で注入する
- すべてのタスクがチェックポイント化され、巻き戻しが可能
- 設計として高密度:
- アイドル停止とリクエスト起動により、数十のサンドボックスが1台を共有する
- VMを1台ずつ用意する方式との差は20ドルのサーバーと2000ドルのクラスタの差になる
- 所有権が自分にあること:
- セルフホスト、MITライセンス、ベンダーロックインなし
- データ、利益率、ロードマップを自分で所有する
- 意図的な退屈さ:
- SQLite、docker CLI、Traefikのみで構成する
- 起動のたびにリコンサイラがDockerをデータベースの状態へ収束させる
- コントロールプレーン全体を半日で読み通せる
■ 9. シェルスクリプトで十分ではないかという疑問
- 自分用の長期稼働コンテナが1、2個ならスクリプトで十分:
- シェルスクリプト、docker run、lxdの方が単純であり、そちらを使うべき
- 単発のプロジェクトにsandboxdは過剰
- 他者のために多数のサンドボックスを動かす時点で価値が出る:
- チーム向けや製品向けの運用になると、小さなdocker runスクリプトが以下すべてへ膨らむ
- ポートではなくURL:
- すべてのサンドボックスが自動ルーティングとTLS付きの整ったプレビューURLを得る
- ポート管理も衝突対応も不要
- 自律的なスリープと起動:
- アイドルのサンドボックスは停止してRAMを解放し、次のリクエストで透過的に再起動する
- ウォームアップ画面、レディネスプローブ、リクエスト保留を含み、その部分だけで100行を優に超える
- 安価な1台で済むか常時稼働VMのラックが必要かの分かれ目になる
- 再起動への耐性:
- SQLiteが信頼できる唯一の情報源であり、起動時にリコンサイラがDockerを再収束させる
- スクリプトはホスト再起動時にすべてを忘れる
- シェルインするCLIではなくAPI:
- create、exec、stop、destroy、write-files、run-agent-taskが認証付きの実HTTPエンドポイントとして存在する
- アプリのバックエンド、CI、スクリプトからユーザー単位で大規模に呼び出せる
- 巻き添え停止の防止:
- サンドボックス単位のメモリ制限とPID制限を持つ
- ホストのメモリ逼迫時に動くリーパーを備える
- ライフサイクルを持つエージェント:
- プロンプト送信、SSEでの進捗ストリーミング、永続的な結果の取得を行う
- opencodeをその場で起動するだけのものとは異なる
- 結論:
- スクリプトを育てて同じ機能を再実装すればsandboxdを再発明することになる
- 単発なら見送り、スクリプトで夜も眠れなくなった時点で採用すべき
■ 10. Kubernetesを好む場合
- コントロールプレーンは薄いdocker CLI境界を介してコンテナランタイムと対話する:
- k8sのJob/Podバックエンド追加は書き直しではなくインターフェース差し替えで済む
- 最初のコントリビューションとして適している
- 現時点では単一のDockerホストを対象とする:
- k8sは不要
- サンドボックスのためだけにクラスタを運用したくないチームに最適な位置
■ 11. プロダクトの土台としての適性
- 製品基盤として使えるかという問いへの答えは肯定:
- それこそが狙いである
- 省ける初期開発:
- マルチテナント隔離、プレビュールーティング、アイドルと起動によるコスト制御、エージェントオーケストレーションを数ヶ月かけて作る必要がない
- AIアプリビルダーやエージェントSaaSの出荷、社内でのサンドボックス環境構築を初日から始められる
- 提供条件:
- 安価なサーバー1台で動き、利益率は自分で制御できる
- 現状の位置づけ:
- ベータ品質、MITライセンス、読まれ拡張されることを前提に作られた誠実な出発点
- 軽量に立ち上げ、成長に応じて堅牢化していく方針を取る