カオスエンジニアリングとは｜障害注入の手順・ツールとSREでの実践

カオスエンジニアリングとは｜「壊して学ぶ」実験の考え方

結論として、カオスエンジニアリングはシステムの耐障害性に対する自信を、実験によって獲得する規律です。提唱元であるPRINCIPLES OF CHAOS ENGINEERINGは、これを「本番環境の乱れた状況に耐えるシステムの能力への確信を築くために、システム上で実験する規律」と定義しています。

鍵になるのは「実験」という言葉です。実験には仮説が要ります。「このPodを落としても、ユーザーから見たエラー率は変わらないはずだ」という予測を先に立て、それが外れるかどうかを見る。外れたときに初めて、設計の穴が見つかります。

壊すこと自体が目的ではありません。

定義と目的｜単体テスト・負荷テストとの違い

テストと実験は目的が違います。テストは既知の期待値を確認する行為で、合格か不合格かが先に決まっています。実験は未知の振る舞いを発見する行為で、結果が分からないから意味があります。

負荷の限界を知りたいなら負荷テストが適しています。この領域はk6とは｜負荷テストの始め方とJMeterとの違い・CI連携で扱っています。カオスエンジニアリングが見るのは、限界値ではなく壊れ方です。

もう一つ、混同されやすいのが障害対応との関係です。障害対応は実際に起きた事象への事後対応、カオスエンジニアリングは起きる前の事前検証で、時間軸が逆になります。事後側の型は障害対応の手順とポストモーテムの書き方｜一次対応から再発防止までにまとめています。両者は対立せず、ポストモーテムで見つかった仮説を、次のカオス実験の題材にするのが噛み合った運用です。

なぜ分散システムで必要になるのか

分散システムでは、構成要素それぞれが正常でも、組み合わさった全体が壊れることがあります。

たとえば外部APIの応答が500ミリ秒遅くなったとします。単体では「少し遅い」程度です。ところが呼び出し元がタイムアウトを設定しておらず、スレッドが溜まり、コネクションプールが枯渇し、無関係な機能まで落ちる。こうした連鎖は、設計レビューでは見落とされやすく、実際に注入してみないと分かりません。

マイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説で触れたとおり、サービスを分割すると障害の発生点は増えます。依存関係が深くなるほど、机上で全パターンを洗い出すのは難しくなります。そこで「実際に注入して観測する」アプローチの出番になります。

ミニFAQ：ステージング環境しかなくても始められますか

始められます。むしろ最初はステージングからの着手が前提です。本番で実験するのは、監視・自動停止・ロールバックの仕組みが揃ってからで十分間に合います。

カオスエンジニアリングの5原則

PRINCIPLES OF CHAOS ENGINEERINGは、理想的な適用として5つの高度な原則を示しています。原文は抽象度が高いため、実務での読み替えをあわせて整理します。

実務で最初に効くのは1番目と5番目です。

定常状態は「ユーザーから見た出力」で定義するのがコツになります。CPU使用率が80%でも、ユーザーが問題なく買い物できているなら定常状態です。逆にCPUに余裕があってもエラー率が跳ねていれば異常です。内部指標を仮説に使うと、実験の合否判定がぶれます。

本番環境の扱いは、原典の趣旨と実務上の安全配慮を分けて理解してください。 原典は本番トラフィックでの検証を重視していますが、実務では監視・停止条件・段階的な検証が前提になります。AWSもAWS Fault Injection Serviceのドキュメントで、本番で実験する前に計画フェーズを完了し、プリプロダクション環境で実行することを強く推奨すると明記しています。原則の文言だけを根拠に初手で本番へ入るのは避けてください。

障害注入の進め方｜5ステップとゲームデー設計

結論から言うと、定常状態の定義 → 仮説 → 障害の選定 → 実行と観測 → フィードバックの5ステップで回します。所要時間の目安を挙げると、小〜中規模の既存サービスで監視基盤がすでにある前提なら、初回の準備は対象の調査と停止条件の設計を含めて2〜4時間程度です。これは調査データではなく実務上の経験則で、対象の複雑さによって幅が出ます。

STEP1：定常状態をSLIで定義する

まず「正常とは何か」を数値で決めます。可観測性の指標（SLI）として使いやすいのは、エラー率・レイテンシのパーセンタイル・スループット・主要なビジネス指標の4つです。

