カオステストとは？障害注入の実験設計とツール選定・本番実施の判断を実装者向けに解説

カオステストは、稼働中のシステムへ意図的に障害を注入し、あらかじめ立てた仮説どおりに耐えられるかを観測する検証手法です。壊れることを確かめるのではなく、壊れたときの挙動が想定と一致するかを測ります。この記事では、負荷テストや従来の障害試験との検査対象の違い、定常状態の数値化と影響範囲の広げ方、ネットワークからアプリケーション依存までのレイヤ別の注入手法、AWS FISやChaos Meshといったツールの守備範囲、そして本番環境で実施してよい組織条件と見送るべき構成を実装者の目線で整理します。

まとめ：カオステストが最初に暴くのは監視と切り戻しの穴

カオステストを導入して最初に見つかるのは、たいていシステムの欠陥ではありません。障害を注入したのにアラートが鳴らない、鳴ったが誰も気づかない、気づいたが切り戻し手順が古い。この3つが初回実験の典型的な収穫です。

だからこそ準備は監視から始まります。定常状態を数値で定義できないなら、結果を判定する基準が存在しない。「なんとなく大丈夫そうだった」で終わる実験に価値はありません。

手順は決まっています。仮説を1文で書き、定常状態の指標を決め、影響範囲を絞り、自動停止条件を設定してから注入する。この4点のうち自動停止条件を省いた実験が、そのまま本番障害へ転がります。ツールは目的で決まります。AWSリソースを止めたいならAWS Fault Injection Service、Kubernetes内部のPodやネットワークを触りたいならChaos MeshやLitmusChaosが射程。単一構成でリリースが手作業の環境なら、カオステストより先に整えるべきものがあります。その見送り条件も最終章で条件付きで明示します。

カオステストの定義と負荷テスト・従来の障害試験との検査対象の違い

同じ「壊して確かめる」でも、何を確かめているかが手法ごとに違います。ここを混ぜると、実験の設計が目的から外れます。

定常状態の逸脱を観測する実験という位置づけと4つの実施ステップ

カオスエンジニアリングの原則をまとめた principlesofchaos.org は、この手法を「本番環境の乱れた状況に耐えるシステムの能力への確信を築くために、システム上で実験する規律」と定義しています。鍵になるのは「テスト」ではなく「実験」という語です。テストは既知の性質が保たれているかを確認し、実験は未知の弱点を発見します。

同サイトが示す手順は4段階です。

1. システムが正常に動いていることを示す測定可能な出力を「定常状態」として定義する
2. 対照群と実験群の双方で、その定常状態が続くという仮説を立てる
3. サーバー障害やネットワーク断といった現実に起きる事象を変数として導入する
4. 対照群と実験群の定常状態に差が出るかを観測し、仮説を検証する

この4段階で最も飛ばされやすいのが1番目です。指標を決めずに障害だけ注入すると、何が起きても「システムは動いていた」と解釈できてしまいます。

負荷テストが測る限界値とカオステストが暴く依存関係の連鎖故障

負荷テストは正常な構成に対して入力量を増やし、どこで性能が崩れるかという限界値を測ります。前提となる構成そのものは壊しません。カオステストは逆で、入力量は通常のまま構成要素を欠損させます。

この差が効くのは、依存関係が連鎖して落ちる故障です。決済APIの応答が3秒遅れただけで、呼び出し側のスレッドプールが埋まり、無関係な商品一覧まで応答しなくなる。こうした波及は負荷試験のグラフには現れません。呼び出し側にタイムアウトとサーキットブレーカーが入っているかどうかは、遅延を注入して初めて判明します。

従来の障害試験（DR訓練やフェイルオーバー試験）との差は、対象の選び方にあります。従来型は「切り替わることが分かっている構成」を計画的に切り替えて手順を確認するもの。カオステストは「切り替わるはずだが誰も検証していない箇所」に仮説を立てて当てにいく行為です。稼働率の計算と高可用性の設計で冗長化を組んだ直後こそ、その冗長化が本当に機能するかを確かめる対象になります。

