【2026年8月時点】Agentforceのモデル選択と推論制御｜出力を安定させる設計基準

同じ質問を2回投げても、Agentforceが返してくる文章が一字一句同じになることはありません。Agentforceの出力制御とは、どこまでをAIの判断に任せ、どこからを業務側で固定するのかを決める設計のことです。 ところが実際には、この線を引かないまま指示文だけを直し続け、直すたびに別の手順が崩れている、という状態に置かれている担当者も少なくないのではないでしょうか。

そこで本記事では、Agentforceの出力が揺れている場所の切り分け方から、任せる範囲と固定する範囲の決め方、モデル選択を含む制御手段の使い分けまでを整理します。なお本記事は2026年8月時点の情報にもとづいています。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援を提供している。

Agentforceの出力が安定しないと感じる3つの場面

Agentforceの出力が安定しないという相談は、設定のどこかに不備があるという話として持ち込まれます。ところが営業や問い合わせ担当から挙がってくる声を1件ずつ聞いていくと、症状の中身は1つではありません。今回は、電子部品を扱う中堅の専門商社（従業員約280名・営業60名）が、問い合わせの一次対応と商談準備メモの要約という2つの用途で半年前からAgentforceを動かしているケースも交えて解説していきます。

「出力が安定しない」という一語は、対処する場所の違う複数の症状をまとめて指しています。症状の側を分けないまま設定に手を入れると、直る症状と直らない症状が混ざり、どの手当てが効いたのかも分からなくなります。

場面①同じ質問に毎回違う回答が返る

1つ目は「同じ質問に毎回違う回答が返る」場面です。営業担当者が昨日と同じ言葉で聞いたつもりでも、返ってくる文章が違うため、どちらを信じてよいのかを自分で判断できなくなります。

この専門商社では、稼働から最初の1か月は営業60名のうち40名がAgentforceを使っていました。ところが半年たったいまは、週あたりの利用者が20名ほどまで減っています。営業企画の担当者が1週間分の申告をまとめたところ、「答えが違う」という指摘は12件あり、そのうち5件が「昨日と違うことを言われた」という内容でした。

具体的には、ある営業担当者が「この型番の代理店向け価格の考え方を教えてほしい」と2日続けて聞いたところ、1日目は値引き率の上限に触れた回答が返り、2日目はその記述がないまま標準価格の説明だけが返ってきました。どちらの回答も社内規程に反してはいませんが、聞いた側からは「昨日と言っていることが違う」と見えます。

回答が毎回変わる用途では、営業担当者がその回答を使ってよいかどうかを自分で確かめ直す作業が増えます。回答の揺れが最初に指摘されやすいのは営業向けの用途で、その活用の全体像は、ほか記事「Agentforce for Sales｜SDR・Sales Coachの使い方と営業活用事例」で解説していますので、ぜひ参考にしてもらえると嬉しいです。

場面②決めた手順の途中が飛ばされる

2つ目に挙げるのは「決めた手順の途中が飛ばされる」場面です。指示文には確認すべき順序を書いてあるのに、会話の流れによっては、その確認を挟まないまま結論だけが返ってきます。

先ほどの12件のうち4件が、この型でした。この専門商社では、納期を答える前に必ず在庫を確認する、という手順を業務側で決めています。在庫が動きやすい商材であり、確認を通さずに答えた納期がそのまま代理店への回答になると、受注後の取り消しにつながるからです。

実際に起きたのは、代理店から「この型番、来週中に200個出せますか」と聞かれた場面でした。エージェントは在庫の確認を通さずに、標準の納期日数だけを根拠として「来週中に出荷できます」と返しています。営業担当者が念のため画面で在庫を見たところ、その時点の引当可能数は120個でした。

指示文に手順を書いても、書いた順序で毎回通るとはかぎりません。この違いを営業企画の担当者が「指示文の書き方が悪い」と受け取ってしまうと、直しても止まらない症状に見えてしまいます。

場面③見てほしいデータを見ずに答える

残る3件は「見てほしいデータを見ずに答える」場面でした。レコードを検索したうえで答えてほしい質問に対して、検索が空で返ったことには触れないまま、一般的な案内文だけが返ってきます。

この専門商社では、代理店からの問い合わせを受けたときに、まず取引先のレコードを検索して過去の取引条件を確認する、という流れを想定していました。ところが代理店名で検索した結果が空で返った場面では、エージェントは「該当する情報が見つかりませんでした」とは伝えず、「一般的には納期は5営業日程度です」といった案内文を返しています。

営業担当者からすると、レコードを見て答えたのか、見ずに答えたのかが文面から判別できません。取引条件が個別に決まっている代理店ほど、この回答は使えないものになります。

エージェントがデータを参照できていないときに、参照できていないと伝えるかどうかは、業務側で決めておく必要があります。ここまでの3つの場面は症状としては近く見えますが、手当てをする場所はそれぞれ違います。

Agentforceの回答が現場に信用されない3つの理由

ここまで、Agentforceの出力が安定しないと感じる3つの場面を見てきました。どれも設定の不備として扱われがちですが、3つを並べてみると、共通しているのは設定の粗さよりも、AIに何をどこまで任せるのかを決めていない点にあると分かります。そこでここでは、Agentforceの回答が現場の担当者に信用されなくなる3つの理由を整理していきます。

Agentforceの回答が信用されなくなるのは出力の精度が低いからではなく、AIが判断してよい範囲を業務側で決めないまま運用を始めているからです。

理由①判断の余地を残したまま任せているから

まず整理したいのは、エージェントに渡した業務のうち、どこまでが判断で、どこからが手続きなのかを分けていない点です。AIは渡された情報の範囲で最も妥当と考えた回答を組み立てるため、判断してよいと明示していない部分についても、判断を挟んで答えます。

たとえば「代理店向けの価格の考え方を教えてほしい」という質問には、標準価格の説明だけで足りる場合と、値引き率の上限まで説明したほうがよい場合の両方があります。どちらを答えるのかを業務側で決めていなければ、エージェントは会話の流れから妥当なほうを選びます。選び方が変われば、返ってくる文章も変わります。

先ほどの専門商社では、この2つのどちらを返すのかを決めないまま、「代理店からの価格に関する質問に答える」という粒度で指示文を書いていました。そのため同じ型番の質問でも、聞き方が少し変わるだけで回答に含まれる情報の範囲が動いています。

判断の余地を残しておくこと自体が誤りというわけではありません。困るのは、残したつもりのない場所に余地が残っている状態です。

理由②手順の順序を指示文だけで伝えているから

次に挙げたいのは、手順の順序を指示文の文章だけで伝えている点です。指示文はエージェントに渡される材料の1つであり、書いた順序がそのまま実行の順序になるとは決まっていません。

では、なぜ書いた順序どおりに実行されないのでしょうか。それは、指示文に書かれた内容が、AIが回答を組み立てるときに参照する情報として扱われるからです。「必ず在庫を確認してから納期を答えてください」と書いた一文は、確認を通らないと先へ進めないという制約にはならず、そう振る舞ってほしいという要望として渡ります。

先ほどの在庫確認の場面が、これにあたります。営業企画の担当者は指示文の冒頭に確認の手順を書き、「必ず」という語も入れていました。それでも代理店からの急ぎの質問では、会話の流れとして納期を先に答えたほうが自然だと判断され、確認が後ろに回っています。

順序を守らせたい手順があるなら、要望として書く方法とは別の手段が要ります。この見極めが、手段を切り替える分岐点になります。

理由③参照先を絞る条件を書いていないから

3つ目に触れておきたいのは、どのデータを参照して答えるのかという条件を書いていない点です。参照できるものが複数あるとき、エージェントはそのつど参照先を選びます。

この専門商社では、問い合わせの一次対応を担うエージェントに、取引先レコードの検索と、社内の商品ナレッジの検索という2つのアクションを配線していました。代理店名を含む質問であれば取引先レコードを見てほしいのですが、その条件は指示文にも設定にも書かれていません。その結果、質問の言い回しによっては、ナレッジ側だけを見て答える場面が出ています。

さらに、参照した結果が空だったときにどう振る舞うのかも決めていませんでした。空で返った場合に一般論で補ってよいのか、見つからないと伝えるべきなのかは業務によって答えが変わりますが、決めていなければ、エージェントはそのつど妥当なほうを選びます。

ここまでの3つの理由に共通しているのは、決めるべきことを決めていない状態を、設定の調整で埋めようとしている点です。

Agentforceに判断を任せてよい3つの条件

前章では、Agentforceの回答が信用されなくなる理由を、決めていないことの側から整理しました。ここから先は、では何を決めるのかという話に入ります。順序としては、固定する範囲を決める前に、任せてよい範囲を先に定めたほうが判断が進みます。そこでここでは、Agentforceに判断を任せてよい3つの条件を整理します。

任せてよい範囲を先に決めておくと、残った部分が固定すべき範囲として浮かび上がるため、固定の対象を1つずつ探す作業がなくなります。

条件①正解が1つに定まらない問いであること

1つ目は「正解が1つに定まらない問いであること」です。答えが1つに決まっている問いをAIに任せると、決まった答えとの差が誤りとして現れます。逆に答えが1つに決まっていない問いでは、複数の妥当な回答があること自体が前提になります。

この専門商社の2用途でいえば、商談準備メモの要約がこれにあたります。同じ商談メモを要約しても、どの発言を残してどれを落とすかには複数の正解があり、営業部長が読んでも「これは違う」とは言えません。要約の目的は、商談前の5分で前回の論点を思い出すことにあるためです。

