Agentforce Service Agentとは？チャットボットとの違いと導入設計

「Agentforceでカスタマーサポートを自動化したい」と調べていくと、Agentforce Service Agentという名前を知るものの、従来のチャットボットと何が違うのかが分からない方は多いのではないでしょうか。結論から言うと、Agentforce Service Agentとは、顧客からのあらゆるサービスの問い合わせを、24時間365日、自律的に解決するカスタマーサポート向けのAIエージェントのことです。あらかじめ決めたシナリオに沿って答えるチャットボットとは、内部で動く仕組みそのものが異なります。

そこで本記事では、Agentforce Service Agentとチャットボットのアーキテクチャの違いから、システムの構成、ユースケース、トピック・アクションの設計、エスカレーションやセキュリティ、そして導入で変わる仕事までを、導入設計にそのまま使える形で解説します。なお、機能の名称と提供状況は更新が続くため、本記事は2026年8月時点の情報にもとづいています。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。

Agentforce Service Agentとチャットボットの違い

本記事では、アウトドア用品をオンラインで販売する中堅のD2C企業（Service Cloud導入済み・CS担当12名・問い合わせ月約4,000件）が、Agentforce Service Agentの導入を検討したケースを例に解説を進めます。この企業は説明のための架空の設定であり、実在の企業ではありません。Agentforce Service Agentをただの高性能なチャットボットと捉えると本質を見誤ってしまいます。

Agentforce Service Agentとチャットボットの違いは、応答の賢さの度合いにはありません。決めた手順どおりに答えるか、状況を見て自ら推論して解決するかという、意思決定のアーキテクチャそのものにあります。

下の表で、従来のチャットボットとAgentforce Service Agentの違いを整理します。

違い①事前定義シナリオで動くチャットボットとの差

1つ目の違いは、従来のチャットボットが、あらかじめ人が用意した事前定義シナリオに沿って動く点です。なぜなら、チャットボットは想定した質問と回答の分岐をたどる仕組みであり、シナリオに用意されていない問い合わせには答えられないからです。

分岐を細かく作り込むほど対応できる幅は広がりますが、それでも人が想定した範囲を超えることはできません。想定外の問い合わせは、結局その先で人が対応することになります。

たとえば、このD2C企業のチャットボットでは、「注文状況を知りたい」といった定型の質問には答えられていました。ところが、「先週の注文をキャンセルして別の色に変えたい」という複数の要望が混ざった問い合わせには対応できず、有人対応へ回っていたのです。CS担当者は、こうした込み入った問い合わせの一次対応に追われていました。

このように、事前定義シナリオで動くチャットボットは、想定の範囲を超えた問い合わせに弱いという限界を抱えています。

違い②ReActパターンで自律推論するアトラス推論エンジンの差

2つ目の違いは、Agentforce Service Agentが、アトラス推論エンジンによって自ら推論しながら問題を解決する点です。アトラス推論エンジンとは、Agentforceの頭脳にあたる推論エンジンのことです。そしてReActパターンとは、「推論→行動→観察」を繰り返し、行動の結果を確かめてから次の判断を下していく方式を指します。

この仕組みが効いてくるのは、CoT（Chain-of-Thought＝最初に立てた計画を順番に実行する方式）のように計画の誤りで止まることがなく、状況を見ながら解決の道筋を組み立て直せるからです。会話の途中で条件が変わっても、その変化を取り込んで対応を続けられます。

たとえば、先ほどのD2C企業で、キャンセルと色変更が混ざった問い合わせをAgentforce Service Agentに任せた場面がありました。まず注文を検索し、キャンセルの可否を確認し、在庫を調べて別の色を提案する、という複数の手順を、会話の流れに合わせて自分で組み立てて進めたのです。チャットボットでは有人対応に回っていた問い合わせが、最後まで自動で完結しました。

このように、ReActパターンで自律推論するAgentforce Service Agentは、想定外の問い合わせにも動的に対応できます。

違い③RAGで社内データを参照して回答する仕組みの差

3つ目の違いは、Agentforce Service Agentが、RAGによって社内データを参照しながら回答する点です。RAG（検索拡張生成）とは、AIが回答を生成する前に社内のデータやナレッジを検索し、その内容を根拠として回答を組み立てる仕組みのことです。

