13. 精度評価¶

13.1.1. スコアと業務上の合否¶

スコアは、用意したテストケースと採点条件に対する測定値です。製品が業務上の合格・不合格を自動決定するものではありません。採点できなかったケースや、試していない利用場面まで含めて品質を保証する値でもありません。

例えば、社内規程を検索して回答するエージェントであれば、「規程どおりに答えたか」と「必要な規程を検索できたか」を分けて確認します。検索結果に必要な情報があっても、回答時に金額を取り違える場合があるためです。回答の誤りと検索の取りこぼしでは、見直す設定が異なります。

評価を始める前に、利用場面と許容できない失敗を決めます。「回答は読みやすいこと」だけでは担当者によって判断が変わるため、「申請期限と上限額を両方答える」「資料にない金額を作らない」のように、実際の回答から確認できる条件にします。

13.1.2. 評価種別の選び方¶

RAG（検索拡張生成）は、文書などのナレッジを検索し、その情報を使って回答する方法です。RAG評価には、対象バージョンにナレッジの設定が必要です。RAG評価の採点では、回答の正確性を含む5指標を使います。

エージェント評価では、ツールを使うタスクに加え、文章の要約・変換なども判定条件で表現できます。どの指標が採点されるかは、評価種別を選んだだけでは決まらず、テストケースに設定した期待値によって変わります。例えば、期待する呼び出しも禁止ツールも設定しなければ、ツール正確性は採点されません。

図：「評価を始める」の最初の画面。対象エージェント・対象バージョンと、評価種別（回答品質評価／作業手順評価）を選ぶ。

13.1.3. 評価に使う情報の単位¶

通常、対象エージェントはテストケースごとに新しいセッションで1回実行されます。採点回数を3にすると、対象エージェントを3回動かすのではなく、保存した同じ回答を繰り返し採点します。採点回数を増やすと、採点のばらつきが抑えられ、スコアが安定します。対象エージェントの回答のばらつきを調べるには、評価実行そのものを繰り返します。

13.2.1. 画面を開く¶

サイトマップから「Copilot」→「Accel Agent」→「精度評価」を開きます。Accel Agent 内では、サイドナビゲーションの「精度評価」から移動できます。

精度評価ホームでは、「自分の評価計画」「最近更新した評価計画」「最近の評価結果」を確認できます。新しく作成する場合は「評価を始める」、既存の評価を続ける場合は計画を開きます。

13.2.2. 必要な権限¶

操作には評価の権限が必要です。参照権限で計画や結果を確認し、管理権限でデータセット画面の表示、計画の作成・変更、実行、生成などを行います。改善提案と添付ファイルの参照にも管理権限が必要です。利用者に見える操作は、付与された権限によって異なります。権限の詳細は「参照だけでは足りない場面」を参照してください。

13.2.3. 対象とモデルの準備¶

評価には、対象エージェント、採点用のLLMモデル、Embeddingsモデルが必要です。自動生成する場合は、テストケースを生成するLLMも選択します。これらのモデルは、「AIモデル管理」に登録したモデルから選ぶため、採点用・生成用にはテキスト生成モデルを、Embeddingsモデルには埋め込みモデルを、あらかじめ登録しておきます。生成用・採点用のモデルを選んでも、対象エージェント自身が使うモデルは変更されません。

13.2.4. 実行先の確認¶

評価では、エージェントに設定したツールやスキルが実際に動作します。登録・更新・通知を行うツールを使う場合は、評価で変更してよい接続先とデータを用意します。これはRAG評価でも同じで、評価種別を選ぶだけで外部操作が無効になる仕組みはありません。

禁止ツールの指定は、呼び出しを検出して減点する採点条件です。実行を事前に遮断する設定ではないため、外部操作の防止を禁止ツール欄だけに任せることはできません。

13.3.1. 通常の質問と失敗しやすい質問¶

データセットには、普段の利用を代表する質問と、失敗すると困る質問を含めます。通常の質問だけでは、情報が見つからない場合や、誤った操作を求められた場合の振る舞いを確認できません。

