Fin Evalsを使って現実的なテスト会話を作成し、Finの設定で実行して自動的に合否結果を得られます。この記事ではEvalsとSimulationsの作成、手動またはOperator経由での実行、Scorecardsでの結果確認、問題を検出する回帰スイートの構築方法を説明します。

難しい返金リクエスト、怒ったお客様、またはProcedureに加えた変更がFinでどう処理されるかを推測する代わりに、現実的なテスト会話を作成しFinで実行して自動合否結果を得られます。変更のたびに同じテストセットを再実行すれば、Finが期待通りに動作しているか数分でわかります。

Fin Evalsは2つのシンプルな概念で構成されています：

Evalを実行すると、その中のすべてのSimulationが自動的に実行され、設定した基準に基づく決定的チェックとAI判定の組み合わせで各Simulationの合否結果が得られます。

Finの動作は固定されておらず、コンテンツ、Procedure、ガイダンス、応答時にアクセス可能なデータに依存します。これらの変更はFinの他の部分の動作に影響を与え、実際の顧客が問題に遭遇するまで気づきにくいことがあります。

Evalsは現実的な複数ターン会話でFinの動作を繰り返しチェックし、問題が実際の会話に届く前に検出する方法を提供します。

Finの動作に自信を持ちたいときはいつでもEvalを使いましょう：

Simulationsをビジネスに合ったテーマでEvalにグループ化しましょう。ベータ顧客がよく使う出発点：

Operatorにアクセスできれば、EvalsとSimulationsの作成や実行後の結果分析が可能です。

Operatorにアクセスし、ユースケースに合わせたEvalの作成を依頼してください。

Simulations、Simulationチェック、ハンドオフチェックの内容を指示するか、Operatorに推測させることができます。作成後はレビューと承認のために表示されます。

準備ができたら、OperatorにEvalの実行を依頼してください。

各Simulationの実行結果が表示されます。

すべてのSimulationが実行されると、Operatorが結果をまとめて説明します：

Operatorは結果を報告するだけでなく、次のアクションを提案し、実行も申し出ます。

Evalを実行するのにOperatorは必要ありません。Fin AI Agent > Test > Evalsにアクセスして自分で実行してください。

Fin AI Agent > Test > Evalsにアクセスし、New evalをクリックします。わかりやすく説明的な名前（最大250文字）を付けてください。後で再実行するため、何をカバーしているか一目でわかる名前が望ましいです（例：「返金リクエスト - 通常経路とエッジケース」）。

この段階でオプションとしてScorecardを添付し、合否テストに加えてFinの応答品質を定義した基準で測定できます。Scorecardsによる品質評価を見る。

Evalの中で、New Simulationを選択します。各Simulationには以下を入力します:

タイトルを追加しない場合、Simulationは会話内の最初の顧客メッセージから自動的に名前が付けられます。

Simulationが揃ったら、Evalを実行します。Finはグループ内のすべてのSimulationを処理し、以下を返します:

単一の会話で複数のProcedureをまたぐ必要がある場合も、Evalは対応します。シミュレートされた会話が進むにつれてFinがProcedureを切り替える様子を、実際の顧客対応と同様に確認できます。

Simulationがエラーを示す場合は、会話が完了できなかったことを意味します。Simulationの設定（顧客メッセージ、コンテキスト、チェック）に誤りがないか確認してください。失敗の場合は、トランスクリプトとイベントログを開き、Finの動作が設定したチェックとどこで異なったかを確認してください。

Finのコンテンツ、Procedure、ガイダンスに変更を加えた後は、既存のEvalを再実行して回帰をチェックしてください。すべてのSimulationが保存され再利用可能なため、テストシナリオを一から作り直す必要がなく、数秒で済みます。これにより、時間をかけて本格的な回帰テストスイートを構築できます。

最も価値のあるテストの一部は、すでに起こった会話から得られます。Finの回答が十分でなかった実際の会話を見つけたら、その瞬間をリプレイに変え、Finを改善するたびに繰り返し実行して正しい回答になるまで確認できます。

リプレイは、選択したFinの回答までの会話のスナップショットをキャプチャし、それ以前のターンを固定します。Finはその固定された開始点に対して再実行され、現在の回答を確認できます。Finの設定を変更して再実行し比較することで、回答前のすべてが固定されているため、動くターゲットではなく特定の回答だけをテストできます。

実際の会話から保存したリプレイSimulationを使って、問題を診断し修正するワークフローは以下の通りです:

