# ログパース ## 定義 ログパース(log parsing)は、生の各ログ行を構造化イベントレコードへ変換し、不変のイベント意味(テンプレート)と動的な runtime 値(パラメータ)を分離する前処理。具体的には raw ログ行 $x$ から (i) ヘッダフィールド(timestamp/level/process/component)、(ii) 動的スパンをプレースホルダ `<*>` に置換したテンプレート $t$、(iii) 抽出パラメータ列 $v$ を出力し、オンライン設定では各テンプレートにイベント ID を割り当てて raw stream をイベント系列へ変換する([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] §5.1)。例えば "Jetty bound to port 62267"/"62258" は同一テンプレート "Jetty bound to port `<*>`" に正規化される。[[異常検知]]・[[障害予測]]・[[根本原因分析]] など多くの下流タスクの前提で、サーベイのコーパスでは task-paper の約 1/4(41 論文)を占める第 2 の主要タスク。本 wiki の [[ログ解析]] が「scoping + RCA」(診断)を扱うのに対し、ログパースはその手前の「raw→構造化」の変換段に当たる。 ## 横断的知見 - **「LLM パースは高品質だが高価なプリミティブ」という前提が reuse/coordination 層を生む**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は LLM パースを supervised/log 特化適応(LogPPT・LLMParser・PreLog・OWL)、prompt/adaptive ICL(DivLog・LogBatcher)、retrieval/refinement 無教師(LibreLog・AdaParser)、システム効率層(LILAC の adaptive cache・LogParser-LLM の grouping・EPAS の非同期スケジュール・InferLog の KV-cache 再利用)に分類し、いずれも「LLM 推論を高品質だが高価なプリミティブと見なし、cache/grouping/scheduling/template memory/tool 分解で LLM トークンあたりの構造化出力を最大化する」共通設計だと整理する(§5.3)。これは本 wiki の [[ログ解析]]([[LogPilot]] が request クラスタリングで LLM 呼び出しを 98.71% 削減)・[[根本原因分析]]([[OpenRCA]] が raw テレメトリをコンテキストに載せずコード実行で捌く)で見た「LLM を選択的に呼ぶ階層設計」と同型——情報を絞ってから LLM を呼ぶ骨格がパース段でも反復する。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - **reuse 層の「誤テンプレート増幅」が LLM パース特有の新たな失敗モード**: サーベイは cache/propagation/template-memory が一度誤ったテンプレートを保持すると広く拡散しうると指摘し、cache 更新ポリシー・validation/refinement フック・variable-aware reuse(SemanticLog のパラメータスロット追跡)を必須とする(§5.3.5)。これは [[根本原因分析]] の reuse 層([[L4]] の fault library・[[AlertGuardian]] の RAG 知識ベース)が「KB の鮮度・誤り混入」に律速される問題と同根で、**過去結果の再利用はコストを償却する一方、誤りの伝播経路にもなる**という reuse の二面性がパース段で先鋭に現れる。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - **ログ署名（コード位置）による事前クラスタリングが従来パーサの精度と速度を同時に上回る**: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] は、既存パーサ（LogCluster/AEL/Drain/LFA）がログ本文の共通語句のみでテンプレートを導くのに対し、ログ署名（ログ文のソースコード上の位置、例: `controller.go:107`）でまず粗くクラスタリングし、クラスタ内の頻度分析で定数語を抽出する 2 段パーサを提案する。MLA で Drain を平均 57.03% 上回り（サービス A=1.000、B=0.986、C=0.992）、100 万行のパース時間は Drain の約半分・AEL の約 1/4。コードの共有（reuse）により同一ログ文が異なるコード位置に現れうるが、ログ署名で一意化することでテンプレートの混同を回避する。これは LLM パーサの cache/grouping 層とは対極の「構造的メタデータによる確定的クラスタリング」であり、ログ署名が利用可能な環境では LLM を一切使わずにパース精度の上限を押し上げる。ただしログ署名がない環境への適用にはフォールバック（LogSig 等）が必要。(Source: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]], [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) ## 横断的知見(続き) - **パース出力のイベントテンプレートの大半は下流の異常検知に不要であり、パース精度の向上だけでは下流改善に直結しない可能性がある**: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] は Brain パーサが生成したイベントテンプレートの 55%〜99.9% が異常検知に不要と実証する。サーベイ([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]])がパース精度向上(GA/PA/FGA/FTA)を追求する一方で、パース後のテンプレート集合自体が冗長であり、情報理論的な選別（相互情報量・OPTICS）が下流性能に直接寄与するという知見は、パース研究が下流の情報利用を意識したテンプレート品質指標を持つべきことを示唆する。(Source: [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]], [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) ## 未解決の問い - パース誤りが下流(scoping・[[異常検知]]・[[根本原因分析]])にどう伝播するか。サーベイは異常検知研究の多くがパース依存(Table 6–7 の "Parsing? Yes")だと示すが、NeuralLog/LogRoBERTa のようにパースを除く流派もある——テンプレート churn が下流の event-identity 安定性を壊す影響は系統的に未測定([[ログ解析]] の同じ問いと接続)。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - GA/PA は頻度バイアスで long-tail を隠す。FGA/FTA(F1 ベースのテンプレートレベル指標)を併記する流れは進むが、online/offline・oracle テンプレート定義・grouping ポリシーの違いで論文間比較が依然困難。パース評価の標準化はどの指標セットに収束すべきか。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - 「unsupervised パースは single-shot でない」——retrieval/grouping 品質が効果を律速する(retrieved ログが複数テンプレートを混ぜると over-general、狭すぎると変数が定数化)。grouping/retrieval とテンプレート生成のどの組合せがドリフト下で安定収束するか。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - パース精度指標(GA/PA)の改善は下流の異常検知 F1 にどの程度寄与するか。LogCleaner が示すように下流にはイベント選別層が入る余地があり、パース精度 100% であっても情報理論的に冗長なテンプレートは依然として下流を劣化させうる。パース→選別→検知の連鎖的な品質伝播を系統的に測る枠組みが必要。([[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]]) ## 関連 - ソース: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] / [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]] / [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] - 概念: [[ログ解析]] / [[異常検知]] / [[根本原因分析]] / [[障害予測]] / [[AIOps]] - エンティティ: [[Tse-Hsun Chen]] / [[Michael R. Lyu]] / [[LogCleaner]] / [[LogReducer]] - 関連 MOC: [[AIOps - Log Analysis - MOC]] ## 出典 - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]](§5 Log Parsing: §5.1 タスク定義/Fig.4 Hadoop 例, §5.3 手法ファミリ/Table 5, §5.3.5 システム効率層と誤テンプレート増幅, §5.4 評価指標 GA/PA/FGA/FTA) - [[@2024__ESEM__Reducing Events to Augment Log-based Anomaly Detection Models - An Empirical Study]](§3.2 パースワークフロー, §5.3 パース後イベントの 3 類型, §6 情報理論的選別) - [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]](§IV-C ログ署名ベースの 2 段パーサ、MLA で Drain を平均 57.03% 上回る)