種類タグはケースの意図を表します。例えば、ガードレールのタグを付けても禁止ツール一覧が自動で補われるわけではありません。何をしてよく、何をしてはいけないかは期待値に記入します。指示文の制約によって断らせたいケースは、ガードレールではなく未完遂（UNFULFILLABLE）として作成します。自動生成でも、ガードレールを設定していないエージェントでは、ガードレールに割り当てた件数を未完遂として生成します。

対象エージェントにガードレールを設定している場合は、種類タグとは別に、テストケースごとに「ガードレール評価」を指定できます。期待する動作（通過・記録のみ・遮断）と、必要に応じて対象ルールと検査位置（入力・ツール実行前・ツール実行後・出力）を指定すると、実行時に記録した実際の判定と照合して「適合」「不適合」を判定します。照合にLLMは使いません。判定処理の失敗によって通過した場合は、適合とは判定しません。指定は、データセットの管理の行編集、またはインポートするファイルのguardrail項目（「RAGの入力形式（CSV・TSV・Excel）」、「エージェント評価の入力形式（JSON）」）で行います。

遮断を期待したケースでは、期待どおり遮断されれば回答を採点しないため、期待回答を空にできます。通過・記録のみを期待したケースは、通常のケースと同様に回答やタスク完遂も採点します。

13.3.2. RAGの質問と模範回答¶

模範回答には、業務資料で確認した答えを記入します。次は説明用の架空の規程を使った例です。

質問で二つの事項を求めるなら、模範回答にも両方を含めます。模範回答から期限が抜けていると、採点でも期限の欠落を十分に評価できないためです。規程が改定されると模範回答も変わるため、模範回答の根拠にした資料の版や適用日を、評価計画の説明欄に書いておきます。

NOT_FOUNDでは、質問への具体的な答えを捏造せず、情報がないことを伝える回答を期待値にします。この種類は回答の正確性で採点し、忠実性などの残り4指標は対象外です。

13.3.3. エージェントの期待回答と判定条件¶

固定の模範回答を用意できる場合は、期待回答を基準にする方式（REFERENCE）を使います。決まった文書の要約や、既知の内容への回答が該当します。

実行時に取得する値が変わる場合は、条件方式（CRITERIA）を使います。例えば在庫照会では、事前に架空の在庫数を正解として固定するより、「照会結果と同じ在庫数を回答する」と定める方が、測りたい振る舞いに合います。

条件方式では、タスク完遂の条件と回答品質の条件を分けます。タスク完遂は必須条件をすべて満たしたときに1点、回答品質は満たした条件の割合を基本に採点します。回答中の事実に根拠があるかも確認し、根拠のない事実があると回答品質は0点です。

「処理が完了した」と回答に書かれているだけでは、外部処理が完了した証拠として扱えません。業務処理の結果を判定する条件には、TOOL_RESULTSなど、完了を確認できる証拠を選びます。ツールが受付までしか返さない場合は、その応答から処理完了までは確認できません。

各条件群は1〜10件で、各説明は2,000文字までです。同じ説明の重複は登録できません。条件は、達成したかどうかを一つずつ判断できる単位に分けます。

条件方式のタスク完遂は、条件ごとに指定した証拠（ANSWER・TOOL_CALLS・TOOL_RESULTS）で判定するため、最終回答が空でも、ツールの呼び出しや応答を証拠にした条件であれば0点ではありません。文章による報告を求めない処理を条件方式で評価できるのはこのためです。空回答を理由に0点になるのは、参照回答方式のタスク完遂と、両方式共通の最終出力の品質だけです。

必要なツール応答が欠けている場合や、証拠として渡すツール応答が一定の長さを超える場合は、その条件が判定不能です。大きなツール応答を扱う処理を評価するときは、この制約を踏まえて結果を読みます。

13.3.4. 自動生成したケースの確認¶

自動生成は、テストケースのたたき台を作る機能です。生成後に担当者が質問、模範回答、呼び出し先、判定条件を確認します。生成処理の検査を通ったことと、業務上の正解であることは別です。