一方、在庫の引当可能数は答えが1つに決まります。120個という数字に対して、妥当な別解はありません。同じエージェントの中でも、この2種類が混ざっている点が判断を難しくしています。

任せてよいかどうかを見るときは、その問いに対して社内の誰かが「正解はこれです」と即答できるかを確かめましょう。即答できる問いは、任せる側には置かない対象です。

条件②誤っても人が引き取れる範囲であること

2つ目に挙げるのは「誤っても人が引き取れる範囲であること」です。ここでいう引き取れるとは、誤りに気づける人が回答と受け手の間に立っていて、その人が訂正できる状態を指します。任せてよいかどうかを決めるのは、誤りが起きる確率ではありません。起きた誤りを、社外へ届く前に誰かが止められるかどうかです。

商談準備メモの要約は、読むのが商談に出る営業担当者本人です。要約に抜けがあっても、本人が元のメモを開けば気づけますし、そのまま社外へ出ることもありません。この構造があるうちは、多少の揺れを許容しても業務が止まりません。

これに対して、代理店へそのまま転送される納期の回答は、営業担当者が目を通さずに送られる運用でした。誤りに気づく人が間に立っていないため、揺れがそのまま社外に出ます。同じ会社の中でも、引き取れる用途と引き取れない用途が並んでいる状態です。

判断するときは、回答が届くまでの間に人の目が何回入るのかを数えてみましょう。ゼロなら、任せる側には置けません。

条件③言い回しだけが変わる出力であること

3つ目は「言い回しだけが変わる出力であること」です。揺れといっても、含まれる情報は同じで表現だけが変わる場合と、含まれる情報の中身まで変わる場合とでは、業務への影響がまったく違います。

先ほどの12件を営業企画の担当者が読み直したところ、「昨日と違う」と申告された5件のうち2件は、文章の組み立てが変わっただけで、伝えている内容は同じでした。残る3件は、値引き率の上限に触れているかどうかという情報の差でした。同じ「違う」という申告の中に、許容できる差と許容できない差が混ざっています。

この区別を営業現場と共有していないと、表現が変わっただけの回答まで誤りとして申告され、どこを直せばよいのかが読めなくなります。逆にいえば、変わってよい範囲を先に伝えておくだけで、申告の内容が絞られます。

任せる側に置けるのは、情報の中身が同じで表現だけが動く出力です。この3つの条件を満たさない業務は、次に整理する固定すべき側に振り分けることになります。

Agentforceで出力を固定すべき3つの業務

前章では、Agentforceに判断を任せてよい条件を3つ整理しました。ここで見ておきたいのは、同じエージェントの中に、任せてよい業務と任せてはいけない業務が並んでいる場合が多い点です。用途の単位で線を引くと粗すぎるため、業務の単位まで下ろして判断します。そこでここでは、Agentforceで出力を固定すべき3つの業務を整理していきます。

固定すべきかどうかを決めるのは、業務の重要度ではありません。固定するかどうかは、誤った回答が社外に出て取り消せなくなるかどうかで決まります。

業務①金額や在庫を確定して回答する業務

1つ目は「金額や在庫を確定して回答する業務」です。金額と在庫は、回答した時点の数字が約束として受け取られるため、揺れが値引きの誤りや納期の取り消しにそのまま変わります。

先ほどの専門商社では、代理店から「この型番、来週中に200個出せますか」と聞かれる問い合わせが週に20件ほど入ります。この質問に対して必要なのは、その時点の引当可能数を見て答えることだけで、判断の余地はありません。エージェントに求めているのは、決まった参照と決まった伝え方だけです。

固定するときに決めるのは、どのデータを見るのか、見た結果をどの形式で返すのか、そして見られなかったときにどうするのか、という3点になります。この3点を決めずに「正確に答えてください」と指示文へ書き足しても、参照先の選び方は変わりません。

金額と在庫を扱う業務では、回答に含める数字の出どころを1つに決めましょう。出どころが2つ以上あるうちは、どちらを見たかによって回答が動きます。

業務②社外に出る文面をそのまま使う業務

2つ目に挙げるのは「社外に出る文面をそのまま使う業務」です。エージェントが作った文章を人が読み直さずに送る運用では、揺れが社外向けの表現の揺れになります。

この専門商社では、代理店からの一次回答をエージェントの文面のまま返す運用を検討していました。ところが試してみると、同じ内容でも「恐れ入りますが」から始まる回答と、いきなり結論から入る回答が混ざり、取引先によっては、この丁寧さの差を対応の差として受け取る場合があります。

こうした業務では、返す文面の型をこちらで用意し、そこへ数値や品名を差し込む形にすると、エージェントに文章を作らせる範囲が狭まり、社外に出る表現は安定します。社外向けの回答を扱うエージェントの設計は、ほか記事「Agentforce Service Agentとは」で詳しく解説しています。

社外に出る文面は、誤りの訂正に取引先とのやり取りが1往復増えます。この1往復を避けたいかどうかが、固定するかどうかの判断になります。

業務③法令や社内規程で順序が決まる業務

3つ目は「法令や社内規程で順序が決まる業務」です。順序が外部の決まりで定まっている業務では、手順を飛ばした時点で、回答の内容が正しくても手続きとしては不備になります。

たとえばこの専門商社では、輸出の該非判定に関わる型番の問い合わせについて、用途と仕向地を確認してから回答する、という順序を社内規程で定めています。確認を通さずに納期だけ答えると、内容が合っていても規程上は通っていない回答になります。

この種の業務で確認したいのは、回答の正しさよりも、決めた順序を毎回通っているかどうかです。通っていることを後から確認できる状態にしておかないと、社内の監査で説明ができません。

法令と社内規程が絡む業務は、任せる側に置かないと決めておきましょう。判断の質が高いかどうかよりも、手順の通過を証明できるかどうかで扱いが決まります。

ここまでの2つの章で示した、任せてよい条件と固定すべき業務を1枚にすると、次の表になります。行を選ぶときの基準は、誤りの影響が社外に出るかどうかです。社外に出るものから順に上へ置き、自社の業務名に置き換えて使ってください。

Agentforceの出力の揺れが起きる3つの層

ここまでは、任せる範囲と固定する範囲をどう分けるかという設計の話でした。次に必要になるのは、いま自分のところで起きている揺れが、どこで発生しているのかを特定する作業です。揺れの発生場所によって、手当てをする場所が変わるためです。そこでここでは、Agentforceの出力の揺れが起きる3つの層を整理します。

揺れが起きる場所は3つに分かれており、どの層で起きているのかを先に特定しないと、効かない場所へ手を入れ続けることになります。

層①どのサブエージェントを選ぶかの揺れ

1つ目は「どのサブエージェントを選ぶかの揺れ」です。Agentforceでは業務ごとにサブエージェントを分けて配置するため、まず入ってきた質問がどのサブエージェントに渡るのかが決まります。この振り分けが会話ごとに変われば、その先の処理はすべて変わります。

先ほどの専門商社の12件を、営業企画の担当者が実行の記録と突き合わせて分けたところ、3件がこの層でした。いずれも代理店向け価格に関する質問だったにもかかわらず、商談準備メモの要約を担うサブエージェントが受けています。要約側には価格の参照先が配線されていないため、回答は過去のメモに書かれた内容だけを根拠にして組み立てられていました。

この層で揺れているときは、指示文の中身をいくら直しても症状が変わりません。手を入れる場所は、それぞれのサブエージェントがどんな質問を受け持つのかという説明の書き分けと、受け持ちが重なっていないかの確認です。

同じ質問が違うサブエージェントに入っていないかを、まず確かめましょう。ここが動いていると、下の2つの層で何を見ても原因を取り違えます。

層②どのアクションを呼ぶかの揺れ

サブエージェントが正しく選ばれたあとにも、揺れは残ります。そこに配線された複数のアクションのうち、どれを呼ぶか、そもそも呼ぶかどうかが、会話ごとに決まるためです。

12件のうち7件がこの層に集まりました。内訳は、在庫の確認を通さずに納期を答えた4件と、取引先レコードを見ずに商品ナレッジ側だけを見て答えた3件です。どちらも、必要なアクションが配線されていなかったわけではありません。配線はされているのに、その会話では呼ばれなかった、という状態でした。

呼ばれるかどうかが会話ごとに変わる以上、「必ず呼んでください」と指示文へ書き足す方法では取りきれません。この層に手を入れるなら、呼べるアクションの集合を条件で絞るか、呼ぶ順序を記述で確定させるかのどちらかになります。

現場から挙がる申告の多くは、この層に集まりやすい傾向があります。データを見て答えたのか見ずに答えたのかは、営業担当者が読めば気づけるためです。

層③生成される文面そのものの揺れ

最後に残るのが、生成される文面の層です。同じサブエージェントが同じアクションを呼び、同じデータを受け取っても、そこから組み立てられる日本語は毎回少しずつ違います。上の2つの層とは性質が違い、ここで起きているのは配線や順序の問題ではありません。文章を組み立てる処理が持っている性質です。

この層に分類されたのは2件だけでした。どちらも伝えている情報は同じで、文章の順序と接続の言葉が変わっていただけです。営業担当者は「昨日と違う」と申告していましたが、営業部長が読み比べたところ、判断に必要な情報はどちらにも入っていました。

この2件は、直す対象というより、変わってよい範囲として営業へ共有すべきものでした。ここを直そうとして指示文へ表現の指定を書き足すと、指定が増えた分だけ他の指示との優先関係が読めなくなります。

3つの層のうち、上の2つは手段で固定できます。文面の層だけは性質が違い、次の章で扱う制御の届かない範囲に入ります。

Agentforceの制御が届かない3つのケース

