Agent Sandbox 構築ガイド：AIコードを安全に実行する完全ソリューション

2025年春、セキュリティ研究者がある実験を行いました。YCombinator Springバッチの公開AI Agent 16個を全てテストしたのです。結果は？7個が侵害されました。ユーザーデータが漏洩したもの、リモートコード実行を許してしまったもの、データベースを削除してしまったものさえありました。

これがAI Agentにコードを実行させる代償です。自由を与えれば、穴を掘ってくれます。

私たちは皆、AIを使ってコードを書き、スクリプトを実行し、データを処理しています。でも正直に言って、考えたことはありますか？LLMが生成したコードをサーバーで直接実行する勇気はありますか？もし rm -rf / が実行されたら、あるいはAWSのキーが外部サーバーに密かに送信されたら？

だからAgent Sandboxが存在するのです。

なぜAI Agentにサンドボックス環境が必要なのか

正直に言うと、AI Agentと従来のアプリケーションの最大の違いは何でしょうか？会話ができることでも、指示を理解できることでもありません。自分でコードを書いて実行できることです。

こんなシナリオを想像してください：データ分析Agentに1GBの売上データを処理させるよう依頼します。Pythonコードを書いて読み込み、分析、グラフ生成を行います。このコードは完全にLLMが自動生成したもので、あなたは一度もレビューしていません。そして？実行されます。

ここには致命的なリスクがあります：

任意コード実行。LLMはセキュリティ境界を理解しません。os.system()、subprocess.run() などの関数は、考慮なしに使用します。巧妙に設計されたプロンプトで、任意のシステムコマンドを実行させることができます。

リソース枯渇攻撃。Agentが書くコードにはリソース意識がありません。単一の無限ループでCPUを使い果たし、暴走した再帰でメモリを爆発させます。サーバーはダウンします。

ファイルシステム侵害。ファイルアクセス制限がない場合、ディスク全体を読み取り、どこにでも書き込めます。設定ファイル、キー、ユーザーデータ—すべてが手の中に。

ネットワークデータ外部送信。コードにHTTPリクエストを隠し、機密データを攻撃者のサーバーに密かに送信できます。気づきません。

OWASPは2025年にAI AgentセキュリティTop 10を発表し、「Agent Tool Interaction Manipulation」が1位にランクされました。簡単に言えば、攻撃者はプロンプトインジェクションなどの方法で、Agentがツールを意図しない方法で使用させることができます。

実際の攻撃事例は既に存在します：

• Langflow RCE脆弱性：Horizon3が発見したリモートコード実行の欠陥。攻撃者は悪意のある入力を通じて任意のコードを実行可能。
• Cursor自動実行脆弱性：研究者がCursorが特定のMCPコマンドを自動実行することを発見。攻撃者は細工されたプロンプトでトリガー可能。
• Replitデータベース削除：AIが生成したコードがデータベース全体を誤って削除。

サンドボックスはオプションではありません。AI Agentアプリケーションのインフラです。ファイアウォールなしでサーバーを公開インターネットに露出しないのと同じように、サンドボックスなしでAIにコードを実行させてはいけません。

サンドボックスのコアバリューは3つ：隔離—リスクのあるコードを檻に閉じ込める；制限—CPU、メモリ、ネットワーク、ファイルアクセスに上限を設定；監査—何が起きたかを記録し、問題発生時に調査可能。

主要サンドボックス技術の比較

サンドボックスが必要なのは分かりました。では何を使うべきでしょうか？現在、3つの主要な技術アプローチがあります：コンテナ（Docker）、gVisor、FirecrackerマイクロVM。

まず比較表を：

ソリューション	セキュリティ隔離	起動速度	リソースオーバーヘッド	使用例
Dockerコンテナ	★★☆☆☆	★★★★★	★★★★★	開発/テスト、低リスクコード
gVisor	★★★★☆	★★★★☆	★★★☆☆	本番環境、中程度リスク
Firecracker	★★★★★	★★★★☆	★★★☆☆	高セキュリティ要件、本番デプロイ

Dockerコンテナ：高速だが不十分なセキュリティ

Dockerは最も一般的な選択です。高速起動、低リソース消費、成熟したエコシステム。しかし問題があります：Dockerコンテナはホストとカーネルを共有しています。

どういうこと？コンテナ内のプロセスは名前空間で隔離されていますが、攻撃者がカーネルの脆弱性を悪用すると、コンテナ境界を突破し、ホストのroot権限を取得できます。

2024年には複数のコンテナエスケープ脆弱性が公開されました。信頼できないAI生成コードにとって、Dockerのセキュリティ境界は不十分です。