RAGの自動生成では、現在の検索で根拠を取得できるかも検査します。そのため、資料に答えはあるのに検索で見つけられないケースが生成結果から除かれることがあります。検索の取りこぼしを評価する場合は、そのようなケースを人手で補います。

比較に使うデータセットは、確認後に固定します。毎回生成し直すと、対象の改善に加えて質問の難しさも変わり、スコア差の原因を切り分けられません。

13.4.1. 「対象と種別」を設定する¶

「評価を始める」をクリックし、対象エージェント、対象バージョン、評価種別、計画名を設定します。説明欄には、評価の目的と、比較する変更内容を記入しておくと後から確認できます。

対象バージョンの「最新」は、実行開始時に非公開を含む最新の番号を選びます。公開中のバージョンだけを意味するものではありません。番号を固定して測定する場合は、そのバージョンを明示的に選択します。

対象バージョンは計画の固定設定として保存されません。「保存のみ（実行しない）」で計画を作った後や、次の評価を始めるときも、実行前に指定を確認します。実際に使用したバージョンは結果の「実行条件」で確認できます。

13.4.2. 「データセット」を準備する¶

データセットは、自動生成、インポート、既存計画からの取り込みのいずれかで準備します。

RAGの取り込み形式はCSV、TSV、Excel（.xlsx）です。CSVとTSVはUTF-8で保存します。エージェント評価はJSON形式です。ファイルの項目名と記入例は「設定値」に掲載しています。

エージェント評価には、RAGのような固定の記入用テンプレートがありません。呼び出せるツール・ナレッジベースや入出力スキーマが対象エージェントごとに異なるためです。代わりに、インポート画面の「作成用コンテキストを表示」から、対象エージェントに実在する呼び出し候補（種別・識別名・入力スキーマ）と入力パラメータのスキーマ、そのまま書き足せる取込ファイルの骨組みを確認できます。ここに表示される呼び出し候補とスキーマは、同じ画面の「自動生成」が生成時に参照する材料と共通です。「すべてコピー」でコピーした内容は、人が直接埋めるほか、手元のAIアシスタントに渡して記入内容を一緒に考える使い方もできます。

図：データセットのインポート画面。JSON ファイルをドロップ、またはファイルを選択して取り込む。

自動生成の件数は1〜100件、初期値は30件です。配分は画面で合計100%にします。「数件だけ試す」は生成内容を確認するためのプレビューで、対象エージェントの少数実行とは別の操作です。通常の自動生成は計画とデータセットも作成するため、完了後の内容を確認してから次へ進みます。

13.4.3. 「採点条件」を設定する¶

採点モデル、Embeddingsモデル、採点回数を選択します。

採点回数の初期値は3回です。忠実性、回答関連性、回答の正確性、タスク完遂率、最終出力の品質で反復判定を行います。コンテキスト精度とコンテキスト再現率は、採点回数を増やしても各1回の採点です。

条件をそろえて比較する場合は、採点モデルだけでなく、Embeddingsモデルと採点回数も固定します。Embeddingsモデルを変更すると、文章の類似度や引数照合の結果が変わる場合があります。

13.4.4. 「確認」で保存または実行する¶

設定とデータセットを確認し、「保存のみ（実行しない）」または「実行して結果へ」を選択します。初回は先頭数件だけを実行し、入力、接続先、所要時間、採点理由を確認すると、全件実行前に設定の問題を見つけられます。

少数実行は、指定した件数を処理した後に中断状態へ移ります。残りを続ける場合は再開します。少数実行の平均は全件の平均とは扱われず、全件評価の比較対象には入りません。

13.7.1. 件数とエラーを先に確認する¶

結果では、総件数、処理済み件数、エラー件数、指標ごとの「採点値あり」の件数を確認します。例えば20件中2件にしか採点値がない0.9と、20件すべてを採点した0.9では、結果から判断できる範囲が異なります。

図：評価結果の画面。指標ごとのスコア、ガードレール評価の件数、評価件数（種類ごとの内訳）、テストケース一覧が並ぶ。

対象外とエラーは、欠けた指標を0として平均へ加える扱いではありません。平均が高くても、採点されなかったケースに問題が残る場合があります。

