Agentforceテストセンターとは？AIエージェントの品質保証を三層で設計

本番リリースの承認会議で「テストは足りているのか」と問われたとき、「私が試した範囲では問題ありませんでした」以外の言い方が出てこなかった、という声をよく聞きます。Agentforceテストセンターとは、エージェントに投げた発話に対して、どのサブエージェントが応答し、どのアクションを実行し、どんな内容を返したかを、あらかじめ定義した正解データと突き合わせて判定する仕組みです。 ただし、同じ質問を2回投げれば違う文章が返るものを扱う以上、何をもって合格とするかは自社で決めることになります。

そこで本記事では、AIエージェントの品質保証を、サブエージェント選択・アクション選択・応答内容という三層で設計する考え方から、テストセンターへの実装、判定会議までの工程、コスト、続けるための体制条件までを順に整理します。なお、機能の提供状況や単価は変わりやすいため、本記事は2026年8月時点で確認できた情報にもとづいています。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

Agentforceの本番承認が止まる3つの状況

今回は、SaaSの保守運用を請け負う中堅のBtoBサービス企業（従業員約400名・カスタマーサポート窓口8名・Service Cloudの運用は4年目）を例に進めます。この会社では、窓口に月およそ1,000件届く問い合わせの一次回答をAIエージェントへ任せる計画が、本番判定会議の直前で止まっていました。そこでここでは、Agentforceの本番承認が止まる3つの状況を整理します。

本番承認が止まるのは、エージェントが動かないからではありません。動いている状態を合格と呼んでよいかを判断する基準が、社内のどこにも定義されていないからです。

状況①動いているが合格の基準がないこと

1つ目は「動いているが合格の基準がない」という状況です。検証環境でエージェントを起動し、思いついた質問を投げれば、それらしい回答が返ってきます。この状態を見て「問題なさそうだ」と判断してしまうと、承認を求める段階で何も示せなくなります。

このBtoBサービス企業の担当者も、検証環境で3週間ほど、自分で考えた質問を投げ続けていました。返ってきた回答はいずれも妥当で、手元のメモには「おかしな回答はなし」とだけ残っていたのです。ところが会議資料を作る段になって、何件試したのか、どんな種類の質問を試したのかを一度も数えていなかったことに気づきました。

このとき担当者に足りなかったのは、エージェントの精度ではありません。何をどこまで試したのかという記録です。「自分が試して問題なかった」は、試した範囲が定義されていない限り、他人が検証できない主張になります。試す件数と質問の種類さえ先に決めてあれば、3週間かけなくても、数日分の記録で承認の材料が揃います。

状況②説明する相手ごとに求める根拠が違うこと

2つ目に挙げるのは、説明する相手ごとに求める根拠が違うという状況です。承認の場に出てくるのは1人ではないため、同じ「大丈夫です」という説明でも、相手によって納得する条件が変わります。

このBtoBサービス企業の判定会議には、サポート部門の部長・法務・情報システム部・窓口の責任者の4名が出席する予定でした。部長が知りたいのは窓口の業務が実際に軽くなるかどうか、法務が知りたいのは誤った案内をしたときに顧客との契約上どこまで責任を負うか、情報システム部が知りたいのはエージェントがどのデータを書き換えうるかです。窓口の責任者はさらに、担当者が手直しする手間がどれだけ増えるかを気にしていました。

同じ検証結果でも4者が受け取りたい内容は違うため、準備の段階で「誰に何を示すか」を分けておかないと、会議の場で追加の宿題が出て、承認がもう一往復先送りになってしまいます。

一次対応を担うエージェントの設計については、ほか記事「Agentforce Service Agentとは」で詳しく解説しています。

状況③誤答が出たときの責任の所在が空白なこと

3つ目は、誤答が出たときに誰が責任を負うのかが決まっていない状況です。人が対応していた頃は、担当者が答え、上長が確認し、間違えれば謝罪と訂正の手順がありました。エージェントが一次回答を返す構成にすると、この経路がそのままでは残りません。

たとえば、このBtoBサービス企業では、法務から「誤った案内をした場合の責任範囲は」と質問される予定になっており、担当者は「モデルが生成した文章なので」と答えかけて、言葉に詰まりました。エージェントの出力だと説明したところで、顧客に届いた案内は自社が出したものであり、責任の所在は動きません。

誤答が出る前提で、どの回答は人が確認してから送るのか、誤りが見つかったときに誰が止めて誰が訂正するのかを決めておきましょう。この線引きが空白のままだと、法務は承認を出せません。

Agentforceのテストが通用しない3つの理由

前章では、本番承認が止まる3つの状況を整理しました。ここまでは体制の話でしたが、そもそもAIエージェントは、これまで社内システムに対して行ってきたテストと同じ考え方では判定できません。そこでここでは、Agentforceのテストに従来のやり方が通用しない3つの理由を整理していきます。

AIエージェントのテストでは、同じ入力に同じ出力が返るという前提が成り立たないため、1回の実行で合否を確定させるという設計の考え方から組み替える必要があります。

理由①同じ入力でも応答が毎回変わるから

まず押さえておきたいのは、AIエージェントが同じ入力に対して同じ応答を返すとは限らないという性質です。Salesforceの公式教材にも、同じ入力が、それぞれ異なるが正しい応答を複数生成することもあれば、誤った応答や、ときにハルシネーションを生成することもある、と明記されており、テストは確率的なものとして扱うべきだという立場が提供元から示されています。

※参考記事はこちら

このBtoBサービス企業の担当者も、同じ「保守契約の更新時期を教えてください」という質問を日をまたいで2回投げて、文面がそろわないことに気づいていました。1回目は更新月を先に書き、2回目は契約書の該当条項に触れてから更新月を書く、という違いがあったのです。どちらの内容も誤りではありませんでした。

期待する文字列と一致したかどうかで合否を決める仕組みをそのまま持ち込むと、正しい応答が不合格として積み上がります。判定の方法を層ごとに変える必要があるのは、この性質があるからです。

理由②正しい応答が1つに定まらないから

応答が変わるだけでなく、そもそも正しい応答が1つに定まりません。人が窓口で答えるときも、同じ質問に対して説明の順序や言葉づかいは担当者ごとに違いますが、どれも正解として受け入れられてきたのと同じことが、エージェントの応答にも起こります。

たとえば「更新は毎年4月です」と返す応答と、「保守契約の更新は年に一度、毎年4月に実施しています」と返す応答は、文字列としてはまったく別ものです。窓口の責任者から見ればどちらも合格ですが、機械的な一致だけを見れば片方は不一致になります。逆に、更新月を4月と正しく書きながら、対象外の契約プランにも同じ案内をしてしまえば、文面が自然でも中身は誤りです。

正解が1つに定まらない対象では、一致するかどうかで判定できないため、何をもって妥当とみなすかを、判定の条件として言語化しておく必要があります。

理由③失敗が一定の確率で起き続けるから

3つ目に押さえたいのは、失敗の起き方の違いです。従来のシステムでは、不具合は原因を直せば再発しませんでした。AIエージェントの誤りは、直しても一定の確率で起き続けます。

