Claudeforceは、2026年8月26日にSalesforceとAnthropicが発表した提携の名称です。Claude側に37種の営業スキルを載せた「Salesforce in Claude」を置き、Salesforce側のAtlas Reasoning EngineにはClaudeを推論モデルとして据える、という双方向の構成になっています。ただし2026年9月時点で手を動かせる範囲は限られます。Salesforce in Claudeは限定パイロットからオープンベータへ進む段階で、Service・Commerce・Field Serviceは提供時期が示されていません。この記事では公式発表を一次情報で切り分けたうえで、提供開始を待たずにSalesforce DX MCPサーバーでClaudeとorgをつなぎ、権限を絞って検証する手順までを示します。
まとめ|Claudeforceの提供段階と先に検証できるMCP構成の結論
Claudeforceは単一の製品ではなく、3つの流れをまとめた提携ブランドです。ClaudeからSalesforceを操作する「Salesforce in Claude」、Agentforceの推論エンジンにClaudeを入れる「Claude in Salesforce」、そしてSlack側の既定モデル化。このうち手に入るのはSales向けのプラグインだけで、公式のClaudeforceページではService・Marketing・Commerce・Revenue・Field Service・Tableau・MuleSoft・Informatica・Industriesがいずれも「近日提供」と表記されています。日付は入っていません。
価格も確定していません。2026年8月26日のプレスリリースには「価格およびパッケージは変更対象」と注記があり、ライセンス体系の記載もありません。つまり今の段階でできるのは、稟議を通すことではなく、自社orgのデータと権限がAIから触られる形になっているかを確かめることです。
その検証には、Claudeforceを待たずにSalesforce公式のDX MCPサーバーが使えます。npx -y @salesforce/mcp を起動し、--orgs にaliasを明示して本番orgを外す。これだけで、Claude Codeから自社のメタデータとレコードをどこまで読めるかが当日わかります。Sales CloudとSlackが主戦場ならベータを追う価値はあるでしょう。Service・Commerce中心の組織やApexにロジックが集中している組織は、待つより先にMCPで自前の接続を組んだほうが早く答えが出ます。
Claudeforceの3本柱と37の営業スキルが実際に動く場所
発表資料を読むと、Claudeforceという1つのプロダクトが出荷されるわけではないことがわかります。Claude側に載るもの、Salesforce側に載るもの、Slackに載るもので提供形態も時期も別々です。
Salesforce in Claudeが担う営業スキル37種の内訳
Salesforce in Claudeは、Claudeのチャット画面に入るプラグインです。プレスリリースには37個のプリビルトスキルが載ると明記され、商談準備・ディール健全性レビュー・パイプラインレビューが例として挙がっています。公式ページ側ではこれらが日次週次のワークフロー、案件戦略、顧客管理、準備支援、アクション実行という括りで整理されています。
| 区分 | 公式スキル名 | 生成される成果物 |
|---|---|---|
| 日次の運用 | Daily Briefing | 当日の優先案件リスト |
| 週次の運用 | Pipeline Review | パイプラインの差分 |
| 案件戦略 | Close Plan | 受注までの工程案 |
| 顧客管理 | Lead Triage | 見込み客の優先順 |
| 実行記録 | Log Activity | CRMへの活動登録 |
| 衛生管理 | SFDC Hygiene Check | 入力不備の検出 |
ここで注意したいのは、スキルの粒度が「営業担当者1人の1日の動き」に寄っている点です。Log ActivityやSFDC Hygiene Checkは現場の入力作業を肩代わりする位置づけで、入力率が低いorgほど効きます。ただし項目設計が崩れていれば、AIが埋める値も崩れる構造です。提供時期は限定パイロットを経て2026年9月のオープンベータ、追加スキルは2026年後半からの段階提供と公表されています。
Claude in SalesforceとSlack統合で変わる作業導線
もう1つの向きが、Salesforce製品の内側でClaudeが推論を担う構成です。プレスリリースでは、ClaudeがAtlas Reasoning Engineの推論モデルとして動き、Agentforce VibesとAgentforce Coworkerの既定モデルになり、Agent Builderからも選べると書かれています。Salesforce側のエージェント基盤を触っている組織にとっては、モデル差し替えという形で影響が来ます。
Slackは3つ目の入口です。Claudeが既定モデルになり、Claude TagとSlack Codeが用意されます。Anthropic側の発表では、SlackのMCPサーバーを通じてClaudeがチャネル・メッセージ・ファイルへアクセスし、会話の要約や決定事項の抽出を行うと説明されています。この基盤にはHeadless 360・MCP・Data 360・MuleSoftが並ぶ。画面を持たないAPI前提の構成が土台です。Salesforce側の構造はHeadless 360が変えるSalesforce運用とエージェント前提設計の全体像で整理しました。
Atlas Reasoning EngineのClaude採用とSlackの既定モデル化
モデルが差し替わるという話は、実装者にとってはプロンプトとガードレールの再検証を意味します。どこまでが自動で変わり、どこからが自分の設定なのかを分けておきます。
Agentforce Vibes・Coworkerでの既定モデル切替の範囲
既定モデルが変わるのはAgentforce VibesとAgentforce Coworkerです。Agent Builderでは選択肢として提供されるという書き方になっており、既存のエージェント定義が黙って書き換わるわけではありません。逆に言えば、Agent Builderで組んだエージェントは自分で切り替えない限りそのままです。既存のトピック定義とアクションの動作差分は、切り替え後に自分で確かめる作業になります。
モデル世代そのものの差は別の話として押さえておく必要があります。Claudeのモデル系列は世代ごとに破壊的変更を含むことがあり、移行判断はモデル側の仕様で決まります。世代間の差分はClaude Fable 5.1とはで整理しました。Agentforce側の既定が変わったときに、プロンプトの長さ制限やツール呼び出しの挙動がどう動くかは、そちらの仕様を前提に読むことになります。
Amazon Bedrock経由のTrust Boundary内実行という条件
規制業界での採用可否を分けるのが、どこでモデルが動くかという点です。プレスリリースには、Amazon Bedrock経由でSalesforce Trust Boundaryの内側でClaudeを使える構成が示されています。Anthropic側の発表では、AnthropicがSalesforceのトラストバウンダリーに完全統合された最初のLLMプロバイダーであり、Claudeの全トラフィックがSalesforceの仮想プライベートクラウド内に収まると説明されています。
想定業界として挙がっているのは金融サービス、医療、サイバーセキュリティ、ライフサイエンスの4つです。日本の金融機関で稟議を通す場合、この「VPC内に収まる」という記述が審査の入口になります。ただし現時点では英語の発表文しか根拠がなく、国内リージョンでの提供条件やデータ所在地の明記はありません。ここを未確認のまま設計に入れると後で覆ります。
Salesforce DX MCPサーバーをClaude Codeに接続する手順
Claudeforceの提供を待つ間でも、ClaudeからSalesforce orgを操作する経路そのものは既に公開されています。Salesforce公式のDX MCPサーバーです。ここからは実際に動かす手順に入ります。
sf org loginとnpx起動でMCP接続を通すまでの3工程
前提として、MCPサーバーがorgへ触る前に、そのorgをローカルで認可しておく必要があります。公式リポジトリのREADMEには、Salesforce CLIの org login web コマンド、またはVS Codeの SFDX: Authorize an Org を使うと明記されています。認可されていないorgはMCP側から一切見えません。次の3行で、認可・既定org設定・サーバー起動まで通ります。
sf org login web --alias sandbox-sales
sf config set target-org sandbox-sales
npx -y @salesforce/mcp --orgs sandbox-sales --toolsets orgs,data
1行目のaliasは後で --orgs に渡す識別子になるので、本番と取り違えない名前を付けます。3行目の -y は npx にインストール確認を省かせる指定で、READMEには変更しないよう注記があります。パッケージは npmの @salesforce/mcp、latestは2026年9月20日時点で 0.30.15 系でした。
mcpServers設定に書くcommandとargsの実際の値
MCPクライアント側の設定は、クライアントごとにファイル名が違うだけで args の書式は共通です。Claude Codeならプロジェクト直下の .mcp.json に次の形で書きます。フラグ名と値の両方をダブルクォートで囲み、カンマで区切るのが公式の指定です。
{
"mcpServers": {
"Salesforce DX": {
"command": "npx",
"args": ["-y", "@salesforce/mcp",
"--orgs", "sandbox-sales",
"--toolsets", "orgs,data,metadata"]
}
}
}
VS Code with Copilot では同じ内容を .vscode/mcp.json に書きますが、最上位キーが mcpServers ではなく servers になります。Clineなら cline_mcp_settings.json に置き、公式例ではパッケージ名に @latest が付いています。プロトコル側の仕組みはMCP(Model Context Protocol)とはで解説しました。
orgsとtoolsetsで権限を絞るMCP設定と本番orgの扱い
ここが検証で最も事故りやすい場所です。MCPサーバーは認可済みorgに対して読み書きの両方を行えるため、渡す値の選び方がそのままリスクの大きさになります。
ALLOW_ALL_ORGSを避けてalias指定に固定する判断基準
--orgs に渡せる値は4種類です。READMEは ALLOW_ALL_ORGS について「慎重に使用」と明記しています。受託開発の現場では、この値を選ぶ理由がまずありません。
| 指定値 | 許可されるorg | 実務での扱い |
|---|---|---|
| ALLOW_ALL_ORGS | 認可済みの全org | 本番が入るため不可 |
| DEFAULT_TARGET_DEV_HUB | 既定のDev Hub | スクラッチorg生成用 |
| DEFAULT_TARGET_ORG | 既定のorg | 毎回動的に解決される |
| ユーザー名またはalias | 指定した1つのorg | 固定したいときはこれ |
見落としやすいのが3行目の挙動です。READMEには、DEFAULT_TARGET_ORG と DEFAULT_TARGET_DEV_HUB はサーバー起動時に固定されず、ツール呼び出しのたびに作業ディレクトリごとの既定orgとして解決し直されると書かれています。ディレクトリを移動しただけで接続先が変わる。固定するならaliasを直接渡します。
toolsets16種のうち本番運用で残す範囲と用途別の切り分け方
toolsetsは16の値を取り、core だけは常時有効です。READMEには全ツールを有効にするとLLMのコンテキストを圧迫するという注意があり、全有効時は60を超えるツールが載ると書かれています。検証段階で入れる順序は次のとおりです。
orgs:認可済みorgの一覧と切り替え。最初に入れるdata:レコードの照会と更新。読み取りの当たりを見るmetadata:メタデータの取得と配備。差分確認に使うtesting:Apexテストの実行。CIに寄せる段階で足すcode-analysis:Code Analyzerによる静的解析
残りの lwc-experts・aura-experts・mobile・devops・enrichment は、案件の作業内容に合わせて後から足します。最初から all を指定すると、一覧が長くなるぶんモデルが誤ったツールを選びやすくなる。絞ったほうが精度は上がります。
Claudeforceと既存のAgentforce 360構成の重なりと差
すでにAgentforceを検討している組織からは、Claudeforceが別物なのか上位互換なのかという質問が出ます。ここは役割が違うと整理したほうが混乱しません。
Agentforce 360側で作るエージェントとの役割分担の線引き
Agentforce 360は、Salesforceの内側で動く自律エージェントを作る基盤です。トピックとアクションを定義し、権限とガードレールをSalesforceの仕組みで縛ります。対してSalesforce in Claudeは、Claudeという外側のクライアントからSalesforceのデータを読んで人間の作業を助けるものです。業務を自動で回すのがAgentforce、人が判断する場を移すのがSalesforce in Claude、という分け方になります。金融業界向けの製品構造は金融DX担当者が押さえるべきAgentforce 360の基本構造と位置づけにまとめています。
重なるのは推論モデルの層だけ。Atlas Reasoning EngineがClaudeを使うようになっても、エージェントの定義・権限・監査はAgentforce側の仕組みのままです。発表を受けてAgentforceの設計をやり直す必要はありません。
Flex Credits単価から出すエージェント実行コストの試算
Claudeforce自体の価格は未公表ですが、Agentforce側の課金は公式の料金ページで公開されています。実行回数で積む構造なので、PoCの段階で概算を出しておけます。
| 課金要素 | 公式表記の単価 | 条件 |
|---|---|---|
| Flex Credits | 500ドル / 10万クレジット | 通貨別の設定あり |
| 標準アクション1回 | 20クレジット | 約0.1ドル相当 |
| 音声アクション1回 | 30クレジット | 約0.15ドル相当 |
| Agentforce 1 Editions | 550ドル / ユーザー / 月 | 年250万クレジット込 |
| Agentforce アドオン | 125ドル / ユーザー / 月 | 業種版は150ドル |
| Agentforce User License | 5ドル / ユーザー / 月 | Flex Credits必須 |
| Conversations | 2ドル / 1会話 | クレジットと併用不可 |
営業50人が1日20アクション動かすなら、月20営業日で20万アクション、400万クレジットで2万ドル前後。Agentforce 1 Editionsに含まれる年250万クレジットは、この規模だと2か月弱で尽きる計算です。PoCの評価軸に「1アクションあたりの削減時間」を入れておかないと、本番移行の稟議で単価だけが議論になります。
Claudeforceを待つ案件と自前MCP実装で先行する案件の線引き
ここは条件を付けて言い切ります。2026年9月時点で、Claudeforceを前提に計画を組んでよい案件とそうでない案件は、はっきり分かれます。
Claudeforceの提供開始を待つ判断が成立する前提条件
待つ側に回ってよいのは、次の3つが同時に成り立つ場合だけです。第一に、営業プロセスがSales Cloudに寄っていること。37スキルはSales向けで、Serviceもfield Serviceも提供日が出ていません。第二に、Slackが全社の主要チャネルであること。Claude TagとSlack Codeの価値は、会話がSlackに集まっている前提で初めて出ます。第三に、2026年後半まで着手を遅らせても事業計画が壊れないこと。
この3つが揃わないなら、待つ判断は取りません。価格が「変更対象」と注記されたままの状態で予算を確保すれば、稟議のやり直しを生みます。提供時期が示されていない製品を前提に、既存のCRM改修を止めるのは損です。
自前のMCP実装へ倒す案件の判断条件と着手を見送るべき3場面
自前でMCPサーバーを立てる方向に倒すべきなのは、業務の中心がSales以外にある場合、カスタムオブジェクトとApexにロジックが集中している場合、そしてデータがSalesforce外の基幹システムにも分散している場合です。いずれもプリビルトの37スキルでは届きません。公式のDX MCPサーバーを使い、足りないツールを自社のMCPサーバーで足す構成が現実的な着地です。org構成やApexの棚卸しから入る必要があるなら、Salesforce導入支援サービス・Apex開発で設計から引き受けています。
逆に、次の3つに当てはまるなら着手そのものを見送ります。1つ目は、プロファイルと共有ルールが実態と合っていないorg。権限設計が崩れた状態でAIを乗せると、見えてはいけないレコードがそのまま要約に出ます。2つ目は、Sandboxを用意せず本番orgへ直接つなごうとする案件。--orgs にaliasを固定する運用が守れないなら、検証の前提が成立しません。3つ目は、評価指標が「動いた」しかないPoC。削減時間か入力率か、数字を先に決めていない検証は本番に進みません。
よくある質問
Claudeforceについて多く見られる質問に、公式発表の記載範囲で答えます。書かれていない部分は推測せず、未公表として扱いました。
Claudeforceはいつから使えますか?
2026年8月26日の発表時点で、Salesforce in Claudeは限定的なパイロット顧客向けに提供されており、2026年9月にオープンベータが予定されています。追加スキルは2026年後半から段階的に提供開始とされています。Service・Marketing・Commerce・Revenue・Field Service・Tableau・MuleSoft・Informatica・Industriesの各領域は公式ページで「近日提供」と表記されるのみで、具体的な日付や日本法人での提供条件は出ていません。
Claudeforceの料金はいくらですか?
公表されていません。2026年8月26日のプレスリリースには「価格およびパッケージは変更対象」という注記があり、ユーザー単価やクレジット消費量の記載もありません。参考になるのはAgentforce側の既存料金で、Flex Creditsが10万クレジットあたり500ドル、標準アクション1回が20クレジットです。Claudeforceがこの体系に乗るかも未公表のため、予算化ではAgentforce側の数字を暫定値として置く扱いになります。
ClaudeforceとAgentforceの違いは何ですか?
Agentforceは、Salesforceの内側で自律的に動くエージェントを作る基盤です。トピックとアクションを定義し、Salesforceの権限とガードレールで縛ります。Claudeforceは提携全体の名称で、その中のSalesforce in ClaudeはClaudeのチャット画面からSalesforceのデータを読む外向きのプラグインです。重なるのは推論モデルの層だけで、ClaudeがAtlas Reasoning Engineに入り、Agentforce VibesとCoworkerの既定モデルになります。エージェントの定義や監査の仕組みは変わりません。
Claudeforceを使わずにClaudeとSalesforceを連携できますか?
連携は可能です。Salesforce公式のDX MCPサーバーが @salesforce/mcp として公開されており、Claude Codeの .mcp.json に command と args を書けば接続できます。事前にSalesforce CLIの org login web でorgを認可しておく必要があります。toolsetsは16値から選べ、core は常時有効。全ツールを有効にすると60を超えるツールが載るため、READMEでも用途に応じた絞り込みが推奨されています。
金融機関でもClaudeforceを検討できますか?
公式発表では、Amazon Bedrock経由でSalesforce Trust Boundaryの内側でClaudeを動かす構成が示されています。Anthropic側の発表では、Claudeの全トラフィックがSalesforceの仮想プライベートクラウド内に収まると説明され、想定業界として金融サービス・医療・サイバーセキュリティ・ライフサイエンスが挙がっています。ただし国内リージョンでの提供条件とデータ所在地の明記は現時点でなく、審査の段階では個別確認が必要です。
関連記事
- 金融DX担当者が押さえるべきAgentforce 360の基本構造と位置づけ:内側のエージェント基盤を業界要件から整理
- Headless 360が変えるSalesforce運用とエージェント前提設計の全体像:Claudeforceの基盤側の設計思想
- MCP(Model Context Protocol)とは:DX MCPサーバーが乗るプロトコルの仕組み
- Claude Fable 5.1とは:既定モデルが変わるときに見る仕様差分
- mitoco AIとは:Salesforce上で動く別系統の生成AI製品