Evals（評価）とは
最終更新: 2026年8月12日
プロンプトを直した。モデルを新しくした。道具を1つ足した。 で、良くなったんでしょうか。
この問いに「たぶん」以外で答えられるようにするのがEvals（評価）です。 2026年に入ってから「いちばんの課題はEvalsだ」という声が あちこちで上がっているのは、多くの現場がここで詰まっているからです。
なぜ「感想」では足りないのか
AIの出力は、同じ入力でも毎回少しずつ変わります。 だから2〜3回試して良さそうに見えたというのは、 良くなった証拠になりません。たまたま良い方に転んだだけかもしれないからです。
実際によく起きるのは、次のような事故です。
- 直した箇所は直ったが、別の場所が壊れた。 「もっと簡潔に」と指示を足したら、必要な情報まで落ちるようになった。
- モデルを新しくしたら、一部の使い方だけ悪化した。 全体には賢くなっているので、気づくのに時間がかかります。
- 気づいたのはユーザーからの指摘だった。 いちばん高くつくパターンです。
評価があると、これが「20件中18件合格だったのが15件に落ちた」という 形で見えます。感想と違って、前回と比べられるのがいちばんの効用です。
評価は4つの部品でできている
| 部品 | 中身 | 最初にやること |
|---|---|---|
| 課題の集まり | 「この入力に対して、こうなってほしい」の一覧 | 過去に失敗したケースを3つ書き出す |
| 採点のしかた | 合格・不合格をどう決めるか | ルールで測れるものから始める |
| 回す仕組み | まとめて実行して結果を並べる | 手で20回叩くのでもいい。まず回す |
| 本番からの持ち帰り | 実際に起きた失敗を課題に追加する | 失敗したやりとりを1件、課題に足す |
きれいに揃える必要はありません。4つめが回り始めると、 評価はひとりでに育ちます。本番で起きた失敗を毎回1件ずつ足していくだけで、 半年後には自分の用途に固有の課題集になっています。
採点のやり方は4種類
「AIに点数をつけさせる」ばかりが注目されますが、 ルールで測れるものはルールで測ったほうが速くて安くて確実です。
| やり方 | どう判定するか | 向いているもの | 費用 | 気をつけること |
|---|---|---|---|---|
| 完全一致・含む | 決まった答えと一致するか、特定の語を含むか | 分類、抽出、形式の判定。答えが1つに決まるもの | ほぼ0 | 言い換えを間違いと判定してしまう |
| ルールで判定 | JSONとして読めるか、文字数が範囲内か、禁止語が入っていないか | 出力の形式、長さ、必須項目の有無 | ほぼ0 | 中身の良し悪しは測れない |
| AIに採点させる | 別のAIに基準を渡して点をつけさせる | 文章の質、指示に従えているか、丁寧さ | 評価のたびに課金される | 採点役も間違える。基準を具体的に書かないとブレる |
| 人が見る | 自分で読んで、合否をつける | 最終確認。他の採点方法が正しいかの検証 | 時間 | 件数を増やせない。だから他の方法と組み合わせる |
採点役のAIも間違えます。 使い始める前に、自分で採点した10件と突き合わせて 同じ結論になるか確かめてください。ここを飛ばすと、 信用できない採点を根拠に判断を続けることになります。
最小の評価を、いま1つ作る
完璧な評価を作ろうとすると、たいてい何も作らずに終わります。 次の手順なら30分で1つできます。
- 失敗したケースを3つ思い出して、書き出す。 入力と「本当はこうなってほしかった」をセットで。 新しく考える必要はありません。過去に困ったことがそのまま課題になります。
- 合格の条件を1行で書く。 「JSONとして読める」「300文字以内」「日付が含まれている」など、 迷わず判定できるものを選びます。
- 3件を流して、いまの合格数を記録する。 これが基準になります。低くてかまいません。
- 何か直したら、また流す。 合格数が下がったら、その変更は失敗です。戻します。
- 本番で失敗が出たら、1件足す。 これで同じ失敗は二度と見逃さなくなります。
0件と3件の差は、3件と100件の差よりずっと大きいです。 3件でも、「同じ失敗が再発したか」だけは確実に判定できるようになります。
評価を回す費用
毎回まとめて流すので、費用が気になるところです。目安を出しました。
前提：課題20件。1件あたり、課題文と指示で約2,000トークンを送って約700トークンが返り、 それを採点役に渡して短い判定が返る、という2回の呼び出し。 単価は仮に入力$3・出力$15（100万トークンあたり）としています。
| 費用 | |
|---|---|
| 1回まわす（20件） | $0.50 |
| 平日に毎日まわす（月20回） | $10.02 |
月あたり$10.02。1回の事故で失う時間より、はるかに安いはずです。 それでも減らしたいなら、ルールで判定できるものを増やすのがいちばん効きます。 採点役への呼び出しが減れば、費用はほぼ半分になります。
自分の課題文が何トークンになるかはトークン数の計算で数えられます。 会話が長いほど費用が伸びる仕組みは コンテキストエンジニアリングで計算しています。
やりがちな失敗
本番と違う条件で測る
評価では短いプロンプトを使い、本番では長い履歴が乗っている。 これでは測っている対象が違います。 評価は本番と同じ条件で流すのが原則です。
点数を上げることが目的になる
評価に載っている課題だけ通るように調整していくと、 評価では満点、実際は改善していないという状態になります。 本番で起きた失敗を足し続けることが、これへの唯一の対策です。
1回の結果で判断する
出力は毎回変わるので、20件中18件と17件の違いは誤差かもしれません。 大きく動いたときだけ意味があると考えるほうが安全です。 同じ条件で2回流してみると、どれくらい揺れるのかがわかります。
層のなかでの位置づけ
評価は、AIエージェント設計の5つの層のうちいちばん外側（ハーネス）にあたります。 権限や記録と同じく、仕事を任せられる状態にするための部品です。
- AIエージェント設計の5階層マップ — 全体像と、症状からの切り分け
- ハーネスエンジニアリング — 評価を含む外側の設計
- サブエージェント — 作る役と確かめる役を分ける設計
- トークン数の計算 — 評価にかかる量を見積もる
本記事は2026年8月時点で見られる用語の使われ方と一般的な手法を整理したものです。評価の設計は用途によって大きく変わり、ここで示した費用は記載した前提とトークン単価にもとづく概算です。特定のツールやフレームワークを推奨するものではありません。