[{"data":1,"prerenderedAt":389},["ShallowReactive",2],{"blog-ja-shadow-ai-kubernetes-admission-control-governance":3,"blog-related-ja-shadow-ai-kubernetes-admission-control-governance":338,"blog-ja-shadow-ai-kubernetes-admission-control-governance-alt":326},{"id":4,"title":5,"author":6,"body":7,"date":320,"description":321,"extension":322,"image":323,"locale":324,"meta":325,"navigation":326,"path":327,"seo":328,"stem":329,"tags":330,"__hash__":337},"blog\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance.md","野良デプロイが会社を壊す。KubernetesクラスターのシャドーAI問題とAdmission Controlという処方箋","Kubo Team",{"type":8,"value":9,"toc":305},"minimark",[10,15,27,30,45,48,52,58,61,69,73,76,79,86,89,92,95,103,107,113,122,135,152,156,165,191,200,203,206,212,221,224,246,257,266,269,272,292],[11,12,14],"h2",{"id":13},"このaiツール誰が入れたの-シャドーaiは雑談ネタで終わらない","「このAIツール、誰が入れたの?」— シャドーAIは雑談ネタで終わらない",[16,17,21],"p",{"className":18,"dir":20},[19],"content-paragraph","ltr",[22,23],"img",{"src":24,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fshadow-ai-kubernetes-admission-control-governance\u002Fsection01.webp","","inherit",[16,28,29],{},"「うちの会社、誰が入れたか分からないAIツールがいくつも動いている」。こうした声を聞く機会が増えている。IT部門の許可を得ずに従業員が独自にAIツールを導入する「シャドーAI」は、もはや一部の先進企業だけの悩みではない。",[16,31,32,39,40,44],{},[33,34,38],"a",{"href":35,"rel":36},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fai-security\u002Fshadow-ai",[37],"nofollow","Deloitteの2026年調査","によれば、従業員によるAI利用は2025年だけで前年比50%増加した一方、成熟したガバナンスモデルを持つ企業は5社に1社にとどまるという。SaaSアプリの無断導入という話にとどまらず、この問題は開発チームの手元、つまり",[41,42,43],"strong",{},"Kubernetesクラスターの中","にも確実に広がっている。",[16,46,47],{},"本記事では、シャドーAIをSaaS層だけの話に閉じず、Kubernetes運用の現場で実際に起きている「野良デプロイ」問題として捉え直し、Admission Controlによる技術的な対処法を解説する。",[11,49,51],{"id":50},"クラスターの中で起きている野良デプロイ-誰が何を動かしているか分からない問題","クラスターの中で起きている「野良デプロイ」— 誰が何を動かしているか分からない問題",[16,53,55],{"className":54,"dir":20},[19],[22,56],{"src":57,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fshadow-ai-kubernetes-admission-control-governance\u002Fsection02.webp",[16,59,60],{},"SaaSのシャドーAIには既に多くの警鐘が鳴らされている。だが同じ構図は、Kubernetesクラスターの内部でも起きている。",[16,62,63,64,68],{},"生成AIの実験に前向きなチームほど、推論エンドポイントやAIエージェント、バッチ処理用のPodを各自の判断で ",[65,66,67],"code",{},"kubectl apply"," してしまいがちだ。管理者が把握しないまま増殖したPodは、次の3つのリスクを同時に生む。",[70,71,72],"h3",{"id":72},"リソース逼迫",[16,74,75],{},"野良Podが GPU やメモリを食いつぶし、正規のワークロードが予期せぬスケジューリング待ちに陥る。",[70,77,78],{"id":78},"セキュリティホール",[16,80,81,82,85],{},"急いでデプロイされたPodは ",[65,83,84],{},"securityContext"," の設定が省略され、特権モードやroot権限で動作しているケースが少なくない。",[70,87,88],{"id":88},"コスト超過",[16,90,91],{},"誰の予算にも計上されていないワークロードが、月次のクラウド費用を静かに押し上げる。",[16,93,94],{},"コンテナレジストリやKubernetesのネームスペースをスキャンし、MLフレームワークやモデルアーティファクトの有無を継続的に確認することで、こうした野良ワークロードの存在自体は検知できる。しかし「検知できる」ことと「防げている」ことの間には大きな溝がある。",[16,96,97,102],{},[33,98,101],{"href":99,"rel":100},"https:\u002F\u002Fkubo.hexabase.io\u002F",[37],"Kubo"," のようなマネージドK3s基盤であれば、クラスターの状態をダッシュボードで俯瞰できるため、こうした野良デプロイの兆候にも気づきやすい。だが可視化だけでは、実際にデプロイされる瞬間を止めることはできない。",[11,104,106],{"id":105},"検知だけでは足りない-admission-controlという入り口で止める発想","検知だけでは足りない — Admission Controlという「入り口」で止める発想",[16,108,110],{"className":109,"dir":20},[19],[22,111],{"src":112,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fshadow-ai-kubernetes-admission-control-governance\u002Fsection03.webp",[16,114,115,116,121],{},"シャドーAIワークロードへの対応を「検知」に頼る限り、原理的に後手に回る。ある研究では、シャドーAIワークロードの検知カバレッジを比較したところ、手動レビューでは約40%、CASB（Cloud Access Security Broker）単独では約70%にとどまったのに対し、ビルド時とランタイムの両方で審査するデュアルゲート方式では100%の検知を達成したと報告されている（",[33,117,120],{"href":118,"rel":119},"https:\u002F\u002Faijcst.org\u002Findex.php\u002Faijcst\u002Farticle\u002Fview\u002F216",[37],"AIJCST掲載論文","）。",[16,123,124,125,128,129,134],{},"Kubernetesの世界でこの「入り口で止める」発想を実現するのが ",[41,126,127],{},"Admission Control"," だ。",[33,130,133],{"href":131,"rel":132},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fadmission-controllers\u002F",[37],"Kubernetes公式ドキュメント","によれば、Admission ControllerはAPIサーバーへのリクエストを認証・認可の直後、リソースの永続化前にインターセプトするコンポーネントである。作成・更新・削除のリクエストに対してのみ働き、Mutating（内容の変更）とValidating（妥当性の検証）の2段階で処理される。",[16,136,137,138,143,144,147,148,151],{},"さらに",[33,139,142],{"href":140,"rel":141},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fextensible-admission-controllers\u002F",[37],"Dynamic Admission Control","を使えば、",[65,145,146],{},"ValidatingWebhookConfiguration"," や ",[65,149,150],{},"MutatingWebhookConfiguration"," によって、どのリソースをどのWebhookの対象にするかを柔軟に設定できる。",[70,153,155],{"id":154},"kyvernoとopa-gatekeeper-2大ポリシーエンジン","KyvernoとOPA Gatekeeper — 2大ポリシーエンジン",[16,157,158,159,164],{},"実装の代表格が ",[33,160,163],{"href":161,"rel":162},"https:\u002F\u002Fkyverno.io\u002Fdocs\u002Fguides\u002Fpod-security\u002F",[37],"Kyverno"," と OPA Gatekeeper だ。",[16,166,167,168,170,171,176,177,180,181,184,185,190],{},"Kyvernoは、AIエージェントやそれに付随するMCPサーバー、ゲートウェイコンテナがクラスター内にデプロイされる際、特権モード・root権限・",[65,169,84],{}," の欠如・機微なホストディレクトリのマウントを伴うPodを自動的に監査または拒否できる。実際、",[33,172,175],{"href":173,"rel":174},"https:\u002F\u002Fkyverno.io\u002Fpolicies\u002Fpod-security\u002Fbaseline\u002Fdisallow-privileged-containers\u002Fdisallow-privileged-containers\u002F",[37],"Kyvernoのポリシーライブラリ","には「特権コンテナの禁止」ポリシーが用意されており、",[65,178,179],{},"securityContext.privileged"," が ",[65,182,183],{},"true"," に設定されたPodの作成をそのまま拒否する。",[33,186,189],{"href":187,"rel":188},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F03\u002F19\u002Fpolicy-as-code-flexible-kubernetes-governance-with-kyverno\u002F",[37],"CNCFのブログ","でも、Kyvernoが宣言的なPolicy as CodeによってKubernetesガバナンスを柔軟に実現する事例として紹介されている。",[16,192,193,194,199],{},"一方でOPA Gatekeeperは、",[33,195,198],{"href":196,"rel":197},"https:\u002F\u002Fopen-policy-agent.github.io\u002Fgatekeeper\u002Fwebsite\u002Fdocs\u002Fconstrainttemplates\u002F",[37],"ConstraintTemplate","というリソースでRegoまたはCELによる違反ロジックを定義し、Constraintオブジェクトとして具体的な制約をクラスターに適用する。Kyvernoの宣言的YAMLに比べると学習コストは高いが、Kubernetes以外のシステムにも同じポリシーエンジンを転用できる拡張性が強みだ。",[16,201,202],{},"どちらの方式であっても、野良AIワークロードが「デプロイされてから気づく」のではなく「デプロイされる前に止まる」状態を作れる。これはK3sのような軽量Kubernetesディストリビューションでも変わらず有効な設計原則であり、マネージドK8s環境であってもAdmission Controlの導入自体はチーム側の責任範囲になる。",[11,204,205],{"id":205},"可視性のないガバナンスはガバナンスではない",[16,207,209],{"className":208,"dir":20},[19],[22,210],{"src":211,"alt":25,"width":26,"height":26},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fshadow-ai-kubernetes-admission-control-governance\u002Fsection04.webp",[16,213,214,215,220],{},"Admission Controlは「入り口を塞ぐ」対策であり、それだけでガバナンスが完成するわけではない。実際に医療業界では83%、金融業界では86%、公共部門では91%の担当者が、未承認のAIツール利用を「重大なビジネス・セキュリティリスク」と認識しているという調査結果もある（",[33,216,219],{"href":217,"rel":218},"https:\u002F\u002Fwww.globenewswire.com\u002Fnews-release\u002F2026\u002F07\u002F15\u002F3327806\u002F0\u002Fen\u002FHealthcare-Financial-Services-and-Public-Sector-Industries-Face-Greatest-Risks-in-Shadow-AI-and-Data-Sovereignty-New-Nutanix-Data-Shows.html",[37],"Nutanixの調査発表","）。これほど高い危機感がありながらガバナンスが追いつかないのは、「止める」仕組みはあっても「見える」仕組みが伴っていないからだ。",[16,222,223],{},"真に機能するガバナンスには、少なくとも次の3点が必要になる。",[225,226,227,234,240],"ul",{},[228,229,230,233],"li",{},[41,231,232],{},"RBAC権限の棚卸し",": 誰がどのネームスペースにデプロイできるかを定期的に見直す",[228,235,236,239],{},[41,237,238],{},"監査ログの活用",": いつ・誰が・何をデプロイしたかを後から追跡できる状態にする",[228,241,242,245],{},[41,243,244],{},"リソースクォータ",": ネームスペース単位でCPU\u002Fメモリ\u002FGPUの上限を設け、無制限な増殖を防ぐ",[16,247,248,249,252,253,256],{},"こうした要素を個別のツールでバラバラに管理すると、結局「誰も全体像を把握できない」という最初の問題に逆戻りしてしまう。この点で、",[33,250,101],{"href":99,"rel":251},[37]," の Captain UI のように、クラスター全体の状態をひとつの画面で可視化できる仕組みは実務上の価値が大きい。EKSやAKSを自前で運用する場合、可視化・監査・ポリシー適用のツールをそれぞれ個別に構築・保守するコストがかかるが、",[33,254,101],{"href":99,"rel":255},[37]," はK3sベースの本格的なKubernetes機能をそのままに、月額48,000円台からこうした運用基盤を整えられる。",[16,258,259,260,265],{},"AIワークロードを扱う組織であれば、",[33,261,264],{"href":262,"rel":263},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[37],"Captain.AI"," のようなAIエージェント実行基盤と組み合わせることで、「誰が承認したAIエージェントが、どのクラスターで、どう動いているか」を一気通貫で管理する設計も現実的になる。",[11,267,268],{"id":268},"まとめ",[16,270,271],{},"シャドーAIは、承認を得ずに従業員がSaaSツールを使う問題として語られがちだが、その本質はKubernetesクラスターの中でも変わらない。「誰が・何を・どこにデプロイしたか分からない」というガバナンス不全が根本原因である以上、対策もインフラレベルで講じる必要がある。",[225,273,274,280,286],{},[228,275,276,279],{},[41,277,278],{},"入り口対策",": Admission Control（Kyverno \u002F OPA Gatekeeper）でデプロイ前に止める",[228,281,282,285],{},[41,283,284],{},"運用対策",": RBAC・監査ログ・リソースクォータで可視性を確保する",[228,287,288,291],{},[41,289,290],{},"基盤選び",": 可視化と運用のしやすさを両立したマネージドK8s基盤を選ぶ",[16,293,294,295,298,299,304],{},"EKS\u002FAKSの高コスト・複雑さに悩みながら自前でガバナンス基盤まで構築するのは負担が大きい。K3sベースの",[33,296,101],{"href":99,"rel":297},[37],"なら、本格的なKubernetesの機能はそのままに、可視化されたガバナンス運用を圧倒的なコスト効率で実現できる。クラスターの中で何が起きているか把握できていないと感じているなら、",[33,300,303],{"href":301,"rel":302},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[37],"お問い合わせ","から一度相談してみてほしい。",{"title":25,"searchDepth":306,"depth":306,"links":307},2,[308,309,315,318,319],{"id":13,"depth":306,"text":14},{"id":50,"depth":306,"text":51,"children":310},[311,313,314],{"id":72,"depth":312,"text":72},3,{"id":78,"depth":312,"text":78},{"id":88,"depth":312,"text":88},{"id":105,"depth":306,"text":106,"children":316},[317],{"id":154,"depth":312,"text":155},{"id":205,"depth":306,"text":205},{"id":268,"depth":306,"text":268},"2026-07-17","SaaSの無断導入だけがシャドーAIではない。Kubernetesクラスター内で誰が何をデプロイしているか分からない状態が生むリスクと、Admission Controlによるガバナンス実装を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fshadow-ai-kubernetes-admission-control-governance\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance",{"title":5,"description":321},"blog\u002Fja\u002Fshadow-ai-kubernetes-admission-control-governance",[331,332,333,334,335,336],"kubernetes","k3s","shadow-ai","admission-control","kyverno","security","0tZ3UPWyE0Kp3zfBqNlvch2VPX-_sMnbi9WdRx1SdEc",[339,347,355,363,372,381],{"path":340,"title":341,"description":342,"date":343,"tags":344},"\u002Fblog\u002Fja\u002Fkubernetes-certificate-management-cert-manager-process-debt","証明書の更新、1行のコードより2ヶ月の会議が長かった。Kubernetesの証明書管理が『技術』ではなく『手続き』の問題である理由","Kubernetesの証明書管理は技術的には数日で終わる。だが実際に時間がかかるのは合意形成という『手続き』だ。cert-managerによる自動化と、組織的負債をなくす設計を解説する。","2026-08-09",[332,331,345,346,336],"cert-manager","tls",{"path":348,"title":349,"description":350,"date":351,"tags":352},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[332,331,353,354,336],"kata-containers","ai-agent",{"path":356,"title":357,"description":358,"date":359,"tags":360},"\u002Fblog\u002Fja\u002Fkubernetes-image-signing-sigstore-supply-chain","イメージタグは誰でも書き換えられる。Kubernetesのイメージ署名にSigstoreで『来歴』を刻むという発想","コンテナイメージ署名の仕組みを解説。イメージタグは誰でも書き換え可能で、CI\u002FCDのテストを通過した保証にはならない。SigstoreとKyvernoを組み合わせ、Kubernetes\u002FK3s上で未署名イメージの起動を拒否する防御層を構築する方法を、GitOps運用との統合も含めて紹介する。","2026-08-06",[332,331,361,362,336],"ci-cd","gitops",{"path":364,"title":365,"description":366,"date":367,"tags":368},"\u002Fblog\u002Fja\u002Fkubernetes-secrets-rbac-etcd-encryption","Base64を見て安心するな。KubernetesのSecretsが「素通し」される理由とRBAC設計の落とし穴","KubernetesのSecretsはBase64エンコードされているだけで、暗号化されていない。etcdへの平文相当保存とRBACの過剰権限が引き起こす事故と、K3s本番運用で実践すべきSecrets管理の対策を解説する。","2026-07-29",[331,332,369,370,336,371],"secrets-management","rbac","etcd-encryption",{"path":373,"title":374,"description":375,"date":376,"tags":377},"\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",[332,331,378,379,380,336],"kubernetes-v136","managed-kubernetes","cost-optimization",{"path":382,"title":383,"description":384,"date":385,"tags":386},"\u002Fblog\u002Fja\u002Fkubevirt-calico-live-migration-networking","VMを動かしても通信は切れない。KubeVirtとCalicoが実現するKubernetesライブマイグレーションの舞台裏","KubernetesでVM（KubeVirt）をノード間へライブマイグレーションしても、なぜ通信が切れないのか。CalicoのIP永続化・BGPルート収束の仕組みと、VMware移行先としての実務的な意味を解説する。","2026-08-07",[332,331,387,388,379],"kubevirt","networking",1786354652393]