情報確認日：2026年10月15日
AIの指示文やモデルを比べるときは、改善に使う問題と、最後に性能を確認する問題を分けます。同じ問題の失敗を見ながら何度も直すと、その問題だけに合った指示になるためです。学習を伴わないプロンプトの改善でも、最終確認用の問題を別に保管する運用が役立ちます。
「初めての問題」がなくなると何を測れないか
例えば、問い合わせを担当部署へ振り分けるAIを作るとします。ある質問で部署を間違えるたび、その質問の言い回しを指示文へ追加すれば、手元の正答率は上がるかもしれません。しかし、別の言い方や複数の相談を含む質問への性能まで上がったとは限りません。
Googleの機械学習教材は、テスト結果を繰り返し改善へ使うと、テストデータの特徴へ合わせ込む問題を説明しています。学習用・検証用・テスト用を分けても、検証・テスト用のデータは使い続けると評価材料として古くなるため、更新が必要です。Google：データセットの分割
これは、モデルの追加学習を説明した教材の考え方です。指示文の選択へ応用する場合は、モデルの重みを学習したという意味ではなく、作り手が既知の問題へ設定を合わせた影響を避けるための運用として使います。
最初に、合格する回答を決める
問題を集める前に、何を成功とするかを書きます。「自然な回答」だけでは採点者によって基準が動きます。部署振り分けなら正しい部署、案内文なら必要な対象条件と期限、要約なら原文の重要事項を落とさないこと、というように仕事へ合わせます。
正解が一つでない文章では、参照回答と完全一致する必要はありません。「対象外の人にも申請できると書かない」「原文にない金額を加えない」など、満たす条件と重大な失敗を先に決めます。OpenAIの評価設計ガイドも、実務に合う評価と人の判断を組み合わせる方法を案内しています。
基準を変更した場合は、変更前後の点数を同じ物差しの成績として並べません。基準の版、問題の版、実行日を一緒に残します。
三つの役割へ分ける
| 役割 | 使い方 |
|---|---|
| 改善に使う問題 | 失敗を読み、指示・資料・処理を直す |
| 候補を選ぶ問題 | 複数の設定を同じ基準で比べる |
| 最終確認用の問題 | 選んだ設定を、未使用の問題で確認する |
追加学習をする場合は、このほかに学習へ投入するデータを明確にします。追加学習なしで指示文を調整する仕事でも、少なくとも「直すために見る問題」と「最後まで見せない問題」の区別を設けられます。
分割割合に万能の正解はありません。Googleの教材も、各集合へ固定の割合を要求していません。件数が少ない段階の好成績は、広い実務を代表した結果として扱わず、どの種類を何件試したかを添えます。
似た質問を別々の集合へ混ぜない
同じ問い合わせのコピーや、語尾だけ変えた質問が改善用と最終用へ分かれると、初めての問題を試したつもりでも内容を既に見ている場合があります。分割前に重複を確認してください。
同じ文書の別ページや、同じ顧客の連続相談も、情報が強く重なることがあります。仕事に応じて文書・案件・期間などの単位でまとめて分ける方法を検討します。これは編集部による運用案で、すべての案件に同じ分け方を要求するものではありません。
通常の質問だけでなく、情報不足、誤字、条件の例外、答えが資料にない質問も入れます。実際には日本語の短い相談が多いのに、整った長文だけを試すと、評価と利用場面がずれます。
最終確認で失敗した後の扱い
最終確認の失敗を見て指示文を修正すること自体は必要な改善です。ただし、その問題は以後、未使用の最終問題ではありません。改善用へ移したことを記録し、新しい問題で次の最終確認をします。
AIを採点に使う場合も、採点AIが参照回答や根拠と一致して判断しているかを人が確認します。回答の順序や長さに引きずられる可能性があるため、設定名を隠した比較や、明確な合否条件が使えます。
同じ入力でも出力が変わる場合があるので、一度の成功だけで安定性を断定しません。回数、成功数、重大な失敗の有無を分け、モデル名・設定・使った資料も記録します。
評価の考え方と、サービスの存続は別
この手順は、表計算や手元の記録でも始められます。OpenAIの現行ガイドには、同社Evalsプラットフォームが2026年10月31日に既存利用者向け読み取り専用となり、11月30日に終了予定との案内があります。評価という考え方全体がなくなる意味ではありません。
特定の評価サービスへ新しく仕組みを作る場合は、公式の移行・終了案内を確認します。問題、採点基準、結果を取り出せる形で保管すると、サービスを変えても比較の根拠を引き継げます。
参照資料
あわせて読みたい記事
執筆・検証：カネさん（政経プラスチャンネル運営）＋ ChatGPT