前章では、揺れが起きる場所を3つの層に分けました。ここで先に伝えておきたいのは、この3層のすべてを固定できるわけではない点です。制御の手段を並べる前に、手段を尽くしても残る範囲を知っておくほうが、投じる労力の配分を間違えずに済みます。そこでここでは、Agentforceの制御が届かない3つのケースを整理していきます。

手段を尽くしても文面の細部は一致しないため、固定できる範囲は「何を答えるか」までであり、「どう書くか」の全部ではありません。

ケース①同じ入力でも文面の細部は一致しない

1つ目は「同じ入力でも文面の細部は一致しない」ケースです。AIが文章を組み立てる処理は、同じ入力に対して毎回同じ出力を返す性質を持っていません。参照するデータを固定し、呼ぶアクションを固定しても、最後に日本語へ変換する部分は動きます。

先ほどの専門商社でいえば、引当可能数の120個という数字は固定できます。ところが、それを「120個であれば来週中に出荷できます」と返すのか「来週中の出荷は120個までとなります」と返すのかは、そのつど変わります。数字が同じでも、文章としては別のものが返ります。

完全に同じ文面を返したい場合は、AIに文章を作らせる工程を外し、あらかじめ用意した文面へ数値を差し込む形にします。文面を一致させたいなら、制御を強めてもたどり着けません。

固定できるのは「何を答えるか」までだと考えておきましょう。「どう書くか」まで完全にそろえたいなら、その部分は生成の対象から外す判断になります。

ケース②参照するデータ側が整っていない

制御を強めても効かない2つ目のケースは、参照するデータの側が整っていない状況です。エージェントが正しいアクションを正しい順序で呼んでも、参照した先のデータが古かったり重複していたりすれば、返ってくる回答は安定しません。ここは制御の設計とは別の準備が要る場所になります。

この専門商社では、同じ代理店が表記の違う取引先レコードとして2件登録されている状態が残っていました。片方には過去の値引き条件が入力されており、もう片方には入っていません。検索がどちらを引いたかによって、回答に含まれる条件が変わります。エージェントの側からは、どちらが正しいレコードなのかを判別できません。

この状態でいくら制御を強めても、揺れは減りません。むしろ手順を固定したことで、間違ったほうのレコードを毎回確実に参照する、という結果になる場合もあります。

制御に着手する前に、参照先のレコードが1件に定まるかどうかを確認しましょう。定まらないなら、先に手を入れるのはデータの整備の側です。

ケース③想定外の言い回しを事前に列挙できない

3つ目に挙げたいのは、想定外の言い回しを事前に列挙できないという限界です。どの質問をどのサブエージェントに渡すかを細かく書き分けても、現場の担当者が実際に打ち込む言葉を、あらかじめ全部そろえておくことはできません。書き分けの精度を上げる作業には、終わりを設定できないという性質があります。

たとえばこの専門商社では、在庫に関する質問を受け持つ説明として「在庫、引当、納期に関する問い合わせ」と書いていました。ところが営業担当者は「これ、いま何個あるんでしたっけ」と打ち込みます。この文には在庫という語も納期という語も入っていません。

想定していない言い回しを増やしていく作業に終わりがない以上、現実的な進め方は、実際に打ち込まれた言葉を記録から拾って、多い順に説明へ足していくことです。

ここまでの3つのケースは、制御の手段を選んでも確実性が上がらない範囲です。ここに労力を投じても効果が出にくいと分かっているだけで、手段を選ぶときの判断が変わります。

Agentforceの出力を制御する4つの層

ここまでは、揺れがどこで起きるのかと、手を尽くしても残る範囲を見てきました。ここから先が手段の話になります。Agentforceで推論を担っているのは推論エンジン（Atlas推論エンジン）で、公式のAgent Scriptの設計ガイドは「決定論を戦略的に加える（Add determinism strategically）」という指針を挙げ、自然言語による指示と決定論的なロジックのバランスを取ることを勧めています。このように、LLM（大規模言語モデル）の推論と決定論的な処理を組み合わせる考え方は、ハイブリッド推論と呼ばれています。なお、先ほど整理した揺れの3つの層と、これから示す制御の4つの層は別の分け方であり、1対1では対応しません。そこでここでは、Agentforceの出力を制御する4つの層を、確実性と限界の両面から整理します。

制御の4つの層は確実性の高さがそれぞれ違うため、固定したい範囲の性質に合わせて、どの層で受け止めるのかを選び分けることになります。

※参考記事はこちら

層①指示文の書き方で振る舞いを寄せる

1つ目は「指示文の書き方で振る舞いを寄せる」層です。もっとも多くの担当者が最初に試す手段で、語調をそろえる、触れてほしい観点を挙げる、回答の長さを指定するといった方向づけには確かに効きます。

この層に含めて考えたいのが、プロンプトテンプレートです。Prompt Builderで作るプロンプトテンプレートは、Agentforce専用の機能ではありません。Salesforceプラットフォーム全体で使える機能で、Agentforceからはアクションとして呼び出せます。指示文の中に書式の指定を積み上げるかわりに、決まった形式の文章を作る処理をテンプレートとして切り出しておく使い方です。この位置づけを含む機能の全体像は、ほか記事「プロンプトテンプレートの位置づけ」で整理しています。

先ほどの専門商社では、商談準備メモの要約について、含めてほしい項目を指示文で4つ挙げていました。要約の観点はこれでそろい、営業部長からも読みやすくなったと言われています。一方、在庫確認の順序については、同じやり方で書き足しても通ったり通らなかったりする状態が続きました。

この層で得られるのは、出力を寄せることであって、固定することではありません。寄せたい対象なのか固定したい対象なのかを先に見分けると、指示文へ書き足すかどうかの判断がつきます。

層②処理の順序を記述で確定させる

2つ目の層では、処理の順序を記述で確定させます。エージェントの定義を記述の形で表すと、どの条件のときにどの処理へ進むのかを、推論に委ねずに決めておけます。

順序を固定できるのは、条件の判定やアクションの呼び出しが、LLMが推論を始める前に処理されるためです。公式のドキュメントには「LLMが推論を始めるのは、解決済みのプロンプトを受け取ったあとであって、Agentforceがまだ解析している最中ではない」と明記されています。つまり記述で決めた分岐は、AIの判断が入る前に確定しています。

先ほどの在庫確認でいえば、納期に関する質問が来たときに在庫の確認を通す、という順序を記述の側に置けば、会話の流れによって前後することがなくなります。指示文に「必ず」と書いたときとの違いは、要望なのか制約なのかという点にあります。

この層は、通る道を1本に絞りたい業務に向いています。反面、絞った道から外れる質問が来たときの受け止めは、別に用意しておく必要があります。

※参考記事はこちら

層③サブエージェント単位でモデルを選ぶ

3つ目は「サブエージェント単位でモデルを選ぶ」層です。Agentforceでは、組織全体で使うモデルを既定として持ちつつ、特定のエージェントやサブエージェントだけ別のモデルへ切り替えられます（2026年8月時点）。

ここで注意したいのは、モデルを変えても出力が一致するようにはならない点です。変わるのは判断の傾向と応答の速さで、同じ質問に同じ文章を返すという性質は、どのモデルを選んでも得られません。速い応答を優先したいサブエージェントと、込み入った条件を読ませたいサブエージェントで、割り当てを変えるための手段だと考えてください。

この専門商社の場合、問い合わせの一次対応は速さが求められ、商談準備メモの要約は多少時間がかかっても内容の読み取りを優先したい用途でした。2つを同じ既定のモデルで動かしていたため、片方に合わせるともう片方が合わない状態が続いています。

モデル選択は、揺れを止める手段としては使えません。用途ごとの配分を決める手段として使いましょう。適用される単位と選び分ける観点は、このあとの2つの章で詳しく扱います。

層④参照できるアクションを条件で絞る

最後の層で扱うのは、参照できるアクションを条件で絞るという手段です。サブエージェントに配線したアクションのうち、推論の材料として渡すものを限定したり、特定の条件を満たすときだけ使えるようにしたりできます。

先ほどの専門商社では、問い合わせの一次対応を担うサブエージェントに、取引先レコードの検索と商品ナレッジの検索の両方を渡していました。この2つを常に選べる状態にしておくと、質問の言い回しによってどちらを見るかが動きます。代理店名を含む質問のときだけ取引先レコードの検索を使える状態にしておけば、誤ったほうを呼ぶ余地がそもそもなくなります。

ただし絞りすぎると、必要な手段まで塞いでしまいます。この専門商社では、代理店名が省略された質問が2割ほどあり、条件を厳しくすると、その2割で業務が進まなくなる見込みでした。

呼べる手段を減らすことは、誤りを減らすと同時に、答えられない質問を増やします。両方の数を見ながら決めましょう。Agentforceの機能を全体から確認したい場合は、ほか記事「Agentforceの機能一覧」をご確認ください。

Agentforceのプロンプト制御が届かない3つの範囲

前章では制御の手段を4つの層に分けました。この4つのうち、最初に試されるのはほぼ例外なく指示文です。ところが指示文で受け止められる範囲には決まった限界があり、そこを知らないまま書き足しを続けると、時間だけが過ぎていきます。そこでここでは、Agentforceのプロンプト制御が届かない3つの範囲を具体的に示します。

指示文は推論の材料として渡るため、順序・必須の通過・遷移後の引き継ぎという3つの範囲については、書いても保証されません。

範囲①呼び出すアクションの順序

1つ目は「呼び出すアクションの順序」です。指示文に手順を番号付きで書いても、その番号どおりにアクションが呼ばれるとは決まっていません。

