本文へスキップ
もと @moto_ai_jp

第4部 ハーネス · 第10回 / 全20回 · 15分くらい

合格を測る。テスト・AIの採点・評価セット

入門編では「合格の条件を先に決める」を学びました。実践編では、その条件を実際に測る道具をそろえます。測れない改善は、本当に改善なのかわかりません。この回では、Anthropic の評価の記事と、AIに採点させるときの偏りの研究を根拠に進めます。

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20

履修 0 / 20 回

この回を読み終えると、できるようになること

  1. 採点のやり方3種類(コード・AI・人)の向き不向きを説明できる
  2. AIに採点させるときの偏りを3つ挙げ、それぞれの対策を言える
  3. 実際の失敗から評価セットを作り、指示を変えたときに回せる

専門用語は、初めて出たところで括弧に短い説明を付けています。説明が長くなるものには ※番号を付け、ページの終わりの用語メモにまとめました。

1採点のやり方は3種類

Anthropic の記事「Demystifying evals for AI agents」では、採点のやり方を3つに分けています。

採点例良いところ弱いところ
コードで採点文字列の一致、テスト、型の確認、文字数、禁止語速い、安い、毎回同じ結果決まった形でしか測れない
AIで採点採点基準(ルーブリック※1)に沿った判定、2つを並べて比べる柔軟、自由な文章も測れる結果がゆれる、費用がかかる、人に合わせた調整が要る
人が採点専門家の確認、抜き取り検査いちばん確か遅い、高い

上から順に、安く、速く、ぶれません。コードで測れるものを、AIの採点に回さないのが基本です。

⚫⚪白黒がつく「良い感じ」はだめ💬理由が言えるなぜ落ちたか🔧直し方がわかるAIが自分で直せる👀測れないもの面白さ・信頼は人が測れるものの例:長さ・数・あるかないか・決めた形か・禁止したものが入っていないか→ 作る前に決める。あとから決めると、出てきたものを見て甘くなる
3つの性質がそろって、はじめてAIが自分で直せます。

2AIに採点させるときの偏り

AIの採点は便利ですが、くせがあります。Zheng らの研究(2023)は、AIに採点させたときの偏りとして、次の3つを挙げています。

  • 順番の偏り:2つを並べて比べさせると、先(または後)に出したほうを選びやすい
  • 長さの偏り:中身が同じでも、長い答えを高く評価しやすい
  • 自分びいき:自分(同じモデル)が書いた答えを高く評価しやすい

一方で同じ研究は、強いモデルの採点が人の好みと8割以上一致し、人同士の一致と同じくらいだったとも報告しています。くせを知って対策すれば、十分に使える道具です。

3偏りへの対策

  • 「良いか悪いか」ではなく、項目ごとの「はい/いいえ」にする。5段階評価は、AIでも人でもぶれます。「見出しは3つか」「根拠の引用が原文にあるか」のように分けます
  • 根拠を引用させる。採点の理由として、答えのどこを見たかを書かせます。第4回の3段目の検査がそのまま使えます
  • 並べて比べるときは、順番を入れ替えて2回採点する。2回で結果が割れたら、引き分けか人が見る扱いにします
  • 作った会話とは別の会話で採点する。同じ会話の中では、自分が作ったものに甘くなりがちです

4評価セットは、実際の失敗から20〜50件

評価セット※2は、何百件も要りません。Anthropic の記事には「実際の失敗から取った20〜50件の単純な課題で、十分なスタートになる」と書かれています。作り始めのころは、1つの変更で結果がはっきり変わるので、少ない件数でも違いが見えるからです。

集め方は、すでに手で確かめていることから始めます。失敗した入力、人から指摘された出力、自分が毎回目で確かめている項目。これを「入力」と「期待する結果(または合格の条件)」の組にして保存します。置き場所は、一時フォルダではなく、履歴の残る場所にします。

52種類の評価:伸ばすための評価と、壊していないかの評価

同じ記事は、評価を2つに分けています。

  • 伸ばすための評価:まだうまくできないことを集めたもの。通る割合が低いところから始まり、改善の目標になる
  • 壊していないかの評価(回帰テスト※3):今できていることを集めたもの。ほぼ100%通るのが当たり前で、下がったら何かが壊れた合図

伸ばすための評価で満点が続くようになったら、その課題は「壊していないか」のほうに移します。満点が続く評価は、もう改善の手がかりになりません。

6何回試すかで、指標の意味が変わる

