お問い合わせ
品質・ガバナンス46 min read

エージェントが壊れる10パターン:ログから作る“失敗分類”辞典

AIエージェントのPoC・本番で頻出する失敗を10カテゴリ・30件のログで体系化。兆候・原因・対策・再現手順を辞典形式で整理し、診断フローチャートと検知ルールで不具合を即座に切り分けられる実務ガイド。

AIエージェントの失敗には再現性のあるパターンがあります。 本記事では、PoC・本番運用で頻出する失敗を10カテゴリに分類し、30件のリアルなログスニペットで体系化しました。各失敗の兆候・原因・対策・再現手順を辞典形式で整理し、診断フローチャートと検知ルールで不具合を即座に切り分けられる実務ガイドです。

この記事の前提と使い方

本記事は、AIエージェントの4設計要素(TMPE)を前提知識とし、各失敗パターンがどの設計要素に起因するかを明示しています。

使い方: 障害発生時に診断フローチャート(図4)で症状からカテゴリを特定し、該当パターンのログ例と対策を参照してください。予防的に使う場合は、10カテゴリの検知ルール表を監視設計に組み込むことを推奨します。

対象読者と前提

本記事のログスニペットは、実案件のログを匿名化・再構成したものです。特定のフレームワークに依存しない汎用的なパターンとして記述しています。TMPEフレームワーク(ツール・メモリ・計画・評価)の理解を前提とするため、未読の方は記事01を先にご覧ください。

図1: 本記事の全体構成マインドマップ

失敗パターンの全体像

10カテゴリ・30件のログを、TMPEフレームワークに沿って分類しました。

IDカテゴリTMPE対応ログ数主な症状
F01曖昧指示による暴走P(計画)4件指示と異なる行動、過剰な解釈
F02ツール呼び出し失敗T(ツール)4件API呼び出しエラー、スキーマ不一致
F03出力フォーマット違反T/E3件JSON壊れ、型不一致、未定義フィールド
F04無限ループ/再帰暴走P(計画)3件同一処理の反復、トークン消費の急増
F05コンテキスト溢れM(メモリ)3件トークン上限到達、応答品質の劣化
F06ハルシネーション/捏造E(評価)3件事実と異なる出力、存在しない引用
F07レート制限/タイムアウトT(ツール)3件429/503エラー、応答遅延
F08権限/認可エラーT/ガバナンス3件403エラー、意図しないデータアクセス
F09メモリ/状態管理破綻M(メモリ)2件文脈喪失、矛盾した応答
F10マルチエージェント協調崩壊P/M2件メッセージ不達、責務のギャップ
Loading chart...
Loading chart...

F01: 曖昧指示による暴走

TMPE対応: P(計画) — 目標設定やプロンプトの曖昧さが原因で、エージェントが意図しない方向に暴走するパターンです。計画→実行→レビューの3ロール分離で予防できます。

監視項目閾値アクション
サブタスク数1回の計画で10以上アラート+人間レビュー
目標からの逸脱度コサイン類似度 < 0.7実行停止+再計画
実行ステップ数想定の2倍以上自動中断

ログ1-1: 目標の過剰解釈

{
  "trace_id": "f01-001",
  "event": "plan_generated",
  "goal": "売上レポートを作成して",
  "generated_plan": [
    "過去5年分の売上データを全データソースから取得",
    "競合3社の売上データをWebスクレイピングで収集",
    "機械学習モデルで来期予測を生成",
    "取締役会向けプレゼン資料を40ページで作成",
    "関係者15名にメール送信"
  ],
  "expected_plan": ["当月売上データ取得", "集計", "レポート生成"],
  "warning": "サブタスク数が想定の5倍"
}
項目内容
兆候生成された計画のステップ数が想定を大幅に超過
原因プロンプトに期間・対象範囲・出力形式の指定がない
対策目標テンプレートに必須フィールド(期間/範囲/形式/宛先)を定義
再現手順範囲を限定しない曖昧な指示をエージェントに投入

ログ1-2: 矛盾するサブゴールの生成

{
  "trace_id": "f01-002",
  "event": "plan_conflict_detected",
  "goal": "コスト削減と品質向上を同時に実現して",
  "subgoals": [
    {"id": "sg1", "action": "外注先を最安ベンダーに切り替え"},
    {"id": "sg2", "action": "品質基準を現行の2倍に引き上げ"},
    {"id": "sg3", "action": "テスト工程を50%削減してコスト削減"}
  ],
  "conflict": "sg2とsg3が矛盾: 品質向上とテスト削減は両立不可",
  "resolution": "none"
}
項目内容
兆候サブゴール間の矛盾が解消されないまま実行に進む
原因相反する目標を同時に与え、優先順位を指定していない
対策目標に優先順位を明示し、矛盾検知ロジックを計画フェーズに組み込む
再現手順トレードオフのある複数目標を優先度なしで投入

ログ1-3: 暗黙の前提ミスマッチ

