Simulationsを使用すると、Finの手順を検証し、自動化への信頼を築き、顧客に影響が出る前に問題を検出できます。会話全体をモデリングすることで、シミュレーションはキャンセルや返金など、ボリュームが多いまたは複雑なシナリオを確実に処理するのに役立ちます。

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

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

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

テストしたいProcedureを開きます。
キャンバス右上のTestをクリックします。
右側パネルでSimulationsタブを選択します。

Note: シミュレーションにアクセスするには以下のpermissionsが必要です：

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

Simulationsボタンが反応しない場合は、Settings > Workspace > Teammatesでワークスペース管理者にこれらの権限が有効になっているか確認してください。

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

重要:

Previewは顧客向けの体験を完全に表示します。Procedureがライブのときに使用すると実際の顧客にメッセージが表示される可能性があります。
Simulationsは顧客向けの出力がないバックグラウンドでProcedureを実行するため、公開前にロジックを検証する最も安全な方法です。プレイレビューは簡単なスポットチェックに、Simulationsは公開前に毎回使用してください。

シミュレーションの作成

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

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

手動シミュレーション: データを精密にコントロールする必要がある場合や、特定のエッジケース、ロジックの特定の分岐をテストする場合に使用します。

AI生成シミュレーション

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

Procedureの右側パネルでSimulationsタブを開きます。
Suggested for these instructionsの下で、提案されたシナリオ一覧（例：「Full cancellation request」）を確認します。
提案の横にあるPlay iconをクリックして即座に実行します。
シミュレーションが作成されるか提案から承認されると、リストに表示されます。保存されたすべてのシミュレーションを一度に実行するにはRun allをクリックします。

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

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

Simulationsタブで+ Newをクリックします。
Simulation name: シミュレーションにわかりやすいタイトルを付けます。
Simulate as: パーソナライズをテストするために特定のuserまたはブランドを選択します。ワークスペース内の実在のusersのドロップダウンリストから選択できます。
Customer's opening message: 顧客が最初に送るメッセージを入力します（例：「注文について助けが必要です」）。スクリーンショットなどの画像を添付して、Finが視覚的コンテキストをどのように処理するかをテストすることもできます。
Additional details: 顧客の状況や取った特定の行動に関するガイダンスを提供します。

チャネルを選択する

Simulationsでは、このシミュレーションでFinが使用するチャネルを選択できるため、Finの挙動をテストできます。チャネルドロップダウンでMessengerとEmailを切り替えてからシミュレーションを実行してください。

Note: Finはチャネルによって挙動が異なります。Emailでは、Finは複数の情報を単一の応答にまとめて送信し、複数のメッセージを送らないことがあります。ガイダンスとコンテンツターゲティングはチャネルごとに設定でき、たとえばEmailの応答はよりフォーマルな口調や特定の導入文を含めるように設定できます。

利用可能なデータを定義する

Customer data available to Finセクションでは、テスト中にFinがアクセスできるデータを定義できます。これにより、あいまいな記述に頼るのではなく正確なデータ値に対してテストできます。

Simulation time: このシナリオが「いつ」発生しているかを定義するために使用します。特定の日付と時間を設定することで、顧客が30日以内の返金対象かどうかを確認するなど、時間に敏感なロジックをテストできます。
Attributes and Data Connectors: このセクションは、Procedureで参照されている属性で事前に入力されます。これらの値を更新して（例：People.Planを"Pro"に設定）、異なる分岐結果をテストします。

Note: シミュレーションを正確に実行するには、Finが「知っている」べきタイミングに基づいてデータを配置してください：

Use Attributes: 会話の開始時点でFinがすでにその情報を知っているはずの場合（例：顧客の現在のPlanやサインアップ日）。
Use Additional details: 情報が会話の途中で顧客から提供されることを想定している場合（例：顧客がフォローアップで"Order ID"を提供する）。これにより、Finがそのデータを正しくキャプチャして属性に保存するかをテストできます。

Note:

Data Connectorsはシミュレーションでライブのuserデータを使用しません。外部システムを呼び出す代わりに、FinはCustomer data available to Finセクションで定義したテスト値を使用します。テスト中にFinが使用する値をData Connectorのフィールドに入力していることを確認してください — そうでないとコネクタは空の結果を返します。
Customer data available to Finセクションには、Procedureの指示またはコードブロックで明示的に参照されている属性のみが表示され保持されます。+ Add attributeボタンで手動で属性を追加しても、その属性がProcedureのどこにも参照されていない場合、保存後に効果がないためシステムはそれを保存せず消えます。永続するカスタム値を追加するには、まずその属性がProcedure自体で使用されていることを確認してください。

Finの挙動を評価する

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

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

設定が完了したら、Saveをクリックします。

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

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

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

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」）。これにより、結果をレビューするときにどのテストがどの経路をカバーしているかを簡単に特定できます。

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

バランスの取れたシミュレーションスイートは3種類のシナリオをカバーします。これらを組み合わせることで、Procedureが通常の条件下で正しく機能し、障害時に適切に処理し、顧客の予期しない行動で破綻しないことに自信を持てます。

