生産環境で LLM エージェント、特に ReAct パターンを採用しているシステムにおいて、リトライバジェットが大幅に無駄になっているという問題が指摘されています。200 タスクのベンチマーク結果によると、リトライの 90.8% が二度と成功しないエラーに対して行われていました。これはモデルの推論能力が不足しているためではなく、システムが実行時にモデルにツール名を任せているという設計上の欠陥が原因です。 通常の ReAct 実装では、LLM が生成したツール名を文字列として直接使用し、存在しないツール名の呼び出しに対してグローバルなリトライカウンターが動作します。この際、システムはそのエラーが永続的なものか一時的なエラーかを区別せず、不存在のツールに対して何度もリトライを試みます。その結果、本来ならネットワークタイムアウトやレートリミットといった実際の失敗に対応すべきリトライ余地が、幻覚による無効なリトライによって枯渇してしまいます。 この問題を解決するための構造的な改善策として三つのアプローチが提案されています。第一に、エラー発生時に分類を行うことです。永続的エラーと一時的エラーを明確に区別し、前者に対してはリトライを行わないようにします。第二に、グローバルなリトライカウンターに代えて、ツールごとに独立したサーキットブレーカーを導入することです。これにより、特定のツールの不調が他のツールの稼働を阻害するのを防ぎます。第三に、最も重要な構造変更として、ツールルーターをコード側の辞書参照に移行し、LLM に生成された文字列を直接使用しないようにする方針です。プラン時点でツール名を確定させることで、ツール名の幻覚を構造的に不可能にします。 これらの対策を適用した結果、無駄なリトライはゼロとなり、ステップ数の標準偏差が 3 分の 1 に低下するなど、実行の予測可能性が劇的に向上しました。成功率和の指標だけでは見えないリソースの浪費が是正され、SLA の遵守やコスト管理が確実に改善されます。実装においては、LangChain や AutoGen などの既存フレームワークでも、エラー分類とサーキットブレーカーの追加を容易に適用可能です。LLM の出力を推論プロセスに限定し、ツールの選別は堅牢なコード層に委ねることで、堅牢かつ効率的な AI エージェントを構築することが可能になります。