90ミリ秒でAIの実行環境を立ち上げる。Daytonaが見せた「サンドボックスの年」の実力

Claude CodeやCodexにコードを書かせて、そのまま自分のマシンで動かしている人は多い。筆者もそうだった。しかし先月、AIが生成したスクリプトがうっかり.envを読みにいく挙動を見て、これは環境を分けないとまずいと改めて思った。

AIエージェントが書くコードは、人間が書くコードと同じかそれ以上に「何をするかわからない」。モデルが改善されても、生成コードを無条件に本番環境で走らせるリスクは消えない。だからこそ、隔離された実行環境——サンドボックスが必要になる。

そして2026年、このサンドボックスというカテゴリが急速に立ち上がっている。その中心にいるのがDaytonaだ。

「サンドボックスの年」に$24Mを調達

Daytonaは、AIが生成したコードを安全に実行するためのインフラストラクチャを提供するオープンソースプロジェクトだ。GitHubで72,000以上のスターを獲得し、1日あたり85万回の実行をさばいている。月間成長率は74%。

2026年にFirstMark Capital主導で$24M（約36億円）のSeries Aを調達した。Pace Capital、Upfront Ventures、E2VCも参加している。

「2026年はサンドボックスの年だ」——これはAIインフラ界隈でよく聞くフレーズになった。AIエージェントが量産され、自律的にコードを書いて実行する時代に入った以上、そのコードをどこで走らせるかは避けて通れない問題だ。Daytonaはそこに正面から取り組んでいる。

90msの冷間起動が意味すること

Daytonaの最大の売りは起動速度だ。コールドスタートが90ms以下。最適化された構成では27msまで縮まる。

この数字の意味は、AIエージェントの応答フローの中にサンドボックスの起動を挟んでも、ユーザーが待たされないということだ。たとえばClaude Codeがコードを生成し、それを即座にDaytonaのサンドボックスで実行して結果を返す。起動に数秒かかるなら実用にならないが、90msなら会話のリズムを崩さない。

技術的にはDockerコンテナベースで、共有カーネル上に隔離環境を構築する。E2Bが採用するFirecracker microVMのようなハードウェアレベルの隔離ではないが、そのぶん起動が速い。

ステートフルという設計判断

もうひとつの特徴は、サンドボックスがステートフルであること。AIエージェントがパッケージをインストールしたり、ファイルを作成したりすると、その変更が次のセッションにも引き継がれる。

これは地味だが重要だ。多くのサンドボックスはエフェメラル（使い捨て）設計で、セッションが終わるとすべてリセットされる。単発のコード実行なら問題ないが、長いタスクをこなすエージェント——たとえば「このリポジトリを分析して、テストを追加して、CIを通して」というような複合タスク——では、途中の状態を保持できないと話にならない。

Daytonaはここを「ワークスペース」という概念で解決している。Git連携で直接リポジトリをクローンでき、エージェントが作業した結果をそのまま維持できる。

料金体系

料金はシンプルな従量課金だ。

• 無料枠: $200分のコンピュートと5GBのストレージ。クレジットカード不要
• コンピュート: $0.0504/vCPU時間
• メモリ: $0.0162/GiB時間
• セルフホスト版: AGPL-3.0で無料
• Enterprise: カスタム価格、オンプレミス対応

無料枠の$200は、軽い用途なら数ヶ月持つ。$0.0504/vCPU時間はE2Bとほぼ同水準で、AI sandbox市場の中では安い部類に入る。

正直なところ、個人開発者がちょっと試す分には無料枠で十分すぎる。コストが問題になるのは、プロダクション環境で数千回/日の実行を回すケースだ。

Daytona vs E2B——どちらを選ぶか

サンドボックスの二大プレイヤーはDaytonaとE2Bだ。両者の違いを整理する。

隔離方式が根本的に違う。 DaytonaはDockerコンテナ、E2BはFirecracker microVM。microVMは各セッションが独自のカーネルを持つため、カーネルレベルの脆弱性があっても他のセッションに影響しない。セキュリティの厳密さではE2Bに分がある。