このBtoBサービス企業でも、契約プランの取り違えが起きたケースを1件見つけて指示文を修正しましたが、同じ種類の質問を件数を増やして投げ直すと、別の言い回しで再び取り違えが出ました。原因を1つ取り除けば終わる話ではなかったのです。担当者はここで、不具合をゼロにしてから出すという前提を取り下げました。

誤りがゼロにならない前提で判定を組むなら、決めるべきなのは「誤りが出たときにどう扱うか」です。どの層で外れたら出さないのか、どの層なら人の確認を挟んで運用するのかを、あらかじめ決めておきましょう。

Agentforceの品質を評価する3つの層

前章で、従来のテストが通用しない理由を3つ整理しました。では、何を見れば良し悪しを判断できるのでしょうか。それは、エージェントの処理を1つの結果としてまとめて見ずに、判定できる単位へ分けた層です。そこでここでは、Agentforceの品質を評価する3つの層を整理します。

サブエージェント選択とアクション選択は一致するかしないかで判定できる一方、応答内容だけは正解が1つに定まらないため、判定の方法を別に用意する必要があります。

なお、この三層は、エージェントが誤作動したときに原因を切り分けるための分類とは違います。リリース前に、どこまで一致すれば出してよいかという合格線を引くための分類です。評価の対象になる機能の全体像を先に押さえたい場合は、ほか記事「Agentforceの機能一覧」をご確認ください。

層①依頼を受け取るサブエージェントの選択

1つ目の層は、依頼を受け取るサブエージェントの選択です。利用者が投げた文章は、まずAgent Routerによって、どのサブエージェントが扱う依頼かを判断されます。ここが外れると、後の処理がすべて別の担当の手順で進みます。

なお、サブエージェントは2026年4月にtopicsから名称が変更された単位で、移行期は新旧の表記が混在すると公式ドキュメントにも明記されています。振り分けを担う部分の現在の名称はAgent Routerです。画面と資料で違う名前を見て戸惑うのは自然なことです。

※参考記事はこちら

このBtoBサービス企業のエージェントには、契約内容の照会・障害の受付・請求に関する問い合わせという3つのサブエージェントを置いていました。「先月の請求額が前と違うのですが」という文章が契約照会のサブエージェントに渡ると、契約内容の説明だけが返り、請求明細は一度も参照されません。回答の文面は落ち着いて読めるため、担当者が見ても誤りだと気づきにくいのです。

依頼が正しい担当に渡ったかどうかは、期待したサブエージェントと実際のサブエージェントが一致したかで判定できます。一致か不一致かで結果が出る層なので、不一致を残したまま本番へ出す理由がありません。

層②業務を実行するアクションの選択

2つ目の層は、業務を実行するアクションの選択です。サブエージェントが正しく選ばれても、その中で呼び出す処理が違えば、レコードは動きません。読み取りだけの処理を呼ぶのか、更新まで行う処理を呼ぶのかで、実害の大きさも変わります。

このBtoBサービス企業では、障害の受付を任せる際に、ケースを新規作成するアクションと、既存ケースにコメントを追加するアクションの2つを用意していました。すでに起票済みの障害について続報を伝えた利用者の依頼で新規作成のアクションが呼ばれると、同じ障害のケースが2件並びます。窓口の担当者が重複に気づいて統合するまで、対応状況が二重に管理されていました。

この層の不一致は、利用者に返る文章には表れません。データの状態を確認して初めて分かるため、テストの段階で期待するアクションを書き出しておかないと、稼働後まで見つからないままになります。

層③利用者に返す応答の内容

3つ目の層は、利用者に返す応答の内容です。ここまでの2層が期待どおりでも、正解が1つに定まらないこの層で必要な条件が抜けていれば、利用者は誤った理解のまま行動します。

たとえば、このBtoBサービス企業の窓口には「解約したい」という問い合わせが月に十数件届いており、正しい回答には、解約の受付窓口・申し出の期限・違約金が発生する条件という3つの要素が必要でした。ところがエージェントの応答は受付窓口と期限だけを書き、違約金の条件を落とす場合がありました。読みやすい文章だったため、社内のレビューでも見落とされかけたのです。

この層で確認すべきなのは、文章が似ているかどうかより、必要な要素が含まれているかどうかです。一致で判定できない以上、採点の条件を自社で言語化し、そのうえで人の確認をどこまで残すかを決める設計に変わります。

Agentforceのテストで合格を判定する3つの基準

前章では評価の対象を三層に分けました。ここからは、その三層それぞれに、どこまで一致すれば出してよいかという線を引く作業に入ります。そこでここでは、Agentforceのテストで合格を判定する3つの基準を整理していきます。

合格の水準は、正答率を先に置いて決めるものではなく、誤答が起きたときに誰が何を損なうかから逆算して決めるものです。

基準①誤答したときの実害から許容水準を逆算する

1つ目の基準は、誤答したときの実害から許容水準を逆算することです。何割正解すれば出してよいかという数字を先に決めても、その数字の根拠を法務にも情報システム部にも説明できません。Salesforceの公式教材でも、精度の基準は業種ごとに自社で決める必要があるとされています。

そこで、対象の業務を実害の大きさで3段階に分けます。このBtoBサービス企業では、違約金の条件を含む解約の案内を1段階目、社内の担当者向けに障害の影響範囲をまとめる依頼を2段階目、営業時間や受付窓口の案内を3段階目に置きました。

区分が決まると、層ごとの扱いが交点で一意に決まります。次の表が、判定会議にそのまま持ち込んだ形です。

応答内容層に人の確認を残すのは、機械による採点にも限界があるからです。査読前の論文ですが、専門知識を要する領域では、大規模言語モデルによる採点と専門家の判断の一致率が、栄養学とメンタルヘルスという2つの専門領域での検証で64〜68%にとどまったと報告されています。この数値はAgentforceの精度を表すものではありませんが、専門的な内容ほど機械の採点だけに任せられないという判断の材料にはなります。

※参考記事はこちら

基準②三層のどこで外れたかで扱いを分ける

2つ目の基準は、三層のどこで外れたかによって扱いを分けることです。不合格という結果は同じでも、層が違えば意味がまったく変わります。件数を合算して見てしまうと、この違いが消えてしまいます。

サブエージェント選択層の不一致は、依頼が別の担当に渡っている構造の誤りです。アクション選択層の不一致は、データが動かないか、誤って動くという実害に直結します。応答内容層の不一致は、正解が1つに定まらないため、不一致であること自体が誤りとは限りません。

このBtoBサービス企業でも、はじめは不合格の件数を1つの数字でまとめていました。層ごとに分け直したところ、サブエージェント選択層とアクション選択層の不一致は、指示文と参照ナレッジを直せば消える性質のものだと分かった一方、応答内容層の不一致には、そもそも期待値の書き方が細かすぎたケースが混ざっていたのです。

不合格の件数は、必ず層ごとに分けて数えておきましょう。上2層と3層目では直す対象が指示文なのか期待値なのかが変わるため、合算した件数のままでは修正の担当を割り振れません。

基準③再テストの条件を変更の内容で決める

3つ目の基準は、再テストの引き金を、実施回数で決めずに変更の内容で決めることです。月に1回まとめて回すといった決め方をすると、危険な変更が1か月放置される一方、文言を直しただけで全件を回し直すことになります。

