【備忘録】Salesforce Hosted MCP Serverで何ができるのか整理する - SObject系サーバーを中心に見る

Posted at 2026-08-13

はじめに

以前の記事では、Salesforce Hosted MCP Server を有効化し、Claude Desktop から sobject-reads へ接続する流れを整理しました。

前回記事: 【備忘録】Salesforce Hosted MCP Server を使い始める ― Claude Desktop から sobject-reads まで繋ぐまでの流れ

今回はその続編として、Salesforce Hosted MCP Server にはどのような標準サーバーがあるのかを、特に SObject 系サーバー を中心にざっくり整理します。

前回は sobject-reads を使いましたが、公式リファレンスを見ると、SObject 系だけでも次のように用途別に分かれています。

platform/sobject-reads
platform/sobject-all
platform/sobject-mutations
platform/sobject-deletes

本記事では、これらを「どれが強いか」ではなく、AI クライアントにどこまで Salesforce データ操作を許すか という観点で整理します。

※本記事は 2026-08-10 時点で確認した公式情報をもとにした個人の整理メモです。提供条件、名称、画面、対応クライアント、利用できるサーバーは変更される可能性があります。実際に利用する場合は、必ず最新の公式ドキュメントを確認してください。

Salesforce Hosted MCP Server の標準サーバーとは

Salesforce Developers のリファレンスでは、Salesforce が提供する標準 MCP サーバーについて、Salesforce の組み込み Platform / Product capabilities を公開するものとして説明されています。

標準サーバーについて、まず押さえておきたい点は次の通りです。

Salesforce が事前構成した MCP サーバーである
標準サーバーはデフォルトでは無効で、管理者が有効化する
標準サーバーのツールセットは固定で、変更できない
ツール呼び出しには Salesforce の標準セキュリティモデルが適用される
Field-Level Security、オブジェクト権限、共有ルールが各ツール呼び出しに適用される

なお、Hosted MCP Server 自体は、公式ブログによると 2026 年 4 月に GA（一般提供）となり、Enterprise Edition 以上の組織向けの本番利用可能な機能として案内されています。また、Developer Edition でも Hosted MCP Servers が利用可能になっています。ただし、Headless 360 (Beta) のように、個別のサーバー単位では Beta 段階のものも含まれます。

つまり、Hosted MCP Server は「AI から Salesforce を何でも無制限に触れるようにする仕組み」ではありません。

一方で、AI クライアントから自然言語で Salesforce データを参照・変更できる可能性があるため、どのサーバーを有効化するか はかなり重要です。

標準サーバーの大きな分類

公式リファレンス上では、標準 MCP サーバーは大きく次のように整理されています。

SObject 系サーバー

Salesforce の標準オブジェクトやカスタムオブジェクトを扱うためのサーバー群です。

サーバー	ざっくりした役割
`platform/sobject-reads`	読み取り・クエリ・検索・リレーション参照のみ
`platform/sobject-all`	作成・読み取り・更新・削除・クエリ・検索・リレーション参照を含むフル機能
`platform/sobject-mutations`	作成・更新を許可し、削除は含めない
`platform/sobject-deletes`	削除ワークフロー向けに絞ったサーバー

Product-specific 系サーバー

SObject 以外の製品・機能に関係する標準サーバーもあります。

公式リファレンスでは、例として次のようなサーバーが挙げられています。

サーバー	ざっくりした役割
`Data 360`	Data 360 の統合顧客データをクエリする
`Headless 360 (Beta)`	Discover / Describe / Dispatch などを通じて Salesforce Setup や Platform capabilities にアクセスする
`Tableau Next`	Tableau Next 関連のサーバー

本記事では、前回記事とのつながりを重視して、以降は SObject 系サーバーに絞ります。

SObject Reads: まず試すなら読み取り専用

前回の記事で使った platform/sobject-reads は、SObject 系の中では一番安全寄りに理解しやすいサーバーです。

公式リファレンスでは、platform/sobject-reads は標準オブジェクト・カスタムオブジェクトに対する read-only access を提供すると説明されています。

できることは、主に次のようなものです。

スキーマを調べる
SOQL でレコードを取得する
SOSL で複数オブジェクトを横断検索する
リレーションをたどって関連レコードを取得する
現在の認証ユーザー情報を取得する
最近参照・更新したレコードを取得する

一方で、次の操作はできません。

レコード作成
レコード更新
レコード削除

公式ドキュメントでも、sobject-reads は SObject server family の中で最も安全であり、データ変更はできないと説明されています。

そのため、最初の検証では sobject-reads から始めるのが自然です。

例えば、次のような用途に向いています。

商談やケースの要約
会議前の顧客情報確認
関連レコードの探索
レポート作成前のデータ確認
Salesforce データをもとにした質問応答

👉 最初の接続確認・読み取り検証・社内説明には sobject-reads が扱いやすい と整理できます。

SObject All: フル機能だが、最初に有効化するものとは限らない

platform/sobject-all は、SObject 系の中で最も広い機能を持つサーバーです。

公式リファレンスでは、platform/sobject-all は標準オブジェクト・カスタムオブジェクトに対して、次の操作を含む complete set of tools を公開すると説明されています。

