CRM への MCP 書き込み権限

まず読み取り権限だけを付与し、書き込みスコープは 1 つずつ独立した意思決定として扱ってください。責任者を名指しし、影響範囲を上限で区切り、あとから実際に読める監査ログを用意することが条件です。多くの GTM チームにとって説明可能な順序は、最初の 30 日は読み取り専用、その後は名前を挙げた一部のオブジェクトに限って作成と更新、そして inbound のコンテンツを取り込むエージェントセッションからは削除も一括書き込みも決して行わない、というものです。問題はエージェントが信頼できないことではありません。CRM の書き込みスコープが、あなたが承認したい意思決定よりも粗い粒度でしか付与できないこと、そして誤った実行を巻き戻すための監査証跡が主要 2 プラットフォームのいずれでも有料アドオンであることが問題なのです。

このページは意思決定のフレームワークです。実際に何を付与しているのか、各段階を通す 4 つの問い、登っていくべきはしご、そして残しておく付与記録を扱います。MCP サーバーが何かはすでに理解している前提です。まだであれば MCP サーバーとは何かから読んでください。

書き込みスコープが実際に付与するもの

Model Context Protocol の 2025-11-25 リビジョンでは、MCP サーバーは OAuth 2.1 のリソースサーバーとして動作し、自身のスコープを公開します。クライアントはそれを発見します。これは見た目以上に重い話です。仕様のスコープ選択戦略によれば、サーバーの 401 チャレンジに scope パラメータが含まれない場合、クライアントは scopes_supported に列挙されたスコープをすべて要求します。汎用の AI クライアントには絞り込みに使えるドメイン知識がないため、一式まとめて要求し、絞り込みは同意画面に委ねます。ベンダーによる tool の分解のしかたが、そのままあなたの権限粒度になります。望んだかどうかにかかわらず、それを引き継ぐことになります。

2 つの CRM プラットフォームは、正反対の方向に分解しました。

Salesforce は動詞ごとにホスト型サーバーを分けました。GA は 2026 年 4 月 29 日です。platform/sobject-reads（読み取りとクエリのみ、ミューテーションなし）、platform/sobject-mutations（作成と更新、削除なし）、platform/sobject-deletes、そして platform/sobject-all（フル CRUD）です。各サーバーは管理者が有効化するまで無効のままで、Salesforce は専用の OAuth スコープ mcp_api を用意しました。エージェントを接続するために、Platform API へのフルアクセスを与える api スコープを渡さずに済ませるためです。

HubSpot は逆の道を選びました。mcp.hubspot.com のリモートサーバーは 2026 年 4 月 13 日に GA となり、書き込み用の tool は manage_crm_objects ただ 1 つです。これがコンタクト、会社、deal、チケット、明細、商品、アクティビティにまたがる作成と更新を一括で覆います。エージェントに通話の記録は許すが deal の金額の変更は許さない、という構成は存在しません。同じ tool だからです。見積、請求書、注文、カート、サブスクリプション、セグメント、そしてマーケティングとコンテンツのオブジェクトは読み取り専用のままです。

したがって、どの評価でも最初の一手は、デモの後ではなく前に、ベンダーへ tool の一覧とスコープの一覧を求めることです。書き込み面が 6 つのオブジェクトにまたがる 1 つの tool なら、あなたのポリシー上の問いはもう「どのフィールドか」ではありません。「そもそも付与するのか」です。

4 つの問いによるゲート

提案された書き込みスコープは、付与する前にこの 4 つを通してください。1 つでも通らないスコープは付与しません。

可逆性。 エージェントが誤った値を書き込んだとき、バックアップからのリストアなしで以前の値を復元できますか。フィールド履歴とアクティビティログがあれば、上書きは手作業で戻せます。削除されたレコードやマージされた重複は戻せません。
1 回の呼び出しあたりの影響範囲。 1 回の tool 呼び出しが触れられるレコードは何件ですか。上限は、あなたの ops アナリストが 1 時間で手作業で直せる件数に設定してください。2 名体制の RevOps チームなら既定値 [200] です。そして上限パラメータを持たない一括処理やクエリ後更新の tool は拒否してください。
レコードの書き手。 書き込みが着地したとき、そこに残る名前は誰のものですか。答えが「接続を設定した人」であれば、監査証跡はエージェントの操作を、その時刻に眠っていた人間に帰属させることになります。
可観測性。 エージェントの書き込みと人間の書き込みを区別できるログはありますか。保持期間はどれだけで、あなたのエディションに含まれていますか。最初のインシデントの後ではなく、付与の前に答えてください。

書き込みのはしご

1 段ずつ登り、各段で滞在期間を固定します。この段階はプラットフォームの実際の設定に対応しており、成熟度の比喩ではありません。