全件を回し直す変更と、該当するケースだけを再実行すれば足りる変更を、先に分けておきます。

再テストの範囲を決める変更の区分 ①全件を回し直す変更・・・サブエージェントの追加、アクションの差し替え、参照ナレッジの入れ替え、利用するモデルの変更 ②該当ケースだけ再実行する変更・・・指示文の言い回しの修正、応答の書式の調整

このBtoBサービス企業では、参照ナレッジを1本入れ替えた際に、該当する数件だけを再実行して済ませようとしていました。ところが入れ替えたナレッジは解約の条件を含んでおり、契約照会と請求の両方のサブエージェントが参照していたため、影響は数件では収まりませんでした。区分を先に決めていれば迷わずに済んだ場面です。

この線引きは、テストを実行するたびに費用が発生する以上、品質だけの話では終わりません。

以上が、Agentforceのテストで合格を判定する3つの基準です。

Agentforceのテストで用意する3種類の入力

ここまでで、何を見て、どこまで一致すれば出してよいかが決まりました。次に必要になるのは、その判定にかける入力です。そこでここでは、Agentforceのテストで用意する3種類の入力を整理します。

テストの入力で結果を左右するのは件数より、実際に窓口へ届いた文章を出発点にして、届き方の違いで3種類に分類して集めることです。

入力①窓口に実際に届いた問い合わせ文

1種類目は、窓口に実際に届いた問い合わせ文です。担当者が自分で考えた質問は、担当者が理解している業務の言葉で書かれます。利用者はその言葉を使いません。

このBtoBサービス企業では、直近3か月のケースの件名と初回の問い合わせ本文を抽出し、内容の似たものをまとめたうえで、件数の多い順に80件を選びました。上位に並んだのは、障害の受付、保守契約の更新時期、請求金額の内訳、解約の条件の4種類です。担当者が最初に用意していた質問リストには、請求金額の内訳がまったく入っていませんでした。

件数の目安は、全網羅を目指さず、問い合わせの多い順に積み上げて、上位のどこまでを対象にするかで決めましょう。営業側で実際に届く依頼文の例は、ほか記事「Agentforce for Sales」も参考になります。

入力②略語や誤字のまま打ち込まれた文

2種類目は、略語や誤字がそのまま入っている文です。実際の問い合わせは、整った文章では届きません。社内の略称、製品名の一部だけ、変換ミスを含んだ表記が混ざります。

このBtoBサービス企業のケース本文には、自社製品を社内の略称で書いたもの、「更新」を「後進」と変換したまま送信されたもの、症状だけを単語で並べて送信ボタンを押したものが含まれていました。担当者はこの種類から25件を抜き出して、原文のまま登録しています。整った日本語に直して登録すると、実際に届く文章では通用しない判定になってしまうからです。

この種類を入れておくと、依頼が正しい担当に渡るかどうかの弱点が先に見つかります。1件でも表記を整えて登録すれば、その1件は実際には試していない発話に変わってしまいます。

入力③業務の範囲外から持ち込まれる依頼文

3種類目は、業務の範囲外から持ち込まれる依頼文です。窓口には、そのエージェントが担当しない依頼も届きます。範囲外の依頼に対して何を返すかは、範囲内の精度と同じくらい判定の対象になります。

たとえば、このBtoBサービス企業のサポート窓口には、他社製品の設定方法を尋ねる問い合わせや、採用に関する問い合わせが月に数件届いていました。担当者はこの種類を15件用意し、期待する応答を「回答せず、担当窓口へ案内する」と定義しています。範囲外の依頼にもっともらしく答えてしまう応答は、誤答のなかでも取り消しが効きにくい種類だからです。

3種類を合わせて、このBtoBサービス企業が用意した入力は120件になりました。ここまでが、Agentforceのテストで用意する3種類の入力です。

Agentforceのテストで確認できない3つの範囲

前章で入力の集め方を整理しましたが、集めた入力をすべて通したとしても、確認できたと言える範囲には限りがあり、ここを先に開示しておかないと、承認の場で過剰な期待を持たれたまま話が進みます。そこでここでは、Agentforceのテストで確認できない3つの範囲を整理していきます。

テストを通したという事実が保証するのは、用意した入力に対する挙動だけであり、確認できていない範囲を明示することまで含めて、承認の材料になります。

範囲①本番データでしか起きない不具合

1つ目の範囲は、本番のデータでしか起きない不具合です。検証環境のデータは、本番の写しであっても件数・状態の偏り・古い書式の残り方までは再現しません。参照するレコードの中身が違えば、同じ質問でも返る内容が変わります。

このBtoBサービス企業の検証環境には、本番の顧客データが一部しか入っていませんでした。契約が1件だけ登録されている取引先のデータで検証していたため、同じ取引先に複数の保守契約がひも付いている場合の挙動は、テストの対象に入っていなかったのです。担当者は判定会議の資料に、この点を確認できていない範囲として書き添えました。

データの状態に依存する挙動は、テストの件数を増やしても埋まりません。稼働の初期に人が確認する対象として残す、という扱いで設計しましょう。

範囲②利用者が納得したかどうかの実感

2つ目の範囲は、利用者が納得したかどうかです。応答が正しいことと、利用者が納得することは別の結果です。必要な情報がすべて含まれていても、説明の順序が分かりにくければ、利用者は結局あらためて問い合わせます。

このBtoBサービス企業の解約に関する応答は、必要な3要素を含んだうえで、条文の引用から書き始める構成になっていました。内容としては合格でしたが、窓口の責任者からは、これでは利用者が結論にたどり着くまでに読み進める量が多すぎるという指摘が出ています。テストの判定はどちらも合格のままでした。

納得したかどうかは、稼働後に問い合わせ直された件数や、担当者への引き継ぎが発生した件数で確認するしかありません。この範囲は、リリース前の判定で担保できない対象として、承認の場で先に伝えておきましょう。

範囲③時間の経過で変わるモデルの挙動

3つ目の範囲は、時間の経過で変わる挙動です。判定した時点の結果は、そのときの構成での結果です。参照するナレッジが更新されたり、利用するモデルが切り替わったりすれば、同じ入力に対する応答も変わります。

このBtoBサービス企業の管理者は情報システム部の兼任1名で、ナレッジの更新はサポート部門が随時行っていました。テストを通した2週間後にはすでに、解約に関するナレッジが1本更新されています。判定に使った条件がいつまで有効なのかを決めていなければ、承認は取得した瞬間から古くなっていきます。

だからこそ、いつ何を変えたら判定をやり直すのかという条件を、判定結果とセットで記録しておく必要があります。ここまでが、Agentforceのテストで確認できない3つの範囲です。

テストセンターで定義する4つのテスト項目

ここまでは、何を見て、どこまで一致すれば出してよいか、どこは確認できないかという設計の話でした。ここからは、その判断をテストセンターの設定として登録していきます。そこでここでは、テストセンターで定義する4つのテスト項目を整理します。

テストセンターに登録するのは三層それぞれに対する期待値であり、この4項目が前章までに決めた合格の基準をそのまま形にしたものになります。

