- Fly.io が新たに公開した ‘Sprites’ は、従来の使い捨てサンドボックスに代わる 永続型クラウドコンピュータ のコンセプト
- 1〜2秒以内に作成 でき、自動アイドル移行、チェックポイント復元、100GBの永続ストレージ を提供
- 従来の ステートレスコンテナモデル は AI エージェント（例: Claude）にとって非効率だと指摘し、永続的な環境 の必要性を強調
- 実例として、Claude が Sprite 上で SQLite ベースの Go アプリ（MDM） を構築し、長期間運用した経験を提示
- 記事の結論: “サンドボックスの時代は終わり、使い捨てコンピュータの時代が来た”
- Fly.io は、従来の 読み取り専用サンドボックスモデルは時代遅れ だとして、それに代わる ‘Sprite’ を公開
sprite create コマンドで 1 秒以内に Linux のルートシェルを作成可能- スプライトは 100GB の永続ストレージ を備え、アイドル時は自動でスリープし、その後再び復元可能
sprite-env checkpoints create で システム全体のチェックポイント を即座に作成可能
sprite checkpoint restore v1 で 1 秒以内に復元でき、Git のようなシステム単位のバージョン管理 が可能
- 主な特徴
- 数百のインスタンス を簡単に作成
- 自動課金停止（Idle metering） によりコストを削減
- Anycast ネットワーク接続 により HTTPS URL を提供
- 完全な永続性 を維持し、明示的に削除するまで保持
Claude とステートレスコンテナの限界
- 現在のクラウド環境の大半は ステートレス（stateless）コンテナ 中心の構造
- データは外部 DB にのみ保存し、単純性と拡張性の確保を目的としている
- しかし Claude のような AI エージェント にはこの構造が適していない
- コンテナを迂回または脱出しようとする挙動を見せ、「コンピュータ」全体へのアクセス を求める
- 「コンピュータ」 の定義として、永続性（durability） と 作業後も消えない環境 を提示
- 現在のサンドボックスにはこの 2 つがどちらも欠けている
シンプルさ（Simple Wins）
- 永続型環境では 開発環境の再構築（node_modules など） が不要
- 業界ではこれを解決するために、スナップショット技術へ数千万ドルを投じている
- 実際のインフラを構成して、エージェントが S3、Redis、RDS などの外部リソースにアクセスできるようにする事例も存在
- これはサンドボックスの非永続性という問題を回避するための暫定策
- スプライトはこうした複雑さを取り除き、ファイルを書けばそのまま残る環境 を提供
- 例として、Phoenix.new プロジェクトでは Fly Machine ベースのエージェントが アプリログを直接観察 しながらエラーを修正
Galaxy Brain Win: 開発と運用の融合
- 筆者は Claude とともに SQLite ベースの Go アプリ（MDM） を Sprite 上で構築
- Anycast URL を通じて MDM 登録 URL として活用
- Claude が APNS 証明書の設定 まで自動処理
- このアプリは 1 か月以上にわたり Sprite 上で安定稼働中
- “開発環境がそのまま本番環境（dev is prod, prod is dev） ” という概念を実現
- 大半のアプリは大規模トラフィックを必要とせず、個人向けに最適化された永続型アプリ の方が重要だと主張
サンドボックスの終焉と使い捨てコンピュータの時代
- Fly.io は長年にわたり 水平スケール型マイクロ VM プラットフォーム を開発してきたが、サンドボックスモデルは限界に達した
- スプライトは Fly Machines に似ているが、新しいストレージスタックとオーケストレーション構造 を採用し、Dockerfile は不要
- 核心となる問いを提示:
> 「エージェントを実行できるなら、読み取り専用サンドボックスより即時に呼び出せる EC2 インスタンスの方がよくないだろうか？」
- 結論: 「サンドボックスの時代は終わり、使い捨てコンピュータの時代が来た。」
1件のコメント
Hacker Newsの意見
最初は本当に気に入ったが、Fly APIを触った他の経験と同じく、今回もどこか壊れている感じがした
https://sprites.dev/api のドキュメントにある例のコマンドをそのまま実行すると、
{"error":"name is required"}というレスポンスが返ってくるしかし、Create Sprite ドキュメント にある完全なリクエスト本文を使えば正常に動作した
個人のワークフローならこうした粗さは受け入れられるかもしれないが、チーム全体に影響する CI/CD ではためらってしまう
Fly チームにはお願いしたい — ドキュメント内のサンプルは必ず 自動テスト で検証してほしい
https://sprites.dev/ は本当に興味深い
自分が好きな2つの問題を一度に解決している
スナップショット機能もあり、実行後に以前の状態へ簡単に戻せる
詳細は自分のブログにまとめた → simonwillison.net の記事
それと、Simon が自分の仕事をもっと 収益化 しようとしているという話を聞けてうれしかった。彼がより利益を得るほど、世の中はよくなる気がする
哲学的には Fly が好きで、初期からの顧客でもある
ただ、CLI 周りの作業にはいまだに 怖さ がある。数週間に一度しか使わなくても自動更新が頻繁に走って、流れが切れてしまう
Sprite CLI でも同じ問題が繰り返されないか心配だ
これは本当に面白い！
会社では Claude を SSH 接続した永続型の開発サーバー を使っているが、git repo や環境が消えると不便だ
Sprite なら SQLite のようなものでデータを保存し、URL でアクセスする簡単なアプリを作れそうだ
一定時間後に自動で消える仕組みなら、シンプルな個人用ソフトウェア に最適だと思う
もし Vercel の preview 環境 のように、Fly アカウント認証を通して URL を見られる機能があればさらによい
見た目は素晴らしいが、Fly の他の製品は 安定性 や 完成度 の面で模範的とは言えない
API のダウンタイムや一時的なエラーが頻繁に発生し、請求の問題 も解決が遅い
たとえば削除したインスタンスがまだ使用中と表示され、時間課金が実際の2倍で計算される
新しい AI 製品である Phoenix.new や Sprites を出してきたが、既存製品の品質改善より新製品に注力しているように見える
こういう 開発用サンドボックス を求めていた — 終了し忘れても大きなコストにならない環境だ
ただし、いくつか問題があった
manpath: can't set the localeエラー — おそらくローカルの locale 設定がそのまま渡されたのだと思う$SHELLが/opt/homebrew/bin/fishに設定されていた。ローカルの環境変数がリモートに 無断で転送 されたようで、少し不安になったこれは本当にすばらしい。自分が待っていた DX と API 形式のサンドボックス実行環境だ
ベースイメージや VM をカスタマイズして、不要なツールなしで必要なバイナリだけを含めたい
あるいは、チェックポイントベースでスプライトを複製する機能があるとうれしい。今のところそのオプションは見当たらない
この数か月、Sprites の作業 をしながら本当に楽しかった
近いうちに Elixir 側の一部を オープンソース として公開する予定だ
5分のデモ動画もある → YouTube デモ
使っていないスプライトはほとんどコストがかからない。新しい作業を始めるたびに、そのまま新規作成すればよい
何も決めなくても、いつでも実行できる環境があるというのは不思議な感覚だ
ドメインが fly.io なので、最初は ローカルソリューション かと思った
self-hosted ではないとしても、Docker や bubblewrap を包んだ ローカル VM ラッパー を期待していた
ZFS ベースの IncusOS をローカルハードウェアで動かせば、非常に強力なサンドボックス環境になる
ドキュメントで見落としただけかもしれないが、スプライトを fork/clone したり、チェックポイントを新しいスプライトとして復元したりできるのか気になる
たとえば、1つのスプライトをテンプレートにして複数立ち上げたり、Claude Code が複数の解法を探索した後で1つだけ残して残りを整理したりする使い方をしたい
ローンチ時に含めるつもりだったが、まずは実際の利用データをもう少し集めようという判断があった