ブログ · ガイド · 2026年10月28日

Firecracker で AEGIS をセルフホストする: ドキュメントが述べる構成と、今日動くもの

他の言語: English, Español, Português · 日本語のガイド一覧

開示: AEGIS は 100monkeys.ai が開発しているため、このガイドは作り手による説明として読んでください。AEGIS の公開ドキュメント、主に Firecracker Deployment、What are Agents?、Infrastructure Requirements、Podman Deployment をもとに当社の AI エージェントが下書きし、当社がレビューしました。この日本語版は英語の原文ガイドの翻訳です。コマンドと設定ブロックはすべてそれらのページからコピーしたもので、引用は英語のまま示し訳を添えています。このガイドのためにどれも実行してはいません。

AEGIS by 100monkeys.ai, in beta は、自律エージェントのためのセルフホスト型オーケストレーターです。そのドキュメントは、強化された本番環境の隔離として Firecracker の microVM を挙げています。ハードウェアを買う前に、そのページの最初の行を読んでください。"Firecracker support is planned for a future release and is not yet available. The Docker and Podman runtimes are the current deployment targets."(Firecracker 対応は将来のリリースで計画されており、まだ利用できない。現在のデプロイ対象は Docker と Podman のランタイムである。)このガイドでは今日できることを扱います。ホストを確認し、計画中のランタイムについてドキュメントが記載している設定を読み、すでに提供されている Podman の手順を動かします。

なぜ Firecracker なのか、ドキュメントの言葉で

"Docker containers share the host kernel: a container escape vulnerability could give a malicious prompt-injected agent code execution on the host. Firecracker provides hardware-level isolation via KVM."(Docker コンテナはホストのカーネルを共有する。コンテナ脱出の脆弱性があれば、プロンプトインジェクションを受けた悪意あるエージェントがホスト上でコードを実行しうる。Firecracker は KVM によるハードウェアレベルの隔離を提供する。)ページの比較表では、各エージェントに "a dedicated guest kernel per agent"(エージェントごとの専用ゲストカーネル)、脱出時の影響範囲は "bounded to single microVM"(単一の microVM に限定)、ストレージはコンテナの NFS に対して virtio-fs で "shared memory, no network"(共有メモリ、ネットワークなし)。代償として、起動時間はコンテナの約 100 ms に対して約 125 ms とされています。

この設計では、ランタイムが変わってもエージェントは変わりません。"Switching a node from Docker to Podman or Firecracker requires only a config change: no agent manifest changes needed."(ノードを Docker から Podman や Firecracker に切り替えるのは設定変更だけで済み、エージェントのマニフェストを変える必要はない。)だから今準備しても無駄になりません。

ステップ 1. ホストの KVM を確認する

Firecracker には KVM が必要で、ドキュメントによればそれは "bare-metal Linux servers with Intel VT-x or AMD-V CPU virtualization extensions"(Intel VT-x または AMD-V の CPU 仮想化拡張を持つベアメタルの Linux サーバー)、あるいはベアメタルか入れ子仮想化を備えたクラウドインスタンスを意味します。"NOT supported on standard EC2 instances without bare-metal, most VMs (including standard VMs on most cloud providers), and macOS (Docker Desktop)."(ベアメタルでない標準の EC2 インスタンス、ほとんどの VM(大半のクラウドプロバイダーの標準 VM を含む)、macOS(Docker Desktop)ではサポートされない。)ドキュメントの確認手順をそのままコピーします。

# Check for KVM device nodes
ls -la /dev/kvm

# Verify CPU virtualization extensions
grep -cw vmx /proc/cpuinfo   # Intel (should return > 0)
grep -cw svm /proc/cpuinfo   # AMD  (should return > 0)

クラウド VM で /dev/kvm がなければ、他に何があっても、そのホストは Firecracker ランタイムが提供されたときに動かせません。

ステップ 2. カーネルを確認する

uname -r を実行してドキュメントと比べてください。2つのページが2つの最低要件を挙げています。What are Agents? は "Bare-metal or KVM-passthrough host, Linux kernel 5.10+"(ベアメタルまたは KVM パススルーのホスト、Linux カーネル 5.10 以上)、Infrastructure Requirements は "Linux kernel 5.15+"(Linux カーネル 5.15 以上)と "KVM support for Firecracker (planned later phase)"(Firecracker のための KVM 対応、後のフェーズで予定)です。5.15 以上を前提にすれば両方を満たします。

