[{"data":1,"prerenderedAt":266},["ShallowReactive",2],{"blog-ja-ai-agent-sandbox-kata-containers-kubernetes":3,"blog-related-ja-ai-agent-sandbox-kata-containers-kubernetes":213,"blog-ja-ai-agent-sandbox-kata-containers-kubernetes-alt":202},{"id":4,"title":5,"author":6,"body":7,"date":196,"description":197,"extension":198,"image":199,"locale":200,"meta":201,"navigation":202,"path":203,"seo":204,"stem":205,"tags":206,"__hash__":212},"blog\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes.md","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","Kubo Team",{"type":8,"value":9,"toc":187},"minimark",[10,15,23,26,29,40,49,53,59,62,77,80,84,90,98,112,121,125,131,134,142,151,163,167,170],[11,12,14],"h2",{"id":13},"_1-aiエージェントの時代コンテナ分離だから安全はもう通用しない","1. AIエージェントの時代、「コンテナ分離だから安全」はもう通用しない",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-sandbox-kata-containers-kubernetes\u002Fsection01.webp",[16,24,25],{},"これまでKubernetesクラスタの安全性は、「コンテナに入れて動かすコードは、人間が書いてレビューし、CI\u002FCDを通した信頼できる製品である」という前提の上に成り立っていた。namespaceやcgroupによるコンテナ分離は、その前提のもとでは十分な防御線だった。",[16,27,28],{},"ところが、AIエージェントが自律的にツールを呼び出し、コードを生成し、外部から取得したスクリプトをその場で実行する運用が広がるにつれて、この前提は崩れ始めている。エージェントが書くコードは、レビューを経た製品ではなく、実行するまで何をするか完全には予測できない未知のプログラムに近い。",[16,30,31,32,39],{},"CNCFのブログでも、AIエージェントに実行権限を与えた瞬間、それは単なる効率化ツールではなく「権限を持ち、影響範囲（blast radius）を持つ、新しい非人間アイデンティティ」になると指摘されている（",[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F08\u002F07\u002Fshadow-ai-in-ci-cd-threat-modeling-the-path-from-developer-laptop-to-kubernetes\u002F",[37],"nofollow","CNCF Blog","）。機密データやインフラのコントロールプレーンに、エージェントが生成したコードを直接触れさせない設計思想が必要になっている。",[16,41,42,43,48],{},"この課題に対する現実的な答えの一つが、Kubernetes上でAIエージェントを動かすためのサンドボックス設計、つまり既存のコンテナ運用に「もう一段厚い壁」を追加するアプローチだ。AIエージェントを本番投入するなら、",[33,44,47],{"href":45,"rel":46},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"Kubo","のような運用基盤を選ぶ段階から、こうした分離設計を前提に逆算しておく発想が要る。",[11,50,52],{"id":51},"_2-コンテナ分離の限界-namespaceとcgroupは同じカーネルを共有している","2. コンテナ分離の限界 — namespaceとcgroupは同じカーネルを共有している",[16,54,55],{},[19,56],{"alt":57,"src":58},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-sandbox-kata-containers-kubernetes\u002Fsection02.webp",[16,60,61],{},"Linuxコンテナは、namespaceでプロセス・ネットワーク・ファイルシステムなどの見える範囲を分離し、cgroupでリソース使用量を制限する仕組みだ。軽量で高速という利点はあるが、すべてのコンテナが同じホストカーネルを共有しているという事実は変わらない。カーネル自体に未知の脆弱性があれば、1つのコンテナからホスト、さらに他のコンテナへ影響が波及する可能性がある。これがコンテナ分離の限界だ。",[16,63,64,65,70,71,76],{},"この限界に対する代表的なアプローチの一つがgVisorだ。gVisorはVMでもseccompのようなシステムコールフィルタでもない、「アプリケーションカーネル」という第三の選択肢としてGoogleが開発した（",[33,66,69],{"href":67,"rel":68},"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fgvisor",[37],"gVisor公式リポジトリ","）。Sentryというユーザースペースのカーネルがシステムコールをすべて横取りし、ホストカーネルに直接届く範囲を絞り込む。公式ドキュメントによれば、VMより軽量なリソース消費と高速な起動を維持しつつコンテナに近い体験を提供できる一方、すべてのシステムコールやファイルシステム機能を実装しているわけではなく、互換性の面でトレードオフが残る（",[33,72,75],{"href":73,"rel":74},"https:\u002F\u002Fgvisor.dev\u002Fdocs\u002F",[37],"gVisor公式ドキュメント","）。",[16,78,79],{},"つまり、コンテナ分離の限界を「ユーザースペースでの仲介」でカバーするか、それとも「ハードウェア仮想化」でカバーするかという、2つの方向性が存在する。AIエージェントのように振る舞いを完全に信頼できないワークロードを動かすなら、後者の選択肢が視野に入ってくる。",[11,81,83],{"id":82},"_3-kubernetesの資産を壊さずにvm分離を足す-kata-containersという選択","3. Kubernetesの資産を壊さずにVM分離を足す — Kata Containersという選択",[16,85,86],{},[19,87],{"alt":88,"src":89},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-sandbox-kata-containers-kubernetes\u002Fsection03.webp",[16,91,92,93,76],{},"既存のKubernetesワークフローを壊さずにVM分離を足す選択肢として登場するのがKata Containersだ。Kata Containersは、コンテナのような使い勝手を保ちながら、ハードウェア仮想化を「第二の防御層」として追加する、軽量な仮想マシンの標準実装を目指すオープンソースプロジェクトだ（",[33,94,97],{"href":95,"rel":96},"https:\u002F\u002Fgithub.com\u002Fkata-containers\u002Fkata-containers",[37],"Kata Containers公式リポジトリ",[16,99,100,101,106,107,76],{},"Kata Containersの重要な特徴は、既存のコンテナイメージやKubernetesのマニフェストをそのまま使える点にある。Kubernetesには、RuntimeClassというPod単位で使用するコンテナランタイムを切り替えられる仕組みが用意されている（",[33,102,105],{"href":103,"rel":104},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fcontainers\u002Fruntime-class\u002F",[37],"Kubernetes公式ドキュメント","）。もともとRuntimeClassは、クラスタ内で複数のランタイムが混在する状況に対応し、「性能」と「セキュリティ」のバランスをPodごとに選べるようにする目的で、2018年のKubernetes 1.12でアルファ機能として導入された（",[33,108,111],{"href":109,"rel":110},"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F2018\u002F10\u002F10\u002Fkubernetes-v1.12-introducing-runtimeclass\u002F",[37],"Kubernetes公式ブログ",[16,113,114,115,120],{},"このRuntimeClassをPod仕様に指定するだけで、対象のPodだけがKata Containersのマイクロ VM上で動く。アーキテクチャ的には、containerd\u002FCRI-O互換のshimv2ランタイムがハイパーバイザーを起動し、専用のゲストカーネルを積んだ軽量VMの中でコンテナプロセスを動かす。これにより、たとえゲストカーネルが侵害されても、ワーカーノードや他のPodへ直接波及しない構造になる（",[33,116,119],{"href":117,"rel":118},"https:\u002F\u002Fkata-containers.github.io\u002Fkata-containers\u002Fdesign\u002Farchitecture\u002F",[37],"Kata Containersアーキテクチャドキュメント","）。イメージもワークフローも変えずに、Kubernetes AIエージェント サンドボックスの実行基盤にマイクロVMという壁を1枚追加できる設計だ。",[11,122,124],{"id":123},"_4-それでも残る壁-起動時間とコストのオーバーヘッド","4. それでも残る壁 — 起動時間とコストのオーバーヘッド",[16,126,127],{},[19,128],{"alt":129,"src":130},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-sandbox-kata-containers-kubernetes\u002Fsection04.webp",[16,132,133],{},"マイクロVMによる分離は、コンテナ分離の限界を補う有効な手段だが、無料ではない。ハイパーバイザーの起動とゲストカーネルの立ち上げが挟まる分、通常のコンテナよりも起動に時間がかかり、常時起動しておくコストも増える。AIエージェント向けにKubernetesでサンドボックスを運用し、1つのタスクごとに新しいマイクロVMを起動するなら、このオーバーヘッドは無視できない運用課題になる。",[16,135,136,137,76],{},"この課題は業界全体でも認識されており、無視するのではなくエンジニアリングで解決すべき対象として扱われている。Google Cloudは、AIエージェント向けにgVisorをベースとしKata Containersにも対応したKubernetesの新しいプリミティブ「Agent Sandbox」を提供し、サンドボックスを事前に温めておく「pre-warmed pool」によってコールドスタートを大幅に短縮し、サブセカンド（1秒未満）のレイテンシを実現したと発表している（",[33,138,141],{"href":139,"rel":140},"https:\u002F\u002Fcloud.google.com\u002Fblog\u002Fproducts\u002Fcontainers-kubernetes\u002Fagentic-ai-on-kubernetes-and-gke\u002F",[37],"Google Cloud公式ブログ",[16,143,144,145,150],{},"一方で、Kubernetes本体のAgent Sandbox APIは、2026年時点でアルファ版から次の開発段階であるv1beta1へ進んでいるものの、まだ仕様が固まりきっていない発展途上の機能だ（",[33,146,149],{"href":147,"rel":148},"https:\u002F\u002Fsreake.com\u002Fblog\u002Fkubernetes-agent-sandbox-explained\u002F",[37],"Kubernetes Agent Sandbox解説","）。本番環境への全面導入は、この先の安定化を見ながら段階的に判断するのが現実的だろう。",[16,152,153,158,159,162],{},[33,154,157],{"href":155,"rel":156},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[37],"Captain.AI","のようなAIエージェント実行基盤が組織の一員として安全に働くには、こうしたコールドスタート・コストのトレードオフを前提の上で、K3sベースの",[33,160,47],{"href":45,"rel":161},[37],"が提供する標準的なKubernetes運用基盤の上に構築するのが実務上の現実解になる。",[11,164,166],{"id":165},"_5-まとめ-kubernetes-aiエージェント-サンドボックス設計は分離設計から逆算する","5. まとめ — Kubernetes AIエージェント サンドボックス設計は「分離設計」から逆算する",[16,168,169],{},"AIエージェントを組織の一員として本番投入するなら、「コンテナに入れているから安全」という前提から出発するのではなく、「このエージェントのコードは信頼できない」という前提から設計を逆算する必要がある。namespace\u002Fcgroupによる軽量分離の限界を理解し、RuntimeClassを使ってKata ContainersのようなマイクロVM分離を必要な箇所だけに足していく。既存のコンテナイメージやKubernetesの運用資産を壊さずに、段階的に防御を厚くできる点が、この設計アプローチの実務上の強みだ。",[16,171,172,173,176,177,180,181,186],{},"AIエージェントを本番運用するには、こうした分離設計を前提にした堅牢な基盤が不可欠だ。",[33,174,47],{"href":45,"rel":175},[37],"は、K3sベースのマネージドKubernetesとして、RuntimeClassをはじめとする標準的なKubernetesの機能をそのまま使える運用基盤を提供している。",[33,178,157],{"href":155,"rel":179},[37],"のようなAIエージェント実行基盤が組織の一員として安全に働くためには、こうした基盤側の分離設計が前提になる。AIエージェント基盤の実行環境設計を検討しているなら、Kuboの上でCaptain.AIを動かす構成について、一度",[33,182,185],{"href":183,"rel":184},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[37],"お問い合わせ","で相談してみてほしい。",{"title":188,"searchDepth":189,"depth":189,"links":190},"",2,[191,192,193,194,195],{"id":13,"depth":189,"text":14},{"id":51,"depth":189,"text":52},{"id":82,"depth":189,"text":83},{"id":123,"depth":189,"text":124},{"id":165,"depth":189,"text":166},"2026-08-08","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-sandbox-kata-containers-kubernetes\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes",{"title":5,"description":197},"blog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes",[207,208,209,210,211],"k3s","kubernetes","kata-containers","ai-agent","security","o8Ccprb10V_AOsdz039tPHsiRhB9lgcH86vpTxgt9no",[214,223,231,239,248,257],{"path":215,"title":216,"description":217,"date":218,"tags":219},"\u002Fblog\u002Fja\u002Fai-agent-authentication-kubernetes-keycloak-spiffe","AIエージェントに鍵を持たせるな。KubernetesでMCPサーバーを『キーレス』に認証する設計","AIエージェントに静的なAPIキーを持たせる運用は、いずれ破綻する。KubernetesでMCPサーバーを運用する現場で起きている静的シークレット問題の構造的な限界と、KeycloakとSPIFFE\u002FSPIREを組み合わせて鍵を配らずに認証する『キーレス』設計思想を解説する。","2026-08-18",[207,208,210,220,221,222],"mcp","keycloak","zero-trust",{"path":224,"title":225,"description":226,"date":227,"tags":228},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[207,208,229,230,211],"cert-manager","tls",{"path":232,"title":233,"description":234,"date":235,"tags":236},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[207,208,237,238,211],"ci-cd","gitops",{"path":240,"title":241,"description":242,"date":243,"tags":244},"\u002Fblog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64を見て安心するな。KubernetesのSecretsが「素通し」される理由とRBAC設計の落とし穴","KubernetesのSecretsはBase64エンコードされているだけで、暗号化されていない。etcdへの平文相当保存とRBACの過剰権限が引き起こす事故と、K3s本番運用で実践すべきSecrets管理の対策を解説する。","2026-07-29",[208,207,245,246,211,247],"secrets-management","rbac","etcd-encryption",{"path":249,"title":250,"description":251,"date":252,"tags":253},"\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance","野良デプロイが会社を壊す。KubernetesクラスターのシャドーAI問題とAdmission Controlという処方箋","SaaSの無断導入だけがシャドーAIではない。Kubernetesクラスター内で誰が何をデプロイしているか分からない状態が生むリスクと、Admission Controlによるガバナンス実装を解説する。","2026-07-17",[208,207,254,255,256,211],"shadow-ai","admission-control","kyverno",{"path":258,"title":259,"description":260,"date":261,"tags":262},"\u002Fblog\u002Fja\u002Fkubernetes-v136-k3s-managed-cost-reduction","マネージドKubernetesはもう高すぎる。K3s軽量化とv1.36セキュリティ強化で実現する『月額4万円台フルK8s運用』の現実味","Kubernetes v1.36「Haru」で強化されたUser Namespaces、セキュリティ機能をK3s軽量環境で活用する方法を解説。EKSより60%コスト削減を実現するマネージドK3s運用戦略と2026年のインフラ選定指針。","2026-05-28",[207,208,263,264,265,211],"kubernetes-v136","managed-kubernetes","cost-optimization",1787649510100]