【2026年8月時点】Agentforceとは？仕組み・料金・導入判断まで

Agentforceとは、Salesforceが提供する、CRM（顧客関係管理）に蓄積したデータを根拠にAIエージェントが自ら手順を決めて業務を実行する基盤のことです。質問に答えて終わる生成AIと違い、社内システムを更新するところまでを、あらかじめ許された範囲の中で担います。本記事では、定義と誕生の背景から、仕組み、メリットとデメリット、向き不向き、料金の考え方、そして導入判断の進め方までを一本で整理します。

Agentforceという名前は聞いたことがあっても、社内で説明を求められたときに公式サイトの言葉をそのまま借りるしかなかった、という担当者の方は少なくないのではないでしょうか。AIエージェントという言葉自体が新しく、チャットボットとも生成AIとも違うと説明されても、何がどう違うのかまでは自分の言葉になりにくいところがあります。

なお、Agentforceは製品名も提供範囲も更新が続いている領域です。本記事は2026年8月時点の情報にもとづいて整理しています。

この記事を書いた人

本田正憲

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

Agentforceとは？

Agentforceとは、Salesforceが提供する、CRMに蓄積したデータを根拠にAIエージェントが自ら手順を決めて業務を実行する基盤のことです。この言葉は、1つのAI機能を指して使われることもあれば、複数のエージェントを載せる基盤の名前として使われることもあり、定義があいまいなまま検討を始めてしまうと、社内で説明するたびに話が噛み合わなくなってしまいます。また、使い始めるにはSalesforceの上位エディションの契約と、回答の根拠になるデータがCRM側に入っていることが前提になるため、ゼロから新しいシステムを入れる場合とは検討の出発点が異なります。

なお、本記事は個々の機能を並べる役割を持たせていません。そこで、機能の一覧と2026年8月時点の提供状況までまとめたのが「Agentforceの機能」です。ここでは、いま挙げた定義を3つの要素に分けて整理していきます。

要素①CRMのデータを根拠にすること

1つ目は「CRMのデータを根拠にすること」です。Agentforceが返す回答は、汎用のAIが学習した一般的な知識から組み立てられるものではありません。自社のSalesforceに入っている取引先・商談・ケース・ナレッジ記事といったデータを参照して作られます。

この要素を最初に置くのは、根拠にできるデータの範囲が、そのままエージェントに任せられる業務の範囲になるためです。CRMに入っていない情報は、どれだけ指示文を工夫しても回答の根拠にはなりません。

参照先はレコードだけではありません。ナレッジ記事、PDF、アップロードしたファイル、Web検索の結果などを検索インデックスに載せておくと、質問に近い箇所が取り出され、回答の材料として使われます。この、検索して取り出したデータを根拠に文章を組み立てる仕組みをAgentforce RAGと呼びます。索引に何を載せると根拠として使えるのか、逆にどのような資料が載らないのかまで詳しくまとめていますので、ぜひ参考にしてみてください。

導入の検討で最初に確かめるのは、任せたい業務で使う情報がSalesforceのどのオブジェクトに入っているかです。項目が用意されていても空欄のまま運用されているなら、その業務は最初の対象から外します。

要素②実行する手順を自ら組み立てること

2つ目の要素は「実行する手順を自ら組み立てること」です。担当者が「この取引先の直近の商談状況をまとめて、フォローのメール文面を作ってほしい」と依頼したとき、どのデータを見て、どの順番で処理するのかを、担当者が指定しなくてもエージェントの側で決めます。

ここで押さえておきたいのは、Agentforceが1つのAIを指す言葉ではないという点です。Agentforceは複数のエージェントを載せる基盤であり、そこに置けるエージェントには、Salesforceがあらかじめ用意しているものと、自社の業務に合わせて作るものの2系統があります。営業やカスタマーサポートといった代表的な業務については、最初から使えるエージェントが用意されています。

あらかじめ用意されたエージェントをそのまま使う場合でも、参照させるデータと実行を許可する操作は自社で設定します。そのうえで、想定していない業務を任せたい場合に、自社でエージェントを作る選択肢が出てきます。

手順を自ら組み立てるという性質は、担当者から見ると「指示の粒度を細かくしなくてよい」という利点になります。一方で、どこまでを任せてよいのかを人が決めておかないと、想定と違う手順で処理が進んでしまいます。範囲を決めるときの目安は、担当者が結果を見て誤りに気づける業務かどうかです。気づけない業務は、手順の組み立てを任せる対象から外しておきます。

要素③業務の完了まで担うこと

3つ目は「業務の完了まで担うこと」です。回答の文章を返したところで処理は終わりません。ケースのステータスを更新する、商談に活動履歴を登録する、注文の状況を照会して返答するといった操作までを、許可された範囲の中で実行します。

生成AIとの違いが最も分かりやすく出るのが、この要素です。文章を作るところまでであれば、担当者がその文章を確認し、システムへ転記する作業が残ります。Agentforceの場合は、転記までを含めて処理の対象に入れられます。

実際に、問い合わせ対応の一次回答を任せるチャットボットとの違いは、この点に集約されます。想定した質問に決められた回答を返すだけでなく、顧客のレコードを確認したうえで回答し、対応の記録を残すところまでを1つの流れとして扱えるためです。アーキテクチャや人へ引き継ぐ条件の決め方まで詳しくまとめていますので、あわせて参考にしてみてください。

以上の3つが揃っている状態を、Agentforceと呼びます。逆にいえば、根拠になるデータがない、手順を人が全部指定している、実行を許可していない、というどれか1つでも欠けている場合、Agentforceを入れても検索窓が1つ増えるだけの状態になってしまいます。

Agentforce誕生の背景と転換点

前章では、Agentforceの定義を3つの要素に分けて整理しました。ここで出てくるのが、なぜSalesforceがこの製品を出すに至ったのかという疑問です。Agentforceは突然登場した製品ではありません。Salesforceが2016年から積み上げてきたAI製品の系譜の先にあります。参考までに事業の規模を挙げておくと、Salesforceが2025年12月に発表した四半期報告の時点で、AgentforceとData 360を合わせた年間経常収益は約14億ドル、前年同期比で114%の増加と開示されています。※参考記事はこちら。そこでここでは、Agentforceに至るまでの4つの転換点を、発表された事実で追っていきます。

転換点①予測にとどまった2016年のEinstein

出発点は、2016年9月19日に発表されたSalesforce Einsteinです。予測分析と機械学習によって、Salesforce上に蓄積されたデータから予測を返す位置づけの機能でした。商談の受注確度を点数で示す、次に取るべき行動を提案するといった使われ方が中心です。

当時のリリースでMarc Benioff氏は「世界で最もスマートなCRMを提供する」と述べています。CRMに入力されたデータを、担当者の判断を助ける形で返すという発想が、この時点で製品として形になりました。

ただし、Einsteinができたのは予測を返すところまででした。受注確度が低いと示すことはできても、確度を上げるためのメール文面を作ることはできません。何をすべきかの判断材料は増えても、その先の作業は担当者の手元に残ります。受注確度の点数を見た担当者が、誰にいつ連絡するかを決め、文面を考え、送信するところまでは従来どおりでした。

つまり、2016年の段階でSalesforceが持っていたのは、データから数字を返す機能でした。数字を受け取った担当者が何をするかは、担当者に委ねられていたのです。

転換点②文章の生成が加わった2023年のEinstein GPT

数字だけを返す状態が変わったのが、2023年3月7日に発表されたEinstein GPTです。CRM向けの生成AIとして、営業メールの下書き、サービスの応答文、ナレッジ記事、マーケティング用のコンテンツを生成する機能が加わりました。

予測を返すだけだったEinsteinに、文章を作る機能が加わったことになります。受注確度が低いと示すだけでなく、フォローのメール文面まで用意できるようになりました。

一方で、Einstein GPTが作るのは文章です。作られたメールを送るかどうか、ケースの記録を更新するかどうかは、担当者が判断して操作する必要がありました。生成の対象が広がっても、業務が完了するまでの間には、担当者の手作業が挟まったままです。下書きの精度が上がるほど、内容を確認して送信するだけの作業が増えるという状態でもありました。

