【ITニュース解説】How to Build an AI-Powered Log Summarizer for DevOps

システム運用の現場では、日々大量のログが生成されており、これらはシステムの状態を把握し、問題が発生した際に原因を特定するための重要な情報源となる。しかし、障害発生時には、数百万行にも及ぶ膨大なログの中から関連する情報を手動で探し出す作業は、非常に時間と労力がかかる課題だ。既存のログ集約ツールは、ログの保存や検索には優れているが、その内容を人間が理解しやすい形に解釈する機能は持たない。例えば、「午後2時23分から2時31分にかけて、支払いサービスがチェックアウトへのすべてのPOSTリクエストで503エラーを返した。その直前の各失敗には、Redis接続プールからの3つのタイムアウトメッセージが先行していた」といった具体的な状況説明は、現在のツールから直接得ることはできない。

このような課題を解決するため、AI、特に大規模言語モデル（LLM）を活用したログ要約ツールが注目されている。このツールは、膨大なログの中から重要な情報だけを抽出し、簡潔にまとめることで、インシデント発生時の初動を大幅にスピードアップさせることを目的としている。従来の監視ツールを置き換えるものではなく、それらを補完し、担当エンジニアが迅速に問題の核心に迫るための「頭出し」を提供することが役割だ。

このAIパワードのログ要約ツールは、三つの主要な部分から構成される。第一に「ログコレクター」が、ファイルや標準入力、またはログクエリAPIからログを読み込む。第二に「プリプロセッサー」が、読み込んだ生ログの中からノイズを取り除き、重複するログを整理し、大規模言語モデルが処理できる文字数に収まるようにログを整形する。そして第三に「LLMサマライザー」が、整形されたログを大規模言語モデルに送り、構造化された要約を受け取るという流れだ。このツールはPythonで実装されたコマンドラインインターフェース（CLI）ツールであり、API呼び出し用のHTTPXライブラリを除けば、特別なフレームワークに依存しないシンプルな設計である。

ログの収集と前処理は、大規模言語モデルにデータを送る上で非常に重要なステップである。生ログには、その量と繰り返し現れる無意味な情報という二つの大きな問題があるからだ。大量のログをそのままLLMに送ると、処理コストが増大するだけでなく、モデルの入力限界（コンテキストウィンドウ）を超過してしまう可能性がある。また、何度も繰り返される同じようなログメッセージは、モデルにとって重要な情報ではなく、かえってノイズとなる場合がある。そのため、前処理ではまず不要な「ノイズ」となるログ（例：ヘルスチェックやキープアライブに関するメッセージ）を除去する。次に、「重複排除」を行う。これは、タイムスタンプや数値部分を一般的なプレースホルダーに置き換えることで、見た目は異なるが本質的に同じ内容のログを同一パターンと見なし、その出現回数をカウントする方法である。特定のパターンが繰り返し現れる場合でも、最初の数回（例えば5回）だけを保持し、それ以上はモデルに送らないようにする。最後に、最も新しいログから最大200行だけを保持する「行数制限」を行う。これは、一般的なログの冗長性を考慮すると、200行で3000～4000トークン程度に収まり、多くのLLMが提供するコンテキストウィンドウに十分な余裕を残し、モデルの応答スペースを確保するためである。この慎重な行数制限により、モデルは最新の状況に焦点を当てて分析できる。

前処理されたログが準備できたら、いよいよ大規模言語モデルによる要約処理に移る。要約処理の肝は「プロンプト」である。モデルに対して何を求めるかを明確に指示するプロンプトがなければ、単にログの内容を言い換えるだけの要約しか得られないだろう。このツールでは、モデルに「DevOpsのインシデントアシスタント」としての役割を与え、「タイムライン（主要なイベントと時刻）」「エラー（明確なエラーの種類とその数）」「根本原因の仮説（最も可能性の高い原因）」「推奨される次のステップ（具体的な調査アクション）」という四つのセクションを含む構造化された要約を生成するよう指示している。このプロンプトは、モデルが単なる情報の羅列ではなく、具体的な洞察と行動につながる情報を提供するための重要なガイドとなる。API呼び出しの際には、temperatureという設定値を0.2に設定している。これは、モデルの出力をより事実に基づいた、創造性の低いものにすることで、信頼性を高めるためだ。また、ログの内容をXMLスタイルのタグで囲むことで、プロンプトの指示とログ本文をモデルが明確に区別できるように工夫されている。max_tokensは800に設定されており、これは有用な要約を得るのに十分な文字数でありながら、不必要な出力によるコストの浪費を避けるためのバランスの取れた値である。この機能はOpenAI互換のAPIであれば動作するため、OpenAIのクラウドサービスだけでなく、ローカルで動作するモデルとも連携可能である。

これらすべての機能を統合したPythonスクリプトは、コマンドラインツールとして提供される。これにより、既存のログファイルを指定して要約を生成したり、標準入力から直接ログのストリームを受け取ってリアルタイムに要約したりできる。特に、「kubectl logs -n production deploy/api-server --since=10m | python log_summarizer.py」のように、Kubernetes環境で過去10分間のログをパイプで渡す使い方は、稼働中のインシデント対応で真価を発揮するだろう。手動で何千行ものログを読み解くよりも、約3秒で構造化された要約が得られるため、インシデント対応チャネルに即座に共有できる価値ある情報となる。

このツールの導入を検討する上で、いくつかの実用的な制限事項と注意点を知っておくべきだ。第一に「ログの機密性」の問題がある。アプリケーションログには、個人を特定できる情報（PII）、セッショントークン、内部IPアドレスなどの機密データが含まれることが頻繁にある。これらを外部の言語モデルサービスに送信する前に、必ず「データ匿名化（Redaction）」の処理を実行する必要がある。第二に「コンテキストウィンドウの枯渇」という問題がある。大規模言語モデルが一度に処理できる情報の量には限界があり、前処理の制限は安全策の一つだが、もしログが非常に詳細な場合は、API呼び出し前にトークン数を正確に計測し、ウィンドウがオーバーフローする前に処理を中止するなどの対策が必要になる。第三に「データが少ない場合のハルシネーション」のリスクがある。前処理後のログが非常に少ない場合、モデルは十分な情報を持たず、もっともらしいが事実に基づかない「幻覚」を生成してしまう可能性がある。これを避けるため、前処理後に生き残ったログが20行未満の場合は、LLMによる要約をスキップし、生のログを出力するなどの閾値を設けるべきだ。第四に「コスト」の考慮が必要となる。例えば、gpt-4o-miniのようなモデルは、入力100万トークンあたり約0.15ドルの費用がかかる。200行のログを処理する場合、1回の呼び出しにかかる費用は0.1セント未満であり、インシデント発生時やデプロイごとに実行する分には問題ないが、すべてのHTTPエラーに対して頻繁に実行するような使い方は、コストが膨れ上がる可能性があるため推奨されない。

このツールの開発において、コード自体は比較的シンプルであり、わずか80行程度のPythonコードで実現可能である。しかし、最も難しい部分は、大規模言語モデルへの「システムプロンプト」を調整し、モデルが常に要求される「タイムライン、エラー、根本原因の仮説」といった構造化された出力を信頼性高く生成するようにすることだ。まずは特定のログソースや単一のサービスから始め、望ましいフォーマットが安定して得られるまでプロンプトを繰り返し改善していくことが重要となる。このAIパワードログ要約ツールは、インシデント対応の迅速化に貢献するだけでなく、新しいエンジニアが不慣れなサービスのログを理解するためのオンボーディングツールとしても活用でき、日々の業務効率向上に大きく貢献するはずだ。