🛡️ 技術調査 - AI Agent SaaS 向け microVM 隔離実行基盤

起点: GMO Flatt Security「AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用」(SRE NEXT 2026)。同社は任意コード実行を伴う AI セキュリティ診断エージェント SaaS の実行基盤を、汎用 Kubernetes 上のコンテナ隔離から専用 microVM 基盤へ移行しました。本調査はこの事例を起点に、AI エージェント sandbox を microVM で運用する隔離実行基盤を、Firecracker / Kata Containers / Cloud Hypervisor / gVisor を中心とした再利用可能な技術調査として構造化します。

調査日: 2026-07-12 / 対象読者: 任意コード実行を伴う AI エージェント基盤を設計・運用する開発者・SRE・アーキテクト

本記事は次の 3 つの問いを軸にします。汎用 Kubernetes 上のコンテナ隔離で、AI エージェント SaaS の何が問題化したのか。専用 microVM 基盤へ移すと、隔離とコスト構造がどう変わるのか。そして、どの規模になれば自社基盤が損益分岐を超えるのか。前半で技術構造（C4・データモデル・API・構築運用）を押さえ、後半のコスト設計と意思決定フレームで判断軸に落とし込みます。

概要

AI エージェント向け microVM ベース隔離実行基盤は、任意コード実行を伴う AI エージェント SaaS において、マルチテナント環境での強固な隔離境界を提供する技術です。従来のコンテナ技術（Linux namespace + cgroups）では不十分な隔離強度を、軽量な仮想マシン（microVM）で補強します。

AI エージェントは、次の特性により従来の Web アプリケーションとは異なる実行基盤要件を持ちます。

• 任意コード実行: LLM が生成したコード（Python / Shell / JavaScript 等）を実行環境で直接実行します。
• 短命なワークロード: 1 回のタスク実行は数秒〜数分で完了し、頻繁に起動・破棄されます。
• 強い隔離要求: マルチテナント環境で、他テナントのデータやホストシステムへの影響を完全に遮断する必要があります。
• 高密度配置: 1 台のホストで数百〜数千の AI エージェント実行環境を並列稼働させます。

なぜコンテナ隔離では不十分なのか

コンテナ技術（Docker / containerd / runc）は、Linux カーネルの namespace と cgroups でプロセスとリソースを隔離します。しかしコンテナはホストカーネルを共有するため、次のリスクが残ります。

AI エージェントはユーザー入力由来の任意コードを実行するため、攻撃者が悪意あるコードを LLM に生成させる攻撃（Prompt Injection 等）が成立します。ゼロトラスト前提のマルチテナント AI SaaS では、コンテナ隔離だけで安全性を保証できません。

microVM による隔離強化

microVM は、次の方式でコンテナ隔離の弱点を補います。

カーネルエクスプロイトが成功しても、侵害範囲は当該 microVM のゲストカーネルに閉じます。ホストへ脱出するには、さらにハイパーバイザーの脆弱性を突く必要があります。ハイパーバイザーの攻撃面は Linux カーネル全体よりも小さく、厳格に監査されています。

関連技術との関係

AI エージェント向け隔離実行基盤では、「隔離強度」と「起動速度」のトレードオフにより、次の技術スペクトラムが存在します。

主要技術の比較

起動時間・メモリオーバーヘッドの数値は、測定バージョン・ホスト・ゲスト構成・ネットワーク有無で変わる代表値です（Firecracker の 125ms 未満・約 5MiB は NSDI 2020 論文の最小構成での値）。絶対比較ではなくオーダー感として扱ってください。

ユースケース別の推奨技術

主要な採用事例

特徴

