[保留] フィードバック本文を LLM で構造化し、THQ の該当路線・時間帯の異常と自動突合する

[TinyKitten]

Important

現状は着手しない（前提が成立していない）

THQ にテレメトリを送っているのは開発メンバーだけで、開発メンバーはテスト以外でフィードバックを送らない。 つまり「フィードバックを送った人のテレメトリ」が存在しないため、突合の対象データがゼロ。

起票時にこの前提を確認しておらず、一般ユーザーのテレメトリが溜まっている想定で書いてしまった。以下の内容はその想定のまま残してある。

テレメトリの送信母数が一般ユーザーへ広がった場合に、この Issue を再開する。 それまでは備えとして置いておく。

---

背景

TrainLCD/Issues に届くフィードバックは自由記述で、「もう仙台駅まで来ているのに、まだ一ノ関駅だって」のような形で来る。現状トリアージは、この文とスクリーンショットを人間が読んで原因を推測している。

一方 THQ には同時刻・同路線の位置ログが溜まっている。文章から「路線・区間・時間帯・症状」を取り出せれば、該当する実データを自動で引き当てられる。

実際 TrainLCD/MobileApp#6883 の調査では、スクリーンショットから「次駅=一ノ関、現在地マーカーは盛岡直後」を目視で読み取って当たりを付けた。テレメトリを引けていれば、精度・速度・state 遷移・位置ログの欠落が最初から見えていた。

やりたいこと

トリアージ時に LLM が次を行う。

1. フィードバック本文（＋発行日時・アプリバージョン・プラットフォーム）から構造化データを抽出する
   • 路線・駅（表記ゆれ・旧称・愛称を含む）
   • 時間帯（発行日時からの逆算で妥当な範囲）
   • 症状クラス（現在地がズレる / 到着が検知されない / 通過駅で止まる / 音声が出ない …）
2. 抽出結果を THQ のクエリへ変換する（locations / accuracyByLine / 開発メンバーのテスト乗車を自動回帰チェックにする（位置ログの欠落＋直前の OS 速度で「現在地凍結」を検出） #30 の凍結検出）
3. 結果を要約して、公開 Issue 側に証跡ブロックとして自動で貼る
   • 該当時間帯・区間の精度分布（avg / p90）
   • state 遷移の並びと、topology から見た欠落・逆行
   • 位置ログの欠落と直前速度（開発メンバーのテスト乗車を自動回帰チェックにする（位置ログの欠落＋直前の OS 速度で「現在地凍結」を検出） #30 の signature）

LLM が効くのは 1 と 3。「自由記述 → 構造化クエリ」と「時系列 → 人間が読める診断文」で、ここは決定的なルールを書きづらい。2 は普通のクエリでよい。

相関キーが無い件（母数が広がっても残る課題）

• フィードバックが持つのは reporterUid（Firebase の匿名 UID）
• THQ の device は Device.modelName、つまり "iPhone 15 Pro" のような機種名であって個体識別子ではない
• 共通するのは app_version / platform / おおよその時刻だけ

なので再開時も初期スコープは個人を特定しない突合にしたい。「この路線のこの時間帯に、報告された症状に対応する異常が観測されているか」を見る。

相関キー（フィードバック送信時に session_id を同送する等）を入れる選択肢はあるが、自由記述の本文と位置トレースが個人単位で紐付くことになるので、入れるかどうかは別途判断したい。THQ が生の位置情報を observer トークンに限定している設計思想とも関わる。

再開の条件

• テレメトリの送信母数が開発メンバー以外へ広がっていること
• 突合対象になるフィードバックが実際に発生していること