LLMカオスエンジニアリング入門 2026年版 — 生成AIアプリの障害注入テストとゲームデイ運用の判断軸

LLMOps・運用論2026.09.22

LLMアプリケーションの障害は、コード起因の障害だけでは説明できません。外部API・モデル出力・参照データ・ツール実行のどこが壊れても、体験が急に劣化します。

カオスエンジニアリング(chaos engineering)は、意図的に障害を注入して壊れ方を先に検証する運用手法です。この記事では、障害シナリオの選び方、ゲームデイ運用、確認すべき指標、企業導入で見る判断軸を整理します。

この記事でわかること

LLMアプリで起きる障害パターンと通常Web障害との違い
注入すべき障害シナリオの選び方と優先順位
ゲームデイ(定期的な障害演習)の準備・実施・振り返りの型
導入前チェックリストと運用開始後に見る指標
中堅企業でカオスエンジニアリングを始めるスモールスタート

結論サマリー：どの障害を先に試すか判断表で決める

障害の全パターンを最初から試そうとすると、準備コストが膨らみます。事業影響が大きい順に絞り込むために、次の判断表から始めます。

事業影響	最初に試す障害	想定される劣化	最初の演習で見る指標
LLM APIの停止・遅延	プロバイダAPIタイムアウト注入	全機能の応答遅延、失敗急増	エンド応答時間、フォールバック成功率
モデル切り替え時の品質差	別モデルへの強制ルーティング	幻覚率、出力形式ズレの増加	幻覚率、スキーマ違反率、ユーザー修正率
ツール実行の失敗	ツールAPIエラー・タイムアウト	エージェント停止、無限リトライ	ツール成功率、リトライ回数、失敗時UX
参照データの欠損・遅延	ベクトルDB遅延、空応答注入	回答品質低下、根拠なし応答	Retrieval成功率、根拠付き応答率
監視・アラート	オンコール気付き時間の演習	検知遅延、誤アラート、担当不在	検知〜初動までの時間、エスカレーション成功率

まず1〜2行を選び、開発環境またはステージング環境で小さく試します。

カオスエンジニアリングとは：LLMアプリ向けの読み方

カオスエンジニアリングは、意図的に障害を注入して、想定外の壊れ方を先に見つける運用手法です。従来はネットワーク遮断やインスタンス停止が中心でした。

生成AIアプリでは、コード障害に加えてモデル出力・参照データ・ツール実行の失敗が加わります。従来型のダウン検知だけでは、静かな品質劣化を見逃します。

用語の整理

用語	意味
カオスエンジニアリング	障害を意図的に注入し、システムの壊れ方を先に検証する運用手法
障害注入(fault injection)	ネットワーク遅延やエラー応答を人為的に発生させること
ゲームデイ	障害を注入し、対応チームが実際に動く定期演習
ブラストラディウス	演習の影響範囲。ユーザー数・機能・データを限定した範囲を指す
フォールバック	主モデルやツールが失敗した際に切り替える代替経路

通常のWeb障害演習との違い

通常Web: サーバ停止、DB遅延、ネットワーク遮断が主な対象
LLMアプリ: モデル切替時の品質差、ツール実行失敗、参照データ欠損も対象
LLMアプリ: 落ちない代わりに「意味が壊れる」障害が多い
LLMアプリ: 監視項目に正答率、幻覚率、スキーマ違反率が加わる

なぜ今LLMカオスエンジニアリングが重要か

LLMアプリの本番導入が広がる中、体験の壊れ方が事前に見えないまま公開される事例が増えました。テストだけでは、外部依存の障害を再現しづらいのが理由です。

事業判断の観点でも、次の点が背景にあります。

主要LLMプロバイダのAPI障害・レート制限は年に複数回発生している
モデルのバージョン切り替え時に、出力形式や品質が変わる
ツール連携が増えるほど、ツール側障害の影響が読みにくくなる
監視を入れても、アラートに気付く導線が整っていない

障害演習は「壊れないシステムを作る」ためではなく、壊れたときにどう動くかをチームで揃えるためのものと捉えます。

判断軸：注入する障害の選び方

障害を選ぶ際は、事業影響、再現の難易度、演習の学びやすさで並べます。ここではLLMアプリでよく使う7種類を整理します。

