LLM の評価ツールは、2026 年にはひととおり出そろいました。ツールごとの紹介や比較は、このブログでも AI eval ツール 10 選 と各ツールの記事で書いてきました。
ところが、いざ自分のサービスに入れようとすると、ツールの機能表からは答えが出ない問いにぶつかります。この業務の「正解」は何なのか。どこまでを機械で判定できて、どこから人が見ないといけないのか。
本稿は、ツールではなく使う側の業務から考えます。例として 3 つのサービスを取り上げます。
- EC の問い合わせ対応（返信の下書き・自動返信）
- 社内の法務チェック（契約書のレビュー）
- 社内規程の問い合わせ（就業規則や経費精算の質問に答える）
先に結論を書きます。
- 評価しやすいかどうかは、ツールよりも「正解をどう決められるか」でほぼ決まります。 ツールを選ぶ前に、出力を「機械で判定できる部分」と「人か LLM が判断するしかない部分」に分けます。
- 小さく始めるなら Promptfoo（設定ファイルと CLI で回せて、CI に入れやすい）。本番の実行記録から評価用データを育て、実験を並べて比べたくなったら Langfuse（自前で運用でき、日本リージョンのクラウドもあります）。厳密な実験や、エージェントに道具を使わせる評価には Inspect AI が向いています。
- 既存のツールに無いのは、業務の担当者が自分で採点基準を書いて直せる場所と、LLM の採点が人の判定とどれだけ一致しているかを常に測る仕組みです。
1. ツールの役割分担
評価のツールは、大きく 2 種類に分かれます。
本番の実行記録 ──(拾う)──> 評価用データセット ──> 実験（プロンプト・モデル・設定を変えて回す）
▲ │
└──────────── 採点結果を見て直す ◀──────────────┘
Langfuse などが担う範囲 Promptfoo / Inspect AI などが担う範囲評価を実行する道具（手元や CI で回す）
| ツール | 書き方 | 向いている用途 | 注意点 |
|---|---|---|---|
| Promptfoo | YAML（採点に JS や Python も使える） | プロンプトやモデルの比較、CI での退行検知、攻撃への耐性の試験 | 2026 年 3 月に OpenAI が買収を発表。オープンソースは続けると表明されています |
| Inspect AI | Python（データ → 解く処理 → 採点） | 研究水準の実験、エージェント評価、隔離した環境での実行 | 覚えることはやや多め。結果を 1 件ずつ見る画面が付いています |
| DeepEval | pytest 風 | 既製の指標（忠実度・関連度など）をすぐ使いたいとき | 既製指標の採点用の指示文は英語で書かれています。日本語で使うなら、人の判定と比べて妥当性を確かめます |
| lm-evaluation-harness | 既存のベンチマーク | モデルそのものの基礎能力の比較 | 自社の業務の評価には向きません |
記録と実験管理の基盤（運用で回す）
| ツール | 強み | 注意点 |
|---|---|---|
| Langfuse | 実行記録・データセット・実験の比較・LLM による採点・人による注釈がそろっています。2026 年 4 月に実験の機能が作り直され、実験がデータセットと同じ扱いの中心機能になりました。日本リージョンのクラウドがあります | 2026 年 1 月に ClickHouse が買収。オープンソースと自前運用は続けると表明されています |
| Braintrust | 実験同士の差分（どのケースが良くなり、どれが悪くなったか）の画面が見やすい | 商用で、データを外部に置くことになります |
| LangSmith | LangChain や LangGraph と密に連携 | LangChain を使っていなければ利点は薄くなります |
| Phoenix | 手元で起動でき、実行記録と評価を見られます | 機能は Langfuse と重なります |
ふつうは両方を使います。最初は実行する道具だけで始め、データが増えてきたら記録の基盤を足します。
2. 採点の方法と、評価のしやすさ
| 方法 | 例 | 費用 | 信頼度 | 向いているもの |
|---|---|---|---|---|
| 機械的な判定 | 完全一致、正規表現、JSON の形、分類ラベルの一致、禁止表現が無いこと | ほぼ無料 | 高い | 分類・抽出・形式を守ること |
| 参照回答との比較 | 期待する答えと意味が近いか | 安い | 中 | 言い回しの自由度が小さい回答 |
| LLM による採点 | 採点基準を渡し、別の LLM に点を付けさせる | 中 | 基準の書き方しだい。人の判定との一致率を測るまでは信用しない | 丁寧さ・網羅性・根拠の妥当性 |
| 人による判定 | 担当者が見て良し悪しを付ける | 高い | 最も高い（ただし人によってぶれる） | 正解の基準そのものを作る段階、LLM による採点の検証 |
原則は 1 つです。1 つの出力を「機械で判定できる部分」と「判断が要る部分」に分け、前者をできるだけ増やします。 判断が要る部分は、最初は人が付け、その判定を正解として LLM の採点を合わせ込みます。LLM による採点の偏りについては LLM 評価とモデル選択の論文を読む で詳しく扱いました。
3. EC の問い合わせ対応
何をするか: 顧客からの問い合わせ（配送の遅れ・返品・在庫・支払い）に、注文情報と FAQ を参照して返信文を作ります。
評価のしやすさ: 高い。 分けてみると、機械で判定できる部分が多くあります。
| 見るもの | 判定の方法 |
|---|---|
| 問い合わせの分類（返品 / 配送 / 支払い / その他）が正しいか | 機械（ラベルの一致） |
| 人の対応に回すべき案件（強い不満、高額、法的な言及）を回したか | 機械（回した / 回さないの一致）。取りこぼしを最も重く見る |
| 注文番号・日付・金額を正しく引用しているか | 機械（注文データと突き合わせる） |
| 方針に反する約束をしていないか（勝手な返金の確約、規約外の送料無料など） | 機械（禁止表現）と LLM による採点 |
| 丁寧さ・分かりやすさ・解決に必要な情報がそろっているか | LLM による採点（採点基準を文章にしておく） |
データセットの作り方: 過去の問い合わせ履歴から、分類ごと・難しさごとに偏りなく抜き出します。実際に担当者が送った返信が、そのまま参照回答になります。個人情報は伏せてから使います。
Promptfoo での例:
prompts:
- file://prompts/reply_v1.txt
- file://prompts/reply_v2.txt
providers:
- anthropic:messages:claude-sonnet-5-5
- anthropic:messages:claude-haiku-4-5-20251001
tests:
- vars:
inquiry: "注文 A-1029 がまだ届きません。明日までに必要です。"
order: file://fixtures/order_A-1029.json
assert:
- type: contains
value: "A-1029"
- type: not-contains
value: "返金いたします"
- type: llm-rubric
value: "配送状況を具体的に伝え、明日までに届かない可能性があるなら代わりの案を示している"npx promptfoo eval を実行すると、プロンプト 2 種類とモデル 2 種類を掛け合わせた結果が表に並びます。CI に入れておけば、プロンプトを直すたびに、既存のケースが悪くなっていないかを確かめられます。
運用に入ったら: Langfuse に本番の実行を記録し、担当者が「直してから送った」返信を拾って評価用データに足していきます。担当者が直さずにそのまま送れた割合は、それ自体が本番でいちばん分かりやすい指標になります。
4. 社内の法務チェック
何をするか: 取引先から届いた契約書を読み、自社の基準（雛形や審査方針）から外れている条項を指摘して、修正案を出します。
評価のしやすさ: 中〜低。 正解が 1 つに決まらず、見落としたときの損害が大きい業務です。それでも分け方しだいで、機械で判定できる部分は作れます。
| 見るもの | 判定の方法 |
|---|---|
| 問題のある条項を見落とさなかったか（損害賠償の上限なし、一方的な解除権、管轄など） | 機械（法務担当が付けた「指摘すべき条項」の一覧と突き合わせ、取りこぼしの割合を測る） |
| 問題の無い条項を指摘していないか | 機械（指摘のうち正しかった割合）。ただし指摘しすぎは見落としより軽い |
| 指摘が契約書の正しい箇所を引いているか | 機械（引用した条番号や文言が原文にあるか） |
| 指摘の理由と修正案が妥当か | 人が見るのが基本。LLM による採点は、人の判定との一致率を確かめてから補助として使う |
データセットの作り方: 過去にレビューした契約書と、そのときの法務の指摘（修正履歴やコメント）を正解にします。問題のある条項をわざと埋め込んだ版を作ると、見落としの割合を確実に測れます。機密性が高いので、データを社外に出さない構成（自前運用の Langfuse、手元で回す Inspect AI や Promptfoo）を選びます。
Inspect AI での例:
import re
from inspect_ai import Task, task
from inspect_ai.dataset import json_dataset
from inspect_ai.scorer import Score, Target, mean, scorer
from inspect_ai.solver import generate, system_message
REVIEW_POLICY = "自社の審査方針に照らし、問題のある条項を「第N条」の形で挙げてください。"
def extract_clause_ids(text: str) -> set[str]:
return set(re.findall(r"第\d+条", text))
@scorer(metrics=[mean()])
def flagged_clause_recall():
async def score(state, target: Target):
expected = set(target.target) # 法務が付けた、指摘すべき条番号
found = extract_clause_ids(state.output.completion)
return Score(value=len(expected & found) / len(expected))
return score
@task
def contract_review():
return Task(
dataset=json_dataset("contracts.jsonl"),
solver=[system_message(REVIEW_POLICY), generate()],
scorer=flagged_clause_recall(),
)inspect eval contract_review.py --model anthropic/claude-opus-5-5 で実行し、inspect view で 1 件ずつ確かめられます。
注意: この業務でいちばん危ないのは「平均点は上がったのに、重大な見落としが 1 件増えた」状態です。平均とは別に、重大度の高い条項の見落とし件数を必ず出します。
5. 社内規程の問い合わせ
何をするか: 社内規程の文書を検索し、その内容に基づいて社員の質問に答えます。
評価のしやすさ: 中。 「検索」と「回答」を分けると、ぐっと評価しやすくなります。
| 見るもの | 判定の方法 |
|---|---|
| 正しい規程の箇所を検索で拾えたか | 機械（正解の文書や節が上位に入っているか） |
| 回答が、拾った規程の内容から外れていないか（でっち上げが無いか） | LLM による採点（回答の各文が根拠の文書で裏付けられるか） |
| 規程に書いていないことを「分からない」と言えたか | 機械（答えの無い質問を混ぜ、断ったかを判定） |
| 規程の改定についていけているか | 機械（改定の前後で答えが変わる質問を用意） |
データセットの作り方: 総務や人事への過去の問い合わせから質問を集め、担当者に「正解の規程箇所」を付けてもらいます。答えの無い質問と、改定で答えが変わった質問をわざと混ぜます。
使い方: 検索の部分は機械の判定だけで回せるので、Promptfoo か小さな自前のスクリプトで足ります。回答が根拠に沿っているかの判定には DeepEval や Ragas の既製の指標が使えますが、日本語での妥当性は人の判定と比べて確かめます。
6. 3 つの例を並べる
| EC の問い合わせ | 法務チェック | 社内規程の問い合わせ | |
|---|---|---|---|
| 機械で判定できる部分 | 多い | 中（見落とし・引用の正しさ） | 中（検索・断り） |
| 正解データの入手 | 容易（過去の返信） | 難しい（専門家の時間が要る） | 中（担当者の確認が要る） |
| 失敗したときの重さ | 中（顧客の不満） | 高い（契約上の損害） | 中（誤った案内） |
| 人の判定がどれだけ要るか | 低〜中 | 高い | 中 |
| データの機密性 | 個人情報を伏せれば中 | 高い | 中 |
| 最初に使う道具 | Promptfoo | Inspect AI か Promptfoo（手元で実行） | Promptfoo と小さな自前スクリプト |
| 運用の基盤 | Langfuse | 自前運用の Langfuse | Langfuse |
7. 自作するなら、どこに価値があるか
実行・記録・比較の画面は、既存のツールで足ります。作る価値があるのは次の部分です。
- 業務の担当者が採点基準を書いて直せる場所。 いまのツールでは基準が YAML や Python に埋まっていて、法務や問い合わせ窓口の担当者が自分では直せません。
- LLM による採点を常に検証する仕組み。 人の判定を一定の割合で混ぜ続け、LLM の採点との一致率が下がったら知らせます。
- 「重大な失敗」を平均から切り離して見せる画面。 平均点が上がった陰で、重い失敗が 1 件増えたことを見逃さないようにします。
- 本番の修正履歴から評価用データを自動で育てる流れ。 担当者が直して送った返信や、法務が付け直した指摘を、そのまま次の正解に回します。
- 同じ条件での繰り返し実行と、結果のばらつきの表示。 1 回の実行で良し悪しを決めないようにします。
最初の一歩としては、3 章の EC の例を Promptfoo で一周させ、データセット・採点基準・結果の流れを回してみてから、何が足りないかを洗い出すのがいちばん早い道です。
参考資料
- OpenAI Acquires Promptfoo (eWeek)
- OpenAI acquisition of Promptfoo (SiliconANGLE)
- Langfuse changelog: Experiments rebuild (2026-04-13)
- Langfuse is joining ClickHouse (2026-01-16)
- Langfuse Cloud 日本リージョンを開始しました (2026-04-27)
- DeepEval の忠実度指標の採点用テンプレート (GitHub)
- Best LLM evaluation tools 2026 (Future AGI)
- Best LLM evaluation tools for enterprise teams 2026 (Braintrust)
関連記事
Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。