Salesforce MCPを8つのテストで比較 AIエージェント連携の実力差は?

by Jerod Johnson, 加藤龍彦 | August 31, 2026

翻訳者ノート

こんにちは!コンテンツチームの加藤です。

「Salesforceの公式MCPサーバーと、CDataのようなサードパーティ製の接続、AIエージェントにはどちらを使えばいいのか」。実装を検討していると、必ずぶつかる疑問です。この記事では、実際のSalesforceのデータに対して8つの機能テストを実行した結果をもとに、集計・JOIN・書き込みといった具体的な場面でどちらが向いているのかを整理しています。

SalesforceとSQL ServerをMCP経由でAIエージェントに接続するイメージ図Anthropicは2024年11月、Model Context Protocol(MCP)をオープンソースとして公開しました。MCP(Model Context Protocol)とは、AIエージェントが外部のデータソースやツールに接続するための共通規格です。この規格使えば、モデルとシステムの組み合わせごとに専用の連携を作る必要はありません。

それ以来、このエコシステムは初期の実験的なサーバーや開発者向けツールから、本番環境で使える相互運用の標準へと進化してきました。LangChainやLangGraphといったAIフレームワークは、MCPを主要な連携経路として採用しています。利用可能なサーバーを一覧化するMCPレジストリも登場しました。

企業向けプラットフォームは、既存のAPIと並行してMCP接続の認定を始めています。そして最近になって、新しい動きが出てきました。データソースを提供するベンダー自身が、公式のMCPサーバーを提供し始めたのです。

Salesforceは、公式MCPサーバーをいち早く公開した主要な企業向けプラットフォームの1つです。Atlassian、ServiceNowなども追随、あるいは計画を発表しています。

ここでアーキテクトに突きつけられる問いは、公式MCPサーバーに価値があるかどうかではありません。それらを管理型の連携プラットフォームとどう評価し、本番のAIスタックの中で何をどこに置くべきかを判断することです。

そこで私たちは検証対象としてSalesforceを選びました。成熟したAPIモデルを持つ、複雑かつ広く使われているデータソースだからです。

データの読み取り、集計、JOIN、フィルタリング、メタデータ、複数オブジェクトをまたぐクエリをカバーする8つの標準的な機能テストを設計しました。これをもとに、公式Salesforce MCPサーバーとCData Connect AIの両方を、実際のSalesforceデータに対して実行しています。そのうえで、実装の深さと実務上のトレードオフをカバーする13の機能についても、両者を評価しました。

なお、「Salesforce MCP」と呼ばれるものには2種類があります。業務データや業務機能をAIクライアントから呼び出すための Hosted MCP Server と、Salesforce CLIやメタデータといった開発文脈にアクセスするための Salesforce DX MCP Server です。この記事で比較しているのは、業務データ接続を担う Hosted MCP Server のほうだと考えてお読みください。

AIエージェントからSalesforceデータへ接続する2つの構成の違いを、スキーマ把握・集計処理・ガバナンスの観点で比較した図

検証結果はどうだった?

Connect AIは、分析・レポーティング・システム横断のデータ処理において優れた能力を示し、評価した13機能のうち10機能をサポートしました。一方、公式Salesforce MCPは13機能中7機能のサポートにとどまり、Salesforce固有のスキーマメタデータとレコード単位の操作に強みがありました。

指標

CData Connect AI

公式Salesforce MCP

合格したテスト数

8 / 8

4 / 8

サポートする機能数

10 / 13

7 / 13

ストアドプロシージャ

37個のプロシージャ

限定的

書き込み操作

可能(有効化した場合)

INSERT/UPDATE(公式対応)

データソースをまたぐJOIN

対応

非対応

比較の前提として、公式Salesforce MCPを使い始めるまでの流れも押さえておきます。手順は大きく3段階で、①外部クライアントアプリケーションを作成してOAuthを有効化する、②「設定 → インテグレーション → API カタログ → MCP サーバー」から使いたいMCPサーバー(sobject-readsなど)を有効化する、③Claude DesktopなどのMCPクライアント側に接続設定を追加する、という順番になります。画面つきの詳細な手順は、Salesforce公式ブログのSalesforce Hosted MCP Server 使い始めで確認できます。設定そのものは難しくありませんが、そこから先の実行能力に差が出ます

公式SalesforceとConnect AIをどう比較した?

実際のSalesforceデータ(14件の取引先、実際のフィールド値、実際のリレーション)に対して、具体的な機能シナリオを検証しました。各テストには、明確な合格・不合格の基準を設けています。

緑のチェックマーク()は優れた結果を、赤の×()はその接続方式が実行できないことを示します。両者が同等の場合は、どちらにもチェックマーク(=)を付けています。

テスト

CData Connect AI

公式Salesforce MCP

結果

テスト1: 基本的なデータ読み取り

14件の取引先を、フィールド値とIDが一致する形で返した。

同じ結果。14件の取引先を返した。

