シミュレーションにより、Fin手順を検証し、自動化への自信を築き、顧客に影響が出る前に問題を発見できます。会話全体をモデル化することで、キャンセルや返金などの大量または複雑なシナリオを確実に処理できます。

時間のかかる手動チェックに代わるものとして設計されたシミュレーションは、ビジネスロジックの進化に伴うFinの動作の問題や徐々の変化を特定するのに役立ちます。

シミュレーションへのアクセス

シミュレーションはProcedureのテストパネル内にあります。アクセス方法は以下の通りです。

テストしたいProcedureを開きます。
キャンバスの右上にあるテストをクリックします。
右側のパネルでシミュレーションタブを選択します。

注意: シミュレーションにアクセスするには、以下の権限が必要です。

"Can manage workspace data"、
"Can access lead and user profile pages"、
"Can access lists of people, companies, and accounts"。

シミュレーションボタンが反応しない場合は、ワークスペース管理者に連絡し、設定 > ワークスペース > Teammatesでこれらの権限が有効になっているか確認してください。

シミュレーションはインテントマッチングをバイパスします。プレビューやライブ会話とは異なり、シミュレーションは「このProcedureを使う時」の指示をチェックせず、Procedureが既にトリガーされていると仮定して直接実行します。これにより、実行ロジックを単独でテストするのに最適です。

重要:

プレビューは実際の顧客に届かないテスト会話を実行し、実際のコンテンツを使用します。デフォルトでは、データコネクターはサンプルデータを返します。特定のユーザーとしてテストし、プレビュー設定（テストパネルの歯車アイコン）で「トリガー時に実際のユーザーデータにアクセス・更新」を選択すると、データコネクターは実際のシステムを呼び出し、Procedureが行う返金や記録更新などの操作はそのユーザーに対して実行されます。必ずテストユーザーアカウントを使用し、実際の顧客は使わないでください。
シミュレーションは外部システムを呼び出しません。Finはあなたが定義したテスト値を使用するため、ライブ前にロジックを検証する最も安全な方法です。

素早いスポットチェックにはプレビューを使用し、公開前には必ずシミュレーションを実行してください。

シミュレーションの作成

シミュレーションは、AI生成の提案を使って素早く開始する方法と、シナリオを手動で定義して完全にコントロールする方法の2通りで作成できます。

AI生成シミュレーション: これらは指示に基づき、一般的または予想される顧客シナリオを素早くカバーするために使用します。Fin AIは時間を節約するための「既製」のスターターテストを生成します。

手動シミュレーション: データの正確な制御、特定のエッジケース、またはロジックの特定の分岐が必要な場合に使用します。

AI生成シミュレーション

指示に基づき、Fin AIは「既製」のシミュレーションを素早く作成するためのスターターテストを生成します。

Procedureの右側パネルのシミュレーションタブを開きます。
これらの指示に提案されたの下で、提案されたシナリオのリスト（例：「完全キャンセルリクエスト」）を確認します。
提案の横にある再生アイコンをクリックすると即座に実行されます。
シミュレーションが作成されるか提案から承認されると、リストに表示されます。すべて実行をクリックすると保存されたすべてのシミュレーションを一度に実行できます。

手動で作成したシミュレーション

Procedureの指示に基づき、特定のエッジケースをテストするためにシミュレーションをゼロから作成することもできます。

シミュレーションタブで+ 新規をクリックします。
シミュレーション名: シミュレーションにわかりやすいタイトルを付けます。
としてシミュレート: パーソナライズテストのために特定のユーザーまたはブランドを選択します。ワークスペース内の実際の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が利用可能な顧客データセクションには、Procedureの指示やコードブロックで明示的に参照されている属性のみが表示・保持されます。+ 属性を追加ボタンで手動で属性を追加しても、その属性がProcedure内で参照されていなければ保存されません。保存後に消えるのは、シミュレーションに影響がないためです。永続的にカスタム値を追加するには、まずその属性をProcedure内で使用してください。

Finの動作を評価する

テストが合格するために満たすべき条件を定義します。+ Add criteriaをクリックして選択してください。