段階 0 — 読み取り専用。 既定値であり、運用開始から 30 日未満のベンダーにとって正しい定常状態です。Salesforce では platform/sobject-reads だけを有効化します。HubSpot では読み取りスコープを付与し、同意画面で manage_crm_objects を拒否します。チームが CRM エージェントに期待する価値のほとんど — パイプラインへの質問、アカウントのリサーチ、商談準備、データ衛生のレポート — は、書き込みリスクゼロのままここで手に入ります。

段階 1 — エージェント固有のオブジェクトへの追記のみの書き込み。 タスク、メモ、記録されたアクティビティです。この段階を定義する性質は、エージェントが新しい行を作るだけで、人間が設定したフィールドを決して上書きしないことです。Salesforce では platform/sobject-mutations を使い、オブジェクト権限を Task、Event、およびカスタムのアクティビティオブジェクトに限定します。HubSpot ではこの段階は独立した付与として存在しません。manage_crm_objects は同じ tool の中に deal とコンタクトへの書き込みを含むため、HubSpot で段階 1 に相当することをやるには、段階 2 の権限を受け入れたうえで、接続ユーザー自身のオブジェクト権限とプロパティ権限で絞り込みを効かせるしかありません。

段階 2 — 名前を挙げた標準オブジェクトへの作成と更新。 コンタクト、会社、そして deal または商談です。報酬や取締役会向け forecast に流れ込むもの — 金額、クローズ日、ステージ、オーナー — はフィールドレベルセキュリティで除外し、残りのフィールドで段階 2 を 30 日間問題なく回してから解禁します。Salesforce は接続ユーザーの権限セットのフィールドレベルセキュリティでこれを強制します。MCP の tool はオブジェクト権限、フィールドレベルセキュリティ、共有ルールを尊重するため、実際の制御面はサーバーの選択ではなく権限セットです。

段階 3 — 削除、一括処理、メタデータ。 platform/sobject-deletes、platform/sobject-all、そして Setup にまで届くサーバーです。これは範囲を区切った移行のために人間の管理者の対話セッションへ付与し、同じ日に取り消します。ベンダーのエージェントに常時与えるものではありません。

サービスアカウントによる分離と、それが手に入らない理由

直感は正しいのです — 人間の identity ではなくエージェント自身の identity を与えるべきです — が、プラットフォーム側の対応は半分にとどまります。

Salesforce のホスト型 MCP サーバーは authorization code フローのみをサポートします。machine-to-machine のフローもサービスアカウント接続もなく、人間が認証してアクセスを許可します。したがってエージェントの書き込みはすべて実在の Salesforce ユーザーの下に着地し、そのユーザーの権限で実行され、そのユーザーの名前がレコード履歴に残ります。実務として成立する分離は、専用の名前付き統合ユーザーを立て、そのユーザー専用の権限セット、専用の External Client App、その権限セットに限定した app policy、App Authorization での IP 制限、そして External Client App の既定である 1 年から短縮したトークン有効期間を組み合わせることです。本番を向ける前に、Apex の runAs で結果として得られるアクセスを検証してください。

HubSpot は同じ継承関係を直接明言しています。すべての操作は接続ユーザーの既存の権限を尊重し、ユーザーは自分がすでに到達できるレコードしか閲覧・変更できません。つまり制御点は、どのユーザーから接続するかです。スーパー管理者アカウントから接続すれば、ワンクリックでスーパー管理者の書き込み範囲をエージェントに渡すことになります。

両者から導かれる規則はこうです。CRM の MCP サーバーを、管理者のセッションから接続してはいけません。 先にユーザーを作り、範囲を絞り、それから接続します。

dry run は存在しない — 3 つの代替手段

Salesforce のホスト型サーバーにも HubSpot のそれにも、書き込みの dry-run モードやプレビューモードはありません。MCP 自体も dry run のプリミティブを定義していません。代わりになるものは 3 つです。

まずサンドボックス。 Salesforce は本番と並んでホスト型サーバーのサンドボックス用パス（/platform/mcp/v1/sandbox/...）を公開しています。本番に向ける前に、代表的なデータを入れたサンドボックスに対して、滞在期間をまるまる使ってエージェントを走らせてください。
提案してから適用する。 エージェントは platform/sobject-reads に留め、意図した変更をレコード ID とフィールド単位の変更前・変更後の値として出力させます。人間、または別途スコープを絞ったプロセスがそのバッチを適用します。これでスループットのほとんどを保ったまま、書き込み権限をモデルのコンテキストから完全に外せます。
クライアント側の確認。 MCP 仕様は、tool の呼び出しを拒否できる人間が常にループの中にいるべきだと述べ、クライアントはサーバーを呼ぶ前に tool の入力をユーザーに見せるべきだとしています。あなたのクライアントが実際に両方を行っているか確認してください。これは MUST ではなく SHOULD であり、クライアントによって差があります。

制御手段ではないものが 1 つあります。tool の annotation です。仕様は、信頼できるサーバー由来でない限りクライアントは annotation を信頼できないものとして扱わなければならない、と明示しています。つまり tool 定義の readOnlyHint はドキュメントであって強制ではありません。読み取り専用はスコープ、サーバー、権限セットの層で強制されなければ、強制されていないのと同じです。

