Salesforce MCPサーバー：ツール、権限、および安全な接続方法

Salesforce MCPサーバーとは

Salesforce MCPサーバーは Salesforce MCPサーバー 、CRMを呼び出し可能なツールへと変換します。 Model Context Protocol（MCP） は、AIエージェントが外部システムのツールを検出し、呼び出すためのオープン標準です。Salesforceの実装では、これを通じて標準オブジェクトおよびカスタムsObjectを公開します。

他の リモートMCPサーバー と異なる点は、その実行環境です。SalesforceはMCPサーバーを 組織内から提供します。これはTrueFoundryのSalesforce管理パッケージを通じて有効化されるため、サードパーティのホストを介したり、OAuthアプリを構築したりする必要はありません。

有効化する設定によって、エージェントがアクセスできる範囲が決まります。

これら2つは、「エージェントがレコードを変更する必要があるか、それとも読み取りのみでよいか」という唯一の重要な判断基準に対応しています。 Salesforceサーバー タブ（設定内）には、お使いのエディションで有効化可能な項目が一覧表示されます。[確認] これら2つ以外のバリエーションが表示されるかどうかについては、ドキュメントに記載されていません。

どちらのサーバーを使用する場合でも、操作対象となるのはデータモデルです。ドキュメントでは固定の関数名ではなく、機能やオブジェクトタイプに基づいてツールが説明されているため、 ツール タブ（サーバー詳細ページ内）が、組織における実際のインベントリとなります。

エージェントが実際に何を行っているか

有用なワークフローチェーンは、読み取りを行い、時には書き込みも行います：

• パイプラインのレビュー しきい値を超えるオープンな商談をクエリし、関連する取引先や取引先責任者を抽出し、最終活動日を照合して、停滞している案件を特定します。
• コール前のリサーチ 取引先、オープンなケース、成約履歴、および製品利用状況を示すカスタムオブジェクトを読み取り、1ページの概要を作成します。
• ケースのトリアージ オープンなケースを製品分野と重要度で分類し、対応目標時間を超過しているものを抽出します。
• データ衛生の管理 重複または不完全なレコードを見つけてフィールドを正規化します。これは、ここで唯一「sobject-all」権限を必要とする作業です。

これら4つのうち3つは純粋な読み取りであり、それがパターンとなっています。チームが求めるもののほとんどは、 CRM MCPサーバー からの読み取りです。したがって、読み取りか書き込みかという議論はここでは抽象的な原則ではなく、アクティベーション時に回答される具体的な問題であり、ほとんどのエージェントは読み取り専用であるべきです。

生の接続がチーム規模で機能しなくなる理由

RevOpsアナリストが1人でSalesforceをClaude Desktopに接続するのは問題ありません。しかし、営業、サポート、財務の30人で同じ統合を行うのは話が別です。

書き込み権限を持つエージェントは、経営陣が目にする数値を変更できてしまいます。 商談金額、完了予定日、フェーズは予測に集計され、取引先フィールドはテリトリーやARRレポートの基になります。フェーズを「整理」したり、重複と思われるレコードを削除したりするエージェントは、単に情報を漏洩させるだけでなく、財務部門が四半期決算を行う記録システムを破壊してしまいます。上書きされた履歴は、コミットのように元に戻すことはできません。プロンプトインジェクションがこれをさらに悪化させます。ケースの説明に仕込まれた指示が、データ管理用と同じ書き込みツールを持つトリアージエージェントに渡ってしまう可能性があるからです。

読み取り権限を持つエージェントは、パイプライン全体をモデルのコンテキストに取り込むことができます。 商談に対する1つの広範なクエリで、すべてのオープンな案件、その金額、所有者が取得されます。共有サービスアカウントを使用している場合、そのクエリは個人の共有ルールによって制限されません。つまり、あなたの予測データがそのままプロンプトになってしまうのです。

共有認証情報を使用すると、Salesforce独自の権限モデルが無効化されてしまいます。 プロファイル、権限セット、項目レベルセキュリティ、共有ルール。チームが長年かけて調整してきたこれらの設定も、統合ツールが管理者レベルの認証情報で接続し、すべてのリクエストが管理者権限を継承してしまえば、その苦労は水の泡となります。

