こんにちは。エンジニアの大橋です。
簡単に自己紹介をさせていただくと、私は入社4年目のエンジニアとなります。 このたびAI部隊に配属となり、Agentforceの知見をまとめましたので、共有します。
フレクトでは、社内のナレッジを蓄積・共有するために「Fラボ」というツールを運用しています。近年は特にAI領域に力を入れており、FラボでもAIに関する知見や活用事例を数多く蓄積しています。今回は、その豊富なAIナレッジの中から「15分でわかる！Agentforce」という記事を特別に公開したいと思います。
なお、本内容は社内入門者向けの教育コンテンツであることをあらかじめご認識ください。
Agentforceとは
まず始めに、Agentforceとは何かというと、「Salesforceプラットフォームに組み込まれた自律型AIエージェントの総称」を指します。
自律型AIエージェント
「自律型AIエージェント」という言葉を少し深掘りしてみましょう。ChatGPTで「自律型」という言葉の意味を調べると、以下のような回答が得られました。
「自律型」とは、外部からの指示や介入がなくても自分自身で意思決定を行い、行動できる状態を指します。
つまりは「人間からの指示や介入がなくても、自己判断でタスクを遂行できるAIシステム」というわけですね。 これをSalesforce上で使えるようになっている、というのがポイントです。
Agentforceの特徴
ここからは、Agentforceがどのような特徴を持っているのかを見ていきましょう。
既存のSalesforce環境に簡単に統合できる
AgentforceはSalesforceのサービスですので、Salesforceプラットフォーム群に簡単に組み込むことができます。 具体的にどのように組み込みやすいか、2つの観点で確認してみましょう。
- 統合可能なプラットフォーム
Sales Cloud、Service Cloud、Experience Cloudなど、Salesforceが提供する各種プラットフォームへ統合可能です。 既存データや開発済みの各種機能をそのまま活用できるので、スピーディに導入を進められることが多いですが、要件やシステム構成によっては大規模な開発作業が必要となる場合もあります。
また、Agentforceは標準機能として複数のエージェント機能(Agentforce の機能について知る | Salesforce Trailhead) を用意しているので、すぐに利用を開始しやすい構成になっています。
- 呼び出し可能な機能
エージェントから呼び出し可能な機能として「プロンプトテンプレート」「Apex」「Flow」「API」があります。 Agentforceでは、発生したトリガーや状況に応じてこれらの機能を自律的に呼び出し、最適な処理を行う仕組みになっています。例えば、エージェントが必要と判断すれば、プロンプトテンプレートを利用して回答文を生成し、業務ロジックが複雑であれば、ApexやFlowを呼び出して処理を行う、といった形で発生したイベントに応じて処理の流れを自動的に進めていきます。 これにより、さまざまなユースケースを柔軟に実装できる、というわけですね。
データ基盤と併用することで活用データを拡張できる
Agentforceはデータ連携基盤とセットで使うことで、より高度なタスクの自動化を実現することができます。ここでは主にDataCloudとMuleSoftの併用例を簡単にご紹介します。
DataCloud・MuleSoftとの併用
Agentforceをフルに活用するには、社内外の多様なデータを大量にインプットする必要があります。そこで役立つのがDataCloudです。DataCloudでは大量のデータを集めることができるだけでなく、会話データやPDF資料、画像データなどの非構造化データも扱えるので、例えば顧客との会話履歴をもとにインサイトを引き出し、営業活動計画を立てて実行するAIエージェントを構築することも可能になります。
また、外部データ連携となるとMuleSoftが非常に便利です。 Agentforceは人間のようにPCを開いてシステムを直接操作するわけにはいかないため、他システムへの操作やデータの受け渡しにはAPIが必要となります。MuleSoftはこうしたAPIを設計・管理・公開できるプラットフォームであるため、DataCloudへ直接取り込みが難しいデータでも、MuleSoftを経由することでAgentforceで活用できるようになります。その結果として、Agentforceで扱えるデータ量や種類を一気に増やすことができ、さらにAPI経由で他システムのデータ操作を行うこともできるのです。
Vector DBを活用したRAG
DataCloudで保持した非構造化データは、そのままでは活用できません。非構造化データを「埋め込みベクトル」に変換し、Vector DB（ベクトルデータベース）に取り込み、インデックスを作成する必要があります。これによって高度な検索が可能になります。
なぜ非構造化データをベクトル化するかというと、非構造化データはそのままでは分析が困難ですが、数値表現に変換することで、データ間の類似度計算が可能となるからです。
Agentforceでは、このVector DBを活用したRAG（Retrieval-Augmented Generation）が重要です。 RAGでは外部の情報源を検索して必要な情報を取得し、その情報をプロンプト内に組み込むことで、LLM作成時の学習データに含まれていない追加データをLLMに与えることができます。これにより、LLMがより適切な回答を生成できるようになります。あわせて、最新のデータを参照することで、LLMが知らない最新情報を反映した回答を得ることが可能になります。 また、Vector DBを活用することで、問い合わせや入力テキストなどをもとに、意味的に関連性の高い情報を効率的に検索・取得できるようになります。 このように、Vector DBとRAGを組み合わせることで、LLMに最新かつ意味的に関連性の高い情報を与えることができ、従来では難しかった高度な回答生成を実現できるようになるのです。
後ほど紹介する「Agentforce活用例」でも、問い合わせ文との類似質問を検索する方法にRAGを活用していますので、注目してみてください。
Agentforce開発の難しさ
Agentforceは非常に便利ですが、開発上の懸念点もあります。ここでは、大きく2つの原因からくる問題について解説します。
LLM（大規模言語モデル）の特性に起因する問題
ハルシネーションを完全には防げない
LLM全般に言えることですが、ハルシネーション（事実でないことをあたかも正しい情報のように返してしまう現象）は避けられません。コールセンター業務の問い合わせ対応を例に挙げると、誤情報を返してしまうといったリスクがあるので、事前にステークホルダーへ説明したり、人による確認プロセスを入れたり、RAGで情報の信頼性を補ったりといった対策が必要です。 一方で、LLMが判断に必要とする十分な情報を適切に提供すれば、かなりのケースでハルシネーションを回避できる可能性が高まるため、システム設計やデータ準備の段階から、どういった情報が必要になりそうか検討しておくことが重要になります。
言語能力は高いが、計算能力は低い
多くのLLMは言語処理が得意である一方、厳密な数値計算や論理的理由づけが苦手です。そのため、在庫予測など数値の正確さが求められるタスクでは、LLMの生成結果に基づき、別途プログラムで数値演算や検証を行う仕組みを組み込む必要があります。あるいは、推論過程を出力させて段階的に推論を行うように促すなど、さまざまな工夫が求められます。
出力生成過程がブラックボックスである
LLMの出力生成過程はブラックボックス的になっているため、「なぜその回答に至ったのか」を厳密に追跡しづらいです。これは開発やテストの段階では、出力の調整に時間と手間がかかってしまうことにつながるため、事前にバッファを見込んだスケジューリングとテスト計画を立てる必要があります。また、それ以上に実運用では大きなリスクとなり得ます。なぜなら、誤回答が生じた場合に原因究明や再現性の確保が難しくなり、説明責任を果たせないからです。そのため、運用フェーズで出力の妥当性を検証する仕組みを準備しておくことが重要になります。
出力がLLMモデルの性能に依存する
LLMの回答は、ベースとなるモデルが保持している知識に強く影響されます。モデルに含まれない情報を扱うにはRAGなどの仕組みが必要ですし、そもそも外部データでも見つからない場合には回答できません。したがって、モデルの選択と外部データ管理には注意を払う必要があります。
業務知識の複雑さに起因する問題
ユーザーから回答に必要な情報を引き出す工夫が必要
LLMが適切な回答を生成したり判断したりするためには、それに必要な情報をインプットとして渡せているかが重要です。 例えば、商談内容の要約を生成したい場合、「どの商談を対象とするか」の情報が必要になります。 このような単純なケースであれば、ユーザーに追加の質問を行い、不足している情報を取得すれば問題なく対応できそうです。
しかし、もし業務知識の間に依存関係があるような場合になると、少し複雑になります。 具体的な例を挙げると、保険会社のカスタマーサポートへの問い合わせを会話記録からレコード自動生成するタスクを考えてみましょう。会話データからレコード登録に必要な「相手車両の状況」を取得できなかった場合、追加の質問を行ってその情報を取得しなければ先へ進めません。しかも「相手車両の状況」によってさらに別の情報が必要になるケースがあるなら、「相手車両の状況」を質問して回答を得た上で、状況に応じた追加の質問を続ける必要が出てきます。
このように、業務知識間の依存関係をしっかり把握しておかないと、必要な情報をうまく引き出せないまま作業フローが中断されてしまう恐れがあります。したがって、業務知識同士の関連性を認識しながら、状況ごとに必要となる追加情報を適切にヒアリングできるような設計を用意しておくことが求められるというわけです。
業界固有の知識に対応しなければならない
LLMは汎用モデルのため、カバーしている知識が広く、幅広い用途に対応可能な柔軟性を持つ反面、特定の業界（医療・金融など）で求められる高度な専門知識は研ぎ澄まされていないことがあります。その場合、プロンプトエンジニアリングで追加の事前知識を入力し、モデルが特定の業界にカスタマイズされた回答を生成できるように調整することが重要になってきます。
こうした「ユーザーから追加の情報を引き出さなければならない場面」と「業界固有の知識への対応」が重なってくると、LLMが判断する際に考慮すべき情報や条件は線形ではなく指数関数的に増加し、いわゆる“組み合わせ爆発”が起きやすくなります。 結果として、要件定義や対話シナリオの設計が大幅に複雑化し、すべてのパターンを網羅的にテストすることも非常に困難になります。ですので、事前に優先度の高いケースや頻度の高いシナリオを特定し、重点的に設計・検証を行うなど、慎重なアプローチが求められます。
Agentforceの基本の流れ
ここでは、Agentforceが実際に動く際の大まかな手順を整理してみましょう。
トリガー
Agentforceを起動するきっかけになるイベントです。以下の種類があります。
- 会話
- 外部のチャットサービスを通じてユーザーから問い合わせがあった場合
- データ変更
- Salesforce内でオブジェクトやレコードが変更された場合
- Flow
- Apex
推論
トリガーが発生すると、Agentforce の推論エンジン（Atlas推論エンジン）が状況を解析し、該当のユースケースに最適な「トピック」を選択します。 Atlas推論エンジンの説明は割愛しますが、興味のある方は確認してみてください。(Agentforceの頭脳「Atlas推論エンジン」の仕組み - セールスフォース・ジャパン )
トピック
エージェントが達成すべき目的や、その目的を達成するためのアクションを定義します。 例えば、サービスエージェントであれば「ケース管理」「注文の問い合わせ」「エスカレーション」などに分かれます。 トピックによってAgentforceが扱う範囲を絞ることができます。これにより、どんな依頼にも対応できる万能なAgentforceを開発しなくても済む、というメリットがあります。また、専門外の領域に対して誤った回答を行うリスクを抑えることができ、Agentforceの品質や信頼性を高めることにもつながります。
アクション
トピック上で実行するタスクを定義します。 Agentforceでは、ガードレール（エージェントが守るべきガイドライン）を参照しながら動くため、意図しないアクションを起こしにくい設計になっています。 呼び出せる機能として「プロンプトテンプレート」「Apex」「Flow」「API」が用意されています。
出力チャネル
生成された応答や結果がどこに返されるのか、という部分です。 CRM、Webサイト、Slackなど、多様なチャネルに対応できるようになっています。
Agentforce活用例
IT Support QA Bot (Pomeko)
ここでは具体的な利用例として、社内情シスへの問い合わせ対応ボット（Pomeko）をご紹介します。 ※PomekoにはSlack, AWSの要素も加わっていますが、本記事ではAgentforce部分に焦点を当てます。
全体像をざっくり言うと、以下のような流れになります。
- SlackでのPomekoへのメンションを受信すると、それがトリガーとなり、Pomekoの処理が開始されます。
- 問い合わせ内容を解析し、最適なトピックが開始されます。
Pomekoにはあらかじめ「Question」「Request」「Others」のトピックが定義されており、いずれかのトピックが選択されます。
- Question
- 問い合わせ内容に回答するためのトピック
- Request
- ユーザからの要請が質問ではなく依頼事項だった場合、情シスへ連携するためのトピック
- Others
- 上記以外の要請に対応するための汎用トピック
- Question
- トピックが決まると、そのトピックに含まれるアクションの中で最適なアクションが実行されます。各トピックに含まれるアクションの詳細は以下をご覧ください。
- FAQ
- 「Question」トピックで実行されるプロンプトテンプレート参照アクション
- ユーザーからの類似質問のスレッドメッセージ全量を取得し、サマリすることで解決方法を作成する
- ユーザーからの類似質問のスレッドメッセージ全量は「Retrieve Similar Question Thread」アクションで取得する
- Retrieve Similar Question Thread
- 「FAQ」アクションから呼び出されるFlow参照アクション
- ユーザーからの類似質問のスレッドメッセージ全量を取得する
- ユーザーからの類似質問は「Retrieve Similar Question」アクションで取得する
- Retrieve Similar Question
- 「Retrieve Similar Question Thread」アクションから呼び出されるプロンプトテンプレート参照アクション
- Vector DBを活用したRAGにより、ユーザーからの質問の類似質問を過去のSlackへの問い合わせデータから取得する ※DataCloudにSlackの親メッセージを表すDMOとそのSearch Indexが定義済みである前提とする。
- Forward To IT Support
- 「Request」・「Others」トピックで実行されるプロンプトテンプレート参照アクション
- 情シスへのメンション文を生成する
- FAQ
- 最終的にはSlackに対してこれらのアクションが実行され、ユーザーが必要とする回答や依頼が処理されます。
補足
料金システム
最後に、Agentforceの料金面も簡単に触れておきたいと思います。(Salesforce Agentforce Pricing | Salesforce US )
Agentforceは会話数の従量課金制となっています。 そのため、検証・開発フローを雑に回しているとあっという間にコストがかさむ可能性があり、効率的な会話設計を行うことがポイントになります。
また、LLMへのAPIコールごとにトークン数に応じて、AI Requestが消費され、こちらも課金対象となります。
さらに、Agentforceには外部顧客向けだけでなく、従業員向けの機能があります。 Salesforce画面の右上に表示されるアイコンですね。（マウスオーバーすると「Agentforce」と表示されるボタン） 会話数ですが、外部顧客向けの場合は消費されますが、従業員向けの場合は消費されないので、注意してください。 AI Requestについては、外部顧客向けと従業員向けのどちらの場合でも、消費されます。
以上です。最後までお読みいただき、ありがとうございました。