カオスエンジニアリングとの呼び分けと実務における用語の使い分け

日本語圏では「カオステスト」と「カオスエンジニアリング」がほぼ同義で使われます。PagerDutyの解説記事も両者を同じ手法の別名として扱っています。厳密に分けるなら、カオスエンジニアリングは仮説・観測・学習を回す継続的な取り組み全体を指し、カオステストはその中の個々の実験実行を指す語です。

社内の合意形成ではこの呼び分けが効きます。「カオステストを1回やる」は工数見積もりの単位。「カオスエンジニアリングを導入する」は監視・オンコール・切り戻しを含む運用体制の変更を指します。稟議で通す対象が違うため、提案時にどちらを指しているかを明示してください。

カオステスト実験設計の手順と定常状態指標・影響範囲・停止条件の決め方

実験の質は、注入する障害の派手さではなく、事前に決めた4つの入力で決まります。仮説、定常状態指標、影響範囲、停止条件。順に埋めます。

定常状態をSLOとゴールデンシグナルで数値化する具体的な手順

定常状態は「サービスが正常」という言葉ではなく、閾値付きの数値で置きます。実務で使える出発点は、すでに定義済みのSLOの設定方法とSLA・SLIとの違いを流用することです。可用性99.9%、95パーセンタイル応答500ミリ秒といった既存の約束があるなら、実験中もそれを割らないことが仮説になります。

SLOが未整備なら、レイテンシ・トラフィック・エラー率・飽和度の4指標から始めます。ゴールデンシグナルの監視指標とアラート設計で扱う4つは、そのまま定常状態の観測項目になります。

仮説には型があります。「この操作をしても、この指標がこの範囲に留まる」という1文です。たとえば「注文APIのPodを1つ削除しても、注文成功率は99.5%を下回らず、95パーセンタイル応答は800ミリ秒を超えない」。操作・指標・閾値が揃っていれば、実験後の判定で議論になりません。

影響範囲を段階的に広げる4段階の適用スコープと切り戻しの基準

影響範囲（ブラストラジウス）は、いきなり本番全体に広げません。principlesofchaos.org の高度な原則も、顧客への悪影響を最小限に封じ込める責任を明記しています。段階は4つに切ると管理しやすくなります。

• 第1段階：開発環境の単一インスタンス。ツールの挙動と観測経路の確認が目的
• 第2段階：ステージングの1サービス。仮説の判定ロジックが機能するかを確認
• 第3段階：本番の1アベイラビリティゾーンまたはトラフィックの1%。実データでの初回検証
• 第4段階：本番の広域。定期実行として自動化に組み込む

各段階を1回通っただけで次へ進まないでください。第3段階は平日昼間と夜間バッチ時間帯の2回に分けます。負荷の形が変われば同じ注入でも結果が変わるためです。段階を上げる基準は「前段階で仮説が支持され、かつ観測データが全て取得できていた」の両方。ログの欠損があった実験は、成功ではなく再実行の対象です。

自動停止条件を設けない実験が本番の障害に転化する典型パターン

停止条件（アボート条件）とは、実験中に定常状態が閾値を割ったら注入を自動で止める仕掛けです。AWS Fault Injection Serviceでは、CloudWatchアラームを停止条件として実験テンプレートに登録すると、アラームがALARM状態になった時点で実験が自動停止します。

この設定を省いた実験が事故になる経路は決まっています。夜間に遅延注入を仕掛け、担当者が別作業に移り、想定外のリトライ嵐でデータベース接続が枯渇する。目視監視を停止条件の代わりに置いた瞬間、実験は事故と区別できません。

停止条件は最低2本用意してください。1本目は仮説の指標そのもの（エラー率が閾値超過）、2本目は仮説と無関係な広域指標（全体スループットの急落）です。仮説の外側で起きる崩れを2本目が拾います。加えて、ツールの自動停止が効かなかった場合に備え、手動で注入を止めるコマンドを実験前に手元へ用意しておいてください。