実験の直前に5〜10分ほどベースラインを取り、通常時の値域を押さえておきます。この作業を飛ばすと、実験後に「そもそも普段どうだったか」が分からなくなります。

メトリクス基盤が無い場合は、ここが最初の着手点になります。Prometheus & Grafanaとは｜メトリクス監視の基本・Datadogとの違い・案件単価をフリーランス視点で解説やOpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向を先に整備してから実験に進む順番をおすすめします。

STEP2：仮説を文章で書く

仮説は口頭で済ませず、1文で書き残します。形式を固定すると楽になります。

「対象に障害を注入しても、SLIは閾値を超えて悪化しない」

例としては「決済サービスのPodを1つ強制終了しても、注文APIのエラー率は0.1%を超えない」といった具合です。閾値まで書くことで、実験の合否が自動的に決まります。

STEP3：注入する障害を選ぶ

注入できる障害は、おおまかに次の層に分かれます。1回の実験では1種類に絞るのが鉄則です。複数を同時に入れると、どれが原因で壊れたのか切り分けられなくなります。

どれから始めるか迷ったら、過去に実際に起きたインシデントの再現が無難です。原則の「実世界の事象を変数にする」にも合致しますし、チーム内で必要性を説明しやすくなります。

STEP4：実行し、観測する

実行中は、注入したチームが画面を見続けます。ここで重要なのが中止基準（アボート条件）を事前に決めておくことです。

設計例としては、SLO違反の兆候が2分続いたら即座に中止する、といった形があります。判断を実行中の議論に委ねると、迷っているあいだに影響が広がります。

ツール側の安全装置も使います。AWS FISでは、CloudWatchアラームを停止条件（stop condition）として実験テンプレートに設定でき、閾値に達すると実験が自動的に停止します。手動の中止判断だけに頼らない構成にしておくと安心です。

STEP5：結果をフィードバックする

仮説が当たっても外れても、結果は記録します。外れた場合は、修正すべき箇所をチケット化し、修正後に同じ実験をもう一度流して検証するところまでが1サイクルです。

ここを回さないと「実験はしたが何も変わらない」状態になります。実際、カオスエンジニアリングが形骸化する典型パターンがこれです。

ミニFAQ：どのくらいの頻度で回せばよいですか

初回の運用頻度としては、月1回程度のゲームデーから始めるチームが多いです。適切な頻度はチーム規模や運用の成熟度で変わるため、標準値ではなく出発点として捉えてください。手順が固まり自動化できた実験から、CIや定期ジョブに移していくと、頻度を上げても運用負荷が増えにくくなります。

ゲームデーの設計例｜初回は90〜120分で区切る

ゲームデーは、関係者を集めて計画的に障害を起こす演習です。Azureのドキュメントでも、大規模イベント前にプリプロダクション環境でシナリオを実行する用途として挙げられています。

初回の設計例を挙げます。時間配分は一例で、チーム規模や対象システムの複雑さによって変わります。

ロールは、注入役・観測役・記録役の3つに分けると進行が安定します。経験則としては、5〜8名程度の小規模チームであればこの分担で回しやすいケースがあります。人数が少ない場合は観測役と記録役を兼任させる形でも成立します。

主要ツールの比較｜マネージドとOSS

結論として、AWS中心ならFIS、Kubernetes中心ならChaos MeshかLitmusChaosが出発点になります。ただし執筆時点の情報であり、各プロダクトは更新されるため、採用前に公式ドキュメントで現行の仕様を確認してください。

マネージドサービス

AWS Fault Injection Serviceは、実験テンプレートにアクション・ターゲット・停止条件を定義して実行するマネージドサービスです。アクションは順次または並列で実行でき、料金はアクションの実行分数と対象アカウント数に基づく従量課金です。AWSリソースに対して実際の操作を行う点は、本番適用前に必ず押さえておく必要があります。

Azure Chaos Studioは、Azure向けの回復性テスト用マネージドサービスです。執筆時点では、従来の「実験（クラシック）」からワークスペースとシナリオという新しいリソースモデルへの移行が進んでおり、ワークスペースとシナリオはパブリックプレビュー段階と案内されています。プレビュー段階の機能はSLAの対象外のため、本番利用の可否は公式の最新情報で確認してください。クラシックモデルでは、管理API経由で実行する「サービスダイレクト」と、VM内部にエージェントを入れて実行する「エージェントベース」の2種類の障害が用意されています。

OSS・Kubernetes向け