指示文に書かれた手順は、AIが回答を組み立てるときに読む情報として渡ります。読んだうえでその順序が妥当だと判断されれば通りますし、会話の文脈から別の順序が妥当だと判断されれば、そちらが選ばれます。番号を振ることで守られやすくはなりますが、守られるという保証にはなりません。

先ほどの専門商社では、指示文に「①取引先レコードを検索する ②在庫を確認する ③納期を回答する」と番号で書いていました。それでも急ぎを示す言葉が質問に入っていた会話では、③だけが実行されています。番号の書き方の問題ではありません。番号が制約として扱われていないという構造の問題です。

順序が業務の要件になっている場合は、指示文の外へ出す判断をしましょう。書き方を工夫する余地は、この範囲についてはほとんどありません。

範囲②必ず通すべき確認の手順

指示文で保証されない2つ目の範囲は、必ず通すべき確認の手順です。順序の話と近く見えますが、こちらで問題になるのは通る順番よりも、通ること自体を保証できるかどうかです。順番が入れ替わったのであれば結果を見れば分かりますが、通らなかったことは結果に現れません。

輸出の該非判定に関わる確認や、与信の状態を見てから金額を出すといった手順は、後回しになるだけでは済まず、通らなかった時点で手続きの不備になります。指示文に「必ず」「例外なく」と書いても、その語は強い要望として渡るだけで、通らなければ止まるという動きにはなりません。

この違いが表に出るのは、たいてい例外的な会話のときです。この専門商社でも、通常の問い合わせでは確認が通っており、急ぎの依頼や、複数の型番をまとめて聞かれた会話でだけ飛ばされていました。うまくいっている大半の会話を見ているかぎり、書けているように見えてしまいます。

通っていないことに気づくには、通った回数を数える仕組みが要ります。数え方については、後半の章で扱います。

範囲③サブエージェントをまたいだ後の指示の引き継ぎ

3つ目に挙げておきたいのが、サブエージェントをまたいだ後の指示の引き継ぎです。会話の途中で別のサブエージェントへ処理が移ると、そこまでのサブエージェントに書いていた指示文は引き継がれません。

公式のドキュメントには、遷移は一方向で前のサブエージェントへ制御が戻らないこと、そして「Agentforceは前のサブエージェントのプロンプト指示を破棄する」ことが明記されています。つまり、最初のサブエージェントに「金額は税抜で答える」と書いてあっても、遷移した先でその指定は効きません。

この専門商社では、問い合わせの一次対応から見積の相談へ会話が移る場面がありました。一次対応側にだけ書いていた表記のルールが、移った先では適用されず、税込と税抜が混ざった回答が返っています。担当者からは、同じ会話の中で書き方が変わったように見えていました。

会話をまたいで守らせたいルールは、通る可能性のあるサブエージェントすべてに置くか、そもそも遷移させない設計にするかのどちらかになります。1か所に書けば全体に効く、という前提は成り立ちません。

※参考記事はこちら

Agentforceで手順を確定させる3つの記述

前章では、指示文では保証されない3つの範囲を示しました。この3つは、いずれも記述の側へ移すことで確定させられます。対応関係としては、順序の範囲を記述①が、引き継ぎの範囲を記述②が、必ず通す手順の範囲を記述③が受け持ちます。そこでここでは、Agentforceで手順を確定させる3つの記述を、何が固定されるのかという側から整理します。

記述で固定できるのは、AIの判断が入る前に決まる部分であり、どこまでを判断の前に決めておくかが設計の中身になります。

記述①条件分岐で通る道を1本に絞る

1つ目の記述は、質問の種類に応じて処理の道を分け、それぞれの道で通る順序を1本に確定させるためのものです。納期に関する質問が来た場合は在庫の確認を通ってから回答へ進む、価格に関する質問が来た場合は取引先の条件を見てから回答へ進む、という形で、分岐の先を決め打ちにします。

この記述がない状態で起きるのが、先ほどの範囲①です。質問の種類は会話ごとに判定されるものの、判定したあとに通る道は決まっておらず、そのつど組み立てられます。急ぎを示す言葉が入っただけで順序が変わったのは、道が確定していなかったためです。

先ほどの専門商社の場合、分けるべき道は納期・価格・仕様の3本でした。3本に分けたうえで、それぞれの道で通るアクションを固定すれば、どの質問がどの道に入ったかまで記録から追えるようになります。

記述へ移したあとに確認したいのは、意図した道に入った会話がどれだけあったかです。分岐の条件が狭すぎると、どの道にも入らない会話が増えます。

記述②アクションを推論に任せず実行する

次に置くのは、特定のアクションを、呼ぶかどうかの判断を挟まずに実行させる記述です。判断を挟まないため、遷移して別のサブエージェントへ移ったあとでも、その先で実行させたい処理を確実に走らせられます。

この記述がない場合に起きるのが、範囲③で挙げた引き継ぎの問題です。前のサブエージェントに書いた指示は破棄されるため、「移った先でも必ず与信の状態を見てください」という文は効きません。移った先の側で、判断を挟まずに実行する形にしておく必要があります。

この専門商社では、見積の相談へ移った先で取引先の与信区分を取得する処理を、判断の対象から外しました。会話の流れがどうであっても取得は走るため、与信区分に触れない回答が返る場面がなくなります。

記述へ移したあとに見ておきたいのは、処理が実行されたかどうかよりも、取得した内容が回答に反映されているかどうかです。実行と反映は別の話で、実行されていても文面に出ていない場合があります。

記述③必須の手順を通るまで先へ進ませない

最後に置くのは、決めた確認を通過するまで、その先の回答へ進ませないための記述です。公式の設計パターンにも、利用者が必要なステップを通過することを保証する形が用意されています。

この記述がない場合に起きるのが、範囲②の状態です。指示文に「必ず」と書いた手順は、通らなくても会話が先へ進みます。進んだ結果として返った回答は、内容としては妥当に見えるため、確認を通っていないことに担当者が気づけません。

先ほどの専門商社では、輸出の該非判定に関わる型番について、用途と仕向地の確認を通過するまで納期の回答へ進めない形にしました。確認が取れない会話は回答へ進まず、営業担当者へ引き継がれます。回答が返らない会話が増えることになりますが、規程上は通っていない回答が出るよりも扱いやすい状態です。

記述へ移したあとは、通過した会話の割合を数えましょう。ここが100%に届かない場合、条件の書き方か、そもそも通せない業務が混ざっているかのどちらかです。

※参考記事はこちら

Agentforceのモデル選択が効く4つの単位

前章では、記述で何が固定されるのかを整理しました。ここで、制御の4つの層のうちまだ扱っていないモデル選択に戻ります。モデルを切り替えられると聞くと、組織でどれを使うかを決める話だと受け取られがちですが、実際に指定できる範囲はもう少し細かく分かれています。そこでここでは、Agentforceのモデル選択が効く4つの単位を、どこで設定するのかまで含めて整理します。

モデルの指定は組織・エージェント・サブエージェント・Agent Routerの4つの単位に分かれており、細かい単位で指定したものが上位の指定を上書きします。

単位①組織全体に適用される既定のモデル

1つ目は「組織全体に適用される既定のモデル」です。公式のドキュメントによると、既定ではAgentforceは設定（Setup）で選択された組織レベルのモデルを、すべてのエージェントとサブエージェントに使います（2026年8月時点）。

ここで押さえておきたいのは、この単位だけが管理画面での選択になっている点です。ほかの3つの単位はエージェントの定義を記述する側で指定するため、担当者も作業の場所も変わります。「モデル選択はどこで設定するのか」という質問に対しては、組織の既定は設定画面、個別の上書きは記述の側、というのが答えになります。

先ほどの専門商社では、稼働開始からこの組織レベルの既定だけを使っており、個別の上書きは一度も設定していませんでした。設定画面で選んだ1つが、2つのエージェントの両方にそのまま効いている状態です。

まずは自社が組織レベルで何を選んでいるのかを確認しましょう。ここを把握しないまま個別の上書きを増やすと、どのサブエージェントが何で動いているのかを追えなくなります。

単位②エージェント単位で上書きするモデル

組織の既定の次に来るのが、エージェント単位での上書きです。特定のエージェントについてだけ、組織の既定と違うモデルを使いたい場合に、エージェントの定義の側で指定します。

この単位が向くのは、エージェントごとに求められる性質がはっきり分かれている場合です。社内の担当者だけが使うエージェントと、社外の問い合わせを受けるエージェントでは、応答の速さに対する要求も、込み入った条件を読む必要の度合いも変わります。エージェントの中に含まれるサブエージェントが同じ傾向でそろっているなら、この単位で足ります。

この専門商社の場合、問い合わせの一次対応と商談準備メモの要約は、そもそも別のエージェントとして分けていました。分けてある以上、エージェント単位での指定でも用途ごとの配分は実現できます。

まずエージェント単位で試し、それでも足りないときに次の単位へ下ろしましょう。指定の場所が増えるほど、確認すべき箇所も増えていきます。

単位③サブエージェント単位で上書きするモデル

3つ目は「サブエージェント単位で上書きするモデル」です。1つのエージェントの中でも、サブエージェントごとに別のモデルを指定できます。公式のドキュメントには、サブエージェント固有のモデルはエージェント固有のモデルより優先される、と明記されています。

この単位が要るのは、1つのエージェントの中に性質の違う業務が同居している場合です。たとえば問い合わせを受けるエージェントの中に、定型的な照会を返すサブエージェントと、複数の条件を突き合わせて判断するサブエージェントが並んでいるとします。前者には速さを、後者には読み取りの力を割り当てたいという状況です。