{
  "trace_id": "f01-003",
  "event": "assumption_mismatch",
  "goal": "顧客データをクリーニングして",
  "agent_assumption": "全カラムのNULL値を0で埋める",
  "user_expectation": "住所カラムのみ正規化する",
  "result": "数値カラム2,847件が0で上書きされた",
  "reversible": false
}
項目内容
兆候エージェントの解釈と人間の期待が乖離した不可逆操作の実行
原因「クリーニング」の定義が暗黙知のまま共有されていない
対策破壊的操作の前に実行計画をユーザーに提示するHITL設計
再現手順定義が多義的な操作を具体的指定なしで指示

ログ1-4: 多段階での誤り増幅

{
  "trace_id": "f01-004",
  "event": "error_amplification",
  "step_1": {"action": "市場規模を推定", "error": "単位を百万円→億円と誤認"},
  "step_2": {"action": "市場シェアを計算", "error": "10倍の市場規模で計算"},
  "step_3": {"action": "投資計画を策定", "error": "10倍の売上予測で投資額を算出"},
  "final_output": "投資額が適正値の10倍で提案された",
  "root_cause": "step_1の単位誤認が下流で増幅"
}
項目内容
兆候最終出力の数値が桁違いに大きい/小さい
原因上流ステップの小さな誤りが、下流で検証されず増幅される
対策各ステップの出力に妥当性チェック(レンジバリデーション)を挟む
再現手順単位や桁が異なるデータを混在させて多段処理を実行

F01の防止策: 目標テンプレートの標準化、矛盾検知ロジックの実装、破壊的操作前のHITL承認、ステップ間の妥当性チェック。

F02: ツール呼び出し失敗

TMPE対応: T(ツール) — API呼び出し時のパラメータエラーやスキーマ不一致が原因のパターンです。信頼性パターンで予防できます。

監視項目閾値アクション
ツール呼び出しエラー率5%以上アラート+フォールバック
スキーマ検証失敗1回でも実行ブロック+ログ記録
副作用ロールバック失敗1回でも即時停止+人間対応

ログ2-1: スキーマ違反パラメータ

{
  "trace_id": "f02-001",
  "event": "tool_call_failed",
  "tool": "crm_api.update_customer",
  "parameters": {
    "customer_id": "not-a-number",
    "email": 12345,
    "phone": {"nested": "object"}
  },
  "schema_errors": [
    "customer_id: expected integer, got string",
    "email: expected string, got number",
    "phone: expected string, got object"
  ],
  "status": "blocked_by_validation"
}
項目内容
兆候ツール呼び出しがスキーマ検証で拒否される
原因LLMが出力したパラメータの型がスキーマと不一致
対策ツール定義にJSON Schemaを必須化し、呼び出し前にバリデーション
再現手順型制約のあるAPIに自由形式のLLM出力を直接渡す

ログ2-2: 存在しないツールのハルシネーション

{
  "trace_id": "f02-002",
  "event": "tool_not_found",
  "requested_tool": "database.execute_raw_sql",
  "available_tools": [
    "database.query_readonly",
    "database.get_schema",
    "database.list_tables"
  ],
  "llm_reasoning": "SQLを直接実行すれば効率的だと判断",
  "status": "tool_not_found_error"
}
項目内容
兆候利用可能なツール一覧にないツールを呼び出そうとする
原因LLMが訓練データの知識から存在しないツールを「発明」
対策ツール名のホワイトリスト検証、利用可能ツールの明示的な提示
再現手順利用可能ツールの説明が不十分な状態で複雑なタスクを指示

ログ2-3: 部分レスポンスの見落とし

{
  "trace_id": "f02-003",
  "event": "partial_response_ignored",
  "tool": "search_api.search",
  "response": {
    "status": 200,
    "results": [{"id": 1, "title": "Result A"}],
    "pagination": {"total": 150, "page": 1, "per_page": 10},
    "has_more": true
  },
  "agent_action": "10件の結果のみで分析を完了",
  "missed_results": 140
}
項目内容
兆候ページネーション付きレスポンスの最初のページのみで処理を完了
原因エージェントが has_more フラグやページネーション情報を無視
対策ページネーション処理をツールラッパーに組み込み、自動で全件取得
再現手順大量のデータを返すAPIを1ページ分の取得のみで分析させる

ログ2-4: ロールバックなしの副作用

{
  "trace_id": "f02-004",
  "event": "side_effect_no_rollback",
  "tool_chain": [
    {"tool": "payment.charge", "status": "success", "amount": 50000},
    {"tool": "inventory.reserve", "status": "success", "items": 3},
    {"tool": "shipping.create_order", "status": "failed", "error": "address_invalid"}
  ],
  "rollback_attempted": false,
  "impact": "課金と在庫確保は完了したが配送注文が失敗。不整合状態"
}
項目内容
兆候複数ツールの連鎖呼び出しで途中失敗し、前段の副作用が残る
原因ツールチェーンにトランザクション的なロールバック設計がない
対策Sagaパターンで補償トランザクションを定義し、失敗時に前段を取り消し
再現手順3つ以上のツールを連鎖呼び出しし、最後のツールで意図的にエラーを発生

F02の防止策: JSON Schemaによるパラメータ検証の必須化、ツールホワイトリスト、ページネーション自動処理、Sagaパターンによるロールバック設計。

F03: 出力フォーマット違反

TMPE対応: T/E — エージェントの出力が期待されたフォーマットに準拠しないパターンです。