Chaos Meshは、Kubernetes向けのカオスエンジニアリングプラットフォームです。執筆時点ではCNCFのIncubatingプロジェクトに位置づけられており、ネットワーク・ファイルシステム・カーネル・ランタイムなど幅広い障害をシミュレートできます。

LitmusChaosもCNCFのIncubatingプロジェクトで、2022年1月にIncubating入りしています。宣言的な実験定義、実験を共有するChaosHub、定常状態仮説の検証に使うProbesといった構成が特徴です。Prometheusメトリクスを出力してカオスの影響を可視化する機能も備えています。

Chaos Monkeyは、この分野の出発点としてよく引き合いに出されるNetflix発のツールです。ただし現行版はSpinnakerをアプリケーション構成の参照元として必要とし、終了スケジュールの管理にMySQL互換データベースを要求します。元になったSimian Armyプロジェクト自体は既に積極的なメンテナンス対象ではなくなっており、「名前は有名だが、今から新規導入する第一候補とは限らない」点に注意してください。

Kubernetes前提のツールが多いため、基盤側の理解は前提になります。Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説やIstioとは｜サービスメッシュの仕組み・Kubernetes運用での役割を解説が土台になります。サービスメッシュを入れている環境では、メッシュ側の機能で遅延や障害を注入できるケースもあります。

SREの実務でどう位置づけるか

カオスエンジニアリングは単独の取り組みではなく、SREの信頼性管理サイクルの一部として機能します。SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説で整理した活動のうち、「信頼性を事前に作る」側に位置します。

SLO・エラーバジェットとの接続

定常状態の仮説は、SLIとSLOをそのまま流用できます。SLOが定義されていれば「どこまで悪化したら実験を止めるか」も自動的に決まるため、SLO策定済みのチームほどカオス実験に着手しやすいという関係があります。

逆にSLOが無い状態では、定常状態の定義から始めることになります。その場合は実験より先にSLO設計を片付けたほうが、結果的に早く進みます。

オブザーバビリティが前提条件になる

観測できない障害を注入しても、得られるのは「なんとなく重かった」という感想だけです。最低でも、メトリクス・ログ・トレースのうちメトリクスとログは実験前に揃えておきたいところです。

分散トレーシングがあると、障害の波及経路を追えるため実験の価値が大きく変わります。このあたりはOpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向の範囲です。

プラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違いで扱う役割では、実験基盤そのものを社内に提供する立場になることもあります。

導入フェーズ別の進め方

組織の状況によって、最初の一歩は変わります。

ケース1：モノリス・オンプレ中心の環境

いきなりツールを導入する必要はありません。手動のフェールオーバー訓練から始めるのが現実的です。待機系への切り替え、DBのフェールオーバー、ネットワーク機器の片系停止といった演習は、専用ツールなしで実施できます。

ここで得た「手順書どおりに動かなかった箇所」の洗い出しだけでも、十分な成果になります。

ケース2：クラウド移行・Kubernetes導入の途中

移行途中は、新旧が混在して依存関係が読みにくくなる時期です。この段階では移行済みコンポーネントの単体障害に絞って実験すると、切り分けがしやすくなります。

対象を絞るぶん、得られる知見も限定的です。それでも「移行後の構成が想定どおり冗長化されているか」の確認にはなります。

ケース3：マイクロサービス運用が定着している環境

依存関係が複雑な環境では、外部依存の遅延注入が効果的です。前述したとおり、連鎖障害の起点は「落ちる」より「遅くなる」であることが多いためです。

日本国内の事例としては、クックパッドが2018年に公開したChaos Engineering やっていく宣言が、マイクロサービス移行に伴う導入の背景を記した早い時期の記録として知られています。公開から時間が経っているため、記載内容は当時の構成に基づく点を踏まえて読んでください。

よくある失敗と対策

実験を始めたチームが詰まりやすい箇所を挙げます。

観測の準備なしに壊してしまう。 最も多いパターンです。メトリクスが無い状態で障害を入れても、仮説の検証ができません。対策は順番を守ること、つまり監視を先に整えることです。

仮説を立てずに「とりあえず落としてみる」。 これは実験ではなく、ただの障害です。1文の仮説と閾値を書く手間を省かないでください。

いきなり本番環境で実施する。 原則が本番を推奨しているため誤解されがちですが、AWSも計画フェーズとプリプロダクションでの実行を先に推奨しています。段階を踏むほうが、結果的に本番実験に早く到達できます。