変更時の帰属先が不明確です。 項目履歴からは「レコードが変更されたこと」や「どのユーザーが変更したか」はわかりますが、「Slackスレッドでの指示を受けてエージェントが変更した」という経緯まではわかりません。

これはSalesforceを接続すべきではないという話ではありません。その手前にコントロールプレーンを置くべきだという話であり、それこそが MCPゲートウェイ の役割です。

Want to see this end to end?

Spin up a TrueFoundry account, activate the read-only Salesforce server, and hand your team a governed CRM agent in an afternoon.

Get started free

始める前に：Salesforce側で必要なもの

このサーバーは組織内で稼働するため、一般的なマネージドMCPとは異なり、いくつかの前提条件を満たす必要があります。

• MCPサーバーを追加する権限を持つTrueFoundryアカウント。
• Salesforce管理者 権限（パッケージのインストールおよび設定変更を行うため）。
• 以下のいずれかのエディションの組織（ APIアクセス が有効であること）：Developer Edition、Enterprise Edition、またはAPIアクセスが有効なProfessional Edition。

所要時間は約10分です。そのほとんどはインストールと有効化の待ち時間となります。

TrueFoundry経由でのSalesforce MCPサーバーの接続

TrueFoundryは、Salesforceを TrueFoundryマネージドMCPとしてプロビジョニングします。サーバーURL、アウトバウンド認証、スコープ、認証情報はプラットフォーム側で管理され、Salesforce側の変更に合わせて常に最新の状態に保たれます。

サーバーはお客様自身で管理されるため、Salesforce側で事前に3つの手順が必要となります。

ステップ1 — TrueFoundry Salesforce MCPパッケージをインストールします。 管理者として組織にログインし、同じブラウザセッションで以下のインストールリンクを開きます。

https://login.salesforce.com/packaging/installPackage.apexp?p0=04ta7000001FUejAAG

インストール画面で すべてのユーザーのインストールを選択し、 インストールをクリックして、完了のメッセージが表示されるまで待ちます。

ステップ2 — MCPサービスを有効化します。 設定のクイック検索ボックスで ユーザーインターフェース を検索し、 MCPサービスを有効化を見つけてオンにし、 保存します。

ステップ3 — MCPサーバーをアクティベートします。 まだ セットアップで、 MCP Servers を検索し、 Salesforce Servers タブを開きます。目的のサーバー（読み書き両用なら sobject-all、読み取り専用なら sobject-reads）を見つけて、 Activateをクリックします。完了まで最大2分かかる場合があります。選択する前に次のセクションをお読みください。

ステップ 4 — TrueFoundry での接続 MCP Serversに移動し、 Salesforce MCPを見つけて、 Connectをクリックします。Salesforceのログインおよび同意画面にリダイレクトされるので、ログインして要求された権限を確認し、 Allowをクリックしてください。

ステップ 5 — 検証 サーバーの表示が Connected となり、 Tools タブにツールの一覧が表示されるはずです。いずれかのツールで Try をクリックするか、 “list all accounts”のようなコマンドを実行して、往復通信が正常に行われることを確認してください。

以下の設定は 不要 です：外部クライアントアプリ、接続アプリケーション、クライアントIDやシークレット、OAuthスコープ、コールバックURLは必要ありません。

認証の仕組み

TrueFoundryでは、 インバウンド 認証（クライアントがゲートウェイに対して自身を証明する方法）と、 アウトバウンド認証（ゲートウェイがSalesforceに対して自身を証明する方法）を分離しています。

インバウンド — クライアントは以下のいずれかを使用してAI Gatewayに対して認証を行います。

他のサーバーよりも特に注意すべき点があります。仮想アカウントトークンを使用すると、すべてのリクエストで同一のアクセス権が付与されるため、ユーザーごとのCRM可視性をサポートできません。インバウンドにはPATまたはIDE OAuthフローを使用してください。

