Claude for Salesforce Service Cloud:2026年のすべての接続ルート

私がこの件をほとんどの人以上に気にかけている理由

私はeeselでAIエージェントを構築しており、Salesforceは私が実際に出荷するより前から要望されていた連携だった。当社の営業史上、最も明確な敗因のうち2件は、製品を気に入っていながらも去っていったミッドマーケットのサポートチームで、その理由は当時、彼らのService Cloud orgに接続できなかったからだ。そのうちの1社は月間約900件のケースを処理しており、ネイティブなSalesforceサポートがないことは取引の決定的な障害だと率直に語ってくれた。コネクタが欠けているせいで失った案件は忘れられない。

だから以下のルートが返信の送信に届く手前で止まっていると私が言うのは、競合への皮肉ではない。それはまさに私自身が何カ月も費やした壁だ。AIにSalesforceを読ませるのは造作もない。Salesforceのチケットシステムとそのガバナー制限の中で、顧客向けのメールのループを実際に閉じさせるのは難しい部分であり、「あなたのCRMにClaudeを接続する」というほぼすべての記事が省略している部分だ。

まず、どのルートもやらないこと

ここから始めよう。以下すべての内容の枠組みがここで決まるからだ。

Salesforceのホスト型MCPカタログはよく作られている。SObject Readsサーバーは6つのツールを、SObject Allサーバーは11のツールを備え、ケースは明確にスコープ内にある。Salesforce自身のサンプルプロンプトには「金融サービス業界のアカウントについて、過去7日間に開かれたすべてのケースの要約をください」といった例が含まれている。

しかし、そのカタログの中で顧客に返信する方法を探すと、専用に作られたものは何も見つからない。sendEmailもない。postCaseCommentもない。replyToCaseもない。手に入るのは、任意のオブジェクト名とフィールド値の集まりを受け取る汎用のcreateSobjectRecordだけだ。つまり返信の経路は、CaseCommentまたはEmailMessageレコードを作成し、自分のorgの自動化がそれを拾って何かを実際に配信してくれることを願うというものになる。

たいていはそうならない。その理由は、常に人々を混乱させるEmailMessageオブジェクトの癖にある。

EmailMessageを作成することは、メールが存在すると記録するだけだ。それは送信することではない。StatusフィールドはNewからReadへの遷移を除いて読み取り専用なので、「送信済み」に切り替えて完了扱いにすることはできない。実際の送信は2回目の別個の呼び出しであり、REST経由の標準アクションemailSimple、あるいはApexのMessaging.SingleEmailMessageだ。2回の呼び出し、2つの失敗モード、そしてlogEmailOnSendはデフォルトでfalseなので、今送信したはずのものがケースに表示されないことすらある。

以下のすべてのルートは、このギャップの左側で止まる。それを越えられるのは自分で書くカスタムApexかFlowだけだ。

5つのルートを並べて比較

これらのいずれも「Service Cloud向けClaude」製品ではない。Salesforceはそのようなものを一度も出荷したことがないからだ。Claudeはこれら5つの扉のいずれかを通じてケースに到達し、間違った扉を選べば四半期分のコストがかかる。そもそもネイティブスタックを使うかどうかをまだ検討している段階なら、Service Cloud向けベストAIの記事で、これらと並べてSalesforce以外の選択肢もカバーしている。

ルート1:AgentforceをClaudeに切り替える

これは人々が「SalesforceでClaudeを動かしている」と言うときに意味しているルートで、org全体に対する単一の設定だ。

Setup内、Audit, Analytics, and MonitoringのQuick Findの下、次にEinstein Audit, Analytics, and Monitoring Setup、そして「Select the Model for Agentforce」で見つかる。SalesforceのSelect Agentforce Model Optionページには、ちょうど3つの選択肢が並んでいる。

• Salesforceが推奨するSalesforce Defaultは、新しいAgentforce Builderで作成されたエージェント向けにGPT-4.1を、旧来のものにはGPT-4oを実行する
• AWS-Hostedは、Amazon Bedrock上のAnthropic Claude Haiku 4.5である
• Google Geminiは、Vertex AI上のGemini 3.5 Flashである

