Salesforce in Claude がベータ公開 — 営業向け37スキルと、権限を Salesforce 側に委ねる設計

要約

Anthropic は 2026-09-15、Salesforce in Claude をベータとして公開しました。Salesforce のデータを Claude から直接扱えるプラグインです。同日付で support.claude.com の Release Notes にも掲載されています。

構成は 37のスキルと2つのコネクタです。スキルは営業担当者（AE）向けで、アカウント調査、商談前準備、パイプラインレビューと予測、商談スコアリングとクローズ計画、面談後フォローと CRM 更新をカバーします。コネクタは Salesforce（データ読み取りと、アカウント要約・商談更新・通話記録などのアクション実行）と Slack（商談チャネルの要約、アカウントチームのスレッド読み書き）の2つです。

この発表で注目すべきは、スキルの本数ではなく権限の設計です。

公式が明示している条件が4つあります。利用者は自分の Salesforce 資格情報でサインインする。Claude は既存の権限レベルをそのまま尊重する。Salesforce が引き続き system of record である。既定では、変更を加える前に営業担当者の承認を求める。

この4点は、AI に業務システムを触らせるときに必ず問われる論点そのものです。 「AI は誰の権限で動くのか」「AI が勝手に書き換えないか」「正しいデータはどちらにあるのか」。実際の導入では、この3つが詰まって止まります。今回の設計は、3つとも「Salesforce 側に寄せる」という一貫した答えを返しています。

管理者側の導入手順も一度きりです。AgentExchange 経由で組織全体の Salesforce 接続を1回行い、どのグループへ配布するかを選ぶだけです。利用者ごとに接続作業は発生しません。

提供対象は**すべての有料プラン（Team / Enterprise）**で、Salesforce MCP はマーケットプレイス経由です。Team / Enterprise では既定で組織データをモデル学習に使いません。個別価格の開示はありません。

何が変わったか

• Salesforce in Claude がベータ公開。すべての有料プラン（Team / Enterprise）が対象
• 37スキル: アカウント調査、商談前準備、パイプラインレビューと予測、商談スコアリング、クローズ計画、面談後フォロー、CRM 更新
• 2コネクタ: Salesforce（読み取り + アカウント要約・商談更新・通話記録などのアクション）、Slack（商談チャネル要約、アカウントチームのスレッド読み書き）
• 管理者は AgentExchange 経由で組織単位に一度だけ接続し、グループ単位で配布する
• 利用者は自分の Salesforce 資格情報でサインインし、Claude は既存の権限レベルを尊重する
• Salesforce が system of record。既定では変更前に営業担当者の承認を求める
• Team / Enterprise では既定で組織データをモデル学習に使わない
• Salesforce MCP はマーケットプレイス経由で提供

業務インパクト（一般企業向け）

CRM を導入している企業にとって、この発表は「AI に CRM を触らせてよいか」という社内議論の参照点になります。

まず、権限を AI 側で作り直していない点が重要です。よくある失敗は、AI ツール専用のサービスアカウントを作り、そこに広い権限を与えてしまう構成です。これをやると、AI 経由なら本来見えないはずのデータが見えるという状態が生まれます。監査のときに説明できません。

今回の構成は逆です。利用者本人の資格情報でサインインし、その人の権限のままで動く。 つまり 「Claude を使ったから見られる範囲が広がる」ということが起きない。 情シスの審査に出すときに、この一文があるかどうかで議論の長さが変わります。

次に、system of record を Salesforce に置いている点です。

AI が業務システムのデータを扱い始めると、必ず「どちらが正なのか」という問題が出ます。AI が要約した内容と CRM の実データがずれたとき、どちらを信じるか。公式が「Salesforce remains the system of record」と明示しているのは、この曖昧さを最初から潰す宣言です。 社内ルールを作るとき、この原則をそのまま採用できます。

3点目が、既定で承認を求める挙動です。

商談の更新や通話記録の登録は書き込み操作です。AI が自動で書き込む設計にすると、誤登録の責任の所在が不明になります。 既定で人間の承認を挟むことで、最終的な記録の責任は担当者に残ります。この既定値を運用でオフにするかどうかは、組織として意思決定すべき項目です。 「便利だからオフにした」で事故が起きたとき、既定値がどちらだったかは効いてきます。

導入検討の実務としては、次の順序を勧めます。 (1) AgentExchange 経由の組織接続を誰が行うか決める、(2) 配布グループを絞って小さく始める、(3) 承認を求める既定値を維持したまま数週間運用する、(4) そのうえで承認を外してよい操作の範囲を決める。いきなり全社配布にすると、権限設計が正しくても運用が追いつきません。

なお、ベータである点は社内説明で明示してください。 仕様変更の可能性があり、業務フローを全面的に組み替えるのは時期尚早です。

副業・個人活用視点

個人の立場では、この製品自体を使う機会は限られます。Team / Enterprise 前提であり、Salesforce を契約している組織が対象だからです。

ただし、受託・支援の立場で見ると、ここには明確な仕事があります。

理由は、37というスキルの本数が、そのまま「営業業務の分解粒度」を示しているからです。多くの企業は、自社の営業プロセスをこの粒度で言語化できていません。「商談前準備」が1つの手順として成立するには、誰が・何を・どの順で見るかが決まっている必要があります。 決まっていない会社では、ツールを入れてもスキルに相当するものを誰も書けません。

つまり、支援側の価値は「Claude を設定できること」ではなく「営業プロセスを37個に分解できること」にあります。 これは技術力の勝負になりません。営業実務を知っている人ほど有利です。

もう1つ、権限設計の話を持ち込めることが差別化になります。

AI 導入の提案は、機能の説明で終わりがちです。そこに「利用者本人の資格情報で動かす」「system of record は既存システムに置く」「書き込みは既定で承認を挟む」という3原則を添えると、提案の性質が変わります。 Anthropic が Salesforce 連携で実際に採用している設計だ、という事実が裏づけになります。情シス・法務が同席する場では、機能の話より権限の話のほうが通ります。

Salesforce 以外の CRM を使っている企業にも、同じ構造で提案できます。 kintone、HubSpot、Zoho、あるいは自社開発の案件管理。繋ぎ方は違っても、「本人権限で動かす」「正はシステム側」「書き込みは承認」という設計原則は共通です。 具体例としてこの発表を引きながら、目の前の環境に翻訳する。これが個人規模でも成立する仕事です。

注意点を1つ。ベータ製品を前提にした提案は避けてください。 「この形が来る」という方向性の根拠としては強いですが、今日の納品物の仕様として組み込むには早すぎます。 方向性の説明材料と、実装の仕様は分けて扱うことです。