成功基準を決めて評価(Eval)を作る

「Claude を使ったこの機能は、うまく動いていると言えるのか」を判断するには、先に基準を決め、その基準を測る評価（Eval）を用意しておく必要があります。Anthropic 公式ドキュメントの「Define success criteria and build evaluations」は、その決め方と作り方をまとめたページです。本記事はその内容を日本語で解説します。

このページで扱うこと

プロンプトを書き始める前に決めておくべきことが 2 つあります。何をもって成功とするか（成功基準）と、それをどう測るか（評価・Eval）です。公式ドキュメントはこの 2 つを一続きのものとして扱っています。基準が曖昧なままだと、プロンプトを変えたときに良くなったのか悪くなったのかが判断できず、改善が感覚頼りになるためです。

本記事では、成功基準の満たすべき条件、実務でよく使われる基準の一覧、評価を設計する 3 つの原則、そして公式が挙げている 5 種類の評価例を順に見ていきます。

成功基準をどう決めるか

良い成功基準は、いわゆる SMART の考え方に沿ったものだと説明されています。

Specific（具体的） — 「性能が良いこと」ではなく「感情分類が正確であること」のように、何の性能かを明示する。
Measurable（測定可能） — 数値で測れる指標を優先する。定性的な尺度でも、統計的に一貫して適用できるなら使ってよい。公式が挙げている書き方の例は「10,000 回の試行のうち、有害性でフラグが立つ出力が 0.1% 未満であること」です。
Achievable（達成可能） — 業界ベンチマーク、事前実験、AI の研究成果、専門家の知見をもとに現実的な水準を置く。
Relevant（関連性がある） — アプリケーションの目的とユーザーのニーズに沿っている。

測定可能にする、という点が実務では効きます。数値指標には次のような種類があります。

タスク固有の指標 — F1 スコア、BLEU スコア、パープレキシティなど
汎用の指標 — 正解率（accuracy）、適合率（precision）、再現率（recall）
運用上の指標 — 応答時間（ミリ秒）、稼働率（%）

倫理や安全性のように一見数値化しにくい題材でも、判定の手順を固定すれば測れる形にできる、というのが公式の立場です。

よく使われる成功基準

公式ドキュメントは、代表的な成功基準として次を挙げています。実際のアプリケーションでは、このうち複数を同時に見ることになります。

Task fidelity（タスク忠実度） — タスクをどれだけ正確に実行できるか。エッジケースへの対応も含む。
Consistency（一貫性） — 似た入力に対して、似た応答を返せるか。
Relevance and coherence（関連性と一貫した構成） — 質問に直接答えているか、論理の流れが通っているか。
Tone and style（トーンと文体） — 想定した口調・文体に合っているか。対象読者に対して言葉づかいが適切か。
Privacy preservation（プライバシーの保護） — 個人情報や機密情報を適切に扱えているか。
Context utilization（コンテキストの活用） — 与えた文脈をどれだけ活かせているか。
Latency（レイテンシ） — 許容できる応答時間に収まっているか。
Price（コスト） — API 呼び出しの費用が予算内に収まっているか。

公式が明示しているとおり、ほとんどのユースケースは 1 つの基準では足りず、多次元の評価が必要になります。たとえば「正確だが遅すぎる」「速いが口調が合わない」は、どちらも単一指標では見えません。

評価(Eval)の設計原則

評価の作り方について、公式は 3 つの原則を挙げています。

タスクに即して作る（Task-specific） — 実際のタスクの分布を反映させる。加えてエッジケースを必ず入れる。挙げられている例は、無関係あるいは存在しないデータ、極端に長い入力、チャット用途なら有害・不適切な入力、そして人間でも判断が割れる曖昧なケースです。
可能なかぎり自動化する（Automate when possible） — 選択式、完全一致、コードによる採点、LLM による採点など、機械的に採点できる形式に寄せる。
質より量を優先する（Prioritize volume over quality） — 少数を人手で丁寧に採点するより、自動採点で多少シグナルが弱くなっても大量の設問を回すほうが有効である。

3 つ目は直感に反しますが、理由は明快です。手作業の採点は件数が伸びず、件数が伸びないと差が誤差に埋もれます。採点の精度を少し落としてでも母数を増やすほうが、プロンプト変更の良し悪しを判別しやすくなります。

