Salesforce Agentforce と Einstein の違い｜検討時の地図の作り方

Salesforceが発表した「Agentforce」は、これまでのAI活用を根本から変えるパラダイムシフトを提示しています。しかし、従来の「Einstein」や「Einstein Copilot」との違いが曖昧なまま、どのように導入を検討すべきか迷っている実務担当者も少なくありません。

本記事では、SalesforceにおけるAIブランドの変遷を整理し、AgentforceとEinsteinの技術的な差異、そして導入時に失敗しないための「検討の地図」を実務視点で詳説します。

1. Salesforce Agentforce と Einstein の本質的な違い

1.1 「Copilot（支援）」から「Agent（自律）」へのパラダイムシフト

最大の違いは、AIが「人間の指示を待って動くか（副操縦士）」か、「目的を与えられて自ら判断して動くか（自律型エージェント）」かにあります。

• Einstein Copilot（従来のAIアシスタント）：ユーザーがチャットで依頼した内容に対し、メールの下書き作成やデータ要約を行います。常に人間が起点となります。
• Agentforce（自律型エージェント）：特定のビジネスゴール（例：返品対応を完遂させる、リードの商談化を促進する）を与えられると、必要なデータをData Cloudから取得し、FlowやApexコードなどの「アクション」を自ら組み合わせて実行します。

1.2 ブランド構成の整理：EinsteinはAIの総称、Agentforceは自律実行の器

誤解されやすいですが、Einsteinという名称が消えるわけではありません。EinsteinはSalesforceにおける「AI技術の総称」であり、その進化系として自律的な動作を司るプラットフォームが「Agentforce」と定義されています。従来の予測AI（Einstein Prediction Builder）などは引き続きEinsteinブランドとして提供されます。

1.3 意思決定の仕組み：推論（Reasoning）エンジンの有無

Agentforceが画期的なのは、「Atlas 推論エンジン」を搭載している点です。従来のAIは単一のプロンプト（命令文）に対して回答を生成するだけでしたが、Atlasはユーザーの意図を解釈し、複雑なタスクをステップに分解。最適なアクションを動的に選択して実行する能力を持っています。

こうした高度な自動化を検討する際、まず理解しておくべきは周辺ツールとの責務分解です。以下の記事では、CRMやMAの全体設計について解説しています。

【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

2. Agentforce と Einstein の機能・仕様比較表

検討にあたり、従来の機能と新しいAgentforceの違いを一覧で整理します。

}

2.1 主要機能とユースケースの比較

Einsteinは「この商談の成約確率は？」といった予測や、「この議事録を要約して」といった生成に強みを持ちます。一方、Agentforceは「お客様からの配送状況の問い合わせに対し、基幹システムのデータを参照し、配送会社に状況を確認した上で、最適な再配送オプションを顧客に提示し、合意を得てレコードを更新する」といった、プロセス横断的な完遂に向いています。

2.2 料金体系と利用コストの考え方

Agentforceの料金体系は、従来のユーザーライセンス型とは異なり、会話やアクションの実行回数に応じた課金モデルが導入されています。具体的な単価（例：1会話あたり2ドル〜）は契約条件やボリュームによって変動するため、最新の料金についてはSalesforce公式製品ページを確認してください。

コストを最適化するためには、不要なSaaSライセンスを整理し、AIへの投資余力を生み出すことが重要です。

SaaSコストを削減。フロントオフィス＆コミュニケーションツールの「標的」と現実的剥がし方【前編】

3. Agentforce 導入に向けた「検討の地図」の作り方

Agentforceを「魔法のツール」として導入しようとすると失敗します。以下のステップで検討を進める必要があります。

3.1 STEP 1：Data Cloud によるデータ基盤の整備

Agentforceが「賢い判断」を下すためには、正しいデータへのアクセスが不可欠です。Salesforce内の構造化データだけでなく、外部ストレージ（S3, Google Cloud Storage等）に眠るPDFの仕様書や過去のやり取りを、Data Cloudに統合し、ベクトル化してAIが読み取れる状態（RAG準備）にする必要があります。

3.2 STEP 2：標準エージェント（Service/Sales）の試用

ゼロから構築する前に、Salesforceが提供する「標準エージェント」が自社の要件をどこまで満たすか評価します。例えば、Service Agentはカスタマーサポートの一般的なFAQ対応をすぐに開始できるようプリセットされています。

3.3 STEP 3：カスタムエージェントのトピック・アクション定義

標準機能で足りない場合、Agent Builderを使用してカスタムエージェントを作成します。ここで重要なのは「トピック（何についてのエージェントか）」と「アクション（何ができるか）」を定義することです。アクションには既存のSalesforce Flowがそのまま利用できるため、現場の業務ロジックを流用することが可能です。

データ基盤の構築については、必ずしも高額な専用ツールを買い揃える必要はありません。以下のガイドが参考になります。

高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

4. Agentforce を支える技術的アーキテクチャ

4.1 Einstein Trust Layer によるセキュリティ担保

企業がAIを導入する際の最大の懸念は「データの漏洩」と「モデルの学習への流用」です。AgentforceはEinstein Trust Layer上で動作しており、以下の保護策が自動で適用されます。

• データマスキング：PII（個人情報）を検知し、LLMに送る前に隠蔽。
• ゼロリテンション：外部のLLMプロバイダー（OpenAI等）にデータが保存・学習されないことを保証。
• 監査ログ：AIとのやり取りをすべて記録し、ガバナンスを確保。

4.2 Data Cloud との連携：RAG（検索拡張生成）の重要性

Agentforceの推論エンジンは、回答を生成する前にData Cloudへ検索（Retrieval）をかけ、最新の事実をコンテキストとして取得します。これにより、AIが不確かな回答をする「ハルシネーション」を大幅に抑制できます。

5. 実装時の注意点とよくあるエラー・対処法

5.1 「何もしてくれない」エージェントを避けるための指示（Instruction）設計

よくある失敗が、エージェントへの指示（Instruction）が曖昧なケースです。「顧客をサポートしてください」といった漠然とした指示ではなく、「まず顧客番号から契約ステータスを確認し、解約猶予期間内であれば特別オファーのFlowを呼び出してください」といった、ロールと手順を明確にする必要があります。

5.2 権限設定（権限セット）の不備による実行エラー

Agentforceが特定のアクション（FlowやApex）を実行しようとしてエラーになる原因の多くは、「Agentforce Service User」などの実行ユーザーに対する権限不足です。AIがアクセスするすべてのオブジェクトおよびクラスに対して、適切な権限セットが割り当てられているか確認してください。

よくあるエラーメッセージ： “I’m sorry, I don’t have permission to access that information.”

対処法： 設定画面の「エージェントユーザーの権限」から、必要なオブジェクトの「表示」「作成」「編集」権限を付与してください。

6. まとめ：自社にとっての「最適解」を見極める

Salesforce Agentforceは、単なるAIチャットボットではなく、Salesforceプラットフォームのデータとロジックを自律的に動かすための強力な「実行エンジン」です。既存のEinstein機能が「個人の生産性」を高めるものだとすれば、Agentforceは「組織のプロセス」自体を自律化させるものと言えます。

検討の第一歩は、Data Cloudによるデータ統合の現状を把握することです。土台となるデータが整っていれば、Agentforceは導入直後から強力なビジネスパートナーとなるでしょう。