このリストで注目すべき点が3つある。Claudeは選択肢の1つであり、デフォルトではない。そしてSalesforce自身の推奨は依然としてOpenAIに支えられたものだ。この選択はorg全体に適用されるため、Agent Scriptでエージェントごとに上書きしない限り、Serviceを含むすべてのAgentforceエージェントに適用される。そしてこの切り替えの背後にあるモデルは小型のものだ。AWS-Hostedのオプションは2026年5月18日の週に、Claude Sonnet 4からHaiku 4.5に切り替わった。

Salesforceは切り替えの移行コストについて、清々しいほど率直だ。同じページからの引用:「Compared to OpenAI, Anthropic tends to be more sensitive to the nuances in the input payload. Anthropic returns more accurate and reliable responses if the prompts are clear, concise, and thorough.」Anthropicのプロンプトエンジニアリングのドキュメントへのリンクまで貼られている。これはそのまま受け止めるべきだ。既存のプロンプトテンプレートは再テストが必要になり、モデルの切り替えは金曜日にさっと済ませられる設定変更ではない。

コンプライアンス上の理由で切り替える場合に重要な、Salesforce自身の文章からのもう一つの注意点がある。モデルオプションを選択した後でも、サブエージェントの分類や引用といった特定のタスクは、依然としてSalesforce所有のモデルを使う可能性がある。この切り替えは完全な密閉ではなく、これは後で発見するよりもセキュリティレビューで先に指摘しておく価値のあるService Cloud AIの制限の一つだ。

実際に得られるもの

このルートの正直な魅力は、モデルの質ではなく信頼境界にある。Anthropicは、Salesforceの信頼境界の内側に完全に統合された最初のLLMプロバイダーであると主張しており、Salesforce自身のドキュメントもそれを裏付けている。Supported Modelsページでは、AnthropicとAmazon Novaのモデルのみがこのフラグを持つ。リスト上のOpenAIやGoogleのモデルはいずれも持っていない。

具体的には、Salesforceはトラフィックが自社の仮想プライベートクラウド内に留まり、少なくともTLS 1.2で暗号化され、AWS PrivateLink経由でBedrockに接続し、モデルプロバイダーは顧客データにアクセスできず、Bedrockには何も保存されないと述べている。もしあなたのorgでAIが停滞している理由がセキュリティレビューにあるなら、この一節こそがClaudeを検討すべき理由だ。それはどんなベンチマークよりもはるかに強力な論拠であり、モデルのランキング表よりもAIガバナンスの承認に役立つ。

そしてそれが何を犠牲にするか

Government CloudのorgはここでReadingをやめるべきだ。Government Cloud対応表はClaude Haiku 4.5とClaude Opus 4.5を利用不可としてリストしている。

ルート2:Prompt Builder、Apex、Models APIで特定のClaudeモデルを選ぶ

Agentforceの切り替えは1つのモデルを与えてくれる。このルートは8つを与えてくれ、特定のケース対応タスクがHaikuよりも大きな頭脳を必要とする場合に使うべきルートだ。

設定ページのSalesforceの注記は、この抜け道を説明している。Agentforceは少数のモデルオプションに限定されているが、プロンプトテンプレート、Apex、あるいはModels APIを使ったカスタムアクションは、Salesforceが管理するモデルであれ、持ち込みモデル(BYO)であれ、どのモデルでも参照できる。

つまり、Prompt Builder内のテンプレートは、エージェント自体はHaikuを実行しつつOpusを実行できる。それは、より大きなモデルに投資する理にかなった方法だ。すべての会話のすべてのターンではなく、推論の質が結果に表れる一握りのタスクに使う。ケース要約を書くことは、その明らかな候補だ。

古い名前の3つは削除ではなく再ルーティングされている。Claude3Haikuは現在Haiku 4.5に、Claude37Sonnetは2026年2月26日からSonnet 4.5に、Claude4SonnetはSonnet 4.6に着地する。1年前にAPI名をハードコーディングしていたなら、今日は静かに別のモデルを実行していることになる。

Enterprise、Performance、UnlimitedでEinstein for Sales、Platform、Serviceのアドオンを付けた場合に利用できる持ち込み(BYO)の経路もある。対応するプロバイダーはちょうど4つ、Amazon Bedrock、Azure OpenAI、OpenAI、Vertex AIだけだ。Anthropicへの直接コネクタは存在しないため、自分のClaudeを持ち込むことは、自分のBedrockアカウントを持ち込むことを意味する。それでもやる価値のあるインセンティブは実在する。SalesforceによればBYOモデルは管理型モデルに比べてEinstein Requestsの消費が30%少ないという。

