Google、Kubernetesで動く“野良AI”を棚卸しするOSS「k8s-aibom」公開：アプリ変更なしで利用可能、構成要素の目録を自動生成

Googleは、「Kubernetes」で稼働するAIシステムの構成要素を自動検出する「k8s-aibom」をオープンソースで公開した。特権を必要とせず、開発者側の設定変更も不要だという。

[＠IT]

　Googleは2026年7月13日（米国時間）、コンテナオーケストレーションツール「Kubernetes」クラスタで稼働するAIワークロードを自動検出し、その構成要素を可視化するOSS（オープンソースソフトウェア）の「k8s-aibom」を公開した。

　AIBOM（AI部品表）とは、従来のSBOM（ソフトウェア部品表）をAI領域に拡張し、使用しているモデルやデータセット、フレームワークなどの構成を可視化する概念だ。k8s-aibomはクラスタ内を自動スキャンし、AIBOMに当たる構成情報を、業界標準フォーマット「CycloneDX 1.6」に基づく「ML-BOM」（機械学習部品表）形式のドキュメントとして生成する。

　正式な登録を経ずに開発者が展開したAIワークロードは、従来のセキュリティスキャナーでは捕捉しきれない。かといって、Kubernetesの特権付きDaemonSetやカーネルレベルのアクセス、Pod定義の手作業での書き換えを求めれば、開発速度や安定性を損なう。

　k8s-aibomは、このトレードオフを解消するために開発された。開発側の手を止めずに実行時の可視性を自動確保できるため、ガバナンスを保ちながらAIプロジェクトの試験導入から本番移行までのスピードを速められるという。

「知らなかった」では済まされない時代　現場を止めずにAI利用を可視化する一手

　k8s-aibomは、k8s-aibom-systemネームスペースに特権を持たない単一のDeploymentとして展開する。サイドカーコンテナやeBPF（Extended Berkeley Packet Filter）のカーネルモジュール、特権付きDaemonSetは使わず、既存のPod定義にも手を加えない。包括的な可視性を求めるCISO（最高情報セキュリティ責任者）の要求と、クラスタの安定性を守るSRE（Site Reliability Engineer）の要求を両立させるという。

k8s-aibomがAIワークロードを監視して部品表を生成する仕組み（提供：Google）

　検出は以下の4段階で進む。

1. クラスタ内のワークロード収集：KServeのリソースやDeployment、StatefulSet、DaemonSet、Jobを継続的に監視する
2. AIスタックの特定：コンテナイメージや環境変数、コマンドライン引数を検査し、稼働中のAIを見分ける
3. 標準形式での生成：検出した要素をCycloneDX 1.6形式のML-BOMとして生成する
4. 出力先への書き出し：AIBOMカスタムリソースのstatus.bomDocumentにML-BOMを添付し、「Cloud Storage」のバケットや外部のWebhookにも送る

　Googleによると、検出可能な対象は多岐にわたるという。

• 推論ランタイム：「vLLM」「NVIDIA Triton Inference Server」「Text Generation Inference（TGI）」「Ollama」
• AIエージェント基盤：「LangChain」「AutoGen」「CrewAI」
• ベクトルデータベース／RAG（検索拡張生成）ストア：「Milvus」「Qdrant」「pgvector」

　この他、分散学習ジョブや評価用ハーネスの検出にも対応する。

　Googleは、k8s-aibomの特徴として「再現性」と「決定性」を挙げる。クラスタ内の構成が全く同じなら、生成されるML-BOM（部品表データ）もバイト単位で100％完全に一致する。ランダム性や余計なノイズが入らないため、GitOpsなどの自動運用フローに組み込みやすいという。

　「構成管理ツール上で厳密な差分（Diff）を比較できるため、AIモデルやライブラリに意図しない変更（不正な書き換えや予期せぬ更新）が生じた際、即座にアラートを発報する高度な改ざん検知プロセスを構築可能だ」（Google）

検出結果を3段階に分け、人の意図と機械の推測を切り分ける

　k8s-aibomは、検出したAI資産を次の3段階に分類する。