なお、提供状況は一枚岩ではありません。テストセンターは2024年11月にSandbox向けの一般提供が告知された機能ですが、2026年8月時点の公式教材ではテストスイートに「Beta」の表記が残り、Agentforce Studio内の次世代のテスト機能、YAMLまたはJSON形式で定義する評価、Custom Scorersもベータとして案内されています。ベータの部分は仕様が変わりうる前提で扱ってください。また、テストの実行はCRMのデータを変更しうるため、公式にSandbox環境でのみ使うことが求められています。

※参考記事はこちら

項目①利用者が入力する発話文

1つ目の項目は、利用者が入力する発話文です。CSVテンプレートではUtteranceという列にあたり、この列だけが必須になっています。前章で集めた3種類の入力が、そのままこの列に入ります。

このBtoBサービス企業は、集めた120件を表計算ソフトに並べ、原文のまま貼り付けていきました。誤字や略称を直さずに登録したのは、直した文章で通ることを確認しても、実際に届く文章での挙動が分からないためです。1件につき1行という単位なので、件数がそのままテストの規模になります。

発話文の質が、その後の3項目すべての意味を決めます。どこから集めた文章なのかを列の外に記録しておくと、後から入力の偏りを点検できます。

項目②期待するサブエージェント

2つ目の項目は、期待するサブエージェントです。Expected Subagentという列に、その発話を受け取るべきサブエージェントの名前を書きます。三層のうち1層目に対する期待値にあたります。

ここで注意したいのが、名称の新旧が混在している点です。テストケースの入力列は Expected Subagent という新しい名前になっている一方、APIが返す評価指標の名前は `topic_sequence_match`（期待したサブエージェントで応答したか）と、旧称のtopicのまま残っています。画面とAPIで違う名前が出てくるため、結果を読むときに別ものだと誤解しやすい箇所です。

このBtoBサービス企業では、120件のうち請求に関する発話が28件、障害の受付が34件、契約照会が43件、範囲外が15件という内訳になりました。期待するサブエージェントを書き出す作業が、そのまま依頼の振り分け設計の点検になっています。

項目③期待するアクション

3つ目の項目は、期待するアクションです。Expected Actionsという列に、その依頼で実行されるべき処理を書きます。三層のうち2層目に対する期待値であり、データが動く層なので、実害の判定に直結します。

この列に書くのは、画面に表示されるラベルではありません。システムが認識する識別子です。標準アクションはラベルと識別子が一致しないものが多く、見た目の表記をそのまま書き写すと、実際には正しく動いていても不一致として記録されます。アクションの詳細画面から、参照されている識別子を直接読み取って書き写しましょう。

このBtoBサービス企業でも、障害の受付で呼ばれるアクションを画面表記のまま書いて登録し、最初の実行で該当する34件がすべて不一致になりました。識別子に書き直したところ、不一致は6件まで減っています。

項目④期待する応答の内容

4つ目の項目は、期待する応答の内容です。Expected Responseという列に、返してほしい内容を書きます。ここは正解が1つに定まらない層なので、文面を一致させる目的では書きません。

なお、Utterance以外の3列は、少なくとも1列以上を埋める必要があります。空欄のまま登録した値は失敗として扱われる、と公式に明記されているため、埋めない列を残すと、判定の対象にしていない項目まで不合格として数えられてしまいます。

※参考記事はこちら

このBtoBサービス企業では、解約に関する発話について「解約の受付窓口、申し出の期限、違約金が発生する条件の3点を含む」という粒度で書き、文面の言い回しまでは指定しませんでした。文面まで書かずに要素で示しておけば、応答の言い回しが変わっても、同じ期待値を使い続けられます。

Ground Truthを決めるときの3つの落とし穴

前章で4つのテスト項目を整理しましたが、この4項目に書き込む期待値の総称がGround Truth（正解データ）であり、独立した機能名ではありません。この期待値は、書き方しだいで結果の意味が大きく変わります。そこでここでは、Ground Truthを決めるときの3つの落とし穴を整理していきます。

不合格の件数が多いとき、疑うべきなのはエージェントの精度より先に、期待値の書き方です。

落とし穴①期待する応答を書き込みすぎること

1つ目の落とし穴は、期待する応答を書き込みすぎることです。正しく判定したいという意識が働くほど、期待値には具体的な文章を書きたくなります。ところが応答内容層は、文面が違っても内容が合っていれば合格にすべき層です。

このBtoBサービス企業では、はじめ解約の案内について、実際に窓口の担当者が使っていた回答文を丸ごと貼り付けていました。その結果、必要な3要素を正しく含んだ応答まで、言い回しが違うという理由で不一致として並んだのです。担当者は21件の不一致を1件ずつ読み直し、そのうち14件が期待値の書きすぎによるものだと判別しました。

期待値は、含まれているべき要素を列挙する粒度にとどめましょう。文章を書き込むほど、判定は厳しくなりません。かえって判定の意味が失われていきます。

落とし穴②空欄で登録して失敗扱いになること

2つ目の落とし穴は、判定しない項目を空欄のまま登録することです。判定する必要がない列は空けておけばよい、と考えると、前章で触れたとおり、その項目は失敗として扱われます。

たとえば、このBtoBサービス企業は、範囲外の依頼15件について、実行されるべきアクションが存在しないと考えてExpected Actionsの列を空けようとしていました。この状態で実行すると、範囲外の依頼はすべてアクション選択層の不合格として数えられます。案内だけを返す設計であることが、結果の画面からは読み取れなくなってしまうのです。

判定の対象にしない列は、空欄で残さず、その扱いを別の記録に残しておきましょう。空欄のまま実行すると、範囲外の15件がアクション選択層の不合格として集計に残り、層ごとの件数そのものがずれてしまいます。

落とし穴③アクションを画面の表記で書くこと

3つ目の落とし穴は、アクションを画面の表記で書くことです。標準アクションは、画面に出るラベルと、システムが参照する識別子が一致しません。ラベルから識別子を推測すると、ほとんど当たらないのが実情です。

先ほど34件が丸ごと不一致になったこのBtoBサービス企業でも、エージェント側は正しいアクションを呼んでいました。名前が一致しないという理由だけで、判定の結果が失敗と表示されていたのです。この種類の不合格は、エージェント側の問題というより、登録の問題です。

登録の誤りかどうかは、不一致がひとつのサブエージェントに集中しているかどうかで見分けられます。期待値を書いた直後に数件だけ実行して、不一致がまとまって出ていないかを確認しましょう。まとまった不一致は、たいてい書き方の誤りを示しています。

LLM-as-a-Judgeが採点する4つの観点

前章では期待値の書き方を整理しました。では、正解が1つに定まらない応答内容層を、どうやって採点するのでしょうか。それは、応答の妥当さを別の大規模言語モデルに読ませて採点する、LLM-as-a-Judgeという手法です。そこでここでは、その採点で使われる4つの観点を整理します。

応答内容の採点では、どの観点で読ませるかを自社が指定するところまでが設計の範囲であり、合否の判断を機械に任せきる仕組みではありません。

なお、LLM-as-a-Judgeは一般的な評価手法の呼称であって、Salesforceの機能名ではありません。大規模言語モデルによる評価手法を機能・手法・応用・メタ評価・限界の観点から整理したサーベイ論文が公開されており、分野として確立した呼び方です。Agentforce上での設定名は「カスタム評価条件」および「Custom Scorers」になります。