RAGが重要なのは、一般知識だけで答えるとハルシネーション（事実と異なる内容をもっともらしく生成すること）が起きやすく、社内データに基づかせることでそれを減らせるからです。Data CloudのRAGは、CRMレコードのような構造化データと、Knowledge記事のような非構造化データの両方を参照します。

たとえば、このD2C企業で「この前買ったテントの防水性能はどのくらい？」と聞かれた場面では、RAGがKnowledge記事の製品仕様と、CRMレコード上のその顧客の注文履歴を参照しました。チャットボットのように用意した定型文を返すところを、その顧客が実際に購入した商品の正確な仕様に基づいて回答したのです。

このように、RAGで社内データを参照するAgentforce Service Agentは、事実に基づいた回答を返せます。

Agentforce Service Agentのシステムアーキテクチャ

前章で、Agentforce Service Agentがアーキテクチャからチャットボットと異なることを整理しました。では、その内部はどのような構造になっているのでしょうか。そこでここでは、顧客の会話が処理される仕組みを、3つの観点から解説します。

Agentforce Service Agentは、オムニチャネルフローで会話を受け渡し、アトラス推論エンジンとData CloudのRAGで解決し、Einstein Trust Layerで保護するという、役割の異なる部品の連携で動いています。

仕組み①チャネル→受信オムニチャネルフロー→Agentforce Service Agent→送信オムニチャネルフローの構造

1つ目は、顧客の会話が「チャネル→受信オムニチャネルフロー→Agentforce Service Agent→送信オムニチャネルフロー」という順で処理される構造です。オムニチャネルフローとは、チャットやメールなど複数のチャネルから来た問い合わせを、適切な担当先へ振り分けるSalesforceのルーティングの仕組みのことです。

この構造になっているのは、どのチャネルからの問い合わせも、いったん受信のルーティングを通してからエージェントへ渡し、回答を送信のルーティングで顧客へ返すことで、チャネルが違っても一貫した対応を保てるからです。チャネルごとに別々の応答の仕組みを作る必要がなくなります。

たとえば、このD2C企業では、Webチャットからの問い合わせも、メールからの問い合わせも、受信オムニチャネルフローを通っていったんAgentforce Service Agentに集約されました。エージェントが回答すると、送信オムニチャネルフローを通じて元のチャネルへ返されたのです。担当者は、チャネルごとに仕組みを用意し直す必要がありませんでした。

このように、受信と送信のオムニチャネルフローがAgentforce Service Agentを挟む構造によって、複数チャネルの問い合わせを一貫して処理できます。

仕組み②8〜12の専門LLMとData CloudのRAGが連携する処理パイプライン

2つ目は、Agentforce Service Agentの内部で、8〜12の専門LLMとData CloudのRAGが連携する処理パイプラインです。LLM（大規模言語モデル）とは、大量の文章を学習して文章の生成や理解を行うAIのことです。

複数のモデルで分担するのは、一つのモデルにすべてを任せるより、意図の解釈・データの検索・回答の生成といった工程を専門のモデルが担当したほうが、精度と安全性を保ちやすいからです。この工程の中で、Data CloudのRAGがCRMレコードやKnowledge記事を参照します。

たとえば、このD2C企業で顧客が「返品したい」と伝えた場面では、内部で複数の工程が動いていました。意図を読み取るモデル、Data CloudのRAGで該当する注文と返品ポリシーを検索する工程、返品手続きの回答を組み立てるモデルが、順に処理を進めたのです。顧客から見れば一つの返答でも、その内部では複数の工程を経ていました。

このように、複数の専門LLMとData CloudのRAGの連携によって、Agentforce Service Agentは正確な回答を組み立てています。

仕組み③Einstein Trust LayerがすべてのLLM送受信を保護する役割

3つ目は、Einstein Trust Layerが、Agentforce Service AgentのすべてのLLM送受信を保護する役割です。Einstein Trust Layerとは、AIとやり取りされるすべてのデータやプロンプトをチェックし、安全性を確保するSalesforceの信頼基盤のことです。

保護の仕組みが要るのは、顧客対応では氏名や住所といった個人情報がLLMに送られる場面が避けられず、送信時と受信時の両方でチェックを通す工程が必要になるからです。一部のやり取りだけを検査する形では、チェックを通らない情報が残ってしまいます。

たとえば、このD2C企業で、顧客の氏名や配送先住所を含むやり取りが処理される場面でも、送信時・受信時に必ずEinstein Trust Layerを通っていました。担当者が個別に設定をしなくても、機密情報の保護が自動で働いていたのです。

