Agentforce 360とは？SalesforceがAI CRMへ進む理由とHeadless 360との関係
Agentforce 360とは何か、SalesforceがAI CRMへ進む理由、Headless 360との関係、導入前に見るべき条件を実務目線で整理します。
3行でいうと、Agentforce 360は、Salesforceの顧客データ、業務アプリ、Slack、AIエージェントを一つの基盤で動かすためのAI CRM構想です。2025年10月13日にSalesforceが一般提供を発表し、2026年4月15日のHeadless 360発表で、画面外からAIエージェントがAPI、MCP tool、CLI commandとして扱う流れがさらに明確になりました。したがって、Agentforce 360は単体機能ではなく、Salesforceを「人が入力するCRM」から「人とAIエージェントが一緒に動くCRM基盤」へ変える動きとして見るべきであり、実運用では長い会話で起きる context rot を前提に設計する必要があります。
本記事のポイント
- Agentforce 360は、Salesforceの顧客データ、業務アプリ、Slack、AIエージェントを一体で扱うAI CRM基盤です。
- Headless 360は、Agentforce 360の文脈を画面外のAPI、MCP tool、CLI commandへ広げる動きとして見ると理解しやすくなります。
- 実運用では、長い会話で文脈が崩れる context rot を前提に、知識記事の分割、アクション出力の絞り込み、context variables の設計を先に決める必要があります。
この記事で扱うテーマ
関連キーワード
- Agentforce 360とは
- Salesforce Agentforce 360
- Agentforce 360 AI CRM
- Agentforce 360 Headless 360 違い
- Salesforce AI CRM
- Salesforce Agentforce 導入
- AI CRM Salesforce
このページで答える質問
- Agentforce 360とは何ですか？
- Agentforce 360とHeadless 360は何が違いますか？
- Agentforce 360はAI CRM比較でどう位置づけるべきですか？
- Salesforceユーザーは導入前に何を確認すべきですか？
- Agentforceで長い会話が崩れる context rot はどう防ぐべきですか？
Agentforce 360とは何か
Agentforce 360とは、Salesforceが提唱するAIエージェント時代のCRM基盤です。Salesforceの発表では、人、AIエージェント、データを一つの信頼できるシステムでつなぐプラットフォームとして位置づけられています。
ここで重要なのは、Agentforce 360を「チャットボット機能」や「営業AI機能」として狭く見ないことです。実務では、Data 360、Customer 360 Apps、Agentforce、Slackを組み合わせ、顧客データ、業務ルール、会話接点、AIエージェントの実行を同じ基盤で扱う構想として捉える方が正確です。
| 構成要素 | 役割 | AI CRMとしての意味 |
|---|---|---|
| Data 360 | 構造化・非構造化データを顧客文脈として扱う | AIエージェントの根拠になるデータを整える |
| Customer 360 Apps | 営業、マーケ、サービスなどの業務アプリをつなぐ | CRM内の業務ルールと履歴をAIが参照しやすくする |
| Agentforce | AIエージェントを構築、実行、管理する | 要約だけでなく、次アクションや業務実行へ近づける |
| Slack | 人とAIエージェントが会話し、承認し、動く接点になる | CRM画面以外の業務導線へAI支援を出しやすくする |
Agentforce 360は、SalesforceにAIを足す話ではなく、SalesforceをAIエージェントが動けるCRM基盤へ広げる話です。
Agentforce 360とHeadless 360の関係
Agentforce 360と Salesforce Headless 360 は、別々の話に見えますが、実務ではかなり近い関係にあります。
Agentforce 360が「Salesforce上で人、AIエージェント、データ、業務アプリをどうつなぐか」という全体構想だとすれば、Headless 360は「その基盤をAIエージェントが画面外からどう呼び出すか」という接続面の発表です。Salesforceの2026年4月15日付発表では、Salesforceの機能をAPI、MCP tool、CLI commandとして扱えるようにする方向性が示されました。
| 観点 | Agentforce 360 | Headless 360 |
|---|---|---|
| 主な論点 | 人、AIエージェント、データ、アプリを同じ基盤で動かす | Salesforceの機能をAPI、MCP、CLIで呼び出せるようにする |
| 見るべき価値 | AI CRMとしての全体運用 | AIエージェントが業務基盤を安全に扱う接続性 |
| 導入時の注意点 | データ品質、業務ルール、承認境界が必要 | 読み取り、下書き、更新、監査の境界が必要 |
| 検索意図 | Agentforce 360とは、Salesforce AI CRMとは | Headless 360とは、Salesforce MCPとは |
つまり、Agentforce 360はAI CRM化の本体、Headless 360はその本体をエージェントや開発環境から扱うための入口と整理できます。
AI CRMとして何が変わるのか
AI CRMの観点で見ると、Agentforce 360の本質は、顧客情報を保存するだけのCRMから、顧客文脈をもとにAIエージェントが次アクションへ進める基盤へ変えることにあります。
これは AI CRMとは で整理した流れと同じです。従来CRMは、人が入力し、人が探し、人が判断する前提でした。AI CRMでは、メール、会話、案件履歴、サポート履歴、資料、Slack上のやり取りまで含め、AIが文脈を整理し、人が承認や判断に集中できる設計へ移ります。
入力中心から、文脈中心へ変わる
案件ステージや活動ログを人が後から入力するだけでなく、営業やCSのやり取りを顧客文脈として拾い直す発想が強くなります。
画面中心から、業務導線中心へ変わる
Salesforce画面だけでなく、Slack、音声、外部AIクライアント、開発環境など、実際に人が作業している場所へAI支援を出しやすくなります。
要約中心から、承認付き実行へ変わる
AIが要約するだけでなく、次アクション候補、更新候補、承認依頼、ワークフロー実行まで進む余地が出ます。ただし、人の承認点を残す設計が不可欠です。
Agentforceで起きやすい context rot とは何か
Agentforce 360を検討するときに見落としやすいのが、長い会話でAIエージェントの文脈理解が崩れる context rot です。短いデモではうまく見えても、本番では会話履歴、ナレッジ検索結果、アクション出力が同じコンテキスト枠を奪い合うため、途中から以前の会話内容や重要な顧客文脈が落ちます。
Salesforce Blog の2026年6月1日公開記事でも、context rot は production-grade なAIエージェントで最も起きやすい失敗要因の1つとして説明されています。顧客がすでに答えたことを再度聞く、会話が長くなるほど解決率が落ちる、想定外の escalation が増える、といった症状が出たら、モデル性能より先に設計を疑うべきです。
| 症状 | 現場で起きること | 先に疑うべき論点 |
|---|---|---|
| 長い会話で解決率が落ちる | 初回は正しく返せるのに、5往復を超えると回答精度が落ちる | ナレッジ記事が長すぎる、履歴が押し出されている |
| 同じ質問を聞き直す | 顧客が伝えた契約種別や案件IDを取り直す | context variables が無い、状態が会話履歴依存 |
| 不要な escalation が増える | API応答の取りこぼしで人間対応へ倒れる | guardrail 不足、アクション出力の検証不足 |
| 関係ない情報を引く | FAQ全体や多話題の記事を毎回取り込んでしまう | 知識記事の粒度が粗い、retrieval設計が雑 |
この論点は、SoAの実行制御 や AIエージェント運用Runbook と同じく、Agentforce 360を「導入したら自動で賢くなる基盤」と見ないための重要な判断軸です。
context rot を減らす5つの設計ポイント
Salesforceの整理をそのまま読むだけでは実装に落ちにくいため、Agentforce 360の導入判断としては次の5点に言い換えると使いやすくなります。
- 知識記事を単一論点に分割する
長いナレッジ記事をそのまま食わせると、retrieval が不要な塊まで持ち込みます。返金、解約、見積修正、請求のように論点単位で分け、顧客が実際に使う言葉を見出しに入れる方が安定します。 - アクション出力を絞る
案件、ケース、契約の全フィールドを返すのではなく、Agentforce が次の一手に必要な値だけ返すようにします。Transform や Apex で出力整形を入れる発想です。 - context variables で状態を持つ
顧客意図、account ID、case summary、last action result のような重要状態を会話履歴に頼らず明示的に保持します。意図変更が起きたら変数を上書きする設計にします。 - escalation guardrails を先に置く
API 応答の必須フィールドが欠けたらそのまま推論させず、Flow や Decision で止めます。誤ったエスカレーションや誤更新を減らす即効性が高い論点です。 - Data Graphs で返す範囲を制限する
Account や Case の関連データを丸ごと返さず、Agentforce に必要な関係と項目だけ見せます。複雑なデータモデルほど効きます。
要するに、Agentforce 360の価値は「何でも大量に読ませること」ではなく、必要な文脈だけを残すように設計できること にあります。Headless 360でAPIやMCP接点が増えるほど、この整理は重要になります。
向いている会社と、まだ早い会社
Agentforce 360は強力ですが、Salesforceを使っている全社がすぐ成果を出せるわけではありません。AI CRM比較では、既存基盤の定着度を先に見る必要があります。
| 会社の状態 | Agentforce 360の見方 | 先にやること |
|---|---|---|
| Salesforceが営業、マーケ、CSの共通基盤になっている | AIエージェント化の価値が出やすい | 最初のユースケースを1つに絞る |
| 承認、権限、監査が厳しい | 統制を保ったAI CRM化と相性がよい | 読み取り、下書き、更新、送信の境界を決める |
| 入力率や項目定義が崩れている | AIを足しても出力品質が不安定になりやすい | CRM運用の定着 を先に整える |
| Google Workspace中心で軽く営業管理している | Salesforce前提が過剰になる場合がある | AI CRM比較 でGoogle Workspace一体型も並べる |
すでにSalesforce資産が厚い会社は、Agentforce 360とHeadless 360を一体で見る価値があります。一方で、日常業務がGmail、Googleカレンダー、Drive、Meet中心なら、ファネルAiのようなGoogle Workspace一体型のAI CRMも比較対象に入れる方が現実的です。
長い会話が前提の窓口ほど、導入前に観測指標を決める
特にサポート、更新交渉、複数部門をまたぐ問い合わせ対応では、会話が長くなりやすく context rot の影響が出やすくなります。Agentforce 360のPoCでは、平均解決率だけでなく「5ターン超の解決率」「聞き直し率」「想定外 escalation 率」を別で追うと、本番移行後の崩れ方を見抜きやすくなります。
最初に試すなら、商談後の次アクション整理から始める
Agentforce 360を検討するとき、最初から全社の営業、CS、マーケをAIエージェント化しようとすると失敗しやすくなります。最初は、人が承認しやすく、失敗時の影響が限定され、効果を測りやすい工程から始めるべきです。
- 商談後要約
会議内容を案件、担当者、次アクションに分けて整理する。 - 次アクション候補
誰が、いつまでに、何をするかを下書きとして返す。 - CRM更新候補
案件ステージ、活動履歴、メモの更新案を作り、人が承認して反映する。 - 停滞案件の検知
一定期間動きがない案件を拾い、確認すべき理由を提示する。
この順番なら、AIが勝手に顧客へ連絡したり、商談ステージを確定したりする前に、人が確認できる余地を残せます。営業AIエージェント全体の比較は 営業AIエージェント比較 もあわせて見ると整理しやすくなります。
逆に、最初のユースケースから長文ナレッジ検索、複数API呼び出し、自動更新、自動エスカレーションを同時に載せると、context rot と権限事故が同時に起きやすくなります。最初は短いタスク、狭いデータ、明確な承認点に絞る方が、Agentforce 360の強みを見極めやすくなります。
参照元
本記事は、Salesforce Newsの2025年10月13日付記事「Welcome to the Agentic Enterprise: With Agentforce 360, Salesforce Elevates Human Potential in the Age of AI」、2026年4月15日付記事「Introducing Salesforce Headless 360. No Browser Required.」、および Salesforce Blog の2026年6月1日付記事「5 Ways to Minimize Context Rot in Enterprise Agentforce Agents」をもとに、AI CRMと営業運用の観点で整理しています。
よくある質問
Agentforce 360とは何ですか？
Salesforceの顧客データ、業務アプリ、Slack、AIエージェントを一体で扱うためのAI CRM基盤です。単なるチャット機能ではなく、人とAIエージェントが同じ顧客文脈を使って動くための構想として見る方が実務的です。
Agentforce 360とHeadless 360は何が違いますか？
Agentforce 360はAI CRMとしての全体構想、Headless 360はSalesforceの機能をAPI、MCP tool、CLI commandとしてAIエージェントが呼び出しやすくする接続面の発表です。
Agentforce 360は既存Salesforceユーザーなら必ず導入すべきですか？
必ずではありません。既存Salesforceの入力率、項目定義、権限、承認、監査が整っている会社ほど価値が出やすく、運用が崩れている会社では先にCRM定着を直す方が効果的です。
Google Workspace中心の会社でもAgentforce 360を比較すべきですか？
大企業や複雑な承認がある場合は比較対象になります。ただし、日常業務がGmailやGoogleカレンダー中心で、軽く営業管理を始めたい会社では、Google Workspace一体型のAI CRMも同時に比較した方が判断しやすくなります。
Agentforceで長い会話が崩れる context rot はどう防げますか？
知識記事の分割、アクション出力の絞り込み、context variables による状態保持、guardrails、Data Graphs の5点を優先します。モデルを替える前に、どの文脈を残し、どのノイズを削るかを設計する方が効果的です。
