レッスン5: 評価セット: 現実のタスク20件から始める

学習目標:

• 「ケースが数百件たまるまで待つ」がなぜ誤りなのか、そして序盤の変更は効果量が大きいので数件のケースでもバージョンを見分けられるのはなぜかを説明する
• 次の原則に沿って評価ケースを一括で設計する。現実の利用に根ざす、エッジケースで補う、可能なら採点を自動化する、1件あたりの質より件数、曖昧なケースを意図的に含める——そのそれぞれを検証可能な結果と対にする
• ホールドアウトセットを使って、プロンプトを「この問題だけ通るモデル」に過学習させることを防ぎ、自動評価では見えず手動テストでしか捕まらない問題を見分ける

前提: レッスン1〜4（「完了に見える」≠ 完了、終状態優先の検証対象、決定的検証、LLM ジャッジ） | 前: << レッスン4 | 次: レッスン6 >>

遅延させる、とりわけよくある理由

この場面は見たことがあるはずです。誰かが提案します。「うちのエージェント用に評価セットを作るべきだ」。別の誰かが応じます。「評価セットって統計的に有意になるには数百件必要でしょう？ 10件や20件回しても出てくるスコアは無意味で、情報より誤解のほうが多い。まず実際のユーザーケースを集めて、十分たまってから作りましょう」。

プロフェッショナルに聞こえます。規律正しくも聞こえます。そして半年が過ぎ、ケースは共有ドキュメントに寝たままで、プロンプトは30回改訂され、どの改訂が改善でどれが後退だったのか誰も言えません。

Anthropic のマルチエージェント・リサーチシステムに関するエンジニアリングの振り返りは、この言い訳を名指しで否定しています。AI 開発チームが評価の作成を先送りするのは、数百件のテストケースを持つ大きな評価だけが有用だと信じているからだとよく耳にするが、実際には先送りせず、少数の例で今すぐ小規模なテストを始めるのが最善である¹。

このレッスンはまさにそこをはっきりさせます。なぜ序盤は小さなセットが本当に機能するのか、1件のケースはどんな形をしているべきか、それらのケースをどう選ぶか、そして「このエージェントをこの問題だけの専門家に仕上げてしまう」ことをどう防ぐか。

効果量: なぜ序盤は少数のケースで差が見えるのか

まず用語から。効果量とは、ある変更による差がどれくらい大きいかを指します——71.2% から 72.4% への移動なのか、それとも 30% から 80% への跳躍なのか。差が大きいほど必要なサンプルは少なく、差が小さいほど多く必要になります。神秘的な話ではなく、2杯の水のどちらが熱いかを判断するときと同じ常識です。30度違えば触れば分かり、0.5度の違いには温度計が要ります。

エージェント開発の序盤は前者に属します。公式の振り返りは平易に述べています。エージェント開発の初期では、手の届く果実が豊富にあるため、変更は劇的な影響を持つ傾向がある。プロンプトを少しいじるだけで成功率が 30% から 80% に上がることもあり、これほど効果量が大きければ、テストケースが数件あるだけで変化を見つけられる¹。

こんな場面を想像してください。ケースが6件あり、変更前は2件通り、変更後は5件通った。p値が必要でしょうか。要りません。必要なのは、このバージョンのプロンプトを確定させ、次の「30% から 80%」の改善を探しに行くことです。

彼らが出発点にした規模も謎めいたものではありません——現実の利用パターンを代表するクエリ20件ほどのセット¹。20 は魔法のしきい値ではなく、単に午後いっぱいで書き終えられて、その日のうちに使い始められる量だというだけです。

逆も成り立ちます。エージェントがすでに 80% 台にいて、残る変更が針を1〜2ポイントしか動かさないなら、数件のケースでは本当に見分けられません。その時点では件数を増やす必要があります——しかしそのころには機能する評価セットがすでに手元にあり、拡張するのはゼロから作るよりはるかに簡単です。まずものさしを手に入れ、それから精度の話をする。ものさしが精密になるのを待ってから測り始めるのではありません。

評価ケース1件の最小構成

評価セットは「プロンプトの寄せ集め」ではありません。プロンプトの寄せ集めでできるのは出力を目視することだけで、2回読めば飽き、3回読めば自分を欺き始めます。