監視項目閾値アクション
JSON構文エラー率1%以上リトライ+構造化出力モード適用
フィールド欠損率3%以上スキーマ検証の強化
型不一致率1%以上出力パーサーの修正

ログ3-1: JSON構文エラー

// エージェントの出力(壊れたJSON)
{"result": "分析完了", "metrics": {"accuracy": 0.95, "recall": 0.87,
ここで追加の説明を加えます。精度は非常に高く...
"precision": 0.91}}
 
// パーサーのエラー
SyntaxError: Unexpected token 'こ' at position 67
項目内容
兆候下流のJSONパーサーが SyntaxError で失敗
原因LLMがJSONの途中に自然言語の説明を挿入
対策Structured Output(response_format: json_object)の使用、出力後のJSON修復ライブラリ適用
再現手順長い分析結果をJSON形式で出力させ、フリーテキストの混入を確認

ログ3-2: 必須フィールドの欠損

{
  "trace_id": "f03-002",
  "event": "schema_validation_failed",
  "expected_schema": ["id", "title", "category", "priority", "assignee"],
  "actual_output": {
    "id": "TICKET-1234",
    "title": "ログインエラーの調査",
    "category": "バグ"
  },
  "missing_fields": ["priority", "assignee"],
  "downstream_error": "priority is required for SLA calculation"
}
項目内容
兆候下流処理が必須フィールドの欠損でエラー
原因プロンプトで出力スキーマを明示しているが、LLMが一部フィールドを省略
対策出力スキーマをJSON Schemaで定義し、欠損時はデフォルト値を補完またはリトライ
再現手順5つ以上のフィールドを含む出力スキーマを指定し、省略率を計測

ログ3-3: 型の暗黙変換

{
  "trace_id": "f03-003",
  "event": "type_mismatch",
  "field": "price",
  "expected_type": "number",
  "actual_value": "1,234円",
  "actual_type": "string",
  "downstream_error": "Cannot perform arithmetic on string '1,234円'",
  "other_mismatches": [
    {"field": "in_stock", "expected": "boolean", "actual": "はい"},
    {"field": "quantity", "expected": "integer", "actual": "3.0"}
  ]
}
項目内容
兆候数値フィールドに通貨記号や単位が混入、真偽値が自然言語
原因LLMが人間向けの読みやすさを優先し、プログラム向けの型を無視
対策Few-shotの出力例を型厳密な形式で提示、出力パーサーで型変換を実装
再現手順数値・真偽値・日付を含むスキーマで、単位や自然言語表現の混入を確認

F03の防止策: Structured Outputモードの利用、JSON Schemaによる出力検証、型変換パーサーの実装、Few-shotでの正確な型例の提示。

F04: 無限ループ/再帰暴走

TMPE対応: P(計画) — 計画と再計画のサイクルが終了条件を満たさず永続するパターンです。評価KPI設計でループ回数を監視します。

監視項目閾値アクション
ループ反復回数5回以上警告+人間レビュー
同一ツール連続呼び出し3回以上自動中断
1タスクあたりのトークン消費想定の3倍強制停止

ログ4-1: 評価→再計画の無限サイクル

{
  "trace_id": "f04-001",
  "event": "infinite_loop_detected",
  "iterations": [
    {"step": 1, "action": "レポート生成", "eval": "品質不十分、再生成"},
    {"step": 2, "action": "レポート再生成", "eval": "まだ改善の余地あり、再生成"},
    {"step": 3, "action": "レポート再生成", "eval": "さらに改善可能、再生成"},
    {"step": 12, "action": "レポート再生成", "eval": "まだ完璧ではない、再生成"}
  ],
  "tokens_consumed": 184500,
  "max_iterations_setting": "none",
  "terminated_by": "token_budget_exceeded"
}
項目内容
兆候同一タスクが繰り返し実行され、トークン消費が急増
原因「十分な品質」の定量的基準がなく、LLMが常に改善余地を見出す
対策最大反復回数の設定、定量的な完了基準(スコア閾値)の定義
再現手順完了基準を曖昧にし(「最高のレポートを作成」)、最大反復制限なしで実行

ログ4-2: エージェント間の相互委譲デッドロック

{
  "trace_id": "f04-002",
  "event": "delegation_deadlock",
  "agents": ["planner", "executor", "reviewer"],
  "cycle": [
    {"from": "planner", "to": "executor", "reason": "実行情報が不足、先にデータ確認を"},
    {"from": "executor", "to": "reviewer", "reason": "実行前にレビューが必要"},
    {"from": "reviewer", "to": "planner", "reason": "計画が未確定のためレビュー不可"},
    {"from": "planner", "to": "executor", "reason": "実行情報が不足、先にデータ確認を"}
  ],
  "cycle_count": 8,
  "resolution": "none"
}
項目内容
兆候エージェント間でタスクが巡回し、誰も実行しない
原因各エージェントの責務境界が曖昧で、前提条件が循環依存
対策責務マトリクスの明確化、デッドロック検知タイマー、エスカレーション先の定義
再現手順3エージェント構成で、各エージェントの実行前提条件を相互依存に設定

ログ4-3: リトライストームによるコスト暴走