誰もが引っかかる制限

これは、あなたのorgの誰かがClaudeを使ったケース要約ツールを約束する前に、付箋に書いておきたい唯一のことだ。

Einstein Trust Layerでデータマスキングを有効にすると、すべてのモデルはコンテキストが65,536トークンに制限される。Opus 4.8の100万トークンのウィンドウは、その約6パーセントにまで縮小する。フルのウィンドウを取り戻すにはマスキングをオフにする必要があるが、それはまさにClaudeを有効にした当初の目的だった機能そのものだ。

サポート業務にとって、これは実際に痛手だ。何十通ものメールのやり取り、引用された履歴、いくつかの添付ファイルを含む長いエスカレーションされたケースは、この65kトークンを超えてしまい、モデルは思っているよりも少ない範囲のスレッドしか見ていないことになる。モデルごとのレート制限も確認する価値がある。Haiku 4.5が最も厳しく毎分250リクエストで、SonnetとOpus 4.6以降は毎分1,000だ。より幅広いモデルラインアップとSalesforce外での各ティアのコストについては、当社のClaudeの料金の解説をご覧いただきたい。

ルート3:ホスト型MCPサーバー、Salesforceが自ら Claude向けガイドを書いたルート

これは最も新しいルートであり、実際に私が最初に試すルートだ。Salesforceが統合作業を代わりに済ませたうえで、手順書まで書いてくれているからだ。

ホスト型MCPサーバーは2026年4月29日にGAを迎え、Developer、Enterprise、Performance、Unlimitedのorgで利用可能だ。GA発表の枠組みはClaudeを直接名指ししている。「Whether your users live in Slack, Claude, ChatGPT, or something else entirely, MCP means they can work with Salesforce without switching contexts.」その5週間後、Salesforceは独自のClaude設定ガイドを公開した。Claude DesktopとClaude Code向けの、本物のステップバイステップガイドだ。

4つの標準SObjectサーバーがあり、すべてデフォルトでは無効になっており、管理者がいずれかを有効にする必要がある。

読み取りサーバーのツールはgetObjectSchema、soqlQuery、find、getUserInfo、listRecentSobjectRecords、getRelatedRecordsだ。ミューテーションサーバーにはcreateSobjectRecord、updateSobjectRecord、updateRelatedRecordが加わる。私が従うであろうSalesforce自身のアドバイスは、サンドボックスで読み取り専用サーバーから始めることだ。「It's read-only, risk-free, and immediately useful.」

その読み取り専用サーバーだけでも、すでに有用な作業をするには十分だ。今週最も未解決のケースが多いアカウントはどれかをClaudeに尋ね、関連する連絡先や商談を引き出させ、急増の背後にあるパターンを見つけさせる。これは他のどんな記録システムとのClaude連携とも同じ種類の価値だが、権限モデルがSalesforce自身のものである点が異なる。

セキュリティモデルこそが最も優れた部分

すべてのトランザクションは、匿名のサービスアカウントなしに認証されたユーザーとして実行される。CRUD、フィールドレベルセキュリティ、共有ルールがすべて適用され、GA発表が述べる通り、エージェントがレコードを更新すればそのユーザーの名前が監査証跡に表示される。既存のREST APIを付与することなくMCPアクセスを付与する、専用のOAuthスコープmcp_apiが存在する。

Salesforceはまた、ガードレールがどこで終わるかについても正直だ。プラットフォームのツールはreadOnlyHintとdestructiveHintのアノテーションを持つが、ベストプラクティスのページは率直にこう述べている。「Annotations are hints, not enforcement. Not all clients read or respect them.」カスタムのFlowとApexのツールは、自分でアノテーションを設定しない限り、デフォルトで潜在的に破壊的なものとして扱われる。これはほとんどのベンダーが隠したがる類の注意書きであり、ドキュメントに記載されていることをありがたく思う。

設定する

SalesforceのConfigure Claudeガイドから、完全なチェックリストを紹介する。