両方合格

テスト2: 集計(COUNT、AVG、MAX)

1つのSQLクエリでCOUNT、AVG、MAXを実行した。

集計機能なし。すべてのレコードをクライアント側で取得して処理する必要がある。

Connect AIの勝ち

テスト3: オブジェクトをまたぐJOIN

1つのSQLクエリで取引先(Account)と取引先責任者(Contact)を結合した。

getRelatedRecordsは親IDが既知である必要があり、1件ずつしか処理できない。

Connect AIの勝ち

テスト4: パラメータ化フィルタリング

型付きパラメータを使った標準SQLの@param構文。

Salesforce Object Query Language(SOQL)のWHERE句。どちらの方式もインジェクションに対して安全。

両方合格

テスト5: GROUP BY

1つのGROUP BYクエリで種別ごとの件数集計を返した。

公式のGROUP BYサポートなし。

Connect AIの勝ち

テスト6: 選択リスト(Picklist)のメタデータ

専用の仮想テーブルPickListValuesとして公開している。

getObjectSchemaが、必須フラグ・フィールド長・読み取り専用ステータスとともに、選択リストのデータをフィールド定義の中に埋め込んでいる。

両方合格

テスト7: 日付フィルタリング

標準SQLの日付比較(>= '2026-01-01')。

SOQLの日付リテラル(TODAY、LAST_N_DAYS:7)。どちらも機能的に正しい。

両方合格

テスト8: 複数オブジェクトにまたがる集計

Account LEFT JOIN OpportunityをGROUP BY Accountで結合した1つのクエリを、サーバー側で実行した。

複数回の往復とクライアント側での集計が必要。

Connect AIの勝ち

8つのテストを通じて、パターンは一貫していました。基本的な読み取り操作と標準的なフィルタリングでは、両者は同等の性能を示しています。差が出るのは、集計・GROUP BY・JOIN・複数オブジェクトのクエリといった分析系の操作です。

いずれのケースでも、Connect AIはデータ層で計算を実行しますが、公式Salesforce MCPは呼び出し側のアプリケーションが先にレコードを取得し、クライアント側で結果を計算する必要があります。AIエージェントがこうした操作をデータ層で実行できなければ、対象となるレコードをすべて取得しない限り分析的な質問に答えられません。

往復回数もトークン消費も増え、データ量が増えるほどスケールしなくなるということです。分析業務を動かす本番のAIエージェントにとって、この違いは些細ではなく構造的な問題です。組織としてどの接続方式を採用するかは、評価軸とセキュリティ要件を整理したうえで判断する必要があります。3つの評価軸とセキュリティ8項目を具体的に解説したMCP接続方式の選び方が参考になります。

13の機能をどう評価した?

13機能の評価は合格・不合格の判定にとどまらず、ストアドプロシージャ・書き込み操作・データソースをまたぐJOIN・権限の可視性について、実装の質と実務上のトレードオフまで踏み込んでいます。

機能

CData Connect AI

公式Salesforce MCP

データの読み取り

✓ 対応

✓ 対応

オブジェクトをまたぐJOIN

✓ 対応

~ 部分対応(SOQLのドット記法とgetRelatedRecordsツールで一部のJOINに対応可能)

集計(GROUP BY、SUM、AVG)

✓ 対応

✗ 非対応

パラメータ化クエリ

✓ 標準SQL

~ SOQLのみ

選択リストのメタデータ

~ 専用テーブル

✓ より詳細で組み込み済み

必須フィールドの検出

~ 部分対応(読み取り専用情報)

✓ 明示的なフラグ

フィールド長・型の詳細度

~ 基本的なSQL型

✓ 公式のSF型

リレーションのたどり方

✓ JOIN

✓ レコード単位のツール

書き込み操作

✓ 有効化した場合

✓ INSERT/UPDATE

ストアドプロシージャ/バルク操作

✓ 37個のプロシージャ

✗ 非対応

SOQLの日付リテラル

✗ 標準SQLのみ

✓ TODAY、LAST_N_DAYS

データソースをまたぐJOIN(Salesforce+他ソース)

✓ 対応

✗ 非対応

権限の可視性

✓ 接続単位

✓ フィールドレベルのセキュリティ

3つの機能では、明確な勝ち負けではなく部分対応(〜印)という結果になりました。

  • パラメータ化クエリ: どちらの接続方式も対応していますが、構文が異なります。Connect AIは標準SQLの@param、公式MCPはSOQLのWHERE句です。

  • 選択リストのメタデータ: どちらも選択リストの値を公開していますが、公式MCPは必須フラグや読み取り専用ステータスといった制約情報を、フィールド定義の中により詳しく埋め込んでいます。

  • 必須フィールドの検出: Connect AIは読み取り専用のメタデータを通じて部分的に把握できますが、公式MCPは明示的な必須フラグを公開しています。

