見知らぬものに向き直る

Annie Ruygt*

僕らは Fly.io というパブリッククラウドだ。アプリをインターネットに送り出す方法として僕ら自身が一番気に入っているやり方であり、同時に、先端の agent コーディングツールに存分に暴れてもらう場所としても一番気に入っている。この記事は僕らの会社と、これからと、Sprites——agent のためのコンピュータ——についての話だ。今すぐ見に行ける。

この記事はちょっと込み入っている。だから一つ約束してほしい。この書き出しを読み終えたなら、最後まで全部読むこと。これは名誉の問題だ。

数か月前、Theo Browne が動画を出して、「2026 年に新しいアプリをホストするのに最適な場所」をランキングしていた。Theo はたいてい僕らのことを好意的に話してくれる。今回もそうだった。ただ、最後にこう言った。彼が追っているサービスの中で、年内に生き残る自信が一番ないのは僕らだと。

まあ、参った。

Theo の指摘は不意を突かれた。僕らは何四半期も好調が続いていて、その中には会社史上最高の財務実績を上げた月も含まれているからだ。それでもこの言葉が頭から離れなかった。僕らが何をやっていて、会社としてどこへ向かうのかという、まさに急所を突いていた。

正直に言えば、予想できたはずだ。Fly.io はこの一年ずっと走り続けてきたが、僕はどこか気を緩めていて、会社を未解決のアイデンティティ危機の中で燻らせていた。

この先もう少し腹を割った話をするが、じらせはしない。つまりこうだ。またまとまった額を調達した。Sprites の新しいバージョンを出し、会社の焦点を Sprites とそれが解決する問題に絞る。そして Scott Johnston に CEO に来てもらった。

プロダクトマーケットフィット

Fly.io を始めたとき、はっきりした原則が二つあった。今ではたぶん、どちらも大した意味を持たない。

一つ目。インターネットアプリは速いほど使い心地がよく、速くするにはユーザーの近くにデプロイするしかない。これは Ars Technica で長年働く中で学んだことで、Fly.io を始めた動機の一部はこの痒いところを掻くことだった。会社の最初の数年、これが僕らの信条だった。

二つ目。クラウドインフラは複雑すぎる。開発者に必要なのは、AWS のように柔軟で、Heroku のように使いやすいプラットフォームだ。Fly.io を始めた頃、この二つは両立できなかった。今はできる——僕らのところでも、他のところでも。

ここまで読んで、そりゃそうだろ、そんなの当然大事だと君は言う。だが、思っているほど大事ではないと教えてあげる。理由は明白で、今となっては誰もが口にする理由だ。AI がソフトウェア開発を作り変えてしまった。ディンゴが本当に子供を食ったのだ。 † この一文は、この 18 か月のあいだに言うたび、より正しくなっていった。

みんなまだこれを飲み込めていないと思う[†]。コーディング agent を、ただ賢いだけのコンパイラみたいに業界に組み込もうとしている。だが AI がもたらした変化は、C を出すのが Ruby を出すのに変わった、という類のものではない。桁が違う。

Dan Bricklin がスプレッドシートを発明する前、世の中の「Excel ドキュメント」はすべてコンピュータプログラムで、プログラマが書いていた。それが数年で、ビジネスに関わる全員がプログラマになった。使ったのは世界で最も重要なプログラミング言語、スプレッドシートの数式だ。AI も同じことを、もっと大きな規模でやる。ほとんど誰もが、ほとんどどんな種類のコンピュータプログラムでも作れるようになる。

そこで従来のパブリッククラウドインフラを思い浮かべてほしい。僕らは厳格な基準で作られ、煩雑な CI/CD のレールに乗った固定機能のアプリを、何百万人もの観客に届けてきた。だが何百万人もの観客を持つコンピュータプログラムは、何百万人もの読者を持つスプレッドシートと同じくらいすぐ当たり前になる。存在はする。だがそれが標準にはならない。

2020 年型の、主張のはっきりしたパブリッククラウドの設計に賭けるのは、個別化され適応するソフトウェアが実現しないことに賭けるのと同じだ。いい賭けとは思わない。思ったとしても、そんな賭けはしたくない。友達や家族が、僕が全部代わりに作ってやるのを待たずに、コンピュータを思い通りに動かせる世界が欲しい。

Agent は何を欲しがるか

ここで二つ目の立身の原則が出てくる。本気のクラウドインフラは、開発者にとって使いこなすのが難しすぎる。これは今も変わらない。だが、もう重要ではないのは明らかだ。

† むしろ今は、丁寧に磨き上げられた主観的なデフォルト付きの人間向け開発体験を提供するほうが、悪手になりかねない。Agent は何もかもが明確なときに最もよく働く。

ざっくり言えば、もう誰もドキュメントを読まない。新しい CLI を触って試行錯誤しながら使い方を覚えることもない[†]。それは agent の仕事だ。Agent なら Fly.io へのデプロイを一発で決められる。ローカルでサイトを組み立てて、「これを Fly.io で動かして」と言えば、ちゃんと動く。だが agent は AWS へのデプロイも一発で決められる。じゃあ僕らは何をやっているんだ？　何が起きているんだ？