このように、2023年の時点でSalesforceのAIは、判断材料と下書きを用意するところまでを担う存在でした。作られたものを業務システムへ反映させる工程は、まだAIの担当範囲に入っていません。

転換点③人の問いかけを待った対話型アシスタント

次の段階として、2024年4月25日にEinstein Copilotの一般提供が発表されました。CRM向けの会話型AIアシスタントとして、担当者の問いかけに対してCRMのデータを踏まえた回答を返し、Copilot Actionsによって一連の作業をつなぐ位置づけです。

この段階で、担当者が画面を切り替えてデータを探す手間はかなり減りました。聞けば答える相手がCRMの中にいる状態になったためです。なお、Einstein Copilotは現在Agentforceのエージェントとして位置づけ直され、Copilot BuilderもAgent Builderへ名称が変わっています。

ただし、対話型アシスタントは担当者が問いかけるまで動きません。担当者が「聞こう」と思い立たなければ、CRMの中にどれだけ有用なデータが入っていても使われないままです。

Einsteinからの流れを踏まえて、両者の関係をもう少し踏み込んで確かめたい場合もあるでしょう。ここで世代ごとの内部構造まで扱うと基礎情報の整理から離れてしまうため、本記事では系譜の事実だけを追います。そこで、推論の仕組みの差まで解説したのが「Einsteinとの違い」です。

転換点④実行まで任せる設計に変えた2024年

そして2024年9月12日に発表されたのがAgentforceです。発表時のリリースには、人の要求に依存する従来のコパイロットやチャットボットとは異なり、自律的に動作し、必要なデータを取得し、タスクの実行計画を組み立て、人の介在なしに実行する、と明記されています。一般提供が始まったのは2024年10月です。※参考記事はこちら。

問いかけを待つ設計から、手順を組み立てて実行する設計へ変わった点が、それまでの3つの段階との違いになります。

その後も範囲は広がっています。2025年10月13日にはAgentforce 360が発表され、日本市場では2025年11月20日から提供が始まりました。※参考記事はこちら。世代ごとに何が追加されてきたのかを一覧で整理していますので、提供状況まで確かめたい方は参考にしてみてください。

4つの転換点を並べると、Agentforceが解決しようとしたものが見えてきます。担当者の側に残り続けていた「判断材料を受け取ってから業務が終わるまでの作業」を、システムの側へ移すという発想です。この発想が自社の業務に当てはまるかどうかで、導入を検討すべきかを判断できます。

AIエージェント時代におけるAgentforceの役割

ここまでは、Agentforceが何であるかと、どのような系譜で登場したのかを整理してきました。AIエージェントの時代にAgentforceが担うのは、担当者が操作する道具という位置づけを超えて、依頼を受けてから業務が終わるまでを引き受ける役割です。とはいえ、社内で説明する場面で最初に聞かれるのは「うちのチャットボットと何が違うのか」という質問ではないでしょうか。今回は、従業員180名の産業向け部材商社を例に考えていきます。この会社では営業18名とカスタマーサポート4名が在籍し、Salesforceは5年前から使っていて商談と顧客の情報は入っているものの、製品仕様の問い合わせだけはベテラン営業2名への電話とチャットに集中している状態でした。情報システムの担当者が経営会議でAgentforceの説明を求められた際、チャットボットとの違いを聞かれて答えに詰まってしまったのです。そこでここでは、従来のAIとの位置づけの差を3つの特徴から整理していきます。

この3つは、終わり方も違います。チャットボットはシナリオの分岐が尽きた時点で終わり、生成AIは文章を返した時点で終わります。AIエージェントは、依頼された業務が完了した時点で終わる設計になっています。

特徴①人の指示を待たずに手順を組み立てる

1つ目は「人の指示を待たずに手順を組み立てる」ことです。担当者が渡すのは依頼の内容だけで、どのデータを見るか、どの操作を何番目に行うかは、エージェントの側で決めます。

チャットボットとの差が最も大きく出るのがこの点です。チャットボットは、設計した人があらかじめ書いた分岐をたどるだけなので、想定していない聞かれ方をされると回答できません。先ほどの部材商社でも、過去にWebサイトへ設置した問い合わせボットが、質問の言い回しが少し違うだけで「該当する回答が見つかりません」と返してしまい、結局は電話が増えていました。

Agentforceの場合は、依頼の内容から必要な処理を組み立てるため、聞かれ方が変わっても対応できる範囲が広がります。この、指示を待たずに自律的に動く仕組みを支えているのが推論エンジンです。どのような仕組みで手順が決まるのかを詳しくまとめていますので、内部の動きまで確かめたい方はぜひ参考にしてみてください。

ただし、手順を組み立てられることと、正しい手順を選ぶことは別です。何を根拠にしてよいか、どこまで実行してよいかを人が設定していない状態では、組み立ての自由度がそのまま想定外の動作につながります。

特徴②社内システムの更新まで実行する

2つ目の特徴は、回答を返すだけでなく社内システムの更新まで実行することです。ケースのステータスを変更する、商談に活動履歴を残す、在庫や納期を照会して回答に含めるといった処理を、許可された操作の範囲で行います。

ここで押さえておきたいのが、担当者がAgentforceに触れる場所です。担当者が専用の画面を新しく開く必要はありません。Salesforceの画面、Slack、自社サイトに設置したチャット、そして電話といった、担当者や顧客がすでに使っている面から呼び出す形になります。使う人の側から見ると、すでに開いている画面に相談先が1つ増えるだけです。

実際に更新できる範囲は、設定した業務を実行するアクションの内容で決まります。標準で用意されているものに加えて、既存のフローや外部システムの呼び出しを組み込むこともできます。どのような操作が用意されているのかを一覧で整理していますので、自社の業務に当てはめて考えたい方は参考にしてみてください。

逆にいえば、更新を伴わない調べ物だけが目的なら、Agentforceでなくても足りる場面はあると考えます。

特徴③許された範囲の外には出られない

3つ目は「許された範囲の外には出られない」ことです。自律的に動くと聞くと、何をするか分からないという不安を持たれることがありますが、参照できるデータも実行できる操作も、設定した範囲の中に限定されます。

ここで最も重要なのは、その範囲を人が決めるという点です。製品側が自動で判断してくれる部分ではありません。誰に何を許すのかを、権限設定とガードレールで先に決めます。この設計を後回しにすると、範囲が広いまま動き始めてしまうため、順番としては業務を任せる前に決めておく必要があります。

先ほどの部材商社の場合、経営会議で最初に出た懸念も「顧客の与信情報まで見て回答してしまうのではないか」というものでした。実際には、参照できるオブジェクトと項目を設定で絞れるため、この懸念は設計で解消できます。ただし、絞る作業を誰がいつ行うのかを決めないまま導入を進めると、懸念が懸念のまま残り続けます。

情報システム部門から見た論点は、この範囲設定をどこまで厳密に行うかに集約されます。想定されるセキュリティリスクと、それぞれに対して何を設定で防ぐのかを詳しくまとめていますので、社内の承認を取る立場の方はぜひ参考にしてみてください。

Agentforceの仕組み

前章では、Agentforceが従来のAIとどう違うのかを3つの特徴から整理しました。ここまで読むと、では実際にどう動いているのかという疑問が出てきます。Agentforceの仕組みは、1つの依頼を受け取ってから回答や処理を返すまでの流れとして見ると、どの段階で人が設計に関わるのかまで把握できます。ここで扱うのは処理の順番であり、各段階の内部でどのような技術が使われているかには立ち入りません。そこでここでは、Agentforceの仕組みを1つの回答が返るまでの4つの段階に分けて整理していきます。

段階①依頼の内容から扱う領域を振り分ける

最初に行われるのが、受け取った依頼をどの業務領域で扱うのかという振り分けです。1つのエージェントの中には、製品仕様の照会、納期の確認、返品の受付といった業務単位のまとまりが登録されており、依頼の内容に応じてどれを使うかが選ばれます。この振り分けを担うのがAgent Routerです。

このまとまりはサブエージェントと呼ばれ、それぞれに「どういう依頼のときに使うか」の説明文と、使ってよいデータ、実行してよい操作が紐づいています。振り分けの精度は、この説明文の書き方でかなり変わります。

