結論

  1. 1アーキテクチャ上、直接APIより「遅くなる構造」になっている
  2. 2コストは「アクション課金」の実態を見ないと見誤る
  3. 3「デフォルトのまま」だと最新世代のモデルでは動かない

「Agentforceを導入すれば、CRMがそのままAIエージェントになる」——営業資料はそう言います。実際、Salesforceのエコシステムに乗っている企業にとって、データ・権限・監査が最初から統合されている価値は本物です。

ただ、導入を検討しているなら、契約前に知っておくべき「構造」が3つあります。この記事は私が見てきた実態のうち、Salesforceの公式ドキュメント・公式エンジニアリングブログ・公式価格ページという一次情報だけで裏を取った内容です（2026年7月23日時点）。

私はAgentforceもLLMの直接APIも、実際に自分の手で実装してきましたが、Salesforceというプラットフォーム自体は今も素晴らしいと思っていますし、現在もSalesforce上の開発を続けています。この記事の動機は批判ではなく、期待値のズレで失敗する導入を減らすことです。

落とし穴1: アーキテクチャ上、直接APIより「遅くなる構造」になっている

ClaudeやOpenAIのAPIを直接叩く場合、リクエストは「自社のコード → LLM」の1ホップです。Agentforceは違います。すべてのプロンプトとレスポンスがEinstein Trust Layerを双方向で通過します。セキュアデータ取得、動的グラウンディング、セマンティック検索、プロンプトディフェンス、LLMゲートウェイ、毒性検出（7カテゴリ）、監査ログ——直接API呼び出しには存在しない処理段が、往路と復路の両方に挟まる設計です。

これは推測ではなく、Salesforce自身が認めた実害になりました。2025年、一部のエージェント応答で20秒の遅延が発生し、社内で「コードレッド」が発動されたことを同社が公式ブログで公表しています。原因の一つは、旧ランタイムでは応答のストリーミングが始まる前に4回のLLM呼び出しが必要だったこと。その最初の1回が、Trust Layerによる入力安全性チェック（プロンプトインジェクションや毒性をLLMでスキャンする処理）でした。「信頼のためのレイヤー」そのものが、体感速度を左右する初回応答時間の遅延要因だったわけです。

公平のために書くと、Salesforceは約6ヶ月かけて30以上の改善を行い、ストリーミング前のLLM呼び出しを4回から2回に半減、レイテンシを70%削減したと2026年1月に発表しています。ただし、押さえておくべき点が3つあります。

  • この数値はベンダーの自己申告であり、第三者による独立計測は見つかりませんでした
  • 改善後でも、直接API（1呼び出し）に対して2呼び出し＋パイプライン段数というハンデは構造として残ります
  • 大手小売の本番導入事例では、Salesforce自身のForward Deployed Engineeringチームが多段推論を単一呼び出しに統合する再設計を行って、ようやくレイテンシ75%削減を達成しています。裏を返せば、標準的な実装パターンのままでは、Salesforceの専門チームが乗り込んで作り直すレベルの遅さだったということです

そして意外な事実をもう一つ。Trust Layerの目玉機能であるLLM向けデータマスキングは、Agentforceのエージェントでは無効化されています。公式ヘルプに「IMPORTANT: Data masking for LLMs is disabled for agents」と明記されており、理由は「マスキングが文脈を奪い、応答精度に影響するから」。つまり「マスキングのせいで遅い」は誤解である一方、「エージェントの会話ではPIIマスキングが効いていない」という、別のもっと重い論点が存在します。セキュリティ部門への説明資料を作る前に、必ず確認してください。

落とし穴2: コストは「アクション課金」の実態を見ないと見誤る

まず公式価格（2026年7月時点）を整理します。

課金モデル価格補足
会話課金$2/会話（240円）24時間セッション単位・複雑さ問わず定額
Flex Credits$500/10万クレジット標準アクション=20クレジット=$0.10
Flex Credits（Voice）30クレジット=$0.15/アクション音声エージェント用

「$0.10/アクションなら安いのでは？」と思ったら、ここが落とし穴です。1つのユーザータスクは通常、複数アクションを消費します。Salesforce自身の公式例では、「注文はどこ？」の自己解決で2アクション（$0.20）、ケース管理で3アクション（$0.30）、フィールドサービス予約で5アクション（$0.50）。さらに1アクションの上限は1万トークンで、超過すると1万トークンごとに追加20クレジットが課金されます。未使用クレジットは契約期間で失効し、サンドボックスでのテストにも本番の80%レートで課金が発生します。

では、LLM APIを直接使う場合と比べてどれくらい高いのか。ネット上には「数万倍」という数字も流れていますが、検証した結論としてこの数字は鵜呑みにできません。数千トークン規模の対話を現行モデルの直接APIで処理すると、概ね$0.001〜$0.03程度。Agentforceの$2/会話と比べると:

  • $2 ÷ $0.01（中規模の会話）≒ 約200倍
  • $2 ÷ $0.0004（最安クラスのモデルで短い会話）≒ 約5,000倍
  • 「4万倍」に到達するには1会話$0.00005という、システムプロンプトもツール呼び出しも無視した極端な前提が必要

