なぜ宣言的構成が必要か
前ページで見たとおり、smolvmはCLIフラグだけでも十分に操作できます。しかし実務では、ネットワーク設定・ボリューム共有・初期化コマンドなどのオプションが積み重なり、「あの環境はどんなフラグで起動したのか」がすぐに曖昧になります。これはDockerにおける「長大なdocker runコマンド問題」と同じ構図です。
smolvmはこの問題に対して、Smolfileという宣言的構成ファイルを用意しています。TOML形式でVMの構成を記述し、リポジトリにコミットしておけば、チームの誰もが同一の環境を1コマンドで再現できます。DockerfileとDocker Composeの役割を、マイクロVMの世界で1つのファイルに集約したもの、と捉えると理解しやすいでしょう。Infrastructure as Code（IaC）の考え方を、個々の開発環境のレベルまで引き下ろすのがSmolfileの役割です。
Smolfileの基本構造
Smolfileは、トップレベルのキーと3つの主要セクション（テーブル）で構成されます。まず全体像を示します。
# rootfsとして使うOCIイメージ
image = "python:3.12-alpine"
# ネットワーク有効化（既定は無効）
net = true
[network]
# egress許可リスト：ここに挙げたホスト以外への通信は遮断
allow_hosts = ["pypi.org", "files.pythonhosted.org"]
[dev]
# VM起動時に実行する初期化コマンド
init = "pip install -r requirements.txt"
# ホストと共有するディレクトリ
volumes = ["./src:/work/src"]
[auth]
# SSHエージェント転送（秘密鍵はゲストに入らない）
ssh_agent = trueTOMLを採用しているため、YAMLのインデント事故やJSONのコメント不可といったストレスがなく、レビューもしやすい構成ファイルになっています。
各セクションの詳細
image / net：VMの土台
imageにはrootfsとして使用するOCIイメージを指定します。Docker Hub・GHCRの公開イメージのほか、docker saveアーカイブや展開済みディレクトリも指定できます。netはネットワークの有効化フラグで、省略時は無効（完全オフライン）です。
[network]：egress許可リスト
allow_hostsに列挙したホストへの通信のみが許可され、それ以外へのegressは遮断されます。パッケージレジストリだけを許可して野良通信を封じる、といった最小権限のネットワークポリシーをファイル1つで表現できます。セキュリティ上の意味はセキュリティ解説で詳述します。
[dev]：初期化とボリューム
initにはVM起動時に実行するセットアップコマンドを記述します。依存パッケージのインストールやサービスの起動をここに書いておけば、VMを起動するだけで作業可能な状態になります。volumesはホストとゲストで共有するディレクトリの対応を「ホスト側:ゲスト側」の形式で列挙します。共有できるのはディレクトリのみで、単一ファイルは指定できない点に注意してください。
[auth]：SSHエージェント転送
ssh_agent = trueとすると、ホストのSSHエージェントがVM内から利用できます。重要なのは、秘密鍵そのものは決してゲストに入らないという設計です。署名要求だけがハイパーバイザ経由でホスト側エージェントに転送されるため、VM内でgit cloneのようなSSH認証が必要な操作を行っても、鍵の漏えいリスクを持ち込みません。この分離はハイパーバイザによって強制されます。
チーム運用の実践パターン
Smolfileを実務に組み込む際の代表的なパターンを紹介します。
- リポジトリ同梱パターン: プロジェクトのルートにSmolfileをコミットし、READMEに「smolvmで起動」とだけ書く運用です。新規メンバーのオンボーディングが「クローンして起動」の2手で終わります。
- ワークロード別テンプレートパターン: 言語・フレームワークごとの標準Smolfileを社内テンプレートリポジトリに整備し、プロジェクト開始時にコピーして調整します。
allow_hostsの標準セット（社内レジストリ・パッケージミラーのみ）をテンプレートに含めることで、セキュリティポリシーの既定を組織的に統一できます。 - CI連携パターン: 開発者のローカルとCIランナーが同じSmolfileを参照することで、「CIでだけ落ちる」問題の原因となる環境差異を構造的に排除します。
tips
Smolfileはあくまで「構成の宣言」であり、構築済み環境の配布にはpackと.smolmachineが適しています。「レシピを配るのがSmolfile、料理を配るのがpack」と使い分けると整理しやすくなります。
宣言的構成は、環境のドキュメント化という副次効果ももたらします。Smolfileを読めば、そのプロジェクトが何のイメージを土台とし、どこと通信し、何を初期化するのかが一目で分かります。属人化しがちな開発環境の知識を、レビュー可能なコードとして残せることは、チーム開発における大きな資産となります。