この専門商社では、問い合わせの一次対応エージェントの中に、在庫と納期の照会、仕様の確認、輸出の該非判定に関わる確認という3つのサブエージェントを置いていました。最後の1つだけは条件の突き合わせが多く、ほかと同じ配分では合いません。

どの単位で指定するかは、業務の性質がどの粒度で分かれているかで決めましょう。粒度が合っていない単位で指定しても、どちらかの業務に無理が出ます。

単位④振り分けを担うAgent Routerのモデル

4つ目に挙げておきたいのが、振り分けを担うAgent Routerのモデルです。入ってきた質問をどのサブエージェントへ渡すかを決める処理についても、モデルを指定できます（2026年8月時点）。

この単位が効くのは、先に整理した揺れの層のうち、サブエージェントの選択で起きているものです。先ほどの専門商社の12件でいえば、価格の質問が要約側のサブエージェントに入っていた3件が該当します。回答の中身をどれだけ直しても、入る先が動いているかぎり症状は変わりません。

ただし、ここを切り替えれば振り分けが固定されるという話ではありません。振り分けは推論で行われるため、傾向は変わっても、同じ質問が必ず同じサブエージェントに入るという保証は得られません。振り分けの精度を上げたい場合は、モデルの切り替えと並行して、各サブエージェントが受け持つ範囲の説明を書き分けます。

以上の4つが、モデルの指定が効く単位です。なお、モデルを切り替える前提となる課金の全体像を先に押さえたい場合は、ほか記事「Agentforce料金・ライセンス」をご参照ください。

※参考記事はこちら

Agentforceのモデルを選び分ける3つの観点

前章では、モデルの指定が効く4つの単位を整理しました。単位が分かると、次に出てくるのは、ではどのモデルを割り当てるのかという問いです。ここで気をつけたいのは、性能の高いモデルを選べば揺れが止まるという理解になりやすい点で、実際には別の判断になります。そこでここでは、Agentforceのモデルを選び分ける3つの観点を整理していきます。

2026年8月時点で公式ドキュメントに記載を確認できたモデルは、次のとおりです。ドキュメントに載っている範囲を書き出したものであり、これが選択できるすべてだという意味ではありません。

モデルの選び分けで出力が一致するようにはならず、ここで決まるのは、応答の速さと判断の深さをサブエージェントごとにどう配分するかです。

観点①応答の速さをどこまで優先するか

1つ目は「応答の速さをどこまで優先するか」です。同じ質問でも、返ってくるまでの時間が業務に効く用途と、多少待っても構わない用途があります。ここを一律にそろえてしまうと、待てない用途の担当者から先に使わなくなります。速さは精度と違い、担当者が我慢して使い続けてくれる種類の不満になりません。

この差が出やすいのは、担当者が相手を待たせている場面です。先ほどの専門商社では、代理店から電話を受けながら在庫を照会する使い方があり、返答が遅いと担当者は画面を閉じて自分でレコードを開きます。数秒の差が、使われるか使われないかを分けている状態でした。

一方、商談準備メモの要約は前日の夜や朝の移動中に読むもので、数秒の差は業務に影響しません。この2つに同じ配分を当てる理由はありません。

速さを優先する用途では、待たされた担当者がどれだけ自力の操作へ戻ったかを見ましょう。使われなくなる理由が精度よりも速さにある場合、モデルの割り当てで改善できる余地があります。

観点②複雑な判断をどこまで任せるか

次に問うのは、複雑な判断をどこまで任せるかという点です。ここでいう複雑さとは、参照する条件の数と、条件同士の突き合わせの多さを指します。業務の名前が同じでも、突き合わせる条件の数が違えば、モデルに求めるものは変わります。同じ問い合わせ対応という括りの中に、両方が混ざっている場合が多くあります。

先ほどの専門商社の輸出の該非判定に関わる確認では、型番の該当区分、用途、仕向地、取引先の登録状況という4つを突き合わせます。突き合わせの数が増えるほど、判断の途中で条件が1つ落ちる場面が出やすくなります。定型的な在庫照会とは、求めるものが違います。

ただし、この観点で選び分けても、条件の落ちがなくなるわけではありません。落ちにくくなるだけです。落としてはいけない条件があるなら、その確認は記述の側で通過を保証する対象になります。

任せる判断の複雑さは、突き合わせる条件の数で数えてみましょう。3つを超えるあたりから、モデルの割り当てだけで受け止めるのが難しくなります。

観点③検証済みのモデルにそろえるか

3つ目に問うのが、検証済みのモデルにそろえるかどうかです。公式のドキュメントでは、GPT 4.1・Claude Haiku 4.5・Gemini 3.5 Flash の3つについて、エージェントで十分にテストされているため推奨する、という趣旨の記載があります（2026年8月時点）。

ここで判断が分かれるのは、推奨されているものの中から選ぶのか、それ以外も含めて比較するのかという点です。自社で比較の検証を続けられる体制があるなら選択肢は広がりますが、検証には後半の章で扱う負担がついてきます。担当者が1名で兼任している状況では、推奨されている範囲から選び、切り替えの回数を減らすほうが現実的です。

なお本記事では、モデルごとの応答時間やベンチマークの数値は扱いません。公式のドキュメントに記載がなく、当社でも測定していないためです。数値のない比較で決められるのは、速さと判断の深さのどちらを優先するかという配分までになります。

以上の3つが、モデルを選び分けるときに問う観点です。どれを選んでも同じ出力にはならないという前提を置いたうえで、用途ごとの配分を決めていきましょう。

※参考記事はこちら

Agentforceの検索が日本語で空振りする3つの原因

前章まではモデルの選び方を扱ってきました。ここからは制御の手段とは別に、実装の現場でつまずきやすい箇所を1つ取り上げます。エージェントにレコードを検索させる処理は、指示文もアクションの配線も間違っていないのに、日本語で組んだときだけ結果が返らない場面があります。そこでここでは、Agentforceの検索が日本語で空振りする3つの原因を、当社が実装して確かめた範囲で整理します。

レコード検索が空振りしているとき、疑うべきなのは指示文の精度よりも、検索へ渡している文字列がレコードの表記と一致しているかどうかです。

原因①英語の自然文で渡したときに結果が安定したから

まず触れておきたいのは、検索の条件を日本語の文章で組んだ場合と、英語の自然文で組んだ場合とで、返ってくる結果が違った点です。当社が実装して確かめた範囲では、日本語で条件を書いた検索は該当なしで返る場面が多く、同じ条件を英語の自然文へ書き直したところ、結果が返るようになりました。

ただし、これがAgentforceの仕様としてそう定められているのかどうかは、公式のドキュメントで確認できていません。2026年8月時点で該当するヘルプページの本文を取得できず、入力する言語についての記述を確かめられなかったためです。ここで書けるのは、実装して観測した挙動の範囲までになります。

現場で困るのは、この空振りが失敗として見えない点です。検索が空で返っても処理は止まらず、エージェントは持っている一般的な知識で回答を組み立てます。先ほどの専門商社で、代理店名で検索したはずの質問に一般的な納期の案内が返っていた3件も、これと同じ形でした。

検索が当たらないと感じたときは、まず条件をどの言語で組んでいるかを確かめましょう。指示文の書き足しでは動かない箇所です。

原因②英訳を任せると固有名詞まで英語に置き換わったから

英語の自然文にすればよいと分かると、次に取りたくなるのは、日本語の条件をそのまま英訳させる方法です。ところが、ここで別の問題が起きました。エージェントに英訳を任せると、文の構造だけでなく、検索したい固有名詞まで英語に置き換わることがあります。

実際に観測したのは、`合同会社クロスコム` という取引先名が `Crosscom LLC` と訳された例です。人が読めば同じ会社を指していると分かりますが、検索の処理は文字列が一致するかどうかを見ています。訳された時点で、探している文字列は元の社名と別のものに変わっています。

置き換わり方は毎回同じとはかぎりません。`Crosscom LLC` と訳される場面もあれば、`Crosscom` だけになる場面もあり、どう訳されるかを事前に決めておけないため、同じ検索を2回試すと、片方だけ当たるという状態が生まれます。

英訳を任せる場合は、何が訳されるのかを一度確かめておきましょう。社名や型番のような登録済みの値を含まない質問であれば、英訳を任せても検索の結果は変わりません。

原因③置き換わった表記がレコードの表記と一致しなかったから

置き換わった固有名詞がなぜ空振りにつながるのかというと、Salesforceに登録されている取引先名が、日本語の表記のままだからです。取引先名の項目に `合同会社クロスコム` と入っているところへ `Crosscom LLC` という文字列で問い合わせても、一致するレコードは見つかりません。

先ほどの専門商社でも、同じことが起きていました。代理店の登録名は日本語の商号で入力されており、英訳された名称で検索した会話では、すべて該当なしで返っています。データが登録されていないわけではありません。登録されているものと違う文字列で探していただけです。

さらに厄介なのは、この状態でも回答は返る点です。該当なしという事実は文面に出ず、一般的な案内文だけが返るため、営業担当者は検索が動かなかったことに気づけません。担当者からは、単に回答の質が低い日として記憶されます。

3つの原因はつながっています。日本語で組むと当たらないため英訳し、英訳すると固有名詞が変わり、変わった表記はレコードと一致しない、という順序です。次の章では、この連鎖をどこで止めるかを扱います。

Agentforceの検索で空振りを減らした3つの指示

前章では、レコード検索が空振りする原因を3つ挙げました。原因が3つ連なっている以上、対処もどこか1か所を直せば済むというものではありません。指示の出し方と、空振りしたときの振る舞いの両方を決めておく必要があります。そこでここでは、Agentforceの検索で空振りを減らした3つの指示を整理します。