• 強隔離: ハードウェア仮想化（KVM）により、ゲストカーネルとホストカーネルを分離します。カーネルエクスプロイトが成功してもホストへの影響を遮断します。
• 高速起動: Firecracker / Cloud Hypervisor は 100〜150ms 程度で microVM を起動します。従来 VM の数秒〜数十秒と比較して 1〜2 桁高速です。
• 低メモリオーバーヘッド: VMM プロセスは約 5〜10MiB です。1 台のホストで数百〜数千の microVM を密に配置できます。
• snapshot / restore: 起動済み microVM の状態を保存し、高速に再開します。AI エージェントの頻繁な起動・破棄に適合します。
• 最小デバイスモデル: virtio ネットワーク・ブロックデバイス等のみをエミュレートし、レガシーデバイスを削除して攻撃面を縮小します。
• CPU / メモリ overcommit: demand paging により未タッチのメモリページを遅延割当します。使用済みページの回収は virtio-balloon 等の明示設定に依存します。
• Rust 実装（Firecracker / Cloud Hypervisor）: メモリ安全言語により、VMM 自体の脆弱性を削減します。
• jailer による多層隔離（Firecracker）: VMM プロセス自体も namespace / cgroup / chroot / 権限降格で隔離します（seccomp フィルタは Firecracker 本体が各スレッドへ適用）。VMM 脆弱性の影響を限定します。
• OCI 互換（Kata Containers）: 既存の Docker / Kubernetes ワークフローを変更せず、Pod（sandbox）単位で microVM 隔離を適用できます（Pod 内コンテナは VM を共有）。

構造

AI エージェント向け microVM 隔離実行基盤の内部アーキテクチャを C4 モデルで 3 段階に図解します。

システムコンテキスト図

microVM 実行基盤と、その周辺の外部アクター・外部システムを示します。

アクター・外部システム

コンテナ図

microVM 実行基盤内の主要構成要素を示します。

コンテナ要素

コンポーネント図

VMM とその周辺コンポーネントの内部構造を、具体的な技術要素で示します。ここでは Firecracker を VMM、Kata Containers をコンテナ管理層とする代表構成を示します。

ホスト空間

ゲスト空間

microVM ネットワーク構成図

Firecracker 標準構成では、ゲストの virtio-net をホスト側 TAP デバイスへ接続し、TAP を VMM 用ネットワーク namespace 内に閉じ込めます。ブリッジまたはルーティングと NAT を介して外部へ接続します。

ネットワーク要素

Kata Containers を Kubernetes 上で使う場合は、CNI が作成した veth と VM の TAP を tc-redirect（Traffic Control フィルタ）で接続するモデルを採ります。Firecracker 単体運用の TAP 直結モデルとは接続経路が異なります。

テナント分離手法

• ネットワーク namespace 分離: 各 VMM プロセスを専用 namespace で起動し、TAP デバイスも namespace 内へ閉じ込めます。
• セグメント分離: テナント単位で VLAN タグやサブネットを分け、論理分離します。
• NAT マスカレード: ゲスト IP をプライベート帯（例: 172.16.0.0/12）に割り当て、外部へ露出させません。
• nftables / iptables フィルタ: テナント間トラフィックを遮断するファイアウォールルールをホスト側で強制します。

データ

実行基盤が扱う主要エンティティを、概念モデルと情報モデルで構造化します。属性は Firecracker REST API 仕様と Kata Containers アーキテクチャに基づいて設計しました。

概念モデル

エンティティ説明

情報モデル

主要エンティティの属性

構築方法

前提条件

Firecracker を動作させるには次の要件を満たします。

• CPU アーキテクチャ: x86_64 または aarch64
• KVM モジュール: 現行 Firecracker はホストカーネル 5.10 以上を要件とします（4.14 以降は旧版の要件）
• KVM デバイスアクセス: /dev/kvm への読み書き権限
• ホスト環境: ベアメタル、または nested virtualization 対応のクラウドインスタンス（AWS の .metal インスタンス等）

KVM モジュールのロードを確認します。

lsmod | grep kvm

/dev/kvm へのアクセス権限を設定します。多くのディストリビューションでは kvm グループで管理します。

# ACL を使う場合
sudo setfacl -m u:${USER}:rw /dev/kvm

# kvm グループを使う場合
[ $(stat -c "%G" /dev/kvm) = kvm ] && sudo usermod -aG kvm ${USER} && echo "Access granted."