ガードレール評価を指定したケースがある場合は、結果画面の上部に、適合・不適合・評価不能などの状態ごとの件数が表示されます。評価不能は、対象ルールが実行時の定義にない場合や、前の段階で遮断されて対象の検査まで到達しなかった場合などです。平均値とあわせて、この件数も確認します。

13.7.2. RAGの指標から調べる箇所¶

先の補助制度の例で、検索結果には上限と期限の両方があるのに回答が期限を誤ったなら、回答生成を調べます。検索結果に期限の情報がなければ、ナレッジの登録内容や検索を調べます。指標だけで原因を断定せず、ケース詳細の実際の回答と検索根拠を突き合わせます。

13.7.3. エージェントの指標から調べる箇所¶

ツール正確性が1でも、ツールの業務処理が成功したとは限りません。この指標は呼び出し先と引数などを照合するため、業務処理の成否はタスク完遂の理由と実際のツール応答で確認します。

禁止ツールを呼ぶと、ツール正確性は0点になり、結果に「禁止ツールを実行しました」と表示されます。この表示はスコアとは無関係に常に出るため、平均スコアとは分けて確認します。

図：テストケース詳細。呼び出しの比較（期待する呼び出しと実際の呼び出し）、期待する回答と実際の回答を確認できる。

13.7.4. スコア平均と前回比較¶

スコア平均は、算出できた品質指標をまとめた診断用の値です。RAGでは回答の正確性が平均の上限です。例えば他の4指標がすべて1でも、回答の正確性が0ならスコア平均も0です。時間・コスト・推論回数は、この平均に含めません。

前回比と過去最高比は、同じ計画で比較条件がそろう全件完了結果を対象とします。題材、入力、期待値、実行ユーザ、採点条件、指標ごとの採点件数などが異なる場合は、比較値が表示されないことがあります。対象エージェントのバージョン変更は改善の比較に必要なため、それだけで比較対象外にはなりません。

前回比は「今回のスコア − 比較対象のスコア」です。0.60 から 0.70 であれば、差は +0.10 と表示されます。これはスコアの差であり、比率ではありません。また、指標値はテストケースごとのスコア（0〜1）の平均であり、必ずしも正解したテストケースの割合ではないため、「正解率が 10% 改善した」という読み方はできません。品質指標は高い方を、時間・コスト・推論回数は低い方を良い値として表示しますが、処理を省略して速くなっていないかは回答と達成条件でも確認します。

13.7.5. 時間と費用¶

エージェント評価には、対象側の実行時間、コスト、推論回数も表示されます。時間と推論回数はケース間の平均、対象コストは算出できたケースの合計です。コストの有効件数が足りない場合は、その合計だけで全件分の費用を判断しません。

採点・埋め込みの費用と、対象エージェントの費用は別に記録されます。自動生成や改善提案でもLLMを使うため、評価画面の一つの金額を、これらをすべて含む請求額と解釈しないようにします。単価や使用量を取得できない場合の「—」は、無料という意味ではありません。

13.11.1. 採点条件と対象バージョン¶

実行開始時に指定した値を優先し、未指定の項目は計画の既定値で補います。

採点モデルが構造化出力を返せない場合、対象エージェントを1件も実行しないまま実行全体をエラーにします。

対象バージョンは実行時に指定し、省略時は非公開のバージョンを含めて取得できる最大番号を選びます。計画自体は対象バージョンを固定保持しません。受付時に対象バージョンと定義の内容から計算した識別値（ハッシュ値）を保存し、対象実行の直前に定義を取得し直して比較します。不一致であれば、その対象を実行せずにエラーにします。実行の途中で定義を変更しても、その回の実行には反映されません。

「再開」「この行を再実行」でも、この識別値を確認します。「保存結果を再採点」は保存済みの回答を使うため、定義が変わっていても対象を再実行せずに処理できます。また、ナレッジ本文や外部業務データを実行時点へ完全に復元する仕組みはないため、同じ定義であっても、これらの変化によって結果が変わることがあります。

13.11.2. データセットの共通制約¶

