マルチエージェントとは？1体に任せるか複数に分けるかの判断と組み方の手順

AIエージェントを1体入れたあと、任せる業務を足すたびに指示文が長くなり、振り分けを誤る回答が目立ってきた経験はないでしょうか。マルチエージェントとは、1つの業務を依頼の単位に分け、それぞれを受け持つ複数のAIエージェントが判断を受け渡しながら仕上げる仕組みのことです。CRMの中で動くAgentforceのような製品でも組める形ですが、体数を増やせば回答がよくなるわけではありません。分け方を誤ると、かえって誤りの原因を追えない状態に陥ることもあります。

そこで本記事では、1体に任せるか複数に分けるかを見分ける判断と、分けると決めた場合の組み方の手順を解説します。特定の開発ツールでの組み方には触れず、業務の側から分け方を決めたい担当者に向けた内容にしています。自社の問い合わせや受付の業務に重ねながら、読み進めてみてください。なお、製品の提供状況や単価は変わりやすいため、本記事の製品にかかわる記述は2026年9月時点で確認できた情報にもとづいています。

マルチエージェントとシングルエージェントの3つの違い

マルチエージェントは、AIエージェントを複数そろえることだと受け取られがちです。しかし体数の多さは違いのごく一部で、1体に任せる形との差は、業務の持たせ方と判断の渡し方、誤りが出たときの追い方に表れます。今回は、業務用の厨房機器を飲食店やホテルへ販売する会社のケースも交えて進めていきます。この企業は説明のための架空の設定であり、実在の企業ではありません。

この販売会社は、営業22名、カスタマーサポート12名、情報システム3名を含む従業員340名の会社です。取引先と納入した機器の記録は、導入済みのSalesforceにまとめていました。問い合わせの一次対応を任せるエージェントを1体入れ、見積もり・在庫の確認・修理の受付という3つの業務をすべて持たせていたのが、この販売会社の出発点です。問い合わせの一次対応をどこで人へ渡すかは、カスタマーサポートのAIエージェントの記事で扱っています。そこでここでは、マルチエージェントとシングルエージェントの違いを、この販売会社の1体目を例に3つに分けて整理します。

違い①1体が受け持つ業務の幅

1つ目の違いは「1体が受け持つ業務の幅」です。1体のAIエージェントが目的に向けて手順を選んで動く仕組みは、エージェンティックAIと呼ばれます。マルチエージェントは、その仕組みを複数に分けて組み合わせた形です。シングルエージェントでは1体が届いた依頼をすべて引き受けるため、業務が増えるほど、その1体の指示文と参照先に条件を書き足していくことになります。一方でマルチエージェントは、業務ごとに受け持つエージェントを分け、1体が持つ範囲を1つの業務に絞る形をとります。

この販売会社の1体目は、見積もりの依頼にも、在庫の問い合わせにも、修理の申し込みにも、同じ指示文で答えていました。導入した当初は、在庫の確認だけを任せる予定だったのです。ところがカスタマーサポートから「見積もりも一緒に受けられないか」という要望が出て、その後に修理の受付も加わっています。業務を足すたびに指示文の末尾へ条件を書き加えていたため、どの条件がどの業務のために置かれたのかを、書いた本人以外は説明できない状態になっていました。

業務を足した回数を振り返ってみて、最初に想定した範囲をすでに超えているなら、1体に持たせる幅を見直す時期に来ていると判断できます。

違い②判断を次へ受け渡すかどうか

2つ目は「判断を次へ受け渡すかどうか」です。1体で動く形では、依頼を読んでから回答を返すまでの判断が、すべてその1体の中で完結します。マルチエージェントでは、あるエージェントが下した判断を次のエージェントへ渡し、受け取った側がその判断を前提に動く点が異なります。

たとえば、取引先から「来月の開店に合わせて製氷機を入れたいので、在庫があれば見積もりがほしい」という依頼が届いたとします。この販売会社の1体目は、在庫を確かめる手順と見積もりを作る手順を同じ指示文の中から選び、1回の応答で両方を返そうとしていました。在庫と見積もりを別のエージェントに分けていれば、在庫を確かめた側が「在庫あり、入荷は来週」という判断を見積もりの側へ渡します。見積もりの側は、その判断を読んでから金額を組み立てる流れになるわけです。

受け渡しがある形では、渡す判断の中身と書き方を決めておかないと、次のエージェントが前提を読み違えてしまいます。この受け渡しの設計は1体で動かすときには要らず、マルチエージェントに分けたときに新しく発生する作業です。

違い③失敗したときに原因を切り分けられるか

3つ目の違いは、回答を誤ったときに、どこで誤ったのかを切り分けられるかどうかです。1体で動かしている場合、誤りの原因が指示文のどこかにあるとは分かります。ただ、どの業務の条件が効いたのかまでは、記録から追えないことがほとんどです。

この販売会社でも、見積もりを頼んだ取引先に修理の受付番号が返ったことがありました。カスタマーサポートの責任者からは「なぜ見積もりの依頼が修理として扱われたのか？」と問われています。情報システムの担当が指示文を読み返しても、修理の条件が先に効いたのか、見積もりの条件が読まれなかったのかは分かりませんでした。結局、同じ依頼を打ち直して再現を試すしかなかったのです。

業務ごとに分けていれば、まずどのエージェントへ依頼が渡ったかを見ることで、振り分けの誤りか回答の誤りかを分けて考えられます。シングルとマルチの違いは体数よりも、誤りが出たときに、どの業務のどの判断を直せばよいかを記録から言えるかどうかに表れます。

