目次
AIチャットの指示文を直したら、昨日より自然に答えるようになった。しかし、以前答えられていた質問で失敗しているかもしれない。この変化を、担当者の数回の試用だけで見抜くのは難しいものです。
AIの評価は、大規模な研究チームだけの作業ではありません。サイトの問い合わせ分類やFAQ回答でも、成功の条件を決め、同じ問題で比較できるようにすると、モデルやプロンプトを変更する判断が具体的になります。
本記事は2026年10月20日に確認した公式資料を参照した実装・運用の解説です。以下の評価セット、判定方法、導入順序は本サイトの提案であり、製品間の実測ランキングではありません。既存のAIコーディング安全性の記事とは分けて、日常的な品質改善の測り方を扱います。
スポンサーリンク
成功とは何かを実際の業務で定義する
問い合わせを担当部署へ振り分けるAIなら、読みやすい理由を返すだけでは成功になりません。適切な部署を選び、判断できない場合を保留し、存在しない部署名を作らないことが必要です。FAQ回答なら、質問に答え、根拠と矛盾せず、適用条件を落とさないことが成功条件になります。
例えば「法人契約の解約」という入力を、契約窓口へ送るべきか、請求窓口へ送るべきかは、会社の業務ルールによって変わります。評価担当者同士で結論が割れるなら、モデルの比較より先に要件を確認してください。曖昧な正解を一つ作っても、公平な採点にはなりません。
本サイトでは、各ケースに期待する結果、必要な根拠、許容する別表現、してはいけない処理を記載することを勧めます。文章の完全一致を正解にするより、業務上満たす条件を記述した方が、自然な言い換えを不当に落としにくくなります。
質問集には成功例と保留例を入れる
最初は、実際によくある依頼と、過去に困った依頼を集めます。個人情報や機密を除き、入力の長さ、曖昧さ、表記揺れ、対象外の内容を偏りなく含めます。AIが得意なきれいな質問だけでは、本番のつまずきを見落とします。
分類なら、一つの部署へ明確に送れる例、複数の相談が混ざる例、情報不足で確認が必要な例を分けます。FAQなら、資料に答えがある例、似た資料はあるが答えがない例、古い資料と新しい資料が競合する例などを作れます。これは説明用の構成であり、すべてのサービスに必要な分類ではありません。
本番の出現頻度を反映するセットと、件数は少なくても重大な失敗を探すセットは分けて集計することを提案します。難しい問題を多く入れたテストの失敗率を、そのまま利用者全体の失敗率として表示してはいけません。
スポンサーリンク
調整用と最終確認用を分ける
失敗例を見て指示文を直す作業は有効です。ただし、同じ例だけで何度も調整すると、その質問に似た言い回しへ過度に合わせ込むことがあります。評価の数字が上がっても、見ていない問い合わせへ改善が広がったとは限りません。
本サイトでは、改善に使う開発セットと、採用判断に使う保留セットを分けることを勧めます。保留セットの失敗を詳しく分析して調整に使ったら、以後はそれを開発用へ移し、新しい確認用の問題を補充する考え方です。
各ケースに識別子、作成の理由、期待結果の根拠、見直した日付を付けます。制度や商品仕様が変わったときは、モデルの回答だけでなく正解側も更新が必要です。古い正解を維持したまま採点すると、正しい新情報を失敗扱いすることがあります。
コードで確認できる部分から自動化する
部署名が許可された一覧に含まれるか、JSONを読み込めるか、必須項目があるかは、通常のコードで判定しやすい項目です。これらは実行するたびに同じ基準で確認できるため、評価の基礎になります。
一方で、根拠の説明が十分か、利用者の質問に答えているかといった観点には、文脈を読む判断が必要です。Anthropicの解説は、コード、モデル、人による採点を使い分ける構成を説明し、モデル採点を人の判断と調整する必要性を示しています。
Anthropic：Demystifying evals for AI agents
スポンサーリンク
AIによる採点には基準と根拠を渡す
採点用AIに「品質を100点で」と頼むだけでは、文章の流暢さへ引っ張られる可能性があります。本サイトでは、「質問に含まれる二つの条件へ回答したか」「指定された資料と矛盾しないか」のように観点を分け、判定理由を短く記録する方法を提案します。
採点対象の回答、質問、必要な参照情報を渡し、情報が不足する場合は判定不能にできるようにします。点数だけを残すと、採点が不合理でも発見しにくくなります。人が正しいと確認した回答と、明らかな誤りを含む回答の両方を使い、採点器そのものを点検してください。
同じモデルで回答と採点を行ったから必ず無効になるわけではありませんが、共通の誤りを見逃さない工夫は必要です。別のモデルを使っただけでも正しさは保証されません。重要な観点は、人が根拠を読んで採点の妥当性を確かめることです。
エージェントは最終状態も確認する
外部のツールを使うAIでは、「処理しました」という回答だけを成功にしないでください。問い合わせをチケット化する例なら、チケットが実際に保存され、担当部署と内容が正しいかを確認します。会話が丁寧でも、保存されていなければ業務は完了していません。
本サイトでは、検証用のデータベースや外部APIの代替環境を使い、各試行の前に初期状態へ戻すことを提案します。前回の試行で作られたチケットが次の採点へ残ると、存在しない成功を数えることがあります。通信失敗や結果が不明なケースも用意します。
実行の途中経過は原因分析に使えますが、特定のツール呼び出し順だけを正解にすると、別の正しい手順を落とすことがあります。必須の本人確認などは条件として守らせつつ、業務の目的と最終状態で判断する部分を分けましょう。
モデル変更は同じ条件で比較する
品質の比較では、モデルだけでなく、指示文、参照文書、検索設定、ツール、出力上限が影響します。安いモデルへ変えるときに指示文と検索も同時変更すると、差の原因が分からなくなります。
本サイトでは、比較する構成を固定して記録し、同じ入力を両方へ与える方法を勧めます。結果のばらつきが問題になるケースは複数回実行し、一度だけの成功で採用しないようにします。試行回数と失敗件数を併記し、小さな差を確実な優劣として断定しません。
費用は一回のモデル呼び出しだけでなく、再試行、検索、採点に要した分も区別して把握します。応答時間は平均に加えて、待たされるケースの分布も見ます。短い回答ばかり出す構成が速くても、必要な情報を省いているなら改善とは言えません。
回帰テストでは平均点以外の条件を設ける
新しい構成の平均点が高くても、契約や請求に関わる特定の回答が悪化していたら、そのまま公開できないことがあります。本サイトでは、改善の目標と、悪化を許さない条件を別に決めることを提案します。
例えば、存在しない部署への振り分け、根拠にない金額の提示、未実行の処理を完了と伝えることを重大失敗として扱えます。これは本サイトの仮想例で、許容条件はサービスの影響に応じて決めます。点数の重みだけで重大失敗が埋もれない設計にしてください。
失敗したケースを見て、モデルの誤り、資料の不足、採点の誤り、環境の不具合へ分類します。テストが壊れていたなら直して再実行しますが、数値を上げるために難しい問題を外してはいけません。除外や修正の理由も記録して、比較の意味を保ちます。
スポンサーリンク
比較結果を採用判断へつなぐ
評価表には、現行構成と変更候補を並べ、用途ごとの合格件数、重大失敗、処理時間、概算費用を記載します。「新モデルの方が自然」という感想は、自由記述の補足として残せますが、合否の代わりにはしません。判断に使った入力と設定を追えることが重要です。
例えば、問い合わせ分類の全体正解率が上がっても、情報不足の相談を勝手に部署へ送る割合が増えたなら、確認質問を増やす調整が必要かもしれません。逆に、保留が増えただけで重大な誤配が減っていない場合は、担当者の負担が増えた可能性があります。処理を止めることも、業務の結果まで見て評価します。
合格基準は比較結果を見てから都合よく決めず、先に担当者と合意します。基準を変更する必要が生じたら、理由と影響を記録し、現行構成も同じ基準で採点し直すと比較の整合性を保てます。
評価の担当と実行時期を決めておく
指示文を変更したときだけでなく、参照文書や検索処理、ツールの仕様が変わったときも、対象のケースを再実行することを提案します。変更内容と関係が深いテストをまず走らせ、公開前には守るべき既存の動作を確認する進め方です。
採点不能のケースを誰が見るか、正解の資料を誰が維持するか、公開を止める判断を誰がするかも決めます。テストの担当者が不在だと、失敗通知だけが蓄積しやすくなります。少人数の運用なら、難しい自動化を増やす前に、一件の失敗が次の修正へつながる流れを作りましょう。
スポンサーリンク
本番の監視と固定テストを組み合わせる
固定した質問集で合格しても、本番には新しい質問が届きます。Microsoftの公式資料は、評価、監視、トレースを組み合わせ、モデル選択から公開後の品質管理まで扱う考え方を示しています。開発中の合格と、本番での継続的な観察は別の役割です。
Microsoft Learn：生成AIのオブザーバビリティ
小さく導入して継続できる仕組みにする
最初に作る成果物は、大きなダッシュボードよりも、合否の理由が読める質問集と実行結果で十分なことがあります。問い合わせの担当者と開発者が同じ失敗例を読み、何を直すか合意できる状態を目指します。
導入時は、一つの用途を選び、成功条件を決め、匿名化した入力と期待結果を作り、現行構成を測ります。その後に一つの改善を試し、合格条件を満たせば小さな範囲で提供します。公開後に見つかった新しい失敗を、次の評価ケースへ戻す運用です。
自動評価の数字だけで、利用者の満足や業務価値のすべては測れません。担当者が手直しした時間、問い合わせの再発、使われなかった回答なども観察します。評価はAIの順位表を作るためというより、自分たちの用途で変更を採用できるかを説明するための道具です。
スポンサーリンク