gVisor：ユーザー空間で「偽カーネル」を構築

gVisorはGoogleのオープンソースプロジェクトで、興味深いアプローチをとっています—ホストカーネルを直接使わず、ユーザー空間に「偽カーネル」（Sentryと呼ばれる）を実装します。

コンテナ内のプログラムがシステムコールを行うと、gVisorがそれを遮断し、Sentryが処理します。Sentryは安全な操作のみを許可し、危険なものは拒否します。これにより、コードが破壊を試みても、実際のカーネルに触れることができません。

gVisorの利点は良好な互換性—ほとんどのDockerイメージが直接動作します。欠点はパフォーマンスオーバーヘッド（約10-20%）と、一部の特殊なシステムコールがサポートされない可能性があります。

GKE（Google Kubernetes Engine）はgVisorをネイティブサポート—Pod設定に runtimeClassName: gvisor を追加するだけです。

Firecracker：真のハードウェアレベル隔離

FirecrackerはAWSのオープンソースマイクロVM技術です。各サンドボックスは独自の独立したカーネルを持つ小さな仮想マシンです。

これはどういう意味？攻撃者がサンドボックス内でroot権限を取得し、カーネルの脆弱性を悪用しても、VM内で遊んでいるだけ—ホストに影響を与えることはできません。

Firecrackerは100-800ミリ秒の起動速度を実現し、従来のVMよりもはるかに低いリソースオーバーヘッド（VMは最小128MBのメモリで動作）。

E2B、AWS Bedrock AgentCoreなどの専門AIコードサンドボックスサービスは、すべてFirecrackerを使用しています。

選択の決定フレームワーク

どう選ぶ？シンプルな決定ツリーを：

1. ローカル開発/テストのみ？Dockerで十分—便利で高速。
2. 本番環境にデプロイ？
   • 中程度のセキュリティ要件、パフォーマンス重視 → gVisor
   • 高セキュリティ要件、コンプライアンス必要 → Firecracker
3. インフラを管理したくない？マネージドサービス（E2B、Bedrock AgentCore）

実践：ローカル開発サンドボックスの構築

理論は十分—実際に構築しましょう。アプローチ：FastAPI + Jupyter Kernel + gVisorコンテナ。

なぜこの組み合わせ？

• FastAPIはクリーンなHTTPインターフェースを提供し、AI AgentがREST APIでコード実行リクエストを送信可能
• Jupyter Kernelは変数永続化をサポートするインタラクティブなPython実行環境を提供
• gVisorコンテナはセキュリティ隔離を提供し、悪意のあるコードがホストに影響するのを防止

ステップ1：FastAPIサービスの作成

main.pyファイルを作成：

# main.py
import asyncio
from contextlib import asynccontextmanager
from fastapi import FastAPI, HTTPException
from jupyter_client.manager import AsyncKernelManager
from pydantic import BaseModel

app = FastAPI()

class CodeRequest(BaseModel):
    code: str

class ExecutionResult(BaseModel):
    output: str

@asynccontextmanager
async def kernel_client():
    """Jupyter Kernelライフサイクル管理"""
    km = AsyncKernelManager(kernel_name="python3")
    await km.start_kernel()
    kc = km.client()
    kc.start_channels()
    await kc.wait_for_ready()
    try:
        yield kc
    finally:
        kc.stop_channels()
        await km.shutdown_kernel()

async def execute_code(code: str, timeout: int = 30) -> str:
    """コードを実行して結果を返す"""
    async with kernel_client() as kc:
        msg_id = kc.execute(code)
        try:
            while True:
                reply = await asyncio.wait_for(
                    kc.get_iopub_msg(),
                    timeout=timeout
                )
                if reply["parent_header"]["msg_id"] != msg_id:
                    continue
                msg_type = reply["msg_type"]
                if msg_type == "stream":
                    return reply["content"]["text"]
                elif msg_type == "error":
                    return f"Error: {reply['content']['evalue']}"
                elif msg_type == "status" and reply["content"]["execution_state"] == "idle":
                    break
        except asyncio.TimeoutError:
            return "Error: Execution timed out"
    return ""

@app.post("/execute", response_model=ExecutionResult)
async def execute(request: CodeRequest):
    """コード実行エンドポイント"""
    try:
        output = await execute_code(request.code)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))
    return ExecutionResult(output=output)

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

コアロジック：各実行リクエストで独立したJupyter Kernelを起動し、コードを実行し、結果を返し、Kernelを破棄。

ステップ2：Dockerfileの作成

