Signals
ここまで、online evalsの必要性、Weaveで使えるモニタリング機能、そしてcontinuous evaluationの考え方を見てきました。
一方で、実際に本番モニタリングを始めようとすると、最初に別の課題が出てきます。何をモニタリングすればよいのかが分からない、という課題です。
レイテンシ、トークン数、コストのようなシステム指標は重要です。しかし、それだけではAI Agentの振る舞いは十分に分かりません。Agentが根拠を失っているのか、ユーザーが苛立っているのか、ツール呼び出しに失敗しているのか、単に回答品質が低いのか。こうした振る舞いを、毎回人がTraceを開いて確認するのは現実的ではありません。
このニーズに応えるために、W&Bではbuilt-in Signalsを開発しています。
補足: 今後の開発方針
2026年5月時点で、SignalsはPrivate Previewの機能です。マルチテナントSaaSの一部のお客様に限定して提供されており、機能、価格・パッケージ、UXはフィードバックに応じて変わる可能性があります。
Signalsとは
Signalsは、本番環境のTraceに対して、あらかじめ用意されたScorerを使って自動的に分類を行う仕組みです。開発者が最初から完璧なScorerやmonitoring promptを作らなくても、よくある品質問題やエラーを検出し、Traceにタグとして残せるようにすることを目指しています。
Signalsは、W&B Inference modelを使ってTraceを評価します。そのため、外部LLM APIキーを別途用意しなくても利用できる設計です。判定結果はCall objectのFeedbackとして保存され、Traces tabで検索・フィルタできるようになります。
Signalsは、大量のproduction traceを自動的に処理することを前提にしたmonitoring機能です。個別Traceを人が読む深いデバッグと、本番全体の傾向を広く見るmonitoringの間を埋める役割を担います。
この考え方は、最初から評価体系を完璧に作れない現実へのアプローチです。まずはbuilt-inのSignalでざっくり問題の兆候を拾い、そこから重要な失敗モードを見つけ、必要に応じてcustom monitorやoffline evalsへ発展させていきます。
Quality signalsとError signals
Signalsには、大きくQuality signalsとError signalsがあります。
Quality signalsは、成功したroot-level traceを対象に、出力品質や安全性に関する問題を検出します。Error signalsは、失敗したtraceを対象に、失敗の原因を分類します。
| グループ | 目的 | 例 |
|---|---|---|
| Quality signals | 成功したTraceの品質や安全性の問題を見る | Hallucination、Low quality、User frustration、Jailbreaking |
| Error signals | 失敗したTraceの根本原因を見る | Rate limited、Timeout、Network error、Tool error、Parsing / validation |
Quality signalsでは、たとえば次のような観点を扱います。
| Signal | 検出するもの |
|---|---|
| Hallucination | 入力コンテキストと矛盾する作り話や根拠のない主張 |
| Low quality | 形式が悪い、努力不足、不完全な回答 |
| User frustration | 繰り返し質問、否定的な感情、不満の兆候 |
| Jailbreaking | safety guidelineを回避しようとするprompt injectionやjailbreak |
Error signalsでは、たとえば次のような観点を扱います。
| Signal | 検出するもの |
|---|---|
| Rate limited | upstream serviceやmodel providerによるrate limit |
| Timeout | timeoutによる失敗 |
| Network error | connection resetなどの一時的なネットワーク問題 |
| Auth error | 認証や権限の問題 |
| Bad request | 入力やrequest formatの問題 |
| Server error | upstream server error |
| Tool error | tool callやtool executionの失敗 |
| Parsing / validation | structured outputのparseやvalidationの失敗 |
| Unknown error | 既存カテゴリに当てはまらない失敗 |
Signalsを有効化する流れ
Signalsは、Monitors pageから有効化する想定です。
- 1Weave projectを開きます。
- 2サイドバーからMonitorsを選びます。
- 3Monitors page上部に表示されるsuggested signal cardsを確認します。
- 41つだけ有効化する場合は、対象カードの
+ Add signalを選びます。 - 5複数まとめて有効化する場合は、signals drawerから必要なSignalsを選びます。
- 6有効化後、Weaveは新しく入ってくるTraceを評価し、結果をCall objectのFeedbackとして保存します。
activeなSignalは、Manage signalsから確認・削除できます。Signalを削除すると、新しいTraceへのスコアリングは止まりますが、既存のスコアは残ります。
Signalsの見方
Signalsが有効になると、Traces tableのSignals columnにタグが表示されます。タグにhoverすると、confidence scoreやreasoningを確認できます。Trace tableのfilterを使えば、特定のSignalが発火したTraceだけを表示できます。
また、Signalsが生成するclassifier Callを開くと、Trace Detailsでより詳しい判定理由を確認できます。たとえば、Low qualityが高いconfidenceで検出された場合、その判定理由をclassifier_metaのような出力から確認できます。
project dashboardでもSignalsを見られるようにする構想があります。Monitor Scoresのようなdashboard panelで、Signalsの発生傾向を時系列で確認できるようになると、個別Traceの深掘りだけでなく、プロジェクト全体の品質変化を追いやすくなります。
Signalsから改善につなげる
Signalsは、それ自体が最終的な評価体系になるわけではありません。むしろ、最初の観測を始めるための入口です。
たとえば、User frustrationが増えているなら、ユーザーが不満を感じている会話を集め、人手評価やAnnotation Queueに回します。Hallucinationが増えているなら、そのTraceをDatasetに追加し、GroundednessやReference alignmentのoffline evalsを強化します。Tool errorやParsing / validationが増えているなら、Agentのtool designやstructured outputの設計を見直します。
Signalsで見つけた問題は、次のように改善ループへ戻します。
| Signalsで見つかるもの | 次のアクション |
|---|---|
| Hallucination | TraceをDatasetに追加し、groundedness評価を強化する |
| User frustration | 人手評価で不満の理由を分類する |
| Low quality | 出力形式やrubricを見直す |
| Tool error | tool schema、引数、error handlingを確認する |
| Parsing / validation | structured outputとvalidatorを改善する |
| Rate limited / Timeout | provider設定、retry、fallbackを見直す |
このように、Signalsは「何が起きていそうか」を広く拾うための機能です。そこから重要な失敗モードを見つけ、custom monitor、offline evals、Annotation、Coding Agentによる改善へつなげていくことが重要です。
まとめ
online monitoringを始めるとき、最初から何を見ればよいかを決めるのは難しいです。Signalsは、その難しさに対するWeaveのアプローチです。
レイテンシやコストのようなシステム指標だけでなく、Hallucination、Low quality、User frustration、Tool errorのようなAgentの振る舞いに近いSignalを自動的に拾うことで、本番で起きている問題の入口を作れます。
2026年5月時点ではPrivate Previewですが、こうしたbuilt-in monitoringの方向性は、今後のAI Agent運用で重要になるはずです。最初から完璧な評価体系を作るのではなく、Signalsで兆候を拾い、TraceをDatasetに戻し、offline evalsと改善に接続していきましょう。