アウトバウンド — OAuth2認可コード フロー。各ユーザーは自身のSalesforceアカウントを認可し、TrueFoundryが同意、トークンストレージ、および更新を管理します。マネージドMCPとして、リダイレクトURIは常にTrueFoundryが中央管理するコールバックとなります。

https://auth.truefoundry.com/mcp/oauth2/callback

これがSalesforceの強みです。アウトバウンドのIDは個々のユーザーであるため、 すべてのアクションは認証されたユーザーとして実行され、組織のCRUD権限、項目レベルセキュリティ、および共有ルールが適用されます。 財務関連の項目を表示できないプロファイルの担当者は、エージェントを通じてもそれらを表示できません。特定の地域に限定されたサポート担当者のエージェントは、その地域のみを表示します。

権限モデルがゲートウェイでバイパス、複製、または近似されることはありません。Salesforceが各呼び出しを実際のユーザーとして評価するため、これがそのまま強制レイヤーとなります。ユーザーはゲートウェイとSalesforceに対してそれぞれ認証を行う必要があり、これによってユーザーごとの属性管理が可能になります。

ソース側での読み取り専用設定

ほとんどのMCPサーバーでは、機能を制限する場所はゲートウェイの1箇所のみですが、Salesforceでは2箇所あり、アップストリーム側の方がより強力です。

`sobject-all` ではなく `sobject-reads` を有効にすると、書き込みおよび削除ツールは 存在しなくなります ゲートウェイが通信するサーバー上に、これらのツールは存在しません。無効化や制限ではなく、そもそも存在しないのです。後で誤って設定を変更したり、共同作業者が設定を戻したり、アップストリームのリリースで書き込みツールが密かに追加されたりする心配もありません。

• デフォルトでは `sobject-reads` を使用してください。 パイプラインレポート、アカウント概要、ケーストリアージ、予測サマリー、リサーチエージェントなど、これらはいずれも書き込みを行いません。
• `sobject-all` は、ワークフローで書き込みが必要な場合にのみ有効にしてください。、そして以下のトグルと承認ポリシーを組み合わせてください。

すでにsobject-allを有効にしている場合、以下の ツール タブで書き込みおよび削除ツールを無効にしても同じ動作になります。これは維持しておくべき制御設定です。

リリース前のツールスコープ設定

接続が完了すると、 ツール タブに、アクティブなサーバーが公開しているすべての項目が一覧表示されます。

ツールごとのトグル。 ツールをオフにすると、tools/listから完全に除外されます。クライアントからは見えなくなり、呼び出すこともできません。これはプロンプト層でのフィルタリングとは異なります。削除ツールが見えないエージェントは、悪意のあるケース説明で誘導されたとしても、そのツールを呼び出すことはできません。

新しいツールをデフォルトで有効にする。 「オン」 オンに設定すると、新しいアップストリームツールが自動的に表示されます。「オフ」 オフに設定すると、明示的に有効にしたツールのみが利用可能になり、新しいツールは承認するまで非表示のままになります。記録システムとしては、「オフ」をデフォルトにするのが適切です。

一括操作。 すべての行をチェックボックスに切り替え、 すべて選択一度にまとめて切り替えられるため、 保存。

各ツールの鉛筆アイコンをクリックすると、モデルへの提示方法を変更できます：

「 説明 」の上書き（最大20,000文字）は、元の説明が曖昧な場合にモデルのツール選択を誘導します。 MCPツールアノテーション は、ツールを 読み取り専用 または 破壊的としてマークし、readOnlyHintやdestructiveHintを設定します。書き込みツールを「破壊的」とマークすることで、以下の承認ポリシーにより、特定の操作クラス全体を一括で制御できるようになります。

誰が何を行えるか：コラボレーターの役割

アクセス制御は、ユーザー、チーム、または仮想アカウントに対して、「どのサーバーにアクセスできるか」と「どのツールを呼び出せるか」という2つの側面から適用されます。

CRMの場合、RevOpsをマネージャー、営業・サポートをユーザー、営業オペレーションのリーダーを書き込みパスの承認者とするのが自然な分割です。これは、 MCPアクセス制御 レジストリ内の他のすべてのサーバーと同じモデルです。

