3行でいうと

  • 両社の文書とも、評価は「本物の入力に近いテスト」を「自動で採点できる形」で持つことを勧めています。
  • 採点は、速く確実な方法（完全一致などのコード判定）を先に検討し、AIによる判定は、信頼できると確かめてから使います。
  • OpenAIのEvals（評価の管理画面とAPI）は2026年10月31日に読み取り専用、11月30日に停止予定です。
  • 10問程度のテストは、小さな差を見分けられません。差がはっきり出たものだけを信じます。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。

先に結論

前提：何を「回帰」と呼ぶか

手順：10問から始めて、育てる

AnthropicとOpenAIの文書の共通点を、僕らが手順の形に整理しました（見立てです）。

  1. 目的を一文で書く。 Anthropicは、成功の基準を「具体的で測れるもの」にするよう勧めています。例は「感情分類の精度がよい」ではなく、「多様な1万件の投稿で、F1スコア（適合率と再現率をまとめた指標）が0.85以上」です。
  2. 入力を10問集める。 実際に使われた入力、実際に失敗した入力から選びます。OpenAIは、開発中のログを残し、そこから評価の事例を拾うよう勧めています。テストの分布が実際の利用と離れることを、アンチパターンとしています。
  3. 境界の例を混ぜる。 Anthropicが挙げる例は、関係ない入力、長すぎる入力、人間でも判断が割れる曖昧な入力です。OpenAIは、典型的な例、境界の例、悪意のある入力の例を入れるよう書いています。
  4. 合格の条件を、先に決める。 「正しい答え」が決まる課題なら、正解を持ちます。決まらない課題は、守るべき条件（例：JSONの形である、特定の語を含む、禁止語を含まない）に分けます。
  5. 採点を自動にする。 次の節で詳しく書きます。
  6. 回して、結果を保存する。 保存した結果が、次の変更との比較の土台になります。
  7. 変更のたびに回す。 プロンプトを直す、モデルを替える、検索の設定を変える、のどれでも回します。
  8. 失敗を足していく。 本番で見つけた失敗を、そのたびにテストセットに足します。

採点方法の選び方

Anthropicの文書は、採点方法を3つ挙げ、コード判定を「最も速く確実で、とても拡大しやすい」と説明しています。文書の並びは、コード判定、人間による判定、AIによる判定の順です。下の表は、読みやすいよう速い順に僕らが並べ替えました。

方法 長所 短所 例（文書より）
コード判定 最速で確実、大量に回せる 微妙な判断ができない 完全一致、文字列を含むか
AIによる判定 速く柔軟、複雑な判断にも使える 先に信頼性を確かめる必要がある 基準表（ルーブリック）で採点
人間による判定 最も質が高く柔軟 遅く高い。できれば避ける 専門家の評価

さらに、次の点が両社の文書で共通しています。

道具：OpenAIのEvals終了と、Promptfoo

OpenAIの文書（評価の案内ページと廃止予定のページ）には、次のとおり書かれています。

Promptfooは、設定ファイル（YAML）に「プロンプト」「モデル」「テスト」「合格条件（assertion）」を書き、コマンドで実行します。公式文書の設定例です。この記事では、実行していません。

prompts:
  - file://prompt1.txt
providers:
  - openai:gpt-6-luna
tests:
  - vars:
      language: French
      input: Hello world
    assert:
      - type: contains-json
      - type: javascript
        value: output.toLowerCase().includes('bonjour')
Promptfooの合格条件と、CIでの足切り

Promptfooの文書にある合格条件（assertion）の種類の一部です。

  • equals（完全に一致）、contains（文字列を含む）、regex（正規表現に合う）、is-json（正しいJSONである）
  • javascript、python（自分で書いた関数で判定）
  • levenshtein（文字列の違いが閾値以下）、latency（応答時間が閾値以下）、cost（費用が閾値以下）
  • similar（意味の近さ、つまり埋め込みの類似度が閾値以上）

AIによる判定の条件（llm-rubricなど）や、検索の評価向けの条件（context faithfulness、context recallなど）も、文書の一覧にあります。

CIの文書には、足切りの例があります。eval --fail-on-errorは、1つでも失敗すれば異常終了にする指定です。また、結果をJSONで出して合格率を計算し、95%未満ならビルドを失敗させるシェルの例が載っています。この95%は、文書の例にある数字で、推奨値ではありません。

npmの最新版は0.124.1、ライセンスはMITでした（2026年10月22日確認）。バージョンが若いので、設定の書き方が変わる可能性があります。

10問で何が分かるか（僕らの計算です）

僕らの計算です。本当の合格率が80%の仕組みを、10問で測ったとします。テストのたびに合格数が揺れる幅の目安（標準偏差）は、√(0.8×0.2÷10) ≒ 0.126、つまり約±13ポイントです。問題数と揺れの幅は次のとおりです。

問題数 揺れの幅（目安）
10問 約±13ポイント
50問 約±6ポイント
100問 約±4ポイント

この計算は、各問題が独立で、合格率が同じとした単純な仮定です。実際は問題ごとに難しさが違います。それでも、次のことは言えます。10問のテストで「前は8問、今回は7問合格」は、改善や悪化の証拠になりません。10問の役目は、明らかな壊れ方を見つけることだと思います。小さな差を見たいときは、問題数を増やすか、同じ問題を複数回走らせて平均を取ります。

よくあるつまずき

気をつけること

出典

更新履歴