「エージェントにコード実行させるのは銀行監査で即アウト」──2026年初頭、X上でこの指摘が大きな反響を呼んだ。LLMベースのAIエージェントが未信頼コードを本番環境で実行するユースケースが急拡大する一方、従来のDockerコンテナでは隔離が不十分であることが繰り返し指摘されている。本稿では、Firecracker MicroVM、gVisor、Kata Containers、Landlock LSMの4技術を比較し、AIエージェントの本番実行環境に求められる多層隔離アーキテクチャの設計パターンを解説する。

なぜDockerだけでは不十分なのか ── AIエージェント実行の脅威モデル

AIエージェントがコードを生成・実行するシナリオでは、従来のWebアプリケーションとは根本的に異なる脅威モデルが発生する。エージェントが生成するコードは本質的に「未信頼コード」であり、プロンプトインジェクションを通じて意図しないシステムコールやファイルアクセスが実行されるリスクがある。

2025年末に発覚したClawHub事件では、AIエージェント向けマーケットプレイスに登録されたスキルの約12%（341件）がマルウェアであったことが判明した。また、MCP（Model Context Protocol）エージェントを標的としたゼロクリック攻撃「Shadow Escape」では、ChatGPTやGoogle Geminiのシステムからデータが流出する事案が報告されている。

Dockerコンテナはカーネルを共有する構造上、カーネル脆弱性を突いたコンテナエスケープに対して本質的に脆弱である。CVE-2025-23266（NVIDIAScape）ではNVIDIA Container Toolkitを介したコンテナエスケープがCVSS 9.0で報告され、クラウド環境の37%が影響を受けた。AIエージェントの実行基盤には、カーネル共有に依存しない隔離境界が不可欠である。

Firecracker MicroVM ── AWS Lambdaを支える軽量仮想化

Firecracker は Amazon Web Services が開発したRust製の軽量VMM（Virtual Machine Monitor）であり、AWS LambdaおよびAWS Fargateの基盤技術として稼働している。2025年1月にリリースされたv1.14.1が最新の安定版である。

最大の特長はその軽量性にある。起動時間は125ミリ秒以下、メモリオーバーヘッドは1 vCPU・128MiBゲスト構成で5MiB未満、1ホストあたり毎秒150台のMicroVMを生成できる。CPU性能はベアメタルの95%以上を維持する。各MicroVMは独自のLinuxカーネルを持つため、ホストカーネルとゲストカーネルの間に完全なハードウェア仮想化境界が存在する。

v1.14.0（2024年12月）ではvirtio-pmemデバイスサポート、virtio-memによるメモリホットプラグ、バルーン統計の強化が実装された。v1.14.1ではJailerバイナリコピー時のシンボリックリンク・ハードリンクを禁止するセキュリティ強化が行われており、権限昇格の経路を遮断している。

AIエージェントのサンドボックスとしてFirecrackerを採用する場合、エージェントごとに専用のMicroVMを起動し、コード実行後にVMを破棄する「使い捨て型」のアーキテクチャが推奨される。クラウドサンドボックスサービスのE2Bはこのアプローチを採用しており、コールドスタート150ミリ秒で数千のサンドボックスを同時実行可能としている。

gVisor ── ユーザー空間カーネルによるシステムコール仲介

gVisorはGoogleが開発したユーザー空間カーネルであり、GKE Sandbox、Google App Engine、Cloud Functionsの基盤として本番運用されている。Firecrackerがハードウェア仮想化で隔離するのに対し、gVisorはシステムコールレベルで仲介するアプローチをとる。

アーキテクチャは2つのコンポーネントで構成される。SentryはGo言語で実装されたLinuxカーネルの再実装であり、コンテナからのシステムコールを受け取り、安全な範囲で処理する。Goferはファイルシステムプロキシプロセスであり、ファイル操作をブローカーとして仲介する。この設計により、コンテナは直接ホストカーネルにシステムコールを発行できない。