監査証跡と、その費用

Salesforce 自身のセキュリティガイダンスは、Event Log File Browser で API_CLIENT_CATEGORY を SALESFORCE_HOSTED_MCP で絞り込んでエージェントのトラフィックを特定し、続いて STATUS_CODE でエラーを、USER_NAME と CLIENT_IP で異常を確認する、というものです。これは機能しますが、契約前に費用を見積もっておくべき条件が 2 つあります。Developer Edition 以外では Event Monitoring に Salesforce Shield または Event Monitoring アドオンが必要で、無償で公開されるのはログインとログアウトのイベントだけです。そして event log file は、拡張保持のアドオンがなければ既定で約 1 日の保持しかありません。

HubSpot のアカウントアクティビティ／監査ログ API は Enterprise 限定で、製品内のビューは 30 日分を表示し、読み取りイベントはそもそも記録されません。書き込まずに持ち出すエージェントは、そこに痕跡を残しません。

2 つの事実は同じ方向を指しています。監査の予算項目が予算会議を生き延びなかったのなら、書き込みスコープも生き延びるべきではありません。

影響範囲に上限を置く理由は prompt injection

具体例は ForcedLeak です。Noma Security が 2025 年 7 月 28 日に Salesforce へ報告し、2025 年 9 月 25 日に CVSS スコア 9.4 で公開しました。攻撃者の指示はごく普通の Web-to-Lead フォーム送信に埋め込まれ、CRM の中で不活性なまま残り、後日従業員がその lead について Agentforce に尋ねた時点で実行されました。期限切れで取得可能なドメインが絡む Content Security Policy の許可リストの弱点と連鎖して、CRM データが持ち出されました。Salesforce は 2025 年 9 月 8 日に Agentforce と Einstein 向けの Trusted URLs enforcement を提供しました。

ForcedLeak は MCP の脆弱性ではなく、そう引用するのは誤りです。しかし障害の種類は同じで、そこが要点です。外部の人間が書き込めるフィールドを読むエージェントは、信頼できない入力を実行しているのであり、書き込みスコープはそれを情報漏えいの問題からデータ整合性の問題へと変えます。運用上の規則はこうです。攻撃者が制御しうるフィールド — web-to-lead のペイロード、inbound メールの本文、フォーム入力、チャットの書き起こし、アップロードされた履歴書 — をコンテキストに含むエージェントは、同じセッションで書き込みスコープを持ちません。「信頼できないコンテンツを読む」仕事と「CRM に書き込む」仕事を、2 つの identity を持つ 2 つの接続に分けてください。

付与記録

付与したスコープごとに、ベンダー台帳と同じ場所にこれを 1 つ残します。5 分で済み、年次レビューを可能にする成果物になります。

Vendor / server:      [vendor] — [server id, e.g. platform/sobject-mutations]
Level granted:        [0-3]
Objects + fields:     [explicit list; note excluded fields]
Connecting identity:  [named integration user, not an admin]
Blast radius cap:     [max records per call]
Token lifetime:       [duration; ECA default is 1 year]
Audit source:         [ELF filter / Account Activity API] — retention [N days]
Untrusted-input rule: [does this session read outsider-writable fields? Y/N]
Granted by / date:    [name] / [date]
Review date:          [date + 90 days]
Revocation steps:     [deactivate server / uninstall app / disable user]

注意点

再同意のプロンプトはスコープ変更です。 HubSpot ではスコープを手で選べません。インストール時点でサーバーに存在する tool と、ユーザーが許可した内容の 2 つで決まります。HubSpot が tool を追加すると、既存のインストールは REQUIRES_REAUTHORIZATION を表示し、対処は切断して再接続することです。これは新しく大きくなった tool セットに対して再付与することを意味します。ガード： 再認可のプロンプトはすべて変更管理チケットとして扱い、読み飛ばさずに同意画面を読み直してください。
パイロットのために有効化したサーバーは有効のまま残ります。 Salesforce のサーバーは既定で無効であり、それは初日は守ってくれますが 90 日目は守ってくれません。ガード： 無効化の手順をパイロットの終了条件に入れ、付与記録の 90 日レビュー日に有効なサーバーを棚卸ししてください。
機微データの設定は書き込み面を黙って変えます。 HubSpot の Sensitive Data が有効な場合、アクティビティオブジェクトと会話データは MCP サーバー経由ではブロックされます。ガード： エージェントが実際に到達できるオブジェクトは、ドキュメントではなく自社のポータルで確認してください。実効的な面はアカウント設定によって異なります。
接続ユーザーは漂流します。 無関係な理由で権限セットが広げられ、エージェントの到達範囲もそれに合わせて広がります。ガード： 統合ユーザーには権限セットをちょうど 1 つだけ持たせ、その権限セットはちょうど 1 人のユーザーにだけ割り当てます。そうすれば範囲の拡大が副作用として届くことはありません。