Fin reply: 会話中にFinが言うべきこと（または言うべきでないこと）を指定します。
Attributes: 属性が設定されているか、設定されていないか、特定の値と等しいか、等しくないかを確認します。
Data connector: コネクタがトリガーされたか、トリガーされていないか、または正確にX回トリガーされたかを確認します。
Instruction outcome: 会話が特定の結論に達したかどうかを確認します。例えば、終了した、チームメイトに引き継がれた、または別のProcedureに切り替わったなどの結果です。

設定が完了したら、Saveをクリックしてください。

Note: Saveをクリックすると、FinがAIを使ってシミュレーションフォームをレビューします。指示が不明確だったり成功基準が矛盾している場合、より正確な結果を得るための改善案が表示されます。

シミュレーションカバレッジのベストプラクティス

シミュレーションを最大限に活用するには、テストスイートを以下の原則に基づいて構成してください。

シミュレーションごとに1つの分岐をテストする。 Procedureに複数のパスを持つConditionsやサブプロシージャがある場合、それぞれの分岐ごとに別々のシミュレーションを作成します。これにより回帰安全網が構築され、将来の編集で特定のパスが壊れた場合にすぐに検出できます。
Data Connectorsの成功パスと失敗パスの両方をカバーする。 コネクタが有効なデータを返すシミュレーションと、何も返さないか失敗するシミュレーションを実行します。これにより、フォールバックロジック（例：空の応答を処理する@Conditionステップ）が正しく機能することを検証します。
変更を公開する前にすべてのシミュレーションを実行する。 Procedureを編集した後、Run allをクリックして全テストスイートを再実行し、ライブ前に確認します。新たに失敗したシミュレーションは編集による回帰を示します。
説明的なシミュレーション名を使用する。 各シミュレーションには、そのシナリオを表す名前を付けます（例：「Full refund — within 30 days」や「Cancellation — no order found」）。これにより、結果を確認するときにどのテストがどのパスをカバーしているかが簡単にわかります。

テスト戦略：ハッピーパス、リスクパス、エッジケース

バランスの取れたシミュレーションスイートは3種類のシナリオをカバーします。これにより、Procedureが通常の条件下で正しく動作し、失敗を適切に処理し、顧客の予期しない行動でも壊れないことを確認できます。

ハッピーパス
ハッピーパスは理想的で中断のない流れを表します。顧客が正確な情報を提供し、FinがProcedureを成功裏に完了するためのすべての条件を満たす場合です。まずここから始めてください。ハッピーパスが失敗すると、より複雑なパスのデバッグが非常に難しくなります。
例：顧客が30日以内に返金を要求し、有効な注文IDを持ち、Data Connectorが注文詳細を返します。Finは返金を処理し、一度のやり取りで確認します。
リスクパス
リスクパスは本番環境で問題が起こりやすいシナリオをテストします。通常、外部データが欠落している、条件が満たされていない、またはフォールバック分岐が発動する場合です。これらのテストは顧客が誤ったまたは不完全な応答を受け取らないように保護します。
例： Data Connectorが注文を返さない（Finが顧客に注文IDを尋ねるかテスト）。顧客が返金期間外（Finが正しいポリシーを伝え適切な引き継ぎを提供するかテスト）。Conditionステップで属性が空（Finのフォールバックパスが正しく発動するかテスト）。
エッジケース
エッジケースは技術的には有効だが珍しいまたは境界条件の入力をカバーします。これらのテストは、時間に敏感なロジック、数値の閾値、または自由形式の顧客入力を含むProcedureで特に重要です。
例：顧客が返金期間の境界である30日目に返金を要求。複数の意図にマッチする曖昧な開始メッセージを送信。予期しない形式の注文IDや余分なテキストを含む注文IDを提供。

ヒント: 各テストがどのカテゴリに属するかを示す説明的なシミュレーション名を使用してください。例えば、「Refund — happy path」、「Refund — no order found (risk)」、「Refund — boundary day 30 (edge)」など。これによりカバレッジのギャップを一目で見つけやすくなります。

実行と結果の確認

テストを実行すると、右側のTestsパネルにステータスインジケーター付きで表示されます。

実行中: テストが現在実行されています。
合格: テストが実行され、すべての成功基準を満たしました。
失敗: テストは実行されましたが、定義された成功基準を満たしませんでした。
キュー待ち: テストは開始されましたが、前のシミュレーションが終了するのを待ってから実行されます。