たとえば、製品仕様の照会と納期の確認を1つのまとまりに詰め込んでしまうと、どちらの依頼が来ても同じ処理が走り、必要のないデータまで参照しにいきます。業務の単位で分けておくほうが、結果として回答が安定します。分ける単位に迷ったときは、参照するデータと許可する操作が違うかどうかを基準にすると決めやすくなります。

この段階の設計は、画面上でのエージェントの設定作業にあたります。まとまりをどう分け、説明文に何を書くのかを画面で確かめながら進められますので、実際の作り方を知りたい方は参考にしてみてください。

段階②根拠になるデータを索引から取り出す

扱う領域が決まったら、次は回答の根拠になるデータを取り出す段階に入ります。ナレッジ記事やPDF、アップロードしたファイルは、あらかじめ検索インデックスの形に変換されており、依頼の内容に近い箇所が抜き出されて回答の材料になります。

ここで押さえておきたいのは、索引に載っていない資料は、この段階で候補にすら上がらないという点です。社内の共有フォルダにある最新の仕様書も、索引の対象として登録していなければ参照されません。回答が的外れになる原因の多くは、この段階でつまずいています。

また、取り出せたとしても、同じ内容の古い版と新しい版が両方索引に載っていると、どちらが現行版なのかをエージェントは判断できません。文書の側に版を見分ける情報が入っているかどうかが、回答の正確さを左右します。

この、検索して取り出したデータを根拠に回答を組み立てる方式をRAG（検索拡張生成）と呼びます。仕組みの全体像に加えて、精度が上がらないときにどこを見直すのかまでまとめています。仕組みを押さえたうえで自社のナレッジ整備に進みたい方は、ぜひ読んでみてください。

段階③推論エンジンが実行手順を組み立てる

根拠になるデータが揃うと、次にそのデータを踏まえて実行の手順が組み立てられます。ここを担うのがAtlas推論エンジン（Atlas Reasoning Engine）です。依頼の内容と取り出した情報から、どの操作をどの順番で行うかを判断します。推論の内部でどのような手法が使われているのかまで詳しく整理していますので、技術的な背景まで確かめたい方は参考にしてみてください。

この段階の特性として、同じ依頼を渡しても、文面の細部までは毎回同じにはなりません。生成の性質上、表現の揺れは残ります。

そこで設計時に人が決めるのは、正解の文面ではありません。通ってはいけない手順と、必ず通す手順を先に置きます。たとえば、金額を回答する前に必ず現在の見積レコードを参照する、といった制約を先に置いておきます。逆に、挨拶文の言い回しのように、表現が変わっても業務に影響しない部分までは指定しません。

このように、推論エンジンが手順を組み立てる以上、出力を1文字単位で固定することはできません。固定すべきところと任せてよいところを業務側で分けておくことが、この段階と付き合う方法になります。

段階④許可されたアクションだけを実行する

最後が、組み立てた手順にしたがって操作を実行する段階です。ここで実行できるのは、そのエージェントに対して許可されたアクションだけです。レコードの更新、メールの下書き作成、外部システムへの照会などが、事前に登録された単位で呼び出されます。

許可されていない操作は、推論の結果として必要だと判断されても実行されません。この点が、自律的に動く設計でありながら範囲を限定できる理由です。

なお、Salesforceの外にあるシステムを呼び出す場合は、どの方式でつなぐかという別の検討が必要になります。基幹システムの在庫情報や、外部の見積システムを参照させたい場合が該当します。ここは接続の設計が1つの独立したテーマになるため、本記事では扱いません。そこで、方式ごとの違いと選び方まで解説したのが「外部システムとの接続方式」です。

以上が、1つの依頼を受け取ってから処理が終わるまでの4段階でした。振り分け・検索・推論・実行のどこでつまずいているかが分かると、指示文を直すべきなのか、索引を整えるべきなのかを切り分けられるようになります。

Agentforceの主要機能

前章では、Agentforceが1つの依頼をどう処理するのかを4つの段階に分けて整理しました。この4段階を実際に動かしているのが、製品として用意されている機能群です。Agentforceの機能は、担当者や顧客が話しかける対話の面、回答の根拠として参照するデータ、業務を実行するアクション、そして動きを監視して検証する仕組みという4つの層に分かれています。さらに、そこへ載せるエージェント自体にも、Salesforceが標準で用意しているものと自社で作るものの2系統があります。

層と系統の組み合わせで捉えると、機能名を一つずつ覚えなくても、どの機能がどの役割を担っているのかを説明できるようになります。個々の機能の内容と、2026年8月時点での提供状況までまとめたのが「Agentforceの主要機能」です。全体像を押さえたうえで自社に必要な機能を選びたい方は、ぜひ読んでみてください。

Agentforceでできること・活用事例

Agentforceで何ができるのかという質問に、機能の名前を並べて答えると、かえって伝わりにくくなります。任せられる業務の型で答えるほうが、自社に当てはめて考えやすくなるためです。Agentforceに任せられる業務は、社内外のデータから必要な情報を調べる、依頼にもとづいて文面の下書きを作る、問い合わせに対して一次回答を返す、対応の結果をレコードとして記録する、という4つの型に整理できます。どの型も、担当者が今すでに行っている作業であり、まったく新しい業務が生まれるわけではありません。

一方で、実際にどの業務から任せたのかという事例は、業種や体制によって前提が大きく変わるため、本記事では扱いません。そこで、実際の活用場面を業種別に整理し、成果が出た組織の共通点まで解説したのが「Agentforce活用事例」です。

Agentforceを導入するメリット

ここまでは、Agentforceが何をする製品で、どのような業務を任せられるのかを整理してきました。そのうえで気になるのは、導入すると自社の現場で何が変わるのかという点ではないでしょうか。ここでいうメリットは、削減できる時間の割合として測るより、担当者が何をしなくてよくなるのかという状態の変化として捉えるほうが正確です。そこでここでは、Agentforceを導入するメリットを、現場で起きる変化として3つに分けて整理していきます。

メリット①情報を探す時間が要らなくなる

1つ目は「情報を探す時間が要らなくなる」ことです。顧客から質問を受けた担当者が、過去の対応履歴を検索し、仕様書のファイルを開き、在庫の画面を確認するという一連の作業を、依頼を1回渡すだけで済ませられるようになります。

そもそも、なぜ探す作業に時間がかかるのかという話ですが、必要な情報が1か所にまとまっていないからです。商談の情報はSalesforce、製品仕様は共有フォルダ、在庫は基幹システムというように置き場所が分かれており、担当者は質問を受けるたびに、その3か所を順番に開いています。

Agentforceを使う場合、担当者が行うのは質問を投げる操作だけです。どの情報源を見るかはエージェントの側で判断するため、担当者は探す作業から離れられます。

この変化が最も分かりやすく出るのが、担当者が普段から使っている会話の場からの呼び出しです。Slackから直接エージェントへ質問できる形にすると、画面を切り替える操作すら不要になります。導入の手順や、どの範囲まで扱えるのかを詳しくまとめていますので、ぜひ参考にしてみてください。

メリット②一次回答の品質が担当者で揺れない

探す時間の次に変わるのが、回答の品質が担当者によって揺れなくなる点です。同じ質問に対して、経験の長い担当者は正確に答え、着任したばかりの担当者は答えられないという状態が、Agentforceを挟むことで揃います。

先ほどの部材商社では、製品仕様の問い合わせが1日あたり10件前後発生しており、そのほとんどがベテラン営業2名に集中していました。若手の営業が顧客から仕様を聞かれても、自分では判断できず、社内チャットでベテランに確認してから折り返すという流れが常態化していたのです。

この2名が不在の日は、折り返しが翌日になることもありました。顧客から見ると、同じ会社に問い合わせても、担当者によって返答の速さと正確さが変わる状態です。

一次回答をエージェントに任せると、若手が自分で確認して回答できる範囲が広がります。ただし、すべての質問を任せきることはできないため、どのような条件で人へ引き継ぐのかを先に決めておく必要があります。このエスカレーション設計の考え方を詳しくまとめていますので、一次対応を任せる想定の方は参考にしてみてください。

メリット③夜間や休日でも処理が止まらない

