Fly.io：コンテナをそのまま世界 18 か所に置ける計算基盤

AI エージェントが自分でコードを書き、そのコードを実行する場面が増えている。 生成したスクリプトをブラウザで動かす。データを整形して外部 API に投げる。 ファイルを読んで別のファイルを作る。こうした作業をエージェントに任せるとき、「実行する場所」の設計が問われる。

コードを動かすサーバーは、隣のテナントとカーネルを共有しないほうが安全だ。 エージェントが未検証のコードを走らせるとき、コンテナの分離では心配が残る。 そこで microVM という仕組みが使われる。コンテナ並みの起動速度を保ちながら、仮想マシン並みの分離を確保する技術だ。

Fly.io はその microVM を世界 18 か所に展開している会社だ。2017 年に設立し、当初はエッジのプロキシ・CDN 的な出自を持つ。 2020 年代に Firecracker microVM を土台にした実行基盤へ軸を移し、開発者コミュニティに根づいた。 2024 年には GPU への投資を公に撤収し、2026 年 1 月には永続実行環境の Sprites を発表した。 累計調達は約 $110.5M、2024 年の自己申告売上は $11.2M だ。

以下、プロダクトの構造から順に見ていく。

1. Fly Machines とは何か：microVM を起動させる土台

Fly.io のすべての提供物は、Fly Machines という Firecracker microVM の上に乗る。 Firecracker は AWS がオープンソースで公開した軽量仮想化技術だ。 コンテナ並みの起動速度と、VM のハードウェア分離を両立させる。

一般的な PaaS は複数のアプリを共有 OS 上のコンテナで動かす。Fly Machines は違う。 アプリごとに専用カーネルを持つ microVM を立て、CPU・メモリ・ネットワークを分離する。

具体的な動作を整理すると次のようになる。

• HTTP リクエストを受けたタイミングで microVM を起動（数百ミリ秒級）
• アイドル状態になれば自動停止して課金を止め、次のリクエストで再起動（使わない間は課金ゼロ）
• マルチテナント環境でも隣のテナントと OS を共有しない
• 同一アプリを複数リージョンに置き、Anycast で最寄りのリージョンへ振り分ける
• ローカル NVMe（高速）と分散オブジェクトストレージ（耐久性）の二層でストレージを持つ

この分離特性が、AI エージェント文脈で効くポイントになる。 エージェントが生成した未検証コードを走らせるとき、microVM は隣テナントやホストへの影響を遮断する。 Fly.io が "Run any code fearlessly." を前面に出すのは、この設計の裏付けがある。

参考: Fly Docs: Machines / Firecracker OSS

2. Sprites：使い捨てではなく「育てる sandbox」

2026 年 1 月 14 日に発表した Sprites は、状態を保持する Firecracker microVM だ。 Fly Machines の上に作られ、AI エージェント向けのコード実行基盤として設計されている。

従来の sandbox は「使い捨て」が前提だった。E2B はセッションが最大 24 時間で終了し、Vercel Sandbox は 45 分制限だ。 エージェントはタスクのたびに環境を作り直す。Sprites はその逆を向く。 パッケージを一度入れたら消えない。数日後でも同じ環境で続きから作業できる。

Sprites の主要な仕様を整理する。

• Docker イメージを使わず、1〜12 秒で microVM を作成
• 100GB の永続 root ファイルシステム（NVMe + オブジェクトストレージで耐久）
• 非アクティブ時に自動で待機状態になり、課金停止。状態は保持
• 環境状態をまるごと保存・復元する checkpoint / restore（約 300ms〜1 秒）
• CPU 専用（GPU は非対応）

設計の背景は、「毎回ゼロから環境を構築し直すのはコンピューティング資源の無駄だ」という認識だ。 CEO の Kurt Mackey は "The age of sandboxes is over." と書いた。 「使い捨てから育てる」への転換を差別化軸にした。

