こんにちは。エンジニアの和田です。
以前、AIエージェントにいくつかデータを繋げたところで見えてきた課題という記事を公開しました。そこでは、AIエージェントにデータを接続することでできることは増えましたものの、単純に接続しただけでは課題がいくつか出てきて、その先には地道な調整が必要となる、という話を書きました。
では、実際にどのように調整すればよいのでしょうか。今回は、AgentforceでAIエージェントを構築した場合を例に、どこをどのように調整していくか解説します。
具体的には、以前の記事で示した以下の3つの問題にフォーカスを当てて、それぞれの調整方法に関して見ていきます。
- 検索すべきデータの選択を誤ることがある
- ユーザーの課題を解決しない検索結果をそのまま提示してしまう
- 明確にデータ化されてない知識が必要になる
以前の記事ではAgentforceに限らず一般のAIエージェントも想定して記述しましたが、今回はAgentforceに絞って議論していきたいと思います。
なお、今回記載の内容は2025年11月現在のものです。近々、Agentforce BuilderのリニューアルやAgent Scriptの導入が予定されているため、その動向次第で最適な解決策が変わり得る点にご留意ください。
「検索すべきデータの選択を誤ることがある」問題の対処
まずは、「検索すべきデータの選択を誤ることがある」問題についてみていきます。
以前の記事で紹介した具体例としては以下のようなものです。
- Slackコネクトを特定の条件下で使う場合の社内申請について尋ねているのに、Web検索してSlackコネクトの一般的仕様について答えてしまう（運用の質問を仕様の質問と勘違いしたケース）
- Teamsの参加招待を受けたのに入れないという問い合わせなのに、Backlog課題チケットを検索し、チーム招待の過去申請について答えてしまう（仕様の質問を運用の質問と勘違いしたケース）
Agentforceでは、データの接続に通常Actionを用いると思います。ActionはTopicに紐づいているため、「検索すべきデータの選択を誤ることがある」問題は、Agentforceにおいては「TopicやActionの選択ミス」の問題と見なせます。
となると、まずチェックしたいのは、次の設定です。
- Topic選択に用いる説明文
- Classification Description
- Scope
- Action選択に用いる説明文
- TopicのInstructions
- ActionのAgent Action Instructions
ただし、これらは、Topic選択であればAgentが呼ばれるたび、Action選択であればTopicが呼ばれるたびに参照されるため、長すぎると性能が低下するリスクがあります。
まずは大まかな指示で試してみて、うまくいかない場合は細かい指示を加えていく形になると思いますが、観点が多い場合は、Actionであれば別途Prompt Templateを立て、Actionを呼ぶかどうかの判定用Actionを作るのも一つの手です（Topic選択ではこの方法は使えませんが）。こうすると、判定Actionは必要に応じて呼ばれ、判定自体は専用に特化したプロンプトのみで行われるため、コンテキストが絞られ、性能低下のリスクを軽減できます。
ただし、Flex Creditの場合、呼ぶActionが増えるためCredit消費量も増える点に注意してください。
どう修正するかですが、まず、そのデータで解決できる例とできない例を具体的に列挙する方法が考えられます。網羅的な列挙が理想ですが、実際にActionの選択を失敗している例があれば、それを挙げるのも有効です。
例えば上記の「運用の質問を仕様の質問と勘違いしたケース」であれば、Web検索Action選択の判定プロンプトで、そのデータで解決できない例として「システムの社内運用ルール」を記載しておく、といった具合です。プロンプトの例としては以下のような形です。
... Web検索をすることで解決可能なものの例: - 一般的なアプリやサービス等の使い方や設定に関するもので、MicrosoftやSalesforceなどのサポートページで一般公開されている情報を参照すればわかるもの - ... Web検索では解決不可能なものの例: - 会社の規則 - システムの社内運用ルール - ... ...
また、データの選択にあたって、実は暗黙知が必要だったという場合もあります。
例えば、社内システムを特定の名称で呼んでいることを知らないために、その名称で間違ってWeb検索してしまう、ということがあります。そこで、こういった暗黙の知識をプロンプトでインプットしておくことが重要です。先ほどのWeb検索Action選択の判定プロンプトにこの知識をインプットした上で、Web検索では解決できない例として「社内システム」と書いておけば、Web検索を選択しないようになります。
ただ、そもそも、その問い合わせがそのデータで本当に解決できるかどうかの判断は、人間でも難しい場合があります。他のLLMで確認したり、実際の問い合わせ例で解決できているかを確認したりするしかなさそうです。
そのデータで解決できるか、できないのか、の議論における一つのポイントは、「部分的に役立つ場合、そのデータに接続するかどうか」というところです。
理想的には、部分的にも役立つのであれば、試しにデータへ接続してみるべきでしょう。しかし、それにはAgent側で複数のデータソースからの出力を統合する仕組みが必要となり、ハードルが高くなります。また、仮にそのような仕組みが整ったとしても、「部分的に役立つ」度合いというのはグラデーションがあり、単独では役立たず他と合わせることで効果を発揮するものから、ほとんど役に立たないがゼロではないというものまであり、後者はかえってノイズになりかねません。したがって、場合によっては、部分的に役立つとしてもデータに接続しない、という判断が必要になることもあります。
「検索すべきデータの選択を誤ることがある」問題のまとめ
- 基本的にTopic/Actionの選択の問題である
- まずはAgentのTopicやActionの指示文を確認する
- 別にPrompt Templateを立てることを検討する（ただしCredit増加に注意）
- そのデータで解決できる例・できない例を具体的に列挙する
- 暗黙知をインプットする
- 部分的に役立つ場合にそのデータに接続することにするか判断する
「ユーザーの課題を解決しない検索結果をそのまま提示してしまう」問題の対処
次に、「ユーザーの課題を解決しない検索結果をそのまま提示してしまう」問題の対処について見てみます。
以前の記事で紹介した具体例としては以下のようなものです。
- 物理的なノートPCのOffice導入について尋ねているのに、EC2上のOffice導入に関する過去質問を持ってきてしまう
- PCがつかないという問題で強制再起動をすでに試したとユーザーが言っているのに、PCがつかない問題に関する過去質問を持ってきて、強制再起動を指示してしまう
基本的にはデータの検索に関する問題ということになるので、データの検索クエリを工夫する、検索機構そのものを改善する（ハイブリッド検索を採用する、Vector DBを作成する際のembedding modelやchunk sizeなどを調整する）ことも考えられますが、上記のケースでは、検索結果と質問を照らし合わせ、真に課題を解決するデータか吟味する仕組みを強化する必要がありそうです。
Agentforceの文脈では、まずAgentのInstructionでデータを吟味するよう指示する方法が考えられますが、経験上、大きな効果は期待できません。Instructionには他にも多くの指示が含まれるため、追記しても期待するほどの効果が得られないことが多いです。 最終的な出力形式の調整程度であればInstructionでも有効な場合がありますが、Atlas推論エンジンの基本LLMモデルがGPT-4oであることも影響しているのか、複雑な吟味には向いていないようです。
そうなると、次の策としては、検索結果を吟味するPrompt Templateを用意することになります。 こうすると、より新しいモデルも扱えますし、より緻密に検索結果を吟味することができます。ただし、レイテンシーは増加します。
問題はこのPrompt TemplateをどうAgentに組み込むかですが、単純に一つのActionとして接続すると呼び出される保証がなく、呼び出されたとしても検索結果をそのままインプットするとは限らないため、一つのFlow内で検索の次にこのPrompt Templateを組み込み、そのFlow自体をActionとする方が現実的です。
ただし、今後導入予定のAgent Scriptでは、Actionの出力を変数に入れたり、変数に入っている値をActionの入力に入れたりできそうなので、Agent Scriptが導入されれば、検索結果を吟味するPrompt Templateのみを一つのActionとしてAgentに接続する方が良いかもしれません。
「ユーザーの課題を解決しない検索結果をそのまま提示してしまう」問題のまとめ
- 検索クエリや検索機構の改善も考えられるが、結果の吟味も大事
- AgentのInstructionで結果を吟味させるのは厳しい
- 結果を吟味するPrompt Templateを立てたほうが効果的
- 現状では、Flowの中で検索実行の次に連続的にPrompt Templateを実行する構成が現実的
「明確にデータ化されていない知識が必要になる」問題の対処
最後に、「明確にデータ化されていない知識が必要になる」問題の対処について見てみます。 なお、似たような話題として暗黙知の話が先ほども少し出てきましたが、ここではもう少し踏み込んで見ていきたいと思います。
以前の記事で紹介した具体例としては以下のようなものです。
- 社内システムに特定の名前を付けているが、その名称を挙げた問い合わせが来ても、その名称が社内システムを指すことや、システムの詳細をエージェントが知らないため、適切に回答できない
- Windows PCに関する問い合わせが来た際、弊社では特定メーカーの製品のみを採用しているため本来はそのメーカーに特化した対処を提示したいが、その前提を知らないため適切な回答ができない
- 「こういう問題が発生するので端末交換させてほしい」という問い合わせに対し、端末交換せずに解決できる方法があっても、それを先に提示できず、すぐに端末交換の回答をしてしまう
そもそも、このような「明確にデータ化されていない知識」は、その性質上、事前に特定して準備することが困難です。まずは試験的にAgentを運用し、実際の問い合わせ例から必要な知識を洗い出すことが重要です。
では、必要な知識を特定できたとして、この知識をどこに設定すればよいでしょうか。
複雑な内容であれば、それ自体をデータソースとして新たに接続することにはなりますが、ちょっとした判断で使いたい簡単な知識もあります。
AgentforceのAgent設定にグローバルに設定すればあらゆる動作で使われるため良さそうですが、実際にはうまくいかないことが多いです。先述の通り、Agent設定の指示が多くなりがちな点や、基本LLMモデルがGPT-4oである点から、現状のAtlas推論エンジンでは対応が難しいようです。
したがって、知識が必要なところに個別に差し込んでいく形になります。
例えば、上記のWindows PCに関する問い合わせであれば、Web検索のクエリを作るPrompt Template等のプロンプトの中に、Windows PCとしては〇〇社の製品を採用しているという知識を入れておくことで、知識を考慮した検索ができるようになります。
「明確にデータ化されていない知識が必要になる」問題のまとめ
- こうした知識は事前に洗い出すのが難しいため、まずは試験運用してみて、不足している前提知識を見つけていく
- 内容が複雑なものはデータソースとして接続し、簡単な前提や判断は個別のPrompt Templateなどに差し込む
- Agent設定にグローバルに書きすぎると効きづらいので、知識が必要なPrompt TemplateやActionなどに差し込んでいく
おわりに
以上、データを接続した際に発生する問題に対し、Agentforceで具体的にどう対処するかを見てきました。
単にデータを接続するだけでは不十分な場合、何らかのプロンプトや機構を加えることになるわけですが、現時点のAgentforceでは、接続データに関してAtlas推論エンジンに複雑な判断をさせるのは難しいように見えます。そのため、きちんと対応しようとすると別途Prompt Templateを組むことが多くなりますが、これはレイテンシーや料金とのトレードオフになります。
以前の記事で述べた通り、この領域は工数に対して効率が悪化しがちなため、どこまで調整を行うかの判断が迫られそうです。
本記事が、AIエージェントを調整する際の一助となれば幸いです。
最後までお読みいただきありがとうございました。
