こんにちは。エンジニアの山下です。
Dreamforce 2024 で華々しく発表された Agentforce ですが、中でも一際力が入っていたのが Service Agent の発表です。これは LLM にエージェントとしてお客様の対応を行なってもらうサービスで、チャットボットなどの従来のサービスよりも自然かつ柔軟な対応が行える点が魅力です。
Service Agent は Salesforce の外部の Web ページからも利用できるように設計されており、任意の画面にチャット形式で埋め込むことが可能です。Salesforce に直結したフルマネージド LLM をそのまま Web ページに埋め込めるとあっては試さないわけにはいきません。
しかしながら、Service Agent の Web ページへの組み込みにはその実装方法が難解であるという難点があります。これは Service Agent が Omni-Channel というあらゆる種類の営業チャネルを統括する仕組みを利用して外部に公開されることに由来します。Omni-Channel はそのコンテキストの大きさ故にそれなりに複雑かつ公式ドキュメントも雑多なため、Service Agent を Web ページに組み込むための必要十分な情報を得るのが難しくなってしまっている印象があります。
せっかく筋の良さそうなサービスがあるのに、これはもったいない状況です。というわけで、今回は Service Agent を Web ページに組み込むのに必要最小限の設定内容について書きたいと思います。
概要
結論から述べると、Web ページから Service Agent に到達するための経路は以下のようになります。
Browser (Web) -> Embedded Service Deployments -> Messaging Channel (Messaging Settings) -> Omni-Channel Flow -> Service Agent
Browser と Service Agent の間にある謎の概念群が Omni-Channel の要素です。
ざっくり述べると、営業チャネルを表す Messaging Channel があり、それを外部に公開するための設定として Embedded Service Deployements が置かれ、実際にその営業チャネルに問い合わせが到達した場合の対応方法が Omni-Channel Flow で定義されているという構成になっています。
結論だけ見るとそれなりに簡潔な構成ですね。どうして公式ドキュメントから掘り起こそうとするとあんなに骨が折れるのかわかりませんね。
というわけで、サクッと実装していきましょう。実装は Service Agent に近い側から順に行います。
Service Agent を作成する
兎にも角にも Service Agent がなければはじまりません。というわけで、まずは Service Agent の作成からはじめます。
前提として、Service Agent を作成するには専用のライセンスが必要です。以下の Trailhead から作成できる Playground に含まれているので、試しに使ってみたいという方はこちらを利用するのがオススメです。なお、筆者もこちらの Playground の環境を利用しています。
Service Agent の作成は Setup の Agents から行えます。画面右上の + New Agent ボタンを押下し、後は画面に表示されるインストラクションに従えば完了です。
作成にあたって特に難しい内容はないため、細かな設定については割愛します。Service Agent の作成後は忘れずに Activate しておきましょう。
Omni-Channel を有効化する
これから Service Agent を外部に公開するための Omni-Channel の設定を行っていくのですが、まずは Omni-Channel を有効化する必要があります。
Omni-Channel の有効化は Setup の Omni-Channel Settings で行えます。Trailhead の Playground では環境取得時点で既に有効化されていますが、念のため確認しておきます。
ちゃんと有効化されていますね。
Enable Skills-Based and Direct-to-Agent Routing にチェックが入っていますが、こちらは Service Agent の利用においては不要なので、チェックを外してしまっても問題ありません。基本的には Enable Omni-Channel にさえチェックが入っていれば OK です。
Queue を作成する
Omni-Channel は、何らかの要因によって問い合わせの適切なルーティングができなかった場合、Fallback Queue にその内容を溜めおくことで機会損失を可能な限り防ぐという設計になっています。従って、その目的で利用する Queue を事前に用意しておかなければなりません。
Omni-Channel で使用する Queue には Routing Configuration を指定する必要があるため、まずはそちらから作成していきます。Setup の Routing Configurations から以下の内容で新規作成を行います。
ここでは Omni-Channel による問い合わせのルーティング方式や優先度などを規定しているのですが、今回の目的においてはそれほど重要な役割は果たさないため、詳細の説明は割愛します。なお、各項目の詳細については こちら の公式ドキュメントに記載されているので、気になる方はそちらを参照してください。
というわけで、作成した TestRouting を使って Queue を作成します。Queue の作成は Setup の Queues から行えます。
設定するのは Routing Configuration と Supported Objects だけでよく、その他の項目（画像中に現れていない Queue Members も含む）は設定不要です。
なお、Supported Objects に指定している Messaging Session は Omni-Channel の問い合わせを管理するためのセッションオブジェクトで、これは次の節で作成する Omni-Channel Flow にも入力として渡されます。
Omni-Channel Flow を作成する
Omni-Channel Flow は、営業チャネルに問い合わせが届いた際に、その問い合わせをどのように処理するかを定義します。今回は Service Agent にその問い合わせを処理してもらうようにルーティングする Flow を作成していきます。
作成方法は通常の Flow と同様で、Setup の Flows から Omni-Channel Flow を作成すれば OK です。
Omni-Channel Flow には暗黙裡に入力として Messaging Session の ID が渡されるのですが、これを受け取るには Flow に recordId という入力用の変数を定義しておく必要があります。以下を参考に変数定義すればよいです。
これで準備は整ったので、いよいよ Flow の中身を作っていきます。といっても、今回作成する Flow は極めてシンプルで、以下のような構成になります。
初期状態から Service Agent に問い合わせを流すための Route Work を追加するだけです。Route Work の設定は以下の通りです。
忘れずに Activate して Flow の作成は完了です。
Messaging Channel (Messaging Settings) を作成する
先ほど作成した Omni-Channel Flow を紐づける営業チャネルを作成します。Setup の Messaging Settings にアクセスして新規作成を選択します。なお、Messaging Settings の一覧画面にあるトグルスイッチは OFF のままで問題ありません。
Messaging Channel は一度作成すると削除できません。Deactivate はできますが、一覧には残存し続ける状態となるため、ご注意ください。
新規作成を行う際に Messaging Channel の種別を聞かれますが、今回は Messaging for In-App and Web を選択します。これは Messaging API を利用する方式で、その名の通り、モバイルアプリないし Web ページから該当のチャネルを利用する際に使用します。
新規作成後に各項目の設定を行う画面に遷移しますが、ここでは Omni-Channel Routing にある項目のみ設定します。具体的には Routing Type を Omni-Flow に設定し、これまでに作成した Flow と Queue をそれぞれ Flow Definition と Fallback Queue に指定すれば OK です。
その他の項目はデフォルトのままでよいです。
こちらも作成後に Activate するのを忘れないようにしましょう。
Embedded Service Deployments を作成する
最後に Messaging Channel を公開するための Deployment を作成します。Setup の Embedded Service Deployments から作成できます。
新規作成時にクライアントとの接続方法を質問されますが、Messaging for In-App and Web の Custom Client を使用すると回答します。最後に作成済みの Messaging Channel を指定して保存すれば完了です。
Deployment は作成後に Publish する必要があるため、忘れずに実施しておきます。なお Publish には 10 分程度かかります。
クライアントを用意する
以上で Salesforce 側の設定は完了です。なので、適当な Web クライアントを用意してテストしてみたいところです。
先にも少し触れた通り、Messaging In-App and Web では Messaging API を利用してクライアントから Omni-Channel にアクセスします。従って、そのためのクライアント実装が必要になるのですが、Salesforce 公式の サンプルアプリ があるので、今回はそちらを利用します。
このサンプルアプリは Web でも利用可能ですが、今回は今後の解析の利便性を考慮してローカル実行してみました。ローカルで実行する場合は以下の２点に注意が必要です。
- package-lock.json を削除しないと
npm isntallに失敗する。Salesforce のプロキシの情報が package-lock.json に残っているため。 - ローカル実行する際には src/index.js にある
React.StrictModeを削除する必要がある。これを忘れるとチャットがうまく動作しない。*1
実際に実行してみると以下のような感じで Service Agent とチャットすることができます。
なお、サンプルアプリへの入力として要求される情報は Embedded Service Deployments の Code Snippet から取得することができます。
何となくレスポンスが返ってきてはいますが、本当に今回作成した Service Agent からレスポンスされているのかも確認しておきます。Agent Builder にログが残っているので、そちらを確認してみます。
ちゃんとチャットで入力した内容がログとして残されていますね。ヨシ！
なお、上記のログは Enrich event logs with conversation data という設定を有効化した場合のもので、この設定が無効になっているとログが少し読みづらくなります。こちらの設定は Agent Builder の Settings から変更可能です。
まとめ
というわけで、Salesforce の外にある Web ページから Service Agent を呼び出すことができました。
Agentforce は Salesforce が今最も販売に力を入れている製品のため、今年一年で Agentforce の活用事例が大幅に増えることが予想されます。今回はその動きに先駆けて、Service Agent を外部アプリないし Web ページで利用する方法について書いてみました。
結論としては、Service Agent は Omni-Channel の Messaging for In-App and Web を使って呼び出すというのが正道になるのですが、Agentforce 自体がかなり新しい製品のためか、Service Agent を API 経由で呼び出す方法について直接的に説明している公式ドキュメントは筆者が探した限り存在せず、開発者が自力で方法を発掘しなければならないというのが現状です。売る気がないのか？
今年一年で開発者向けの情報もわかりやすく整備されていくと嬉しいですね。
以上です。最後までお読みいただき、ありがとうございました。