3つ目は「夜間や休日でも処理が止まらない」ことです。担当者の勤務時間に関係なく、問い合わせの受付と一次回答、そして記録の作成までが動き続けます。

海外の顧客や、営業時間の異なる取引先を抱えている場合、この違いは大きく効いてきます。翌営業日に担当者が出社してから対応を始めるのと、受付と一次回答が済んだ状態で出社するのとでは、担当者が着手する時点がまるごと変わるためです。時差のある地域から夜間に届いた問い合わせでも、受付の記録と一次回答が残っていれば、翌朝は内容の確認から始められます。

もっとも、24時間動くこと自体が成果になるわけではありません。夜間に受け付けた内容が翌朝そのまま人の対応待ちになるなら、受付時刻が変わっただけになってしまいます。どの種類の問い合わせなら夜間のうちに完了と扱ってよいのかを、あらかじめ決めておく必要があります。

実際に成果として説明できている組織は、夜間に受け付けた依頼のうち、どこまでを完了扱いにするかを先に決めています。そうした成果が出た組織の特徴を業種別の活用場面とあわせて整理していますので、投資対効果を社内で説明する立場の方はぜひ参考にしてみてください。

Agentforceを導入するデメリットと注意点

前章では、Agentforceを導入すると現場で何が変わるのかを3つ挙げました。ただし、良くなる面だけを見て判断すると、導入したあとで想定と違う結果になってしまいます。Agentforceには、製品の性質上どうしても残る制約と、運用を始めてから顕在化する問題があります。ピラーとなる本記事では、検討の早い段階で知っておくべき不利益を先に示しておきます。そこでここでは、Agentforceを導入するデメリットと注意点を3つに分けて整理します。

注意点①索引に載らない資料は根拠にできない

まず知っておきたいのが、検索インデックスに載せていない資料は、回答の根拠として使えないという制約です。社内に正しい情報が存在していても、索引の対象として登録されていなければ、エージェントはその存在を認識できません。

この制約が問題になるのは、自社のナレッジが整理されていない場合です。製品仕様が個人のフォルダに置かれている、決裁の条件がメールの添付ファイルにしか残っていない、といった状態では、索引に載せられる形へ資料を整える作業が、最初の仕事になります。

また、索引に載せられる形式にも条件があります。画像として保存された図面や、文字を抽出できない形式のファイルは、そのままでは検索の対象になりません。手元にある資料の量と、索引に載せられる資料の量は、多くの場合一致していないのです。公開前に確かめるのは、資料が社内にあるかどうかより、その形式のまま索引に登録できるかどうかです。

回答の精度が上がらないという相談の多くは、指示文より索引の側に原因があります。精度が上がらない原因を5つの類型に分けて整理していますので、制約を押さえたうえでナレッジの改善に進みたい方は、ぜひ読んでみてください。

注意点②利用量が増えると費用が動く

索引の制約に続いて押さえておきたいのが、使えば使うほど費用が動くという点です。従来のSaaSのように、契約したユーザー数だけで年間の費用が固定される仕組みとは、費用の決まり方が異なります。

なぜ動くのかというと、Agentforceの課金には実行した回数を数える型が含まれているからです。エージェントが1つのアクションを実行するたびに消費が発生するため、利用が広がるほど消費量も増えていきます。

この性質は、導入前の試算を難しくします。何人が使うかは分かっても、1人が月に何回依頼するかは、動かしてみるまで正確には分かりません。試算の幅が広くなること自体を、あらかじめ見込んでおく必要があります。対象業務を1つに絞って一定期間動かし、実際の依頼件数を確かめてから範囲を広げると、見込みと実績の差を小さくできます。

消費の単位となるのがFlex Creditsです。どのような操作で何が消費されるのか、ライセンス体系との関係まで詳しくまとめていますので、費用の見積もりを担当される方はぜひ参考にしてみてください。

注意点③設定を終えても現場で使われない

3つ目は「設定を終えても現場で使われない」ことです。エージェントは正常に動いており、テストでも想定した回答を返しているのに、担当者が日常業務の中で使わないまま止まってしまう状態を指します。

導入プロジェクトとしては完了と報告されるため、経営層からは問題が見えにくく、対応が後手に回りやすくなります。では、なぜ設定が終わったエージェントが使われないのでしょうか。それは、設定のゴールがエージェントを動かすことに置かれ、担当者の業務の流れに合わせるところまで設計されていないからです。

先ほどの部材商社でも、最初に作った試作のエージェントは1週間ほどでほとんど使われなくなりました。営業がSalesforceの画面を開くのは商談を登録するときだけで、顧客からの質問はスマートフォンの社内チャットで受けているため、質問が発生した場所とエージェントがいる場所が離れていたのです。呼び出す場所を社内チャット側へ移したところ、若手営業から使われ始めました。動かなかった原因は、回答の精度ではありませんでした。呼び出す場所にあったのです。

社内に運用を担当できる人がいない場合、この状態から抜け出すまでに時間がかかります。外部の定着支援を使う選択肢もありますので、依頼先の選び方を知りたい方は参考にしてみてください。

Agentforceが向いている企業・向いていない企業

ここまで、Agentforceのメリットと注意点をそれぞれ整理してきました。両方を並べたうえで最後に残るのが、では自社はいま導入すべきなのか、という判断です。ここで前提として申し上げておくと、導入しないという判断も正しい選択肢になります。条件が揃っていない状態で始めると、費用と工数をかけたうえで使われないまま終わってしまうためです。なお、他社の対話型AIサービスとの比較という観点から向いている企業の特徴を整理した記事もありますので、ツールの選択で迷っている方はあわせて参考にしてみてください。そこでここでは、Agentforceが向いている企業の条件と、向いていない企業の状態を分けて整理します。

条件①問い合わせが特定の担当に集中していること

1つ目の条件は「問い合わせが特定の担当に集中していること」です。同じ内容の質問が繰り返し発生し、その回答が特定の担当者に依存している状態は、Agentforceの効果が出やすい条件になります。

なぜ集中していることが条件になるかというと、繰り返し発生する質問ほど、根拠になる資料と回答の型が定まっているからです。年に1度しか来ない質問のために索引を整えても、整備にかけた工数を回収できません。

判断の目安になるのは、その質問が月にどれくらい発生しているかです。同じ内容の問い合わせが週に数件以上あり、答えられる人が限られているなら、任せる対象として検討する価値があります。件数を数えるときは、電話とメールと社内チャットを分けずに、同じ内容の質問として合算します。窓口ごとに数えると、1つあたりの件数が少なく見えてしまうためです。

どのような業務が実際に対象になっているのかは、業種別のユースケースを見ると自社に近い形が見つかります。製造・商社・サービスなど業種ごとに整理していますので、対象業務を洗い出す前に目を通しておくと考えやすくなります。

条件②判断の根拠がCRM側に残っていること

2つ目の条件は、回答や判断の根拠になる情報が、すでにCRMの側に入っていることです。顧客とのやり取りの履歴、商談の経緯、対応した内容の記録が、Salesforce上に残っている状態を指します。担当者の頭の中やローカルのファイルにしか残っていない情報は、この条件に含みません。

この条件が満たされていないと、Agentforceを入れても回答の材料がありません。エージェントは、入力されていない情報を推測して補うことはしないため、記録の量がそのまま回答できる範囲になります。

とはいえ、すべてのデータが完璧に揃っている必要はありません。任せると決めた1つの業務について、その業務で使う情報が入っているかどうかを確かめれば十分です。全社のデータ整備を終えてから着手しようとすると、いつまでも始められなくなってしまいます。

担当者の人数が限られている企業ほど、この見極めが効いてきます。規模に応じてどこまで整えてから始めるべきかという規模ごとの進め方を整理していますので、少人数で検討している方は参考にしてみてください。

条件③手順を文書として更新し続けていること

3つ目の条件は「手順を文書として更新し続けていること」です。対応の手順や判断の基準が文書になっており、内容が変わったときに更新される運用ができているかどうかを指します。

文書があるかどうかだけでなく、更新されているかどうかが条件になる理由は、索引に古い版が残ると回答が誤るからです。エージェントは、複数の版が索引に載っていても、どちらが現行なのかを自分では判断できません。

