単一の AI Agent を本番環境に投入した後、最もよくある悩みはシステム全体のダウンではありません。時折とんでもない回答を返す、あるステップで止まる、外部サービスの呼び出しに失敗する——しかも明確なエラースタックが残らないことがほとんどです。障害は想像以上に頻繁に起こります。Sierra チームが 2024 年に発表した τ-bench は、カスタマーサービスを模した環境で実測し、当時最強の function calling Agent（GPT-4o）でもタスク成功率は 50% 未満でした。清華大学などによる AgentBench（ICLR 2024）も 8 種類の環境で評価した結果、長期推論と指示遵守の能力不足が LLM Agent の実用性を阻む主因だと指摘しています。毎回ゼロからデバッグするのではなく、まず障害を「症状」で分類し、よくある原因と対処に照らし合わせて範囲を素早く絞り込みましょう。
本記事ではインシデントの重大度分類やポストモーテムのプロセスは扱わず、マルチエージェント協調にも触れません。単一 Agent の実行レベルで最も頻出するエラーだけに絞り、「症状・考えられる原因・初動対応」の 3 つの早見表——ハルシネーションと出力品質、API と外部依存、デッドロックと制御フロー——に整理しました。現場で止血するためのハンドブックとして、まず Agent を使える状態に戻し、根本対策はその後で検討することをおすすめします。
これは最も気づきにくい障害クラスです。プログラムはエラーを出さず、応答も流暢に読めるのに、内容が捏造されている。しかもモデルを替えれば解決すると期待してはいけません。Vectara の Hallucination Leaderboard は HHEM で「要約が原文に忠実か」を評価しており、2025 年 4 月版で最も優秀だった Gemini 2.0 Flash のハルシネーション率はわずか 0.7% でしたが、同年 11 月により大規模で難しいドメイン特化データセットに切り替えた後は全モデルで率が大幅に上昇し、首位でも 3.3% にとどまりました。「原文という根拠がある」制約付きタスクでさえゼロにできない以上、自由回答ではさらに高くなります。一方、フォーマットの問題には成熟したエンジニアリング的解決策があります。OpenAI が 2024 年 8 月に Structured Outputs を発表した際の評価では、プロンプトだけで複雑な JSON を要求した場合の準拠率は 40% 未満でしたが、スキーマ制約付きデコーディングを有効にした GPT-4o は 100% に達しました。診断の第一歩は、問題が「内容の正確性」なのか「フォーマット構造」なのかを切り分けることです。両者では対処の方向がまったく異なります。
| 症状 | 考えられる原因 | 初動対応 |
|---|---|---|
| 存在しないデータや出典を捏造する | 検索による根拠づけがない、temperature が高すぎる、プロンプトが「わからない」を許していない | RAG 検索と出典表示を追加；引用を必須化；temperature を下げる |
| 出力フォーマットが不安定（JSON が壊れる） | 構造化出力を使わず、モデルが自由生成している | function calling／JSON schema 制約に切り替え；出力検証と再試行を追加 |
| 質問と噛み合わない、指示を無視する | 長すぎる context の中で重要な指示が希釈されている | 重要指示を簡潔にして先頭へ；タスクを分解；1 回の context を短縮 |
| 同じ入力なのに回答がぶれる | temperature が高め、パラメータ未固定 | 一貫性が必要なタスクは temperature を下げ、パラメータを固定 |
Agent はほぼ必ず LLM API・外部ツール・社内サービスを呼び出しており、これら依存先の揺らぎは Agent 自体の問題と誤診されがちです。依存先の障害は例外ではなく常態です。2025 年に ACM ICPE で発表された実証研究は主要 LLM サービスの公開インシデント記録を分析し、復旧時間の中央値は OpenAI API が約 1.23 時間、Anthropic API が約 0.77 時間でした。つまり上流の 1 インシデントは数十分以上続くことが多く、リトライだけでは乗り切れないため、縮退運転（デグレード）プランが必須です。公式のエンジニアリング実践もこの現実を反映しており、OpenAI と Anthropic の SDK はいずれもタイムアウト・429・5xx エラーに対する指数バックオフ付き自動リトライ（デフォルト 2 回）を標準搭載しています。「上流は壊れるもの」を前提にした設計です。診断の鍵は「Agent の推論」と「呼び出し先」を切り分け、エラーがリクエスト送信の前と後のどちらで起きているかを確認することです。
| 症状 | 考えられる原因 | 初動対応 |
|---|---|---|
| 断続的なタイムアウト | 上流 API の遅延、ネットワークの揺らぎ、1 回のプロンプトが長すぎる | 適切な timeout と指数バックオフ再試行を設定；プロンプトを分割 |
| 突然大量の 429、レート制限 | 並列度が高すぎる、速度制御をしていない | rate limit とリクエストキューを導入；リクエストを分散；クォータ引き上げを申請 |
| ツールの返却フォーマット変更でパース失敗 | サードパーティ API の改版、フィールド欠落 | ツール出力を schema 検証；防御的パースと fallback を追加 |
| コストやレイテンシが急騰 | リトライストーム、context の際限ない膨張 | token 使用量を監視；リトライ上限を設定；会話履歴を定期的に圧縮 |
Agent が自律的にツールを呼び、複数ターンの推論を行えるようになると、止まらなくなる状態に陥り得ます。これは稀なケースではありません。AgentBench のエラー分析では「ターン上限超過」が最大の失敗タイプで、知識グラフタスクでは失敗の 67.9% を占めました。原因はまさに、堂々巡りとバックトラックのない長期プランニングです。さらに 2026 年の arXiv 研究《When Agents Do Not Stop》は 6,549 件のオープンソース LLM Agent プロジェクトを静的解析でスキャンし、47 プロジェクトに計 68 件の無限ループ欠陥を確認しました。最多カテゴリは「上限のないリトライ」と「上限のないツール呼び出し反復」で、主な影響は API コストの枯渇とサービス停止でした。この障害クラスのビジネス上の代償は、空回りで token を燃やし、ユーザーを待たせ続けることですが、ハルシネーションと比べて利点が一つあります。症状が明確で、監視で捕捉しやすいことです。
| 症状 | 考えられる原因 | 初動対応 |
|---|---|---|
| 同じツールを繰り返し呼び、無限ループに陥る | ステップ上限が未設定、モデルがタスク未完了と誤判定 | 最大ステップ／ターン上限を設定；「完了」条件を明確に定義 |
| あるステップで固まり応答しない | ツール呼び出しのブロッキング、timeout なしで外部応答を待機 | すべてのツール呼び出しに timeout を設定；超過時は中断 |
| 2 つのタスクが互いを待つ（デッドロック） | 共有リソースの競合、ロックが解放されない | リソースアクセスに順序と時間制限を設定；ロックの長時間保持を回避 |
| 途中中断後に状態が不整合 | チェックポイントがない、失敗時にロールバックしない | 冪等設計とチェックポイントを導入；失敗時に安全に再実行可能にする |
新しい障害に遭遇したら、3 つの質問で素早く切り分けます。第一に、これは「出力内容」の問題か「実行フロー」の問題か。第二に、エラーは Agent 自身の推論にあるのか、それとも呼び出している外部依存にあるのか。第三に、同じ入力で安定して再現するか。特に重要なのは第三の質問です。Agent の失敗はしばしば確率的だからです。τ-bench はまさにこのために pass^k という指標——連続 k 回すべて成功する確率——を提唱し、GPT-4o が小売カスタマーサービスのタスクを 8 回連続で全問成功する割合は 25% 未満だと実測しました。1 回の成功は信頼性とはほど遠いのです。この 3 問に答えられれば、障害を上記のいずれかのクラスに対応づけ、対処をそのまま適用できます。前提となるのは Agent 自身の十分な可観測性です。すべてのツール呼び出し・入出力・token 使用量を記録していなければ、どんなに優れた早見表も照合のしようがありません。
さらに重要なのは、切り分けた症状と対処を毎回チーム自身の早見表に追記していくことです。そうすれば障害対応はどんどん速くなり、同じ落とし穴を二度踏むこともなくなります。恩梯科技（Nerdtechnic）は AI 導入コンサルティングとカスタムシステム開発を提供し、単一 Agent のための可観測なログ、障害早見表、信頼性設計の構築を支援します。本番の AI を「動くだけ」でなく、長期的に安定して動き続けるものにしていきましょう。
これらの手法を自社に導入したいですか？
LINEで無料相談
技術共有
多くのブランドはチャネルごとに別々のAIボットを設置し、音声・チャット・CRMがかみ合わず、同じ顧客がつながりのない断片に分割されています。本記事では、CXMのチャネル横断統合を三層——統一顧客ビュー、システム統合、チャネル横断のオーケストレーション——として実データとともに読み解き、あらゆる接点が同一の顧客レコードの上に成り立つ仕組みを示します。
技術共有
会話が長くなるほど AI はなぜ高く、そして散漫になるのでしょうか。本稿は Chroma や Anthropic などの最新研究データをもとに、スライディングウィンドウ、要約圧縮（compaction）、分割による外部退避、重要情報のピン留めという四つの戦略と、その組み合わせ方を解き明かします。
技術共有
多くの企業は AI への権限委譲を白か黒かのスイッチとして扱い、全件を人が審査するか、すべてをシステムに自動で任せるかのどちらかになりがちです。しかし Gartner は、リスク管理の不足により agentic AI プロジェクトの 40% 超が 2027 年までに中止されると予測しています。本記事は人間工学と AI エージェントの実在する分級枠組みをもとに、全件人手審査から完全自律までの五段階の権限委譲の階段を示し、定量的な昇格基準と品質低下時のサーキットブレーカーによるフォールバックまでを扱います。
サポートが必要ですか？
ここをクリックしてお問い合わせください！