1. サーバーを有効化する。 Setup、MCP Serversを検索、Salesforce Serversタブ、サーバーを選択、Activate。API名とサーバーURLをコピーする。
2. External Client Appを作成する。 Salesforceはここで率直だ。「Connected Apps aren't supported.」これは、10年間このプラットフォームで構築してきた人々をつまずかせるポイントだ。
3. コールバックURLを設定する。 Claude webとDesktopにはhttps://claude.ai/api/mcp/auth_callbackを、Claude Codeにはhttp://localhost:38000/callbackを設定する。
4. OAuthスコープを設定する。 mcp_apiに加えてrefresh_tokenまたはoffline_accessを設定する。汎用のapiスコープは誤りだ。
5. Require PKCEと「Issue JWT-based access tokens for named users」にチェックを入れる。2つの「require secret」のチェックボックスは外す。
6. アプリが伝播するまで最大30分待つ。 これは文書化されており、実際にそうなる。

サンドボックスとプロダクションは、URLのセグメント1つだけ、/v1/<server>か/v1/sandbox/<server>かの違いしかない。

Claude側には、クリックできる自社製のSalesforceカードはコネクタディレクトリに存在しない。Salesforceはそこにサードパーティのアグリゲーター内にのみ表示されるため、文書化された方法はカスタムコネクタを追加し、サーバーURLを貼り付け、Advanced settingsのOAuth Client IDにExternal Client Appのコンシューマーキーを貼り付け、接続することだ。対照的にSlackは自社製のカードを持っており、それはこの2つの連携がライフサイクルのどの段階にあるかを物語っている。デスクトップアプリ側については、当社のClaude Cowork Salesforce連携の記事で扱っている。

最初の試行では多少の摩擦を覚悟しておこう。Anthropicの MCPリポジトリの未解決のissueは、OAuthが完了し、Salesforceがトークンが発行されたと確認しているのに、最初のツール呼び出しがそれでも「Authorization with the MCP server failed」を返す不具合を追跡している。複数のコメント投稿者がプロダクションのEnterprise orgでこれを再現している。コミュニティによる修正は、External Client Appのセキュリティセクションを名前付きユーザー向けのPKCEとJWTだけに絞り込み、サーバーが単に存在しているだけでなく、実際にAPI CatalogでActivatedになっていたかを確認することだ。あるコメント投稿者はこう言っている。「not a bug, it's a missing setting.」

ClaudeのツールとしてのAgentforceエージェント

Salesforceが文書化しているさらなるステップがある。AgentforceエージェントをMCPツールとして公開することで、Claudeがすでにあなたのorgを知っているエージェントに処理を委任できるようにするものだ。ドキュメント自体の例は、ケースの説明を分析し、重大度を判定し、トラブルシューティングの手順を提案し、ルーティング先のチームを特定するサポートトリアージエージェントだ。これはチケットトリアージの作業に非常によく合致し、ネイティブのボットルーティングがすでに試みていることに近い。

私の熱意を和らげる点が2つある。新しいAgent Script Builderで構築されたエージェントのみがサポートされているため、旧来のエージェントはまずアップグレードが必要であり、それはあなたのAgentforce実装に加えたそれ自体のプロジェクトになる。そしてSalesforce自身のページ間で時制の扱いが一貫していない。4月のGA発表は「soon, you'll be able to open up even more possibilities by invoking Agentforce agents via MCP」と書いているのに対し、ツールのドキュメントはすでに稼働しているかのように読める。このルートはSObjectサーバーよりも新しく、より不安定なものとして扱ってほしい。

ルート4:DX MCPサーバー、これは欲しいものではない

「Salesforce MCP server」で検索すると、まずGitHub上の@salesforce/mcpに行き着く。それが古くからあり、スター数も多いからだ。しかしこれはService Cloudプロジェクトのためのルートではない。

これはノートPC上ですでに認可済みのorgに対してstdio経由でローカルに動作し、60を超えるツールを備え、Claude CodeはREADMEにコピー&ペースト用の設定ブロックが載った、文書化されたファーストクラスのクライアントだ。ここまでは問題ない。問題は、その60個のツールが何であるかだ。