このように、Einstein Trust LayerはAgentforce Service Agentの送受信を保護し、業務利用の前提となる安全性を支えています。この仕組みの詳細は、後半のセキュリティの章で改めて整理します。

どこで使う？Service Agentのユースケース4選

システムの構造がわかると、次に気になるのは、Agentforce Service Agentが実際にどんな業務をこなせるのかです。事前定義したアクションを組み合わせることで、単なる質問応答を超えた対応ができます。そこでここでは、BtoCのカスタマーサポートで効果が出やすい4つのユースケースを紹介します。

Agentforce Service Agentは質問に答えるだけでなく、注文検索・返品・外部システム連携・能動的な顧客連絡といった、業務そのものを実行できます。

ユースケース①注文の検索・管理・返品処理の自律対応

1つ目は、注文の検索・管理・返品処理を自律的に対応するユースケースです。なぜなら、これらは問い合わせの多くを占める定型業務であり、事前定義アクションとして用意しておけば、人手をかけずに最後まで完結できるからです。

問い合わせ件数の大部分は、注文状況の確認や返品の受付といった定型的なものです。ここを自動化できるかどうかで、CS部門にかかる負荷は大きく変わります。

たとえば、このD2C企業で「注文番号◯◯を返品したい」という問い合わせが来た場面では、Agentforce Service Agentが注文を検索し、返品の可否を返品ポリシーに照らして確認し、返品処理の開始まで自律で進めました。月およそ4,000件の問い合わせのうち、こうした定型の注文・返品に関するものが半数以上を占めており、その一次対応が自動化されたのです。

このように、注文と返品の定型対応は、Agentforce Service Agentが自律的にこなせます。

ユースケース②ServiceNow・Jira等の外部チケットシステムとの自律連携

2つ目は、ServiceNowやJiraといった外部のチケットシステムと連携し、ケースを自律的に作成・更新・クローズするユースケースです。なぜ役立つのかというと、サポート業務は自社のCRMだけで完結せず、別部門が使う外部システムへの起票が必要になる場面があるからです。

外部システムへの連携を人の手作業に頼ると、転記の遅れや記入ミスが生じます。問い合わせを受けたその場で自動起票できれば、対応のスピードと正確さを保てます。

たとえば、このD2C企業では、配送業者側の確認が必要な問い合わせを受けた場面で、Agentforce Service AgentがJiraに自動でチケットを起票し、進捗に応じて更新し、解決後にクローズまで行いました。あわせて、Salesforceと基幹システムの間でアカウントデータを同期させ、担当者が手作業で転記する必要がなくなったのです。

このように、外部チケットシステムとの自律連携によって、部門をまたぐ対応も自動で進みます。

ユースケース③キャンセル時の代替商品提案による売上維持

3つ目は、顧客がキャンセルを選んだ場面で、代替商品や割引を提示して売上を維持するユースケースです。なぜなら、キャンセルをそのまま処理すると売上機会を失いますが、その瞬間に適切な代替を提案できれば、一部は購入につなげられるからです。

キャンセルの受付は、これまで売上が消える場面でしかありませんでした。その場で顧客の関心に合う選択肢を出せるかどうかで、結果は変わってきます。

たとえば、このD2C企業で、顧客が在庫切れの商品をキャンセルしようとした場面では、Agentforce Service Agentが在庫のある類似モデルや割引を提示しました。その結果、キャンセルを申し出た顧客の一定割合が、そのまま代替品の購入に切り替えたのです。キャンセル対応が、売上を維持する機会に変わりました。

このように、キャンセル時の代替提案によって、失われかけた売上をつなぎとめられます。

ユースケース④配送遅延が発生した際の顧客への自律連絡

4つ目は、天候などの影響で配送遅延が発生した際に、顧客へ自律的に連絡するユースケースです。なぜ効果があるのかというと、遅延の連絡は顧客が問い合わせてくる前に能動的に伝えるほど、不満やクレームを抑えられるからです。

顧客が「まだ届かない」と問い合わせてから対応するのでは、どうしても後手に回ります。先に状況を伝えられれば、同じ遅延でも受け止められ方は変わります。

たとえば、このD2C企業で、大雪により一部地域への配送が遅れた場面では、Agentforce Service Agentが対象の注文を特定し、該当する顧客へ遅延の状況と到着見込みを自動で連絡しました。問い合わせが集中する前に先回りで連絡できたため、その週のCS担当者への問い合わせがはっきりと減ったのです。