※参考記事はこちら

観点①応答が筋の通った文になっているか

1つ目の観点は、応答が筋の通った文になっているかどうかです。評価指標の名前は `coherence`（一貫性）で、応答が理解しやすく、文法上の誤りがないかを判定し、PASSまたはFAILEDを返します。

この観点は、日本語の応答では特に確認しておきたい項目です。ナレッジから引用した文と、モデルが生成した説明文が接続されずに並ぶと、書かれている情報は正しいのに読み進められない応答になります。このBtoBサービス企業でも、障害の受付に対する応答で、受付番号の案内と復旧の見通しの説明が別々の文体で並び、一貫性の判定が落ちたケースが3件ありました。

文として読めるかどうかは内容の正しさとは別に確認する項目であり、この観点だけが落ちている応答は、指示文で応答の構成を指定すれば改善します。

観点②必要な情報が欠けていないか

2つ目の観点は、必要な情報が欠けていないかどうかです。評価指標の名前は `completeness`（網羅性）で、応答に必要な情報がすべて含まれているかを判定します。三層のうち3層目で、実害に最も近い観点です。

先ほどの解約の応答で違約金の条件が落ちていた例は、文章としては自然に読めるため、一貫性の観点では合格します。落ちているのは網羅性のほうです。

窓口の責任者と洗い出した3つの要素のうち、1つでも欠ければこの観点は落ちます。必要な要素を先に列挙しておかないと、この観点は判定できません。前章で期待値を要素の列挙で書くとしたのは、この観点で読ませるためです。金銭や契約に関わる業務ほど、落としてはいけない要素が増えるため、業務の区分ごとに要素の一覧を用意しておきましょう。

観点③冗長さがなく簡潔に収まっているか

3つ目の観点は、冗長さがなく簡潔に収まっているかどうかです。評価指標の名前は `conciseness`（簡潔性）で、網羅していながら短いほど良い、という基準で判定します。網羅性とは反対の方向に働く観点であり、この2つは同時に満たしにくくなります。

そこで、どちらを優先するかを業務ごとに決めておきましょう。このBtoBサービス企業では、解約や請求のように条件を落とせない依頼では網羅性を優先し、営業時間や受付窓口の案内では簡潔性を優先する、という方針を決めました。方針を決めずに両方を合格条件にすると、どちらの観点も中途半端な応答になります。

業務ごとの優先順位を決めていれば、簡潔性の判定が落ちても、そのまま合格として扱ってよい対象かどうかを迷わずに判断できます。

観点④指示どおりの答え方をしているか

4つ目の観点は、指示どおりの答え方をしているかどうかです。評価指標の名前は `instruction_adherence`（指示への追従）で、サブエージェントに与えた指示にどれだけ沿った応答かを判定し、HIGH・LOW・UNCERTAINのいずれかを返します。ほかの観点がPASSとFAILEDを返すのに対し、この観点だけは3段階で返ります。

このBtoBサービス企業では、範囲外の依頼に対して「回答せず、担当窓口へ案内する」という指示を与えていました。他社製品の設定方法を尋ねる発話に対して、エージェントが一般論として答えてしまった応答は、内容の正しさとは関係なく、この観点でLOWと判定されます。範囲外の依頼を判定できるのは、この観点です。

UNCERTAINが返ったものは、指示文があいまいで判定できなかった可能性が高いため、応答よりも先に指示文を読み直しましょう。以上が、応答内容を採点する4つの観点です。

Agentforceのテストを回す3つの実行手段

前章までで、何をどう採点するかが決まりました。次に決めるのは、それをどの場面でどう実行するかです。そこでここでは、Agentforceのテストを実行する3つの手段を整理していきます。

3つの手段は、作りながら試す場面、まとめて判定する場面、変更のたびに自動で実行する場面という、使う場面の違いで選び分けます。

手段①作りながら試すプレビュー画面

1つ目の手段は、エージェントを組み立てながら使うプレビュー画面です。1件ずつ発話を入力して、どのサブエージェントが選ばれ、どのアクションが実行されたかを、その場で確認できます。

このBtoBサービス企業の担当者が最初の3週間で行っていたのも、この画面での確認でした。指示文を直しては1件投げ、また直しては1件投げる、という進め方です。作っている最中の手応えは得られますが、記録が残らないため、承認の材料にはなりませんでした。

なお、この画面での実行でも、アクションが動けばFlex Creditsは消費されます。1件ずつの確認を延々と続けるより、ある程度まとまった時点でまとめて回すほうが、費用の面でも記録の面でも合理的です。

手段②まとめて回すテストセンター

2つ目の手段は、テストケースをまとめて実行するテストセンターです。用意した発話と期待値を一括で流し込み、三層それぞれの判定結果を一覧で受け取れます。判定会議に持ち込む記録が残るのは、この手段です。

実行結果の画面には、実際に選ばれたアクションと期待値との判定、実際の応答と期待した内容との判定が並びます。このBtoBサービス企業は120件を一括で実行し、層ごとの不合格件数を数えられる形で受け取りました。1件ずつ試していたときには存在しなかった数字が、ここで初めて手に入っています。

判定の記録を残したい段階に入ったら、この手段に切り替えましょう。逆に、指示文をまだ大きく書き換えている段階では、一括実行の消費に見合いません。

手段③自動化に組み込むTesting API

3つ目の手段は、Testing APIです。テストをプログラムから構築し、多数のリクエストを短時間で評価できます。実行はREST API、Connect API、Salesforce CLIの `agent test run` コマンドから行い、定義の配布の前工程として組み込む使い方もあります。

なお、この手段の提供形態はドキュメントで確認できますが、正式提供かベータかの明示は公式ページ上で確認できませんでした。自動化の設計に組み込む前に、提供状況を確認してください。このBtoBサービス企業も、定義をまだコードとして管理していないため、この手段は判定会議のあとの検討課題として残しました。

エージェントの定義をコードとして管理し、変更のたびに配布まで自動で流す体制であれば、この手段をその流れに組み込む価値があります。IDE側でコードを書く支援については、ほか記事「Agentforce Vibesとは」で解説していますが、こちらはコードを生成する道具であり、エージェントの応答を評価する本記事の手段とは役割が違います。

Agentforceのテストを本番判定へ進める4ステップ

ここまでで、実行する手段の選び方までが決まりました。そこでここでは、判定会議までに何をどの順で進めるかを、Agentforceのテストを本番判定へ進める4ステップとして解説していきます。

各ステップの終わりに残すのは自社で数えられる件数であり、この件数がそのまま承認の場で示す材料になります。

ステップ①窓口の問い合わせからテスト入力を集める

最初に取りかかるのは、テストにかける発話を集める作業です。実際に届いた文章を抽出していく工程なので、着手した日から数日で終わります。

このBtoBサービス企業では、直近3か月のケースから、窓口に実際に届いた問い合わせ文を80件、略語や誤字を含む文を25件、業務の範囲外から持ち込まれた依頼文を15件、合わせて120件を集めました。ここで内訳を記録しておくと、後から「どの種類の入力が足りていないか」を指摘されたときに、その場で答えられます。

