AI生成シミュレーション：これらは指示に基づいて一般的または予想される顧客シナリオを素早くカバーするために使用します。Fin AIは時間を節約する"ready-made"なスターターテストを生成します。

手動シミュレーション：データの精密な制御、特定のエッジケース、またはロジックの特定の分岐をテストする場合に使用します。

Simulation time：このシナリオが「いつ」発生しているかを定義するために使用します。特定の日付と時刻を設定することで、顧客が30日間の返金期間内にいるかどうかなど、時間に敏感なロジックをテストできます。

Attributes and Data Connectors：このセクションは、Procedureで参照されている属性で事前に入力されます。これらの値を更新して（例：People.Planを"Pro"に設定）異なる分岐結果をテストします。

Fin reply: 会話中にFinが何を（または何をしないか）指定します。

Attributes: 属性が設定されたか、設定されていないか、特定の値と等しかったか、等しくなかったかを検証します。

Data connector: コネクタがトリガーされたか、トリガーされていないか、正確にX回トリガーされたかを検証します。

Instruction outcome: 会話が完了した、チームメンバーに引き継がれた、別のProcedureに切り替わったなど、特定の結論に達したかどうかを確認します。

Test one branch per simulation. Procedureに条件や複数の経路を持つサブプロシージャがある場合は、各分岐ごとに別々のシミュレーションを作成してください。これにより回帰安全網が構築されます — 将来の編集で特定の経路が壊れた場合、すぐに検出できます。

Cover both success and failure paths for Data Connectors. コネクタが有効なデータを返す場合のシミュレーションと、何も返さないか失敗する場合のシミュレーションを実行してください。これによりフォールバックロジック（例：空の応答を処理する@Conditionステップ）が正しく機能することを検証できます。

Run all simulations before publishing changes. Procedureを編集した後、公開前にRun allをクリックしてテストスイート全体を再実行してください。新たに失敗したシミュレーションは、編集によって導入された回帰を示します。

Use descriptive simulation names. 各シミュレーションに、そのシナリオを表す名前（例：「Full refund — within 30 days」や「Cancellation — no order found」）を付けてください。これにより結果を確認する際に、どのテストがどの経路をカバーしているかが分かりやすくなります。

Happy path

ハッピーパスは理想的で途切れのないフローを示します — 顧客が正確な情報を提供し、FinがProcedureを正常に完了するためのすべての条件を満たす場合です。まずここから始めてください。ハッピーパスが失敗すると、より複雑な経路のデバッグが非常に困難になります。

Example: 顧客が30日以内に返金を要求し、有効な注文IDを持ち、Data Connectorが注文の詳細を返します。Finは返金を処理し、1回のやり取りで確認します。

Risk path

リスクパスは、本番環境で最も問題が発生しやすいシナリオをテストします — 通常は外部データが欠落している、条件が満たされていない、またはフォールバック経路が発動する場合です。これらのテストは、顧客が不正確または不完全な応答を目にするのを防ぎます。

Examples: Data Connectorが注文を返さない（Finが顧客に注文IDを尋ねるかをテスト）。顧客が返金期間外である（Finが正しいポリシーを伝え、適切な引き継ぎを提案するかをテスト）。Conditionステップが評価する属性が空である（Finのフォールバック経路が正しく発動するかをテスト）。

Edge cases

エッジケースは珍しいまたは境界条件の入力をカバーします。これらは技術的には有効だが稀です。時間に依存するロジック、数値の閾値、自由形式の顧客入力があるProcedureでは特に重要です。

Examples: 顧客がちょうど30日目に返金を要求する（期間の境界）。顧客が複数のインテントに一致する曖昧な冒頭メッセージを送る。顧客が予期しない形式で注文IDを提供する、または余分なテキストを含める。

Running: テストが実行中です。

Passed: テストが実行され、定義された成功基準をすべて満たしました。

Failed: テストは実行されたが、定義された成功基準を満たしませんでした。

Queued: テストは開始されましたが、前のシミュレーションが終了するのを待ってから実行されます。

Fin's thoughts

会話の各ステップで、Finの推論を展開して、顧客のメッセージをどのように解釈したか、どのProcedureステップを実行していたか、どのような判断を下したかを確認してください。Finが予期しない経路を取った場合、Fin's thoughtsは通常、解釈があなたの意図とどこで乖離したかを正確に示します。属性や条件に対するFinの解釈が期待と一致しないステップを探してください。

Conversation events

トランスクリプト内に会話イベントがインラインで表示され、属性の更新、Data Connector呼び出し、引き継ぎトリガーなどの低レベルなアクションを示します。これらを使用して、適切なコネクタが適切なタイミングで発火したか、各分岐ステップの前に属性が期待どおりに設定されていたかを検証してください。

Pinpointing the failure

Fin's thoughtsと会話イベントで見たものを定義された成功基準と照合してください。一般的なパターンはConditionステップが間違った分岐を評価することで、通常は属性が空であるか予期しない値を持っていることが原因です。シミュレーション実行前に必要な属性がすべて設定されていることを確認するために、Customer data available to Finの設定を確認してください。

私たちは前月の会話数を使用してワークスペースをセグメントに割り当てます。

毎月セグメントは再評価され、割当は直近の月の会話ボリュームを反映します。

会話量が増減した場合、次の月のサイクルでSimulation割当が変更されることがあります。