障害注入の種類とネットワーク・ホスト・依存サービス別の適用手法

注入できる障害は無数にありますが、実務で使われるのは3つの層に集約されます。層ごとに、見つかる不具合の種類が違います。

ネットワーク層の遅延・パケットロス・分断注入で表面化する不具合

ネットワーク層の注入は、Linuxのトラフィック制御機能（tc netem）でパケットに遅延・損失・並び替えを加える形が基本です。Pumbaのようなコンテナ向けツールも内部でこの機能を呼び出します。

この層で見つかるのは、タイムアウト設定の不在と、リトライ設計の誤りです。接続タイムアウトは設定済みでも読み取りタイムアウトが無限のまま、というHTTPクライアントは今も珍しくありません。200ミリ秒の遅延を入れて応答が返るのに、3秒の遅延で全体が停止するなら、どこかにブロッキング待ちが残っています。ネットワーク分断の注入では、分断解消後にコネクションプールが古い接続を掴んだままになる不具合も出ます。

ホストとコンテナ層のインスタンス停止・リソース枯渇の注入設計

ホスト層の代表がインスタンスの強制終了です。Netflixが公開したChaos Monkeyが担ってきた領域で、オートスケーリングと自己修復が本当に働くかを直接確かめます。Kubernetes環境ではPodの削除がこれに相当し、Pumbaによるコンテナ障害注入の仕組みと使い方で扱うコンテナ単位のkillも同じ層です。

リソース枯渇の注入は見落とされがちですが、実運用での再現性は高い部類です。CPU使用率を90%まで押し上げる、メモリを圧迫する、ディスクを書き込み不能にする。この3種は監視の閾値設定が現実的かを試す材料になります。ディスク書き込み不能の注入では、ログ出力が詰まってアプリケーション自体が停止する構成も見つかります。

依存サービスのエラー率注入でサーキットブレーカーを検証する型

外部API、決済ゲートウェイ、認証基盤といった自社の外にある依存先は、停止させて試すことができません。そこで、呼び出し経路にプロキシを挟んで応答を書き換えます。ToxiProxyのような障害注入プロキシは、この用途で使われます。

注入するのは3種類。応答遅延、HTTPステータス500の一定割合での返却、接続拒否です。これでサーキットブレーカーの開閉閾値と、開いている間のフォールバック動作を検証します。サービス間の入出力の取り決めそのものは契約テストによる消費者駆動契約の検証が担うため、カオステストは「約束どおりの応答が返らないとき」に限定して見てください。検査対象を分けておくと、どちらの手法で何を担保しているかが説明できます。

ツール選定：AWS FIS・Chaos Mesh・OSS勢の適用範囲と費用構造

ツールは機能の多さで選びません。動かす基盤と、停止条件を監視系とつなげられるかで決まります。

マネージド型のAWS FISの料金体系と停止条件のアラーム連携

AWS Fault Injection Serviceは、EC2の停止、EBSの入出力遅延、RDSのフェイルオーバーといったAWSリソースへの注入をマネージドで提供します。課金単位はアクション分（action-minute）で、公式の料金ページは標準リージョンで1アクション分あたり0.10USD、追加アカウントごとにさらに0.10USD、GovCloudでは0.12USDと記載しています。実験レポートの生成は1件あたり5USDです。

10分間の実験を1アクションで実行すれば1USD程度で、費用は導入障壁になりません。判断の実質的な論点は、停止条件をCloudWatchアラームで宣言的に書ける点にあります。詳細な設定手順はAWS FISの実験テンプレートと料金・採用判断で扱っているため、AWS上で完結する構成ならまずここから検討してください。

Kubernetes前提のOSSであるChaos MeshとLitmusの守備範囲

Chaos MeshとLitmusChaosは、いずれもKubernetes上でカスタムリソースとして実験を定義するOSSです。Pod削除、コンテナkill、ネットワーク遅延、ストレス負荷、時刻のずらしまでをクラスタ内部で完結して注入できます。2026年8月時点でGitHubのReleasesに掲出されている系列は、Chaos Meshが2.8系、LitmusChaosが3.31系です。

