# ログ生成 ## 定義 ログ生成(logging statement generation / 自動ロギング)は、ソースコードへログ文を自動で挿入・更新し、実行時に有用な runtime レコードを emit させる取り組み。コード文脈(メソッド・基本ブロック・ファイル)を与え、**どこに記録するか(where-to-log)**・**何を記録するか(what-to-log: level・message・variables)**・**どう保守するか(how-to-log: 品質・進化への追従)**の 3 決定を行う。ログ文は `logger.info(...)` のようなコードレベル API 呼び出しと簡潔な自然言語メッセージ・選択された変数を組み合わせるハイブリッドな成果物で、命名・冗長度・severity 慣習などプロジェクト固有の規約に整合させる必要がある([[LLM4Log]] §4.1)。[[ログ解析]] パイプラインの**最上流**(observability の設計段)に当たり、下流の [[ログパース]]・[[異常検知]]・[[根本原因分析]] が解析できる証拠そのものを作る。サーベイのコーパスでは 20 論文。 ## 横断的知見 - **LLM が持ち込んだ転回は「生成能力」でなく「ロギングを構文的挿入から意味的推論へ」組み替えたこと**: [[LLM4Log]] は、従来手法(ヒューリスティック・静的解析・古典 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: [[LLM4Log]]) - **「ログ品質の低さ」がログホットスポットの支配的原因であり、ロギング段の品質は運用コストに直結する**: [[@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]], [[LLM4Log]]) - **LLM はロギングの曖昧さを消さず、難所を「ルール設計」から「文脈選択・検証・oversight」へ移すだけ**: サーベイは LLM がロギング決定の本質的曖昧さ(同じイベントが module 次第で INFO/WARN)を除去するのでなく、難しさの所在を移動させると明言する(§4.3 まとめ)。これは [[ログ解析]] で見た「LLM は前処理を不要にせず変動に強いだけ」、[[異常検知]] の「LLM は何が異常かの曖昧さを消さず、努力を feature 設計から normality curation へ移す」と同型の観察——**LLM4Log 全段で「LLM は問題を解くのでなく難所を再配置する」というメタパターンが反復する**。ログ品質を開発プロセスへ還元する Dev-Ops ループ([[ログ解析]] の LogPilot が silent failure を開発チームへ feedback する議論)とも接続する。(Source: [[LLM4Log]]) - **コーディングエージェント文脈での実証が「where/what/how の 3 決定」のうち what が最弱であることを大規模に裏づけた**: [[LLM4Log]] は 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?]], [[LLM4Log]]) - **明示的指示への 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]]) - **what-to-log の決定は、LLM 以前は「アプリケーションの特性に応じた経験則」として人手で行われていた**: [[LLM4Log]] は what-to-log(level・message・variables の選択)を LLM が意味推論で決定する対象として整理するが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] は 2011 年時点で、Apache が応答時間をマイクロ秒単位で記録する、[[Percona]] が MySQL のスロークエリ閾値を動的にチューニング可能にする独自パッチを当てる、といった「何を・どの粒度で記録するか」の判断をミドルウェア開発者が個別に作り込んでいた実例を報告する(§3.5)。これは、[[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] が定量化した「what-to-log(KeyBag F1)は where-to-log(Position F1)より学習が難しい」という非対称性が、LLM 登場以前から people 側でも同様に「どこに記録するか」より「何を記録するか」の意思決定が個別化・属人化しやすかったことを示唆する——ミドルウェア側(Apache・MySQL・Squid)が what-to-log を製品として作り込み、アプリケーション開発者はそれを「メトリクスとして読む」側に回るという役割分担が、2011 年の実務で既に成立していた。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] §3.5, [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - **ログ品質の無駄という同一の観察が、コード側の定量分析(LogReducer)と運用側の予算論(Building Secure and Reliable Systems)で独立に確認される**: LogReducer([[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]])はログホットスポットの根本原因の63.15%がログレベル誤設定・テストログ消し忘れというコード生成段階の問題であることを定量化したが、[[セキュリティログの設計と保護]]が集約する*Building Secure and Reliable Systems*第15章は「100 TBのログを持つシステムで、そのほとんどが一度も使われなかった」という実例を挙げ、有用性を検討せずログを積み増す無駄を組織の予算論として警告する。前者はコードレベルの記述品質、後者は運用レベルの保持コストという異なる粒度で観察されているが、根は「ロギング段の意思決定(where/what/how)の質を検討せずに積み増す」という同じ問題であり、ロギングの経済性は生成段階と保持段階の両方で作り込む必要があることを示唆する。(Source: [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] §Collect Appropriate and Useful Logs > Budget for Logging) ## 未解決の問い - ロギング評価は exact-match(PA/LA/MA・BLEU/ROUGE)から semantics-aware(BERTScore)・set 予測(変数の precision/recall/F1・位置の precision/recall/F1)へ移りつつあるが、ロギングは本質的に under-specified(複数の妥当な挿入点・言い回し)。「複数の正解を許す」評価をどう標準化するか。(Source: [[LLM4Log]]) - 実行文脈(コールグラフ・slicing)を与える CoT 型ロギングはシステム複雑度と引き換えに意味的 grounding を得る。静的解析の前処理コストに見合うほど where/what 精度が上がるか、どの規模のコードベースで割に合うか。(Source: [[LLM4Log]]) - ログ品質の保守(how-to-log)を agentic に閉じる(検出→分類→説明→修復)流れは、コード進化に伴う semantic drift(コード挙動は変わったがメッセージは plausible なまま)をどこまで検知できるか。生成段の改善が下流診断([[根本原因分析]] が依拠する障害指示ログの質)を実際に底上げするかは未測定。(Source: [[LLM4Log]]) ## 関連 - ソース: [[LLM4Log]] / [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] / [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 3 インフラとアプリケーションのメトリクス]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] - 概念: [[ログ解析]] / [[ログパース]] / [[異常検知]] / [[根本原因分析]] / [[テレメトリ]] / [[オブザーバビリティ]] / [[コーディングエージェント評価]] / [[セキュリティログの設計と保護]](ログ品質の無駄というコード側/運用側の対応する観察) - エンティティ: [[Tse-Hsun Chen]] / [[Concordia University]] / [[LogReducer]] / [[Guangba Yu]] / [[Pengfei Chen]] - 関連 MOC: [[AIOps - Log Analysis - MOC]] ## 出典 - [[LLM4Log]](§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 インスタンスのソースレベル復元実証) - マット・マッシー、ジョン・オルスポー, 「3章 インフラとアプリケーションのメトリクス」, 『ウェブオペレーション ―サイト運用管理の実践テクニック』, オライリー・ジャパン, 2011, §3.5(Apache/MySQL/Squid のログ記録粒度に関する 2011 年の実務判断)。 - Pete Nuttall, Matt Linton, David Seidman, "Investigating Systems", Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 15, §Collect Appropriate and Useful Logs > Budget for Logging(100 TB のログの大半が未使用という運用側の予算論)。