Salesforce AIとは？Einstein・Agentforceの関係と使い分け

Salesforceを使っていると、Einstein、Agentforce、Data 360といったAI関連の名前が次々に出てきます。それぞれが何を指し、自社の契約でどれが使えるのかを社内に説明しようとして、手が止まった経験はないでしょうか。Salesforce AIとは、データを集める層・予測と生成を担う層・自律的に実行する層という3つの層の総称です。単一の製品を指す名前ではありません。Agentforceはそのうち最も新しい層にあたります。

本記事では、自動車の内装部品を製造する中堅メーカー（従業員450名・営業25名・情報システム部3名）を例に、どの層から使うかを業務側から決める考え方を解説します。この企業は説明のための架空の設定であり、実在の企業ではありません。記載内容は2026年8月時点のものです。

この記事を書いた人

本田正憲

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

Salesforce AIの名前が整理できない3つの状況

Salesforce AIという言葉が分かりにくいのは、情報が不足しているからではありません。むしろ名前が多く、しかも同じ文脈に並んで出てくることが原因です。例に挙げた自動車内装部品メーカーは、Sales Cloudを7年前から使っていましたが、AI機能を利用している担当者は当初1人もいませんでした。使えない理由があったわけではありません。何から見ればよいのかが決まらないまま時間が過ぎていた状態です。ここでは、名前の整理でつまずく3つの状況を確認していきます。

状況①製品名と機能名が同じ文脈で並んでいる

紹介記事や営業資料を読むと、Einstein、Agentforce、Data 360、Trust Layerといった名前が、同じ段落に並んで登場します。読み手からすると、これらが対等な選択肢なのか、それとも上下の関係にあるのかが判別できません。

このメーカーの情報システム部では、担当者3名がそれぞれ別々の資料を読んで検討を始めました。1人は「Agentforceを入れるかどうか」の話だと理解し、別の1人は「Einsteinの延長線上の機能追加」だと受け取っています。3人目は、まずデータの整備が要るという前提で調べていました。同じ製品について話しているつもりで、指している対象が3通りに分かれていたのです。議論の前提が食い違ったまま、2週間ほど時間が過ぎました。

食い違いに気づいたのは、稟議の下書きを持ち寄った場面でした。3人が書いた1枚目の記述が、それぞれ別の製品の説明になっていたのです。名前が対等に並んでいる資料からは、階層の関係を読み取れません。同じ文脈に並ぶ名前が、実は違う階層を指していることが、整理を難しくしています。 資料を読むときは、それぞれが製品を指すのか、機能を指すのか、保護の仕組みを指すのかを先に区別すると、取り違えを避けられます。

状況②自社の契約でどれが使えるか分からない

2つ目は、自社の契約範囲との照合ができないという状況です。機能の説明は読めても、それが標準で含まれるのか、追加の契約が要るのかまでは書かれていないことが少なくありません。

このメーカーは7年前にSales Cloudを導入し、その後エディションの変更を1度行っていました。当時の契約書を確認しても、AIに関する記載は現在の製品名と一致しません。名称が変わったのか、別の製品に置き換わったのか、そもそも対象外なのかが判別できない状態でした。営業担当へ問い合わせるにも、何を尋ねればよいのかが定まりません。

総務省の令和7年版情報通信白書によると、生成AIについて「積極的に活用する方針」または「活用を検討する方針」を示した日本企業の割合は、2023年度の42.7%から2024年度は49.7%へ増えています。一方で、活用にあたっての懸念として最も多く挙げられたのは「効果的な活用方法がわからない」でした。※参考記事はこちら

方針は定めたものの、どこから手をつけるかで止まっている企業が多いと読み取れます。契約範囲の確認が進まないことは、その足踏みの具体的な中身の1つだといえます。

状況③社内に説明する資料が作れない

3つ目は、社内向けの説明資料を作ろうとして手が止まる状況です。稟議には、何をいくらで導入し、何が変わるのかを書く必要があります。

このメーカーの情報システム部長は、役員会に提出する資料の1枚目で行き詰まりました。「SalesforceのAIを導入する」と書いても、役員から「それは何を指すのか」と問われた場合に答えられないためです。機能名を並べれば技術的には正確ですが、それを読んだ役員が投資の可否を判断できる形にはなりません。

書けなかったのは、業務がどう変わるのかを先に定めていなかったからです。営業25名の何がどう変わり、月90件の商談のどこに効くのかが決まっていれば、必要な機能は後から絞り込めます。

説明できない状態は、理解が足りないから起きているのではありません。説明の順番が、名前から入っているために起きています。 どの業務が変わるのかから書き始めると、資料の構成も自然に決まります。

Salesforce AIの検討が止まる原因は情報不足ではなく、名前から入って業務を後回しにする順番のほうにあります。

Salesforce AIが3つの層に分かれている理由

前章では名前の整理でつまずく状況を挙げました。ここからは、その整理の枠組みを示します。Salesforce AIに含まれる要素は、役割の違いによって3つの層に分かれており、この層の区別を先に置くと個々の名前が収まる場所が決まります。層はそれぞれ独立していません。下から順に積み上がる関係にあり、下の層が薄いままだと上の層の効果も出にくくなります。層という言い方はSalesforceの公式資料にそのまま並んでいるものではありません。役割の違いから整理した見方です。ここでは、3つの層をそれぞれ解説していきます。

層①データを集めて整える層

一番下にあるのが、判断の材料になるデータを集めて整える層です。

AIが何かを予測したり実行したりするには、その根拠になるデータが要ります。商談の履歴、問い合わせの記録、過去の取引の内容といった情報が、読める形で保持されている必要があります。この層が担うのは、社内外に散らばっているデータを集約し、AIが参照できる状態にすることです。

この層が薄いと、上の層をどれだけ整えても出力の精度が上がりません。読む材料がなければ、根拠のない推測になるためです。自動車内装部品メーカーの場合、商談の記録はSales Cloudに入っていた一方で、問い合わせの履歴は別のメールソフトに残っており、同じ顧客の情報が2か所に分かれていました。営業が把握している商談の経緯と、カスタマーサポートが受けた不具合の連絡が、別々の場所にある状態です。

この状態でAIに「この顧客の状況を要約して」と求めても、返ってくるのは片方の情報だけになります。層①の整備は地味に見えますが、上の2層の精度をそのまま左右します。

層②予測と生成を担う層

真ん中にあるのが、集まったデータをもとに予測したり文章を生成したりする層です。

