Agentforce Service Agent における Adaptive Response Formats の現状調査

こんにちは、エンジニアの浅見です。

今回のテーマは、Agentforce Service Agent における Adaptive Response Formats(アダプティブ応答形式)です。 Adaptive Response Formats とは簡単にいえば、Service Agent の出力を自動で綺麗にしてくれるオプションです。 今回は主に公式の情報を調査して整理したものとなっておりますが、後半では実装例も簡単に紹介しております。

なお、本記事は執筆時点の情報であり、今後変更になることがございますのでご承知おきください。


Adaptive Response Formats とは?

まずはじめに、Agentforce の Agent は以下の二つに大別されます。

  • Agentforce Employee Agent (AEA):従業員向けのエージェントで、Salesforce に埋め込まれたチャットでやり取りを行う場合が多い
  • Agentforce Service Agent (ASA):顧客向けのエージェントで、自社サイトなどに埋め込まれたチャットでやり取りを行う場合が多い

ASA は AEA に比べて外部のユーザーが利用するわけですから、細かい見た目や導線などにこだわり、顧客体験を向上するための工夫が大切です(もちろん従業員向けでも大切ですが)。 一方で外部のサイトに会話の内容を送信して表示させるため、当然ながら当該サイトの仕組みに大いに依存します。 ということで、Service Agent(のルーティング)で設定することで応答のデータ構造をもとに自動的にリッチな表示に適応してくれる仕組みがあります。 それが Agentforce Service Agent における Adaptive Response Formats(アダプティブ応答形式)になります。

前提として、Agent の出力に対する UI をアレンジしようと思うと、その選択肢は以下の二択となります。

  • Custom Lightning Types
  • Adaptive Response Formats

端的に述べるのであれば、「Custom Lightning Types」はカスタム開発によるもので「Adaptive Response Formats」は設定変更によるものとなるのですが、公式の開発者ブログにわかりやすい比較表があります。 こちらの表は大変わかりやすいのですが、最近の変更点が考慮されておりません(この辺りの変化はとても早いので、本ブログ記事もすぐに古い情報になってしまうかもしれません)。

ということで、上記の記事にある表を参考にしつつ再構成したものを以下に記載します。

Custom Lightning Types Adaptive Response Formats
対応エージェント Service Agent(Enhanced Chat v2)/ Employee Agent(Lightning Experience) Service Agent の各メッセージングチャネル(Experience Cloud は除く)
目的 入出力UIを自由に設計 応答データに応じて自動でリッチ化
実装 LWC(LightningTypeBundle: editor/renderer) 設定ベース(ルーティング/アクション構成)+返却データ構造を整える
入出力カスタム 可能 限定的
使いどころ 複雑で厳格な要件の場合 少ない工数で実現したい場合

こちらの表に出てきた Enhanced Chat v2 については、主題から離れてしまうため省略いたします。 詳細は公式ヘルプをご覧いただくのが確実で、他にも以下のような参考になるヘルプが多数ございます。

ここで関連するのは、こちらのヘルプ記事で、要するに Service Agent でも Custom Lightning Types を利用してカスタム開発ができるようになったということです。 したがって、Adaptive Response Formats で簡単に UI を強化することもできるし、満足できなければより凝ったものも作れるようになったということです。 もちろんなんでもできるわけではないですし比較的新しい機能ですから、要件に応じて検証が必要なことは言わずもがなですが、自由度が上がったのは嬉しいことです。

Adaptive Response Formats でできること

さて、「自動的にリッチな表示に適応してくれる」とは言ってもどこまでできるものなのでしょうか? 上記の表にて「入出力カスタム」を「限定的」としておりましたが、具体的には以下の2種類の出力形式が用意されています。

意味合いとしてはその名の通りですが、Rich Choice Response の方では表示された選択肢をユーザーが選択すると値がそのまま入力になってくれます。また、画像を表示することもできるので、Rich Link Response を使うことで、おすすめの商品画像を表示させておいてその商品ページに誘導することもできたりするわけです。 このようなことが設定のオン/オフだけでできるので、なかなか便利そうではあります。

それではこのような出力を自動で行わせるにはどうしたらいいのでしょうか? 実はそれ自体は比較的簡単で、Agent による出力を特定の形式にすれば良いです。 具体的には、Apex や Flow を用いてレコード情報を取得して Agent に出力変数として渡せば良いです。 上記の各形式ごとに、以下のような項目を出力させることが推奨されています(参考リンク)。

