アクセスと利用可能性
Finは地域ホストされたワークスペースでデータコネクタを使用できますか?
Finは地域ホストされたワークスペースでデータコネクタを使用できますか?
データコネクタはすべての米国、EU、AUのホストされたワークスペースで利用可能です。
カスタムアクションはどうなりましたか?
カスタムアクションはどうなりましたか?
アクションまたは「カスタムアクション」は単に「データコネクタ」に名称変更されました。機能や設定に変更はありません。
機能: 外部システムでAPIコールをトリガーする機能。Finが直接トリガーしてリアルタイムデータを使ったパーソナライズ回答を生成(例:「注文状況を取得」)したり、WorkflowsやFin Proceduresに追加して特定条件でトリガー(例:注文がまだ発送されていない場合のみ「注文キャンセル」を使用)できます。
ナビゲーション: 設定 > 統合 > データコネクタ
データのプライバシーとセキュリティ
Finとの会話で機密データはどのように扱われますか?
Finとの会話で機密データはどのように扱われますか?
IntercomはPANマスキング機能を提供しており、会話内容をクレジットカード番号のような数字でLuhnチェックを通過するものをスキャンします。該当番号が見つかると、番号の最後の4桁以外はマスクされ、顧客はWeb MessengerやiOS・Android SDKでマスク版を確認できます。Inboxの会話でもマスク表示されます。
追加の制御にはStracアプリをインストールして、Intercomのメッセージや添付ファイルから機密データを検出・マスキングできます。SSN、誕生日、運転免許証、パスポート、クレジットカード、デビットカード、APIキーなどの機密データ要素リストを設定可能です。
なりすましを防ぐには?
なりすましを防ぐには?
なりすまし防止には、JWTによるMessengerセキュリティの適用を強く推奨します。これにより、データは認証済みUsersのみに公開されます。認証を有効にしないと、悪意ある者が不正操作やworkspace上のデータコネクタのトリガーを行う可能性があります。
LeadsやMessenger以外のチャネルからの会話にはMessenger認証は適用されません。その場合はワンタイムパスコード(OTP)などの安全な認証方法を使い、ユーザーデータ公開前に検証してください。
データコネクタのテストはデータに影響しますか?
データコネクタのテストはデータに影響しますか?
はい。POST、PUT、DELETEメソッドでテストすると、実際にデータに対して操作が行われます。例えばDELETE呼び出しのテストはユーザーを実際に削除します。
Finがユーザー以外の人に個人データを共有しないようにするには?
Finはプレビュ―タブでアクセス許可したデータのみを読み取り、ユーザーの質問に基づく回答生成に使用します。アクセスさせたくない機密内部データがあれば制限付きデータアクセスを選び、Finに使わせたいフィールドだけを許可してください。さらに応答データの変換で顧客向けの名称や値に変換可能です。例:「申請状況 ‘Pending four eyes check’」を「審査中」などに変換。
このリスクを最小化する推奨設定は以下の表をご覧ください。
ユースケース | リスク | リスク軽減のベストプラクティス |
FinはIntercom CDAに保存されたユーザーIDに基づき顧客のパーソナライズデータを取得します。 | 悪意ある者がCDA値を操作し、別のアカウントのデータをFinに取得させる可能性があります。 | Messenger経由でユーザーがこれら属性を更新できないように設定することを推奨します。これにより悪意ある者が他人のデータにアクセスするのを防げます。設定は設定 > データ > Peopleで該当属性を選び、「Messenger経由の更新を防止」をオンにしてください。 |
FinはFinが収集したデータ値に基づき顧客のパーソナライズデータを取得します。 | 悪意ある者がアクセス権のないアカウントの値をFinに提供する可能性があります。 | APIサーバー側でユーザーのアクセス権を確認するチェックを行うことを推奨します。 |
FinはFinが収集したデータ値に基づき顧客のパーソナライズデータを取得します。 | Finが別の顧客の値を誤って生成し、誤ったデータを取得することがあります。 | この誤生成のリスクはゼロではありませんが低いです。 しかし、APIサーバー側でユーザーのアクセス権を確認するチェックを行うことを推奨します。 |
保存、認証、実行
データコネクタのトークンはどのように保存されますか?
データコネクタのトークンはどのように保存されますか?
トークンはヘッダー設定の一部として保存されます。これらの値は保存時に暗号化されます。Intercomのセキュリティについて詳しくはこちら。
データコネクタはどの認証オプションをサポートしていますか?
データコネクタはどの認証オプションをサポートしていますか?
データコネクタは固定トークンと動的トークンの両方を認証に対応しています。認証トークンの設定と管理が可能で、リクエストのヘッダーに追加できます。
データコネクタのリクエストはどのように実行されますか?
データコネクタのリクエストはどのように実行されますか?
すべてのリクエスト設定(本文、URL、ヘッダー)は保存時に暗号化されます。
すべてのリクエストはバックエンドから送信されます。つまり、ブラウザからAPIコールは行いません。例えば、ユーザーがアクションをトリガーすると、そのアクションはUIではなくIntercomシステムによって実行されます。
重要: サードパーティのデータはIntercomによって検証されず、データコネクタがIntercomに保存したデータを上書きする可能性があります。データコネクタから返されるデータを信頼できることを確認してください。
APIエラーコード(例:4xxや5xx)に基づいて分岐できますか?
APIエラーコード(例:4xxや5xx)に基づいて分岐できますか?
Workflowsのエラー処理: 現時点では、データコネクタが返す特定のAPIエラーコード(4xxや5xxなど)で直接分岐できません。Workflowsはデータコネクタのトリガー成功・失敗でのみ分岐可能です。ただし、APIがJSONペイロード内にレスポンス詳細(例:statusフィールド)を返す場合、その値をConversation Data Attribute(CDA)として保存し、後続のWorkflowsステップで分岐ロジックに利用できる場合があります。
Fin Proceduresのエラー処理:Fin Proceduresはデータコネクタの失敗を自動的に処理しません。コネクタがタイムアウトやエラーを返した場合、Finはリトライや自動回復を行いません。明確なフォールバック指示がないと、Finは予期せず停止したり設定に基づかない応答を生成する可能性があります。
これを避けるには、Procedureに失敗時の明確な指示を含めてください。例:「検索に失敗したら謝罪し、人間のエージェントにエスカレーションする」。より高度なフォールバックが必要な場合は、サブプロシージャ内でデータコネクタ呼び出しをラップし、エラー処理を制御してください。高度な失敗処理では、データコネクタ呼び出しのstatus_codeが出力属性として公開され、条件ステップで特定のHTTPレスポンスコード(例:404と500)に基づく分岐が可能です。詳細は「Fin Proceduresのコード条件の書き方」を参照してください。
コネクタが失敗しフォールバックが設定されていない場合はどうなりますか?
コネクタが失敗しフォールバックが設定されていない場合はどうなりますか?
データコネクタが失敗、タイムアウト、またはエラーを返した場合でも、Finは自動的に情報がないと言いません。ガイダンスルールが明示的にFinに失敗したルックアップで辞退または引き継ぎを指示しない限り、回答生成ステップは有用な応答を試みます。モデルは実際のデータのように自信を持って聞こえるが完全に作り話のアカウント固有の詳細(名前、残高、請求、日付、プラン状況)を生成することがあります。
これは、失敗したルックアップをアカウント、請求、または権利が存在しない証拠として扱ってはならないことを意味します。Finは単に空白を作り話の詳細で埋めることがあります。
これを防ぐ方法:
すべてのコネクタ呼び出しの後に条件ステップを追加し、
status_codeがエラーを示す場合は明示的な失敗メッセージに分岐し、トラブルシューティング記事の「Advanced failure handling with status_code」セクションへのリンクを付けてください。コネクタが失敗した場合にFinがアカウント固有のデータを作り話や推測しないよう指示し、現在情報を取得できないことを顧客に明確に伝えるガイダンスルールを追加してください。
部分的なデータのみが返された場合、Finに検証済みの部分のみを提供し、取得できなかった詳細を明示するよう指示してください。
会話作成時にAPI経由でBrand属性を設定できますか?
会話作成時にAPI経由でBrand属性を設定できますか?
いいえ、会話作成時にAPI経由でBrand属性を設定することはできません。Brandの関連付けは、顧客が使用しているMessengerインターフェースやworkflow設定に基づいて自動的に決定され、APIリクエストによっては決まりません。特定のブランドに会話を関連付ける必要がある場合は、顧客が正しいブランドのMessengerを通じて会話を開始するか、workflowを設定して会話条件に基づいて適切なブランドを割り当ててください。
注意:APIリクエストボディでブランド値を渡そうとしても効果はありません。その値は無視され、ブランドの関連付けはMessengerまたはworkflowの設定から解決されます。
Data connectorsはXMLを返すAPIと連携できますか?
Data connectorsはXMLを返すAPIと連携できますか?
はい、Data connectorsはAPIからのXMLレスポンスを自動的にJSONに変換します。これにより、より多くのAPIに簡単に接続でき、Fin、Workflows、Inboxでデータ形式を手動で変換することなくデータを使用できます。
IntercomはどのIPアドレスからData connectorリクエストを送信しますか?
IntercomはどのIPアドレスからData connectorリクエストを送信しますか?
Intercomからのリクエストを受け入れるために、以下のIntercom IPアドレス(Data connector、Canvas Kit、webhookリクエストの送信元)を許可リストに追加する必要がある場合があります。以下の通りです:
アメリカ合衆国:
34.231.68.152
34.197.76.213
35.171.78.91
35.169.138.21
52.70.27.159
52.44.63.161
ヨーロッパ:
54.217.125.63
54.246.173.113
54.216.9.3
オーストラリア:
52.63.36.185
3.104.68.152
52.64.2.165
Finは単なる情報提供AIですか、それともアカウント更新などの操作も行えますか?
Finは単なる情報提供AIですか、それともアカウント更新などの操作も行えますか?
Finは単なる情報提供以上のものです。サポートコンテンツに基づく質問に答えるだけでなく、Fin Proceduresを使ってアカウント更新のような複数ステップの処理を扱うように設定できます。Data connectorsを使えば、Finは外部システムのデータを安全に取得または更新できます(注文状況の変更やユーザー詳細の更新など)。
Finの動作
FinがProcedures、Guidance、Data connectors、Workflowsと連携する方法
機能 | 機能の説明 | 使用タイミング | 備考 |
Procedures | Finに自然言語とルールベースのステップを使って、返金やアカウント更新のような特定の複数ステップの処理を扱う方法を教えます。 | Finに自然言語でトリガーされる複雑な複数ステップの処理を管理させたい場合。 | 高負荷で論理的なリクエストに最適。会話の流れを完全に制御できます。 |
Guidance | Finにあなたのコミュニケーションスタイルやポリシーに基づいて正確な回答を提供し、問題をエスカレーションするようにトレーニングします。 | Finにあなたのトーンを合わせ、エスカレーションルールを適用し、ポリシーに沿ったサポートを確実に行わせたい場合。 | 操作は行いませんが、Finの話し方、明確化、エスカレーションの方法を管理します。 |
Data connectors | Finが外部システムのデータにアクセスできるようにします(例:API呼び出し)、Fin ProceduresやWorkflowsからトリガーされます。 | Fin Procedures、Workflow、Inboxのworkflowの一部として外部データを取得または更新する必要がある場合。 | Finが直接パーソナライズされた回答を生成するために使用します。また、ProceduresやWorkflowsの内部でも使用されます。 |
Workflows | チケットのトリアージ、リードの資格付け、プロアクティブサポートなどの運用ワークフローをハードコードされたパスで自動化します。 | 柔軟性を必要とせず、構造化された既知のパスに従う標準的なサポート業務を自動化する場合。 | エッジケースが増えるとスケールやメンテナンスが難しくなることがあります。 |
Fin Procedures と Workflowsの違い
特定のイベントやボタン選択からトリガーされる厳格で事前に決められた自動化パス(ルーティング、タグ付け、スケジュールメッセージ送信など)が必要な場合はWorkflowを使用します。Finが会話的で多段階のプロセス(予約のための質問、情報収集、トラブルシューティングなど)を自然言語のリクエストや顧客の応答に動的に適応しながら処理する場合はFin Procedureを使用します。
Fin Procedures と Data connectorsの違い
Data connectorsは注文状況を取得してパーソナライズされた回答を生成しますが、Fin Procedureは注文キャンセルの処理、返金適格性の確認、該当する場合は返金の完了を行います。
Fin Procedures と Fin Guidanceの違い
Fin Guidanceは返金リクエストに対してFinがより丁寧に応答することを保証しますが、Fin Procedureは適格ルールに基づいて返金プロセスを自動化します。
Finが保留中の会話を閉じたときに自動終了メッセージが送信されなかったのはなぜですか?
Finが保留中の会話を閉じたときに自動終了メッセージが送信されなかったのはなぜですか?
Let Fin Handleのworkflowステップ内でAuto-close pending Fin conversationsを有効にすると、Finが会話を閉じる前に送信するメッセージを選択できます。ただし、場合によってはFinがそのメッセージを送信せずに会話を閉じることがあります。
Finはジョブ実行中に顧客が非アクティブになった場合や、Finがインタラクティブ要素(返信ボタンなど)への顧客の応答を待っている間は自動終了メッセージの送信をスキップします。この場合でもFinは期待通りに会話を閉じますが、静かに行います。
Finはワークフローを壊さないようにこのように設計されています。もしFinがアクティブなジョブやインタラクティブなステップ中に自動終了メッセージを送信した場合:
自動終了メッセージが会話に表示され、返信ボタンがすべて削除されます。
しかしFinはまだ顧客がその返信オプションのいずれかを選択するのを待っている状態になります。
これによりワークフローが停止してしまいます。
これを避けるために、Finはバックグラウンドで会話を閉じ、ワークフローがジョブ中または返信ボタンの選択を待っている間は自動終了メッセージを送信しません。
注意:メッセージがスキップされても、Finは以下を実行します:
顧客が非アクティブになったことを検知する。
会話を自動的に閉じる。
会話イベントに閉鎖を記録する。
よくあるFinの自動化問題
なぜFinは会話を早期に閉じるのですか?
なぜFinは会話を早期に閉じるのですか?
Finは自動終了設定やworkflowの構成により会話を自動的に閉じることがあります。主な原因:
workflowが顧客に追加の質問がないことを確認した後、終了ステップに到達すると会話が閉じられます。
自動終了設定はFinの最後のメッセージから数分後に会話を閉じるように設定されている場合があります。早期終了を防ぐには、workflowのLet Fin handleステップをクリックし、自動終了タイマーを長く設定してください。
なぜFinは顧客の問い合わせに応答しないのですか?
なぜFinは顧客の問い合わせに応答しないのですか?
Finが顧客の問い合わせに応答しない理由は以下の通りです:
ワークスペースで設定された使用制限に達している。Fin Usageページを確認し、必要に応じて制限を増やしてください。
workflowの構成がFinではなく人間のエージェントへのルーティングを優先している。workflowのトリガーを見直し、Finが適切に使用されるよう調整してください。
なぜFinは不必要に問い合わせを人間のエージェントにエスカレーションするのですか?
なぜFinは不必要に問い合わせを人間のエージェントにエスカレーションするのですか?
Finはワークスペースで設定された解決制限に達すると、不必要に問い合わせを人間のエージェントにエスカレーションすることがあります。Settings > Billing > Usageに移動し、Resolutionグラフを確認してください。必要に応じて制限を増やしてください。
なぜFinは追加情報を求めた後に会話を閉じるのですか?
なぜFinは追加情報を求めた後に会話を閉じるのですか?
Finが満足のいく回答を提供できず、顧客がエスカレーションを要求しなかった場合、会話が閉じられることがあります。会話が閉じられた後でも顧客はFinに質問を続けることができ、返信があればFinは会話を再開します。
なぜFinは質問がされていないのに応答するのですか?
なぜFinは質問がされていないのに応答するのですか?
Finは会話内のすべての入力(クイックリプライボタンの選択も含む)を考慮して応答を形成します。Finに明確な質問にのみ応答させたい場合は、Guidanceの指示を更新してその動作を指定してください。
なぜFinはOutboundメッセージへの顧客の返信に応答しないのですか?
なぜFinはOutboundメッセージへの顧客の返信に応答しないのですか?
FinがOutboundメッセージの返信に応答するオプションはSimple展開設定でのみ機能します。Advanced展開でWorkflowsを使用している場合、Finはこれらの返信に自動応答しません。Simple展開設定に切り替えるか、Let Fin handleステップを含むAdvanced Workflowで返信を処理してください。
なぜFinはエスカレーションせずに会話を閉じるのですか?
なぜFinはエスカレーションせずに会話を閉じるのですか?
Finは「この問題をエスカレーションしてくれてありがとう」などのメッセージを解決の合図と解釈し、エスカレーションせずに会話を閉じることがあります。Fin Guidanceを更新して、エスカレーションの言葉の扱いを明確に指示し、感謝のメッセージを解決済みとみなさないようにしてください。
なぜFinは営業時間外に連絡があったと顧客に伝えるのですか?
なぜFinは営業時間外に連絡があったと顧客に伝えるのですか?
Finは会話が設定された営業時間外に開始された場合、営業時間外メッセージを送信します。アカウント設定で営業時間を確認・調整し、運用スケジュールに合わせてください。Workflowsはチームごとに設定されたカスタム営業時間ではなく、デフォルトの営業時間のみを使用します。
なぜFinは期待通りにメールに応答しないのですか?
なぜFinは期待通りにメールに応答しないのですか?
Finが期待通りにメールに応答しない理由は以下の通りです:
Intercomでチームメイトのメールとして設定されていないメールアドレスからテストメールを送信している。適切に設定されたテストアドレスを使用してください。
workflowの割り当てルールがFinの初回応答後に会話をチームメイトに割り当てている。workflowを見直し、割り当てステップがFinのメール自動化と競合しないようにしてください。
なぜFinはバイパスすべきメールに返信するのですか?
なぜFinはバイパスすべきメールに返信するのですか?
レガシーFinプロファイルが新しい展開方法と競合し、Finがバイパスすべきメールに応答してしまうことがあります。アクティブなFinプロファイルを一時停止し、FinはWorkflowsまたはSimple展開のみで展開してください。
Fin AI Agentを無効にするには?
Fin AI Agentを無効にするには?
Fin AI Agentを無効にするには、無効にしたいチャネルのFin AI Agent Deployページに移動してオフにします。Finを完全に無効にするために以下の手順を実行してください:
Fin AI Agent > Deployに移動し、該当チャネルのFinを無効にします。無効にすると「Chat」と「Email」の設定横の緑の点が黄色に変わります。
すべてのアクティブなWorkflowsからFinを削除してください。
Finが有効になっているライブのProceduresまたはWorkflowsを無効にしてください。主要チャネルが一時停止されていても、FinはアクティブなWorkflows、Data connectors、およびProceduresを通じて顧客とやり取りできます。
