> [!abstract] 概要(abstract 和訳) > ネットワークシステムに障害が発生した際、オブザーバビリティデータを用いた根本原因分析(RCA)の自動実行はネットワークシステムの信頼性確保に不可欠である。近年、LLM ベースのエージェントが高度な推論と自律的な探索によりこの診断プロセスを自動化する有望な手段として注目されている。しかし、既存のオブザーバビリティフレームワークは依然として旧態依然であり、断片化したデータサイロ・互換性のないスキーマ・不十分なセマンティクスメタデータを特徴とし、エージェントが効果的な RCA に必要な複雑な関係を構築することを妨げている。これらの課題に対処するため、我々はオブザーバビリティをデータ中心からオブジェクト中心のモデリングへと転換する統一オントロジーフレームワーク UModel を提案する。UModel は、異種テレメトリ・エンティティ・エキスパート知識をオブジェクトとして標準化しセマンティクスグラフで相互接続する仮想オントロジーレイヤーを構築する。さらに、エージェントがシステムトポロジーを自律的に探索しマルチモーダルデータを相関させることを可能にするパイプラインベースのクエリインターフェース U-SPL を導入する。UModel を用いて「AIOps 2025 Challenge」データセットを再モデリングすることで、根本原因局所化の精度が 8% 向上し、データ組織化の改善が下流タスクの精度を大幅に向上させることを実証した。UModel は、Alibaba Cloud に 1 年以上にわたり展開され、数万ユーザーにサービスを提供し、毎秒数百万回の操作を維持し、サブ秒のクエリレイテンシを実現したスケーラブルなモデリングフレームワークを提供する。 ## 論文情報 - **タイトル**: UModel: An Agent-Ready Observability Data Modeling Method at Scale - **著者**: [[Changhua Pei]], Zheyuan Li, Zexin Wang, Hang Cui, Xiaohui Nie, Qi Zhou, Fang Situ, Cheng Zhang, Xin Zhang, Xidao Wen, [[Gaogang Xie]], Jingjing Li, [[Dan Pei]] - **所属**: CNIC CAS・Hangzhou Institute for Advanced Study UCAS / UCAS / Alibaba / Tsinghua University - **arXiv**: arXiv:2606.04799v1 [cs.SE]、2026-06-03 投稿 - **インデックス用語**: AIOps, Observability, Root Cause Analysis, Agent Ready ## 概要 既存のオブザーバビリティスタックは「死んだデータ」（セマンティクスなしの文字列・数値）・「孤立したイベント」（トポロジー関係なし）・「ツール欠如」（読み取り専用ダッシュボード）・「サイロ」（Prometheus・ELK・Jaeger が互換スキーマなしに並存）という 4 つのギャップを持ち、LLM エージェントが自律的に RCA を実行するうえでボトルネックとなっている。UModel はこれを解決する統一オントロジーフレームワークであり、U-SPL は LLM エージェントがそのモデルを単一クエリ言語で探索するインターフェースである。 ## 問題設定 - **入力**: 既存のヘテロジニアスなオブザーバビリティデータ（メトリクス、ログ、トレース、イベント）と、Prometheus / Elasticsearch などの異種ストレージバックエンド - **出力**: エージェントが推論と RCA に利用できるセマンティクス豊富なオブジェクト中心ナレッジグラフと、統一クエリインターフェース - **前提**: エージェントは ReAct パラダイムで動作し、ツール呼び出しでデータを取得する。PromQL や SQL の方言を事前学習しない ## 提案手法 ### アーキテクチャ UModel のアーキテクチャは **3 層**（オブジェクト層・クエリ層・アプリケーション層）で構成される（Figure 1）。 **オブジェクト層（Object Layer）** は UModel の核心であり、すべての運用リソースを以下 6 概念で表現する（Table I）： | 概念 | 機能 | 主要スキーマ | |---|---|---| | EntitySet | ビジネスオブジェクトの構造と属性を定義（テンプレート） | metadata.name, spec.fields, spec.primary_key_fields | | DataSet | テレメトリデータのスキーマを定義（メトリクス・ログ・トレース・イベント） | Metric: metrics/labels, Log: fields/message_field, Trace: trace_id_field | | EntitySetLink | エンティティ間のトポロジー関係を定義 | left_entity_set, right_entity_set, link_type | | DataLink | DataSet をエンティティへフィールドマッピングで論理結合 | src(Entity), dest(DataSet) | | Storage | 物理ストレージ層（Prometheus・Elasticsearch 等） | — | | StorageLink | DataSet と Storage の物理ルーティング | — | EntitySet と EntitySetLink がトポロジースケルトンを形成し、DataSet が標準スキーマを提供し、Storage が物理層を担い、DataLink・StorageLink がコネクタとして機能する。この分離により、エージェントはストレージ実装を意識せずセマンティクス豊富なエンティティとして推論できる（Figure 2）。 ### Unified Search Processing Language（U-SPL） U-SPL は Unix パイプ発想のパイプライン型クエリ言語で、`Source → | Command₁ → | Command₂ → ...` の構造を持つ（式 1）。3 コンポーネント（Table II）： - **USearch**: エンティティインスタンスへのクエリ（特定のサービスや Pod のメトリクス取得）。マルチキーワード検索（OR 結合）・フィルタリング（属性条件・fuzzy matching）・IDF ベースのマルチフィールド関連性スコアリング・ランキングを提供。生のマルチモーダルデータを構造化・情報豊富な表現に変換することでエージェント可読性を高める。 - **GSearch**: エンティティ間関係のトポロジークエリ。2 サブコンポーネント：(1) **graph-match**：パス表現に基づくグラフ横断クエリ（Cypher 不使用・開始ノードとラベル必須・サイクル不可）、(2) **graph-call**：グラフアルゴリズムや Cypher 文を直接実行するインターフェース（getNeighborNodes・getDirectRelations 等の組み込み関数も利用可） - **MetaSearch**: EntitySet の定義・スキーマ情報のクエリ（主にエージェントの初期コンテキスト取得に使用） Figure 3 は U-SPL と従来 PromQL を比較し、「golden metrics for domain ad」の取得タスクで U-SPL が 2 行で完結するのに対し、PromQL ベースでは手動ラベルマッピング・逆変換・クロスシステム操作が必要なことを示す（Table VII でも 3 タスクで UModel SPL の優位を定量的に示す）。 ### アプリケーション層 **MCP サーバー**: Model Context Protocol (MCP) を実装した専用サーバーを Application Layer に配置し、UModel の統一表現をエージェント呼び出し可能なツールとして公開する。IaaS 層（`sls_execute_spl` 等）と PaaS 層（`umodel_get_entities`・`umodel_get_golden_metrics`・`search_entity`・`get_topology`・`drill_down` 等）の階層的ツール体系を提供（Table III）。 **データエージェント層**: 主エージェント（RCA エージェント）を U-SPL の複雑なクエリ構文から切り離すために、UModel は U-SPL クエリをドメイン固有の分析ツール（`analyze_golden_metric(entity)`, `analyze_error_log(entity)` 等）に内包するデータエージェント層を導入する。この分離により(1)クエリ構文の幻覚を削減、(2)コンテキスト消費量を 80% 超削減しながら診断精度を向上。 ### 本番展開 Alibaba Cloud の本番環境に 1 年以上展開。Container Services・APM・DevOps・実ユーザー監視・合成監視・ログサービス・クラウド監視を含む数百クラウドプロダクトをカバー。K8s・Network を含む複数ヘテロジニアスサブシステムにまたがる数千の標準化コンフィグレーションモデルを管理。1 日数万ユーザー・1 秒あたり数百万エンティティ/関係オペレーション・大規模データ取得に対するサブ秒クエリ応答を維持。 ## 新規性 | 既存の課題 | UModel の解決策 | |---|---| | メトリクス名が文字列トークンにすぎず LLM が単位・型・用途を推論できない | EntitySet に unit・type・説明等のセマンティクスを付与（Semantically Rich） | | 孤立したイベントの記録で「なぜ」がわからない | EntitySetLink でトポロジー依存関係をエッジとして明示（Graph-Based） | | 読み取り専用ダッシュボードでエージェントがアクションできない | MCP ツール経由でリメディエーションツール・データ前処理ツールを提供（Tool-Enabled） | | Prometheus・ELK・Jaeger が互換スキーマなしに並存 | EntitySet/DataSet の統一スキーマで物理ストレージを抽象化（Unified Object Store） | マルチモーダル統合技術（[13][15]）は教師ありパラダイムへの依存があり未見障害に脆弱だが、UModel はデータ組織化（教師不要）で一般的に改善する。 ## 実験設定 - **データセット**: 「2025 AIOps Challenge」—ChaosMesh で注入した 138 障害、ノードレベル・Podレベル・サービスレベル障害を網羅 - **評価指標（品質メトリクス）**: LA（Location Accuracy with Redundancy Penalty: `LA = (L_c - σ×L_i) / L_t`、σ=0.05）・TA（Type Accuracy）・RS（Reasoning Score）・OS = 0.4TA + 0.3LA + 0.3RS - **評価指標（ランキングメトリクス）**: Top-1 Acc・Top-3 Acc（根本原因が Top-k 予測内に含まれるか） - **ベースライン**: ReAct ベースエージェント + 従来データモデル（PromQL/SQL 直接クエリ）と UModel 接続エージェントの比較 - **RQ3（IaaS vs PaaS）**: ReAct・OpenClaw・Multi-Debate・Reflexion・Plan-Execute の 5 フレームワーク × Full Paired / Stratified Main / Filtered Effective の 3 評価セット ## 実験結果 ### RQ1: 従来データモデル vs UModel（Table IV） | メトリクス | 従来モデル | UModel | 改善 | |---|---|---|---| | OS | 49.70 | 55.45 | +5.75 | | TA | 36.11 | 40.74 | +4.63 | | LA | 55.96 | 64.08 | +8.12 | | RS | 48.56 | 58.53 | +9.97 | | Top-1 Acc | 68.12 | 74.64 | +6.52 | | Top-3 Acc | 71.74 | 78.99 | +7.25 | 従来モデルでは PromQL を直接生成する精度が <5%（既往研究と一致）であり、UModel 設定では LA・RS 改善が主要ドライバーであることが確認された。 ### RQ2: アブレーション（Table VI） GSearch（G）と USearch（U）の除去アブレーション： | 設定 | TA | LARP | Top-1 | Top-3 | |---|---|---|---|---| | G&U | 36.96 | 66.34 | 68.84 | 74.64 | | w/o G | 30.43 (-6.53) | 62.39 (-3.95) | 68.84 (+0.00) | 74.64 (+0.00) | | w/o U | 55.48 (-10.86) | 55.48 (-10.86) | 64.83 (-4.01) | 70.83 (-3.81) | | w/o G&U | 20.29 (-16.67) | 57.50 (-8.84) | 64.83 (-4.01) | 69.83 (-4.81) | GSearch はトポロジー関係の発見を通じて Location 関連メトリクスに大きく影響し、USearch はエンティティ関連情報（イベントデータ含む）の高速取得で全評価メトリクスに寄与する。 ### RQ3: IaaS vs PaaS（Table V） PaaS 意味的層は 3 評価セット全体で一貫して IaaS 直接 SPL を上回る（Pooled OS: Full Paired +9.29, Stratified Main +12.33, Filtered Effective +12.45）。場所精度（LA）が主要ドライバーで +21〜+25 ポイント改善。TA は -0.90〜+4.30 の微小変化にとどまり、PaaS はエンティティ正規化・トポロジー探索によって「場所を特定する」能力を主に強化する。 ## 考察 - **UModel の 8% 改善は保守的推定**: 実験設定ではベースラインに全観測可能性データをプリロードして 100% アクセス権を付与したため、U-SPL のオブジェクト中心設計（幻覚率削減・方言不要）による実際の優位は数値以上に大きい可能性がある。 - **PaaS が IaaS を上回る理由**: IaaS では LLM が service_id をフィルタとして使用するシナリオで node_id を要求するような意味的不一致が起きやすく、PaaS の正規化されたエンティティ識別子とトポロジー認識型検索がこれを排除する（Figure 5・Case Study 1）。 - **GSearch の役割（Case Study 2）**: productcatalog-1 のコンフィグ変更がノード共有を通じて checkout-2 に波及した事例では、従来データモデルは checkout-2 の異常シグナル数が多いために誤診するが、UModel は GSearch でノード同居関係とコンフィグ変更イベントを一クエリで取得し正しい根本原因を特定した（Figure 6）。 ## 強み / 弱点・課題 **強み**: - 既存テレメトリシステム（Prometheus・Elasticsearch 等）をそのまま利用し、統一オントロジーレイヤーを仮想的に構築できる（後方互換性） - Alibaba Cloud 1 年以上の本番デプロイという工業規模の検証済み - 教師なしアプローチであり、未見障害に対して教師ありモデルより一般性が高い **弱点・課題**: - UModel モデル構築の一次的な人的コスト（エンティティ定義・DataLink スキーマ作成）は依然として残る（アプペンディクス A の Visualized Model Building で軽減されているが、大規模・高頻度変更環境では継続的なメンテナンスが必要） - 評価データセット（138 障害）の規模と多様性。実際の本番障害分布とのギャップの定量化が未実施 - UModel の改善の一部は U-SPL のクエリ品質（意味的一致）による可能性があり、オントロジー設計の良否が性能に非線形に影響する - エージェントへの LLM として Qwen3-max のみを使用しており、他 LLM ファミリーへの汎化性が未確認 ## 関連 - ソース: [[.raw/papers/arxiv-2606.04799.pdf]] - エンティティ: [[Changhua Pei]] / [[Dan Pei]] / [[Gaogang Xie]] / [[Alibaba Cloud]] / [[Tsinghua University]] - 概念: [[オブザーバビリティデータモデル]] / [[根本原因分析]] / [[AIOps]] / [[テレメトリ]] / [[ワークフロー自動化]] - 関連ソース: - [[@2025__WWW__Flow-of-Action - SOP Enhanced LLM-Based Multi-Agent System for Root Cause Analysis]]（同グループの RCA マルチエージェント研究） - [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]（同グループの AgentOps サーベイ。UModel はデータ層、AgentOps はエージェント層の研究） - [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]]（事前コンテキスト制御の類似アプローチ：UModel のデータエージェント層と [[Flexible Skill Arrangement]] の哲学は近接する） - [[@2026__arXiv__Which Types of Heterogeneity Matter for Root Cause Localization in Microservice Systems]]（マイクロサービス RCL の関連研究。NexusRCL は GNN ベースの boxを探るが、UModel はデータモデル自体を変える） ## 出典 - [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] = 本論文(arXiv:2606.04799v1, 2026-06-03)