この層の特徴は、人が求めたときに応じるという点にあります。担当者が画面を開けば受注確度が表示され、ボタンを押せばメールの下書きが返ってきます。逆にいえば、誰も操作しなければ何も起きません。使う人が能動的に取りに行くことが前提の設計です。

長らくSalesforceのAIといえば、この層を指していました。予測スコアや推薦の機能が中心で、結果を見た人が次の行動を決めるという使い方です。メーカーの営業25名が知っていたAI機能も、この層に含まれるものでした。ただし知っていることと使っていることは別で、実際に画面を開いてスコアを確認する担当者はいませんでした。

この層の効果は、使う人の習慣に左右されます。表示されていても見に行かなければ、業務は何も変わりません。導入したのに使われないという状態が起きやすいのも、この層の性質によるものです。

層③自律的に実行する層

一番上にあるのが、条件を満たしたときに自ら判断して実行する層です。

前の層との違いは、動き出すきっかけが人の操作ではない点にあります。データを継続的に読み、条件に合致した時点で通知を出したり、下書きを作ったり、記録を更新したりします。人が担うのは、目標を渡すことと最終的な承認です。

この違いは、層②で起きていた「見に行かなければ何も起きない」という問題への答えになります。メーカーの営業がスコアを確認しに行かなかったとしても、条件を満たした案件について通知が届けば、そこから判断が始まります。業務が始まる起点が、担当者の記憶から条件の充足へ移るわけです。

一方で、任せる範囲を決める作業と、人が確認する地点を設計する作業が新しく発生します。自ら動く以上、誤った判断もそのまま実行に向かうためです。この層を使うかどうかは、その設計を担える体制があるかとあわせて考える必要があります。

Salesforce AIを理解する近道は、個々の名前を覚えることより、データ・予測生成・自律実行という3つの層の区別を先に置くことです。

Salesforce AIの主要な呼び名4つの対応関係

3つの層を示しましたが、実務で目にするのは層の名前ではありません。製品や機能の呼び名のほうです。前章の枠組みに、よく出てくる4つの呼び名を当てはめておくと、資料を読むときに位置が分かります。読んでいる資料がどの層の話をしているのかが判別できれば、状況①で起きていた議論の食い違いも避けられます。呼び名は製品名・機能名・仕組みの名前が混在しており、粒度も揃っていません。それぞれがどの役割を担うのかを先に決めておくと、後から新しい名前が出てきても同じ枠組みに置けます。ここでは、4つの呼び名がどの層を指しているのかを整理していきます。

表の右端を見ると、Agentforceだけ起点が人の操作から離れていることが分かります。この違いが、後の章で扱う「できること」の差につながります。

呼び名①Einsteinは予測と生成を担う名前

Einsteinは、層②にあたる予測と生成の機能を指してきた名前です。受注確度のスコアリング、推薦、文章の生成といった機能がここに含まれます。

注意したいのは、この名前が指す範囲が時期によって変わってきた点です。当初は予測が中心で、後から生成の機能が加わりました。そのため、参照する資料の時期によって説明の内容が違います。古い資料を読むと予測の話が中心になり、新しい資料では生成が前面に出ます。

自動車内装部品メーカーの情報システム部が最初に読んだ資料は数年前のもので、予測スコアの説明が中心でした。そこから現在の製品構成へたどり着くまでに時間がかかっています。資料の発行時期を確認せずに読み進めたことが、遠回りの一因になりました。

資料を読むときは、まず時期を確かめる習慣を持つと誤解が減ります。EinsteinとAgentforceがアーキテクチャの面でどう違うかは、ほか記事「Salesforce Einsteinとは？Agentforceとの違いと使い分け」で詳しく解説しています。

呼び名②Agentforceは自律実行を担う名前

Agentforceは、層③にあたる自律実行を担う名前です。条件を満たしたときに自ら動く仕組みが、この名前でまとめられています。

Salesforce公式のTrailheadでは、Agentforceの頭脳にあたるAtlas Reasoning Engineについて「The Atlas Reasoning Engine is the “brain” behind Agentforce, the agentic layer of the Salesforce Platform」と説明されています（2026年8月時点）。※参考記事はこちら

この記述からも、Agentforceが既存のプラットフォームの上に置かれた層であることが読み取れます。まったく別の製品を新しく導入するというより、いま使っている基盤の上に実行の層を足すという理解が近くなります。

この理解は、稟議の書き方にも影響します。「新しいシステムの導入」として起案すると、既存環境との連携や移行の検討まで論点になるでしょう。「いま使っているSalesforceに実行の層を足す」という説明であれば、論点は任せる範囲と承認の設計に絞られます。メーカーの情報システム部長が資料を書き直したのも、この整理を得てからでした。

呼び名③Data 360は判断の材料を集める名前

Data 360は、層①にあたるデータの集約を担う名前です。社内外に分かれている情報を1か所へまとめ、AIが参照できる状態にします。

同じTrailheadの記述では、Atlasが「the most relevant data–both structured and unstructured–from Salesforce Data 360」を取得すると記載されています。判断の材料がこの層から供給されるという関係です。表計算のような構造化されたデータだけでなく、文章のような形の定まらないデータも対象に含まれます。

なお、この機能は以前 Data Cloud という名前で提供されていました。2026年8月時点の公式資料では Data 360 の表記が使われているため、本記事でも Data 360 で統一します。古い資料を参照するときは、同じものを指していると読み替えてください。改称に気づかず別の製品だと受け取ると、状況①で起きたような食い違いにつながります。

このメーカーで問い合わせの履歴が別のメールソフトに残っていた問題は、まさにこの層が担う領域にあたります。層①が担う範囲と、Agentforceがその上に依存している関係は、ほか記事「Data 360（旧Data Cloud）とは？Agentforceに必要な理由と導入の判断軸」で詳しく解説しています。

呼び名④Trust Layerは送受信を守る名前

Trust Layerは、層をまたいで働く保護の仕組みを指す名前です。AIが外部の言語モデルとやり取りするデータに対して、送信の前後で保護をかけます。

この呼び名だけは、3つの層のどれか1つに収まりません。層②と層③のどちらが動く場合でも、外部へデータが出る経路に介在するためです。位置づけとしては、層を横断する安全のための仕組みと考えると整理できます。

保護の仕組みがあること自体は、稟議を通すうえで説明しやすい材料になります。ただし、仕組みがあることと、どこまでを自動で実行させてよいかを決めることは別の作業です。前者は製品の機能ですが、後者は自社で決める設計にあたります。

