Skip to main content
Failproof AI Observability は、完了したすべてのエージェント実行を自動的に品質スコアリングできます。小さなスコアリングサービスを用意するだけで、あとは Observability が処理します。追跡したい指標(有用性、ツール効率、事実性、安全性など、選択は自由)を管理し、品質低下を早期に検知し、エージェントや環境を一目で比較できます。スコアリングはオプトイン式です。サーバーに EVALUATOR_ENDPOINT を設定するまでパイプラインは何もしません。
注意: スコアの次元はご自身が定義します。評価器はお好きな数値キーを返せます。Observability は送り返された内容をそのまま保存・トレンド表示・ダッシュボード表示します。

概要

  1. スコアラーを作成する。 セッションのトランスクリプトを読み込んでスコアを返す小さな HTTP サービスを立ち上げます。Observability には動作するリファレンス実装が含まれているのでコピーして使えます。SDK を使った評価器の作成 を参照してください。
  2. Observability にエンドポイントを設定する。 サーバープロセスに EVALUATOR_ENDPOINT(および共有の EVALUATOR_TOKEN)を設定します。
  3. スコアを確認する。 完了したセッションはすべて自動的にスコアリングされ、セッション詳細ページ・セッション一覧グリッド・保存済みダッシュボードに結果が表示されます。
評価サマリー、次元別スコアバー、右ペインの推論テキストを含むセッション詳細ビュー 評価器を設定すると、完了した各実行がスコアリングされ、結果がセッションの右ペインに表示されます。上部にサマリー、続いて各次元のスコアバーと推論テキストが表示されます。

仕組み

Observability SDK がセッションの agent_end イベントを送出すると、サーバーは評価をスケジュールします。次に、完全なイベントトランスクリプトを評価器サービスに POST します。評価器は次のどちらかを行えます。
  • インラインで結果を返す: {"status":"done", "scores":{...}, "reasoning":{...}, "summary":"..."} を返します。結果はセッションの評価タイムラインに追記されます。reasoningsummary はオプションです。
  • 処理を遅延させる: {"status":"pending", "job_id":"abc-123"} を返します。Observability は評価器が {"status":"done", ...} または {"status":"error", "error":"..."} を返すまで GET {EVALUATOR_ENDPOINT}/evaluate/abc-123 をポーリングします。 ポーリング間隔はジョブごとに設定できます。pending レスポンスに next_poll_secs を含めると間隔を上書きできます。省略した場合、Observability は GET /configdefault_poll_interval_secs を使用し、それもなければ EVALUATOR_POLLING_INTERVAL_SECS(デフォルト 10 秒)にフォールバックします。すべての値は [1 秒、1 時間] にクランプされます。
agent_end を送出しないセッション(クラッシュしたエージェントプロセスなど)もピックアップできます。評価器の GET /config{"inactivity_timeout_secs": 1800} を返すと、Observability はその時間アイドル状態になったセッションを評価します。このフォールバックを無効にするには、フィールドを null に設定するか省略してください。 EVALUATOR_ENDPOINT が未設定の場合、パイプラインは完全に no-op になります。 セッションは時間の経過とともに複数の終端評価を蓄積できます。各 agent_end イベント(およびダッシュボードからの手動再評価)ごとに新しい評価行が追記されます。これは再開された会話を評価するサポート方式です。ユーザーがエージェントを終了し、後で戻ってさらにイベントを送信し、再度エージェントを終了すると、更新された完全なトランスクリプトに対して2回目の評価が実行されます。ダッシュボードは最新の評価をヘッドラインとして表示し、以前の評価は折りたたみ可能なタイムラインとして表示します。あるセッションに対して評価が実行中の間、そのセッションの追加 agent_end イベントは無視されます。実行中の評価が完了した後の次のイベントで、通常どおり新しい評価がエンキューされます。 アイドル状態フォールバックは再開されたセッションでも再び動作します。以前の終端評価後に新しいイベントが届き、その後セッションが inactivity_timeout_secs を超えてアイドル状態になった場合、新しい評価がエンキューされます。 一時的な障害(5xx、429、タイムアウト、ネットワークエラー)は EVALUATOR_MAX_ATTEMPTS に達するまで指数バックオフで再試行されます。4xx レスポンスは終端扱いです。Observability は水平スケールされた複数のサーバーインスタンスで安全に実行できます。同じセッションが同時に2回ディスパッチされないようにワークが分割されます。

HTTP コントラクト

