サイトにログイン済みusers向けにMessengerを設置している場合、不正なusersのなりすましや無許可のデータ送信を防ぐためにセキュリティ対策が必須です。
セキュリティが不十分なMessengerでは、誰かがIntercom Messengerとやり取りし、メールアドレスやuser_idなどの既知の識別子を使って別のuserのなりすましが可能です。これにより攻撃者は実際のuserになりすまし、チームメンバーに過去の会話や機密データへのアクセスを許してしまいます。
参考になれば、こちらの機能とリスク軽減のビデオ解説をご覧ください。
注意：
ログイン済みusers向けのMessenger連携がある場合は、Messengerのセキュリティ強化を強く推奨します。
複数のusersが同じメールアドレスを共有し、連携がメールのみを識別子として使う場合、Intercomはどのuserを使うか推測せず、競合エラーでリクエストを拒否します。認証成功のためには、JWTペイロードに安定した一意の識別子（user_id）を必ず含めてください。JWTの本人確認にはuser_idが必須で、ないトークンは拒否されます。
JSON Web Token（JWT）とは？
JSON Web Token（JWT）はデータ署名の業界標準方式です。通常、ドットで区切られた3つの部分から成り、典型的なJWTはheader.payload.signatureの形をしています。
ヘッダーはトークンタイプ（JWT）と署名アルゴリズム（例：HS256）を指定します。
ペイロードにはuserやセッションに関するクレーム（例：user_id、email）が含まれます。
最後に署名は秘密鍵やプライベートキーを使い、トークンが改ざんされていないことを保証します。
MessengerをJSON Web Tokens（JWTs）で保護する利点は？
ユーザーの本人確認の強化：Messengerを保護することで、チームメンバーは話しているuserが本当にそのuserであることを確信できます。
ユーザーデータのセキュリティ向上：Messengerを保護することで、Messenger APIを通じてuserのデータ属性を安全に送信できます。
盗まれたセッションによるリスク軽減：JWTでMessengerを保護すると、トークンの有効期限を設定でき、userのブラウザからトークンが盗まれた場合のデータ漏洩リスクを大幅に減らせます。短い有効期限を指定することでリスクが軽減されます。
より安全なFinとAI workflows：信頼できるuser情報が必要な複雑なプロセス、Actions、WorkflowsをFinに任せられます。
ヒント：Messenger Securityを有効にすると、usersのMessenger内の全会話履歴が利用可能になります。有効化していない場合、ログイン済みusersは過去14日間の会話のみ閲覧可能で、不正アクセス防止のためのセキュリティ措置です。Messenger Securityがチャネルで有効になると、履歴制限は自動的に解除されます。詳細はUser conversation history visibilityをご覧ください。
userの本人確認とデータを安全に送信し、トークンの有効期限を強制することで、JWTはIntercom Messengerを最も安全な状態に保ちます。
カスタマーエクスペリエンス
Intercom MessengerでJWTを使う場合の体験は以下の通りです：
Messenger連携は、JWTを含む
Intercom('boot')リクエストでログイン済みuserを起動し、送信したいすべてのuserデータを含めます。JWTの署名は設定のMessengerシークレットキーで生成されます。その後、IntercomはuserのブラウザにセッションCookieを発行します。このCookieはデフォルトで7日間有効で、ユーザー認証や更新に使用されます。
セッションが期限切れで新しいJWTが送信されない場合、userのセッションは終了します。userはログアウトしたウェブサイト訪問者として新しいMessengerを見ます。会話履歴は含まれません。
Messengerが
Intercom('boot')と有効なJWTで再起動されると、Messengerはuserを識別し、過去の会話と新しいセッションを表示します。同じデバイスで発生したログアウト中のアクティビティも認証済みuserのアカウントに統合されます。
userのセッションCookieの有効期間をデフォルトの7日より短くしたい場合は、session_duration Messenger属性でミリ秒単位のTTLを指定できます。
インストール：JWTの生成と送信
ステップ1：アプリケーションにMessengerをインストールする
ワークスペース固有のセットアップ手順は設定 > Messenger > セキュリティで確認できます。
安全でないMessenger設定と安全な設定の主な違いは、ユーザーリクエストに追加のintercomUserJwtフィールドを含め、それを使ってuserを識別・更新する点です。
注意：Javascriptスニペットにデータ属性を追加するオプションがあります。これはIntercomに送信したいデータを制御します。JWTでデータを送信するため、署名したくない属性（例：フロントエンド固有のデータ）のみをここに含めるべきです。
JWT以外にデータを送信したくない場合は、api_baseとapp_id以外のすべてのデータをスニペットから削除できます。app_idはIntercomワークスペースの一意識別子です。
ステップ2：usersのためにJWTを生成し始める
業界標準のJWTライブラリを使い、Messenger API Secretを秘密鍵としてトークンを生成できます。秘密鍵は設定 > ワークスペース > セキュリティ > Messengerから生成可能です。
次にMessenger設定 > セキュリティに戻り、バックエンドとフロントエンドのフレームワークを選択して、インストール用の関連コード例を取得してください。
Node.jsの例はこちらです：
重要：Messenger APIのシークレットキーやJWT生成コードはフロントエンドコードに絶対に入れないでください。必ずサーバー側に置き、シークレットキーを適切に保護してください。
usersに関する追加属性（例：price_planやnumber_of_songs_added）を送信したい場合は、それらもJWTに含めます。user_idが唯一の必須フィールドです。カスタムデータ属性についてはこちら。
JWTはいつ含めるべき？
Messengerでuserを起動したり、userデータを更新しようとするすべてのリクエストにJWTを送信してください。
どの有効期限を設定すべき？
JWTの有効期限は短く設定し、リクエストが完全に届き処理されるのに十分な長さにしてください。有効期限は必須ではありませんが、トークンのリプレイリスクを減らすため強く推奨されます。
ステップ3：MessengerスニペットにJWTを追加する
ログイン済みuser向けにMessengerを起動する際、署名済みJSON Web Tokenを提供し、Messengerペイロードのintercom_user_jwt属性に割り当てます。
クライアント側設定例：
window.Intercom("boot", {
api_base: "https://api-iam.intercom.io",
app_id: "APP_ID_CODE",
intercom_user_jwt: <YOUR_USER_JWT_TOKEN>,
};
このJWTには、userに安全に送信したい任意のuserデータ属性を含められます。有効なJWTが受信されると、userのブラウザにデフォルト7日間有効のセッションCookieが作成されます。
MessengerセッションCookieのTTLを制御するには、設定 > チャンネル > Messenger > 一般 > Messengerのセキュリティを保つで最大値を設定できます。
ステップ4：属性の更新を無効にすることを確認する
Messenger APIのデータ属性に対して安全でない更新を有効にすると、Messenger経由のその属性の更新はすべて成功します。
JWTで安全にデータを送信する場合は、これらの属性に対する安全でないMessengerの更新を無効にすることで、有効なJWT経由でのみ更新されるようにしてください。注：このトグルは、botを使ってleadsから直接データを収集することを妨げるものではありません。
JWTで送信するすべての属性に対して、このトグルを有効にすることをお勧めします。
ステップ5：ログアウト時にユーザーセッションをシャットダウンする
Intercomは、あなたが所有する任意の公開サイト（マーケティングサイト、ドキュメントサイト、開発者ハブなど）にIntercom Messengerを設置できます。ユーザーがログインしている間、これらの異なるサブドメイン間で会話の連続性を維持するために、ユーザーのブラウザにクッキーを設定します。このクッキーは1週間で期限切れになります。
共有コンピュータとブラウザを他の誰かと使うユーザーは、クッキーが期限切れになるまで、直近でログインしたユーザーの会話履歴を見ることができます。そのため、ユーザーのセッションが終了した際（手動または自動ログアウト時）にIntercomを適切にシャットダウンすることが非常に重要です。
Intercomをシャットダウンする方法は以下の通りです：
すでにIntercom JSスニペットまたは“boot”メソッドでユーザーのトラッキングを開始しているはずです。
ユーザーがIntercomからログアウトした（またはアプリによって自動的にログアウトされた）場合、JavaScript APIのIntercom('shutdown');を呼び出してIntercomセッションを終了し、クッキーをクリアしてください。
最終ステップ：ワークスペースのMessengerセキュリティを強制する
統合がユーザーのJWTを正しく送信している場合は、Messenger設定 > セキュリティでトグルをオンにしてMessengerセキュリティを強制してください。これにより、Intercomはワークスペースのユーザーに対するリクエストが有効なJWTまたは有効なuser_hashで保護されていることを要求します。
トラブルシューティングガイド
インストールのデバッグに役立つ2つのツールがあります。1つは最近のエラーログを確認する方法、もう1つはトークンデバッガーです。
インストールログを確認する
設定 > チャンネル > Messenger > セキュリティのステップ6でインストールログを確認できます。ここにはJWTインストールに関連するすべての失敗ログが表示されます。JWTが無効、期限切れなどのエラーが表示されます。「ログを見る」をクリックすると、リクエストID、タイムスタンプ、リファラー、ユーザーデータを含む完全なログが表示されます。これにより、リクエストが失敗した理由を理解し、自分のアプリに遡って追跡するのに役立ちます。
一般的なエラーメッセージ
HTTP 400 - "user_hash and intercom_user_jwt cannot be provided simultaneously": リクエストにJWTとuser_hashの両方が含まれていました。顧客はこれらのいずれか一方のみを含めるべきで、両方を含めてはいけません。HTTP 400 - “Missing user_id in payload”: すべてのJWTはペイロードにuser_idを含むことが期待されています。顧客が“email”を主な識別子と考える場合、emailの値をペイロードのuser_idとemailフィールドの両方に入れるべきです。HTTP 400 - “Invalid intercom_user_jwt payload”: JWTのペイロードが無効です。顧客はペイロードが正しく形成され、エンコードされ、api_secret値を署名秘密として使用してSHA256 HMACで署名されていることを確認する必要があります。HTTP 400 - “Intercom_user_jwt expired”: JWTの‘exp’は過去のタイムスタンプです。顧客は将来の有効期限を提供する必要があります。HTTP 400 - “JWT identity mismatch": JWTに提供されたユーザーIDが、アクティブなintercomセッションのクッキーに関連付けられたユーザーと一致しません。これは2つの競合するセッションを開始しようとしていることを示します。新しいユーザーを起動する前にIntercom('shutdown')を呼び出していることを確認してください。HTTP 400 - "Invalid intercom_user_jwt": 有効なユーザーを正しく起動していることを確認してください。
JWTデコーダー
デコーダーツールではJSONウェブトークンをチェックする方法も提供しています。インストールページのサイドバーで見つけることができます。
ツールで生成したユーザーJWTの1つを有効性チェックできます。JWTを生成するために使用した関連する秘密鍵を選択し、「デコード」をクリックしてください。
デコード後、JWTのペイロード、ヘッダー、そして有効か無効かのメモを確認できます。ペイロードを見ることで、属性を送信しているかどうかのトラブルシューティングに役立ちます。
この例では無効な秘密鍵を使用し、user_idフィールドを含めていません。これらはどちらも失敗の原因となります。
よくある質問
なぜJWT内でuser_idが必要なのですか？私のusersはメールアドレスしか持っていません。
現在、usersの主な識別子としてuser_idを提供する必要があります。これまではuser_idまたはemailのいずれかを識別子としてサポートしていましたが、基本的なIdentity Verificationで大きな混乱を招いていました。
usersを識別するためにemailしか持っていない場合は、emailアドレスをペイロードのuser_idとemail属性の両方に入れることができます。ただし、すでにIntercomにemailだけでusersが存在する場合は、JWTを使用する前にuser IDを持つように更新する必要があります。これはuser IDがemailよりも上位の識別子であるためです。
usersにuser IDを追加するには、まずユーザーのIntercom IDでユーザーを特定します。これはAPIの"Get a contact"エンドポイントで行えます。次に"Update a Contact"エンドポイントを使ってuser_idを追加します。詳細はこちら
user_idがない非ログインusers向けにこれを設定するには？
Messengerのセキュリティ機能は、usersに一意のuser IDを提供することを要求します。leads向けにMessengerを使用している場合は、この方法で識別できません。Messenger APIがusersのトラフィックに対して無効になっていることを確認してください。
これはMessenger > インストールで設定できます。使用しているインストール方法（web、iOS、Android）を選択し、「メッセンジャーへの接続を有効にする」トグルがusersに対してオフになっていることを確認してください。
有効期限は何に設定すべきですか？
Messengerが起動されるたびに新しいJWTを送信する必要があるため、トークンの有効期間はMessengerの起動間隔をサポートするだけで十分です。アプリケーションの動作に適した最小期間を選択してください。ウェブページが頻繁にリロードされる場合、JWTは短命であるべきですが、予期しない期限切れ問題を防ぐために最低5分を推奨します。
どの署名アルゴリズムを使用できますか？
HS256（SHA-256を使ったHMAC）をサポートしています。このアルゴリズムは共有秘密鍵を使ってトークンに署名および検証し、トークン内のデータが改ざんされていないことを保証します。
user_hashとintercom_user_jwtの両方を送信できますか？
いいえ、user_hashはJWTに置き換えられるべきため、user_hashとintercom_user_jwtの両方を送信することはサポートしていません。ただし、一部の顧客はuser_hashからintercom_user_jwtに移行する際に、user_hashとintercom_user_jwtの値を交互に送信する必要がある場合があります。
現在Identity Verificationを使用してuser hashesを送信している場合は、JWTを送信するように統合を変更するためのこのガイドを参照してください。
JWTが有効で正常に動作しているかどうかを確認するには？
上記のトラブルシューティングセクションを参照してください。
ワークスペースでJWTの要件を強制するには？
Messenger設定で強制トグルを有効にしてください。
どの属性を保護すべきですか？
すべての識別属性は保護マークを付け、可能であればJWTで安全に送信する必要があります。これにはemail、電話番号、および顧客がUserレコードに保存する可能性のあるaccount_idsが含まれます。属性は設定 > データ > Peopleで確認できます。
FinがActionやWorkflowの重要な部分で使用する属性は、悪意のあるユーザーがその値を上書きできないように保護する必要があります。
JWTの外でデータを送信したい場合は、Messengerの更新を許可している限り可能ですが、ユーザー自身がこのフィールドを更新できる可能性があることに注意してください。
window.intercomSettings = {
app_id: <APP_ID_CODE>,
intercom_user_jwt: <TOKEN>,
unsigned_data_attribute: 'data'
};
ユーザーが何かをしている途中でセッションが期限切れになったら？
クッキーが期限切れた後にユーザーがMessengerでアクティビティを行った場合、Intercomはユーザー体験に悪影響を与えないように1時間の短命クッキーを新たに発行します。ユーザー体験への意図しない影響を防ぐため、クッキーのセッション期間はアプリケーションのセッションタイムアウトと一致させることをお勧めします。
私のモバイルMessengerはどうなりますか？
なぜペイロード全体の署名を必須にしないのですか？
お客様がアプリケーションでユーザーが操作している間に低精度のデータを送信する必要がある場合に対応できるよう、署名されていないAttributesの送信を許可しています。この機能が不要な場合は、すべてのUser Data Attributesを「Messengerの更新から保護」に設定し、署名済みペイロードのみを送信できます。
Messengerのシークレットキーはどのように管理・ローテーションしますか？
シークレットキーはワークスペースのMessengerセキュリティ設定で生成できます。
JWT設定ページの右側サイドバーで既存のキーを見つけてコピーできます。
キーはWorkspace > Security > Messengerでローテーションできます。
JWTに含まれるAttributesは単一のticketまたは会話にのみ適用されますか？
いいえ。JSON Web Token（JWT）に含まれるAttributesは常にIntercomのユーザープロフィールを更新します。JWTのAttributesは単一のticketや会話にのみ適用されるデータを追加するためには使用できません。
Identity Verificationはどうなりましたか？これがそれに代わるものですか？
Identity VerificationはMessenger Securityの以前のバージョンで、HMACユーザーハッシュを使ってユーザーリクエストが統合から送信されたことを識別します。
user_hashesは引き続き受け入れられますが、より多くのセキュリティ利点があるため、すべてのお客様にJWTへのアップグレードを強く推奨します。Identity Verificationは今後更新されません。
JWTページからIdentity Verificationのインストールを管理することも可能です。手順はJWT設定に合わせて更新されており、変更を行う場合はJWTへの移行を強く推奨しますが、機能を無効化したりMessenger APIのシークレットキーをローテーションしたりする必要がある場合は、JWT設定ページからこれを行うことができます。
JWTに会社データを含めてユーザーを会社に関連付けることはできますか？
はい。JWTペイロードにcompany_idやその他の会社属性を含めて、Intercomでユーザーを会社に関連付けることができます。存在する場合、Intercomは起動時に自動的に会社を作成し関連付けます（ping/bootリクエスト中にインラインで会社が作成されるため、追加の遅延は発生しません）。
重要：会社データはJWTペイロード内のcompanyオブジェクトの下にネストする必要があります。company_idやcompany_nameをuser_idと並べてフラットに送信してはいけません。フラットな会社クレームは認識されず、会社の関連付けは作成されません。
これは、会社データがcompanyオブジェクトの下にネストされている場合に正しく動作します。
{
"user_id": "042c8338-591e-4e88-a31b-e5b29c4684ad",
"email": "user@example.com",
"company": {
"company_id": "5de34166-f360-474a-b54d-5615bf22ce35",
"name": "Acme Corp"
}
}
これは、複数のusersが提出したticketsが共有の会社ビューに集約されるTickets Portalなどの会社レベルの機能を使用するセットアップで特に重要です。usersが会社に関連付けられていない場合は、JWTペイロードにcompany_idが含まれているか確認してください。
重要：JWTの外で渡された会社データ（例えば、Intercom('boot')呼び出しのcompanyオブジェクトとして）はJWTが存在する場合は無視されます。会社は更新されず、会社のlast_seen値も更新されません。会社データを正しく更新するには、JWTペイロードに含める必要があります。これはすべての安全なMessengerセットアップで推奨される方法です。
または、ユーザーがログインする前にサーバーサイドAPIを使って会社を作成し、ユーザーを関連付けることもできます。これは、最初のユーザーセッション前に会社データが存在する必要がある場合（例えば、テナント作成時に会社レコードを事前入力する場合）に適した方法です。
注意：JWTにcompany_idを渡しているのにIntercomで会社が作成されない場合は、bugの可能性があるためサポートチームにお問い合わせください。