# 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]]) - **ハーネス(deterministic code)による誤り補正は、失敗モード分類上の「システム・運用失敗」を統計的に縮小できる具体的介入策である**: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] はツール/APIエラーやコスト起因劣化をシステム・運用失敗として分類するが、`Observability Engineering` 第21章の Query Assistant 事例(OpenAIが返すJSONの`COUNT`演算子に不要な`column`フィールドが含まれる構造誤りをプログラム的に除去)は、この種の失敗を「モデルを再訓練・再プロンプトする」のではなく「ハーネス側の後処理で機械的に補正する」ことでエラー率を25%から14%へ、その後のプロンプト改善と合わせて1%未満まで低減させた定量実例である。分類論が失敗の名前を与え、ハーネス補正はそれに対する最小コストの緩和策の1つを具体化する。(Source: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]], [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]]) → [[Harness Engineering]] - **「本番でのテスト(test in prod)」の必要性は、失敗モード分類と産業実装の双方から独立に導かれる**: LLM アプリケーションは環境・ユーザーをまたいで同じ挙動をしない可能性が高いため、伝統的な網羅的テストケースでは失敗を捕捉しきれないと `Observability Engineering` 第21章は述べる。これは [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] が指摘する「評価ギャップ・本番ギャップ」(評価時に発見できない失敗が本番で顕在化する)と同じ構造の問題を、別の語彙(harness / test in prod)で捉え直したものである。(Source: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]], [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]]) ## ユーザー拡張コードの信頼性 LLM が生成する拡張コードも、LLM アプリケーションの補助出力ではなく、テナント境界・資源制限・監査・ロールバックを必要とする本番コンポーネントである。ウェブ拡張論が挙げる無限ループ、クラッシュ、機密データ流出、サービス拒否は、本ページが既に記録する「生成されたコードやコマンドも本番システムの一部」という観察を、ユーザー向けソフトウェアの拡張実行へ広げる。(Source: [[@2026__jeremymorrell.dev__Extensible Software in the age of LLMs]], [[@2026__SREcon26 Americas__Taming the Unpredictable - Reliability in Chaos]]) ## 未解決の問い - ユーザーが LLM に生成させた拡張コードを、LLM アプリケーションの入力・コンテキスト・ツール失敗と同じ信頼性管理へ組み込むとき、どの実行境界と監査証跡を必須にすべきか。 - 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]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]] / [[@2026__jeremymorrell.dev__Extensible Software in the age of LLMs]] - 概念: [[エージェントシステム運用]] / [[LLM推論]] / [[運用障害分析]] / [[ディペンダビリティ]] / [[エージェント運用安全性]] / [[SRE Benchmark]] / [[Harness Engineering]] / [[LLM評価]] / [[ウェブ拡張型ソフトウェア]] / [[LLMネイティブソフトウェア]] - エンティティ: [[Vaishali Vinay]] / [[Microsoft]] / [[Honeycomb.io]] / [[Phillip Carter]] - 関連 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 エージェントによる変更増加、複雑システム、汎用緩和と継続的検証) - [[@2026__OReilly__Observability Engineering 2E - Chapter 21 Observability for Large Language Models]](Query Assistant のJSONバリデーション誤りをハーネス側で補正しエラー率を25%→14%→1%未満に低減した産業実例)