AIエージェントの失敗には再現性のあるパターンがあります。 本記事では、PoC・本番運用で頻出する失敗を10カテゴリに分類し、30件のリアルなログスニペットで体系化しました。各失敗の兆候・原因・対策・再現手順を辞典形式で整理し、診断フローチャートと検知ルールで不具合を即座に切り分けられる実務ガイドです。
この記事の前提と使い方
本記事は、AIエージェントの4設計要素(TMPE)を前提知識とし、各失敗パターンがどの設計要素に起因するかを明示しています。
使い方: 障害発生時に診断フローチャート(図4)で症状からカテゴリを特定し、該当パターンのログ例と対策を参照してください。予防的に使う場合は、10カテゴリの検知ルール表を監視設計に組み込むことを推奨します。
対象読者と前提
本記事のログスニペットは、実案件のログを匿名化・再構成したものです。特定のフレームワークに依存しない汎用的なパターンとして記述しています。TMPEフレームワーク(ツール・メモリ・計画・評価)の理解を前提とするため、未読の方は記事01を先にご覧ください。
失敗パターンの全体像
10カテゴリ・30件のログを、TMPEフレームワークに沿って分類しました。
| ID | カテゴリ | TMPE対応 | ログ数 | 主な症状 |
|---|---|---|---|---|
| F01 | 曖昧指示による暴走 | P(計画) | 4件 | 指示と異なる行動、過剰な解釈 |
| F02 | ツール呼び出し失敗 | T(ツール) | 4件 | API呼び出しエラー、スキーマ不一致 |
| F03 | 出力フォーマット違反 | T/E | 3件 | JSON壊れ、型不一致、未定義フィールド |
| F04 | 無限ループ/再帰暴走 | P(計画) | 3件 | 同一処理の反復、トークン消費の急増 |
| F05 | コンテキスト溢れ | M(メモリ) | 3件 | トークン上限到達、応答品質の劣化 |
| F06 | ハルシネーション/捏造 | E(評価) | 3件 | 事実と異なる出力、存在しない引用 |
| F07 | レート制限/タイムアウト | T(ツール) | 3件 | 429/503エラー、応答遅延 |
| F08 | 権限/認可エラー | T/ガバナンス | 3件 | 403エラー、意図しないデータアクセス |
| F09 | メモリ/状態管理破綻 | M(メモリ) | 2件 | 文脈喪失、矛盾した応答 |
| F10 | マルチエージェント協調崩壊 | P/M | 2件 | メッセージ不達、責務のギャップ |
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の防止策: 共通メッセージスキーマ、責務マトリクスの網羅性テスト、デフォルトハンドラ、ギャップ検知アラート。
診断フローチャート
障害発生時に、症状からカテゴリを特定するためのフローチャートです。エラーログの内容を確認し、以下のフローに従って原因カテゴリを絞り込んでください。
フローチャートの使い方
まずエラーログにツール名が含まれるかを確認します。ツール関連のエラー(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%未満 | 中(ログ+人間) |
失敗ログの記録テンプレート
障害発生時に統一的なフォーマットでログを記録することで、チーム内のナレッジとして蓄積できます。以下のテンプレートをログスキーマ設計に組み込んでください。
{
"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パターンに体系化できます。
- F01: 曖昧指示による暴走 — 目標テンプレートとHITLで防止
- F02: ツール呼び出し失敗 — JSON Schemaとフォールバックで防止
- F03: 出力フォーマット違反 — Structured Outputと型検証で防止
- F04: 無限ループ/再帰暴走 — 最大反復回数とサーキットブレーカーで防止
- F05: コンテキスト溢れ — メモリ設計と要約戦略で防止
- F06: ハルシネーション/捏造 — RAG Groundingと人間レビューで防止
- F07: レート制限/タイムアウト — バックオフ戦略とリソース管理で防止
- F08: 権限/認可エラー — ポリシーエンジンと最小権限で防止
- F09: メモリ/状態管理破綻 — 書き込み検証とチェックポイントで防止
- F10: マルチエージェント協調崩壊 — 共通スキーマと責務テストで防止
本記事の各パターンの詳細な対策は、以下の記事で深掘りしています。
- 計画設計 → 計画→実行→レビューの3ロール分離(F01/F04対策)
- メモリ設計 → 短期・長期・外部メモリの設計パターン(F05/F09対策)
- 人間監督 → Human-in-the-Loop設計(F06/F08対策)
- 可視化 → オブザーバビリティダッシュボード設計(ログスキーマ)
- 評価 → エージェント評価KPI設計(F04対策)
- 信頼性 → エージェント信頼性パターン(F02/F07対策)
- セキュリティ → エージェント脅威モデルとセキュリティ設計(F08対策)
AIエージェントの設計・障害分析支援は、サービス紹介 と お問い合わせ からご相談ください。
この記事の著者
Agentic Base 編集部
AIエージェントとWebメディア運用の知見を活かし、実践的なナレッジを発信しています。



