トップ > Salesforce > Agentforce へのリブランディングに伴う Copilot の仕様の変化

Agentforce へのリブランディングに伴う Copilot の仕様の変化

Salesforce Einstein Copilot Agentforce

こんにちは。エンジニアの山下です。

先日行われた Dreamforce 2024 の目玉として Agentforce が大きく取り上げられました。その一環として Einstein Copilot は Agent の一種として取り扱うという階層変更が行われ、またこれに伴い８月末から９月初頭にかけて一部の仕様が変更されています。

この仕様変更の中には Einstein Copilot の開発工程に大きく影響を与えるものが含まれており、その筆頭が Agent Topics の追加です。端的に述べると、これは既存の Copilot と Action の間に階層を一つ追加するような変更で、開発に対して設計レベルの影響があります。

この Agent Topics の追加により、これまで当ブログに書いてきた Einstein Copilot の記事の内容が古くなってしまったわけで、これはいただけない状況です。というわけで、今回は Agent Topics について書きたいと思います。

概要

そもそも古い仕様では、Copilot に対して複数の Action が登録されており、ユーザからの質問の内容に応じて必要な Action を自発的に呼び出すという構成になっていました。以下のような階層関係があるイメージです。

- Copilot
  - Action A
  - Action B
  - Action C

Agentforce へのリブランディング後は上記の階層関係に Topic という階層が追加され、以下のような構成に変更されました。

- Copilot
  - Topic A
    - Action A-1
    - Action A-2
  - Topic B
    - Action B-1
    - Action B-2

Topic は現在の話題に近い概念で、Copilot はユーザの質問からまず Topic を特定し、その後、該当する Topic に紐づく Action を必要に応じて呼び出すという動作をします。複数の Action を統括するためのグルーピング機能が実装されたというような趣ですね。

Action の利用は Action に付与された説明文を参照して LLM が決定するため、これまでの Copilot に Action が直接紐づく方式では Action の数が増えると誤用されないように制御するのが難しくなるという問題があったのですが、この問題は Topic の追加によってある程度緩和されそうです。

Action の登録方法

Agent Topics の追加によって Action 登録の動線が結構変わったので、登録方法を紹介しておきます。Action の作成方法等は旧仕様と同じなので割愛します。

Topic の作成や Action の Topic への登録等は全て Agent Builder で行います。Agent Builder へのアクセス方法は旧 Copilot Builder と同じです。

今回は 以前の記事 で紹介した Copilot にリスク評価をさせる Action のための Topic を作成します。以下の画像にあるメニューから Topic を作成できます。

上記の New Topic を押下すると、以下のようなウィンドウが開きます。

Topic を作成する際には以下の情報を入力します。

  • Topic label

Topic の名前を入力します。LLM がユーザの質問内容からトピックを選定する際に参照されるそうなので、地味に手を抜けない項目です。

  • Classification Description

Topic の概要説明で、Topic label と同様に LLM がユーザの質問内容からトピックを特定する際に参照されます。

  • Scope

その Topic が選択された場合に LLM がとるべき態度や振る舞いについて記述する説明文です。プロンプトによくある言い回しの「あなたの仕事は〇〇です」のような記述を行います。Topic 選択後にのみ参照される情報のため、Topic の選択自体には影響を与えません。

  • Instructions

Topic に関連する Action をどのように利用するかを記述します。Topic の中で〇〇関連の話題なら Action A を使用して、△△関連の話題なら Action B を使用して ... といった指示を記載します。

参考までに、筆者が今回作成したそれぞれの入力内容は以下になります。

Topic label:
OpportunityRiskAssessment

Classification Description:
This topic treats risk assessment for an Opportunity and questions about emails that relate to an Opportunity. Set this topic if a user asks something about risk assessment.

Scope:
Your job is to assess risks or answer questions about emails that form the basis of the assessment.

Instructions:
If a user requests a risk assessment, please use RiskAssessment action. And if a user asks about emails, please use EmailMessagesQA action.

結構適当に入力したものですが、こんな内容でも割とちゃんと動いてくれます。

上記の入力を終えて Next を押下すると、以下の Topic に紐づける Action を選択する画面にウィンドウが遷移するので、必要な Action を選択して Finish を押下すれば完了です。

Agent Topics は突然の変更だったので最初は面食らいましたが、慣れてしまえばそれほど難しい内容はないです。

Agent Topics の余波