ツールエンジニアリングの記事は直截です。各評価プロンプトは検証可能な応答または結果と対にすべきであり、検証器は正解と生成された応答の完全一致比較という単純なものから、Claude に応答を判定させるという高度なものまであり得る²。これはレッスン2の成功基準、レッスン3の決定的検証、レッスン4の LLM ジャッジに直結します——それらのレッスンが教えたのは「どう検証するか」で、このレッスンが教えるのは「何を検証するか」です。

つまり使い物になるケース1件には、少なくとも3つの構成要素が明記されている必要があります。

prompt   : エージェントへの入力（ユーザーが実際に言うとおりに書く）expected : 検証可能な結果（終状態、文字列、状態変化、またはルーブリック）verifier : 誰が判定するか——決定的検証器か LLM ジャッジか

データとして構造化すると、こうなります。

ここでの expected フィールドが記述しているのは終状態と観測可能な証拠であって、「エージェントが辿るべき思考の順序」ではありません。レッスン2の結論はここでも生きています。同じゴールに対してエージェントは複数の妥当な経路を取り得るので、経路をハードコードしないこと。ツールエンジニアリングの記事も、エージェントが各ツールの目的を掴めているかを測るために、呼ぶと期待するツールを任意で指定できるが、正しく解く経路は複数あり得るので、過剰に指定したり特定の戦略に過適合したりしないよう注意せよ、と念を押しています²。

mustCallTools フィールドを見て、レッスン2の expectedTools を思い出したかもしれません。この2つの関係ははっきりさせておく価値があります。否定的なアサーション（mustNotContain、mustNotCallTools——「変更しておきました」と言わない、注文番号を推測して照会しない）は本質的に終状態のガードレールで、「起きてはいけないことが起きなかった」を記述するものなので、厳格に強制できます。肯定的なツールのアサーション（あるツールを必ず呼んだこと）はレッスン2の軌跡アサーションであり、あの3つの規律がそのまま適用されます。集合への所属だけをアサートすること、本当に気にかけている1〜2個のツールだけを挙げること、そしてアサーションが落ちても終状態が通っているなら、即座にケースを失敗させるのではなく観測として記録すること。硬くなるのは1つの場面だけです。応答の中の鍵となる情報が、そのツールの戻り値からしか来得ない場合です。ケース cs-003 はまさにこの型で、「発送済み」という判断は getOrder からしか来得ないので、ツールが呼ばれていないならその記述は捏造であり、この肯定的アサーションは強制可能になります。迷ったらソフト扱いにしてください。

もう1点。このケースの mustNotContain には「変更しておきました」が入っています——エージェントが口頭では住所変更に同意しながら、実際には何もしていない事態を防ぐためです。この「口先だけの完了」こそ、レッスン1のテーマそのものです。

評価セットを設計する5つのルール

以下の5つのルールは、Claude プラットフォームの「テストと評価」ドキュメントの設計原則と、ツールエンジニアリングの記事の実践を、1つのチェックリストにまとめたものです——各ルールの後ろの引用がその出所を示します。

その1: 現実の利用に根ざす。 現実世界での使われ方に根ざした評価タスクを大量に生成すること²。現実世界のタスク分布を映す評価を設計すること³。判定基準は単純です。このプロンプトが実際のログからコピーされたものでないなら、それを指して「先週これとまったく同じことを3人のユーザーが聞いてきた」と言えますか。言えないなら、たぶん机に座って想像したものです。

その2: エッジケースを落とさない。 公式ドキュメントは「現実世界のタスク分布を映す」のすぐ後に、エッジケースを織り込むのを忘れないように、と付け加えています³。現実の分布が本体で、エッジケースは保険です。エッジケースだけで構成された評価セットはあなたを誤らせます——月に2回しか現れない問題の修正に、1か月を費やすことになります。

その3: 可能なら採点を自動化する。 自動採点が可能になるように問題を構成すること。たとえば多肢選択、文字列一致、コードによる採点、LLM による採点です³。これがあなたの評価セットを繰り返し実行できるかどうかを決めます。合否を判断するのに5分読む必要があるケースは、10件書いた時点で二度と回したくなくなります。