なぜ分ける？マルチエージェントが要る3つの理由

前章では、1体に任せる形とマルチエージェントの違いを、業務の幅・判断の受け渡し・原因の切り分けの3点で見てきました。違いが分かっても、自社の業務を分けるべきかどうかは別の問題です。分けて得られるものが、分けたときに増える手間を上回るかどうかで決まります。この販売会社が1体目を分けると決めたのも、困っていた点が、1体のまま指示文を直しても解消しない種類のものだと分かったからでした。そこでここでは、マルチエージェントに分ける3つの理由を、この販売会社の経緯とあわせて解説します。

理由①1体の指示文が長くなると判断がぶれるから

分ける理由として最初に挙がるのは、1体に持たせる業務が増えるほど、どの条件に従えばよいかの判断がぶれやすくなることです。指示文に並ぶ条件が1つの業務の分だけなら、依頼に当てはまる条件はほぼ決まります。しかし3つの業務の条件が同じ指示文に並んでいれば、依頼が届くたびに、そのうちのどれを使うかを選び直すことになります。

この販売会社の1体目が受けていた問い合わせは月2,400件で、振り分けを誤った回答は月192件、割合にして8%にのぼっていました。誤りの多くは、見積もりの依頼を修理の受付として扱うものです。取引先の文面に「交換」や「部品」という語が入っていると、修理の条件が先に読まれていたのです。カスタマーサポートの担当は誤った回答を見つけるたびに取引先へ連絡し直しており、一次対応を任せたはずのエージェントが出した誤りの対応に時間を使っていました。そこでこの販売会社は、「問い合わせの一次対応を任せたまま、振り分けの誤りを人が見つけて直さなくて済む状態にすること」を、1体目を見直す目的に定めました。

誤りの割合が指示文を書き足した時期に合わせて増えているなら、原因は書き方の細部よりも、1体に持たせた業務の数にあると考えます。

理由②業務ごとに見てよいデータが違うから

次の理由は、業務ごとに参照してよいデータの範囲が違うことです。1体にすべての業務を持たせると、その1体には、最も広い範囲を見る業務に合わせた権限を与えるしかありません。すると、狭い範囲だけを見ればよい業務の回答にも、本来は使わないデータが混ざるおそれが出てきます。

この販売会社の見積もりには、取引先ごとに決めている掛け率が使われていました。ある取引先の掛け率を、別の取引先に見せることはできません。一方で在庫の確認に要るのは、在庫の管理システムにある在庫数と入荷の予定だけです。修理の受付に要るのは、納入した機器の型番と保守契約の記録でした。3つの業務を1体にまとめていたために、在庫を尋ねただけの取引先にも、掛け率を読める状態のエージェントが答えていたことになります。

利用者やエージェントごとに見てよい範囲を分ける設定の考え方は、権限の設計として別に整理しています。業務ごとに参照するデータを並べたとき、重ならない部分が大きい業務どうしほど、分けたほうがそれぞれの権限を狭く保てます。

理由③直すときに影響の範囲を狭められるから

最後の理由は、指示文を直したときに、その影響が及ぶ範囲を狭く保てることです。1体の指示文を直すと、直した本人が見ていない業務の回答まで変わることがあります。業務ごとに分けておけば、修理の受付を直しても、見積もりや在庫の回答は変わりません。

そもそも、なぜ影響が広がるのかという話ですが、同じ指示文の中にある条件は、どの業務の依頼が届いても読まれるからです。この販売会社では、修理の受付に「急ぎの依頼には訪問の候補日を先に示す」という1文を足したことがありました。すると翌週から、見積もりの回答にまで候補日が書き込まれるようになったのです。修理の担当から出た要望に応えただけの1文でしたが、確かめたのは修理の回答だけで、見積もりへの影響は誰も見ていませんでした。

マルチエージェントに分ける理由は回答の精度を上げることより、1つの業務を直したときに、ほかの業務の回答が変わらない範囲を作ることにあります。

分けすぎ？1体で足りる業務の3つの条件

マルチエージェントに分ける理由を3つ挙げましたが、どの業務でも細かく分けたほうがよいわけではありません。分けた体数だけ、受け渡しの設計も、動きを確かめる手間も増えていきます。得られるものが少ない業務まで割ってしまうと、管理する対象だけが増える結果になります。この販売会社でも、情報システムの担当が最初に出した案では業務をさらに細かく割っていましたが、検討の中でいくつかを取り下げました。そこでここでは、マルチエージェントに分けず1体で足りる業務の3つの条件を整理します。

条件①入力と出力がそれぞれ1種類で済む

1つ目の条件は「入力と出力がそれぞれ1種類で済む」ことです。受け取る情報の形が決まっていて、返す答えの形も1つに決まる業務は、指示文が長くなりにくいものです。分けたとしても、エージェントの間で受け渡す情報がほとんど生まれません。

この販売会社では、在庫の確認がこの条件に当てはまる業務でした。情報システムの担当は当初、在庫数を答えるエージェントと、入荷の予定を答えるエージェントを分ける案を出していました。ところが、どちらも取引先から受け取るのは機器の型番で、返すのは在庫の有無と入荷の見込みを並べた1つの答えです。2体に分けると、同じ型番を2回照会して結果をまとめる作業が増えるだけだと分かり、在庫の確認は1体のまま持たせることにしました。

分ける案が出たときは、それぞれのエージェントが受け取る情報と返す情報を書き出し、両方とも同じ形になっていないかを確かめるとよいでしょう。

条件②判断が1回で終わる

