AIエージェントに専用の実行環境を渡すとき、VMの起動待ちやリソース設定がボトルネックになりがちです。smol machinesがクラウド版「smol cloud」のベータを公開し、秒単位で仮想コンピュータを用意できる基盤が動き始めました。
この記事では、smol cloudのベータ公開内容と、開発者・エージェント運用者にとっての実用ポイントを整理します。
この記事でわかること
- smol cloudベータで追加された主な機能と料金の考え方
- CPU・メモリを事前設定しなくてよい動的割り当ての仕組み
- smolvm CLIと組み合わせて複数エージェントを分離実行する方法
- ローカル実行や他のサンドボックス基盤との違い
smol cloudベータで何が変わったか
2026年7月3日、smol machinesの開発者であるBinBin氏がXで、smol cloudのベータ公開を告知しました。自分用でもAIエージェント用でも、秒単位で仮想コンピュータを取得できるクラウド基盤です。
従来、smol machinesはローカルで動くマイクロVMツール「smolvm」として知られていました。起動は200ミリ秒未満、ハードウェア分離されたLinux VMを、Dockerデーモンなしで動かせます。smol cloudは、この同じ実行モデルをクラウド上に持ち上げたサービスです。公式サイトでも「ノートPCと同じsmol machineを、クラウドや自前サーバーでも動かせる」と説明されています。
なぜ動的リソース割り当てが重要か
クラウドVMを借りるとき、CPU数やメモリ容量を先に決める必要があるサービスが多いです。エージェントの負荷はタスクごとに変わるため、固定スペックは過剰になりやすく、コストも読みにくくなります。
smol cloudでは、CPU・メモリの事前設定は不要です。利用中の負荷に応じて動的に割り当てられ、上限は現時点で4 vCPU・8 GiB RAMです。ローカル版smolvmでも、virtio balloonによる弾性メモリと、アイドル時にvCPUスレッドをハイパーバイザー側で休止する設計が採用されており、クラウドでも同じ思想が活きています。
主な機能と使いどころ
smol cloudの仮想マシンは、libkrunベースのマイクロVM（microVM）です。コンテナと違い、ワークロードごとに独立したカーネルを持つため、ハードウェアレベルの分離が得られます。公式の比較表では、Firecrackerと同程度の起動速度（125ミリ秒未満）を掲げています。
代表的な用途は次のとおりです。
- AIエージェントのコード実行: 信頼できないコードをホストから切り離して動かす
- 複数エージェントの並列運用: smolvm CLIと統合し、エージェントごとに別クラウドマシンを割り当てる
- Webターミナル経由の操作: ブラウザから仮想コンピュータへ入るデモも公開されている
- ローカルとの切り替え: 同じ
.smolmachineアーティファクトやSDK APIで、ローカル・クラウド・自前ホストを行き来できる
ネットワークはデフォルトでオフにでき、特定ホストだけ許可するegress制御にも対応しています。SSHエージェント転送で秘密鍵をゲストに渡さずgit操作する機能も、ローカル版から引き継がれています。
料金体系
smol cloudベータでは、月あたり5ドルのクレジットが付与されます。課金はアクティブなCPU・メモリ・ディスク使用分のみで、停止中のリソースには課金されない設計です。エージェントを常時起動せず、タスク単位でVMを立ち上げて止める運用と相性がよい料金モデルです。
Python SDK「smolmachines」では、環境変数SMOL_CLOUD_TOKENまたはAPIキー（smk_で始まるトークン）でクラウド接続を指定します。2026年7月4日リリースのsmolvm v1.4.3でも、CLIがSMOL_CLOUD_TOKENを読み取るようになり、CI環境からクラウド操作がしやすくなりました。
使い方の流れ
まずローカルでsmolvmを試し、必要になったらクラウドへ移す流れが基本です。
# smolvmのインストール（macOS / Linux）
curl -sSL https://smolmachines.com/install.sh | bash
# ローカルでエフェメラルVMを実行
smolvm machine run --net --image alpine -- sh -c "echo 'Hello from microVM'"
クラウド接続は、Python SDKでConnectOptions(target="cloud")を指定するか、CLIでクラウド用APIキーを設定します。ローカルとクラウドでMachine.createやmachine.execなどのAPIが共通なので、エージェント側のコード変更を最小限に抑えられます。
数百のエージェントを別々のクラウドマシンで動かす場合、smolvm CLIのマシン管理コマンド（create・start・exec・stop・delete）をエージェントごとに呼び分ける形になります。ローカルでも同じCLIで分離実行できるため、開発時はローカル、本番負荷はクラウドと段階的に移行しやすい構成です。
類似サービスとの違い
AIエージェント向けサンドボックスとしては、E2BやFirecrackerベースの実行環境が知られています。smol machinesの強みは、オープンソースの実行エンジン（Apache-2.0）とクラウドサービスが同じAPIでつながる点です。ローカルで検証した.smolmachineファイルやSmolfile（TOML形式のVM定義）を、そのままクラウド展開の土台にできます。
コンテナと比べると起動はやや遅いものの、カーネル共有がない分、エージェントが生成した未知のコードを走らせる場面では隔離の厚みが増します。DockerイメージをそのままOCI形式で取り込めるため、既存のコンテナ資産も活かせます。
注目すべき背景
smol machinesはY Combinator Spring 2026バッチのスタートアップで、GitHubのsmol-machines/smolvmリポジトリは公開から半年で4000スター超を記録しています。Hacker Newsでも「WASMの約束をLinuxバイナリ互換で実現する」といった評価が寄せられ、エージェント基盤としての需要が背景にあります。
smol cloudベータは、そのローカル実行エンジンにクラウドのスケールと従量課金を載せた一手です。エージェントごとに独立VMを秒単位で用意し、使った分だけ払うモデルは、マルチエージェント運用の実務課題に直接応えます。