具体的には、価格改定や仕様変更のたびに文書を差し替える担当者が決まっているかを確認します。誰の担当でもない状態のまま索引に載せると、改定前の内容がそのまま回答され、顧客へ誤った情報が伝わってしまいます。あわせて確かめたいのが、差し替えたときに古い版を削除する手順まで決まっているかです。新しい版を追加するだけの運用では、索引の中に両方が残り続けます。

逆にいえば、文書の更新体制がすでにある企業は、Agentforceの導入で最も手間のかかる工程を先に済ませていることになります。ナレッジ整備の負荷は、この体制の有無で大きく変わると考えます。

状態①顧客データが複数の場所に分かれている

ここからは、先に整えるべき状態を3つ見ていきます。1つ目は「顧客データが複数の場所に分かれている」状態です。取引先の情報がSalesforceにあり、対応履歴はメールと共有フォルダ、契約条件は別の販売管理システムにあるという分散した状態を指します。

この状態でAgentforceを導入すると、回答の根拠が部分的にしか集まりません。エージェントは参照できる範囲のデータだけで回答を組み立てるため、契約条件を見ないまま納期を答えてしまうといった、部分的に正しく全体としては誤った回答が生まれます。

部分的に正しい回答は、明らかな誤りより発見が遅れます。担当者が違和感を持たずに顧客へ伝えてしまい、後になって条件の相違が判明するという形で表面化するためです。納期や取引条件のように、部門をまたいで管理されている項目ほど、この食い違いが起きやすくなります。

そこで、この状態にある場合は、どのデータをどこまで参照させるかを決めるところから始めます。分散したまま急いで導入すると、回答の正しさを担当者が毎回検証することになり、探す時間が減らないまま検証の時間が増えてしまいます。

状態②業務の手順が担当者ごとにばらついている

2つ目は「業務の手順が担当者ごとにばらついている」状態です。同じ問い合わせに対して、誰が対応するかによって確認する項目も回答の順序も変わっている状態を指します。

手順がばらついていると、エージェントに何を任せるのかを決められません。任せる手順を1つ選ぶということは、その手順を正とすると社内で決めることでもあるためです。この合意がないまま設定を進めると、公開後に「自分のやり方と違う」という指摘が出て、使われなくなります。

先ほどの部材商社でも、経営会議で「まだ早いのではないか」という意見が出た理由がここにありました。ベテラン営業2名は、顧客ごとに過去の取引経緯を踏まえて回答を変えており、その判断基準は文書になっていません。何を正とするかを決める話し合いから始める必要があったのです。

この状態は、Agentforceを入れられない理由ではありません。ただし、設定作業より先に業務側の合意を取る工程が必要になる、という順序の問題になります。合意にかかる時間を見込まずに導入時期を決めてしまうと、公開の日程から順に崩れていきます。

状態③自動化したい処理が月に数件にとどまる

3つ目は「自動化したい処理が月に数件にとどまる」状態です。任せたい業務は明確にあるものの、その業務が発生する頻度が低い場合を指します。

頻度が低いと、整備にかけた工数を回収できません。索引に載せる資料の準備、手順の合意、公開前の検証にかかる作業量は、対象業務の発生件数とは関係なく発生するためです。月に数件の処理のために、それらをすべて行う判断にはなりにくいと考えます。

たとえば、年に数回しか発生しない特殊な見積の作成を最初の対象に選ぶと、検証に使えるパターンが集まらないまま公開することになります。想定外の依頼が来たときの動きを確かめられず、公開してから問題が見つかります。次に同じ依頼が来るのが半年先であれば、そのあいだに担当者が操作の手順を忘れてしまうという問題も重なります。

この場合の判断は、導入を見送るか、対象業務を見直すかのどちらかです。頻度の高い業務が社内に見当たらないのであれば、いまは進めないという結論が合理的だと考えます。時期を改めて、業務量が増えた段階で検討し直すほうが、結果として無駄がありません。

Agentforceの料金とライセンス体系

前章では、Agentforceを導入すべきかどうかを判断する条件を整理しました。条件が揃っていると分かった段階で、次に必要になるのが費用の見通しです。Agentforceの費用は、1つの料金表では決まりません。数え方の異なる3つの型が併存しています。実行した回数で数えるFlex Credits、会話の件数で数える従量課金、そして利用する人数で数えるユーザーライセンスの3つです。費用の増え方も型によって変わり、実行回数で数える型はアクション単位で費用が積み上がっていくのに対し、人数で数える型は使う担当者が増えたときに増えます。どの型を選ぶかで見積もりの前提が変わるため、まず型の違いから押さえておきましょう。

本記事では金額に踏み込みません。単価と総額の試算まで整理したのが「Agentforceの料金」です。型の違いを押さえたうえで自社の費用を見積もりたい方は、ぜひ読んでみてください。

Agentforce導入の投資対効果をどう示すか

料金の型が分かると、次は社内でどう説明するかという段階に進みます。ここでよくあるのが、ライセンス費用だけを並べて稟議に出し、それ以外の費用を問われて差し戻されるという流れです。実際にかかるのはライセンス費用だけではありません。索引に載せる資料を整える作業、公開前の検証、公開後に回答を見直す運用の工数が加わります。効果の側も、削減できた時間を積み上げる形にすると、その時間が何に使われたのかを問われて説明が止まります。

効果は時間の量より、担当者が行う業務がどう変わったかという状態で定義するほうが、承認する側に伝わります。総コストの積み上げ方と稟議資料の組み立て方は、それ自体が1つのテーマになるため本記事では扱いません。そこで、費目ごとの内訳から説明の順序まで解説したのが「Agentforceの費用対効果」です。

最初のユースケースをどう選ぶか

Agentforceの導入で最初につまずく場面は、設定の操作ではありません。どの業務を任せるのかが決まらないところです。稟議では「営業の生産性向上」といった大きな目的で承認を取ったものの、いざ設定画面を開くと、何を作ればよいのか誰も答えられないという状態がよく起こります。任せる業務が決まっていないと、参照させるデータも許可するアクションも決められないため、設定の作業が進みません。

最初の足切りになるのは、その業務が繰り返し発生しているか、回答の根拠がどこにあるか、そしてやり直しがきく範囲かという3点です。この3つを満たさない業務を最初に選ぶと、検証が終わらないまま時間だけが過ぎていきます。業務の洗い出し方から絞り込みまでを整理したのが「Agentforceのユースケースの選び方」です。判断の材料をそろえてから選定作業に入りたい方は、ぜひ読んでみてください。

営業部門でのAgentforce活用

営業部門で最初に決めるのは、商談のどの工程を任せるのかという範囲です。営業活動を丸ごと自動化する話として捉えると対象が広がりすぎるため、工程を切り分けたうえで考えます。Agentforceが効きやすいのは、商談前に過去のやり取りと取引状況をまとめる準備の工程、見込み客への初期接触を継続する工程、そして商談後の記録と振り返りの工程の3つです。いずれも、担当者ごとの力量差が出やすく、かつ作業の型が決まっている領域になります。

一方で、成否を分けるのは機能の選択より、自社の営業の型が文書として残っているかどうかです。型が個人の経験の中にしかない場合、任せる手順を決める段階で止まります。仕組みの詳細と選ぶ基準をまとめたのが「Agentforce for Sales」です。工程の全体像を押さえたうえで自社の営業に当てはめたい方は、あわせてご確認ください。

カスタマーサポートでのAgentforce活用

問い合わせ対応にAIを入れると聞くと、すべての問い合わせを無人化する話だと受け取られがちです。実際に設計するのは、一次回答をどこまで担わせ、どこから人が引き取るかという線引きになります。全件を任せる前提で設計すると、判断が難しい問い合わせまでエージェントが回答してしまい、後から人が訂正する対応が増えていきます。

そのため、引き継ぐ条件を先に決めておくことが、カスタマーサポートでの設計の中心になります。条件としては、金額や契約内容に関わる問い合わせ、顧客が不満を示している場合、そして同じ質問が繰り返されている場合などが挙げられます。この線引きの考え方と、必要になるエディションや権限の前提まで整理したのが「Agentforce Service Agent」です。一次対応の設計に着手する段階の方は、ぜひ読んでみてください。

