マルチエージェントの本番運用で起きる問題と対策：ループ・誤ルーティング・ハンドオフ・待ち時間

2026.10.23公開
株式会社Laboro.AI　システムエンジニアリング部 シニアSYSPM　神山 龍
株式会社Laboro.AI　システムエンジニアリング部 部長　光岡 駿
株式会社Laboro.AI　機械学習エンジニアリング部 シニア機械学習エンジニア　田本 篤喜

概要

マルチエージェントシステムのデモは、うまく動いているように見えます。ところが本番に近づくにつれ、シングルエージェントでは起きなかった種類のトラブルが顔を出します。

司令役と専門エージェントが同じやり取りを繰り返す。誤った専門エージェントに仕事が回る。回答に誤りがあっても、どの段階が原因かわからない、など。

本記事では、私たちLaboro.AIの案件で実際に起きた問題と、その対処を整理します。マルチエージェントシステムの基本や構成の考え方は、以下のコラムで扱っています。

【関連】マルチエージェントシステムとは？仕組み・メリット・活用事例と、開発現場で見えた設計の要点

目次

・マルチエージェントの本番運用で、新たに生まれる問題
・ループ：やり取りが終わらないときの対処
・誤ルーティング：誤った専門エージェントを呼んでしまうとき
・原因の特定：どこで前提が崩れたのかを追う
・ハンドオフエラー：誤りを連鎖させない設計
・待ち時間と冗長さ：モデルと出力を役割で使い分ける
・まとめ：問題が起きる前提で、設計の段階から備える

マルチエージェントの本番運用で、新たに生まれる問題

シングルエージェントのRAGでも、「意図と異なるチャンク※を取得する」「複数の知識ソースの内容が矛盾する」といった原因で、誤った回答は起こります。

マルチエージェントでは、これに加えて次のような問題が生まれます。

• オーケストレーター（司令役）のルーティングの誤り
• 専門エージェント間でのプロンプトの用語・フォーマットの不整合
• 引き継ぎ時のコンテキストの欠落

厄介なのは、各コンポーネントを単体で見ると「正しく」動いているように見える点です。どこで前提が崩れたのかが、見えにくくなります。

以降では、問題ごとに具体的な対処を紹介します。なお、精度・セキュリティ・コストといったAIエージェント全般の運用上の注意点は、別のコラムで扱っています。

【関連】AIエージェント運用時の注意点：精度・セキュリティ・コストで失敗しないために

※チャンク：データや情報、あるいは言葉などの大きな塊を意味や処理のしやすい「小さなまとまり」に分割したもの

ループ：やり取りが終わらないときの対処

よく起きるのが、司令役の役割を担うエージェントと専門エージェントの間で、やり取りが繰り返されてしまうケースです。専門エージェントの回答を受けた司令役が、同じ質問で再度専門エージェントを呼び出し、やり取りが終わらなくなります。

対策として、私たちはプロンプトとシステムの二段構えで上限を設けています。

プロンプトでは、同じ質問での専門エージェントの呼び出しを2回までとし、解決しない場合は問い合わせ窓口を案内して終了するよう指示します。利用者への確認も、原則1回、多くとも2回までに制限します。

そのうえで、システム側でもやり取りの回数に上限を設けます。LLMは、プロンプトの指示を常に守るとは限りません。指示を守らなかった場合でも、強制的に打ち切れるようにしておくことが重要です。

誤ルーティング：誤った専門エージェントを呼んでしまうとき

もう1つの代表的な問題が、司令役が誤った専門エージェントを呼び出すケースです。特に、担当範囲が重なる領域で起きやすくなります。

対策の1つ目は、判断の手順をステップ・バイ・ステップで定義することです。具体的には、まず司令役自身が即答すべき内容かを確認し、必要な場合のみ利用者への確認を行ったうえで、専門エージェントを1つだけ選ばせます。LLMに考える順序を教える、Chain of Thought※1の考え方を応用しています。

2つ目は、紛らわしいケースを個別のルールとして明記することです。判断に迷いやすい具体例は、ワンショットプロンプティング※2で、例とともに指示に含めておきます。

3つ目は、検証です。LLM as a Judge※3を使った自動テストを作り、あるユースケースで想定どおりの専門エージェントが呼び出されているかまで確認します。ルールを変更するたびにこのテストを回せば、直したつもりが別のケースを壊す、という事態を防ぎやすくなります。

※1 Chain of Thought：結論に至るまでの思考の過程を段階的に示させる手法
※2 ワンショットプロンプティング：指示に1つ分の例を添えて、期待する出力の形を示す手法
※3 LLM as a Judge：LLM自身に、出力や判断の妥当性を評価させる手法