社内データを外部のAIへ渡すことへの懸念は、稟議が止まる代表的な理由です。一任と承認の境界をどう設計するかは、ほか記事「Einstein Trust Layerとは？AIに一任する範囲と人が承認する場面の設計」で扱っています。

4つの呼び名は横並びの選択肢ではありません。データを集める層・予測と生成の層・自律実行の層と、それらを横断して守る仕組みという関係にあります。

Salesforce AIで実際にできる4つのこと

呼び名と層の対応を整理してきましたが、稟議で問われるのは「それで何ができるのか」です。層の違いは、そのままできることの違いとして現れます。層②に属する機能は人が求めたときに応じ、層③に属する機能は条件を満たしたときに自ら動きます。同じ「AIが助けてくれる」という説明でも、業務の変わり方は同じではありません。稟議の資料でも、機能名を並べるより、この4つのどれにあたるのかを書いたほうが読み手に伝わります。ここでは、Salesforce AIで実際にできることを4つに整理していきます。

できること①商談の受注確度を数値で示す

1つ目は、過去の商談データから傾向を読み取り、いま動いている案件がどの程度受注に近いかを数値で示すことです。表示は商談の一覧と詳細の両方から確認できます。

自動車内装部品メーカーでは、月におよそ90件の商談が動いていました。営業25名がそれぞれ自分の案件を管理しており、優先順位は担当者の判断に委ねられています。経験の長い担当者と入社2年目の担当者では、同じ案件でも見立てが分かれることがありました。数値が表示されると、その判断に共通の目安が加わります。

ただし、この機能は数値を出すところまでを担います。数値を見てどう動くかは人が決めます。層②に属する機能である以上、担当者が画面を開かなければ何も起きません。実際にこのメーカーでも、機能自体は使える状態でありながら、確認しに行く担当者がいませんでした。

表示される数値の精度より、見に行く習慣があるかどうかが効果を分けます。数値の高い案件から順に並べ替えて確認するといった、日々の動作に組み込む工夫が要るでしょう。見に行く習慣に頼らず変化のほうを届ける仕組みは、分析基盤の側にもあります。Tableau AIのメトリクス配信がその例です。

できること②文章の下書きを作る

2つ目は、メールや提案書の下書きを作ることです。顧客の情報と過去のやり取りを踏まえた文面が返ってきます。

このメーカーでは、見積書の作成に1件あたり平均40分かかっていました。内訳を聞くと、文面を書く時間より、過去の類似案件を探して条件を確認する時間のほうが長いという答えでした。似た仕様の案件がどれだったかを思い出し、そのときの単価と納期を確かめる作業です。下書きが用意されれば、担当者は確認と調整から始められます。

生成の機能は、ゼロから考える時間を短くする用途に向きます。一方で、返ってきた内容をそのまま送れるかは別の話です。過去の条件をそのまま引いてくると、原材料の価格が変わっている場合に古い単価が載ります。確認の工程を省くと、誤った条件が顧客へ届く可能性が残ります。

確認の工程を残しても、過去の案件を探す時間が消えるぶんの効果は残ります。下書きまでを任せ、送信は人が判断するという区切り方が現実的でしょう。

できること③社内外の質問に答える

3つ目は、質問に対して社内の資料をもとに答えることです。顧客からの問い合わせにも、従業員からの質問にも使えます。

このメーカーには、月におよそ200件の問い合わせが届いていました。製品の仕様、納期、過去の取引条件といった内容が中心です。担当者が資料を探して回答する作業が、そのまま時間として積み上がっていました。質問の多くは既存の資料に答えが書かれており、探す時間が負担の実体になっています。

答えの元になる資料が整理されているほど、返ってくる内容は正確になります。逆に、資料が複数の版に分かれていたり、担当者の手元にしかなかったりすると、精度は上がりません。層①の状態がここでも効いてきます。

社内向けに使う場合の設計は、顧客向けとは前提が変わります。誤答の影響範囲が社内に収まるという性質があるためです。詳しくは、ほか記事「Agentforce Employee Agentとは？社内問い合わせを任せる範囲の決め方」をご確認ください。

できること④条件を満たした時点で自ら動く

4つ目は、人の指示を待たずに動くことです。層③にあたる機能で、ここが従来との最も大きな違いになります。

たとえば、商談が2週間更新されていない状態を検知して担当者へ通知する、あるいは保守の履歴から更新提案の対象を抽出して下書きを用意する、といった動きです。担当者が思い出したときに作業が始まるのではありません。滞留の日数などの条件を満たした時点で始まります。

この違いが効いてくるのは、月90件の商談を25名で管理している状況です。全件の状態を担当者が定期的に見直すのは現実的とはいえず、動きの止まった案件は気づかれないまま残ります。条件で拾えれば、記憶に頼る部分が減ります。

機能の一覧は、ほか記事「【2026年最新】Agentforceの機能一覧｜360・Coworker・Voiceまで」で整理しています。本記事では、どれを選ぶかの考え方に絞って進めます。選ぶ段階で確かめるのは機能の数ではありません。その機能が層②と層③のどちらに属するかという1点です。

できることの違いは機能の多さで決まりません。人が取りに行くか、条件を満たしたときに向こうから届くかという起点の違いに集約されます。

Salesforce AIを使う前に確認する3つの前提

できることを4つ挙げましたが、どれも前提が整っていなければ動きません。自動車内装部品メーカーが検討に2か月を要したのも、機能の比較に手間取ったからではありません。この前提の確認に時間がかかったためです。確認すべきなのは、契約でどこまで使えるか、判断の材料が読める形にあるか、設定を担う人がいるかの3点です。3つとも、機能の説明を読んでいるだけでは答えが出ません。契約書と自社のデータと体制を、それぞれ実際に見に行く作業になります。ここでは、着手する前に確認しておく3つの前提を解説していきます。

前提①契約しているエディションの範囲

最初に確認するのは、いま契約している内容でどこまで使えるかです。標準で含まれる機能と、追加の契約が必要な機能が分かれています。

このメーカーは7年前の導入時から1度エディションを変更しており、当時の契約書と現在の製品構成が一致しませんでした。情報システム部が販売元へ確認したところ、使える機能と追加が必要な機能の切り分けが判明するまでに3週間ほどかかっています。長引いた理由は、最初の問い合わせが「AIは使えますか」という漠然とした聞き方だったためでした。

2度目の問い合わせでは、商談の優先順位付けに使いたいという業務を先に伝えています。すると回答は具体的になり、必要な機能と費用の目安がその場で示されました。