これは実際に起こったことから始めるため、ゼロからシナリオを書く代わりに、実際のミスを恒久的なテストに変える最速の方法です。

HandoffチェックとSimulationチェックはFinが正しい動作をしたかを示します。スコアカードはその実行の良さを示します。

デフォルトでは、すべてのSimulationはHandoffチェック（Finが回答したか、チームまたはWorkflowsに引き継いだか）と設定したSimulationチェック（例：特定のProcedureが起動されたか、データコネクターが呼ばれたか）で評価されます。これはFinの動作に対する合否判定です。

スコアカードはEvalの合否チェックに定性的な評価層を追加します。トーン、ブランドセーフティ、効率など、二元的な結果にきれいに対応しない側面を測定します。スコアカードはMonitorsと共有されるため、変更がライブになる前に同じ品質基準でテストし、Monitorsは変更後にそれを強制します。

スコアカードは1つ以上の基準で構成されます。これは関心のある評価軸（例：「効率」「明確化」「エスカレーションの容易さ」）です。各基準には以下があります。

Evalでは基準はAIジャッジによって自動的にスコア付けされ、Simulationの他の部分と共に評価されます。

Evalにスコアカードを添付すると、各基準が全体スコアにどう寄与するか設定できます。

Evalが実行されると、各Simulationは従来通りHandoffチェックとSimulationチェックの結果に加え、スコアカードスコアと各基準に対するジャッジの評価と理由を表示します。ジャッジの理由が示されるため、なぜその評価になったかが分かり、すぐに修正に活かせます。

Procedure Simulationsは引き続き有効で、特定の目的には最適なツールです：単一のProcedureを単独でテストすること。すべてのテストに成功基準と結果基準を定義する必要があり、個別のProcedureが正しく動作するか検証するのに理想的です。

EvalはProcedure Simulationsの範囲を超えます。Procedure Simulationが単一のProcedureに限定されるのに対し、Eval SimulationはFinの全設定をエンドツーエンドで検証できます。複数のProcedure、コンテンツ、ガイダンス、データコネクターをまたいだリアルな会話を通じて、実際の顧客会話のように動作します。

一緒に使いましょう：

現在、多くのチームはBatch Testを使ってFinを検証しています。これは単一ターンの情報質問を一括で行い、各回答を手動でGood、Acceptable、Poorに評価する方法です。

Fin EvalsはBatch Testの機能をすべて備え、それ以上のことができます。

以下の表はBatch TestとFin Evalsを会話タイプ、スコアリング、回帰テスト、グルーピングの4つの観点で比較しています。

現在Batch Testを使っている場合は、ベータ期間中に同等のテストシナリオをEvalsで作成することをお勧めします。Evalsはより速く、自動化され、より現実的な方法で同じ信頼性以上を得られます。

Evalsで実行できるSimulationの数には月ごとの制限があります。この制限はワークスペース単位で適用され、毎月のカレンダー月の初日にリセットされます。

各ワークスペースには月ごとのSimulation実行数の割り当てがあります。割り当てはワークスペースの会話量セグメントに基づき、大規模な顧客ほど多くの割り当てを受けます。

シミュレーション許容量は、あなたのワークスペースのIntercomでの会話量に基づいています。

以下の表は、ワークスペースの会話量セグメントごとの月間シミュレーション実行許容量を示しています。

テスト管理を支援するため、Evaluationsタブ内に視覚的な指標が表示されます。

使用警告

ワークスペースが月間上限の80％に達すると、黄色の警告バナーが表示されます。現在の使用量（例：「850/1000」）とリセット日時が示されます。

上限到達

月間上限の100％に達すると、赤いエラーメッセージが表示されます。次の月の開始までEvals内でのシミュレーション実行はできません。

Fin Evalsはクローズドベータ版で、現在積極的に開発中です。現時点での注意点は以下の通りです。

明示的なHandoffチェックもシミュレーションチェックもないシミュレーションを追加した場合、Evalsはデフォルトで「ハンドオフなし」基準で評価します。つまり、Finがチームやworkflowにハンドオフせずに会話を解決した場合のみ合格となります。

このデフォルトはシミュレーション設定UIには表示されないため、Finがエスカレーションした場合に意図せずシミュレーションが失敗することがあります。失敗理由が不明な場合は、Handoffチェックが設定されているか確認してください。設定がなければ、デフォルトのハンドオフなしルールが原因です。