原因の特定：どこで前提が崩れたのかを追う

実際の案件では、オーケストレーター、専門エージェント、RAG、ツールまで含めて情報の流れを組み立てていました。そのため回答に誤りがあったとき、どの段階が原因かの特定に時間がかかる事例がありました。

対策として、1回の質問応答をスレッドIDで紐づけてログに出力する仕組みを整えました。ルーティングの結果と、各エージェントが使用したプロンプト・RAG・ツールを、時系列で追跡できます。これにより、ルーティングミス、プロンプトの不整合、引き継ぎの欠落のどこに原因があるのかを切り分けやすくなりました。

ポイントは、この仕組みを後付けにしないことです。ログの設計は、最初の構成を決める段階で一緒に決めておく項目だと考えています。

ハンドオフエラー：誤りを連鎖させない設計

マルチエージェントでは、各エージェント単体の応答精度が高くても、エージェント間で情報を受け渡す際の欠落や意図のずれが原因で、システム全体としては誤った結果になることがあります。これをハンドオフエラーと呼びます。

そのため、単体のテストに加えて、エージェント間の入出力、つまり「誰が何を渡し、何を受け取ったか」をログとして可視化し、どのエージェントの判断や情報伝達で問題が起きたのかを追える状態にしておくことを重視しています。

あわせて、あるエージェントが想定外の応答をした場合に、後続のエージェントへ誤りを連鎖させない設計も欠かせません。フォールバックや異常検知の仕組みを入れておくことで、精度を担保しやすくなります。

待ち時間と冗長さ：モデルと出力を役割で使い分ける

最後に、体感の問題です。あるプロジェクトでは、クライアントから「オーケストレーターと専門エージェントの1往復に時間がかかっているように感じる」「両者の回答が似通っていて冗長に見える」という声が上がりました。テキスト自体はストリーミングで表示していたものの、こうした印象が生まれたのです。

一方で、エージェント間のやり取りを画面に出さないと、利用者には画面がローディングしているだけに見えます。裏側で何が起きているのかが分からず、不安を与えてしまいます。

そこで、エージェント間のやり取りは画面上に見せて「裏側で処理が進んでいる」ことを伝えつつ、役割に応じてモデルと出力の粒度を分けました。

• タスクの振り分けや回答の統合判断を担うオーケストレーターには、応答は遅いものの推論能力の高いモデルを使い、全体を踏まえた要約を返させる
• 個別の処理を担う専門エージェントには、やや精度は劣るものの高速なモデルを使い、待ち時間を短縮しつつ詳細な回答を返させる
• Reasoning Effort※1で推論の深さを、Verbosity※2で出力の長さを、エージェントごとに調整する

これにより、計算コストと待ち時間を抑えながら、内容の重複による冗長さも解消しました。

※1 Reasoning Effort：モデルが回答の前に行う推論の深さを調整するパラメータ
※2 Verbosity：出力の詳細さ・長さを調整するパラメータ

まとめ：問題が起きる前提で、設計の段階から備える

ここまでの問題は、どれもデモの段階では見えにくく、本番に近づいて初めて表に出ます。ループには、プロンプトとシステムの二段構えで上限を設ける。誤ルーティングには、判断手順とルールを明文化し、自動テストで確かめる。原因の特定には、スレッドIDで紐づけたログを使う。ハンドオフエラーには、エージェント間の入出力を可視化し、誤りを連鎖させない仕組みを入れる。待ち時間と冗長さには、役割ごとにモデルと出力を使い分ける。対処はそれぞれ異なりますが、共通するのは、問題が起きてから足すのではなく、最初の構成を決める段階で一緒に設計しておくという考え方です。

マルチエージェントは、構成を決めて終わりではなく、運用で磨き込む領域です。私たちLaboro.AIは、AIエージェント／生成AIの開発で、ビジネス課題の整理からAIエージェントの設計・開発・本番運用までを一気通貫で支援しています。お気軽にご相談ください。

【関連】Laboro.AIのAI／カスタムAI開発

　

監修者

システムエンジニアリング部 部長　光岡 駿

東北大学理学部物理学科卒業後、仙台のアプリ・システム開発会社に入社。自身が主催する勉強会が宮城大学との共同研究へと発展。「仙台X-TECH イノベーションアワード2023」最終プレゼンター選出など、幅広い活動を通じてシステム開発の実践を積む。2023年、Laboro.AIに1人目のシステム開発エンジニアとして参画し、「AI×システム開発」の領域をリード。2025年9月期エンジニアリング部MVP受賞。2026年よりシステムエンジニアリング部 部長。