ステップ 3. ドキュメントに記載された設定を読む

計画中のランタイムは aegis-config.yaml の runtime.firecracker で設定します。ページのブロックをそのままコピーします。

runtime:
  type: firecracker
  firecracker:
    # Path to the jailer binary
    jailer_binary: /usr/local/bin/jailer
    # Path to the Firecracker VMM binary
    firecracker_binary: /usr/local/bin/firecracker
    # User/group for the jailed process
    uid: 65534   # nobody
    gid: 65534
    # Kernel image for microVMs
    kernel_image_path: /opt/aegis/vmlinux
    # Root filesystem for agent microVMs (minimal Linux + Python)
    rootfs_path: /opt/aegis/agent-rootfs.ext4
    # CPU and memory limits
    vcpu_count: 2
    mem_size_mib: 512
    # cgroup version (v1 or v2)
    cgroup_version: v2

ホストに何を求めるかという観点で読んでください。jailer と Firecracker のバイナリ、特権のない uid と gid、ゲストカーネルのイメージ、エージェントのルートファイルシステム、VM ごとの CPU とメモリです。jailer は "drops privileges before starting the VMM"(VMM を起動する前に特権を手放す)。chroot の牢獄、事前に作成した tap インターフェースと cgroup、seccomp フィルターを使います。各 microVM は専用の tap デバイスを持ち、"outbound traffic from the microVM is routed through the orchestrator proxy (SEAL), not directly to the internet"(microVM からの外向き通信はインターネットに直接ではなく、オーケストレーターのプロキシ(SEAL)を経由する)。

このブロックを今日デプロイしないでください。カーネルイメージとルートファイルシステムをどこから入手するかはドキュメントに書かれておらず、それを読むランタイムは "in development"(開発中)とされています。

ステップ 4. 今日は Podman で AEGIS を動かす

今の本番環境について、ドキュメントは aegis-deploy リポジトリを示しています。"aegis-deploy is the recommended production deployment path. It includes OpenBao (secrets management), TLS via Caddy, and full observability."(aegis-deploy は推奨される本番デプロイ手段で、OpenBao(シークレット管理)、Caddy による TLS、完全な可観測性を含む。)そのクイックスタートをそのままコピーします。

# Clone the deployment repo
git clone https://github.com/100monkeys-ai/aegis-deploy.git
cd aegis-deploy

# Copy and edit environment configuration
cp .env.example .env
# Edit .env with your values (GHCR credentials, passwords, LLM API keys)

# Install system dependencies (Ubuntu)
make setup

# Authenticate with GitHub Container Registry
make registry-login

# Generate SEAL signing keys
make generate-keys

# Deploy the full stack
make deploy PROFILE=full

# Validate all services are healthy
make validate

# Bootstrap secrets
make bootstrap-secrets

Podman はエージェントをルートレスで動かします。ドキュメントによれば、これにより "the privileged daemon"(特権デーモン)がなくなり、コンテナの root は "to an unprivileged host UID"(ホストの特権のない UID に)対応づけられます。1台のマシンで評価するなら、100monkeys.ai に載っているワンライナーのインストーラーは curl -fsSL https://get.100monkeys.ai | bash で、ローカルの Docker スタックを立ち上げます。ドキュメントはこのスタックを "for local testing and evaluation only"(ローカルでのテストと評価専用)としています。

ステップ 5. 切り替えを設定変更だけにしておく

エージェントのマニフェストでは隔離方式を固定せず、ノードに決めさせてください。マニフェストの isolation フィールドは inherit、firecracker、docker、process を受け付け、既定値は inherit、つまり "from node config"(ノードの設定から)です。設定リファレンスの例ではノードの default_isolation を docker にしており、この値は "works with both Docker and Podman runtimes"(Docker と Podman の両ランタイムで動く)。Firecracker が提供されたとき、変更するのはノードで、各エージェントではありません。

ステップ 6. 進捗を追う

ページはこう締めくくっています。"Monitor progress on Firecracker support in the aegis-orchestrator GitHub repository."(Firecracker 対応の進捗は aegis-orchestrator の GitHub リポジトリで確認できる。)ランタイムを含むリリースが告知されるのはそこです。

ドキュメントが明示していないこと

次に読む

評価用スタックをインストールし、承認の後ろで最初のエージェントを動かすには、新しい Ubuntu VPS に AEGIS をインストールし、最初の承認付きタスクを実行するを読んでください。

100monkeys.ai から AEGIS をインストール