コードを生かしておく

Agent の分離について今ある最善の手段は、読み取り専用のサンドボックスだ。Fly.io ではこの売り文句を何年も使ってきた。だがここで宣言する。使い捨てサンドボックスはもう古い。タスクが終わるたびに殺すのはやめよう。

先に新しいものを見せないと、この主張は成り立たない。大人同士だし、ここは会社だし、やったことはやったと言う。始めよう。

コードを走らせたい。そこでやるのは sprite create の実行だ。これが動いている間に、裏で何が起きているかを話そう——

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

もう終わった。

Linux マシン上の root シェルが、今こちらのものになった。立ち上がるまでの時間は、既存のホストに ssh するのとほぼ同じ。これを “Sprites” と呼んでいる。

Sprite に FFmpeg を入れる：

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

最初に Sprite を作るときと違い、apt-get で ffmpeg を入れるのはひどく遅い。なるべく二度とやらないように：

sprite@sprite:~# sprite-env checkpoints create
# ...
{"type":"complete","data":"Checkpoint v1 created successfully",
"time":"2025-12-22T22:50:48.60423809Z"}

これは一瞬で終わる。測る気にもならない。

コーヒーを買いに出かける。時間が過ぎる。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:~#

離れたときのまま、すべてがそこにある。Sprites は永続的だ。最初から 100GB の容量が付いてきて、面倒な手続きは何もない。もう数日置いておいても、数か月でもいい。とにかく、そのまま使える。

アプリを一つ動かしたとする。パッケージもいくつか入れた。そして：災難。軽率なグローバル pip3 install かもしれない。rm -rf $HMOE/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:~#

Sprites にはファーストクラスの checkpoint と restore がある。文章からは伝わらないが、この restore は 1 秒ほどで終わった。気軽に、対話的に使える速さだ。脱出ポッドではない。Sprite を使う日常の流れに最初から組み込まれているべき一工程だ。git のようなものだが、システム全体に効く。 EC2 インスタンスと何が違うのかと聞かれれば、いい質問だ。まさにそれが狙いで、ただし：

数百個を気軽に作れる（Docker コンテナは不要）。それぞれ 1〜2 秒で起動する。
アイドル状態になれば課金が自動で止まるので、大量に抱えても高くつかない。実際に数十個使っている。
Anycast ネットワークに接続されているので、HTTPS URL が手に入る。
それでいて完全に永続的。こちらが言わない限り死なない。

この組み合わせはまだ一般的な名前を持っていないので、自分たちで付けることにした。Sprites だ。Sprites は BIC の使い捨てクラウドコンピュータのようなものだ。

これが我々の作ったものだ。自分で試してみていい。仕組みを 1000 語で説明した文章も書いたが、削った。今は製品の話をしたいわけではなく、本題を話したい。

Claude はステートレスコンテナを求めていない

何年ものあいだ、我々はまったく異なる二種類のユーザーを同じ抽象で扱おうとしてきた。うまくいかなかった。

プロのソフトウェア開発者はステートレスインスタンスを作るよう訓練されている。ステートレスなデプロイは永続データをデータベースサーバーに限定し、その代わりにシンプルさと柔軟な水平スケール、小さな障害範囲を得る。これは良いアイデアで、その良さゆえにクラウド上でコードを動かせる場所の大半はステートレスコンテナに見える。我々の主力製品である Fly Machines もステートレスコンテナに見える。

問題は、Claude がプロの開発者ではないことだ。Claude はとんでもなく有能な五歳の神童だ。恐ろしいほど賢く、コンセントを見れば指を突っ込みたがる。一番いいのは、自分で自分を感電させる方法を用意してやることだ。（コンテナから逃げ出すこともある！）

