Messaging for In Web and App (MIAW) のユーザー検証に関して①

Messaging for In Web and App (MIAW)について解説します。

はじめに: Messaging for In Web and App (MIAW)とは

Messaging for In Web and App (MIAW)はお客様とチャットのやり取りを可能にするDigital Engagementの機能の一つです。(以降この記事では省略してMIAWと記載します。)

Summer '22 にてリリースされた比較的新しい機能の一つであり、2026年2月14日に機能廃止が発表されているLiveAgentに代わるチャット機能でもあるため、現在MIAWへの切り替えを検討している方もいらっしゃるかと思います。

この記事ではLive AgentにはなかったMIAWの新機能である「ユーザー検証」に関して説明します。

ユーザー検証とは

ユーザー検証機能は簡単にいうと「同じお客様からの問い合わせであれば、過去のチャットのやり取りが
お客様側からもエージェント側からもすべて見られるようになる」という機能です。

Live Agentでは同じお客様から2回目以降の問合せが来ても、過去のチャットのやり取りは見えませんでしたが、MIAWのユーザー検証機能を実装することによって、エージェント側からはもちろん、お客様側でもが過去のチャットの履歴を見られるようになります。
また何らかの事情で、お客様からのチャットの返信が途絶えてしまったり、お客様側で間違ってチャットのブラウザのタブを閉じてしまっても、チャットが勝手に終了してしまったり、やり取りが消えることなく再問合せが可能となるのも大きなメリットです。

ただし、ユーザー検証に関してはSalesforce側から提供されている機能であるものの、ユーザー検証機能を実装するためには、Salesforce外でのユーザー検証サーバーの構築や、Webサイトに埋め込むJavaScriptの開発が必要となります。
(ちなみにユーザー検証を実装せずにMIAWを利用することも可能です。)

MIAWのOBJ構成

MIAWで使用する主要なOBJに関して説明します。
(このOBJをわかっておくとユーザー検証の実装有無による違いが理解していただきやすいと思います!)

①メッセージングセッション
お客様とのチャットのやり取りを管理するOBJです。
LiveAgentでいう「チャットのトランスクリプト」にあたります。

②メッセージングユーザー
チャットのやり取りをしているお客様を管理するOBJです。

ユーザー検証の実装有無によりレコードの紐づけの関係の違いは以下の通りです。

○ユーザー検証機能を実装した場合
メッセージングユーザーは初回の問合せ時のみに作成され、2回目以降の問合せの場合はすでに作成済みのメッセージングユーザーのレコードを取得します。
そのため、メッセージングユーザーとメッセージングセッションのレコードの紐づきは1:Nになります。

○ユーザー検証機能を実装しない場合
メッセージングユーザーはお客様が問合せをするたびに作成されます。
(同じユーザーからの問い合わせであっても、メッセージングユーザーは問合せごとに作成されます)
そのため、メッセージングユーザーとメッセージングセッションのレコードの紐づきは1:1になります。

OBJ構成図

JWT・JWKに関して

ユーザー検証機能を実装するにあたって、JWTとJWKが必要になります。
MIAWのユーザー検証で使用するJWTとJWKに関して説明をします。

JWT

JWTとはJSONベースのデータを暗号化して作られる文字列です。
ヘッダー、ペイロード、署名の 3 つの部分で構成されており、公開鍵を使用してクライアント側(呼び出す側)にて正当性を確認できるといった特徴があります。

また通常のトークンであればそれ自体が何の情報を持たないことがほとんどですが、JWTはトークン自体に情報を持っています。
(ツールを使用してJWTをデコードした場合、トークンに含まれる情報が分かってしまいます。
そのため個人情報等はトークンに含めないようにすることが望ましいです)
以下がサンプルヘッダーになります。
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "terrasky-mockverify"
}
JWTサンプルヘッダー(デコードしたもの)
以下がサンプルペイロードです。
{
  "sub": "terraskymock01",
  "iss": "terrasky-mockverify-eapi",
  "exp": 1759978223
}
JWTサンプルペイロード(デコードしたもの)
ユーザー検証ではこのJWTのペイロードのsubのプロパティを使用して、ユーザーを識別します。
(つまりこのsubプロパティが一意にユーザーを特定し、会話履歴を表示するキー値になります)

JWK

JWKはトークン(今回でいうJWT)の有効性を検証するために使用できる公開鍵になります。
トークンが改ざんされていないこと、正しい発行元から取得したことを確認できます。

MIAWにおけるJWKの登録方法は2種類あります。
①エンドポイント
　・ユーザー検証のアクセスするごとにJWKを発行する固定のエンドポイントを登録する
②鍵
JWKキーセットをSalesforce組織に登録する

Salesforceヘルプサイトにも①②の詳しい説明がされているので、参考にしていただければと思います。
Salesforceヘルプサイト
{
    "kty":"RSA",
    "use":"sig",
    "alg":"RS256",
    "kid":"mule-miawuserverify",
    "x5c": ["<公開証明書>"],
    "n": "<Base64でエンコードされたモジュール>",
    "e":"<Base64でエンコードされた公開指数>"
}
サンプルJWK

SalesforceでJWKを設定する

今回は②の方法でJWKを登録していきます。
流れとしては、JWKの登録をおこない、次に登録したJWKを用いてJWKキーセットの作成をします。
(①でおこなう場合はJWKの登録は必要ありません)
まず最初にSalesforceにJWKを登録します。
Salesforceでユーザー検証に使用するJWKは
設定>組み込みサービス>アプリ内及びWebのメッセージングのユーザー検証から登録する必要があります。

JWK登録画面

「ファイルをアップロード」からアップロードしたいJWKファイルを選択します。
※ここでJWKが要件を満たしていない場合、アップロードできず下記のようなエラー画面が表示されます。
(今回の場合は x5c の証明書が配列でなかったためエラーがでました)

JWK登録エラー画面

次にJWKキーセットの登録をおこないます。
JWKの登録と同様、
設定>組み込みサービス>アプリ内及びWebのメッセージングのユーザー検証から登録する必要があります。

JWKキーセット登録画面

ここで1つポイントなのは「Json Web キー 発行者」をJWTの iss と一致させる必要があります。
一致していない場合、発行元の正当性を確保できないとみなされ、
ユーザー検証ができなくなるので注意してください。

ユーザー検証の仕組み

ユーザー検証の仕組みとしては上記の図のようになります。
上記の図に関して各①-⑤の実装内容は以下になります。
(具体的にどのような実装が必要なのかといった部分に関しては別の記事で共有させていただこうと思います!)

①JWTを発行するユーザー検証サーバーを構築
②ユーザー検証サーバーにて発行されたJWKをSalesforceにアップロード
③組込みチャットトランスクリプトのJavascriptからユーザー検証サーバーにJWT発行のキーとなる値を含めてJWT発行のリクエストをおこなう処理をおこなう
④レスポンスからJWTを取得
⑤④で取得したJWTをSalesforce標準API(userVerificationAPI.setIdentityToken)に渡して認証をおこなう

おわりに

ユーザー検証機能は従来のLive Agentにはなかった機能であり、より向上した顧客体験を提供できることに貢献できると考えています。
この記事がMIAWのユーザー検証機能の実装を検討していらっしゃる方の参考になれば幸いです。