Salesforce Developers Blog

Salesforce Hosted MCP Serverをセキュアにする方法

Avatar for Philippe OzilPhilippe Ozil
Avatar for ディベロッパーリレーションチームディベロッパーリレーションチーム
Salesforce Hosted MCP サーバーのセキュリティ対策について、認証、認可、権限管理、およびログ記録の観点から学びます。
Salesforce Hosted MCP Serverをセキュアにする方法
September 16, 2026

※本記事は2026年6月30日に米国で公開された How to Secure Salesforce Hosted MCP Serversの抄訳です。本記事の正式言語は英語であり、その内容および解釈については英語が優先されます。

Salesforce Hosted MCP(Model Context Protocol)Server(英語)は、Headless 360を構成する主なコンポーネントの1つで、標準機能(英語)やカスタム機能(英語)をサーバー経由で利用可能にし、AIエージェントの能力を拡張できます。ツール、プロンプト、リソースをユーザーに公開する際には、データや操作を保護するために、MCPサーバーへのアクセスを安全に保つことがきわめて重要です。

MCPサーバーを構築する開発者やそのサーバーの管理者は、セキュリティモデルを理解しておくことで、誰が、何に、いつ、どのような方法でアクセスできるかを制御できます。この記事では、Salesforce Hosted MCP Serverの認証、認可、権限の制御、ログの記録のベストプラクティスについて説明します。

Salesforce Hosted MCP Serverのセキュリティモデルを理解する

Salesforce MCPのセキュリティモデルは、3つのレイヤーで構成されています。

  1. 認証 – 誰がリクエストを行っているかを確認します。
  2. 認可 – そのユーザーが何を実行できるかを決定します。
  3. 権限の制御 – サーバーが公開する基本要素(ツール、プロンプト、リソース)を利用する際に、オブジェクトや項目のレベルで細かなアクセス制御を適用します。

これらのセキュリティレイヤーに加え、監査やコンプライアンスに対応できるよう、すべての操作がログに記録されます。

3つのセキュリティレイヤーとログを示す図
最初の2つのレイヤーはMCP標準に直接関連しており、3つ目のレイヤー(権限の制御)はSalesforce Platform固有のものです。それぞれのセキュリティレイヤーは、1つ前のレイヤーの上に成り立っています。ユーザーが誰なのかを確認するまでは、そのユーザーに何を許可するかを決めることはできません。そして、認可ルールがなければ、権限を適用することはできません。

これらのレイヤーとログがどう連携しているかを理解すれば、多層防御戦略を構築しやすくなります。各レイヤーを詳しく見ていきましょう。

認証 – 本人確認

認証は、最初の防御線となります。ユーザーの身元を確認します。

MCPの仕様(英語)では、認証と認可は実装に必須の技術的要件としては定義されていません。しかし、適切なセキュリティ対策がなければ、権限のないユーザーが機密データにアクセスしたり、望ましくない操作を実行したりするおそれがあります。そのため、この記事では、エンタープライズ環境に必須の要件として扱います。

MCPでは、認証と認可の仕組みとしてOAuth 2.0(英語)を規定しています。MCPでサポートされているのはOAuth 2.0の一部のみで、すべての認可フローやグラントタイプを利用できるわけではありません。また、ClaudeやChatGPTなどの広く使われているクライアントがサポートするフローは、Salesforceよりも少数です。

MCPは比較的新しいものですが、OAuth 2.0は10年以上使われており、Salesforce Platformには、クライアントとして、あるいはサーバーとして動作する場合でも、OAuthと連携するためのさまざまな仕組みが用意されています。そのため、Salesforce開発者は、OAuthのセキュリティを自分で実装する必要がなく、外部クライアントアプリ(ECA)を通じて宣言的に制御できます。

Salesforceは、1つのECAを複数のMCPクライアントで共有するのではなく、MCPクライアントごとに専用のECA(Claude用、ChatGPT用、Cursor用など)を作成することを強く推奨します。こうすることで、アクセス制御とクライアントのアクティビティの監査が容易になります。
Salesforce Hosted MCP Serverでは、ECAを介した認可コードフローのみをサポートしています。そのため、ユーザーがMCPサーバーに接続する際には、Salesforceでの認証が必要になります。各ユーザーのSalesforceユーザーアカウントが、MCPセッションに関連付けられます。