Ready to scope your first server?

Activate sobject-reads, add your team as Users, and ship a read-only CRM agent today.

Start free on TrueFoundry

書き込みツールに対する人間による承認

書き込みを無効にするのは強力な手段であり、ほとんどのSalesforceエージェントにとっては適切な対応です。しかし、アクティビティの記録、ステージの進行、タスクの作成など、正当な理由で書き込みを行うワークフローも存在します。こうした操作には、人間の監視が必要です。

ゲート設定されたツールが呼び出されると、その呼び出しは 実行されずに保留されます。同時に承認リクエストが作成され、承認者に通知が送信されます。人間が承認すると、設定された期間内は呼び出しが成功するようになり、期間が過ぎると再度承認が必要になります。ポリシーを作成するには、 AI Gateway → Policies → MCP Tool Approval （コンソールでベータ版と表示されています）に移動してください。

各ポリシーでは、ゲート対象となるサーバーを指定し、 承認スコープを選択します。

ここでアノテーションが役立ちます。書き込み操作を「Destructive（破壊的）」としてマークし、クラスを「approval_scope: destructive」でゲート設定します。スコープが重複する場合は、より具体的な設定が優先されます（個別指定 > destructive > すべて）。

有効期間 は、 1回限り （単一の実行）または 時間ベース（分単位の期間）から選択します。ポリシーが競合する場合は、より制限の厳しい設定が優先されます（「1回限り」は「10分」より優先され、「10分」は「30分」より優先されます）。商談や取引先レコードに影響する操作には、 1回限り を選択してください。書き込みツールに対して30分間の許可を与えると、エージェントはその30分間ループを実行できてしまうためです。

承認者にはメール、Slack、PagerDuty、またはMS Teams経由で通知が届き、コンソール上で確認を行います：

各リクエストには、ツール、ポリシー、リクエスター、有効期限、および 実際のツール引数 が表示されます。これにより、承認者はエージェントが40万ドルの商談を「失注（Closed Lost）」に変更しようとしていることを確認してから承認できます。この可視性こそが、CRMにおける本機能の最大の価値です。

保留中、呼び出し元にはエラーではなく _meta.approval_status: "pending" を含むJSON-RPCの結果が返されるため、適切に設計されたエージェントであれば待機して再試行します。許可はリクエスターごとにスコープ設定され、拒否されても永続的にブロックされることはありません。次の呼び出しで改めてリクエストが生成されます。

ツールプレイグラウンドでのテスト

まずは手動でツールを試してみましょう。サーバー詳細ページで 試す をクリックし、入力内容（AccountやOpportunityなどのオブジェクトタイプ、およびクエリフィルター）を指定して、 ツールを実行をクリックし、JSONを確認します。 試す ボタンは、無効化されているツールでは使用できません。これにより、プロファイルから読み取れないフィールド、パッケージで公開されていないオブジェクト、誤ったフィルター形式など、単純な失敗を早期に発見できます。

IDEからの利用

を開き、 使い方 タブから、テナント固有のゲートウェイURLとそのまま貼り付け可能なスニペットを取得します。

Claude Code、VS Code、Claude Web、Claude Desktop、Cursor、Windsurf、Codex、およびPythonとTypeScriptのMCP SDKに対応しています。 APIキーを表示 は、クライアントがヘッダーでトークンを必要とする場合にそのトークンを表示します。URLは手動で組み立てるのではなく、このタブから取得してください。URLはテナント固有のものであり、手動で作成したエンドポイントは、クライアントが接続できてもツールが一覧表示されないという問題の最も一般的な原因となります。

ゲートウェイ経由で利用できる機能

ツールレベルのメトリクス。 ツールメトリクス タブでは、呼び出し回数、ツールごとのレイテンシ、エラー率を追跡できます。ゲートウェイ全体では、MCPメトリクスにより、秒間リクエスト数、P50/P75/P90/P99のレイテンシ、エラータイプ別の失敗率が追加されます。

リクエスト全体の可観測性。 すべてのツール呼び出しは、呼び出し元のID、ツール名、入力内容、レイテンシとともにトレースされ、OpenTelemetryを介してGrafana、Datadog、またはPrometheusにエクスポートされます。これは、アトリビューションレイヤーの履歴だけでは得られない情報です。

