# オブザーバビリティデータモデル ## 定義 オブザーバビリティデータモデル(Observability Data Model)は、分散システムのメトリクス・ログ・トレース・イベントといった異種テレメトリを、エージェントや機械学習モデルが推論・行動に直接利用できる形式で整理するデータアーキテクチャである。単に「データを集める」のではなく、エンティティ・関係・セマンティクスを明示的にモデル化することで、システムの「なぜ壊れたか」の因果推論を支援する。 Karumuri ら([[@2021__SIGMOD Record__Towards Observability Data Management at Scale]])は 2021 年にオブザーバビリティを「データ管理問題」として最初に体系的に定式化し、MELT(Metrics/Events/Logs/Traces)の 4 類型が異なるデータモデル・クエリ・ストレージを要することを Slack の定量データで示した。この研究は ODMS(Observability Data Management System)の 4 設計原則とポリストア型アーキテクチャのブループリントを提案した。 [[UModel]] は 4 要件「Semantically Rich・Graph-Based・Tool-Enabled・Structured & Standardized」を「エージェント対応(Agent-Ready)」の条件として定義し、データ中心モデルからオブジェクト中心モデルへの転換を提案した最初の大規模実証フレームワークである。([[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]) ## 横断的知見 - **MELT の 4 型分類は 2021 年の産業論文で初めて定量的に確立され、2026 年の UModel がその未解決問題を解く系譜を形成している**: Karumuri ら(2021)は Slack の実測データ(表1・表2)で MELT 各型が相互に非互換の特性を持つことを示し、「統一 ODMS」の必要性を問いかけた。[[UModel]](2026)は LLM エージェントへの提供精度という角度から同じ問題に取り組み、セマンティクス欠如・トポロジー欠如・ツール欠如・方言乱立の 4 ギャップを解消する。5 年の間に問題は「どう管理するか(データ工学)」から「どうエージェントに見せるか(意味的モデリング)」へシフトした。(Source: [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]], [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]]) - **クエリの 97% 超が直近 24 時間以内というデータで、「履歴と鮮度の分離」がアーキテクチャ原則として裏付けられた**: Karumuri ら(表2)は Logs(92.5%→99.8%)・Metrics(94.7%→99.8%)・Traces(85.2%→97.3%)でいずれも 97% 超のクエリが <24h データを対象とすることを実測した。この強い鮮度バイアスは、リアルタイム層と履歴層を分離してそれぞれ最適化する設計を正当化する構造的根拠である。(Source: [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] 表2) - **従来のオブザーバビリティスタックは LLM エージェントに対して 4 つの構造的ギャップを持つ**: (1) セマンティクスなしの「死んだトークン」（メトリクス名 `node_cpu_seconds_total` は単位・型・用途を示さない）、(2) トポロジー関係なしの「孤立イベント」（サービス A の障害がサービス B への伝播原因かどうかを推論できない）、(3) ツール欠如の「読み取り専用ダッシュボード」（エージェントが修復アクションを実行できない）、(4) 方言の乱立（Prometheus/ELK/Jaeger が互換スキーマなしに並存）。UModel はそれぞれ Semantic Layer・Graph Structure・Tool-Enabled・Unified Object Store で解決する。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §III) - **データモデルの品質が下流 RCA 精度を律速することが初めて大規模実証された**: [[UModel]] は 2025 AIOps Challenge データセットで従来データモデル比 8% の RCA 精度改善（LA +8.12, Top-1 Acc +6.52）を達成した。これはモデルアーキテクチャや推論手法の改善ではなく、データ組織化の改善のみによる。([[AIOps]] の多くの研究が推論モデル・エージェント手法の改善に焦点を当てるなかで、データ層の設計が同等以上の影響を持つことを示唆する）(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-A, Table IV) - **「何を取得するか」の意味的正確性は「どう推論するか」より早い段階でエージェント性能を制限する**: 従来の IaaS 直接クエリ設定では LLM が PromQL を直接生成する精度が <5% にとどまり（既往研究と一致）、エージェントが正しい推論ロジックを持っていても正しいデータを取得できない。UModel の PaaS 意味的ツール層はこの制限を解消し、OS+9〜+13 ポイントの RCA 改善をもたらす。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-C, Table V) - **コンテキスト圧縮はデータモデル設計の一部である**: UModel のデータエージェント層は生テレメトリを集約・要約して LLM コンテキストに投入することでコンテキスト消費量を 80% 超削減しながら診断精度を向上させる。この設計は [[Bian Que]] の [[Flexible Skill Arrangement]]（事前 LoadDataSchema 宣言による取得スコープの制御）と同じ哲学——「エージェントに何を見せるか」の制御がエージェント性能の主要決定因——を共有する。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §IV-C; [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]]) - **オブジェクト中心モデリングはトポロジー推論を「マルチホップグラフ探索」に変える**: 従来データモデルではエージェントが「A から B への call 関係」を暗黙の知識か外部アーキテクチャ図から補う必要があるが、UModel の EntitySetLink によりエージェントは GSearch で `A --[calls]--> B` を直接クエリできる。Case Study 2（GSearch）では、同一ノード共有による障害伝播を 1 クエリで発見し、従来モデルが誤って checkout-2 を根本原因と誤診したケースを正しく productcatalog-1 の設定変更と特定した。(Source: [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] §VI-D, Figure 6) ## 未解決の問い - Karumuri ら(2021)が提案した ODMS ポリストアアーキテクチャ（Replicated Log Service → Real-Time Indexing → Persistent Storage → Hot Data Cache）は、その後 Slack や他社でどの程度実現されたか。Lambda アーキテクチャとの違いを定量的に比較した後続研究はあるか。 - UModel のオントロジー構築（エンティティ定義・DataLink スキーマ設計）のコストはどの程度か。頻繁に変化する大規模マイクロサービス環境では自動的なスキーマ発見・更新が必要になるが、実用的な手法は確立されているか。 - UModel の 8% RCA 改善はデータモデルの質とクエリインターフェースの意味的正確性のどちらがより大きく寄与するか。両者を分離した実験は未実施。 - オブジェクト中心モデリングの利点は [[AIOps]] 以外のドメイン（ネットワーク管理・DB チューニング・GPU クラスタ O&M）でも一般に成立するか。それとも分散システムのトポロジー構造に固有か。 - PaaS 意味的ツール層が IaaS 直接 SPL を一貫して上回るならば、IaaS 層を公開する理由は何か（デバッグ用途？特殊クエリ？）。PaaS 抽象が「うまくいかないケース」のパターン化は今後の設計指針になりうる。 - Qwen3-max 以外の LLM（GPT-4o・Claude 等）との組み合わせで同様の改善が得られるか。LLM ファミリーによってオブジェクト中心モデリングの恩恵の大きさが変わるか。 ## 関連 - ソース: [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]] / [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]] - 関連プロダクト: [[UModel]] / [[U-SPL]] - 親/隣接概念: [[AIOps]] / [[根本原因分析]] / [[テレメトリ]] / [[分散トレーシング]] / [[異常検知]] - 関連概念: [[Flexible Skill Arrangement]]（コンテキスト制御の類似哲学） ## 出典 - [[@2021__SIGMOD Record__Towards Observability Data Management at Scale]](§2 MELT 4 類型・表1・表2 鮮度バイアス・§3 Slack 産業事例・§4 ODMS 設計 4 原則とポリストア型アーキテクチャ) - [[@2026__arXiv__UModel - An Agent-Ready Observability Data Modeling Method at Scale]](§III Agent-Ready の 4 要件・§IV UModel アーキテクチャ・§VI 実験)