dataツールセット全体はたった1つのツール、run_soql_queryしかなく、しかも読み取り専用だ。レコード作成ツールもレコード更新ツールも、どこにもCaseツールは存在しない。残りはメタデータのデプロイと取得、Apexテストの実行、権限セットの割り当て、12個のDevOps Centerツール、そしてorgのデータではなくドキュメントを返すLWC、Aura、モバイルのガイダンス系ツールの長い裾野だ。

つまりDXサーバーは、--orgsをプロダクションに向ければSOQLでプロダクションデータを読み取ることができるが、それが上限だ。ケースを作成することも、コメントを投稿することも、何かを送信することもできない。たまたまMCPを話す開発者向けツールであり、まだBeta扱いだ。それでも使う場合に知っておくべき鋭利な点が一つある。DEFAULT_TARGET_ORGは起動時に固定されるのではなく、ツール呼び出しのたびに解決されるため、デフォルトのorgを切り替えると、サーバーがどのorgに触れられるかが静かに変わる。

ルート5:APIの上に自分で構築する

上記のいずれも合わない場合は、自分で書くことになる。これは送信ラインを越える唯一のルートであり、エンジニアをそこに投入する前に壁の形を理解しておく価値がある。

そのパターンは、新しいケースを購読し、ケースを読み取り、Claudeを呼び出し、返信を書き、送信するというものだ。この5つのステップのうち4つには制限が付いている。

読み取りとトリガー。 ケースの読み取りは、1日あたりのAPI割り当てにカウントされる。Enterpriseは100,000回の呼び出しに加えてライセンスごとに1,000回を得るため、Salesforce自身の計算例である15席のEnterprise orgでは、1日あたり115,000回に達する。UnlimitedとPerformanceは代わりにライセンスごとに5,000回を得る。トリガーについては、Platform EventsとChange Data Captureが1つの配信プールを共有する。Enterpriseでは24時間あたり25,000イベント、Unlimitedでは50,000イベントだ。

そしてChange Data Captureは、org全体で選択可能なエンティティを5つに制限する。Case、EmailMessage、CaseComment、Contact、Accountでその割り当て全体が使い果たされ、事業が他にストリーミングしたい何かのために残される余地はない。同じイベントストリーム上でさらにケース自動化も計画していたなら、その予算はすでに使い切られている。

Claudeを呼び出す。 Apexからは、トランザクションごとに100回のコールアウトと、トランザクション内のすべての呼び出しにわたって加算される120秒の累積コールアウト予算が与えられる。複数ステップにわたるエージェント的な推論は1つの同期トランザクションには収まらないため、すぐにqueueableまたはfutureメソッドに移行することになる。

最も強く噛みつく制約は順序に関するルールだ。保留中のDML操作の後にコールアウトを行うことはできない。ケースを進行中とマークし、Claudeを呼び出し、返信を書くという明白な設計は、Apexでは違法だ。それを回避するように再構築することになるが、それはこの制約にぶつかった後の話だ。

送信。 この記事の冒頭にあった2回の呼び出し問題に戻る。レコード用にEmailMessageを作成し、それから実際に送信するためにemailSimpleを発火させる。150人の受信者と、受信者フィールドあたり4,000バイトに制限されている。スレッド化はaddThreadingTokenToSubjectとaddThreadingTokenToBodyを通じてオプトインであり、これがないと、顧客の返信は古いケースを続行するのではなく、まったく新しいケースを開いてしまう。これは技術的なバグではなく、サポートチームの士気に関わるバグだ。

ノーコードのバージョンもある。Flow HTTP Callout、External Services、Named Credentialの組み合わせにより、管理者はApexなしでClaudeのAPIを呼び出すことができ、実際に機能する。その上限は、非同期コールバックがApex専用であるため、長時間実行される処理は結局コードに引き戻されてしまうことだ。

実際にかかるコスト

ClaudeはSalesforceにおいて別建ての費用項目を持たない。Agentforceのメーターを通じて課金されるからだ。そしてAgentforceのメーターには、まったく違う2つの設定がある。

Salesforceは両方を公開している。複雑さに関係なく一律の会話ごとに2ドル、あるいはFlex Creditsとしてアクションごとに20クレジット(1アクションあたり0.10ドル相当)で、100,000クレジットのパック単位で500ドルで販売される。Salesforce自身の比較チャートは、ケース管理のインタラクションを3アクションとしている。

