シミュレーションによりFin手順を検証し、自動化への自信を築き、顧客に影響が出る前に問題を発見できます。会話全体をモデル化することで、キャンセルや返金などの大量または複雑なシナリオを確実に処理できます。
時間のかかる手動チェックに代わるよう設計されたシミュレーションは、ビジネスロジックの進化に伴うFinの動作の問題や徐々の変化を特定するのに役立ちます。
シミュレーションへのアクセス
シミュレーションはProcedureのテストパネル内にあります。アクセス方法は以下の通りです：
テストしたいProcedureを開きます。
キャンバスの右上にあるTestをクリックします。
右側パネルのSimulationsタブを選択します。
注意：シミュレーションにアクセスするには「Can manage workspace data」権限が必要です。Simulationsボタンが反応しない場合は、設定 > Workspace > Teammatesでこの権限が有効か確認してください。
シミュレーションはインテントマッチングをバイパスします。Previewやライブ会話とは異なり、「このProcedureを使う時」の指示をチェックせず、Procedureが既にトリガーされたと仮定して直接実行します。これにより、シミュレーションは実行ロジックを単独でテストするのに最適です。
重要：
Previewは顧客向けの全体体験を表示し、Procedureがライブ中に使うと実際の顧客にメッセージが届く可能性があります。
SimulationsはバックグラウンドでProcedureを実行し、顧客向けの出力がないため、ライブ前のロジック検証に最も安全な方法です。素早いスポットチェックにはPreviewを使い、公開前には必ずSimulationsを使いましょう。
シミュレーションの作成
シミュレーションは、AI生成の提案を使って素早く開始する方法と、シナリオを手動で定義して完全にコントロールする方法の2通りで作成できます。
AI生成シミュレーション：指示に基づき、一般的または予想される顧客シナリオを素早くカバーするために使います。Fin AIが「すぐ使える」スターターテストを生成し、時間を節約します。
手動シミュレーション：データの正確な制御、特定のエッジケース、またはロジックの特定の分岐をテストしたい場合に使います。
AI生成シミュレーション
指示に基づき、Fin AIが「すぐ使える」シミュレーションのスターターテストを生成し、素早く作成を支援します。
Procedureの右側パネルのSimulationsタブを開きます。
Suggested for these instructionsの下で提案されたシナリオのリスト（例：「完全なキャンセルリクエスト」）を確認します。
提案の横にある再生アイコンをクリックして即座に実行します。
シミュレーションが作成されるか提案から受け入れられると、リストに表示されます。Run allをクリックすると保存されたすべてのシミュレーションを一度に実行できます。
手動で作成したシミュレーション
Procedureの指示に基づき、特定のエッジケースをテストするためにシミュレーションをゼロから作成することもできます。
Simulationsタブで+ Newをクリックします。
シミュレーション名：シミュレーションにわかりやすいタイトルを付けます。
Simulate as: テストのために特定のuserまたはブランドを選択します。ワークスペース内の実際のusersのドロップダウンリストから選べます。
顧客の最初のメッセージ：顧客が送る最初のメッセージを入力します（例：「注文の助けが必要です」）。エラーのスクリーンショットなどの画像を添付して、Finが視覚的コンテキストをどのように処理するかをテストできます。
追加の詳細：顧客の状況や取った特定の行動に関するガイダンスを提供します。
チャネルを選択
シミュレーションでは、Finがこのシミュレーションで使用するチャネルを選択でき、Finの動作をテストできます。シミュレーション実行前にチャネルのドロップダウンでMessengerとEmailを切り替えます。
注意：Finはチャネルによって動作が異なります。Emailでは複数の情報をまとめて1つの応答にし、複数メッセージを送信しません。ガイダンスやコンテンツターゲティングもチャネルごとに設定可能で、例えばEmail応答はよりフォーマルな口調や特定の導入文を含めることができます。
利用可能なデータを定義
Finが利用可能な顧客データセクションでは、テスト中にFinがアクセスできるデータを定義できます。これにより、曖昧な説明に頼らず正確なデータ値でテストできます。
シミュレーション時間：シナリオが「いつ」起こるかを定義します。特定の日付と時間を設定することで、顧客が30日間の返金期間内かどうかなど、時間に敏感なロジックをテストできます。
属性とデータコネクター：このセクションはProcedureで参照される属性で事前入力されます。これらの値（例：
People.Planを「Pro」に設定）を更新して異なる分岐結果をテストします。
注意：シミュレーションを正確に実行するには、Finが「知っている」べきタイミングに基づいてデータを配置してください。
属性を使う：会話開始時にFinが既に情報を知っている場合（例：顧客の現在のPlanや登録日）。
追加の詳細を使う：情報が会話中に顧客から提供される場合（例：顧客がフォローアップで「注文ID」を提供）。これにより、Finがそのデータを属性に正しくキャプチャし保存するかをテストできます。
注意：データコネクターはシミュレーションでライブのuserデータを使いません。外部システムを呼び出す代わりに、FinはFinが利用可能な顧客データセクションで定義したテスト値を使います。テスト中にFinが使う値をデータコネクターのフィールドに入力していることを確認してください。そうでないとコネクターは空の結果を返します。
Finの動作を評価
テストが合格するために満たすべき条件を定義します。+ Add criteriaをクリックして選択してください：
Finの返信：会話中にFinが言うべきこと（または言うべきでないこと）を指定します。
属性：属性が設定されたか、設定されなかったか、特定の値と等しいか、等しくないかを検証します。
データコネクター：コネクターがトリガーされたか、されなかったか、または正確にX回トリガーされたかを検証します。
指示の結果：会話が特定の結論に達したか（終了、チームメンバーへの引き継ぎ、別のProcedureへの切り替えなど）を確認します。
設定が完了したら保存をクリックします。
注意：保存をクリックすると、FinはAIを使ってシミュレーションフォームをレビューします。指示が不明瞭だったり成功条件が一貫しない場合、より正確な結果のための改善案が表示されます。
シミュレーションカバレッジのベストプラクティス
シミュレーションを最大限に活用するには、これらの原則に基づいてテストスイートを構成してください：
シミュレーションごとに1つの分岐をテストします。 Procedureに複数のパスを持つConditionsやサブプロシージャがある場合は、各分岐ごとに別々のシミュレーションを作成してください。これにより回帰安全ネットが構築され、将来の編集で特定のパスが壊れた場合にすぐに検出できます。
Data Connectorsの成功パスと失敗パスの両方をカバーします。 コネクターが有効なデータを返すシミュレーションと、何も返さないか失敗するシミュレーションをそれぞれ実行します。これにより、フォールバックロジック（例：空の応答を処理する
@Conditionステップ）が正しく機能することを検証します。変更を公開する前にすべてのシミュレーションを実行します。 Procedureを編集した後、Run allをクリックして本番前に全スイートを再実行してください。新たに失敗したシミュレーションは、編集による回帰を示します。
説明的なシミュレーション名を使用します。 各シミュレーションには、そのシナリオを表す名前を付けてください（例：「全額返金 — 30日以内」や「キャンセル — 注文が見つかりません」）。これにより、結果を確認する際にどのテストがどのパスをカバーしているかが簡単にわかります。
テスト戦略：ハッピーパス、リスクパス、エッジケース
バランスの取れたシミュレーションスイートは3種類のシナリオをカバーします。これにより、Procedureが通常の条件下で正しく動作し、失敗を適切に処理し、顧客の予期しない行動にも対応できることに自信が持てます。
ハッピーパス
ハッピーパスは理想的で中断のない流れを表します。顧客が正確な情報を提供し、FinがProcedureを正常に完了するためのすべての条件を満たす場合です。常にここから始めてください。ハッピーパスが失敗すると、より複雑なパスのデバッグが非常に困難になります。
例： 顧客が30日以内に返金を要求し、有効な注文IDを持ち、Data Connectorが注文詳細を返します。Finは返金を処理し、一度の処理で確認します。
リスクパス
リスクパスは、本番環境で問題が起こりやすいシナリオをテストします。通常は外部データが欠落している、条件が満たされていない、またはフォールバック分岐が発動する場合です。これらのテストは、顧客が誤ったまたは不完全な応答を見るのを防ぎます。
例： Data Connectorが注文を返さない（Finが顧客に注文IDを尋ねるかテスト）。顧客が返金期間外（Finが正しいポリシーを伝え適切な引き継ぎを提供するかテスト）。Conditionステップが空の属性を評価する（Finのフォールバックパスが正しく発動するかテスト）。
エッジケース
エッジケースは技術的には有効だが珍しい、または境界条件の入力をカバーします。これらのテストは、時間に敏感なロジック、数値の閾値、または自由形式の顧客入力を含むProcedureで特に重要です。
例： 顧客がちょうど30日目に返金を要求（期間の境界）。顧客が複数の意図にマッチする曖昧な開始メッセージを送信。顧客が予期しない形式で注文IDを提供、または余分なテキストを含む。
ヒント： 各テストがどのカテゴリに属するかを示す説明的なシミュレーション名を使用してください。例：「返金 — ハッピーパス」、「返金 — 注文なし（リスク）」、「返金 — 境界日30（エッジ）」。これにより、カバレッジのギャップを一目で見つけやすくなります。
実行と結果の確認
テストを実行すると、右側のTestsパネルにステータスインジケーター付きで表示されます：
実行中： テストがアクティブに実行されています。
合格： テストは実行され、すべての成功基準を満たしました。
失敗： テストは実行されましたが、定義された成功基準を満たしませんでした。
キュー待ち： テストは開始されましたが、前のシミュレーションの終了を待ってから実行されます。
結果を調査するには、See conversationをクリックしてください。これにより、シミュレーションされた顧客とFinの間の完全なやり取りの記録が開き、フローの展開やテストの合否理由が簡単に確認できます。
失敗したシミュレーションのデバッグ
シミュレーションが失敗とマークされた場合、See conversationで利用可能な記録には原因特定に必要なすべてが含まれています。効果的に読む方法は以下の通りです：
Finの考え
会話の各ステップで、Finの推論を展開して顧客のメッセージの解釈、実行中のProcedureステップ、決定内容を確認してください。Finが予期しないパスを取った場合、Finの考えは通常、解釈が意図と異なった箇所を正確に示します。Finの属性や条件の解釈が期待と異なるステップを探してください。
会話イベント
会話イベントは記録内にインラインで表示され、属性の更新、Data Connectorの呼び出し、引き継ぎトリガーなどの低レベルアクションを示します。これらを使って、適切なコネクターが適切なタイミングで発動し、各分岐ステップ前に属性が期待値に設定されていることを確認してください。
失敗箇所の特定
Finの考えと会話イベントを定義された成功基準と照合してください。一般的なパターンは、Conditionステップが誤った分岐を評価することです。通常は属性が空か予期しない値の場合です。シミュレーション実行前に必要な属性がすべて設定されているか、Customer data available to Finの設定を確認してください。
ヒント： 原因を特定したら、Procedureやシミュレーション設定を調整し、同じシミュレーションでRunをクリックしてすぐに再テストしてください。新しいシミュレーションを作成する必要はありません。既存の設定が保持されます。
シミュレーション使用制限
毎月実行できるシミュレーションの数には制限があります。この制限はワークスペース単位で適用され、毎月のカレンダー月の初日にリセットされます。
各ワークスペースには月ごとのシミュレーション実行数の割り当てがあります。この割り当てはワークスペースの会話量セグメントに基づき、大規模な顧客ほど多くの割り当てを受けます。
シミュレーションの割り当ては、ワークスペースのIntercomでの会話量に基づいています。
ワークスペースは前月の会話数に基づいてセグメントに割り当てられます。
セグメントは毎月再評価され、割り当ては直近の月の会話量を反映します。
会話量が増減した場合、次の月次サイクルでシミュレーションの割り当てが変わる可能性があります。
会話量セグメント | 月ごとのシミュレーション制限 |
1K未満 | 50 |
1K〜15K | 200 |
15K〜100K | 350 |
100K〜1M | 1000 |
1M+ | 2500 |
使用状況の監視
テスト管理を支援するために、FinはSimulationsタブ内に視覚的な指標を提供します：
使用警告
ワークスペースが月間制限の80%に達すると、黄色の警告バナーが表示されます。現在の使用状況（例：「85/100」）とリセット日時が表示されます。
制限到達
月間制限の100%に達すると、赤いエラーメッセージが表示されます。次の月の開始までシミュレーションを実行できなくなります。
注意：制限に達しても、「See conversation」をクリックすれば過去のシミュレーション結果やトランスクリプトを確認できますが、「Run」および「Run all」ボタンは無効になります。
よくある質問
シミュレーションは私のライブAPIや外部データと連携しますか？
シミュレーションは私のライブAPIや外部データと連携しますか？
いいえ。Previewツールとは異なり、シミュレーションは実際のAPIやShopifyやStripeのような外部システムにアクセスしません。シミュレーション中に外部APIのデータを読み取ったり変更したりすることはできません。これにより、実際のデータに影響を与えずにロジックを安全にテストできます。
なぜ手動テストではなくSimulationsを使うのですか？
なぜ手動テストではなくSimulationsを使うのですか？
SimulationsはProceduresを大規模に検証し、Finが複雑でリスクの高いシナリオでも信頼性を持って動作することを保証します。手動テストは迅速なスポットチェックや設定レビューに適しています。毎回のリリース前にSimulationsを実行することで、予期しない動作を早期に発見できます。
シミュレーションが失敗したらどうなりますか？
シミュレーションが失敗したらどうなりますか？
失敗したシミュレーションは完全にレビューできます。シミュレートされた会話を開いて、Finが期待通りに動作しなかった理由を理解し、Procedureを調整して、顧客に影響を与えずに再実行してください。
Finが問題を解決したのにシミュレーションが「Failed」と表示されるのはなぜですか？
Finが問題を解決したのにシミュレーションが「Failed」と表示されるのはなぜですか？
Finが問題を解決したにもかかわらず「Failed」とマークされる場合、通常はSuccess Criteriaが厳しすぎることを意味します。例えば、「Order IDを尋ねる」ことを要求しているが、Finが自動的にIDを見つけた場合、質問をスキップしたためテストは失敗します。特定の中間ステップを義務付けるのではなく、最終結果（例：「Procedure完了」）に焦点を当てて基準を更新してください。
Finがシミュレーションの途中で停止します。なぜ詰まるのですか？
Finがシミュレーションの途中で停止します。なぜ詰まるのですか？
Finは指示の「行き止まり」に達すると停止することがあります。例えば、空の変数（例：People.signed_up）をチェックする場合です。データがない場合の指示がないと停止します。指示に「フォールバック」プランを含めてください。例：「変数に値があるか確認。空なら顧客に日付を尋ねる。」
「Sign up dates」や「Order history」などのテストデータはどこに入力すべきですか？
「Sign up dates」や「Order history」などのテストデータはどこに入力すべきですか？
サインアップ日や注文履歴などのテストデータは、シミュレーション設定のCustomer data available to Finセクションに入力してください。顧客の最初のメッセージや追加情報フィールドには入力しないでください。Finが見逃す可能性があります。テストする特定のAttributesやVariablesに正確な値（例：2024-06-01）を入力してください。
私のツールは実際には動作しますが、シミュレーションでは失敗します。なぜですか？
私のツールは実際には動作しますが、シミュレーションでは失敗します。なぜですか？
シミュレーションは外部システムから実データを取得しないため、Data Connectorは実際の会話のようにライブ結果を返しません。ライブ会話で動作するがシミュレーションで失敗する場合、Customer data available to Finセクションに期待される戻り値が定義されていない可能性があります。通常の戻り値をテスト値として追加し、再度シミュレーションを実行してください。
SimulationsはProceduresとは別に請求されますか？
SimulationsはProceduresとは別に請求されますか？
SimulationsはProceduresに含まれており、別途請求されません。シミュレーションの実行に追加料金は発生しません。
なぜEmailでProcedureをテストすべきですか？
なぜEmailでProcedureをテストすべきですか？
EmailでProcedureをテストすると、Messengerとは異なるチャネル固有の動作を検証できます。EmailではFinが複数の情報をまとめて1通のメールで送信します。ガイダンスやコンテンツも特定チャネル向けに調整可能で、例えばEmailの返信はよりフォーマルなトーンや特定の導入文を含める設定ができます。Email会話のシミュレーションでこの動作を検証し、自信を持ってEmailに展開できます。
なぜSimulationの実行に制限があるのですか？
なぜSimulationの実行に制限があるのですか？
すべてのSimulation実行は正確なAI予測を生成するためにリソースを必要とします。標準的なユースケースで自由にProceduresをテストできるよう月間割当を提供し、過度の使用によるコスト増加を防止しています。
サブプロシージャを独立してシミュレートできますか？
サブプロシージャを独立してシミュレートできますか？
いいえ。サブプロシージャには独自のシミュレーションパネルがなく、単独で実行できません。サブプロシージャをテストするには、親のProcedureでシミュレーションを実行し、シナリオを設定して実行経路がサブプロシージャに到達するようにします。顧客メッセージ、属性、追加情報を設定して特定の分岐を呼び出してください。
同じ親内に複数のサブプロシージャがある場合は、それぞれのサブプロシージャが呼び出されるシナリオをカバーする別々のシミュレーションを作成してください。
シミュレーションでData Connectorが空の結果を返します。どうすればいいですか？
シミュレーションでData Connectorが空の結果を返します。どうすればいいですか？
シミュレーションでData Connectorが空の結果を返すのは、テストデータが不足していることが原因です。シミュレーションは外部システムからライブデータを取得しないため、Data Connectorが返すべき値をシミュレーション設定のCustomer data available to Finセクションで定義する必要があります。Finが使用するテスト値を関連するData Connectorフィールドに入力してください。
意図的に「connector returns nothing」パスをテストしている場合、これは期待される動作であり、まさにテストすべき内容です。Procedureに空のconnector応答を処理するフォールバックの@Conditionステップがあることを確認してください。
実データを持つユーザーでもconnectorが空を返す場合は、テスト連絡先のexternal_idが外部システムの顧客識別子と一致しているか確認してください。