--- title: 評価 sidebarTitle: 評価 description: 手動レビュー、コードベースのチェック、LLM-as-a-Judge を使って、実験出力が良いかどうかを判断する方法。 translatedAt: 2026-08-19 --- # 評価 ## 評価はループのどこに位置するか オフライン評価は、実験を実行することと、変更をリリースすることの間にあるステップです。 データセットがあり、それに対してアプリケーションを実行し、出力が良いかどうかを判断する必要があります。 ## 評価の典型的な進化のしかた [#how-evaluation-typically-evolves] 多くの場合、まず **[手動で出力をレビュー](/docs/evaluation/evaluation-methods/annotation-queues)** し、自分のアプリケーションにおける良し悪しの感覚を養うことから始めます。 そこから、**注目すべき失敗モードを洗い出し** ます。 それを精緻に定義できるようになったら、**専用の評価器で自動化** します。 以降では、各種の評価を詳しく扱います。 実務では、これらを組み合わせて使うことになるでしょう。 ただし、よく機能する自動評価の構成への道のりは、ほぼ常に手動レビューから始まります。 手動評価は一度きりのステップではありません。 良い本番構成は、新しい失敗モードを捕捉し、自動評価器のキャリブレーションを保つために、人間の専門家による継続的なレビューを組み込みます。 このサイクルについては [評価セットを生かし続ける](/academy/japan/evaluate/choosing-what-to-evaluate#keeping-the-set-alive) で扱っています。 > **ガイド: [エラー分析](/guides/cookbook/error-analysis-llm-applications)** > > サンプルデータを選び、Annotation queue を構築し、失敗カテゴリにクラスタリングし、失敗率を定量化し、対応を決定します。 ## 評価手法 [#three-kinds-of-evaluation] 評価には主に 3 つの方法があります。 手動、コードによる方法、LLM による方法です。 それぞれが異なる種類の品質チェックに適しています。 ### 手動評価 手動評価とは、出力を実際に目を通し、スコアを付けたり品質に関する考えを書き留めたりするプロセスです。 これは重要なプロセスです。 出力を読むことで、アプリケーションが実際に何をしているか、どこで苦戦しているか、特定のユースケースにおいて「良い」とは何かを理解できます。 その理解こそが、後でどの自動評価器を作るべきか、その基準をどう定義すべきかを教えてくれます。 このステップを飛ばして自動評価に直行するチームは、結局重要でないものを計測することになりがちです。 手動評価は、後で自動評価器を検証するための正解データとして使える、人間によるラベルも生み出します。 ### コードベース評価 [コードベース評価器](/docs/evaluation/evaluation-methods/code-evaluators)は、決定論的なロジックで検証可能なプロパティをチェックします。 高速・安価で、毎回同じ結果を返します。 コードベース評価器がよくフィットするチェックの例: - 出力が有効な JSON か、必須スキーマに従っているか - 出力が特定のキーワードやパターンを含んでいる (または含んでいない) か - 出力が長さ制限内に収まっているか - 生成された SQL がエラーなく実行されるか ただし限界もあり、意味を判定することはできません。 コードベース評価器は、出力に「refund」という語が含まれているかは確認できますが、出力が返金ポリシーを正しく説明しているかは確認できません。 ### LLM-as-a-Judge [LLM-as-a-Judge の評価器](/docs/evaluation/evaluation-methods/llm-as-a-judge)は、言語モデルを使って出力にスコアを付けます。 AI アプリやエージェントの品質はテキスト出力の品質に依存する、という根本課題に向き合うために必須です。 これは言語理解を要する品質に対する適した手法です。 応答が質問に関連しているか、トーンが想定読者に合っているか、要約が原文の要点を捉えているか、などです。 LLM-as-a-Judge は不完全で、間違えやすいものです。そのため、以下の特徴があります。 - モデルは人間の専門家のようには自動で採点しません。専門家の持つコンテキストを持っていないからです - 期待する評価対象を実際に測れているかを確認するため、人間の選好に対する[キャリブレーション](/guides/llm-as-a-judge-calibration-skill)が必要です - アプリケーション側の LLM と同じモデルファミリーを使うと、特に同じ盲点を抱えがちです こうした制限は、LLM-as-a-Judge を避ける理由にはなりません。 人間ラベルに対してキャリブレーションされ、コードベースのチェックで補強された LLM-as-a-Judge は、信頼できる評価器です。 その書き方は [良い評価器の書き方](/academy/japan/evaluate/writing-evaluators) の解説で扱います。 ## 参照あり評価器と参照なし評価器 [#reference-based-vs-reference-free] コードベース評価器も LLM-as-a-Judge 評価器も、参照あり (Reference-based) と参照なし (Reference-free) の両方になり得ます。 参照ありの評価器は、事前定義された期待出力 (正解や模範解答など) に対して出力を比較します。 参照なしの評価器は、比較対象となる正解データを必要とせずに、出力単独で評価します。 | | コードベース | LLM-as-a-Judge / 手動評価 | | -------- | ---------------------- | --------------------------------------------------- | | 参照あり | 完全文字列一致チェック | 「応答はこの特定のポリシーを正しく説明しているか?」 | | 参照なし | JSON 構造の検証 | トーンの評価、言語検出 | 参照なし評価器の利点は、未知の本番データに適用できることです。 参照あり評価器は常に事前定義の参照応答を必要とします。 ## 実務では ### 評価器を設置するタイミング [#when-to-set-up-evaluators] [前述のとおり](#how-evaluation-typically-evolves)、まず手動レビューから始めます。 それを行った上で、見つけた失敗のすべてに評価器が必要なわけではありません。 単純なプロンプト変更で解決する **一度きりの修正** には不要で、繰り返し捕まえる必要がある **汎化の問題** には必要です。 この点は [何を評価するかを選ぶ](/academy/japan/evaluate/choosing-what-to-evaluate#fix-first) でさらに掘り下げています。 ### 何を評価するか? 「役立ち度」や「品質」のような汎用的な性質は出発点として魅力的に見えますが、有用なシグナルを生むことはほとんどありません。 曖昧な基準をチェックする評価器は曖昧な結果を返します。 アプリケーションにとって「良い」「悪い」とは何かを精緻に定義できるほど、評価器は有用になります。 この点は [何を評価するかを選ぶ](/academy/japan/evaluate/choosing-what-to-evaluate) のページでさらに掘り下げています。 実際に評価器を設計するときは、5 段階評価などの段階スケールよりも二値スコア (合格/不合格) を優先してください。 その理由は [良い評価器の書き方](/academy/japan/evaluate/writing-evaluators#binary-verdicts) で説明しています。 ### 評価手法の組み合わせ 重視する品質ごとに、[それぞれの評価器](/academy/japan/evaluate/writing-evaluators#one-evaluator-per-failure-mode) を用意します。 **成熟した評価構成のほとんどは、[3 つすべての評価手法](#three-kinds-of-evaluation) を使います。** 組み合わせることで、アプリケーション全体の品質を多面的に把握できます。 具体例として、3 つのアプリケーション例と、その評価器スタックを示します。 _自然言語の質問を、社内データウェアハウスに対する SQL に変換する SQL エージェント。 ユーザーは「先四半期の地域別売上は?」のような質問をし、エージェントはクエリを生成して実行します。_ | 品質 | 手法 | | -------------------------------------- | -------------- | | クエリがスキーマに対して実行できる | コードベース | | クエリがユーザーの意図に答えている | LLM-as-a-Judge | | 継続的なサンプルでのキャリブレーション | 手動レビュー | _マーケティングコピーの草案を受け取り、企業のブランドボイスに合わせて書き換えるトーン書き換えツール。 出力は平文の文章で、構造のチェック対象も、完全一致の参照回答もありません。_ | 品質 | 手法 | | -------------------------------------- | -------------- | | トーンがブランドボイスに合っている | LLM-as-a-Judge | | 元のメッセージが忠実に保たれている | LLM-as-a-Judge | | 継続的なサンプルでのキャリブレーション | 手動レビュー | _アップロードされた PDF から構造化フィールド (ベンダー、合計、支払期日) を抽出する請求書処理ツール。 データセットは各フィールドに対する完全一致ラベルを持ちます。_ | 品質 | 手法 | | -------------------------------------- | ------------------------------------------------- | | 抽出された JSON がスキーマに一致する | コードベース | | 各フィールドが期待値に一致する | コードベース (データセットラベルに対する完全一致) | | エッジケースや新規ベンダーフォーマット | 手動レビュー (サンプル) | ## どこから始めるか 手動レビューから始め、繰り返し実行する必要のあるチェックだけを自動化しましょう。 1. アプリケーションでの良し悪しの感覚を養うため、[出力を手動でレビュー](#how-evaluation-typically-evolves) します。 2. 捕捉したい特定の失敗モードを書き出し、できるだけ明確に定義します。 3. 多くの入力にわたって、または時系列で、その失敗モードを繰り返しテストする必要があるときだけ、自動評価器を設置します。信頼できる評価器の作り方は [良い評価器の書き方](/academy/japan/evaluate/writing-evaluators) の解説で扱います。 ## 次のステップ 結果が十分に良ければ、変更をリリースできます。 リリースされた後、ループは再び始まります。 更新されたシステムは新しい [トレース](/academy/japan/tracing)、新しい [モニタリング](/academy/japan/monitoring) シグナル、そして新しい改善機会を生み出します。 オフライン実験の枠を超えて使うべき評価器もあります。 参照なしの評価器、ユーザーフィードバックシグナル、その他の本番でも安全に動かせるチェックは、本番トラフィックに適用して、リリース前に見た品質と本番品質が一致することを確認できます。 本番挙動が期待と一致していれば、より自信を持ってスケールできます。 一致していなければ、そのケースをトレースで捕捉し、[データセット](/academy/japan/datasets) のアイテムに変え、次のラウンドの [実験](/academy/japan/experiments) を回します。 こうしてループを閉じます。 ## その他のガイド - [LLM-as-a-Judge のキャリブレーション](/guides/llm-as-a-judge-calibration-skill) — 判定用プロンプトが自分のラベル付けと一致するかを検証し、一致するまで反復します。 - [RAGAS を使った RAG 評価](/resources/engineering/evaluation-of-rag-with-ragas) — RAG アプリケーションのリトリーバルと生成の品質を採点します。 - [外部の評価パイプラインから Langfuse へスコアを書き込む](/guides/cookbook/example_external_evaluation_pipelines) — 本番トレースを取得し、Langfuse の外で評価し、API 経由でスコアを書き戻します。 - [マルチターン会話の評価](/guides/cookbook/example_evaluating_multi_turn_conversations) — チャットアプリの会話ターン間で品質を採点します。 - [シミュレートされたマルチターン会話](/guides/cookbook/example_simulated_multi_turn_conversations) — シミュレートされたマルチターンシナリオを生成・評価します。 --- ## 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.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**: , 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 `) to read or write traces, prompts, datasets, and scores from the terminal. Found an error in these docs? Please open an issue at .