英語にする対象を文の構造だけに限り、固有名詞は原文のまま渡すと明示しておくと、レコードの表記と突き合わせられる文字列が検索へ渡ります。

指示①英語にするのは文構造だけに限る

1つ目は「英語にするのは文構造だけに限る」です。検索の条件をどう組むかを指示するときに、英語にする対象を文の構造に限定し、値として渡す文字列は変換の対象から外します。

では、なぜ対象を分ける必要があるのでしょうか。それは、英訳という言葉に、文を訳すことと、その中の語を訳すことの両方が含まれてしまうからです。「英語で検索してください」とだけ書けば、文の中にある社名も品名も訳す対象として扱われます。指示の書き方としては、訳す範囲をこちらで区切ります。

先ほどの専門商社では、代理店名を条件に含む検索について、条件の組み立ては英語で行い、代理店名は入力された文字列をそのまま使う、という書き分けをしました。書き分けたあと、該当なしで返る会話の件数を同じ数え方で追いかけています。

なお、この書き分けで空振りが必ずなくなると書くことはできません。当社が観測した範囲では空振りの件数が減りましたが、的中率のような数値は測定しておらず、そこまでの効果は確かめられていません。

指示②固有名詞は原文のまま残すと明示する

訳す範囲を区切っただけでは、まだ足りませんでした。何を訳さずに残すのかを名指しで書いておくほうが確実で、これが2つ目の指示にあたります。範囲の区切りは方針として読まれるのに対して、名指しの指示は対象が特定されるぶん、そのとおりに扱われる場面が増えました。

対象になるのは、取引先名・品名・型番・部署名といった、Salesforce側に登録されている値です。これらはレコードに入っている文字列と一致することに意味があるため、読みやすさのために整えられては困ります。指示の中で「これらは翻訳や整形の対象にしない」と明示します。

置き換わりやすいのは、`合同会社クロスコム` のように法人格を示す語を含む社名です。合同会社という部分は一般的な語として訳せてしまうため、社名全体が `Crosscom LLC` という別の文字列になり、日本語の商号のまま登録されている取引先レコードとは一致しなくなります。名指しする対象を選ぶときは、こうした訳せる語を含む表記が入っているかどうかを目安にできます。

明示したあとに確認したいのは、実際に渡っている文字列です。会話の記録から検索の条件を1件ずつ見て、社名が原文のまま渡っているかを確かめましょう。

指示③結果が空だったときの動きを決める

最後に決めておきたいのが、結果が空だったときの動きです。空振りを完全になくすことはできないため、空で返ったときにどう振る舞うのかを、あらかじめ決めておきます。

決めておく選択肢は3つあります。

①見つからないと伝える・・・該当するレコードがなかった事実を回答に含めます ②担当者へ引き継ぐ・・・回答を作らずに、営業担当者へ会話を渡します ③条件を変えて再検索する・・・表記のゆれを想定した別の条件でもう一度探します

先ほどの専門商社では、代理店からの問い合わせでは①と②を組み合わせ、社内の営業担当者からの照会では③を許容する形にしました。社外に出る回答で一般論を補われるのが、いちばん困る状態だったためです。

決めておくと、空振りが記録に残ります。残っていれば数えられますし、数えられれば原因を追えます。何も決めていないと、空振りは一般的な案内文の中に隠れたままになります。

※この表の内容は、当社が実装して観測した傾向をまとめたものであり、公式ドキュメントで確認できた仕様ではありません。的中率などの数値は測定していないため記載していません（2026年8月時点）。

Agentforceの制御を指示文から移す3つの場面

前章では、レコード検索の空振りを減らすための指示を整理しました。ここまで読むと、どの手段をいつ使うのかという判断が残ります。指示文の調整を続けるか、記述の側へ移すかは、実際には理屈より先に、直らない症状として現れる場合がほとんどです。そこでここでは、Agentforceの制御を指示文から移す判断につながった3つの場面を振り返ります。

指示文の調整から記述による制御へ切り替える判断は、直らない症状が3つの形のどれかで現れた時点で下すことになります。

場面①確認の手順が会話の途中で飛ばされた

1つ目は「確認の手順が会話の途中で飛ばされた」場面でした。指示文には「必ず在庫を確認してから回答する」と書いてあり、通常の問い合わせでは確認が通っていたものの、急ぎを示す言葉が入った会話や、複数の型番をまとめて聞かれた会話では、確認を挟まないまま納期が返っています。

このとき担当者が取りやすい手は、「必ず」をもっと強い表現に書き換えるか、確認しない場合の禁止を追記することです。ところがどちらも、指示文の中で要望を強めているだけで、通らなければ止まるという動きにはなりません。強めた表現が通った会話と通らなかった会話が混ざり、何が効いたのかも読めなくなります。

先に触れた公式の設計パターンのように、指示文で「お願いする」場合と、記述で「通らないと先へ進めない」ようにする場合とでは、保証の性質が違います。この違いに気づいた時点が、手段を切り替える分岐点でした。

飛ばされてはいけない確認があるなら、指示文の表現を強める作業はいったん止めましょう。強めても保証にはならないと分かっていれば、時間の使い先を変えられます。

場面②同じ指示文で結果が日によって変わった

次に挙げるのは、同じ指示文のまま結果が日によって変わった場面でした。指示文に手を入れていない期間にも症状が出たという点で、前の場面とは性格が違います。

変わり方として現れるのは、手順が通るか通らないかという形です。代理店から納期を聞かれたときに在庫を確認してから答えるという同じ手順が、ある日は確認を挟んで回答され、別の日は確認を挟まないまま納期だけが返ります。担当者の目には日ごとの当たり外れとしか映らないため、通らなかった会話だけを取り出して並べないかぎり、何が違っていたのかは見えてきません。

この場面の意味は、切り分けとして使える点にあります。指示文に手を入れていないのに結果が変わったのであれば、変わった理由は指示文の書き方の側にはありません。書き方が原因なら、書き方を変えていない期間の結果は変わらないはずだからです。

先ほどの専門商社でも、同じ判断をした場面がありました。営業企画の担当者が指示文を触っていない週に、在庫確認を通らなかった会話が2件出ています。この2件を見た時点で、書き方をさらに調整する方向はいったん外し、記述で確定させる方向へ検討を移しました。

指示文を触っていない期間の結果を、まず確かめてみましょう。ここが揺れているなら、書き方の調整に時間を使う理由がなくなります。

場面③指示文を足すほど別の手順が崩れた

最後の場面は、指示文を足すほど別の手順が崩れたというものでした。在庫確認を通すための一文を足したところ、今度は取引先の条件を見てから答えるという別の手順が抜けるようになった、という形で現れます。

こうなるのは、指示文に書いた内容がすべて推論の材料としてまとめて渡るためです。材料が増えるほど、どの指示が優先されるのかは読みにくくなります。1つを強めれば、相対的に別の1つが弱くなる、という関係が生まれます。

一方で、条件の判定やアクションの明示的な実行は、先に触れたとおりLLMが推論を始める前に処理されるため、記述で決めた部分は推論の材料になる前に確定しています。推論に渡す前に決まっていることと、推論に委ねることを分けるという判断が、指示文の追加を止める分岐点になりました。

指示文が長くなってきたと感じたら、そこに書いてある内容を2つに仕分けてみましょう。推論に渡す前に決まっていてよいものが混ざっているなら、その分は外へ出せます。

※参考記事はこちら

Agentforceの出力を安定させる4ステップ

ここまで、制御の手段と、手段を切り替える判断の分岐点を整理してきました。とはいえ、実際に着手するとなると、どこから手をつけるのかという順序が要ります。順序を間違えると、固定してはいけない範囲まで固定してしまい、業務の側が止まります。そこでここでは、Agentforceの出力を安定させる4つのステップを、誰が何をするのかまで含めて解説します。

着手の順序は、揺れている層の特定から始めて業務側の線引きへ進み、手段の選択は3番目に置きます。

ステップ①揺れている層を切り分ける

最初にやることは、現場から挙がっている申告を集めて、揺れがどの層で起きているのかを1件ずつ確認する作業です。先ほどの専門商社では、営業企画の担当者が1週間分の申告12件をまとめ、それぞれがどのサブエージェントに入った会話だったかを実行の記録と突き合わせました。ここは1人で完結する工程で、情シスの手も業務部門の判断も要りません。

切り分けた結果は、サブエージェントの選択で3件、アクションの呼び出しで7件、文面の違いで2件でした。7件が集まったアクションの層が、最初に手を入れる場所になります。

この作業をせずに着手すると、申告の多い順に対処することになりがちです。ところが申告の多さは、その層の重大さとは一致しません。文面の違いは気づかれやすいため申告に上がりやすく、参照先の間違いは気づかれにくいため上がりにくい、という差があります。

1週間分でよいので、記録と突き合わせて分けてみましょう。ここで手を入れる場所が決まります。

ステップ②固定する範囲を業務側で決める

層が分かったら、次は固定する範囲を業務の側で決めます。この専門商社では、営業部長と営業企画の担当者が同じ場で、金額と在庫に関わる回答は固定する、商談メモの要約は言い回しが変わってよい、という線を引きました。情シスの兼任担当者も同席していますが、決める側には入りません。

この工程だけは、設定の話が一切出てきません。決めるのは、誤った回答が社外に出て取り消せなくなるかどうか、そして誤りに気づける人が間に立っているかどうかの2点だけです。どの機能で実現するかは、この時点では考えません。