認証が必要なすべてのルートはベアラートークン認証を使用します。両側で同じ値を設定する必要があります。
  • Observability サーバー: 環境変数 EVALUATOR_TOKEN
  • 評価器サービス: 同じ方法で設定(agenteye-evaluator SDK は慣例として EVALUATOR_TOKEN を読み込みます)
EVALUATOR_TOKEN が未設定の場合、サーバーは Authorization ヘッダーを送信しません。評価器は匿名リクエストを受け付けることができますが、内部ネットワーク専用であれば問題ありませんが、公開インターネット上では非推奨です。

評価器が提供するルート

サーバーが送信する EvalRequest ボディ

レスポンス形式

同期(done):
reasoning(スコアごとの根拠マップ)と summary(全体の概要段落)はどちらもオプションです。reasoning のキーは scores のキーと一致させてください。ダッシュボードは各エントリをスコアバーの下にインライン表示します。scores のみを返す旧来の評価器もそのまま動作します。reasoningsummary は null として扱われ、対応する UI 要素は省略されます。 非同期(遅延):
next_poll_secs はオプションです。省略した場合、サーバーは /configdefault_poll_interval_secs、次に独自の EVALUATOR_POLLING_INTERVAL_SECS 環境変数にフォールバックします。 評価器側の終端エラー:
サーバーはその他の 2xx ボディをプロトコルエラーとして扱い、セッションに終端 error を記録します。

SDK を使った評価器の作成

HTTP コントラクトを手動で実装する必要はありません。agenteye-evaluator Python パッケージは、認証・ルーティング・リクエスト/レスポンス形式を処理する型付き FastAPI ラッパーを提供します。 Failproof AI Observability には、トランスクリプトの形状から helpfulnesstool_efficiencyfactuality をスコアリングする動作するリファレンス評価器も含まれています。出発点としてコピーし、独自のロジック(LLM ジャッジ、ルールエンジンなど、品質基準に合ったもの)に置き換えてください。 最小限の評価器:
app インスタンスはあらゆる ASGI サーバーで動作するため、uvicorn module:app で起動できます。 重い処理を遅延させる必要がある評価器では、代わりに JobPending を返し、@app.job_lookup ハンドラーを登録してください。Observability サーバーは評価器が終端ステータスを返すか、EVALUATOR_MAX_POLL_DURATION_SECS の上限(デフォルト 1 時間)に達するまで GET /evaluate/{job_id} をポーリングします。 完全な API リファレンス、非同期パターン、イベントスキーマは agenteye-evaluator SDK の README に記載されています。

評価器の実行

評価器はご自身のサービスです。Failproof AI Observability はデフォルトの評価器を提供しないため、ご自身のサービスを実行している場所でビルドして実行してください。任意の ASGI サーバー(例: uvicorn my_evaluator:app)で動作します。HTTP コントラクト/health/config/evaluate ルートを提供し、サーバーからアクセスできるように設定してください(サーバーの設定 を参照)。 評価器に到達できるようになると、GET /health{"status":"ok"} を返します。エージェントがエンドツーエンドで実行された後、サーバーの GET /evaluationsstatus: "done" と評価器が生成したスコアを含む行を返します。

サーバーの設定

サーバープロセスに設定する環境変数: 自動スコアリングを有効にするには、サーバーに EVALUATOR_ENDPOINTEVALUATOR_TOKEN の両方を設定し、サーバーを再起動して変更を反映させてください。EVALUATOR_ENDPOINT が未設定の場合、パイプラインは no-op のままです。 上記のチューニングパラメータはオプションです。デフォルト値を変更する必要がある場合のみ、対応する環境変数をサーバーに設定してください。

API リファレンス

スコア範囲でのフィルタリング: score_filters

GET /evaluations はオプションの score_filters パラメータを受け付けます。これにより scores オブジェクト内の数値で結果を絞り込めます。パラメータは key:min..max エントリのカンマ区切りリストです。どちらの境界も省略できます。複数のエントリは論理 AND で結合されます。指定したキーが存在しない行や非数値の行は除外されます。リクエストには最大 20 のフィルターエントリを含められます。超過した場合は HTTP 400 が返されます。 例:
/evaluations レスポンスオブジェクトには以下のフィールドが含まれます:

権限

ブートストラップ管理者(ADMIN_KEYADMIN_EMAIL)はこれらすべてを自動的に受け取ります。