Happy path
ハッピーパスは理想的で中断のない流れを表します — 顧客が正確な情報を提供し、すべての条件を満たしてFinがProcedureを正常に完了できる場合です。まずここから始めてください。ハッピーパスが失敗すると、より複雑な経路のデバッグが非常に難しくなります。
Example: 顧客が30日以内に返金を要求し、有効な注文IDを持ち、Data Connectorが注文の詳細を返します。Finは返金を処理し、一度で確認します。
Risk path
リスクパスは本番で最も問題になりやすいシナリオをテストします — 通常、外部データが不足している、条件が満たされていない、またはフォールバックブランチが発動する場所です。これらは不正確または不完全な応答を顧客が見るのを防ぐテストです。
Examples: Data Connectorが注文を返さない（Finが顧客に注文IDを尋ねるかテスト）。顧客が返金期間外である（Finが正しいポリシーを伝え、適切な引き継ぎを提供するかテスト）。Conditionステップが評価する時に属性が空である（Finのフォールバック経路が正しく起動するかテスト）。
Edge cases
エッジケースは技術的には有効だが稀な入力や境界条件をカバーします。これらのテストは、時間に敏感なロジック、数値の閾値、自由形式の顧客入力を持つProcedureに特に重要です。
Examples: 顧客がちょうど30日目に返金を要求する（ウィンドウの境界）。顧客が複数のインテントに一致する曖昧な開始メッセージを送る。顧客が予期しない形式で注文IDを提供する、または余分なテキストを含める。

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

実行と結果の確認

テストを実行すると、右側のTestsパネルにステータス指標とともに表示されます：

Running: テストが実行中です。
Passed: テストが実行され、定義されたすべての成功基準を満たしました。
Failed: テストは実行されましたが、定義された成功基準を満たしませんでした。
Queued: テストは開始されましたが、先行するシミュレーションが完了するのを待って実行されています。

結果を調査するには、See conversationをクリックします。これにより、シミュレーションされた顧客とFin間の完全なやり取りの書き起こしが開き、フローがどのように進み、なぜテストが合格または失敗したかを正確に確認できます。

シミュレーションのデバッグ

シミュレーションがFailedとマークされた場合、See conversationで参照できる書き起こしには原因を特定するために必要なすべてが含まれています。効果的に読み解く方法は次のとおりです：

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の設定を確認してください。

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

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

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

各ワークスペースには毎月のシミュレーション実行の割当が与えられます。割当はワークスペースの会話量セグメントに基づき、規模の大きい顧客にはより高い割当が与えられます。

Simulation allowance is based on your workspace’s conversation volume in Intercom.

We assign your workspace to a segment using the number of conversations in the last calendar month.
Your segment is re-evaluated monthly and your allowance will reflect your most recent month’s conversation volume.
If your conversation volume increases or decreases, your Simulation allowance may change in the next monthly cycle.

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

使用状況の監視

テスト管理のため、Simulationsタブ内に視覚的な指標をFinが表示します：

使用状況警告

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

上限到達

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

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

よくある質問

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

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

なぜ手動テストの代わりにSimulationsを使うのですか？

SimulationsはProceduresを大規模に検証し、複雑でリスクの高いシナリオでもFinが確実に動作することを確認できます。手動テストはクイックなスポットチェックや設定レビューに適しています。各リリース前にSimulationsを実行することで、予期せぬ挙動を早期に検出できます。

Simulationが失敗した場合はどうなりますか？

失敗したSimulationは全て確認できます — シミュレートされた会話を開いて、Finが期待通りに動作しなかった理由を理解し、Procedureを調整して、顧客に影響を与えずに再実行してください。

Finが問題を正常に解決したのにSimulationが「Failed」と表示されるのはなぜですか？

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

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

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

「サインアップ日」や「注文履歴」のようなテストデータはどこに入力すべきですか？

サインアップ日や注文履歴などのテストデータは、シミュレーション設定の「Customer data available to Fin」セクションに入力してください — 顧客の最初のメッセージや追加の詳細フィールドに入れるとFinが見逃す可能性があります。テストしている属性や変数には正確な値（例：2024-06-01）を入力してください。

私のツールは実際の会話では動作するが、シミュレーションでは失敗します。なぜですか？

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

SimulationsはProceduresとは別請求されますか？

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

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

EmailでProcedureをテストすると、Messengerとは異なるチャネル固有の動作を検証できます。EmailではFinが複数の情報を1通のメールにまとめて送るのに対し、Messengerでは複数のメッセージを送ることが多いです。GuidanceやContentはチャネルごとに調整可能で、Emailの応答はよりフォーマルな口調や特定の導入文を含めるよう設定できます。Email会話のシミュレーションにより、この動作を検証して自信を持ってデプロイできます。

なぜSimulation実行数に制限があるのですか？

正確なAI予測を生成するにはリソースが必要なため、各シミュレーション実行にはコストがかかります。当社はProceduresを標準的なユースケースで自由にテストできる月間許容量を提供し、極端な使用が費用を悪化させないようにしています。

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

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

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

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

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

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

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

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

月間のSimulation実行許容量は、前月のIntercomにおけるワークスペースの会話量に依存します。上限はワークスペース単位で適用され、毎月1日にリセットされます：

会話量セグメント	月間のSimulation上限
Under 1K	250
1K–15K	1,000
15K–100K	1,750
100K–1M	5,000
1M+	12,500

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

シミュレーションの割当は、加入日や使用済みの回数に関係なく、毎月の初日にリセットされます。未使用の実行は繰り越されず、毎月新たに割当が開始されます。

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

シミュレーションの上限は、ワークスペースの会話量に基づいて自動的に設定され、各暦月の初めに再評価されます。会話量が増加すれば、次の月次サイクルで割当が増えます — 追加の実行を手動で購入したり、この階層システム外で上限を増やすことはできません。リセット日より前に月間上限に達した場合でも、過去のシミュレーション結果やトランスクリプトを確認できますが、「実行」や「すべて実行」ボタンは割当がリセットされるまで無効になります。

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