2つ目に挙げるのは、判断が1回で終わる業務です。依頼を受けてから答えを返すまでに下す判断が1つしかなければ、その判断を次へ渡す相手がいません。分けても、受け渡しの手間だけが残ることになります。

修理の受付が、この形にあたりました。修理の申し込みを受けたときに下す判断は、その機器が保守契約の対象かどうかの1つです。対象なら訪問を手配し、対象外なら有償の修理として受け付けていました。この販売会社では、契約を確かめるエージェントと受付を登録するエージェントに分ける案も出ています。しかし契約の確認が済んだ時点で受付の中身もほぼ決まるため、2体に分ける理由は見当たりませんでした。

判断の数は作業の手順の数では数えず、担当者が途中で迷う場面がいくつあるかで数えます。迷う場面が1つだけなら、その業務は1体のままで足ります。

条件③参照するデータが1か所にまとまっている

3つ目は「参照するデータが1か所にまとまっている」ことです。業務の中で読むデータが同じ場所にあり、見てよい範囲も1通りで済むなら、分けて権限を狭くする必要は生まれません。

この販売会社の見積もりは、冷蔵機器・加熱機器・洗浄機器と扱う品目が多く、品目ごとにエージェントを分ける案が挙がっていました。ところが、どの品目でも参照するのはSalesforceにある取引先ごとの掛け率と価格表で、見てよい範囲も営業の担当と同じ1通りです。品目ごとに分けると、同じ掛け率を3体が読むことになります。そのため見積もりは、品目をまとめた1体として残しました。

入力と出力が1種類ずつで、判断が1回で終わり、参照するデータが1か所にまとまっている業務は、分けずに1体で持たせたほうが、確かめる手間も直す手間も少なく済みます。

4パターン｜マルチエージェントの組み方

1体で足りる業務の条件から外れ、分けると決めた業務では、次に複数のエージェントをどうつなぐかを選ぶことになります。つなぎ方は、依頼がどの順でエージェントの間を流れるかと、人がどこで確かめるかによって、おおむね4つのパターンに分けられます。この販売会社が組んだ形も、1つのパターンだけでできていたわけではありません。業務の性質に合わせて、複数のパターンを組み合わせていました。そこでここでは、マルチエージェントの組み方を4つのパターンに分けて解説していきます。

パターン①司令役が依頼を振り分ける

1つ目は「司令役が依頼を振り分ける」パターンです。依頼を最初に受けるエージェントが中身を読み、どの業務のエージェントへ渡すかを決めます。依頼の種類が多く、取引先の書き方もそろっていない問い合わせのような業務に向いており、マルチエージェントの組み方としては最も基本になる形と言えます。

この販売会社が問い合わせ対応で採ったのも、このパターンでした。見積もり・在庫の確認・修理の受付を受け持つ3体の前に、依頼を読み分ける司令役を1体置いています。取引先から届いた文面は、必ず司令役が先に受け取る形です。1体目のときに振り分けを誤っていた「交換」や「部品」を含む依頼も、司令役が業務の見分けだけを受け持つようになったことで、読み分ける条件を短く書けるようになりました。

司令役を置くかどうかは、依頼がどの業務のものかを、取引先の書き方からすぐには判断できない業務かどうかで決めると迷いません。

パターン②順番に受け渡して仕上げる

2つ目は、前のエージェントの出力を次のエージェントが受け取り、決まった順番で1つの成果物を仕上げていくパターンです。工程の順番が毎回同じで、前の工程の結果がなければ次へ進めない業務に向いています。

この販売会社では、在庫を前提にした見積もりの依頼がこの形にあたりました。司令役から渡された依頼を、まず在庫の確認を受け持つエージェントが受け取ります。在庫の有無と入荷の予定を判断してから、その結果を見積もりのエージェントへ渡す流れです。見積もりのエージェントは、入荷が先になる機器には納期の見込みを添えて金額を返すため、取引先が改めて納期を尋ね直す手間もなくなりました。

順番に受け渡すパターンでは、前のエージェントが誤ると、後ろのすべてが誤る点に注意が要ります。最初の工程が出した結果を人が確かめられる場所に残しておけば、誤りがどの工程で入ったのかを後から追えるようになります。

パターン③並行して分担し最後に集める

3つ目は「並行して分担し最後に集める」パターンです。1つの依頼に対して、別々のデータを調べる複数のエージェントを同時に動かし、それぞれの結果を最後に1つの回答へまとめます。調べる先が互いに独立しており、どれかの結果を待たずに進められる業務で使われる形です。

たとえば、この販売会社の修理の受付では、保守契約の記録を確かめる作業と、交換に使う部品の在庫を確かめる作業を、互いの結果を待たずに進められました。そこで修理の受付と在庫の確認を受け持つエージェントに、同時に依頼を渡しています。司令役が2つの結果を受け取ってから、訪問の可否と部品の見込みを1通の回答にまとめる形にしました。

並行して動かすと、回答までの待ち時間は短くなります。ただし集める側が2つの結果の食い違いに気づけなければ、矛盾した回答がそのまま取引先へ返ってしまうため、集める役を持たせるエージェントは先に決めておく必要があります。

パターン④人が途中で承認を挟む

4つ目は、エージェントの間の受け渡しの途中に、人が内容を確かめて承認する段階を置くパターンです。回答を送った後に取り消せない処理や、金額のように取引条件に関わる判断を含む業務では、エージェントだけで最後まで進めない形をとります。

