「Code and Let Live」を日本語に訳すと、 **「コードと生きる」** となります。

イメージは Annie Ruygt さんのものです

エージェント隔離の最先端は「読み取り専用サンドボックス」です。Fly.io では長年この話を語ってきましたが、私たちはこれに対してこう呼んでいます：
“揮発性のサンドボックスは時代遅れだ”。使うたびにサンドボックスを消す必要はありません。

私の主張は、新しく構築したものを示さなければ成り立ちません。ここでは大人同士、会社として話し合っているので、どうやってコードを走らせるかを説明します。

---

コード実行例

まず

sprite create

を実行します。処理中に何が起きているかを解説します。

✓ Created demo-123 sprite in 1.0s
● Connecting to console...
sprite@sprite:~#

ほら、すでにそこにあります。

これは私たちが所有する Linux コンピュータの root シェルです。既存のホストへ SSH する時間とほぼ同じ時間で起動します。これを Sprite と呼んでいます。

FFmpeg をインストール

sudo apt-get install -y ffmpeg >/dev/null 2>&1

apt‑get

で

ffmpeg

を入れるのは遅いです。もう一度やらないようにしましょう：

sprite@sprite:~# sprite-env checkpoints create
# ...
Checkpoint v1 created successfully

これだけで完了します。測定もしません。

コーヒーを買いに離れます。時間が経つと Sprite は自動的にスリープ状態になります。カフェで旧友に会い、数日過ごして戻ると：

> $ sprite console 
sprite@sprite:~# ffmpeg
ffmpeg version 7.1.1-1ubuntu1.3 Copyright (c) 2000‑2025 the FFmpeg developers
Use -h to get full help or, even better, run 'man ffmpeg'
sprite@sprite:~#

何も変わっていません。Sprite は耐久性があります。最初に 100 GB の容量を持ち、儀式は不要です。数日、数か月使い続けても問題ありません。

アプリケーションを立て、パッケージを増やすと…何かが壊れます（

pip3 install .

、

rm -rf $HOME/bin

、

dd if=/dev/random of=/dev/vdb

など）。その場合：

> $ sprite checkpoint restore v1
Restoring from checkpoint v1...
Container components started successfully
Restore from v1 complete

> $ sprite console
sprite@sprite:~#

チェックポイントとリストアは一級品です。復元に約１秒で、日常的に使える速度です。Git のようにシステム全体を扱うツールとして意図されています。

---

EC2 との違い

EC2 インスタンスとはどう違うかと聞くなら、答えは簡単です：

• Docker コンテナなしで数百個を気軽に作れます。起動時間は 1–2 秒。
• アイドル状態になると自動的に料金が停止するので、多数持つのが安価です。私は数十台使っています。
• Anycast ネットワークに接続され、HTTPS URL が取得できます。
• 完全耐久性。手で止めるまで死なない。

この組み合わせはまだ名前がありませんでしたから Sprite と名付けました――使い捨てクラウドコンピュータのようです。

---

Claude はステートレス・コンテナを望まない

長年、同じ抽象化で二種類のユーザーにサービスを提供しようとしましたが、うまくいきませんでした。プロフェッショナルな開発者は「状態のないインスタンス」を作る訓練を受けています。永続データはデータベースサーバに限定することでシンプルさとスケールアウトの柔軟性、失敗範囲の縮小が実現します。

しかし Claude は 5 歳の超生産的天才です。電気ソケットを探し回り、コンテナから抜け出して自分で動かしたいと考えます。エージェントに強制すると、コンテナ化を迂回して作業しますが、助けにはなりません。彼らは「サンドボックス」ではなく「コンピュータ」を求めています。

---

シンプルな勝利

実際のコンピュータがあれば Claude は PR を拾うたびに開発環境を再構築する必要がありません。

node_modules

の再生成は大痛手で、業界は揮発性サンドボックスのスナップショットとリストアで数千万ドルを費やしています。しかしそれらは不要です。実際にコンピュータを使えば PR を修正しレビュー・プッシュした後、次へすぐ移行できます。

人々は「毎回新しいビルド環境から始めるべき」と合理化しますが、これは株スクール症候群です。自分で機能ブランチを作るなら、完全に新しい開発環境を用意する必要がありますか？エージェントはそのような努力を余計にしています。

現在のサンドボックスは「読み取り専用」かつ「揮発性」です。エージェントが実際にファイルを書き込んで保持できないため、S3 バケットや Redis サーバー、RDS インスタンスなど外部インフラを構築しなければならず、面倒です。

揮発性は時間制限を意味します。プロバイダは期待されるワークロードに合わせてサンドボックスを設計しています。エージェントが行う作業はほとんどが数分で完了し、99 パーセンタイルの実行時間は 15 分未満です。

しかし計算やネットワーク時間がトークン処理を上回る機能リクエストもあります。私は Sprite API のドキュメントサイトを Claude がコードと API を操作して作成しました。API によっては、クライアントとの対話だけでサンドボックス予算を超えることがあります。

「plan files」を経由して状態をラウンドトリップする現行手法の限界が見えます。実際にコンピュータ上で動くエージェントは、アプリケーションのライフサイクル全体を活用できます。例えば Chris McCord が

Phoenix.new

を作ったとき、そのエージェントは Fly Machine 上で動き、生成された Phoenix アプリのログを閲覧できました。例外が発生するとすぐに検知して対処します。

Chris は自分でエージェントを書いたおかげでこれを実現しました。Claude でも MCP サーバや他の手段でログを転送できますが、基本的には「サンドボックスを無視せず」動作するだけです。

---

Galaxy Brain の勝利

ここからは私の話が聞きにくくなるかもしれません。多くのチームメンバーも同じように感じているでしょう。

ソフトウェア開発の本質は変わりつつあります。プロフェッショナル開発者の配備方針だけで終わるとは考えが甘いです。

私は子供がいます。彼らにはデバイスがあります。管理したいとき、MDS を作りました。Claude で SQLite バックエンドの Go アプリを Sprite 上に構築し、Anycast URL を MDM 登録用に使いました。APNS Push Certificate の調整も Claude がやってくれました。

「FTP で PHP ファイルを編集する」―これは当時先駆的だったかもしれませんが、今は普通です。私はこのアプリを 1 ヶ月以上 Sprite 上で動かし続けており、中止の理由はありません。実際に必要な機能を Claude に教えるだけで変化します。

大規模に配布するアプリはほとんど存在せず、重要なのは日常的に使う小規模アプリです。実際の問題を解決するアプリは、そのユーザー自身が所有し、プロフェッショナルな開発者の門番不要で動きます。

---

揮発性サンドボックスにはもう終わり

もちろんこれは商品販売のための話ですが、それが私たちが作ったものを売る理由です。

• 私たちはこれらをリリースしました。
• 今すぐ数十個の Sprite を作れます。時間は 1 秒程度です。

長い道のりでした。横方向にスケールする本番アプリ向けプラットフォームを構築し、マイクロ VM が極めて高速に起動できるようにしました。これらを使えば「コードサンドボックス」を比較的容易に実現できますが、完全な解決策ではありません。

Sprite は Fly Machine と似ていますが重要な点で大きく異なります。ストレージスタックも新しく、オーケストレーションも別です。Dockerfile は不要です。

---

まとめ

あなた自身がエージェントをどこかにデプロイしたいと考えるなら、クラウドの K8s クラスターで読み取り専用サンドボックスのような形より、EC2 インスタンスを指先ひとつで呼び出せる「完全なコンピュータ」の方が欲しいでしょうか？

答えは明白です。サンドボックス時代は終わり。使い捨てコンピュータの時代が到来しました。