このチャートは注意深く読んでほしい。なぜならこれは、Salesforce自身が自社の会話単位の料金体系に反論しているものだからだ。ケース管理のやり取りは、片方のメーターでは2.00ドル、もう片方では0.30ドルだ。サポート業務で会話単位の課金を使っているなら、同じ作業をクレジットで行う場合に比べておよそ7倍の料金を支払っていることになる。

自分の実際の数字を入れてみよう。

このウィジェットが前提としている2つの数字は、自分自身の契約と照らし合わせて検証すべきものだ。ケースあたりのアクション数がすべての鍵であり、3はSalesforceの例示であって、あなたのorgに関する約束ではない。そしてAgentforce 1 Serviceにユーザーあたり月額550ドルで付属する250万Flex Creditsは、年間125,000アクションに相当し、月間1,200ケース、1ケースあたり3アクションであれば、これはおよそ3年弱の余裕になる。1ケースあたり6アクションであれば、1年半未満だ。

単なる連携ではなくビジネスケースを構築しているなら、当社のAgentforceの料金の解説と、Agentforceがその費用に見合うかというより長い記事で、ここで扱う以上に席料と消費量の計算を掘り下げている。

すべての土台にある席料

すべての行に「初期価格、取引手数料が適用されます」とあり、Pro Suite以上はすべて年払いだ。ClaudeのオプションにはFoundationsまたはAgentforce 1が付いたEnterprise以上が必要なため、Agentforceで実際にClaudeを使い始める最も安い入り口は、単一のAIアクションが計測される前の時点で、ユーザーあたり月額175ドルだ。エディションの全段階は当社のSalesforceの料金の記事に、設定側の話はAgentforceの設定コストにまとめている。

現場の担当者が実際にぶつかっていること

ドキュメントは何が可能かを教えてくれる。フォーラムは何が実際に起きるかを教えてくれる。

料金について、会話単位の課金への反応はローンチ以来一貫している。

「I just cannot stomach the pricing model. Sure, $2.40 for agent might beat $15 for a human interaction, but it's much, much more expensive than the $.05 - $.10 you'd pay to make the API calls to OpenAI to do the same thing.」

u/Exotic-Sale-3003, Reddit

このコメントはFlex Creditsへの移行より前のものであり、クレジットはまさにその反論に対するSalesforceの答えだ。しかしクレジットにはそれ自体の問題があり、それは消費量に上限がないことだ。

「There are currently no native hard caps, circuit breakers, or real-time consumption alerts to automatically halt credit drain. The system prioritizes operational continuity for their servers, leaving the customer exposed to un-capped financial liability.」

Agentforce & Digital Wallet lack hard caps for async loops, Reddit

契約を結ぶ前にメカニズムを知っておく価値がある。プロダクションでの経験を持つあるコメント投稿者は、「1 action = 20 flex credits in production. Sandboxes are 80% consumption, so in sandboxes, 1 action = 16 flex credits」と説明しており、サンドボックスでのパイロットから予算を組もうとしている人には良いディテールだ。

信頼性については、私が見つけた中で最も鋭いスレッドの一つは、稼働中のキューでAgentforceのエージェントが自信満々に間違ったことをしてしまった例だ。

「The Agent accessed a internal only knowledge article and shared internal instructions on how to cancel the service. Instead of passing to a real human agent to attempt to resolve the issue, and prevent churn.」

u/Interesting_Button60, Reddit

根本原因は、すべてのナレッジ記事にアクセスできるデフォルトのretrieverを使うプロンプトテンプレートにあった。これはClaudeの問題でもOpenAIの問題でもなく、ナレッジのスコープ設定の問題であり、AIサポート導入がうまくいかなくなる、断トツで最も一般的な原因だ。また、実際の過去のケースに対してまず乾式のリハーサルをせずにライブキューへエージェントを出荷することは決してしない理由でもある。それはチケット分類の自動化を安全にするのと同じ規律だ。

構築コストもレビューに現れているが、それは容赦ないものではなく、公正なものだ。

「The learning curve is definitely real. It's a powerful platform, but getting a new agent or admin fully comfortable takes time, and the deeper configuration really benefits from someone who already knows the system well. Licensing costs can climb quickly once you start layering on additional features.」