データセットは1〜100件です。ケースID は最大50文字で、同じデータセット内の重複は拒否されます。未指定のID は自動採番します。質問またはタスク指示は必須です。

検証状態の「未検証」「問題なし」「警告あり」は、項目や定義との整合性を確認した結果です。模範回答の事実確認や、採点モデルの判定精度を保証する状態ではありません。

13.11.3. RAGの入力形式（CSV・TSV・Excel）¶

CSVとTSVはUTF-8で読み込み、先頭のBOM（バイトオーダーマーク）を許容します。Excelは.xlsxの先頭シートを読み、数式セルは数式の評価結果を使います。先頭行はヘッダとして扱います。question列とground_truth列は必須ですが、ground_truthの値そのものは空欄でも構いません。

記入例（説明用の架空の規程を使ったもの。実際の評価では対象資料に合わせて差し替えます）。

id,kind,question,ground_truth,target_path,run_user
rag-01,NORMAL,購入補助の上限額と申請期限は？,上限は10万円で、申請期限は購入月の月末です。,,
rag-02,NOT_FOUND,翌年度の購入補助の上限額は？,提供された資料には翌年度の上限額の記載がありません。,,

必須ヘッダや質問が欠落している場合や、ケース数が上限を超える場合は、取り込みエラーが発生します。行末の空セルのように、存在しない位置の値は空として扱います。取り込み後は、追加の入力パラメータや種類タグの警告を確認してから実行します。

13.11.4. エージェント評価の入力形式（JSON）¶

ルートはオブジェクトとし、文字列のformatVersion: "1.0"と、配列のsamplesを指定します。JSON内のキー重複は拒否されます。未知の項目は警告した上で読み飛ばすため、期待条件の入力ミスが警告のまま見過ごされないよう、取り込み後の警告を確認します。

記入例（入力文の変換を条件方式で評価する例。ツールを必要としないため呼び出し期待値は指定していません。取り込むだけでは対象エージェントは実行されません）。

{
  "formatVersion": "1.0",
  "samples": [
    {
      "id": "agent-01",
      "kind": "NORMAL",
      "taskInstruction": "次の文を丁寧な日本語に直してください。『資料を明日までに送って。』",
      "answerEvaluationMode": "CRITERIA",
      "completionCriteria": [
        {"description": "資料の送付を依頼する意味と、明日までという期限を保持する", "evidence": "ANSWER"}
      ],
      "answerCriteria": [
        {"description": "丁寧な日本語の依頼文になっている", "evidence": "ANSWER"},
        {"description": "変換後の文だけを出力する", "evidence": "ANSWER"}
      ],
      "callOrderRequired": false
    }
  ]
}

13.11.5. 呼び出し条件と証拠¶

期待する呼び出しにはtype・name・任意のargsを指定します。typeはTOOL・KNOWLEDGE・SKILLのいずれかです。nameには実際の呼び出しカタログの識別名を使います。表示名を推測して記入すると一致しないことがあるため、対象の候補を評価画面側で確認してから記入します。

argsの各項目はname・expected・matchを持ちます。matchはEXACT（前後空白を除いて比較し、双方が数値なら数値として比較する。1と1.0は一致）、またはSIMILARITY（期待引数と実引数の埋め込みのコサイン類似度が0.85以上で一致）のいずれかです。

{
  "type": "TOOL",
  "name": "lookup_inventory",
  "args": [
    {"name": "productCode", "expected": "P-001", "match": "EXACT"}
  ]
}

条件方式（CRITERIA）のcompletionCriteria・answerCriteriaは、それぞれ1〜10件を指定します。各条件はdescriptionとevidenceを持ち、descriptionは空白だけを認めず最大2,000文字です。同じ条件群の中で、前後の空白を除いた説明が完全一致する条件は拒否されます。参照回答方式（REFERENCE）では条件群を指定できません。

evidenceに指定できる値は、「エージェントの期待回答と判定条件」で挙げた ANSWER・TOOL_CALLS・TOOL_RESULTS のいずれかです。TOOL_RESULTSでは、全呼び出しの応答が完全に保存されていること（resultCompleteが真であること）を要求します。応答が未保存・一部欠落の場合や、呼び出し要素自体が欠けている場合は証拠不足として扱われます。TOOL_CALLSとTOOL_RESULTSの材料は、JSON化した合計が24,000文字を超える場合、証拠不足として扱われます。呼び出しが0件であることは、記録の欠落ではなく「呼び出さなかった」という観測として扱います。