5種類の評価例

公式ドキュメントは、成功基準ごとに具体的な評価の作り方を 5 つ示しています。採点方法がそれぞれ違う点が要点です。

タスク忠実度 — 完全一致による評価（感情分析）

出力があらかじめ決めた正解と完全に一致するかを見ます。テストケースは人手でラベル付けした 1,000 件のツイート。空白と大文字小文字を正規化してから比較します。エッジケースとして、皮肉（「5 時間のフライト遅延、最高の一日」→ negative）や、感情が混ざった文（「筋はひどいが、演技は素晴らしかった」→ mixed）を含めます。
一貫性 — コサイン類似度による評価（FAQ ボット）

言い換えた質問に対して、意味的に近い回答を返せているかを見ます。Sentence-BERT の埋め込みを使い、コサイン類似度で採点します（1 に近いほど類似）。テストケースは 50 グループの言い換え質問。エッジケースには、綴りの崩れた入力、無関係な情報が混ざった長文、前置きの長い質問を含めます。
関連性と構成 — ROUGE-L による評価（要約）

生成した要約と参照要約の最長共通部分列（LCS）を測ります。テストケースは参照要約つきの記事 200 本、採点は ROUGE-L の F1 スコア（0〜1、1 が最高）。エッジケースには、複数の話題が混在する記事や、内容とずれた見出しを持つ記事を含めます。
トーンと文体 — LLM によるリッカート尺度評価（カスタマーサービス）

応答のトーン（共感的か、忍耐強いか、専門的か）を 1〜5 で採点します。テストケースは目標トーンを指定した 100 件の問い合わせ。エッジケースには、怒っている顧客、複雑な問題、褒め言葉のかたちを取った苦情を含めます。採点する LLM は、応答を生成するモデルとは別のモデルを使うのがベストプラクティスとされています。
プライバシーの保護 — LLM による二値分類（医療チャットボット）

応答に PHI（保護対象保健情報）が含まれていないかを yes / no で判定します。テストケースは 500 件の模擬患者クエリ。エッジケースは 3 段階に分かれていて、明示的な PHI（氏名・生年月日・処方薬が並んでいる）、仮定形の PHI（「もし友人のアリスが…」）、そして暗黙の PHI（「息子が去年の父親と同じ薬を処方された」）です。判定対象となる PHI には、識別子（氏名・住所・生年月日・社会保障番号・カルテ番号）、健康情報（診断・治療計画・検査結果・投薬記録）、財務情報（保険・支払い記録）、やり取り（医療提供者のメモ、健康に関するメール）が含まれます。

暗黙の PHI の例は、この種の評価で見落としやすい部分を示しています。氏名も日付も書かれていないのに、家族関係と処方の組み合わせから個人が特定されうる、という形です。エッジケースを設計するとは、こうした「素直なテストケースなら通ってしまう入力」を意図的に用意することです。

実務での進め方

ここまでを実務の順序に並べ直すと、次のようになります。

まず成功基準を言葉で書き出す。「良い応答」ではなく、何がどれだけできていれば良いのかを具体化する。
基準ごとに採点方法を決める。完全一致で足りるのか、類似度が要るのか、LLM 採点が要るのかは基準によって変わる。
テストケースを集める。実際の入力分布を反映させつつ、エッジケースを別枠で用意する。
自動採点できる形に整え、件数を増やす。
LLM に採点させる場合は、生成用と採点用でモデルを分ける。

公式が繰り返し強調しているのは、多次元で評価することと、曖昧に見える基準でも測れる形にすることの 2 点です。基準を 1 つに絞ると、その 1 つだけが最適化されて他が崩れます。

出典と注記

本記事は Anthropic 公式ドキュメントの「Define success criteria and build evaluations」ページ（2026年8月31日時点）に基づく非公式の日本語解説です。指標や例は更新される場合があるため、実装前に公式ドキュメントで最新をご確認ください。

関連するトピックとして、当サイトには「プロンプトのベストプラクティス」「Claude モデルの選び方」「コストを抑える」の各記事があります。評価の結果を受けてモデルやプロンプトを調整する段階で参照してください。