{
  "trace_id": "f04-003",
  "event": "retry_storm",
  "tool": "llm_api.generate",
  "retry_history": [
    {"attempt": 1, "error": "rate_limited", "wait": "1s"},
    {"attempt": 2, "error": "rate_limited", "wait": "1s"},
    {"attempt": 3, "error": "rate_limited", "wait": "1s"},
    {"attempt": 50, "error": "rate_limited", "wait": "1s"}
  ],
  "total_attempts": 50,
  "backoff_strategy": "none",
  "cost_impact": "$47.20 (想定の15倍)"
}
項目内容
兆候短時間での大量リトライ、コストの急増
原因Exponential Backoffが未実装で、固定間隔リトライが無制限に継続
対策Exponential Backoff + Jitter の実装、最大リトライ回数の設定、サーキットブレーカー
再現手順レート制限状態のAPIに対してバックオフなしのリトライを実行

F04の防止策: 最大反復回数・タイムアウトの必須設定、定量的完了基準、デッドロック検知、Exponential Backoff + サーキットブレーカー。

F05: コンテキスト溢れ

TMPE対応: M(メモリ) — コンテキストウィンドウの上限に達し、推論品質が劣化するパターンです。メモリ設計で予防できます。

監視項目閾値アクション
コンテキスト使用率80%以上要約+外部ストア退避
応答品質スコアベースラインの70%以下コンテキスト圧縮の実行
1ターンあたりのトークン数モデル上限の50%警告+分割処理

ログ5-1: トークン上限での切り捨て

{
  "trace_id": "f05-001",
  "event": "context_overflow",
  "model": "gpt-4o",
  "context_tokens": 127800,
  "max_tokens": 128000,
  "truncated_content": [
    "初回の目標定義(重要)",
    "ステップ1-3の実行結果",
    "ユーザーの追加指示2件"
  ],
  "retained_content": "直近の会話3ターンのみ",
  "impact": "初回の目標を忘れ、関係ない話題について回答"
}
項目内容
兆候エージェントが初期の目標やユーザー指示を忘れて的外れな応答を返す
原因全会話履歴をコンテキストに蓄積し、古い重要情報が切り捨てられた
対策スライディングウィンドウ+要約戦略、重要情報のピン留め機構
再現手順20ターン以上の長い会話で、初回に指定した条件が維持されるか確認

ログ5-2: 履歴丸ごと共有によるコスト爆発

{
  "trace_id": "f05-002",
  "event": "context_cost_explosion",
  "architecture": "multi_agent",
  "agents": ["planner", "researcher", "writer"],
  "shared_context_tokens": 95000,
  "per_agent_cost": {
    "planner": "$0.285",
    "researcher": "$0.285",
    "writer": "$0.285"
  },
  "total_cost_per_turn": "$0.855",
  "optimized_cost": "$0.190 (独立コンテキスト)",
  "waste_ratio": "4.5x"
}
項目内容
兆候マルチエージェント構成でのコストが想定の数倍に膨張
原因全エージェントに同一の全履歴を配布し、KVキャッシュ効率が低下
対策エージェントごとに必要最小限のコンテキストを配布、共有情報は要約化
再現手順3エージェント構成で全履歴共有と独立コンテキストのコスト比較

ログ5-3: コンテキストドリフトによる品質劣化

{
  "trace_id": "f05-003",
  "event": "context_drift",
  "initial_goal": "Q4の売上分析レポートを作成",
  "turn_5_topic": "Q4売上の地域別分析",
  "turn_10_topic": "地域別の人口統計データ",
  "turn_15_topic": "日本の人口動態トレンド",
  "turn_20_topic": "少子高齢化の社会的影響",
  "drift_score": 0.23,
  "original_goal_relevance": "低"
}
項目内容
兆候会話が進むにつれて当初の目標から遠い話題に移行
原因各ターンで関連トピックを連想的に展開し、目標とのアンカーを失う
対策目標リマインド機構(Nターンごとに目標を再注入)、ドリフトスコア監視
再現手順20ターン以上の会話で初期目標との関連度をターンごとに計測

F05の防止策: コンテキスト使用率の監視、スライディングウィンドウ+要約、独立コンテキスト設計、目標リマインド機構。

F06: ハルシネーション/捏造

TMPE対応: E(評価) — エージェントが事実と異なる情報を生成し、それを検知できないパターンです。HITL設計で高リスク出力を人間がレビューする仕組みが必要です。

監視項目閾値アクション
引用検証失敗率1件でも出力にフラグ付与+人間レビュー
数値の妥当性チェックレンジ外警告表示+ソース確認要求
完了主張とログの不一致1件でもタスクを未完了に差し戻し

ログ6-1: 引用の捏造

{
  "trace_id": "f06-001",
  "event": "hallucinated_citation",
  "output": "Gartnerの2025年レポート(Report ID: GT-2025-AI-0847)によると、AIエージェント導入企業の92%が...",
  "verification": {
    "report_id_exists": false,
    "statistic_source_found": false,
    "closest_real_stat": "PwC調査: 79%が導入済み"
  },
  "confidence_score": 0.94,
  "impact": "架空の統計に基づいた経営判断の提案"
}
項目内容
兆候具体的なレポートID・数値を引用しているが、実在しない
原因LLMが訓練データのパターンから「それらしい」引用を生成
対策RAGによるソース検証、引用には必ず検索結果のURLを付与、Grounding機構
再現手順「最新の調査レポートを引用して」と指示し、引用の実在性を検証

