サイトにログインユーザー向けのMessengerを設置している場合、不正なユーザーによるなりすましや不正データ送信を防ぐためにセキュリティ対策が必須です。
セキュリティが不十分なMessengerでは、誰かがIntercom Messengerにアクセスし、メールアドレスやuser_idなど既知の識別子を使って他のユーザーになりすます可能性があります。これにより攻撃者は実際のユーザーとしてチームメンバーに接触し、過去の会話や機密データにアクセスできてしまいます。
参考までに、こちらの動画解説では、この機能と軽減されるリスクについて説明しています。
注意：
ログインユーザー向けのMessenger連携がある場合は、Messengerのセキュリティ強化を強く推奨します。
複数のusersが同じメールアドレスを共有し、連携がメールのみを識別子として使用している場合、Intercomはどのuserを使うか推測せず、競合エラーでリクエストを拒否します。認証成功のためには、JWTペイロードに安定した一意の識別子（user_id）を必ず含めてください。JWTの本人確認にはuser_idが必須であり、これがないトークンは拒否されます。
JSONウェブトークン（JWT）とは何ですか？
JSON Web Token（JWT）はデータに署名する業界標準の方法です。通常、ドットで区切られた3つの部分から成り、典型的なJWTはheader.payload.signatureの形式です。
ヘッダーはトークンタイプ（JWT）と署名アルゴリズム（例：HS256）を指定します。
ペイロードにはユーザーやセッションに関するクレーム（例：user_id、email）が含まれます。
最後に署名は秘密鍵やプライベートキーを使い、トークンが改ざんされていないことを保証します。
JSONウェブトークン（JWT）でMessengerを保護する利点は何ですか？
ユーザーの本人確認を強化：Messengerを保護することで、チームメンバーは話している相手が本当にそのユーザーであることを確信できます。
ユーザーデータのセキュリティ向上：Messenger APIを通じてユーザーのデータ属性を安全に送信できます。
盗まれたセッションのリスク軽減：JWTでMessengerを保護するとトークンの有効期限を設定でき、ユーザーのブラウザからトークンが盗まれた場合のデータ漏洩リスクを大幅に減らせます。短い有効期限を指定することでリスクを低減します。
FinやAI workflowsの安全性向上：信頼できるユーザー情報が必要な複雑なプロセス、Actions、WorkflowsをFinに安心して任せられます。
ヒント：Messenger Securityを有効にすると、usersはMessenger内の全会話履歴にアクセス可能になります。有効化していない場合、ログイン済みusersは過去14日間の会話のみ閲覧可能で、不正アクセス防止のためのセキュリティ措置です。Messenger Securityがチャネルで有効になると履歴制限は自動的に解除されます。詳細はユーザー会話履歴の表示をご覧ください。
ユーザーの本人確認とデータを安全に送信し、トークンの有効期限を強制することで、JWTはIntercom Messengerを最も安全な状態に保ちます。
カスタマーエクスペリエンス
Intercom MessengerでJWTを使用する場合の体験は以下の通りです。
Messenger連携は、JWTを含む
Intercom('boot')リクエストでログイン済みuserを起動し、送信したいすべてのユーザーデータを含めます。JWTの署名は設定のMessenger secret keyを使って生成されます。その後、Intercomはユーザーのブラウザにセッションcookieを発行します。このcookieはデフォルトで7日間有効で、ユーザー認証や更新に使用されます。
セッションが期限切れで新しいJWTが送信されない場合、ユーザーのセッションは終了します。ユーザーはログアウト状態のウェブサイト訪問者として新しいMessengerを表示し、会話履歴は含まれません。
Messengerが
Intercom('boot')と有効なJWTで再起動されると、Messengerはユーザーを識別し、過去の会話と新しいセッションを表示します。同じデバイスでのログアウト時の活動も認証済みuserのアカウントに統合されます。
ユーザーのセッションcookieの有効期間をデフォルトの7日より短くしたい場合は、session_duration Messenger属性でミリ秒単位のTTLを指定できます。
インストール：JWTの生成と送信
ステップ1：アプリケーションにMessengerをインストールする
ワークスペース固有のセットアップ手順は設定 > Messenger > セキュリティで確認できます。
安全でないMessenger設定と安全な設定の主な違いは、ユーザーリクエストに追加のintercomUserJwtフィールドを含め、それを使ってユーザーを識別・更新する点です。
注意：Javascriptスニペットにデータ属性を追加するオプションがあります。これはIntercomに送信したいデータを制御します。JWTでデータを送信する場合、署名したくない属性（例：フロントエンド固有のデータ）のみをここに含めてください。
JWT以外に送信したくないデータがなければ、api_baseとapp_id以外のデータはスニペットから削除できます。app_idはIntercomワークスペースの一意識別子です。
ステップ2：users向けにJWTを生成し始める
業界標準のJWTライブラリを使い、Messenger API Secretを秘密鍵としてトークンを生成できます。秘密鍵は設定 > ワークスペース > セキュリティ > Messengerで生成可能です。
Messenger設定 > セキュリティに戻り、バックエンドとフロントエンドのフレームワークを選択すると、インストール用のコード例が得られます。
Node.jsの例はこちらです。
重要：Messenger API secret keysやJWT生成コードはフロントエンドコードに絶対に入れないでください。必ずサーバー側に置き、秘密鍵を適切に保護してください。
usersに関する追加属性（例：price_planやnumber_of_songs_added）を送信したい場合は、それらもJWTに含めます。user_idは唯一必須のフィールドです。カスタムデータ属性についてはこちら。
JWTはいつ含めるべきですか？
Messengerで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には、usersに安全に送信したい任意のユーザーデータ属性を含められます。有効なJWTを受け取ると、ユーザーのブラウザにデフォルト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とintercom_user_jwtは同時に提供できません"：リクエストにJWTとuser_hashの両方が含まれていました。顧客はどちらか一方を含めるべきで、両方は含めないでください。HTTP 400 - “ペイロードにuser_idがありません”：すべてのJWTはペイロードにuser_idを含む必要があります。顧客が“email”を主な識別子と考える場合は、emailの値をuser_idとemailの両方のフィールドに入れるべきです。HTTP 400 - “無効なintercom_user_jwtペイロード”：JWTペイロードが無効です。顧客はペイロードが正しく形成され、エンコードされ、api_secret値を署名秘密鍵として使用したSHA256 HMACで署名されていることを確認してください。HTTP 400 - “Intercom_user_jwtの有効期限切れ”：JWTの‘exp’が過去のタイムスタンプです。顧客は将来の日付の有効期限を提供する必要があります。HTTP 400 - “JWTのID不一致”：JWTに提供されたユーザーIDが、アクティブなintercomセッションのクッキーに関連付けられたユーザーと一致しません。これは2つの競合するセッションを開始しようとしていることを示します。新しいユーザーを起動する前にIntercom('shutdown')を呼び出していることを確認してください。HTTP 400 - "無効なintercom_user_jwt"：有効なユーザーを正しく起動していることを確認してください。
JWTデコーダー
デコーダーツールではJSON Web Tokenをチェックできます。インストールページのサイドバーで見つけられます。
ツールで生成したユーザーJWTの有効性をチェックできます。JWT生成に使用した関連する秘密鍵を選択し、「Decode」をクリックしてください。
デコード後、JWTのペイロードからユーザー詳細、ヘッダー、有効か無効かのメモが表示されます。ペイロードを見ることで、属性が送信されているかどうかのトラブルシューティングに役立ちます。
この例では無効な秘密鍵を使い、user_idフィールドを含めていません。どちらも失敗の原因になります。
無効なJWTを渡したらどうなりますか？
intercom_user_jwtが起動リクエストに含まれているが無効（例えばプレースホルダー値や誤った秘密鍵で署名された場合）だと、Messengerは読み込まれません。Messengerセキュリティがオフでも同様です。Messengerはフィールドが完全にない場合のみJWT検証をスキップし、無効な値は常に拒否されます。
ヒント：まだ有効なJWTを生成する準備ができておらず、Messengerセキュリティが強制されていない場合は、Messenger起動コードからintercom_user_jwtフィールドを完全に削除してください（プレースホルダーや空の値を残すのではなく）。これによりJWT生成準備が整うまで、安全ではないが機能するMessengerインストールが復元されます。
有効なJWTでログイン済みユーザーを起動すると403 Forbiddenエラーが発生するのはなぜですか？
有効なJWTでログイン済みユーザーを起動した際の403「Forbidden request」エラーは、ワークスペースでMessenger API for webがオフになっている場合に発生します。オフの間は匿名訪問者にはMessengerが読み込まれますが、JWTが有効でuser_idがcontactのexternal_idと一致していても、すべてのログインユーザーは拒否されます。
403エラーを解決するには、設定 > チャネル > Messenger > インストールを開き、For users with loginsを選択して、Web向けのEnable the Messenger API to continue installationトグルをオンにしてください。その後、JWTを使ってMessengerを再度起動してください。
Messenger API for webがオフのワークスペースでも、新規ユーザーの最初の読み込みでは動作しているように見えることがあります。JWT起動で403が返り、JWTデコーダーがトークンを有効と報告する場合は、この設定を確認してください。
よくある質問
なぜJWTにuser_idが必要なのですか？ユーザーはメールアドレスしか持っていません。
現在、ユーザーの主な識別子としてuser_idを提供する必要があります。これまではuser_idまたはemailのどちらかをサポートしていましたが、基本的なID検証で大きな混乱を招いていました。
ユーザーをメールアドレスだけで識別している場合は、ペイロードのuser_idとemail属性の両方にメールアドレスを入れることができます。ただし、すでにIntercomにメールアドレスだけでユーザーがいる場合は、JWTを使う前にユーザーIDを追加する必要があります。ユーザーIDはメールアドレスよりも上位の識別子だからです。
ユーザーIDを追加するには、まずユーザーのIntercom IDを特定します。これはAPIの「Get a contact」エンドポイントで行えます。次に「Update a Contact」エンドポイントを使ってユーザーにuser_idを追加します。詳細はこちら
user_idがない非ログインユーザー向けにはどう設定しますか？
Messengerセキュリティ機能は、ユーザーに一意のuser_idを提供することを要求します。leads向けにMessengerを使うだけの場合は、この方法で識別できません。ユーザーのトラフィックがこのチャネルを通らないことを想定しているため、Messenger APIをユーザートラフィックに対して無効にしてください。
これはMessenger > インストールで行えます。使用しているインストール方法（web、iOS、Android）を選択し、「Messengerへの接続を有効にする」トグルがユーザー向けにオフになっていることを確認してください。
有効期限はどう設定すべきですか？
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を交互に送る必要があります。
現在Identity Verificationを使ってuser_hashを送信している場合は、JWT送信に切り替えるためのこのガイドを参照してください。
JWTが有効で正常に動作しているかどうかはどう確認できますか？
上記のトラブルシューティングセクションを参照してください。
ワークスペースでJWTの使用を強制するにはどうすればいいですか？
Messengerの設定で強制トグルを有効にする必要があります。
どの属性を保護すべきですか？
すべての識別属性は保護としてマークし、可能であればJWTで安全に送信する必要があります。これには、email、phone、および顧客がUserレコードに保存する可能性のあるaccount_idsが含まれます。属性は設定 > データ > Peopleで確認できます。
FinがActionやWorkflowの重要な部分で使用する属性は、悪意のあるユーザーがその値を上書きできないように保護する必要があります。
JWTの外でデータを送信したい場合は、Messengerの更新を許可していれば可能ですが、そのフィールドをユーザー自身が更新できる可能性があることに注意してください。
window.intercomSettings = {
app_id: <APP_ID_CODE>,
intercom_user_jwt: <TOKEN>,
unsigned_data_attribute: 'data'
};
ユーザーが操作中にセッションが切れたらどうなりますか？
cookieが期限切れになった後にユーザーからMessengerでアクティビティがあった場合、Intercomはユーザー体験への悪影響を避けるために1時間の短時間cookieを新たに発行します。ユーザー体験への意図しない影響を防ぐために、cookieのセッション期間はアプリケーションのセッションタイムアウトと一致させることを推奨します。
モバイルMessengerはどうですか？
なぜペイロード全体の署名を要求しないのですか？
お客様がアプリケーションでユーザーが操作中に低精度のユーザーデータを送信する必要がある状況をサポートするために、署名されていないAttributesの送信を許可しています。もしこの機能が不要であれば、すべてのUser Data Attributesを「Messengerの更新から保護」に設定し、署名済みペイロードのみを送信できます。
Messengerの秘密鍵はどのように管理・ローテーションしますか？
秘密鍵はワークスペースのMessengerセキュリティ設定で生成できます。
JWT設定ページの右側サイドバーで既存の鍵を見つけてコピーできます。
鍵はワークスペース > セキュリティ > Messengerでローテーションできます。
JWTに含まれる属性は単一のticketまたは会話にのみ適用されますか？
いいえ。JSON Web Token（JWT）に含まれる属性は常にIntercomのユーザープロフィールを更新します。JWT属性は単一のticketまたは会話にのみ適用されるデータを追加するためには使用できません。
Identity Verificationはどうなりましたか？これはそれに代わるものですか？
Identity VerificationはMessenger Securityの以前のバージョンで、HMACユーザーハッシュを使用してユーザーリクエストが統合から送信されたことを識別します。
user_hashesは引き続き受け入れられますが、すべての顧客にJWTの使用へのアップグレードを強く推奨します。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"
}
}
これは、複数のユーザーが提出したticketが共有会社ビューに集約されるTickets Portalなどの会社レベル機能を使用する設定で特に重要です。ユーザーが会社に関連付けられていない場合は、JWTペイロードにcompany_idが含まれているか確認してください。
重要：JWTの外部（例えば、Intercom('boot')呼び出しのcompanyオブジェクトとして）で渡された会社データはJWTが存在する場合は無視されます。会社は更新されず、会社のlast_seen値も更新されません。会社データを正しく更新するには、JWTペイロードに含めてください。これはすべての安全なMessenger設定に推奨される方法です。
あるいは、ユーザーがログインする前にサーバーサイドAPIを使って会社を作成し、ユーザーを関連付けることもできます。これは、テナント作成時に会社レコードを事前に入力するなど、最初のユーザーセッション前に会社データが存在する必要がある場合に適した方法です。
注意：JWTにcompany_idを渡しているのにIntercomで会社が作成されない場合は、bugの可能性があるためサポートチームにお問い合わせください。