アクセスと利用可能性

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

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

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

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

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

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

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

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

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

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

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

なりすましを防ぐには？

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

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

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

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

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）に基づいて分岐できますか？

Workflowsのエラー処理：現時点では、データコネクターが返す特定のAPIエラーコード（4xxや5xxなど）で直接分岐できません。Workflowsはデータコネクターのトリガー成功・失敗でのみ分岐可能です。ただしAPIがJSONペイロード内にレスポンス詳細（例：statusフィールド）を返す場合、その値をConversation Data Attribute（CDA）として保存し、後続のWorkflowsステップで分岐ロジックに利用できる場合があります。

Fin Proceduresのエラー処理：Fin Proceduresはデータコネクターの失敗を自動処理しません。タイムアウトやエラーが発生しても再試行や自動回復は行いません。明確なフォールバック指示がない場合、Finは予期せず停止したり設定に基づかない回答を生成する可能性があります。

これを避けるために、Procedureには失敗時の明確な指示を含めてください。例：「検索失敗時は謝罪し、人間のエージェントにエスカレーションする」。より高度なフォールバックが必要な場合はサブプロシージャ内でデータコネクター呼び出しをラップし、エラー処理を制御してください。高度な失敗処理では、データコネクター呼び出しのstatus_codeが出力属性として利用可能です。これを条件ステップで参照し、404（未検出）と500（サーバーエラー）などHTTPレスポンスコードで分岐できます。詳細はFin Proceduresのコード条件の書き方を参照してください。

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

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

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

これを防ぐ方法：

すべてのコネクタ呼び出し後に条件ステップを追加し、status_codeがエラーを示す場合は明示的な失敗メッセージに分岐させ、トラブルシューティング記事の「Advanced failure handling with status_code」セクションへのリンクを付けてください。
コネクタが失敗した場合に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アドレスを許可リストに追加する必要がある場合があります。以下の通りです：

USA:

34.231.68.152

34.197.76.213

35.171.78.91

35.169.138.21

52.70.27.159

52.44.63.161

Europe:

54.217.125.63

54.246.173.113

54.216.9.3

Australia:

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に切り替えるか、Advanced WorkflowのLet Fin handleステップで返信を処理してください。すでにSimple deploymentでFinが応答しない場合は、Outboundメッセージの設定を確認してください。メッセージを開き、Add follow up actionをクリックし、Let Fin respondが選択されていることを確認してください。このフォローアップアクションが追加されていないと、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を通じて顧客とやり取りできます。

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