AIエージェントの実装は、対話を作るだけでは終わりません。実際に業務を進めるには、データ、ワークフロー、権限、監査の4つが必要です。Salesforceが発表したHeadless 360は、この前提をUIの外に出して、API、MCP、CLIとして使える形にした点が重要です。

https://www.salesforce.com/news/stories/salesforce-headless-360-announcement/

この記事では、Headless 360が何を変えるのか、従来のSalesforce運用と何が違うのか、そしてAIエージェント実装でどこに効くのかを整理します。

  • UI中心の業務システムを、エージェントが直接扱える形に変える考え方
  • 60個超のMCPツールや30個超のcoding skillsが何に使えるか
  • 既存のSalesforce運用と比べて、どこがボトルネックを消すのか
  • 導入時に見ておくべき注意点

UIを前提にしない設計

Headless 360の核は、Salesforceの機能を「画面の向こう側」に閉じ込めないことです。従来は人がログインして操作する前提でしたが、今回の発表では、主要機能をAPI、MCP tool、CLI commandとして公開しています。これにより、エージェントはブラウザを開かずに、必要な処理を直接呼び出せます。

この変化は見た目の問題ではありません。営業、サポート、DevOpsのような業務は、画面を見て完結するものではなく、データ参照、承認、更新、通知の連続です。Headless 360は、その連続処理をエージェント向けの実行経路に変えています。

開発者に効く3つの要素

Salesforceの発表で目立つのは、MCPと開発支援の厚さです。60個超の新しいMCP toolsと30個超のpreconfigured coding skillsが用意され、Claude Code、Cursor、Codex、Windsurfのような既存の開発環境からSalesforceのデータやワークフローに触れられます。

これは、単なる連携拡張ではありません。エージェントが「外部SaaSを少し操作する」段階を超え、実運用の業務基盤に入るための経路です。たとえば、メタデータ更新、設定変更、デプロイ準備、簡単なリファクタリングのような作業を、会話の流れの中で処理できます。

さらに、Agentforce Vibes 2.0はSalesforce内での開発体験を強めます。マルチモデル対応、org awareness、ビジネス文脈を見た提案は、コード補助より広い領域を狙っています。要するに、エージェントがコードだけでなく、業務の事情まで含めて動く方向です。

画面ではなく体験を配る

Headless 360のもう1つの柱は、表示層を分離した点です。発表では、Slack、Voice、WhatsAppなど、複数の表面でリッチなやり取りを返すExperience Layerが示されています。ここで重要なのは、業務ロジックと見せ方を切り離していることです。

この設計なら、同じ処理をチャット、モバイル、社内ツール、将来の別UIに再利用できます。画面を作るたびにロジックを作り直す必要がなくなります。エージェント時代に必要なのは、単発のチャットボットではなく、どの接点でも同じ業務を流せる体験層です。

本番運用で差が出る

AIエージェントは作るより、安定して走らせるほうが難しいです。Salesforceはその点も意識しており、Testing Center、Custom Scoring Evals、Agent Script、Observability、Session Tracing、A/B Testingをまとめて出しています。

ここでのポイントは、正解かどうかを「実行したか」ではなく「正しい判断をしたか」で評価することです。これは通常のソフトウェアテストと違います。エージェントは確率的に振る舞うため、単純な成功・失敗判定では足りません。評価指標を業務ルールに合わせて作る必要があります。

また、導入後に何が起きたかを追える仕組みがあるのも大きいです。暴走したときに原因を追えなければ、エージェントは本番に載りません。Headless 360は、そこを運用レベルで押さえにいっています。

既存のSalesforceと何が違うのか

従来のSalesforceは、強いCRMとワークフロー基盤でした。ただし、人が画面を開いて使う前提が残っていました。Headless 360は、その前提を崩します。

違いを短く言うと、従来は「人がSalesforceを使う」でした。今回は「エージェントがSalesforceを使い、その上で人が関与する」です。ここが大きいです。データ、業務ルール、権限、Slackのような接点まで一体で動くため、個別ツールの寄せ集めよりも実装の重複が少なくなります。

一方で、向いているのはすでにSalesforce中心に業務がある組織です。業務データが散っている、権限設計が未整備、評価基準が曖昧という状態では、Headless 360を入れても効果は出にくいです。先に業務の定義を固める必要があります。

こんな場面で価値が出る

Headless 360が効くのは、サポート、営業支援、業務承認、DevOpsのように、複数システムをまたいで決定と更新が発生する領域です。特に、エージェントに「読む・判断する・更新する」を一気通貫で任せたい場合に向きます。

逆に、単発の生成タスクだけなら過剰です。文書要約や画像生成のような用途なら、別の軽いAIツールで足ります。Headless 360は、業務の実行基盤そのものをエージェント化したいときに意味があります。

まとめ

Salesforce Headless 360は、AIエージェントを画面操作から解放し、業務基盤に直接つなぐための発表です。MCP、CLI、API、評価、観測、権限をまとめてそろえた点に価値があります。

エージェント導入で本当に難しいのは、会話ではなく実運用です。Headless 360はそこに踏み込んでおり、Salesforceを使う企業にとっては、エージェント活用の現実解に近い発表です。