アクセスと利用可能性

私のプランにはFin用のデータコネクタが含まれていますか？

データコネクタはFinのすべての料金プランで利用可能で、成果ごとに課金されます。

Finは地域ホストされたワークスペースでデータコネクタを使用できますか？

データコネクタはすべての米国、EU、AUのホストされたワークスペースで利用可能です。

カスタムアクションはどうなりましたか？

アクションまたは「カスタムアクション」は単に「データコネクタ」に名前が変更されました。機能や設定に変更はありません。

機能：外部システムでAPIコールをトリガーする能力。これらはFinによって直接トリガーされ、リアルタイムデータを使ったパーソナライズされた回答を生成します（例：「注文状況を取得」）。またはWorkflowsやFin Proceduresに追加され、特定の条件が満たされた後にトリガーされます（例：注文がまだ発送されていない場合のみ「注文キャンセル」を使用）。
ナビゲーション：設定 > 統合 > データコネクタ

データのプライバシーとセキュリティ

Finとの会話で機密データはどのように扱われますか？

IntercomはPANマスキング機能を提供しており、会話内容をスキャンしてクレジットカード番号のように見え、ルーンチェックを通過する番号を検出します。該当番号が見つかると、番号の最後の4桁以外はマスクされ、顧客はWeb MessengerおよびiOSとAndroid SDKでマスクされたバージョンを確認できます。番号はInboxの会話でもマスク表示されます。

追加の制御のために、Stracアプリをインストールして、Intercomのメッセージや添付ファイルから機密データを検出・マスキングできます。これにより、SSN、DoB、運転免許証、パスポート、クレジットカード、デビットカード、APIキーなどの機密データ要素のリストを設定してマスキング可能です。

なりすましを防ぐにはどうすればいいですか？

なりすましを防ぐために、MessengerのセキュリティをJWTで強制することを強く推奨します。これにより、データは認証済みのUsersにのみ公開されます。認証を有効にしないと、悪意のある者が不正な操作やデータコネクタのトリガーを行う可能性があります。

LeadsやMessenger以外のチャネルからの会話にはMessenger認証は適用されません。その場合は、ワンタイムパスコード(OTP)や他の安全な認証方法を使用して、ユーザーデータを公開する前に検証してください。

データコネクタのテストはデータに影響しますか？

はい。データコネクタのテストでPOST、PUT、DELETEメソッドを使用すると、その操作が実際にデータに対して実行されます。例えば、ユーザーに対するDELETE呼び出しのテストは実際にユーザーを削除します。

Finがユーザー以外の誰かに個人データを共有しないようにするには？

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のセキュリティについて詳しくはこちら。

データコネクタはどのような認証オプションをサポートしていますか？

データコネクタはテキスト、HTTPリクエスト、OAuthリクエスト、ユーザー（JWT）トークン、事前設定されたOAuthプロバイダーなど複数のトークンタイプをサポートしています。認証トークンの設定と管理が可能で、リクエストのヘッダーに追加できます。

データコネクタでリクエストはどのように実行されますか？

すべてのリクエスト設定（本文、URL、ヘッダー）は保存時に暗号化されます。
すべてのリクエストはバックエンドから送信されます。つまり、ブラウザからAPIコールは行われません。例えば、ユーザーがアクションをトリガーすると、そのアクションはUIではなくIntercomシステムによってトリガーされます。

重要：サードパーティのデータはIntercomによって検証されず、データコネクタがIntercomに保存したデータを上書きする可能性があります。データコネクタから返されるデータを信頼できることを確認してください。

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が出力属性として利用可能です。これを条件ステップで参照し、404（未検出）と500（サーバーエラー）などのHTTPレスポンスコードで分岐できます。詳細はFin Proceduresのコード条件の書き方をご覧ください。

コネクタが失敗しフォールバックが設定されていない場合はどうなりますか？

データコネクタが失敗、タイムアウト、またはエラーを返した場合でも、Finは自動的に情報がないと言い換えません。ガイダンスルールが明示的に失敗したルックアップで拒否または引き継ぎを指示しない限り、回答生成ステップは有用な応答を試みます。モデルは実際のデータのように自信を持って聞こえるが完全に作り話のアカウント固有の詳細（名前、残高、請求、日付、プラン状況）を生成することがあります。

これは、失敗したルックアップをアカウント、請求、または権利が存在しない証拠として扱ってはならないことを意味します。Finは単に空白を作り話の詳細で埋めることがあります。

これを防ぐ方法：

すべてのコネクタ呼び出し後に条件ステップを追加し、status_codeがエラーを示す場合は明示的な失敗メッセージに分岐させます。 詳細はTroubleshooting Fin Procedures and Data connectorsを参照してください。
コネクタが失敗した場合にFinがアカウント固有のデータを作り話や推定しないよう指示し、現在情報を取得できないことを顧客に明確に伝えるガイダンスルールを追加します。
部分的なデータのみが返された場合、Finに検証済みの部分のみを提供し、取得できなかった詳細を明示するよう指示してください。

