Langfuse MonitorsでLLMアプリの異常を自動検知する

本記事でわかること

#

対象環境: 本記事の内容はLangfuse Cloud環境が対象です。セルフホスト環境では現時点でMonitors機能は利用できません。

• LLMアプリ運用における「見に行く監視」の限界と、能動的アラートで補う価値
• Langfuse Monitorsの仕組みと設定要素
• コスト急騰・品質劣化・レイテンシ悪化・トラフィック断を自動検知する実践的なユースケース
• データ欠損時の挙動（no-dataモード）の選び方など、運用で失敗しないための設計ポイント

対象読者

#

• LangfuseでLLMアプリの監視・評価を行っているエンジニア
• LLMアプリのコスト管理・品質管理に課題を感じているエンジニア
• Slack等への自動アラートを設定したい方

LLMアプリ運用の「気づけない問題」

#

LLMアプリを本番運用していると、「気づいたら困っていた」という問題が起きやすいです。

• コストが読めない: 月末になって初めてAPI利用料が想定を超えていたことに気づく
• 品質劣化が遅れる: プロンプト変更後のスコア低下を、誰かがダッシュボードを開くまで把握できない
• レイテンシの異常: レスポンスが遅くなっていても、ユーザーから報告が来るまで検知できない
• パイプライン断: バッチ処理が止まっていても、次の確認タイミングまで気づかない

Langfuseのダッシュボードは強力ですが、「見に行く（pull）」監視です。問題が起きていても、誰かがダッシュボードを開くまで誰も気づきません。

既存のAutomations機能も、「プロンプトのバージョンが公開された」「トレースがスコアされた」といったイベントにしか反応できませんでした。「直近1時間の平均コストが閾値を超えたら通知」という集計メトリクスへのアラートは、自前で実装するしかなかったのです。

なぜLLMアプリは「メトリクス監視」が必要なのか

#

従来のWebアプリ監視では、CPU使用率やHTTP 5xxエラー、レイテンシ監視が中心でした。しかしLLMアプリでは、それだけでは不十分です。

なぜなら「インフラは正常に動いているが、品質が落ちている」という状態が起こるためです。

例えば：

• モデル変更後にハルシネーションが増えた
• プロンプト変更で回答品質が低下した
• 入力コンテキストの肥大化でコストだけ急増した

これらはインフラ監視だけでは検知できません。LLMアプリでは「品質」「コスト」「推論速度」をアプリメトリクスとして監視する必要があります。

さらに、これらのメトリクスへのアラートは「ダッシュボードを見に行く」だけでは対応が遅れます。問題が顕在化してから気づくのではなく、閾値を超えた時点でチームに通知される体制が求められます。

Langfuse Monitorsとは

#

Langfuse Monitorsは、この課題に直接応えるメトリクスアラート機能です。

監視したいメトリクスと閾値を登録しておくと、Langfuseが定期的に自動評価し、閾値を超えたらSlack / Webhook / GitHub Dispatch（GitHub Actionsワークフローの起動）へアラートを送ります。

ここで誤解しないでほしいのは、Monitorsはダッシュボードの置き換えではないということです。Monitorsは「異常を検知して通知する」仕組みであり、原因の深掘りには引き続きDashboardsやTrace詳細を使います。つまり 「Monitorsで気づく → DashboardsやTrace詳細で原因を調べる」という使い分け が基本になります。「見に行く監視」に「知らせてくれる監視」を足すことで、LLMOpsの監視体制を一段階引き上げられます。

Monitorの設定要素

#

1つのMonitorは、次の4要素で構成されます。

1. 監視するメトリクス（クエリ）

#

2. アラート条件（Alert Conditions）

#

UIでは「Trigger when the value is [比較条件]」という形で、閾値の方向（above / below 等）と数値をまとめて設定します。アラートは2段階で設定できます。

比較条件は above / above or equal to / below / below or equal to / equal to / not equal to から選択します。

3. データ欠損時の挙動（no-dataモード）

#

評価窓にデータが存在しない場合の扱いを4モードから選べます（後述）。

4. 通知先（Channels）

#

通知は専用設定を持たず、既存のAutomation（通知チャネル）を利用します（Slack / Webhook / GitHub Dispatch）。最低1つのAutomationが必要なので、未設定の場合は次節「事前準備」で先に用意してください。

事前準備：Automationを設定する

#

Monitors の通知を受け取るには、事前に Automation（通知チャネル）を1つ以上設定しておく必要があります。設定は Settings → Automations から行います。

利用できる通知チャネルは3種類です。

