メインコンテンツへスキップ
見出し画像
Photo bymineral_z

【第571回】 Agentforce : 2026 年 9 月 新機能リリース ハイライト

    Data 360 と同様に、Agentforce もほぼ毎月のように新機能や改善が追加されています。そのため、最新情報を追い続けるだけでも、かなりの労力が必要になってきました。

    私自身も、「気が付いたら新機能が追加されていた」「どの機能が本当に重要なのか判断しづらい」と感じることが増えています。リリースノートには多くの情報が掲載されていますが、そのまま読むだけでは、変更点の全体像や実際のインパクトを把握するのは簡単ではありません。

    そこで今後は、Data 360 のまとめ記事と同様に、Agentforce の毎月の新機能を分かりやすく整理した解説記事 を継続的に公開していきます。

    単に新機能を列挙するのではなく、

    • 何が変わったのか

    • なぜ追加されたのか

    • 実際にどのような影響があるのか

    という視点で整理し、できるだけ実務に役立つ情報をお届けしたいと思います。


    過去の記事


    2026 年 9 月リリース ハイライト

    今回は、Agentforce Connections、Agentforce Builder、Enhanced Chat v2、Agentforce Voice、Agentforce Development など、幅広い領域で改善が行われています。

    個人的に特に注目しているのは、Custom Lightning Type を Agentforce Builder の Preview で簡単に確認できるようになったことと、Agent Memory が一般提供開始になったことです。

    Custom Lightning Type は、これまで Preview で確認するために Action を作り直す必要がある場合がありましたが、今回のアップデートで開発・確認がかなり楽になります。

    また、Agent Memory によって、Agent が過去の Conversation をまたいで User に関する情報を利用できるようになった点も、Agentforce の利用体験を大きく変えるアップデートだと感じています。

    それでは、1 つずつ確認していきましょう。


    Agentforce Connections

    ① Dynamic Messaging Components でエージェントの回答をカスタマイズ可能に

    Agentforce の Messaging Connection で、Messaging Component を利用したカスタム Response Format を作成できるようになりました。

    これにより、エージェントからの回答を単純なテキストだけではなく、ユーザーがそのまま操作できる UI として表示できます。

    利用できる主な Messaging Component には、以下があります。

    • Enhanced Link

    • Question with Static Options

    • Question with Dynamic Options

    • Time Selector

    • Form

    さらに、Agent Action の出力を利用して Response Format の内容を動的に生成することもできます。

    例えば、返品手続きを行うエージェントの場合、Agent Action で返品対象の商品や注文情報などを取得し、その結果を利用して、ユーザーごとに内容が異なる Form を表示するといった構成が可能です。

    これまでのようにエージェントが文章で「商品を選択してください」「返品理由を入力してください」と案内するだけではなく、選択肢や Form などを会話の中に直接表示し、ユーザーに操作してもらうことができます。

    利用方法

    1. Agentforce Builder で対象の Agent を開き、Messaging Connection を追加します。

    2. Explorer Panel から Messaging を選択します。

    3. Available Response Formats セクションの Add response format を選択し、New response format を選択します。

    4. New Response Format 画面の Component 項目から、利用する Messaging Component を選択します。

    Messaging Component 自体は Component Builder で作成・カスタマイズできます。

    画像

    また、Component の種類によっては Flow や Formula を利用して、Session ごとに異なる動的な Content を設定できます。

    この機能は、Enhanced Web Chat v1、Enhanced In-App Chat、WhatsApp、Facebook Messenger、LINE、Bring Your Own Channel など、Messaging Connection を利用するチャネルが対象です。ただし、利用できる Component の表示形式はチャネルによって異なりますので、実際に試しながら実装してください。

    Enhanced Chat v2 は別の Connection を利用するため、今回のカスタム Response Format の対象ではありません。 v2 では、Custom Lightning Type と LWC を利用して回答の UI をカスタマイズします。


    ② Connection Instructions でチャネルごとに Agent の動作をカスタマイズ可能に

    Agentforce の Connection Instructions を利用して、接続するチャネルごとに Agent の推論や応答方法をカスタマイズできるようになりました。

    対象となる Connection は以下の 3 種類です。

    • Messaging

    • Service Email

    • Marketing Email

    これにより、同じ Agent を複数のチャネルで利用する場合でも、Connection ごとに異なる Instructions を設定できます。

    例えば、Email ではメール本文に含まれる Disclaimer を無視するように指示したり、特定のメッセージでは指定した Response Format を利用するように指示したりできます。

    Connection Instructions は自然言語で記述できるほか、Adaptive Response Format や Variable などの Resource を参照することもできます。

    さらに、System Variable を利用することで、現在利用している Connection や Modality に応じて Agent の動作を変更することも可能です。

    例えば、Messaging Connection を利用しており、かつ Voice で会話している場合のみ回答を短くするには、以下のような Instructions を設定できます。

    | if @system_variables.current_connection == "Messaging" and @system_variables.current_modality == "voice"
        | Shorten the response length

    このように、Connection や Modality など実行時の状況に応じて Agent の応答方法を切り替えることができます。

    また、複数の Connection Instructions を設定した場合は、上から順番に Instructions が解決されます。

    利用方法

    1. Agentforce Builder で対象の Agent を開きます。

    2. Messaging、Service Email、または Marketing Email Connection を追加します。

    3. Explorer Panel から対象の Connection を選択します。

    4. Connection のページで Instructions を設定します。

    5. 必要に応じて Adaptive Response Format や Variable などを参照しながら、自然言語で Agent への指示を記述します。

    今回のアップデートにより、Agent 本体の共通ロジックを維持しながら、Messaging、Service Email、Marketing Email など、それぞれのチャネルや利用状況に適した振る舞いを Connection 側で定義できるようになりました。


    ③ Agent Action の出力形式を Connection ごとに指定可能に

    Agentforce Builder で、Agent Action の出力を Connection ごとに指定した Response Format で表示できるようになりました。

    新しく利用できる render Nested Inline Action を使用すると、特定の Agent Action の出力に対して、利用する Adaptive Response Format を明示的に指定できます。

    Adaptive Response Format を指定しない場合は、Conversation の状況に応じて Agentforce が利用する Response Format を判断します。

    今回のアップデートでは、例えば同じ Agent Action でも、

    • Messaging では Rich Link として表示

    • Enhanced Chat v2 では JSON として返却

    といったように、Connection に応じて出力形式を切り替えることができます。

    また、Agent Action の出力を JSON として返すことで、Connection 側で構造化されたデータをそのまま受け取ることもできます。

    さらに、show_and_return Nested Inline Action を利用すると、Agent Action の実行後に Response を送信し、その時点で Reasoning を終了できます。

    例えば、以下の Agent Script では、Get Menu For Restaurant Action の出力形式を Connection ごとに変更しています。

    Get_Menu_For_Restaurant: @actions.Get_Menu_For_Restaurant
    	when @connection.messaging
    		render: @response_formats.messaging_rich_link
    	when @connection.customer_web_client
    		render: @response_formats.json
    			show_and_return: True

    この Script では、まず Get_Menu_For_Restaurant という Agent Action を定義しています。

    Get_Menu_For_Restaurant: @actions.Get_Menu_For_Restaurant

    Messaging Connection から利用された場合は、以下の部分が適用されます。

    when @connection.messaging
    	render: @response_formats.messaging_rich_link

    この場合、Agent Action の出力は Messaging Rich Link Response Format を利用して表示されます。

    一方、Enhanced Chat v2 から利用された場合は、以下の部分が適用されます。

    when @connection.customer_web_client
    	render: @response_formats.json
    		show_and_return: True

    この場合は、Agent Action の出力を JSON として返します。

    さらに show_and_return: True が指定されているため、Response を送信した後、その時点で Agent の Reasoning を終了します。

    つまり、同じ Agent Action に対して、

    when @connection.messaging

    や

    when @connection.customer_web_client

    のように Connection を判定し、その Connection に適した Response Format を render で指定できる仕組みです。

    利用方法

    1. Agentforce Builder で、少なくとも 1 つ Connection が設定されている Agent を開きます。

    2. Explorer Panel から対象の Subagent を選択します。

    3. Script View に切り替えます。

    4. Actions セクションで、対象の Agent Action に render Nested Inline Action を追加します。

    5. Connection ごとに利用する Adaptive Response Format を指定します。

    6. 必要に応じて show_and_return を設定します。

    Script View で設定した render は、Canvas View に切り替えると Actions Available For Reasoning セクションでも確認できます。

    今回のアップデートにより、Agentforce に出力形式の判断を任せるだけではなく、特定の Agent Action の結果を、Connection ごとに決められた UI やデータ形式で返すことができるようになりました。

    特に、Messaging ではユーザーが操作しやすい Rich UI を利用し、Enhanced Chat v2 では JSON の構造化データを返すといった、Connection の用途に合わせた出力制御がしやすくなります。


    Agentforce Agents

    ① Agent で File Upload に対応

    Agentforce の Service Agent と Employee Agent で、Production Conversation と Preview Conversation の両方から File Upload を利用できるようになりました。

    これにより、ユーザーは Chat Window から、

    • Screenshot

    • Receipt

    • PDF

    などの File を添付して Agent に渡すことができます。

    Agent は、アップロードされた Image や PDF の内容を解釈して質問に回答できるほか、File を Salesforce Record に追加したり、Conversation の Context として利用したりできます。

    例えば、ユーザーが Receipt や Screenshot をアップロードし、その内容について Agent に質問すると、Agent が File の内容を確認したうえで回答するといった利用が可能になります。

    利用方法

    File Upload を利用する場合は、まず File Processing 用の Subagent を作成し、アップロードされた File をどのように処理し、Conversation の中でどのように利用するかを Instructions に記述します。

    また、必要に応じて Script View から Agent の config Block に file_upload Parameter を追加し、File Upload の Mode を指定できます。

    例えば、以下では managed Mode を設定しています。

    config:
        developer_name: "Support_Agent"
        agent_label: "Customer Support Agent"
        file_upload:
            mode: "managed"

    file_upload の Mode によって、アップロードされた File の処理方法を制御できます。

    Default の動作では、Agent が File を自動的に処理し、Conversation History に保存します。

    一方、managed Mode を利用した場合は、アップロードされた File が uploaded_files Variable に保存されます。

    そのため、uploaded_files を利用して、

    • どの File を処理するか

    • どのように File を利用するか

    • Conversation のどのタイミングで File を参照するか

    といった処理を Agent 側で制御できます。

    また、Mode を利用して File Upload 自体を無効化することもできます。


    ② Agent の Version Commit が不要に

    Agentforce Builder で Agent を編集・Activate する際の Version 管理が簡素化されました。

    これまでは、Agent の変更後に Version を手動で Commit してから Activate する必要がありましたが、今回のアップデートでは、この手動 Commit が不要になり、Draft のまま Activate すると、そのタイミングで Agentforce Builder が自動的に Version を Commit します。

    これに伴い、これまで表示されていた Commit Version ボタンも削除されました。

    この変更は 2026 年 9 月に発表されましたが 10 月中旬に中止されました。


    Einstein Bots

    ① Einstein Bot を Agentforce Service Agent にアップグレードする機能が一般提供開始

    Upgrade Agent Tool を利用すると、既存の Einstein Bot をもとに、新しい Agentforce Service Agent を作成できます。このとき、既存の Einstein Bot 自体が置き換えられるわけではありません。

    元の Einstein Bot はそのまま残り、別の Agentforce Service Agent が作成されるため、新しく作成された Agent の内容を確認したり、追加設定を行ったりしたうえで移行できます。

    これにより、既存の Einstein Bot をすぐに停止することなく、Agentforce Service Agent への移行を段階的に進めやすくなりました。


    Enhanced Chat v2

    ① 終了した Conversation を再開可能に

    Enhanced Chat v2 で、Messaging Session が Timeout または終了した後でも、Customer が Chat Window から Continue Conversation を選択して Conversation を再開できるようになりました。

    これまでは Messaging Session が終了すると、その Conversation をそのまま続けることができませんでしたが、今回のアップデートにより、Customer は新しい Conversation を最初から開始することなく、終了した Conversation を再開できます。

    これにより、例えば途中で Session が Timeout した場合でも、Customer は Continue Conversation をクリックするだけで、そのまま Conversation を続けることができます。

    利用方法

    Continue Conversation の表示 Label はカスタマイズできます。

    1. Setup から Embedded Service Deployment Settings を開きます。

    2. Set Custom Labels を選択します。

    3. Chat Group で Chat in Progress を選択します。

    4. Label Group で Input Footer を選択します。

    5. Label Type で Standard を選択します。

    6. Continue Conversation Row に任意の Label を設定します。

    今回のアップデートにより、Session Timeout などで Conversation が終了した場合でも、Customer が簡単に Conversation を再開できるようになり、Enhanced Chat v2 の Conversation Experience が改善されました。


    ② Conversation View を改善

    Enhanced Chat v2 で、Conversation をより追いやすくするための UI 改善が行われました。

    Customer が Message を送信した際、これまでは Agent の Response を読み込んでいる間に、送信した Message が画面外へ Scroll してしまう場合がありました。

    今回のアップデートにより、送信した Message が Response の読み込み中も画面内に表示されたままになります。

    これにより、Customer は自分が送信した Message と Agent の Response を同じ流れの中で確認しやすくなります。

    また、Avatar の表示位置も変更され、Send Message Text Field の上部に表示されるようになりました。

    今回の変更は大きな機能追加ではありませんが、Enhanced Chat v2 で Conversation の流れを把握しやすくし、より自然に Message のやり取りを確認できるようにする UI 改善です。


    Agentforce Builder

    ① Agent Version を比較・マージ可能に

    Agentforce Builder で、2 つの Agent Version を比較し、一方の Version の変更内容をもう一方へ反映できるようになりました。

    これまでも Agent Version を作成して変更を管理することはできましたが、今回のアップデートにより、Version 間の差分を Canvas View と Script View の両方で確認できるようになりました。

    比較すると、2 つの Version の違いが Highlight されるため、どこが変更されているのかを確認しやすくなります。

    さらに、比較するだけではなく、選択した Version に含まれる変更を、現在の Version に Merge することもできます。

    変更内容は、

    • 1 件ずつ Accept または Decline

    • すべての変更をまとめて Accept または Decline

    できます。

    これにより、以前の Version で行った改善内容の一部だけを現在の Draft Version に取り込むといった操作が可能になります。

    利用方法

    1. Agentforce Builder で対象の Agent を開きます。

    2. Header の Menu から Compare versions を選択します。

    3. Compare with から、現在の Version と比較する Version を選択します。

    4. Canvas View または Script View で Highlight された差分を確認します。

    5. 変更を現在の Version に反映する場合は、現在の Version が Draft であることを確認します。

    6. 必要な変更を個別、またはまとめて Accept します。不要な変更は Decline できます。


    ② Custom Lightning Type を Preview で簡単に確認可能に

    ↓ ↓ ↓ 個人的にはこれがもっとも嬉しいです。作り直しが面倒でした ↓ ↓ ↓  

    Agentforce Builder で、Agent 内に作成またはカスタマイズした Agent Action の Custom Lightning Type(CLT) を、Preview でそのまま確認できるようになりました。

    Custom Lightning Type は、Agent Action の Input や Output の UI をカスタマイズし、よりブランドに合わせた表示や、ユーザーが操作しやすい UI を作成するために利用できます。

    これまでは、Agent 内で直接作成・変更した Action に Custom Lightning Type を設定しても、Agentforce Builder の Preview では表示されない場合がありました。

    そのため、Preview で確認するためには Action を Asset Library 側で作り直す必要がありました。

    また、Agent を Commit しなければ Custom Lightning Type が Render されないという制約もありました。

    つまり、Custom Lightning Type の表示確認だけのために Asset Library に Action を作り直したり、Agent を Commit したりする必要がなくなります。

    この機能は、Winter ’27 にアップグレードされた Salesforce Org を対象に、2026 年 9 月 21 日の週から Rolling Basis で提供されています。


    Agentforce Voice

    ① Dynamic Routing が日本の電話番号に対応

    Agentforce Voice の Dynamic Routing で、日本のローカル電話番号を利用できるようになりました。

    Dynamic Routing は、既存の Telephony System で受けた通話を Agentforce Voice の Voice Agent へ転送するための仕組みです。

    今回のアップデートにより、日本でも Salesforce から Dynamic Routing 用のローカル電話番号を取得し、その番号を利用して Agentforce Voice へ通話をルーティングできるようになりました。

    利用する場合は、reserveRoutableNumber API を呼び出して Dynamic Routing 用の電話番号を取得し、既存の Telephony System からその番号へ通話を転送します。

    つまり、今回の変更は Agentforce Voice 自体が日本で初めて利用できるようになったというものではなく、既存の電話環境と Agentforce Voice を接続する Dynamic Routing で、日本のローカル電話番号を利用できるようになったというアップデートです。

    これにより、日本国内の既存の電話番号や Telephony System を利用している企業でも、通話を Agentforce Voice へ転送する構成を取りやすくなりました。

    利用方法

    1. reserveRoutableNumber API を利用して、Dynamic Routing 用の日本のローカル電話番号を取得します。

    2. 既存の Telephony System で受けた通話を、そのローカル電話番号へ転送します。

    3. 転送された通話を Agentforce Voice の Voice Agent で処理します。

    8 月には Dynamic Routing で利用可能なローカル電話番号としてアイルランド、イスラエル、メキシコへの拡大がありましたが、それに日本も続く形となりました。


    ② Custom SIP Header / SIP REFER に対応

    Agentforce Voice で、Inbound Call から Custom SIP X-header を取得し、Agentforce Voice へ Context として渡せるようになりました。

    例えば、Telephony System や IVR から以下のような情報を SIP Header として渡すことができます。

    • Customer Intent

    • Language Preference

    • Case History

    これにより、ユーザーが Agentforce Voice へ接続した時点で、それまでの電話システム側で取得した情報を引き継いだ状態で会話を開始できます。

    これまでも Agentforce Voice では SIP Header を利用した Context の受け渡しが可能でしたが、対応していたのは UUI SIP Header のみでした。

    今回のアップデートでは、名前を付けた Custom SIP X-header を利用できるようになり、より柔軟に情報を Salesforce Flow へ渡せるようになりました。

    また、受信した Header をそのまま利用するだけではなく、Salesforce 側で Header の内容を変更し、Response として Telephony System 側へ返すこともできます。

    さらに、通話の切断や転送方法として、新たに SIP REFER が利用可能になりました。

    これまでは Agentforce Voice から通話を切断する場合、SIP BYE のみがサポートされていました。

    SIP REFER に対応したことで、Agentforce Voice から Telephony Partner 側へ通話を引き渡すなど、より柔軟な Call Transfer Scenario を構成できるようになりました。

    利用方法

    1. Agentforce Voice Setup で Include Custom SIP Headers and REFER Support を有効化します。

    2. Agent の Escalation Flow を更新します。

    3. 必要に応じて Fallback Autolaunched Flow を追加します。

    4. Agent で利用している Inbound Omni-Channel Flow を編集し、Custom SIP Header や SIP REFER を利用するための処理を設定します。


    ③ Post-Call Transcript に会話履歴全体を保持

    Agentforce Voice で、Voice Agent から Service Rep へ通話を転送した場合でも、通話終了後の Transcript に Agent と Customer の会話履歴を残せるようになりました。

    Service Console の Enhance Conversation Component では、通話中に以下の両方の Transcript を確認できます。

    • Agent と Customer の会話

    • Service Rep と Customer の会話

    これまでは、通話中は両方の Transcript を確認できましたが、通話終了後になると、Service Rep と Customer の Voice Call Record から Agent と Customer の Transcript が表示されなくなるという違いがありました。

    今回のアップデートにより、通話終了後も Service Rep と Customer の Voice Call Record から、Agent と Customer の会話を含む一連の Conversation History を確認できるようになりました。

    例えば、最初に Voice Agent が Customer の問い合わせ内容を確認し、その後 Service Rep へ Escalation した場合でも、Service Rep は通話後に Agent が Customer とどのような会話をしていたのかを含めて確認できます。

    利用方法

    この機能を利用するには、Service Rep へ通話を転送する前に Voice Call Record を作成し、Connect Related Voice Calls を有効化します。

    これにより、

    • Service Rep と Customer の Voice Call Record(VC1)

    • Agent と Customer の Voice Call Record(VC2)

    が関連付けられ、通話終了後の VC1 から両方の Transcript を確認できるようになります。


    ④ Toolkit API から録音の Pause / Resume を制御

    Agentforce Voice で、Salesforce Voice Toolkit API を利用して通話録音を一時停止・再開する際に、Control Call Recording 権限が不要になりました。

    これまでは、Toolkit API から通話録音を一時停止・再開する場合でも、操作を行う User に Control Call Recording 権限が必要でした。

    今回のアップデートにより、Developer や Admin は、この権限を持っていなくても Toolkit API から、

    • 通話録音の Pause

    • 通話録音の Resume

    を実行できるようになりました。

    例えば、Customer が クレジットカード情報などの機密情報を伝える場面だけ録音を一時停止 し、その後自動的に録音を再開するといった制御を、Toolkit API を利用して実装しやすくなります。

    ただし、Salesforce の UI 上にある Pause / Resume の Control を利用する場合は、引き続き Control Call Recording 権限が必要です。

    つまり、今回変更されたのは Toolkit API から録音を制御する場合の権限要件であり、UI から操作する場合の権限要件は変更されていません。

    利用方法

    • Toolkit API から録音の一時停止・再開を行うには、まず利用している Telephony System 側で Call Recording を有効化します。

    • そのうえで、Salesforce Voice Toolkit API の Telephony Action を利用して、Conversation の途中で録音の Pause / Resume を制御します。


    ⑤ 取得可能な電話番号数の上限を適用

    Agentforce Voice で、Salesforce Voice(Native Telephony)から取得できる Phone Number 数の上限が実際に適用されるようになりました。

    これまでも取得可能な Phone Number 数には上限が定められていましたが、その上限は実際には Enforcement されていませんでした。

    今回のアップデートにより、Salesforce Voice(Native Telephony)を利用して Phone Number を取得する場合、設定されている上限を超えて追加取得することができなくなります。

    上限は利用する環境によって異なります。

    • Production Org:Agentforce Voice License によって上限が決定

    • Sandbox / Trial Org:License に関係なく最大 10 Phone Numbers

    この変更は、Telephony Model として Salesforce Voice(Native Telephony) を利用し、Communication Protocol に PSTN を利用している Agentforce Voice Customer が対象です。

    このアップデートは新しい機能を追加するものではなく、Agentforce Voice で取得できる Phone Number 数を License や環境ごとの上限に従って制御するための変更です。


    Agentforce Development

    ① Agent の組織間移行を簡素化

    Winter ’27 では、新しい Metadata Type である

    • AiAgentDefinition

    • AiAgentDefinitionVersion

    が追加され、Agentforce Agent を Sandbox から Production など別の Org へ移行する作業が簡素化されました。

    これまで Agent を別の Org へ Deploy する場合は、少なくとも複数の Metadata Type を扱う必要がありました。

    さらに、Agent Action で利用している、

    • Apex Class

    • Flow

    • Prompt Template

    などの Dependency(その Agent が動くために依存している関連コンポーネント)も個別に追加し、正しい Agent Version と合わせて管理する必要がありました。

    今回追加された AiAgentDefinition と AiAgentDefinitionVersion を利用すると、Salesforce CLI から Agent を取得する際に、Agent とその Dependency をまとめて Retrieve できるようになります。

    例えば、Agent と Dependency を取得する場合は、以下の Salesforce CLI Command を利用します。

    sf project retrieve start --metadata AiAgentDefinitionVersion --root-type-with-dependencies AiAgentDefinitionVersion

    --root-type-with-dependencies を利用することで、AiAgentDefinitionVersion を Root として、それに関連する Dependency もまとめて取得できます。

    利用方法

    まず Salesforce CLI を最新 Version に Update し、Package Manifest で以下の新しい Metadata Type を利用するように変更します。

    • AiAgentDefinition

    • AiAgentDefinitionVersion

    そのうえで Salesforce CLI から Agent を Retrieve / Deploy します。

    ただし、この新しい Metadata Type を利用して Agent を Org 間で移行するには、移行元と移行先の両方の Org が API Version 68.0 である必要があります。

    例えば、Sandbox が Winter ’27 に Upgrade 済みでも、Production Org がまだ Summer ’26 の場合は、新しい Metadata Type を利用できません。

    その期間は、これまでの以下の Metadata Type を引き続き利用します。

    • AiAuthoringBundle

    • Bot

    • BotVersion

    従来の Metadata Type を継続して利用する場合は、Package Manifest で API Version 67.0 を指定します。

    また、AiAgentDefinition と AiAgentDefinitionVersion は、Second-Generation Managed Packaging(Managed 2GP)のみをサポートしています。

    Sandbox で開発・Test した Agent を Production へ移行するような DevOps の場面では、特に大きな改善です。


    ② Agent Memory が 一般提供開始

    Agentforce の Agent Memory が 一般提供開始になりました。

    Agent Memory を利用すると、Agent が User との過去の Conversation から関連する情報を記憶し、その内容を後の Conversation でも利用できるようになります。

    これまでは、新しい Conversation を開始するたびに、User が同じ情報をもう一度 Agent に伝える必要がありました。

    今回の新機能により、Agent は過去の Conversation から User に関係する情報を参照できるようになります。

    例えば、以前の Conversation で User が伝えた情報を、次回の Conversation でも利用できます。

    また、User の名前などの Profile Detail についても、最初の Message から参照して Response に利用できます。

    そのため、User が毎回同じ情報を繰り返し入力しなくても、過去の Context を踏まえた Conversation を行いやすくなります。

    この機能は、Winter ’27 にアップグレードされた組織を対象に、2026 年 9 月 21 日の週から Rolling Basis で提供されています。


    ③ Enhanced Chat Agent の構築・デプロイ手順を公開

    Agentforce Developer Guide に、Enhanced Chat v2 で利用する Chat Agent を構築し、Test、Activate、Deploy するまでの一連の手順を解説したドキュメントが追加されました。

    https://developer.salesforce.com/docs/ai/agentforce/guide/headless-examples-enhanced-chat-agent.html

    このドキュメントでは、同じ Chat Agent の構築を以下の 3 つの方法で実施する手順を確認できます。

    • Headless:AI Coding Assistant を利用

    • Canvas:Salesforce UI を利用

    • Agent Script:Code を利用

    つまり、Salesforce UI から Agent を作成する方法だけではなく、AI Coding Assistant を利用した Headless Development や Agent Script を利用した Code ベースの開発方法も、同じ Example を利用して比較しながら確認できます。

    手順には、Agent の Build だけではなく、

    • Test

    • Activate

    • Enhanced Chat v2 Channel への Deploy

    まで含まれています。


    ④ Agentforce Data Library を利用した Grounding の実装手順を公開

    Agentforce Developer Guide に、Agentforce Data Library を利用して Agent を Grounding し、Test、Activate するまでの手順を解説したドキュメントが追加されました。

    https://developer.salesforce.com/docs/ai/agentforce/guide/headless-examples-agent-adl.html

    この Example では、以下の 2 つの方法で Agentforce Data Library を利用した Agent の開発方法を確認できます。

    • Headless:AI Coding Assistant を利用

    • Canvas:Salesforce UI を利用

    Agent を作成するだけではなく、Agentforce Data Library を Grounding Source として利用し、その後に Agent を Test、Activate するまでの一連の流れが紹介されています。


    ⑤ 本番データを分析して Agent を最適化する開発手順を公開

    Agentforce Developer Guide に、Production Data を利用して Agent の Response を分析し、Agent を改善するための Headless Development の Example が追加されました。

    https://developer.salesforce.com/docs/ai/agentforce/guide/headless-examples-agent-optimize.html

    この Example では、Production 環境で実際に発生した Agent の Response を分析し、改善が必要な箇所を特定する一連の流れを確認できます。

    AI Coding Assistant を利用して Production Data を分析すると、

    • 問題のある Agent Response の特定

    • Root Cause の分析

    • 再現可能な Test Case の作成

    • 修正案の提案

    といった処理を行います。

    その後、提案された修正をそのまま Production に反映するのではなく、Sandbox などの Testing Environment で Full Test Suite を実行し、修正によって他の動作へ影響がないか確認します。


    Prompt Builder / Field Generation

    ① Field Generation の Refinement でも選択した Model を利用

    Field Generation で、Follow-up Response や Refinement を行う際にも、Prompt Template で選択した Model が利用されるようになりました。

    これまでは、Field Generation Prompt Template に特定の Model を設定していても、Field Generation Panel から追加の指示を行った場合、その Follow-up Response には Salesforce の Default LLM が利用されていました。

    そのため、最初の Field Generation と、その後の Refinement で異なる Model が利用される可能性がありました。

    今回のアップデートにより、Field Generation Panel で Follow-up や Refinement を行った場合でも、Field Generation Prompt Template に設定されている Model がそのまま利用されます。

    例えば、Prompt Template で特定の Model を選択して Field Generation を実行した後に、

    • 回答を短くする

    • 表現を変更する

    • 内容を調整する

    といった追加の Refinement を行った場合でも、最初に設定した Model を利用して Response が生成されます。

    これにより、Field Generation の最初の生成から Refinement まで、同じ Model を利用した一貫した生成処理を行えるようになりました。


    ② Field Generation の Refinement を業務用途に限定可能に

    Field Generation で、Follow-up や Refinement の内容を Field Generation に関連する業務用途に限定できるようになりました。

    これまで Field Generation Panel では、最初に Field Generation を実行した後、User が追加の指示を入力して Response を調整できました。

    一方で、その Follow-up Request が本来の Field Generation や業務目的に関連しているかどうかは Validation されていなかったため、User が Field Generation とは関係のない質問や依頼を行うことも可能でした。

    今回のアップデートでは、新しく追加された Validate Field Generation Refinements を有効化することで、Follow-up や Refinement を Field Generation に関連する内容へ限定できます。

    これにより、Field Generation Panel が本来の目的とは関係のない生成 AI の利用に使われることを防ぎ、Einstein Credits を業務に関連する Field Generation に集中して利用しやすくなります。

    また、この Validation を利用する場合でも、Refinement の動作を Business Requirement に合わせてカスタマイズできます。

    専用の Prompt Template を利用することで、

    • Refinement に利用する Model

    • Response Parameter

    • Refinement 時の動作

    などを調整できます。

    利用方法

    1. Setup の Quick Find から Einstein Setup を開きます。

    2. 組織で Einstein Setup が有効になっていることを確認します。

    3. Prompt Builder Settings の Validate Field Generation Refinements を有効化します。

    Refinement の動作をカスタマイズする場合は、Setup の Quick Find から Prompt Builder を開き、Validate Field Generation Refinements 用の Prompt Template を利用します。

    既存の Template をそのまま利用することもできますが、必要に応じて新しい Version を保存し、Model や Response Parameter などを変更できます。


    Agentforce Platform Settings

    ① Agentforce Platform がデフォルトで有効化

    Winter ’27 では、Agentforce を利用できる SKU、License、Edition を持つ Org で、Agentforce Platform がデフォルトで有効化されるようになりました。

    新しく作成される Winter ’27 Org では、Org 作成時から Agentforce Platform が有効になります。

    また、既存 Org についても、2026 年 9 月第 1 週から Rolling Basis で順次自動的に有効化されます。

    これに伴い、Setup の Agentforce Agents Page にある Agentforce Setting は Winter ’27 の後半に削除される予定です。

    これまで必要だった Agentforce Platform 自体を有効化する手順が不要になるため、Agent の Build、Test、Deploy を開始するまでの Setup が 1 Step 少なくなります。

    利用方法

    • Org で Einstein Generative AI が有効になっている場合、Admin はすぐに Agentforce Builder を利用できます。

    • Admin 以外の User に Agentforce を管理させる場合は、Manage AI Agents Permission を付与します。

    また、Agentforce Platform がデフォルトで有効になる場合でも、以下の Access Control は引き続き利用できます。

    • Agentforce を利用するには Einstein Generative AI が有効である必要があります。

    • Agentforce Platform を無効化する場合は、Setup の Einstein Setup Page から Einstein Setting を無効化します。

    • Agentforce Platform が有効な場合、Admin は Agentforce Studio、Agentforce Builder、Analytics、Observability を利用できます。

    • Admin 以外の User の Access は User Permission で管理します。

    • 個々の Agent は、Agentforce Builder で Activate されている場合のみ End User が利用できます。

    • Agentforce Employee Agent など、一部の Agent は User Permission による Access Control も行われます。

    今回のアップデートによって、Agentforce を利用できる Org では Platform 自体を個別に有効化する必要がなくなり、Agentforce を利用開始するまでの初期 Setup が簡素化されます。


    いかがでしたでしょうか。

    最初にも言いましたが、個人的には、Custom Lightning Type を Preview で簡単に確認できるようになったことと、Agent Memory の一般提供開始が特に印象に残っています。

    Custom Lightning Type は、実際に Agentforce を開発していると地味ながら手間のかかる部分だったため、今回の改善はかなり嬉しいアップデートです。ほんとに何度も作り直した経験があり、非常に面倒でした。

    また、Agent Memory によって、Conversation をまたいで User に関する情報を活用できるようになったことで、Agentforce がより継続的な顧客体験を提供できる方向へ進んでいることも感じます。

    Agentforce は毎月かなりのスピードで進化していますので、今後も重要なアップデートを整理して紹介していきたいと思います。

    今回は以上です。


    次の記事はこちら

    前回の記事はこちら

    私の note のトップページはこちら

     
     
    Salesforce Marketing Cloud、Agentforce、Data Cloud、Salesforce 認定資格に関する実践的な情報を発信しています。これらの記事が、皆さまの学習や日々の業務に少しでもお役に立てば幸いです。