ツールの応答本文は1件あたり16,000文字を上限に保存します。条件判定に必要な応答が切り詰められた場合は、切り詰めた値だけで条件を満たしたとは判定せず、その指標は算出せず「判定不能」として扱います。

13.11.6. 実行のやり直しに必要な条件¶

同じ計画で実行中（RUNNING）または停止処理中（STOPPING）の実行がある間は、新しい実行を受け付けません。

対象実行でrunUserCdを指定すると、その間だけ指定ユーザとして実行します。終了後に元のユーザへ戻す処理に失敗すると、誤ったユーザのまま処理を続けないよう実行全体を停止します。

再採点で、明細・ケーススナップショット・回答のいずれかが欠けているケースは、既存値を保持してスキップします。再開は、評価の開始後にデータセットが変更されていると拒否されます。「この行を再実行」は現在のケース内容を読むため、停止中に編集すると、一つの実行内に異なる時点のケース内容が混在することがあります。内容を変更して比較したい場合は、新しい評価実行を作成します。

13.11.7. RAGの対象外条件¶

次の表は、NOT_FOUND以外のケースを対象とした、指標ごとの対象外条件です。「通常」は他の条件を満たした場合に通常どおり採点する、という意味です。

NOT_FOUNDは回答の正確性だけを採点し、他の4指標は対象外にします。空回答は正確性0、回答はあるが模範回答が無い場合は正確性も対象外です。

13.11.8. エージェントの対象外条件¶

期待する呼び出しも禁止ツールも指定が無い場合、ツール正確性は対象外です。参照回答方式で期待回答が無い場合、条件方式で条件または根拠判定が判定不能な場合は、タスク完遂率・最終出力の品質（または回答品質）が対象外として扱われます。判定不能は、証拠として必要なツール応答が欠けている、または長さの上限を超えて切り詰められている場合に起こります。

呼び出し順を採点に含めるかどうかはcallOrderRequiredで切り替えます。真にすると条件方式でも呼び出し順を確認し、順序が違えば減点します。参照回答方式では、一致した期待呼び出しが2件以上あれば常に順序を確認します。

13.11.9. 履歴比較の条件¶

前回比・過去最高値の比較は同じ計画内で行います。比較候補になるのは、実行状態OK・全件処理済み・ケースエラーなしの実行だけです。少数実行、中断、実行エラー、ケースエラーを含む実行は、比較候補から除外します。候補の中から、総件数・指標別の有効件数・保存した評価条件が一致する実行を抽出します。評価条件は、ケースのスナップショットを正規化して照合します。

ケースID や並び順だけの変更は、内容比較の材料にしません。対象バージョンは改善を測るために変える対象であるため、比較条件から除いています。添付ファイルの期待値メタデータは照合材料に含まれますが、外部リソースの同一性そのものを保証するものではありません。条件スナップショットが保持期限などで失われた実行は比較条件を確認できないため、比較対象外です（スコア自体は表示できます）。前回比は「今回値−比較対象値」で求め、過去最高・過去最低は指標ごとに求めるため、各指標の最高値が同じ一つの実行で達成されたとは限りません。

13.11.10. 改善提案・権限区分¶

改善提案は、低スコアの材料に件数の上限があるため、提案が全ケースの問題を網羅するとは限りません。生成に失敗しても、確定済みの評価結果を提案側の失敗によってERRORへ変更することはありません。既にOKまたはRUNNINGの提案がある場合、通常の開始要求では重複生成しません。

HTMLレポートの明細が削除済みの場合、保持している集計値だけからは、失われた判定理由を復元できません。

評価の操作権限と、ケースを実行するユーザの業務権限は別です。実行ユーザを指定すると、その業務権限で測定できますが、評価結果の参照権限が同じユーザへ自動的に付与されるわけではありません。