1. AIエージェントの時代、「コンテナ分離だから安全」はもう通用しない
これまでKubernetesクラスタの安全性は、「コンテナに入れて動かすコードは、人間が書いてレビューし、CI/CDを通した信頼できる製品である」という前提の上に成り立っていた。namespaceやcgroupによるコンテナ分離は、その前提のもとでは十分な防御線だった。
ところが、AIエージェントが自律的にツールを呼び出し、コードを生成し、外部から取得したスクリプトをその場で実行する運用が広がるにつれて、この前提は崩れ始めている。エージェントが書くコードは、レビューを経た製品ではなく、実行するまで何をするか完全には予測できない未知のプログラムに近い。
CNCFのブログでも、AIエージェントに実行権限を与えた瞬間、それは単なる効率化ツールではなく「権限を持ち、影響範囲（blast radius）を持つ、新しい非人間アイデンティティ」になると指摘されている（CNCF Blog）。機密データやインフラのコントロールプレーンに、エージェントが生成したコードを直接触れさせない設計思想が必要になっている。
この課題に対する現実的な答えの一つが、Kubernetes上でAIエージェントを動かすためのサンドボックス設計、つまり既存のコンテナ運用に「もう一段厚い壁」を追加するアプローチだ。AIエージェントを本番投入するなら、Kuboのような運用基盤を選ぶ段階から、こうした分離設計を前提に逆算しておく発想が要る。
2. コンテナ分離の限界 — namespaceとcgroupは同じカーネルを共有している
Linuxコンテナは、namespaceでプロセス・ネットワーク・ファイルシステムなどの見える範囲を分離し、cgroupでリソース使用量を制限する仕組みだ。軽量で高速という利点はあるが、すべてのコンテナが同じホストカーネルを共有しているという事実は変わらない。カーネル自体に未知の脆弱性があれば、1つのコンテナからホスト、さらに他のコンテナへ影響が波及する可能性がある。これがコンテナ分離の限界だ。
この限界に対する代表的なアプローチの一つがgVisorだ。gVisorはVMでもseccompのようなシステムコールフィルタでもない、「アプリケーションカーネル」という第三の選択肢としてGoogleが開発した（gVisor公式リポジトリ）。Sentryというユーザースペースのカーネルがシステムコールをすべて横取りし、ホストカーネルに直接届く範囲を絞り込む。公式ドキュメントによれば、VMより軽量なリソース消費と高速な起動を維持しつつコンテナに近い体験を提供できる一方、すべてのシステムコールやファイルシステム機能を実装しているわけではなく、互換性の面でトレードオフが残る（gVisor公式ドキュメント）。
つまり、コンテナ分離の限界を「ユーザースペースでの仲介」でカバーするか、それとも「ハードウェア仮想化」でカバーするかという、2つの方向性が存在する。AIエージェントのように振る舞いを完全に信頼できないワークロードを動かすなら、後者の選択肢が視野に入ってくる。
3. Kubernetesの資産を壊さずにVM分離を足す — Kata Containersという選択
既存のKubernetesワークフローを壊さずにVM分離を足す選択肢として登場するのがKata Containersだ。Kata Containersは、コンテナのような使い勝手を保ちながら、ハードウェア仮想化を「第二の防御層」として追加する、軽量な仮想マシンの標準実装を目指すオープンソースプロジェクトだ（Kata Containers公式リポジトリ）。
Kata Containersの重要な特徴は、既存のコンテナイメージやKubernetesのマニフェストをそのまま使える点にある。Kubernetesには、RuntimeClassというPod単位で使用するコンテナランタイムを切り替えられる仕組みが用意されている（Kubernetes公式ドキュメント）。もともとRuntimeClassは、クラスタ内で複数のランタイムが混在する状況に対応し、「性能」と「セキュリティ」のバランスをPodごとに選べるようにする目的で、2018年のKubernetes 1.12でアルファ機能として導入された（Kubernetes公式ブログ）。
このRuntimeClassをPod仕様に指定するだけで、対象のPodだけがKata Containersのマイクロ VM上で動く。アーキテクチャ的には、containerd/CRI-O互換のshimv2ランタイムがハイパーバイザーを起動し、専用のゲストカーネルを積んだ軽量VMの中でコンテナプロセスを動かす。これにより、たとえゲストカーネルが侵害されても、ワーカーノードや他のPodへ直接波及しない構造になる（Kata Containersアーキテクチャドキュメント）。イメージもワークフローも変えずに、Kubernetes AIエージェント サンドボックスの実行基盤にマイクロVMという壁を1枚追加できる設計だ。
4. それでも残る壁 — 起動時間とコストのオーバーヘッド
マイクロVMによる分離は、コンテナ分離の限界を補う有効な手段だが、無料ではない。ハイパーバイザーの起動とゲストカーネルの立ち上げが挟まる分、通常のコンテナよりも起動に時間がかかり、常時起動しておくコストも増える。AIエージェント向けにKubernetesでサンドボックスを運用し、1つのタスクごとに新しいマイクロVMを起動するなら、このオーバーヘッドは無視できない運用課題になる。
この課題は業界全体でも認識されており、無視するのではなくエンジニアリングで解決すべき対象として扱われている。Google Cloudは、AIエージェント向けにgVisorをベースとしKata Containersにも対応したKubernetesの新しいプリミティブ「Agent Sandbox」を提供し、サンドボックスを事前に温めておく「pre-warmed pool」によってコールドスタートを大幅に短縮し、サブセカンド（1秒未満）のレイテンシを実現したと発表している（Google Cloud公式ブログ）。
一方で、Kubernetes本体のAgent Sandbox APIは、2026年時点でアルファ版から次の開発段階であるv1beta1へ進んでいるものの、まだ仕様が固まりきっていない発展途上の機能だ（Kubernetes Agent Sandbox解説）。本番環境への全面導入は、この先の安定化を見ながら段階的に判断するのが現実的だろう。
Captain.AIのようなAIエージェント実行基盤が組織の一員として安全に働くには、こうしたコールドスタート・コストのトレードオフを前提の上で、K3sベースのKuboが提供する標準的なKubernetes運用基盤の上に構築するのが実務上の現実解になる。
5. まとめ — Kubernetes AIエージェント サンドボックス設計は「分離設計」から逆算する
AIエージェントを組織の一員として本番投入するなら、「コンテナに入れているから安全」という前提から出発するのではなく、「このエージェントのコードは信頼できない」という前提から設計を逆算する必要がある。namespace/cgroupによる軽量分離の限界を理解し、RuntimeClassを使ってKata ContainersのようなマイクロVM分離を必要な箇所だけに足していく。既存のコンテナイメージやKubernetesの運用資産を壊さずに、段階的に防御を厚くできる点が、この設計アプローチの実務上の強みだ。
AIエージェントを本番運用するには、こうした分離設計を前提にした堅牢な基盤が不可欠だ。Kuboは、K3sベースのマネージドKubernetesとして、RuntimeClassをはじめとする標準的なKubernetesの機能をそのまま使える運用基盤を提供している。Captain.AIのようなAIエージェント実行基盤が組織の一員として安全に働くためには、こうした基盤側の分離設計が前提になる。AIエージェント基盤の実行環境設計を検討しているなら、Kuboの上でCaptain.AIを動かす構成について、一度お問い合わせで相談してみてほしい。