中小企業におけるAgentforce導入

自社の規模では使いこなせないのではないか、という相談を中小企業の担当者からよく受けます。実際に導入の可否を分けるのは、従業員数より、任せたい業務がどれだけ繰り返し発生しているかです。少人数の組織であっても、同じ問い合わせが毎週発生しているなら対象になりますし、逆に大きな組織でも、対象業務が散らばっていれば効果は出にくくなります。むしろ規模の小さい企業で効いてくるのは、意思決定の速さです。任せる業務を決める会議に必要な人数が少なく、手順の合意も短期間で取れます。

一方で、専任の担当者を置けないという制約は現実に存在するため、兼任である前提に立って対象範囲を絞る設計が必要になります。中小企業ならではの課題と進め方を5つのステップに整理したのが「中小企業のAgentforce導入」です。少人数の体制で検討している方は、本記事の全体像を押さえたうえで読んでみてください。

Agentforceの初期設定と使い方

任せる業務が決まったら、次は実際に作る工程に入ります。最初に安心していただきたいのは、1体目のエージェントを作るのに開発は必要ないという点です。Agent Builderという画面上の設定だけで、業務のまとまりを定義し、参照させるデータを指定し、実行を許可するアクションを選ぶところまで進められます。ただし、画面を開いてから考え始めると必ず手が止まります。何を任せるのかと、どのデータを参照させるのかが決まっていない状態では、設定画面のどの欄も埋められないためです。設定作業は、決めたことを画面へ写す工程だと捉えるほうが実態に近いといえます。画面ごとの操作手順と、標準のアクションを使う際に見落としやすい点まで解説したのが「Agentforceの使い方」です。手を動かす段階に入る方は、ぜひ参考にしてみてください。

Agentforceのナレッジ設計

回答の質を上げようとすると、多くの担当者はまず指示文の書き方を調整します。ところが、実際に精度を左右しているのはその手前にあるナレッジの整備です。エージェントは索引に載っている情報からしか回答を作れないため、指示文をどれだけ工夫しても、根拠になる資料が索引にない状態では回答は良くなりません。

ナレッジ設計で確かめるのは2点です。1つは、その資料が索引に載る形式になっているか。もう1つは、同じ内容の資料が複数ある場合に、どれが現行版かを見分けられる情報が入っているかです。この2点が整っていない状態のまま公開すると、古い条件で回答してしまう問題が後から見つかります。索引の作り方から、精度が上がらないときの見直し方まで整理したのが「Agentforceのナレッジ設計」です。本記事の全体像を押さえたうえで、自社の資料を点検する段階に進んでみてください。

Agentforceのテストと品質保証

作ったエージェントを本番に出してよいかどうかは、動いたかどうかでは判断できません。テストで確かめるのは、想定した質問に正しく答えられることだけではありません。想定していない聞かれ方をされたときにどう応じるかまで確かめます。現場の担当者や顧客が投げる言い回しは、設計した人が想定した文面とは必ずずれます。そのずれた入力に対して、誤った情報を断定して返すのか、それとも分からないと答えて人へ引き継ぐのかで、公開後に起きる問題の大きさが変わります。

もう1つ必要なのが、合格の基準を人が先に決めておくことです。何割の質問に答えられれば公開してよいのかを決めないままテストを始めると、検証がいつまでも終わりません。検証の進め方と基準の作り方をまとめたのが「Agentforceのテスト」です。公開の判断を控えている方は、ぜひ読んでみてください。

Agentforceの効果測定と定着

公開したあとに続けてよいかどうかを判断するには、時期ごとに見る指標を変える必要があります。立ち上げ期に見るのは使った人数と利用回数、定着期は同じ担当者が使い続けているかどうか、拡大期は対象業務を広げても品質が保てているかです。同じ指標を最初から最後まで追い続けると、初期は問題なく見え、後半で判断できなくなります。ここで注意していただきたいのが、指標の読み方です。

人へ引き継いだ割合を示すエスカレーション率は代理指標であり、その問い合わせが解決したかどうかを示す数値ではありません。引き継ぎが適切に働いた結果としてこの数値が上がることもあるためです。測れる指標の一覧と、それぞれをどう読むのかを整理したのが「Agentforceの効果測定」です。何を見るかを決めた段階の方は、あわせてご確認ください。

Agentforceのセキュリティとガバナンス

情報システム部門の承認を取る段階で、従来のSaaSと同じ観点だけを説明すると話が止まります。通信の暗号化や保管場所といった観点に加えて、エージェントが自律的に実行する範囲と、参照できるデータの範囲をどう設計したのかを問われるためです。承認する側から見ると、担当者が操作したときにしか動かないシステムと、依頼を受けて自ら処理を進めるシステムでは、確認すべき点が変わります。

ここで先に決めておくのは、設定項目より、どこまでを任せるのかという業務側の線引きです。線引きが決まっていれば、権限の設定もガードレールの内容もそこから導けます。逆に、設定画面の項目から埋め始めると、何のための制限なのかを説明できなくなります。想定されるリスクの分類と、それぞれに対する設定の考え方を整理したのが「AIエージェントのセキュリティ」です。社内の承認を取る立場の方は、本記事の全体像とあわせて読んでみてください。

Agentforceと外部システム・Slackの連携

Agentforceが参照し、更新できるのはSalesforceの中のデータだけではありません。基幹システムに入っている在庫や出荷の情報、外部の見積システムの内容まで扱わせたい場合、どの方式でつなぐのかという検討が必要になります。方式によって、実装にかかる工数も、後から対象を増やすときの手間も変わってきます。ここは方式ごとの比較が独立したテーマになるため、本記事では踏み込みません。そこで、MCP（Model Context Protocol）を含む接続方式の違いと選び方まで解説したのが「Agentforce MCP」です。もう1つ、つなぐ先として実際に最も使われているのが会話ツールです。担当者が日常的に開いている画面から呼び出せるかどうかで、使われる頻度が変わるためです。導入の手順と扱える範囲をまとめた「Agentforce in Slack」もありますので、社内利用を想定している方はぜひ参考にしてみてください。

Agentforceの定義をコードで管理する

画面上の設定だけで運用を続けられると考えていると、担当者が増えた段階で問題が出てきます。誰がいつ何を変更したのかを追えない、複数人が同時に編集できない、検証用の組織へ同じ内容を移せない、といった制約が順番に表面化するためです。1体のエージェントを1人で運用しているうちは起きませんが、対象業務を広げていくと必ず通る場面になります。この制約に対して、エージェントの定義をコードとして持つという選択肢が用意されています。定義がコードになっていれば、変更履歴を残すことも、レビューを経てから反映することもできます。記法と、開発の流れへの載せ方まで解説したのが「Agent Script」です。あわせて、自然言語での指示から実装を進める開発の仕組みとして「Agentforce Vibes」もありますので、開発体制を検討している方は両方を見比べてみてください。

AgentforceとEinstein・他社AIツールの違い

すでにSalesforceを使っている企業の担当者から、Einsteinとの関係を聞かれる場面がよくあります。結論としては、Agentforceが登場したことでEinsteinがなくなったわけではありません。予測や採点を担う機能は基盤の側に残っており、その上でAgentforceが手順の組み立てと実行を担うという関係になっています。両者の関係については、推論の仕組みの差まで踏み込んだ説明が必要になるため、本記事では扱いません。そこで、内部の処理の違いから移行時の注意点まで解説したのが「AgentforceとEinsteinの違い」です。もう1つ、社外の対話型AIサービスと並べて検討されることも増えています。判断の分かれ目は、CRMのデータとどこまで統合されているかと、実行まで担うかどうかの2点です。個別の製品名を挙げた比較は「AgentforceとChatGPTの比較」にまとめていますので、複数の候補を並べている方はご確認ください。

Agentforceの資格と人材育成