結果を調査するには、See conversationをクリックしてください。これにより、シミュレーションされた顧客とFinの間の完全なやり取りの記録が開き、フローの展開やテストが合格または失敗した理由を簡単に確認できます。

失敗したシミュレーションのデバッグ

シミュレーションが失敗とマークされた場合、See conversationで利用できるトランスクリプトには原因特定に必要なすべてが含まれています。効果的な読み方は以下の通りです。

Finの考え
会話の各ステップで、Finの推論を展開して、顧客のメッセージの解釈、実行中のProcedureステップ、下した決定を確認します。Finが予期しないパスを取った場合、Finの考えは通常、解釈が意図と異なった箇所を正確に示します。属性や条件の解釈が期待と異なるステップを探してください。
会話イベント
会話イベントはトランスクリプト内にインラインで表示され、属性の更新、Data Connectorの呼び出し、引き継ぎトリガーなどの低レベルのアクションを示します。これらを使って、適切なコネクタが適切なタイミングで発動し、各分岐ステップの前に属性が期待通りに設定されているかを確認します。
失敗箇所の特定
Finの考えと会話イベントを定義した成功基準と照合してください。よくあるパターンは、Conditionステップが誤った分岐を評価することです。通常は属性が空か予期しない値であるためです。シミュレーション実行前に必要な属性がすべて設定されているか、Customer data available to Finの設定を確認してください。

ヒント: 原因を特定したら、Procedureやシミュレーション設定を調整し、同じシミュレーションでRunをクリックしてすぐに再テストしてください。新しいシミュレーションを作成する必要はありません。既存の設定が保持されます。

シミュレーション使用制限

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

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

シミュレーションの割り当ては、Intercomのワークスペースの会話量に基づいています。

ワークスペースは前月の会話数を使ってセグメントに割り当てられます。
セグメントは毎月再評価され、割り当ては直近の月の会話量を反映します。
会話量が増減した場合、次の月次サイクルでシミュレーションの割り当てが変わることがあります。

Conversation Volume Segment	Simulation Limit per month
1K未満	250
1K〜15K	1,000
15K〜100K	1,750
100K〜1M	5,000
1M+	12,500

使用状況の監視

テスト管理を支援するため、FinはSimulationsタブ内に視覚的な指標を提供します:

使用警告

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

制限到達

月間制限の100%に達すると、赤いエラーメッセージが表示されます。次の月の開始までシミュレーションを実行できなくなります。

注意：制限に達しても、「See conversation」をクリックすれば過去のシミュレーション結果やトランスクリプトを確認できますが、「Run」および「Run all」ボタンは無効になります。

よくある質問

シミュレーションは私のライブAPIや外部データと連携しますか？

いいえ。Previewツールとは異なり、シミュレーションは実際のAPIやShopifyやStripeのような外部システムにアクセスしません。シミュレーション中に外部APIのデータを読み取ったり変更したりすることはできません。これにより、実際のデータに影響を与えずに安全にロジックをテストできます。

なぜ手動テストではなくシミュレーションを使うのですか？

シミュレーションはProceduresを大規模に検証し、Finが複雑でリスクの高いシナリオでも信頼性を持って動作することを保証します。手動テストは迅速なスポットチェックや設定レビューに適しています。毎回のリリース前にシミュレーションを実行することで、予期しない動作を早期に発見できます。

シミュレーションが失敗したらどうなりますか？

失敗したシミュレーションは完全にレビューできます。シミュレートされた会話を開いてFinが期待通りに動作しなかった理由を理解し、Procedureを調整して再実行してください。顧客への影響はありません。

Finが問題を解決したのにシミュレーションが「Failed」と表示されるのはなぜですか？

Finが問題を解決したにもかかわらず「Failed」と表示される場合、Success Criteriaが厳しすぎることが多いです。例えば、「Order IDを尋ねる」ことを要求しているが、Finが自動的にIDを見つけた場合、質問をスキップしたためテストは失敗します。最終結果（例：「Procedure完了」）に焦点を当て、中間ステップを必須にしないように基準を更新してください。

Finがシミュレーションの途中で停止します。なぜ詰まるのですか？