Parth S., Senior Software Engineer, Small-Business, G2

そしてエコシステムで5年を過ごした開発者から、ルート5を苦痛にするプラットフォームの制約について:「platform limits are silly in 2025 - 6 meg max heap size for a backend transaction?????」(zdware, Hacker News)。彼が説明しているのは、Apex内で複数ステップのAIコールアウトを厄介にする、まさに同じガバナー制限だ。

私なら実際にどう判断するか

4つの状況に対する4つの答え。

すでにAgentforceのライセンスを持っていて、コンプライアンス上の理由でClaudeを使いたい。 AWS-Hostedの切り替えをオンにして、プロンプトテンプレートを再テストしよう。信頼境界に関する主張は実在し、具体的であり、パートナーシップ全体の中で最も強力な論拠だ。プロンプトの再テストには午後1回分ではなく、1スプリントを見込んでおこう。

Claudeにチームがケースを処理するのを手伝わせたいのであって、顧客に返信させたいわけではない。 サンドボックスでのplatform/sobject-reads、ホスト型MCPサーバーだ。設定は30分未満、計測されるアクションはなく、すべての呼び出しがユーザー自身の権限を伴う。これはここに挙げたどのルートよりも1時間あたりの価値が高く、金曜の午後に真っ先に試したいものだ。それはまた、ダッシュボードよりも、キューの実際の意図の内訳について多くを教えてくれるだろう。

ティア1のケースを最初から最後まで自律的にクローズできるエージェントが欲しい。 これらのルートのどれも、単独ではそこまで連れて行ってくれない。なぜならどれも返信を送信しないからだ。MCPツールの背後にカスタムApexを構築するか、すでにその壁を越えているものを購入するかのいずれかになる。Agentforceの代替案の記事は、当社自身の製品も含め、その2番目の選択肢についての正直な概観だ。

Government Cloudのorgである。 Claude Haiku 4.5とOpus 4.5は利用できない。Salesforce Defaultのオプションを前提に計画するか、ネイティブのSalesforceチャットボットがすでにカバーしている範囲を確認してみよう。

どのルートを取るにしても押し通したいパターンが一つある。ドラフトモードから始めることだ。私が同席するデモの通話全体を見ても、成功するチームはほぼ常に、数週間はAIを提案返信を書くコパイロットとして動かし、何を間違えるかを観察し、信頼できるようになってから完全な自動化に卒業するチームだ。すべてを一度にオンにするチームが、エージェントが顧客に内部の解約手順を貼り付けてしまったというRedditのスレッドの主人公になる。

Salesforce Service Cloud向けのeesel AI

このセクションが存在する理由について率直に述べておく。eeselはかつて、最もシンプルな理由でService Cloudの案件を失っていた。それは接続できなかったからだ。Salesforce連携を構築したことがその解決策であり、それはまさにこの記事全体が扱っている壁を越えるために特別に構築されたものだ。

eeselはService Cloudに参加し、ケース、連絡先、アカウントを読み取り、クローズ済みのケース履歴とナレッジ記事で学習し、そのうえで標準のMCPツールがやらないことをする。顧客向けの返信を作成して送信し、内部メモを追加し、ステータスと優先度を更新し、適切なキューにルーティングする。設定は30分未満で完了し、この連鎖にAgentforceのライセンスは含まれない。これはService CloudにおけるAIと同じ仕事であり、計測されるアクション数がないだけだ。

上記のメーターと対比して重要な違いが2つある。課金は処理したケースごとに0.40ドルであり、ケースはケースだ。あらゆる返信、あらゆるフォローアップ、あらゆる確認質問がその1回分の料金に含まれるため、難しい会話が簡単な会話より高くつくことはない。そしてすべての導入は、あなた自身の過去のケースに対するシミュレーションから始まるため、顧客が実際にそれを目にする前に、実際のチケットに対してエージェントが何を言っていたであろうかを確認できる。カードなしで50ドル分の利用枠から無料で始められる。eeselの料金をご覧いただきたい。

すでにAgentforceに深く関わっていて満足しているなら、そのまま続けてほしい。もし175ドルの席料、計測されるアクション数、そしていまだ自分でApexに書かなければならない返信経路を見つめているなら、それはeeselがあなたの午後の20分間を費やす価値がある瞬間だ。