この2つが射程に入るのは、対象がクラスタ内部で完結する場合に限られます。クラスタ外のマネージドデータベースやロードバランサを止めたいなら、クラウド側のAPIを叩けるツールが別途必要。実務では「クラスタ内はChaos Mesh、クラスタ外はクラウドのマネージドサービス」と役割を分ける構成が落としどころになります。Python製のChaos Toolkitは拡張ライブラリでKubernetesとクラウド双方を扱えるため、両者をまたぐ実験を1つの定義に書きたい場合の選択肢です。

Chaos MonkeyがSpinnaker必須である前提と代替手段の選び方

「カオステストといえばChaos Monkey」という連想でこのツールを選ぶと、多くの現場は導入前に止まります。GitHubのNetflix/chaosmonkeyのREADMEは、現行版がSpinnakerと完全に統合されており、インスタンスを終了させるにはアプリケーションをSpinnakerで管理している必要があると明記しているためです。バックエンドはAWS、Google Compute Engine、Azure、Kubernetes、Cloud Foundryが挙げられ、動作確認済みとされているのはAWS・GCE・Kubernetesの3つです。

Spinnakerを使っていない環境でインスタンス終了だけを試したいなら、別ツールへ寄せてください。AWSならFIS、KubernetesならChaos Mesh、Docker単体構成ならPumba。Chaos Monkeyは歴史的な位置づけとして参照する対象であり、2026年時点で新規に選ぶ標準ではありません。

導入形態・対象レイヤ・費用構造で比較するツール4種の選定基準

選定の判断材料を1枚に並べます。

停止条件の列が選定を分けます。監視基盤と連動した自動停止を最初から求めるならマネージド型、実験の判定ロジックを自前で書ける体制があるならOSSです。

カオステストを本番環境で実施する判断基準と見送るべき構成の条件

ここからは判断の話です。カオステストは全ての現場に効く手法ではありません。効く条件と、効かない条件を切り分けます。

ステージング環境限定で終えた場合に取り逃す障害の具体的な種類

「本番は怖いのでステージングまで」で止める運用は、実験の価値を大きく削ります。本番でしか出ない不具合には型があるためです。

第一に、キャッシュのヒット率が違う。温まったキャッシュでのインスタンス停止と空のキャッシュでの停止では、下流データベースへ流れる負荷が桁で変わります。第二に、接続数とコネクションプールの飽和は実トラフィック量に依存します。第三の盲点が外部SaaSのレート制限で、本番アカウントにしか掛かっていない場合がある。第四に、オンコール当番の反応速度はステージングでは測れません。

ステージングは「ツールと判定ロジックの動作確認場所」と割り切り、仮説の検証は第3段階の本番1%から始めるのが筋です。段階的に本番トラフィックを流す仕組みがあるなら、カナリアリリースによる段階リリースの実装と同じ経路で実験対象を絞り込めます。

本番環境で実施する前に満たすべき監視・切り戻し・当番の3条件

本番で注入してよいかは、次の3条件で判定します。全て満たさない限り実施しないでください。

条件1は観測です。定常状態の指標がダッシュボードでリアルタイムに見え、かつ実験前後の値を後から比較できる形で保存されていること。指標が5分遅れで集計される構成では、停止条件が間に合いません。

条件2は切り戻しです。注入を止めるだけでなく、生じた状態（不整合なデータ、退避したトラフィック、開いたままのサーキットブレーカー）を元に戻す手順が文書化され、直近で実行された記録があること。誰も実行したことのない手順は、無いものと同じです。

条件3は当番体制です。実験の実施時刻に、システムを止められる権限を持つ担当者が待機していること。この3点が揃わない段階でツールだけ導入しても、実験は「障害の自作自演」に終わります。監視の整備や切り戻し手順の維持まで含めて内製が難しいなら、システムの保守運用・内製化支援のように運用体制の設計から手を入れる方が先です。