確認する順番としては、使いたい業務を先に決めてから、その業務に必要な機能が契約に含まれるかを尋ねるほうが早くなります。料金の考え方は、ほか記事「【2026年最新】Agentforce料金・ライセンス完全ガイド」で詳しく解説しています。

前提②AIが読めるデータが整っているか

2つ目は、判断の材料になるデータが読める形で入っているかどうかです。層①が薄いままでは、上の層の精度は上がりません。

このメーカーでは、商談の記録はSales Cloudに入っていた一方、問い合わせの履歴は別のメールソフトに残っていました。同じ顧客の情報が2か所に分かれており、片方だけを読ませても全体像は出てきません。さらに、商談の記録も担当者によって粒度が違い、「訪問」の一言で終わっているものと、先方の反応まで書かれているものが混在していました。

ここで全社のデータ整備から始めると、着手までの期間が読めなくなります。このメーカーが選んだのは、最初に扱う業務で使うデータだけを確認するという進め方でした。商談の優先順位付けであれば、必要なのはSales Cloud内の商談データです。問い合わせ履歴の統合は、後の段階へ回しました。

整備が終わるまで待つと、着手の時期が読めなくなります。対象の業務に必要な範囲だけを見れば、着手できるかどうかは判断できます。

前提③誰が設定を担当するか

3つ目は、設定と運用を担う人を決めることです。導入して終わりにはなりません。動き出してからの調整が続きます。

情報システム部3名のうち、Salesforceの設定を日常的に触っているのは1名でした。残る2名は社内インフラとヘルプデスクを担当しており、Salesforceの画面はほとんど開きません。この1名が通常の運用に加えて対応できる範囲を見積もらないまま計画を立てると、稼働後に手が回らなくなります。

見積もる項目は、初期の設定にかかる時間だけではありません。出力を確認して基準を直す作業が、月にどれくらい発生するかも含めて考えます。このメーカーでは、試験運用の期間中に週1時間ほどを確認に充てる想定を置きました。

担当を決められない場合は、外部の支援を組み合わせる判断もあります。着手の可否を分けるのは機能の有無ではありません。設定を続けられる体制があるかどうかです。

Salesforce AIの検討は機能の比較から入るより、契約範囲・データ・担当者という3つの前提を先に確かめるほうが早く進みます。

Salesforce AIの導入でつまずく3つの落とし穴

前提の確認を終えても、進め方を誤ると使われないまま止まります。自動車内装部品メーカーでも、最初の1か月は方向が定まりませんでした。つまずきの中身は技術的な難しさに起因しません。選び方・広げ方・測り方という進め方の設計に集中しています。しかも3つは連鎖します。選び方を誤れば範囲の広げ方も定まらず、広げ方が定まらなければ測る対象も決まりません。順番に見ていくと、自社がどこで止まっているのかを特定できます。ここでは、繰り返し起きる3つの落とし穴を解説していきます。

落とし穴①機能の一覧から使う順番を決める

1つ目は、機能の一覧を見て使う順番を決めようとすることです。

一覧には数十の機能が並びます。どれも役に立ちそうに見えるため、優先順位が付きません。このメーカーの情報システム部も、最初は機能の一覧に印を付けながら検討していましたが、絞り込めないまま2週間が過ぎました。印を付けた機能は10を超え、そのすべてに「使えそう」という評価が並んでいます。

順番が決まらなかったのは、比較の基準が機能の側にあったからです。機能同士を比べても、どちらが自社にとって先かという答えは出てきません。基準を業務の側へ移すと、判断できるようになります。月90件の商談のうち、どの判断に時間が取られているかを数えれば、順位は自然に付きます。

機能を起点にすると、比較の対象は際限なく増えていきます。新しい機能が発表されるたびに検討がやり直しになり、決める時期も後ろへずれていきました。次章で扱う判断軸は、この転換を具体化したものです。

落とし穴②全社に一度に開放する

2つ目は、設定が終わった時点で全社へ開放してしまうことです。

一見すると効率がよく見えますが、問題が起きたときに原因を切り分けられません。誰がどう使ってうまくいかなかったのかが分からないまま、「使いにくい」という評価だけが残ります。営業25名が同時に触り始めれば、寄せられる意見も25通りに分かれます。

意見が分かれること自体は問題ではありません。むしろ、使う場面が人によって違うことの表れです。困るのは、どれから直すべきかを決められなくなる点です。担当している製品も、顧客の規模も、経験年数も違う25名の意見を同じ重さで並べると、共通する課題が埋もれます。

加えて、最初の印象は後から覆しにくいという問題もあります。一度使いにくいと感じた担当者は、改善した後も戻ってきません。範囲を絞って始めると、確認すべき点も絞られます。最初から広げないことは、慎重さの表れではありません。原因を切り分けるための設計です。

落とし穴③使われているかを測らないまま進める

3つ目は、利用状況を測らずに進めることです。

導入した機能が使われているかどうかは、感覚では分かりません。このメーカーでは、以前に別のツールを導入した際、半年後に「あまり使われていないらしい」という話が出たものの、実際の利用回数を誰も把握していませんでした。使われていないという印象だけが残り、改善も撤収も判断できないまま契約だけが続いています。

測る項目は多くなくて構いません。使った人数と回数だけでも、続けるかどうかの判断はできます。加えて、導入前の状態を記録しておくと比較ができます。見積の作成に1件あたり平均40分かかっているという数字を先に押さえていたことが、後の判断で効いてきました。

測る項目は、着手の前に決めておきます。測っていなければ、改善すべき点も、やめるべき理由も示せません。

つまずきの多くは技術の問題として現れません。業務から選ばず、範囲を絞らず、測らないという進め方の設計から生じます。

Salesforce AIを業務から選ぶ4つの判断軸

落とし穴①で触れたとおり、機能の一覧から選ぶと順番が決まりません。選ぶ基準は業務設計から持ってくる必要があります。自動車内装部品メーカーが最終的に1つの業務へ絞り込めたのも、この転換によるものでした。判断軸は4つあり、すべてを満たす業務ほど最初の対象に向きます。軸はどれか1つを満たせばよいというものではありません。4つすべてを候補の業務に当てて、欠けている軸があればその業務は後回しにします。逆にいえば、4つ揃った業務が見つかれば、そこから始めてよいという判断になります。ここでは、その4つを順に解説していきます。

判断軸①その業務に判断の繰り返しがあるか

最初に見るのは、同じ種類の判断が繰り返し発生しているかどうかです。

AIが効くのは、一度決めた基準を何度も適用できる場面です。年に数回しか起きない判断であれば、基準を整理する手間のほうが大きくなります。基準を言語化する作業には相応の時間がかかるため、適用される回数が少なければ割に合いません。

