「Salesforce の標準 UI が現場に合わない」「Lightning コンポーネントだと AI エージェント連携が組みづらい」——SFDC を基幹に据える中堅・大手企業から、こうした相談が増えています。そこに着地点を提示したのが、Salesforce が発表した「Salesforce Headless 360」。CRM・サービス・マーケティングの主要機能を API / CLI / MCP からフルアクセス可能にし、フロントエンドと業務ロジックの分離を「公式に」サポートする構成です。
本記事では、SFDC 基幹を抱える企業のリプレース受託案件で、Headless 360 と MCP をどう組み合わせて設計するかを整理します。
なぜ今「ヘッドレス Salesforce」なのか
過去にも SFDC を API 越しに使う構成（Heroku Connect / REST API 直叩き）はありました。Headless 360 が決定的に違うのは次の 3 点です。
| 観点 | 従来 | Headless 360 |
|---|---|---|
| API カバー範囲 | 一部機能のみ | 主要機能を網羅 |
| 認証統合 | OAuth を都度実装 | 公式 CLI/MCP で抽象化 |
| AI エージェント連携 | 自前で MCP 化が必要 | 公式 MCP が同梱 |
| 開発体験 | Apex / LWC 中心 | TS/JS のフロント自由 |
つまり、「業務ロジックは SFDC、フロントは自由」 という長年の理想が、無理筋ではなくなりました。これは特にコーポレートサイト・営業ポータル・パートナー向けポータルの受託案件に直結します。
既存 SaaS API を MCP サーバー化する設計パターン で示した「ユースケース集約型」を、Salesforce の MCP に重ね合わせるのが本記事のコアです。
アーキテクチャ全体像
弊社が想定する「Headless SFDC + 自社フロント + AI エージェント」の標準構成は、4 層で整理します。
- Salesforce Headless 360：基幹データ・ワークフロー・権限管理
- BFF（Backend for Frontend）：フロント最適化・キャッシュ・集約
- 自社フロント：Astro / Next.js / TanStack Start などの自由選択
- MCP レイヤ：エージェントが自然言語で SFDC を操作
「BFF を挟むかどうか」は受託案件で必ず判断ポイントになります。読み中心の社内ポータルなら BFF 必須、書き込み中心の業務 UI なら MCP に直接依存——というのが弊社の経験則です。
受託案件で頻出する 3 つの型
型 A：営業ポータルのヘッドレス再構築
「Lightning が重い・遅い」という現場不満に応える案件。SFDC のデータはそのまま、フロントだけを TanStack Start や Astro に置き換えます。
- 期間：3〜5 ヶ月
- 効果：ページ遷移速度を体感 3〜5 倍
- 注意：権限・モバイル対応・オフライン要件を初期に確定
TanStack Start で作るレスなコーポレートサイト で書いたフロント設計の発想は、ヘッドレス SFDC 案件にもそのまま適用できます。
型 B：パートナー / 顧客向けポータル
代理店・販売店・顧客に直接 SFDC 機能の一部を公開する案件。Headless 360 を通すことで、
- SFDC の権限境界をそのまま外部に拡張
- ブランディングと UX を自社で完全コントロール
- AI チャットを MCP 経由で組み込み「自然言語で見積取得」
といった実装が現実的になります。
型 C：SFDC × AI エージェント基幹刷新
最も野心的なパターン。営業・カスタマーサポートの一次対応を AI エージェントに置き換え、SFDC の状態を MCP 経由で操作します。
server.tool("update_opportunity_stage", async (args, ctx) => {
if (!ctx.userApproved) {
return {
kind: "approval_required",
summary: `商談 ${args.opp_id} を「${args.next_stage}」に進めます`,
approval_token: issueApprovalToken(args),
};
}
return await sfdc.opportunity.update(args.opp_id, {
StageName: args.next_stage,
NextStep: args.note,
});
});Anthropic Computer Use を業務に組み込むガイド で書いた HITL の発想で、商談ステージ変更や見積発行は必ず人間承認を挟みます。
段階的な進め方（4 フェーズ）
SFDC 基幹のリプレースは、ビッグバンで一気にやると必ず炎上します。弊社では 4 フェーズに分割して提案します。
| フェーズ | 期間 | 目的 |
|---|---|---|
| 1. ヒアリング & API 棚卸し | 2〜3 週間 | どの SObject / どのフローを Headless 化するか確定 |
| 2. MCP / BFF 設計 PoC | 4〜6 週間 | ユースケース 1〜2 本をエンドツーエンド試作 |
| 3. フロント本番開発 | 8〜12 週間 | 自社フロントの構築 + SFDC 同期 |
| 4. AI エージェント拡張 | 6〜10 週間 | 一次対応・レコメンド・要約を順次追加 |
フェーズ 1 で 「Headless 化する範囲」 をクライアントと握れるかが成否を分けます。範囲が曖昧なまま PoC に入ると、必ず「これも欲しい」が膨らみます。
落とし穴：ガバナーリミットと API 配分
SFDC には API コール数の日次上限（Governor Limits）があります。Headless 化で API 呼び出しが激増すると、上限に達して業務が止まる事故が起きます。設計初期で次の 3 点を確定させてください。
- キャッシュ戦略：マスタデータは BFF / Cloudflare KV にキャッシュ
- Composite API の活用：複数操作を 1 リクエストにまとめる
- API 配分の監視：ライセンス上限の 60% を超えたらアラート
受託案件の単価帯
| 案件の型 | 期間 | 単価帯 | 提供物 |
|---|---|---|---|
| 営業ポータル ヘッドレス再構築 | 4〜6 ヶ月 | 1,500〜3,500 万円 | フロント・BFF・移行 |
| パートナーポータル 新規構築 | 5〜8 ヶ月 | 2,000〜5,000 万円 | フロント・MCP・SSO |
| SFDC × AI エージェント刷新 | 6〜10 ヶ月 | 3,000〜8,000 万円 | フロント・MCP・運用 |
特に保険・不動産・製造業では「SFDC は残したまま現場 UX を一新」のニーズが強く、受託パートナーの獲得競争が始まっています。
まとめ — Salesforce が「裏方」になる時代
Headless 360 は、Salesforce 自身が「自分は裏方になる」と宣言した戦略的アップデートです。フロントの選択肢が広がり、AI エージェント連携が標準化されることで、SFDC を採用した企業ほど受託パートナーの戦略性が結果に直結するようになります。
弊社では、Salesforce Headless 360 を起点とした基幹リプレース、BFF 設計、MCP エージェント連携、運用監視までをワンストップで提供しています。「SFDC の現場不満をなんとかしたい」「ヘッドレス化を検討している」というご相談は、お問い合わせフォーム からお声がけください。