カオステストを採用すべきでない構成条件と先に整えるべき運用基盤

採用を見送るべき条件を、言い切ります。

第一に、冗長化されていない単一構成のシステムでは実施しません。インスタンスが1台しかない構成に障害を注入した結果は「落ちる」で確定しており、実験になっていません。冗長化が先です。第二に、リリースが手作業でロールバックに30分以上かかる環境では見送ります。切り戻せない実験は事故と同義です。SREとDevOpsの違いで語られる自動化の水準に達していない段階では、パイプラインの整備が優先されます。

第三に、監視が「サーバーが生きているか」の死活監視だけの環境も対象外です。定常状態を数値化できないため、仮説の判定ができません。スモークテストのCI組み込みと対象選定のような基本的な自動検証すら回っていないなら、そちらを先に通してください。

逆に、複数サービスが相互に依存し、自動デプロイと自動復旧が組まれ、SLOで運用されている環境なら、カオステストは費用対効果が高い部類に入ります。その環境では、冗長化が「設計上は効くはず」の状態で放置されている箇所が必ず残っているためです。

よくある質問

カオステストの導入検討で実際に挙がる質問を5つ取り上げます。

カオステストとカオスエンジニアリングは違うものですか？

実務ではほぼ同義で使われます。厳密に分けるなら、カオスエンジニアリングは仮説・実験・学習を継続的に回す取り組み全体を指し、カオステストはその中の個々の実験実行を指します。社内提案では対象範囲が変わるため、運用体制の変更を伴う話なのか、1回の検証工数の話なのかを明示して使い分けてください。

カオステストは本番環境でやらないと意味がないのですか？

ステージングだけでは取り逃す不具合があります。キャッシュのヒット率、コネクションプールの飽和、外部SaaSのレート制限、オンコールの反応速度は、本番の負荷とデータでしか再現しません。ただし最初から本番に入れる必要はなく、開発環境でツールの挙動を確認し、ステージングで判定ロジックを検証してから、本番のトラフィック1%へ進む順序が現実的です。

AWS FISの費用はどのくらいかかりますか？

公式の料金ページによると、標準リージョンで1アクション分（action-minute）あたり0.10USD、実験に追加アカウントを含める場合はアカウントごとにさらに0.10USD、GovCloudでは0.12USDです。実験レポートの生成は1件あたり5USDとされています。10分間の単一アクション実験なら1USD程度で、費用より停止条件の設計工数のほうが導入判断を左右します。

Chaos Monkeyを使うにはSpinnakerが必要ですか？

必要です。Netflix/chaosmonkeyのREADMEは、現行版がSpinnakerと完全統合されており、インスタンスを終了させるにはSpinnakerでアプリケーションを管理している必要があると明記しています。Spinnakerを使っていない環境では、AWSならFIS、KubernetesならChaos MeshやLitmusChaos、Docker単体ならPumbaへ寄せるのが実務的な選択です。

小規模なチームでもカオステストを始められますか？

構成次第です。冗長化された環境で自動デプロイと監視が回っているなら、規模が小さくても第1段階から始められます。一方、単一インスタンス構成やリリースが手作業の環境では結果が最初から分かっており、成果が出ません。冗長化と切り戻しの自動化、定常状態を測れる監視、その後にカオステストという順で整えてください。

関連記事

• AWS Fault Injection Service（FIS）とは？実験テンプレートと料金：マネージド型で実験を組む場合の具体的な設定手順を確認できます
• Pumbaとは？カオスエンジニアリング向けツールの概要と特徴：コンテナ単位で障害を注入する場合の実装手段を扱っています
• Golden Signalsとは？SREの監視指標と実装・アラート設計：定常状態の指標を何で置くかを決める際の土台になります
• 可用性とは？稼働率の計算と高可用性の設計：実験対象となる冗長構成の前提を整理しています
• 契約テストとは？消費者駆動契約の実装とCI組み込み：サービス間の検証をどの層で分担するかの判断材料になります