会話作成時にAPI経由でBrand属性を設定できますか？

REST APIバージョン2.16以降では、Create Conversation APIのbrand_idパラメータが尊重され、会話はそのブランドに割り当てられます。2.16以前のREST APIバージョンでは、会話作成時にAPI経由でBrand属性を設定できません。ブランドの関連付けは、顧客が使用しているMessengerインターフェースやworkflow設定に基づいて自動的に決定されます。2.16以前のバージョンで特定のブランドに会話を関連付ける必要がある場合は、REST APIバージョン2.16以降にアップグレードして作成時にbrand_idを渡すか、顧客が正しいブランドのMessengerから会話を開始するか、workflowを設定して会話条件に基づき適切なブランドを割り当ててください。

注意：この動作はREST APIバージョンに依存します。REST APIバージョン2.16以降では、Create Conversationリクエストボディにbrand_idを渡すと会話のブランドが設定されます。2.16以前のバージョンでは値は無視され、ブランドの関連付けはMessengerまたはworkflow設定から解決されます。brand_idが効果を発揮しない場合は、統合で使用しているAPIバージョンを確認してください。

Data connectorsはXMLを返すAPIと連携できますか？

はい、Data connectorsはAPIからのXMLレスポンスを自動的にJSONに変換します。これにより、より多くのAPIに簡単に接続でき、Fin、Workflows、Inboxでデータ形式を手動で変換することなくデータを利用できます。

IntercomはどのIPアドレスからData connectorリクエストを送信しますか？

IntercomからのData connector、Canvas Kit、webhookリクエストを受け入れるために、以下のIntercom IPアドレスを許可リストに追加する必要がある場合があります。以下の通りです：

米国：

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は単なる情報提供以上のものです。サポートコンテンツに基づく質問に答えるだけでなく、操作を実行するよう設定できます。Fin Proceduresを使って、アカウント更新のような複数ステップのプロセスをFinに教えることができます。Data connectorsを使えば、Finは外部システムのデータを安全に取得または更新できます（注文状況の変更やユーザー詳細の更新など）。

Finの動作

FinがProcedures、Guidance、Data connectors、Workflowsと連携する仕組み

機能	機能内容	使用タイミング	備考
Procedures	自然言語とルールベースのステップを使って、返金やアカウント更新などの特定の複数ステッププロセスをFinに教えます。	自然言語でトリガーされる複雑な複数ステッププロセスをFinに管理させたい場合。	労力のかかる論理駆動のリクエストに最適。会話フローを完全に制御できます。
Guidance	コミュニケーションスタイルやポリシーに基づき、正確な回答を提供し問題をエスカレーションするようFinを訓練します。	Finにトーンを合わせ、エスカレーションルールを適用し、ポリシーに沿ったサポートを確実に行わせたい場合。	操作は行わず、Finの話し方、明確化、エスカレーションを管理します。
Data connectors	Fin ProceduresやWorkflowsでトリガーされる外部システムのデータ（例：API呼び出し）にFinがアクセスできるようにします。	Fin Procedures、Workflow、Inboxのワークフローの一部として外部データを取得または更新する必要がある場合。	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が保留中の会話を閉じたときに自動終了メッセージが送信されなかったのはなぜですか？

Let Fin Handleのworkflowステップ内でAuto-close pending Fin conversationsを有効にすると、Finが会話を閉じる前に送信するメッセージを選択できます。ただし、場合によってはFinがそのメッセージを送信せずに会話を閉じることがあります。

Finはジョブ実行中に顧客が非アクティブになった場合や、Finがインタラクティブ要素（返信ボタンなど）への顧客の応答を待っている間は、自動終了メッセージの送信をスキップします。この場合でもFinは期待通りに会話を閉じますが、静かに行います。

Finはワークフローを壊さないようにこのように設計されています。もしFinがアクティブなジョブやインタラクティブなステップ中に自動終了メッセージを送信した場合：

自動終了メッセージが会話に表示され、返信ボタンがすべて削除されます。
しかしFinはまだ顧客がその返信オプションのいずれかを選択するのを待っている状態になります。
これによりワークフローが停止してしまいます。

これを避けるために、Finはバックグラウンドで閉じる処理を行い、ワークフローがジョブ中または返信ボタンの選択待ちの間は自動終了メッセージを送信しません。

注意：メッセージがスキップされても、Finは以下を実行します：

顧客が非アクティブになったことを検知する。
会話を自動的に閉じる。
会話イベントに閉鎖を記録する。

よくあるFinの自動化問題

なぜFinは会話を早期に閉じるのですか？