Notes:

  • インテグレーションユーザーなど、プリンシパル(実行主体)となるユーザーを設定したサービスアカウントを、すべてのセッションで共通して使用するように指定することはできません。これは避けるべきアンチパターンです。
  • 現時点では、マシン間のフローをサポートする予定はありません。組織への接続とMCPツールに対するアクセスの許可には、引き続き人間が関与します。

デフォルトでは、組織内のすべてのユーザーがECAに接続し、MCPサーバーにアクセスできるようになっています。ただし、認可ルールを指定すれば、アクセスを制御できます。

認可 – アクセス制御

認可により、ユーザーが実行できる操作を決定します。ユーザーの認証が完了すると、Salesforceはそのユーザーの権限を評価し、どのリソースにアクセスできるかを判断します。
認可を制御する仕組みはいくつかあります。

OAuth範囲でアクセスを認可する

認可の第一段階として、ECAの設定時に指定するOAuth範囲により、特定のリソースへのアクセスが制御されます。

新たに追加された「SalesforceでホストされているMCPサーバーにアクセス(mcp_api)」範囲によって、Salesforce Hosted MCP Serverへのアクセスが許可されます。この範囲は、Platform API(REST、Tooling、Metadataなど)へのフルアクセスを許可する「APIを使用してユーザーデータを管理(api)」範囲の使用を避けるために導入されました。

原則として、AIエージェントにAPIへのフルアクセスを許可のではなく、MCPを介して限られた「安全な」操作だけを公開することが推奨されます。

承認済みユーザーのみにアクセスを許可する

デフォルトのECA設定では、組織内のすべてのユーザーが認証を行い、MCPサーバーにアクセスできます。アプリケーションポリシーを設定すると、事前に承認した特定のユーザーにのみアクセスを限定できます。この設定では、特定のプロファイルや権限セットが割り当てられたユーザーを選択できます。

たとえば、次の設定では、「MCP Client User」権限セットを持つユーザーだけがECAに接続できます。
MCP Client User権限セットを持つユーザーのみにアクセスを許可するECA設定を示すスクリーンショット

IP制限を適用する

ECAを利用できるユーザーを限定するだけではなく、接続可能なIP範囲を指定してIPアドレスによる制限を適用することもできます。これらの制限は、デフォルトのECA設定の[アプリケーション認証]で有効になっています。
IP制限の適用方法を示すECA設定のスクリーンショット
ネットワークアクセス]設定メニューで、信頼済みIP範囲をすべてのユーザー、または特定のユーザープロファイルに対して指定できます。

更新トークンの有効期間を短縮する

ユーザーがECAでログインするとアクセストークンが取得され、その後のすべてのMCP操作にそのトークンが渡されます。トークンは、有効期間が終了したら更新する必要があります。

デフォルトのトークン有効期間は1年ですが、調整が可能で、本番環境で短く設定することもできます。これにより、トークンが盗まれ、悪意のある目的で再利用されるリスクを軽減することができます。トークンの有効期間を制御するには、ECAの設定を開き、[アプリケーション認証]にある[更新トークンポリシー]を探します。更新トークンのセキュリティを強化する推奨設定については、こちらのドキュメント(英語)で紹介しています。

アクセス権を取り消す

有効期限が切れる前にECAのトークンを取り消す必要がある場合は、[設定]に移動して[OAuthの利用状況]を検索し、ECAを選択して個々のトークンを取り消すか、一括で取り消します。
ECAのトークンを取り消す方法を示すスクリーンショット

MCPサーバーを有効化する

デフォルトでは、すべてのMCPサーバーが無効になっています。AIエージェントに公開するMCPサーバーだけを有効にしてください。

たとえば、以下の図では1つのカスタムサーバーと2つの標準サーバーのみを有効にしています。
3つの有効なMCPサーバーを示すスクリーンショット

MCPツールにアノテーションを追加する

