「このAIツール、誰が入れたの?」— シャドーAIは雑談ネタで終わらない
「うちの会社、誰が入れたか分からないAIツールがいくつも動いている」。こうした声を聞く機会が増えている。IT部門の許可を得ずに従業員が独自にAIツールを導入する「シャドーAI」は、もはや一部の先進企業だけの悩みではない。
Deloitteの2026年調査によれば、従業員によるAI利用は2025年だけで前年比50%増加した一方、成熟したガバナンスモデルを持つ企業は5社に1社にとどまるという。SaaSアプリの無断導入という話にとどまらず、この問題は開発チームの手元、つまりKubernetesクラスターの中にも確実に広がっている。
本記事では、シャドーAIをSaaS層だけの話に閉じず、Kubernetes運用の現場で実際に起きている「野良デプロイ」問題として捉え直し、Admission Controlによる技術的な対処法を解説する。
クラスターの中で起きている「野良デプロイ」— 誰が何を動かしているか分からない問題
SaaSのシャドーAIには既に多くの警鐘が鳴らされている。だが同じ構図は、Kubernetesクラスターの内部でも起きている。
生成AIの実験に前向きなチームほど、推論エンドポイントやAIエージェント、バッチ処理用のPodを各自の判断で kubectl apply してしまいがちだ。管理者が把握しないまま増殖したPodは、次の3つのリスクを同時に生む。
リソース逼迫
野良Podが GPU やメモリを食いつぶし、正規のワークロードが予期せぬスケジューリング待ちに陥る。
セキュリティホール
急いでデプロイされたPodは securityContext の設定が省略され、特権モードやroot権限で動作しているケースが少なくない。
コスト超過
誰の予算にも計上されていないワークロードが、月次のクラウド費用を静かに押し上げる。
コンテナレジストリやKubernetesのネームスペースをスキャンし、MLフレームワークやモデルアーティファクトの有無を継続的に確認することで、こうした野良ワークロードの存在自体は検知できる。しかし「検知できる」ことと「防げている」ことの間には大きな溝がある。
Kubo のようなマネージドK3s基盤であれば、クラスターの状態をダッシュボードで俯瞰できるため、こうした野良デプロイの兆候にも気づきやすい。だが可視化だけでは、実際にデプロイされる瞬間を止めることはできない。
検知だけでは足りない — Admission Controlという「入り口」で止める発想
シャドーAIワークロードへの対応を「検知」に頼る限り、原理的に後手に回る。ある研究では、シャドーAIワークロードの検知カバレッジを比較したところ、手動レビューでは約40%、CASB（Cloud Access Security Broker）単独では約70%にとどまったのに対し、ビルド時とランタイムの両方で審査するデュアルゲート方式では100%の検知を達成したと報告されている（AIJCST掲載論文）。
Kubernetesの世界でこの「入り口で止める」発想を実現するのが Admission Control だ。Kubernetes公式ドキュメントによれば、Admission ControllerはAPIサーバーへのリクエストを認証・認可の直後、リソースの永続化前にインターセプトするコンポーネントである。作成・更新・削除のリクエストに対してのみ働き、Mutating（内容の変更）とValidating（妥当性の検証）の2段階で処理される。
さらにDynamic Admission Controlを使えば、ValidatingWebhookConfiguration や MutatingWebhookConfiguration によって、どのリソースをどのWebhookの対象にするかを柔軟に設定できる。
KyvernoとOPA Gatekeeper — 2大ポリシーエンジン
実装の代表格が Kyverno と OPA Gatekeeper だ。
Kyvernoは、AIエージェントやそれに付随するMCPサーバー、ゲートウェイコンテナがクラスター内にデプロイされる際、特権モード・root権限・securityContext の欠如・機微なホストディレクトリのマウントを伴うPodを自動的に監査または拒否できる。実際、Kyvernoのポリシーライブラリには「特権コンテナの禁止」ポリシーが用意されており、securityContext.privileged が true に設定されたPodの作成をそのまま拒否する。CNCFのブログでも、Kyvernoが宣言的なPolicy as CodeによってKubernetesガバナンスを柔軟に実現する事例として紹介されている。
一方でOPA Gatekeeperは、ConstraintTemplateというリソースでRegoまたはCELによる違反ロジックを定義し、Constraintオブジェクトとして具体的な制約をクラスターに適用する。Kyvernoの宣言的YAMLに比べると学習コストは高いが、Kubernetes以外のシステムにも同じポリシーエンジンを転用できる拡張性が強みだ。
どちらの方式であっても、野良AIワークロードが「デプロイされてから気づく」のではなく「デプロイされる前に止まる」状態を作れる。これはK3sのような軽量Kubernetesディストリビューションでも変わらず有効な設計原則であり、マネージドK8s環境であってもAdmission Controlの導入自体はチーム側の責任範囲になる。
可視性のないガバナンスはガバナンスではない
Admission Controlは「入り口を塞ぐ」対策であり、それだけでガバナンスが完成するわけではない。実際に医療業界では83%、金融業界では86%、公共部門では91%の担当者が、未承認のAIツール利用を「重大なビジネス・セキュリティリスク」と認識しているという調査結果もある（Nutanixの調査発表）。これほど高い危機感がありながらガバナンスが追いつかないのは、「止める」仕組みはあっても「見える」仕組みが伴っていないからだ。
真に機能するガバナンスには、少なくとも次の3点が必要になる。
- RBAC権限の棚卸し: 誰がどのネームスペースにデプロイできるかを定期的に見直す
- 監査ログの活用: いつ・誰が・何をデプロイしたかを後から追跡できる状態にする
- リソースクォータ: ネームスペース単位でCPU/メモリ/GPUの上限を設け、無制限な増殖を防ぐ
こうした要素を個別のツールでバラバラに管理すると、結局「誰も全体像を把握できない」という最初の問題に逆戻りしてしまう。この点で、Kubo の Captain UI のように、クラスター全体の状態をひとつの画面で可視化できる仕組みは実務上の価値が大きい。EKSやAKSを自前で運用する場合、可視化・監査・ポリシー適用のツールをそれぞれ個別に構築・保守するコストがかかるが、Kubo はK3sベースの本格的なKubernetes機能をそのままに、月額48,000円台からこうした運用基盤を整えられる。
AIワークロードを扱う組織であれば、Captain.AI のようなAIエージェント実行基盤と組み合わせることで、「誰が承認したAIエージェントが、どのクラスターで、どう動いているか」を一気通貫で管理する設計も現実的になる。
まとめ
シャドーAIは、承認を得ずに従業員がSaaSツールを使う問題として語られがちだが、その本質はKubernetesクラスターの中でも変わらない。「誰が・何を・どこにデプロイしたか分からない」というガバナンス不全が根本原因である以上、対策もインフラレベルで講じる必要がある。
- 入り口対策: Admission Control（Kyverno / OPA Gatekeeper）でデプロイ前に止める
- 運用対策: RBAC・監査ログ・リソースクォータで可視性を確保する
- 基盤選び: 可視化と運用のしやすさを両立したマネージドK8s基盤を選ぶ
EKS/AKSの高コスト・複雑さに悩みながら自前でガバナンス基盤まで構築するのは負担が大きい。K3sベースのKuboなら、本格的なKubernetesの機能はそのままに、可視化されたガバナンス運用を圧倒的なコスト効率で実現できる。クラスターの中で何が起きているか把握できていないと感じているなら、お問い合わせから一度相談してみてほしい。