# カーネル障害診断 ## 定義 カーネル障害診断は、Linux カーネルのようなオペレーティングシステムカーネルで発生したクラッシュに対し、障害箇所(ファイル・メソッド)を特定し、その障害がどのように観測されたクラッシュへ伝播したかを説明する取り組みである。分散システム・マイクロサービス向けの [[根本原因分析]] や [[Fault Localization]] が主に扱ってきた運用テレメトリ(トレース・メトリクス・構造化ログ)とは異なり、カーネル障害診断は疎で低レベルなアーティファクト(syscall・非構造化ログ・crash report)とソースコードレベルの意味論(マクロ展開・ポインタ間接参照・設定依存分岐)を対象とする点で性質が異なる。(Source: [[@2026__arXiv__KernelDiag - Agent-Based Root Cause Diagnosis for Kernel Crashes]]) ## 横断的知見 - **クラウド/マイクロサービス向け LLM ベース RCA はカーネルへ転用できない**: [[@2026__arXiv__KernelDiag - Agent-Based Root Cause Diagnosis for Kernel Crashes]] によれば、既存の LLM ベース RCA は end-to-end トレースや構造化ログといった rich な運用コンテキストの存在を前提とするが、カーネルにはこれが欠け、既存手法は疎で低レベルなアーティファクトしか持たない。加えて既存 RCA は障害種別分類やコンポーネント単位の粗い出力で十分とされる一方、カーネルの複雑なコードベースでは修正可能な粒度(メソッドレベル)の特定が要求される。この「運用コンテキストの欠如」と「必要な粒度の細かさ」という二重の乖離が、カーネル障害診断を独立した問題領域として扱う根拠になっている。 - **ログの発行元をソースコードへ対応づける「Log-to-Code Mapping」は、カーネル特有の課題である**: 一般的な障害診断手法はログ発行がキーワード(`log`・`print`・`info`)や既定の API で明示的に識別可能だと仮定するが、Linux カーネルのロギングはサブシステム固有マクロ(例: `invalfc` → `errorfc` → `__plog` → `logfc` → `printk`)で多層にラップされ、表層識別子を持たないことが多い。KernelDiag はこれを atomic logging sink からの backward reachability として形式化し、静的解析で解決する。マイクロサービスのログ解析(構造化ログ・ログテンプレート抽出が主流)とは前提が根本的に異なる。 - **アーティファクトの相対的重要度は crash report > syscall/log の順で、単一モダリティでは不十分**: KernelDiag のアブレーションでは crash report の除去が最大の性能低下(ファイル/メソッド Top@1 で -63.04%/-78.49%)をもたらし、根本原因の因果的アンカーとして機能することを示す。一方 crash report のみでは Figure 1 の EXT4 例のように真の障害メソッド(`__ext4_fill_super`)へ到達できず、ログの異常検知(checksum failure)が絞り込みの決め手になる。マイクロサービス RCA での「単一モダリティ vs マルチモーダル」論争([[マルチモーダル障害診断]])と同型の構図がカーネルにも現れている。 - **既存の一般目的コードローカライゼーション手法は、C/カーネル固有の構造を扱えるよう再設計が必要**: LocAgent のような graph-guided LLM エージェントは Python リポジトリ向けのグラフ構築・索引前提であり、マクロ・条件コンパイル・関数ポインタ・サブシステム固有ディスパッチを持つ C 言語のカーネルコードへは大幅な再エンジニアリングなしに適用できない。これは Fault Localization 分野で「ドメインの構造に従って手法を分ける方が自然」という [[Fault Localization]] の横断的知見と一致するが、カーネル領域では言語・ビルドシステムのレベルでの違いがより深刻になる。 - **正しい局所化と説明品質の相関は一様ではない**: 正しい Top-1 局所化は Consistency・Usefulness と強く相関するが(効果量 δ=0.47〜0.52)、Clarification(説明の分かりやすさ)とはほぼ無相関(δ=0.02〜0.08)。LLM は誤った局所化を起点にしても一貫性のある説明文を構成できてしまうため、説明の「分かりやすさ」評価だけでは診断の正しさを保証しない。 ## 未解決の問い - 既存の診断アーティファクト(syscall・ログ・crash report)のいずれにも中間状態が明示的に現れないケース(KernelDiag の失敗分析、フレームバッファのジオメトリ更新から後段のサイズ計算までの伝播)を解くには、軽量な動的解析(ブレークポイント・対象関数への一時的ロギング挿入)をどう静的な Evidence Graph 構築と統合すべきか。 - KernelDiag は複数 LLM バックエンド(DeepSeek-V3・Qwen3-Max)で部分的に相補的な正解セットを持つことが示された(ファイルレベルで共通 146 件、それぞれ独自に 38/31 件)。マルチバックエンド診断による頑健性向上は、コストとレイテンシをどこまで許容すれば実用的になるか。 - カーネル障害診断の役割特化エージェント設計(Syscall/Log/Report Agent)は、KGYM 以外のカーネル(BSD 系・組み込み OS・ハイパーバイザ)や、カーネル以外の低レベルシステム(デバイスドライバ・ファームウェア)にどこまで一般化するか。 - Log-to-Code Mapping の backward reachability 形式化は、カーネル以外の C/C++ 大規模プロジェクトのロギングマクロ体系にも適用可能か。マイクロサービスのログテンプレート抽出手法([[ログ解析]])との統合余地はあるか。 ## 関連 - 上位/隣接概念: [[Fault Localization]] / [[根本原因分析]] / [[マルチモーダル障害診断]] - 手法的関連: [[エージェント型コーディング]](役割特化エージェント設計・Evidence Graph はコーディングエージェントの構造化推論パターンと共通する) - ドメイン関連: [[Linuxカーネルインタフェース]] ## 出典 - [[@2026__arXiv__KernelDiag - Agent-Based Root Cause Diagnosis for Kernel Crashes]](§I Introduction: 既存 RCA との差異、§III-A Log-to-Code Mapping、§V-C アブレーション、§VI-IV 失敗分析)