この販売会社の見積もりでは、エージェントが組み立てた金額を取引先へ返す前に、担当の営業が内容を確かめる段階を残しました。見積もりの金額は掛け率と数量で決まるものの、開店の時期やほかの機器との組み合わせによって、営業が個別に調整してきた経緯があったためです。承認を挟む位置は、金額を出した直後の1か所に絞りました。在庫の確認や修理の受付の流れには挟んでいません。

組み方のパターンは、依頼がどの順でエージェントの間を流れるかと、取り消せない判断がどこにあるかの2点で選ぶと、業務ごとに迷わず決められます。

オーケストレーション｜司令役が持つ3つの仕事

4つの組み方のうち、この販売会社の問い合わせ対応で中心になったのは、司令役が依頼を振り分けるパターンでした。複数のエージェントの動きを取りまとめる働きはオーケストレーションと呼ばれ、マルチエージェントでは、この働きを受け持つ司令役の設計が全体の出来を大きく左右します。ところが司令役の役割を「依頼を渡すだけ」と捉えて組むと、結果をつなぐ仕事や途中で止める判断が、設計から抜け落ちかねません。そこでここでは、マルチエージェントの司令役が持つ3つの仕事を解説します。

仕事①依頼を読み分けて渡し先を決める

1つ目の仕事は「依頼を読み分けて渡し先を決める」ことです。司令役は依頼の文面から業務の種類を見分けて、受け持つエージェントへ渡します。ここで司令役に持たせるのは業務を見分ける条件だけで、見積もりの計算や在庫の照会の手順までは持たせません。

この販売会社で司令役の条件を書くときに最も時間をかけたのは、1つの依頼に2つの業務が含まれる文面の扱いでした。「製氷機の部品を交換したいので見積もりがほしい」という依頼は、修理の受付とも見積もりとも読めます。情報システムの担当はカスタマーサポートの担当と相談し、文面に故障や不具合を示す語があれば修理の受付へ、なければ見積もりへ渡す基準を決めました。この基準を、そのまま司令役の条件に書き込んでいます。

2つの業務にまたがる依頼をどちらへ渡すかは、エージェントに判断を任せる前に、業務を知る担当者が基準として決めておくべき事柄です。

仕事②各エージェントの結果をつなぐ

次に司令役が持つのは、複数のエージェントから返った結果を受け取り、取引先に返す1つの回答へつなぐ仕事です。受け持つエージェントがそれぞれ正しく答えていても、つなぎ方を決めていなければ、取引先には別々の回答が届いたり、同じ内容が繰り返されたりします。

先ほどの販売会社では、在庫を前提にした見積もりの依頼で、2体の結果を司令役がまとめていました。組み始めた頃は2つの結果を届いた順に並べるだけだったため、回答の冒頭に「在庫はありません」と書かれ、その下に金額が続く形になっていたのです。カスタマーサポートの担当から「在庫がないのに見積もりが出てくるのは読みにくい」という指摘があり、入荷の見込みを金額の直前に置く順番へ直しています。

結果をつなぐ順番は、エージェントが返した順ではなく、取引先が読む順で決めると回答が伝わりやすくなります。

仕事③止めて人へ戻す判断をする

最後の仕事は、エージェントに任せたまま進めてよいかを見きわめ、条件に当てはまる依頼を途中で止めて人へ戻す判断です。どれほど振り分けを正確にしても、エージェントでは答えられない依頼や、答えてはいけない依頼は必ず届きます。そうした依頼を最後まで進めると、誤った回答が取引先にそのまま届いてしまいます。

この販売会社が人へ戻す条件として決めたのは、保守契約の記録が見つからない修理の依頼と、値引きを求める見積もりの依頼の2つでした。どちらも、カスタマーサポートや営業の担当が取引先と話さなければ決められない内容です。司令役はこの2つに当てはまる依頼をエージェントへ渡さず、担当者の確認待ちの一覧へ送る形にしています。

自社で構築するので設計レビュー・アドバイザリーだけ頼みたい場合は、司令役の振り分けの条件と人へ戻す条件の2つに絞って、外部に見てもらう形を検討してください。司令役の仕事のうち後回しにされやすいのは止めて人へ戻す判断で、この条件を先に決めておかなければ、答えてはいけない依頼にまでエージェントが答えてしまいます。

マルチエージェントに分ける4つの手順

司令役が持つ3つの仕事までを見てきたところで、実際に1体を複数に分けていく作業の順番に移ります。分ける作業は、エージェントの画面での設定から始めたくなるものです。ところが、業務の見分け方やデータの線引きが決まらないまま設定に入ると、つないだ後に振り分けや権限を組み直す手戻りが生じかねません。そこでここでは、この販売会社が1体目を3体と司令役に分けたときの順番をもとに、マルチエージェントに分ける4つの手順を解説していきます。

手順①業務を依頼の単位で書き出す

最初の手順では、エージェントに任せている業務を、取引先が実際に送ってくる依頼の単位で書き出していきます。社内の部署や業務フローの単位で書き出してしまうと、1つの依頼が複数の業務にまたがる場合を見落とすからです。部署は同じでも依頼の中身が違う場合も、同じように見えなくなります。

この販売会社では、カスタマーサポートの担当が1体目に届いた依頼の文面を読み、取引先が何を求めているかで分類し直しました。部署の単位で見れば、見積もりは営業、修理の受付はカスタマーサポートの仕事です。ところが依頼の単位で並べてみると、在庫を確かめてから見積もりを求める依頼がまとまって存在していたことが分かっています。この分類があったために、在庫と見積もりを順番に受け渡すパターンを最初から組み込めました。