FROM jupyter/base-notebook:latest

WORKDIR /app

COPY main.py /app/main.py
COPY requirements.txt /app/requirements.txt

RUN pip install --no-cache-dir -r requirements.txt

# 非rootユーザーを使用（セキュリティベストプラクティス）
USER jovyan

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

USER jovyanに注目—これはセキュリティプラクティスです。非rootでコンテナを実行すると、コードがエスケープしても権限は制限されます。

ステップ3：GKEにデプロイ（gVisor有効化）

GKEを使用している場合、Pod設定に1行追加：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor  # キー：gVisorを有効化
      containers:
      - name: sandbox
        image: your-registry/agent-sandbox:latest
        ports:
        - containerPort: 8000
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"

これで、コード実行環境がgVisorサンドボックス内で動作します。

ステップ4：セキュリティ制限の追加

上記の設定は不完全です。本番環境では少なくともこれらの制限を追加：

# ネットワークポリシー：必要なAPIのみに制限
# 読み取り専用ファイルシステム
securityContext:
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

# 実行タイムアウト設定
# FastAPIコードに既にtimeoutパラメータを追加済み

応用：Kubernetesクラスタデプロイ

AI Agentアプリケーションが大規模デプロイを必要とする場合、単一コンテナでは不十分です。ここでKubernetesのAgent Sandboxコントローラーが登場します。

Googleは2025年にAgent Sandboxをオープンソース化し、宣言的なサンドボックス管理APIを提供しています。

Sandbox CRDコアコンセプト

Agent Sandboxはいくつかのカスタムリソースを定義：

• Sandbox：安定したID、永続ストレージ、ライフサイクル管理を持つ単一サンドボックスインスタンス
• SandboxTemplate：標準化された設定を定義するサンドボックステンプレート
• SandboxClaim：オンデマンドサンドボックスインスタンスリクエスト

シンプルなSandbox設定例：

apiVersion: sandbox.k8s.io/v1alpha1
kind: Sandbox
metadata:
  name: my-agent-sandbox
spec:
  template:
    spec:
      runtimeClassName: gvisor
      containers:
      - name: executor
        image: python:3.11-slim
        command: ["sleep", "infinity"]
      # 永続ストレージ
      volumes:
      - name: workspace
        emptyDir: {}
      # リソース制限
      resources:
        limits:
          memory: "1Gi"
          cpu: "1"

ライフサイクル管理

Agent Sandboxのハイライトの1つはpause/resumeサポート：

# サンドボックスを一時停止（CPUと大部分のメモリを解放）
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":true}}'

# サンドボックスを再開
kubectl patch sandbox my-agent-sandbox --type=merge -p '{"spec":{"paused":false}}'

これは断続的に実行されるAI Agentに特に有用—アイドル時に一時停止（ほぼリソース消費なし）、仕事があるとき秒単位で再開。

ウォームプール

起動レイテンシーをさらに削減するため、Agent Sandboxは「ウォームプール」をサポート—一時停止状態のサンドボックスを事前に作成し、オンデマンドでアクティブ化。

これによりサンドボックスの「コールドスタート」時間が秒からミリ秒に短縮されます。

マネージドサービス選択ガイド

インフラを自分で管理したくない場合、マネージドサービスが良い選択です。主流のオプション：

E2B：オープンソース + クラウドホスティング

E2BはAI Agent専用に設計されたコードサンドボックスサービスです。2つのバージョンがあります：

• E2B Cloud：クラウドサービスを直接使用、従量課金
• E2B on AWS：オープンソース版を自分のAWSアカウントにデプロイ

E2BはFirecrackerをベースにしており、セキュリティは確保されています。SDKはシンプル：

from e2b import Sandbox

# サンドボックス作成
sandbox = Sandbox()

# コード実行
result = sandbox.run_code("print('Hello, World!')")

# サンドボックスクローズ
sandbox.close()

E2B on AWSはデータ主権要件のある企業に特に適しています—全てのデータが自分のアカウントに留まります。

AWS Bedrock AgentCore

AWSは2025年にBedrock AgentCoreを立ち上げ、AI Agentのコード実行とブラウザ操作を専門に提供しています。

Code InterpreterはPython/JavaScript/TypeScriptランタイムを提供し、各セッションは独立したマイクロVMで実行され、最大5GBのファイルをサポート。

Browser ToolはAI Agentにブラウザ操作を可能にします—ページを開き、フォームに入力し、ボタンをクリック。これはウェブページをスクレイピングしたり、SaaSアプリケーションを操作するAgentに特に有用。

