ハクソク

世界を動かす技術を、日本語で。

Launch HN: Freestyle – コーディングエージェントのためのサンドボックス

49日前原文(freestyle.sh)

概要

  • Freestyle はAIエージェント向けの強力なクラウドサンドボックスを提供
  • 完全なLinux仮想マシン とリアルなroot権限を実現
  • Git連携・Webhooks・高速スナップショット など豊富な機能
  • 独自のベアメタルインフラ で高性能・低遅延を実現
  • 無料トライアル で手軽に開始可能

Freestyle：AIエージェントのための次世代クラウドサンドボックス

  • Freestyle はAIエージェントが利用するための 高性能サンドボックス を提供
  • EC2互換性 を持ち、AIエージェントから見てシームレスな環境構築が可能
  • 数万台規模のエージェント同時稼働 を想定したインフラ設計
  • Gitリポジトリ管理 や Webhooks による柔軟なデプロイフロー
    • リポジトリ単位で ブランチ・パス・イベント種別 によるWebhookフィルタリング
  • GitHubとの双方向同期 に対応
  • Freestyle Deployments によるプッシュデプロイ、またはVMへのクローンが可能

サンドボックスの特徴と技術的優位性

  • コンテナではなく、完全なLinux VM （Debianベース、systemd init採用）
  • 本物のroot権限、eBPFやFuseなど ハードウェア仮想化 フルサポート
  • ネスト仮想化 ：VM内でさらにVMやDockerを起動可能
  • 複数ユーザー・グループ・systemdサービス をVM内で完全分離
  • Linuxのフルネットワークスタック を利用可能
  • サンドボックスの高速起動 （約500msでVM起動）
  • メモリごとフォーク ：
    • サンドボックス全体の状態（アニメーション中のブラウザ、Minecraftサーバー等）をそのまま複製
    • スナップショット保存・復元も対応
  • 独自ベアメタルラック を利用し、クラウドノード間移動によるパフォーマンス低下を回避
  • ハードウェアコスト最適化 ：Google CloudやAWSのベアメタルと同等コストで自社調達
  • 人間の開発ループをAI大規模多重化環境で再現 するためのインフラ構築方針

利用開始・サポート体制

  • 無料トライアル でクレジットカード不要
  • バグ報告歓迎 ：Debian上で期待通り動作しない場合はフィードバック受付
  • 公式デモ （https://www.loom.com/share/8b3d294d515442f296aecde1f42f5524）で起動速度を確認可能
  • Ben と Jacob による創業、AI時代の開発基盤を牽引するスタートアップ

まとめ

  • Freestyle はAIエージェント向けに 最強の仮想開発環境 を目指す
  • 高速・高性能・柔軟性 を兼ね備えたクラウドサンドボックスの提供
  • 今後のAI開発・運用基盤のスタンダード となる可能性

Hackerたちの意見

ModalやDaytona、Blaxel、E2B、Vercelなどの他のプロバイダーと比べて、どんな感じなのか知りたいな。多くのエージェントビルダーも同じ疑問を持ってると思う。比較しやすいように、機能やパフォーマンスの比較マトリックスを提供してもらえる？

└

みんなの違いについて深掘りした記事を書いてるんだ。Freestyleの目標は、みんなの中で最もパワフルでEC2に近い存在になることだと思ってる。DaytonaはSysbox（https://github.com/nestybox/sysbox）で動いてるけど、VMっぽいものの、低レベルのことをやると問題が出ることがある。ModalはGPUサポートがある唯一のプロバイダーだね。Blaxelはまだ自分では試してないけど。E2BとVercelはどちらも素晴らしいハードウェア仮想化の「サンドボックス」で、Freestyle VMSはユーザーからのフィードバックを基に作られてるんだ。期待してたことが既存のサンドボックスでできなかったっていう意見が多かったから。いい例としては、Freestyleは上記の中で唯一（Blaxelは試してないけど）ユーザーがブートディスクにアクセスできたり、VMを再起動できるようにしてる点だね。

└

あと、fly.ioのスプライトについても。

└

現在使ってるexe.devとの比較にも興味があるな。

メモリフォークを使ってサブ秒のスタートとフォークタイムを実現するのはかなりの技術的課題だよね。そのレベルの状態転送と迅速なプロビジョニングを達成するのは大変だと思う。「EC2っぽい」っていうのは多くの人に伝わるけど、ベアメタルでやるとクラウド仮想化の実際の限界が見えてくる。高パフォーマンスで複雑なワークロードには、クラウドの抽象化がどこで役立つか、どこでオーバーヘッドを増やすかを理解してるってことだね。この特定のユースケースでハードウェアを所有するコストの議論も、エージェント環境が求めるスケールを考えると納得できる。サンドボックスは実質的にオープンな攻撃面だから、メインのVPCに置かないように設計するのは最初から安全な判断だと思う。

すごく興味あるよ。いろいろ考えて努力してるみたいだけど、ちょっと理解できてないかも。サンドボックスって言うと、隔離された実行環境を思い浮かべるんだけど、フォークするサンドボックスって何をもたらしてくれるの？あなたのサンドボックスは一般的に何を提供してくれるの？これは最善の意図で言ってるんだけど、抽象的じゃない、もっと具体的なユースケースの例が欲しいな。最終的な目標は何なの？

└

そう、隔離は正しいよ。サンドボックスをフォークすると、隔離された環境の正確な複製が複数できるんだ。コーディングエージェントが10個のアイデアを持ってるとき、それを正しく評価するには、隔離された状態で評価できる必要がある。ウェブサイトテストエージェントを作っていて、ウェブサイトの途中でフォームが半分埋まっててセッションが進行中のときに、2つのことを隔離してテストしたいと思ったら、フォークするのが唯一の方法なんだ。これが次世代の開発サイクルを支えることを想像してる。「AIエージェント、これらの10個のことを試して、どれが一番良いか教えて」ってね。AIが環境を10回フォークして、10個の正確なコピーを作って、それぞれで実行して評価して、最良の選択肢を取るって感じ。