ファイルシステム性能については、LISAFSプロトコルの導入により、従来の9Pプロトコルと比較してファイルI/Oが50〜75%高速化された。コールドスタートは平均25%以上改善されたとGoogleが報告している。一方、システムコールのオーバーヘッドはgVisor最大のコストであり、特にシステムコール頻度の高いワークロードでは性能低下が顕著になる。計算集約型のワークロード（TensorFlowなど）ではネイティブに近い性能を維持する。

AIエージェントのユースケースにおけるgVisorの利点は、Seccompよりも柔軟かつ包括的なシステムコールフィルタリングにある。エージェントが生成するコードが予期しないシステムコール（ネットワークソケットの作成、デバイスファイルへのアクセスなど）を発行した場合、Sentryがこれを検知・遮断できる。ただし、ハードウェア仮想化と異なり、カーネル脆弱性に対する保護は限定的である。

Kata Containers ── コンテナセマンティクスとハードウェア隔離の統合

Kata Containersは、OCI（Open Container Initiative）準拠のコンテナランタイムでありながら、各コンテナを軽量VMとして実行する。最新版はv3.26.0であり、ハイパーバイザーとしてQEMU/KVM、Cloud-Hypervisor、Firecrackerを選択できる。

アーキテクチャ上の特徴は、containerd-shim-kata-v2を通じてKubernetesと透過的に統合される点にある。VM内部ではgRPCエージェントがVIRTIOシリアルまたはVSOCKインターフェース経由で通信する。これにより、既存のKubernetesマニフェストをほぼそのまま利用しながら、Podレベルのハードウェア隔離を実現できる。

性能面では、起動時間は150〜300ミリ秒とFirecrackerよりやや遅く、ファイルI/O帯域幅はネイティブの約14%（581〜752MB/s）にとどまる。一方で、システムコール性能はgVisorより良好であり、カーネルレベルの隔離強度はFirecrackerと同等である。

AIエージェント基盤としてKata Containersが特に有効なのは、既存のKubernetesインフラへの統合が求められる場合である。エージェントワークロード専用のRuntimeClassを定義し、通常のコンテナと混在して運用できる柔軟性がある。また、Rust実装への移行（runtime-rs）が進んでおり、TDX/SNPベースのConfidential Computingとの統合も進展している。

Landlock LSM ── カーネルレベルのアクセス制御補完層

Landlock LSM（Linux Security Module）は、Linux 5.13で導入された非特権アクセス制御メカニズムであり、プロセスが自身のファイルシステムアクセスやネットワークアクセスをプログラム的に制限できる。root権限を必要とせず、コンテナやVM内部からも適用可能である点が他のLSM（SELinux、AppArmor）との最大の違いである。

ABI（Application Binary Interface）のバージョンごとに機能が拡張されており、ABI 1（Linux 5.13）ではファイルシステムアクセス権の制御、ABI 2（Linux 5.19）ではファイル参照制御、ABI 3（Linux 6.2）ではtruncate操作の制御、Linux 6.4ではネットワーク制限が追加された。最新のABI 7では監査イベントログの制御が可能になっている。

多層隔離アーキテクチャにおけるLandlockの役割は「最内層の防御」である。MicroVMやgVisorで外側の隔離境界を構築した上で、VM内部またはSentry内部で実行されるエージェントプロセスに対してLandlockルールを適用する。これにより、たとえVMエスケープやgVisorバイパスが発生した場合でも、プロセスのアクセス範囲が制限される。具体的には、エージェントの作業ディレクトリ以外へのファイルアクセスの禁止、許可されたポート以外へのネットワーク接続の遮断などが実現できる。

多層隔離アーキテクチャの設計パターン

本番環境でAIエージェントの安全なコード実行を実現するには、単一の隔離技術に依存するのではなく、複数の技術を組み合わせた多層防御が必要である。以下に推奨する3層構成を示す。

第1層：ハードウェア仮想化（Firecracker / Kata Containers）──各エージェントセッションに専用のMicroVMを割り当て、カーネルレベルの隔離を確保する。VMは使い捨てとし、セッション終了後に破棄する。ネットワークはVMレベルでフィルタリングし、必要最小限のエンドポイントへのアクセスのみを許可する。

