# 設定マイニング ## 定義 設定マイニング(configuration mining)は、オンラインの設定リポジトリ群を統計的に解析し、設定が満たすべき「不変条件(invariant)」やチェック規則を自動発見する取り組み。多数の実例に共通して現れる相関(例: 「PHP のアップロードファイルサイズは upload_max_filesize より小さい」)をアソシエーションルールマイニング等で抽出し、設定ミス検知のためのチェックを導出する。対象ソフトウェアを内部不可視の**ブラックボックス**として扱う系統(EnCore [70] 等)と、内部実装と設定を**ホワイトボックス**で同時解析する系統(silent misconfiguration の静的検知 [69] 等)に大別される。([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) [[Zodiac]] はこの系譜を[[Infrastructure as Code|IaC]]へ拡張する。従来の設定マイニングが MySQL 等の「フラットな」属性間相関を対象とし検証を手作業(Stack Overflow・GitHub issue を辿る)で行うのに対し、Zodiac は (1) IaC の階層的・グラフ的構造を表すドメイン固有のチェック仕様言語、(2) 実クラウドへのデプロイによる**自動検証**、(3) inter-resource 制約の発見、で拡張する。マイニングは「セマンティック知識ベース(KB)」+ 84 テンプレートでアソシエーションルールマイニングを走らせ、confidence/lift で統計的フィルタリングし、量的範囲が観測不足のケースは LLM 補間で埋める。([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) ### LLM interpolation 量的特性・範囲・Enum が観測不完全だと不正確なチェックになるため、[[Zodiac]] は LLM(GPT-4)を **interpolation(補間)** に使う。「sf2 sku の VM に許される NIC の最大数は?」のような自然言語クエリを生成し、信頼できるオンライン文書(クラウドの sku 表等)を参照させて具体値を埋める。LLM をチェックの正しさ判定(correctness validation)に直接使うのでなく、**欠落情報の補完**に限定し、最終的な真偽はデプロイ観測で決める——LLM のハルシネーション耐性を確保するための役割限定。([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) ## 横断的知見 - **LLM を「判定器」でなく「補助役」に限定する設計が、設定マイニングと AIOps で独立に現れている**: [[Zodiac]] は LLM を correctness-critical な検証から外し、欠落値の補間に限定して真偽はデプロイ観測に委ねる。これは [[MonitorAssistant]] が LLM を異常検知器そのものでなく「設定推奨・解釈・フィードバック仲介」のメタ層に限定したのと同型の判断であり、いずれも「LLM はハルシネートするので最終判定の責任を負わせない」という制約から来る。検知/検証という correctness が問われる場では LLM を脇に置き、知識補完・対話・解釈に使う、という役割分担が分野を越えて反復している。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]]) - **マイニングだけでは偽陽性が残り、検証(ground truth 化)が要点になる**: 設定マイニングは open-world assumption の下にあり、データに現れない invariant を取り逃がし、データの偏りで誤った規則を生む([[Zodiac]] は稀な `create == 'Attach'` を観測できず誤チェックを生成、最終的に 5.4% が偽陽性)。これは [[障害注入]] ベンチが「注入したが障害化しない silent fault」で汚染されるのと表裏で、**「観測された相関 ≠ 真の規則」をどう篩い分けるか**が両分野の核心。Zodiac はデプロイ観測、注入ベンチは impact-driven validation という、それぞれ実環境での観測で ground truth を作る点が共通する。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **「クラウド挙動の観測から一般化規則を KB へ蓄積する」骨格が同一グループの IaC 3 研究で共通する**: [[Zodiac]] は IaC リポジトリと provider スキーマからセマンティック KB(3 クラスの base facts)を構築する。同じ [[Ang Chen]] グループの [[Lilac]] は「lifting ルールは順方向デプロイの観測から学習できる」を洞察に Cloud Discovery/Mapping/Dependency 規則の KB を育て、[[NSync]] は成功した reconciliation からプロジェクト単位の継続学習 KB を蓄積する。3 者とも**ブラックボックスなクラウドの実挙動(デプロイ・API トレース)を観測し、再利用可能な規則へ一般化して KB に貯める**点で同型——クラウドが opaque で形式モデル化できないからこそ、観測駆動のマイニングが共通解になっている。違いは対象(Zodiac=セマンティックチェック、Lilac=lifting ルール、NSync=drift パターン)と KB の粒度(Zodiac はグローバルな provider KB、NSync は汚染防止のためプロジェクト単位)。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]]) ## 未解決の問い - [[Zodiac]] の検証は実クラウドデプロイで 3 日を要する。デプロイせずに(あるいはシミュレーションで)チェックの真偽を高精度に判定し、検証コストを下げられるか。 - テンプレートは手作業キュレート(約 400 行)。新リソース・新プロバイダのたびにテンプレートを更新する必要があるが、テンプレート自体を自動生成・進化させられるか。 - confidence/lift の統計的フィルタは「ユーザーリポジトリで常に守られている規則」を選ぶため、稀だが真の制約を落としうる。統計的稀少性と真の制約をどう両立して篩うか。 - ブラックボックス設定マイニング(EnCore 系)とホワイトボックス解析([[Tianyin Xu]] らの silent misconfiguration 静的検知)を、IaC のようなグラフ構造設定でどう統合するか。 ## 関連 - ソース: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]] / [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]] / [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]] - 概念: [[Infrastructure as Code]] / [[障害注入]] / [[異常検知]] - エンティティ: [[Zodiac]] / [[Lilac]] / [[NSync]] / [[Terraform]] / [[Ryan Beckett]] / [[Ang Chen]] / [[Tianyin Xu]](EnCore・silent misconfiguration 検知の系譜で被参照) - 関連 MOC: [[Software Engineering - MOC]] / [[AI4SE - MOC]] ## 出典 - [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]](§2.3 Inspiration: Configuration mining, §3 Mining, §3.3 統計的フィルタリングと LLM interpolation, §5.6 False positives, §7 Related work) - [[@2025__AIOps__Automated Lifting for Cloud Infrastructure-as-Code Programs]](§3.3 Knowledge Integration: クラウドクエリ規則の KB) - [[@2025__arXiv__Automated Cloud Infrastructure-as-Code Reconciliation with AI Agents]](Continual Learning: プロジェクト単位の進化する KB) - [[@2024__ESEC-FSE__MonitorAssistant - Simplifying Cloud Service Monitoring via Large Language Models]](LLM をメタ層に限定する設計) - [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]](実観測による ground truth 化と silent fault)