実験が改善につながらない。 発見した問題をチケット化せず、修正後の再実験もしない状態です。STEP5を省略しないことが対策になります。

中止基準が曖昧なまま実行する。 実行中に「まだ大丈夫か」を議論し始めると、判断が遅れます。開始前に数値で決めておきます。

フリーランスエンジニアから見た案件動向

まず短答です。カオスエンジニアリング単体を要件とした募集は、公開案件ではほとんど見かけません。 SREやプラットフォームエンジニアの募集要件の中に、信頼性向上の手段の一つとして記載されるかたちが中心になります。

以下は、首都圏中心の主要フリーランスエージェント数社の公開案件ページを2026年10月時点で確認した範囲での観測であり、公開案件数が多い領域ではないため、観測ベースの目安として読んでください。

スキルの見せ方は「組み合わせ」で考える

案件に応募する立場では、カオスエンジニアリングを単独スキルとして打ち出すより、SLO設計・オブザーバビリティ構築・障害対応の実績とセットで示すほうが伝わりやすくなります。

具体的には、スキルシートに次のような書き方ができます。

• SLOを定義し、エラーバジェットに基づく運用ルールを策定した経験

• メトリクス・ログ・トレースの基盤を設計し、ダッシュボードを整備した経験

• ゲームデーや障害訓練を設計・実施し、発見した課題を改修まで持っていった経験

• 実際のインシデントで一次対応を担当し、ポストモーテムを書いた経験

これらを経験している方は、SRE系の案件要件と噛み合いやすくなります。実務経験3年以上のインフラ・クラウド領域のエンジニアで、Kubernetes運用と監視基盤の構築を一通り担当した経験があると、要件に合致するケースが増えます。

単価レンジそのものについては、SREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安で職種別に整理しているため、そちらを参照してください。自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で現在の市場単価の目安を確認できます。

実際の募集条件はフリコンの案件一覧でも確認できます。

導入チェックリスト

初回の実験に入る前に、次の項目を確認してください。このページの整理として、準備フェーズと実行フェーズに分けています。

準備フェーズ

• 定常状態をSLIの数値で定義したか（内部指標ではなくユーザー視点の出力になっているか）

• 実験前のベースラインを取得する手順を決めたか

• 仮説を1文で書き、閾値まで明記したか

• 注入する障害を1種類に絞ったか

• 中止基準を数値と継続時間で決めたか

• 影響を受けうる関係者に事前共有したか

• ロールバック手順を用意し、実際に動くか確認したか

実行フェーズ

• 注入役・観測役・記録役の分担を決めたか

• ツール側の停止条件（CloudWatchアラーム等）を設定したか

• 実験後に復旧を確認する手順を決めたか

• 発見した課題をチケット化する先を決めたか

• 修正後に同じ実験を再実行する予定を入れたか

まとめ

カオスエンジニアリングは、仮説と観測を伴う実験によってシステムの壊れ方を事前に把握する手法であり、監視とSLOが整っているチームほど着手の効果が出ます。

要点を整理します。

• 定義は「乱れた状況に耐える能力への確信を築くための実験」であり、壊すこと自体が目的ではありません

• 5原則のうち実務で先に効くのは「定常状態の仮説」と「影響範囲の最小化」です

• 手順は定常状態の定義・仮説・障害の選定・実行と観測・フィードバックの5ステップで、1実験1障害に絞ります

• 初回は90〜120分のゲームデーとして設計し、中止基準を数値で事前に決めておきます

• ツールはインフラ構成で選び、AWS中心ならFIS、Kubernetes中心ならChaos MeshやLitmusChaosが出発点になります

• 本番実験は原則として推奨されますが、計画とプリプロダクションでの実行を先に済ませる段階論が現実的です

• 案件では単独要件ではなくSRE・プラットフォーム領域の一部として現れるため、SLO・監視・障害対応の実績とセットで示します

次のステップとしては、自分の担当システムで「定常状態を1つSLIで定義してみる」ところから始めてください。そこが書けない場合は、実験より先に監視の整備が必要だと判断できます。

参照した一次情報は以下のとおりです。

• PRINCIPLES OF CHAOS ENGINEERING

• What is AWS Fault Injection Service?（AWS公式ドキュメント）

• Azure Chaos Studio とは（Microsoft Learn）

• Chaos Mesh Documentation

• LitmusChaos

• Chaos Monkey（Netflix）

• Chaos Engineering やっていく宣言（クックパッド開発者ブログ・2018年）