【ITニュース解説】Building a Query-Aware Log Compressor in Rust: From 100k Lines to 200

システムが正常に動作しているかを確認したり、問題が発生した際にその原因を突き止めたりするために、「ログ」は不可欠な情報源となる。しかし、現代のシステムは複雑化しており、たった1時間で数万、時には10万行ものログが出力されることは珍しくない。これほど膨大なログの中から、「なぜ決済処理が失敗したのか」といった具体的な問題を解決するために必要な情報を見つけ出すのは、非常に困難な作業だ。

従来のログ検索方法では、「grep」のようなツールを使って特定のキーワードを検索することが一般的だった。だが、「タイムアウト」といったキーワードで検索しても、それがログのどの部分で、どのような文脈で発生したのかまでは把握しにくい。例えば、10万行のログから「タイムアウト」という単語が47箇所でヒットしても、それだけでは問題の全体像はつかめない。また、最近注目されている大規模言語モデル（LLM）に大量のログを分析させようとしても、一度に処理できる情報の量（コンテキストウィンドウ）を超えてしまい、実用的な解決策とはならないのが現状だ。

このような課題を解決するために開発されたのが「logcompress」というツールである。このツールは、自然言語（普段私たちが使う言葉）で「なぜ決済番号42がタイムアウトしたのか」といった質問（クエリ）を入力し、ログファイルを指定するだけで、膨大なログの中から本当に重要な200行程度の情報を抽出し、それらにスコアを付けて関連度順に並べ、さらに問題の背景を理解するための関連情報（トレースコンテキスト）を補足してくれる。これにより、最初の要求から再試行、そして最終的なタイムアウトエラーに至るまでの一連の流れを、効率的かつ網羅的に把握できるようになる。

logcompressの処理は、いくつかの段階を経て実行される。まず最初のステップは「トークン化」と呼ばれるもので、ログの各行を高速にハッシュトークンという数値のデータに変換する。この際、文字列を直接扱うのではなく、その文字列から計算されたユニークな数値（ハッシュ値）を直接利用することで、メモリーの効率化と処理速度の向上を図っている。この変換処理は複数のCPUコアを使って並列で行われるため、10万行のログでも50ミリ秒未満という短時間で完了する。

次に、各ログ行とユーザーが入力したクエリの関連性を評価するために、「TF-IDF（Term Frequency-Inverse Document Frequency）」という手法を用いる。TF-IDFは、クエリに含まれる単語が、そのログ行の中では頻繁に出現する一方で、ログファイル全体の中ではあまり出現しない場合に、そのログ行のスコアを高くする仕組みだ。これにより、特徴的でクエリに密接に関連する情報を持つログ行が上位にくる。しかし、ログには「"service":"payment"」のように、多くの行に共通して出現する単語も多い。これらがクエリに含まれると、すべての行のスコアが高くなりすぎてしまい、本当に重要な情報を見分けにくくなる。そこでlogcompressは、最もスコアが高い行の25%以下のスコアしか持たない行を候補から除外する「スコアギャップフィルター」を適用し、ノイズを排除してより意味のある情報だけを絞り込む。

さらに、ログがJSON形式などの構造化されたデータである場合、「trace_id」や「error_id」といった特定のフィールドにクエリで言及されている内容と一致する情報が含まれていれば、その関連性は非常に高いと判断できる。logcompressでは、このような構造化フィールド内の情報に特別な「ブースト（倍率）」をかけることで、より正確に関連性の高いログを特定する。例えば、「error_id」や「trace_id」がクエリと一致した場合、そのログ行のスコアを3倍にするといった設定が可能で、これにより重要な情報が埋もれるのを防ぐ。

logcompressの最も特徴的な機能は「トレース拡張」である。これは一般的な検索ツールとは一線を画す点だ。例えば、システムでタイムアウトが発生した際に、「支払いゲートウェイへの要求を開始」「ゲートウェイ接続を再試行」「ゲートウェイ応答が遅い」「支払いゲートウェイがタイムアウト」という一連のログが出力されることがある。もしユーザーが「タイムアウト」という単語で検索した場合、直接ヒットするのは最後の「支払いゲートウェイがタイムアウト」という行だけかもしれない。しかし、問題の原因や経緯を理解するには、その前の3つのログも不可欠である。これらのログは直接「タイムアウト」という単語を含まないため、TF-IDFだけでは見落とされてしまう可能性がある。ここで「trace_id（トレースID）」が活躍する。システム内の各処理には、通常、一連の関連する操作を紐づけるための一意のIDが付与されている。logcompressは、高スコアのログ行からこのtrace_idを抽出し、そのIDを共有するすべてのログ行を自動的に収集する。これにより、検索キーワードには直接ヒットしなくても、同じ一連の処理に属する関連ログを漏れなく発見できるようになり、問題解決に必要な情報の網羅性（リコール）が大幅に向上する。実際の検証では、この機能によって網羅性が約70%から100%にまで改善されたという結果が出ている。

最後に「コンテキストウィンドウ」というステップで、特定された重要なログ行の前後数行も一緒に取得し、重複する範囲を結合する。これは、trace_idを共有しないものの、時間的に問題発生の直前や直後に出力された関連性の高いログ（例えば、タイムアウトを引き起こした最初のリクエストのログや、その後の復旧処理のログなど）を捕捉するために役立つ。

これらの高度な処理を組み合わせることで、logcompressは10万行のログから、わずか100〜200行の本当に重要な情報を、250ミリ秒未満という非常に高速な時間で抽出し、しかも問題に関連するすべての情報（網羅率100%）を漏らさずに提供できるという、優れた性能を発揮する。従来の「grep」のような単純な文字列検索ツールや、「jq」のようなフィールドフィルタリングツール、高速な正規表現検索ツールである「ripgrep」と比較しても、logcompressはTF-IDFによる関連度ランキングとトレース拡張という独自の強力なアプローチにより、開発者やシステムエンジニアが本当に求めている「問題解決に必要な文脈を持った情報」を提供する点で、圧倒的な優位性を持つ。このツールは、システム運用やデバッグ作業におけるログ分析の効率を劇的に向上させる、強力な解決策となるだろう。