本記事の実践例では Slack を使用します。設定方法はLangfuse公式ドキュメント（Webhooks / Slack Integrations） をご参照ください（ドキュメントはプロンプト更新通知を例にした記載ですが、Slack接続の手順自体は共通です）。

注意：Webhook ActionはSlack/Discord Incoming Webhookとは直接連携できません

LangfuseのWebhook Actionが送信するJSON形式は、Langfuse独自のフォーマット（{"type": "monitor-alert", "apiVersion": "v1", ...}）に固定されており、変更できません。SlackやDiscordの「Incoming Webhook URL」はそれぞれ独自のフォーマット（{"text": "..."} や {"content": "..."} など）を期待するため、Langfuseのペイロードを受け取ると400エラーを返します。

• Slackへの通知には、Webhook ActionではなくLangfuse専用の Slack Action（OAuth連携）を使ってください。色付きカード形式（ALERT=赤・WARNING=黄・OK=緑）で届きます。
• Discordへの通知には、Langfuseにネイティブ対応はありません。Webhook Actionで受け取った後、フォーマット変換プロキシ（Zapier・Make等）を経由してDiscordへ転送する構成が必要です。

なお、送信失敗が5回連続で続くとLangfuseは自動的にそのAutomationのTriggerを無効（Inactive）に切り替えます。Webhook AutomationがInactiveになっていた場合は、Settings → Automations で再度Activeに戻してください。

実践：コスト監視用のMonitorを設定する

#

LLMアプリで最も重要な監視の1つが、API利用コストの上限管理です。

例として「直近1時間のObservations合計コストが閾値を超えたらSlack通知」を設定します。

注意: 以下の手順はv3.185.0時点のUIを参考にしています。Monitorsは追加されたばかりの機能で公式ドキュメントは整備中のため、UIはバージョンによって変わる可能性があります。

1. 左ナビゲーションから「Monitors」を選択し、「New Monitor」ボタンをクリック
2. Metric Definition を設定する
   • View: Observations
   • Measure: Total Cost
   • Aggregation: Sum
3. Alert Conditions を設定する
   • “Trigger when the value is”: above or equal to
   • ALERT Threshold: 50（即時対応が必要なレベル / USD）
   • WARNING Threshold: 30（コスト上昇の兆候を早期検知 / USD）
   • Over the past: 1h
   • ※ 数値はあくまで例示です。実際の閾値は運用状況や規模に応じて設定してください
4. Advanced Options → “When there is no data” を「Treat missing data as 0」に設定する（コスト監視はこれが適切）
5. Notifications → Automations から作成済みのSlack連携にチェックを入れる
6. 「Save Monitor」をクリックして保存する

設定が完了すると、Monitorが定期的にメトリクスを評価し、閾値を超えた場合にSlackへ通知が届きます。

通知には over the last 1h のように集計窓が明示されるため、受け取った側も「いつの値が閾値を超えたか」をアラートだけで判断できます。カラーバー付きのSlack通知として届きます（ALERT=赤、WARNING=黄、OK=緑）。「View in Langfuse」ボタンから該当のMonitorページへ直接ジャンプできるのも便利です。

運用で失敗しないために：no-dataモードの選び方

#

実運用で意外と重要なのが、「メトリクスのデータが存在しない時間帯」の扱いです。

例えば深夜帯にトラフィックがゼロになった場合、集計値がnullになります。このnullをどう扱うかで、アラートの挙動が大きく変わります。

Langfuse Monitorsでは Advanced Options の「When there is no data」から以下の4モードを選択できます（デフォルトは「Treat missing data as 0」）。

アンチパターン：レイテンシ監視に「Treat missing data as 0」を使う

#

レイテンシ監視に「Treat missing data as 0」を設定すると、深夜帯にトラフィックがゼロになった際「レイテンシ0ms」と誤解釈されます。「0ms < 閾値500ms」という条件が成立してしまい、異常状態が「正常」と誤判定される可能性があります。

レイテンシ系のメトリクスでは、Treat missing data as 0 よりも Keep the previous SEVERITY のほうが無難です。「データがない時間帯は直前の状態を維持する」ことで、誤ったOK通知を抑制できます。

ただし Keep the previous SEVERITY も万能ではありません。直前の状態を保持するという性質上、たとえば夜間にトラフィックが完全に止まるアプリで、停止直前が ALERT だった場合、データが来ない夜間ずっと ALERT が維持され、翌朝トラフィックが戻るまで状態が更新されない、ということが起こり得ます。

トラフィックが恒常的に流れ続けるアプリなら Keep the previous SEVERITY で問題になりにくいですが、夜間にゼロになるような運用では、欠損時間帯を Show severity NO DATA（無通知で可視化）として扱い、状態を据え置きにしない選択肢も検討してください。どのモードが適切かは「そのアプリでデータが来ない時間帯が正常か異常か」で判断するのが基本です。