# 権限確認
[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

Firecracker バイナリの入手

公式リリースからダウンロードします。

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
mv release-${latest}-$(uname -m)/firecracker-${latest}-${ARCH} firecracker
chmod +x firecracker

jailer も同じリリースから入手できます。

ARCH="$(uname -m)"
VERSION="v1.16.1"
curl -L ${release_url}/download/${VERSION}/firecracker-${VERSION}-${ARCH}.tgz | tar -xz
sudo mv release-${VERSION}-${ARCH}/jailer-${VERSION}-${ARCH} /usr/local/bin/jailer
sudo chmod +x /usr/local/bin/jailer

ソースからビルドする場合は Docker を使います。

git clone https://github.com/firecracker-microvm/firecracker firecracker_src
sudo ./firecracker_src/tools/devtool build

ゲストカーネルと rootfs の準備

ゲストカーネル（vmlinux）と rootfs（ext4 イメージ）を用意します。CI アーティファクトから取得できます。

ARCH="$(uname -m)"
S3="https://s3.amazonaws.com/spec.ccfc.min"
# 最新 CI ビルドのカーネル (vmlinux) を取得
CI_PREFIX=$(curl -fsSL "$S3?list-type=2&prefix=firecracker-ci/&delimiter=/" | grep -oP "(?<=<Prefix>)firecracker-ci/[0-9]{8}-[^/]+/(?=</Prefix>)" | sort | tail -1)
kernel_key=$(curl -fsSL "$S3?list-type=2&prefix=${CI_PREFIX}${ARCH}/vmlinux-" | grep -oP "(?<=<Key>)(${CI_PREFIX}${ARCH}/vmlinux-[0-9]+\.[0-9]+\.[0-9]{1,3})(?=</Key>)" | sort -V | tail -1)
wget "$S3/${kernel_key}"

rootfs は squashfs を展開して ext4 イメージへ変換します。

# squashfs を展開し ext4 化
unsquashfs ubuntu.squashfs
sudo chown -R root:root squashfs-root
truncate -s 1G ubuntu.ext4
sudo mkfs.ext4 -d squashfs-root -F ubuntu.ext4

jailer のセットアップ

jailer は chroot・cgroup・network namespace で Firecracker プロセスを隔離します。既定の chroot ベースは /srv/jailer です。

sudo mkdir -p /srv/jailer
# cgroup のマウント確認
mount | grep -E "cgroup|cgroup2"
# 専用ネットワーク namespace を作成
sudo ip netns add fc_netns

利用方法

Firecracker REST API の主要エンドポイント

Firecracker は UNIX ドメインソケット経由の REST API で制御します。

基本的な起動フロー

Firecracker を API ソケット待機で起動します。

API_SOCKET="/tmp/firecracker.socket"
sudo rm -f $API_SOCKET
sudo ./firecracker --api-sock "${API_SOCKET}"

--enable-pci フラグを付けると、VirtIO デバイスが MMIO ではなく PCI トランスポートで作成されます（スループット向上・レイテンシ低減）。ただし後述の CVE-2026-5747 の影響を受けるため、パッチ済みバージョンの利用が前提です。

ブートソース（カーネル）を設定します。

KERNEL="./vmlinux-5.10"
KERNEL_BOOT_ARGS="console=ttyS0 reboot=k panic=1 pci=off"
sudo curl -X PUT --unix-socket "${API_SOCKET}" \
    --data "{\"kernel_image_path\": \"${KERNEL}\", \"boot_args\": \"${KERNEL_BOOT_ARGS}\"}" \
    "http://localhost/boot-source"

rootfs（ドライブ）を設定します。

ROOTFS="./ubuntu.ext4"
sudo curl -X PUT --unix-socket "${API_SOCKET}" \
    --data "{\"drive_id\": \"rootfs\", \"path_on_host\": \"${ROOTFS}\", \"is_root_device\": true, \"is_read_only\": false}" \
    "http://localhost/drives/rootfs"

マシン設定（vCPU・メモリ）を設定します。

sudo curl -X PUT --unix-socket "${API_SOCKET}" \
    --data '{"vcpu_count": 2, "mem_size_mib": 1024, "smt": false}' \
    "http://localhost/machine-config"

ホスト側で TAP デバイスを作成し、ネットワークを設定します。

TAP_DEV="tap0"
sudo ip tuntap add dev "$TAP_DEV" mode tap
sudo ip addr add 172.16.0.1/30 dev "$TAP_DEV"
sudo ip link set dev "$TAP_DEV" up
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
HOST_IFACE=$(ip -j route list default | jq -r '.[0].dev')
sudo iptables -t nat -A POSTROUTING -o "$HOST_IFACE" -j MASQUERADE

sudo curl -X PUT --unix-socket "${API_SOCKET}" \
    --data '{"iface_id": "net1", "guest_mac": "06:00:AC:10:00:02", "host_dev_name": "tap0"}' \
    "http://localhost/network-interfaces/net1"

microVM を起動します。

sudo curl -X PUT --unix-socket "${API_SOCKET}" \
    --data '{"action_type": "InstanceStart"}' \
    "http://localhost/actions"

設定ファイル（JSON）による一括起動

API 呼び出しの代わりに、設定ファイルで起動できます。

sudo ./firecracker --api-sock /tmp/firecracker.socket --config-file config.json

{
  "boot-source": {
    "kernel_image_path": "./vmlinux-5.10",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "path_on_host": "./ubuntu.ext4",
      "is_root_device": true,
      "is_read_only": false
    }
  ],
  "machine-config": { "vcpu_count": 2, "mem_size_mib": 1024, "smt": false },
  "network-interfaces": [
    { "iface_id": "net1", "guest_mac": "06:00:AC:10:00:02", "host_dev_name": "tap0" }
  ]
}