このように、配送遅延時の能動的な連絡によって、顧客の不満を未然に抑えられます。以上が、Agentforce Service Agentが得意とする4つの代表的なユースケースでした。

トピック・アクション・指示の設計方法

ここまで見てきたユースケースは、トピックとアクションという単位を設計することで実現します。Agentforce Service Agentは、この設計に沿って自律的に動きます。そこでここでは、トピック・アクション・指示をどのように設計するのかを、3つのステップで解説します。

Agentforce Service Agentの挙動は、役割を定義するトピックと、実行内容を紐付けるアクション、そして自然言語の指示という3つの設計要素で決まります。

設計①トピックにロールと自然言語のインストラクションを定義する

1つ目は、トピックに、エージェントの役割と自然言語のインストラクションを定義することです。トピックとは、エージェントが担う役割を自然言語で定義する単位のことで、インストラクションとは、その役割の中でどう振る舞うかを言葉で指定する指示のことです。

自然言語で定義するのは、ReActパターンのエージェントが、手順を固定するより、どんなときに何を目的として動くかを言葉で与えたほうが、状況に応じて判断できるからです。細かな分岐を書き並べる必要はありません。

たとえば、このD2C企業では、「返品対応」というトピックに、返品ポリシーの適用範囲や、どんな場合に人の担当者へ引き継ぐかを、自然言語で書きました。手順を一つずつ指定せず、判断の枠組みを言葉で与える形にしたのです。標準テンプレートのAgentforce Service Agentを使えば、こうした設計をローコードで数分から始められます。

このように、トピックにロールと指示を定義することが、設計の出発点になります。

設計②アクションにフロー・Apex・プロンプトテンプレートを紐付ける

2つ目は、アクションに、フロー・Apex・プロンプトテンプレートといった処理を紐付けることです。アクションとは、トピックに紐付けて実際に実行する処理のことで、Apexとは、Salesforce上で使うプログラミング言語のことです。

トピックが役割の定義だとすれば、アクションはその役割で実際に動かす手段にあたります。ここで押さえておきたいのは、各アクションには最低1つの入力が必要になる点です。たとえば注文検索のアクションなら、注文を引き当てるための入力が欠かせません。

たとえば、このD2C企業の「注文検索」アクションには、注文を特定するための入力として、顧客のメールアドレスを設定しました。エージェントは会話の中でそのメールアドレスを集めてから、注文検索のアクションを実行したのです。

このように、アクションに処理と入力を紐付けることで、トピックが実際の実行に変わります。

設計③エージェントが情報収集からアクショントリガーまで自律判断する仕組み

3つ目は、エージェントが、会話の中で必要な情報が揃っているかを自律的に判断し、アクションを実行する仕組みです。なぜこれが要点なのかというと、手順を固定しないぶん、何が揃えばどのアクションを起動するかを、エージェント自身が判断するからです。

必要な情報が足りなければ、エージェントは顧客に質問して不足を補います。人があらかじめ「この場合はこの質問をする」と分岐を作り込む必要はありません。

たとえば、このD2C企業で顧客が「返品したい」とだけ伝えた場面では、エージェントは注文検索に必要なメールアドレスがまだ揃っていないと判断し、まず顧客にメールアドレスを尋ねました。情報が揃った時点で注文検索のアクションを実行し、返品対応へ進んだのです。担当者が分岐を指定しなくても、情報収集からアクション実行までが自律的に進みました。

このように、情報収集からアクション実行までを自律的に判断できることが、Agentforce Service Agentの設計の要点になります。

いつ人へ渡す？エスカレーション設計の3つの構造

設計の要点がわかると、避けて通れないのが、エージェントが対応しきれないときにどう人へ引き継ぐかです。Agentforce Service Agentは、このエスカレーションの流れもあらかじめ設計しておけます。エスカレーションとは、AIが対応しきれない問い合わせを、人間の担当者へ引き継ぐことを指します。そこでここでは、エスカレーション設計の3つの構造を解説します。

エスカレーション設計とは、エージェントが対応できない場面で顧客を人へ確実につなぐための、転送・フォールバック・事前メッセージという3つの仕組みを用意することです。

構造①顧客が人間担当者を希望した場合の自律転送フロー

1つ目は、顧客が人間の担当者を希望した場合に、自律的に転送する構造です。なぜなら、顧客が人と話したいと望んだ時点で速やかにつなぐことが、顧客満足度を保つうえで欠かせないからです。