最初の1体でどの業務から任せるかの考え方は、業務の選び方にまとめています。ツール設定ではなく業務設計から入ってほしい場合は、依頼の単位で業務を書き出す段階から外部の支援を受けられるかどうかが、相談先を選ぶときの判断材料になります。

手順②見てよいデータで線を引く

業務を書き出したら、次はそれぞれの業務が参照してよいデータを並べ、重なりの少ないところで線を引きます。依頼の単位で分けた業務でも、同じデータを同じ範囲で見ているなら、1体に持たせたままのほうが扱いやすくなります。逆に、見てよい範囲が大きく違う業務どうしを1体に同居させる形は避けたいところです。

先ほどの販売会社では、見積もりは取引先ごとの掛け率、在庫の確認は在庫の管理システム、修理の受付は保守契約の記録を参照していました。3つの業務が見るデータはほとんど重なりません。とくに掛け率は見積もりの業務だけに閉じておく必要があったため、この3つをそのまま3体に分ける線になっています。司令役には依頼を読み分けるための文面と取引先の名前だけを見せ、掛け率や保守契約の記録は見せない設計にしました。

データで線を引いたあとに、線の内側に入る依頼の種類が多すぎると感じたら、手順①に戻って依頼の単位を見直すことをおすすめします。

手順③受け渡す情報の形を決める

線が引けたら、エージェントの間で受け渡す情報の形を決めます。何を渡すかを決めずにつなぐと、前のエージェントが文章で返した結果を次のエージェントがその都度読み解くことになり、そのたびに読み違いが起きやすくなります。

この販売会社は、司令役から各エージェントへ渡す情報を、取引先の名前・機器の型番・依頼の種類・急ぎかどうかの4つにそろえました。在庫から見積もりへ渡す情報も在庫の有無と入荷の予定日の2つに限り、「残りわずか」のような言い回しで返さない決まりにしています。この作業にはカスタマーサポートと情報システムの担当が一緒に取り組み、項目ごとにどんな値が入りうるかを一覧にしました。

受け渡す項目が決まったかどうかは、受け取る側のエージェントが項目の値だけを読んで、次に何をするかを1通りに決められるかで確かめられます。

手順④1体ずつ試してからつなぐ

最後の手順では、分けたエージェントをいきなりつながず、1体ずつ単独で試してからつないでいきます。最初からつないだ状態で試すと、誤った回答が出たときに、どのエージェントの誤りなのか、受け渡しの誤りなのかを見分けられないからです。

この販売会社は、見積もり・在庫の確認・修理の受付の3体を、それぞれ2週間ずつ単独で試しました。手順③で決めた形の情報を人が入力して動かし、返ってきた結果をカスタマーサポートの担当が確かめる進め方です。3体の結果が安定したことを確かめてから司令役とつなぎ、さらに4週間試しています。そのうえで、取引先からの問い合わせをすべて受ける形へ切り替えました。

小さく始めたい場合は、分けた業務のうち1つだけを1ユースケースとして単独で試し、結果を確かめてから次の業務へ広げるスモールスタートの進め方が合います。以上が、マルチエージェントに分ける4つの手順でした。マルチエージェントに分ける作業はつなぐところから始めず、業務を依頼の単位で書き出し、データで線を引き、受け渡す形を決めて1体ずつ試した後に、最後につなぐ順番で進めます。

なぜ噛み合わない？受け渡しで起きる3つの不具合

分ける4つの手順を見てきましたが、手順どおりに分けてつないだ後も、マルチエージェントの問い合わせ対応がすぐに安定するとは限りません。1体ずつ試した段階では問題がなかったエージェントどうしでも、つないだとたんに、受け渡しの部分で不具合が出てくることがあります。いずれも、1体のときには起きなかった種類のものです。この販売会社でも、つないで試した期間に、受け渡しにまつわる不具合が続けて見つかりました。そこでここでは、マルチエージェントの受け渡しで起きる3つの不具合を、この販売会社で見つかった順に整理します。

不具合①前の出力を次のエージェントが読み違える

1つ目は「前の出力を次のエージェントが読み違える」不具合です。受け渡す情報の形を決めていても、決めた項目の中に書き方の揺れが残っていることがあります。そうなると、受け取る側は揺れた値を別の意味に読んでしまいます。

この販売会社では、司令役が渡す「急ぎかどうか」の項目に、取引先の文面にあった「至急」「今週中」「開店前に」といった言葉をそのまま入れていました。修理のエージェントは「至急」だけを急ぎと読み、「開店前に」を急ぎとして扱いませんでした。そのため、開店の直前に故障した冷蔵庫の修理が、通常の順番で受け付けられています。取引先からの電話でこの件に気づいたカスタマーサポートの担当は、急ぎかどうかの項目に「急ぎ」と「通常」の2つの値だけを入れる決まりへ改めました。

受け取る側の読み違いは、渡す項目の数を増やすことより、1つの項目に入る値の種類を絞ることで防げます。

不具合②同じ確認を2体が重ねて行う

2つ目に挙げるのは、同じ確認を2体のエージェントが重ねて行ってしまう不具合です。分ける前は1体の中で1回だけ行っていた確認が、分けた後にそれぞれの指示文へ書き写されることがあります。そうなると、1つの依頼に対して同じ確認が二重に行われるようになります。

先ほどの販売会社で重なっていたのは、取引先との取引が続いているかどうかの確認でした。1体目の指示文にあった「取引が止まっている取引先には回答しない」という条件を、見積もりと在庫の両方のエージェントに書き写していたのです。その結果、在庫を前提にした見積もりの依頼では、同じ確認が二重に行われていました。片方が取引の状況を読み違えた依頼では、在庫の回答は返るのに見積もりは返らないという食い違いも起きています。