起動速度はDaytona。 Daytonaが90ms以下、E2Bが約150ms。実用上の差は小さいが、大量実行時には積み上がる。

リソース上限はE2B。 E2Bは1サンドボックスあたり最大8 vCPU/8 GiB RAM。Daytonaはデフォルトで4 vCPU/8 GB RAM。ただしGPUアクセスが必要ならDaytonaの一択だ。E2BにはGPUオプションがない。

永続性はDaytona。 ステートフルなワークスペースはDaytonaの強み。E2Bはセッションベースの使い捨て設計が基本。

選び方はシンプルだ。レイテンシ重視ならDaytona。隔離の厳密さ重視ならE2B。長時間タスクを走らせるエージェントにはDaytona、単発のコード実行にはE2Bが向いている。

何が実現できるようになるか

Daytonaのようなサンドボックスインフラが当たり前になると、いくつかの可能性が見えてくる。

ひとつは、AIコーディングエージェントの「安全なデプロイ」だ。現状、Claude CodeやCodexが書いたコードを本番に近い環境で検証するには、自前でDocker環境を用意するか、CIパイプラインに流すしかない。Daytonaを挟めば、エージェントが書いたコードを即座に隔離環境でテストし、問題なければマージするフローが数行のAPI呼び出しで構築できる。

もうひとつは、非エンジニアがAIエージェントを使う場面だ。たとえば営業チームが「先月の売上データを分析してグラフを作って」とChatGPTに頼む。そのPythonコードを社内のサーバーで実行するのはリスクがある。Daytonaのサンドボックスに流せば、社内システムに一切触れずに結果だけ受け取れる。ある金融サービス企業では、Claude + Daytonaの組み合わせでSQLクエリの検証時間を8時間から12分に短縮したという事例が報告されている。

さらに、複数のエージェントが並行して作業するマルチエージェント構成では、各エージェントに専用のサンドボックスを割り当てることで、互いの作業を干渉させずに済む。エージェント同士のファイル衝突やパッケージ競合を避けられる。

正直な評価

強い点: Daytonaの起動速度とステートフル設計は、AIエージェント時代のインフラとして理にかなっている。セルフホスト版がAGPL-3.0で無料提供されている点も、エンタープライズの導入障壁を下げている。SDKはPythonとTypeScriptに対応しており、既存のAIツールチェーンとの統合が容易だ。

気になる点: Dockerコンテナベースの隔離は、セキュリティに厳格な環境では不安が残る。カーネルを共有する以上、コンテナエスケープのリスクはゼロではない。金融機関や医療系のプロダクションで使うなら、E2BのmicroVM方式のほうが安心感がある。

もうひとつ、AGPL-3.0ライセンスは企業によっては導入のハードルになる。AGPLはSaaSとして提供する場合にソースコード開示義務が発生するため、自社プロダクトに組み込む場合はEnterprise版のライセンスが必要になるケースが多い。

デフォルトのリソース上限（1 vCPU, 1 GB RAM, 3 GiB disk）は、重い処理には物足りない。組織レベルでは4 vCPU/8 GBまでスケールできるが、大規模なビルドやML推論をサンドボックス内で回すには制約がある。

使うべきタイミング

Daytonaは「AIエージェントを開発している人」と「AIエージェントをプロダクションで運用している人」の両方に刺さる。個人開発者が手元のClaude Codeの出力を安全にテストする用途から、エンタープライズがマルチエージェント基盤の実行レイヤーに組み込む用途まで、レンジが広い。

逆に、コードを書かない人にはほぼ関係ない。あくまで開発者向けのインフラツールだ。

AIが書いたコードを動かす場所をまだ真剣に考えていないなら、Daytonaの無料枠で一度体験してみる価値はある。$200分のクレジットがあれば、ワークフローに組み込んで判断するには十分だ。