- 好調な業績にもかかわらず事業アイデンティティが揺らいだため、Fly.ioは追加資金を調達し、元Docker CEOのScott Johnstonに経営を託し、Spritesを中核事業へ転換した
- AIによって誰もがカスタムソフトウェアを作れるようになる中、ユーザーの近くにデプロイするパブリッククラウドや、人間の開発者中心の使いやすさだけでは差別化が難しくなった
- Spritesは、必要なときに数百・数千個を生成して長期間維持できるエージェント用コンピュータで、それぞれ100GBの永続ディスクと、アイドル時には課金が止まる従量課金を提供する
- 新しいSpritesには、より高速で安定したSprite Block Device、ディスクフォーク、認証情報を露出せずに外部システムを呼び出すConnectorsが追加された
- Fly.ioは、人間が設計した固定機能のアプリケーションプラットフォームとエージェント中心の未来を同時に追うのではなく後者に集中する一方、Fly Machinesと既存のPaaS機能は継続して維持する
好調な業績の中で露呈したアイデンティティ危機
- Theo Browneは2026年に新しいアプリケーションをホスティングするのに最適な場所を評価する中でFly.ioを好意的に取り上げたが、自分が見ているプロバイダーの中で年末まで存続する可能性を最も確信しにくいとも評価した
- 当時Fly.ioは、会社史上最高の財務実績を含む好調な四半期業績を続けていたが、何を作り、どこへ向かうのかというアイデンティティの問題は未解決のままだった
- Fly.ioは相当額の追加資金を調達し、Spritesの新バージョンをリリースして会社の力を集中させる一方、Scott JohnstonをCEOに任命した
既存のプロダクト・マーケットフィットの前提が変わる
- Fly.ioは2つの原則から出発した
- インターネットアプリケーションはユーザーの近くにデプロイするほど速くなる
- 複雑なクラウドインフラの代わりに、開発者へAWSの柔軟性とHerokuの使いやすさを併せて提供すべきである
- 2つの原則はいまも重要だが、AIがソフトウェア開発を変える中で、以前ほど決定的な要素ではなくなった
- コーディングエージェントを、より賢いコンパイラのように既存の開発プロセスへ統合するだけでは、変化の大きさを捉えにくい
- スプレッドシートが登場する前は、現在のExcel文書に相当する作業もプログラマーが作ったプログラムでなければならなかったが、スプレッドシートの数式は無数の業務担当者をプログラマーに変えた
- AIはこれよりさらに大きな変化を起こし、ほぼ誰もがほぼあらゆる種類のプログラムを作れる方向へ進んでいる
- 既存のパブリッククラウドは、厳格な標準とCI/CD手順を経た固定機能アプリケーションを数百万人へ配布するよう設計されている
- 今後も数百万人のユーザーを対象にするプログラムは存在するだろうが、数百万人の読者が見るスプレッドシートのように、それが一般的な形とは限らない
- 2020年式のパブリッククラウド設計に賭け続けることは、パーソナライズされ適応するソフトウェアの普及に逆張りするようなものだ
- Fly.ioは、友人や家族が開発者を待たずにコンピュータで望むことを自分で実行できる世界を選んだ
人間の開発者体験よりエージェントの要求
- クラウドインフラが開発者にとって難しいという問題は残っているが、エージェントが作業を代行するにつれ、綿密に設計された人間向け開発者体験の重要性は低下する
- 明示的な環境でよりうまく動くエージェントにとって、強い意見を持つデフォルト値や厳選された開発者体験は、むしろ不利になる可能性もある
- 人々はドキュメントを読み、新しいCLIを試行錯誤で覚える代わりに、エージェントに任せ始めている
- エージェントはローカルで作ったサイトをFly.ioへデプロイする依頼を一度で処理できるが、AWSへのデプロイも一度で処理できるため、従来の使いやすさだけでは差別化しにくい
- 最も速く成長している顧客がロボットだという観察の後、Fly.ioは既存製品をエージェント向けに再解釈するのではなく、エージェントが実際に望む環境を探し始めた
エージェントが望むコンピュータ
- コーディングエージェントは基本的に開発者のワークステーション上で実行されるよう作られている
- 信頼できるサンドボックスであっても物理的なノートPC上で実行すれば、ふたを閉じた瞬間に作業が止まるため、ユーザーは結局エージェントのサンドボックスをクラウドへ移すことになる
- 既存のパブリッククラウドサーバーは、エージェントの作業に対して過度に大きなコミットメントを要求する
- 従来のペット型サーバーや家畜型サーバーよりも一時的でなければならない
- 望む瞬間に生成し、必要な期間だけ維持しながら、低コストで運用できなければならない
- Spritesは、こうした要求に合わせた半使い捨てコンピュータである
- 数百または数千個を素早く生成できる
- 各Spriteに100GBの永続ディスクが提供される
- 使用量に応じて課金されるが、何もしていないときは計量が止まり、アイドル状態を自ら判断する
- アプリケーションをホスティングし、インターネット経由で同僚と共有できる
- 業界はサンドボックスに注目しているが、エージェントに必要なのはサンドボックスではなく、永続性と実用性を備えたコンピュータである
- Spritesをすぐに生成して直接使える
Spritesを会社の中心へ転換
- 初期のSpritesは、Fly.io内部の小規模な非公式チームが作ったプロジェクトで、Fly.ioのメインWebサイトでホストされてもいなかった
- 今後は**エージェント用コンピュータ（Computers for Agents）**が会社の中核的な焦点となり、Spritesももはや少人数だけが担当するプロジェクトではない
- Fly Machinesと既存のPlatform as a Service（PaaS）機能は廃止せず、引き続き提供する
- 新しいSpritesはスケーリングとオーケストレーションを改善し、2つの主要サブシステムを導入して、目標としていた機能構成を完成させた
Sprite Block Deviceとディスクフォーク
- 既存のストレージスタックはJuiceFSを基盤に作り、Litestreamを接続した構成だった
- Ben JohnsonとTim Newshamがストレージスタックを基礎から再構築した**Sprite Block Device（SBD）**は、以前より高速で安定しており、即時チェックポイント・復元機能も維持している
- SBDの中核的な拡張であるドライブフォークを使うと、テンプレートSpriteを1つ作った後、それを効率よく何百万回も複製できる
認証情報の露出を防ぐConnectors
- Connectorsは、Fly.ioの中核プラットフォームを保護するために開発したトークン化されたトークンを基盤にしている
- Spriteが他のシステムへ認証済みリクエストを送る一方で、エージェントには漏えいし得る認証情報を直接与えないよう設計されている
- アカウントとAPIキーを手動で管理する方式より使いやすい
- SBDの複製機能とConnectorsは顧客から最も多く要望された機能であり、専用エージェント製品のリリース後も多くのエージェント企業がFly Machinesを使い続けた理由でもある
- Transformerモデルよりさらに見慣れない技術変化が登場しない限り、Spritesは将来の顧客と既存顧客のかなりの割合に適していると判断し、新ベータを提供する
創業者CEOの退任
- 創業初期の8年間、Fly.ioはプロダクト・マーケットフィットを探す実験組織として運営された
- マネージドではないPostgres、グローバルCDN、ユーザーモードWireGuardなど、数十種類を試した
- ボトムアップ型のエンジニアリング組織を作り、プロダクトロードマップを避け、12を超える国で働く完全リモートチームを構成した
- 一部の実験は成果を上げ、他の実験は学習の機会になったが、現在の段階のFly.ioにはこの種の科学プロジェクトはもはや必要ない
- 創業者はCEOとして提供できる強みをほとんど使い切ったと判断し、退任した
Scott JohnstonのCEO就任
- 2025年から数か月にわたり、Scott JohnstonにFly.ioの意思決定を任せる案を議論した
- ScottはDocker CEO時代、企業市場と開発者市場の間のアイデンティティ危機から始まった困難な時期を率い、その後事業を大きく成長させた
- Fly.ioの株主であり当時CEOだった創業者は、現在の会社の段階には自分のやり方よりScottの運営手法の方が適していると判断し、取締役会とともに彼を説得した
- 創業者はアドバイザー兼取締役として残り、製品設計の議論に参加し、Scottは事業運営と実行を担う
新戦略のための追加資金
- Fly.ioは数年間、新規投資の調達を発表していなかったが、以前に大規模な資金を調達しており、従来計画なら追加調達が不要な水準で運営してきた
- AIによって従来計画が変わったため、新戦略を推進するための追加資金を調達したが、具体的な規模や条件は公開していない
- Scott Johnstonが今後、資金調達の内容を別途取り上げる予定である
2つの未来のうち1つを選択
- Fly.ioは、数年以内にエージェントがほぼすべてのソフトウェアの構築とデプロイ方法を決定するようになると見ている
- ソフトウェアはよりパーソナライズされ、対象ユーザーはより小さくなり、形態はより柔軟で流動的になると見ている
- こうした変化は期待を抱かせる一方で、業界関係者を不安にさせてもいる
- 会社には2つの選択肢があった
- 人間が設計した固定機能のフルスタックアプリケーションプラットフォームを拡張・改善し続ける
- エージェント中心の近い未来に合う製品を精緻に完成させる
- スタートアップが2つの方向を同時に追えば、どちらにも十分集中しにくいため、Fly.ioはエージェント中心の製品を選んだ
- 数か月間先送りされていた優先順位の決定をSpritesが解消し、Scott JohnstonはこれをFly.ioの中核事業へ転換する役割を担う
1件のコメント
Hacker News の意見
Sprites の抽象化は美しいが、30年の開発経験の中で、これほどバグの多いインフラ製品は初めてだった。
データがしょっちゅう消え、接続不能なゾンビ状態になり、システムの半分は Sprite が正常だと報告する一方で、残りは死んでいると判断し、スナップショットすら読み込めなかった。
昼食中や一晩の間、さらには作業中でさえ成果物が消え、2週間で諦めた。ターミナル履歴を掘り返して、死んだ Sprite から作業物をコピーして救い出す必要があった。
実行した Sprite の半分以上で問題が起きたように思う。コンセプトは素晴らしいので、安定性を確保してほしい。
ただし、ここ2か月ほどはずっと安定してきたように見える。
数年前の Fly.io も実用途には厳しいほどバグが多かったが、今ではいくつかの本番ワークロードを非常に安定して運用できているので、Sprites も同じ道をたどるだろうと思っていたし、実際そうなりつつある。
CEO がひどい運営をしてきたという点では、辞任はむしろ良いことかもしれない。
理由も、深刻なインターフェースのバグとデータ損失、ひどいサポートだった。
ただし、試用期間中に実際の会社ドメインを使わず、Fortune 200企業であることも明かしていなかったため、サポート品質に影響した可能性はある。
Elixir 開発者として Fly.io の成功を願っていたが、優れたエンジニアリングと運用安定性の間でバランスを見つけられず、二度も離れざるを得なかった。
しばらくの間、世界規模の障害が起きてもステータスページはすべて正常と表示され、フォーラム投稿を見て初めて障害を知る状況だった。会社は、問題解決に忙しくステータスを更新できなかったと答えた。
その後ステータスページを更新し始めたが、「特定リージョンの障害」の後、何時間も音沙汰がないことが繰り返された。
有料サポートが出るとすぐ加入したが、迅速な応答を約束したメールアドレスはほとんど誰も確認しておらず、大規模障害を報告しても、翌日や数日後になってようやく「どのような問題がありますか？」という返事が来た。
こうしたことがまれならカスタマーサポートの問題で済んだだろうが、ある時期はほぼ毎月重大な障害を経験し、少し安定したように見えてはまた繰り返し崩れた。
結局すべてのサービスをセルフホストに戻した。手間はかかるが稼働時間は大幅に改善し、障害が起きても原因を自分で把握できるので、はるかに苦痛が少ない。
ホスティング事業を続けるなら責任を受け入れ、運用に予算を投入すべきだ。そうでなければホスティングをやめて、もう一つの HashiCorp になるほうがよい。
会社全体を Sprites に集中させるのは、Fly.io が自殺を選んだように見える。
AI サンドボックスはすでに競争が激しく、事実上コモディティ化している。新 CEO は創造的なビジョンを犠牲にして収益に集中する可能性が高い。
この判断が間違っていることを願う。
コンテナは使い捨てで、作業を簡単に再実行できるため、データ保持もそれほど重要ではない。エージェントに直接ベアメタル上で環境を立ち上げさせることもできる。
エージェントはほとんど GPU を待っているので、似たワークロード同士にメモリ重複排除を適用すれば、少ないハードウェアでも数百個を実行できる。
AWS はすでにエージェントのためのクラウドであり、エージェントと Infrastructure as Code（IaC）を使えば AWS の複雑さも大きく減る。
いま価値があるのは、オーケストレーションやモデルサービング層のハードウェアマージンを数 bp 争うことではなく、エージェントがよりよい判断を下せるよう助けるツールを作ることだ。
最近の LLM の発展により、個人だけでなく企業や組織もアイデンティティ危機を経験しており、この文章はその好例だ。
AI が一度に作り出せる製品や会社を、作り続ける価値があるのかは疑問だ。
反対に、以前は不可能だった、より大きく野心的なことに挑戦するよう迫るという興味深い結果もある。
クリーンエネルギーのように、何百人が同じことをしても人類に継続的な純益をもたらす分野に、もっと多くの人が飛び込んでほしい。
Docker が本当に事業を爆発的に成長させたという意味なのか、それとも Boeing のようにドアが吹き飛んだという意味なのか疑問だ。
Bryan Cantrill による関連評価も興味深い: https://news.ycombinator.com/item?id=28460504
Sprites は、投資を受けたスタートアップというより、友人何人かで運営する小規模で安定した事業に向いているように見える。
開発者なら、すでに Docker や Podman で十分うまく解決できる。
おばあちゃんやおじいちゃんまでアプリを作るような巨大な新規市場は Lovable のようなサービスが取るだろうし、非開発者が Sprites を使う可能性は低い。
結局、既存開発者の一部しか獲得できない。
OpenCode や Claude Code などがセキュリティ上の惨事だという話が毎日出ているのに、隔離がそんなに簡単なら、なぜもっと多くの開発者がコンテナを使わず、こうした事故も起き続けるのか疑問だ。
コードをより速く書くためという理由で、自宅の環境をリモート企業の LLM に開放したくないのでエージェントコーディングは避けているが、複数のソースファイルをまとめて分析する必要が出てくる時点から、明らかに損をしている。
会社全体の方向性を Sprites に変えた直後にすぐ去るのは、荒っぽく感じる。
少なくとも新 CEO が自分で方向を定めて勝負する機会は与えるべきだ。
Sprites に会社の未来を賭けるだけの価値があるかは疑問で、最終判断は新 CEO 次第だ。
長期的には、こうした隔離実行環境は Claude Code や Codex に組み込まれるか、AI 企業が直接提供する可能性が高い。
Git worktree も似た問題を解決するが、Sprites を使えばインスタンスを素早く立ち上げてサービスを実行し、その後コーディングエージェントに渡して機能を改善させられる。
複数のエージェントを並列に実行して結果の一つを選べるし、ポート数やローカル CPU の制約も受けない。
RAM 不足が当面続くことまで考えると、Sprites で数百個のエージェントを実行できる。
Fly.io が直して集中すべきなのは信頼性だ。
Docker コンテナを立ち上げるとすぐにアプリが動く方式は気に入っていたが、サービスは何度も停止し、価格も非常に高かった。
今は単に VPS を使っている。