Langfuseの異常だけをSlackに流す朝ブリーフィングを作りたい

Langfuse、便利なんですが、毎日ちゃんと見るのは普通に無理です。

Trace は溜まります。Token も増えます。たまに変な出力も出ます。ダッシュボードを開けば分かるんですが、本業や個人開発を並行していると、「毎朝 Langfuse を巡回する」みたいな丁寧な運用はだいたい破綻します。

でも、全部を見たいわけではないんですよね。

知りたいのは、昨日どの Agent が失敗したのか、どこで token が跳ねたのか、cost が妙に増えていないか、評価が低い出力がなかったか。このあたりだけです。

ということで、Langfuse の trace を集計して、見るべき異常だけを Slack に朝ブリーフィングとして流す仕組みを作ってみたい、という話です。

この記事は、まだ実装完了レポートではありません。現時点では、作りたい構成、見るべき指標、実装の分割、検証 TODO を整理する構想メモです。

何がつらいのか

LLM アプリや Agent を触っていると、観測したいものはすぐ増えます。

• エラーになった trace
• やたら token を使った実行
• latency が高い実行
• cost が急に増えた実行
• 評価 score が低い出力
• 想定外の tool call
• ユーザーには返せない雑な出力

Langfuse は、こうした挙動を後から追える場所としてかなり便利です。

ただし、観測基盤は「見に行かないと気づけない」状態になると弱いです。ダッシュボードを開けば分かる。でも、開かない。開かないので、事故った後に気づく。嫌なことを言いますが、個人開発だとこのパターンになりがちです。

本当に欲しいのは、毎日すべての trace を見ることではありません。

昨日の実行のうち、今日見るべきものだけがまとまっている状態です。

作りたいもの

作りたいのは、Langfuse の朝ブリーフィングです。

毎朝 1 回、Slack に次のような内容を流します。

• 昨日の実行サマリー
• 失敗した trace
• token または cost が急増した実行
• latency が高かった実行
• score が低かった出力
• 優先して見るべき trace URL
• 原因として疑うべきポイント

全部を通知すると、すぐ通知疲れします。なので、平常時は短く、異常時だけ濃くする方針にします。

たとえば Slack には、次のような通知を出したいです。

Langfuse Morning Briefing

昨日の実行:
- traces: 128
- errors: 3
- total tokens: 412,000
- estimated cost: $2.31

見るべき異常:
1. hermes-pricing-agent で error trace が 2 件
2. blog-draft-agent の token が前日比 +82%
3. support-rag の score 低下 trace が 1 件

まず見る:
- https://cloud.langfuse.com/project/...

これくらいなら、朝に眺められます。

全体構成

最小構成はかなり単純です。

Langfuse
  ↓
定期実行する Worker / Cron
  ↓
trace と metrics を取得
  ↓
閾値で異常候補を抽出
  ↓
LLM で短く要約
  ↓
Slack Incoming Webhook へ投稿

最初から複雑な監視基盤にしません。やりたいことは、アラート基盤の完成ではなく、Langfuse を毎日見に行かなくても異常に気づける導線を作ることです。

実装場所は、Cloudflare Workers の Cron Triggers が扱いやすそうです。ブログや個人ツールを Cloudflare 側に寄せているなら、運用面でも揃えやすいです。

ただし、ここはまだ要検証です。Langfuse API の取得範囲、認証、rate limit、trace URL の組み立て方を確認してから決めます。

どの指標を見るか

最初に見る指標は、あまり増やしません。

指標	見たいこと
error count	失敗した実行が増えていないか
total tokens	token が急増していないか
estimated cost	cost が想定を超えていないか
latency	異常に遅い実行がないか
score	評価が低い出力がないか
model	想定外の model を使っていないか
agent / prompt name	どの処理で異常が出たか

ポイントは、絶対値と前日比を両方見ることです。