create
read
update
delete
query
search
relationship traversal

つまり、sobject-reads が読み取り専用なのに対し、sobject-all は CRUD 全体を含みます。

この違いはかなり大きいです。

観点	`sobject-reads`	`sobject-all`
スキーマ参照	○	○
SOQL クエリ	○	○
SOSL 検索	○	○
関連レコード参照	○	○
レコード作成	×	○
レコード更新	×	○
レコード削除	×	○

公式リファレンスでは、sobject-all を使っても Salesforce の権限モデルは安全網として働き、操作は認証ユーザーの Field-Level Security、オブジェクト権限、共有ルールに制約されると説明されています。

ただし、ここで注意したいのは、Salesforce の権限が効くことと、誤操作リスクがなくなることは別 という点です。

たとえば、ユーザーが UI 上で編集できる項目であれば、AI クライアント経由でも更新できる可能性があります。ユーザーが削除権限を持つレコードであれば、AI クライアント経由で削除できる可能性もあります。

そのため、sobject-all は便利ですが、初回検証でいきなり有効化するよりも、次のような確認を先に置いたほうが安全です。

どのユーザーに接続させるのか
どの Salesforce 組織で試すのか
Sandbox / Scratch Org / Developer Edition で試せるか
更新・削除を許可してよい業務なのか
AI クライアント側で確認プロンプトやレビュー手順を入れられるか
操作ログや監査観点をどう確認するか

👉 sobject-all は「何でもできて便利」ではなく、「読み取りから更新・削除まで含むので慎重に扱うサーバー」 と捉えると理解しやすいです。

SObject Mutations: 作成・更新だけを許可する中間地点

platform/sobject-mutations は、作成・更新を許可しつつ、削除は含めないサーバーです。

公式リファレンスでは、AI エージェントが Salesforce レコードを create / update できる一方で、delete はできないと説明されています。

用途としては、次のようなワークフローが考えられます。

会議メモからフォローアップ Task を作成する
調査結果をもとに Account や Lead の項目を補完する
条件に合う Opportunity の Stage を更新する
Contact や Lead の情報を追加する

ここでのポイントは、変更は許すが、削除は別プロセスに分ける という設計ができることです。

platform/sobject-all だと作成・更新・削除まで含みますが、platform/sobject-mutations なら削除を除外できます。

そのため、AI エージェントにある程度の業務補助をさせたいが、削除まで任せるのはまだ怖い、という場合の中間地点として考えられます。

ただし、削除を含まないから安全、とは言い切れません。更新操作でも、商談ステージ、金額、顧客属性、ケースステータスなど、業務上重要なデータを書き換える可能性があります。

そのため、次のような運用ルールは必要です。

作成・更新前に対象レコードを確認する
一括更新は件数や条件を明示する
重要項目は人間の確認を挟む
Sandbox でプロンプトと操作範囲を検証する

👉 sobject-mutations は、削除を避けつつ、作成・更新ワークフローを試すための選択肢 と整理できます。

SObject Deletes: 削除をあえて分離して考える

platform/sobject-deletes は、削除ワークフロー向けに絞ったサーバーです。

公式リファレンスでは、スキーマ discovery や query tools と delete operations を組み合わせ、対象レコードを特定して削除できる一方で、create / update は除外されていると説明されています。

用途例としては、次のようなものが考えられます。

重複 Lead の整理
誤って作成されたテストデータの削除
データ品質基準を満たさないレコードの削除候補確認
アーカイブ前のデータ整理

ただし、削除は SObject 系の中でも最もリスクの高い操作です。

公式リファレンスでも、削除は highest-risk mutation として、可能な限り human review を要求することが推奨されています。

また、削除されたレコードは Salesforce UI の Recycle Bin から最大 15 日間は復元できると説明されていますが、MCP 経由の undelete tool は現時点で提供されていないと記載されています。

そのため、sobject-deletes は「削除もできるから便利」というより、削除を他の変更操作から分離して、より慎重に扱うためのサーバー と見るほうがよさそうです。

実務で使うなら、最低限次のような確認を入れたいところです。

削除対象を SOQL で事前確認する
削除候補を人間に一覧提示する
件数、条件、対象オブジェクトを明示する
本番ではなく Sandbox でプロンプトを確認する
削除権限を持つユーザーを限定する
Recycle Bin で戻せる期間や運用を確認する

👉 sobject-deletes は、削除専用だからこそ、承認・確認・監査をセットで考えるべきサーバー です。

使い分けのイメージ

SObject 系サーバーは、次のように段階的に考えると整理しやすいです。

やりたいこと	候補サーバー	コメント
まず接続して読めるか確認したい	`platform/sobject-reads`	最初の検証向き
Salesforce データを要約・検索したい	`platform/sobject-reads`	読み取りだけで足りるならこれでよい
Task や Lead を作成したい	`platform/sobject-mutations`	作成・更新はできるが削除は含めない
既存レコードを更新したい	`platform/sobject-mutations`	更新対象と項目の確認が重要
作成・更新・削除まで一通り許可したい	`platform/sobject-all`	権限・監査・確認手順を慎重に設計する
削除ワークフローだけを分離したい	`platform/sobject-deletes`	human review 前提で扱う