設定の話を先に始めてしまうと、実現しやすい範囲から固定することになります。実現しやすさと、固定すべきかどうかは別の話です。決める場に情シスの担当者を呼ぶのは、決まったあとの実現可能性を確かめるためだと位置づけましょう。

線を引いたら、その内容を1枚の文書に残してください。あとから見返せる形になっていないと、次の工程で判断の理由が失われます。

ステップ③固定する手段を層の中から選ぶ

線が引けたら、そのそれぞれに手段を割り当てます。この専門商社では、情シスの兼任担当者が、引かれた線ごとに、指示文で寄せるのか、記述で順序を確定させるのか、参照できるアクションを絞るのかを決めていきました。この工程で作業台になるのが、先に示した制御手段の比較表です。

割り当ての結果、在庫と納期の回答は記述による順序の確定と参照範囲の絞り込みの両方を使い、商談メモの要約は指示文だけで寄せる形になりました。モデルの切り替えは、この時点では使っていません。切り替えると検証の回数が増えるため、記述で足りるかを先に確かめる順序にしています。

ここで注意したいのは、1つの線に対して複数の手段を同時に当てないことです。同時に当てると、どちらが効いたのかを確かめられなくなります。順に当てて、そのつど確認するほうが結果的に早く進みます。

手段の割り当ては、確実性の高いものから順に検討しましょう。確実性の低い手段で足りるかどうかは、当ててみないと分かりません。

ステップ④残した揺れの許容範囲を合意する

最後に、固定しなかった範囲について、変わってよい部分を営業現場へ伝えます。この専門商社では、営業企画の担当者が1枚の資料を作り、ここは毎回同じ、ここは言い回しが変わる、という区分を営業60名へ共有しました。

この工程が要るのは、変わってよい範囲を伝えていないと、表現が変わっただけの回答まで誤りとして申告されるためです。切り分けの工程で見たとおり、12件のうち2件は伝えている情報が同じでした。この2件が申告に混ざっているかぎり、申告の件数を数えても状態が読めません。

伝える相手は営業担当者だけではありません。営業部長には「固定した範囲は毎回同じであること」を、情シスの担当者には「揺れてよい範囲には手を入れないこと」を、それぞれ伝えておきます。同じ資料でも、読む人によって知りたい点が違います。

以上が、Agentforceの出力を安定させる4つのステップでした。ここまで進めると、次に出てくるのは、この進め方にどれだけの負担がかかるのかという話になります。

Agentforceの制御設計で増える3つの負担

前章では、出力を安定させる手順を4つのステップに分けました。ここで正直に書いておきたいのは、この進め方を選ぶと増えるものがある点です。増えるのは主にライセンスの費用ではありません。確かめる回数と業務側の稼働で、それぞれ現れ方が違います。そこでここでは、Agentforceの制御設計で増える3つの負担を整理します。

制御を強めるほど、固定できたかどうかを確かめる実行の回数が増えるため、負担は費用の項目よりも先に検証の反復として現れます。

負担①揺れを切り分けるために繰り返す検証の消費

1つ目は「揺れを切り分けるために繰り返す検証の消費」です。エージェントの設定や構成の作業では、クレジットは消費されません。一方で、Agent Builderでのプレビュー実行、プロンプトビルダーでのプレビュー、テストセンターやテストスイートでの実行、テストケースの生成と評価、プレビュー時のデータ検索、検索インデックスを作るときのデータ処理では消費されます。

ここで効いてくるのは、制御の設計が「直して終わり」の作業ではない点です。揺れている層を切り分ける工程も、固定できたかどうかを確かめる工程も、どちらも実際に動かしてみないと分かりません。制御を強めるほど、確かめる回数は増える方向に動きます。

先ほどの専門商社では、在庫確認の手順を記述へ移したあと、通常の問い合わせ・急ぎの依頼・複数型番の質問という3つのパターンで、それぞれ数回ずつプレビューを回しています。1回あたりは小さくても、パターンの数だけ掛かります。

消費が発生する場面については、ほか記事「エージェントの構築作業やテスト実行でクレジットは消費されるのか？」で整理しています。着手前に、確かめる回数を見込んでおきましょう。

負担②選んだモデルによって変わる消費の乗数

次に見ておきたいのが、構成と環境によって変わる消費の乗数です。ここは誤解が生まれやすいところなので、先に範囲を限定しておきます。乗数を動かすのは、Salesforceが管理するLLMを使うのか独自のLLMを持ち込むのかという構成の違いと、本番かSandboxかという環境の違いです。

2026年8月時点で確認できている値は、次のとおりです。

①環境による差・・・標準アクションとカスタムアクションの乗数は、本番が20、Sandboxが16です ②構成による差・・・Salesforceが管理するLLMを使う構成では4または16、独自のLLM（BYOLLM）を使う構成では2です

②は4と16という2つの値であり、その間の値を取るわけではありません。また、どのモデルがどちらに当たるのかは、当社が確認できた範囲では公開されていません。前章で扱ったモデルの選び分けと、この乗数を直接結びつけて計算することはできない、と考えてください。

消費はトークン数に基づいており、入力したテキストとモデルが生成した応答の双方が対象になります。乗数の詳細は、ほか記事「【Agentforce Q＆A】エージェント実行によるクレジット消費を抑えるコツは？」で扱っています。なお本記事では金額への換算は行いません。単価と費用の全体像は、ほか記事「Agentforce料金・ライセンス」をご確認ください。

負担③固定した範囲を業務側で維持する稼働

3つ目に増えるのが、固定した範囲を業務側で維持する稼働です。一度固定した内容は、放置すると業務の実態と合わなくなります。金額の考え方が変わり、在庫の引当ルールが変わり、社内規程が改定されれば、固定した内容も直す対象になります。

この専門商社の場合、輸出の該非判定に関わる確認の項目は、社内規程の改定に合わせて見直す必要があります。誰がいつ確認するのかを決めておかないと、規程だけが更新され、エージェント側は古い順序を毎回確実に通り続けるという状態が生まれます。固定したことが、そのまま古い手順の維持に変わります。

なお、この維持にどれだけの時間がかかるのかについては、数値を出せる根拠を当社は持っていません。書けるのは、確認の担当と頻度を決める作業が増える方向に働く、というところまでです。確認の頻度は、業務の変更の起きやすさに合わせて自社で決める前提になります。

※乗数を決めるのは環境（本番／Sandbox）と構成（Salesforceが管理するLLM／独自のLLM）であり、打ち手の側ではありません（2026年8月時点）。

最後に1つ書き添えておきます。先に整理した制御の届かない3つのケースに該当する範囲は、この負担を払っても確実性が上がりません。払う価値のある固定と、払っても戻ってこない固定があると分かったうえで、対象を選びましょう。

Agentforceの出力が安定したかを見る3つの記録

前章では、制御を強めると何が増えるのかを整理しました。負担を払う以上、払った結果が出ているのかを、記録の形で言えるようにしておきたいところです。ここで扱うのは、固定した範囲が実際に固定されているかを確かめるための記録に限ります。エージェント全体が健全に動いているかを見る指標は、別の話になります。そこでここでは、Agentforceの出力が安定したかを見る3つの記録を、数え方まで含めて整理します。

記録の目的は改善率を出すことにはなく、固定したはずの範囲が本当に毎回通っているかを、割合と件数で言い切れる状態にすることです。

記録①必須の手順を通過したセッションの割合

1つ目は「必須の手順を通過したセッションの割合」です。数え方は、固定したい手順を1つ決め、その手順を通ったセッションの数を、対象となるセッションの数で割ります。単位は割合になります。

ここで気をつけたいのが、分母の取り方です。全セッションを分母に置くと、その手順とまったく関係のない会話まで含まれてしまい、割合が実態から離れます。先ほどの専門商社でいえば、在庫確認の通過率を見るときの分母は、納期に関する質問が入ったセッションだけです。商談準備メモの要約は分母から外します。

この記録で分かるのは、記述で固定した範囲が実際に固定されているかどうかです。手順を記述へ移したのに割合が100%に届かないなら、分岐の条件が想定と違う会話を拾っているか、そもそも通せない業務が混ざっているかのどちらかになります。

先ほどの専門商社では、営業から挙がっていた「確認してほしい手順を飛ばして答える」という指摘に対して、飛ばされたのが週に何件で、どの型の質問だったのかを件数で言える状態になりました。指摘を受けても、どこを直すのかを担当者が自分で決められます。

記録②レコード検索が空振りしたセッションの件数

次に数えるのは、レコード検索が空振りしたセッションの件数です。数え方は、検索の結果が空で返った回数をそのまま数えます。単位は件で、指示の書き方を変える前と後で、同じ数え方を続けることが条件になります。

注意したいのは、空振りの中に「そもそもデータが存在しない」場合が混ざる点です。存在しないレコードを探して空で返るのは、検索の書き方の問題ではありません。数えるのは、存在するはずのレコードで空振りした件数に絞ります。絞るには、空で返った会話の条件を1件ずつ見て、その条件でレコードを手作業で探し直す確認が要ります。

この記録で分かるのは、固有名詞の置き換えによる空振りが実際に減っているかどうかです。指示の書き方を変えたのに件数が変わらないなら、原因は別のところにあります。

この専門商社では、営業から「見てほしいデータを見ずに答える」と言われていた症状について、検索が空で返っていたのか、そもそも呼ばれていなかったのかを分けて数え始めました。空で返っていたのか呼ばれていなかったのかが分かれば、直す先は指示の書き方かアクションの配線かに絞られます。

記録③現場から回答の誤りが申告された件数

