この記事はバージョン Spring ’26 において執筆しています。
現在の動作と異なる場合がありますので、ご認識おきください。
これまで私たちは、AuraサイトやLWRサイトにおいて、Einstein Botsを駆使してチャットボットを構築してきました。「メニューを選んでください」「注文番号を入力してください」——苦労して設計したダイアログツリー(決定木)は、確かに顧客対応の自動化に貢献してきました。
しかし、Agentforce Service Agentの登場により、そのパラダイムは完全に変わろうとしています。
今回は、LWRサイトにおけるAgentforceの実装アーキテクチャが従来とどう異なるのか、そしてSpring ’26で予定されている最新機能を交えながら、その衝撃的な進化を解説します。
シナリオの終焉:If/Thenから「推論(Reasoning)」へ
最大の変更点は、「シナリオ(Dialog)」を作る必要がなくなるということです。
従来のEinstein Botsは、私たちが事前に定義した「決定木(If/Then)」の上でしか動けませんでした。想定外の質問が来れば、すぐに「すみません、よく理解できませんでした」と返すしかありませんでした。
一方、AgentforceはLLM(大規模言語モデル)を用いた推論エンジン(Reasoning Engine)で動きます。 「過去の注文状況を確認したい」と言われれば、エージェントは自律的に「注文オブジェクトを検索するツールが必要だ」と判断し、実行し、結果を自然言語で返します。
LWRサイトにおいて、Agentforceは単なる「Q&Aウィジェット」ではなく、サイト全体のデータと連携し、ユーザーの意図を汲み取って行動する「コンシェルジュ」へと進化します。
アーキテクチャの違い:MIAWが標準に
技術的な実装において、従来のBotと決定的に異なるのが通信基盤です。
- 従来 (Legacy): Chat (Live Agent) ベース、または古いEmbedded Service。
- Agentforce (Modern): MIAW (Messaging for In-App and Web) ベース。
LWRサイトでAgentforceを動かすには、「Embedded Messaging (組み込みメッセージング)」 コンポーネントを使用するのが標準です。
実装の仕組み
従来のようにサイトのヘッダーにJavaScriptのスニペットを貼り付けるのではありません。Salesforceプラットフォームの標準機能をフル活用します。
- エクスペリエンスビルダー: 「組み込みメッセージング」コンポーネントをドラッグ&ドロップで配置。
- オムニチャネルフロー: チャットのルーティングを制御。ここで「Agentforce Service Agent」へ会話を渡します。


これにより、セッションが切れても会話履歴が維持されたり、非同期でのやり取りが可能になったりと、UXが大幅に向上します。
Spring ’26 新機能:サイト体験を深化させる「文脈(Context)」の力
最新のリリースノート(Spring ’26)によると、LWRサイトでのエージェント体験はさらに「文脈」を理解するものになります。これらは従来のBotでは実装が困難だった機能です。
プロアクティブなトラブルシューティング (Interactive Troubleshooting)
ユーザーがサイト上の特定のページ(キャンペーンページなど)を開いた瞬間、Agentforceが能動的に声をかける機能です。
ドキュメントに基づく仕様: サービス担当者はキャンペーン計画中に「シナリオプロンプト」を定義します。顧客がサイトを開くと、Agentforceはそのプロンプトを使用して、対話型のトラブルシューティングセッションを開始します。
(Source: Guide Your Users Through Interactive Troubleshooting for Proactive Scenarios)
【推測される挙動】 従来の「プロアクティブチャット」は単に挨拶をするだけでしたが、Agentforceは「お客様、このキャンペーンの申し込みでエラーが出ていませんか?現在システムが混み合っており…」といった、状況に合わせた具体的な提案を自律的に生成して話しかけてくるようになると考えられます。
統合顧客プロファイル (Unified Customer Profile)
これは、サイト上の行動履歴や属性データをリアルタイムでAgentforceが参照する機能です。
ドキュメントに基づく仕様: リアルタイムの統合顧客プロファイルを表示し、コンテキストを意識したセルフサービスを提供します。属性、アクティビティ履歴、センチメントなどのインサイトを読み取り、新しいアクティビティデータを自動的に書き込むことができます。
(Source: Give Your Users Personalized Self-Service with a Unified Customer Profile)
【推測されるメリット】 「お名前とメールアドレスを入力してください」という不毛なやり取りが激減します。ログインしているLWRユーザーであれば、エージェントは既に「誰が」「どのページを見て」「過去にどんな買い物をしたか」を知った状態で会話を始めます。
実装ステップ:LWRサイトへの配置
では、実際にLWRサイトにAgentforceを配置する流れを見ていきましょう。 ※以下は標準的な設定フローに基づく構成案です。
ナレッジ検索(RAG)とCRM操作(フロー)を組み合わせた「注文サポートエージェント」を例に、Data Cloud構築からプロンプト設計、LWRサイトへの配置まで以前公開した 【完全版】Agentforce実装ガイドでステップ・バイ・ステップで徹底解説しています。
ステップ1: エージェントの作成 (Agent Builder)
[設定] > [Agentforce スタジオ] からエージェントを作成します。ここで重要なのは「トピック」と「アクション」の定義です。
ステップ2: オムニチャネルフローでのルーティング設定
MIAWチャネルからの着信をエージェントに渡すため、フロービルダーでオムニチャネルフローを作成します。 Route to Agent アクションを使用し、ルーティング先に作成した Agent を指定します。
ステップ3: エクスペリエンスビルダーでのコンポーネント配置
- エクスペリエンスビルダーを開きます。
- コンポーネントパネルから 「組み込みメッセージング」 を選択します。
- サイトの適切な場所(通常はフッターや共通テンプレート)に配置します。
- プロパティ設定で、先ほど作成したエージェントを選択します。
ステップ4: 権限セットの付与【重要】
ここが見落としがちなポイントです。従来のBotとは異なり、Agentforceを使用するユーザー(ゲストまたは認証済みユーザー)には、適切な権限セットが必要です。 リリースノートの例では、以下のような権限が必要とされています。
- Access Agentforce Default Agent
- Prompt Template User (プロンプトを使用する場合)
- 各機能ごとのExperience Cloudユーザー権限
これらを適切に付与しないと、ウィジェットが表示されてもエージェントが応答しない(またはエラーになる)場合があります。
グラウンディング (Grounding) の進化
最後に、エージェントの回答精度を高めるグラウンディング(根拠付け)についてです。
Spring ’26以降、「ケースフィード」さえもグラウンディングのソースとして使用可能になります。
ドキュメントに基づく仕様: [Service AI Grounding] 設定ページで [Include Case Feed] を選択することで、ケースフィードのデータをService Agentの回答根拠に追加できます。
(Source: Use Case Feed as the Latest Grounding Source)
これにより、エージェントはナレッジ記事だけでなく、「過去にオペレーターがどのような対応をして解決したか」という人間の対応履歴からも学習し、回答を生成できるようになります。これは、より人間らしく、的確な対応を実現するための大きな一歩です。
まとめ:System of RecordからSystem of Actionへ
LWRにおけるAgentforceの実装は、単なるチャットボットの置き換えではありません。 それは、データを記録・表示するだけのシステム(System of Record)から、ユーザーのために自律的に考え、行動するシステム(System of Action)への転換です。
特にSpring ’26で追加される「文脈理解」や「ケースフィード参照」は、Experience Cloudのセルフサービス率を劇的に向上させる可能性を秘めています。
まずはSandbox環境で、MIAWとAgentforceの基本接続から試してみてはいかがでしょうか?
参考URL
Salesforce Spring ’26 Release Notes




読者の声