誠実な言い方はこうです。「数万倍」は誇張の可能性が高い。ただし数十倍〜数千倍という「桁違い」であること自体は、公式価格から計算できる事実。

もちろんAgentforceの$2にはインフラ・Trust Layer・監査ログ・ホスティング・CRM統合が含まれており、純粋なLLM原価との比較はフェアではありません。本当の比較対象は「直接API＋自前でエージェント基盤を作る開発・運用コスト」です。ただ、会話量の多いカスタマーサポートのような用途では、この単価差が損益分岐を大きく左右します。月間会話数×$2（またはタスクあたり$0.20〜0.50×件数）を先に計算してから商談に臨んでください。

落とし穴3: 「デフォルトのまま」だと最新世代のモデルでは動かない

「AgentforceのデフォルトはGPT-4」という情報が流れていますが、2026年時点の正確な姿はこうです。

  • デフォルトは「Salesforce Default」という、Salesforceが中身を管理するモデルミックス（抽象化レイヤー）
  • 公式ドキュメントはそこに「現在GPT-4oを含む」と明記
  • レガシーのAgent Builderで作られたエージェントはGPT-4oを使用

つまり「GPT-4という固定の旧モデル」ではないものの、何も設定しなければ、最新世代とは言えないモデルミックスで動くのは事実です。GPT-5系、Claude（Haiku 4.5 / Sonnet 4.5〜4.6 / Opus 4.5〜4.8。Amazon Bedrock経由のSalesforce管理で、日本リージョンの推論プロファイルもあり）、Gemini 3.5 Flashなどが選択肢として公式サポートされているのに、です。

自社でモデルを持ち込むBYOLLM（Bring Your Own LLM）も、Amazon Bedrock / Azure OpenAI / OpenAI / Google Vertex AIの4プロバイダ＋Open Connectorで公式対応しています（Anthropicへの直接コネクタはなく、ClaudeはBedrock経由）。

この落とし穴の本質は「モデルが古くて使えない」ではありません。モデル選定という重要な意思決定が、デフォルトのままではSalesforceに委ねられていることです。PoCで「精度が低い」と感じたら、まずどのモデルで動いているかを確認する。逆に言えば、モデルを明示的に選び直すだけで結果が変わる余地があります。

それでも導入すべきケース

ここまで読んで「Agentforceはダメなプロダクト」と受け取ったなら、それは本意ではありません。次の条件が揃うなら、Agentforceは合理的な選択になり得ます。

  • 顧客向けの会話チャネルをSalesforce上で完結させたい（Webチャット・WhatsApp・SMS・電話などの提供、履歴を保ったまま人へエスカレーション、会話をレコードとして残す——これらを自前で作るとコンタクトセンターの自作になります）
  • エージェント基盤を自前で開発・運用する体制がない（直接APIの安さは、基盤構築の人件費と引き換えです）
  • 会話量が限定的で、$2/会話（またはアクション課金）でも投資対効果の計算が成立する

1点目は、公式ヘルプに「収集されたメッセージや情報を含む会話履歴も次の宛先に転送されます」と明記されており、送信オムニチャネルフローで担当者やキューへ振り分けられます。会話自体もMessagingSessionレコードとして残ります。ただし権限は別問題です。 別の公式ヘルプによれば、未認証チャネルのエージェントは「エージェントが作業するために必要なすべての権限を持つ Salesforce インテグレーションユーザー」として動きます。「Salesforceに載せたから権限も監査もそのまま」とはならないので、OWDとエージェントユーザーの権限設計は自分で詰める必要があります。加えて公式は、コンテキスト変数を認証代わりに使わないよう注意しています。

逆に、会話量が多い・応答速度がKPI・最新モデルの精度が生命線、インテグレーションユーザーではなく利用者本人の権限でレコードを操作したい——という用途なら、直接APIでの構築や他の選択肢との比較検討をおすすめします。

導入前チェックリスト

  1. レイテンシ: 自社ユースケースの許容応答時間を決め、PoCで本番同等チャネル（埋め込みウィジェット等）の実測を取る。ベンダー公称値ではなく自分で測る
  2. コスト: 想定会話数・タスクあたりアクション数から月額を試算する。サンドボックス課金（80%）とトークン超過課金も忘れずに
  3. モデル: デフォルトミックスに任せず、対象業務で複数モデルを比較評価してから固定する
  4. セキュリティ: エージェントではデータマスキングが無効である前提で、PIIの取り扱いポリシーを設計する

「契約してから知る」には重すぎる構造が、確かにあります。この4項目を先に潰しておけば、導入判断の精度は大きく上がるはずです。自社のユースケースで具体的にどう詰めるか、もう少し詳しく聞きたい方は無料相談もどうぞ。

出典（注記のない限り2026年7月23日時点で確認）

※本記事のレイテンシ関連の数値（20秒・70%・75%）はいずれもSalesforce社の公表値であり、第三者による独立計測ではありません。価格は公表リスト価格で、エンタープライズ契約の実勢価格とは異なる場合があります。