Agent を無理に押さえつければ、コンテナ化を回避してでも仕事をやり遂げる。だがそれは agent の助けにはならない。彼らはコンテナを求めていない。「サンドボックス」も求めていない。求めているのはコンピュータだ。先日、agent にサウンドカードや USB ポートが必要だと言っているのかと聞かれた。かもしれない。わからない。今日の話ではない。

理由は後で説明する。まずは「コンピュータ」と言うときの意味をはっきりさせておきたい。次の点は全員一致でいいはずだ：

コンピュータはタスクを一つ終えたからといって必ず消えるわけではない、そして
永続ストレージを持つ。

今の agent サンドボックスにはどちらもないのだから、定義はここまでで十分だ。本題に戻る。

シンプルさが勝つ

まずこれから始めよう。本物のコンピュータがあれば、Claude は PR を引き継ぐたびに開発環境全体を再構築せずに済む。

表面的に聞こえるが、node_modules のようなものの再構築は極めて苦痛で、業界全体が一時サンドボックスのスナップショットと復元の研究に数千万ドルを注ぎ込んでいる。

これらの問題が解けないと言っているのではない。存在する必要がないと言っている。解くよりも、本物のコンピュータをそのまま使えばいい。PR を一つ終えたら、レビューして、プッシュして、次に進む。再起動は要らない。

changeset を始めるたびにまっさらなビルド環境から始めるのは良いことだと、人は自分に言い聞かせる。ストックホルム症候群だ。自分で feature branch を切るとき、そのために新しい開発環境をわざわざ作るだろうか。

Agent がこれほど無駄な労力を使うのは、誰も彼らの到来を予見しなかったからだ。読み取り専用の一時サンドボックスは、当時壁に掛かっていた道具の中で、彼らをまだ正気に使える唯一のものだった。

agent に実データを触らせるために、本物のインフラを組んだことはあるか？組んだ人はいる。agent に prompt を投げるたびに白紙の状態から始まると分かっているから、サンドボックスの外に S3 bucket や Redis サーバー、果ては RDS インスタンスまで用意して、agent に接続させる。ファイルを書いて、そのまま残っていることを願う——それができない部分を回避するために、インフラを組むのだ。ひどい話だ。

一時的であるということは、時間の制約があるということだ。サービス提供者はサンドボックスシステムを設計するとき、agent が生み出すと想定されるワークロードを基準にする。今日 agent がやっていることの大半は、それほど時間がかからない。実際、多くの場合はフロンティアモデルが token を処理する速度によってのみ制限されている。テストスイートはすぐに走り終わる。99 パーセンタイルのサンドボックス agent の実行でも、おそらく 15 分はかからない。

機能リクエストの中には、token の消費量をはるかに超える計算時間とネットワーク時間を必要とするものがある。Sprites API のドキュメントサイトを構築したとき、私は Claude Sprite にコードと私たちの API を操作させ、API のサンプルを一つずつビルドしてテストした。API によっては、クライアントとのやり取りだけでサンドボックスの予算を吹き飛ばしてしまう。

現在のアプローチの限界は、「plan ファイル」——名目上は散文だが、実際には信じられないほど不格好な方法でエンコードされたキーバリューストアにすぎないことが多いファイル——を通じて人々が状態をやり取りする様子にはっきりと表れている。

本物のコンピュータ上で動く agent は、アプリケーションのライフサイクル全体を活用できる。Chris McCord が Phoenix.new を構築したとき、私たちはこれを目の当たりにした。Phoenix.new アプリケーションの背後で動く agent は Fly Machine 上で動作し、自身が生成した Phoenix アプリのログを見ることができる。ユーザーの操作が例外を引き起こすと、Phoenix.new はそれに気づき、何が起きたのかを突き止めようとする。

Chris はこれに膨大な労力を注ぎ込んだ。それができたのは、彼が自分の agent を書いたからでもある。今日では、Claude と MCP サーバー、あるいはログを送り届ける何らかの方法を組み合わせれば、同じことができる。しかし本当に必要なのは、agent がコードを書き終えた直後に自分のサンドボックスを粉々に破壊しないこと、ただそれだけだ。

