問い合わせ対応にAIを入れるとき、最初に決めるのは「どの質問をAIに答えさせるか」だと考えがちです。ブラジルのストリーミングサービス Globoplay が公式事例で見せているのは、別の切り分け方です。分けているのは質問ではなく、会話の相手でした。WhatsAppに届いた会話は、まずEinsteinのチャットボットがログイン情報を確認します。有料会員はそのままEinsteinか担当者が受け持ち、無料の会員（フリーミアム）の複雑な質問だけが、Agentforceで作ったAIエージェントへ引き渡されます。
この記事が扱えるのは、Salesforceの公式事例ページと公式ニュースに書かれている範囲だけです。確認日は2026年10月24日です。公表されているのは比率が中心で、会話の件数、測定した期間、比率の分母は、いずれのページにも書かれていません。同じ構成にすれば同じ結果になる、という読み方はできない事例です。
読みどころは3つあります。会員区分で窓口を分けたこと、設計から公開まで4週間で、扱う範囲を絞って出したこと、そして同じ「22%」という数字が、Salesforce自身のページの間で別々の指標名で説明されていることです。最後の1つは、ベンダーの事例ページから数字を引くときの読み方そのものに関わります。
問い合わせは年間「7.7 million」、担当者は200人
まず、この窓口が置かれた前提を押さえます。公式事例によると、Globoplayはブラジル最大のメディア企業 Globo が運営するストリーミングで、「25 million viewers each month」と記載されています。無料、広告つき、有料の階層があり、会員は年に30%の伸びが続いていると書かれています。
対して、問い合わせを受ける側の規模は小さいままでした。ページには年間「7.7 million subscriber questions」が WhatsApp、SNS、Webチャット、電話に届くと記載があり、対応するのは「200 service reps」と書かれています。既存のチャットボット（Einstein）でさばける範囲は限られており、アクセスが集中する時期には待ち時間が延びたとあります。とくに多かったのが、まだ有料会員ではない人からの質問です。加入の条件や、見たい作品が配信されているかどうかを尋ねる会話が、話題作の公開に合わせて増えます。
ここが、この事例の出発点として重要です。混み合っていたのは既存顧客からの苦情ではなく、買う前の人からの質問でした。答えが遅れて失うのは、サポートの満足度ではなく申し込みそのものです。
会話の入口で、有料会員と無料会員を分けている
公式事例には、会話がどう流れるかが書かれています。WhatsAppで始まった会話は、Einsteinのチャットボットがログイン情報を確認するところから始まります。そこから、相手の状態に応じて適切な窓口へ振り分けられます。有料会員はこれまでどおりEinsteinか担当者が対応し、無料会員の場合は、込み入った質問が Agentforce のエージェントへ引き渡されます。
この分け方には、実務上の意味があります。間違えたときの損害が小さい側から渡しているということです。有料会員との会話には契約内容、支払い、解約が絡みます。無料会員との会話は、作品の有無やプランの違いを説明する場面が中心です。前者で誤った案内をすれば契約の話になりますが、後者はやり直しがききます。
もう1つの読み方もできます。無料会員は、そのまま加入へ進む可能性がある相手です。待たせていた層を先にAIへ回したのであれば、これはサポートの効率化ではなく獲得の施策として設計されたことになります。公式事例の見出しが「subscriptions」を主語にしているのも、そのためだと読めます。ただし、どちらの意図だったかはページに書かれていません。ここは推測として扱ってください。
エージェントができることも列挙されています。メニューを選ばせずに自然な文章で質問へ答えること、視聴の好みに合わせてプランを提案すること、申し込みやアカウント復旧の手順を案内すること、自分の範囲を超えた依頼を担当者へ引き継ぐこと、終了後に満足度調査を集めることです。範囲外を人へ渡す線引きが、できることの一覧に並んで書かれている点は、そのまま参考にできます。
設計から4週間、最初は35以上のトピックから
公開までの進め方も公表されています。設計から稼働までは「four weeks」、しかも最大の話題作が公開される繁忙期に合わせて出したと書かれています。最初に載せた知識は「more than 35 topics」で、やり取りはすべてData 360へ保存されます。作ったのはAgentforceのAgent Builderで、ローコード・ノーコードで組み立てられる道具だと説明されています。
4週間という数字だけを見ると、短期間で作れることの証明に見えます。しかし並べて読むと、別のことが分かります。短くできたのは、扱う範囲を先に絞ったからです。相手は無料会員、置き場所はWhatsApp、知識は35以上のトピック、範囲外は人へ。4つとも、作る前に決めておける種類の決め事です。
土台が先にあったことも押さえておきます。同じSalesforceのブラジル向け公式事例では、Globoが Marketing Cloud や Service Cloud を使って売上が209%伸びたと紹介されています。こちらのページにAgentforceの記載はなく、顧客情報の統合やチャネルをまたいだ対応を整えた段階の話です。エージェントは、何もないところへ置かれたのではありません。なお209%という数字にも、対象期間と比較の起点は書かれていません。
公表されている4つの数値
公式事例が結果として挙げているのは4つです。NPSが110%向上、回答の正確性が109%向上、WhatsApp経由のサブスクリプション売上が22%増、そして解決まで到達した会話が22%増。いずれも比率で、件数は書かれていません。
数字を見る前に、1つ断っておきます。この4つにはいつからいつまでを測ったのか、何と比べたのかという説明がありません。NPSの110%向上は、元の値が分からなければ変化の大きさを判断できません。回答の正確性も、何を正解とし、誰が採点したのかが書かれていません。どれも、自社の目標値として持ち帰れる形にはなっていないということです。
公表されていない項目も、はっきりさせておきます。1日に扱う会話は「thousands of conversations」とだけ書かれ、実数はありません。担当者へ引き継がれた割合、誤った案内が出た割合、導入にかかった費用、対応言語、有料会員へ広げる予定の時期も、いずれも記載がありません。問い合わせ対応をAIで自動化する考え方を自社で検討するときは、この「書かれていない欄」のほうが参考になります。公表値ではなく、同じ欄を自社で埋められるかどうかが判断材料になるためです。
同じ22%が、公式ページの間で3通りに説明されている
ここが、この事例でいちばん注意が要る部分です。22%という同じ数字が、Salesforce自身のページの間で、違う指標名に結びついています。
公式事例ページでは、22%は「WhatsApp経由のサブスクリプション売上の増加」と「解決まで到達した会話の増加」の2つに添えられています。一方、公式ニュースの「Agentforce Makes It Easy to Experiment with and Expand Agentic AI Use」では、Grupo Globo が解約しそうな会員の特定、個別のアップグレード提案、クロスセル、非会員の転換にエージェントを使い、その結果として「Agentforce boosted Globo’s retention rates by 22% in less than three months」と書かれています。継続率が3か月足らずで22%向上した、という説明です。さらに別の公式ニュース「Agentforce in Action」では、「a 22% increase in retention rates compared to their previous bot」と、以前のボットとの比較として紹介されています。
別々の指標がたまたま同じ22%になった可能性はあります。売上、会話の完走、継続率は、そもそも別のものです。ただ、各ページは互いを参照しておらず、読む側には区別できません。社内の資料に「海外事例では継続率が22%上がっている」とだけ書き写すと、どのページのどの指標を指しているのか辿れなくなります。
ベンダーの導入事例を引くときの扱い方は、ここから決まります。数字だけを抜き出さず、どのページのどの指標名かを一緒に残す。そして、指標名が複数ある場合は、その食い違いごと記録しておく。解約率を下げる取り組みのように自社の継続率を扱う場面では、他社の公表値を基準線にしないほうが安全です。測り方が違えば、同じ名前の指標でも比べられません。
70人のワークショップで、作る人を増やした
導入のあと何をしたかも公表されています。デジタル部門の責任者 Samuel Dall’Agnol さんの発言として、「Out of all the Salesforce products we use, Agentforce was the easiest to get started with.」と掲載されています。使っているSalesforce製品の中で、いちばん始めやすかった、という評価です。続けて、70人を集めた2日間のワークショップを開き、終わる頃には参加者全員がエージェントを作れるようになった、と述べています。
ここで測られているのは、エージェントの性能ではありません。作れる人の数です。1つの窓口がうまくいったかどうかと、組織が次の窓口を自分で作れるかどうかは別の問題で、後者を数えている事例は多くありません。
ただし、この数字にも限界があります。研修の終了時点で作れた人が70人いたことは分かりますが、その後も作り続けているのか、作られたエージェントがいくつ稼働しているのかは書かれていません。同じ公式事例には、今後の展望として、有料会員の対応、視聴提案の個別化、B2Bの広告業務、開発の生産性へ広げる構想が挙げられていますが、これらは実施済みの結果ではなく予定として書かれています。
日本の実務者が持ち帰れること
数字ではなく、決め方の順番が参考になる事例です。
第一に、AIへ渡す相手を先に決めることです。質問の種類で切り分けようとすると、どの質問が難しいかを事前に判定する作業が必要になり、設計が止まります。会員区分や取引の状況なら、すでに持っているデータで分けられます。間違えたときの損害が小さい側から始める、という順番でもあります。
第二に、範囲を数えられる形にすることです。この事例では、最初に載せた知識が35以上のトピックと書かれていました。扱う話題を数えられるなら、増やす計画も、答えられなかったときの原因の切り分けもできます。
第三に、引き継ぎ先を同時に決めることです。できることの一覧に「範囲外は担当者へ」が並んでいるのが、この事例の作り方です。AIが答えられる範囲の外側に、誰がいつ出てくるのかを決めていないまま公開すると、待ち時間の問題がそのまま残ります。
第四に、自社の現状値を先に測ることです。110%も22%も、測り方が公表されていないため比較対象になりません。先に自社の数値を持っていれば、導入後の変化を自分の基準で説明できます。同じメッセージ窓口の事例として、Klarnaが公表したAIアシスタントの数値も、測り方の記載がどこまであるかという目で読むと、扱い方が見えてきます。
最後に、効果について補足します。ここに出ている数値は、ブラジルの特定のサービスで、特定の時期に、特定の相手へ向けて実施した結果として公表されたものです。同じ仕組みを置けば同じ数字になる、という性質のものではありません。借りられるのは、誰の会話をAIへ渡すかを先に決め、範囲を数え、渡し先を用意してから出すという順番までです。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。
あわせて読みたい
AIで問い合わせ対応を自動化する方法｜導入の判断と設計を解説 問い合わせ対応の自動化を、対象の見極めから設計、運用までの手順で解説します。自動で答えてよい範囲、人へ引き継ぐ条件、公開前に整えるべき情報を実務目線で整理します。
KlarnaのAIアシスタントは初月で顧客対応の3分の2を処理した 決済のKlarnaは、OpenAIと組んだAIアシスタントが初月で2.3 million件の会話に対応し、フルタイム700人分の仕事をこなしたと公表しました。解決時間や再問い合わせ率まで公開された事例から、顧客対応AIの実像を整理します。
解約率を改善する方法｜サブスク・SaaSのチャーンを減らす施策 解約率の定義、顧客チャーンと売上チャーンの違い、コホート分析、オンボーディング、利用障害、請求失敗、解約理由から改善する方法を解説します。