社内の誰に担当させるのかを決める段階で必要になるのは、2種類の人材です。1人は設定を組み立てられる人、もう1人は任せる業務と手順を決められる人になります。この2つは求められる知識が異なり、片方だけでは進みません。設定ができても、どの業務を任せるかを決められなければ作るものが定まりませんし、業務を決められても設定に落とす人がいなければ形になりません。このうち、設定を担う側の知識水準は資格である程度測れます。Salesforceが用意している認定資格は、エージェントの設計・構築・運用に必要な範囲を出題の対象にしているためです。試験の範囲と学習の進め方をまとめたのが「Agentforceスペシャリスト資格」です。社内で担当者を育成する方針の場合は、本記事で全体像を押さえたうえで参考にしてみてください。

Agentforce導入支援会社の選び方

外部に依頼するかどうかを検討するとき、設定を代行してもらうことと、定着まで付き合ってもらうことは別の依頼だと分けて考える必要があります。設定の代行だけを依頼した場合、エージェントは完成しますが、公開後に回答を見直す作業と、使われるようにする働きかけは自社に残ります。もう1点、資格の保有数だけでは実装力を判断できません。資格が示すのは設定に必要な知識であり、任せる業務を業務側と一緒に決められるかどうかは別の能力になるためです。選定の基準と、依頼先のタイプごとの違いを整理したのが「Agentforce導入支援会社」です。依頼を検討する段階の方は、本記事の全体像を押さえたうえで読んでみてください。

なお、当社はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化した導入・定着支援を提供しています。1ユースケース×3ヶ月のスモールスタートから対応しており、無料相談も受け付けていますので、任せる業務の決め方から相談したい場合はご利用ください。

Agentforceでできないこと

ここまで、Agentforceで何ができるのかと、どう進めるのかを整理してきました。ただし、検討を進める前にできないことを把握しておかないと、導入後に想定と食い違います。ここで挙げるのは、設定を工夫すれば解決するものではありません。製品の仕組みとして越えられない範囲です。この範囲を先に共有しておくと、社内での期待値を揃えられますし、公開後に「なぜこれができないのか」と問われる場面も減らせます。そこでここでは、Agentforceでできないことを3つに分けて示します。

できないこと①索引にない情報を根拠として示す

1つ目は「索引にない情報を根拠として示す」ことです。検索インデックスに登録されていない資料の内容を、エージェントが推測して補うことはできません。

この制限が効いてくるのは、社内に情報はあるものの、置き場所が索引の対象外になっている場合です。担当者の個人フォルダにある最新の価格表や、メールの添付でしか共有されていない仕様変更の通知は、そのままでは参照されません。

さらに注意が必要なのが、索引にない情報を聞かれたときの振る舞いです。分からないと答えるように設定していなければ、索引に載っている近い内容から回答を組み立て、結果として誤った情報を返してしまう場合があります。旧型番の仕様しか索引になければ、新型番について聞かれても旧型番の数値で答えてしまう、といった形で表面化します。

したがって、公開前に確かめるのは、正しく答えられるかどうかだけではありません。答えられない質問を投げたときに何を返すのかまで確認します。この想定外の質問の洗い出しをどう進めるのかを詳しくまとめていますので、公開前の検証を担当される方はぜひ参考にしてみてください。

できないこと②権限で許していない操作の実行

2つ目は、権限として許可していない操作を実行することです。推論の結果として必要だと判断された場合でも、許可されていないレコードの更新や外部システムへの照会は実行されません。

これは制限であると同時に、Agentforceを安全に使うための仕組みでもあります。自律的に手順を組み立てる設計である以上、実行できる操作を限定しておかなければ、想定していない更新が起きてしまうためです。

一方で、運用面では別の注意が必要になります。許可の範囲が狭すぎると、エージェントが処理の途中で止まり、担当者が結局は手作業で続きを行います。安全側に寄せすぎた設定は、使われない原因にもなるのです。参照は許可しても更新は許可しない、という段階的な設定にしておくと、影響の大きさを確かめながら範囲を広げられます。

どこまで許可するかの判断は、業務の重要度と、誤った場合の影響の大きさで決めます。金額や在庫を書き換える操作は担当者の確認を挟み、活動履歴の登録のように取り消しがきく操作から任せると、判断の順序がつけやすくなります。この権限設計の考え方と、あわせて設定しておくべきガードレールの内容を整理していますので、範囲を決める段階の方は参考にしてみてください。

できないこと③有効なエージェントを上限より増やす

3つ目は「有効なエージェントを上限より増やす」ことです。Agentforceでは、1つのSalesforce組織で同時に有効化できるエージェントの数に上限があり、2026年8月時点では20体とされています。同じく、1体のエージェントに登録できる業務のまとまりにも上限があります。

この上限は、最初の1体を作る段階では気になりません。問題になるのは、部門ごとに別々のエージェントを作る方針で進めた場合です。営業部門と購買部門とカスタマーサポートがそれぞれ複数体を持つ形にすると、想定より早く上限へ達します。検証用に作ったまま無効化していないエージェントも数に含まれるため、試作を重ねた組織ほど残数が読みにくくなります。

対処としては、業務ごとにエージェントを増やす前に、1体のエージェントの中へ業務のまとまりを分けて登録する形を検討します。まとまりの単位で参照するデータと許可する操作を切り替えられるため、多くの場合はこの形で足ります。

なお、上限の値は提供状況によって変わる可能性があります。設計を確定させる前に、現在の作成上限の確認方法とあわせて把握しておくと、後から構成を組み直す作業を避けられます。

Agentforce導入判断の進め方

前章では、Agentforceの仕組みとして越えられない範囲を3つ示しました。できることとできないことが揃ったところで、最後に残るのは、では何から着手するのかという順序の問題です。ここで扱うのは、着手する前に何をどの順番で決めるかという判断の流れです。設定画面の操作手順には立ち入りません。順番を誤ると、決まっていないことを前提に作業を始めることになり、途中で前の工程へ戻ることになります。そこでここでは、Agentforce導入の判断を4つのステップに分けて整理していきます。

ステップ①任せる業務を1つに決める

最初に決めるのは、どの業務を任せるのかという1点です。ここでいう1つとは、部門でも機能でもなく、「製品仕様の一次回答」のように担当者が日々行っている作業の単位を指します。

このステップでよくあるのが、社内説明のために対象を広く置いてしまう失敗です。稟議で承認を得やすいという理由から「営業全体の効率化」と設定すると、その後の工程がすべて止まります。参照させるデータも、許可するアクションも、対象業務が決まっていなければ選べないためです。

判断の材料になるのは、その業務が週に何件発生しているか、回答の根拠がどこにあるか、そして誤った場合にやり直せるかの3点でした。この3点を業務ごとに並べると、候補の順位が自然と決まってきます。やり直せるかという点では、社内向けの回答から始めるほうが安全です。顧客へ直接返す業務は、誤った内容が出たときに取り消せません。

より細かい判断の材料を求める場合は、絞り込みに使う5つの判断軸を整理した記事があります。任せる業務を1つに決めてから選定の作業に入りたい方は、本記事で進め方を押さえたうえで読んでみてください。

ステップ②根拠にするナレッジの所在を確かめる

任せる業務が決まったら、次に確かめるのは、その業務の回答の根拠になる資料がどこにあるかです。作業としては地味ですが、このステップで判明することが導入の可否を左右します。

先ほどの部材商社では、製品仕様の一次回答を任せると決めた後で、情報システムの担当者が実際に資料を探しに行きました。ところが、現行の仕様書はメーカーから送られてきたPDFのままベテラン営業2名の個人フォルダに保存されており、社内の共有フォルダにあったのは2年前の版でした。さらに、顧客ごとの特別な取り決めは、過去のメールの中にしか残っていませんでした。

つまり、資料は社内に存在していたものの、どこにあるかを誰も把握していない状態だったのです。この確認を飛ばして設定に進んでいたら、古い版を索引に載せたまま公開していたことになります。

この確認は、資料の一覧を作るところまでで終わりにせず、それぞれの版がいつ更新されたかまで書き出しておきます。ナレッジの所在を確かめる作業は、Agentforceを入れるかどうかに関わらず価値が残ります。逆に、この段階で資料が集まらないと分かった場合は、対象業務を変える判断をこの時点で行えます。

ステップ③試作を作って想定外の回答を集める

所在が確かめられたら、次は小さく作って動かす段階に入ります。この段階の目的は、完成させることより、想定外の回答を集めることにあります。

