---
title: 何を評価するかを選ぶ
sidebarTitle: 何を評価するかを選ぶ
description: "観測された失敗とプロダクトの目標を、少数のメトリクスに落とし込む方法。評価基準はどこから来るのか、どの候補を追跡する価値があるのか、メトリクスはいくつ必要かを解説します。"
translatedAt: 2026-08-19
---

# 何を評価するかを選ぶ

「トレースは取れた。ここから評価をどう設定すればいいのか?」は非常によくある質問であり、正しく押さえておきたい重要な問いでもあります。
このページでは、評価すべき適切なメトリクスの選び方を順に見ていきます。

## メトリクスの 3 つの種類 [#the-three-roles]

最終的に手元に残るメトリクスは、いずれも次のどれかに分類されます。

| 役割               | 答える問い                                          | 典型的な出どころ                           |
| ------------------ | --------------------------------------------------- | ------------------------------------------ |
| **目標メトリクス** | 作ろうとしているものについて、品質は上がっているか? | エラー分析、プロダクトの目標               |
| **ガードレール**   | 絶対に壊してはいけないものが壊れていないか?         | 要件、コンプライアンス、過去のインシデント |
| **運用メトリクス** | コストはいくらか、1 時間あたり何リクエストか?       | トレーシングから追加コストなしで得られる   |

良い構成では、この 3 つを組み合わせて使います。
目標メトリクスは能動的に押し上げていく対象、ガードレールは一度たりとも許容できない失敗を捕まえるもの、運用メトリクスはシステムの状態をより深く把握するためのものです。

**見落としが出ている感覚を持たずに済む範囲で、メトリクスは少ないほど良いです。**

- メトリクスが 1 つ増えるたびに、実行・保守すべき評価器やデータセットが 1 つ増えます
- すべてが重要だということは、何も重要でないのと同じです[3]

**メトリクスの集合は生き物です**

北極星となるメトリクスは時間とともに変わります。
評価の仕組みを整えた後でも、トレースのサンプルを定期的に手で見る習慣は欠かせません。
評価がまだカバーできていない失敗が見つかったり、重要度が下がったメトリクスに気付いたりするからです。

## メトリクス候補はどこから来るのか [#where-criteria-come-from]

良いメトリクスの集合を得る第一歩は、候補を集めることです。候補の出どころは 2 つあります。

### 1. 観測された失敗 [#observed-failures]

メトリクスの多くは、自分でトレースを見ていく中から生まれます。
エージェントが実際にどう振る舞っているか、本当はどう振る舞ってほしいかが、そこで見えてきます。
見えたものを評価対象のメトリクスに翻訳するための体系的なプロセスがあり、[エラー分析](/academy/japan/monitoring/error-analysis) と呼ばれます。
ほとんどの場合、これがメトリクスを決める既定の方法になるはずです。**見つけた失敗に対して評価器を書くこと。想像上の失敗に手をかけないこと** です。[1]

### 2. 目標と絶対条件 [#goals-and-hard-constraints]

エージェントが動いているところを見る前から、監視が必要だと分かっている要件もあります。
コンプライアンス上のルール、安全性の要件、フォーマットの取り決めなどは、一度も壊れたところを見ていなくても初日から評価器を用意します。
これらはガードレールのメトリクスになることが多いです。

**メトリクスのカタログは探索には役立ちますが、自分のプロダクトに合わせてください**

ハルシネーション、有害性、役立ち度といった既製のメトリクスを備えた評価器ライブラリは、抽象的な性質を測るものであり、自分のアプリケーションが実際に失敗する形とは一致しないことがあります。[1]

## どの候補をメトリクスにすべきか? [#which-candidates-deserve-a-metric]

基準の候補すべてを追跡すべきというわけではありません。

### 一度きりの修正か、汎化の問題か? [#fix-first]

エージェントがある点で失敗するのは、その点についてどう振る舞ってほしいかを指定していなかったから、という場合があります。
単純なプロンプト変更で失敗モードが解消するなら、変更してそれで終わりにしてください。
単純なプロンプト変更では解決せず、その失敗モードを時系列で継続的に追跡する必要があるときにだけ、メトリクスとして残します。[1]

<Tabs items={["一度きりの修正になりやすいもの", "汎化の問題"]}>
<Tab>

- 出力が有効な JSON になっていない
- 返答の日付フォーマットが違う
- プレーンテキストのチャネルなのに Markdown を使っている
- ボットが AI アシスタントであることを明示していない

</Tab>
<Tab>

- 回答が、取得したコンテキストによって裏付けられているか
- 質問に答えるために適切なコンテキストが取得できていたか
- 応答がユーザーの依頼に実際に答えているか
- エージェントが適切なツールを選び、適切な引数を渡したか

</Tab>
</Tabs>

### すべてのメトリクスを判断に結びつける [#tie-every-metric-to-a-decision]

メトリクスの候補ごとに、その値が動いたときに何の判断が変わるのかを決めてください。
デプロイを止める、プロンプトを戻す、調査を始める、といったものです。
何の行動も変わらないなら、そのメトリクスはノイズであり、追跡すべきではありません。

<Tabs items={["会話の長さは具体性が足りない", "店舗名の抽出失敗は影響がなかった"]}>
<Tab>

会話の長さは、ユーザーが熱中しているときにも、詰まっているときにも伸びます。
無関係な理由で同じように動くため、この数値だけを見て手を打つことはできません。

</Tab>
<Tab>

OpenAI のレシート処理のウォークスルーでは、店舗名の抽出が 85% の確率で誤っていました。
しかしその誤りは、システムが本来下すべき監査の判断とは相関していないと分かったため、チームは追跡をやめました。[2]