ガードレール。 フックは、ツール呼び出し前の「mcp_pre_tool」で呼び出しを完全にブロックしたり、応答がエージェントに戻る前の「mcp_post_tool」で適用したりできます。CRMデータにおいて重要なのはポストツールフックです。これは、モデルに到達すべきではない過剰なレコードや機密フィールドを含む結果を検知するための場所です。

低オーバーヘッド。 ゲートウェイによるレイテンシの増加はわずか 3～4ミリ秒 であり、 単一のvCPUで350 RPS以上を処理します。

単一のレジストリ。 複数のサーバーを登録すると、それらのツールから厳選したサブセットを1つのエンドポイントの背後に公開できます。その際、 仮想MCPサーバー — つまり、ディールデスク担当者はSalesforceの読み取りツールと、要約を投稿するためのSlackツールのみを利用でき、それ以外の権限は与えられません。

アクセス権の取り消し

テナント管理者は、サーバー上の保存済み認証情報をすべて削除できます。これを行うには、以下の横にある3点リーダーメニューをクリックします。 編集：

すべてのトークンを取り消す この操作を実行すると、そのサーバー上のすべてのユーザーおよび仮想アカウントの認証オーバーライドと保存済みOAuthトークンが削除されます。この変更は次回の要求から有効になり、アクティビティログに記録されます。この操作は取り消すことができず、テナント管理者のみが実行可能です。

重要な制限事項として、この操作はトークンを ゲートウェイ上でのみ クリアするものであり、Salesforce内部の権限付与までは取り消しません。インシデント発生時には、 Salesforceサーバー タブでサーバーを無効化してください。こちらが認証情報ではなく、機能そのものを削除するためのスイッチとなります。

知っておくべき注意点

読み取り専用設定は単なる切り替えスイッチではなく、アクティベーション時の選択項目です。 最も強力な読み取り専用Salesforceエージェントは、組織で「sobject-reads」を有効にした状態です。これなら書き込みツール自体が存在しません。ゲートウェイ側で「sobject-all」を切り替えるのも有効な手段ですが、設定の不一致が生じる可能性があります。

項目レベルセキュリティ（FLS）は、想定以上に重要な役割を果たしています。 すべての呼び出しは認証済みユーザーとして実行されるため、ある人には機能せず別の人には機能するツールがある場合、それは通常、故障ではなくFLSや共有ルールが正しく動作している結果です。

API制限は共有されます。 エージェントによるツール呼び出しは、夜間ジョブと同じ組織のAPI割り当てを使用します。

関連資料

• MCPゲートウェイとは：アーキテクチャとユースケース — 本記事の背景となるアーキテクチャの入門編
• MCPアクセス制御：MCPゲートウェイによるAIエージェントの保護 — ツールレベルおよびサーバーレベルの権限設定の実践的な仕組み
• MCP認証の解説 — インバウンドおよびアウトバウンド認証モデルの詳細
• 仮想MCPサーバーの解説 — 複数のサーバーのツールを1つのエンドポイントにまとめる方法
• エンタープライズ向けMCPアクセス制御 — 大規模チームのためのロール設計

まとめ

Salesforce MCPサーバーは、適切に管理するのに非常に適している一方で、設定を誤った際のリスクも非常に高いという特徴があります。適切に管理できる理由は、サーバーが自身の組織内で実行され、ユーザーごとに認証を行うため、管理者がすでに維持している権限モデルをそのままエージェントに適用できるからです。リスクが高い理由は、その先にあるオブジェクトが、予測や四半期決算の基盤となる重要なデータだからです。

制御には優先順位があり、最もコストがかからないのは、ワークフローで書き込みが必須でない限り、sobjectの読み取りのみを有効にすることです。次に、使用しないツールを無効にし、書き込みパスには人間による承認を組み込んでください。 一度 の妥当性を確認し、トレースされた呼び出しログを保持してください。

Connect the Salesforce MCP server on TrueFoundry

Free to start