これは重要なプロセスです。出力を読むことで、アプリケーションが実際に何をしているか、どこで苦戦しているか、特定のユースケースにおいて「良い」とは何かを理解できます。その理解こそが、後でどの自動評価器を作るべきか、その基準をどう定義すべきかを教えてくれます。このステップを飛ばして自動評価に直行するチームは、結局重要でないものを計測することになりがちです。

手動評価は、後で自動評価器を検証するための正解データとして使える、人間によるラベルも生み出します。

コードベース評価

コードベース評価器は、決定論的なロジックで検証可能なプロパティをチェックします。高速・安価で、毎回同じ結果を返します。

コードベース評価器がよくフィットするチェックの例:

出力が有効な JSON か、必須スキーマに従っているか
出力が特定のキーワードやパターンを含んでいる (または含んでいない) か
出力が長さ制限内に収まっているか
生成された SQL がエラーなく実行されるか

ただし限界もあり、意味を判定することはできません。コードベース評価器は、出力に「refund」という語が含まれているかは確認できますが、出力が返金ポリシーを正しく説明しているかは確認できません。

LLM-as-a-Judge

LLM-as-a-Judge の評価器は、言語モデルを使って出力にスコアを付けます。 AI アプリやエージェントの品質はテキスト出力の品質に依存する、という根本課題に向き合うために必須です。

これは言語理解を要する品質に対する適した手法です。応答が質問に関連しているか、トーンが想定読者に合っているか、要約が原文の要点を捉えているか、などです。

LLM-as-a-Judge は不完全で、間違えやすいものです。そのため、以下の特徴があります。

モデルは人間の専門家のようには自動で採点しません。専門家の持つコンテキストを持っていないからです
期待する評価対象を実際に測れているかを確認するため、人間の選好に対するキャリブレーションが必要です
アプリケーション側の LLM と同じモデルファミリーを使うと、特に同じ盲点を抱えがちです

こうした制限は、LLM-as-a-Judge を避ける理由にはなりません。人間ラベルに対してキャリブレーションされ、コードベースのチェックで補強された LLM-as-a-Judge は、信頼できる評価器です。

参照あり評価器と参照なし評価器

コードベース評価器も LLM-as-a-Judge 評価器も、参照あり (Reference-based) と参照なし (Reference-free) の両方になり得ます。参照ありの評価器は、事前定義された期待出力 (正解や模範解答など) に対して出力を比較します。参照なしの評価器は、比較対象となる正解データを必要とせずに、出力単独で評価します。

	コードベース	LLM-as-a-Judge / 手動評価
参照あり	完全文字列一致チェック	「応答はこの特定のポリシーを正しく説明しているか?」
参照なし	JSON 構造の検証	トーンの評価、言語検出

参照なし評価器の利点は、未知の本番データに適用できることです。参照あり評価器は常に事前定義の参照応答を必要とします。

実務では

評価器を設置するタイミング

前述のとおり、まず手動レビューから始めます。それを行った上で、問いはこうなります。見つけたものに対して自動評価器を設置すべきか?

一度きりの修正 で済む問題か、汎化の問題 かを自問してください。単純なプロンプト変更で解決するなら、変更するだけで構いません。評価器は不要です。ただし、異なる入力にわたって繰り返しテストすべき失敗モードを明確に特定できるなら、そのときが評価器を設置すべきタイミングです。

何を評価するか?

「役立ち度」や「品質」のような汎用的な性質は出発点として魅力的に見えますが、有用なシグナルを生むことはほとんどありません。曖昧な基準をチェックする評価器は曖昧な結果を返します。アプリケーションにとって「良い」「悪い」とは何かを精緻に定義できるほど、評価器は有用になります。

1 つ実務的な推奨があります。評価器を設計するときは、5 段階評価などの段階スケールよりも、二値スコア (合格/不合格) を優先してください。二値スコアは、許容可能と許容不可の線を明確に定義せざるを得なくします。段階スケールは、3 と 4 の違いといった曖昧さをもたらし、スコアの解釈を難しくし、評価器間や時系列での一貫性を損ねます。

評価手法の組み合わせ

重視する品質ごとに、それぞれの評価器を用意します。

成熟した評価構成のほとんどは、3 つすべての評価手法を使います。 組み合わせることで、アプリケーション全体の品質を多面的に把握できます。

具体例として、3 つのアプリケーション例と、その評価器スタックを示します。

自然言語の質問を、社内データウェアハウスに対する SQL に変換する SQL エージェント。ユーザーは「先四半期の地域別売上は?」のような質問をし、エージェントはクエリを生成して実行します。

品質	手法
クエリがスキーマに対して実行できる	コードベース
クエリがユーザーの意図に答えている	LLM-as-a-Judge
継続的なサンプルでのキャリブレーション	手動レビュー

マーケティングコピーの草案を受け取り、企業のブランドボイスに合わせて書き換えるトーン書き換えツール。出力は平文の文章で、構造のチェック対象も、完全一致の参照回答もありません。

品質	手法
トーンがブランドボイスに合っている	LLM-as-a-Judge
元のメッセージが忠実に保たれている	LLM-as-a-Judge
継続的なサンプルでのキャリブレーション	手動レビュー

アップロードされた PDF から構造化フィールド (ベンダー、合計、支払期日) を抽出する請求書処理ツール。データセットは各フィールドに対する完全一致ラベルを持ちます。

品質	手法
抽出された JSON がスキーマに一致する	コードベース
各フィールドが期待値に一致する	コードベース (データセットラベルに対する完全一致)
エッジケースや新規ベンダーフォーマット	手動レビュー (サンプル)

どこから始めるか

手動レビューから始め、繰り返し実行する必要のあるチェックだけを自動化しましょう。

アプリケーションでの良し悪しの感覚を養うため、出力を手動でレビューします。
捕捉したい特定の失敗モードを書き出し、できるだけ明確に定義します。
多くの入力にわたって、または時系列で、その失敗モードを繰り返しテストする必要があるときだけ、自動評価器を設置します。

次のステップ

結果が十分に良ければ、変更をリリースできます。リリースされた後、ループは再び始まります。更新されたシステムは新しいトレース、新しいモニタリングシグナル、そして新しい改善機会を生み出します。

オフライン実験の枠を超えて使うべき評価器もあります。参照なしの評価器、ユーザーフィードバックシグナル、その他の本番でも安全に動かせるチェックは、本番トラフィックに適用して、リリース前に見た品質と本番品質が一致することを確認できます。

本番挙動が期待と一致していれば、より自信を持ってスケールできます。一致していなければ、そのケースをトレースで捕捉し、データセットのアイテムに変え、次のラウンドの実験を回します。こうしてループを閉じます。

その他のガイド

Was this page helpful?

On this page