Salesforce Headless 360とは？API・MCP・CLI化がCRM運用に与える意味を整理する
Salesforceが2026年4月15日に発表した「Salesforce Headless 360」は、CRMの画面を単に軽くする話ではありません。Salesforce上のデータ、業務ワークフロー、権限、開発・運用機能を、AIエージェントがAPI、MCP tool、CLI commandとして扱えるようにする発表です。
営業やマーケティングの現場から見ると、ポイントは「Salesforceにログインしなくてよくなるか」ではありません。重要なのは、AIエージェントが顧客文脈を読み、更新候補を作り、人の承認を経てCRMへ戻す流れを、既存の業務ルールと権限の上で設計できるかです。2026年6月17日にSalesforce Blogが強調したように、Headless 360では自由な接続面よりも、既存の統制をそのまま継承できる trust の設計が本質になります。
結論を先に言うと、Salesforce Headless 360は、SalesforceをUI中心のSaaSから、AIエージェントが直接呼び出す業務基盤へ広げる動きです。Agentforce 360 がAI CRM化の全体構想だとすれば、Headless 360はその基盤をAPI、MCP、CLIで扱う入口です。既存のSalesforce運用が整っている会社ほど価値が出やすく、逆に入力率や権限設計が崩れている会社では、AI接続の前に運用の土台を直す必要があります。
本記事のポイント
- Salesforce Headless 360は、Salesforceを画面中心のSaaSから、AIエージェントが呼び出せる業務基盤へ広げる発表です。
- Agentforce 360がAI CRM化の全体構想だとすれば、Headless 360はその基盤をAPI・MCP・CLIで呼び出す接続面です。
- Headless 360では、OAuth 2.0、RBAC、FLS、sharing rules、AI Trust Layerの継承に加え、APIごとの認証情報、操作権限、監査ログをそろえることが重要です。
Salesforce Headless 360とは何か
Salesforce Headless 360とは、Salesforceの機能をブラウザ画面の内側に閉じず、API、MCP tool、CLI commandとして外部のAIエージェントや開発環境から扱えるようにする構想です。Salesforceの発表では、Claude Code、Cursor、Codex、Windsurfなどのコーディングエージェントから、Salesforceのデータ、ワークフロー、業務ロジックへアクセスできる方向性が示されています。
ここでいう headless は、利用者がSalesforceを一切見なくなるという意味ではありません。人が画面で操作する場面と、AIエージェントが裏側でデータ取得、下書き作成、テスト、デプロイ、監査を行う場面を分けるという意味です。CRM一般の設計は、Headless CRMとは何かを整理した記事 を先に読むと理解しやすくなります。ヘッドレス全体の考え方は、ヘッドレスとは何かをERP・CRM・CMS横断で整理した記事 もあわせて読むと、Salesforce以外の業務システムとの違いが見えやすくなります。既存のSalesforce AIやAgentforceの位置づけは、Salesforce AIの導入判断 とあわせて読むと整理しやすくなります。
| 発表の要素 | 何ができるようになるか | 実務上の見方 |
|---|---|---|
| MCP tools / coding skills | AIエージェントがSalesforceの機能や開発作業を呼び出しやすくなる | 接続先と権限範囲を先に定義する |
| Agentforce Experience Layer | Slack、音声、WhatsAppなど複数の接点にリッチな操作部品を出せる | 業務の入口をSalesforce画面だけに限定しない |
| Testing Center / Evals / Observability | 公開前後のエージェント挙動をテスト、評価、追跡しやすくなる | 本番投入後の改善ループまで設計する |
| DevOps Center MCP / CLI | 開発、テスト、デプロイの一部を自然言語とCLIで扱いやすくなる | sandbox、本番、承認の境界を明確にする |
Agentforce 360との関係は、全体構想と接続面で分ける
Headless 360を理解するときは、Agentforce 360 との関係を分けて見ると整理しやすくなります。Agentforce 360は、人、AIエージェント、顧客データ、業務アプリ、SlackをつなぐAI CRM基盤の方向性です。一方、Headless 360は、その基盤を画面外のAIエージェントや開発環境から呼び出しやすくする発表です。
| 観点 | Agentforce 360 | Headless 360 |
|---|---|---|
| 役割 | AI CRM化の全体構想 | API、MCP、CLIによる接続面 |
| 主な利用者 | 営業、マーケ、CS、管理者、AIエージェント | AIエージェント、開発者、業務自動化チーム |
| 実務上の価値 | 顧客文脈をもとにAIが業務支援する | CRM画面外から安全に読み取り、下書き、更新候補を作る |
| 導入前の確認 | 既存Salesforce運用が定着しているか | どのデータを読ませ、どの更新を人が承認するか |
この関係を押さえると、Headless 360は単なる開発者向けニュースではなく、SalesforceをAI CRMとして再評価するための重要な検索入口になります。
なぜCRM運用にとって重要なのか
従来のCRM活用では、人が画面を開き、項目を確認し、メモを読み、ステータスを更新していました。Headless 360の方向性では、AIエージェントが顧客データや業務ロジックを直接参照し、会話や開発環境の中で次のアクションを支援しやすくなります。
ただし、これは「CRM入力をAIが全部自動化する」という話ではありません。CRMのAPIやMCP接続で見るべき論点は、API経由・MCP経由で操作するCRM と同じで、何を読めるか、何を書けるか、誰が確定するか、どのログが残るかです。
Headless 360の本質は、SalesforceをAIエージェントに開放することではなく、Salesforceに蓄積された文脈、業務ルール、権限をエージェント運用へ引き継ぐことです。
実務では4つの境界を先に決める
Salesforce Headless 360を前向きに見る会社ほど、最初に「どこまで自動化するか」を急ぎがちです。しかし本番運用では、接続前に境界を切る方が重要です。
| 境界 | 最初の設計 | 曖昧だと起きること |
|---|---|---|
| 読み取り | 参照できるオブジェクト、項目、ユーザー範囲を決める | 不要な顧客情報までエージェントが読める |
| 下書き | 要約、次アクション、更新候補は下書きとして返す | AIの判断がそのままCRMに残る |
| 更新 | ステージ変更や外部送信は人の承認を挟む | 誤更新や誤送信の影響が大きくなる |
| 監査 | 入力、参照先、出力、承認者、実行結果を残す | 問題発生時に理由を説明できない |
この境界設計は、MCPでSalesforce連携する場合の実務論点 とほぼ同じです。Headless 360によって接続手段が増えても、権限設計と監査設計を省略できるわけではありません。
Headless 360で重要なのは、境界の外側より継承される統制
2026年6月17日に公開された Salesforce Blog の「Securing the Agentic Enterprise: Why Trust is the Engine of Headless 360」は、Headless 360 を単なる開発体験の話ではなく、統制を保ったまま接続面を広げる仕組み として説明しています。要点は、AIエージェントがどのUIからSalesforceへ入ってきても、権限とデータ保護をゼロから作り直さなくてよいことです。
従来は、ブラウザ画面が実質的な操作境界になっていました。Headless 360 ではその境界が薄くなるため、守る場所も「画面の外周」から「データと行動」へ移ります。つまり、誰がログインしたかだけでなく、AIエージェントが何を参照し、なぜその更新候補を出し、どこで人が止めるかまで設計しなければなりません。
| 統制レイヤー | Headless 360で継承されるもの | 実務上の意味 |
|---|---|---|
| 認証 | OAuth 2.0 | 接続面が増えても認証方法をばらけさせにくい |
| 権限 | RBAC、FLS、sharing rules | AIエージェントが見てよいデータ範囲を既存ルールで制御しやすい |
| AI保護 | AI Trust Layer | data grounding、prompt injection防御、zero data retention を共通で持ち込める |
| 承認 | Human-in-the-Loop | 会話UI上の提案をそのまま本番更新にしないで止められる |
ここが custom 連携と大きく違う点です。通常の自作連携では、AIエージェントを増やすたびに認証、権限、監査、データ保持を再設計しがちですが、Headless 360 は既存の Salesforce 統制を各接続面へ引き継ぐ前提で組み立てやすくなっています。
Shield系の観測性を前提にしないと、自由な接続面が逆に怖くなる
Salesforce Blog がもう一つ強調しているのが、Headless 360 では observability が速度そのものになるという点です。接続面が Claude、React アプリ、Slack、音声チャネルへ広がるほど、「何が起きたか」を後から追えることが前提になります。
| 機能 | 何を見るか | Headless運用での使いどころ |
|---|---|---|
| Full Copy Sandboxes | 本番に近い設定とフロー | 本番前に agent の推論と接続を高再現で試す |
| Data Mask & Seed | 匿名化データ | PIIを露出させずに sandbox 検証する |
| Salesforce Shield | イベント、更新履歴、監査証跡 | 誤更新や過剰参照を検知し、説明可能性を残す |
| Security Center | 認証設定、API設定、権限ドリフト | 接続面追加による設定ずれを早めに見つける |
| Privacy Center | PII匿名化、削除、同意管理 | agent が触る個人情報の扱いを揃える |
| Backup & Recover | 復旧ポイント | agent の誤削除や破損を戻せるようにする |
この表をそのまま「Headless 360導入前チェック」にしておくと、単に接続できるかではなく、安全に戻せるか、追えるか、止められるか まで確認できます。特に営業やCSのデータは、更新ミスよりも「なぜその変更が起きたのか説明できない」状態が問題になります。
perimeter security だけでは足りず、data と action の設計が必要になる
ブラウザ中心の運用では、操作権限とUIの導線がある程度一致していました。しかし Headless 360 では、会話UIやCLIから同じデータへ到達できます。そのため、守るべき対象は「ログイン境界」だけでなく、データアクセスと行動単位の許可へ移ります。
実務では、次の順番で統制を設計した方が安全です。まず 何を読めるか、次に どこまで下書きを返せるか、その次に どの更新から人の承認が必要か、最後に どのログを残して復旧できるか です。順番を逆にして UI から作り始めると、便利でも止められない構成になりやすくなります。
API接続ではOriginヘッダーより認証情報と操作単位を守る
2026年6月27日のSalesforce Blogでは、APIセキュリティでOriginヘッダーやRefererヘッダーの確認に頼ると、守れているように見えて実際の防御にならない場面があると説明されています。モバイルアプリや外部クライアントからAPIを呼ぶ場合、通信元の見た目ではなく、有効なセッション、トークン、権限、実行できる操作をどう制御するかが重要です。
Headless 360やMCP接続を検討するときも同じです。AIエージェントがSalesforceへ到達できる経路を増やすほど、「どの画面から来たか」よりも「どの認証情報で、どのデータを読み、どの操作を実行できるか」を細かく見る必要があります。
| 確認項目 | Origin確認だけでは足りない理由 | Headless運用で見るポイント |
|---|---|---|
| セッションとトークン | 通信元ヘッダーは偽装や再利用の前提を切り分けにくい | 短寿命トークン、スコープ、失効手順を決める |
| APIごとの操作権限 | 入口を通った後に過剰な読み書きができると被害が広がる | 読み取り、下書き、更新、外部送信を別権限にする |
| クライアント種別 | ブラウザ、モバイル、AIクライアント、CLIで同じ境界を使えない | 接続元ごとに許すユースケースと認証方式を分ける |
| 監査と復旧 | 入口だけ見ても、どの操作が実行されたか追えない | 参照、更新、承認、差し戻し、失効をログで追えるようにする |
つまり、Headless化したSalesforceを守る基本は、APIを閉じることではなく、APIで何を許すかを小さく分けることです。AIエージェントには広い管理者権限を渡さず、必要なデータだけを読み、更新は下書きに留め、人の承認を経て反映する構成にすると、接続面が増えても事故を小さくできます。
Agentforce Experience Layerは「会話の中で完結する操作」を増やす
今回の発表で見逃せないのが、Agentforce Experience Layerです。これは、AIエージェントが行う処理と、その処理をどの画面やチャネルに表示するかを分ける考え方です。
たとえばSlack上で承認カードを出す、音声チャネルで顧客対応の次アクションを返す、別のAIクライアントからSalesforce内のワークフローを呼び出す、といった使い方が想定されます。重要なのは、会話チャネルが増えても、裏側の顧客データ、承認ルール、権限は同じ基盤で管理することです。
この考え方は、営業担当がCRM画面へ戻らなくても、要約、確認、承認、更新候補のチェックを普段の業務導線で進められる可能性を広げます。一方で、どのチャネルからどの操作を許すかを決めないと、便利さと統制のバランスが崩れます。
Testing CenterやObservabilityは導入後の運用を左右する
AIエージェントは、従来の決定論的な業務システムと違い、同じ入力でも出力や判断が揺れることがあります。そのため、公開前のテストだけでなく、公開後にどう観測し、どう評価し、どう改善するかが重要になります。
Salesforceは発表の中で、Testing Center、Custom Scoring Evals、Agent Script、Observability、Session Tracing、A/B Testingといった運用統制の要素も打ち出しています。これは、AIエージェントを作るだけでなく、本番投入後に挙動を見直す前提の発表だと見た方が自然です。
営業AIやCRM更新を伴うエージェントでは、Agent Evalsで営業AIの評価項目を決める ことが特に重要になります。処理が成功したかだけでなく、正しい判断だったか、ポリシー違反がなかったか、差し戻しが多くないかまで見ないと、現場で使い続けられません。
向いている会社と、先に整えるべき会社
Salesforce Headless 360は、すでにSalesforceを深く使い、顧客データ、承認フロー、業務ルール、権限設計が整っている会社ほど価値が出やすい発表です。既存基盤を変えずに、AIエージェントや開発エージェントからその資産を呼び出せるからです。
一方で、Salesforceが現場で入力されていない、項目定義が部署ごとにずれている、更新責任が曖昧という状態なら、Headless化より先にCRM運用の整備が必要です。基盤の文脈が壊れていると、AIエージェントは壊れた文脈を速く処理するだけになります。
| 会社の状態 | Headless 360の見方 | 先にやること |
|---|---|---|
| Salesforceが営業・CSの共通基盤になっている | AIエージェント接続の価値が出やすい | 読み取りと更新の権限境界を決める |
| 承認、監査、例外処理が厳しい | 統制されたエージェント運用と相性がよい | Testing CenterやEvalsの評価軸を設計する |
| 入力率や項目定義が不安定 | AI接続の前に土台の整備が必要 | CRM定着、項目整理、更新責任を見直す |
| Google Workspace中心で軽く営業管理している | Salesforce前提が過剰になる場合もある | 顧客文脈の持ち方と運用人数で比較する |
AIエージェントを本番に載せる前提条件は、AIエージェント ガバナンス の観点で見ると整理しやすくなります。ツールの導入可否ではなく、権限、接続先、記録、承認を先に決めることが重要です。
参照元
本記事は、Salesforce Newsの2026年4月15日付記事「Introducing Salesforce Headless 360. No Browser Required.」、Salesforce Blogの2026年6月17日付記事「Securing the Agentic Enterprise: Why Trust is the Engine of Headless 360」、および2026年6月27日付記事「The API Security Myth That’s Putting Your Data at Risk」をもとに、CRM運用とAIエージェント設計の観点で要点を整理しています。
よくある質問
Salesforce Headless 360とは何ですか？
Salesforceのデータ、業務ロジック、開発・運用機能を、AIエージェントがAPI、MCP tool、CLI commandとして扱えるようにする発表です。画面をなくすというより、画面以外の接点からSalesforceを安全に呼び出せるようにする方向性です。
画面を使わないSalesforceとはどういう意味ですか？
人がブラウザで操作する代わりに、AIエージェントや開発環境が必要な機能を直接呼び出す場面が増えるという意味です。ただし、人の確認や承認が不要になるわけではありません。
Agentforce 360とはどう関係しますか？
Agentforce 360がAI CRM化の全体構想だとすれば、Headless 360はその基盤をAPI、MCP tool、CLI commandとしてAIエージェントや開発環境から呼び出す接続面です。
導入前に何を決めるべきですか？
参照できるデータ、下書きまで許す処理、承認が必要な更新、監査ログに残す項目を先に決めるべきです。ここを曖昧にしたまま接続だけ広げると、誤更新や説明不能な自動処理が起きやすくなります。
API接続でOrigin validationだけに頼ってよいですか？
頼るべきではありません。OriginやRefererは補助的な情報にはなりますが、APIの本質的な防御は認証情報、セッション、スコープ、操作権限、監査ログで設計します。AIエージェントやCLIからSalesforceを呼ぶ場合は、接続元の見た目より、何を読めて何を実行できるかを小さく分けることが重要です。
Headless 360でsecurityはどう担保されますか？
Salesforce Blogでは、OAuth 2.0、RBAC、FLS、sharing rules に加え、AI Trust Layer、Shield、Security Center、Privacy Center、Backup & Recover の組み合わせで担保すると整理されています。つまり、新しいUIごとに別の統制を作るより、既存統制を継承したまま広げる考え方です。