Agent Topics それ自体には特に難しい点はないのですが、この変更によって発生したと思われる微妙な問題がいくつかあります。というのは、Copilot の動作確認をしていると、明らかに以前の振る舞いとは異なる振る舞いをすることがあり、Copilot に暗黙裡に与えられているプロンプトの変更が感じられるのです。

Topic という階層を新規に追加する以上、プロンプトを変更すること自体はやむを得ないと思うのですが、一見 Agent Topics と関係なさそうな箇所にもその影響が見られるのが気になります。

ここでは筆者が発見した（ないし感じた）変化を２点ほど紹介したいと思います。

Action へのオブジェクトの引き渡し方法の変更

Action の入力パラメータとして Account などのオブジェクトを指定することできますが、このオブジェクトの引き渡し方法が変更されたようです。

以前は LLM がオブジェクトの ID を指定し、その ID から内部的に検索・取得されたオブジェクトが Action へ渡されていたのですが、Agentforce へのリブランディング後はオブジェクトの各フィールドの値を LLM が JSON で丸々引き渡す方式に変更されたようです。

具体的には LLM から Action に対して以下のような JSON が指定されます：

{
  "id" : "0064z00002F7O1cAAF",
  "sObjectInfo" : {
    "apiName" : "Opportunity",
    "label" : "Opportunity"
  },
  "data" : {
    "Id" : "0064z00002F7O1cAAF",
    "Name" : "セイキンエンタープライズ基幹システム開発",
    "CreatedDate" : "2024-09-30T05:15:04.000Z",
    "StageName" : "Closed Won",
    "CloseDate" : "2024-09-29T00:00:00.000Z"
  }
}

data の中身が入力となるオブジェクトのフィールドです。

これ自体は単なる仕様変更に過ぎないのですが、問題は LLM によるオブジェクトのフィールドの指定内容が安定しないことです。

オブジェクトのどのフィールドが指定されるかは LLM の機嫌次第なので、Action の実行に必要なフィールドが指定されないケースが普通にあり得ます。また、より悪いケースとして、以下のように data キー自体が指定されないこともあります。

{
  "id" : "0064z00002F7O1cAAF",
  "sObjectInfo" : {
    "apiName" : "Opportunity",
    "label" : "Opportunity"
  }
}

この場合、当然ながら Action の実行はエラーになります。同様にオブジェクトの必須フィールドが指定されなかった場合もエラーになるので注意が必要です。

一応、Action の Instruction に「これとこれとこれをフィールドに必ず指定してください」と明記することでこの問題は防ぐことができます。参考までに、今回筆者が Opportunity を受け取るパラメータのために書いたプロンプトを掲載しておきます。

An Opportunity subject to risk assessment. The Opportunity must contains at least Opportunity ID, Opportunity Name, Stage, and Closed Date in the data.

とはいえ、オブジェクトの Action への引き渡しはプラットフォームが担保すべき基本機能なので、あまりこちらでケアしたくないという感はあります。そしてこの変更、Agent Topics の追加と全く関係なくないか。

英語以外の言語への対応

これは確たる証拠がないので単に筆者の偏見かもしれないのですが、英語以外の言語への許容度が下がったような感じがしています。

具体的には「回答は日本語で作成してください」と指示した際に Copilot から「回答できません」とすげなく断られる頻度が上がった印象があります。時折「英語の回答しかできません」と回答されることもあるため、少なくともプロンプトで何らかの制約がかけられていること自体は確実そうです。

そもそも Copilot 自体は英語以外の言語のサポートを謳ってはいないので、より厳密にそれを適用してきたということかもしれません。日本語への対応自体は計画されているようなので、正式なサポート待ちたいですね。

まとめ

今回の内容をまとめると以下になります。

  • Agent Topics が追加され Action のグルーピングができるようになった
  • Agent Topics の追加で Copilot に暗黙裡に渡されるプロンプトが変更された
  • Copilot から Action へ渡されるオブジェクトの指定方法が何故か変更された
  • 英語以外の言語への許容度が下がった（ような気がする）

今回の件で LLM プラットフォームの変更によって既存のプロダクトが大きな影響を受けるということが実感でき、非常に勉強になりました。LLM プラットフォームを利用する場合はプラットフォーム自体の安定性も考慮せねばならず、採用に際してはかなり注意深く選定する必要がありそうです。

LangChain 等による自前での構築はこの点で優位ですが、当然ながら開発工数が嵩むため悩ましいところです。今後どのような方法がスタンダードになっていくのか、市場の動向に注目していきたいです。

以上です。最後までお読みいただき、ありがとうございました。