OpenAI Evals は、OpenAI が 2023 年に公開した LLM 評価用フレームワークで、GPT 系モデルの評価を YAML と JSONL だけで記述できる仕組みを広めた立役者です。本稿では、GitHub にある OSS 版（openai/evals）と、OpenAI Platform 上の evals／Datasets 機能、両方の現状と使い分けを整理します。
2 系統ある「OpenAI Evals」
ここが最初の落とし穴です。「OpenAI Evals」と呼ばれるものは実は 2 つあります。
- OSS 版: GitHub の
openai/evalsリポジトリ。CLI (oaieval) で YAML を回す形式。2023 年 3 月公開。 - Platform 版: OpenAI Platform（platform.openai.com/evaluations）の GUI。API からも呼べる。2024 年に追加され、2026 年には後継の Datasets へ移行中。
同じ「evals」という名前ですが、設計思想も対象ユーザーも別物です。OSS 版は研究者と OSS 開発者向けの登録制レジストリ、Platform 版は本番運用で評価データを溜める SaaS 的な位置づけです。本記事では主に OSS 版を扱い、Platform 側の動きは後半で触れます。
OSS 版の歴史と現状
公開は 2023 年 3 月、GPT-4 発表と同時でした。「GPT-4 の評価を外部にも開く」という宣言とともに登場し、当時は OSS コミュニティから評価用データセットを集めるクラウドソーシング的な役割も担っていました。スターは 19,500 を超え、LLM 評価分野では事実上の標準として参照され続けています。
ただし 2026 年現在、開発ペースはかなり落ちています。コミット履歴を見ると、2024 年後半から 2026 年にかけてのコミットは月数件程度で、内容も依存関係の更新や CI 設定の修正が中心です。新機能よりも維持管理フェーズに入ったと見るのが実態に近いでしょう。コミュニティ由来の PR はマージまで数ヶ月単位でかかることも珍しくありません。
主な機能
OSS 版の中心概念は 3 つです。
YAML registry
評価の定義を YAML ファイルとして evals/registry/evals/ 配下に置き、データ本体は JSONL で evals/registry/data/ に置く構造です。コードを書かずに評価を追加できる点が最大の売りでした。
Basic eval テンプレート
答えの揺らぎが小さい評価向けに、文字列ベースの比較テンプレートが用意されています。
Match: 出力が理想解の先頭と一致するかIncludes: 理想解が出力に含まれるかFuzzyMatch: 双方向の包含関係を確認JsonMatch: 構造化データのキーと値を比較
Model-graded eval（GPT-as-judge）
自由記述の回答を評価する場合は、別のモデルに採点させるテンプレートを使います。fact.yaml（事実一貫性を 5 段階で評価）、closedqa.yaml（関連性・簡潔さ・正確さの 3 基準）、battle.yaml（2 つの出力の優劣比較）といった既製テンプレートが同梱されており、自分の設問に合わせて差し替えて使う形です。
eval_type には cot_classify（推論させてから最後に選択肢を出させる）、classify_cot、classify の 3 種類があり、cot_classify が推奨です。選択肢は choice_strings で指定します（例: "ABCDE" や ["Yes", "No"]）。
最小動作例
まず簡単な JSONL データを用意します。
{"input": [{"role": "user", "content": "1+1=?"}], "ideal": "2"}
{"input": [{"role": "user", "content": "日本の首都は？"}], "ideal": "東京"}これを evals/registry/data/my_eval/samples.jsonl として保存します。次に YAML で評価を登録します。
# evals/registry/evals/my_eval.yaml
my_eval:
id: my_eval.dev.v0
description: "簡単な事実確認"
metrics: [accuracy]
my_eval.dev.v0:
class: evals.elsuite.basic.match:Match
args:
samples_jsonl: my_eval/samples.jsonlCLI で走らせます。
oaieval gpt-4o-mini my_evalPython から呼ぶ場合は、Completion function と呼ばれる抽象を介します。独自のモデル呼び出しをプラグインとして登録しておけば、同じ YAML を別モデルで評価できる建付けです。
# evals/registry/completion_fns/my_fn.yaml
my_completion_fn:
class: my_package.my_module:MyCompletionFn
args:
model_name: my-custom-modelこれを oaieval my_completion_fn my_eval で呼び出せます。
向くケース・向かないケース
OSS 版が向くのは、GPT 系モデルを中心に組んでいて、評価結果を社内で共有する簡単な場をすぐ欲しいとき、あるいは既存の model-graded テンプレートが設問にそのまま使えるときです。小さな JSONL と YAML 1 枚で動く手軽さは今でも魅力的です。
向かないのは次のような場合です。エージェント型のワークフロー評価（複数ステップのツール呼び出しや trajectory レベル分析）、OpenAI 以外のモデルを一次市民として扱いたい場面、そして評価の内部ロジックを細かく制御したい用途。Completion function を書けば他モデルも通せますが、本家ツールほどの滑らかさはありません。
他 OSS との棲み分け
2026 年現在、LLM 評価の OSS は選択肢が増えました。
- Inspect AI は UK AISI 製で、エージェントの trajectory 評価やサンドボックス実行まで含めた本格派。活発度・設計の近代性ともに OpenAI Evals を上回ります。
- DeepEval は pytest 風の API で、CI/CD に組み込みやすい設計。LLM-as-a-judge の指標（G-Eval, RAGAS 系）が揃っています。
- Phoenix（Arize）はトレース観測と評価を統合した方向。
OpenAI Evals は「YAML だけで登録制」という思想では今でも唯一無二ですが、新規プロジェクトでは Inspect AI か DeepEval を先に検討する人が増えています。参入時期と GPT-4 公開のタイミングが重なった歴史的意義は大きい一方で、設計面の後発優位が働きつつある状況です。
OpenAI Platform 側の進化
Platform 側の evals は、OSS 版とは別文脈で進化しています。ダッシュボードから JSONL をアップロードして、string_check などの grader を選び、ブラウザで結果を眺める SaaS 的な体験です。API からも Eval・Run を作れます。
ただし公式ドキュメントによれば、Platform 側の evals 機能は 2026 年 10 月 31 日に read-only、11 月 30 日に完全停止となり、後継の「Datasets」機能へ移行する予定です。ベンダー側の都合で機能名が変わるのは SaaS では珍しくありませんが、評価データとパイプラインを Platform に閉じ込めていると、こうした移行コストは利用者が払うことになります。
ハマりポイント
実際に導入するときに引っかかる場所をいくつか挙げておきます。
開発ペースと期待値のずれ: スター数とブランド力に比して、OSS 版の更新はゆっくりです。issue を立ててもすぐ返事が来るとは限りません。本番運用に組み込む場合は、自前でフォークして保守する覚悟か、他ツールを選ぶ判断が要ります。
OpenAI 以外のモデル対応: Completion function を書けば Claude や Gemini、ローカルモデルも通せます。ただしドキュメントは OpenAI API 前提で書かれており、Anthropic 公式 SDK や LiteLLM のような中継層を自分で噛ませる必要があります。Inspect AI や DeepEval が最初からマルチプロバイダ対応している点と比べると、手間がかかります。
ベンダーロックの気配: OSS 版は MIT ライセンスで独立していますが、Platform 側に評価データを溜める運用は、OpenAI の都合次第で後継サービスへの乗り換えを迫られます。評価は本来、モデル提供元から独立した場所で持つべき資産です。ベンダー横断で比較する将来を想定するなら、評価基盤はベンダー中立な層に置くほうが安全でしょう。
model-graded eval の判定モデル費用: GPT-as-judge で GPT-4 クラスを採点者に使うと、評価の実行コストが推論本体を上回ることがあります。採点モデルを軽量化しつつ、判定の人手との一致率をモニタする運用が要ります。
まとめ
OpenAI Evals は、LLM 評価という領域に「YAML で登録する」文化を持ち込んだ最初のフレームワークで、歴史的な意義は大きいものです。一方 2026 年現在、OSS 版は維持管理フェーズに入り、Platform 側は後継サービスへ移行中という過渡期にあります。
GPT に閉じたプロジェクトで、小さく評価を回したい用途には今でも使えます。マルチプロバイダや trajectory 評価が要るなら Inspect AI、CI 統合重視なら DeepEval を先に検討すると、2026 年のベストプラクティスに近いでしょう。何より、評価を特定ベンダーに預け切らない設計を最初から意識することが、本家ツールを使う上でも重要です。
chaff grade との連携 — 決定論的採点を混ぜる
OpenAI Evals は samples.jsonl の input / ideal ペアで動きます。モデル採点に加えて決定論的採点を足すなら、chaffjs の grade CLI に食わせる形が素直です。
評価の出力を chaff grade 用の items ファイルに変換して回すパターンの実装例: isamu/lab: examples/evals/openai-evals（samples.jsonl と chaff items の対応付け）
関連記事
- AI エージェント評価サーベイ論文を読み解く
- AI の評価って何？なぜ難しい？
- AI エージェントの evaluation (evals) 入門
- AI eval ツール: Inspect AI
- AI eval ツール: Phoenix
Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。