厳密な意味でのセキュリティ対策ではありませんが、公開するMCPツールには、その動作を示すアノテーションを付けることが推奨されます。これにより、AIエージェントにツールをどのように使用すべきかを伝えられます。たとえば、AIエージェントに対して、レコードの削除など破壊的な可能性のある操作を実行する際にユーザーに確認を求めるべきか、あるいはツールを複数回実行しても安全かどうか、といった情報を提供できます。
MCPツールのアノテーション設定のスクリーンショット
Note: MCPツールのアノテーション(英語)をクライアント側でサポートするかどうかは任意であるため、すべてのAIエージェントがその内容に従うとは限りません。

権限の制御 – きめ細かなアクセス管理

ECAの設定によって特定のMCPサーバー自体へのアクセスを制限することはできませんが、サーバーを構成する各ツールへのアクセスは制御できます。

MCPツールは、ECAを使用して認証したユーザーと同じ権限で実行されます。つまり、Salesforceの中核的なセキュリティモデルが、次のすべてのレベルで適用されます。

  • オブジェクトレベルのアクセス制御(CRUD権限)
  • 項目レベルのセキュリティ(FLS)による制限
  • レコード共有ルール

個別のセキュリティ要件に対応する(英語)ために、Agentforce、Apex、Flowを使ってカスタムツールを実装する(英語)こともできます。この方法を採用する場合は、必ずセキュリティのベストプラクティスに従ってください。

機密性の高い操作を保護し、最小権限の原則に従うために、権限セットを使ってください。ユーザーには、業務に必要な権限だけを付与します。権限は定期的に見直し、不要になったアクセス権は取り消してください。

また、本番環境にデプロイする前に、権限をテストしてください。たとえば、runAsメソッドを使ってMCPツールに対してApexテストやFlowテストを実行し、さまざまなアクセスレベルでユーザーの動作をシミュレーションします。

ログの記録 – アクセスのトラッキング

ログを記録することにより、誰が、何に、いつアクセスしたかを示す監査履歴が作成されます。こうした記録は、セキュリティの監視、コンプライアンス、トラブルシューティングに不可欠です。

MCPツールによって実行されたすべてのアクションは、監査履歴の中でECAに接続したユーザーに紐付けられます。Salesforceは、イベントモニタリングを使用してMCPサーバーのアクティビティを自動的に記録します。

ログにアクセスするには、[設定]に移動し、「イベントログファイルブラウザー」を検索します。[イベントの種別]で[API合計使用量]を選択して絞り込みます。イベントログのCSVファイル��、API_CLIENT_CATEGORY列の値がSALESFORCE_HOSTED_MCPである行をフィルタリングして、MCPトラフィックを特定できます。MCPツールを呼び出したユーザーや、影響を受けたオブジェクト(エンティティ)などの詳細を確認できます。
MCPツールの呼び出しが表示されるように絞り込んだイベントログのスクリーンショット
ログは定期的に確認してください。STATUS_CODEでエラーを探し、USER_NAMECLIENT_IPを見て予期しないアクセスパターンがないかを確認しましょう。何か見つかった場合、セキュリティ上の問題や権限設定の誤りがあるかもしれません。

まとめ

Salesforce Hosted MCP Serverのセキュリティを確保する方法を確認し、多層的セキュリティアーキテクチャーを構成するすべてのコンポーネントを見てきました。

  • 認証で、ユーザーの本人確認を行う
  • 認可で、ユーザーがアクセスできるツールを制御する
  • 権限の制御で、きめ細かなデータアクセス制御を適用する
  • ログの記録で、コンプライアンスとセキュリティ監視のための監査履歴を作成する

MCPサーバーとツールのセキュリティアーキテクチャーをまとめた図
この記事で紹介したセキュリティのベストプラクティスを実践して、便利なMCPツールをAIエージェントに提供しながら、データを確実に保護してください。

関連情報

執筆者について

Philippe Ozilは、Salesforce Platformの開発に取り組むプリンシパルデベロッパーアドボケイトです。技術的なコンテンツを執筆し、カンファレンスにもよく登壇します。フルスタック開発者で、API、DevOps、ロボティクス、VRプロジェクトに注力しています。XLinkedInBlueskyでのフォロー歓迎。GitHubのプロジェクトもチェックしてください。