vsock によるゲスト連携

vsock を使うと、ホストとゲスト間で Unix ソケットライクな通信ができます。AI エージェント sandbox では、コード投入と成果物回収の経路に使います。

sudo curl -X PUT --unix-socket /tmp/firecracker.socket \
    --data '{"guest_cid": 3, "uds_path": "./v.sock"}' \
    "http://localhost/vsock"

ホストからゲストのポート 52 へ接続する例です。

# ホスト側
socat - UNIX-CONNECT:./v.sock
CONNECT 52
# ゲスト側で待受
socat VSOCK-LISTEN:52,fork -

MMDS（メタデータサービス）の利用

MMDS はホストからゲストへメタデータを配信します。V2 はセッショントークンを要求します。

sudo curl -X PUT --unix-socket /tmp/firecracker.socket \
    --data '{"network_interfaces": ["net1"], "version": "V2", "ipv4_address": "169.254.169.254"}' \
    "http://localhost/mmds/config"

sudo curl -X PUT --unix-socket /tmp/firecracker.socket \
    --data '{"latest": {"meta-data": {"instance-id": "i-agent-001"}}}' \
    "http://localhost/mmds"

ゲスト側からトークンを取得して読み出します。

# ゲスト内
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-metadata-token-ttl-seconds: 21600")
curl -s "http://169.254.169.254/latest/meta-data" -H "X-metadata-token: ${TOKEN}"

スナップショットの作成と復元

スナップショットは microVM の状態を保存し、高速な復元を可能にします。AI エージェント基盤の冷間起動回避の要です。

# 一時停止 → Full スナップショット作成 → 再開
sudo curl -X PATCH --unix-socket /tmp/firecracker.socket \
    --data '{"state": "Paused"}' "http://localhost/vm"
sudo curl -X PUT --unix-socket /tmp/firecracker.socket \
    --data '{"snapshot_type": "Full", "snapshot_path": "./snapshot_file", "mem_file_path": "./mem_file"}' \
    "http://localhost/snapshot/create"
sudo curl -X PATCH --unix-socket /tmp/firecracker.socket \
    --data '{"state": "Resumed"}' "http://localhost/vm"

新しい Firecracker プロセスでスナップショットから復元します。

sudo curl -X PUT --unix-socket /tmp/firecracker.socket \
    --data '{"snapshot_path": "./snapshot_file", "mem_backend": {"backend_path": "./mem_file", "backend_type": "File"}, "resume_vm": true}' \
    "http://localhost/snapshot/load"

• mem_backend.backend_type: File（カーネルがページフォルトを処理）または Uffd（ユーザー空間プロセスが処理）
• resume_vm: 復元後に自動再開する場合 true

jailer 経由での起動

本番のマルチテナント環境では jailer を必須とします。