その4: 質より件数を優先する。 公式の言い回しはこうです。シグナルがやや弱くても自動採点できる問題が多いほうが、人手で丁寧に採点する高品質な評価が少数あるより良い³。これが最も直感に反し、同時に最も時間を節約します——1件のケースの採点基準を完璧に磨く時間があるなら、ケースを10件書き足してください。

その5: 曖昧なケースを意図的に集める。 ドキュメントは含める価値のあるテストケースの一種を明示的に挙げています。人間でも評価の合意に達するのが難しい曖昧なテストケースです³。これらはスコアを上げるためのものではなく、意見の不一致を浮かび上がらせるためのものです。エージェントがこれらのケースでぐらつくなら、それはプロダクトレベルのルール自体が固まっていないというシグナルであり、プロダクト側が解決すべきことで、プロンプトエンジニアリングで直せるものではありません。

もう1点、「設計原則」ではないが同じくらい重要なことがあります。評価環境を単純にしすぎないでください。ツールエンジニアリングの記事は、十分な複雑さでツールを負荷試験しない、単純すぎたり表層的だったりする「サンドボックス」環境は避けるよう勧めています。強い評価タスクは複数回、場合によっては数十回のツール呼び出しを必要とすることがあります²。データベースへの1回の問い合わせで答えられる問題は、7回目のツール呼び出しであなたのエージェントがコンテキストを見失うかどうかを明らかにしません。

ホールドアウトセット: プロンプトを「この問題だけ得意」に仕上げない

きちんと20件のケースを作り、プロンプトの調整を始めたとします。最初のバージョンは8件通り、1回改訂して12件、もう1回で16件、さらに19件。素晴らしい。

問題は、その19件のうち、どれだけがエージェントが本当に強くなったことによるもので、どれだけがあなたがこの20問の特徴をこっそりプロンプトに埋め込んだ結果なのか、という点です。たとえばケース7がいつも落ちるのに気づいて、システムプロンプトに1行足す。「返品に関する問い合わせでは7日間無条件返品ポリシーを優先的に引用すること」——ケース7は通るようになりますが、あなたが実際にやったのは、その問題の答えを書くことです。

この現象を過学習と呼びます。モデル（この文脈ではプロンプトとツールの構成全体）が、タスク自体の規則性ではなく、訓練材料の特徴を学んでしまうことです。

ツールエンジニアリングの記事が示す対処は一文ですが決定的です。彼らは「訓練用」の評価に過適合していないことを確かめるために、ホールドアウトのテストセットに頼りました²。

ホールドアウトセットとは、最初から取り分けておき、日々の調整では見ない・回さない・触らない一群のケースです。その価値はすべて「汚染されていないこと」から来ます。チームの取り決めとして明文化する価値のある規律がいくつかあります。

• マイルストーンでのみ回す。 日々のプロンプト調整では dev セット（先ほどの引用にある「訓練用」の評価。このレッスンでは dev セットと呼び、JSON フィールドでは dev と記録します）だけを回します。ホールドアウトセットを回すのは、リリース前か構造的な変更（モデルの切り替え、ツール説明の書き直し、ハーネスのループの変更）の後だけです。
• 集計値だけを見る。 全体の合格率と、落ちたケースの ID を確認するだけにします。落ちたホールドアウトのケースを1件ずつ開いて、全文のトランスクリプトをデバッグしてはいけません。特定のホールドアウトのケースを直すためにプロンプトを変更した瞬間、そのケースはすでに dev セットの一部になっています。
• 汚染したら退役させる。 ある問題のデバッグでホールドアウトのケースを何件か本当に開いてしまったなら、それらを dev セットに統合し、新しいホールドアウトのケースを補充します。ホールドアウトセットは消耗品であって、家宝ではありません。
• 誰がアクセスできるかを文書化する。 小さなチームほどこれを飛ばしがちです。「ホールドアウトセットの実行はリリース前に1人が行い、結果はチャンネルにスコア1行だけ投稿する」と取り決めるほうが、「各自で気をつける」という口約束よりはるかに効きます。

よくあるエンジニアリングの実践に触れておきます。評価を CI につなぎ、コミットごとに dev セットを自動実行し、前のバージョンとスコアを比較し、下がったらブロックするというものです。これは標準的なエンジニアリングの実践で、どう組むかはあなたのパイプライン次第なので、このコースでは展開しません——レッスン6では「実際に動く評価トラック」を作ります。それを CI につなぐかどうかはあなたの選択です。

