Salesforce「Headless 360」は何を変えるのか――AIエージェント向けMCP設計を読み解く｜2026年8月26日版
Salesforceが拡張した「Headless 360」の核心は、CRMの画面をAIに操作させることではありません。データ更新やユーザー管理、Apexのデプロイといった業務機能を、権限付きのAIエージェントから直接呼び出せる形に変えることです。
中心になるのが、オープン標準のModel Context Protocol（MCP）です。ただし、何千もの操作をそのままAIへ見せる設計ではありません。Headless 360 MCP Serverは、操作の発見・仕様確認・実行を少数のツールに分け、機能追加に耐えやすい接続面を作っています。
今日押さえたいポイントは次の4点です。
- Headless 360 MCP Serverはオープンベータで、APIバージョンはv67.0以降が対象
- AIに公開する入口を4ツールに絞り、利用可能な操作は実行時に検索する
- OAuthとSalesforce側の権限を引き継ぎ、無制限なデータ操作を前提としない
- 導入時は「接続できるか」より、書き込み権限と監査方法の設計が重要になる
Headless 360で変わるAIエージェントの接続方法
従来、AIエージェントからSalesforceを利用するには、用途ごとにAPIやワークフローを選び、個別の連携処理を作る場面が多くありました。対象業務が増えるたびに、ツール定義や認証、エラー処理を追加する必要があります。
Headless 360は、Salesforceに蓄積された次の資産を再利用可能な機能として外部へ公開します。
- 顧客や商談などのデータ
- 承認フローや入力規則を含む業務ロジック
- ユーザー、権限セット、認証情報の管理機能
- Apexやイベント連携などの開発・運用機能
- 組織で設定済みの認証、権限、ガバナンス
重要なのは、単なるデータベース接続ではない点です。AIエージェントは、企業がSalesforce上で積み上げた権限や業務ルールを通して処理を実行します。
Salesforceは2026年8月19日の発表で、Headless 360 MCP Serverに加え、Data 360 MCP Server、100を超える再利用可能なAgent Skills、React向けのSalesforce Multi-frameworkなどを案内しました。Headless 360 MCP ServerとHeadless Experience Layerはオープンベータ、Data 360 MCP ServerやAgent Skillsリポジトリなどは一般提供とされています。提供状況は製品や地域、契約によって異なります。
4ツールで大きな機能群を扱う仕組み
Headless 360 MCP Serverの技術的な特徴は、Salesforceの機能を一つずつMCPツールとして並べないことです。エージェントから見える入口は、次の4種類に整理されています。
Discover：実行できる操作を探す
エージェントが依頼内容を解釈し、利用可能なSalesforce操作の索引を意味検索します。
たとえば「退職者のアカウントを無効化する」という依頼に対し、エージェントは最初から特定のAPI名を知っている必要がありません。Discoverを使い、現在のサーバーで利用できる関連操作を探します。
Describe：操作仕様を確認する
候補となる操作が見つかったら、Describeで必要な引数や仕様を取得します。これにより、操作内容を推測したまま実行するリスクを抑えられます。
Dispatch：選んだ操作を実行する
仕様に沿って引数を組み立て、Dispatchで処理を実行します。レコードの作成・更新、ユーザー管理、Apexの操作、イベント連携の構築などが想定されています。
Dispatch（Read-Only）：読み取り専用で実行する
参照だけで済む処理には、読み取り専用のDispatchが用意されています。調査や確認の段階で書き込み可能なツールを使わせずに済むため、権限分離の入口として重要です。
ここがポイント: AIへ何千もの固定ツールを一度に渡すのではなく、「探す→仕様を読む→実行する」という手順を共通化しています。機能群が増えても、エージェント側の接続面を小さく保つ設計です。
なぜ「ツール数を増やさない」設計が重要なのか
AIエージェントへ大量のツール定義を一括で渡すと、選択肢が増え、モデルが適切な操作を選ぶために扱う情報も膨らみます。サーバー側に機能が追加されるたび、クライアント側の定義更新が必要になる可能性もあります。
Headless 360 MCP Serverでは、利用可能な操作を実行時にDiscoverで探します。これにより、次の分離が可能になります。
- MCPクライアントは少数の安定したツールだけを扱う
- Salesforce側は操作ライブラリを継続的に拡張する
- エージェントは必要になった操作の仕様だけを取得する
これは、APIをMCP形式に置き換えただけではありません。巨大な業務システムの機能を、AIが段階的に発見できるようにする抽象化です。
一方、意味検索で操作候補を選ぶ以上、意図と異なる候補が返る可能性は残ります。Describeで仕様を確認することに加え、重要な書き込み操作では、人による承認や実行前プレビューを組み合わせる必要があります。
OAuth対応だけでは安全性は完成しない
Headless 360 MCP Serverの利用には、mcp_apiスコープを設定したExternal Client AppとOAuth認証が必要です。本番環境とSandbox／Scratch環境では接続先も分かれています。
標準的な認証を使えることは重要ですが、認証に成功したことと、安全に運用できることは同じではありません。AIエージェントは、メールの閲覧やデータベース検索だけでなく、APIを通じて実際の処理を起動できるためです。
導入前には、少なくとも次を決める必要があります。
- エージェント専用ユーザーに付与する権限
- 読み取りと書き込みを分ける基準
- ユーザー停止やコード配備など、承認必須とする操作
- 誰の指示で何を実行したかを追える監査ログ
- プロンプトインジェクションを受けた場合の権限制限
- 本番接続前にSandboxで検証する手順
Google Cloudが2026年8月24日に公開したAIインフラ調査では、技術リーダーの79％が、推論基盤の拡大における最大の課題としてセキュリティ、ガバナンス、運用のいずれかを挙げています。エージェントがデータを読むだけでなく処理を実行する段階では、従来のアプリ利用者より細かな権限制御が必要になります。
日本の開発・運用現場への影響
国内企業にとっての変化は、Salesforceを使う新しい画面が増えることではありません。Claude Code、Codex、CursorなどのMCP対応クライアントや独自エージェントから、既存のSalesforce機能を呼び出す選択肢が広がることです。
開発者
個々の業務操作を独自ツールとして作り直す負担を減らせる可能性があります。一方で、ベータ機能を本番ワークフローの中核に据えるのは慎重に判断すべきです。APIバージョン、提供地域、契約条件、エラー時の再実行方式を確認する必要があります。
Salesforce管理者
設定変更やユーザー管理もエージェントの操作対象になり得ます。便利さと同時に、過大な権限を持つサービスアカウントを作らないことが重要です。退職者の無効化など対象が明確な処理から始め、権限セットの付与や認証情報の作成は承認付きにする方法が現実的です。
企業のAI導入担当者
モデル選定だけでなく、業務システム側の「安全な操作面」が導入速度を左右します。検証時には、回答精度だけでなく次の指標を見るべきです。
- 正しい操作をDiscoverできた割合
- 実行前に必要な仕様を取得できた割合
- 権限不足時に安全に停止できたか
- 同じ指示を再実行した際に処理が重複しないか
- 人の承認が必要な操作を自動実行しなかったか
継続ウォッチ
Headless 360は、AIエージェントと業務システムの接続方法が、個別API連携から「実行時に機能を発見する基盤」へ移る動きを示しています。ただし、Headless 360 MCP Serverはオープンベータです。
今後は次の点を確認する必要があります。
- ベータから一般提供へ移る時期と正式なSLA
- Discoverの検索精度と、利用者が候補操作を制限する仕組み
- 書き込み操作に対する承認、監査、取り消しの実装
- 操作ライブラリの拡大範囲と地域別の提供状況
- Salesforce以外のMCPサーバーを併用する際の権限管理
まず試すなら、本番データを変更しない参照処理から始めるのが安全です。次の判断点は、AIが操作を見つけられるかではなく、誤った操作を選んだときに実行前で止められるかです。