結果の閲覧

  • /sessions/<id>: イベントタイムラインと、セッションのスコアおよびディスパッチ試行からのエラーを表示する右ペイン。キーに evaluations:trigger 権限がある場合、エクスポートボタンの横に再評価ボタンが表示されます。agent_end を送出しなかったセッションや、新しい評価器をデプロイした後にスコアを更新する際に便利です。ダッシュボードは新しい結果をポーリングし、届いた時点で右ペインを更新します。
  • /sessions: フィルタリング可能なセッション一覧グリッド。スコア列で各セッションの評価ステータスとスコアを一目で確認できます。
  • /dashboards: 保存済みの評価ヘルスビュー(以下のダッシュボードを参照)。
セッションごとの評価ステータスバッジとカラーコードのスコアバッジ(helpfulness、factuality、tool_efficiency、safety、coherence)が表示されたセッション一覧グリッド セッション一覧グリッドでは各実行の評価ステータスとスコアを一目で確認できます。赤/黄/緑のバッジで低スコアをすぐに発見できます。

ダッシュボード

ダッシュボードページ(/dashboards)では、評価フィルターの組み合わせを名前付きの再利用可能なビューとして保存し、そのスライスの評価状態を一目で確認できます。ダッシュボードは組織全体で共有されますdashboards:read 権限を持つ全員が同じセットを閲覧できます。 各ダッシュボードが保持する内容:
  • フィルター: セッションページと同じコントロール(環境、ステータス、エージェント、ローリング時間ウィンドウ、スコア範囲フィルター(key:min..max))。
  • 表示設定: 表示するスコアキー、緑/黄/赤のヘルスしきい値、表示するパネル、セッションごとに最新の評価に折りたたむかどうか。
各カードにはマッチするセッション数、done/error/timeout の内訳、各注目スコアの平均、小さなトレンドスパークラインが表示されます。ダッシュボードを開くとフルサイズのパネルが表示されます。セッションで開くをクリックすると、そのスライスに絞り込まれた状態でセッションページが開きます。メトリクスはサーバーサイドでマッチするセット全体にわたって計算されます(GET /evaluations/aggregate 経由)。そのため数値はサンプリングではなく正確です。 評価器の次元ごとの平均スコアバー、ツールの成功/エラー内訳、上位ツール、1 時間あたりのイベント数トレンドを含む評価ヘルスダッシュボード 権限: 閲覧には dashboards:readevaluations:read の両方が必要です。作成と編集には dashboards:write、削除には dashboards:delete が必要です。ブートストラップ管理者はこれらすべてを自動的に受け取ります。

トラブルシューティング

セッションは存在するが評価が作成されない。 サーバープロセスに EVALUATOR_ENDPOINT が設定されていること、サーバーと評価器が同じ EVALUATOR_TOKEN の値を共有していること、評価器の /health エンドポイントがサーバーから到達可能であることを確認してください。EVALUATOR_ENDPOINT が未設定の場合、パイプラインは no-op です。 処理中の評価が積み上がる。 GET /evaluation-jobs でインフライトキューを確認してください。各行の attempt_countnext_attempt_atlast_error を確認してください。よくある原因: 評価器サービスに到達できないか 5xx を返している(バックオフで再試行)、EVALUATOR_TOKEN が間違っている(401 は終端)、pending を無限に返す非同期評価器(以下を参照)。 セッションが完了したが終端評価がない。 GET /evaluation-jobs?status=polling を照会してください。まだ処理中かもしれません。ジョブが pending のままスタックしている場合、サーバーが評価器に到達できていません。評価器が起動していること、EVALUATOR_TOKEN が一致していることを確認してください。 評価器からの HTTP 401: 無効なベアラートークン サーバーの EVALUATOR_TOKEN が評価器サービスに設定された値と一致していません。両方が同一である必要があります。 非同期評価器が永遠に pending を返す。 サーバーは評価器が done または error を返すか、EVALUATOR_MAX_POLL_DURATION_SECS(デフォルト 1 時間)が経過するまで GET /evaluate/{job_id} をポーリングします。上限を超えると評価は timeout として記録され、インフライトキューから削除されます。評価器が正当にデフォルトより長い時間を必要とする場合は EVALUATOR_MAX_POLL_DURATION_SECS を増やしてください。

次のステップ

  • 評価器エージェントスキル: コーディングエージェントに、実際のセッションに対して次元を設計し、このサービスを構築させる。
  • Python SDK: スコアリングをトリガーする agent_end イベントを送出する。
  • API キー: evaluations:readevaluations:trigger 権限。
  • 監査: Observability のもう一つの自動品質機能、ポリシーベースのレビュー。