活用シーン：こんな監視に使える

#

① コスト急騰の早期検知

#

LLMのAPIコストは、入力・出力トークン数とモデル単価をベースに決まります。ただし、エージェント型アプリケーションでは、複数回のLLM呼び出し、ツール呼び出し、リトライ、コンテキスト肥大化が重なり、リクエスト数だけではコスト増加を把握しにくくなります。Langfuse Monitorsでは、Total Cost や Total Tokens に閾値を張ることで、想定外のコスト増加を検知できます。

Claude/GPT等のAPIコストは使い始めると予測が難しく、月末になって初めて超過に気づきがちです。時間単位（1h〜24h）の集計を監視しておけば、請求書サプライズを未然に防ぎやすくなります。

• View: Observations、Measure: Total Cost、Aggregation: Sum、Over the past: 1h or 24h
• no-dataモード: Treat missing data as 0（トラフィックゼロ＝コストゼロ）

② 品質スコアの劣化検知

#

プロンプト変更・モデル切り替え後、LLM-as-a-judge（LLMを評価者として使い、各トレースに品質スコアを自動付与する手法）で付けた評価スコアが下がっていないか自動で監視できます。

• View: Scores（数値型）、Measure: Value、Aggregation: Avg、Filters: 監視したいスコア名（評価器名）を指定、Over the past: 1h
• “Trigger when the value is”: below、WARNING: 0.7、ALERT: 0.5
• no-dataモード: Keep the previous SEVERITY（評価が少ない時間帯で状態をバタつかせない）
• ※ スコア名は各プロジェクトで設定した評価器の名前に合わせてください

③ レイテンシ悪化の検知

#

本番APIのレイテンシが急増したときに即座に検知できます。平均値ではなくパーセンタイル値（P95など）を使うことで、「一部のリクエストだけが極端に遅いケース」を見落とさずに検知しやすくなります。

• View: Observations、Measure: Latency、Aggregation: P95、Over the past: 30m
• “Trigger when the value is”: above、ALERT: 5000（5秒超を異常と定義する場合）
• no-dataモード: Keep the previous SEVERITY（ただし夜間トラフィックが止まるアプリでは状態が据え置かれる点に注意。前述の「アンチパターン」節を参照）

④ パイプライン断の検知

#

夜間バッチの要約生成・Embedding生成・評価ジョブなど、定期実行のLLMパイプラインが止まっていないか確認できます。「Treat missing data as 0」を使うことで、「Observationsが1件も来ない＝0件」を正しくALERTとして検知できます。

• View: Observations、Measure: Count、Over the past: 30m
• “Trigger when the value is”: below、ALERT: 1（件数が1未満）
• no-dataモード: Treat missing data as 0（データなし＝0件として判定）

設計ノウハウ：アラートを「使える状態」に保つ

#

まずは「絶対に見逃したくない」指標から始める

アラートは多ければ良いわけではありません。1日に何十件も通知が来る状態では、やがて誰も見なくなります（アラート疲れ）。まずコスト・品質・パイプライン断など「絶対に見逃したくない」指標だけから始め、運用しながら閾値を調整していくのが現実的です。

2段階閾値を活用する

WARNING（注意）とALERT（即時対応）を分けることで、通知疲れを防げます。WARNINGは情報チャンネルへ、ALERTはオンコール対応チャンネルへ振り分けるのも有効です。

評価窓の選び方

窓が短すぎると瞬間的なスパイクで誤検知が増え、長すぎると問題の発見が遅れます。コスト監視なら 1h〜24h、レイテンシ監視なら 5m〜30m を起点に調整してください。

再通知（Renotify）の設定

アラート状態が解消されない間、定期的に再通知する設定も用意されています。OFF（再通知しない）または指定間隔（最長1週間まで設定可能）での繰り返し通知から選択できます。オンコール対応中に「まだ解消されていない」ことを能動的に把握したい場合に有効です。

通知は「重大度が変化したとき」にのみ発火する

Monitors の通知は評価のたびに毎回送られるわけではなく、重大度（Severity）が変化したタイミングにのみ発火します。 主な遷移と通知の関係は以下の通りです。

「ALERTになったはずなのに通知が来ない」場合は、すでに同じ重大度のまま継続しているだけで追加の通知は発火しません。逆に、閾値を下回って回復したときはOK（緑）の通知が届くため、「問題が解消された」ことも自動で把握できます。

設定直後に通知が来なくても正常な場合がある

