プロンプト評価をAnthropicの公式コースで学ぶ実践ガイド

prompt_evaluationsとはどんなコースか

prompt_evaluationsは、Anthropicが公開するGitHubリポジトリanthropics/coursesに含まれる学習コースの1つです。このリポジトリには「Anthropic API fundamentals」「Prompt engineering interactive tutorial」「Real world prompting」「Prompt evaluations」「Tool use」の5コースが収録されています。prompt_evaluationsはそのうち「本番運用のプロンプト品質を測る評価(eval)の書き方」だけを扱う専門コースです。

9つのレッスンの内容は次の通りです。

04と06はそれぞれ03・05と同じ採点手法を分類タスクに応用しただけの回なので、本記事では01・02・03・05・07・08・09の実装パターンを中心に扱います。

なお、Anthropicの学習コンテンツにはanthropics/courses(GitHub上のコードコース)とは別に、Anthropic Academyという対象者別に整理された学習プラットフォーム(skilljar.com上)もあります。promptfooの設定ファイルの書き方のような実装パターンを知りたいときは本記事やGitHubのコースを、Anthropicの学習コンテンツ全体の見取り図を知りたいときはAnthropic Academyを参照するとよいでしょう。

このリポジトリは2026年9月15日にAnthropicによってアーカイブされ、read-only(読み取り専用)になりました。以後の更新は止まっています。評価という手法自体の入門資料としては引き続き有効ですが、コード中のモデル名はclaude-3-haiku-20240307のようなClaude 3世代の表記で固定されており、現行のモデル名とは異なります。手元で動かす場合は、モデル名の部分だけ現行のものに置き換える前提で読む必要があります。

評価に必要な4つの要素と3つの採点方法

コースの1限目「Evaluations 101」は、ベンチマークと自社アプリ向けの評価(customer evaluation)を区別するところから始まります。ARCやMMLUのようなベンチマークはモデル全般の実力を示しますが、自分のアプリの特定タスクでどれだけ使えるかは教えてくれません。そこで、入力・正解・出力・スコアの4要素で自分のタスク専用の評価を組み立てます。

• Example Input: モデルに与える指示や質問
• Golden Answer: 正解として扱う理想的な回答
• Model Output: モデルが実際に返した回答
• Score: GoldenAnswerとModel Outputを比較して出す評価値

公式コースは「最低100件のテストケースを推奨するが、学習中はAPIコストを抑えるためもっと少ない件数で進める」と明記しています。少数のテストケースで学び、実運用では件数を増やすのが前提です。

採点方法は3系統に分かれます。

コード採点の中でも、完全一致は「模範解答と1文字でも違えば不正解」という最も厳しい形式です。キーワード検出は語順を問わず特定の語が含まれるかだけを見る方式です。正規表現はより複雑なパターン(例: 「クレジットスコアは3桁の数字で、条件を満たすか満たさないかが書かれている」)を検証する方式です。出力の形式を厳密に制御したい場面ほど、コード採点の基準を先に決めておく効果が大きくなります。Claude APIのプロンプトリーク対策のように、出力形式そのものが安全性に関わる実装では、この基準づくりが特に重要になります。

Anthropic Workbenchで人手採点を試す

2限目「Writing human-graded evals with Anthropic's Workbench」は、コードを1行も書かずに人手採点を試せるツール、Anthropic Workbench(コンソールの実行環境)を使う回です。コード翻訳タスクを例に、プロンプトを画面上で編集しながら評価を進める流れを示します。

最初のプロンプトは「ソースコードをPythonに翻訳して」と指示するだけのものです。Workbenchの評価ビューでJavaScriptとRubyのコードを追加のテストケースとして流すと、翻訳自体は成功するものの、「Certainly! Here's the Python translation...」のような前置きや、翻訳後の長い解説文が出力に混ざります。この結果を5点満点中3点として人手で採点します。

プロンプトに「<python_code>タグの中だけを出力し、他には何も書かない」という指示を追加した2つ目のバージョンを同じテストケースで再実行すると、前置きも解説文も消え、評価は5点満点に上がりました。Workbenchはこのようにプロンプトのバージョンを画面上で並べて比較できるため、コードを書く前に「どこを直せば採点が上がるか」を素早く確認する用途に向いています。

動物の脚の数を当てるチュートリアルで採点の流れを体験する

3限目「A simple code-graded evaluation」は、実際に手を動かして評価のサイクルを体験するレッスンです。テーマは「動物に関する文章から、その動物の脚の数を当てる」という単純な分類タスクで、あえてトリッキーな設問を混ぜています。

