Agentforceでエージェントを1体作ったあと、次にぶつかるのは機能の使い方ではありません。受け持たせたい業務が増えたときに、同じ1本へ詰め込んでよいのか、それとも分けるべきなのかという設計の判断です。サブエージェントとは、1体のAgentforceのエージェントの内側で、受け持つ業務ごとに指示文と実行できる操作をまとめた単位のことです。 なお、Agentforceの名称と提供状況は更新が続くため、本記事は2026年9月時点の情報にもとづいています。
そこで本記事では、サブエージェントの分割単位を決める基準から、受け持ちの書き分け方、指示文をどこまで書くかの線引き、分け直す手順までを解説します。
なお、定義をコードとして記述する話はAgent Scriptの記事、稼働後に出力が揺れたときの切り分けはモデル選択と推論制御の記事、有効化と初期設定はAgentforceの使い方の記事で扱っています。本記事はそれらと重ならないよう、分ける単位を決める判断だけに絞ります。
当社はSalesforce公式コンサルティングパートナーとして、 ソリューション営業に特化したAgentforce導入・定着支援を 行っています。
- どのユースケースから始めればいいか分からない
- 設定は完了したが現場に定着しない
- ナレッジ設計から一緒に考えてほしい
というお悩みがあればお気軽にご相談ください。 1ユースケース×3ヶ月のスモールスタートプランから対応しています。
この記事を書いた人
合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。
サブエージェントの分割単位を決める3つの基準
建築金物（丁番・ハンドル・什器金具）を扱う専門商社では、従業員260名のうち営業が34名、情報システム部が2名という体制で、Sales Cloudを4年運用してきました。この企業は説明のための架空の設定であり、実在の企業ではありません。この会社は半年前に営業向けのエージェントを1体だけ作り、商談準備と見積の照会と過去案件の抽出という3つの業務を、1本のサブエージェントに詰め込んで動かしています。当初の目的は「営業が調べる時間を減らすこと」でした。そこでここでは、この会社を例に、サブエージェントの分割単位を決める3つの基準を整理します。
分ける単位を機能で決めると、あとから必ず組み直すことになります。サブエージェントを分ける単位は、機能の種類では決まりません。担当者が依頼として口に出せる業務のまとまりで決まります。
| 比較の観点 | 1本にまとめた場合 | 業務ごとに分けた場合 |
|---|---|---|
| 依頼の渡り先 | 常に同じ1本 | 業務ごとに変わる |
| 指示文を直す範囲 | 全文を読み直す | 該当する1本だけ |
| 失敗した箇所 | 経路に情報がない | 渡り先から追える |
| 共通の手順 | 1箇所で済む | 本数だけ書き写す |
| 配線するアクション | 1本に集中する | 受け持ちごとに分散 |
基準①担当者が依頼として口に出せる範囲
1つ目は「担当者が依頼として口に出せる範囲」です。営業担当者がエージェントに話しかけるとき、頭のなかにあるのは機能の名前ではありません。「明日の訪問先の直近のやり取りをまとめて」「この型番の前回の見積を出して」という、業務としての依頼です。この依頼の言い方が変わる境目が、そのままサブエージェントの境目になります。
なぜこの基準が効くかというと、依頼の言い方が違えば、参照すべき記録も、返すべき答えの形も変わるからです。訪問前の準備であれば直近の商談メモと未対応の依頼が要りますが、見積の照会であれば必要なのは型番と過去の価格です。同じ1本の指示文で両方を扱えば、どちらの依頼が来ても両方の手順を読ませることになります。
この建築金物の商社では、営業34名が半年間にエージェントへ投げた依頼を、情報システム部が直近8週ぶんだけ書き出しました。1,204件の依頼を「訪問前の準備」「見積の照会」「過去案件の抽出」「その他」に手作業で仕分けたところ、最初の3つでほぼすべてを占めています。営業が使っていた言い回しは業務ごとに固まっており、担当者が読んだだけで、どの業務の依頼かを判別できる状態でした。
分け方に迷ったときは、依頼のログを声に出して読み、業務名を言い当てられるかを確かめましょう。言い当てられない依頼が多いなら、分ける単位がまだ業務になっていません。
基準②参照するデータの置き場所がそろう範囲
2つ目に挙げるのは、参照するデータの置き場所がそろう範囲です。サブエージェントは、受け持つ業務のなかで参照させる記録を指定して動きます。参照先の種類が増えるほど、依頼に対してどの記録を読むべきかの判断が増えます。
判断が増えると、回答は不安定になります。商談メモを読めば答えられる依頼に対して、ナレッジ記事と見積履歴まで候補に入っていれば、そのなかから選ぶ工程がひとつ増えるためです。
先ほどの商社では、1本のサブエージェントに4種類を参照先として登録していました。
1本にまとめて登録していた4つの参照先 ①商談メモ・・・営業が面談後に残す自由記述の記録です ②見積履歴・・・型番ごとの過去の提示価格が入っています ③製品カタログ・・・仕様が書かれたPDFです ④過去の受注データ・・・他部署が管理する実績の記録です
営業から「訪問前の準備を頼んだのに、製品カタログの説明が返ってきた」という申告が出ていたのは、この状態が理由です。情報システム部が参照先を業務ごとに切り分けたあとは、訪問前の準備で読むのは商談メモと未対応の依頼だけになりました。
非構造データの参照精度を上げる設計は、Agentforce RAGの記事で詳しく解説しています。参照先を絞ってもまだ答えがずれるなら、そちらの原因を先に確認してください。
基準③実行してよい操作の権限がそろう範囲
3つ目は「実行してよい操作の権限がそろう範囲」です。サブエージェントには、レコードを検索する、下書きを作る、担当者に通知するといった操作を配線できます。ここで問題になるのは、業務ごとに「やってよい範囲」が違うことです。
読むだけの業務と、書き込む業務を1本に同居させると、権限の設計が最も広い業務に引きずられます。過去案件を抽出するだけの依頼を受け付けるサブエージェントに、見積レコードを更新する操作が配線されていれば、その操作はいつでも呼び出せる状態になります。
この会社では、当初1本に14件の操作を配線していました。そのうち3件はレコードを更新するもので、残りは検索と要約でした。情報システム部の担当者は、更新を伴う3件を見積照会のサブエージェントへ移し、訪問前の準備には検索と要約だけを残しています。移したあと、意図しない更新の申告は出ていません。
読む業務と書く業務が同じ1本に入っていないかを、配線した操作の一覧で確認しましょう。混ざっているなら、それは分ける合図です。
サブエージェントを1本にまとめたときの3つの症状
ここまで分ける基準を整理してきましたが、そもそも1本にまとめたままだと何が起きるのかが見えていなければ、分ける判断には踏み切れません。実際にこの建築金物の商社でも、営業からの申告は「なんとなく使いにくい」という形で挙がっており、原因が設計にあるとは誰も考えていませんでした。そこでここでは、サブエージェントを1本にまとめたときに現れる3つの症状を整理します。
症状は精度の問題として報告されますが、原因は別のところにあります。依頼の意図から外れた回答が続くとき、疑うべきは指示文の書き方より先に、1本が受け持つ業務の数です。
症状①依頼の意図から外れた回答が返る
1つ目は「依頼の意図から外れた回答が返る」という症状です。営業担当者が見積の履歴を確認したくて依頼したのに過去の類似案件の一覧が返り、訪問前の情報整理を頼んだはずが製品仕様の説明から始まる場合もあります。こうした申告は、エージェントを動かして数週間で必ず出てきます。
この状態が起きるのは、1本のサブエージェントが3つの業務を受け持っていると、どの手順を使うかの判断がサブエージェントの内側に押し込まれるためです。受け持ちが1業務なら、選ぶ余地はありません。3業務が同居していれば、依頼のたびに選び直すことになります。
先ほどの商社が8週ぶんの依頼1,204件を仕分けたとき、あわせて「想定した業務の手順が使われたか」も数えました。想定どおりに処理されていたのは58%で、残りの42%は別の業務の手順に流れています。営業からの申告は月に十数件でしたが、実際にずれていた依頼はその何倍もあったのです。
申告の件数を見るだけでは、この症状の大きさは分かりません。依頼のログを業務ごとに数えて、はじめて割合が出てきます。どの業務から着手するかの決め方は、Agentforceのユースケースの選び方でも整理しています。
症状②指示文の修正が別の業務へ波及する
2つ目に挙げるのは、指示文の修正が別の業務へ波及する症状です。1本の指示文に3業務ぶんの条件が並んでいると、ある業務のために足した1行が、別の業務の振る舞いを変えます。
条件を足した本人には、その影響が見えません。修正した理由は目の前の1業務にあり、確認するのもその業務だけになるためです。
この会社の指示文は、半年で128行まで伸びていました。情報システム部の担当者が見積照会の言い回しを直したところ、翌週になって営業から「訪問前の準備で出てくる項目が減った」という連絡が入っています。原因は、見積のために足した「金額に関する情報を優先する」という1行でした。担当者はこの1行を書いたとき、訪問前の準備への影響を考えていません。
修正のたびに128行すべてを読み直す運用は、続きません。読み直す範囲を業務ぶんに閉じることが、分ける目的のひとつです。
症状③どの手順で失敗したのかを追えない
3つ目は「どの手順で失敗したのかを追えない」という症状です。回答がずれたとき、確認したいのは「どの受け持ちが選ばれ、どの操作が実行されたか」という経路です。
1本にまとめていると、この経路がほとんど情報を持ちません。受け持ちは常に同じ1本であり、実行された操作だけが記録に残るためです。原因が振り分けにあるのか、指示文にあるのか、参照先にあるのかを、記録から切り分けられません。
この商社の情報システム部は、営業から申告が来るたびに、当該の依頼文を自分たちで打ち直して再現を試みていました。1件あたり20分ほどかかり、それでも再現しないことがあります。分け直したあとは、まずどの受け持ちに渡ったかを見て、想定と違えば説明の書き方を、想定どおりなら指示文を疑うという順番で確認できるようになりました。
原因の切り分けができない状態は、改善の速さを決めます。経路が記録に残る設計にしておくことが、あとの運用を軽くします。
サブエージェントを分けすぎたときの3つの負担
ここまで挙げた1本にまとめたときの症状を踏まえると、分ければ分けるほどよいように読めますが、細かく分けすぎた結果として別の手間が発生している場合は、立て直しにかかる時間がかえって長くなります。営業が業務として区別していない単位まで割ってしまうと、依頼の行き先が安定しないまま、管理する本数だけが増えていくのです。設計案の段階で気づけば書き直しで済みますが、稼働後に気づいた場合の組み替えは、指示文とアクションの配線の両方に及びます。そこでここでは、サブエージェントを分けすぎたときに生じる3つの負担を整理します。
分割は多いほどよいという話ではありません。サブエージェントの本数は、営業が業務として言い分けている数を超えると、管理の手間だけが増えます。
負担①同じ手順を何本にも書き写す
1つ目は「同じ手順を何本にも書き写す」という負担です。業務を細かく割ると、どの業務にも共通して必要な手順が出てきます。
どの受け持ちにも共通して必要になる手順 ①相手の確認・・・依頼した担当者と対象の取引先を特定します ②根拠の提示・・・回答の最後に参照したレコードを添えます ③範囲の宣言・・・答えられない依頼をその場で断ります
こうした手順は、分けた本数だけ書くことになります。
書き写した瞬間は問題になりません。困るのは、その共通の手順を直すときです。8本に分けていれば8箇所を直すことになり、1箇所でも直し忘れれば、そのサブエージェントだけ振る舞いが変わります。
この建築金物の商社は、最初の設計案で業務を9本に割っていました。案の段階で共通の手順を数えたところ、9本のうち7本に同じ3行が入っています。情報システム部の2名は、この時点で分け方を見直し、最終的に4本へ寄せました。書き写す行が減ったことで、共通の手順を直す作業は1回で済んでいます。
分けた案が固まったら、複数本に同じ行が並んでいないかを確認しましょう。並んでいるなら、その業務は同じ受け持ちに入る可能性があります。
負担②依頼の言い方で行き先が変わる
2つ目に挙げるのは、依頼の言い方で行き先が変わる負担です。受け持ちを細かく割るほど、隣の受け持ちとの境目が近づきます。境目が近い2本があると、依頼のわずかな言い回しの差で、渡る先が入れ替わります。
営業担当者から見れば、同じ内容を頼んでいるつもりです。「前回の見積を見せて」と「この型番でいくらで出したか教えて」は、業務としては同じ依頼にあたります。それでも受け持ちが「見積の照会」と「価格の確認」に割れていれば、どちらに渡るかは文面次第になります。
この会社の設計案でも、見積の照会と価格の確認を別々に置いていました。試しに営業3名へ同じ内容を10通りの言い方で依頼してもらったところ、行き先は2本に割れています。情報システム部はこの2本を1本へ統合し、そのうえで「価格を答えるときは有効期限も添える」という条件を指示文に1行足しました。
営業が言い分けていない業務を、設計側で分けてはいけません。分ける前に、言い方の違いが業務の違いかどうかを確かめる必要があります。
負担③構成の上限に届いて増やせない
3つ目は「構成の上限に届いて増やせない」という負担です。Agentforceには、構成の3つの単位にそれぞれ上限が設けられています。
上限が設けられている3つの単位 ①エージェント・・・1つの組織で有効にできる体数に上限があります ②サブエージェント・・・1体あたりの本数に上限があります ③アクション・・・1本あたりの配線できる件数に上限があります
細かく割る設計を続けると、この上限に先に届きます。届いたあとで統合するには、指示文とアクションの配線を組み直すことになり、稼働中のエージェントを止める判断まで必要になる場合があります。
先ほどの商社は、営業向けの1体だけで9本を使う案を検討していました。ここで情報システム部が確認したのは、この先にカスタマーサポート向けの受け持ちを足す予定があることです。営業だけで枠の大半を使えば、次の業務を足すときに組み直しが発生します。4本へ寄せた判断には、この見通しも入っていました。
上限の具体的な数値と、その前提での構成の考え方は、Agent Scriptの記事で2026年8月時点の値として整理しています。Agentforceの機能の全体像とあわせて確認すると、どこまで増やせるかの見当がつきます。
サブエージェントの受け持ちを書き分ける4つの型
ここまでで分ける単位が決まっても、それだけでは依頼が正しい受け持ちへ渡りません。渡り先を決めているのは、サブエージェントごとに書く「どんな依頼を受け持つか」の記述だからです。Salesforceの画面では、この記述はClassification Descriptionという項目に置かれ、Scope・Instructions・配線したアクションと並んで1本のサブエージェントを構成しています。そこでここでは、受け持ちを書き分ける4つの型を整理します。
指示文をいくら細かくしても、渡り先が違えば読まれません。回答が業務ごとずれているときに直すのは指示文ではありません。受け持ちの記述のほうです。
型①受け持つ依頼の言い方を並べる
1つ目は「受け持つ依頼の言い方を並べる」型です。受け持ちの記述には、業務の説明を書きたくなります。ところが渡り先の判定に使われるのは、依頼の文面とこの記述の近さです。業務の定義を丁寧に書くより、営業が実際に使っている言い回しを並べるほうが、判定は安定します。
言い回しは想像で並べても効きません。手元の依頼ログから、実際に届いた文面をそのまま拾う必要があります。
この建築金物の商社では、訪問前の準備を受け持つサブエージェントの記述に、はじめは「営業担当者の商談準備を支援します」という1文だけを置いていました。8週ぶんのログから実際の依頼を抜き出し、「明日の訪問先の状況をまとめて」「前回の面談で出た宿題を教えて」「この取引先の未対応の依頼はある？」という3つの言い方を記述へ足したところ、この業務に渡る割合は目に見えて上がっています。
記述を書き始める前に、依頼のログを開きましょう。ログに1件も見当たらない言い方は、まだ記述へ入れる段階にありません。
※参考記事はこちら
型②受け持たない依頼を先に書く
2つ目に挙げるのは、受け持たない依頼を先に書く型です。隣の受け持ちと境目が近い業務では、「何を受け持つか」だけを書いても判定が割れます。受け持たない依頼を明示すると、境目がはっきりします。
これは受け持ちを狭める作業ではありません。境目にある依頼を、どちらが引き取るかを決める作業です。
先ほどの商社では、見積の照会と過去案件の抽出が隣り合っていました。どちらも過去のレコードを読む業務のため、「去年の同じような案件を出して」という依頼が両方に渡っています。情報システム部は見積の照会の記述に「金額の確認を伴わない類似案件の検索は受け持ちません」という1文を置き、過去案件の抽出の記述には「見積の金額を答える依頼は受け持ちません」と書きました。境目の依頼が割れる件数は、月11件から1件へ減っています。
境目にある依頼を1つ選び、どちらが引き取るかを決めてから記述に書きましょう。
型③業務の呼び名を先頭に置く
3つ目は「業務の呼び名を先頭に置く」型です。記述の冒頭に、社内で使われている業務の呼び名をそのまま置きます。営業が「訪問前準備」と呼んでいるなら、その語を最初に書きます。
社内の呼び名を使う理由は、営業が依頼のなかでもその語を使うためです。「訪問前準備をお願い」という依頼が実際に届くのであれば、記述の先頭にある語と直接つながります。
この会社の営業は、訪問前の情報整理を「事前準備」と呼んでいました。情報システム部が最初に書いた記述の冒頭は「商談準備支援」で、社内では誰も使っていない語です。「事前準備」へ書き換えたあと、その語を含む依頼が別の受け持ちへ流れる件数はなくなりました。
設計側で作った呼び名を、記述の先頭に置かないよう注意しましょう。使うのは、営業が口にしている語です。
型④他の受け持ちで使った語を削る
4つ目は「他の受け持ちで使った語を削る」型です。複数の記述に同じ語が入っていると、判定はその語では区別できません。区別に効いていない語は、記述から削ります。
削る対象は、業務を説明するために置いた一般的な語です。「営業」「顧客」「情報」「支援」といった語は、どの受け持ちにも当てはまるため、判定の材料になりません。
この商社が4本の記述を並べて確認したところ、4本すべてに「営業担当者の業務を支援します」という同じ一文が入っていました。情報システム部はこの一文を全本から削り、代わりに業務ごとの依頼の言い方を足しています。記述の文字数は減りましたが、想定した受け持ちへ渡る割合は上がりました。
4本の記述を横に並べて、同じ語に印を付けてみましょう。印だらけの語は削って構いません。それでも渡り先が揺れるなら、原因は記述より推論の側にある可能性があります。モデル選択と推論制御の記事で、どの層で揺れているかの切り分け方を整理しています。
サブエージェントの指示文をどこまで書くかの3つの線引き
ここまでの手順で受け持ちの記述が整うと、次に迷うのが指示文です。細かく書くほど狙いどおりに動くはずだと考えて条件を足し続けた結果、行数だけが増えて手に負えなくなる例は少なくありません。この建築金物の商社でも、1本の指示文が128行まで伸びたのは、この考え方が理由でした。そこでここでは、指示文をどこまで書くかの3つの線引きを整理します。
書く量と精度は比例しません。指示文に書くのは、判断が分かれる場面だけです。判断が1つに決まる操作は、アクションの配線で表現します。
線引き①判断が分かれる場面だけ書く
1つ目は「判断が分かれる場面だけ書く」という線引きです。指示文が効くのは、同じ依頼に対して複数の返し方がありうる場面です。どちらを選ぶかを言葉で決めておく必要があるとき、はじめて1行の価値が出ます。
逆に、返し方が1つしかない場面に条件を書いても、振る舞いは変わりません。行数だけが増え、読み直す範囲が広がります。
先ほどの商社の指示文128行を、情報システム部が分類したことがあります。判断が分かれる場面を扱っていた行は、およそ3割でした。残りは「レコードを検索する」「結果を一覧で返す」といった、配線した操作を言葉で説明し直した行です。この7割を削っても、営業から挙がる回答の内容に変化はありませんでした。
書こうとしている1行について、「どちらを選ぶかを決めているか」を自問しましょう。決めていないなら、その行は要りません。
線引き②画面の操作手順は書かない
2つ目に挙げるのは、画面の操作手順を書かないという線引きです。担当者向けの手順書をそのまま指示文へ貼り付けた記述を見かけますが、これは動作に結びつきません。
サブエージェントが実行できるのは、配線されたアクションだけです。画面上のボタンを押す順番を書いても、対応するアクションがなければ実行されず、書いた側だけが「指示したつもり」になります。
この会社の指示文にも、見積の照会について「商談画面から見積タブを開き、有効期限の新しい順に並べ替える」という3行が入っていました。実際に配線されていたのは見積レコードを検索するアクション1件だけで、並べ替えの条件はアクション側の設定に持たせるものです。情報システム部はこの3行を削り、アクションの検索条件を直しています。
手順を書きたくなったら、その手順に対応するアクションが配線されているかを先に確認してください。
線引き③禁止する行為を1文で書く
3つ目は「禁止する行為を1文で書く」という線引きです。やってよいことを列挙するより、やってはいけないことを1文で置くほうが、指示文は短く保てます。
禁止の条件は、業務ごとに数が限られます。
見積の照会で置いた禁止の条件 ①金額・・・見積の金額を確定しません ②送信・・・顧客へ直接送信しません ③範囲・・・権限のない取引先の情報を返しません
この程度の数であれば、1文ずつ置いても指示文は膨らみません。
この建築金物の商社は、見積の照会に「金額の変更や見積の確定は行いません」という1文を置きました。それまでは、更新してよい条件を場合分けして5行で書いていたところです。1文へ置き換えたあと、意図しない更新は発生していません。
人が承認する場面とAIへ任せる範囲の線の引き方は、Einstein Trust Layerの記事で詳しく整理しています。禁止の条件を指示文だけで担保しきれない業務では、そちらの仕組みとあわせて設計してください。
サブエージェントに配線する標準アクションの4つの条件
前章で指示文の線引きが決まると、書かずに済ませた分はアクションの配線が引き受けることになります。Agentforceには標準アクションが用意されており、レコードの検索や下書きの作成といった操作は、設定だけで受け持ちへ配線できます。ただし配線できる操作をすべて足すと、1本あたりの件数が膨らみ、どれを実行するかの判断が増えてしまうのです。そこでここでは、標準アクションを配線してよい4つの条件を整理します。
配線は多いほど便利になるという話ではありません。配線してよい標準アクションは、その業務で毎回使う操作に限ります。ときどき使う操作は、別の受け持ちへ寄せます。
条件①その業務で毎回使う操作であること
1つ目は「その業務で毎回使う操作であること」という条件です。毎回の依頼で必ず通る操作は、配線しておく価値があります。ときどきしか使わない操作は、実行するかどうかの判断を毎回発生させます。
判断の回数が増えると、実行されるべき操作が飛ばされる場面が出てきます。候補が6件のときと14件のときでは、選ぶ精度が変わるためです。
先ほどの商社は、1本に14件を配線していました。8週ぶんのログで実行回数を数えたところ、上位5件で全体の9割を占め、残り9件は合計で50回に届いていません。情報システム部は使用頻度の低い操作を外し、4本へ分けたあとは1本あたり最大6件に収めています。
配線した操作の実行回数を数え、依頼の総数に対する割合まで出してみましょう。1割に届かない操作は、外して構いません。
※参考記事はこちら
条件②実行後に取り消せる操作であること
2つ目に挙げるのは、実行後に取り消せる操作であることです。検索や要約のように、実行しても記録が変わらない操作は、間違って呼ばれても影響が残りません。レコードの更新や外部への送信は、取り消しに人の作業が要ります。
この違いは、承認を挟むかどうかの判断に直結します。取り消せない操作を配線するなら、実行前に人が確認する設計を一緒に用意する必要があります。
この会社では、見積照会の受け持ちに「見積の下書きを作成する」というアクションを配線しました。下書きは作成しても取引先へは届かないため、間違って呼ばれても削除するだけで済みます。一方、担当者へメールを送るアクションは、営業が内容を確認してから送る運用に切り替えています。
外部のシステムをまたぐ操作を配線する場合の境界の決め方は、Agentforce MCPの記事で扱っています。取り消せない操作が社外に及ぶなら、そちらの設計を先に確認してください。
条件③参照するデータの権限がそろっていること
3つ目は「参照するデータの権限がそろっていること」という条件です。アクションは、実行する利用者の権限で動きます。同じ受け持ちに配線した操作が、担当者によって成功したり失敗したりする状態は、設計の問題として扱う必要があります。
権限が業務ごとに違うなら、受け持ちも業務ごとに分けるのが自然です。1本に権限の違う操作を混ぜると、利用者ごとに使える操作の組み合わせが変わります。
この建築金物の商社では、過去案件の抽出に他部署の受注データを読むアクションを配線していました。営業34名のうち閲覧権限を持つのは主任以上の11名だけで、残りの23名が同じ依頼をすると、途中で結果が返らなくなります。営業からの申告のうち何件かは、この権限の差が原因でした。情報システム部は権限の要る操作を管理職向けの受け持ちへ切り出しています。
配線した操作を、権限の最も狭い担当者の目線で一度確認しましょう。
条件④他の受け持ちに重複して配線されていない
4つ目は「他の受け持ちに重複して配線されていない」ことです。同じアクションを複数の受け持ちへ配線すると、依頼がどちらへ渡っても同じ操作が実行されます。動作としては成立するため、重複には気づきにくくなります。
気づけないまま運用を続けると、操作の仕様を変えたときに影響範囲が読めません。1件のアクションを直したつもりが、想定していなかった受け持ちの振る舞いまで変わります。
先ほどの商社が4本へ分け直したあと、配線したアクションは合計17件でした。ここで情報システム部が確認したのは、17件のうち同じアクションが2本以上に入っていないかです。実際には、取引先を検索するアクションが3本に入っていました。この1件だけは共通で使う操作として残し、残りは重複がない状態に整えています。
配線の一覧を受け持ちごとに書き出して、同じ名前が2回以上出てこないかを見ましょう。共通で残すものは、残す理由を記録しておく必要があります。
サブエージェントを分け直す5つのステップ
ここまでで配線の条件まで決まれば、あとは実際に分け直す作業に入ります。すでに動いているエージェントを組み替えるため、営業の業務を止めない順番で進める必要があります。この建築金物の商社が1本を4本へ分け直したときは、情報システム部の2名で3週間、合計38時間をかけました。そこでここでは、分け直す作業を5つのステップで整理します。
作業の順番を間違えると、途中で営業が使えなくなります。分け直しは記述の書き換えから始めません。依頼のログを業務ごとに数えることから始めます。
ステップ①依頼のログを業務ごとに数える
最初に手をつけるのは、これまでに届いた依頼を業務ごとに数える作業です。分け方の案を先に作ってしまうと、その案に合う依頼だけが目に入ります。数えてから決める順番にすると、実際の使われ方に沿った分け方になります。
数える単位は業務です。依頼の文面を読み、どの業務のつもりで頼まれたのかを人が判断して仕分けます。件数が多い場合でも、直近8週ぶんに絞れば作業量は収まります。
この商社では、8週ぶんの1,204件を情報システム部の2名で仕分けました。1件あたり数秒で判断できるものがほとんどで、迷ったものだけを別に置いています。結果は訪問前の準備が最も多く、次いで見積の照会、過去案件の抽出と続き、どの業務にも当てはまらない依頼は全体の1割に届きませんでした。この1割は分け直しの対象から外しています。
仕分けの結果を業務ごとの件数として書き出しましょう。件数の少ない業務は、この時点で独立させない判断ができます。
ステップ②行き先が割れた依頼だけ抜き出す
数え終えたら、次に見るのは想定と実際がずれた依頼です。全件を見直す必要はありません。想定した業務と実際に処理された業務が食い違った依頼だけを抜き出します。
ここで抜き出した依頼が、記述を書き換えるときの材料になります。ずれた理由を1件ずつ読むと、境目がどこにあるのかが具体的な文面として見えてきます。
この会社では、1,204件のうち42%にあたる依頼が想定と違う手順で処理されていました。情報システム部はこのなかから、同じ言い回しで繰り返し届いていた30件を抜き出しています。読み返すと、そのうち19件は「前回」という語を含む依頼で、見積の照会と過去案件の抽出のどちらにも読める文面でした。
ずれた依頼のなかから、繰り返し出てくる言い回しを探しましょう。そこが最初に直す境目になります。
ステップ③受け持ちの説明文を書き直す
材料がそろったら、受け持ちの記述を書き直します。この段階ではまだアクションの配線に触れません。記述だけを直して、渡り先が想定どおりになるかを先に確かめます。
書き直す内容は、前の章で整理した4つの型に沿って決めます。実際の言い回しを並べ、受け持たない依頼を明示し、社内の呼び名を先頭に置き、他の受け持ちと重なる語を削ります。
この建築金物の商社では、4本ぶんの記述を1日で書き直しました。抜き出した30件の依頼をひとつずつ読み、どちらが引き取るかを2名で決めてから文面に落としています。「前回」を含む19件は見積の照会が引き取ることにし、過去案件の抽出の記述には金額を伴う依頼を受け持たない旨を書きました。
記述を直したら、抜き出した依頼をそのまま投げて、渡り先を確かめてください。
ステップ④配線するアクションを付け替える
渡り先が安定してから、アクションの配線に手を入れます。この順番にする理由は、渡り先が揺れている状態で配線を変えると、変化がどちらの影響なのかを判別できなくなるためです。
付け替えの内容は、受け持ちごとに毎回使う操作を残し、ときどきしか使わない操作を外すことです。取り消せない操作は、承認を挟む設計にあわせて置き場所を決めます。
この会社は、1本に配線していた14件を4本へ振り分け、あわせて実行回数の少ない5件を外しました。残った9件に、分けたことで新しく必要になった8件を足して、最終的な配線は合計17件です。1本あたりで最も多い受け持ちでも6件に収まっています。
配線を変えたあとは、外した操作が本当に不要だったかを2週間ほど見ましょう。必要だと分かれば戻せます。
ステップ⑤限定した範囲で動かして確かめる
最後に、対象を絞った状態で動かして確かめます。全社へ一度に反映すると、想定していなかったずれが出たときに、戻す判断が難しくなります。
範囲の絞り方としては、利用する担当者を限定する方法が扱いやすいでしょう。営業全員へ一度に公開せず、特定のチームだけに開いて、2週間ほど使ってもらってから広げます。小さく始めたい場合は、この1ユースケースからのスモールスタートが、投資を抑えたまま設計の妥当性を確かめる進め方になります。
この商社は、まず営業6名に限定して2週間動かしました。この期間に出た指摘は7件で、そのうち5件は記述の言い回しで解消しています。残り2件はアクションの検索条件の問題で、修正してから34名全員へ広げました。全社へ広げたあとに戻す判断が必要になった場面はありません。
限定して動かす期間の検証は、テストセンターの仕組みを使うと記録が残ります。最初の1体を作るところからの流れは、Agentforceの使い方で整理しています。以上が、サブエージェントを分け直す5ステップでした。
サブエージェントの設計でつまずく3つの落とし穴
ここまで示した5つのステップを順に進めれば分け直しは終わりますが、実際には途中で手順を飛ばしてしまう場面があり、飛ばした結果として起きる失敗にはいくつか決まった形が見られます。とくに多いのは、依頼のログを数える工程と、限定した範囲で動かして確かめる工程を省いてしまうことです。どちらも作業量が読みにくく、急いでいるときほど後回しにされる工程にあたります。そこでここでは、サブエージェントの設計でつまずく3つの落とし穴を整理します。
失敗の多くは、作業の順番を入れ替えたことから生まれます。設計を直す前に依頼のログを見ていないなら、直したあとに何が良くなったのかを説明できません。
落とし穴①依頼のログを見ずに分け方を決める
1つ目は「依頼のログを見ずに分け方を決める」という落とし穴です。業務の一覧は、営業部門の組織図や業務フロー図から作れます。そのため、ログを見なくても分け方の案は書けてしまいます。
図から作った案が合わないのは、営業がエージェントに頼む業務と、業務フロー上の工程が一致しないためです。フロー図では別の工程でも、営業から見れば同じ依頼という場面がよくあります。
この建築金物の商社が最初に作った9本の案も、営業部門の業務フロー図をもとにしたものでした。ログを仕分けたあとで見比べると、9本のうち3本には8週間で1件も依頼が届いていません。逆に、フロー図には工程として書かれていなかった「取引先の担当者の異動を確認する」という依頼が、80件以上ありました。
分け方の案を作ったら、その案に対して実際の依頼が何件届いているかを必ず数えましょう。
落とし穴②説明文を直さずに指示文だけ足す
2つ目に挙げるのは、受け持ちの記述を直さずに指示文だけを足す落とし穴です。回答がずれたという申告を受けたとき、最初に開きたくなるのは指示文です。条件を1行足せば直りそうに見えます。
この対処が効かないのは、渡り先が違っている場合です。渡っていない受け持ちの指示文をいくら直しても、その依頼は読みません。それでも申告が減らないため、さらに条件を足すことになります。
先ほどの商社の指示文が128行まで伸びた経緯も、これにあたります。情報システム部の担当者は、申告を受けるたびに条件を足していました。分け直しの作業で行を分類したとき、渡り先の問題に対して指示文を足していた行が20行以上見つかっています。この20行は、記述を直した時点で不要になりました。
申告を受けたら、まずその依頼の渡り先を見て、想定どおりだった場合に限って指示文を開きましょう。
落とし穴③1本で試した設計を全社へ広げる
3つ目は「1本で試した設計を全社へ広げる」という落とし穴です。1本のサブエージェントで狙いどおりに動いたからといって、同じ書き方を他の業務へそのまま当てはめると、境目の問題が一度に発生します。
1本だけで動かしている間は、渡り先の判定が発生しません。届いた依頼はすべてその1本へ渡ります。2本目を足した瞬間から、判定が始まります。
この会社も、当初は訪問前の準備だけで試す計画でした。結果が良かったため、同じ記述の書き方で見積の照会と過去案件の抽出を一度に足す案が出ています。情報システム部は2本目までで一度止め、境目の依頼がどう割れるかを確かめてから3本目へ進みました。この判断で、境目の調整は2回に分かれています。
受け持ちを増やすときは、1本ずつ足して境目を確かめましょう。公開後に使われなくなる状態からの立て直しは、Agentforceの定着をご確認ください。
サブエージェントの設計が進んだかを測る4つの指標
落とし穴を避けて分け直しを終えたあと、次に必要になるのは成果の説明です。設計を直したことが業務にどう効いたのかを、経営層や営業部門へ数字で示せなければ、次の投資の判断につながりません。そこでここでは、サブエージェントの設計が進んだかを測る4つの指標を整理します。
利用回数だけを見ても、設計が良くなったかは判断できません。サブエージェントの設計を測る指標は、使われた回数より、想定した受け持ちへ渡った割合です。
指標①想定した受け持ちへ渡った依頼の割合
1つ目は「想定した受け持ちへ渡った依頼の割合」です。依頼が意図した業務へ渡っているかどうかは、分割設計の出来を表します。この割合が低いままなら、指示文をどれだけ直しても回答は安定しません。
測り方は、一定期間の依頼を業務ごとに仕分けし、実際に渡った受け持ちと突き合わせるだけです。仕分けは人の判断で構いません。
当初の目的は「営業が調べる時間を減らすこと」でしたが、この建築金物の商社では分け直す前の割合が58%にとどまっていました。3か月後に同じやり方で1週間ぶんを数えたところ、91%まで上がっています。営業からの申告件数も、月に十数件から2件へ減りました。
まず現状の割合を出しましょう。改善したかどうかは、同じ数え方をもう一度するだけで確かめられます。
指標②担当者が依頼を言い直した回数
2つ目に挙げるのは、担当者が依頼を言い直した回数です。渡り先が想定どおりでも、返ってきた内容が求めていたものと違えば、営業はもう一度言い方を変えて頼みます。この回数は、設計の使い勝手を表します。
この指標が役に立つのは、申告として上がってこない不満を拾えるためです。営業は1回言い直せば答えが返るなら、わざわざ情報システム部へ連絡しません。
この会社では、同じ担当者が5分以内に似た内容を再度依頼した件数を、週単位で数えていました。分け直す前は週42回で、営業34名のうち半数以上が週に1回以上言い直しています。3か月後には週9回まで減りました。
言い直しの回数は、ログから機械的に数えられます。申告の件数と並べて見ると、実態との差が分かります。
指標③指示文を直してから反映するまでの日数
3つ目は「指示文を直してから反映するまでの日数」です。設計が分かれていれば、直す範囲は該当する1本に閉じます。範囲が閉じれば、確認にかかる時間も短くなります。
この日数が長いままだと、営業からの要望に応える速さが上がりません。設計を分けた効果は、回答の精度だけでなく、直す速さにも表れます。測り方は、修正を依頼された日と反映した日を並べ、その間の日数を平均するだけです。同じ日のうちに反映できたものは0.5日として数えます。
先ほどの商社は、分け直す前は平均4.5日かかっていました。128行すべてを読み直し、他の業務への影響がないかを2名で確認してから反映していたためです。営業から「その1行を足すだけなのに、なぜ数日もかかるのか」と聞かれたこともありました。4本へ分けたあとは、読み直す範囲が最大42行に収まり、平均0.5日で反映できています。
直すたびに読み直した行数を記録しておくと、この指標の裏づけになります。
指標④受け持ちが重なって競合した件数
4つ目は「受け持ちが重なって競合した件数」です。境目にある依頼が、月にどれだけ発生しているかを数えます。件数が増えているなら、受け持ちの記述に重なりが戻っています。
この指標を続けて見る理由は、記述が運用のなかで少しずつ書き足されるためです。営業の要望に応えて1文足すたびに、隣の受け持ちとの重なりが生まれる場合があります。
この建築金物の商社は、分け直す前に月11件あった競合を、3か月後に月1件まで減らしました。その後も月次で数え続けており、2件を超えた月は記述を見直す運用にしています。
稼働後の精度と定着を継続して測る仕組みは、Agentforce Observabilityの記事で整理しています。ここで挙げた4つの指標とあわせて設計してもらえると嬉しいです。
サブエージェントの設計に外部支援を使う4つの判断軸
ここまで挙げた指標まで決めれば、社内で運用を続ける準備は整います。とはいえ、情報システム部が2名という体制で、依頼のログの仕分けから記述の書き分けまでを回し続けられるかは別の問題です。では、外部の支援を検討するとき、何を見て選べばよいのでしょうか。それは、支援会社によって入る工程がまったく違うからです。そこでここでは、サブエージェントの設計に外部支援を使うときの4つの判断軸を整理します。
支援会社の実績数だけでは、自社に合うかどうかは判断できません。サブエージェントの設計を任せる相手は、依頼のログを一緒に読むところから入れるかどうかで選びます。
判断軸①依頼のログを見て分け方を決められるか
1つ目は「依頼のログを見て分け方を決められるか」という判断軸です。分け方を業務フロー図から作る支援と、実際の依頼から作る支援では、出来上がる設計が変わります。
見分け方は、提案の段階で何を材料に使っているかを確認することです。ヒアリングした業務の一覧だけで設計案を出してくる場合、ログを読む工程が見積に入っていない可能性があります。
先ほどの商社も、当初は業務フロー図から9本の案を作っていました。ログを仕分けてはじめて、3本には依頼が1件も届いていないことが分かっています。この工程を外部に任せる場合、仕分けの作業自体が見積に含まれているかを確かめる必要があります。
ツール設定ではなく業務設計から入ってほしい場合は、依頼のログを読む工程が提案に含まれているかが判断材料になります。
判断軸②動かしたあとの直しに付き合えるか
2つ目に挙げるのは、動かしたあとの直しに付き合えるかどうかです。分け直しは、公開した時点では終わりません。営業が使い始めてから2週間ほどで、境目の依頼が必ず出てきます。
構築までを請け負う契約と、公開後の調整まで含む契約では、費用の考え方も期間も違います。契約の範囲がどこで切れるのかを、着手前に確認しておく必要があります。
この会社が営業6名に限定して動かした2週間で出た指摘は7件でした。このうち5件は記述の言い回しの調整で、公開前には見つけられない類のものです。こうした調整を誰が担うのかを決めていなければ、公開後に情報システム部の2名へ作業が戻ります。
定着まで伴走してほしい場合は、公開後の調整が契約の範囲に入っているかが判断材料になります。
判断軸③営業の依頼の言い方を知っているか
3つ目は「営業の依頼の言い方を知っているか」という判断軸です。受け持ちの記述に並べるのは、営業が実際に使っている言い回しです。この言い回しは業種と商材によって変わります。
支援する側が営業の業務を理解していなければ、ログを読んでも業務の単位が判断できません。「前回の見積を見せて」という依頼と「この型番でいくらで出したか」という依頼が同じ業務かどうかは、営業の進め方を知らなければ決められないからです。
先ほどの商社では、境目にあった19件の依頼をどちらが引き取るかの判断に、営業課長2名が同席しました。情報システム部の2名だけでは、どちらの業務の依頼として扱うべきかが決まらなかったのです。
ソリューション営業に特化した支援がほしい場合は、営業の依頼の言い方まで一緒に読み解けるかを確認してください。
判断軸④設計レビューだけを頼めるか
4つ目は「設計レビューだけを頼めるか」という判断軸です。分け方の案を自社で作れるなら、外部に必要なのは案の確認だけという場合があります。
構築まで一括で請け負う形しか用意していない支援会社では、この頼み方ができません。工程を切り出して依頼できるかどうかは、着手前に確認しておく項目にあたります。
この建築金物の商社も、記述の書き分けとアクションの配線は情報システム部の2名で進められる見通しでした。判断に迷ったのは、9本と4本のどちらが妥当かという分け方の妥当性だけです。
自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、工程を切り出した依頼を受けているかを確認しましょう。支援会社の選び方の全体像は、Agentforce導入支援会社で7つの見極め方として整理しています。
【一問一答】サブエージェントの設計に関するよくある質問
ここまで、分ける基準から外部支援の判断軸までを整理してきました。設計を実際に進める段階では、上限や名称、担当の分担といった細かい点で手が止まります。こうした点は、判断を間違えても大きな手戻りにはならない一方で、確かめないまま進めると設計の前提がずれたままになってしまうのです。社内で分け方を説明するときにも、先に答えを持っておくと話が早く進みます。そこで最後に、サブエージェントの設計についてよく寄せられる質問を5つ取り上げます。
質問①サブエージェントは1体あたり何本まで作れますか？
1体のエージェントに配置できるサブエージェントの本数には上限があります。具体的な数値は提供状況にあわせて変わるため、2026年8月時点の値はAgent Scriptをご確認ください。この記事の例に挙げた建築金物の商社も、8週で1,204件の依頼を仕分けたうえで、最終的に4本へ寄せています。設計の段階では上限を目指すより、営業が業務として言い分けている数に合わせるほうが管理しやすくなります。
質問②トピックという表記はサブエージェントを指しますか？
同じものを指します。エージェントのtopicはsubagentと呼ばれるようになりましたが、この変更に機能の違いはありません。どのサブエージェントを使うかを判断する仕組みの名称も、Topic SelectorからAgent Routerへ変わっています。画面の表記とドキュメントのURLで新旧が混在する場合がありますが、設定する対象は同じです。この会社でも、担当者が取得したファイルの中では`topic`と書かれており、古い版ではないかと疑う場面がありました。
※参考記事はこちら
質問③サブエージェントの指示文はどこまで細かく書きますか？
判断が分かれる場面だけを書きます。同じ依頼に対して複数の返し方がありうるとき、どちらを選ぶかを決める1行に価値があります。この会社の指示文で判断の分かれる場面を扱っていた行はおよそ3割で、残る7割を削っても営業から挙がる回答の内容は変わりませんでした。禁止する行為は、条件を場合分けするより1文で置くほうが、行数を抑えられます。
質問④サブエージェントを分けても回答がずれるのはなぜですか？
分割設計とは別の層で揺れている可能性があります。この会社が8週ぶんを数えたときは、想定どおりに処理されていたのが58%で、残る42%は別の業務の手順へ流れていました。渡り先が想定どおりなら、原因は参照先のデータか、推論の設定にあります。どの層で揺れているかの切り分けは、Agentforceのモデル選択と推論制御で扱っていますので、ぜひ参考にしてもらえると嬉しいです。
質問⑤サブエージェントの設計は誰が担当するのがよいですか？
システムの担当者だけでは決めきれません。分ける単位は業務の単位であり、どこまでを同じ依頼として扱うかは、実際に依頼する部門しか判断できないためです。この会社も情報システム部は2名で、依頼の仕分けと分け直しの判断には営業側が関わっています。設定の作業はシステム側が担い、分け方の判断には利用する部門の担当者が同席する形が現実的です。
サブエージェントの設計は、担当者が依頼として口に出せる単位で決まる
サブエージェントの設計で最初に決めるのは、機能の割り当てではありません。ここまで見てきたとおり、営業や担当者が依頼として口に出せる業務のまとまりです。本記事では、分割単位を決める3つの基準から、1本にまとめたときの症状、分けすぎたときの負担、受け持ちの書き分け、指示文の線引き、標準アクションを配線する条件、分け直す5つのステップ、つまずく落とし穴、設計が進んだかを測る4つの指標、外部支援を使う判断軸までを、一連の流れとして整理してきました。
例に挙げた建築金物の商社は、1本に3業務を詰め込んだ状態から4本へ分け直し、想定した受け持ちへ渡る割合を58%から91%へ、指示文の反映にかかる日数を平均4.5日から0.5日へ変えています。作業にかけたのは3週間と38時間で、追加のライセンス費用は発生していません。設計を直すだけで動く範囲が、まだ残っている企業も多いのではないでしょうか。
合同会社クロスコムでは、ソリューション営業の業務プロセスに特化したAgentforceの導入・定着支援を行っています。1ユースケース×3ヶ月のスモールスタートプランから対応しており、無料相談も受け付けていますので、Agentforce導入・定着支援までお気軽にご相談ください。本記事で紹介した内容を、ぜひ自社の設計に合わせて活用し、少しでもお役に立てれば幸いです。