OpenAIのEvalsプラットフォームは、2026年10月31日に既存評価が読み取り専用となり、11月30日にダッシュボードとAPIが終了予定です。評価はモデル更新のたびに品質を守る「検査設備」なので、画面やAPIが止まってから移すのでは遅すぎます。
今回のポイントは、Promptfooへ乗り換えること自体ではありません。テストケース、採点基準、実行環境、履歴を分離し、評価を持ち運べる設計にすることです。
終了するのは「評価」ではなく、評価を置いていた場所です
OpenAIの公式廃止予定では、Evalsプラットフォームは次の順で終了します。
- 2026年10月31日：既存のevalが読み取り専用になる
- 2026年11月30日：EvalsのダッシュボードとAPIが終了予定
一方、OpenAIは評価そのものを不要とはしていません。公式の評価ベストプラクティスでは、変更のたびに評価を回す継続評価、実運用に近いデータ、そして自動採点と人間評価の一致確認を推奨しています。
つまり今回の廃止は、「品質保証をやめる話」ではなく、品質保証の資産を特定サービスの中だけに置かない話です。
公式移行手順から見える4つの評価資産
OpenAIは移行先としてPromptfooを案内し、対応する評価については実行可能な設定ファイルをエクスポートできると説明しています。ただし、過去の実行結果は別に書き出して取り込む方式です。
この違いから、評価基盤は少なくとも次の4つに分けて管理すべきだと分かります。
- テストデータ：入力、期待値、典型例、境界例、失敗事例
- 採点基準：文字列一致、コード判定、LLMルーブリック、合格しきい値
- 実行設定：プロンプト、モデル、プロバイダー、温度などの条件
- 結果履歴：スコア、失敗内容、実行日時、使用モデル
設定ファイルだけ保存しても、過去との比較材料がなければ回帰を判定できません。逆に履歴だけ残しても、同じ条件を再現できなければ検証になりません。製造ラインでいえば、検査仕様書と測定記録の両方が必要です。
移行は「コピー」ではなく「同等性確認」です
OpenAIの移行ガイドは、類似度ベースの採点がシステム間で同じ数値になるとは限らず、手作業で再構成した採点器、特にLLMによる採点は検証が必要だと注意しています。
そのため、移行は次の順で進めるのが安全です。
- 移行元で完了済みの実行を1つ作り、実行可能な設定と過去結果を別々に保存する
- 移行先で同じ代表データを実行する
- 平均点だけでなく、各ケースの合否と失敗理由を突き合わせる
- 差が出た採点器は、人間の正解ラベルと照合してしきい値を調整する
- 一致を確認してから、CIで変更時に自動実行する
特に危険なのは、「総合スコアが近いから移行完了」と判断することです。重要ケースAの悪化と、簡単なケースBの改善が相殺されれば、平均値は変わらなくても本番リスクは上がり得ます。
考察：評価基盤は開発ツールではなく構成管理の対象です
モデル、プロンプト、エージェントのツール構成は頻繁に変わります。その変更を判定する評価基盤まで同時に変わると、「製品が変わったのか、物差しが変わったのか」を切り分けられません。
だから評価資産には、コードと同じくバージョン、レビュー、変更理由が必要です。おすすめは、テストデータと採点基準をアプリのリポジトリに置き、モデル固有の設定を分離し、結果には設定のバージョンを必ず記録することです。
これなら評価ツールを交換しても、品質の定義は残ります。PL視点では、これは単なるツール移行ではなく、検証可能性をサプライヤー変更から守る設計です。
まとめ
- OpenAI Evalsは2026年10月31日に読み取り専用、11月30日にダッシュボードとAPIが終了予定です
- 実行設定と過去結果は別資産として退避します
- 移行前後は各ケースの合否を比較し、採点器を人間評価で再調整します
- 評価資産をリポジトリとCIに寄せ、特定の画面やAPIに閉じ込めないことが重要です
評価はモデルの付属品ではありません。AIシステムの品質要求そのものです。サービスが変わっても物差しが残る状態を、終了日より前に作っておくべきです。