ギャラクシーブレインな勝利

ここから先の話は、あなたを置いてけぼりにするだろう。なぜ分かるかというと、私のチームの大半も同じように置いてけぼりになっているからだ。彼らのほとんどは、私の考え方を受け入れない。

ソフトウェア開発の本質は、私たちの足元で変わりつつある。そして私たちは、それが最終的にはプロの開発者がソフトウェアを届ける方法の再構成程度のものにしかならない、と自分に言い聞かせているのだと思う。

私には子供がいる。子供たちはデバイスを持っている。私はそれらをある程度コントロールしたい。そこで、同じ立場の多くの人がするように、私は MDM を vibe coding した。

これは Claude と一緒に作った。Sprite 上で動く Go アプリケーションで、バックエンドは SQLite。Sprite がエクスポートする Anycast URL は、そのまま MDM の登録 URL として使える。APNS プッシュ証明書まわりの面倒も全部 Claude に片付けてもらった。ちゃんと動く。

「FTP で PHP ファイルを編集する——俺たちは間違ってなかった。ただ、生まれる時代を間違えただけだ！」

この使い方を始めて一ヶ月になる。一台の Sprite 上で動かしていて、止める理由は一つも見当たらない。これは俺の現実の、重要な問題を解決してくれている。要件が変われば、それに合わせて変わるかもしれない。そのときは Claude に直接直させる。変わらないかもしれない。このアプリにとって、開発環境は本番環境であり、本番環境は開発環境だ。

何百万人向けのアプリをなぜ Sprite で動かすべきでないかは、セットアップの手順を書くときに詳しく話す。ただ、ほとんどのアプリはそもそも何百万人も相手にする必要がない。日常的に使われる重要なアプリの大半は、百万単位のユーザーを持たない。百万単位のユーザーがいるアプリの中に重要なものがあるのは確かだが、多くは市民社会を壊し、俺たちの脳を焼き、チーズバーガー一つに専属ドライバーをつけるだけだ。

人々の実際の問題を本当に解決するアプリは、その問題を抱えている人たちの手に渡る。そして多くの場合、機能開発の門番をする専門のソフトウェア開発ギルドなど必要としない。彼らは要求を出し、そして手に入れる。

俺たち全員が取り組んでいるこの問題は、「プロのソフトウェア開発者を安全に加速する」よりもはるかに大きい。サンドボックスが足を引っ張っている。

使い捨てサンドボックスなんてくたばれ

ここで俺が何かを売りたいのは明らかだ。だからといって、俺が間違っていることにはならない。上の議論こそ、俺が売ろうとしているものを作った理由そのものだ。

*## もう作ってある。

今すぐ何十台もの Sprite を、一秒で作成できる。 Sprite を作成する。→*

ここに至るまでには長い時間がかかった。何年も自分たちを騙してきた。マイクロ VM で本番アプリを水平スケールさせるプラットフォームを作った。その VM は——うまくやれば——起動が速すぎて、かなりまともなコードサンドボックスの代わりに使えてしまうほどだった。だが、それはずっと無理やりな話だった。

Sprite がどう動くかについては、言いたいことが山ほどある。Fly Machines と関係はあるが、要所でまったく違う。まったく新しいストレージスタックを備えている。オーケストレーションの仕組みも違う。Dockerfile はない。

だが今は、ここで俺が言っていることだけを考えてほしい。最終的に Sprite を立ち上げるかどうかに関わらず、こう問う価値はある。どこでもコーディングエージェントを動かせるとして、クラウド上の K8s クラスタにある読み取り専用サンドボックスと、指を鳴らすだけで呼び出せる完全な EC2 インスタンス、どちらに近い方がいいか？

答えは明らかだと思う。サンドボックスの時代は終わった。使い捨てコンピュータの時代が来た。