このメーカーで候補に挙がったのは、月90件の商談に対する優先順位付けと、月200件の問い合わせ対応でした。どちらも週の単位で同じ種類の判断が繰り返されています。一方、年に一度の価格改定の判断は、繰り返しがないため候補から外れました。取引先ごとの事情を踏まえる必要があり、基準を作っても翌年には前提が変わるためです。

繰り返しの回数は、そのまま整理する手間の回収しやすさを表します。件数を数える作業は、候補を並べた時点で一度やっておくと後で効いてくるはずです。感覚で「多い」と言い合うより、月あたりの件数を書き出したほうが順位は早く決まります。

判断軸②答えの元になるデータが社内にあるか

2つ目は、判断の根拠になる情報が社内に存在しているかどうかです。

前提②と重なりますが、ここでは業務単位で確認します。全社のデータが整っていなくても、その業務で使うデータが揃っていれば着手は可能です。逆に、全社的にはデータが豊富でも、対象の業務に必要な情報だけが欠けている場合もあります。

問い合わせ対応の場合、答えの元になるのは製品の仕様書と過去の対応履歴でした。仕様書は最新版が管理されていた一方、対応履歴はメールに散らばっています。商談の優先順位付けであれば、必要なデータはSales Cloud内で完結していました。この差が、着手の順番を決める材料になっています。

データが足りない業務を選ぶと、整備の作業が本体になります。それ自体は必要な作業ですが、最初の1つに選ぶ対象としては向きません。確認する順番としては、業務を先に決めてから、その業務で使うデータだけを見に行くほうが早く進みます。全社のデータを俯瞰してから業務を探す進め方だと、着手の判断まで届きません。

判断軸③間違えたときに取り消せるか

3つ目は、誤った出力が出たときに取り消せるかどうかです。

顧客へ送信してしまう処理と、担当者が確認してから送る処理とでは、リスクの大きさが違います。取り消せる範囲であれば、精度が固まる前でも試せます。裏を返せば、精度が十分に上がるまで待つ必要がなくなるということです。

このメーカーが見積の自動送信を候補から外したのは、この軸によるものでした。金額の誤りがそのまま顧客へ届き、訂正の連絡と経緯の説明が必要になります。原材料の価格が動く商材である以上、古い単価が載る可能性は常に残ります。下書きの作成までなら、担当者の確認が挟まります。

取り消せるかどうかは、出力が誰に届くかで決まります。社内に留まるなら直せますが、顧客に届いた後では訂正の連絡が必要になります。最初の1つを選ぶ段階では、社内で完結する業務のほうが試す回数を増やせます。精度が上がるまで待つ判断より、間違えても戻せる業務から始める判断のほうが、着手は早くなります。

判断軸④人が承認する地点を置けるか

4つ目は、実行の前に人が確認する地点を設けられるかどうかです。

承認を挟む位置は、業務の重さに応じて変えます。すべてを承認制にすると確認の手間が減らず、導入した意味がなくなります。逆に、影響の大きい処理を自動で完結させると、事故の余地が残ります。どちらに寄せても運用は続きません。

このメーカーでは、問い合わせへの回答は担当者が確認してから送る設計にし、社内向けの資料検索は確認なしで完結させました。前者は顧客に届く内容であり、後者は社内で閉じるためです。同じ「質問に答える」という機能でも、届く相手によって扱いを分けています。

承認の位置は、運用しながら動かせるものです。最初は全件を確認し、内容が安定してきた範囲から外していく進め方もできます。業務選定の一般的な考え方は、ほか記事「Agentforceのユースケースの選び方は？どの業務から始めるかを決める5つの判断軸」で解説しています。

どの層のどの機能を使うかは、繰り返し・データ・取り消し可否・承認という4つの軸を業務に当てて決めます。

Salesforce AIで先に着手しやすい3つの業務

4つの判断軸を示しましたが、軸だけを渡されても自社の候補は挙がりません。実際にどの業務が当てはまりやすいのかを見ておくと、社内で候補を出す会話が早く進みます。営業とカスタマーサポートの業務のうち、4軸を満たしやすいものには共通の性質があります。判断が日常的に繰り返され、根拠がSalesforceの中にあり、出力を人が確認してから次へ進める構造を持っていることです。ここでは、先に着手しやすい3つの業務を解説していきます。

業務①商談の記録から次の行動を整理する

1つ目は、商談の記録を読んで次にすべきことを整理する業務です。

営業担当者は商談のたびに記録を残しますが、その記録を後から読み返して次の行動を決める作業は、後回しになりがちです。目の前の商談対応が優先されるため、過去の記録を棚卸しする時間は最後に残ります。自動車内装部品メーカーでも、月90件の商談に対して、記録は残っているのに次のアクションが設定されていない案件が一定数ありました。

この業務は4軸をすべて満たします。判断が月90件の規模で繰り返され、根拠になる記録はSales Cloud内で完結し、提案された行動は担当者がその場で却下でき、実行の前に承認を挟む地点も設けられます。4つのうち1つでも欠けていれば候補から外れますが、この業務は欠けている軸がありません。

もう1つの利点は、効果が担当者に見えやすいことです。次の行動が示されれば、その日の動きが変わります。使った実感が得られる業務から始めると、試験運用の期間中に意見が集まりやすくなります。

業務②見積や提案の下書きを作る

2つ目は、見積書や提案書の下書きを作る業務です。

このメーカーでは、見積の作成に1件あたり平均40分かかっていました。内訳の大半は、過去の類似案件を探して条件を確認する時間です。似た仕様の案件を思い出し、そのときの単価と納期を確かめる作業に時間が吸われていました。下書きが用意されれば、担当者は探す作業を飛ばして、確認と調整から始められます。

注意したいのは、下書きの作成と顧客への送信を分けて考える点です。作成までであれば、内容を見て直せます。送信まで自動化すると、誤った条件がそのまま届き、訂正の連絡と経緯の説明が必要になります。判断軸③に照らして、どこで区切るかを先に決めておく必要があります。

区切る位置を左右するのは、扱う商材の性質です。原材料の価格が動く商材であれば、過去の単価をそのまま引くと古い条件が載ります。自動化する範囲を広げる判断より、どこで人の目を入れるかを先に決める判断のほうが、運用は続きます。

業務③社内からの問い合わせに答える

3つ目は、社内の従業員からの質問に答える業務です。