自動評価が見逃し、人間が捕まえるもの

評価セットができて、回っていて、スコアも良い。では人間によるテストは外せるでしょうか。

外せません。公式の振り返りは明示しています。自動評価がある世界でも、手動テストは依然として不可欠である¹。理由は、エージェントをテストする人間が、評価の見逃すエッジケースを見つけるからです——珍しいクエリでの幻覚的な回答、システム障害、あるいは微妙なソース選択のバイアスなどです¹。

3つめのカテゴリはとりわけ典型的なので、特筆に値します。彼らの人間テスターはこう気づきました。初期のエージェントは、学術 PDF や個人ブログのような権威はあるが検索順位の低いソースよりも、SEO 最適化されたコンテンツファームを一貫して選んでいた¹。

このバイアスがどう見えるかを考えてみてください。個々の事例はどれも問題なく見えます——エージェントは引用付きで出典のある、もっともらしい回答を返します。ファクトチェックは通り、引用フォーマットも通り、完全性も通り、あなたの採点次元のどれも問題を捕まえません（レッスン4の「ソースの品質」次元がたまたまルーブリックに入っていて、その基準が十分に鋭くない限りは）。しかし100件の出力をまとめて眺めるとパターンが見えます。最も見つけやすい種類のコンテンツを、系統的に選んでいるのです。

この種のパターンをあなたの評価セットが事前に見ることはできません。評価セットは、あなたがすでに知っている失敗モードに基づいて書かれるからです——思いついていないモードには、当然それを守るケースがありません。手動テストは評価の代わりではなく、評価セットに新しい項目を供給するものです。この種のパターンを見つけるたびにケースとして明文化すれば、次回からは自動的にチェックされます。

もう1つ、自然に評価セットに属する種類があります。ドキュメントが明示的に「保証されない」と述べている挙動です。ツール利用のドキュメントが良い例を提供しています——ユーザーのプロンプトに、あるツールの必須パラメータをすべて埋めるだけの情報が含まれていない場合、Claude Opus はパラメータが欠けていることを認識してそれを尋ねる可能性がはるかに高い。しかしドキュメントはすぐに、この挙動は保証されない、とくにより曖昧なプロンプトや能力の低いモデルでは保証されない、と明確にしています⁴。

「可能性がはるかに高い」と「保証されない」はシグナルです。これがあなたのシナリオで成り立つかどうかは、自分でテストするしかありません。プロダクトのロジックが依存しているのに、ドキュメントが確率的にしか記述していない挙動は、数件のケースで継続的に監視する価値があります。

評価セットはものさし: まずものさしを手に入れる

このレッスンをまとめ直します。

ツールエンジニアリングの記事が示す順序はこうです。まずツールの素早いプロトタイプを立ち上げてローカルでテストし、次にその後の変更を測定するために包括的な評価を回す²。「その後の変更」に注目してください——評価は現状にスコアを付けて終わりにするためのものではなく、その価値はその後のすべての変更を測定可能にすることにあります。それがあれば、「このバージョンのプロンプトのほうが良い」は感覚から結論に変わります。

エージェント構築の記事はさらに踏み込みます。他のあらゆる LLM 機能と同じく、成功の鍵は性能を測定し実装を反復することであり、繰り返すが、複雑さを足すことを検討すべきなのは、それが結果を明らかに改善するときだけである⁵。

この一文は文脈と合わせて読むと重みを持ちます。これまでの9つのコースで学んだ手法——マルチエージェントの分業、メモリシステム、コンテキストの圧縮、チェックポイントからの復旧——はどれも複雑さを足します。評価セットがなければ「これを足して本当に良くなったのか」に答えられないので、直感で足すしかなく、直感で足すということは足し続けるということです。評価セットは、凝った設計を取り除くための証拠です。

どれくらいあれば十分か: 数値の答えはない

最後に規模について一言。

このコースが引用するすべての一次資料を検索しましたが、「評価セットが十分と言えるのは何件からか」というしきい値を与えているものは1つもありません。あるのは出発点の規模（現実のクエリ20件ほど）と方向性の指針（1件あたりの質より件数）だけです。ですからその数字を探しに行かないでください。そして「最低50件」などと気軽に言う人を信用しないでください。