この設計は、常時稼働が必要なエージェントとの相性がよい。 Slack の受信を常時監視するボット、定期的にデータを取得して処理するワーカー、夜間にバッチを走らせる自動化スクリプト。 こうした処理はローカルマシンを開けたままにしておく必要がなく、Fly の Machine に置けばよい。 fly.toml で min_machines_running = 1 を設定すると、その Machine は常時起動したまま維持される。 Sprites の 100GB 永続ストレージと組み合わせると、インストールした依存関係や中間ファイルも残り続け、次回の起動オーバーヘッドが小さくなる。

参考: SDxCentral: Fly.io debuts Sprites（2026/1） / Techzine: Fly.io puts AI agents in VMs, not containers / Fly Docs: Autostop/autostart Machines

3. GPU の賭けを撤収した理由

2022 年、Fly.io は GPU Machines（A10 / L40S / A100）を提供し始めた。 当時は「AI インフラ会社になる」という方針だった。 それが 2024 年の公式ブログ "We Were Wrong About GPUs" で大きく変わった。

Kurt Mackey の論旨は率直だった。開発者が AI を使うとき、欲しいのは GPU を自分で回すことではない。 Claude や GPT のような LLM への API 呼び出しだ、という認識だ。 推論に GPU が要るのはモデルプロバイダーであって、API を呼ぶユーザー企業ではない。

結果として Fly.io は GPU を成長ドライバーから外した。L40S は実需があるため維持するが、新規拡張には踏み込まない。 代わりの賭けが Sprites だ。AI エージェントが書いたコードを CPU microVM で安全に走らせる方向に転じた。

転換が示す区別は明確だ。「AI 向けの会社」という立場は変わらないが、その意味が「推論基盤」から「実行・分離基盤」へ移っている。 AI モデルはプロバイダーが動かす。Fly.io はエージェントが生成したコードを安全に走らせる場所を提供する。

参考: Fly Blog: We Were Wrong About GPUs

4. PaaS としての競合と、Fly.io が勝る場面

Fly.io を語るとき、Heroku の後継として比較されることが多い。 実際に競合になるのは Railway と Render だ。どちらも「コードを上げればデプロイまで面倒を見る」という PaaS の使い勝手を重視している。

Railway はダッシュボードの完成度と手軽さが際立つ。Render はマネージド Postgres と予測可能なプラン課金が強い。 Fly.io は VM レベルの制御・世界分散の簡単さ・下り通信費の安さで異なる位置を取る。

下り通信費（クラウドから外に出ていく通信コスト、egress）の差は数字で見える。Fly.io の北米・欧州単価は $0.02/GB だ。 AWS の約 $0.09/GB と比べると 4 分の 1 以下になる。通信量の多いアプリでは、この差がコスト構造に直結する。

Vercel との比較もよくされるが、Fly.io とは対象が異なる。 Vercel は Next.js / フロントエンドに特化したエッジ実行の仕組みだ。 Fly.io はバックエンド・任意言語・任意バイナリを VM ごと動かせる。 Cloudflare Workers は超軽量だが、フル Linux 環境や任意バイナリは動かせない。

Fly.io が明確に向いているのは、世界分散と VM レベルの分離を組み合わせたい場面だ。

開発者体験も差別化要素の一つだ。 fly launch を実行すると、プロジェクトの種類を自動判定して設定ファイル（fly.toml）を生成し、そのままデプロイまで進む。 Dockerfile があれば追加の設定なしにそのイメージでビルドされる。 ビルドはローカルではなく Fly 側のサーバーで行われるため、手元のマシンスペックに依存しない。 デプロイ後は fly logs でリアルタイムのログを確認でき、fly ssh console で稼働中の Machine に直接入れる。 Railway や Render と比べると設定の自由度が高い分、最初の設定ファイル調整が必要な場面はある。 ただし、コードを書いてから本番環境に届くまでの手数は少ない。

参考: Railway 公式 / Render 公式 / Comparing Deployment Platforms 2025 / Fly Docs: fly launch

5. 価格体系：使わない間は課金ゼロ、下り通信費は AWS の 4 分の 1

Fly.io の課金は従量制で、Machine・ストレージ・下り通信・IP を個別に積む。主要な単価を整理する。

