商品比較からチャット内の購入まで。SalesforceのCarterは何をする？

商品を探す質問には答えられても、購入するには別の場所で選び直す。そんな買い物の分断を減らす用途として、Salesforceは買い物支援AI「Carter」を紹介しました。商品を見つけ、比較し、質問への回答を得て、チャット内で購入手続きへ進む役割です。[1]

自社の通販サイトにAI接客を取り入れたい担当者は、商品を選ぶ支援と、注文を受け付ける処理を分けて検討すると、必要な確認が具体的になります。この記事では一つの買い物例を通じて、Carterに期待する役割と、導入前に確かめる条件を説明します。

参照確認日：2026年9月15日。根拠は同年9月14日付のSalesforce公式発表です。実アカウントでの設定や購入は確認していません。

Carterは、商品選びから購入までを支えるAI

Salesforceは、企業の仕事を進めるAIの仕組み「Agentforce」に、役割別のAIを追加すると発表しました。Carterは買い物客向けで、発表上は一般提供中です。各AIは企業の業務ルール、権限、セキュリティーの範囲で動作すると説明されています。[1]

買い物客にとっての利点は、希望を伝えた会話から、比較や購入へ進めることです。店側が検討したいのは、質問への回答だけを任せるのか、それとも購入の直前まで案内をつなげたいのかという違いです。ただし、この発表だけで日本での利用地域、料金、必要な製品契約、設定方法は確定できません。[1]

以下の通勤バッグの例、記入表、確認の進め方は、AgentSignalによる独自の編集提案です。Carterの実画面や実行結果、事例企業の取り組みを再現したものではありません。

商品比較では、希望を「確かめられる条件」にする

例えば、架空の店が通勤バッグを販売しているとします。客の希望は「雨の日にも使えて、仕事用のパソコンが入るバッグ」です。この段階で店が解決したいのは、商品名を知らない客でも、自分に合う候補を選べるようにすることです。

ここでは、商品Aと商品Bを説明用の候補にします。商品Aは軽さを重視した型、商品Bは荷物の仕分けを重視した型という仮定です。実際の検討では、この呼び名を自社で販売している商品名に置き換え、商品の仕様書や商品ページにある情報で比較します。

あいまいな希望を、そのまま断定に変えない

「雨の日にも使える」という希望だけでは、どこまでの性能が必要かは決まりません。短時間の小雨を想定しているのか、長時間の屋外移動を想定しているのかで、確認したい情報が違います。AIに望む会話を考えるなら、推薦文より先に、この聞き分けを書き出します。

パソコンについても、単に「入ります」と答える設計では判断材料が足りません。客が持っている機器の寸法と、バッグの収納部分の寸法を照らし合わせる場面を想定します。寸法が不明なら、確認を求める回答を用意するという考え方です。

次の表は、商品担当者が普段使っている表計算ファイルなどに作る、説明用の記入例です。「根拠」は回答を支える社内の商品情報、「不明時の扱い」は情報がないときの応答方針を意味します。

客の希望	比較に使う情報	説明用の記入内容	不明時の扱い
雨の日にも使いたい	水への強さと使用上の注意	生地の説明だけでなく、縫い目や開口部の注意も確認	確認できない性能は約束しない
パソコンを入れたい	収納部分と機器の寸法	機器の幅・高さ・厚みを聞く	寸法の確認を求める
軽い方を選びたい	商品の重さ	同じ単位でAとBを比べる	重量情報がないと伝える
荷物を分けたい	収納部分の構成	ポケットの数だけでなく用途を示す	商品写真や説明を確認する

この表で見つけたいのは、文章の言い回しではなく、答えの根拠が欠けている箇所です。例えば商品Aに重量の記載がなければ、比較用の説明を作る前に、商品担当者が正しい値を確認します。こうしておくと、AIの回答を評価するときも「自然に話せたか」だけでなく「根拠のある比較だったか」を見られます。

この準備表をCarterへ直接読み込めるかどうかは、参照した公式資料では分かりません。商品情報をどこから、どの形式で渡すかは、実際の構成について別途確かめる事項です。

質問への回答と、購入を決める案内を分ける

候補を出した後は、客が迷っている点を解く場面になります。通勤バッグの例なら「軽さならA、荷物の仕分けならB」という説明が考えられます。これは編集上の例であり、Carterが実際にこの比較を生成したという意味ではありません。

比較の説明には、選ぶ理由と、選ばない理由の両方を含めると確認しやすくなります。商品Aを軽さで案内するなら、収納の構成は客の希望に合うかも見ます。高い商品へ誘導したかではなく、客が伝えた条件との対応を評価するためです。

回答に使う情報の持ち主を決める

商品仕様は商品担当者、配送条件は配送を管理する担当者、返品条件は規約を管理する担当者が確認する、といった分担を検討します。同じ商品でも、仕様の質問と、注文後の扱いの質問では、根拠になる情報が違うからです。

例えば「このバッグを来週の出張に使えるか」という質問には、バッグの用途だけでなく、届け先や発送条件の確認が必要になります。商品説明だけで到着日を約束する設計にはしません。ここで書いているのは店が決めたい回答方針であり、Carterの配送日確認機能を確認済みとするものではありません。