• 「Declared」（宣言済み）：開発者や管理者がKubernetesのマニフェスト構成において明示的に定義した資産を指す。コンテナの起動引数に直接指定された「--model meta-llama/Llama-2-7b」などもこれに該当し、人間による明確な管理意思と設計意図を証明する
• 「Inferred」（推測）：マニフェストなどに直接の記述はないものの、コンテナイメージのレイヤー構造、環境変数、プロセスの実行プロファイルをコントローラーのエンジンが深くスキャンし、パターンマッチングから自律的に導き出した資産を指す。「vllm/.*」といったコンテナの固有シグネチャからAIの稼働を検出するケースが該当し、開発者が無自覚・無許可で実行している「シャドーAI」を洗い出す
• 「Unresolved」（未解決）：クラスタ内でAIワークロードが活動しているシグナル自体はあるものの、モデルパラメーター、ウェイト、バージョンなどを決定論的に特定できないグレーな資産を指す。即座に警告が出され、セキュリティチームによる個別・重点的なリスク検証レビューの対象となる

ビルド時スキャンとの違いは「今動いているもの」を見る点

　既存のAIBOM関連ツールの多くは、「静止状態の成果物からBOMを作るビルド時スキャナーだ」と、Googleは指摘する。これらが追跡できるのは「展開するつもりだったコード」であり、今この瞬間に何が動いていて何につながっているのかは分からない。

　k8s-aibomが出力するのは、ベンダー独自の形式ではなくOWASP（Open Worldwide Application Security Project）やOpenSSF（Open Source Security Foundation）の枠組みと連携できるCycloneDX 1.6準拠のML-BOMだ。既存のビルド時スキャンや態勢管理ツールを置き換えるものではなく、補完するものだとしている。

最小権限と書き換え不能な保存で監査証跡を担保

　万が一クラスタ内のノードが攻撃者に乗っ取られた場合や、インサイダー（内部特権ユーザー）が攻撃に関与した場合、監視ログは後から削除・改ざんされる恐れがある。k8s-aibomは「最小権限の分離」と「データの不変性」をアーキテクチャの根幹に据えることで、監査基準を満たす極めて強固な証跡トレースを実現する。

　コントローラーは専用のKubernetesサービスアカウントで動作し、最小限の権限のみが付与されたIAM（IDおよびアクセス管理）の「Workload Identity」にひも付く。外部ストレージへBOMレコードを書き込める唯一のIDとして機能し、権限はレコードの新規作成のみを許可する「roles/storage.objectCreator」のみに制限されている。

　Google Cloud Storage（GCS）など外部にエクスポートをする際は、APIレベルでオブジェクトが実在しないことを示す前提条件を厳格に適用する。これらにより、一度ストレージバケットに書き込まれたML-BOMドキュメントは、イミュータブルオブジェクトとして固定され、後から特権管理者や乗っ取られたノードが過去の監査ログを書き換えられない仕組みだ。

EU AI法など規制・フレームワーク対応の監査証拠を自動生成

　AIシステムの運用においては、今や企業には法的義務や国際標準に基づく高度なガバナンスが厳しく求められている。とりわけ、AIシステムを構成するコンポーネントの可視化と継続的な追跡可能性（トレーサビリティー）の確保は急務だ。

　「EU AI法」（EU AI Act）では、第12条で「継続的な追跡可能性のための自動ログ記録」を、第50条で「特定AIシステムにおける透明性義務」の順守をそれぞれ規定している。

　NIST（米国国立標準技術研究所）の「AIリスクマネジメントフレームワーク」（AI RMF）でも、「統治（Govern）」「マッピング（Map）」など各機能で、詳細な構成情報の把握を求める。「ISO/IEC 42001」（AIマネジメントシステム）も同様に、AI資産の正確な発見とライフサイクル全体の追跡を要求する。

　従来、こうした適合性監査に必要な技術的証拠の収集や目録の作成は、運用担当者が表計算ソフトウェアを用いて手作業で進めるケースが多く、作業負担の増大や管理漏れが課題となっていた。

　Googleは「CycloneDX 1.6準拠のML-BOMを自動生成することで、Kubernetesの実行時の状態と、こうした上位のガバナンスの枠組みをつなぐものだ」と説明する。

　k8s-aibomはGitHubのリポジトリで公開されており、コントローラーの実装やCRD（カスタムリソース定義）の詳細を確認できる。