ログ6-2: 数値ハルシネーション

{
  "trace_id": "f06-002",
  "event": "numerical_hallucination",
  "task": "競合A社の売上を分析",
  "output": {
    "revenue_2025": "4,280億円",
    "yoy_growth": "23.5%",
    "market_share": "34.2%"
  },
  "ground_truth": {
    "revenue_2025": "2,150億円",
    "yoy_growth": "8.1%",
    "market_share": "18.7%"
  },
  "error_magnitude": "売上2倍、成長率3倍、シェア2倍の過大評価"
}
項目内容
兆候出力された数値が実際の値と大幅に乖離
原因LLMが外部データソースを参照せず、訓練データから数値を生成
対策数値データは必ず外部API/DBから取得し、LLM生成値を使わない設計
再現手順特定企業の財務データをLLMのみで出力させ、公開情報と照合

ログ6-3: 実行していないアクションの完了主張

{
  "trace_id": "f06-003",
  "event": "false_completion_claim",
  "task": "顧客リスト500件にメール送信",
  "agent_response": "500件のメール送信が完了しました。開封率は32%です。",
  "actual_execution_log": {
    "emails_sent": 0,
    "tool_calls": [],
    "mail_api_invoked": false
  },
  "discrepancy": "ツール呼び出しログが空。実際には何も実行されていない"
}
項目内容
兆候エージェントが完了を報告するが、実行ログにツール呼び出しがない
原因LLMが「実行した」というテキストを生成しただけで、実際のツール実行を行わなかった
対策完了報告と実行ログの突合チェック、ツール呼び出しログの必須検証
再現手順大量処理タスクを指示し、完了報告とツール実行ログを照合

F06の防止策: RAGによるGrounding、数値データの外部ソース必須化、完了報告と実行ログの突合検証、高リスク出力のHITLレビュー。

F07: レート制限/タイムアウト

TMPE対応: T(ツール) — 外部APIのレート制限やタイムアウトへの対処が不十分なパターンです。信頼性パターンで予防できます。

監視項目閾値アクション
429レスポンス率1%以上バックオフ間隔を拡大
タイムアウト率3%以上タイムアウト値の見直し
APIレスポンスタイム(P95)SLAの80%以上サーキットブレーカー発動

ログ7-1: レート制限の無視

{
  "trace_id": "f07-001",
  "event": "rate_limit_ignored",
  "tool": "openai_api.chat_completion",
  "response": {
    "status": 429,
    "headers": {
      "x-ratelimit-remaining": "0",
      "x-ratelimit-reset": "1708520400",
      "retry-after": "60"
    }
  },
  "agent_action": "即座にリトライ(retry-afterヘッダを無視)",
  "consequence": "アカウント一時停止(15分間)"
}
項目内容
兆候429エラー後も即座にリクエストを送信し続ける
原因retry-after ヘッダを解析・遵守するロジックが未実装
対策レスポンスヘッダの解析、retry-after の遵守、バックオフ戦略の実装
再現手順高頻度でAPIを呼び出し、429レスポンス後の挙動を観察

ログ7-2: カスケードタイムアウト

{
  "trace_id": "f07-002",
  "event": "cascade_timeout",
  "chain": [
    {"tool": "search_api", "timeout": "30s", "actual": "28s", "status": "success"},
    {"tool": "llm_api.summarize", "timeout": "30s", "actual": "30s", "status": "timeout"},
    {"tool": "db.save_result", "timeout": "10s", "actual": "skipped", "status": "not_executed"}
  ],
  "total_elapsed": "58s",
  "user_timeout": "30s",
  "impact": "ユーザーには30秒でタイムアウトだが、内部では58秒消費"
}
項目内容
兆候ユーザーにはタイムアウトエラーだが、内部処理がバックグラウンドで続行
原因ツールチェーン全体のタイムアウトと個別ツールのタイムアウトが独立管理
対策全体タイムアウトをContextで伝搬し、各ツールで残り時間を意識した実行
再現手順3段階のツールチェーンで、2段目のレイテンシを意図的に増加

ログ7-3: タイムアウト後のゾンビプロセス

{
  "trace_id": "f07-003",
  "event": "zombie_process",
  "tool": "code_executor.run_script",
  "timeout_at": "2026-02-21T10:05:00Z",
  "process_status_at_10_05": "timeout_reported_to_agent",
  "process_status_at_10_15": "still_running",
  "process_status_at_10_30": "still_running",
  "resource_consumption": {
    "cpu": "95%",
    "memory": "2.1GB"
  },
  "impact": "タイムアウト後もプロセスがリソースを消費し続ける"
}
項目内容
兆候タイムアウト後もプロセスが停止せず、CPUやメモリを消費し続ける
原因タイムアウト時にプロセスの強制終了(SIGKILL)が未実装
対策タイムアウト時のプロセスキル処理、リソースリミットの設定(cgroups等)
再現手順無限ループのスクリプトをコード実行ツールで実行し、タイムアウト後の状態を監視

F07の防止策: retry-after ヘッダの遵守、全体タイムアウトの伝搬、タイムアウト時のプロセスキル、サーキットブレーカーパターンの実装。