顧客が人を求めているのに手続きで待たせると、そこで不満が生まれます。希望をくみ取って、すぐに人へ渡す流れを用意しておく必要があります。

たとえば、このD2C企業で顧客が「担当者と話したい」と伝えた場面では、エスカレーショントピックが起動し、案内のメッセージを送ってから、送信オムニチャネルフローを通じて適切なキューへ転送しました。顧客は長く待たされることなく、人の担当者につながったのです。

このように、顧客が人を希望した場面では、エスカレーショントピックが自律的に転送を進めます。

構造②担当者不在時にSalesforceにケースを自動作成するフォールバック

2つ目は、担当者が不在で転送できない場合に、Salesforceへケースを自動作成するフォールバックの構造です。フォールバックとは、想定した処理ができないときに備えた、代替の対応のことです。なぜ必要かというと、転送先の担当者が全員対応中や時間外で、エスカレーションが失敗する場面があるからです。

エスカレーションが失敗したまま放置されると、顧客の問い合わせが誰にも引き継がれずに残ってしまいます。そうならないよう、代替の受け皿を用意しておきます。

たとえば、このD2C企業で夜間に顧客が担当者を希望したものの、担当者が不在だった場面では、エージェントが顧客に確認したうえでSalesforceにケースを自動作成し、翌営業日に担当者が折り返す形にしました。問い合わせが記録として残り、対応漏れが防がれたのです。

このように、担当者不在時のフォールバックによって、対応の抜け漏れを防げます。

構造③エスカレーション前に顧客へ送るカスタムメッセージの設定方法

3つ目は、エスカレーションの前に顧客へ送るメッセージを、カスタマイズして設定することです。なぜなら、転送やケース作成の前に、これから何が起きるかを一言伝えるだけで、顧客の不安を減らせるからです。

無言のまま転送されると、顧客はつながるまで状況がわからず不安になります。ひと言の案内があるかどうかで、同じ待ち時間でも受け止められ方は変わります。

たとえば、このD2C企業では、「担当者におつなぎします。少々お待ちください」といったメッセージを、自社のトーンに合わせて設定しました。転送やケース作成の前にこの案内が届くことで、顧客の不安を減らせたのです。

このように、事前のカスタムメッセージを設定することで、エスカレーションを丁寧な顧客対応にできます。

導入に必要なエディションと権限設定

エスカレーションまで含めた設計像が見えたら、実際に導入するために必要な条件を確認しておきましょう。Agentforce Service Agentには、エディションと権限の前提があります。そこでここでは、導入に必要なエディションと権限、そして移行の方法を整理します。

Agentforce Service Agentの導入には、対応するエディションとアドオンライセンスに加え、管理者権限とエージェントユーザー権限の設定が必要になります。

必要なSalesforceエディションとアドオンライセンスの条件

1つ目に確認したいのは、対応するエディションとアドオンライセンスの条件です。なぜなら、Agentforce Service Agentは、対応エディションとアドオンが揃っていなければ利用を始められないからです。

必要な条件は、Lightning Experience上でEnterprise・Performance・Unlimited・Developerのいずれかのエディションを使っていることと、Einstein for Service、またはAgentforce for Serviceのアドオンを追加していることです。まず自社の契約がこれに当てはまるかを確かめます。

たとえば、このD2C企業はEnterprise Editionを使っていたため、Agentforce for Serviceのアドオンを追加して要件を満たしました。すでに対応エディションを契約していれば、アドオンの追加から始められる場合があります。

このように、まず自社のエディションが対応しているかと、必要なアドオンを確認することが、導入の出発点になります。

管理者権限とエージェントユーザー権限の設定方法

2つ目は、管理者権限とエージェントユーザー権限の設定です。なぜ両方が要るのかというと、エージェントを構築・管理する人と、エージェント自身が動くために使う権限は、別々に用意する必要があるからです。

管理者には「Agentforceサービスエージェントを管理」「AIエージェントの管理」といった権限が必要です。エージェントユーザーには「Agentforceサービスエージェントユーザー」の権限セットライセンスを付与し、取引先責任者・ケース・KnowledgeオブジェクトへのCRUD権限を許可します。CRUD権限とは、データの作成・参照・更新・削除を行う権限のことです。