顧客向けと比べたときの違いは、社内向けなら誤答の影響が社内に収まる点です。この性質があるため、精度が固まりきる前でも実際の質問で試せます。外部への説明や訂正が発生しないぶん、試す回数を増やせるという利点もあります。このメーカーの情報システム部3名にも、システムの操作方法に関する質問が日常的に届いていました。同じ内容の質問が繰り返し来ており、答えは既存の手順書に書かれています。

外部への影響を伴わない業務から始めると、運用にかかる手間を先に把握できるはずです。どのくらいの頻度で出力を確認する必要があるのか、資料をどの程度整えれば答えられるようになるのかが、実際の数字として分かります。この感覚を得てから顧客向けへ広げると、必要な体制を見積もれます。

最初の1つを選ぶ段階では、効果の大きさより確かめやすさを優先するほうが進みます。

最初に選ぶ業務は効果の大きさで決めません。判断の繰り返しがあり、根拠が社内にあり、間違えても戻せるという3点が揃っているかで決めます。

Salesforce AIを使い始める4ステップ

着手しやすい業務を挙げてきましたが、選んだ後の進め方も決めておく必要があります。手順が定まっていないと、設定が終わった時点で全社へ開放するという落とし穴②の状態に戻ります。自動車内装部品メーカーが実際に踏んだのは、対象を1つ選び、使う層を決め、範囲を絞って試し、測った結果で広げるという4つのステップでした。順番を入れ替えると、どこかで手戻りが発生するでしょう。とくにステップ①と②を逆にすると、機能のほうから使える業務を探すことになり、落とし穴①へ戻ります。ここでは、その4ステップを順に解説していきます。

ステップ①対象の業務を1つ選ぶ

最初にするのは、対象を1つに絞ることです。前章の4つの判断軸を候補に当てて、最も条件を満たすものを選びます。

このメーカーが選んだのは、商談の記録から次の行動を整理する業務でした。候補には問い合わせ対応もありましたが、対応履歴がメールに散らばっており、データを整える作業が先に必要だったためです。判断軸②で差が付いた形になります。どちらも判断の繰り返しはありましたが、根拠になるデータの状態が違いました。

複数を同時に進めない理由は、うまくいかなかったときに原因を切り分けられなくなるからです。2つの業務を並行させると、出力の質が低い原因がデータにあるのか、条件の設定にあるのか、業務の選び方にあるのかが判別できません。1つに絞ると、条件の調整も1か所で済みます。

絞る作業は、他の候補を捨てることを意味しません。順番を決めているだけです。残した候補は、最初の1つで得た知見を持ち込める状態で着手できます。

ステップ②使う層と機能を決める

次に、その業務にどの層の機能を使うかを決めます。ここで初めて機能の一覧を開きます。

商談の記録を読んで次の行動を提案するには、層②の生成の機能で足りるのか、層③の自律実行まで必要なのかを判断します。このメーカーは、まず担当者が画面を開いたときに提案が表示される形から始め、通知を出す設計は後回しにしました。理由は、提案の内容が業務に合っているかを先に確かめたかったためです。内容が定まらないまま通知を送ると、届いた通知が読まれないまま流されるようになります。

層を1つ上げる判断は、試験運用の途中でも下せます。層②で提案の質が安定してきた時点で、条件を満たした案件に通知を出す設計へ進めば、積み上げた調整をそのまま活かせます。

機能の一覧を開くのがこの段階になるのは、選ぶ対象がすでに絞られているからです。読む範囲も自然に限られるはずです。順番として、業務を決めてから機能を選ぶという流れを守ります。逆にすると、落とし穴①で触れた状態に戻ってしまうでしょう。守れているかどうかは、稟議の資料に対象の業務名が先に書かれているかで確かめられます。

ステップ③限られた範囲で試す

3つ目は、対象者を絞って実際に動かす段階です。

このメーカーは、営業25名のうち5名を対象に4週間試しました。5名は拠点も担当製品も分かれており、特定の使い方に偏らないよう選んでいます。全員を同じ拠点から選ぶと、その拠点特有の運用に合わせた調整になってしまうためです。期間中は週に一度、情報システム部の担当者が出力の内容を確認しました。前提③で見積もった週1時間ほどが、ここで実際に使われています。

小さく始める（スモールスタート）進め方の利点は、寄せられる意見の数が扱える範囲に収まることです。25名で始めれば意見も25通りに分かれ、どれから直すかの判断ができなくなります。5名であれば、意見の共通点も相違点も追えます。

期間を4週間と区切ったことにも意味があります。終わりを決めておかないと、試験運用のまま続いて評価の場が来ません。4週間という長さは、週次の確認を4回はさめる最短の期間として選んでいます。

ステップ④利用状況を見て範囲を広げる

最後は、測った結果を見て広げるかどうかを決める段階です。

広げる判断には、使われているという事実が要ります。このメーカーでは、5名のうち4名が週に3回以上使っている状態を確認してから、次の10名へ広げる計画を立てました。使っている人数と頻度の両方を見ているのは、1名が集中的に使っている状態と、複数名が習慣的に使っている状態を区別するためです。後者でなければ、人数を増やしても同じようには広がりません。

使われていない場合は、広げる前に理由を確かめます。出力の内容が合っていないのか、使い方が伝わっていないのか、そもそも業務の選び方が合っていなかったのかで、次の手は変わります。人数を増やしても、原因が残っていれば同じ結果になります。

以上が、Salesforce AIを使い始める4ステップでした。

着手の進め方は、業務を1つ選ぶ・使う層を決める・範囲を絞って試す・測って広げるという4ステップに整理できます。

Salesforce AIの効果を測る3つの指標

4ステップの最後で触れたとおり、広げる判断には測った結果が必要です。ただし、最初から時間短縮の効果を測ろうとすると、まだ使われていない段階で数字が出ずに判断を誤ります。見るべき指標は、立ち上げ期・定着期・拡大期で変わります。落とし穴③で挙げたとおり、測らないまま進めると改善も撤収も判断できません。指標を1つに固定しないほうがよいのは、時期によって知りたいことが変わるためです。ここでは、フェーズごとに1つずつ、計3つの指標を解説していきます。

指標①立ち上げ期は使った人数

立ち上げ期に見るのは、実際に使った人数です。

この時期は対象者が少なく、利用回数で見ると数字が安定しません。5名のうち1名が多く使えば、全体の平均は上がります。まず確かめるべきなのは、対象にした人が触ったかどうかです。自動車内装部品メーカーでは、5名のうち何名が使ったかを週単位で数えていました。1週目は2名、2週目は4名という形で推移を追っています。

