[保留] log_events のメッセージを LLM で意味クラスタリングし、バージョン別の新規・急増パターンを抽出する

[TinyKitten]

Important

現状は着手しない（規模が見合わない）

THQ にテレメトリを送っているのは開発メンバーだけなので、log_events の件数は目視で追える規模にとどまる。その規模で LLM クラスタリングを入れても、コストに対して得るものが無い（正規化＋完全一致で畳んだ一覧を眺めれば足りる）。

起票時に送信母数を確認しておらず、一般ユーザーぶんのログが溜まっている想定で書いてしまった。#31 と同じ誤りが原因。

テレメトリの送信母数が広がり、目視で追えない件数になった時点で再開する。

なお、下記「設計メモ」の前半（正規化＋完全一致で粗く畳む）は今の規模でも有効で、LLM なしで単独実装できる。先に着手するならそこだけを切り出すのが現実的。

---

背景

log_events には console.* 出力が自由記述の message として溜まっている。level での絞り込みはできるが、中身は文字列なので「同じ事象か」を機械的に判定できない。

実際にアプリ側のログを見ると、同じ失敗が可変部分（駅名・座標・エラーメッセージ・件数）を含んだ形で出る。

Failed to send location: NetworkError when attempting to fetch resource.
バックグラウンド位置情報の更新開始に失敗しました（リトライ 2/3）: ...
前回セッションの位置情報タスクの停止に失敗しました: ...

文字列の完全一致でも前方一致でも、これらは綺麗にまとまらない。正規表現でパターンを足していく運用は、パターンを書いた人が知っている失敗しか拾えない。

やりたいこと

LLM でメッセージを意味単位にクラスタリングし、次を出せるようにする。

• クラスタ一覧 — 代表メッセージ、件数、level 分布、影響セッション数
• バージョン別の増減 — app_version / channel ごとの発生率。あるビルドで新規に出現したクラスタ、急増したクラスタを上位に出す
• クラスタの命名と要約 — 「バックグラウンド測位の開始リトライ失敗」のような人間が読めるラベル

LLM が効くのは「可変部分を無視して同じ事象とみなす」判定と、クラスタへの命名。ここは事前にパターンを列挙できないので、決定的な実装では埋めきれない。

設計メモ

• 全件を毎回 LLM に流すのは非現実的。まず正規化（数値・UUID・座標・駅名をプレースホルダ化）＋ 完全一致で粗く畳み、残った代表文字列だけを LLM に渡す
  • ← この前半は現在の規模でも有効。LLM なしで単独実装できる
• クラスタ定義は永続化して再利用する。新しいメッセージはまず既存クラスタへの所属を判定し、どれにも当てはまらないものだけ新規クラスタ候補にする
• log_events は app_version / channel / platform を持っているので、バージョン別集計は単一テーブルで書ける（location_logs と違って join 不要）

期待する効果

Sentry がクラッシュを拾うのに対し、これはクラッシュしない失敗を拾う。測位の開始失敗、リトライ、送信失敗のような「動き続けるが劣化している」系は現状ログに埋もれている。

スコープ外

• クラッシュ収集は Sentry の担当。ここでは扱わない
• アラート通知は別 Issue にしたい

再開の条件

• log_events が目視で追えない件数になっていること