---
title: "Langfuseの異常だけをSlackに流す朝ブリーフィングを作りたい"
description: "Traceを毎日見に行く運用は続かない。Langfuseの失敗、トークン急増、低評価出力だけをSlackへ集約する個人GenAIOpsの構想メモ。"
lang: "ja"
canonical: "https://llm-lab.dev/posts/langfuse-morning-briefing/"
source: "https://llm-lab.dev/posts/langfuse-morning-briefing.md"
publishedAt: "2026-06-06"
updatedAt: "2026-06-06"
category: "AgentOps"
tags:
  - "agentops"
  - "slack"
  - "genaiops"
  - "langfuse"
---

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

> [!NOTE]
> この記事で確認したこと: この記事はLangfuse朝ブリーフィングの実装完了レポートではなく、構想段階の設計メモです。定期実行でtraceメタデータを取得し、見るべき異常だけを抽出し、Slackへ安全な構造化メタデータとして要約する方針を先に決め、自動修正やIssue化は通知ループが役に立つと分かってから進める設計にしています。

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

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

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

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

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

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


## 何がつらいのか

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

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

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

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

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

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

## 作りたいもの

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

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

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

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

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

![Slack通知のイメージモックアップ](/images/posts/langfuse-morning-briefing/slack_mockup.svg)

```text
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/...
```

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

## 全体構成

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

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

![Langfuse朝ブリーフィングの全体構成図](/images/posts/langfuse-morning-briefing/architecture_diagram.svg)

最初から複雑な監視基盤にしません。やりたいことは、アラート基盤の完成ではなく、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 を使っていたら、少し見た方がいい。

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

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

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

## LLM に要約させる範囲

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

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

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

```json
{
  "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 の朝ブリーフィングはちょうどいいのでは、と思っています。

## 検証したい観点

- 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 で通知量を確認する

これらの観点を実際に検証し、Cloudflare Workersで実装したプロセスは、実践編「[Langfuse朝ブリーフィングを実装して試す：異常traceだけをSlackに流せるか](/posts/langfuse-morning-briefing-trial/)」にまとめています。