触られていない場合、原因が精度にあるとは限りません。気づかれ方の問題であることも少なくありません。画面のどこに表示されるのか、どの操作をすれば出てくるのかが伝わっていない状態は、案内で解決します。実際にこのメーカーでも、1週目に使わなかった3名のうち2名は、表示される場所を知らなかっただけでした。

精度の改善に手を付ける前に、伝わっているかを確かめる順番が効きます。人数で見る期間は、対象にした全員が一度は触った状態になるまでと考えておくと区切りやすくなります。

指標②定着期は1人あたりの利用回数

定着期に入ったら、1人あたりの利用回数を見ます。使う人が固定されてきた段階では、回数のほうが実態を表すためです。

回数が伸びない場合、出力が業務の役に立っていない可能性があります。1度使ってみて期待した内容が返らなければ、次からは使いません。このメーカーでは、提案された次の行動のうち担当者が採用した割合もあわせて記録しました。使った回数と採用の割合を並べると、精度の問題か使い勝手の問題かを切り分けられます。回数が少なく採用の割合も低ければ内容の問題であり、採用の割合が高いのに回数が伸びないなら、使う場面が限られている可能性が高くなります。

2つの数字を並べる作業は手間に見えますが、直す対象を絞り込むための材料になります。回数は週単位で追うと、案内や調整を入れた影響も読み取りやすくなります。

利用が伸びない原因は、使った人数と1人あたりの回数を分けて見ると、気づかれ方の問題か中身の問題かを切り分けられます。

指標③拡大期は対象業務にかかる時間

拡大期に見るのは、対象にした業務にかかっている時間です。

導入前の時間を記録していなければ、比較できません。このメーカーが見積の作成時間を1件あたり平均40分と記録していたのは、この比較のためでした。着手の前に現状を数えておく作業が、後の判断材料になります。数え方も揃えておく必要があります。作成に着手してから完成までを測るのか、確認と修正まで含めるのかで、出てくる数字は変わります。

測る対象は、着手した業務に限定します。全社の残業時間のような広い指標に置き換えると、他の要因が混ざって判断できなくなります。時間が短くなっていない場合でも、確認の手間が増えただけという状態か、対象の業務選定が合っていなかったのかで打つ手は変わります。前者であれば承認を挟む位置を見直し、後者であれば対象の業務を選び直します。どちらにあたるかは、担当者に作業の内訳を聞けば判別できるはずです。測った数字が動かないこと自体は失敗ではありません。どこを直すかを決める材料になります。

Salesforce AIが向いている企業の3つの条件

ここまで進め方と測り方を解説してきましたが、どの企業でも同じ効果が出るわけではありません。前提の整い方によっては、着手の順番を変えたほうがよい場合もあります。判断の材料になるのは、業務のなかに繰り返しがあるか、記録が残っているか、設定を担う人がいるかの3点です。3つとも、製品を選ぶ前に自社の側だけで確認できる項目です。見積もりを取る前の段階でも、ある程度の見当がつきます。ここでは、効果が出やすい企業に共通する3つの条件を整理していきます。

条件①同じ判断を繰り返している業務がある

1つ目は、同じ種類の判断が業務のなかで繰り返されていることです。

判断軸①と重なりますが、企業単位で見ると分かりやすくなります。取引の件数が多く、担当者が似た判断を日々行っている企業ほど、基準を整理した効果が広く及びます。基準を言語化する作業には相応の時間がかかるため、その手間を何回分の判断で回収できるかという見方になります。

自動車内装部品メーカーの場合、月90件の商談と月200件の問い合わせがありました。この件数であれば、基準を1度整理する手間に対して適用される回数が十分にあります。仮に商談が月10件であれば、同じ整理をしても回収には時間がかかります。

数えるのは1か月分で足ります。年間の合計を出さなくても、候補の順位は付けられます。件数の多さは、企業の規模だけで決まりません。取引の単価が低く回数が多い事業か、単価が高く回数が少ない事業かによっても変わります。自社の事業がどちらに近いかを見ておくと、判断しやすくなります。

条件②Salesforceに記録が残っている

2つ目は、判断の材料になる記録がSalesforceに入っていることです。

導入していても、入力が担当者任せになっていて実態が反映されていない場合があります。商談の記録が「訪問」の一言で終わっている状態と、先方の反応や検討の状況まで書かれている状態では、読ませたときに返ってくる内容が変わります。前者では、読ませても正確な判断は返りません。

このメーカーは7年間の利用のなかで、商談の記録を残す運用が定着していました。AI機能は使っていなかったものの、層①にあたるデータが積み上がっていたことが、着手を後押しした要因になっています。7年分の記録があるという事実が、判断の根拠として機能しました。

利用年数より、その間に記録を残す習慣が続いていたかどうかが効きます。確認するなら、直近3か月の商談の記録を無作為に10件ほど読んでみてください。導入して間もない企業でも、入力の運用が整っていれば同じ状態に近づけます。

条件③設定を担当できる人がいる

3つ目は、設定と調整を担う人を置けることです。

前提③と同じ観点ですが、条件として見ると判断しやすくなります。動かし始めてからも、出力を確認して基準を直す作業が続きます。この作業を担う人がいなければ、精度は上がりません。初期の設定が終わった時点で担当が離れると、そこで調整が止まります。

社内に置けない場合の選択肢は、外部の支援を組み合わせることです。自社で構築する方針であれば、設計レビュー・アドバイザリーだけを外部に頼み、実装と運用は社内で持つという分け方もできます。すべてを外部に任せる形と、すべてを社内で持つ形の中間に、いくつかの組み合わせがあります。

効果が出るかどうかを分けるのは製品の性能ではありません。繰り返しの多さ・記録の有無・担当者の3つが揃っているかです。

Salesforce AIの効果は製品の性能で決まりません。判断の繰り返し・記録の蓄積・設定を担う人という3つの条件が揃っているかで決まります。

Salesforce AIを急がなくてよい3つのケース

向いている条件を挙げましたが、当てはまらない場合に無理に進める必要はありません。先に整えるべきことがある状態で着手すると、効果が出ないまま評価だけが下がります。一度「使えなかった」という評価が付くと、条件が整った後で再び提案するときの障害になります。急がない判断は、諦める判断とは違います。着手の時期をずらし、その間に前提を整えるという選び方です。3つのケースはいずれも、整え直せば着手できる状態にあります。ここでは、着手を急がなくてよい3つのケースを解説していきます。

ケース①Salesforceの入力が定着していない

1つ目は、そもそも記録を残す運用が定着していないケースです。

