Fly.io Sprites、sandboxを「永続するLinuxコンピュータ」へ置き換えた転換

Kurt Mackeyは、agent向けの実行環境を「sandboxesではなくcomputers」と捉え直し、Spritesを作った理由を説明している。

They don’t want containers. They don’t want “sandboxes”. They want computers.

Fly.ioの従来のFly Machinesは、productionアプリをcontainerとして配信するための強い基盤だった。

しかしagentの開発では、毎回環境を作り直し、作業終了と同時にfilesystemを捨てることが負担になる。

Mackeyは、作成して約1秒でshellへ入り、100GBのdurable diskを持ち、idle時にはsleepするSpriteを提示した。出典

Thomas Ptacekは設計記事で、作成速度を妨げるcontainer imageをユーザー向けの基本単位から外し、workerが標準containerを使った空のSpriteをあらかじめ用意する判断を解説した。

これにより作成はimage pullではなく、既存VMをstartする処理に近づいた。出典

次の転機はstorageだった。

SpritesはNVMeを唯一の保存先にせず、object storageをrootに置き、local cacheを組み合わせる。

checkpoint/restoreはprocessを途中から再開する機能ではなく、filesystem全体を戻す仕組みとして設計された。出典

その後、ConnectorsとMCPが加わった。

agentはOpenRouter、Slack、GitHubなどへ、credentialそのものを手元に置かず接続できる。

Fly.ioはMCPを提供しつつ、長期的にはCLIとdiscoverable APIをagentに使わせる考えも明言している。出典

Fly.ioはSpritesを小さなskunkworksから会社の中心へ移した。

MackeyはCEOをScott Johnstonへ引き継ぎ、自身はadvisorとして関わると説明した。

Spritesの物語は、既存PaaSの機能追加ではなく、AI時代に「cloud computer」の単位を作り直す賭けとして続いている。出典

AI agentを毎回使い捨てのsandboxへ戻すと、依存関係の再構築、長時間タスク、実データとの接続が摩擦になる。

Spritesは永続filesystemと常時利用できるURLを一つの実行単位にまとめ、その痛みを「computerを渡す」ことで解く。

公式説明では100GBのdurable storage、auto-sleep、checkpoint/restoreが中核であり、単なる隔離containerとの差分が明確だ。出典

一方で、大規模な固定機能アプリをそのまま載せるための製品ではない。

Fly.io自身も、millions of users向けにはFly Machinesへcontainerizeする想定を示している。

まずagentの開発・検証・小規模な個人向けアプリに刺さるPMFと見るべきだ。出典

技術的なmoatは、VM・Anycast・object storage・orchestratorをagent向けの一体験へ落とし込む運用知だ。

100GB filesystemをcheckpoint/restoreし、URLとConnectorsまで同じAPIで扱う組み合わせは、単一機能のsandboxより模倣範囲が広い。出典

ネットワーク効果は弱い。

Sprite自体は単独で価値を持ち、利用者が増えても直接的な相互作用は発生しない。

ただし、SDK・agent plugin・MCP連携が増えるほど、利用開始時の選択肢は増える。出典

主対象は、coding agentや評価agentを長時間・反復的に動かす開発者、agent startup、個人開発者。

依存関係やログを保持したまま複数の実験環境を作りたい人に向く。出典

大規模productionのSREや、厳密なcontainer image標準化を必要とするチームは第一対象ではない。

Fly Machinesとの使い分けを前提に選ぶべきだ。出典

第一は、作成の速さと永続性を同時に設計したこと。

container image pullを避け、worker側で空のSpriteを待機させることで、作成体験を短くした。出典

第二は、既存のAnycast、object storage、Fly Machinesを再利用しながら、agent向けに課金・起動・storageの単位を変えたこと。

新規クラウドをゼロから作らず、既存基盤の強みを別の利用形態へ束ね直している。出典

最大の不確実性は、永続diskと便利な自動sleepが、production workloadの低遅延・高可用性要件と両立する範囲だ。

Fly.io自身も、millions of usersへ配信する用途ではFly Machinesを推奨している。出典

また、料金はCPU・RAM・storageのusage-basedで、idle状態やプランの上限を理解しないと予算を読み違える。

agentが作る大量のSpriteを安全に管理するには、Connectorsの権限設計とorg単位の上限運用も必要になる。出典

成長の入口は、CLIと公式SDKを使うdeveloper-led distributionだ。

公式サイトはCLIのinstall、API、Node.js/Go/Elixir/Pythonの例を同じ導線で見せ、Claude・Gemini・Codexなどagentとの利用を前面に出す。出典

さらに、Fly.ioのブログが「sandboxではなくcomputer」という問題定義を繰り返し、MCP endpointやConnectorsで既存agent workflowへ接続する。

新規カテゴリを広告で説明するのではなく、実行環境を一度使わせるPLGが合理的だ。出典

主要チャネル: content, developerCommunity, productLedGrowth, partnerships

agent向け基盤では、実行を安全に隔離するだけでなく、作業状態が次のpromptにも残ることが体験価値になる。

従来のsandboxの制約を前提に最適化するより、agentが本当に必要とするcomputerの性質を定義し直す方が、プロダクトの差別化軸を作れる。出典

ただし、万能な基盤を目指さず、interactive workloadとproduction workloadを分ける判断も重要だ。

用途ごとに課金・永続性・スケールの単位を変えることが、既存基盤の再利用を可能にする。出典

日本で展開するなら、個人開発者や小規模チームが「閉じたノートPCの代わり」に使える導入体験を強調したい。

日本語のCLI/docs、国内リージョンでのデータ保存方針、企業内APIへのConnectors設定例が、価格以外の採用理由になる。

これは公式情報からの直接事実ではなく、日本市場への仮説である。