sudo jailer --id 551e7604-e35c-42b3-b825-416853441234 \
    --exec-file /usr/local/bin/firecracker \
    --uid 1234 --gid 1234 \
    --chroot-base-dir /srv/jailer \
    --cgroup-version 2 \
    --netns /var/run/netns/fc_netns \
    --daemonize

• --id: microVM の一意な識別子
• --uid / --gid: Firecracker を実行する非特権ユーザー
• --chroot-base-dir: chroot jail のベース（既定 /srv/jailer）
• --cgroup-version: cgroup バージョン（1 または 2）
• --netns: ネットワーク namespace のパス
• --daemonize: setsid() で切り離し、標準入出力を /dev/null へ

起動後の API ソケットは次のパスに作成されます。

/srv/jailer/firecracker/<id>/root/run/firecracker.socket

cgroup v2 で実際にリソース制限を適用するには、事前に cgroup を作成し --parent-cgroup（または --cgroup <file>=<value>）で指定します。--cgroup-version 2 の指定だけでは新しい cgroup を作成・適用しません。

Kata Containers 経由での利用

Kata Containers は containerd / Kubernetes から RuntimeClass 経由で microVM を透過的に使えます。hypervisor には QEMU / Cloud Hypervisor / Firecracker を選べます。

/etc/containerd/config.toml にランタイムを追加します。

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
  runtime_type = "io.containerd.kata.v2"

上記は containerd 1.x の設定です。containerd 2.x では plugin パスが io.containerd.cri.v1.runtime 系に変わるため、利用する containerd のメジャーバージョンに合わせてください。

RuntimeClass を作成し、Pod で指定します。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
---
apiVersion: v1
kind: Pod
metadata:
  name: isolated-workload
spec:
  runtimeClassName: kata
  containers:
    - name: app
      image: your-image

containerd で直接実行する例です。

sudo ctr run --runtime io.containerd.kata.v2 docker.io/library/alpine:latest test sh

AI エージェント sandbox としての典型フロー

1. テンプレート snapshot の作成: 依存関係を導入した microVM のスナップショットを事前に作成します。
2. 高速起動: /snapshot/load でテンプレートから microVM を復元します（数十〜数百 ms）。
3. コード投入: vsock 経由でゲストにユーザーコードを送ります。
4. 実行: ゲスト内でコードを実行します。
5. 成果物回収: vsock 経由で結果をホストへ返します。
6. VM 破棄: microVM を停止し、リソースを解放します。

運用

microVM のライフサイクル管理

• ウォームプール: 起動時間を最小化するため、復元済み microVM のウォームプールを維持します。復元元となるゴールデンスナップショットは別途ローカルにキャッシュします（前者はメモリ等の実行資源、後者は主にストレージを消費）。
• snapshot からの高速再開: VM の完全な状態（メモリ・CPU・デバイス）を snapshot として保存し、高速に復元してコールドスタートを回避します。
• アイドル VM の休眠・破棄: 未使用 VM を定期的にヘルスチェックし、アイドル時間が閾値を超えたら休眠または破棄します（E2B の auto-pause 相当）。
• プールサイズの動的調整: リクエストレート・レイテンシ・リソース使用率を監視し、ウォームプールのサイズを自動スケールします。

ウォームプール運用の流れです。

1. CI/CD で定期的にゴールデン snapshot をビルドする
2. ホストが最新 snapshot をプルし、ウォームプールを目標容量まで充填する
3. ワークロード到着時に scheduler が準備済み snapshot を割り当てて起動する
4. プール枯渇を監視し、scaler が復元済み VM を追加補充する
5. 古い snapshot を段階的に drain し、最新版へ入れ替える（パッチ反映）

スケール

• 同時実行数とホスト台数: Firecracker は 1 ホストで数千の microVM を実行できます（AWS Lambda の実運用実績）。メモリオーバーヘッドは約 5MiB/VM、起動は 125ms 未満です。
• oversubscription: CPU・メモリを論理的にオーバーサブスクライブする場合、実使用率を監視してホスト限界を超えないよう制御します。
• rate limiter による DoS 抑制: ネットワークとブロック I/O の rate limiter をテナント単位で設定し、リソース独占を防ぎます。

ネットワーク rate limiter の設定例です。

