# LLMアプリケーション信頼性 ## 定義 LLMアプリケーション信頼性とは、LLM を意思決定支援、ワークフロー自動化、ツール呼び出し、マルチエージェントシステムに組み込んだとき、モデル出力だけでなく、入力、コンテキスト、状態管理、外部ツール、バージョン更新、コスト制約を含むシステム全体が安定して期待動作を保つ性質である。[[Vaishali Vinay]] は、LLM アプリケーションの隠れた失敗を「推論失敗」「入力・コンテキスト失敗」「システム・運用失敗」の 3 次元 15 種として整理し、LLM 信頼性をモデル中心問題ではなくシステムエンジニアリング問題として扱う必要を示した。(Source: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]) ## 横断的知見 - **LLM 本番信頼性の問題は「品質劣化の観測困難性」と「確率的実行エンジンの運用困難性」に分かれる**: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]] はルーティング・TPU 設定・コンパイラ精度バグが同じ品質劣化症状を生むことを示し、[[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] はその症状を幻覚・コンテキスト喪失・ツール/API エラー・コスト起因劣化などのアプリケーション層失敗へ拡張する。前者は本番障害の実例、後者は失敗面の分類であり、両者を合わせると「意味的品質は単一メトリクスで測れず、原因層もモデル内部に閉じない」ことが見える。(Source: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]], [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]) - **AgentOps の異常タクソノミーは、LLM アプリケーション失敗モードを運用サイクルへ落とす受け皿になる**: [[エージェントシステム運用]] は監視→異常検知→根本原因局所化→解決の 4 段階でエージェントシステムを運用対象にする。[[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] が列挙する計画崩壊、通信破綻、ツール呼び出しエラー、競合指示、コンテキスト喪失は、AgentOps 側では Intra-Agent / Inter-Agent 異常として運用検知・解決の対象になる。分類論は失敗の名前を与え、AgentOps はそれを継続運用の制御ループへ載せる。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]], [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]) - **LLM アプリケーション信頼性は「モデルが間違える」だけでなく「生成された変更が荷重を受ける」問題を含む**: Brush は、LLM やエージェントが書くコードやコマンドも本番システムの一部としてアウトエージを起こしうると述べる。これは Vaishali Vinay の失敗モード分類が扱うツール/API エラーやシステム・運用失敗を、開発・変更管理の側へ広げる観察である。LLM アプリケーション信頼性は、出力品質の評価だけでなく、エージェントが行った変更の継続的テスト、ロールバック、汎用緩和の検証まで含む。(Source: [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]], [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]) - **「能力の穴」は高リスク領域での LLM 適用を構造的に制限する**: ZEH の実測(GPT-5.2 が 127×82 を誤り、`((((())))))` がバランスしていると判断する)は、単純なサブタスクでの誤りが複雑タスク全体の失敗を引き起こすことを示す。ツール呼び出しを許可しても適切に使わず自力で計算してミスする事例は、[[ゼロエラー境界]] が信頼性の高い領域向け LLM 選定基準として有効であることを示唆する。(Source: [[joisino-LLMの能力の穴-2026]]) ## 未解決の問い - 15 種の失敗モードのうち、本番 LLM アプリケーションで頻度・ユーザー影響・検出困難性が最も大きいものはどれか。分類だけでなくリスク優先度を付けるには、どのような観測データとポストモーテムスキーマが必要か。 - コスト起因劣化（短いコンテキスト、小型モデル、低サンプリング、キャッシュ活用）は信頼性の一部として扱うべきだが、SLO/エラーバジェットのような既存 SRE 指標へどう写像できるか。 - 意味的オブザーバビリティは、幻覚、ドリフト、ツール非効率、ビジネスルール不整合をどの粒度で記録すべきか。プロンプト、コンテキスト、ツール呼び出し、出力、検証結果の完全トレースはプライバシー制約とどう両立するか。 - エージェントが生成したコード・設定・運用コマンドを「荷重を受ける変更」として扱うとき、どの段階で SLO、エラーバジェット、汎用緩和テストへ接続するべきか。 ## 関連 - ソース: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] / [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]] - 概念: [[エージェントシステム運用]] / [[LLM推論]] / [[運用障害分析]] / [[ディペンダビリティ]] / [[エージェント運用安全性]] / [[SRE Benchmark]] - エンティティ: [[Vaishali Vinay]] / [[Microsoft]] - 関連 MOC: [[LLM4SRE - MOC]] / [[AIOps - Failure Detection - MOC]] ## 出典 - [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]](LLM アプリケーションの 3 次元 15 失敗モード、評価ギャップ、本番ギャップ、設計原則) - [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]](本番 LLM 品質劣化のルーティング・設定・コンパイラ層事例) - [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]](AgentOps の運用サイクルと Intra-Agent / Inter-Agent 異常分類) - [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]](AI エージェントによる変更増加、複雑システム、汎用緩和と継続的検証)