</Tab>
</Tabs>

### コストを意識する [#mind-the-budget]

これは、評価器を設定した後に絞り込む段階でより役に立つ観点です。
評価器によって実行コストは異なります。

- コードベース評価器はほぼ無料です
- LLM-as-a-Judge の評価器は実行にお金がかかり、保守も難しくなります ([良い評価器の書き方](/academy/japan/evaluate/writing-evaluators) を参照)

それほど重要ではないメトリクスで、追跡コストが高いなら、落としてしまうのが良い判断かもしれません。

## ゼロから始める [#starting-from-zero]

メトリクスの集合ができるまでは、まずエージェントの失敗モードを見極める必要があります。
それがメトリクスを導く手がかりになります。

始めるにあたっては、汎用的な 2 つの [スコア](/docs/evaluation/scores/overview) を足場にします。
1 つは何が起きて何がおかしそうかを書く自由記述のメモ、もう 1 つは全体の合格・不合格です。
この 2 つだけを付けながら 30〜50 件のトレースを読み、メモを名前の付いた失敗カテゴリにまとめ、カテゴリごとに真偽値のスコアを 1 つ作ります。
このプロセスが [エラー分析](/academy/japan/monitoring/error-analysis) です。

> **ガイド: [エラー分析](/guides/cookbook/error-analysis-llm-applications)**
>
> 一連の手順の解説です。トレースをサンプリングし、アノテーションキューに足場となる 2 つのスコアを設定し、失敗カテゴリにまとめ、スコア設定に落とし込みます。

## 評価セットを生かし続ける [#keeping-the-set-alive]

メトリクスの集合は、今日時点のアプリケーションを写したものです。
これを最新に保つ習慣が 3 つあります。

- **大きな変更のあとにエラー分析をやり直す。** プロンプトの書き直し、モデルの入れ替え、新機能の追加は失敗の分布を変えることがあります。実施タイミングは [いつ実施するか](/academy/japan/monitoring/error-analysis#when-to-run-it) で扱っています。
- **何も捕まえなくなったメトリクスを引退させる。** ガードレールのチェックを除けば、何か月も 100% のままのスコアは情報を持っておらず、多くの場合は落として構いません。
- **最適化対象のメトリクスに目を配る。** ここにはグッドハートの法則が当てはまります。[4] 特定のメトリクスに向けてプロンプトを調整していくと、どこかで過適合します。ときどき [新しい人間ラベルで再検証する](/guides/llm-as-a-judge-calibration-skill) ことが重要です。

## どこから始めるか

1. まだなら [エラー分析](/academy/japan/monitoring/error-analysis) を実施します。
2. プロダクトの目標と絶対条件を書き出し、目標をそれぞれトレース上で観測できるシグナルに変換します。
3. フィルタを適用します。プロンプト変更で直るものは直し、判断に結びつく候補だけを残し、判定のコストで絞り込みます。
4. メトリクスの集合に納得できたら、それに対応する評価器を実装します。作り方は [良い評価器の書き方](/academy/japan/evaluate/writing-evaluators) の解説で扱います。

## 参考文献

1. [LLM evals FAQ (Hamel Husain & Shreya Shankar)](https://hamel.dev/blog/posts/evals-faq/)
2. [Eval-driven system design: from prototype to production (OpenAI Cookbook)](https://developers.openai.com/cookbook/examples/partners/eval_driven_system_design/receipt_inspection)
3. [A field guide to rapidly improving AI products (Hamel Husain)](https://hamel.dev/blog/posts/field-guide/)
4. [Categorizing variants of Goodhart's law (Manheim & Garrabrant)](https://arxiv.org/abs/1803.04585)

<!-- agent-instructions -->

---

## Agent Instructions

This page is part of the [Langfuse](https://langfuse.com) documentation, published as plain Markdown for AI agents. Every page is available as Markdown by appending `.md` to its URL, or by sending an `Accept: text/markdown` header. This page: `https://langfuse.com/academy/japan/evaluate/choosing-what-to-evaluate.md`.

### Querying these docs

If the answer is not on this page, query the documentation instead of guessing:

- **Semantic search** across all Langfuse docs, returning an answer with the relevant pages and excerpts. Ask a specific, self-contained question:

  ```bash
  curl -sG "https://langfuse.com/api/search-docs" --data-urlencode "query=How do I trace a LangGraph agent?"
  ```

- **Index of every page**: <https://langfuse.com/llms.txt>, with per-section indexes [llms-docs.txt](https://langfuse.com/llms-docs.txt), [llms-integrations.txt](https://langfuse.com/llms-integrations.txt), and [llms-self-hosting.txt](https://langfuse.com/llms-self-hosting.txt).

### Before writing Langfuse code

- **Install the [Langfuse Agent Skill](https://langfuse.com/docs/api-and-data-platform/features/agent-skill).** It encodes Langfuse's own best practices for instrumentation, prompt management, and evaluation, and materially improves results.
- **Read [What does a good trace look like?](https://langfuse.com/docs/observability/best-practices.md)** before instrumenting an application.
- **Verify endpoints, parameters, and response fields** against the [API reference](https://api.reference.langfuse.com) instead of inferring them from code examples.
- **Use the [Langfuse CLI](https://langfuse.com/docs/api-and-data-platform/features/cli)** (`npx langfuse-cli api <resource> <action>`) to read or write traces, prompts, datasets, and scores from the terminal.

Found an error in these docs? Please open an issue at <https://github.com/langfuse/langfuse-docs/issues>.