Finは指示の「行き止まり」に達すると停止することがあります。例えば、空の変数（例：People.signed_up）をチェックした場合です。データがない場合の指示がないと停止します。指示に「フォールバック」プランを含めてください。例：「変数に値があるか確認。空なら顧客に日付を尋ねる。」

「Sign up dates」や「Order history」などのテストデータはどこに入力すべきですか？

サインアップ日や注文履歴などのテストデータは、シミュレーション設定の「Customer data available to Fin」セクションに入力してください。顧客の最初のメッセージや追加情報欄には入力しないでください。Finが見逃す可能性があります。テスト対象のAttributesやVariablesに正確な値（例：2024-06-01）を入力してください。

実際のツールは動作するのにシミュレーションで失敗するのはなぜですか？

シミュレーションは外部システムから実データを取得しないため、Data Connectorは実際の会話のようにライブ結果を返しません。ライブ会話で動作するがシミュレーションで失敗する場合は、Customer data available to Finセクションに期待される戻り値が定義されていない可能性があります。通常の戻り値をテスト値として追加し、再実行してください。

シミュレーションはProceduresとは別に課金されますか？

シミュレーションはProceduresに含まれており、別途課金されません。シミュレーションの実行で追加料金は発生しません。

なぜEmailでProcedureをテストすべきですか？

EmailでのテストはMessengerとは異なるチャネル固有の動作を検証します。EmailではFinが複数の情報を1通のメールにまとめて送信します。ガイダンスやコンテンツもチャネルごとに調整可能で、Emailの応答はよりフォーマルなトーンや特定の導入文を含める設定ができます。Email会話のシミュレーションでこの動作を検証し、自信を持ってEmailに展開できます。

なぜシミュレーション実行に制限があるのですか？

正確なAI予測を生成するにはリソースが必要です。標準的な使用ケースで自由にProceduresをテストできるよう月間割当を提供し、過度な使用によるコスト増加を防止しています。

サブプロシージャを独立してシミュレーションできますか？

いいえ。サブプロシージャには独自のシミュレーションパネルがなく、単独で実行できません。サブプロシージャをテストするには、親のProcedureでシミュレーションを実行し、シナリオを設定して実行経路がサブプロシージャに到達するようにします。顧客メッセージ、属性、追加情報を設定して特定の分岐を呼び出してください。

同じ親内に複数のサブプロシージャがある場合は、それぞれのサブプロシージャが呼び出されるシナリオをカバーする別々のシミュレーションを作成してください。

シミュレーションでData Connectorが空の結果を返します。どうすればいいですか？

シミュレーションでData Connectorが空の結果を返すのは、テストデータが不足していることが原因です。シミュレーションは外部システムからライブデータを取得しないため、Customer data available to FinセクションでData Connectorが返す値を定義する必要があります。関連するData Connectorフィールドにテスト値を入力しているか確認してください。

意図的に「connector returns nothing」パスをテストしている場合、これは期待される動作であり、テストすべき内容です。空のコネクター応答を処理するフォールバックの@ConditionステップがProcedureにあることを確認してください。

実データを持つユーザーでもコネクターが空を返す場合は、テスト連絡先のexternal_idが外部システムの顧客識別子と一致しているか確認してください。

月に何回シミュレーションを実行できますか？

月間のシミュレーション実行数の上限は、前月のIntercomでのワークスペースの会話量に依存します。制限はワークスペース単位で適用され、毎月1日にリセットされます。

会話量セグメント	月間シミュレーション上限
1K未満	250
1K–15K	1,000
15K–100K	1,750
100K–1M	5,000
1M+	12,500

シミュレーションの制限はいつリセットされますか？

シミュレーションの許容量は、参加日や使用したシミュレーション数に関係なく、毎月の初日にリセットされます。未使用の回数は繰り越されず、毎月新たに開始されます。

シミュレーションの制限を増やせますか？

シミュレーションの制限は、workspaceの会話量に基づいて自動的に設定され、毎月の初めに再評価されます。会話量が増加すると、次の月のサイクルで許容量が増えます。追加の実行回数を手動で購入したり、この階層システム外で制限を増やすオプションはありません。リセット日までに月間制限に達した場合でも、過去のシミュレーション結果やトランスクリプトは確認できますが、RunおよびRun allボタンは許容量がリセットされるまで無効になります。

Fin手順のシミュレーションを実行する