これについては昨年書いた。僕らの最も急成長している顧客が全員ボットだという記事で。その後、すでに作ったものに後付けで設定を書くのをやめ、ボットの顧客が本当に何を欲しがっているのかを突き止めるほうに移った。以下がその結論だ。

最初の話：コーディングエージェントは開発者のワークステーションで動くことを想定している。

二つ目の話：たとえ信頼できるサンドボックスであっても、エージェントを自分の物理的な開発ノートPCで走らせるのは面倒だ。蓋を閉じれば止まってしまうから。今年、蓋を開けたMacBookを抱えて階段を上り下りした人、手を挙げて。もう下ろした？　じゃあ君の家には階段がないんだろう。だから結局みんな、エージェントのサンドボックスをクラウドで走らせるようになる。

三つ目の話：パブリッククラウドはエージェントを走らせるには厄介な場所だ。サーバーは「ペット」と「家畜」に分けると言うけれど、エージェントにとっては家畜ですら約束事が多すぎる。欲しいのは、そうだな、半使い捨ての牛だ。必要なときに現れ、必要なだけ居て、しかも大して金がかからない。だから比喩を書くのは難しい。

今年の初め、うちのチームはシステム工学、いや計算機科学全体における画期的な成果を成し遂げたと思う。半使い捨ての牛を出荷したんだ。名前はSprites。

Spriteの形は少し変わっている。ロボットが本当に欲しがっているもの——そう僕は思っている——にぴったり寄り添った結果だ。何百、何千と素早く作れるが、一つ一つが100GBの永続ディスクを抱えている。クラウドの他のものと同じく従量課金だが、暇なときはメーターが止まる。しかも自分がいつ暇かを見極めるのがうまい。アプリを載せてインターネット経由で同僚に共有することもできる。

この雑多な機能の寄せ集めが、エージェントについてのある主張を形づくっている。業界全体がsandboxに夢中だ。だがロボットが欲しいのはsandboxではない。コンピュータだ。うちの半使い捨ての牛はまさにそれ、エージェント用のコンピュータだ。

*## Spriteは今すぐ作れる

1分ほどで ✨ さあ行こう→*

エージェント用のコンピュータ

Spritesの今回のリリースには満足している。だが正直に言えば、Spritesはもともとskunkworksプロジェクトだった。Fly.ioのメインサイトにすら載せていなかったんだ！　我ながら変な話だ。言い訳をしているわけじゃない。当時はアイデンティティ・クライシスの真っただ中だった。それが晴れて、今後はComputers for Agentsが我が社の重心になる。 †（これがどれだけ本気かを感じたいなら、コードベース全体に対してgit blameを一度やってみてほしい。僕の名前が誰よりも多く出てくる）

Fly MachinesとPlatform As A Serviceの機能群がなくなるわけではない。ただ、SpritesはFly.io内部のごく小さな骨幹チームが作った[†]もので、もうそうではなくなった。

恒例だが、新製品を出すときはいつも、どう作ったかを数千字の技術深掘り記事に書いている。Spritesについても書く。でもこの記事はすでに長いし、他にも話したいことがある。だから今は手短に。

スケーリングとオーケストレーションの裏方仕事は別として、nu-Spritesは二つの大きなサブシステムを導入し、俺たちがやりたいことに関してようやく「機能完備」と呼べる状態に到達した。

一つ目はSprite Block Device（SBD）。初期のSpritesのストレージスタックは、俺が個人的にJuiceFSから引っ張り出したゴブリンじみた装置で、Ben JohnsonのLitestream経由でうちのシステムにつないでいた。次の知らせを聞けば喜ぶはずだ：BenとTim Newshamがスタック全体を竜骨だけになるまで解体し、作り直した。より速く、より信頼性が高く、それでいてインスタントcheckpointと復元はそのままできる。

さらに重要なのは、SBDがdrive forkingを可能にしたことだ。テンプレートのSpriteを一つ作れば、何百万回でも効率よくクローンできる。

Spritesのもう一つの重要な新要素がConnectors。Connectorsは、コアプラットフォームを守るための俺たちの仕事の上に成り立っている。Spriteが他のシステムに対して認証済みのリクエストを送れるようにしつつ、エージェントに漏洩可能な有用情報を一切渡さない。Connectorsのセキュリティ特性は面白いし、アカウントとAPI keyを手動で管理するよりずっと快適だ。

これらは最も要望の多かった機能だ。そしてこれがあるからこそ、多くのエージェント企業が、うちの専用製品のリリースから数か月たった今もFly Machinesを使い続けている。だからこの賭けに出る：Transformerモデル以上の衝撃を計算機科学に与えるようなエイリアン技術でも出てこない限り、Spritesは新規顧客にとって最良の選択であり、既存顧客のかなりの部分にとってもそうだ。というわけで：

*## Fancy Sprite Beta

自己複製する奇妙なベータ版Spriteが欲しい？　足の指くらいなら用意できるよ。✨ ベータに参加 →*

