SlackとSalesforce連携とは？権限設計・Integration User・Agentforce連携の注意点
SlackとSalesforceを連携すると、営業担当はSlack上で顧客情報を確認したり、レコード更新の通知を受けたり、AgentforceエージェントにSalesforceデータを使わせたりできます。便利な一方で、設計を誤ると「Salesforceでは見せていないつもりの情報が、Slackのチャンネル名やプレビューで見えてしまう」という別のリスクが生まれます。
特にAgentforceやSlackbotまで含める場合、Slack連携は単なる通知連携ではなく、Salesforceの権限、Connected App、Integration User、ユーザーIDマッピング、MCPサーバーをまたぐ設計になります。2026年6月24日にSalesforce Architecture Blogが公開した解説でも、Slack連携を安全に運用するには、接続前にID解決と権限スコープを設計する必要があると整理されています。
結論として、SlackとSalesforce連携では「誰の権限でSlackに情報が出るのか」を最初に決めるべきです。Integration Userは連携全体の上限権限を作り、個別ユーザーのSalesforce権限は本人が実行できる操作を制限します。さらに、レコードチャンネル、レコードプレビュー、Agentforce in Slack、SlackbotのMCP接続では実行主体が少しずつ異なるため、同じSlack連携としてまとめて有効化すると、意図しない表示や過剰権限が起きやすくなります。
本記事のポイント
- SlackとSalesforce連携は、接続手順よりもIntegration User、OAuthスコープ、ユーザーIDマッピングの設計が成否を分けます。
- レコードチャンネルとレコードプレビューはSlack上の見え方が異なり、閲覧者本人ではなく共有者やIntegration Userの権限で情報が出る場面があります。
- AgentforceやSlackbotを接続する前に、標準接続、MCPサーバー、Agentforceエージェントのどれに何を任せるかを切り分ける必要があります。
この記事で扱うテーマ
関連キーワード
- Slack Salesforce 連携
- Slack Salesforce 権限
- Salesforce Slack Integration User
- Salesforce Slack レコードプレビュー
- Agentforce Slack 連携
- Slackbot Salesforce MCP
- Salesforce connected app Slack
- Salesforce Slack セキュリティ
このページで答える質問
- SlackとSalesforce連携で最初に設計すべき権限は何ですか？
- SalesforceのIntegration UserはSlack連携でどのような役割を持ちますか？
- Slackのレコードチャンネルとレコードプレビューは何が違いますか？
- AgentforceをSlackで使う前に確認すべきことは何ですか？
SlackとSalesforce連携は3層で分けて考える
SlackとSalesforce連携を設計するときは、まず機能を3層に分けると整理しやすくなります。1つ目は、SlackワークスペースとSalesforce組織をつなぐ標準接続です。これはConnected App、OAuthスコープ、Integration User、ユーザーIDマッピングを含む基盤部分です。
2つ目は、Slack上にSalesforceレコードをどう見せるかです。Salesforceレコードに紐づくチャンネル、Salesforce URLを貼ったときのレコードプレビュー、通知カードなどが該当します。ここでは「Salesforce上で見えるか」だけでなく、「Slack上でチャンネル名やプレビューとして残ってよいか」を別に判断する必要があります。
3つ目は、SlackからAIや自動化を動かす層です。AgentforceエージェントをSlackに出す、SlackbotがSalesforceレコードを検索・更新する、MCPサーバー経由で操作範囲を絞る、AgentforceエージェントをMCPツールとして公開する、といった使い方がここに入ります。これはAgentforce 360やSalesforce Headless 360の実務接点として見ると理解しやすい領域です。
| 層 | 主な論点 | 最初に決めること |
|---|---|---|
| 標準接続 | Connected App、Integration User、OAuthスコープ、IDマッピング | 連携の上限権限とユーザー識別方法 |
| レコード表示 | レコードチャンネル、チャンネル名、レコードプレビュー | Slackに表示してよい項目とチャンネルの公開範囲 |
| AI・自動化 | Agentforce in Slack、Slackbot、MCPサーバー | 標準接続で足りる操作と、MCPで絞る操作の分担 |
この3層を分けずに「Slack連携をオンにする」とだけ進めると、営業現場は便利になりますが、どこでどの権限が使われているかを後から説明しにくくなります。特に顧客名、商談名、金額、課題、契約条件のように、本文よりもタイトルや要約の方が敏感な情報では注意が必要です。
Integration Userは連携全体の上限権限になる
Salesforce公式ブログでは、SlackとSalesforceの基本接続はSlack管理者側から開始し、Salesforce管理者側で承認されると説明されています。この承認により、Salesforce組織側にはConnected Appが作られ、OAuthスコープとIntegration Userを通じて接続の権限範囲が決まります。
Integration Userは、Slack連携がSalesforceプラットフォーム上で動くときの基礎となるIDです。ここに広すぎるプロファイルや権限セットを与えると、Slack側の通知やプレビューで扱える情報の上限も広がります。Salesforce公式ブログでは、API Onlyのユーザープロファイルから始め、必要なオブジェクト権限だけを積み上げる考え方が示されています。
重要なのは、Integration Userに全ての営業データを見せれば現場が便利になる、という単純な話ではないことです。個々の営業担当がSlackから操作するときは、本人のSalesforce権限も効きます。しかし、管理者が作る通知や一部のプレビューではIntegration Userの権限が表示内容に影響します。つまり、Integration Userは「Slack連携の裏側で使う技術ユーザー」ではなく、Slackに出てよい情報の上限を決める設計要素です。
ユーザーIDマッピングはメールアドレスだけで決めない
SlackユーザーとSalesforceユーザーを対応付けるには、メールアドレスやFederation IDのような一意の識別子を使います。小規模な会社ではメールアドレスで十分に見えますが、買収、子会社、外部委託、複数ドメイン、退職者再入社が絡むと、同じ人を同じ人として扱えるかが問題になります。
営業組織でSlackとSalesforceを連携するなら、少なくとも次の点を先に確認します。
- SlackとSalesforceでユーザーのメールアドレス体系が一致しているか。
- 外部パートナーや派遣メンバーをSlackに入れている場合、Salesforceユーザーとしても同じ扱いにしてよいか。
- SSOやIdPを使っている場合、Federation IDを主キーとして使えるか。
- 退職・異動時にSlack側とSalesforce側の無効化タイミングがずれないか。
CRMデータの整合性そのものに課題がある場合は、Slack連携の前にCRMが更新されない原因やCRM・SFA・MAの役割分担を見直した方が、連携後の手戻りを減らせます。
レコードチャンネルとレコードプレビューは別のリスクを持つ
Slack上でSalesforceレコードを扱うときに見落としやすいのが、レコードチャンネルとレコードプレビューの違いです。どちらもSalesforceの情報をSlackに出す機能ですが、見える範囲とリスクの出方が異なります。
レコードチャンネルはチャンネル名にも注意する
レコードチャンネルは、Salesforceの特定レコードに紐づくSlackチャンネルです。Salesforce公式ブログでは、チャンネルのデフォルト公開範囲はSalesforce側のオブジェクト設定に影響されると説明されています。オブジェクトがSalesforceで公開設定ならSlack側でも見つけやすくなり、それ以外では限定公開寄りになります。
ただし、チャンネルに追加された人がSlack上のやり取りを見られることと、Salesforceレコード本体を見られることは同じではありません。Slack内の会話や通知は見えても、Salesforce本体の閲覧・更新は本人のSalesforce権限に制限されます。この差を理解していないと、「Salesforce権限で守られているからSlackでも安全」と誤解しやすくなります。
さらに、チャンネル名自体には権限チェックがかかりません。商談名、顧客名、案件名に機密性がある場合、レコード名をそのままチャンネル名にすると、本文を見せていなくても重要情報が漏れる可能性があります。大口商談、未公開案件、解約交渉、採用候補者、法務相談のようなレコードでは、チャンネル名の命名ルールも権限設計の一部として扱うべきです。
レコードプレビューは共有者の権限で生成される
Salesforce URLをSlackに貼ると、レコードの概要がプレビューとして表示されることがあります。ここで重要なのは、プレビューが閲覧者本人の権限ではなく、共有した人や通知を生成したIntegration Userの権限に基づいて作られる場面があることです。
たとえば、強い権限を持つマネージャーが商談URLをSlackに貼ると、そのマネージャーが見られる項目をもとにプレビューが生成される可能性があります。閲覧者がSalesforce本体ではその項目を見られないとしても、Slack上のプレビューには残るかもしれません。管理者が作成したカスタム通知でプレビューを出す場合は、Integration Userの権限が表示内容に影響します。
Salesforce公式ブログでは、Slack向けのレコードレイアウトを定義し、プレビューで表示してよい項目を制御できると説明されています。設定がない場合はcompact layoutに従うため、既存のcompact layoutに金額、契約条件、個人情報、失注理由などが含まれていないかを確認します。
| 確認対象 | 起きやすい問題 | 設計で見ること |
|---|---|---|
| チャンネル名 | レコード本文を隠しても顧客名や案件名が見える | 機密レコードでは汎用名やID中心の命名にする |
| レコードプレビュー | 共有者やIntegration Userの権限で項目が出る | Slack用レイアウトで表示項目を最小化する |
| カスタム通知 | 通知が広い権限で生成される | Integration Userの権限と通知先を同時に確認する |
| 外部メンバー入りチャンネル | 社外メンバーに顧客情報が残る | 外部共有チャンネルでプレビューを出さない前提を確認する |
Slack連携のリスクは、個別の機能だけでなく、社内の運用習慣にも左右されます。営業担当が商談URLを気軽に貼る文化があるなら、レコードプレビューの項目制御は必須です。逆に、Slackには通知だけを出し、詳細確認はSalesforce本体に戻す運用なら、表示情報をかなり絞れます。
AgentforceとSlackbotは役割を分けて接続する
SlackからSalesforceを使う方法は、標準接続だけではありません。Salesforce公式ブログでは、AgentforceエージェントをSlackに出す方法、SlackbotがSalesforceレコードへアクセスする方法、Salesforce MCPサーバーを使ってSlackbotの機能範囲を絞る方法が整理されています。
AgentforceエージェントをSlackで使う場合は、Salesforceでエージェントを構築・有効化し、Agent BuilderでSlack接続を追加し、対象ワークスペースにインストールする流れになります。このとき、組織レベルのSlack接続とユーザーマッピングは基盤として使われますが、各エージェントには明示的な接続設定が入ります。
ここで混同しやすいのが、SlackbotとAgentforceエージェントの違いです。SlackbotがSalesforceレコードを検索、作成、更新するだけなら、標準接続で足りる場合があります。一方で、既にSalesforce側に業務ロジックや推論を持つAgentforceエージェントがあるなら、それをSlackbotのMCPツールとして公開する設計もあります。
Salesforce MCPサーバーを使うと、SObjectの読み取り、作成・更新、削除、Data 360へのSQLクエリなど、操作範囲をサーバー単位で分けられます。標準接続では「ユーザーがSalesforceでできること」がそのままSlackbotにも広がりやすい一方、MCP経由なら機能単位で上限を切りやすくなります。MCPの全体像はBtoB営業AIでモデルとMCPを使い分ける考え方も参考になります。
| 使い方 | 向いている場面 | 注意点 |
|---|---|---|
| 標準Slack連携 | Salesforceレコードの参照、更新、通知をSlackで扱いたい | Integration Userと個別ユーザー権限の分担を明確にする |
| Agentforce in Slack | 営業支援、問い合わせ対応、社内業務のAIエージェントをSlackから使いたい | エージェント種別、実行ユーザー、利用可能アクションを分けて確認する |
| Slackbot + MCP | SlackbotにSalesforce操作をさせたいが操作範囲を絞りたい | MCPサーバーのscopeとSalesforceのFLS、共有ルールの両方を見る |
| AgentforceをMCPツール化 | Salesforce側にある推論や業務ロジックをSlackbotから呼びたい | Slackbot側で再実装せず、どのエージェントを公開するかを審査する |
AI CRMの文脈では、Slackは単なる通知先ではなく、営業が実際に作業する入口になります。だからこそ、AI CRMの導入判断と同じく、入力負荷を下げることと、権限・承認・監査を残すことを同時に設計する必要があります。
導入前チェックリスト
SlackとSalesforceの連携は、営業現場の定着には効きやすい施策です。ただし、最初から全社・全オブジェクト・全チャンネルに広げるより、対象ユースケースを絞って段階的に進める方が安全です。
- 対象ユースケースを決める。例として、商談更新通知、顧客対応チャンネル、営業会議前のレコード確認、問い合わせ対応などに絞る。
- Integration UserをAPI Onlyに寄せ、必要なオブジェクト権限と項目権限だけを付ける。
- SlackユーザーとSalesforceユーザーのIDマッピング方法を決め、外部メンバーや複数ドメインの扱いを確認する。
- レコードチャンネルの公開範囲とチャンネル名ルールを決める。
- Slack用レコードプレビューの表示項目を確認し、compact layout任せにしない。
- AgentforceをSlackに出す場合は、エージェント種別、実行ユーザー、許可アクション、監査ログを確認する。
- SlackbotにSalesforce操作をさせる場合は、標準接続で足りる操作とMCPサーバーで絞る操作を分ける。
- 営業、管理者、セキュリティ担当で、Slack上に残してよい情報とSalesforce本体に戻す情報を合意する。
設計レビューでは、Salesforce構成図も役立ちます。既存のCRM、Slack、Data 360、Agentforce、外部AIクライアントの関係を整理するなら、Salesforce Reference Diagramsの使い方をあわせて確認すると、関係者間で認識を合わせやすくなります。
参照した公式情報
この記事は、2026年6月24日にSalesforce Architecture Blogで公開されたSlackとSalesforce連携の設計解説を中心に、AIエージェント連携の文脈を踏まえて整理しています。実際の設定や対象機能は契約、組織設定、ロールアウト状況で変わるため、導入時はSalesforceとSlackの管理画面で最新状態を確認してください。
- Salesforce Blog: A Deep Dive Into Slack and Salesforce Integrations for Salesforce Architects
- Salesforce Blog: Trusted Agents at Scale: How Open Discovery Is Unifying the Agentic Enterprise
よくある質問
SlackとSalesforce連携で最初に設計すべき権限は何ですか？
最初に決めるべきなのは、Integration Userの権限、Connected AppのOAuthスコープ、SlackユーザーとSalesforceユーザーのIDマッピングです。この3つが、Slack連携の上限権限と実行主体を決めます。
Integration Userには管理者権限を付けてもよいですか？
原則として推奨しません。Salesforce公式ブログでも、API Onlyのユーザープロファイルから始め、必要なオブジェクト権限を積み上げる考え方が示されています。管理者権限を与えると、通知やプレビューで扱える情報の上限が広がりすぎます。
レコードプレビューは閲覧者本人のSalesforce権限で制限されますか？
常にそうとは限りません。Salesforce公式ブログでは、レコードプレビューは共有した人のSalesforce権限や、管理者が作った通知ではIntegration Userの権限に基づいて生成されると説明されています。Slack用レコードレイアウトで表示項目を絞ることが重要です。
AgentforceをSlackで使う場合、標準のSlack連携だけで足りますか？
基盤として標準接続は必要ですが、AgentforceエージェントごとにSlack接続や対象ワークスペースへのインストールが必要になります。さらに、どのエージェントをSlackに出すか、どのユーザー権限で動くか、どのアクションを許可するかを個別に確認します。
SlackbotからSalesforceを操作させるときはMCPを使うべきですか？
ユーザー本人がSalesforceでできる範囲をそのままSlackbotでも使わせたいなら標準接続で足りる場合があります。操作範囲を読み取りだけ、更新だけ、特定ツールだけに絞りたい場合は、Salesforce MCPサーバーを使う方が設計しやすくなります。
外部メンバーがいるSlackチャンネルでもSalesforceプレビューを出してよいですか？
Salesforce公式ブログでは、レコードプレビューは外部メンバーがいるチャンネルには表示されないと説明されています。ただし、チャンネル名、過去の投稿、手動で貼られた情報、スクリーンショットまでは別問題です。外部共有チャンネルではSalesforce情報をどこまで扱うかを別途ルール化します。
CRM連携の設計を整理したい場合
Slack、Salesforce、Google Workspace、AIエージェントをつなぐ前に、どのデータを誰の権限で扱うか、どこに人の承認を残すかを決めておくと、連携後の手戻りを減らせます。