項目	単価（2026/6 時点）
shared-cpu-1x / 256MB	$2.02 /月
performance-1x / 2GB	$32.19 /月
performance-4x / 8GB	$128.77 /月
追加 RAM	約 $5 / GB / 30 日
永続ボリューム	$0.15 / GB / 月
下り通信費（北米・欧州）	$0.02 / GB
下り通信費（アジア太平洋）	$0.04 / GB
専用 IPv4	$2 / 月
Machine 予約割引	最大 40% off

この構造のポイントは 3 つある。

第一に、使わない間は課金ゼロになる仕組みだ。アイドル中は Machine が停止するため、リクエストがないときの課金がほぼゼロになる。 小規模サービスやエージェント実行環境との相性がよい。

第二に、下り通信費の安さがある。北米・欧州は $0.02/GB と、AWS の $0.09/GB に比べ 4 分の 1 以下だ。 自前ハードウェアで原価を握っているため、上位 PaaS より価格優位が出せる。

第三に、アジア太平洋の下り通信費は北米・欧州の 2 倍（$0.04/GB）になる点だ。 東京リージョン（nrt）では通信量が多いほどこのコスト差が響く。

参考: Fly Docs: About Pricing / Fly.io Pricing

6. エージェント sandbox 市場での競合と Sprites の位置

Sprites が参入する「AI エージェント向けのコード実行基盤」は、2025〜2026 年にプレイヤーが急増した市場だ。主要な競合を並べて比較する。

プレイヤー	分離モデル	永続性	特徴
E2B	Firecracker microVM	セッション最大 24 時間	エージェント向け SDK、LangChain・Anthropic 連携
Modal	gVisor	セッション制限あり	Python・機械学習バッチに最適化、大規模自動拡張
Vercel Sandbox	Firecracker microVM	最大 45 分	Vercel エコシステム統合、使い捨て前提
Daytona	Docker コンテナ	設定次第	90ms 以下の起動、AI デモ向け
Northflank	Kata / Cloud Hypervisor + gVisor	○	自社クラウド持ち込み対応（BYOC）、GPU 対応、本番向け
Fly.io Sprites	Firecracker microVM	数日以上の永続	チェックポイント / 復元、CPU 専用、育てる実行環境

Sprites の差別化は「永続性」にある。 E2B と Vercel Sandbox は使い捨てを前提とするが、Sprites はエージェントが同じ環境で作業を継続できる。 ただし GPU 非対応のため、モデル推論を自前で走らせるエージェント用途は対象外になる。 Northflank が本番マルチテナント企業向けを狙うのに対し、Sprites は個人開発者・単一エージェント向けの継続的作業環境に絞った設計だ。

この文脈で実用的な使い方が一つある。Claude Code をリモートの Fly Machine 上で動かす構成だ。 Claude Code はインタラクティブ TUI モードであれば、Claude Pro や Max のサブスクリプション認証のまま動作する。 Fly Machine に SSH で入り、そこで claude を起動すれば、API 従量課金ではなくサブスク内の利用枠でエージェントが回る。 Fly 側に発生するのは Machine の計算費用のみで、shared-cpu-1x / 256MB なら月あたり $2.02 の枠内に収まる。 ローカルマシンを閉じても Machine は動き続けるため、長時間のタスクをバックグラウンドで進められる。 なお、claude -p によるスクリプト実行（Agent SDK）は 2026 年 6 月 15 日以降、サブスクとは別枠のクレジットになった。 この方式の対象はインタラクティブセッションに限られる。

参考: Northflank: Top Fly.io Sprites alternatives / E2B 公式 / Claude Code ヘッドレスモードと Agent SDK / Claude Code を Pro・Max プランで使う

7. リスクと課題

Fly.io に対してよく指摘される課題は 3 点ある。

信頼性の評判が、本番採用の最大の障壁だ。 Fly.io Status の履歴には多数のインシデントが記録されており、2024 年 4 月に大規模障害が発生した。 その後、コミュニティで運用の回避策が広く議論された。"Run any code fearlessly." を掲げる以上、基盤の安定性が問われる。