辞めました

前々からくすぶっていたことだが、Fly.ioの現在の段階で、CEOとして俺が搾り出せるものはほぼ搾り出し切った。だからもうやらない。

スタートアップの最初の数年、君がやっているのは実質的に研究プロジェクトだ。実験に駆動された、product-market fitを探す探検だ。ここで働いたことのある人なら証言できるだろう、俺たちは何十ものことを試した。マネージドでないPostgres（絶対にやるな）からグローバルCDN、ユーザー空間WireGuardまで。会社のもっと深いところでは、ボトムアップのエンジニアリング組織を作り、プロダクトロードマップを置かず、十数か国に散らばる全リモートチームを組んだ。

実験がうまくいくこともあれば、learning opportunitiesこともある。この8年間、そうした実験を回すことが僕の生活のすべてだった。だが Fly.io は、もうこういう研究プロジェクトを必要としていない。

2025年にまでさかのぼる数か月間、僕は Scott Johnston と話し続けてきた。彼が指揮を執ったら Fly.io はどうなるか、という話だ。Scott はかつて Docker の CEO で、Docker を極めて厳しい時期——Docker 自身のエンタープライズ顧客と開発者の間でアイデンティティ・クライシスが起きたところから、最終的にビジネスを大成功させるまで——導いた。Fly.io の株主として、Fly.io が今いるライフサイクルの段階を踏まえると、僕は自分のやり方よりも彼のやり方が好みだ。Fly.io の CEO としても、自分でやるより彼にやってほしい。話をまとめるのにかなり時間がかかったが、最終的に取締役会と僕が彼を説得して、このポジションを引き受けてもらった。

こういう記事はこの辺りで、なぜ Scott が Fly.io に完璧な人材なのかを説明し、彼の輝かしい経歴を振り返るのがお決まりだ。確かに彼は完璧だし、経歴も本当にすごい。でもそんなことはもう皆知っているし、書いても退屈なだけだ。Scott は自己紹介したいときは自分でやればいい。彼は恥ずかしがるタイプじゃない。

というわけで、賢い、すでにイグジット済みの創業者 CEO がみんなやることをやろうと思う。顧問に転じて、プロダクトデザインの議論にランダムに降ってくる（これが僕の仕事の楽しい部分だ）。そして取締役の席から Scott を煩わせる——彼が今進めている仕事は、（僕にとっては）自分の職務の中でも楽しくない部分で、しかも彼のほうが上手い。

Scott が詳しく話すに違いないことの一つが、ちょうど完了したばかりの資金調達ラウンドだ。これも Theo Browne が動画で指摘していたことの一つだ（怒ってないよ、怒ってるように聞こえる？）——僕らは何年も資金調達を発表していなかった。答えはこうだ。僕らはめちゃくちゃ大きな金額を調達した。しかもそれ以上は必要としていない。当初の計画通りに進んでいれば、AI が地面を引き裂いて僕ら全員を丸呑みにしていなければ、永遠に追加調達は不要、という瀬戸際にずっと立っていた。でも明らかに、今はゲームが変わった。

変わる、変わる、変わる

聞いてくれ、これがどんな反応を呼ぶかは分かっている。誰も怒らせない記事を書くこともできた。でも、誰も怒らせずにしかも読む価値のある文章にする方法を、僕は知らない。

僕らはこの業界の未来について、非常に具体的で、おそらく意見が真っ二つに割れる賭けをした。数年以内に、agent がほぼすべてのソフトウェアの構築とリリースのされ方を決めるようになる。ソフトウェアははるかにパーソナルになり、対象はより小さくなり、はるかに柔軟で、移ろいやすくなる。

このすべてに僕はわくわくしている。こんな転換期にこの領域にいられるなんて、少し恐縮してしまう。ただ、この変化が業界の他のプロフェッショナルたちをどれほど不安にさせているかが見えていないなら、僕は目が見えていないということだ。

今年の半ばまでに、僕らは二つの道のどちらかを選べた。

一つ目の道：これまで拡張し磨き続けてきたもの——人間向けに設計された、固定機能のフルスタックアプリケーションのプラットフォーム——に注力し続ける。
二つ目の道：agent がソフトウェアを駆動する近未来に合ったプロダクトを、全力で調整し磨き上げる。

スタートアップで最も危険な五つの単語は「¿Por qué no los dos?」だ。どちらか一方をやる。両方に足をかけて、中途半端にやることはしない。失敗するなら、全力で失敗する。とはいえ、これからはほとんど、ではなく大半しかできないだろうと予想している。

Fly.io のこの段階で、チームと、会社と、顧客の一群を率いるのは本当に楽なことじゃない。優先順位に関する大きな決断を、僕らは何か月も先送りしてきた。Theo、君はそれに気づいていた。いい指摘だ！もっと速く、もっと明確に決められたはずだ。なのに僕は Sprites を作りに行った。Sprites は、僕らがずっと直面してきた問いに答えてくれた。時間をかけて作ったことを嬉しく思うし、それを僕らのコアビジネスにするために Scott を招けたことも嬉しく思う。