集めた発話の件数と3種類ごとの内訳を書き出せない状態なら、このステップはまだ終わっていません。件数の目標を先に置かず、直近3か月という抽出の期間と、どこで切ったかまで記録しておきましょう。

ステップ②三層それぞれの期待値を書き起こす

発話が集まったら、次は1件ごとに三層の期待値を書き起こします。工程のなかで最も時間がかかるのがここで、集めた件数がそのまま作業量になります。

このBtoBサービス企業では、期待するサブエージェントと期待するアクションは、業務の分類がすでに決まっていたため機械的に埋まりました。時間がかかったのは期待する応答のほうで、解約や請求のように条件を落とせない依頼について、含まれているべき要素を窓口の責任者と一緒に洗い出す作業に、延べ数日を要しています。範囲外の15件については、アクションの列を空欄にせず、案内だけを返す扱いとして別に記録しました。

期待値を書いた件数と、空欄のまま残した列の数を数え、空欄がゼロであることを確認してから次のステップへ進みましょう。

ステップ③Sandboxで一括実行して不合格を分類する

期待値が揃ったら、Sandbox環境で一括実行します。ここで初めて、層ごとの不合格件数という数字が手に入ります。

このBtoBサービス企業は、先ほどの識別子の取り違えを書き直したうえで再実行し、サブエージェント選択層で9件、アクション選択層で6件、応答内容層で21件という不合格を受け取りました。合計36件という数字を、層ごとに分けたまま記録しています。

なお、ここで行うのはエージェントの応答に対するテストであり、変更セットのリリース時に選ぶApexのテストオプションとは別ものです。本番反映の直前には、見た目の小さな変更でもフローやApex、周辺の自動化処理に影響することがあるため、そちらのテストも別途必要になります。

※参考記事はこちら

ステップ④不合格が定義の不備かを先に判別する

最後に行うのは、出てきた不合格を1件ずつ読み直して、原因がエージェント側にあるのか、期待値の書き方にあるのかを判別する作業です。この判別を飛ばして指示文を直し始めると、直す必要のない箇所を直すことになります。

このBtoBサービス企業では、36件のうち22件がエージェント側の定義に原因のあるもので、残りは期待値の書きすぎによるものでした。内訳は、サブエージェント選択層の9件と、アクション選択層の6件がすべて定義側、応答内容層の21件のうち7件が定義側、14件が期待値の粒度の問題です。定義側の22件を修正したうえで、応答内容層については人の確認を必須にする対象を14件と定めました。

以上が、Agentforceのテストを本番判定へ進める4ステップです。

Agentforceの定義を検証しても残る3つの見落とし

前章までの工程を踏めば、承認の場に持ち込む数字は揃います。ここで1つ、実装の現場で分かったことをお伝えしておきます。エージェントの定義をコードとして扱っている場合、その構文検証が通っていても、動作は保証されません。そこでここでは、定義の検証だけでは残る3つの見落としを整理していきます。

構文検証の成功が示しているのは、書式として正しく書けているという事実だけであり、書かれた内容が実際に動くかどうかは一度も確認されていません。

見落とし①アクションが実在するかを見ていない

1つ目の見落としは、書かれたアクションが実在するかどうかを、構文検証が見ていないことです。存在しないアクション名を書いたまま検証をかけても、結果は `Errors: 0` と表示されます。書式として正しく書けていれば、参照先が存在しなくても検証は通ります。

このBtoBサービス企業でも、標準アクションの識別子を1文字取り違えたまま定義を保存し、検証を通していました。実際に発話を投げて初めて、期待したアクションが呼ばれていないことが分かっています。検証の結果を見て安心していた分だけ、気づくのが遅れました。

検証が通ったという結果は、承認の材料になりません。実際に発話を投げて、期待したアクションが呼ばれたかを確認するところまでが必要です。

見落とし②選ばれるサブエージェントは対象外

2つ目の見落としは、どのサブエージェントが選ばれるかが、そもそも構文検証の対象に入っていないことです。振り分けは、発話を受け取ったAgent Routerが実行時に判断します。定義を静的に読むだけでは、判断の結果は分かりません。

このBtoBサービス企業の定義には、契約照会・障害の受付・請求という3つのサブエージェントが正しい書式で並んでいました。検証はもちろん通ります。ところが「先月の請求額が前と違うのですが」という発話が契約照会に渡っていたことは、実行して結果を見るまで分からなかったのです。

振り分けの結果は実行しなければ観測できないため、三層のうち1層目は、定義の検証では担保されない対象になります。

見落とし③応答の中身は判定されないまま

3つ目の見落としは、返ってくる応答の中身が、検証の対象にまったく入っていないことです。応答は実行時に生成されるものなので、定義を読む処理が判定できる余地がありません。三層のうち3層目も、同じ理由で対象外です。

つまり、構文検証が通っている状態で保証されているのは、書式の正しさだけです。三層のどの層も、定義の検証では担保されません。このBtoBサービス企業の担当者が「検証は通っています」と会議で言いかけて止めたのは、この構造に気づいたからでした。

では、何を検証すれば「出せる」と言えるのでしょうか。それは、三層それぞれに期待値を置き、実際に発話を投げて、層ごとの不一致を数えた記録です。前章までに整理した三層の分類と4ステップの工程が、そのまま検証の中身になります。

Agentforceの評価機能の変更に備える3つの対処

前章では、検証が通っても動作が保証されないことを整理しました。もう1つ、運用の設計で織り込んでおきたいのが、評価の仕組み自体が変わりうるという前提です。そこでここでは、Agentforceの評価機能の変更に備える3つの対処を整理していきます。

ベータの機能に依存する部分は、画面や出力の形式が変わっても判定の考え方が残るように、道具の外側に記録を持たせておく必要があります。

対処①評価基準を自社の文書にも残す

1つ目の対処は、評価の基準を自社の文書にも残しておくことです。前述のとおり、Agentforce Studio内の次世代のテスト機能やCustom Scorersは2026年8月時点でベータであり、UIや評価の基準は変更される可能性があります。

このBtoBサービス企業では、業務影響の3区分と三層の交点をまとめた表を、社内の共有ドライブに置いています。ツールの画面で設定した内容とは別に、なぜその扱いにしたのかという判断の根拠を文書として残しました。管理者が兼任1名という体制では、設定の意図が本人の記憶にしか残らない状態が最も危険だからです。

判断の記録が道具の外にあれば、画面が変わっても設定し直せます。ベータの機能を使うかどうかより、記録がどこにあるかのほうが、運用の継続性を左右します。

対処②画面名に依存しない手順書を書く

2つ目の対処は、社内の手順書を画面の名前に依存しない書き方にすることです。「この画面のこのボタンを押す」という書き方は、ボタンの位置が変わった瞬間に使えなくなります。

たとえば、このBtoBサービス企業の手順書は、当初「テストスイート画面の右上から実行」という書き方をしていました。これを「用意したテストケースを一括で実行し、層ごとの判定結果を書き出す」という、目的と入出力を書く形に直しています。画面が変わっても、何をしたいかが分かれば操作は追えるという考え方です。

手順書には、操作の順序よりも、その工程で何を残すかを書きましょう。前章の表に挙げた数字が、そのまま各工程の出力になります。担当者が交代しても、残すべき数字が書いてあれば同じ工程を再現できます。