商談の記録が担当者によって粗密に分かれている状態では、読ませても判断の精度は上がりません。詳しく書く担当者の案件では妥当な提案が返り、一言で済ませる担当者の案件では的外れな提案が返ります。この差が担当者ごとの評価の差につながり、「あの機能は当たらない」という印象だけが残ります。

この場合は、入力の運用を整えるほうが先になります。何を書くのかを決め、書かれているかを確認する仕組みを置く作業です。その作業はAIを入れるかどうかに関係なく必要なものであり、後回しにしても別の場面で必要になります。

見分ける方法としては、直近の商談の記録を何件か読んでみることです。書かれている量に大きな差があれば、その状態にあたります。整える対象は、書く項目を決めることと、書かれているかを確認する場面を置くことの2つです。順番を入れ替えると、記録の粗密という別の原因が、AIの評価として跳ね返ります。

ケース②対象にしたい業務の判断基準が人によって違う

2つ目は、任せたい業務の判断基準が担当者ごとに違うケースです。

基準が揃っていなければ、何を正解として学ばせるかが決まりません。この状態でAIの出力を評価すると、人によって「合っている」「合っていない」の判断が分かれます。試験運用で意見を集めても、どちらの意見に合わせるかを決められず、調整の方向が定まりません。

まず基準を言語化する作業が先になります。どういう条件のときに優先度を上げるのか、どの段階で上長へ相談するのかを、言葉にして揃える作業です。この作業自体は、属人化を解消する取り組みとしても意味があります。経験の長い担当者の判断を書き出すと、教育の材料にもなります。

違いが出ているかどうかは、同じ案件を複数の担当者に見せて、優先度と次の行動を答えてもらうと分かります。答えが割れた項目が、そのまま揃えるべき基準の候補になります。判断が分かれる場面は限られており、書き出してみると数は多くありません。基準が揃ってから着手すると、評価の物差しも同時に手に入ります。

ケース③契約の更新が近く構成が変わる見込みがある

3つ目は、契約の更新時期が近く、エディションや構成が変わる可能性があるケースです。

前提①で確認した契約範囲が変われば、使える機能も変わります。設定を作り込んだ後で構成が変わると、やり直しになる部分が出てきます。試験運用で得た調整の内容が、そのまま引き継げるとは限りません。

更新の内容が決まってから着手するほうが、手戻りは少なくなります。待っている期間を無駄にしないなら、条件①②で挙げた前提を整える作業に充てられます。入力の運用を見直し、判断基準を言語化しておけば、構成が決まった時点ですぐ着手できます。

更新の時期が半年以上先であれば、待つ理由にはなりません。数か月以内に構成が動く見込みがある場合に限った話です。待つ判断も、進める判断と同じくらい具体的な理由にもとづいて選びます。

入力が定着していない・判断基準が揃っていない・契約構成が変わる見込みがあるという3つのケースでは、着手を急がず前提を整えるほうが結果的に早く進みます。

【一問一答】Salesforce AIに関するよくある質問

ここまで、層の整理から着手の進め方までを解説してきました。実際に検討を始めると、費用や資格、データの扱いなど、判断の手前で確認しておきたい点が出てきます。稟議を書く場面で問われやすい内容です。社内の関係者から同じ質問が出ることも多いため、答えを用意しておくと説明の手間が減ります。とくに費用とデータの扱いは、役員会や情報システム部から必ず問われる項目です。最後に、Salesforce AIについてよく寄せられる質問に答えていきます。

質問①Salesforce AIは追加の費用がかかるのか

契約しているエディションと使う機能によって変わります。標準で含まれる機能と、追加の契約が必要な機能が分かれているためです。とくに層③にあたる自律実行の機能は、実行の回数に応じた費用が発生する仕組みがあります。料金の考え方は、ほか記事「【2026年最新】Agentforce料金・ライセンス完全ガイド」で整理しています。

質問②Salesforce AIとAgentforceは何が違うのか

Salesforce AIは3つの層をまとめた総称で、Agentforceはそのうち自律実行を担う層の名前です。並列の選択肢ではありません。包含の関係にあります。「Salesforce AIを導入する」という言い方では何を指すかが定まらないため、社内の資料では層か機能の名前まで下ろして書くほうが伝わります。

質問③Salesforce AIを使うのに資格は必要か

利用にあたって資格は要りません。ただし設定を担当する場合、製品の構成を体系的に理解しているほうが判断は速くなります。関連する認定資格の内容は、ほか記事「【2026年最新】Agentforceスペシャリスト資格の試験概要や勉強法」で解説しています。

質問④Salesforce AIは日本語に対応しているのか

日本語での利用に対応しています。ただし、参照するデータが日本語で整理されていることと、社内で使われている用語の揺れを吸収できるかは別の問題です。同じ製品を指す社内の略称が複数ある場合、そのままでは答えられないことがあります。試験運用のなかで、答えられなかった内容を見ながら調整していく必要があります。

質問⑤Salesforce AIに社内データを渡して問題ないのか

外部の言語モデルとやり取りするデータには、Trust Layerと呼ばれる保護の仕組みが介在します。ただし、どこまでを自動で実行させ、どこで人が確認するかは自社で設計する必要があります。仕組みがあることと、任せる範囲を決めることは別の作業です。

Salesforce AIは層の総称であり、どの層を使うかは業務から決める

Salesforce AIとは、データを集める層・予測と生成を担う層・自律的に実行する層という3つの層の総称です。本記事では、名前が整理できない状況から、層と呼び名の対応、できること、着手前に確認する前提、業務から選ぶ4つの判断軸、進め方の4ステップ、測る指標までを、一連の流れとして解説してきました。

本記事で例として挙げた自動車内装部品メーカーの場合も、変わったのは製品の選び方でした。従業員450名・営業25名で7年間Sales Cloudを使いながら、AI機能の利用者は当初1人もいません。機能の一覧から選ぼうとした2週間は候補が絞れず、業務の側から4つの判断軸を当て直したことで、月90件の商談に関する1つの業務へ絞り込めました。営業5名・4週間の試験運用を経て、次の10名へ広げる判断に進んでいます。検討にかけた期間は2か月でした。

名前を覚えることから始めると、いつまでも整理は終わりません。自社のどの業務に同じ判断の繰り返しがあるかを数えるところから始めてみてはいかがでしょうか。

なお、どの業務から任せるかを業務設計から一緒に整理し、定着まで伴走してほしい場合は、Agentforce導入・定着支援サービスにお気軽にご相談ください。1ユースケース×3ヶ月のスモールスタートから対応しています。