たとえば、このD2C企業では、構築担当者に管理権限を割り当て、エージェントが使うユーザーに権限セットライセンスを付与しました。あわせて、外部の顧客向けチャネルへ展開する前に、認証済みユーザーを確認する設計も行ったのです。

このように、管理者とエージェントユーザーの権限を正しく設定することが、安全な稼働の前提になります。

Einsteinボットから移行する場合のBot-to-Agentアプローチ

3つ目は、すでにEinsteinボットを使っている場合の移行方法です。ここでは、Bot-to-Agentアプローチを使うと移行の負担を抑えられます。Bot-to-Agentとは、既存のEinsteinボットから、AIが自動でトピックとアクションを生成する移行機能のことです（ベータ機能）。

ゼロからすべてを作り直すと、それまで積み上げたボットの設定が使えなくなります。既存のボットを変換の出発点にすれば、これまでの資産を活かせます。

たとえば、このD2C企業では、既存のEinsteinボットのシナリオをBot-to-Agentで変換し、生成されたトピックとアクションをもとに調整を進めました。まっさらから作るより、変換された内容に手を入れる形にしたことで、移行の工数を抑えられたのです。ただしベータ機能のため、変換された内容は必ず人が確認して整えました。

このように、Bot-to-Agentアプローチを使えば、既存のEinsteinボットから段階的に移行できます。

Service Agentの安全設計｜セキュリティと統制

権限の設定まで済むと、外部の顧客とやり取りさせる以上、セキュリティとガバナンスの担保が欠かせません。Agentforce Service Agentは、Einstein Trust Layerによってこれを標準で備えています。そこでここでは、セキュリティを支える3つの仕組みを確認します。

Agentforce Service Agentのセキュリティは、動的データマスキング・ゼロデータ保持・有害性検出・監査証跡という、管理者が無効化できない仕組みによって標準で担保されています。

セキュリティ①動的データマスキングとゼロデータ保持でPIIを保護する

1つ目は、動的データマスキングとゼロデータ保持によって、PII（個人を特定できる情報）などの機密データを保護する仕組みです。動的データマスキングとは、PIIや機密データを、LLMに送信する前に自動で伏せ字へ置き換える機能のことです。そしてゼロデータ保持とは、LLMプロバイダー側でのデータの保持や学習利用を防ぐ仕組みを指します。

これらが必要なのは、顧客対応では氏名や連絡先といった個人情報がLLMに送られる以上、その情報が保持されたり学習に使われたりするリスクを、仕組みの側で断つ必要があるからです。現場の一人ひとりの注意に頼る方法では、いつか漏れが生じます。

たとえば、このD2C企業で、顧客の氏名や配送先を含む問い合わせを処理した場面では、動的データマスキングがそれらのPIIを送信前に自動で伏せ字にし、ゼロデータ保持によってLLM側にデータが残らないよう、システムレベルで強制的に適用されていました。現場が個別に気をつけなくても、顧客の個人情報が外部に残らない状態が保たれたのです。

このように、動的データマスキングとゼロデータ保持は、PIIをはじめとする機密データを、システムの側で自動的に保護します。

セキュリティ②有害性検出がデフォルトで有効化されていて管理者は編集不可

2つ目は、有害性検出がデフォルトで有効化されており、管理者でも編集できない仕組みです。有害性検出とは、LLMが生成した応答を顧客へ送る前にリアルタイムで検査し、不適切な内容を防ぐ機能のことです。

デフォルトで有効かつ編集不可になっているのは、生成された応答が顧客へ直接届く以上、不適切な応答を一件も通さないためです。管理者の設定次第で検査が外れてしまうと、その隙に問題のある応答が顧客へ届くリスクが残ります。

たとえば、このD2C企業では、生成された応答が顧客へ届く前に、有害性検出が毎回はたらいて不適切な表現がないかを検査していました。管理者でも無効にできないため、設定の見落としで検査が外れる心配がなかったのです。

このように、有害性検出がデフォルトで有効かつ編集不可であることが、顧客に届く応答の安全性を支えています。

セキュリティ③監査証跡で全プロンプトの送受信を追跡できる

3つ目は、監査証跡によって、すべてのプロンプトの送受信を追跡できる仕組みです。監査証跡とは、送受信されたプロンプト、マスクされたデータ、有害性検出による毒性スコアを、すべて記録として残す仕組みのことです。

記録が必要なのは、顧客対応をエージェントに任せるほど、後から「なぜその応答になったのか」を確認し、説明できる状態が求められるからです。記録がなければ、問題が起きたときに経緯をたどれません。