対処③出力形式の変更を前提に集計を組む

3つ目の対処は、結果の出力形式が変わる前提で集計を組むことです。書き出したファイルの列の並びをそのまま参照する集計を作ると、列が1つ増えただけで壊れます。

このBtoBサービス企業では、実行結果から層ごとの不合格件数を数える集計を、列の位置を参照する形から、列の名前で参照する形へ組み直しました。あわせて、月次で見るのは層ごとの不合格件数と、人の確認を必須にした対象の件数の2つだけに絞っています。項目を増やしすぎると、形式が変わるたびに直す箇所も増えるためです。

変更に追随するために必要な知識の水準については、ほか記事「Agentforceスペシャリスト資格」が目安になります。ここまでが、評価機能の変更に備える3つの対処です。

Agentforceのテストにかかる3つのコスト

前章までで、判定の設計と運用の備えが揃いました。ここで正面から扱っておきたいのが、この進め方を続けたときに何がどれだけかかるのかという問いです。本章で扱うのは、テストを実行する行為で消費される分と、期待値の作成・基準の見直しにかかる工数であり、ライセンスの料金体系には踏み込みません。そこでここでは、Agentforceのテストにかかる3つのコストを整理していきます。

テストの費用は、実行で消費される分に加えて、期待値を作る工数と基準を見直す工数まで含めて見積もらないと、続けられる体制かどうかを判断できません。

コスト①テストの実行そのもので消費される分

1つ目のコストは、テストの実行そのもので消費される分です。消費されるのはFlex CreditsとData Services Creditsの2種類で、発生源はアクションの実行と、Data 360でのデータ処理になります。エージェントを組み立てながら行うプレビューの実行、テストセンターとテストスイートの実行、テストケースの生成と評価が、いずれも対象です。

2026年8月時点で、標準アクションとカスタムアクションの乗数は、本番が20に対してSandboxが16に設定されています。Salesforceが管理する大規模言語モデルを使う場合の乗数は4または16、自社が用意した大規模言語モデルの持ち込み（BYOLLM）によるStarter Prompts構成では2です。消費はトークン数に基づくため、入力するテキストと生成される応答の両方が対象になります。

※参考記事はこちら

このBtoBサービス企業は120件を一括実行しており、指示文を直すたびに全件を回し直せば、その都度この件数分の消費が積み上がります。実行をSandboxに寄せる、フローで検索の対象データを先に絞る、会話ログの保持設定を外す、といった設計が消費を抑える手段です。

※参考記事はこちら

なお、Flex Creditsは2025年5月の発表時点で10万クレジットあたり6万円、1つのAgentforceアクションが20クレジット（12円）を消費するとされていました。単価は改定されうるため、現在の価格として扱わず、料金体系の全体は、ほか記事「Agentforce料金・ライセンス」で詳しく整理しています。

※参考記事はこちら

コスト②期待値を作り込む工数

2つ目のコストは、期待値を作り込む人の工数です。金額として請求されない分、見積もりから落ちやすい項目ですが、テストの設計で最も時間を使うのはこの作業になります。

このBtoBサービス企業では、120件の発話に対して三層分の期待値を書き切るまでに、延べ数日を要しました。時間を使ったのは期待する応答の要素を洗い出す作業で、窓口の責任者の予定を押さえられた日にしか進みません。管理者は情報システム部の兼任1名で、この作業に専任で入れる人はいませんでした。

工数を抑えるには、全網羅を目指さないことです。対象から外した範囲を確認できていない範囲として承認の場で先に開示しておけば、件数を絞ったこと自体は問題になりません。

コスト③基準の見直しを続ける運用工数

3つ目のコストは、基準の見直しを続ける運用工数です。テストは一度通せば終わりになりません。ナレッジの更新やモデルの切り替えのたびに、判定をやり直すかどうかの判断が発生します。

このBtoBサービス企業は、判定会議のあと、月に一度サポート部門と情報システム部で30分の枠を取り、その月に変わった内容を確認する運用にしました。全件を回し直すのは、先に挙げた4種類の変更があったときだけと決めています。30分の枠で確認するのは、参照ナレッジの更新と指示文の修正の2点だけです。この線引きがないと、判断のたびに全件の消費が発生します。

見直しの工数は、変更の頻度によって決まります。以上が、Agentforceのテストにかかる3つのコストです。

Agentforceのテスト設計が回らない3つのケース

前章でコストの内訳を整理しましたが、費用を用意できれば誰でも同じ進め方ができるわけではありません。この設計は、成立しない体制があります。そこでここでは、Agentforceのテスト設計が続けられなくなる3つのケースを先にお伝えします。

この設計が成立するかどうかを決めるのは、発話を集める経路・合格を承認する人・本番に近いデータという3つが社内に揃っているかどうかです。

ケース①想定発話を集める窓口が社内にない

1つ目のケースは、想定される発話を集める窓口が社内にないことです。テストの入力は、実際に届いた文章から作ります。問い合わせを受ける窓口がなければ、その材料が存在しません。

たとえば、社内の担当者向けに情報を検索させるエージェントを、これから新しく立ち上げる場合が該当します。誰も使ったことがない機能なので、利用者がどんな文章を打ち込むかは、担当者の想像でしか書けません。想像で作った入力で判定しても、実際の利用が始まった時点で不一致が並びます。

この状態に当てはまるなら、まず少人数に限定して使ってもらい、実際の入力を集めるところから始めましょう。範囲を限定した利用であれば、誤答が出ても影響は社内にとどまります。判定の設計は、実際の入力が数十件たまってから始めても遅くありません。

ケース②合格を承認する担当が決まっていない

2つ目のケースは、合格を承認する担当が決まっていないことです。基準を作る人はいても、その基準でよいと決める人がいなければ、判定はいつまでも確定しません。

このBtoBサービス企業でも、当初は基準を作る担当者が、そのまま合格の判断まで行う想定でした。作った本人が判断すると、不合格が出たときに基準のほうを緩める判断が働きやすくなります。実際、応答内容層の不一致が21件出たとき、担当者は最初「応答内容層は参考値でよい」と扱おうとしていました。窓口の責任者を承認の担当に立てたことで、この扱いは撤回されています。

基準を作る役と、合格を決める役は分けましょう。社内で分けられない規模であれば、外部の目を入れる選択肢を検討することになります。外部に頼む場合の選び方は、ほか記事「Agentforce導入支援会社のおすすめ8選」をご参照ください。

ケース③Sandboxに本番相当のデータがない

3つ目のケースは、Sandbox環境に本番相当のデータが入っていないことです。テストはSandboxで実行することが求められている一方、そこにあるデータが本番と大きく違えば、判定の結果も実態と合いません。

このBtoBサービス企業のSandboxは月次でリフレッシュされていたものの、本番の顧客データは一部しか入っておらず、複数の保守契約がひも付いた取引先での挙動を、確認できていない範囲として明示することになりました。データの整備には情報システム部の稼働が必要で、担当者の判断だけでは動かせません。テストの設計に入る前に、どのデータをどこまで移すかを決める工程が挟まります。

大掛かりなテスト体制を組みにくい規模であれば、対象の業務を1つに絞り、そこだけデータを整えるところから始める進め方が現実的です。規模に応じた始め方については、ほか記事「中小企業のAgentforce導入ガイド」もあわせてご確認ください。