eval_data = [
    {"animal_statement": "The animal is a human.", "golden_answer": "2"},
    {"animal_statement": "The animal is a snake.", "golden_answer": "0"},
    {"animal_statement": "The fox lost a leg, but then magically grew back the leg he lost and a mysterious extra leg on top of that.", "golden_answer": "5"},
    {"animal_statement": "The animal is a spider with two extra legs", "golden_answer": "10"},
]

最初のプロンプトは「脚の数を数字で答えて」と指示するだけのシンプルなものです。これをAnthropic APIのclaude-3-haiku-20240307で12件のテストケースに流すと、完全一致採点でのスコアは66.6%でした。原因を出力ごとに見ていくと、2つの問題が見つかります。1つ目は「2本足だと思われます」のように数字以外の説明文が混ざり、完全一致で不正解になる出力形式の問題です。2つ目は、キツネが脚を1本失って再生し、さらに余分な1本まで生えたという設問のように、単純に数え間違えている論理の問題です。

出力形式の問題は「数字だけを、他には何も書かずに答えて」という一文をプロンプトに追加するだけで解消しました。残る論理の問題には、Chain of Thought(思考の連鎖)を使います。

def build_input_prompt3(animal_statement):
    user_content = f"""You will be provided a statement about an animal and your job is to determine how many legs that animal has.
 
    Here is the animal statement.
    <animal_statement>{animal_statement}</animal_statement>
 
    How many legs does the animal have?
    Start by reasoning about the numbers of legs the animal has, thinking step by step inside of <thinking> tags.
    Then, output your final answer inside of <answer> tags.
    Inside the <answer> tags return just the number of legs as an integer and nothing else."""
    messages = [{'role': 'user', 'content': user_content}]
    return messages

<thinking>タグの中で段階的に推論させ、<answer>タグの中身だけを正規表現で抜き出して採点する構成に変えると、スコアは100%まで上がりました。ここで重要なのは、思考過程をタグで分離しておかないと、コード採点自体が組めなくなる点です。CoTを使うプロンプトでは、採点ロジック側にタグ抜き出しの一手間が必ず要ります。

promptfooでコマンドライン評価を自動化する

5限目からは、評価を自前のPythonスクリプトで書く代わりに、オープンソースの評価ツールpromptfooを使う方法に移ります。promptfooは評価を実行できるCLIツールです。promptfooconfig.yamlという設定ファイルに、使うモデル(providers)・比較したいプロンプト(prompts)・テストケース(tests)を書くだけで動きます。

npx promptfoo@latest init

このコマンドでpromptfooconfig.yamlのひな形が作られます。設定ファイルの中身は次のように書きます。

description: "Animal Legs Eval"
 
prompts:
  - prompts.py:simple_prompt
  - prompts.py:better_prompt
  - prompts.py:chain_of_thought_prompt
 
providers:
  - "anthropic:messages:claude-3-haiku-20240307"
 
tests: dataset.csv

テストケースは__expectedという列名を使ったCSVファイルとして用意します(先頭にアンダースコア2つが付くのはpromptfoo特有の記法です)。設定が終わったら、以下の2コマンドで評価を実行し、ブラウザで結果を確認します。

npx promptfoo@latest eval
npx promptfoo@latest view

evalコマンドはCSVの各行にプロンプトを当てはめてAnthropic APIを呼び、期待値と出力を比較します。viewコマンドはブラウザ上のダッシュボードを立ち上げ、どのテストケースがどのプロンプトで失敗したかを一覧・詳細表示できます。動物の脚チュートリアルと同じデータセットをpromptfoo経由で3種類のプロンプト(シンプル・出力形式修正・CoT)に流しても、同じ傾向が再現されます。シンプル版はほぼ全滅、出力形式修正版は単純な設問だけ通過、CoT版だけがトリッキーな設問も含めて安定して正解します。何十件・何百件のテストケースを繰り返し評価する運用では、同じシステムプロンプトを毎回送ることになります。バッチ処理でプロンプトキャッシュのヒット率を上げる工夫が、評価の実行コストにも効いてきます。

独自の採点ロジックを書くカスタムグレーダー

7限目「Promptfoo: custom code graders」は、完全一致やキーワード検出のような組み込みアサーションでは書けない採点ロジックを、Pythonの関数として自作する方法です。例に使うタスクは「指定した単語をちょうどN回だけ含む短い文章を書かせる」という、単純な一致では判定できない課題です。

