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として扱う流れがさらに明確になりました。さらに2026年7月6日のSalesforce Blogでは、Amazon Agentcore GatewayとMCPを通じてSalesforce外の業務システムを呼び出す設計が示され、AI CRMは単一画面内の自動化ではなく、複数クラウドをまたぐ実行基盤として見る必要が出てきています。実運用では、複数エージェントの割り当て、共通プロンプト、オプトアウト、人への引き継ぎ、長い会話で起きる context rot を前提に設計する必要があります。
本記事のポイント
- Agentforce 360は、Salesforceの顧客データ、業務アプリ、Slack、AIエージェントを一体で扱うAI CRM基盤です。
- Headless 360は、Agentforce 360の文脈を画面外のAPI、MCP tool、CLI commandへ広げる動きとして見ると理解しやすくなります。
- 実運用では、自律リード選別や休眠顧客フォローに加え、MCP経由で外部システムを呼ぶ権限、監査、データ複製を避ける設計まで先に決める必要があります。
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はその本体をエージェントや開発環境から扱うための入口と整理できます。
Amazon Agentcore連携で見えるクロスクラウド設計
2026年7月6日に Salesforce Blog で公開された Agentforce と Amazon Agentcore の連携記事は、Agentforce 360を考えるうえで重要です。記事では、Salesforce内の顧客対応だけでは完結しない業務に対して、MCPで公開された外部システムの機能を Agentforce が呼び出す構成が説明されています。
実務で見るべきポイントは、Salesforceにすべてのデータを複製するのではなく、Agentforce が会話と顧客文脈を持ち、Amazon Agentcore Gateway 側が基幹システム、SaaS、データベース、カスタムサービスへの接続点を担う分担です。Salesforceは顧客接点、AWSや既存基盤は業務実行、MCPはその間のツール発見と呼び出しの標準、と整理すると判断しやすくなります。
| 設計論点 | Agentforce側 | Agentcore / 外部基盤側 |
|---|---|---|
| 顧客文脈 | ケース、商談、顧客接点、会話を扱う | 必要な業務データを返す |
| ツール呼び出し | MCP Clientから承認済みツールを呼ぶ | MCP toolやGatewayで接続先を公開する |
| 認証と統制 | AI Trust LayerやSalesforce側の権限を効かせる | OAuth2、Cognito、Gateway側の認証を組み合わせる |
| データ管理 | 必要な回答と証跡を顧客対応に使う | 正本データを複製せず、その場で参照する |
この構成は、Headless 360の「SalesforceをAPIやMCP toolとして扱う」発想と表裏の関係にあります。Agentforceから外部へ出る経路と、外部のエージェントからSalesforceへ戻る経路の両方を考えるほど、AI CRMの設計は「どの製品を使うか」より「どの業務システムを、どの権限で、どの証跡付きで呼ぶか」が中心になります。
AI CRMとして何が変わるのか
AI CRMの観点で見ると、Agentforce 360の本質は、顧客情報を保存するだけのCRMから、顧客文脈をもとにAIエージェントが次アクションへ進める基盤へ変えることにあります。
これは AI CRMとは で整理した流れと同じです。従来CRMは、人が入力し、人が探し、人が判断する前提でした。AI CRMでは、メール、会話、案件履歴、サポート履歴、資料、Slack上のやり取りまで含め、AIが文脈を整理し、人が承認や判断に集中できる設計へ移ります。
入力中心から、文脈中心へ変わる
案件ステージや活動ログを人が後から入力するだけでなく、営業やCSのやり取りを顧客文脈として拾い直す発想が強くなります。
画面中心から、業務導線中心へ変わる
Salesforce画面だけでなく、Slack、音声、外部AIクライアント、開発環境など、実際に人が作業している場所へAI支援を出しやすくなります。
要約中心から、承認付き実行へ変わる
AIが要約するだけでなく、次アクション候補、更新候補、承認依頼、ワークフロー実行まで進む余地が出ます。ただし、人の承認点を残す設計が不可欠です。
自律リード選別ユースケースで何が見えてきたか
2026年6月10日に Salesforce Blog で公開された Siemens 事例は、Agentforce 360を「何となく便利なAI」ではなく、営業パイプラインを前に進める実行基盤として見る材料になります。ここで扱われているのは、問い合わせ待ちの受け身なチャットではなく、AIエージェントが会話を主導しながら初期ヒアリングを進め、適切な担当や商談化条件へつなぐ自律リード選別です。
この事例で重要なのは、AIが単にリードへ点数を付けるのではなく、会話の順序、確認事項、引き継ぎ条件まで含めて営業導線を設計している点です。つまり Agentforce 360の価値は「Lead Scoringの置き換え」より、人が介入すべき地点まで会話を整えて渡す ことにあります。
| 論点 | 従来の受け身運用 | 自律リード選別で増える価値 |
|---|---|---|
| 会話開始 | 問い合わせ内容を待ってから返答する | 不足情報を順番に聞き、会話を前へ進める |
| 判定基準 | 担当者の経験やルール表に依存しやすい | 必要項目、除外条件、引き継ぎ条件を事前に固定できる |
| 引き継ぎ | 要約だけ渡して担当者が読み直す | 要点、温度感、次アクション候補をそろえて渡せる |
| 統制 | 属人的な判断が残りやすい | 承認境界と escalation 条件を先に決めやすい |
日本のBtoB営業で置き換えると、展示会後の一次フォロー、資料請求後の要件聞き取り、パートナー経由リードの初期整理のような領域が近いです。Agentforce 360を導入する意義は、AIが受注判断まで担うことではなく、営業が受け取る前の情報欠損と初動遅れを減らすことにあります。
そのため、導入判断では MQL判定AI や Lead Scoringのルールベース比較 と同じく、何を聞ければ営業へ渡してよいか、どこで人に切り替えるかを先に決める必要があります。Agentforce 360は、その判定をSalesforce上のデータ、Slack、承認フローと結びつけやすい点が差分です。
10エージェント運用の事例で見える設計条件
2026年7月6日に Salesforce Blog で公開された Batteries Plus 事例は、Agentforce 360を複数エージェントで運用するときの現実的な設計条件を示しています。同社は米国で700店以上を展開し、CRM上に残る休眠顧客や新規リードを、10体のAgentforceエージェントで分担する構成を採りました。
この事例をそのまま「大量送信の成功例」と読むより、実務では 誰に、どのエージェントが、どの文脈で接触し、どこで人に渡すか を先に固定した点を見るべきです。7体は休眠顧客、3体は新規リードを担当し、各レコードは必ず1つのエージェントへ割り当てられる設計でした。受け手から見ると、複数エージェントの複雑さではなく、一貫した担当者からの会話として見えるようにしています。
| 設計論点 | 事例での考え方 | 自社で確認すること |
|---|---|---|
| 対象の絞り込み | 全レコードではなく、接触価値のある顧客・リードへ絞る | 休眠顧客、未対応リード、除外対象の条件を定義する |
| エージェント割り当て | 休眠顧客と新規リードで担当を分け、重複接触を防ぐ | 1レコード1エージェントの原則と再割り当て条件を決める |
| 共通プロンプト | 複数エージェントが同じトーンと判断基準を参照する | 担当ごとの設定差分を増やしすぎず、共通テンプレートを正本にする |
| 人への引き継ぎ | 面談希望や電話希望は人が対応できるように分岐する | 日程調整、電話希望、例外返信、苦情を人へ渡す条件を固定する |
特に重要なのは、複数エージェント化が「AIを増やすこと」ではなく、送信上限、対象者の種類、メッセージの一貫性、人への引き継ぎを分ける設計だという点です。BtoB営業で同じ考え方を使うなら、展示会後フォロー、休眠顧客掘り起こし、資料請求後の初回確認を混ぜず、それぞれの対象、除外条件、承認点を別に設計する方が安定します。
この観点は、営業AIエージェントKPI ともつながります。成果を見るときは、送信数だけでなく、接触対象カバー率、重複接触率、返信から人へ渡った件数、商談化後の品質を分けて追う必要があります。
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」、2026年6月10日付記事「From Reactive to Proactive: How Agentforce is Redefining Autonomous Lead Qualification At Siemens」、2026年7月6日付記事「How Batteries Plus Built 10 Agents to Activate 100,000 Sales Prospects」、および2026年7月6日付記事「Your AI Agents, Any Cloud: Building the Agentic Enterprise with Agentforce and Amazon Agentcore」をもとに、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とAmazon Agentcoreの連携では何を見るべきですか？
見るべき点は、Agentforceが顧客会話とSalesforce文脈を持ち、Amazon Agentcore Gateway側が外部システムへのMCP接続を担う分担です。データをSalesforceへ複製する前に、どのシステムをライブ参照し、どの権限と監査で呼び出すかを決める必要があります。
Agentforce 360は既存Salesforceユーザーなら必ず導入すべきですか？
必ずではありません。既存Salesforceの入力率、項目定義、権限、承認、監査が整っている会社ほど価値が出やすく、運用が崩れている会社では先にCRM定着を直す方が効果的です。
Google Workspace中心の会社でもAgentforce 360を比較すべきですか？
大企業や複雑な承認がある場合は比較対象になります。ただし、日常業務がGmailやGoogleカレンダー中心で、軽く営業管理を始めたい会社では、Google Workspace一体型のAI CRMも同時に比較した方が判断しやすくなります。
Agentforceで長い会話が崩れる context rot はどう防げますか？
知識記事の分割、アクション出力の絞り込み、context variables による状態保持、guardrails、Data Graphs の5点を優先します。モデルを替える前に、どの文脈を残し、どのノイズを削るかを設計する方が効果的です。
Agentforce 360は自律リード選別にどう使えますか？
資料請求や問い合わせ直後の会話で、必要情報の聞き取り、除外条件の確認、担当振り分け、次アクション候補の整理までを一連で支援できます。ただし、商談化の最終判断や対外約束は人が承認する境界を残すべきです。
Agentforceで複数エージェントを動かすとき何を決めるべきですか？
対象者の絞り込み、1レコードを1エージェントへ割り当てる基準、共通プロンプト、送信上限、オプトアウト、人へ引き継ぐ条件を先に決めます。複数エージェント化は処理量を増やすだけでなく、重複接触やトーンのばらつきを防ぐ運用設計まで含めて考える必要があります。