本当の判定基準は、このレッスンの冒頭で述べたことです。いまのあなたの変更の効果量に対して、手持ちのケースはまだそれらを見分けられるか。

• バージョンを変えたら合格数が6から15に跳ねた——十分です、そのまま進めてください。
• バージョンを変えたら合格数が17と18の間で揺れ、2回回すと違う結果が出る——いまは不十分です。ケースを足すか、採点方法のノイズを減らす（レッスン4のジャッジの一貫性に戻る）ときです。
• 比べたい2つのアプローチの差がケース1件分しかない——それは「どちらが良いか」という問題ではなく、「あなたのものさしではこの差を分解できない」という問題です。

ケース数は分解能の必要に従うのであって、心理的な数字に従うのではありません。

このケース群を実際にどう回すか——タスクごとに1ループ、採点をどう階層化するか、合格率以外に何を追跡するか——はレッスン6です。このレッスンから持ち帰るべきなのは、ケース群そのものです。

💻 演習

まとめ

• 「ケースが数百件たまるまで評価セットを作らない」は最もよくある先送りの言い訳で、公式の振り返りはこれを名指しで否定しています。数百件を持つ大きな評価だけが有用だと信じてチームは評価の作成を先送りするが、正しいやり方は少数の例で今すぐ小規模なテストを始めることです¹。
• 序盤に小さなセットが本当に機能する根拠は効果量です——プロンプトを1回いじるだけで成功率が 30% から 80% に上がることがあり、それほど大きな差なら数件のケースで見分けられます。彼ら自身も現実の利用パターンを代表するクエリ20件ほどのセットから始めました¹。
• 評価タスクは現実世界での使われ方に根ざすべきであり²、現実世界のタスク分布を映し、エッジケースを織り込むべきです³。同時に単純すぎるサンドボックス環境は避けること。強い評価タスクは複数回、場合によっては数十回のツール呼び出しを必要とすることがあります²。
• 自動採点が可能になるように問題を構成し（多肢選択、文字列一致、コードによる採点、LLM による採点）³、質より件数を優先します——シグナルがやや弱くても自動採点できる問題が多いほうが、人手で丁寧に採点する高品質な評価が少数あるより良いのです³。
• 人間でも評価の合意に達するのが難しい曖昧なテストケースを意図的に集めること³。これらはスコアを上げるためではなく、プロダクトのルール自体にある意見の不一致を浮かび上がらせるためのものです。
• 各評価プロンプトは検証可能な結果と対にすべきで、検証器は完全一致の文字列比較から Claude をジャッジに立てるものまで幅があります²——これはレッスン2、3、4に直結します。
• ホールドアウトのテストセットは過学習を防ぎます。「訓練用」の評価に過適合していないことを確かめるために、それに頼るのです²。中核の規律は、日々は見ない、集計値だけを見る、汚染したら退役させる、の3つです。
• 自動評価には固有の盲点があります。エージェントをテストする人間は、評価の見逃すエッジケースを見つけます。珍しいクエリでの幻覚的な回答、システム障害、微妙なソース選択のバイアスなどです¹。実例は、初期のエージェントが学術 PDF や個人ブログのような権威はあるが検索順位の低いソースよりも、SEO 最適化されたコンテンツファームを一貫して選んでいたというものです¹。自動評価があっても、手動テストは依然として不可欠です¹。
• ドキュメントが明示的に「保証されない」と述べている挙動は、自然に評価セットに属します。たとえばモデルが欠けた必須パラメータを自分から尋ねるかどうか——ドキュメントはこの挙動が保証されない、とくにより曖昧なプロンプトや能力の低いモデルでは保証されない、と述べています⁴。
• 評価セットの価値は、その後のすべての変更を測定可能にすることです。その後の変更を測定するために包括的な評価を回すこと²。成功は性能を測定し反復することにかかっており、複雑さを足す価値があるのは、それが結果を明らかに改善するときだけです⁵。
• 「どれくらいあれば十分か」の数値のしきい値を与える一次資料はありません。判定基準はこうです。いまのあなたの変更の効果量に対して、手持ちのケースはまだそれらを見分けられるか。見分けられなくなったときが、拡張するときです。

>> レッスン6: ハンズオン: エージェント用の評価トラックを構築する