3つ目に置くのが、現場から回答の誤りが申告された件数です。営業担当者や問い合わせ担当から「答えが違う」と申告された件数を数えます。単位は件になります。

この記録には、申告のしやすさで数字が動くという性質があります。申告の窓口が決まっていない期間の件数と、決めたあとの件数を並べても比較になりません。数え始める前に、どこへ何を申告するのかという手順を先に決め、あわせて変わってよい範囲を現場へ伝えておきましょう。

先ほどの専門商社では、稼働から半年たった時点で「同じことを聞いても答えが違う」と言われている状態でした。いまは、申告された内容を層ごとに分けたうえで、営業に対して「ここは毎回同じ、ここは言い回しが変わる」と説明できる状態になっています。到達した数字を示せるようになったわけではありません。何が起きているのかを件数で説明できるようになった、という段階です。

なお、記録を始める前の状態が分からない場合は、先に1か月数えてから固定に着手しましょう。過去に遡って数字を作ることはできません。

Agentforceの制御設計を内製しにくい3つの条件

ここまで、制御の設計から記録の取り方までを一通り整理してきました。とはいえ、この一連の作業を自社だけで進められるかどうかは、体制によって分かれます。判断のもとになるのは担当者の人数よりも、決めるために必要な知識と基準が社内にそろっているかどうかです。そこでここでは、Agentforceの制御設計を内製しにくい3つの条件を挙げます。

内製が難しくなるのは作業量が多いからというより、固定する範囲を決める判断と、その副作用を評価する基準が社内で用意できないときです。

条件①固定する範囲を判断できる業務知識の持ち主がいない

1つ目は「固定する範囲を判断できる業務知識の持ち主がいない」条件です。どの回答を固定すべきかは、その業務で誤りが出たときに何が起きるかを知っている人にしか決められません。この判断は設定の知識では代わりが利かない部分で、外から短期間で補うことも簡単ではないでしょう。

先ほどの専門商社では、営業部長が「金額と在庫は固定する」と即断できました。過去に納期の回答を取り消して代理店との関係が悪くなった経験があるためです。ところが、この判断ができる人が退職や異動でいなくなると、同じ線を引き直せる人が社内に残りません。

困るのは、この不在が作業の場面では見えない点です。設定の作業は情シスの担当者が進められるため、決める人がいなくても手は動きます。線を引かないまま実現しやすい範囲から固定していく、という進み方になります。

固定の対象を挙げる会議で、誤りが出たときの影響を具体的に語れる人がいるかを確かめましょう。いなければ、そこが最初に埋める場所です。

条件②揺れが再現する条件を切り出せる担当がいない

次に挙げるのは、揺れが再現する条件を切り出せる担当がいないという状況です。制御に着手するには、どんな入力のときに揺れるのかを切り出す作業が要りますが、これは実行の記録を読み慣れていないと進みません。

先ほどの12件を層ごとに分けた作業がこれにあたります。申告された文面を読むだけでは、サブエージェントの選択で起きたのか、アクションの呼び出しで起きたのかを区別できません。会話ごとの記録を開いて、どのサブエージェントが受けて何を呼んだのかを1件ずつ確認する必要があります。

この作業は難しいというより、時間がまとまって取れないと進まない性質のものです。情シスを1名で兼任している体制では、日々の運用の合間に12件を追う時間を確保できず、切り分けの前で止まり、手段の議論に進めないまま、指示文の調整だけが残ります。

自社で進める場合は、この切り分けに充てる時間を先に確保しましょう。確保できないなら、外部の支援を検討する対象になります。会社の選び方は、ほか記事「Agentforce導入支援会社の選び方」で解説しています。

条件③固定した結果の副作用を評価する基準がない

3つ目に挙げておきたいのが、固定した結果の副作用を評価する基準がないという状況です。固定は必ず副作用を伴います。参照できるアクションを絞れば誤った呼び出しは減るかわりに答えられない質問が増えますし、必須の手順を通過するまで進ませなければ、確認が取れない会話は回答なしで終わります。

先ほどの専門商社では、代理店名が省略された質問が2割ほどありました。この2割で回答が返らなくなることを許容するのかどうかは、設定の判断ではありません。業務の側で決めることです。許容できないなら、絞る条件を緩めるか、返らなかった会話を担当者へ引き継ぐ仕組みを別に用意します。

この判断に必要なのは、誤った回答が出ることと、回答が返らないことのどちらが自社にとって重いかという基準です。基準がないまま固定を進めると、業務が止まった時点で設定を戻し、元の揺れた状態へ帰るという往復が起きます。

制御設計を担う人に求める知識の水準を測りたい場合は、ほか記事「Agentforceスペシャリスト資格」も目安になります。3つの条件のうち2つ以上に当てはまるなら、設計の部分だけでも外部と進める判断が現実的です。当社の「Agentforce導入定着支援」でも、固定する範囲の線引きから記録の設計までをご一緒しています。

【一問一答】Agentforceの推論制御に関するよくある質問

ここまで、出力の制御について設計から記録までを整理してきました。最後に、個別の前提について質問をいただくことが多い点をまとめておきます。そこでここでは、Agentforceの推論制御に関するよくある質問に答えていきます。

モデル選択と推論制御の質問は、どこで設定するのかという操作の話と、どこまで保証されるのかという性質の話に分かれます。

質問①Agentforceのモデル選択はどこで設定するのか

組織全体で使う既定のモデルは、設定（Setup）の画面で選択します。特定のエージェントやサブエージェント、そして振り分けを担うAgent Routerについて別のモデルを使いたい場合は、エージェントの定義を記述する側で指定します（2026年8月時点）。設定画面だけを探しても個別の上書きは見つからないため、どちらの単位で切り替えたいのかを先に決めてください。

質問②Agentforceのハイブリッド推論とは何を指すのか

LLMによる推論と、条件分岐やアクションの実行といった決定論的な処理を組み合わせる考え方を指します。推論を担う部分は推論エンジン（Atlas推論エンジン）と呼ばれており、決定論的に処理される部分は、推論が始まる前に確定します。柔軟さと確実性のどちらか一方を選ぶ話ではありません。業務ごとに配分を決めるための考え方だと捉えてください。

質問③Agentforceで生成の温度などを調整できるのか

2026年8月時点で当社が確認した公式ドキュメントの範囲では、温度やtop-p、トークンの上限といった生成のパラメータを調整する設定は見つかりませんでした。確認できたのは、条件分岐、アクションの明示的な実行、推論に渡すツールの限定、ツールの条件付き提示、そしてモデルの指定です。振れ幅を数値で絞る方法は用意されておらず、判断の入る余地を構造で減らす方法が用意されている、という整理になります。

質問④Agentforceのプロンプトテンプレートは制御に使えるのか

出力の形式をそろえる用途では使えます。Prompt Builderで作るプロンプトテンプレートは、Salesforceプラットフォーム全体で使える機能であり、Agentforceからはアクションとして呼び出せる位置づけです。ただし、テンプレートを用意しても、それが呼ばれる順序や、必ず呼ばれることまでは保証されません。順序と必須の通過は、記述による制御の担当になります。

質問⑤Agentforceのモデルは全て同じものにそろえるべきか

用途の性質がそろっているなら、同じもので構いません。分ける理由になるのは、応答の速さを優先したいサブエージェントと、条件の突き合わせを優先したいサブエージェントが混在している場合です。ただし分けるほど、切り替えごとに応答を確かめる作業が増えます。まずは既定のままで動かし、合わない用途が具体的に見つかってから分けるほうが、確認の回数を抑えられます。

質問⑥Agentforceの出力を毎回完全に同じにできるのか

文面まで完全に一致させることはできません。参照するデータと呼ぶアクションを固定しても、最後に日本語へ組み立てる部分は毎回動きます。同じ文面を返す必要がある業務では、その部分をAIに作らせず、あらかじめ用意した文面へ数値や品名を差し込む形にしてください。固定できるのは何を答えるかまでで、どう書くかの全部ではありません。

AIに任せる範囲を業務側で決めてから制御の手段を選ぶ

Agentforceの出力制御とは、どこまでをAIの判断に任せ、どこからを業務側で固定するのかを決める設計のことです。本記事では、出力が安定しないという一語を3つの症状に分け、揺れが起きる層と制御の手段を別々に整理したうえで、任せる条件と固定すべき業務、そして制御が届かない範囲までを一連の流れとして解説してきました。

順序として押さえておきたいのは、手段の比較を先に始めないことです。指示文で寄せるのか、記述で確定させるのか、モデルを切り替えるのかという議論は、固定したい範囲が決まってからでないと結論が出ません。範囲が決まっていない状態で手段だけを比べると、実現しやすい範囲から固定が進み、本当に固定すべき業務が最後まで残ります。

そのうえで、固定した範囲が実際に固定されているかを、割合と件数で確かめる仕組みまでを設計に含めてください。確かめる仕組みがないと、負担を払ったことだけが残り、効いたかどうかを説明できません。

制御設計の周辺については、次の記事もあわせてご確認ください。

①Agentforceの機能一覧・・・制御の各層に対応する機能の全体像を確認できます ②Agentforce料金・ライセンス・・・クレジットと費用の全体像を確認できます ③Agentforce導入支援会社の選び方・・・設計を外部と進める場合の選定基準を整理しています

出力の揺れをどこで止めるかという判断は、業務の側を知っている人にしか下せません。線の引き方から一緒に検討したい場合は、Agentforce導入・定着支援で無料相談も受け付けていますので、お気軽にご相談ください。本記事で整理した内容を、ぜひ自社の業務に合わせて実践し、少しでもお役に立てれば幸いです。