import re
 
def get_assert(output, context):
    topic = context["vars"]["topic"]
    goal_count = int(context["vars"]["count"])
    pattern = fr'(^|\s)\b{re.escape(topic)}\b'
    actual_count = len(re.findall(pattern, output.lower()))
    pass_result = goal_count == actual_count
    return {
        "pass": pass_result,
        "score": 1 if pass_result else 0,
    }

promptfooはget_assertという名前の関数を自動で探し、モデルの出力と変数を渡してくれます。promptfooconfig.yaml側ではtype: pythonとvalue: file://count.pyを指定するだけで、この自作関数を採点ロジックとして組み込めます。

このレッスンでは同じテストケースをClaude 3.5 SonnetとClaude 3 Haikuの両方に流し、結果を比較しています。Claude 3.5 Sonnetは100%、Claude 3 Haikuは20%という結果になりました。単語の出現回数を正確に数えるという一見単純なタスクでも、モデルによって成績が大きく変わることを、コースは実際の評価結果で示しています。1限目で挙げられていた評価の利点(モデルを切り替えても性能を保てるかの客観的な比較)を、具体的な数字で体験できるレッスンです。

LLMを判定者にするモデル採点評価

8限目「Model-graded evaluations with promptfoo」は、コード採点では測れない基準をLLMに判定させる方法です。promptfooにはllm-rubricという組み込みアサーションがあり、判定用のモデルと基準文をYAMLに書くだけでLLM採点を実装できます。

assert:
  - type: llm-rubric
    provider: anthropic:messages:claude-3-opus-20240229
    value: Is not apologetic

コースの実例は、中学生向けの学習アシスタントを想定したプロンプトです。「学業に関係ない質問には答えない」という指示を入れたうえで、llm-rubricに「学業以外の話題に誘導し直しているか」を判定させます。最初のプロンプトはサッカー選手についての質問にうっかり答えてしまい、判定に失敗しました。対象トピックを明示的に列挙する2つ目のプロンプトに変えると、この問題は解消します。

さらに、出力の大半が「申し訳ありませんが」のような謝罪的な言い回しで始まっている点に気づきます。「謝罪せずに、学業の話題へやさしく誘導する」という指示を追加した3つ目のプロンプトを作り、2つ目のllm-rubricアサーション(謝罪的でないか)を追加しています。1つの評価に複数のアサーションを重ねて、複数の品質基準を同時にチェックできることがこのレッスンの要点です。安全性に関わる評価を独自の判定ツールとして仕組み化した例もあります。Bloomという評価ツールも、LLMを判定者に使う発想を土台にしています。

9限目「Custom model-graded evals」は、07のカスタムPython関数と08のLLM判定を組み合わせた発展編です。get_assert関数の内部でAnthropic APIを直接呼び出し、簡潔さ・正確さ・トーンの3項目を1〜5点で採点させ、平均点が4.5点以上かをpass/failとして返します。組み込みのllm-rubricでは表現しにくい、複数項目の平均によるしきい値判定のような採点基準を作りたいときの実装パターンです。

つまずきやすいポイント

• CoTを使うと採点ロジックが増える: <thinking>と<answer>を分けるプロンプトは精度が上がりやすい一方、正規表現で最終回答を抜き出す処理を必ず書く必要があります
• 少数データでのスコアは参考値: コース内の評価はどれも十数件程度のテストケースで、公式ノートブックも複数のレッスンで「データセットが小さすぎる」という注記を繰り返しています。100件以上での再評価が前提です
• 判定者モデルにも好みや偏りがある: LLM採点は柔軟な基準を扱える一方、判定用モデルの選び方や基準文の書き方次第で結果がぶれるリスクがあります
• モデル名は書き換えが必要: providers欄のclaude-3-haiku-20240307などはコース公開時点のモデル名です。実際に試すときは、自分が使いたい現行モデルの名前に置き換える前提で読みます

まとめ

prompt_evaluationsコースは、評価の考え方を「入力・正解・出力・スコア」という4要素に分解し、人手採点・コード採点・LLM採点それぞれの実装をノートブック形式で追える教材です。リポジトリは2026年9月にアーカイブされ、更新は止まりました。それでも、動物の脚チュートリアルで示された「出力形式を先に固定し、それでも解けない論理的な誤りにCoTを当てる」という進め方や、promptfooのYAML設定パターンは今でもそのまま使えます。モデル名だけを現行のものに読み替えれば、社内プロンプトの評価基盤を作る出発点として十分に機能します。