ここで起きやすいのが、自分で考えた質問だけを試して「動いた」と判断してしまうことです。設計した人が投げる質問は、設定した内容に沿った聞き方になります。実際に現場の担当者や顧客が投げる言い回しは、それとは違いますし、索引に載せていない資料を前提にした質問も混ざってきます。そこで、設計に関わっていない担当者に数日間使ってもらい、返ってきた回答をそのまま記録に残します。集めた回答のうち、誤っていたものを分類すると、索引を直すべきか設定を直すべきかを切り分けられます。

まず作る工程は、画面上の設定だけで1体目を用意できます。操作の流れはAgent Builderの使い方として整理していますので、手を動かす前に確認しておくと迷わずに進められます。そのうえで確かめる工程では、何をもって公開してよいと判断するのかを先に決める必要があります。品質保証の三層として検証の進め方をまとめていますので、試して終わりにせず本番前の合否基準まで決めたい方は、あわせて読んでみてください。

ステップ④測る指標を決めてから範囲を広げる

最後に決めるのが、何を測るかという指標です。順序として重要なのは、対象業務を広げる前にこれを決めることになります。

指標を決めないまま範囲を広げると、うまくいっているのかどうかを説明できなくなります。処理した件数は増えていくため、動いていることは示せますが、業務が変わったかどうかは示せません。経営層から効果を問われた時点で、遡って集計できるデータが残っていないという事態になります。

測る対象としては、利用した担当者の人数、同じ担当者が使い続けているかどうか、人へ引き継いだ割合などが挙げられます。どの数値を追うかは、任せた業務によって変わります。あわせて決めておきたいのが、確認する間隔です。毎日見ると数値の上下に振り回され、四半期ごとでは対象を広げる判断に間に合いません。公開してから最初の数か月は、週単位で見る形が扱いやすくなります。

定着の度合いを示す定着率の測り方については別途整理していますので、指標を決める段階で参考にしてみてください。以上が、Agentforceの導入を判断するための4つのステップでした。

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

ここまで、Agentforceの定義から導入判断の進め方までを一通り整理してきました。最後に、検討の場でご質問をいただくことの多い前提を、一問一答の形でまとめておきます。社内で説明する場面では、定義よりも先に、Salesforceの契約との関係や日本語での提供状況といった前提を確かめられることが少なくありません。いずれも、検討の初期に出てくる質問です。そこでここでは、Agentforceに関するよくある質問に順番に答えていきます。

質問①Agentforceとは何をする製品ですか？

Agentforceとは、Salesforceが提供する、CRMに蓄積したデータを根拠にAIエージェントが自ら手順を決めて業務を実行する基盤のことです。担当者が依頼の内容を渡すと、どのデータを参照し、どの操作をどの順番で行うかをエージェントの側で組み立てて実行します。

生成AIとの違いは、文章を作って終わらず、ケースの更新や記録の登録といった業務システムの操作までを担う点にあります。ただし実行できるのは、あらかじめ許可された操作の範囲に限られます。

任せられる業務は、必要な情報を調べる、下書きを作る、一次回答を返す、結果を記録する、という4つの型に整理できます。いずれも担当者がすでに行っている作業であり、新しい業務が増えるわけではありません。

質問②AgentforceはSalesforceの契約とどういう関係になりますか？

Agentforceは、Salesforceとは別の独立したシステムとして導入するものではありません。すでに契約しているSalesforceの上に載る形で提供されるため、利用にはSalesforceの契約が前提になります。エディションについても、上位のエディションを契約していることが条件です。

そのうえで、費用の数え方は既存のライセンスとは別に設けられています。実行した回数で数える型、会話の件数で数える型、利用する人数で数える型の3つが併存しており、どれを使うかで見積もりの前提が変わります。

すでにSalesforceを使っている企業にとっては、データが入っている分だけ導入の前提条件が揃っていることになります。逆に、Salesforceを使っていない状態から検討する場合は、CRMの導入から順に考える必要があります。

質問③Agentforceは日本語で使えますか？

Agentforceは日本語で利用できます。日本市場向けの提供も段階的に進んでおり、Agentforce 360は2025年11月20日から日本での提供が始まっています。

音声で対応するAgentforce Voiceについても、日本語版の一般提供開始が2026年8月7日に発表されました。※参考記事はこちら。また、社内の情報を横断して検索し、日本語で根拠付きの回答を返すAgentforce Coworkerは、2026年8月5日に日本市場での一般提供が発表されています。※参考記事はこちら。

ただし、日本語で使えることと、日本語で高い精度が出ることは別の話になります。特にレコードの検索では、索引に載っている表記と質問の表記が一致しているかどうかが結果を左右します。実際に自社のデータで試したうえで判断されることをおすすめします。

質問④AgentforceにData 360は必要ですか？

Agentforceのすべての機能にData 360が必要になるわけではありません。ただし、資料を検索インデックスに載せて回答の根拠として使うRAGの機能や、Agentforce Data Libraryのように索引を扱う機能は、Data 360の上に構築されています。

つまり、CRMのレコードだけを根拠にした回答であれば前提は変わりませんが、ナレッジ記事やPDFといった文書を根拠にさせたい場合には、Data 360側の構成が関係してきます。自社が任せたい業務が、どちらの範囲に当てはまるのかで判断が分かれます。

提供の形は更新が続いている領域でもあります。契約の内容を確定させる前に、任せる業務で使う機能を具体的に挙げたうえで、現在の提供条件を確認されることをおすすめします。

質問⑤Agentforceの導入判断にはどれくらいの期間がかかりますか？

期間を決めているのは、設定の作業量ではありません。1体目のエージェントは画面上の設定だけで組み立てられるため、作る工程だけを見れば長くかかるものではないと考えます。

実際に時間がかかるのは、任せる業務を1つに決める合意と、その根拠になる資料の所在を確かめる作業です。特に、手順が担当者ごとに異なっている場合は、何を正とするかを業務側で決める話し合いが必要になり、ここが期間を左右します。

したがって、導入の時期から逆算して計画を組むより、業務側の合意にどれくらいかかりそうかを先に見積もるほうが、現実的な見通しになります。合意の目処が立たない段階で設定作業の日程を先に決めてしまうと、後の工程がすべて後ろへずれてしまいます。

質問⑥Agentforceは情報システム部門がいなくても運用できますか？

専任の情報システム部門がなくても、運用を始めること自体はできます。1体目の作成は画面上の設定で進められるため、開発の担当者を置く必要はありません。

ただし、公開したあとに続く作業を誰が担うかは決めておく必要があります。回答の内容を確認して索引の資料を差し替える、想定外の質問が来たときに設定を見直す、といった作業が定期的に発生するためです。この担当を決めないまま公開すると、資料が古くなった時点で回答の精度が落ち、使われなくなっていきます。

兼任でも問題はありません。重要なのは人数より、公開後の見直しを誰の担当にするかが決まっていることだと考えます。社内で担い手を確保できない場合は、外部の支援を使う選択肢もあります。

Agentforceは任せる業務とナレッジの設計で導入の可否が決まる

Agentforceとは、CRMに蓄積したデータを根拠にAIエージェントが自ら手順を決めて業務を実行する基盤であり、導入の成否を分けるのは機能の選択ではなく、任せる業務を1つに決められるかと、その根拠になるナレッジを索引に載せられるかという2点です。本記事では、定義と誕生の背景から、1つの回答が返るまでの4段階、メリットと注意点、向き不向き、そして導入判断の進め方までを一連の流れとして整理してきました。

はじめに例として挙げた部材商社も、最初は「AIで営業を効率化せよ」という指示だけがある状態でした。任せる業務を製品仕様の一次回答に絞り、資料の所在を確かめ、呼び出す場所を担当者が日常的に使う画面へ移したことで、ベテラン営業2名に集中していた問い合わせのうち、どれが手元に残るのかを毎月確認できる状態になっています。

当社では、どの業務から任せるか、その根拠になるナレッジをどう整えるかという判断からご一緒しています。Agentforce導入・定着支援では無料相談も受け付けていますので、社内で検討を進める段階の方はお気軽にご相談ください。本記事の内容が、判断の材料として少しでもお役に立てれば幸いです。