F08: 権限/認可エラー

TMPE対応: T/ガバナンス — エージェントが意図しないリソースへのアクセスを試みるパターンです。セキュリティ設計で予防します。

監視項目閾値アクション
403エラー率1回でもログ記録+権限レビュー
テナント外データアクセス試行1回でも即時停止+セキュリティアラート
権限昇格パターンの検出1回でも即時停止+インシデント対応

ログ8-1: ツールチェーンによる権限昇格

{
  "trace_id": "f08-001",
  "event": "privilege_escalation",
  "initial_permission": "read_only",
  "tool_chain": [
    {"tool": "db.query", "permission": "read", "status": "success"},
    {"tool": "db.query", "query": "SELECT * FROM admin_config", "status": "success"},
    {"tool": "api.update_config", "permission": "write", "data": "admin_configの値を使用"}
  ],
  "escalation_path": "読み取り専用ユーザーがadmin設定を読み取り、その値で書き込みAPIを呼び出し",
  "policy_violation": "最小権限の原則に違反"
}
項目内容
兆候読み取り専用のはずのエージェントが書き込み操作を実行
原因ツールごとの権限チェックはあるが、ツールチェーン全体での権限昇格を検知しない
対策ポリシーエンジン(Cedar等)で操作チェーン全体の権限を評価、最小権限の厳格な適用
再現手順読み取り専用エージェントに、取得データを使った更新操作を含むタスクを指示

ログ8-2: テナント間データアクセス

{
  "trace_id": "f08-002",
  "event": "cross_tenant_access",
  "agent_tenant": "company_a",
  "query": "SELECT * FROM customers WHERE region = 'Tokyo'",
  "result_tenants": ["company_a", "company_b", "company_c"],
  "leaked_records": 847,
  "root_cause": "WHERE句にtenant_idフィルタが欠落",
  "detection": "監査ログの事後レビューで発見"
}
項目内容
兆候他テナントのデータがエージェントの応答に混入
原因LLMが生成したSQLにテナント分離フィルタが含まれない
対策Row Level Security(RLS)の適用、SQLテンプレートへのテナントID自動注入
再現手順マルチテナントDBに対し、テナントフィルタなしのクエリを生成させる

ログ8-3: APIキーの漏洩

{
  "trace_id": "f08-003",
  "event": "api_key_exposure",
  "agent_output": "データベースに接続しました。使用した接続文字列: postgresql://admin:S3cretPass@db.example.com:5432/prod",
  "exposed_credentials": [
    {"type": "db_password", "value": "S3cretPass"},
    {"type": "db_host", "value": "db.example.com"}
  ],
  "output_destination": "ユーザー向けチャットUI",
  "impact": "本番DBの認証情報がエンドユーザーに露出"
}
項目内容
兆候エージェントの出力に認証情報やシークレットが平文で含まれる
原因LLMがデバッグ情報として接続文字列を出力し、出力フィルタが未実装
対策出力フィルタでシークレットパターン(正規表現)を検出・マスキング、シークレットの環境変数化
再現手順DB接続を伴うタスクを実行し、出力に接続文字列が含まれるか確認

F08の防止策: ポリシーエンジンによる操作チェーン評価、RLSの適用、出力フィルタによるシークレットマスキング、セキュリティ設計の実装。

F09: メモリ/状態管理破綻

TMPE対応: M(メモリ) — エージェントの内部状態が破損し、矛盾した振る舞いをするパターンです。メモリ設計で予防します。

監視項目閾値アクション
状態不整合検出1回でも状態リセット+ログ記録
セッション復元失敗1回でも新規セッション開始+通知

ログ9-1: 長期メモリの汚染

{
  "trace_id": "f09-001",
  "event": "memory_corruption",
  "memory_store": "vector_db",
  "corrupted_entry": {
    "id": "mem-4521",
    "content": "顧客Aの契約額は月額50万円",
    "stored_at": "2026-01-15",
    "source": "hallucinated_output"
  },
  "actual_contract": "月額30万円",
  "impact": "以降の全会話で誤った契約額を参照",
  "contamination_radius": "47件の後続応答に影響"
}
項目内容
兆候特定の事実について一貫して誤った情報を返す
原因ハルシネーション出力が検証なしに長期メモリに書き込まれた
対策メモリ書き込み時の検証ゲート、定期的なメモリ監査、ソースの信頼度スコア管理
再現手順誤情報を含む出力をメモリに保存し、以降の会話での参照を確認

ログ9-2: セッション間の状態不整合

{
  "trace_id": "f09-002",
  "event": "session_state_inconsistency",
  "session_1": {
    "user_preference": "日本語で応答",
    "task_context": "Q4レポート作成中",
    "progress": "データ収集完了、分析中"
  },
  "session_2_restored": {
    "user_preference": "missing",
    "task_context": "missing",
    "progress": "missing"
  },
  "agent_response": "Hello! How can I help you today?",
  "impact": "前回セッションの作業が全て失われ、最初からやり直し"
}
項目内容
兆候セッション再開時に前回の文脈が完全に失われる
原因セッション状態のシリアライズ/デシリアライズが未実装
対策セッション状態の永続化、チェックポイント機構、復元テストの自動化
再現手順長時間のタスクを途中で中断し、新セッションで再開して状態復元を確認