AIの答えはゆれるので、1つの課題を何回か試します。そのときの数え方が2つあります。

  • pass@k:k回のうち、1回でも成功する割合。何案か出して良いものを選べる仕事向け
  • pass^k:k回すべて成功する割合。毎回同じ品質が要る仕事向け

1回あたりの成功率が75%なら、3回すべて成功する割合は 0.753 ≒ 42% です。定時に動く仕組みのように「毎回ちゃんと動いてほしい」ものは、pass^k で見るほうが実態に近くなります。

7比べるときは条件をそろえる。そして、測れないものは測れないと書く

指示を変えて比べるときは、変えたところ以外(モデル、入力、試す回数)をすべてそろえます(第5回の対照実験)。数字が出たら、何が効いてその数字になったのかまで説明できると、次に活かせます。

自分は、文脈に情報を差し込む道具の効き目を測ったとき、日本語の6つの課題で、標準の差し込みではトークンが3%増え、自作の差し込みでは10%減る、という結果を得ました。数字だけでなく「標準のほうは日本語の依頼で何も見つけられず、案内文だけを足していた」という原因まで確かめたことで、どちらを使うか決められました。

そして、面白いか、信頼できるか、相手を傷つけないか、のように測れないものは、無理に数字にしません。人が見る項目として、はっきり残しておきます。測りやすいものだけを良くしていくと、測れない大事なものが置き去りになります。

誤解よくある思い違い

評価セットは何百件もないと意味がない

作り始めは、実際の失敗から取った20〜50件で十分です。変更の効き目が大きい時期は、少ない件数でも差が見えます。

AIに5段階で採点させれば、細かい違いまでわかる

5段階はぶれやすく、長い答えや自分の答えをひいきする偏りもあります。項目ごとの「はい/いいえ」に分けます。

満点が続いているなら、その評価は役目を終えた

改善の手がかりにはなりませんが、「壊していないか」を見る回帰テストとして使い続けます。

演習手を動かして確かめる

演習1

2つの要約のどちらが良いかを、AIに比べさせています。いつも、先に見せたほうが選ばれている気がします。どう確かめ、どう直しますか。

答えを見る

順番を入れ替えて、同じ組をもう一度採点させます。入れ替えると結果も入れ替わるなら、中身ではなく順番で選んでいることになります。直し方は、①毎回2回(順番を入れ替えて)採点し、割れたら引き分けにする、②「どちらが良いか」ではなく「要点を3つ含むか」「400字以内か」のように、それぞれを項目ごとに「はい/いいえ」で採点する、のどちらかです。

演習2

朝のまとめを作る仕組みの評価セットを作ります。最初に入れる項目を3つ考えてください。コードで採点できるものと、AIで採点するものを分けてください。

答えを見る

例:

  • コードで:今日の日付の予定がすべて含まれているか(予定の一覧と文字列で照らし合わせる)
  • コードで:数字(件数など)が元のデータと一致するか
  • AIで:「今日の重点」が、予定か直近の作業の記録に根拠があるか(根拠の引用を求め、引用は原文にあるかをコードで確かめる)

根拠のない話題を出していた、という実際の失敗の入力を、必ず1件入れておきます。

頼み方そのまま使える頼み方の例

次の作業の合格条件を、3種類の採点に分けて設計してください。
1. コードで採点できるもの:確かめ方も書く
2. AIに採点させるもの:「はい/いいえ」で答えられる質問の形にし、根拠の引用を求める
3. 人が見るもの:なぜ機械では測れないのかを一言で
最後に、評価セットに最初に入れるべき入力を5件提案してください。実際に失敗した入力があれば、それを優先してください。

作業:(ここに書く)
実際に失敗した例:(あれば貼る)

用語メモ本文の ※番号の説明

  1. ※1ルーブリック 採点の基準を、項目と合格の条件の一覧にしたもの。「見出しが3つある」「専門用語に説明がある」のように、1つずつ確かめられる形で書く。 本文へ戻る ↩
  2. ※2評価セット 「この入力なら、こういう結果になってほしい」という組を集めたもの。指示やモデルを変えたときに回して、良くなったか、悪くなったところはないかを確かめる。 本文へ戻る ↩
  3. ※3回帰テスト 今まで動いていたものが、変更のあとも同じように動くかを確かめるテスト。「前は動いていたのに壊れた」(回帰)を見つけるのが目的。 本文へ戻る ↩

出典確かめた資料(2026年10月時点)

読めたらチェック

この回:0 / 3