課金モデルは合理的：vCPUとメモリの実際の使用時間に対して支払い、インスタンス実行時間ではありません。コード実行終了後、リソースは自動的に解放されます。

選択推奨

シナリオ	推奨ソリューション
迅速な検証、小規模アプリ	E2B Cloud
エンタープライズ、データローカライズ必要	E2B on AWS または Bedrock AgentCore
AWSエコシステム深層ユーザー	Bedrock AgentCore
ブラウザ自動化必要	Bedrock AgentCore Browser Tool
完全制御、運用能力あり	セルフホストKubernetes + Agent Sandbox

結論

結局のところ、コアメッセージはシンプルです：セキュリティはオプションではない—AI Agentアプリケーションのインフラです。

技術選択について：

• 小規模チーム、迅速な検証—DockerまたはgVisorで十分
• エンタープライズアプリ、高セキュリティ要件—Firecrackerまたはマネージドサービス
• 既にKubernetes使用中—Agent Sandboxコントローラーを選択

何を選ぶにせよ、ローカルテストから始めましょう。最もシンプルなFastAPI + Docker設定を書き、実行し、その後セキュリティ強化と本番デプロイを検討します。

覚えておいてください：早期にサンドボックスを追加。セキュリティインシデントを待ってから対策するのは、コストがはるかに高くなります。

AI Agentサンドボックス環境の構築

安全なAIコード実行環境をゼロから構築

⏱️ 目安時間: 60 分

1. 1

   ステップ1: FastAPIサービスの作成

   main.pyファイルを作成し、コード実行エンドポイントを実装：
   
   • AsyncKernelManagerでJupyter Kernelを管理
   • 実行タイムアウトを設定（デフォルト30秒）
   • 実行結果またはエラーメッセージを返す
2. 2

   ステップ2: Dockerfileの作成

   jupyter/base-notebookイメージをベースにビルド：
   
   • 依存関係をインストール（FastAPI、uvicorn）
   • 非rootユーザー（jovyan）で実行
   • ポート8000を公開
3. 3

   ステップ3: Kubernetesにデプロイ

   gVisorを有効化するPod設定：
   
   • runtimeClassName: gvisor を設定
   • リソース制限を設定（CPU/メモリ）
   • セキュリティコンテキストを追加（読み取り専用ファイルシステム）
4. 4

   ステップ4: サンドボックス隔離の検証

   セキュリティ境界をテスト：
   
   • ホストファイルシステムへのアクセスを試行（拒否されるべき）
   • リソース集約型コードを実行（制限されるべき）
   • ネットワーク隔離が機能するか確認

FAQ

DockerコンテナとgVisorの違いは？

Dockerコンテナはホストとカーネルを共有します。攻撃者がカーネルの脆弱性を悪用するとエスケープ可能です。gVisorはユーザー空間に「偽カーネル」（Sentry）を実装し、全システムコールを遮断して安全な操作のみを許可し、より強力な隔離を提供します。

いつgVisorではなくFirecrackerを使うべき？

セキュリティ要件が極めて高い場合にFirecrackerを選択：

• ハードウェアレベルの隔離が必要（金融、医療データなど）
• 厳格なコンプライアンス要件を満たす必要
• 完全に信頼できないサードパーティコードを処理

gVisorはパフォーマンスオーバーヘッドが低く（10-20%）、ほとんどの本番シナリオに適しています。

E2BとAWS Bedrock AgentCoreの選び方は？

E2Bは迅速な検証とオープンソース管理に適しています：
• 小規模アプリはE2B Cloudから開始
• データローカライズにはE2B on AWS

Bedrock AgentCoreはAWSエコシステム深層ユーザーに適しています：
• 既にAWSサービスを使用中なら統合が容易
• ブラウザ自動化にはBrowser Toolを選択

サンドボックスはコード実行パフォーマンスに影響する？

ある程度の影響はあります：Dockerはほぼ損失なし、gVisorは約10-20%のオーバーヘッド、Firecrackerは約15-30%のオーバーヘッド。しかし、AI Agentのコード実行シナリオ（データ分析、スクリプト処理）では、このオーバーヘッドは通常許容範囲です。

ローカル開発でサンドボックスを素早く構築するには？

最もシンプルな方法：gVisor有効なコンテナをDockerで実行。GKEを使用している場合、Pod設定に `runtimeClassName: gvisor` を追加するだけ。純粋なローカル開発では、Dockerの隔離でも十分—重要なのはリソース制限とユーザー権限の設定です。

5 min read · 公開日: 2026年3月23日 · 更新日: 2026年3月23日