第2層：システムコール制御（gVisor / Seccomp-BPF）──VM内部でさらにgVisorまたはSeccomp-BPFプロファイルを適用し、エージェントが利用可能なシステムコールを制限する。ファイルシステム操作、ネットワーク操作、プロセス生成に対して明示的な許可リストを定義する。

第3層：プロセスレベルアクセス制御（Landlock LSM）──エージェントプロセスに対してLandlockルールを適用し、作業ディレクトリ外へのアクセスやネットワーク接続を制限する。root権限なしで適用できるため、VM内部でも容易に導入できる。

この3層構成に加え、監査・可観測性の観点から、各層のセキュリティイベントを集中ログシステムに送信する仕組みが不可欠である。SOC2 Type IIやPCI-DSS、日本のFISCセキュリティガイドラインへの準拠においては、エージェントの全操作に対する決定論的な監査証跡（Thought → Tool Call → Observation → Response）が求められる。EU AI規則（2026年8月施行）では高リスクAIシステムに対する詳細なログ記録が義務付けられ、違反には最大3,500万ユーロまたは全世界売上高の7%の制裁金が科される。

クラウドサンドボックスサービスの比較 ── E2B・Modal・Daytona

自前でMicroVM基盤を構築する代わりに、AIエージェント向けのクラウドサンドボックスサービスを利用する選択肢も拡大している。主要3サービスを比較する。

E2BはFirecracker MicroVMを基盤とし、コールドスタート150ミリ秒、最大24時間のセッション持続、Kubernetes上での大規模同時実行に対応する。隔離強度はMicroVMに裏打ちされており、コンプライアンス要件の厳しい環境に適している。

ModalはGPU最適化のMLワークロードに特化し、ゼロから数千インスタンスへのスケーリングを数秒で実行できる。Pythonワークロードが中心であり、AI推論とコード実行を組み合わせるユースケースに強い。ただし、隔離レベルは標準的なコンテナベースである。

Daytonaはコールドスタート27〜90ミリ秒という業界最速の起動性能を実現する。Docker コンテナベースの隔離であるため、セキュリティ強度ではE2Bに劣るが、リアルタイム性が求められるインタラクティブなエージェントセッションに適している。

選定基準としては、金融・医療・政府機関など規制産業ではE2BのMicroVM隔離、MLワークロード中心ならModalのGPU最適化、低レイテンシが最優先ならDaytonaの起動速度が判断軸となる。

FAQ

AIエージェントにDockerコンテナだけでコードを実行させるのは危険か？

Dockerはカーネルを共有する構造上、カーネル脆弱性を突いたコンテナエスケープのリスクがある。AIエージェントが生成する未信頼コードの実行には、MicroVMやgVisorなどの追加隔離層を組み合わせた多層防御が推奨される。

Firecracker MicroVMとKata Containersのどちらを選ぶべきか？

Firecrackerは起動速度（125ms以下）とリソース効率に優れ、使い捨て型サンドボックスに最適である。Kata Containersは既存のKubernetesインフラとの統合が容易で、既にK8sクラスタを運用している環境に向いている。

gVisorの性能オーバーヘッドはどの程度か？

システムコール頻度の高いワークロードでは顕著な性能低下が発生するが、計算集約型のタスクではネイティブに近い性能を維持する。LISAFSプロトコルの導入でファイルI/Oは50〜75%改善されている。

SOC2やPCI-DSS監査でAIエージェントの実行はどう評価されるか？

現行のSOC2 Type IIやPCI-DSSにはAIエージェントの自律的コード実行に関する明示的なガイダンスがない。アーキテクチャレベルでの隔離設計と、全操作の決定論的な監査証跡の記録が監査対応の鍵となる。

Landlock LSMはどのLinuxカーネルバージョンから使えるか？

Linux 5.13以降で利用可能である。ファイルシステム制御はABI 1（5.13）、ネットワーク制限はLinux 6.4以降で対応する。最新のABI 7では監査イベントログの制御も可能になっている。

参考文献