{
  "rx_rate_limiter": { "bandwidth": { "size": 1048576, "refill_time": 1000 } },
  "tx_rate_limiter": { "bandwidth": { "size": 524288, "refill_time": 1000 } }
}

CPU の制限は cgroup v2 を併用します。

echo "100000 100000" > /sys/fs/cgroup/<vm_slice>/cpu.max

監視・可観測性

• VMM メトリクス: Firecracker は --metrics-path で FIFO 経由のメトリクスを公開します。vCPU 使用率・メモリ・ネットワーク / ブロック I/O・rate limiter 統計を取得します。
• ゲスト health: ゲスト内 agent が vsock 経由で定期的にヘルスチェックを返します。
• 起動レイテンシ: snapshot restore 時間を含む VM 起動時間を SLO として追跡します。
• host cgroup 監視: 各 VM のリソース使用量を cgroup から収集し、Prometheus + Grafana で可視化します。
• Kata のメトリクス統合: kata agent が /metrics を公開し、Prometheus で収集します。

更新

• ゲストカーネル / rootfs テンプレの更新: ゴールデンイメージを定期的にリビルドし、新しい snapshot を配布します。ウォームプールは古い snapshot を drain して置き換えます。
• 脆弱性パッチ・CVE 対応: Firecracker 本体・ゲストカーネルの CVE を監視し、優先度に応じてパッチを適用します（後述の CVE-2026-5747 等）。
• ローリング更新: ホスト側の Firecracker 更新は、ホストを順次 drain して再起動します。

ログ収集

• ホスト側 VMM ログ: --log-path で指定した FIFO からログを収集し、集約基盤へ送ります。
• vsock 経由のゲストログ: ゲスト内アプリのログを vsock でホストへ転送し、集中ログシステムへ送ります。
• セキュリティ監査ログ: VM 起動・停止・snapshot 作成・ネットワーク接続などの重要イベントを監査ログとして記録します。

ベストプラクティス

隔離

• jailer 必須: 各 VM プロセスを chroot・namespace・cgroup で隔離し、非特権ユーザーに降格します（seccomp フィルタは Firecracker 本体が各スレッドへ適用）。
• seccomp フィルタ: Firecracker 公式の seccomp プロファイルを使い、必要最小限のシステムコールのみ許可します。
• 最小デバイスモデル: 不要なデバイスは公開しません。
• ネットワーク egress 制御: テナント分離・SSRF / 横移動防止のため、nftables / iptables で外向き通信を制限します。
• read-only rootfs + overlay: rootfs は read-only でマウントし、書き込みは overlay で受けます。
• rate limiter / cgroup で DoS 抑制: ネットワーク・ブロック I/O は Firecracker の rate limiter、CPU・メモリは cgroup でテナントごとに制限します。

jailer の起動例です。

sudo jailer --id ${vm_id} \
    --uid 12345 --gid 12345 \
    --chroot-base-dir /srv/jailer \
    --daemonize \
    --exec-file /usr/local/bin/firecracker \
    -- --api-sock /run/firecracker.sock

マルチテナント設計

• VM 境界の粒度: 1 テナント = 1 VM（強隔離）または 1 ジョブ = 1 VM（細粒度）を選びます。AI Agent SaaS では 1 ジョブ = 1 VM が一般的です。
• ホスト共有の是非: 信頼境界が異なるテナントを同一ホストで共有する場合、ホストカーネル脆弱性リスクを評価します。高セキュリティ要件ではテナントごとにホストを分けます。
• per-tenant ネットワーク namespace: network namespace をテナントごとに分離し、ネットワーク層の横移動を防ぎます。

CI/CD 連携・イメージ管理

• テンプレ snapshot のビルドパイプライン: ゴールデンイメージを自動ビルドし、テスト後に snapshot として配布します。バージョン管理とロールバックを実装します。
• イメージのハッシュ検証: snapshot ファイルのハッシュを検証し、改ざんを検出します。
• immutable infrastructure: snapshot は immutable として扱い、修正ではなく再ビルドします。

Kubernetes 併用

信頼できないコードを実行するワークロードのみ Kata Containers（microVM）で実行し、内部の信頼されたワークロードは runc を使ってオーバーヘッドを抑えるハイブリッド構成が有効です。RuntimeClass で使い分けます。