たとえば、このD2C企業で、後日ある顧客対応の経緯を確認する必要が生じた場面では、監査証跡に送受信されたプロンプトやマスクされたデータ、毒性スコアまでが全件残っていました。そのため、担当者は対応の経緯をたどって社内に説明できたのです。

このように、監査証跡は全プロンプトの送受信を記録し、顧客対応をエージェントに任せるうえでの説明責任を果たせる状態を保ちます。

Agentforce Service Agent導入で変わる仕事

セキュリティまで押さえると、導入後に現場の仕事がどう変わるのかが具体的に気になってきます。Agentforce Service Agentは、CS部門の業務の形を変えます。そこでここでは、導入で変わる仕事を2つの観点から整理します。

Agentforce Service Agentの導入で変わるのは、初期対応の速度と24時間対応できる件数、そしてCS担当者が対応する問い合わせの質です。

変わること①初期対応の速度と24時間対応可能件数

1つ目に変わるのは、初期対応の速度と、24時間対応できる件数です。なぜなら、Agentforce Service Agentが24時間365日稼働し、定型的な問い合わせの一次対応を即座に返すため、人の勤務時間や人数の制約を超えて対応できるからです。

これまでは、対応できる件数が担当者の人数と勤務時間で決まっていました。時間外の問い合わせは、翌営業日まで待ってもらうしかありませんでした。

たとえば、このD2C企業では、これまで営業時間内にCS担当12名で対応していましたが、導入後は夜間や休日の問い合わせにもエージェントが即時に一次対応するようになりました。日中は平均10分前後だった一次応答までの待ち時間が、定型の問い合わせでは即時に短縮され、これまでゼロだった時間外の一次対応も、月およそ1,500件まで自動でカバーされるようになったのです。

このように、初期対応の速度と時間外の対応件数が、導入によって大きく変わります。

変わること②CS担当者が対応する問い合わせの難易度と質

2つ目に変わるのは、CS担当者が対応する問い合わせの難易度と質です。なぜなら、定型的な一次対応をエージェントが引き受けることで、人に残る問い合わせが、判断や交渉を要する難しいものへと絞られていくからです。

量の多い定型対応に追われていた状態では、難しい案件にじっくり向ける時間が取れませんでした。定型対応が自動化されると、その時間の使い方が変わります。

たとえば、このD2C企業では、注文確認や返品受付といった定型対応が減り、担当者は複雑なクレームや個別の提案に時間を使えるようになりました。対応する件数そのものは減っても、一件あたりに求められる判断の重みは増したのです。

このように、担当者が対応する問い合わせは、量をさばく仕事から、質を要する仕事へと変わります。

Service Agentを導入しても変わらない仕事

変わる仕事がある一方で、Agentforce Service Agentを導入しても人が担い続ける仕事もあります。すべてをエージェントに任せられるわけではありません。そこでここでは、導入後も変わらず人が担う仕事を2つ整理します。

感情的でデリケートな顧客対応や、クレーム・契約変更の最終判断は、Agentforce Service Agentを導入しても人が担い続ける領域です。

変わらないこと①感情的・複雑なデリケートな顧客対応は人が担う

1つ目は、感情的で複雑な、デリケートな顧客対応を人が担い続けることです。なぜなら、強い不満や個別の事情が絡む対応は、相手の感情をくみ取って柔軟に応じる必要があり、あらかじめ定型化しにくいからです。

こうした場面では、正しい情報を返すだけでは足りません。相手の気持ちに配慮しながら、その場に応じて言葉を選ぶ対応が求められます。

たとえば、このD2C企業では、商品の不具合に強い不満を持つ顧客への対応は、エージェントが一次で受けつつ、感情的な場面だと判断したら速やかに人へ引き継ぐ設計にしました。謝罪や個別の配慮を要する対応は、これまでどおり担当者が担ったのです。

このように、感情への配慮が要るデリケートな顧客対応は、導入後も人の役割として残ります。

変わらないこと②クレームや契約変更の最終判断は人が行う

2つ目は、クレームや契約変更の最終判断を人が行うことです。なぜなら、金銭の補償や契約条件の変更は、責任と権限を伴う判断であり、企業として人が最終決定を持つべき領域だからです。

AIにどこまで任せるかは、業務のリスクに応じて線を引く必要があります。責任の伴う判断まで自動化すると、想定外の対応を招きかねません。