Rich Link のデータ構造(参考: Rich Link Reference

  • linkTitle: ラベル(必須)
  • linkUrl: URL(必須)
  • linkImageUrl: 画像URL(必須)
  • linkImageMimeType: 画像MIMEタイプ(任意だが推奨)
  • description: 説明(任意)

Rich Choice のデータ構造(参考: Rich Choice Reference

  • name: ラベル(必須)
  • imageUrl: 画像URL(必須)
  • mimeType: 画像MIMEタイプ(任意だが推奨)
  • description: 説明(任意)

これらを Agent に出力変数として渡すことで Agent は出力を JSON 形式で返し、チャットでの表示が自動で調整されるというわけです。

実装例

Agent の構築と Adaptive Response Formats の設定

では実際に Agent を作って Adaptive Response Formats をオンにしてみましょう。 とはいえこちらで実装例やサンプルコードも公開されております。 あくまでもこれまでに記載してきたページを参考に Agent を作成してみた実験過程としてご覧いただければ幸いです。

今回の想定は、動物のぬいぐるみ販売サイトとしました。 ユーザーは特定の動物のぬいぐるみについて質問するので、該当する商品があればその情報を返すことができます。 また、どのような商品があるのかも聞けば教えてくれるよう設定します。 (この辺りも上述の例を踏襲しております)

具体的には画像のようなトピックを作成し、アクションとしては単にレコードを取得して項目値を出力可能な変数として割り当てただけの Flow を割り当てます。

トピックの設定
アクションの設定
フローの内容

Service Agent の構築自体はこれだけです。 当然ながらMessaging Channel などの設定は別途必要になります。 設定手順は基本的にService Agent を Web ページから利用する - フレクトのクラウドblogに沿っています。 Enhanced Chat v2 に変わったことで少し UI が変わってはおりますが、設定する項目に大きな変更はありません。 そして肝心の Adaptive Response Formats の設定は画像の場所で行います。

設定箇所

以前は Agent Builder の Connection タブから設定していたのですが、いつの間にやら設定箇所が変わっていました。

出力の確認

ということで Adaptive Response Formats を切り替えて出力がどうなるか見ていきますが、以下の部分からテストを行なっていきます。

Test Enhanced Web Chat
ちなみにService Agent を Web ページから利用する - フレクトのクラウドblogの際には Salesforce のサンプルアプリを用いていたのですが、最近使えるようになったこちらであれば Agent の情報を入れずにすぐに使えて便利です。 簡単な動作確認であれば十分でしょう。

設定オンの状態で質問してみた結果が以下の通りです。

入出力の結果

そして選択肢から "Sea Lion Stuff" を選択すると以下のようになります。 確かに選択した値がチャットに入力され、それに応じて取得したレコード情報を綺麗に表示してくれていることがわかります。

選択した後

では設定オフの場合はどうなるのでしょうか。

設定オフの場合
今回の例は単純なため、正直なところこれはこれでいいのでは?と思ってしまいますが、やはり選択肢をクリックするだけで確実に入力を与えられるのは便利です。 またここでは試していませんが、実際の販売サイトでは画像をその場で比較させたり商品ページに移動して詳細を比較したりなど、使い方はさまざまです。 設定一つで可能であることを考えると、なかなか良い機能に思えます。

一つ注意点ですが、Agent Builder の表示には Adaptive Response Formats は適用されません。 本機能をテストする際には、実際に使用するチャットを配置した画面を用意する必要があります。 上述の Test Enhanced Web Chat は簡単な動作確認はできますが、やはり実際のチャット画面を用意するのが最も確実です。

まとめとその他所感

今回は Agentforce Service Agent における Adaptive Response Formats について公式情報を整理し、極めて簡単ではあるものの実際に動かせるかを試してみました。 端的に言って、これだけ簡単な設定でリッチ表示になるのはなかなか良いように思いました。 ところが一方で、社内の実案件では出力が安定しないと言った報告が実は多く、課題も多いようです。

また個人的に気になるのは比較表に「Experience Cloudは除く」と書いてある点です。 すなわち Experience Cloud にて Embedded Messaging を利用したとしても Adaptive Response Formats は適用されないわけです。 私が参画しているプロジェクトではチャットボットの検証にあたって簡単な Experience Cloud Site を構築し、そこで Agent のやり取りを確認しております。 その際に Adaptive Response Formats をオンにしていたところ、表示が乱れてしまったのです。 問題なのはこれが、Agent Builder では表示の乱れに気づけない点です。 この際は原因を特定することができず、ケース起票をした結果、良かれと思っていた Adaptive Response Formats が悪さをしていたことが判明したわけです。

Agentforce の関連機能は発展が凄まじく早く、情報が整備されていない中で実装を進めなければならないのが現状です。 今回の Adaptive Response Formats に関しても実案件で作成していた頃と本記事執筆時点で UI が異なる部分が多く、本題とは無関係な部分での困難が多くありました。 常にアンテナを張り続けてキャッチアップする姿勢の大切さを感じる実験となりました。