情報システムの担当はこの確認を司令役の1か所に寄せ、各エージェントの指示文からは外しました。指示文を書き写して分けるときは、先に条件を1行ずつ並べて持たせる先を書き込み、2体以上に割り当てた条件が残っていないかを確かめてからつなぎます。

不具合③どこで止まったのかが分からなくなる

3つ目は「どこで止まったのかが分からなくなる」不具合です。依頼がエージェントの間を渡る途中で止まり、取引先に回答が届かないまま時間が過ぎていく状態を指します。1体で動かしていれば回答がないことはその1体の不具合だと分かりますが、複数のエージェントを渡る形では、どこで止まったのかを探すところから始めることになります。

この販売会社でも、つないで試した期間に、修理を申し込んだ取引先から「受付の連絡が来ない」という問い合わせが入りました。情報システムの担当が調べると、司令役は修理のエージェントへ依頼を渡していたものの、修理のエージェントは部品の在庫の結果を待ったまま止まっていたのです。司令役も、その状態に気づいていませんでした。当時は取引先へ返した最終的な回答しか記録に残していなかったため、止まった場所を突き止めるまでに、依頼の流れを1つずつ追い直す必要がありました。

受け渡しの不具合は、各エージェントの回答の出来よりも、渡す値の決め方と、止まった場所を記録に残す設計が抜けていることから起きます。

マルチエージェントの動きを確かめる3つの記録

ここまで挙げた受け渡しの3つの不具合は、いずれも依頼がエージェントの間をどう流れたかが見えていれば、早い段階で気づけるものでした。そのため、つないだ後の運用に入る前に、マルチエージェントの動きを後から確かめられる記録を、設計の一部として組み込んでおく必要があります。この販売会社も不具合③をきっかけに、最終的な回答だけでなく、途中の受け渡しまで残す形へ記録を改めました。そこでここでは、マルチエージェントの動きを確かめるために残しておきたい3つの記録を解説します。

記録①どのエージェントへ渡ったか

当初の目的は「問い合わせの一次対応を任せたまま、振り分けの誤りを人が見つけて直さなくて済む状態にすること」でした。この目的を達成できたかどうかは、1つ目の記録である「どのエージェントへ渡ったか」を残していなければ測れません。

この販売会社では、司令役が依頼を渡すたびに、渡した先のエージェントとその依頼の文面を記録に残すようにしました。月末にカスタマーサポートの担当が記録を見直し、文面と渡し先が合っていない依頼を数えています。その結果、振り分けの誤りは1体のときの月192件から月48件へ、割合にして2%まで減っていました。残った誤りの多くは2つの業務にまたがる文面の依頼で、司令役の条件を見直す材料としてそのまま使われています。

渡し先の記録は、誤りを数えるためだけに残すものとは限りません。どの文面がどこへ渡ったかが並んでいれば、司令役の条件のどこを直せばよいかを、担当者が記録から直接読み取れるようになります。

記録②各エージェントが何を根拠に判断したか

2つ目に残すのは、各エージェントが回答を出すときに、どのデータを参照してどの条件に当てはめたかの記録です。渡し先が正しくても、受け持つエージェントが誤ったデータを根拠にしていれば回答は誤ります。渡し先の記録だけでは、原因の半分しか追えないのです。

この販売会社では、見積もりのエージェントが参照した掛け率と、在庫のエージェントから受け取った入荷の予定日を、回答とあわせて残させていました。ある取引先から「前回より高い」という指摘が届いたときも、情報システムの担当が記録を開くと、参照していたのが改定前の掛け率だとすぐに分かっています。原因は掛け率を更新する手順の漏れにあり、エージェントの指示文を直す必要はありませんでした。

判断の根拠を残す設計にしておくと、誤りの原因がエージェントの側にあるのか、参照したデータの側にあるのかを分けて考えられます。

記録③人へ戻した件数

3つ目は、司令役が止めて人へ戻した依頼の件数です。マルチエージェントの運用では、人へ戻す件数が少ないほどよいと考えがちです。しかし戻すべき依頼まで進めてしまえば、件数は減っても、取引先への誤った回答が増えてしまいます。

先ほどの販売会社で、分けた後に人へ戻した依頼は月120件で、問い合わせ全体の5%にあたりました。カスタマーサポートの担当は戻ってきた依頼を、保守契約の記録が見つからない修理と、値引きを求める見積もりに分けて数えています。どちらかが急に増えた月は、取引先の側で何かが変わった兆候として、営業とカスタマーサポートで理由を話し合う決まりにしました。

どこへ渡り、何を根拠に判断し、何件を人へ戻したかを記録から追う考え方は、稼働後の動きを測る指標の設計として別に整理しています。マルチエージェントの動きは、正しく答えた件数だけを見ても確かめられず、どこへ渡り、何を根拠に判断し、何件を人へ戻したかの3つを記録に残して、はじめて確かめられます。

Agentforceでマルチエージェントを組む3つの方法

ここまで見てきた分け方・組み方・記録の考え方は、特定の製品に限らず当てはまるものです。そのうえで、この販売会社のように取引先の記録をSalesforceで管理している会社には、Agentforceで組む方法も現実的な選択肢です。Agentforceで組む場合は、1体の中で分けるか、別のエージェントとして分けるか、社外のエージェントとつなぐかによって使う仕組みが変わり、確かめるべき提供状況も方法ごとに違ってきます。そこでここでは、マルチエージェントをAgentforceで組む3つの方法を整理します。