Finは自動終了設定やworkflowの構成により会話を自動的に閉じることがあります。主な原因：

workflowが顧客に追加の質問がないことを確認した後、終了ステップに到達すると会話が閉じられます。
自動終了設定はFinの最後のメッセージから数分後に会話を閉じるよう設定されている場合があります。早期終了を防ぐには、workflow内のLet Fin handleステップをクリックし、自動終了タイマーを長めに調整してください。

なぜFinは顧客の問い合わせに応答しないのですか？

Finが顧客の問い合わせに応答しない理由は以下の通りです：

ワークスペースで設定された使用制限に達している。Fin Usageページを確認し、必要に応じて制限を増やしてください。
workflowの設定でFinではなく人間のエージェントへのルーティングが優先されている。workflowのトリガーを見直し、Finが適切に使用されるよう調整してください。

なぜFinは不必要に問い合わせを人間のエージェントにエスカレーションするのですか？

Finはワークスペースで設定された解決制限に達すると、不必要に問い合わせを人間のエージェントにエスカレーションすることがあります。設定 > 請求 > 使用状況に移動し、解決グラフを確認してください。必要に応じて制限を増やしてください。

なぜFinは追加情報を求めた後に会話を閉じるのですか？

Finが満足のいく回答を提供できず、顧客がエスカレーションを要求しなかった場合、会話が閉じられることがあります。会話が閉じられた後でも顧客はFinに質問を続けることができ、返信があればFinは会話を再開します。

なぜFinは質問がされていないのに応答するのですか？

Finは会話内のすべての入力（クイック返信ボタンの選択も含む）を考慮して応答を形成します。Finに明確な質問にのみ応答させたい場合は、Guidanceの指示を更新してその動作を指定してください。

なぜFinはOutboundメッセージに対する顧客の返信に応答しないのですか？

FinがOutboundメッセージの返信に応答するオプションはSimple deployment設定でのみ機能し、Outboundメッセージ自体で明示的に有効にする必要があります。Advanced deploymentでWorkflowsを使用している場合、Finはこれらの返信に自動応答しません。Simple deploymentに切り替えるか、Let Fin handleステップを含むAdvanced Workflowで返信を処理してください。すでにSimple deploymentでFinが応答しない場合は、Outboundメッセージの設定を確認してください。メッセージを開き、Add follow up actionをクリックし、Let Fin respondが選択されていることを確認してください。このフォローアップアクションが特定のOutboundメッセージに追加されていないと、Simple Deployと対象設定が正しくてもFinは返信に応答しません。詳細はLet Fin AI Agent follow up after Outbound messages or Workflowsをご覧ください。

なぜFinはエスカレーションせずに会話を閉じるのですか？

Finは「この問題をエスカレーションしてくれてありがとう」などのメッセージを解決の合図と解釈し、エスカレーションせずに会話を閉じることがあります。Fin Guidanceを更新して、エスカレーション言語の扱いを明確に指示し、感謝メッセージを解決済みとみなさないようにしてください。

なぜFinは営業時間外に連絡されたと顧客に伝えるのですか？

Finは会話が設定された営業時間外に開始された場合、営業時間外メッセージを送信します。アカウント設定で営業時間を確認・調整し、運用スケジュールに合わせてください。Workflowsはチームごとに設定されたカスタム営業時間ではなく、デフォルトの営業時間のみを使用します。

なぜFinは期待通りにメールに応答しないのですか？

Finが期待通りにメールに応答しない理由は以下の通りです：

Intercomでチームメイトのメールとして設定されていないメールアドレスからテストメールを送信している。適切に設定されたテストアドレスを使用してください。
workflowの割り当てルールがFinの初回応答後に会話をチームメイトに割り当てている。workflowを見直し、割り当てステップがFinのメール自動化と競合しないようにしてください。

なぜFinはバイパスすべきメールに返信するのですか？

旧式のFin Profilesが新しい展開方法と競合し、Finがバイパスすべきメールに応答することがあります。アクティブなFin Profilesを一時停止し、FinはWorkflowsまたはSimple deployment経由でのみ展開してください。

Fin AI Agentを無効にするには？

Fin AI Agentを無効にするには、無効にしたいチャネルのFin AI Agent Deployページに移動してオフにします。Finを完全に無効にするために以下の手順を実行してください：

Fin AI Agent > Deployに移動し、該当チャネルのFinを無効にします。チャットとメールの設定横の緑の点が無効時に黄色に変わります。
すべてのアクティブなWorkflowsからFinを削除してください。
Finが有効になっているライブのProceduresまたはWorkflowsを無効にしてください。主要チャネルが一時停止されていても、FinはアクティブなWorkflows、Data connectors、およびProceduresを通じて顧客とやり取りできます。

データコネクタのよくある質問