トラブルシューティング

一般的な切り分け手順です。

1. dmesg | grep kvm でカーネルメッセージを確認する
2. Firecracker ログ（--log-path）を確認する
3. ゲストコンソールログ（console=ttyS0）を確認する
4. cgroup 制限（/sys/fs/cgroup/）を確認する
5. SELinux / AppArmor が拒否していないか確認する

セキュリティ注意: CVE-2026-5747（virtio PCI transport）

Firecracker の virtio PCI transport に out-of-bounds write の脆弱性（CVE-2026-5747, CVSS v4.0 8.7 / v3.1 7.5）が報告されています。AWS Security Bulletin 2026-015-AWS および GitHub Advisory GHSA-776c-mpj7-jm3r で公表されました。

任意コード実行を伴う AI エージェント sandbox は「ゲストが root を取り得る」前提で運用するため、この種の VMM 脆弱性への即時パッチ運用が重要です。

コスト設計と意思決定

本調査の起点である GMO Flatt Security の移行事例が示す通り、microVM 基盤の採否は隔離要件だけでなく総コストで決めます。

総コストの構成

技術コスト

• 起動時間（課金対象時間）: microVM は 125ms 未満で起動するため、短命ジョブでもオーバーヘッドが小さく、無駄な課金時間を抑えます。
• 隔離境界（セキュリティ工数・監査）: VM 隔離により監査工数が下がり、コンプライアンス要件に対応しやすくなります。
• 環境破棄コスト: VM の破棄はプロセス終了で完了し、状態のクリーンアップが容易です。
• アイドル資源（ウォームプール保持）: 復元済み VM のウォームプールはメモリ等の実行資源を常時消費し、ゴールデンスナップショットのキャッシュはストレージを消費します。両者を分けてプールサイズを最適化します。

運用コスト

• 運用要員: 自社基盤ではインフラ・セキュリティ・監視の専任が必要です。マネージドサービスは料金に含まれます。
• ライセンス: Firecracker・Kata Containers は Apache 2.0 で無償です。
• マネージド sandbox の従量課金: E2B・Modal 等は vCPU / メモリ / 秒単位で課金されます。

自社基盤が成立する分岐点モデル

マネージドサービスと自社 microVM 基盤の総コストを次の式で比較します。

• 総コスト（マネージド）= M × C_managed
• 総コスト（自社）= C_fixed + M × C_variable

ここで M は代表 VM サイズ（例: 2 vCPU + 4 GiB）での月間総 VM 秒、C_managed / C_variable は同サイズ 1 VM 秒あたりの単価です。厳密には vCPU 秒とメモリ秒は次元が異なるため、合算せず S_cpu × P_cpu + S_mem × P_mem で個別計上します（本節は代表 VM サイズに固定して VM 秒で近似）。C_fixed は自社基盤の固定費（ホスト + 人件費）です。損益分岐は次で表せます。

• 分岐点: M = C_fixed / (C_managed − C_variable)

C_fixed が大きい（専任要員が要る）ため、規模 M が十分大きいときだけ自社基盤が合理化されます。判断は次の 4 軸で行います。

分岐点の具体計算例（illustrative）

代表的な VM サイズを 2 vCPU + 4 GiB とし、次の仮定で試算します。値は説明用であり、実際には当該時点の公式単価と自社実測費で再計算してください。

• マネージド単価 C_managed: 2 × $0.000014 + 4 × $0.0000045 ≈ $0.000046 / VM 秒（E2B 公表単価に基づく概算）
• 自社固定費 C_fixed: ホスト費 + SRE 0.5 人月 ≈ $6,000 / 月（説明用の仮定）
• 自社変動費 C_variable: ≈ $0.000010 / VM 秒（電力・ネットワーク等の説明用仮定）

損益分岐は次のとおりです。

M = C_fixed / (C_managed - C_variable)
  = 6,000 / (0.000046 - 0.000010)
  ≈ 166,700,000 VM 秒 / 月
  ≈ 46,300 VM 時間 / 月

月間の総 VM 稼働時間がこの分岐点を超えると、自社 microVM 基盤の固定費が薄まり合理化されます。月間 VM 時間は「月間ジョブ数 × ジョブ平均寿命」で概算します。