Monitorはトレース1件ごとに反応するPush型ではなく、定期ポーリング型です（最短1分間隔）。トレースを送信してもその瞬間にアラートは飛ばず、次の評価タイミングまで待つ必要があります。また、Monitor作成後の初回評価でメトリクスが閾値内に収まっていた場合も通知は発火しません（「初期状態 → 正常」への遷移は通知しない仕様）。「作成したのに通知が来ない」と感じた場合は、Monitor一覧のSeverity列が ALERT または WARNING に変化しているかを確認するのが最初の切り分けになります。

Monitorを有効にする前にライブプレビューで確認する

Monitorエディタのライブプレビューでは、設定した評価窓で実際のデータがどう見えるかを確認できます（前掲のMonitor設定画面スクリーンショット右側がライブプレビューです）。「閾値が常に超過している」「データが全く来ない」状態に気づかずに保存してしまうと、通知が来ても誰も対応しなくなります。保存前にプレビューで動作を確認しましょう。

「通知が突然来なくなった」場合はAutomationの状態を確認する

Monitorの設定は正常でも、通知先のAutomationが自動的に無効化されているケースがあります。Slack連携やWebhookへの送信が5回連続で失敗すると、Langfuseは自動的にそのAutomationのTriggerを INACTIVE（無効）に切り替えます。一度INACTIVEになると、Monitor側がALERTになっても通知は届きません。

「通知が来なくなった」と気づいたら、まず Settings → Automations でTriggerのステータスを確認してください。INACTIVEになっていた場合は再度ACTIVEに戻すことで通知が再開されます。あわせてSlack連携のOAuth認証やWebhookエンドポイントの疎通も確認しておくと、同じ失敗が繰り返されるのを防げます。

前提：Monitorsが効くのは「計測の土台」があってこそ

#

ここまで読むと「Monitorsを設定すれば監視できる」ように見えますが、実際にはその手前の設計が効果を大きく左右します。Monitorsはあくまで「集計済みメトリクスに閾値を張る」機能なので、そもそも切り分けに使える形でデータが入っていることが前提になります。

具体的には、次の3つが揃っていないと、「コストが上がった」「品質が落ちた」をチーム・機能・環境ごとに切り分けて検知できません。

つまりMonitorsは、Trace・Metadata・Evaluatorという計測の土台があって初めて「切り分けて気づける監視」になるということです。これから監視を整えるなら、Monitorの設定よりも先に「監視したい単位（環境・機能・チーム）でフィルタできるよう、トレースにメタデータが付いているか」を確認しておくと、後から監視を細分化しやすくなります。

自動アラートはあくまで補助

#

監視の自動化はインシデントの検知を早めますが、「何を監視すべきか」の定義や閾値の妥当性確認は人間が担う必要があります。「アラートが鳴り続けているが誰も対応しない」状態は、監視がないよりも運用を硬直させる場合があります。定期的に閾値を見直し、アラートが適切に対応されているかをチームで確認する仕組みを合わせて整えることをお勧めします。

提供範囲

#

本記事執筆時点（2026年6月）では、Monitorsは Langfuse Cloud 限定で、UI上は Beta 表記のまま提供されています。仕様や挙動は今後変わる可能性があるため、最新の状態は公式ドキュメントとUI上の表記をご確認ください。なお、セルフホスト環境ではまだ利用できません。Langfuse Town Hall（2026年6月）にて「セルフホストへの提供を予定」とアナウンスされていますが、正確な提供時期は公式情報をご確認ください。

まとめ

#

Langfuse MonitorsはLLMアプリの監視に「問題が起きたら知らせてくれる」一段を追加する機能です。ダッシュボードを置き換えるものではなく、Monitorsで異常に気づき、DashboardsやTrace詳細で原因を調べるという使い分けになります。

• コスト・レイテンシ・品質スコア・トレース件数などのメトリクスに閾値を設定し、Slack等へ自動アラートを受け取れる
• WARNING/ALERTの2段階閾値で、通知の重要度を使い分けられる
• no-dataモードの選択で、夜間トラフィックゼロなどの欠損パターンを扱える（ただし「直前状態の据え置き」には注意）
• チーム・機能・環境別に切り分けて検知するには、Trace・Metadata・Evaluatorという計測の土台が前提になる
• 現在はLangfuse Cloud限定で、UI上は Beta 表記。セルフホストへの提供も予定と案内（時期は公式情報を確認）

LLMアプリを本番運用しているチームであれば、まずコスト監視から試してみることをお勧めします。「月末になって初めて気づく」から「閾値に近づいたら教えてくれる」へ移行するだけでも、十分な価値があるはずです。

参考リンク

#

• Monitors機能のTown Hall動画（@39:11〜）
• Monitors機能の要望 Discussion #3997