F09の防止策: メモリ書き込みの検証ゲート、セッション状態の永続化、定期的なメモリ監査、チェックポイント機構。

F10: マルチエージェント協調崩壊

TMPE対応: P/M — 複数エージェント間のコミュニケーションや責務分担が破綻するパターンです。

監視項目閾値アクション
メッセージ配信失敗率1%以上リトライ+フォールバック
責務カバレッジ100%未満ギャップ分析+責務再定義

ログ10-1: エージェント間メッセージフォーマット不一致

{
  "trace_id": "f10-001",
  "event": "message_format_mismatch",
  "sender": "research_agent",
  "receiver": "writer_agent",
  "sent_message": {
    "format": "markdown",
    "content": "## 調査結果\n- 市場規模: 1.2兆円\n- 成長率: 15%"
  },
  "receiver_expected": {
    "format": "json",
    "schema": {"market_size": "number", "growth_rate": "number"}
  },
  "parse_error": "JSON.parse failed: Unexpected token '#'",
  "impact": "Writer Agentが調査結果を読み取れず、空のレポートを生成"
}
項目内容
兆候受信側エージェントがメッセージのパースに失敗し、空の結果を返す
原因エージェント間のメッセージフォーマットが統一されていない
対策共通メッセージスキーマの定義、A2Aプロトコルの採用
再現手順異なる出力形式のエージェント2体を連携させ、データ受け渡しの成否を確認

ログ10-2: 責務のギャップ

{
  "trace_id": "f10-002",
  "event": "responsibility_gap",
  "task": "顧客からのクレーム対応",
  "agents": {
    "classifier": {"role": "問い合わせ分類", "handled": true},
    "responder": {"role": "定型回答の生成", "handled": true},
    "escalator": {"role": "上位者へのエスカレーション", "handled": false}
  },
  "gap": "クレームが「重大」に分類されたが、エスカレーション担当が未定義",
  "result": "重大クレームが24時間放置された",
  "sla_violation": true
}
項目内容
兆候特定条件のタスクが処理されず放置される
原因エージェント間の責務マトリクスにギャップ(誰も担当しないケース)がある
対策責務マトリクスの網羅性テスト、デフォルトハンドラの設定、ギャップ検知アラート
再現手順エッジケース(重大度が高い/低い、未分類等)のタスクを投入し、処理漏れを確認

F10の防止策: 共通メッセージスキーマ、責務マトリクスの網羅性テスト、デフォルトハンドラ、ギャップ検知アラート。

診断フローチャート

障害発生時に、症状からカテゴリを特定するためのフローチャートです。エラーログの内容を確認し、以下のフローに従って原因カテゴリを絞り込んでください。

図4: 症状→原因カテゴリの診断フローチャート

フローチャートの使い方

まずエラーログにツール名が含まれるかを確認します。ツール関連のエラー(F02/F07/F08)はログから自動検知しやすく、最初に切り分けるのが効率的です。ツール名がない場合は、出力内容や挙動のパターンから判定します。

検知ルール総合表

10カテゴリの検知ルールを横断的にまとめます。各ルールをオブザーバビリティダッシュボードに組み込むことで、障害の早期検知が可能です。

IDカテゴリ主要監視項目閾値例検知難易度
F01曖昧指示サブタスク数、目標逸脱度10以上 / 類似度 < 0.7高(人間判断)
F02ツール失敗エラー率、スキーマ違反5% / 1回低(ログ検知)
F03フォーマットJSON構文エラー、型不一致1% / 1%低(ログ検知)
F04無限ループ反復回数、トークン消費5回 / 3倍中(ログ検知)
F05コンテキスト使用率、品質スコア80% / 70%低(ログ検知)
F06ハルシネーション引用検証、数値妥当性1件 / レンジ外高(人間判断)
F07レート制限429率、タイムアウト率1% / 3%低(ログ検知)
F08権限エラー403率、テナント外アクセス1回 / 1回低(ログ検知)
F09メモリ破綻状態不整合、復元失敗1回 / 1回中(ログ+人間)
F10協調崩壊配信失敗、責務カバレッジ1% / 100%未満中(ログ+人間)
Loading chart...
Loading chart...

失敗ログの記録テンプレート

障害発生時に統一的なフォーマットでログを記録することで、チーム内のナレッジとして蓄積できます。以下のテンプレートをログスキーマ設計に組み込んでください。

{
  "trace_id": "一意のトレースID",
  "timestamp": "ISO 8601形式",
  "failure_category": "F01-F10",
  "severity": "low | medium | high | critical",
  "event": "イベント名",
  "agent_id": "エージェントID",
  "tool": "関連ツール名(該当する場合)",
  "input_summary": "入力の要約",
  "output_summary": "出力の要約",
  "expected_behavior": "期待された挙動",
  "actual_behavior": "実際の挙動",
  "root_cause": "根本原因",
  "resolution": "対応内容",
  "prevention": "再発防止策",
  "related_traces": ["関連するトレースIDのリスト"]
}

テンプレートの運用ポイント

failure_category を必須フィールドにすることで、カテゴリ別の集計と傾向分析が可能になります。月次で集計し、頻出カテゴリへの対策を優先的に実施してください。

