AIの変更を同じ課題で比べる：運用チームの評価セットの作り方

一次情報から

公式資料は、出力記録と最終状態を区別する

Anthropicの2026年1月の評価解説は、試行の記録と、終了時に環境へ残った最終状態を区別しています。[1] 回答が完了を宣言していても、必要な変更が保存されたかは別に確認するという考え方です。本記事は、この既存の解説を運用設計の参考にしています。

同社の2025年11月の長時間エージェントの解説では、一度に一つの機能へ取り組み、進捗を記録する構成を紹介しています。[2] それだけで品質が保証されるわけではありません。以下では、変更と評価結果を対応づける独自の実務手順を提案します。

出典：[1][2]

編集部の実務提案

業務の判断が割れる入力を集める

例として、問い合わせを担当部署へ振り分けるAIを考えます。これは実在の導入実績ではなく、設計用の例です。正しい部署が明らかな入力だけを集めると、判断が難しい境界を見逃します。二つの相談が混在する、情報が足りない、既存の分類に合わないといった入力を含め、担当者が期待する扱いを記入します。

実際の記録を使う場合は、利用範囲を確認し、識別情報を取り除きます。匿名化で判断に必要な条件まで失われた場合は、その条件を明記した架空の入力へ置き換えます。各課題には識別子と選んだ理由を付け、何件あるかだけでなく、どの業務上の境界を含むセットなのかを説明できるようにします。

編集部の実務提案

機械で確かめる項目と、人が読む項目を分ける

部署コードが許容値か、必須項目があるか、保存先が正しいかは、期待値と照合する判定を検討できます。一方、説明が誤解を招かないか、確認質問が妥当かは、評価基準を読んだ人が確認する対象です。単一の総合点へ急いでまとめず、業務を壊す誤りと表現上の改善を分けて記録します。

AIに採点を補助させる場合も、まず人が付けた判定と比較し、どの条件で食い違うかを確認します。正解が複数ある課題は、許容する範囲を記載します。例えば文末の違いで不合格にする一方、別の部署へ保存した結果を高評価にするような採点では、運用判断に使えません。

編集部の実務提案

一回の改善判断で変える条件を絞る

比較記録には、入力セットの版、指示文の版、モデル設定、接続ツール、実行日時を残します。指示文とツールを同時に変えたときは、結果が変わっても原因を一つに決められません。現場では複数変更が必要な場合もあるため、その場合は一括変更であることを明示し、個別の改善効果と混同しないようにします。

出力が揺れる課題は、同じ入力を複数回試し、成功した回だけを選ばず全結果を比較します。必要な反復数は、失敗時の影響と実行費用から決めます。全体の点数に加え、分類別の失敗件数、所要時間、課金対象の利用量を並べると、精度だけを理由に運用負担を増やす変更を見つけやすくなります。

編集部の実務提案

委託先から受け取るのは、点数と差分と未解決事項

オフショアチームへの依頼には、比較対象、評価セット、実行環境、提出物をまとめます。提出物は、変更前後の集計、悪化した課題の識別子、判定理由、再現に必要な設定です。生の応答をすべてチャットへ貼るより、担当者が気になる課題を選んで確認できる記録を残すと、時差のあるレビューでも判断が具体的になります。

修正した失敗例を評価セットへ加える際は、その例だけに合わせた改善になっていないか、別の課題でも確かめます。以前は成功した重要な課題も残して再実行し、採用を決める人が悪化分を把握できるようにします。公開後に見つかった新しい失敗は、再現条件を確認してから次の比較へ加えます。