Agentforceの品質保証を続ける3つの体制条件

前章では、この設計が成立しないケースを3つ挙げました。続けられる体制には、その反対の条件が共通しています。そこでここでは、Agentforceの品質保証を続ける3つの体制条件を整理していきます。

品質保証を続けられるかどうかを決めるのは、承認する人・発話が集まる経路・不合格を定義の修正につなげる手順という、社内の役割分担です。

条件①合格基準を承認する担当がいること

1つ目の条件は、合格の基準を承認する担当が決まっていることです。前章で触れたとおり、基準を作る役と決める役を同じ人が兼ねると、不合格が出たときに基準のほうが動きます。

このBtoBサービス企業では、業務影響の3区分ごとに承認の担当を分けました。金銭・契約に及ぶ業務は法務、社内の判断材料になる業務はサポート部門の部長、一次回答にとどまる業務は窓口の責任者という割り振りです。区分ごとに承認者を決めておくと、新しい業務をエージェントに任せる際にも、誰に持ち込めばよいかで迷いません。

承認の担当を決めることは責任の所在を決めることでもあり、誤答が出たときに誰が止めるのかという、最初に空白だった問いへの答えがここで埋まります。

条件②現場の問い合わせを集める経路があること

2つ目の条件は、現場に届いた問い合わせが継続的に集まる経路があることです。テストの入力は、利用者の書き方が変われば入れ替えていく対象になります。

このBtoBサービス企業では、窓口の担当者がエージェントの回答を手直しした会話に、決まったラベルを付ける運用にしました。翌月の見直しの際に、そのラベルが付いた会話をテスト入力の候補として読み直します。担当者に新しい作業を増やさず、すでに行っている手直しの作業にラベル付けを1つ足すだけの設計にしたのが、続いている理由です。

入力が更新され続ける経路があれば、判定の内容も現実から離れません。逆に、この経路がなければ、テストは初回の判定のためだけの作業になります。

条件③不合格時に定義を直す手順があること

3つ目の条件は、不合格が出たときに、誰がどこを直すかという手順が決まっていることです。判定して不合格を見つけても、修正の担当と手順がなければ、結果は記録として残るだけになります。

このBtoBサービス企業では、層ごとに修正の担当を分けました。サブエージェント選択層とアクション選択層の不一致は情報システム部の管理者、応答内容層の不一致はサポート部門が期待値の粒度を見直す、という割り振りです。不合格の一覧は自動でSlackのチャンネルへ通知し、そこから修正の担当が起票する流れにしています。通知先の設計については、ほか記事「Agentforce in Slackとは」が参考になります。

なお、ここまでの内容はすべてリリース前の合格判定の話です。稼働が始まったあと、品質が保たれているかを測り続ける指標の設計は、また別の話になります。

自社の業務に合わせて合格の基準を設計するところから相談したい場合は、Agentforce導入・定着支援サービスにお気軽にお問い合わせください。1ユースケース×3ヶ月のスモールスタートから対応しています。

【一問一答】Agentforce テストセンターに関するよくある質問

前章までで、判定の設計から続けるための体制条件までを整理しました。最後に、Agentforce テストセンターについて検索されやすい疑問に、判定の準備で迷いやすい点から順にお答えします。

Agentforce テストセンターは、公式にSandbox環境でのみ使うことが求められており、本番組織での実行は想定されていません。

質問①Agentforce テストセンターは本番組織で実行してよいか

本番組織での実行は避けてください。テストの実行はCRMのデータを変更しうるため、公式にもSandbox環境でのみ使うことが求められています。ケースの作成やレコードの更新を含むアクションが呼ばれると、実際のデータが動きます。

質問②Agentforce テストセンターはベータ機能なのか

提供状況は一枚岩ではありません。テストセンターは2024年11月にSandbox向けの一般提供が告知されましたが、2026年8月時点の公式教材ではテストスイートに「Beta」の表記が残り、Agentforce Studio内の次世代のテスト機能やCustom Scorersもベータとして案内されています。ベータの部分は、UIや評価の基準が変わりうる前提で運用を組んでください。

質問③Agentforce テストセンターのテストは何件あれば足りるのか

必要な件数の基準は、公式にも示されていません。精度の水準は業種ごとに自社で決める必要があるとされているため、件数も同じく自社で決めることになります。全網羅を目指さず、問い合わせの多い順に積み上げて、どこで切ったかを記録し、対象外の範囲を明示するのが現実的な進め方です。

質問④Agentforce テストセンターで日本語の応答も評価できるか

発話も期待値も日本語で登録できます。ただし、応答内容の層は意味の比較で判定するため、言語によって判定の傾向が変わる可能性があります。日本語で運用する場合は、応答内容層の判定を機械の採点だけに任せず、人が抜き取りで確認する対象を残しておくと安全です。対応言語の最新の状況は、公式ドキュメントでご確認ください。

質問⑤Agentforceテストセンターを使わずにテストを自動化できるか

Testing APIとSalesforce CLIの `agent test run` コマンドを使えば、プログラムから実行できます。ただし、自動化できるのは実行と集計の部分であり、三層それぞれの期待値を用意する作業は変わりません。工数の大半は期待値の作成にあるため、自動化だけで負担が大きく減るわけではない点にご注意ください。

質問⑥Agentforce テストセンターの結果を法務にどう示せばよいか

示すべきなのは合格率ではありません。テストした発話の件数、三層それぞれの不合格件数、人の確認を必須にした対象の件数、テストで確認できないと明示した範囲の4つを揃えると、何を確認し、何を確認していないかが1枚で伝わります。確認できていない範囲を先に開示することが、承認を得るうえで有効です。

Agentforceの品質保証は三層の合格基準を決めることから始まる

Agentforceの品質保証は、サブエージェント選択・アクション選択・応答内容という三層それぞれに、どこまで一致すれば出してよいかという合格の基準を決めることから始まります。本記事では、承認が止まる状況の整理から、従来のテストが通用しない理由、三層の分解、業務影響からの逆算、テスト入力の集め方、確認できない範囲の明示、テストセンターへの実装、判定までの4ステップ、コスト、体制の条件までを一続きで整理してきました。

同じ入力に同じ応答が返らない以上、合格の水準を数字で先に置いても、その根拠は説明できません。誤答が起きたときに誰が何を損なうかから逆算し、層ごとに扱いを分けるほうが、上司にも法務にも情報システム部にも同じ表で説明できます。今回例に挙げたBtoBサービス企業も、120件の発話を三層で判定し、不合格36件のうち定義側に原因があった22件を修正したうえで、人の確認を必須にする対象を14件、テストでは確認できない範囲を3つと明示して、判定会議に臨みました。持ち込んだのは、この4つの数字でした。

エージェントを動かすこと自体は目的ではありません。窓口に届く月およそ1,000件の問い合わせのうち、どこまでを安心して任せられるかを決め、業務が実際に軽くなるところまで進めて初めて、導入の目的が果たされます。評価の対象になる機能を整理したい場合は、ほか記事「Agentforceの機能一覧」をご覧ください。

本記事の内容が、自社の品質保証の設計に少しでもお役に立てれば幸いです。