概要比較

障害種別	一言でいうと	向くケース	注意点
LLM APIタイムアウト	プロバイダAPIの遅延・停止を再現	主モデル依存が大きいアプリ	本番APIには注入しない
モデル強制切替	フォールバック先モデルに固定	マルチモデル構成を組んでいる	品質差の指標を先に決める
ツール実行失敗	外部ツールAPIをエラー化	エージェント型アプリ	リトライ回数の上限を設定
ベクトル検索失敗	Retrievalを空応答・遅延化	RAG系のアプリ	根拠なし応答の扱いを決める
プロンプト崩壊	プロンプトを一部破損させる	変更検出とロールバック演習	本番プロンプトは触らない
監視・アラート	通知経路を意図的に落とす	オンコール体制の演習	顧客影響のない時間帯で行う
データ権限違反	権限外データが混入する状況	ガバナンス・監査体制の演習	実データを使わず合成データで行う

実務判断の比較

比較軸	確認すること	実務上の意味
事業影響	停止・劣化した場合の売上・顧客影響	演習の優先順位を決める
再現しやすさ	開発・ステージングで作れるか	準備工数と定期化のしやすさ
学びやすさ	チームが指標や手順を持ち帰れるか	演習後の改善アクションにつながる
ブラストラディウス	影響範囲をどこまで限定できるか	顧客・本番データへの安全性
撤退容易性	演習を即時停止できるか	想定外の劣化への保険

演習は、優先順位が高く、ブラストラディウスを限定しやすい障害から始めます。

ゲームデイ運用の型

ゲームデイは、単発のテストではなく定期的な障害演習です。準備、実施、振り返りの3工程に分けて整理します。

準備フェーズ

対象アプリ、対象環境、演習時間帯を決める
注入する障害と、期待する挙動を明文化する
ブラストラディウス(影響範囲)を限定する条件を書く
撤退条件を先に決める(顧客影響が出た瞬間に停止する)
オンコール、開発、プロダクト、ステークホルダーの役割を割り当てる

実施フェーズ

障害注入は開発・ステージングから始め、慣れてから本番に段階的に広げる
記録係を1名置き、時系列でアクションと指標をログに残す
監視ダッシュボード、アラート、ユーザー影響をリアルタイムに確認する
撤退条件に触れたら、原因分析より復旧を優先する

振り返りフェーズ

障害検知〜初動〜復旧までの時系列を再構成する
想定と実際のズレを、非難ではなく学びとして整理する
チェックリスト、監視、フォールバック、プレイブックのどれを改善するか決める
改善アクションに担当と期限を付け、次回演習で確認する

演習は月次または四半期で回します。長期未演習の項目は、リスクの再評価対象にします。

実装・運用で確認すべき項目

導入前と運用開始後で見る項目を分けます。

導入前チェックリスト

演習対象アプリと影響範囲(ユーザー・データ・機能)が特定できるか
障害注入の手段(モックAPI、フィーチャーフラグ、ネットワークプロキシ)が用意できるか
撤退条件と復旧手順が言語化できているか
監視ダッシュボードで、正答率・幻覚率・スキーマ違反率が見られるか
フォールバック先モデル、代替ツール、キャッシュ経路が定義されているか
演習中の顧客・法務・情報セキュリティへの通知フローがあるか
実データではなく合成データで演習できるか

運用開始後に見る指標

検知時間: 障害注入から最初のアラートまでの時間
初動時間: 担当者がアクションを開始するまでの時間
復旧時間: 演習環境が正常状態に戻るまでの時間
フォールバック成功率: 代替経路が正しく動いた割合
品質劣化幅: 幻覚率、スキーマ違反率、ユーザー修正率の変化
演習改善アクション消化率: 前回演習の改善TODOがどれだけ完了したか

採用しないほうがよい条件

監視・ログ・フォールバック経路がまだ整っていない
演習の撤退手順がなく、影響範囲を限定できない
本番データにしか実データがなく、合成データで代替できない
演習を実施できる人員が1名しかおらず、属人化が強い
顧客・法務・セキュリティへの通知経路が未整備

これらは、ゲームデイより先に監視・フォールバック・体制の整備を行う判断につながります。

リスクと限界