たとえば、このD2C企業では、返金額の決定や特別対応の可否は、エージェントに任せず担当者が判断する形にしました。エージェントは情報の整理と提案までを担い、最終的な判断は人が下すという線引きにしたのです。

このように、責任を伴う最終判断は、導入後も人が担い続けます。

【一問一答】Agentforce Service Agentに関するよくある質問

最後に、Agentforce Service Agentについて検索されやすい疑問に、簡潔にお答えします。導入判断に直結する点から順に整理します。

Agentforce Service Agentは、Agentforce for Serviceのアドオンを前提に、ReActパターンで自律的に動く点が、従来のEinsteinボットとの大きな違いです。

質問①Agentforce Service AgentはService Cloudなしで使えるのか

サービス機能の基盤なしに単体では使えません。このD2C企業では、これまで営業時間内にCS担当12名で対応していましたが、導入後は夜間や休日の問い合わせにもエージェントが即時に一次対応するようになりました。Agentforce Service Agentはカスタマーサポート向けの機能のため、Einstein for Service、またはAgentforce for Serviceのアドオンが前提になります。対応エディション上でこれらのアドオンを追加する必要があります。

質問②Agentforce Service Agentは日本語対応しているのか

Agentforceは複数言語での運用を想定した設計になっています。この記事の例に挙げたD2C企業では、CS担当12名の体制のまま夜間と休日の一次対応を任せました。ただし、対応言語の範囲や精度はアップデートによって変わります。日本語での本番運用を予定している場合は、最新の対応状況を導入時に確認するのが確実です。

質問③Agentforce Service AgentとEinsteinボットは何が違うのか

最大の違いはアーキテクチャです。このD2C企業でも、事前定義シナリオの分岐を作り込む方式から、月約4,000件の問い合わせをデータを根拠に処理する方式へ移しました。Einsteinボットは事前定義シナリオに沿って動き、Agentforce Service AgentはReActパターンのアトラス推論エンジンで自ら推論します。想定外の問い合わせにも動的に対応できる点が両者を分けています。

質問④Agentforce Service AgentのFlex Credits消費量の目安はどのくらいか

一律の目安を示すのは難しいのが実情です。なぜなら、消費量は1回の対応で動くアクションの数や、会話の複雑さによって変わるからです。まず小さなユースケースで実際の消費量を計測し、その結果をもとに本格運用の規模を見積もるのが現実的です。

質問⑤Agentforce Service Agentは個人情報保護法に対応しているのか

エージェント単体が法令対応そのものを保証するわけではありません。このD2C企業では、エージェントは情報の整理と提案までを担い、最終的な判断は人が下すという線引きにしています。ただし、Einstein Trust Layerの動的データマスキング、ゼロデータ保持、監査証跡といった仕組みが、個人情報の保護と説明責任の基盤になります。最終的な法令対応は、自社の運用設計とあわせて確認するのが確実です。

Agentforce Service Agentはアトラス推論エンジンとEinstein Trust Layerで動く自律型のカスタマーサポートエージェント

Agentforce Service Agentとは、アトラス推論エンジンとEinstein Trust Layerによって動く、自律型のカスタマーサポートエージェントです。本記事では、事前定義シナリオで動くチャットボットとのアーキテクチャの違いを起点に、システムの構成、ユースケース、トピックとアクションの設計、エスカレーションやセキュリティ、そして導入で変わる仕事と変わらない仕事までを、一続きで整理してきました。

Agentforce Service Agentの価値は、単に問い合わせに答えることではなく、注文検索や返品、外部システムとの連携までを自律的に実行し、24時間365日、社内データに基づいた対応を続けられることにあります。今回例に挙げたD2C企業も、月およそ4,000件の問い合わせのうち半数以上を占める定型対応をエージェントに任せ、時間外の一次対応を月およそ1,500件まで自動でカバーしながら、担当者は複雑なクレームや個別の提案といった質の高い対応に時間を使えるようになりました。一方で、感情的な対応や最終判断は人が担うという線引きも、あわせて設計しています。

Agentforce Service Agentを使いこなせるかどうかは、どの問い合わせをエージェントに任せ、どこから人が担うかという設計で決まります。この線引きを自社の業務に合わせて描ければ、カスタマーサポートの速度と質を両立させられるでしょう。自社のカスタマーサポートでAgentforce Service Agentをどう設計すればよいか、ユースケースの絞り込みから一緒に検討したい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。