書き込みを行うエージェントにとって、こうした違いは実務上の影響を伴います。書き込みの前に必須フィールドを確実に検出できないエージェントは、実行時にバリデーションエラーを起こしてしまうでしょう。

選択リストの制約情報を持たないエージェントは無効なフィールド値を送信してしまい、APIのエラー処理次第ではサイレントに失敗することもあります。この評価表の「部分対応」に当たる項目こそが、本番運用に耐えられるかどうかを左右します。

それぞれの得意分野は?

CData Connect AI

公式Salesforce MCP

分析やマルチソースの業務に最適

  • 分析・レポーティング業務

  • 1つのクエリでのオブジェクト横断JOIN

  • サーバー側での集計(GROUP BY、SUM、AVG)

  • 複数データソースをまたぐクエリ(Salesforce+MySQLなど)

  • バルク処理・ETL(抽出・変換・ロード)操作(37個のストアドプロシージャ)

  • GetDeleted/GetUpdatedによる変更追跡

  • 標準SQL構文によるパラメータ化クエリ

  • リード変換・マージ・削除の取り消し操作

Salesforce公式の書き込み・メタデータ処理に最適

  • 詳細なスキーマメタデータ(必須フラグ、フィールド長)

  • SOQLの日付リテラル(TODAY、LAST_N_DAYS:7)

  • フィールド定義に埋め込まれた選択リストの情報

  • IDが分かっている場合のレコード単位の操作

  • 設定不要の公式なINSERT・UPDATE

  • フィールドレベルのセキュリティと読み取り専用の検出

  • Salesforce公式のセマンティクスとオブジェクトモデル

  • シンプルなレコードクエリ向けの軽量な構成

公式MCPを本番で使う場合は、運用面の前提もあわせて確認しておきたいところです。Salesforce側のMCPサーバーは機能ごとに有効化の単位が分かれており、Beta表記の残る機能も含まれます。エージェントが触れる範囲はプロファイルや権限セット、フィールドレベルセキュリティの設定に完全に依存するため、「誰のどの権限でエージェントが動いているか」を組織として決めておく必要があります。Connect AIの場合はこの制御がワークスペース単位のアクセス制御と監査ログに寄っているので、複数システムをまたぐときの棚卸しが一箇所で済むという違いがあります。

結論は?

検証データを見ると、それぞれの接続方式には異なる役割があることが分かります。同様の実測比較をkintoneの公式MCPとConnect AIで行ったkintone MCPとConnect AIの実測比較でも、コストと正確性の面で近い傾向が確認できました。

公式Salesforce MCPが適しているのは、書き込みの前にSalesforceのスキーマを調べる場面です。フィールドのバリデーション、必須フィールドのチェック、プラットフォームに公式な制約情報の把握など、Salesforceを内側から知っているからこそ得られる情報は少なくありません。単一システムのワークフローで動く書き込み系のエージェントにとって、この知識は大きな武器になるでしょう。

Connect AIが適しているのは、クエリが単なる取得ではなく計算(集計、GROUP BY、オブジェクト横断のJOINなど)を必要とする場面、または業務が複数のデータソースにまたがる場面です。加えて、Connect AIはマルチソース全体のガバナンス層も備えています。監査ログ、ID連携、ワークスペースの分離といった機能は、公式の接続方式ではSalesforce自体を超えては提供されません。

書き込み系のパスと分析系のパスは、異なる役割を持つ別々のエージェントのためにあるのです。

Salesforceの分析をConnect AIで実現する

CData Connect AIなら、Salesforceを含む400種類以上のデータソースに対してSQL標準の集計・JOIN・37種のストアドプロシージャをそのまま実行できます。エージェント側でレコードを取得してから計算するロジックを組む必要はありません。監査ログやID連携、ワークスペースごとのアクセス制御も標準で備えており、複数システムにまたがるガバナンスも一元管理できます。実際に、独自カテゴリで統一されていない5,100万件超の商品マスタをMCP Server経由でSQLに抽象化した事例もあります。ハルシネーションのリスクを抑えたままLLMによる自動カテゴライズを実現した、ヘルスケア業界(専門商社)の導入事例です。

とはいえ、便利な仕組みほど落とし穴も潜んでいます。SalesforceとClaudeを組み合わせた導入で実際につまずきやすいポイントは、Salesforce×Claude導入でつまずく3つの壁で具体的に整理しています。

Connect AIの14日間無料トライアルを今すぐ開始して、SalesforceデータをAIエージェントに安全に使わせる方法を確かめてみてください。

Salesforceの分析をConnect AIで実現する

CData Connect AIなら、Salesforceを含む400種類以上のデータソースに対してSQL標準の集計・JOIN・37種のストアドプロシージャをそのまま実行できます。エージェント側でレコードを取得してから計算するロジックを組む必要はありません。監査ログやID連携、ワークスペースごとのアクセス制御も標準で備えており、複数システムにまたがるガバナンスも一元管理できます。

デモを見てみる