本番障害の振り返りで「監視は入れていたのに、想定していなかった連鎖で復旧に時間がかかった」という結論が出たことはないでしょうか。冗長化もしている、アラートも設定している、それでも障害は起きるし、起きたときの挙動は事前に描いていた絵とは違っていた。経営層からは再発防止策の提示を求められているものの、監視ツールを増やす以外の打ち手が見つからない、という状況は珍しくありません。
そうした情報収集の中でたどり着くのが「カオスエンジニアリング」という言葉です。ただ、内容を調べるとほとんどの解説記事が「本番環境で意図的に障害を起こす」と説明しています。運用責任者の立場からすれば、これは稟議に出しにくい提案です。実験が原因で障害になったら誰が責任を取るのか、開発・保守を委託しているベンダーに「壊してください」と依頼できるのか、そもそも既に実施しているフェイルオーバー訓練と何が違うのか。手法の説明を読めば読むほど、判断できない論点が増えていきます。
必要なのは手法の網羅的な知識ではなく、「自社は今この手法に取り組むべきか、それともその前に整えるべきことがあるか」を自分で判定できる基準です。カオスエンジニアリングは万能の再発防止策ではなく、いくつかの前提条件が揃って初めて機能する手法です。逆に言えば、前提条件を確認するだけでも自社の運用の弱点が見えてきます。
本記事では、カオスエンジニアリングの定義と 5 原則、既存の障害試験・負荷試験との違いを整理したうえで、導入前に満たすべき 3 つの前提条件、外部ベンダーに開発・保守を委託している場合の責任分界と契約上の論点、ツール選定の判断軸、そしてスモールスタートの進め方と社内説明の仕方までを解説します。読み終えたときに「今やる」「まだ早い」のどちらかを根拠を持って言える状態を目指します。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
カオスエンジニアリングとは？意図的に障害を起こして耐障害性を検証する手法
まずは言葉の定義から確認します。ここを曖昧なまま社内で説明すると、「わざとシステムを壊す危険な取り組み」という印象だけが独り歩きし、議論が止まってしまいます。
定義は「本番環境の不安定さに耐えられるという確信を得る実験」
カオスエンジニアリングは、Principles of Chaos Engineering（カオスエンジニアリングの原則） において「システムが本番環境の不安定な状況に耐えられるという確信を築くために、分散システム上で実験を行う訓練分野」と定義されています。この定義で重要なのは、目的が「確信（confidence）を得ること」に置かれている点です。
つまり、障害を起こすこと自体は目的ではありません。目的は、システムが不安定な状況に置かれたときにどう振る舞うかについて、机上の想定ではなく観測されたデータで裏付けを取ることです。「壊す」は手段であり、得たいものは「壊れなかった」または「ここが壊れると分かった」という事実です。
もう一つ押さえておきたいのが、テストと実験の違いです。テストは「こう動くはずだ」と分かっている性質を検証し、合否を判定します。一方で実験は、まだ知らない性質を明らかにして新しい知識を得るために行います。カオスエンジニアリングが「テスト」ではなく「実験」と呼ばれるのは、既知の仕様を確認するのではなく、誰も把握していない弱点を見つけることを狙っているためです。
社内で説明する際は、「わざと壊す取り組み」ではなく「システムの弱点を、障害が起きる前に管理された条件下で見つける取り組み」と言い換えると、議論の出発点がそろいます。
Netflix の Chaos Monkey から広がった背景
この考え方を世に広めたのが Netflix です。同社は 2011 年に「Simian Army」と呼ばれる一連の障害注入ツール群を公開しました。その中核が Chaos Monkey で、本番環境で稼働しているインスタンスをランダムに停止させ、サービスが利用者への影響なく稼働し続けられるかを確かめるツールです（出典: Netflix Technology Blog「The Netflix Simian Army」、2011 年）。Chaos Monkey はのちに OSS として公開され、Netflix/chaosmonkey で現在も参照できます。
Simian Army には、通信に遅延を挿入して劣化時の挙動を確かめる Latency Monkey、アベイラビリティゾーン全体の障害を模擬する Chaos Gorilla など、対象範囲の異なるツールが含まれていました。単一のインスタンス障害から、より広い範囲の障害へと段階的に検証範囲を広げていく発想は、今日の実践にも引き継がれています。
なお、Chaos Monkey が生まれた背景には「クラウド上のインスタンスはいつでも落ちうる」という前提があります。落ちない前提で設計するのではなく、落ちても平常運転を続けられるかを日常的に確かめる。この前提の置き換えが、カオスエンジニアリングの出発点になっています。
監視を入れていても障害が読めないのはなぜか
監視ツールを整備しているのに障害の影響範囲が読めない、という状況には構造的な理由があります。監視は「起きたことを検知する」仕組みであり、「これから起きることがどう波及するか」を教えてくれる仕組みではないためです。
特にマイクロサービス化が進んだシステムでは、サービス間の依存が網の目のように広がります。ある依存先が遅くなったとき、呼び出し側のタイムアウト設定・リトライ回数・キャッシュのフォールバック処理が組み合わさって、想定外の連鎖を起こすことがあります。個々の設定値はレビュー済みでも、組み合わさったときの全体の振る舞いは誰も検証していない、という状態が生まれやすいのです。
クックパッドは Cookpad TechConf 2019 で、モノリスからマイクロサービスへの移行によって開発速度は改善した一方、認証サービスの遅延がユーザー向けサービスにまで波及するなど、分散システム特有の複雑性が課題になったと報告しています。同社はカオスエンジニアリングによって、レシピサービスのレスポンスキャッシュロジックに耐障害性の問題があることを発見し、修正につなげました（ログミー Tech「クックパッドが『カオスエンジニアリング』を始めた理由」）。
設計レビューでも、監視ダッシュボードでも見つからなかった弱点が、実験によって初めて表面化する。これがカオスエンジニアリングに取り組む理由です。
障害試験・負荷試験とカオスエンジニアリングの違い
すでにフェイルオーバーテストや負荷試験を定期的に実施している場合、「それとどう違うのか」「重複投資にならないか」という疑問が出てきます。ここを整理しておかないと、追加投資の説明ができません。
障害試験（フェイルオーバーテスト）は「既知」、カオスエンジニアリングは「未知」の検証
両者は手段が似ているため混同されやすいのですが、目的が異なります。区別の軸は「何を知っている状態で実施するか」です。
観点 | 障害試験（フェイルオーバーテスト） | カオスエンジニアリング |
|---|---|---|
目的 | 設計時に想定した障害シナリオが想定どおり動作するかの確認 | 想定していなかった弱点の発見 |
立てる問い | 「設計どおりに切り替わるか」 | 「この条件下でシステムはどう振る舞うか」 |
成功の定義 | 期待した動作が再現されること（合否判定） | 仮説と現実のズレが見つかること、または仮説が裏付けられること |
主な実施タイミング | リリース前・構成変更後 | 定常運用の中で継続的に |
障害試験は「DB のプライマリを落としたらスタンバイに切り替わる」という既知の設計を検証します。合格すれば設計どおりであることが確認できます。一方でカオスエンジニアリングは、「決済サービスの応答が 3 秒遅延したとき、注文完了率は維持されるか」のように、答えを知らない問いを立てます。仮説どおりであれば耐障害性の裏付けが得られ、外れていれば改善対象が特定できます。どちらの結果にも価値がある点が、合否を判定する試験との違いです。
負荷試験・障害注入（フォールトインジェクション）との関係
障害注入（フォールトインジェクション）は、システムに意図的に異常を発生させる技術的な手段を指します。インスタンスの停止、ネットワーク遅延の挿入、CPU 負荷の付与、API のエラー応答などが該当します。この手段は障害試験でもカオスエンジニアリングでも使われるため、手段だけを見ても両者は区別できません。区別できるのは目的の側です。
負荷試験との関係も同様です。負荷試験は「想定トラフィックを処理できるか」という容量の検証で、カオスエンジニアリングは「異常が起きたときの振る舞い」の検証です。ただし両者は組み合わせて実施すると効果が高く、平常時と同等の負荷をかけた状態で障害を注入することで、より本番に近い条件での挙動を観測できます。
なお、日本語の記事では「カオステスト」という表記も見かけます。多くの場合はカオスエンジニアリングと同じ取り組みを指していますが、文脈によっては「障害注入を用いた単発のテスト」を指していることもあります。社内で用語を使う際は、継続的な実験サイクルを指すのか、単発の検証を指すのかを明確にしておくと認識がそろいます。
既存の訓練と重複させないための切り分け方
すでに障害訓練を実施しているなら、ゼロから始める必要はありません。切り分けの実務的な手順は次のとおりです。
- 既存の訓練シナリオを棚卸しする: 何を、どの頻度で、どの環境で検証しているかを一覧化します
- 各シナリオを「既知の確認」と「未知の探索」に分類する: 設計書に期待動作が書かれているものは前者、書かれていないものは後者です
- 未知の探索に分類されたものが実質的なカオスエンジニアリングの対象になる: ここに仮説と観測の枠組みを追加すれば、既存の訓練を土台にできます
- 既知の確認に分類されたものは障害試験として維持する: 別の取り組みに置き換える必要はありません
この整理をすると、「新しい取り組みを追加する」ではなく「既存の訓練のうち、答えを知らないまま実施していたものに仮説と観測を足す」という説明ができるようになります。稟議上も、まったくの新規投資より通しやすい形になります。
カオスエンジニアリングの5原則と実験の進め方
カオスエンジニアリングには広く参照されている 5 つの原則があります。この原則は手法の説明であると同時に、安全に実施するための設計指針にもなっています。
5 原則の全体像
Principles of Chaos Engineering が示す 5 つの原則は次のとおりです。
- 定常状態における振る舞いについて仮説を立てる: システム内部の状態ではなく、スループットやエラー率といった観測可能な出力に注目し、それが維持されるという仮説を立てます
- 実世界の事象は多様であることを前提にする: サーバーの停止だけでなく、レスポンス遅延、依存サービスのエラー応答、リソース枯渇など、現実に起こりうる事象を幅広く対象にします
- 本番環境で実験を実行する: 環境ごとに構成やトラフィックの性質が異なるため、本番環境で得られる知見が最も価値を持ちます
- 実験を継続的に自動実行する: 手動での実施は続かないため、実験を仕組みに組み込みます
- 影響範囲を限定する: 実験は利用者への影響を最小限に抑えて設計します
社内説明で誤解を招きやすいのは 3 番目の「本番環境で実験を実行する」です。この原則は「いきなり本番から始めよ」という意味ではなく、「最終的に確信を得たいのは本番環境の振る舞いである」という到達点を示したものです。5 番目の「影響範囲を限定する」と一体で読むことで、原則そのものが安全設計を内包していることが分かります。
実務では、これらの原則を次の 4 ステップに落として進めます。
ステップ1 — 定常状態を定義し、仮説を立てる
最初にやることは、システムが「正常である」とはどういう状態かを、測定可能な指標で定義することです。ここが曖昧なままだと、実験後に「壊れたのか壊れていないのか」を判定できません。
定常状態の指標には、次のような利用者側から観測できるメトリクスを使います。
- スループット: 単位時間あたりの注文完了数、ログイン成功数など、ビジネス上の主要な処理量
- エラー率: リクエストに対するエラー応答の割合
- レイテンシ: 主要な画面・API の応答時間（平均だけでなく 95 パーセンタイルなどの分布も併せて見ます）
CPU 使用率やメモリ消費量といった内部指標は原因分析には役立ちますが、定常状態の判定基準としては適していません。利用者が困っているかどうかを表さないためです。
指標の水準を決める際は、エラーバジェットとは？SLO運用で許容する障害時間の決め方 で扱っている SLO（サービスレベル目標）の考え方が土台になります。SLO を定義していれば、それがそのまま定常状態の判定基準として使えます。定義していない場合は、実験の前に主要な導線の目標値を決めるところから始めるとよいでしょう。
定常状態が決まったら仮説を立てます。仮説は「実験条件」と「維持されるはずの定常状態」をセットにした文にします。
- 例1: 「商品検索サービスの 1 台が停止しても、検索成功率は 99.9% を維持する」
- 例2: 「決済 API の応答に 2 秒の遅延を注入しても、注文完了率は平常時の 95% 以上を維持する」
- 例3: 「特定アベイラビリティゾーンを切り離しても、注文処理のエラー率は 0.5% を超えない」
このように「〜しても〜は維持される」という形で書くと、実験後に結果を機械的に判定できます。
ステップ2 — 実験を設計し、影響範囲と中止基準を決める
次に、仮説を検証するための実験を設計します。ここで必ず先に決めておくのが、影響範囲の限定（ブラストラジウス）と中止基準（アボートコンディション）の 2 点です。この 2 つが決まっていない実験は、実施すべきではありません。
影響範囲の限定（ブラストラジウス） は、実験の影響が及びうる最大範囲をあらかじめ絞り込む設計です。具体的には次のような絞り方があります。
- 対象を単一のサービス・単一のインスタンスに限定する
- 特定のリクエストのみ（社内アクセスや特定のヘッダーを持つリクエストのみ）に障害を注入する
- 全トラフィックの数パーセントに限定して段階的に広げる
- 利用者数が少ない時間帯を選ぶ
中止基準（アボートコンディション） は、「この状態になったら実験を即座に停止する」という条件を数値で定義したものです。定常状態の指標を使い、「エラー率が 1% を超えたら中止」「注文完了数が平常時の 90% を下回ったら中止」のように設定します。あわせて、誰の判断で中止するのか、どの手順で停止するのかも事前に決めておきます。停止手順が手動オペレーションになる場合は、その手順自体を先にリハーサルしておく必要があります。
この 2 点を実験計画書に明記しておくと、稟議の場でも「何が起きうるか」「起きたらどう止まるか」を具体的に説明できるようになります。「わざと壊す」という説明が、「影響範囲を X に限定し、Y の条件で自動停止する管理された実験」という説明に変わります。
ステップ3・4 — 実行・観測と、結果の分析および改善
実行時は、障害を注入する担当と、監視を見ながら対応する担当を分けるのが実務的です。注入した本人が挙動を判断すると、「どこを見るべきか知っている状態」での観測になり、実際の障害時に検知できるかどうかの検証になりません。
観測では、次の 3 点を記録します。
- 定常状態の指標が仮説どおり維持されたか: 仮説の成否そのものです
- 異常を検知するまでにかかった時間: アラートが鳴ったか、何分後だったかを記録します。ここが遅ければ、システムの耐障害性ではなく監視設定に改善余地があることが分かります
- 対応にかかった時間と手順の詰まり: 手順書のどこで迷ったか、必要な権限がなかったか、といった運用面の課題も記録対象です
実験後は必ず振り返りを行い、見つかった課題を改善タスクとして起票します。ここで重要なのは、課題をその場の議事録に残すだけで終わらせず、優先度をつけて開発・保守のバックログに入れることです。改善につながらない実験は、繰り返しても学びが蓄積しません。
そして、改善した内容に対して再度同じ実験を実施し、仮説が成立するようになったかを確認します。この「仮説 → 実験 → 改善 → 再実験」のサイクルが回り始めて初めて、カオスエンジニアリングが継続的な取り組みになります。
カオスエンジニアリング導入前に満たすべき前提条件
ここからが、多くの解説記事では触れられない部分です。カオスエンジニアリングは、いくつかの前提条件が揃っていない状態で実施しても効果が出ないばかりか、単に本番環境を不安定にするだけの取り組みになりかねません。以下の 3 つを自社に当てはめて確認してください。
前提条件1 — 実験結果を読み取れる可観測性があるか
実験は「障害を注入して観測する」行為なので、観測できなければ何も得られません。次の項目を確認します。
- 定常状態の指標（スループット・エラー率・レイテンシ）が、リアルタイムに近い形でダッシュボードで確認できるか
- サービス間の呼び出し関係と、各呼び出しの成否・所要時間が追跡できるか（分散トレーシング）
- ログが集約されており、実験の時間帯を指定して横断的に検索できるか
- アラートが設定されており、閾値超過時に担当者へ通知が届く状態になっているか
このうち複数が「いいえ」になる場合、実験をしても「何かおかしくなったが、どこで何が起きたか分からない」という結果に終わります。そのときに優先すべきは実験ではなく、可観測性の整備です。監視基盤への投資は、カオスエンジニアリングの有無にかかわらず障害対応時間の短縮に直結するため、投資判断としても説明しやすいはずです。
前提条件2 — 影響が出たときに戻せるか
実験が想定外の影響を及ぼしたときに、元の状態へ戻せることが必須の条件です。確認すべきは次の点です。
- 障害注入を即座に停止できる手順があり、その手順を実施できる人が実験時間帯に待機しているか
- 直近のデプロイをロールバックできるか。手順は文書化されており、実行時間の目安が把握できているか
- 障害発生時の一次対応フロー（誰が何を判断し、誰に連絡するか）が定まっているか
- 外部ベンダーへの緊急連絡経路と、その応答可能時間帯が明確か
特に 3 点目と 4 点目は、外部委託が前提の運用体制では見落とされがちです。障害時の判断と連絡の流れが属人化していると、実験中に想定外の事態が起きたときに対応が遅れます。この領域の整理は 【発注者向け】本番障害の対応フロー で扱っているので、フローが未整備の場合はそちらを先に確認してください。
前提条件3 — 失敗を学習として扱う振り返りの運用があるか
3 つ目は組織文化に関わる条件です。カオスエンジニアリングは「弱点が見つかること」を成果とする取り組みなので、弱点が見つかったときに担当者が責められる文化では機能しません。実験の結果が悪いほど報告しにくくなり、無難な実験しか行われなくなります。
判定の目安は、障害発生後の振り返りが「誰のミスか」ではなく「どういう条件が重なるとこの事象が起きるか」を議論する場になっているかどうかです。この形式の振り返りは ポストモーテムとは？障害後の振り返りに発注者が関わる5ステップ で扱っているポストモーテムに相当します。
ポストモーテムの運用がまだない場合は、カオスエンジニアリングより先にそちらを整えるのが順序として自然です。実際の障害という「意図せず起きた実験」から学ぶ仕組みができていないのに、意図的な実験から学べる可能性は高くありません。逆に、ポストモーテムが定着していれば、実験の振り返りはその枠組みをそのまま流用できます。
「まだ早い」と判断すべきケースと、先に着手すべきこと
3 つの前提条件を踏まえて、「今は取り組むべきではない」と判断すべき典型的な状況を整理します。
状況 | なぜ早いか | 先に着手すべきこと |
|---|---|---|
本番障害の一次対応が特定の担当者に依存している | 実験中の異常時に対応が止まるリスクが高い | 障害対応フローの文書化と、対応可能な担当者の複数化 |
アラートが多すぎて通知が確認されていない | 実験による異常を検知できず、結果を判定できない | アラートの棚卸しと、重要度に応じた通知の整理 |
変更をロールバックできない、または手順が未検証 | 影響が出たときに戻す手段がない | デプロイ・ロールバック手順の整備と訓練 |
定常状態を表す指標が定義されていない | 仮説を立てられず、成否を判定できない | 主要導線の SLO 設定と、ダッシュボードでの可視化 |
障害の振り返りが責任追及の場になっている | 弱点の報告が抑制され、学習が起きない | ポストモーテムの導入と、非難のない振り返りの定着 |
ここで「まだ早い」と判定されたとしても、それは無駄な調査ではありません。表の右列に挙げた項目は、いずれも障害の検知時間と復旧時間を短くする施策であり、カオスエンジニアリングに進むかどうかにかかわらず投資価値があります。経営層への報告も、「カオスエンジニアリングの導入可否を検討した結果、前提となる運用整備が先だと判断し、優先順位を A・B・C とした」という形にできれば、検討そのものが成果になります。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
カオスエンジニアリングを委託先と実施する際の責任分界と契約上の論点
開発・保守を外部ベンダーに委託している場合、技術面より先に整理すべきなのが実施体制と契約の論点です。ここが曖昧なまま話を進めると、ベンダー側の合意が得られないか、得られたとしても実験由来の事象の扱いで後からもめる可能性があります。
なお、以下は一般的な整理であり、法的な助言ではありません。契約条項の具体的な文言については、個別の契約内容にもとづき法務担当者や専門家に確認してください。
実験の設計・実行・観測を誰が担当するかを決める
まず、実験プロセスのどの部分を誰が担うかを決めます。代表的な分担パターンは 3 つです。
パターン | 分担 | 向いているケース | 留意点 |
|---|---|---|---|
発注側主導 | 発注側が仮説と実験を設計し、実行はベンダーが支援 | 社内に運用を理解する担当者がおり、システム構成の把握が進んでいる | 発注側に設計の学習コストがかかる |
ベンダー主導 | ベンダーが設計・実行・報告まで担当 | 社内に SRE 相当の担当者がいない | 追加の作業範囲になるため、工数と費用の合意が必要 |
共同実施 | 仮説は共同で立て、実行はベンダー、観測と判定は双方 | 中長期的に発注側へ知見を移していきたい | 役割の境界を明文化しないと責任が曖昧になる |
社内に SRE 専任がいない体制では、ベンダー主導か共同実施が現実的です。ただし、いずれの場合も「観測結果をどう報告してもらうか」は発注側が決めておく必要があります。実験の価値は報告の質で決まるため、報告フォーマット（仮説・実験条件・観測結果・検出時間・改善提案）を事前に合意しておくとよいでしょう。
また、実験の実施は既存の保守業務の範囲に含まれない追加作業になるのが通常です。定例の保守契約の中でどう位置づけるか（範囲に含める／別途の作業として都度見積もる）を先に決めておくと、後の費用交渉が円滑になります。
実験由来の事象を保守契約・SLA でどう扱うか
保守契約に稼働率の保証（SLA）が含まれている場合、実験に起因して発生した停止・劣化をどう扱うかを事前に合意しておく必要があります。ここを決めずに実験を始めると、ベンダー側は「稼働率の未達リスクを負う実験には協力できない」という立場を取らざるを得なくなります。
一般に SLA の稼働率算定では、計画停止（事前に合意されたメンテナンス時間）は算定から除外する扱いが広く採られています。カオスエンジニアリングの実験も、事前に日時と範囲を合意した計画的な作業として扱えば、同様に除外条件として位置づける整理が考えられます。合意しておきたい項目は次のとおりです。
- 実験時間帯に発生した事象を稼働率の算定対象から除外するか、その定義（実験に起因する事象に限るのか、実験時間帯全体を除外するのか）
- 実験が原因で想定を超える障害が発生した場合の責任の所在と、復旧作業の費用負担
- 実験の対象範囲・注入する障害の種類について、事前承認を要する範囲の線引き
- 実験に関する記録（実施日時・条件・結果）の保管と、双方での共有方法
これらは既存の保守契約に定めがないことが多いため、覚書や作業指示書のレベルで補うことになります。契約更新のタイミングが近い場合は、その際にまとめて整理するのが手間が少ない進め方です。
実施時間帯・事前通知・中止判断の権限を事前に合意する
運用面では、次の 3 点を実施前に文書で合意しておくと、当日の判断で迷わずに済みます。
実施時間帯: 利用者への影響が小さい時間帯を選びます。ただし、深夜帯は対応要員の確保が難しく、判断の質も落ちるため、トラフィックが少ない日中の時間帯を選ぶという考え方もあります。どちらを優先するかを、対応体制と合わせて決めます。
事前通知の範囲: 実験の存在を誰まで知らせるかは、目的によって変わります。監視とアラートが機能するかを検証したい場合は、対応チームに事前通知せず「本当に検知できるか」を確かめる設計もありえます。一方で、通知しない実験は関係者の心理的負荷が高く、初期段階では全員に通知したうえで実施するのが安全です。少なくとも、カスタマーサポート部門と経営層には事前に共有しておくのが望ましいでしょう。
中止判断の権限: 「誰が中止を宣言できるか」を単独の権限として明確にします。複数人の合議が必要な設計にすると、判断が遅れます。発注側の運用責任者とベンダー側の実行担当者のいずれもが単独で中止できる形にしておくのが実務的です。あわせて、中止時の連絡経路（誰から誰へ、どの手段で）も決めておきます。
カオスエンジニアリングのツール選定
ツールは数多く存在しますが、機能を横並びで比較しても選定は進みません。実務的には「対象環境」「運用体制」「コストの形」の 3 点から絞り込むほうが早く決まります。ここでは 3 つのカテゴリに整理して紹介します。
クラウドマネージド型 — AWS Fault Injection Service / Azure Chaos Studio
クラウド事業者が提供するマネージドサービスです。対象のクラウド上のリソースに対して、管理された形で障害を注入できます。
AWS Fault Injection Service（AWS FIS） は、EC2 インスタンスの停止、ネットワークの遮断、API のエラー応答など、AWS リソースに対する障害注入を実験テンプレートとして定義・実行できるサービスです。リリース当初は AWS Fault Injection Simulator という名称でしたが、現在は AWS Fault Injection Service に変更されています（AWS 公式ドキュメント）。停止条件（Stop condition）を CloudWatch アラームと連携させて設定できるため、前述の中止基準を仕組みとして実装しやすい点が特徴です。料金はアクションの実行時間に応じた従量課金で、体系は変更される可能性があるため導入前に AWS FIS の料金ページ で確認してください。
Azure Chaos Studio は Azure 上のリソースを対象としたマネージドサービスです。仮想マシンにエージェントをインストールして内部リソースに障害を注入する「エージェントベース」の障害と、Azure のコントロールプレーン経由でリソースに作用する「サービス直接」の障害の 2 方式を提供しています（Microsoft Learn）。料金はアクションの実行時間に応じた従量課金です（Azure Chaos Studio の価格）。
いずれも、既に利用しているクラウドの IAM・監査ログ・課金の枠組みの中で完結する点が導入面の利点です。新しいベンダーとの契約手続きが不要なため、稟議のハードルも下がります。
商用 SaaS 型 — Gremlin
Gremlin は、カオスエンジニアリングに特化した商用 SaaS です。対象ホストにエージェントを導入する方式で、単一のクラウドに限定されず、複数のクラウド・Kubernetes・オンプレミスのサーバーを横断して同じ操作体系で扱えます。
商用サービスであるため、障害注入のシナリオがテンプレートとして用意されている、影響範囲の制御や停止機能が製品として実装されている、サポートを受けられる、といった点が特徴です。マルチクラウド構成やオンプレミスとの併用がある環境で、ツールを 1 つに統一したい場合の選択肢になります。料金体系は対象ホスト数などにもとづくため、詳細は Gremlin の料金ページ で確認してください。
Kubernetes ネイティブ OSS — Chaos Mesh / LitmusChaos
Kubernetes 上で稼働するシステムであれば、CNCF のプロジェクトとして開発されている OSS が有力な選択肢になります。
Chaos Mesh は、実験を Kubernetes のカスタムリソース（CRD）として定義するプラットフォームです。実験定義を YAML でバージョン管理でき、GitOps の運用に組み込みやすい設計になっています。Pod の停止、ネットワークの遅延・分断、DNS・HTTP・I/O の障害、CPU/メモリのストレス付与など、対象とする障害の種類が幅広い点も特徴です。
LitmusChaos も同様に Kubernetes 向けの OSS で、2020 年に CNCF Sandbox プロジェクトとなり、2022 年 1 月に Incubating プロジェクトへ昇格しています（CNCF ブログ）。Kubernetes 上のアプリケーションに加え、クラウド基盤やベアメタル、仮想マシンなど幅広い対象に実験を適用できる点が特徴です。
いずれもライセンス費用はかかりませんが、導入・アップグレード・トラブル対応の工数は自社（または委託先）が負担します。「無料」ではなく「費用の形が人件費に変わる」と捉えるのが実態に近い理解です。
対象環境・運用体制・コスト形態から選定軸を絞る
以上を選定の観点で整理すると次のようになります。
判断軸 | クラウドマネージド型 | 商用 SaaS 型 | Kubernetes ネイティブ OSS |
|---|---|---|---|
適した対象環境 | 単一クラウドに集約されている | 複数クラウド・オンプレミス混在 | Kubernetes 中心 |
必要な運用工数 | 小さい（基盤の運用は事業者側） | 小さい（サポートあり） | 大きい（構築・保守は自社／委託先） |
コストの形 | 実行時間に応じた従量課金 | 契約にもとづく費用 | ライセンス費用なし・人件費が中心 |
稟議のしやすさ | 既存のクラウド契約内で完結 | 新規のベンダー契約が必要 | 費用の稟議は不要だが工数の確保が必要 |
社内に SRE 専任がおらず、システムが単一のクラウドに集約されているなら、まずはクラウドマネージド型から始めるのが無理のない選択です。ツールの学習と運用の負担が最も軽く、既存の権限管理・監視の仕組みをそのまま使えるためです。Kubernetes を全面的に採用しており、マニフェストの管理体制が整っている場合は OSS の選択肢も現実的になります。
いずれの場合も、ツールの選定は実験の設計より後で構いません。最初の仮説と定常状態の指標が決まっていれば、それを検証できる障害注入の種類が明らかになり、必要な機能が絞り込まれます。
スモールスタートの進め方と、成果の社内説明
最後に、最初の一歩をどう踏み出すか、そして結果をどう社内に説明するかを整理します。
ステージング環境から始める段階的アプローチ
原則の 3 番目は「本番環境で実験を実行する」ですが、これは最初から本番で始めよという意味ではありません。実務では、次の順序で段階的に範囲を広げていくのが現実的です。
- ステージング環境で実験サイクルを一巡させる: 仮説の立て方、障害注入の手順、観測の方法、振り返りの進め方を一通り経験します。この段階の目的は弱点の発見ではなく、進め方の習熟です
- ステージング環境で複数のシナリオを試す: 依存サービスの停止、遅延の注入、部分的な障害など、対象を変えて実施し、観測の解像度を上げます
- 本番環境で影響範囲を極小にした実験を行う: 対象を単一のインスタンス、あるいは社内アクセスのみに限定し、中止基準を厳しめに設定して実施します
- 本番環境で範囲を段階的に広げ、継続的な運用に組み込む: 実施頻度を決め、定例の運用サイクルに組み込みます
前掲のクックパッドの事例も、サービスメッシュの機能を用いた障害注入の基盤を構築し、ステージング環境で「既知だが未検証な障害（Known unknowns）」から着手しています。すでに存在は認識しているものの検証していない障害から始めるという順序は、未知の領域にいきなり踏み込むより安全で、結果の解釈もしやすくなります。
最初の実験テーマの選び方
最初の実験は、結果が読み取りやすいものを選びます。目安は次のとおりです。
- 影響範囲が構造的に限定されている: 単一コンポーネントの停止、単一のアベイラビリティゾーンの切り離しなど、影響が波及する範囲を事前に説明できるもの
- 仮説が明確に立てられる: 「冗長化してあるので停止しても継続するはず」といった、期待動作を言葉にできるもの
- すでに疑いを持っている箇所: 過去の障害で挙動が読めなかった依存関係、タイムアウト設定の妥当性に確信が持てない箇所など
- 観測できる指標がすでにある: ダッシュボードで結果を判定できる箇所を優先します
逆に、依存関係が複雑に絡む領域や、データの整合性に関わる処理を最初の対象にするのは避けたほうがよいでしょう。結果の解釈が難しく、影響が出たときの復旧も複雑になります。
国内外の事例から成果の説明方法を学ぶ
カオスエンジニアリングの説明で最も難しいのが、「実験したが何も問題が起きなかった場合、何が成果なのか」という問いです。ここに答えられないと、継続の予算が確保できません。
参考になるのが、ZOZO が公開している運用事例です。同社は月 1 回「GameDay」としてステージング環境で障害注入と対応訓練を実施し、成果を測るための指標を定義しています。チーム能力の面では各メンバーの実施回数と自己評価スコア、システム把握の面では挙動予測スコアと障害検出時間（3 分以内）、耐障害性の面では復旧時間（MTTR 10 分以内）とエラーバジェットの消費率を KPI として設定しています。実行者と対応者を分け、負荷をかけながら障害を注入し、振り返りで KPI を評価して改善タスク化するという流れです（ZOZO TECH BLOG「障害への不安をぶっ壊す！カオスエンジニアリングを運用しシステムとチームの耐障害性を高める」）。
この事例が示しているのは、成果を「見つかった弱点の数」だけで測らないという考え方です。システムが壊れなかった実験でも、次の 3 つは成果として報告できます。
- 耐障害性の裏付けが得られたこと: 「単一インスタンスの停止に耐えられる」という設計上の想定が、観測データで裏付けられました。これは監査や顧客への説明にも使える事実です
- 検知と対応の訓練になったこと: アラートが何分で鳴ったか、手順書のどこで迷ったかが記録として残ります。障害検出時間や復旧時間の短縮は、そのまま障害時の影響縮小につながります
- 改善タスクが具体化したこと: 監視の抜け、手順書の不備、権限の不足など、実験をしなければ表面化しなかった課題がバックログに入ります
経営層への報告では、「実験を N 回実施し、弱点を M 件発見した」という数だけでなく、「障害検出時間が平均 X 分から Y 分に短縮した」「対応可能な担当者が 1 名から 3 名に増えた」といった運用指標の変化を併せて示すと、投資対効果の説明として成立しやすくなります。ZOZO の事例のように、始める前に測る指標を決めておくことが、この説明を可能にします。
まとめ
カオスエンジニアリングは、システムが不安定な状況に耐えられるという確信を得るために、管理された条件下で障害を注入して振る舞いを観測する実験手法です。「壊すこと」ではなく「未知の弱点を安全に見つけること」が目的であり、5 つの原則のうち「影響範囲を限定する」が安全設計として組み込まれています。既存の障害試験が「既知の設計の確認」であるのに対し、カオスエンジニアリングは「未知の弱点の探索」を担うため、両者は置き換えではなく補完の関係にあります。
自社が今取り組むべきかを判断する際は、まず 3 つの前提条件を確認してください。実験結果を読み取れる可観測性があるか、影響が出たときに戻せるか、失敗を学習として扱う振り返りの運用があるか。いずれかが欠けている場合は、その整備を先に行うほうが投資効率は高くなります。前提条件の確認自体が、自社の運用の弱点を洗い出す作業になります。
外部ベンダーに開発・保守を委託している場合は、技術的な準備と並行して 3 つの合意を進めてください。実験の設計・実行・観測を誰が担うかという責任分界、実験由来の事象を保守契約や SLA の稼働率算定でどう扱うかという契約上の整理、そして実施時間帯・事前通知の範囲・中止判断の権限という運用ルールです。この 3 点が文書化されていれば、実験は「危険な取り組み」ではなく「管理された定例作業」として社内外に説明できるようになります。
最初の一歩は、ステージング環境で 1 つの仮説を検証するところからで十分です。定常状態の指標を決め、影響範囲と中止基準を設定し、実施して振り返る。このサイクルを一巡させれば、自社の運用体制で何ができて何が足りないかが具体的に見えてきます。
関連情報
外部ベンダーに保守運用を委託している体制で、障害対応や運用ドキュメントの整備状況を点検したい方は、失敗しないためのシステム保守の引継ぎチェックリスト をご活用ください。可観測性・復旧手順・体制の確認項目を一覧で整理しています。
耐障害性の検証体制づくりや、委託先との責任分界の整理についてご検討中の方は、お問い合わせフォーム からご相談ください。現状の運用体制の確認段階からご相談いただけます。
業務委託エンジニアのマネジメント実践ガイド
この資料でわかること
こんな方におすすめです
- 業務委託エンジニアのオンボーディングを効率化したい
- 正社員と業務委託が混在するチームのマネジメントを改善したい
- 業務委託エンジニアとの長期的な関係を構築したい
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 障害試験（フェイルオーバーテスト）を既にやっている場合、カオスエンジニアリングは別途必要ですか？
障害試験は設計どおり動くかを確認する「既知の検証」、カオスエンジニアリングは想定外の弱点を見つける「未知の探索」であり目的が異なるため、別途必要です。既存の障害訓練シナリオのうち期待動作が定義されていないものに仮説と観測を追加すれば、重複投資にならずに始められます。
- 前提条件が1つでも満たせていない場合、カオスエンジニアリングは実施すべきではありませんか？
はい、可観測性・復旧手段・非難のない振り返り運用のいずれかが欠けると原因究明や失敗報告が難しくなり効果が出ないため、その前提条件の整備を先に行うべきです。整備自体が障害対応力の向上に直結するため、投資として無駄にはなりません。
- 外部ベンダーに開発・保守を委託している場合、何から合意を進めればいいですか？
まず実験の設計・実行・観測の役割分担を決め、そのうえで実験由来の事象を保守契約・SLAの稼働率算定でどう扱うかを覚書レベルで補うのが実務的な順序です。あわせて実施時間帯・事前通知範囲・中止判断の権限を事前に文書で合意しておくと、当日の判断で迷わずに済みます。
- 実験で何も問題が起きなかった場合、経営層にどう成果を説明すればいいですか？
「弱点が見つからなかった」ことも成果です。耐障害性の裏付けが得られたこと、検知・対応の訓練になったこと、改善タスクが具体化したことの3点を、障害検出時間や対応可能な担当者数の変化など運用指標の変化とあわせて報告すると説得力が増します。
- 本番環境で実験するのが不安な場合、ステージング環境だけで進めても問題ありませんか？
最初はステージング環境で仮説・注入・観測・振り返りのサイクルに慣れることが目的なので問題ありません。ただし最終的に確信を得たいのは本番環境の振る舞いであるため、慣れた後は影響範囲を極小にした本番実験へ段階的に移行するのが原則に沿った進め方です。