カオスエンジニアリングは、万能な保険ではありません。実務では、次の限界を先に理解します。

演習で再現できる障害は一部で、未経験の障害はゼロにはならない
障害注入自体が新しい障害を生む可能性がある
過度に本番へ広げると、顧客影響とブランド毀損のリスクが上がる
演習指標だけを追うと、日常の品質改善が薄くなる
外部プロバイダの障害を完全に再現することはできない

避けたい断定表現:

演習を実施すれば障害率が◯%下がる
特定ツールを入れれば本番の壊れ方が事前に全て見える
カオスエンジニアリングがあれば、SLA未達を回避できる

※本記事は2026年9月時点の一般的な運用論としてまとめました。LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があるため、導入前に各プロバイダの公式情報で最新条件を確認してください。

Blackfordの見解：カオス演習を運用ループに接続する

Blackford Technologiesは、LLMカオスエンジニアリングを「単発の演習」で終わらせないことを重視します。業務設計、データ基盤、クラウド構成、運用責任と接続する運用ループとして捉えます。

企業導入で先に整理する観点は次の6つです。

業務課題: どの業務・どの顧客体験が壊れると事業影響が大きいか
扱うデータ: 顧客データ、機密データ、合成データの切り分け
評価指標: 幻覚率、スキーマ違反率、フォールバック成功率など
コスト上限: 演習に使うAPI費用、代替経路の維持費、監視ツール費
セキュリティ要件: 演習環境の権限、監査ログ、通知フロー
運用責任者: プロダクト、開発、SRE、セキュリティ、法務の役割分担

RAGや社内ナレッジ検索を扱う場合は、DataRoidやDataRoid Cloudで参照データの版管理とアクセス制御を運用ループに組み込みつつ、ベクトル検索障害と参照データ欠損の演習を優先します。導入後の伴走運用と改善提案を含めて設計したい場合は、AI開発・実装とAI導入後の運用・改善で障害演習の設計から運用体制までまとめて相談できます。

よくある質問

Q. カオスエンジニアリングは大企業だけのものですか？

A. いいえ、中堅・中小企業でも小さく始められます。まずは開発・ステージング環境で、外部API障害を注入する最小演習から始めるのが安全です。監視、フォールバック、撤退条件が揃っていない段階では、それらの整備を先に行います。

Q. 本番環境で障害注入して大丈夫ですか？

A. 段階を踏めば本番でも実施できますが、最初は避けたほうが安全です。まず開発・ステージングで手順と撤退条件を確立し、次にトラフィックを限定した本番、最後に全体という順で広げます。ブラストラディウスを限定できない段階では本番演習を行いません。

Q. LLM評価やモニタリングと何が違うのですか？

A. 評価とモニタリングは「起きたことを測る」仕組みです。カオスエンジニアリングは「起きる前に壊してみる」演習です。両者は補完関係にあり、ゲームデイの学びは評価・監視の改善に戻します。

Q. どのくらいの頻度で行えばよいですか？

A. 目安は、重要アプリで四半期に1回、業務クリティカルなアプリで月次です。頻度より、演習後の改善アクションを次回までに消化できることが重要です。改善TODOが積み上がると、演習が形骸化します。

Q. 外部ツールに頼らず始められますか？

A. 始められます。フィーチャーフラグとモックAPI、ネットワーク遅延を挟むシンプルなプロキシがあれば、最初の演習は組めます。ツール導入は演習が定期化してから、監視・注入・記録を統合したい段階で検討します。

まとめ：小さく始めて、運用ループに戻す

LLMカオスエンジニアリングは、生成AIアプリの壊れ方を先に見つけるための運用手法です。全障害を再現することはできませんが、事業影響が大きい順に演習を回すことで、対応チームの判断を揃えられます。

ただし、監視・フォールバック・撤退条件が整っていない段階での本番演習は、逆に事故を増やす可能性があります。開発・ステージングで小さく始め、運用ループに戻すことが現実的な進め方です。

自社アプリでどの障害から演習を始めるべきか、体制やクラウド構成を含めて整理したい場合は、業務課題とデータの取り扱いから相談してください。

＼LLM本番運用の障害演習設計を相談できます／ Blackfordに相談する

関連サービス: AI開発・実装、FDE・アフターサービス、DataRoid Cloud。