# ログ生成 ## 定義 ログ生成(logging statement generation / 自動ロギング)は、ソースコードへログ文を自動で挿入・更新し、実行時に有用な runtime レコードを emit させる取り組み。コード文脈(メソッド・基本ブロック・ファイル)を与え、**どこに記録するか(where-to-log)**・**何を記録するか(what-to-log: level・message・variables)**・**どう保守するか(how-to-log: 品質・進化への追従)**の 3 決定を行う。ログ文は `logger.info(...)` のようなコードレベル API 呼び出しと簡潔な自然言語メッセージ・選択された変数を組み合わせるハイブリッドな成果物で、命名・冗長度・severity 慣習などプロジェクト固有の規約に整合させる必要がある([[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] §4.1)。[[ログ解析]] パイプラインの**最上流**(observability の設計段)に当たり、下流の [[ログパース]]・[[異常検知]]・[[根本原因分析]] が解析できる証拠そのものを作る。サーベイのコーパスでは 20 論文。 ## 横断的知見 - **LLM が持ち込んだ転回は「生成能力」でなく「ロギングを構文的挿入から意味的推論へ」組み替えたこと**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は、従来手法(ヒューリスティック・静的解析・古典 ML)が level/variable/message を独立サブタスクへ分解して不整合(message と合わない level、弱く関連する変数)を生んだのに対し、LLM はコードと自然言語の joint model としてこれら 3 決定を同時にモデル化し、where/what/how を学習済み意味パターンと in-context 推論から導くと整理する(§4.3)。fine-tuned 生成器(LANCE/FastLog/LEONID/ELogger)・ICL(UniLog)・実行文脈を与える CoT(SCLogger の 2-hop コールグラフ・PDLogger の backward slicing)・retrieval(OmniLLP の level 予測)・agentic 保守(LogUpdater の検出→分類→修復)に分類される。中心メッセージは「最も効く手法は無制約生成でなく、実行文脈・プロジェクト固有 exemplar・多段制御で LLM を制約し情報づける」こと——これは下流タスク([[根本原因分析]]・[[異常検知]])でサーベイが繰り返す「LLM を絞って選択的に呼ぶ階層設計」と同じ結論を、最上流のロギング段で再確認したもの。(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]] は WeChat の 57 ホットスポット・19 開発者インタビューに基づき、ホットスポットの根本原因の 63.15% が**ログレベル誤設定**(40.35%) と**テストログ消し忘れ**(22.8%) であると報告する。修正方法もログレベル修正(31.57%) とログ文削除(29.82%) が 61.69% を占める。いずれも where-to-log・what-to-log(特に level 選択)の決定品質の問題であり、本 concept が扱う**ロギング段の 3 決定が運用時のストレージ・CPU・ネットワーク帯域コストを直接左右する**ことを大規模産業データで初めて定量的に裏づけた。サーベイが整理する LLM ベースのログレベル推薦(OmniLLP/DeepLV)は、まさにこの品質問題を自動化で予防する研究群に当たる。(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]]) - **LLM はロギングの曖昧さを消さず、難所を「ルール設計」から「文脈選択・検証・oversight」へ移すだけ**: サーベイは LLM がロギング決定の本質的曖昧さ(同じイベントが module 次第で INFO/WARN)を除去するのでなく、難しさの所在を移動させると明言する(§4.3 まとめ)。これは [[ログ解析]] で見た「LLM は前処理を不要にせず変動に強いだけ」、[[異常検知]] の「LLM は何が異常かの曖昧さを消さず、努力を feature 設計から normality curation へ移す」と同型の観察——**LLM4Log 全段で「LLM は問題を解くのでなく難所を再配置する」というメタパターンが反復する**。ログ品質を開発プロセスへ還元する Dev-Ops ループ([[ログ解析]] の LogPilot が silent failure を開発チームへ feedback する議論)とも接続する。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) ## 未解決の問い - ロギング評価は exact-match(PA/LA/MA・BLEU/ROUGE)から semantics-aware(BERTScore)・set 予測(変数の precision/recall/F1・位置の precision/recall/F1)へ移りつつあるが、ロギングは本質的に under-specified(複数の妥当な挿入点・言い回し)。「複数の正解を許す」評価をどう標準化するか。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - 実行文脈(コールグラフ・slicing)を与える CoT 型ロギングはシステム複雑度と引き換えに意味的 grounding を得る。静的解析の前処理コストに見合うほど where/what 精度が上がるか、どの規模のコードベースで割に合うか。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - ログ品質の保守(how-to-log)を agentic に閉じる(検出→分類→説明→修復)流れは、コード進化に伴う semantic drift(コード挙動は変わったがメッセージは plausible なまま)をどこまで検知できるか。生成段の改善が下流診断([[根本原因分析]] が依拠する障害指示ログの質)を実際に底上げするかは未測定。(Source: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) ## 関連 - ソース: [[@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]] - 概念: [[ログ解析]] / [[ログパース]] / [[異常検知]] / [[根本原因分析]] / [[テレメトリ]] - エンティティ: [[Tse-Hsun Chen]] / [[Concordia University]] / [[LogReducer]] / [[Guangba Yu]] / [[Pengfei Chen]] - 関連 MOC: [[AIOps - Log Analysis - MOC]] ## 出典 - [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]](§4 Logging Statement Generation and Maintenance: §4.1 タスク定義/Listing 1-2, §4.2 where/what/how の 3 課題, §4.3 手法ファミリ/Table 4, §4.4 評価指標 PA/LA/MA/AOD/BERTScore) - [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]](§III-D/Table I 根本原因 63.15% がレベル誤設定+テストログ消し忘れ、ロギング品質→運用コスト直結の産業データ)