たとえば total tokens が 100,000 でも、それが平常運転なら慌てる必要はありません。一方で、普段 10,000 token 程度の Agent が急に 80,000 token を使っていたら、少し見た方がいい。

なので、最初の抽出条件は次のような形にします。

- error がある trace
- total tokens が前日比 50% 以上増えている agent
- estimated cost がしきい値を超えた実行
- latency が p95 を大きく超えた実行
- score が指定値を下回った trace

このあたりは、最初から正解を決めるより、数日流して調整する方が現実的です。

LLM に要約させる範囲

Slack に投げる文章は、LLM に要約させたいです。

ただし、trace の全文を雑に突っ込むのは危ないです。token cost も増えますし、機密情報や個人情報が含まれる可能性もあります。

要約に渡すのは、まず構造化したメタデータに限定します。

{
  "date": "2026-06-13",
  "totalTraces": 128,
  "errorTraces": [
    {
      "name": "hermes-pricing-agent",
      "traceUrl": "https://...",
      "errorType": "tool_error",
      "latencyMs": 12400
    }
  ],
  "costAnomalies": [
    {
      "name": "blog-draft-agent",
      "costDeltaRate": 0.82,
      "tokens": 98000
    }
  ]
}

この情報から、「今日見るべきもの」を短くまとめさせる。

本文や prompt / completion の中身まで要約させるのは、次の段階でいいです。まずは、異常を見つける導線を作る方が先です。

どこまで自動化するか

最初のスコープでは、自動修正まではやりません。

理由は単純で、観測と修正を同時に作ると、どこで失敗しているか分かりにくくなるからです。

最初は、Slack に「見るべき trace」を流すだけで十分です。これで運用が回るなら、次に原因仮説の生成、自動 issue 化、特定パターンの自動再実行へ進める。

順番としては、次のように分けたいです。

1. 異常 trace を Slack に流す
2. 異常の理由を LLM に要約させる
3. GitHub Issue や Notion に調査タスクを作る
4. 一部の失敗だけ自動再実行する
5. 修正提案まで Agent に作らせる

いきなり 5 まで行くと、たぶん壊れます。荒削りでもいいので、まずは毎朝見る通知を作るところからです。

この仕組みで変えたいこと

この仕組みで変えたいのは、Langfuse の使い方です。

今は、何か問題が起きたときに Langfuse を見に行くことが多いです。これはこれで便利ですが、問題が起きた後の調査に寄っています。

朝ブリーフィングを作ると、使い方が少し変わります。

• 毎日ダッシュボードを開かなくてよくなる
• 異常がある日だけ trace を掘ればよくなる
• cost 事故に早く気づける
• score の低い出力を放置しにくくなる
• Agent ごとの運用状態を軽く眺められる

個人開発でも、LLM アプリを育てるなら観測は必要です。

ただし、観測に時間を取られすぎると続きません。だから、ダッシュボードを毎日見に行くのではなく、異常だけが生活の導線に入ってくる形にしたい。

その入口として、Slack の朝ブリーフィングはちょうどいいのでは、と思っています。

要検証 TODO

• Langfuse API で、対象日の trace、generation、score、cost、latency をどの粒度で取得できるか確認する
• Cloudflare Workers Cron Triggers から Langfuse API を呼び出せるか確認する
• Langfuse の trace URL を API レスポンスから安定して組み立てられるか確認する
• 前日比を計算するための保存先を決める。Workers KV、D1、ローカル集計のどれがよいか検証する
• Slack Incoming Webhook の通知フォーマットを決める
• LLM 要約に渡してよいメタデータ範囲を決める。prompt / completion 本文を渡すかは別途判断する
• error、cost、token、latency、score の初期しきい値を仮決めし、数日分の trace で通知量を確認する

※ これらのTODOを実際に検証し、Cloudflare Workersで実装したプロセスは、実践編「Langfuse朝ブリーフィングを実装して試す：異常traceだけをSlackに流せるか」にまとめています。