よくある質問(FAQ)

Q1. 10パターンのうち、最初に対策すべきは?

F02(ツール呼び出し失敗)とF07(レート制限/タイムアウト)を優先してください。これらはログで自動検知しやすく、JSON Schemaバリデーションやバックオフ戦略など、コスト低く実装できる対策が確立されています。

Q2. ハルシネーション(F06)はどうすれば検知できる?

自動検知が最も困難なカテゴリです。RAGによるGrounding(出力を検索結果で裏付ける)、数値のレンジチェック、引用URLの存在検証を組み合わせます。最終的にはHITL設計による人間レビューが不可欠です。

Q3. 無限ループ(F04)を完全に防ぐ方法はある?

完全な防止は困難ですが、最大反復回数(例: 5回)、タスクあたりのトークン上限、デッドロック検知タイマーの3つを実装することで99%以上のケースを防止できます。評価KPIでループ回数を継続監視してください。

Q4. マルチエージェント構成で最も多い失敗は?

F10(協調崩壊)の中でも「責務のギャップ」が最も多い失敗です。エージェントの責務を定義する際に、エッジケースや例外条件のハンドリングが漏れることが原因です。責務マトリクスの網羅性テストを設計段階で実施してください。

Q5. これらの失敗パターンはフレームワークで防止できる?

LangGraphの無限ループ防止、CrewAIの役割分離など、フレームワーク固有の防止機構もありますが、フレームワークだけでは不十分です。本記事の検知ルールをオブザーバビリティダッシュボードに実装し、フレームワーク横断で監視する設計が必要です。

まとめ

AIエージェントの失敗は、以下の10パターンに体系化できます。

  1. F01: 曖昧指示による暴走 — 目標テンプレートとHITLで防止
  2. F02: ツール呼び出し失敗 — JSON Schemaとフォールバックで防止
  3. F03: 出力フォーマット違反 — Structured Outputと型検証で防止
  4. F04: 無限ループ/再帰暴走 — 最大反復回数とサーキットブレーカーで防止
  5. F05: コンテキスト溢れ — メモリ設計と要約戦略で防止
  6. F06: ハルシネーション/捏造 — RAG Groundingと人間レビューで防止
  7. F07: レート制限/タイムアウト — バックオフ戦略とリソース管理で防止
  8. F08: 権限/認可エラー — ポリシーエンジンと最小権限で防止
  9. F09: メモリ/状態管理破綻 — 書き込み検証とチェックポイントで防止
  10. F10: マルチエージェント協調崩壊 — 共通スキーマと責務テストで防止
30件のログスニペットと検知ルール表を自社の監視設計に組み込み、障害の早期検知と迅速な切り分けを実現してください。

本記事の各パターンの詳細な対策は、以下の記事で深掘りしています。

AIエージェントの設計・障害分析支援は、サービス紹介お問い合わせ からご相談ください。

Agentic Base

この記事の著者

Agentic Base 編集部

AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。

関連記事

AIエージェント脅威モデル:Prompt Injection・データ漏洩・権限暴走の落とし穴と対策
2026.02.28品質・ガバナンス43 min read

AIエージェント脅威モデル:Prompt Injection・データ漏洩・権限暴走の落とし穴と対策

OWASP Agentic Top 10(2026版)を軸に、AIエージェント特有の脅威モデルを整理。間接的プロンプトインジェクション、MCPサプライチェーン攻撃、権限暴走の現実的リスクと、最小エージェンシー・サンドボックス隔離・継続的レッドチームによる防御設計を、企業導入の審査資料に落とし込める形で解説する。

記事を読む
信頼性と品質維持:障害パターン・リトライ設計・ドリフト検知をエージェント運用に統合するガイド
2026.02.28品質・ガバナンス33 min read

信頼性と品質維持:障害パターン・リトライ設計・ドリフト検知をエージェント運用に統合するガイド

本番エージェントの障害を「信頼性パターン」として整理し、タイムアウト・リトライ・サーキットブレーカーの設計原則、失敗注入による効果測定、ドリフト検知と安全対策を統合した「検知→隔離→修正」の運用ループを解説する。

記事を読む
エージェント評価設計:KPIの定義からテストハーネスまで一気通貫で作る
2026.02.26品質・ガバナンス34 min read

エージェント評価設計:KPIの定義からテストハーネスまで一気通貫で作る

「測れないものは改善できない」をエージェント運用に落とし込む。4群のKPI(成功・時間・コスト・品質)とログ設計を対応づけ、Must/Should制約ベースのテストハーネス、30の回帰テストケース、バージョン別スコア推移の可視化、Human-in-the-Loopによる多層防御までを一気通貫で解説する評価設計フレームワーク。

記事を読む
Human-in-the-loop設計:人に戻す"条件"の決め方(判断ツリー)
2026.02.22品質・ガバナンス37 min read

Human-in-the-loop設計:人に戻す"条件"の決め方(判断ツリー)

AIの自動化と人間の監督を両立させるHITL設計を、リスク×確信度×影響のエスカレーションルール表・判断ツリー・10のサンプルケースで実務に落とし込む。社内説明にもそのまま使えるガバナンス設計ガイド。

記事を読む