AIに返してほしい答えを先に書くよりも、「何を確認した後なら、その答えを出してよいか」を書く方が、導入時の相談内容が明確になります。不明な条件が残る場合は、確認を続けるのか、人へ引き継ぐのかも決めておきます。

チャット内の購入でも、店側の注文処理を確かめる

Carterについて発表された購入機能は、チャット内で購入手続きを進める「in-chat checkout」です。決済手段、注文の保存先、在庫の更新方法など、具体的な処理の仕様は公式発表からは確認できません。[1]

導入を考える際は、客が会話を続けられることと、店が注文を正しく受け付けられることを別々に確かめます。見た目が一つの会話にまとまっていても、購入対象や金額、注文結果について何を確認できるかは、省略できない検討事項です。

通勤バッグの例では、客が商品Aを選んだ後に、色や数量を確定する場面を想定します。その次に、送料などを含む支払額を示し、客が購入内容を確認する流れを検討します。これは購入体験を評価するための例で、Carterの画面や必須操作を説明する手順ではありません。

確認する場面	店側が用意する説明用の質問	合否を判断する材料
購入対象の確定	選んだ商品・色・数量を客が確認できるか	客に示す購入内容
支払額の確認	商品代以外に何が加わるか分かるか	送料などを含む金額の説明
注文の受付	何をもって注文成立とするか	店側の注文記録と客への案内
処理の中断	途中で止まったとき、注文の有無をどう調べるか	確認先と再試行の判断方法

この表も独自の編集提案です。「合否」は、店が期待する購入体験を満たすかどうかを指し、Salesforceの公式な審査基準ではありません。担当者は自社の購入手続きに照らして、何を見れば判断できるかを右の欄へ具体的に書き換えます。

特に、会話に「購入しました」と表示されることだけを、店側の注文成立の証拠にしない評価が必要です。試験を依頼する場合は、店側の注文記録と客への案内を照合できるかを確かめます。本記事では、その接続や試験は行っていません。

問い合わせ対応AI、営業AIとは役割が違う

同じ発表では、Caseyは質問、返品、アカウント管理、人への引き継ぎなどを扱う問い合わせ対応AIとして一般提供中です。Hunterは見込み客の調査から働きかけまで進める営業向けAIで、試験提供中、2026年11月に一般提供予定とされています。[1]

自社の課題が「買う前に商品を選べない」なら、まず商品選びの支援を検討します。「買った後の返品条件が分からない」なら、問い合わせ対応の課題として切り分けます。似たチャット形式でも、必要な情報と、完了を判断する条件が変わります。

例えば、商品Aの軽さを説明して候補が決まれば、比較の支援は一区切りです。一方、返品の問い合わせなら、商品が決まっただけでは解決しません。どの役割のAIを検討するかは、画面の見た目ではなく、客の困りごとが解けるところまでの仕事で選びます。

また、営業先へ継続的に連絡する仕事と、通販サイトを訪れた客の買い物を手伝う仕事を、同じ導入要件にまとめないようにします。今回はCarterによる商品選びと購入の支援が対象です。Hunterの提供予定をCarterの利用条件に重ねる必要はありません。

日本の店で検討するなら、利用条件を先に確かめる

検討の入口は、Salesforce公式発表のCarterの説明と提供状況です。この発表は機能の概要を知る資料であり、日本の店向けの申込フォームや設定手順としては使えません。[1]

社内の検討メモには、現在の通販システム、販売する国、必要な言語、AIへ任せたい場面を記入します。そのうえで、Salesforceとの導入検討時には次の点を確認する、と論点を絞ります。以下は公式の申込項目ではなく、担当者向けの編集提案です。

• 利用対象： 日本で運営する店が契約・利用できるか。日本語で必要な案内ができるか。
• 必要な契約と費用： Carter以外に必要な製品は何か。利用量などによって何の費用が変わるか。
• 商品情報との接続： 商品説明、価格、在庫をどこから渡し、変更をどう反映するか。
• 注文処理との接続： 現在の購入・決済・注文管理をどこまで使えるか。
• 人へ戻す条件： 回答の根拠がない場合や購入が中断した場合に、誰が対応するか。

一般提供という表示だけを根拠に、自社の通販サイトですぐ使えるとは判断しません。公開された商品登録用のAPI、つまり別のシステムから商品データを送る窓口として案内することもできません。どのサイトにも短い設置コードを一つ加えれば使える、という導入方法も、この資料では確認できません。[1]

最初の検討対象は、実在する商品を二つ選び、客が比較で迷う質問を一つ書くことです。商品担当者は答えの根拠を確認し、通販運営担当者は購入までつなぐ際の未確認事項を書き添えます。Carterを採用するかを急ぐより、任せたい仕事と、自社で成立条件を確認する仕事を具体的に分けられることが、この段階の到達点です。

自社で確認するときに使える公式資料

Salesforceの機能一覧には、店のサイト内で買い物を案内するShopper Agentも掲載されています。[2] また、公式学習ページでは、商品情報を取得する仕組みとしてSCAPI（SalesforceのECシステムから情報を受け取るための接続口）を説明しています。[3] 「AIが商品を知っている」だけで注文まで動くわけではなく、店の商品情報や注文処理との接続が必要だと考える手がかりになります。これらは関連する製品の案内であり、Carterの契約条件や日本での提供範囲を確定する資料ではありません。