# ログ生成 ## 定義 ログ生成(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]]) - **コーディングエージェント文脈での実証が「where/what/how の 3 決定」のうち what が最弱であることを大規模に裏づけた**: [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]] は where-to-log・what-to-log・how-to-log の 3 決定を理論的に整理したが、[[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] はコーディングエージェント(GPT-5.5・Claude Opus 4.8・Gemini 3.5 Flash)によるリポジトリレベルのオブザーバビリティ復元実験(1,223 インスタンス)で、Position F1(where、0.551〜0.633)が KeyBag F1(what、0.237〜0.398)を全プロンプト戦略・全モデルで一貫して上回ることを定量化した。これは LLM4Log が理論的に区別した 3 課題のうち、**「どこに記録するか」は構造的パターンとして学習しやすいが、「何を記録するか」は障害固有の意味論推論を要するため学習が難しい**という非対称性を、ロギング生成の実応用(コーディングエージェントによるリポジトリ全体の復元タスク)で実証した初のケースと言える。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]], [[@2026__arXiv__LLM4Log - A Systematic Review of Large Language Model-based Log Analysis]]) - **明示的指示への over-generation は、ロギング品質の低下という LogReducer の知見と同型の失敗モードをコーディングエージェントでも再現する**: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] は本番コードでのログレベル誤設定・テストログ消し忘れがホットスポットの根本原因の 63.15% を占めると報告したが、Observability-Aware Code 論文は生成時点で同型の問題を観測する——observability-hinted プロンプト(明示的指示)は blind と比べ生成量を倍増(2.1→4.9 文/インスタンス)させるが Precision は 0.33→0.20 へ悪化し、KeyBag F1 は 0.36→0.26 へ低下する(Quantity over Quality)。人間エンジニアが事後的にログを過剰生成・誤設定する問題(LogReducer)と、コーディングエージェントが生成時点で明示的指示に対して過剰生成で応答する問題は、**「指示・意図の量的解釈が質を犠牲にする」という同じ失敗モード**を運用後/生成時の両方で示す。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]], [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]) ## 未解決の問い - ロギング評価は 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]] / [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] - 概念: [[ログ解析]] / [[ログパース]] / [[異常検知]] / [[根本原因分析]] / [[テレメトリ]] / [[オブザーバビリティ]] / [[コーディングエージェント評価]] - エンティティ: [[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% がレベル誤設定+テストログ消し忘れ、ロギング品質→運用コスト直結の産業データ) - [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]](Table II Position F1 vs KeyBag F1 の一貫した非対称性、Figure 4 Quantity over Quality、18 リポジトリ 1,223 インスタンスのソースレベル復元実証)