こんにちは！コンテンツチームの加藤です。
Salesforce の商談や取引先、ケースの情報、AI から直接扱いたいですよね。営業会議の前に「今週動いた案件を要約して」と聞けば答えが返ってくる状態、最高じゃないですか？その入口として必要になるのが MCP（Model Context Protocol）です。
ところがSalesforce 用のMCP Serverを調べ始めるとさまざまな選択肢があることに気づきます。Salesforce 自身が提供しているホスティング型、GitHub で公開されているコミュニティ製の OSS、そしてCDataを含むサードパーティが提供するマネージドプラットフォームなど、いずれもSalesforce へのMCP接続を提供するものです。しかし前提となる契約形態やデプロイ方法、権限をどこで管理するかなど各製品で大きく異なります。
この記事では、この3つの選択肢を6つの軸で比較してニーズ別に最適な選択肢を提示します。Salesforce用MCPサーバーを選定する際の参考になれば幸いです！
Salesforce MCPサーバーとは？
MCP は AI アプリケーションと外部のデータ・ツールをつなぐためのオープンなプロトコルです。公式仕様（2026-07-28版）では、通信の土台に JSON-RPC 2.0 を使い Host・Client・Server 構成で定義されています。サーバー側が公開できるものは Tools（AI が呼び出せる操作）、Resources（読み取れるデータ）、Prompts（定型のやり取り）の3種類です。
この枠組みに当てはめると、「Salesforce MCPサーバー」とは Salesforce の中にあるデータや処理をMCP の Tools や Resources として AI 側へ公開する枠組みを指します。AI が SOQL 相当の問い合わせで商談を取ってきたり、レコードを更新したりできるようになるのは、この層があるからです。
ここで押さえておきたいのは、MCP が既存の API を置き換えるものではないという点でしょう。裏側で動いているのは従来どおり Salesforce の API であり、MCP はその呼び出し方と結果の形をAI が扱える共通の作法に揃える層になります。だからこそ、サーバーの実装が違えば「同じSalesforce に接続できる MCP サーバー」でも中身が変わってきます。プロトコルそのものの仕組みや、サーバーを構築・運用するときに何を決める必要があるのかを先に固めておきたい場合は、MCPサーバーの構築・運用ガイドで基礎から解説しています。
混同しやすい7つの用語を切り分ける
選択肢の比較に入る前に、用語を定義しておきましょう。類似の概念が多く存在するので混乱しやすいポイントだと思います。
Agentforce と MCP：Agentforce は Salesforce 上で動く AI エージェントであり、MCP の枠組みで言えばクライアント側にあたります。一方 Hosted MCP Servers はデータやロジックを差し出すサーバー側です。「Agentforce を導入すれば MCP サーバーが手に入る」わけではありません。
MCP サーバーと REST API：MCPはREST APIを置き換えるわけではなく、APIを土台にして作られます。MCP サーバーを立てても Salesforce の API は裏で使われ続けますし、既存の連携基盤が不要になるわけでもありません。
ローカル MCP とリモート（ホスト型）MCP：MCPには手元の PC でプロセスとして起動するものと、ネットワーク越しのエンドポイントとして提供されるものがあります。この記事で扱う3択のうち、OSS 版は手元起動が前提で残る2つはリモート型です。運用がまるごと変わる分岐点になります。
公式サーバーとパートナー製サーバー：Salesforce が「MCP に対応している」と言うとき、自社がホストするサーバーとAgentExchange のパートナーが提供する検証済みの MCP サーバーの両方が含まれます。ここで比較対象とするのは公式のサーバーです。
MCP サーバーとクライアント／ホスト：仕様上は3者構成なので、Claude や ChatGPT、Cursor、Copilot といった AI アプリは MCP サーバーではありません。これらはサーバーに接続するクライアントです。
CData Connect AI と CData Salesforce ドライバー：どちらも Salesforce につながりますが、前者は AI と MCP のためのマネージドプラットフォーム、後者は BI ツールや開発ツールから使う ODBC / JDBC ドライバーです。用途が違うので、選ぶ場面も別になります。
この6つを切り分けておくと、以降の比較で「どの層の話をしているのか」で迷わなくなります。
選択肢1：Salesforce 公式の Hosted MCP Servers
さて、選択肢の1つめは Salesforce 自身が提供するホスティング型のサーバーです。開発者向けドキュメントに Hosted MCP Servers として整理されており、自分でサーバーを立てずに、Salesforce がホストするエンドポイントへ MCP クライアントから接続する形をとります。
この選択肢の性格をひとことで言えば、Salesforce の中で完結する用途に対していちばん素直、ということになるでしょう。データもロジックも権限も Salesforce 側にあるので、外部に開放する経路を新しく作らずに済みます。運用の責任もベンダー側にあり、自前でプロセスを常駐させたり、バージョン追従を自分で抱えたりする必要がありません。
標準で用意されているサーバーのほかに、Apex の Invocable Action や @AuraEnabled メソッド、Apex REST メソッド、Flow、Named Query といった既存の資産をコネクタを書かずに MCP のツールとして公開する方法も用意されています。すでに Salesforce 上で業務ロジックを作り込んでいる組織にとっては、その投資をそのまま AI 側へ持ち出せるのは利点でしょう。
検討にあたっては接続時に要求される認証方式とスコープ、そしてレート制限などの上限値を確認しておくと良いでしょう。公式のセキュリティのベストプラクティスでは、接続を External Client App 経由とし、ブラウザを介した認可コードフローのみを許可、PKCE はすべての OAuth フローで必須と定めています。認証の設計はこのあたりを起点に読み進めることになります。
選択肢2：コミュニティ製の OSS MCP サーバー
2つめはコミュニティが公開している OSS です。代表的なものが tsmztech/mcp-server-salesforce で、MIT ライセンスのもとで公開されています。
この選択肢の強みは、開発者向けの操作にいちばん深く踏み込んでいることです。README で挙げられている機能を見ると、親子リレーションをまたぐレコードのクエリ、SOSL による複数オブジェクト横断検索、オブジェクトや項目の作成、Apex クラスの読み書き、匿名 Apex の実行、デバッグログの管理、項目レベルセキュリティ（FLS）の付与と剥奪、集計クエリ、複数 Org の切り替えまで並びます。
3択のうち、Salesforce の開発・検証作業を AI にやらせるという意味ではこの OSS がもっとも優れているようです。データを読ませたいのではなく開発を手伝わせたいのであれば、最初に見るべきはここでしょう。
とはいえデメリットも明確です。デプロイは stdio 前提で、クライアントから対話的に起動する形になります。Docker を使う場合も同様の起動の仕方で、リモートのホスト型として提供する記述は README にありません。つまり動かす端末ごとに設定と資格情報が置かれ、誰がいつ何を実行したかを追う仕組みは自前で用意することになります。
バージョンが v0.0.x のままである点は、本番の業務プロセスに載せるかどうかの判断材料として素直に受け止めておくべきところです。問い合わせ先として README が案内しているのは GitHub の Issue だけで、商用のサポート窓口はもちろんありません。企業で使うには多くのハードルがありそうです。
選択肢3：CData Connect AI の MCP エンドポイント
3つめが CData Connect AI です。位置づけとしては、数百のデータソースを同じ作法で扱えるクラウドサービスの上にMCP 経由でアクセスする構成です。Salesforce は、その接続先の1つです。
そのため、Connect AIは「Salesforce だけを AI から見たい」場面よりも。Salesforce の商談と、kintone の案件、会計システムの実績、DWH に溜めた履歴を、1つの AI から横断して聞きたい、という要件のときです。構成上の違いはワークスペースにまとめた接続をひとつのエンドポイントとして用意できる点です。ソースごとに別々の MCP サーバーを用意する必要はありません。
ガバナンス周りは公式の権限とアクセス制御のドキュメントが明記しています。システムロールは Administrator・Connection Administrator・User Administrator・Query の4つで、Select / Insert / Update / Delete / Execute の権限は加算的に積み上がります。ワークスペース単位で設定した権限は、カスタム MCP エンドポイント経由のアクセスにもそのまま使えます。
SSO については Just-in-Time プロビジョニングに対応し、監査イベントとクエリログの見える範囲はロールごとに分かれています。Administrator は全クエリログと全監査イベントを、Connection Administrator は自分の接続ドメインの監査イベントを見る、といった具合です。
精度についても数字を出しておきます。当社が実施したベンチマークでは、5つの MCP プロバイダーを CRM・プロジェクト管理・データウェアハウス・ERP の4ソースに対して 378 プロンプトで比較し、事前に定義した正解と照らして採点しました。
このベンチマークでCData の正答率は 98.5%（68件中67件）でした。数値と手法はこちらの記事で確認できます。
逆に、この選択肢が向かない領域もあります。Connect AI が主眼に置いているのは SQL ベースのデータアクセスであり、匿名 Apex の実行やデバッグログの取得といった Salesforce 固有の開発者向け操作については前節の OSS 版のほうが踏み込んでいます。機能や料金の詳細はCData Salesforce MCP の製品ページをご覧ください。
なお、これと同じ「3つの選択肢を同じ物差しで並べる」整理をkintone について実施したkintone MCP Server の3択をフラットに比較した記事があります。
6つの軸で3つの選択肢を比較する
3つを同じ軸の上で比較したのが以下の表になります。なお、実際に動かしたときの挙動差を見たい場合は、公式サーバーと Connect AI を同じ課題で走らせたSalesforce MCP のテスト比較が判断材料になります。
軸 | Salesforce 公式（Hosted MCP Servers） | OSS（tsmztech/mcp-server-salesforce） | CData Connect AI |
|---|
対象範囲 | Salesforce 単体 | Salesforce 単体（複数 Org の切り替えあり） | Salesforce を含む数百のデータソースを横断 |
利用可否の前提 | 利用可否の条件は公式ドキュメントに明記なし。Salesforce へ要確認 | エディションの条件なし。API が使える Org であれば動く | Salesforce のエディション条件には依存しない（API が使える Org が前提）。Connect AI 側の契約が必要 |
デプロイ形態 | Salesforce がホストするリモートのエンドポイント | stdio でクライアントから起動するローカル実行（Docker も対話起動） | クラウド上のマネージドな MCP エンドポイント |
ガバナンスの所在 | Salesforce 側の権限モデルに寄せて設計。適用範囲は Salesforce 内 | 自前。監査ログの集約も SSO も自分で用意する | 複数ソースを跨いだロール・SSO・監査ログを1か所で持つ |
開発者向け操作の深さ | Apex の Invocable Action・Flow・Named Query などをコネクタ実装なしでツール化できる | もっとも深い。匿名 Apex 実行、デバッグログ、FLS の付与まで | SQL ベースのデータアクセスが主眼 |
運用責任とサポート | ベンダーが運用。サーバーは Salesforce がホストする | 自己責任。問い合わせは GitHub Issue のみ、バージョンは v0.0.x | ベンダーが運用。日本法人による日本語サポートあり |
こうして並べてみると、争点が機能の数ではないことが見えてきます。分かれ目は「Salesforce の中だけで足りるのか」と「誰が運用を負うのか」の2つで、残る4軸はその結果としてついてくる性格の違いと言えるでしょう。
権限とガバナンスをどこで担保するか
6軸のうち、日本の IT 部門の意思決定で特に重要なのはガバナンスの軸だと思います。AI に社内システムを触らせる話は、機能の可否より「誰が何を見られるのか」で止まることが多いためです。
公式のホスト型を選ぶ場合、アクセス制御の設計は Salesforce 側の権限モデル、つまりプロファイルと権限セット、項目レベルセキュリティ、共有ルールに寄せて考えることになります。すでに運用している仕組みの上に乗せられるので、設計の出発点としては分かりやすい形でしょう。
公式ドキュメントは、MCP のツール呼び出しが接続を認可したユーザーと同じ権限で動き、オブジェクト権限・項目レベルセキュリティ・共有ルールがそのまま効くと明記しています。Lightning の画面や REST API でできない操作は、MCP 経由でもできないという設計です。加えて External Client App をプロファイルや権限セットに紐づけて、どのユーザーがどの MCP クライアントを使えるかを絞れます。いずれにせよ、担保の範囲は Salesforce の内側です。
OSS を選ぶ場合は、担保の仕組みを自社で作ることになるでしょう。接続に使う資格情報がどの端末に置かれ、誰が匿名 Apex を実行できるのかを設計する必要があり、開発チームの検証環境なら現実的な割り切りですし、本番の顧客データに向けるなら、この設計コストを見積もりに入れておかないと後で困ります。自前で担保する側に回るのであれば、どこに穴が空きやすいのかを先に把握しておくほうが確実です。想定すべき攻撃面と導入前の対策手順は、MCPサーバーの主要な脆弱性と対策手順にまとめてあります。
そして見落とされがちなのが、MCP サーバーが増えたときに監査の観点が分散するという構図です。Salesforce は Salesforce の中で、別の SaaS はその SaaS の中で、それぞれ完結して制御。個々には正しく守られていても、「先週この AI エージェントは、どのシステムのどのデータを見たのか」を追いたくなったときに、見る場所が接続の数だけ増えていきます。
Connect AI がロールと SSO、監査ログをワークスペースの単位で持っているのは、この分散を集約するための設計です。逆に接続先が Salesforce だけで完結するなら、集約する必要はないかもしれません。
自社の条件からどれを選ぶか
ここまでの軸を、条件から引ける形に並べ替えます。
Salesforce だけで完結し、公式の Hosted MCP Servers を自社の契約で使える場合 → 公式の Hosted MCP Servers。権限を新しく設計せずに済み、運用もベンダー側です。まずここを当たるのが順序として自然でしょう。
Apex の実行やデバッグログまで AI に触らせたい開発・検証用途 → OSS。この深さは3択のうち OSS だけが持っています。本番運用ではなく開発の生産性が目的なら、迷う必要はありません。
公式が自社の契約で使えない場合 → OSS または Connect AI。Salesforce のエディション条件に依存しない選択肢を選ぶことになります。自前運用を負えるかどうかで分かれます。
Salesforce と他システムを1つの AI から横断したい場合 → Connect AI。接続の数だけサーバーを立てて回る構成を避けたいときの選択肢です。
監査ログと SSO を、複数ソース分まとめて1か所で持ちたい場合 → Connect AI。前節で書いた分散の問題を、運用の初期から抱えたくないケースにあたります。
3択のどれを選んでも、次に必要になるのは実際の接続作業です。特定の AI クライアントからの接続手順については、Salesforce MCP を Claude Desktop から使う手順のナレッジベース記事で具体的な設定まで書いていますので、こちらを参照してください。CData Connect AI で Salesforce と他システムをまとめて扱う構成を検討される場合は、Connect AI の製品ページに機能と対応範囲の詳細があります。自社の要件に落とし込む段階でご相談いただければ、。
Salesforce と他システムを1つの MCP エンドポイントに
CData Connect AI は Salesforce を含む数百のデータソースへの接続を1つの MCP エンドポイントとして差し出し、ロール・SSO・監査ログもワークスペース単位で一元管理します。接続ごとにサーバーを立てて回る構成を避けたい場合の選択肢です。
CData Salesforce MCP の詳細を見る
よくある質問
Salesforce 公式の Hosted MCP Servers を使うのに追加費用はかかりますか。
公式の Hosted MCP Servers のドキュメントには課金条件が明記されていないため、本記事では断定を避けています。費用と対象エディションの条件は必ず Salesforce の公式ドキュメント、または契約担当者にご確認ください。エディションの条件に左右されない選択肢を先に知りたい場合は、コミュニティ製の OSS と CData Connect AI が候補になります。
Professional Edition では Salesforce のデータを MCP 経由で AI から扱えないのですか。
公式の Hosted MCP Servers のドキュメントには、対象エディションによる制限は明記されていません。ただし利用可否の条件そのものが公開されていないため、本記事では断定せず、Salesforce の担当者への確認をおすすめします。仮に公式が使えない場合でも道が閉じるわけではありません。OSS の MCP サーバーは API が使える Org であれば動きますし、CData Connect AI は Salesforce のエディション条件に依存せず MCP エンドポイントを提供します。
MCP サーバーを導入すれば Salesforce の REST API は不要になりますか。
不要にはなりません。MCP は API を置き換えるプロトコルではなく、API の呼び出し方と結果の形を AI が扱える共通の作法に揃える層です。裏側では従来どおり Salesforce の API が使われますし、既存の連携基盤を止める必要もありません。
Agentforce と Salesforce MCPサーバー は同じものですか。
別のものです。MCP の仕様は参加者を Host・Client・Server の3者に分けており、Agentforce は AI エージェントとしてクライアント側に座ります。Hosted MCP Servers はデータやロジックを差し出すサーバー側です。Claude や ChatGPT などの AI アプリも同じくクライアント側にあたります。
Salesforce 以外のシステムも同じ AI から扱いたい場合、MCP サーバーは複数立てることになりますか。
ソースごとに個別の MCP サーバーを用意する構成は成り立ちますが、接続の数だけ設定と権限、監査の見る場所が増えていきます。CData Connect AI は、ワークスペースにまとめた複数ソースの接続を1つの MCP エンドポイントとして差し出し、ロールと SSO、監査ログもその単位で持つ構成をとります。横断が要件に入っているかどうかで、どちらが素直かは変わってきます。
出典・参考情報
Salesforce と他システムを1つの MCPプラットフォームで管理
CData Connect AI は Salesforce を含む数百のデータソースへの接続を1つの MCP エンドポイントとして差し出し、ロール・SSO・監査ログもワークスペース単位で一元管理します。接続ごとにサーバーを立てて回る構成を避けたい場合の選択肢です。
