LLMアプリの観測ツール — 何を記録しておけば後から直せるか

記録しておくべき5つ

• どのプロンプト版で実行したか（バージョンが分からないと再現できない）
• 検索で何が引かれたか（RAG なら誤答の原因はたいていここ）
• モデルとパラメータ（温度やモデル差し替えの影響を切り分ける）
• 入出力のトークン数と所要時間（費用と遅延の調査に要る）
• ユーザーの反応（やり直したか、離脱したか）

2つめが最も重要で、最も残されていない。「回答が間違っている」と報告を受けたとき、モデルが悪かったのか、検索が関係ない文書を引いたのかを切り分けられないと、対策が勘になる。

設置の仕方で2種類に分かれる

Langfuse と Braintrust は SDK でトレースを送る形で、アプリのコードに計測を入れる。どのステップを1つのトレースにまとめるかを自分で設計できるので、エージェントのような多段の処理に向く。

Helicone と Portkey はゲートウェイとして間に入る。API のベースURLを差し替えるだけで記録が始まるので、既存コードをほとんど触らない。代わりに、アプリ内部のステップ構造は見えない。

単純な1回の呼び出しが中心ならゲートウェイ型が速い。検索・判断・ツール呼び出しが連なるエージェントなら、トレース型でないと原因を追えない。

いつ入れるか

本番に出す前である。多くのチームは問題が起きてから入れるが、そのときには過去のトレースが存在しない。「先週のあの誤答」を調べる手段がないまま、再現を試みることになる。

Langfuse の Hobby は月5万ユニット無料で、小規模な本番アプリなら賄える。予算の相談を待つ理由がない。

ユニットの数え方に注意する

Langfuse は1トレース・1観測（スパン、イベント、生成）・1スコアをそれぞれ1ユニットと数える。エージェントが1回動くと、ツール呼び出しの数だけ観測が増える。5ステップのエージェントなら1回の実行で6〜10ユニットになる計算で、月5万ユニットは5,000〜8,000回程度に相当する。

単純なチャットなら1回2〜3ユニットなので、同じ無料枠でも2万回近く使える。自分のアプリの形で見積もらないと、枠の大きさを読み違える。

プロンプト管理を分けるかどうか

プロンプトをコードから出して管理画面で変えられるようにすると、デプロイなしで調整できる。これは便利だが、変更履歴とバージョンの紐付けを同時にやらないと、「いつ何を変えたか分からないのに挙動が変わった」状態になる。

Langfuse と Portkey はプロンプト管理を内蔵している。使うなら、トレースにプロンプト版が記録されることを確認してから運用に乗せる。

よくある質問

Q. 既存の監視ツールでは駄目ですか。

A. レイテンシとエラー率は既存のもので取れます。足りないのは、プロンプト版・検索結果・トークン数といったLLM固有の情報です。Langfuse は OpenTelemetry に載るので、既存の観測基盤と併用できます。

Q. セルフホストすべきですか。

A. トレースにはユーザーの入力がそのまま含まれます。その内容を外部サービスに置けないなら、セルフホスト一択です。置けるなら、運用の手間を考えるとマネージドのほうが安く済みます。