packコマンド：環境を単一実行ファイルに
smolvmの3つ目のワークフローである「ポータブル成果物」の中核がpackコマンドです。pack createは、指定したOCIイメージとVMランタイムを丸ごと束ね、単一の実行ファイルとして書き出します。受け取った側は、smolvmのインストールもDockerも不要で、そのファイルを実行するだけでVM内のアプリケーションを起動できます。
# Python 3.12環境を単一実行ファイル化
$ smolvm pack create --image python:3.12-alpine -o ./python312
# 生成されたファイルを実行（smolvm不要・依存ゼロ）
$ ./python312 run -- python3 --version
Python 3.12.xこれは「アプリケーションの配布」の考え方を変える機能です。従来、実行環境ごとアプリを配るにはコンテナレジストリとランタイムの整備が前提でした。packはその前提を取り払い、ファイルを渡すという最も原始的で確実な方法で、ハードウェア分離されたVM環境ごとアプリケーションを届けます。
.smolmachine形式：状態ごと持ち運ぶスナップショット
packが「これから実行する環境」を配布するのに対し、.smolmachine形式は実行中の状態を含むVMスナップショットを単一ファイル化したものです。インストール済みのパッケージ、設定ファイル、作業途中のデータまで、VMの中身がそのまま1つのファイルに収まります。
受け取った側は、同じCPUアーキテクチャのホストであれば、依存関係のインストールなしにそのVMをそのまま実行できます。「環境構築手順書」をやり取りする代わりに、構築済みの環境そのものをファイル共有やアーティファクトストレージで受け渡す運用が可能になります。
唯一の制約はCPUアーキテクチャです。スナップショットにはネイティブな実行状態が含まれるため、x86_64で作成したファイルはx86_64ホストで、arm64で作成したファイルはarm64ホストで実行する必要があります。Apple Silicon標準の組織であればこの制約は実質問題になりませんが、混在環境ではアーキテクチャ別にスナップショットを用意する運用を設計してください。
配布シナリオ別の活用方法
開発環境のオンボーディング配布
ミドルウェアの構築や初期データ投入まで済ませたVMを.smolmachineで保存し、新規メンバーに渡します。従来数日かかっていた環境構築が、ファイルのダウンロードと起動だけで完了します。Smolfileが「レシピの共有」だとすれば、こちらは「完成品の共有」です。
エアギャップ環境・オフライン実行
インターネットに接続できない検証環境や規制産業の閉域網では、レジストリからのイメージ取得自体が困難です。packで生成した単一実行ファイルや.smolmachineをUSBメディアや内部ファイルサーバーで持ち込めば、外部依存なしにワークロードを実行できます。
CIアーティファクトとしての利用
ビルドパイプラインの成果物としてpackバイナリを生成すれば、テスト環境・ステージング・本番検証で「まったく同じ実行環境」を使い回せます。環境差異によるすり抜けを構造的に防げる点で、リリースエンジニアリングの品質向上に直結します。
SDK組み込みによる製品機能化
smolvmはSDKとしてアプリケーションに組み込むこともできるため、「ユーザーが持ち込んだコードを安全に実行する」機能を自社製品に内蔵する、といった発展的な使い方も視野に入ります。AIエージェント製品のコード実行機能などが典型例です（企業活用シナリオ参照）。
packと.smolmachineの使い分け
最後に、2つのポータブル形式の使い分けを整理します。
| 観点 | pack（単一実行ファイル） | .smolmachine（スナップショット） |
|---|---|---|
| 含まれるもの | VMランタイム + イメージ（初期状態） | VMの実行状態・データまるごと |
| 受け手の前提 | 完全に依存ゼロ（smolvm不要） | smolvm + 同一CPUアーキテクチャ |
| 主な用途 | ツール配布・デモ・CI成果物 | 構築済み環境の共有・退避・複製 |
| 状態の扱い | 実行のたびに初期状態から開始 | 保存時点の状態から再開 |
「初期状態のクリーンな環境を広く配るならpack、作り込んだ状態を正確に引き継ぐなら.smolmachine」というのが基本方針です。いずれも単一ファイルで完結するため、既存のファイル配布インフラ（社内ストレージ、アーティファクトリポジトリ等）にそのまま乗せられることが、運用面での大きな利点となります。