カオスエンジニアリングは「破壊」ではなく「検証」である
- 年代に Netflix が Chaos Monkey を公開したとき、カオスエンジニアリングは「本番環境をランダムに壊す過激なプラクティス」として受け取られた。その文化的インパクトは大きかったが、同時に誤解も生んだ——本番で爆弾を投げるためには組織的成熟が必要で、ほとんどの企業にとってハードルが高すぎたのである。
- 年の到達点は明確だ。カオスエンジニアリングは「破壊する技術」ではなく「レジリエンスを検証する規律」であり、その本質は「障害を想定した設計が、実際に想定通り動くかを科学実験として確かめる」ことにある。仮説を立て、小さく試し、観測し、改善する。この PDCA を回す営み全体が chaos engineering なのである。日本企業で広く参照されてきた TPM（全員参加の予防保全）や FMEA（故障モード影響解析）の延長線上にあると捉えると、導入の説明がしやすい。
ツール選定: Gremlin / LitmusChaos / Chaos Mesh
- 年時点の主要ツールは三分化している。Gremlin は商用 SaaS の雄で、SRE チームのいない組織でも安全に導入できる「Blast Radius（影響範囲）制御」と「Halt 条件」がセールスポイント。ネットワーク遅延、CPU 圧迫、ディスク I/O 枯渇、ゾーン障害など標準攻撃が数十種類用意され、Web UI から数クリックで実験が開始できる。金融や通信のように「規制対応として chaos engineering プログラムが必要」なケースで強い。
LitmusChaos は CNCF Graduated プロジェクトで、Kubernetes ネイティブの OSS。Chaos Experiment を CRD として定義し、ChaosHub からコミュニティ実験をインポートできる。GitOps 連携が秀逸で、Argo CD と組み合わせて「実験を Git で宣言し、Argo Workflows で実行、Prometheus でメトリクス検証、失敗時は自動 rollback」という完結したパイプラインが組める。SRE チームの規律が整っている組織に向く。
Chaos Mesh は PingCAP 発の CNCF Incubating プロジェクトで、Kubernetes 上の細粒度障害注入に特化する。PodChaos、NetworkChaos、IOChaos、TimeChaos、DNSChaos などの CRD が充実しており、特に NTP ずれや DNS 汚染といった「他ツールでは難しい低レベル障害」を再現できる。Chaos Dashboard の UX も優れていて、LitmusChaos より学習コストが低い。
Kubernetes での実施: 実験の三階層モデル
Kubernetes 環境では実験を三階層に分けて運用するのが標準パターンになった。第一階層は「Pod レベル」。PodChaos で特定 Deployment の Pod を一つ kill し、HPA やサービスメッシュのリトライ・サーキットブレーカーが想定通り動くかを確認する。影響範囲が最小で、毎日自動実行できる。
第二階層は「Node レベル」。NodeChaos で AZ 内の一ノードを drain し、Pod Disruption Budget と再配置が機能するか確認する。週次実行が目安。第三階層は「リージョン/AZ レベル」で、NetworkChaos でゾーン間通信を遮断し、マルチ AZ 構成のフェイルオーバーを検証する。四半期の game day で実施する規模である。
- 年の現場では、第一・第二階層は完全自動化（CI パイプラインに組み込み）し、第三階層のみ人間が介在する game day として残す設計が主流だ。自動化部分は GitHub Actions や Tekton から LitmusChaos を呼び出し、SLO ダッシュボードと連動して「SLO 違反が検出されたら実験を自動停止」する halt 条件を必ず付ける。
Multi-Region Failover の検証
複数リージョン構成を持つサービスでは、年に1〜2回の「リージョン切り替え game day」が事実上の必須プラクティスになった。やり方は三段階だ。まず現行リージョンから DNS トラフィックを段階的に副リージョンへ寄せる（10% → 50% → 100%）。各段階で SLI が劣化していないかを確認し、劣化していれば rollback。100% 移行後、現行リージョンを意図的にネットワーク切断（NetworkChaos の partition）し、副リージョンが単独で耐えられるかを数時間観察する。
この game day で頻繁に見つかるのが、(1) 副リージョンの容量不足（通常時は低トラフィックで扱っているため HPA 上限が足りない）、(2) データベースレプリカ遅延のスパイク（書き込み集中でレプリカが遅れる）、(3) サードパーティ API のリージョン制約（特定リージョンから呼び出せない、レート制限が厳しい）の三つである。事前に想定しにくい問題ばかりで、game day で実証しなければ本物の災害で初めて顕在化する。
日本企業の文化的課題: 「計画停電」vs「本番カオス」
カオスエンジニアリング導入で最も深刻な障壁は技術ではなく文化だ。日本企業には「計画停電（事前告知して短時間サービス停止）」の文化はあるが、「本番で動いているシステムに意図的に障害を入れる」ことへの抵抗が強い。「本番を壊すとは何事か」という役員の反応は珍しくない。
この障壁を越えるための実務的戦術は三つある。第一に、最初は「非本番環境での chaos」から始める。Staging 環境で毎日 PodChaos を回し、リリース前に SLO を検証する文化を作る。「本番ではやっていません」と説明できる状態で半年〜1年の実績を積む。
第二に、本番導入時は「既存の計画停電枠」を活用する。月次メンテナンスウィンドウで小規模 chaos を実施し、「計画停電の一環」として位置付ける。これにより役員レベルの承認プロセスを新設する必要がなくなる。
第三に、game day を「訓練」として brand する。「障害対応訓練」「BCP 演習」と呼べば、品質管理部門や内部監査部門からむしろ評価される。実際に game day は ISO 22301（事業継続）や FISC 安全対策基準の演習要件を満たす根拠として使える。
成熟度と次のステップ
Chaos Engineering Maturity Model（Casey Rosenthal 提唱、2026年改訂版）では、成熟度が Level 1（ad hoc 実験）から Level 5（本番完全自動・継続実行）まで定義されている。日本企業の多くは Level 2（staging で定期実験）から Level 3（本番で game day）への移行フェーズにある。Level 4（本番自動実験）への移行には、SLO・Error Budget・observability の三点セットが完備されていることが前提で、前稿で触れた multi-window multi-burn-rate が機能していることが事実上の必要条件である。
KGA IT では、クライアントの SRE 成熟度診断のなかで「chaos engineering 導入ロードマップ」を 6〜18ヶ月単位で設計している。文化的障壁を越える順序が技術選定以上に重要で、Gremlin か LitmusChaos かの選択は実は後半の論点だ。