セルフホスト型AIエージェントでツール呼び出しが繰り返しループする原因は何ですか？

エージェントが進捗、失敗、完了を認識できず、同じアクションを選び続けると、ツール呼び出しのループが繰り返し発生します。

セルフホスト型エージェントは、結果が変わり得ないにもかかわらず、同じフォルダーを何度も検索したり、同じコマンドを再実行したり、同じファイルを開き直したり、同一のAPIリクエストを送信し続けたりすることがあります。目に見えるループは症状にすぎません。根本原因は、モデルの計画、ツールスキーマ、返された観測結果、保存されたエージェント状態、外部の再試行ラッパー、または終了ルールの欠如に潜んでいる可能性があります。これらの層を区別することが重要です。なぜなら、コンテキストウィンドウやターン上限を増やしても、ループを長引かせるだけで、原因を説明できない場合があるからです。

ループの兆候は、新しい状態を生まないアクションの反復です

正当なエージェントは、異なる引数を使ったり、新しい証拠を受け取った後に、同じツールを何度か呼び出すことがあります。一方、異常なループでは、タスクの状態、利用可能な証拠、予測される次のステップが実質的に変わらないまま、同等の呼び出しを繰り返します。

LangGraphは、意図しないサイクルを含め、停止条件に到達する前にステップを実行しすぎるワークフロー向けに、グラフの再帰制限を定めています。

見分けるポイントは、呼び出し回数そのものではありません。各呼び出しが新しい事実を生み出すか、リソースを変更するか、計画を絞り込むか、グラフを終端状態へ近づけるかどうかです。

ツール結果が曖昧だと、エージェントは何かが起きたか判断できません

ツールは、空の文字列、汎用的な成功メッセージ、不完全なペイロード、古いキャッシュ値、あるいは成功・再試行可能性・恒久的な失敗を明確に示さない人間向けのエラーを返すことがあります。

Model Context Protocolでは、ツール結果に明示的なエラー状態を設定することで、ツール実行エラーを区別しています。ランタイムがすべての結果を通常のテキストに平坦化すると、モデルは別の呼び出しが役立つかどうかを推測しなければなりません。

この問題が原因のループでは、安定した完了マーカーを含まない観測結果の後に、同じツールと引数が繰り返されることがよくあります。ツール自体は正常に動作していても、エージェントが計画を更新するにはレスポンスの契約が曖昧すぎる可能性があります。

状態の書き込みがエージェントの外部で成功しても、内部のメモリでは失敗することがあります

ファイルが作成されたり、データベースの行が更新されたり、サービスが再起動したりしても、エージェントに保存された状態がアクションを保留中のまま示していることがあります。そのため、次の推論ターンで完了済みの操作を繰り返してしまいます。

ReAct型エージェントは、推論、アクション、観測を交互に行い、観測結果によってアクション計画を更新します。観測結果が破棄されたり、誤ったツール呼び出しIDに割り当てられたり、途中で切り詰められたり、次のプロンプトから除外されたりすると、制御ループは前進に必要な証拠を失います。

この根本原因は、外部システムには進捗が見られる一方で、モデルに提示されたトレースには進捗がないという点で、モデルの混乱とは区別できます。正しい観測結果を使ってモデルのターンだけを再実行すると、次のアクションが変わることがよくあります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

再試行レイヤーによって、1回の失敗が同一呼び出しの複数回実行に変わることがあります

モデルは1回のツール呼び出しを要求していても、オーケストレーションフレームワーク、HTTPクライアント、キューワーカー、タスクランナーが複数回再試行することがあります。最終的なトレースは、モデル層で迷いが生じたように見えても、実際にはモデルより下の層で反復が起きている可能性があります。

Tenacityの再試行制御では、再試行するかどうかの判断と、停止条件および再試行判定を分離しています。広すぎる再試行ルールは、入力を変更しない限り成功しない決定的な検証エラー、権限エラー、形式不正の引数を繰り返す可能性があります。

同一のリクエストID、タイムスタンプ、例外クラス、モデルターン数を確認してください。1回のエージェントターン内で複数回実行されているなら、ランタイムによる再試行です。新しい推論ターンごとに1回ずつ実行されているなら、エージェントの計画または状態解釈に原因がある可能性が高くなります。

完了条件が弱いと、ツールルーターに制御が戻り続けます

エージェントが要求された副作用を完了していても、タスク全体が完了したことを示す機械可読な条件がない場合があります。ルーターは、さらにツールを使用できるモデルメッセージを検出し、制御をアクションノードへ戻します。

OpenAI Agents SDKには、実行が設定されたターン数を超えたときに例外を発生させる最大ターン数の境界があります。

ターン上限は被害を抑えますが、根本原因を特定するものではありません。トレースに成功したツール出力と、それに続く同等の呼び出しがある場合、通常は完了への遷移、最終回答へのルート、またはルーターが実際に確認する状態フィールドが不足しています。

ツールの説明によって、失敗後も同じ選択が促されることがあります

重複した機能を持つツール、曖昧な失敗時の動作、制限を示さず機能だけを強調した説明は、どのターンでも同じツールが最適に見える原因になります。

CrewAIは、反復制限と再試行制限を別々のエージェント制御として説明しています。これは、推論サイクルの反復と実行試行の反復が異なることを示しています。

この原因は、引数が少しずつ変化しているにもかかわらず、観測結果によってツールにアクセス権、範囲、必要なデータがないことが明らかになった後も、選択されるツールが変わらない場合に最も明確に現れます。この場合、ループは通信再試行ではなく、選択ポリシーの問題です。

コンテキストの喪失によって、呼び出しがすでに失敗した証拠が消えることがあります

長いトレース、大きなツールスキーマ、冗長な出力、ローカルモデルのコンテキスト制限によって、以前の失敗の詳細や完了マーカーが実効プロンプトの範囲外に押し出されることがあります。

するとエージェントには、元のタスクと現在のツール一覧は見えても、優先したアクションが不可能だと示す観測結果は見えません。不完全な履歴から同じ計画を再構築するため、自分の試行を忘れたように見えます。

ZimaSpaceのセルフホスト型自動化エージェントに関する記事は、関連する境界を示しています。ツールを増やすと機能は拡張できますが、信頼性の高いオーケストレーションには、コンパクトな状態、明示的な結果、実行範囲の制限が依然として必要です。

よくある質問

ツール呼び出しが繰り返されると、すべて無限ループですか？

いいえ。ページネーション、ポーリング、分割処理、反復検索では、同じツールを正当に再利用することがあります。重要なのは、呼び出しの間で引数、証拠、またはタスクの状態が変化しているかどうかです。

最大ターン数を増やせば問題は解決しますか？

いいえ。正当な長いワークフローを完了できるようになる一方で、進捗のないループに繰り返す時間を与えることにもなります。トレースには、検証可能な進捗条件または終了条件が必要です。

より強力なモデルなら、ツール呼び出しのループをなくせますか？

曖昧な観測結果をより適切に解釈できる可能性はありますが、返されなかった状態を復元したり、隠れたランタイム再試行を識別したり、ワークフローに存在しない停止条件を強制したりすることはできません。