AIゲーム開発の評価セットを作る｜出力品質の確認とEvals移行予定

評価する対象を、一つの使い方へ絞る

最初に「AI全体の性能」ではなく、自分のゲームで何に使うかを決めます。クイズの生成なら選択肢と答え、NPCなら進行に合う会話、コードの修正なら指定の操作が直ったかが対象です。何を満たせば採用できるかを先に書き、出力を見た後に都合よく採点条件を変えないようにします。

評価例には、よく使う場面だけでなく、境界の場面を入れます。NPCなら初対面、受注中、達成直前、達成後、報酬受領後です。クイズなら短い文章と長い文章、似た選択肢、扱わない話題を入れます。すべてを大量に作るより、用途ごとの失敗を見つけられる小さな組から始めましょう。

OpenAIの評価の公式資料は、通常の例に加えて境界や難しい例を含める考え方を説明しています。ここからの評価表は当ブログの提案です。制作中に実際に困った入力があれば、その条件を記録して組へ追加します。成功した例だけを保存すると、変更で以前の不具合が戻ったかを確かめにくくなります。

機械で確認できる条件と、人が選ぶ条件を分ける

JSONの項目、選択肢の数、文字数の上限、座標の範囲などは、検証関数で判定できます。まずこれらを満たすかを調べ、失敗した出力を採用候補から分けます。内容が面白く見えても、ゲームで読めない形式なら使用できません。形式と範囲の条件を、好みとは別の判定にしておきます。

一方で、台詞の分かりやすさやキャラクターらしさは、人が読む工程を残します。「良い」「悪い」の二択だけより、依頼の目的を伝えているか、次に何をするか分かるか、既知の設定と矛盾しないかを別に見ます。採点者によって判断が変わるところは、理由と具体的な文章を記録します。

AIに評価を手伝ってもらう場合も、その判断を正解として固定しません。明らかに誤った説明を高く評価する可能性や、長い文章を有利に見る可能性を考えます。少数の出力を自分でも読み、評価の理由が制作の目的と合っているかを確認します。合計点だけでなく、失敗の種類を残しましょう。

JSONLなどに、再確認できる条件を保存する

一つの行に一件の入力を記録する形式なら、別の道具へ移すときも扱いやすくなります。入力、期待する条件、分類、仕様の版番号を保存します。実行した結果には、使ったモデルの識別子、設定、確認日、出力、検証結果を対応させます。これは評価サービスを使うかどうかにかかわらず有用な制作記録です。

以下は当ブログの記録例で、そのまま特定のAPIへ送る正式な形式ではありません。台詞が一字一句一致することを求める例と、意味の条件を満たせばよい例を区別します。NPCの案内なら、行く場所を伝え、未達成なのに報酬を受け取ったと述べないことが確認条件になり得ます。

比較する際には、一度に変更する条件を絞ります。指示とモデルとゲームのルールを同時に変えると、結果の違いを説明しにくくなります。同じ入力組で確認し、採用した出力だけを比べず、失敗した出力も含めて見ます。少数の結果から、あらゆるゲームで性能が上がったと結論づけることは避けます。

{"id":"npc-before-complete","input":"薬草は二個。依頼は三個。","checks":["あと一個必要と案内する","報酬受領済みと述べない"],"specVersion":1}
// 実行結果には入力ID、モデル、設定、確認日、出力、判定理由を対応させる。

Evalsの終了予定を確認し、記録を持ち運べるようにする

2026年10月14日に確認したOpenAIのDeprecationsページは、Evalsが10月31日に読み取り専用となり、ダッシュボードとAPIが11月30日に終了予定であると記載しています。今から構築する評価を、以前のEvals画面やAPIが継続する前提だけに置かないようにしましょう。日程や移行案内は採用時にも公式ページを確認してください。

評価という作業自体と、特定のサービスは分けて考えます。検証関数、入力例、人が付けた判断、失敗理由が手元にあれば、別の実行方法へ移しても条件を引き継げます。今使っているサービスから何を取り出せるかを確認し、必要な記録を保存する工程を設けます。移行した後も同じ小さな組を実行して確かめます。

評価セットは完成後に凍結するものでもありません。ゲームの仕様が変わったら、古い条件を残すか更新するかを決めます。新しい問題を見つけたら再現例を追加します。本記事は実測した順位表ではなく、制作の判断材料を残すための方法です。失敗を説明できる記録を、次の修正と公開の確認へつなげましょう。