方法①トピックで1体の中を分ける

1つ目の方法は、1体のエージェントの中を、業務ごとの受け持ちに分ける形です。この受け持ちは以前はトピックと呼ばれ、現在はサブエージェントと呼ばれています。どの受け持ちに依頼を渡すかは、以前のTopic Selectorにあたる仕組みであるAgent Routerが判断します。名称が変わっても機能に違いはなく、受け持ちそれぞれに指示文と実行できる操作を持たせる点も同じです。受け持ちをどの粒度で分けるかは、トピックの設計で整理しています。

この販売会社がAgentforceで最初に組んだのも、この方法でした。見積もり・在庫の確認・修理の受付を1体の中の3つの受け持ちとして置き、それぞれの指示文と操作は、手順③で決めた受け渡しの形に合わせて書き分けています。依頼を読み分ける司令役の仕事①は、この振り分けの仕組みが受け持つことになりました。エージェントの数を増やさずに、ここまで見てきた分け方をそのまま当てはめられたわけです。

1体の中で分ける方法は、受け持ちを1つずつ足して境目を確かめられるため、手順④の1体ずつ試してからつなぐ進め方にも乗せやすい形です。

※参考記事はこちら

方法②サブエージェントに分ける

2つ目は、業務ごとに別のエージェントを作り、1体目のエージェントからサブエージェントとして呼び出す形です。同じ組織の中の別のエージェントは、Agentforce Builderの「Connect Agent as Subagent (Beta)」の項目から接続できます。その名称はConnected Subagentsで、接続したエージェントに付ける説明文が、どの依頼を渡すかの判断に使われます。1体の中の受け持ちにとどめず、判断ごと別のエージェントに任せられる点が、方法①との違いです。

この販売会社でも、保守契約の条件をよく知るカスタマーサポートの側で、修理の受付だけを別のエージェントとして運用する案を検討しました。ただ、検討した時点では項目名にBetaと付いていたため、本番の問い合わせをすべて載せる構成は避け、方法①のまま運用を始めています。

この仕組みの提供段階は変わるため、使う前には公式ドキュメントで最新の記載を確かめてください。切り出す業務を1つに限って試す形なら、仕様が変わっても直す範囲はその業務にとどまります。

※参考記事はこちら

方法③外部のエージェントとつなぐ

3つ目の方法では、社外のエージェントやツールとAgentforceのエージェントをつなぎます。つなぎ方には、Agentforceの側から外部のMCPサーバーのツールを使う向きと、外部のAIアシスタントの側からAgentforceのエージェントを呼び出す向きがあります。後者のホスト型MCPサーバーは、2026年4月29日にEnterprise Edition以上の組織を対象として正式提供へ移りました。これに対して前者の向きは、2026年8月時点で正式提供への移行を確認できていません。

この販売会社の在庫の確認は、在庫の管理システムとの既存の連携で動いており、方式を変える理由はありませんでした。社外のエージェントやツールとつなぐのは、在庫の管理システムの提供元が接続の仕組みを用意し、既存の連携では答えられない照会が出てきた時点で改めて検討すると決めています。

接続の向きごとの使い分けと提供段階の違いは、Agentforceの外部との接続の設計の中で比べています。マルチエージェントをAgentforceで組むときは、1体の中の受け持ちで足りるかを先に確かめ、足りない業務だけを別のエージェントや外部との接続へ出すと、提供段階が変わっても組み直す範囲を小さく抑えられます。

※参考記事はこちら

マルチエージェントを急がなくてよい3つの状況

Agentforceで組む3つの方法まで見てきましたが、どの会社にとっても、今すぐ1体目を複数に分けるのが正しいとは限りません。分ける作業は、1体目がすでに業務の中で使われ、手順と直す担当がそろっていることを前提にしています。この前提が欠けたまま分けると、つないだ後に出る不具合を直せる人がいない状態になってしまいます。この販売会社が分けると決めたのも、カスタマーサポートが1体目を毎日の対応に使い続け、誤りの記録が残っていたからでした。そこでここでは、マルチエージェントに分けるのを急がなくてよい3つの状況を解説していきます。

状況①最初の1体がまだ使われ続けていない

1つ目は、最初に入れた1体のエージェントが、まだ担当者の毎日の業務の中で使われ続けていない状況です。使われていない1体を複数に分けても、誤りの傾向を読む材料がありません。どこで分けるべきかを、依頼の記録から決められないのです。

この販売会社が分ける判断に使ったのは、カスタマーサポートの担当が1体目を毎日の対応に使い、誤った回答を見つけるたびに書き留めていた記録でした。どの業務の依頼がどの業務として扱われたかが残っていたからこそ、見積もりと修理の受付の境目で線を引く必要があると判断できています。1体目が使われていなかったなら、境目の位置も分からないまま、分け方を推測で決めることになっていたでしょう。

定着まで伴走してほしい場合は、分ける作業に入る前に、最初の1体が使われ続ける状態を作るところから支援を受けられるかどうかを確かめてください。自社で進める範囲と支援を頼む範囲の切り分けは、AIエージェント導入支援の記事で整理しています。

状況②業務の手順が文書になっていない

2つ目は、任せたい業務の手順が文書になっておらず、担当者の頭の中にだけある状況です。マルチエージェントに分けるには、業務ごとに受け持つ範囲と受け渡す情報を決める必要があります。手順が文書になっていなければ、その線をどこに引くかを話し合う材料がありません。