単価・固定費は組織のコスト構造（人件費の地域差・クラウド契約条件・ウォームプール保持コスト）で大きく変わります。平均同時実行は「月間 VM 時間 ÷ 730 時間」の概算です。この仮定での損益分岐は平均同時実行 約 63 VM に相当します（判断軸の「ピークで数百〜数千 VM」はホスト容量・オートスケール設計の指標で、コスト回収の指標である平均同時実行とは役割が異なります）。マネージド側は基本プラン料金 + 従量課金の合算で比較してください（例: E2B は無料枠の同時実行上限を超えると Pro の月額が加算されます）。この数字は絶対値ではなく、相対比較の枠組みとして扱ってください。

判断フロー

1. 同時実行が少ない、または利用頻度が低い → マネージドサービス（E2B / Modal 等）を使う。初期投資なし・運用要員不要。
2. 同時実行が多く、予測可能なワークロード → 自社 microVM 基盤を検討する。Reserved 系でホストを確保しスケールメリットを取る。
3. 強隔離が必須でコンプライアンス要件が厳しい → 自社 microVM 基盤（Firecracker）でデータ主権と監査対応を確保する。
4. 既に Kubernetes 環境がある → Kata Containers（RuntimeClass）で信頼境界だけ microVM 化するハイブリッドにする。

GMO Flatt Security が Kubernetes を離れた理由（起点事例の解釈）

起点資料（SRE NEXT 2026 の登壇概要）が主因として挙げるのは、Kubernetes 運用後に顕在化したインフラ維持費と運用の複雑さです。以下はその起点資料からの解釈として、コスト・運用面の理由とセキュリティ設計上の判断を分けて整理します。

• インフラ維持費・運用コストの複雑さ（主因）: Kubernetes は汎用オーケストレーションであり、AI エージェント固有の短命ジョブ・snapshot 高速起動・テナント完全分離には最適化されていません。維持費と運用負荷が増大しました。
• セキュリティ設計上の判断（解釈）: コンテナ隔離（namespace / cgroup / seccomp）は共有カーネルを前提とし、任意コード実行に対する強隔離という観点では VM 境界に劣ります。専用 microVM 基盤への移行で、運用効率と隔離強度を両立しました。

なお E2B / Modal 等の従量単価やコールドスタート値は各社の料金ページで変動します。分岐点の試算では、当該時点の公式単価と自社ホストの実測固定費を用いて再計算してください。

まとめ

任意コード実行を伴う AI エージェント SaaS では、コンテナのプロセス隔離だけでは共有カーネルのリスクを閉じられません。本記事は Firecracker / Kata Containers / Cloud Hypervisor を軸に、microVM による強隔離と snapshot 高速起動、テナント分離、そして「マネージド利用か自社基盤か」を総コストと分岐点で判断する枠組みを、GMO Flatt Security の Kubernetes から自社 microVM 基盤への移行事例を起点に整理しました。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

起点・事例

• AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 - SRE NEXT 2026（GMO Flatt Security）
• SRE NEXT 2026 Schedule
• GMO Flatt Security Blog

概要・比較

• Firecracker: Lightweight Virtualization for Serverless Applications（公式サイト）
• Firecracker: Lightweight Virtualization for Serverless Applications（NSDI 2020 論文）
• Cloud Hypervisor
• Kata Containers
• gVisor Documentation
• E2B - AI Code Execution Sandbox
• Modal

構造・データ

• Firecracker Design Document
• Firecracker API (swagger)
• Firecracker Network Setup
• Firecracker Snapshotting
• Firecracker MMDS User Guide
• Kata Containers Architecture
• DeepWiki: Firecracker MicroVM

構築・利用

• Firecracker Getting Started
• Firecracker Jailer
• Firecracker rootfs and kernel setup
• Kata Containers Installation

運用・セキュリティ

• Firecracker CHANGELOG
• Firecracker Releases
• AWS Security Bulletins（2026-015-AWS として公表）
• GitHub Advisory GHSA-776c-mpj7-jm3r（CVE-2026-5747）
• CVE-2026-5747 - NVD
• Kata Containers Prometheus Monitoring Guide