AIエージェントのコード実行、本番環境に直結していませんか

コード生成AIエージェントに「このスクリプトを実行して」「このパッケージをインストールして」と指示している開発チームは、そのコードがどこで動いているか把握できているでしょうか。フロントエンド開発でもAIエージェントにビルドコマンドやCLIツールの実行を任せる場面が増えています。実行環境の分離を後回しにしているプロジェクトは少なくないはずです。

本記事では、Kubernetes（コンテナ運用を自動化する基盤ソフトウェア）上でAIエージェントのコード実行環境を分離する「Agent Sandbox」という仕組みを取り上げます。GKE（Google Kubernetes Engine、GoogleのマネージドKubernetesサービス）が提供する機能と、その裏にあるオープンソースのkubernetes-sigs/agent-sandboxプロジェクトが対象です。

何が起きるか: エージェントに実行権限を渡すリスク

AIエージェントに「このシェルコマンドを実行して」と頼むのは、プログラミングの本は全部読んでいるが危機回避能力がゼロの新人に、鍵の束を渡すようなものです。

LLM（大規模言語モデル）が生成したコードは、意図せずrm -rf相当の破壊的操作を実行してしまう可能性があります。悪意はなくても、一時ファイルの掃除だと誤認識して本番ディレクトリを消すようなケースです。

フロントエンドの文脈で言えば、AIエージェントにnpm installやビルドスクリプトの実行、ブラウザ操作（Playwrightなどでのクリック操作）を任せる場面が増えています。これらがホストマシンや共有CI環境で直接実行されていると、影響範囲はプロジェクト全体に及びます。

なぜ起きるか: 実行環境が「借り物」のままだから

根本的な原因は、AIエージェントの実行基盤が人間の開発者用に作られたシェル環境やコンテナをそのまま使い回している点にあります。

人間のエンジニアがターミナルで打つコマンドには、経験に基づく「これは危険だ」という直感が働きます。エージェントにはその直感がありません。

さらに、多くのAIコーディングツールは実行結果を素早く返すことを優先し、サンドボックス化（隔離された仮想環境での実行）のコストを後回しにしています。結果として、開発チームは「速いが危険」な構成のまま本番に近い環境を触らせてしまいます。

Agent Sandboxは、この問題に対してKubernetesのCRD（Custom Resource Definition、Kubernetesの機能を拡張する独自リソース定義）を使って答えを出しています。中心となるのは4つのリソースです。

Sandbox: 安定したホスト名と永続ストレージを持つ、1台のLinuxボックスのような存在
SandboxTemplate: イメージやリソース制限、gVisorやKataといったランタイムクラスを定義した設計図
SandboxClaim: 開発者やエージェントSDKが「サンドボックスが欲しい」と要求するインターフェース
SandboxWarmPool: 事前起動済みのPodを保持し、要求が来たら即座に割り当てる高速化の仕組み

gVisorはGoogleが開発したユーザースペースカーネルで、コンテナとホストカーネルの間に隔離層を作ります。Kataはハードウェア仮想化を使ってコンテナを軽量VM相当に隔離する技術です。どちらもデフォルトのcontainerdランタイムより隔離レベルが高い分、オーバーヘッドも増えます。

自分のプロジェクトが該当するか確認する方法

まず、AIエージェントやCIパイプラインがどこでコードを実行しているかを洗い出します。

# CI設定でエージェント関連のジョブがホストで直接実行されていないか確認
grep -r "agent\|copilot\|claude\|codex" .github/workflows/ 2>/dev/null

# 現在のコンテナランタイムを確認（Kubernetes環境の場合）
kubectl get nodes -o jsonpath='{.items[*].status.nodeInfo.containerRuntimeVersion}'

# 実行中のPodがどのRuntimeClassを使っているか確認
kubectl get pods -o jsonpath='{.items[*].spec.runtimeClassName}'

RuntimeClassNameが空欄であれば、標準のcontainerdでエージェントのコードが実行されている状態です。gVisorやKataによる追加隔離はかかっていません。

次に確認すべきは、AIエージェントに与えているシェル実行権限の範囲です。フロントエンドのAIコーディングツール（Claude CodeやCursorのエージェントモードなど）を使っている場合、実行許可の設定ファイルやサンドボックスオプションの有無を見ます。

GKEを使っているなら、Google Cloudコンソールでクラスタのバージョンを確認し、Agent Sandbox機能が利用可能なバージョンかどうかをチェックします。オープンソース版を検討する場合はkubernetes-sigs/agent-sandboxのリポジトリでCRDのバージョン（現時点でv1beta1）を確認してください。

対策の手順

ステップ1: 実行環境を分離する

エージェントのコード実行を、開発者のローカル環境やCIのメインジョブから切り離します。専用のコンテナまたはVMを用意し、そこでのみ実行させます。

ステップ2: ネットワークポリシーをdeny-allにする

Agent SandboxのSandboxリソースはデフォルトで全通信を拒否する設計です。自前でサンドボックスを作る場合も、Kubernetesの NetworkPolicy で外部通信を明示的に許可制にします。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress: []

ステップ3: テンプレート化して再利用する

SandboxTemplateの考え方を参考に、実行環境の設定（イメージ、リソース上限、ランタイムクラス）を1か所にまとめます。プラットフォームチームが定義し、開発者は選ぶだけにすることで、設定のばらつきを防げます。

ステップ4: コールドスタートの遅延を測る

SandboxWarmPoolのような事前起動プールを使わない場合、コンテナの起動には画像取得とスケジューリングの時間がかかります。エージェントの応答速度に影響するため、実際の起動時間を計測してから採用を判断します。

ステップ5: 消滅ポリシーを決める

SandboxにはTTL（Time To Live、生存期間）を設定してガベージコレクションさせる運用があります。エージェントの作業単位ごとに使い捨てにするか、状態を保持し続けるかをプロジェクトの要件に合わせて決めます。

導入前に確認すること

Agent Sandboxはまだ新しい仕組みで、GKEのマネージド機能とkubernetes-sigs/agent-sandboxのオープンソース版のどちらを使うかは、既存のインフラ構成次第です。

すぐに導入できない場合でも、まずはAIエージェントの実行権限がどこまで広がっているかを可視化するところから始められます。上記のgrepやkubectlコマンドは今すぐ試せます。

フロントエンド開発でエージェントにビルドやブラウザ操作を任せる機会が増えるほど、実行環境の隔離は後回しにできない課題になっていきます。まずは自分のCIとローカル環境で、エージェントがどこまでの権限を持っているかを確認することから始めてみてください。