SalesforceのAIを調べると、AgentforceとEinsteinという2つの名前が並んで出てきて、機能の一覧を見比べても違いをつかめない、という方は多いのではないでしょうか。結論から言うと、AgentforceとEinsteinを分けているのは、搭載している機能の数ではありません。AIが物事を判断する内部の仕組み、つまりアーキテクチャの違いです。かつてのEinstein Copilotが「決めた計画を順番にこなすアシスタント」だったのに対し、Agentforceは「状況を見ながら次の一手を決め直す自律型のエージェント」へと、構造から作り替えられています。
そこで本記事では、この2つを分けるアーキテクチャの違いを出発点に、Agentforceの内部で何が起きているのか、Einsteinがどのように基盤を支えているのか、そして自社での使い分けと移行の注意点までを、導入判断にそのまま使える形で整理します。
- AgentforceはEinsteinの「後継」ではなく「進化した別の存在」だ
- CoTとReActの違いがEinsteinとAgentforceの能力差を生む
- Agentforceの内部アーキテクチャ”Atlas Reasoning Engine”とは
- AgentforceはEinsteinを基盤として安全に動作する仕組み
- AgentforceとEinsteinの使い分け方
- Einstein CopilotのプロンプトをAgentforceへ移行する際の注意点
- 【一問一答】AgentforceとEinsteinの違いに関するよくある質問
- EinsteinはAgentforceが安全に動くための基盤でありAgentforceはEinsteinの上でReActパターンで自律的に行動する
当社はSalesforce公式コンサルティングパートナーとして、 ソリューション営業に特化したAgentforce導入・定着支援を 行っています。
- どのユースケースから始めればいいか分からない
- 設定は完了したが現場に定着しない
- ナレッジ設計から一緒に考えてほしい
というお悩みがあればお気軽にご相談ください。 1ユースケース×3ヶ月のスモールスタートプランから対応しています。
この記事を書いた人
合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。
AgentforceはEinsteinの「後継」ではなく「進化した別の存在」だ
今回は、産業用機械の製造・販売を手がける中堅メーカー（従業員約300名・営業40名・Salesforce導入済み）が、営業とCS（カスタマーサクセス）の現場でEinsteinとAgentforceの使い分けを検討したケースを例に、解説を進めます。AgentforceとEinsteinの違いを「新しいAgentforceが古いEinsteinを置き換えた」と後継関係で理解すると、かえって混乱してしまいます。そこでここでは、両者を後継と旧製品の関係で捉えるのは正確ではないこと、そしてアーキテクチャの異なる別の存在であることを、3つの違いから整理します。
AgentforceとEinstein Copilotを分けているのは、搭載機能の数ではありません。意思決定をCoT方式で進めるか、ReActパターンで進めるかという構造の違いです。
違い①EinsteinはCoT方式のアシスタントとして定義されていた
1つ目の違いは、かつてのEinstein Copilotが、CoT（Chain-of-Thought）方式のアシスタントとして定義されていたことです。CoT方式では、タスクを達成するための一連のアクションプランを先に生成し、その計画に沿って順番に処理を進めていきます。
アシスタントと呼ばれたのは、Einstein Copilotが自ら計画を組み替えることはせず、人が投げかけた指示に沿って会話や作業を支援する役割にとどまっていたからです。人の作業を補助する立場であり、業務を引き受ける主体ではありませんでした。
たとえば、この産業機械メーカーの営業部門で、Einstein Copilotに商談メモの要約を頼んだ場面では、指示した手順どおりに要約を返すところまではこなせました。ただ、その要約をもとに次に何をすべきかを自分で判断して動くことはなく、担当者からの次の指示を待つだけでした。担当者が一つずつ指示を出し、その都度AIが応答する対話の往復が、当時の使い方の前提だったのです。
手順を固定できる作業かどうかが、当時のEinstein Copilotに任せられる業務を見分ける基準でした。
違い②Agentforceが自律型エージェントプラットフォームである理由
2つ目の違いは、Agentforceが、旧Einstein CopilotをAgentforceブランドへ統合したうえで、自律型のエージェントプラットフォームとして位置づけ直された点です。自律型と呼べるのは、Agentforceが人の逐一の指示を待たずに、自分で推論し、計画し、行動するところまでを一続きで実行できるからです。
Salesforceは、Agentforceを、複雑な業務ワークフローを人間の介入なしに実行できるプロアクティブなAIエージェントと位置づけています。目的を与えられれば、その達成に必要な手順を自分で選び、実行まで進みます。
実際に、同じ商談メモの要約をこの産業機械メーカーの営業部門でAgentforceに任せた場面では、要約を作るだけで終わりませんでした。要約の内容から次にとるべき行動を判断し、フォローメールの下書き作成とCRMへの活動記録まで、一続きで進めてくれました。担当者は途中で細かな指示を出さず、最後に内容を確認するだけで済んだのです。
目的と判断基準を渡さないままAgentforceに任せた場合は、アシスタントと同じ使い方から抜け出せません。
違い③名称変更が示すアーキテクチャの根本的な転換
3つ目の違いは、Einstein CopilotからAgentforceへの名称変更が、単なるブランド名の付け替えにとどまらず、内部アーキテクチャの根本的な転換を示していることです。Agentforceの意思決定は、計画を先に立てるCoT方式から、推論と行動を繰り返すReActパターンで動くAtlas Reasoning Engineへ置き換わりました。Salesforceも、検証の結果、ReAct型のプロンプティングのほうがCoT方式より良い結果になったと説明しています。
名前が変わったのは、製品名を新しくしたかったからではありません。AIが物事を判断する構造が別物になったため、それに合わせて呼び名も改めた、という順序で捉えると理解しやすくなります。
たとえば、この産業機械メーカーでも、社内に残っていた古い検討資料に「Einstein Copilot」と書かれていて、担当者が現在のAgentforceと同じものなのか判断できずにいました。過去の資料でEinstein Copilotとあるものは現在のAgentforceに読み替えて差し支えありませんが、その中身は名前を引き継いだだけにとどまらず、推論エンジンの側で判断の進め方が変わっています。この点を押さえると、担当者の混乱も解けました。
CoTとReActの違いがEinsteinとAgentforceの能力差を生む
前章で、Einstein CopilotとAgentforceがアーキテクチャの異なる別の存在だと整理しました。その違いの中心にあるのが、CoTとReActという2つの意思決定の方式です。そこでここでは、この2つの方式がどう異なり、その差がEinsteinとAgentforceの能力の差をどう生むのかを、3つの角度から解説します。
CoTとReActの決定的な違いは、計画の途中で誤りに気づいたときに軌道修正できるかどうかにあります。
下の表で、CoT方式とReActパターンの違いを整理します。
| 観点 | Einstein Copilot（CoT方式） | Agentforce（ReActパターン／Atlas Reasoning Engine） |
|---|---|---|
| 意思決定の方式 | 最初に計画を立てて順番に実行する | 推論→行動→観察を繰り返す |
| 途中の軌道修正 | できない | 状況を見て判断をやり直せる |
| 位置づけ | 会話を支援するアシスタント | 業務を自律実行するエージェント |
| 応答の関連性・精度 | 比較値の公表なし | 応答関連性2倍・精度33%向上 |
違い①Einstein Copilotが抱えていたCoT方式の欠陥
1つ目は、Einstein Copilotが採用していたCoT方式に、計画に誤りがあっても途中で軌道修正できないという欠陥があったことです。この欠陥は、対応の途中で条件が変わる業務ほど問題になります。なぜなら、CoT方式は最初にアクションプランをすべて立ててから順番に実行し、実行の途中で前提が変わっても、いったん決めた計画をやり直す仕組みを持っていないからです。
そもそもCoT方式が向いていたのは、手順が最初から確定している定型作業でした。反対に、途中で条件が動く問い合わせ対応では、計画の誤りに気づく工程がないまま処理が最後まで進みます。
この産業機械メーカーのCS部門では実際に、顧客からの問い合わせをEinstein Copilotに対応させていました。最初に立てた手順どおりに回答を進めていたところ、途中で顧客が当初とは別の条件を持ち出したのですが、AIは最初の計画のまま古い前提で回答を続けてしまい、担当者が気づいて最初からやり直すことになりました。こうした手直しは、月におよそ50件発生していたのです。
手直しが月50件という水準は、条件が途中で変わる業務をCoT方式に任せたときの負荷の目安になります。
違い②AgentforceのAtlas Reasoning EngineがReActパターンを採用した理由
2つ目は、AgentforceのAtlas Reasoning Engineが、CoT方式に代えて、推論と行動を繰り返すReActパターンを採用した理由です。ReActとは、「推論（Reason）→行動（Act）→観察（Observe）」を繰り返し、行動の結果を確かめてから次の判断を下していく方式を指します。そしてAtlas Reasoning Engineは、AgentforceがこのReActパターンで動くために搭載している推論エンジンです。
このパターンが採用されたのは、環境を動的に再評価しながら意思決定できるようにするためです。1ステップごとに結果を観察して次を考えるため、途中で前提が変わっても、その変化を取り込んで判断をやり直せます。
たとえば、先ほどのCS部門の問い合わせ対応でも、Agentforceに任せた場面では動きが違いました。顧客が途中で条件を変えた時点で、その変化を観察し、次の推論に反映して回答を組み立て直したのです。担当者がやり直しを指示しなくても、変わった条件に合わせて対応が進みました。
対応の途中で前提が変わる業務かどうかが、ReActパターンの利点が出るかどうかを判断する基準になります。
違い③応答関連性2倍・精度33%向上という数値が示すReActの優位性
3つ目は、応答の関連性が2倍、エンドツーエンドの精度が33%向上という数値が、ReActパターンの優位性を具体的に示していることです。これらの数値が意味を持つのは、状況を見ながら判断をやり直せる仕組みが、そのまま回答の的確さに反映されるからです。
Salesforceは、Atlas Reasoning Engineの初期パイロットについて、カスタマーサービス領域で、競合製品や自社構築のソリューションと比べて応答の関連性が2倍、業務の開始から完了までを通したエンドツーエンドの精度が33%向上したと説明しています。途中で軌道修正できることが、最終的な回答の質を高めるという関係です。
※参考記事はこちら
この産業機械メーカーの場合は、CoT時代は問い合わせの途中で前提が変わると回答がずれ、担当者の手直しが月におよそ50件発生していました。ReActベースのAgentforceに切り替えてからは、条件の変更を踏まえた回答が返るようになり、手直しの回数が月30件ほどへとおよそ4割減ったという結果でした。当初は「AIの回答は結局チェックが要る」と考えていたCS部門の担当者も、任せられる範囲が広がったと受け止めるようになったのです。
反対に、手順が最初から確定している定型業務だけなら、ReActパターンへ切り替えても手直しの件数は大きく変わりません。以上が、CoTとReActの違いがEinsteinとAgentforceの能力差を生む3つの角度でした。
Agentforceの内部アーキテクチャ”Atlas Reasoning Engine”とは
ここまで、AgentforceがReActパターンで動くことを見てきました。では、その中心にあるAtlas Reasoning Engineは、内部で実際に何をしているのでしょうか。そこでここでは、Agentforceの回答がどのように組み立てられているのかを、3つの仕組みに分けて解説します。
Atlas Reasoning Engineは、単一のAIが答えを出しているのではありません。役割の異なる複数の専門LLMが分担して、1つの回答を組み立てるパイプラインとして動いています。
仕組み①8〜12の専門LLMが順次・並行に動作するパイプライン処理
1つ目の仕組みは、1つのクエリに対して、8〜12の専門LLMが順次・並行に動作するパイプライン処理です。ここでいうLLM（大規模言語モデル）とは、大量の文章を学習して自然な文章の生成や理解を行うAIを指します。Atlas Reasoning Engineは、このLLMを役割ごとに複数組み合わせて動かしています。
複数のモデルで分担するのは、一つのモデルにすべてを任せるより、工程ごとに専門のモデルが担当したほうが、精度と安全性を保ちやすいからです。Atlas Reasoning Engineが工程ごとに割り当てているモデルは、大きく3種類です。
①意図解釈・・・利用者の質問が何を求めているのかを読み取るモデル ②データ取得・・・回答に必要なCRMデータやナレッジを検索するモデル ③回答生成・・・取得した内容をもとに回答を組み立てるモデル
たとえば、この産業機械メーカーで営業担当が「この商談の次の打ち手を提案して」と一言投げかけた場面では、内部で複数のモデルが順番に、あるいは同時に処理を進めていました。担当者から見れば一つの回答でも、その内部では8〜12もの工程を経ていたのです。
※参考記事はこちら
Agentforceの回答が想定と違ったときは、どの工程のモデルでずれたのかという単位で切り分けると、原因を特定しやすくなります。
仕組み②安全性チェックとChit-Chat Detectorが担う役割の分担
2つ目の仕組みは、パイプラインの中で、安全性チェックやChit-Chat Detectorといった機能が、それぞれの役割を分担していることです。Chit-Chat Detectorとは、利用者の入力がエージェントの対応範囲内の依頼かどうかを最初に判定し、範囲外であれば設定した定型の応答を返す機能を指します。
役割分担が必要なのは、すべての入力を同じように処理すると、対応範囲外の入力にまで業務用の重い処理をかけてしまったり、逆に確認すべき安全性を見落としたりするからです。Chit-Chat Detectorの次にはQuery Evaluatorが控えており、回答に必要な情報がそろっているかを判定したうえで、足りなければ利用者へ確認を返します。
この産業機械メーカーのCS部門で顧客対応に使った場面でも、入力によって処理の流れが変わっていました。「ありがとう、助かりました」という対応範囲外の一言にはChit-Chat Detectorが働いて設定どおりの短い返答で終わり、「解約を検討している」という相談ではQuery Evaluatorと安全性チェックを通して慎重に処理が進んだのです。同じAIでも、入力の種類に応じて通す工程が切り替わっていました。
対応範囲外と判定される入力が多い場合は、エージェント側のトピック設定が業務の実態に合っていない可能性があります。
仕組み③Data CloudのRAGが回答精度を支えるグラウンディングの仕組み
3つ目の仕組みは、Data Cloud（2025年10月にData 360へ改称）のRAGが、回答をCRMデータやKnowledge記事に結びつけ、精度を支えるグラウンディングの仕組みです。RAG（検索拡張生成）とは、AIが回答を生成する前に社内のデータやナレッジを検索し、その内容を根拠として回答を組み立てる方式を指します。そしてグラウンディングとは、AIの回答を実在するデータに結びつけ、事実に基づかせることをいいます。
RAGが必要なのは、AIが学習済みの一般知識だけで答えると、事実と異なる内容をもっともらしく生成するハルシネーションを起こすことがあるからです。Data 360のRAGで自社データを参照させると、その回答がどの記録に基づいているのかを後から確認できる状態になります。
たとえば、この産業機械メーカーの営業担当が「A社向けの前回の見積もり条件は？」と尋ねた場面がありました。参照する仕組みがなければ一般論で曖昧に答えるところですが、Data 360のRAGがCRM上に蓄積されたA社の実際の商談データを検索し、その内容に基づいて具体的な条件を回答したのです。担当者が過去の記録を探し直さなくても、事実に基づいた回答が返るようになりました。
グラウンディングの精度は、参照させるKnowledge記事とCRM項目の整備状況で決まるため、導入前にどのデータを参照範囲へ含めるかを決めておく必要があります。
AgentforceはEinsteinを基盤として安全に動作する仕組み
ここまでは、Agentforceが内部でどのように回答を組み立てるのかを見てきました。その処理はすべて、Einstein Trust Layerという安全のための基盤の上で行われています。そこでここでは、AgentforceがEinsteinを基盤として安全に動作する仕組みを、3つの観点から確認します。
Einstein Trust LayerはAgentforceの送受信プロンプトに標準で介在し、機密データの保護と応答の安全性を、追加の設定なしに担保しています。
仕組み①Einstein Trust LayerがAgentforceのすべての送受信に常時介在する
1つ目は、Einstein Trust LayerがAgentforceの送受信プロンプトに標準で介在する仕組みです。Einstein Trust Layerとは、AIとやり取りされるデータやプロンプトをチェックし、安全性を確保するSalesforceの信頼基盤を指します。
標準で介在する仕組みが要るのは、生成AIを業務で使うと、顧客情報や機密データがLLMに送られる場面が避けられず、その送信時と受信時の両方でチェックを通す工程が必要になるからです。反対に、Salesforceの標準機能を経由せず外部のLLMを直接呼び出す構成にすると、このチェックの対象からは外れます。
この産業機械メーカーのCS部門でAgentforceに顧客対応を任せた場面では、顧客名や取引履歴を含むやり取りが、送信時も受信時もEinstein Trust Layerを通っていました。担当者が特別な設定をしなくても、すべてのプロンプトが自動でチェックを経ていたのです。
ただし、Trust Layerが守るのは送受信の経路であり、どの担当者にどのデータを見せるかという権限設計は、これまでどおり管理者が決める必要があります。
仕組み②動的データマスキングとゼロデータ保持でPIIを保護する
2つ目は、動的データマスキングとゼロデータ保持（Zero Data Retention）によって、PIIなどの機密データを保護する仕組みです。動的データマスキングとは、PII（個人を特定できる情報）や機密データを、LLMに送信する前に自動で伏せ字へ置き換える機能を指します。そしてゼロデータ保持とは、LLM提供事業者にデータを保持・閲覧・学習利用させないことを、Salesforceが契約で取り決めているものです。
これらが必要なのは、外部のLLMに業務データを送る以上、その情報が保持されたり学習に使われたりするリスクを、仕組みの側で断つ必要があるからです。担当者一人ひとりの注意に頼る方法では、対応の抜けを完全には防げません。送信前のマスキングと、提供事業者側での保持の禁止という2段構えで、データの経路と保存先の両方をふさいでいます。
たとえば、この産業機械メーカーで顧客の担当者名や連絡先を含む問い合わせを処理した場面では、動的データマスキングがそれらのPIIを送信前に自動で伏せ字へ置き換えていました。LLM側にデータが残らない点はゼロデータ保持の契約で担保されており、担当者が個別に気をつけなくても、機密情報が外部に残らない状態が保たれたのです。
自社で扱う情報のうちどこまでをマスキングの対象にするかを決めておくと、法務や情報システム部門との確認も進めやすくなります。
仕組み③監査証跡で全プロンプトのトランザクションを記録する
3つ目は、監査証跡（Audit Trail）によって、プロンプトのやり取りを記録する仕組みです。監査証跡とは、いつ・どのようなプロンプトが送受信され、どのデータがマスクされ、どんな安全性の判定が下されたかを記録として残す機能を指します。
記録が必要なのは、AIに業務を任せるほど、後から「なぜその回答になったのか」を確認し、説明できる状態が求められるからです。あわせて、LLMが生成した応答には有害性検出が働き、判定された毒性スコアも記録に残ります。Salesforceの開発者向けドキュメントでも、この毒性スコアリングが標準で実行されると説明されています。
※参考記事はこちら
この産業機械メーカーでは実際に、後日「あの顧客対応でAgentforceがなぜこう回答したのか」を確認する必要が生じました。監査証跡に、送受信されたプロンプト、マスクされたデータ、有害性検出による毒性スコアまでが残っていたため、担当者は経緯をたどって社内に説明できたのです。記録がなければ、AIの判断は後から追えないままでした。
監査証跡をどれくらいの期間さかのぼれるかは保存の設定で決まるため、社内規程で必要な保存期間を先に決めておくと運用に迷いません。
AgentforceとEinsteinの使い分け方
ここまで、Agentforceが安全に動作する仕組みを見てきました。では、予測やスコアリングを担うEinsteinの分析機能と、Agentforceは、実務でどう役割分担させればよいのでしょうか。そこでここでは、AgentforceとEinsteinの使い分けを3つの場面で整理します。
使い分けの基準はシンプルで、判断の材料を出すところまではEinstein、その判断をもとに複数ステップの業務を実行するのはAgentforceが担います。
下の表で、仕事の種類ごとの担い手を整理します。
| 仕事の種類 | 担うのはどちらか |
|---|---|
| 予測スコアリング・推薦・レポート生成 | Einstein |
| 複数ステップの自律実行・ハンドオフ判断 | Agentforce |
| Next Best Actionの提案から実行まで | Einstein（提案）＋Agentforce（実行） |
使い分け①予測スコアリング・推薦・レポート生成はEinsteinが担う
1つ目の使い分けは、予測スコアリング・推薦・レポート生成といった、判断の材料を出す仕事をEinsteinが担うことです。いずれも過去のデータから確率や傾向を導く分析で、算出した数値を画面やレポートに返すところまでが処理の範囲になります。
Einsteinが示すのは、人やAgentforceがそのあとにどう動くかを決めるための材料です。実際に案件を進める操作は、人かAgentforceのどちらかが引き受けることになります。スコアや予測の精度が低いままだと、そのあとの行動もずれてしまうため、まず参照するデータの整備から着手する必要があります。
たとえば、この産業機械メーカーの営業部門では、Einsteinがリードの有望度をスコアリングし、どの商談が受注に近いかを数値で示していました。営業マネージャーは毎朝そのスコアと予測レポートを見て、その日に営業40名が優先して追う商談を決めていたのです。
担当者がその出力を見てから次の操作を決めているなら、その業務はまだEinsteinの範囲にとどまっていると判断できます。
使い分け②複数ステップの自律実行・ハンドオフ判断はAgentforceが担う
2つ目の使い分けは、複数ステップの自律実行や、人への引き継ぎ（ハンドオフ）の判断をAgentforceが担うことです。ハンドオフとは、AIが対応しきれない案件を、適切な担当者へ引き継ぐことを指します。どちらも一度の分析では終わらず、状況を見ながら次の行動を選び続ける必要が生じる領域です。
分析結果を返すだけでは、その先の作業が担当者の手元に残ってしまいます。Agentforceに任せられるのは、この残りの作業を含めて、どこまでを自動で進めるかを設計できる場合です。
この産業機械メーカーのCS部門の場合は、Agentforceが顧客の問い合わせを受けて回答し、解決しなければ担当者へ引き継ぐところまでを自律的に進めていました。一次対応から引き継ぎの判断までを一続きでこなしたため、担当者は引き継がれた難しい案件だけに集中できたのです。
反対に、どんな条件で引き継ぐかを決めきれていない業務では、Agentforceに任せても担当者への引き継ぎが遅れます。
使い分け③EinsteinのNext Best ActionをAgentforceが実行に変えるユースケース
3つ目の使い分けは、EinsteinのNext Best Actionを、Agentforceが実際の実行に変えるユースケースです。Next Best Actionとは、Einsteinがデータに基づいて「次に取るべき最善の行動」を提案する機能を指します。提案だけでは担当者が動くまで成果につながらないため、提案を受けて実行するところまでを自動化する組み合わせが有効になります。
提案と実行が分かれていると、そのあいだに時間差や対応漏れが生まれます。両者をつなぐときは、Einsteinの提案をどのアクションへ渡すかを、トピックとアクションの単位で決めておかなければいけません。
たとえば、この産業機械メーカーで、Einsteinが「この顧客には保守契約の更新を提案すべき」というNext Best Actionを出した場面がありました。以前はその提案を営業担当が見て手作業でフォローメールを書いていましたが、Agentforceを組み合わせてからは、提案を受けてメールの下書きまで自動で用意されるようになったのです。提案から実行までにかかっていた平均2日ほどの時間差が、ほぼ即日に縮まりました。
提案から実行までに2日以上かかっている業務があれば、この組み合わせを検討する目安になります。
Einstein CopilotのプロンプトをAgentforceへ移行する際の注意点
AgentforceとEinsteinの使い分けを整理できると、すでにEinstein Copilotを使ってきた企業は、その設定をAgentforceへどう移すかが気になるのではないでしょうか。ただ、意思決定の方式が違うため、設定をそのまま移すだけでは期待どおりに動きません。そこでここでは、Einstein CopilotからAgentforceへ移行する際に押さえておきたい3つの注意点を整理します。
CoTベースのEinstein Copilot向けに作ったプロンプトやアクションは、ReActベースのAgentforceへそのまま移せず、トピック・アクション・指示の再設計が前提になります。
注意点①CoTベースのプロンプト・アクション設計はそのまま移行できない
1つ目の注意点は、CoTベースのEinstein Copilot向けに設計したプロンプトやアクションが、Agentforceへそのまま移行できないことです。移行の工数は、この作り直しをどこまで見込むかで大きく変わります。なぜなら、Einstein CopilotのCoT方式に最適化した指示は、ReActパターンで動くAgentforceでは意図どおりに動かないからです。
決めた手順を前提にした指示と、状況を見て行動を選ぶ前提の指示とでは、書き方の考え方が違います。移す前に、既存の指示のうちどこが手順の固定でどこが目的の記述なのかを、いったん分解しておく必要があります。
この産業機械メーカーでも実際に、Einstein Copilot時代に作り込んだ問い合わせ対応のプロンプトを、そのままAgentforceに読み込ませようとしました。ところが、決めた手順を前提にしたプロンプトはReActの動き方と合わず、期待どおりには動きませんでした。ここで、そのままでは使えず作り直しが要ると気づいたのです。
一方で、Apexや外部システム連携として作り込んだ処理は、Agentforceのアクションから呼び出す形で引き継げます。
注意点②移行時にトピック・アクション・指示を再設計する必要がある理由
2つ目の注意点は、移行時にトピック・アクション・インストラクション（指示）を再設計する必要があることです。ReActパターンのAgentforceは状況に応じて自分で行動を選ぶため、手順を固定的に並べた指示ではうまく動かず、どんなときに何を目的として動くかという判断の枠組みを渡す形に組み替えます。
手順を一つずつ指定する書き方は、決めた計画を順番に実行するCoT方式には合っていました。一方、その場で行動を選ぶAgentforceには、目的と判断基準を渡す書き方が向いています。
たとえば、この産業機械メーカーでは、Einstein Copilot時代は「まずAを確認し、次にBを実行する」と手順で書いていた指示を、Agentforce向けには「どんなときに、何を目的として動くか」というトピックとアクションの形に組み直しました。組み直しの対象は問い合わせ対応の12トピックにおよび、作業には3週間かかったのです。
既存の指示に「まず」「次に」といった順序を表す語がどれだけ含まれるかを数えると、組み直しの分量を見積もれます。
注意点③Bot-to-Agentアプローチによる段階的な移行の進め方
3つ目の注意点は、Bot-to-Agentアプローチを使うと、移行を段階的に進められることです。Bot-to-Agentアプローチとは、既存のEinsteinボットのダイアログを解析し、Agentforceのトピックとアクションへ変換する進め方で、Salesforceの機能名は「Create AI Agents From Einstein Bots」といいます。2026年8月時点でもベータ機能のままです。では、なぜ変換から始めると負担が軽くなるのでしょうか。それは、すべてを手作業でゼロから作り直すより、既存の資産を出発点にしたほうが、作り直しの範囲を絞り込めるからです。
※参考記事はこちら
変換で引き継げるのは、ダイアログの構造から起こしたトピックとアクションの骨組みまでです。会話の分岐やNLUの学習データは、そのままの形では引き継げません。
この産業機械メーカーの場合も、既存ボットのダイアログをBot-to-Agentで変換し、その結果をもとに再設計を進めました。まっさらから作るより、変換された結果に手を入れる形にしたことで、移行の工数を抑えられたのです。ただしベータ機能のため、変換された内容は必ず担当者が確認して調整しました。
以上が、Einstein CopilotからAgentforceへ移行する際の3つの注意点でした。なお、営業やCSでの具体的な活用イメージをつかみたい場合は、ほか記事「Agentforce for Sales完全ガイド」でユースケースを解説していますので、ぜひ参考にしてもらえると嬉しいです。
【一問一答】AgentforceとEinsteinの違いに関するよくある質問
最後に、AgentforceとEinsteinの違いについて検索されやすい疑問に、判断に必要な結論から順にお答えします。
AgentforceとEinsteinは、切り離して選ぶものではありません。Einsteinの判断の上にAgentforceの実行を重ねる前提で検討するのが、迷わないための基本になります。
質問①AgentforceはEinsteinなしで単体で使えるのか
完全に切り離しては使えません。Agentforceは、Data 360（旧Data Cloud）のデータ基盤とEinstein Trust Layerの上で動く前提になっているからです。利用者がEinsteinを個別に操作するというより、AgentforceがEinsteinの基盤の上で自律実行する関係だと捉えると分かりやすくなります。
質問②Einsteinだけで十分かAgentforceも必要かの判断基準は何か
境界は「行動まで任せたいかどうか」の一点にあります。予測・スコア・レポートといった判断の材料があれば足りる業務なら、Einsteinだけで十分です。一方、問い合わせ対応やフォローのように、複数ステップの実行まで自動化したい場合は、Agentforceが必要になります。
質問③AgentforceとEinsteinのどちらを先に導入すべきか
基本は、まずEinsteinの予測やスコアリングでデータの精度を確かめてから、Agentforceで実行を自動化する順序です。なぜなら、Agentforceの行動はEinsteinの判断を前提にしており、判断の精度が先に必要になるからです。判断がぶれたまま実行を自動化すると、ずれた行動が積み上がってしまいます。
質問④Agentforce for SalesとEinstein for Salesは何が違うのか
役割が違います。Einstein for Salesは、商談の予測やスコアリングなど、営業の判断を支える機能です。対してAgentforce for Salesは、リードへの一次対応やフォローなど、営業業務を自律的に実行します。なお、一次対応を担うエージェントは、Summer ’26でAgentforce SDRからAgentforce Lead Nurturingへ改称されています。
質問⑤Agentforceを使いこなすのに必要なSalesforceの前提知識は何か
トピック・アクション・指示を設計できる、基本的なSalesforce管理者の知識が出発点になります。加えて、どの業務をどこまでAIに任せるかを決める業務設計の視点が欠かせません。プログラミングの専門知識は必須ではありませんが、業務設計を伴わない設定は、担当者が日常的に使わないまま残ります。
EinsteinはAgentforceが安全に動くための基盤でありAgentforceはEinsteinの上でReActパターンで自律的に行動する
AgentforceとEinsteinの違いは、搭載機能の差にとどまらず、判断を支えるEinsteinと、その判断をもとに自律的に行動するAgentforceという、役割とアーキテクチャの違いにあります。本記事では、この違いを、Einstein CopilotのCoT方式とAgentforceのReActパターンの対比を起点に、Agentforceの内部構造、Einstein Trust Layerによる安全の仕組み、両者の使い分け、そして移行の注意点まで、一続きで整理してきました。
AgentforceとEinsteinは、どちらが優れているかを競う関係ではありません。Einsteinがデータから判断の示唆を出す基盤を支え、Agentforceがその上でReActパターンによって自律的に行動します。両者は役割を分担しており、つなげて初めて本来の価値を発揮するのです。今回例に挙げた産業機械メーカーも、Einsteinの予測で判断の精度を固めてからAgentforceに実行を任せ、問い合わせ対応の手直しを月50件から30件へとおよそ4割減らし、提案から実行までの時間差を平均2日からほぼ即日へと縮めました。
AgentforceとEinsteinの違いを理解するうえで重要なのは、Einsteinが安全に判断を支える基盤であり、Agentforceがその上で自律的に行動する存在だという役割の分担です。この関係を押さえておけば、名前の違いに惑わされずに、自社にとって必要なのが判断支援までなのか、実行の自動化までなのかを、迷わず見極められるでしょう。