└

同意するよ、一番興味があるのは君が言ってた隔離された実行環境だね。自動操縦で動くエージェントは強力だ。開発者権限と証明書を持ったマシンで無監視で動くエージェントが、攻撃者の代わりに行動するように影響を受ける可能性があるのは恐ろしいよ。

仕事で普通のDockerイメージを使って似たようなものを作ったことがあるんだけど、もう少しあなたのバリュープロポジションを理解する手助けをしてもらえる？メモリフォークはクールな技術的成果に見えるけど、ユーザーとしての私にどう利益をもたらすのかがわからない。AIに全てを任せるなら、決定論的なビルドの方が重要だから、AIが問題に取り組めるようにしたいんだ。

└

まず、MicroVMはコンテナとは違うし、コンテナは安全な隔離システムじゃないよ。信頼できないコンテナをノードで動かすのは、余分な強化なしではやらない方がいい。メモリフォークは、AIアプリビルダーや初動対応アプリケーションのために元々発明されたんだ。これらのアプリは即座に動くことが超重要だからね（bun devを動かすのと、すでにdevサーバーが動いてるのとの違い）。でも、これはもっと一般的に適用できるよ。Postgresがそのいい例だね。Postgresの下でファイルシステムをフォークしても、一貫性は得られない。ブラウザの状態や変なサーバーの状態、メモリに存在するもの全般も同じことが言える。メモリフォークは、実際に何が起きているかを一瞬でスナップショットしながら、すごいパフォーマンス向上をもたらすんだ。

これすごいね！特にスナップショット機能は、長時間動くエージェントには重要だよ。私たちはエージェントを耐久性のある実行ハーネス（TemporalやDBOSに似たもの）で動かしてるから、実行後に状態をスナップショットして、失敗時に復元・再実行できるようにするためのサンドボックスアプローチが必要だったんだ。AgentFSを使ってファイルシステムのスナップショットを作るlocalsandbox [0]を作ったけど、私たちのソリューションはFreestyleとは違うユースケースを想定してるんだ。エージェントのコード実行をローカルで行うための、シンプルなFS + コード実行だよ。フルOSを動かしてないから、機能は少ないけど、エージェントの実行をローカルで行いたい場合にはシンプルで使いやすいんだ。フォークできる機能は本当に面白いね。私が想像できる主なユースケースは、ユーザーがフォークする会話や並行するサブエージェントかな。他に何かユースケースを見たことある？ [0] https://github.com/coplane/localsandbox

└

エッジケースの決定論的テスト。サービスを動かしているときの変なエッジケースを再現するのは本当に難しいけど、もしそれを作れるなら、まさにそのままスナップショットできるよ。

わぁ、メモリとディスクスペースをこんなに早くフォークするのは面白いね！これは競合他社では見たことがないよ。もしマシンが自分自身をフォークできるなら、ウェブサイトのUIテストをあらゆる意思決定ポイントでフォークして、すごく面白い自動フォークワークフローができるかもしれない。最近、コンピュータや車を制御するために動画だけを使ったモデルの名前を忘れちゃったけど、彼らはこれを使って銀行のインターフェースをフォークして、すごい数のUI状態の変化を生み出す印象的なデモをしてたよ。

└

それが私の期待してることだよ！

実際にebpfとxdpをサポートしてる数少ない一人だと思う。低レベルのものを作るときには必要だしね。それに、ベアメタルのセットアップはまるで異次元だよ（笑）。

└

ありがとう、すごく大変だった（笑）。

これって https://instavm.io/ に似てるの？

└

使ったことはないけど、VMプロバイダーの変なところは、実際の実行に全てがかかってるってことだよね。ここのサービスはコンセプトとしては良さそうだけど、ちゃんとどう動くのかはあんまり知らないな。

いい仕事だね。ただ、50の同時VMはそんなに多くないよ。似たような制限は他のクラウドプロバイダーにもあるけど、AWSだけはコストが高くて遅いかも。今年の初めに、自分たちでやることにしたんだ。特別なことはないよ。X台のマシンをウォームプールに置いてる。全てはファイアクラックVMのクラスターで支えられてる。気にするブートタイムはないし、プールが健康なら新しいサンドボックスは瞬時にVMを得られるんだ。

└

50は重くないよ、重いのは1000のVMで、1秒で50を一時停止したり復活させたりできるやつだね。まあ、一般的には、こういうのを手動でやるのは50VMの規模ではうまくいくけど、数百や数千に達するとかなり難しくなるよ。

└

アプローチを共有してくれてありがとう！ > 特別なことはないよ。X台のマシンをウォームプールに置いてる。ここでのユニットエコノミクスをもっと理解したいな。特に、コストが意味のある要素かどうか。そう聞く理由は、多くのスタートアップが冷却/ブートスタートの時間を減らすために技術の最適化に重きを置いているから。君が指摘したように、ウォームプールのVMを維持することで知覚されるレイテンシーも改善できる。だから、より深い技術的最適化に投資する方が効果的なのか、ウォームプールを維持して冷スタート問題に対処する方がいいのかを判断しようとしてるんだ。

今は軽量VM（Proxmoxコンテナ）とgitワークツリーを使ってる。既存のVMを数秒でフォークできるよ。君のソリューションを使うことで何が得られるのか、いまいち分からないな。

└

Proxmoxのフォークが数秒でできるのは奇跡だね！これらは大規模で運用する場合や、数百を動かしたくなったときにだけ、より良い価値があるかもしれないね。