この販売会社では、修理の受付の手順は保守契約に合わせて文書になっていました。一方で見積もりの手順は営業ごとに少しずつ違い、掛け率を調整する条件も文書にはなっていなかったのです。そこで分ける作業に入る前に、営業の担当と情報システムの担当が見積もりの手順を文書にまとめています。人へ戻す条件として値引きの依頼を切り出したのも、この整理の中で決まったことでした。

手順を文書にする作業は社内の担当者にしかできないため、分ける時期は、その文書が業務ごとにそろった後に置くのが確実です。

状況③直す担当が1名しかいない

3つ目は、エージェントを直す担当が社内に1名しかいない状況です。マルチエージェントでは、エージェントの数だけ直す対象が増えます。受け渡しの不具合のように複数のエージェントをまたいで調べる作業も加わるため、担当が1名のままでは、不具合が重なった週に直す作業が止まってしまいます。

この販売会社の情報システムは3名で、分けた後は見積もり・在庫の確認・修理の受付のそれぞれに、主に直す担当を決めました。司令役の条件は、全員で見直す形をとっています。それでも、つないで試した期間に不具合①と不具合③が重なった週には、ほかの業務を後回しにして対応していました。

直す担当が1名しかいない会社は、まず1体のまま手順と記録を整え、担当を増やせる見通しが立ってから分けても遅くはありません。

【一問一答】マルチエージェントに関するよくある質問

急がなくてよい状況まで確かめたところで、最後に細かな疑問を整理しておきましょう。マルチエージェントを社内で検討し始めると、体数や費用、言葉の意味といった点で話が止まることがよくあります。答えを持たないまま進めれば、会議のたびに同じ質問が繰り返されてしまいます。この販売会社でも、分けると決めるまでの打ち合わせでは、体数と費用の質問が何度も出ていました。そこでここでは、マルチエージェントについて社内の検討で出やすい5つの質問に、ここまで見てきた販売会社の例を添えて答えていきます。

質問①マルチエージェントは何体から始めればよいのか

体数は先に決めるものではなく、業務を依頼の単位で書き出したときの業務の数で決まります。この記事の例でも、3つの業務に分けた結果が3体と司令役1体の構成になりました。3体はそれぞれ2週間ずつ単独で試してから、つないでいます。

質問②マルチエージェントにすると費用は1体より増えるのか

受け渡しの回数だけ処理が増える形で組むと、利用料もその分増えます。Agentforceの標準的なアクションは1回で20 Flex Credits（0.10ドル）を消費します。Flex Creditsの価格は10万クレジットで500ドルです（2026年9月時点）。この販売会社は月2,400件の問い合わせが各エージェントを何回通るかを数えてから、料金の考え方に沿って規模を見積もりました。※参考記事はこちら

質問③マルチエージェントとサブエージェントは同じ意味なのか

両者は、指す範囲が異なる言葉です。マルチエージェントは複数のエージェントに業務を分担させる考え方の全体を、サブエージェントはAgentforceでその分担を組むときの単位の1つを指します。この記事の例でも、3つの業務をAgentforceの1体の中の受け持ちとして組んでいます。考え方としてのマルチエージェントを、製品の中ではサブエージェントの形で実現したわけです。

質問④マルチエージェントは小さな業務でも必要なのか

入力と出力が1種類ずつで、判断が1回で終わり、参照するデータが1か所にまとまっている業務なら、分ける必要はありません。この販売会社でも、在庫の確認を2体に分ける案は採らず、1体のまま持たせています。小さな業務ほど、分けたときに増える受け渡しの設計の手間のほうが大きくなります。

質問⑤マルチエージェントの失敗に人はどこで気づけるのか

渡し先・判断の根拠・人へ戻した件数の3つを記録に残していれば、担当者は記録から気づけます。この販売会社では、人へ戻した月120件を種類ごとに数え、急に増えた月に理由を話し合う決まりにしました。一方で、最終的な回答しか残していなかった時期は、取引先からの問い合わせで初めて止まった依頼に気づいていました。

マルチエージェントは、業務を依頼の単位で分けたときにだけ1体より強くなる

マルチエージェントは、エージェントの数を増やせば回答がよくなる仕組みではありません。取引先が送ってくる依頼の単位で業務を分け、見てよいデータで線を引き、受け渡す情報の形を決めたときに、はじめて1体に任せる形より誤りを減らせるものです。この販売会社の当初の目的は「問い合わせの一次対応を任せたまま、振り分けの誤りを人が見つけて直さなくて済む状態にすること」でした。3体と司令役に分けた結果、振り分けの誤りは月192件から月48件へと144件減り、司令役が止めた依頼だけを担当者が確かめる形が続いています。

本記事では、1体に任せるか分けるかの判断から、分ける手順、受け渡しの不具合、Agentforceで組む方法までを整理しました。いずれも、エージェントの画面を開く前に、業務の側で決めておける内容です。1体目がすでに使われているなら、まずその記録から誤りの傾向を読み、分ける業務を1つに絞って試すことから始めてみてはいかがでしょうか。

合同会社クロスコムでは、1体目の次をどう分けるかの判断から司令役の条件の見直しまでを一緒に進める、Agentforceの導入・定着支援を提供しています。進め方は、1つの業務から小さく始める形です。無料相談も受け付けていますので、1体目の次の組み方で迷ったときは、Agentforce導入・定着支援までお気軽にご相談ください。本記事の整理が、自社の業務を分けるかどうかを社内で話し合う場面で少しでもお役に立てれば幸いです。