Postgres の手離れの悪さが、DB を預けたい層を Railway や Render へ流す。 Fly.io の Postgres はもともと unmanaged（自己管理）として提供されていた。 公式ドキュメントにも "This Is Not Managed Postgres" と長く明記されていた。 2025 年以降は managed 化が進んでいる。 ただし Supabase が 2025 年 4 月に Fly 上の Postgres を deprecate したことは、課題の象徴として残る。

ユニットエコノミクスの論点もある。評価額 $397M（2023 年 Series C 時点）に対し、2024 年の自己申告売上は $11.2M だ。 自前ハードウェアを抱える計算基盤会社として、SaaS 的な粗利率を取りにくい構造になっている。 Sprites でエージェント向けの継続的な計算消費を獲得する筋が、このギャップを埋める仮説として読める。

参考: Fly.io Status / Supabase: Deprecation of Fly.io Postgres（2025/4）

まとめ：Fly.io を 8 点で整理する

1. 土台は Firecracker microVM：コンテナ並みの起動速度と VM 並みの分離を両立。アプリごとに専用カーネルを持ち、マルチテナントでも隣テナントと OS を共有しない
2. 18 リージョンへの Anycast 分散：同一アプリを複数リージョンに置き、ユーザーを最寄りへ振り分ける。下り通信費は北米・欧州で $0.02/GB と AWS の 4 分の 1 以下
3. Sprites で「育てる実行環境」を打ち出した：2026 年 1 月発表。E2B・Vercel Sandbox の使い捨て前提に対し、状態を保持して数日後も続きから作業できる永続 microVM を差別化軸にした
4. 常時稼働のリモートエージェント基盤として機能する：min_machines_running = 1 で Machine を常時起動に設定すると、定期実行・常時監視・長時間バッチをローカルマシンなしで動かせる。Sprites の永続ストレージと組み合わせると依存関係が維持される
5. flyctl の操作感が開発者体験の軸：fly launch がプロジェクトを自動判定してそのままデプロイまで進む。Dockerfile があれば追加設定なしに動作し、fly logs / fly ssh console で稼働中の Machine に手が届く
6. GPU の賭けを公に撤収した：2024 年の "We Were Wrong About GPUs" で方向転換を明示。推論基盤ではなく実行・分離基盤として AI 市場に向かうと決めた
7. 下り通信費の安さが構造的優位：自前ハードウェアで原価を握る。通信量の多い世界分散アプリで価格優位が出やすい。アジア太平洋は $0.04/GB と北米・欧州の 2 倍になる点は留意が要る
8. 信頼性と Postgres が本番採用の障壁：開発者コミュニティでの評価は高い一方、障害頻度と DB の手離れの悪さが、エンタープライズ採用を遅らせる要因として繰り返し指摘されてきた

---

参考リンク

• Fly.io 公式サイト
• Fly.io Pricing
• Fly Docs: About Pricing
• Fly Docs: Regions
• Fly Blog: We Were Wrong About GPUs
• Fly Blog: Fly.io has GPUs now
• Fly Blog: We Raised A Bunch Of Money（Series C）
• Fly Blog: The Region Consolidation Project
• Fly.io Status
• Fly Docs: This Is Not Managed Postgres
• SDxCentral: Fly.io debuts Sprites（2026/1）
• Techzine: Fly.io puts AI agents in VMs, not containers
• Northflank: Top Fly.io Sprites alternatives
• getLatka: Fly.io revenue（2024）
• Intel Capital: Fly.io Series A/B 発表
• Supabase: Deprecation of Fly.io Postgres（2025/4）
• Comparing Deployment Platforms 2025
• Fly Docs: Autostop/autostart Machines
• Fly Docs: fly launch
• Claude Code ヘッドレスモードと Agent SDK
• Claude Code を Pro・Max プランで使う
• Fly.io Community: High latency from west-jp to NRT region
• Stainless（Anthropic 買収）の SDK 生成とエージェント接続の話