ClaudeをカオスエンジニアリングのMCPサーバーに繋いだら、ステージングを4回殺した — 6ヶ月見逃していた本番バグを見つけた話
最初に書きます。本記事の実験はすべてstaging環境で実行しています。productionは二重ロックです。CLAUDE.mdに「production環境でのカオス実験は無条件NG」を書き、PreToolUse hookで--env=productionの文字列を検出したらexit 2で実行を弾く。両方とも後段で書きます。「Claudeにカオス実験を設計させた」は字面で読むと不穏な一文なので、先に書いておきます。staging限定、二重ロック、最初から最後まで監督ありです。
その前提で本題。Steadybitが2025年6月に業界初と表現されることが多いカオスエンジニアリングMCPサーバーをリリースしました。Claude Codeに繋いで、一文だけ頼みました。「payment-serviceのコネクションプール耐障害性を測る実験を設計して」。Claudeは4本の実験を提案しました。3本はSLO違反なく完了しました。4本目でstagingが完全に落ちました。原因を追うと、人為的なテストバグではありませんでした。半年前から本番のログにチラついていて、これまで誰も再現できていなかった本物のバグでした。プール枯渇 → リトライ嵐 → レートリミッタ自己DoSの連鎖です。今日はその実験ログと、AIにカオスを任せる前に必須だった3つのガードレールを書きます。
5/12 サブエージェント → 5/13 Voice AI → 5/14 3役分離 → 5/15 デバッグ装備 → 本日 5/16 カオスMCPの、ハーネス装備シリーズ5回目です。シリーズの先頭から読む必要はなく、本記事はカオス章単独で読み切れる構成です。「症状を隠す修正をAIにやられた話」の姉妹記事は Claudeが3回連続でバグを「隠す修正」を出してきた話 です。
Steadybit MCPに繋ぐ手順、1段落で
Steadybitは2025年6月18日に、業界初と紹介されることが多いカオスエンジニアリング向けのMCPサーバーをリリースしました (Steadybit ニュース / BusinessWire 2025-06-30)。MCPはAnthropicが2024年末に公開したオープンプロトコルで、LLMクライアント (Claude / Gemini / ChatGPT) が外部ツールを構造化された型で呼び出すための標準規格です。Steadybit MCPサーバーは、実験カタログ、過去の実験結果、ポストモーテム、それと「新しい実験を設計する」ツールを公開しています。Claude CodeまたはClaude Desktopに繋ぎ、両方を同じstagingのKubernetesコンテキストに向けると、ターミナルに「payment-serviceのコネクションプール耐障害性実験を設計して」と書くだけで、承認用のパラメタ付き実験仕様が返ってきます。
セットアップは配管仕事です。本当に面白いのは、その配管から出てきたものを実際に流したときに何が起きるかです。
2026年のAI駆動カオス、4プレイヤーの整理
実験を回す前に、他にどんなアプローチがあるのか軽く整理しました。現時点で意味のある4プレイヤーは、それぞれ別のレバーを引いています。
Krkn-AI はRed Hat + IBM Researchが共同開発しているOSSフレームワークで、実験パラメータの探索を遺伝的アルゴリズムに任せます。生成 → 各パラメータを実験 → SLO (レイテンシ・エラーレート・可用性) でスコア → 上位を交叉・突然変異、をループします。狙いは「ギリギリSLOを破る組み合わせ」を見つけることです。99.9%のSLOを99.85%まで落とすパラメータ、明らかに全部壊すパラメータではありません。発見しにくく再現も難しい、本当に危険なやつです。Red Hat Developerの記事に詳しい解説があり、コードは krkn-chaos/krkn-ai です。
Harness AI は2025年1月にGenAI支援のカオスエンジニアリング機能を出し、その後 MCPツール をリリースしました。Claude Desktop / Windsurf / Cursor / VS Codeから自然言語で実験を設計・実行できます。Harnessエコシステムに既にいるなら、学習コストが最も低い経路です。
Steadybit は本記事で使った、専用のカオスMCPサーバーを最初にリリースしたプレイヤーです。差別化ポイントは実験履歴へのアクセスで、新しい実験を設計するだけでなく、過去の実験結果とポストモーテムをLLMが読み、自社のインシデント履歴に基づく提案ができます。
Dynatrace は逆方向のアプローチです。AIエンジンがシステムの正常な振る舞いを学習し、「今のパターンは過去のインシデント直前と似ている」を予測します。仮説を立ててから検証するのではなく、プラットフォーム側から「次にカオスを当てるべきサブシステム」を提示してきます。
四半期に1回しか実験を回さないならDynatraceの予測角度は過剰、研究チームがあってKubernetesを使っているならKrkn-AIの遺伝探索が最深、HarnessかSteadybitに既に住んでいるならMCP経由でダッシュボード税が消える。4社は競合というより、レイヤーで重ねるものです。
Claudeが提案した4本の実験
実際の運用に戻ります。プロンプトは1文でした。返ってきたのは4本の実験で、各々に対象サービス・障害タイプ・規模・持続時間・ロールバックSLO・ブラストレディアスが付いていました。仕様はYAMLでしたが、面白いのはLLMが読める構造ではなく実験設計の中身なので、要約で書きます。
実験1: プール30%削減、3分、1ポッド。 payment-service のコネクションプール上限を100から70に削る。対象はレプリカ1台のみ。SLOゲート: エラーレート1%未満。結果: green。レイテンシは約12%上がりましたが、エラーレートは0.2%で十分ゲート内。他のレプリカがトラフィックを吸収しました。人間のSREが最初に提案する種類の実験です。
実験2: プール50%削減 + リトライありの状態、3分、2ポッド。 同じ障害をより深く、2レプリカに当てる。クライアントライブラリのデフォルトのリトライ動作はオンのまま。SLOゲート: エラーレート1%未満、p99レイテンシ800ms未満。結果: greenでした。レイテンシp99は約640ms、エラーレートは0.4%。リトライ層がプール圧迫を吸収しました。
実験3: プール70%削減 + リクエストtimeout短縮、3分、2ポッド。 timeoutを5秒から1.5秒に下げて、プールは30に削減。仮説: 高負荷下では短いtimeoutは接続を早く解放して助けるのか、それともリクエストを途中で切って傷を増やすのか。結果: 意外にもgreen。エラーレート0.7%、p99レイテンシは早期切断のおかげで約520msまで下がりました。ここで止めようとしました。3回連続greenは耐障害性の証明に見えました。
実験4: プール90%削減 + リトライ上限なし、5分、3ポッド。 来ました。プールはポッドあたり10接続、リトライ予算は事実上無制限 (このクライアントのデフォルトで、configで上書きしていなかった)、3レプリカに同時に当てる。SLOゲート: エラーレート1%未満。結果: not green。最初の90秒以内に、エラーレートが0.5%から23%まで垂直に立ち上がり、p99レイテンシは200msから14秒、stagingは上流のゲートウェイから到達不能になりました。Steadybitが1%のSLO違反で自動ロールバックを発火しましたが、その時点では完全にウェッジしたサービスが残っていました。
最初の3つのgreenは耐障害性の証明ではありませんでした。「ブラストレディアスがシステムが吸収できる範囲に収まっていた」ことの証明でした。4本目がブラストを吸収できる境界の少し先まで広げた瞬間、下に潜んでいた病理が表に出ました。
Slackに「計画的な障害です」と書きました。当番のSREは笑いませんでした。彼は「先週分のポストモーテムチャンネル、まだピン留めしっぱなしじゃないですか」と言ってきました。新しいのをピンしておきました。
半年間見逃していた本番バグの正体
最初は「stagingの環境変数の差異か、サイドカーの挙動か、タイミング依存で本番では再現しないやつだろう」と思っていました。一応追いました。チェーンは3つで、各々は単独ではドキュメント済みでまったく問題なく、複合した瞬間に病気になります。
ピース1: コネクションプール枯渇。 プール上限10、3ポッド、通常トラフィック。新規接続が必要な受信リクエストは待つか、失敗しました。標準的な挙動です。驚きはありません。
ピース2: 呼び出し側の無制限リトライ。 payment-service を呼ぶ上流サービスは、試行回数ではなく1試行あたりの時間だけで制御されたリトライを持っていました。payment-service がプール枯渇エラーを返し始めると、呼び出し側はリトライしました。各リトライが新しいTCP接続を開き、プール待ちのキューに入り、timeoutになり、また次のリトライを発火しました。3回が9回になり、27回になり、数秒で呼び出し側の outbound concurrency が通常の十数倍に達しました。
ピース3: 呼び出し側自身のレートリミッタ。 ここに30分かかりました。呼び出し側は outbound 経路に自己防衛的なレートリミッタを持っていました。「下流のどのサービスに対しても、秒間N以上のリクエストを発行しない」というやつです。通常運用ではNに近づくことはありませんでした。リトライ嵐の最中、呼び出し側は自分のoutboundレートリミッタを超え、自分のリトライを自分で弾き始めました。アプリケーションコードはこれを下流の失敗と解釈し、さらにリトライを発火しました。呼び出し側は、自分のレートリミッタを武器にして自分自身をDoSしていました。下流の payment-service は回復できませんでした。新しいトラフィックが呼び出し側の自己DoSを抜けて「プールはもう空いていますよ」を伝えられないからです。
過去6ヶ月の本番ログを「このサービスからの outbound リトライ上でレートリミッタが拒否を返した」シグネチャでgrepしたら、11件ありました。各イベントは4秒から90秒の短さで、誰かがGrafanaを開き終わる前に自己回復し、「一時的、対応不要」のバケツに振り分けられていました。これがKrkn-AIのフィットネス関数が見つけようとしているパターンそのものでした。SLO境界のすぐ先に住んでいて、人間が見続けるには短すぎ、重要であるには十分な長さの障害です。
修正そのものは派手ではありませんでした。リトライをjitter付きで上限2に制限し、outboundレートリミッタを硬い拒否ではなくサーキットブレーカ的に振る舞うよう変更し、特定のシーケンス (プール枯渇 → リトライスパイク → リトライ上での outbound レートリミッタ拒否) にメトリクスを足しました。次に起きたときは、見えないところで自己回復せず、誰かをページします。
必須だった3つのガードレール
私は自律否定派ではありません。むしろ前日の記事で「症状隠しを止める10技法をプロンプト化してClaudeに任せる」を書いた側です。それでも「AIにカオスを設計させる」をガードレールなしでやるのは、私がこれまで試した中でstagingを最速で壊す方法でした。MCPサーバーを実環境に近づける前に、3つを必ず仕込んでいます。
ガードレール1: CLAUDE.md にポリシーを書く。 20行未満の短いブロックで、禁止事項とSLOゲートを名指しします。CLAUDE.mdの書き分けは CLAUDE.md でコンテキストエンジニアリングを実装する にまとめてあります。
## Chaos Rules
- カオス実験の対象はstaging環境のみ。productionは禁止 (production=trueの
cluster / namespace / serviceを含む)。
- 全実験はSLOゲート (エラーレート / レイテンシ / 可用性) を宣言し、超えたら
自動ロールバックする。
- ブラストレディアスは段階的: ポッド10% → 25% → 50%。段階をスキップする
場合はプロンプトで人間の承認を得る。
- 3回連続greenでも耐障害性を宣言しない。ブラストレディアスを広げるか、
別の障害タイプを提案してから停止する。
## Chaos Workflow
1. 対象環境がstagingであることを確認。違ったら拒否。
2. SLOゲート、ブラストレディアス、ロールバック条件を宣言して実験提案。
3. プロンプトで人間の承認を得てから MCP の run ツールを呼ぶ。
4. 実行中はメトリクスをストリーム。SLO違反で即座にロールバックツールを呼ぶ。
5. 実行後、1段落のポストモーテムを書く。CLAUDE.mdの難しい部分は、毎ターンcontextに乗る程度に短く保つことです。Anthropicの目安はおおよそ100-150行です。そのうち16行をカオスルールに割り当てるのは、初日にstagingを殺さないための公正な取引です。
ガードレール2: PreToolUse hookでポリシーを強制する。 CLAUDE.mdは脳です。hooksは反射神経です。脳は負荷がかかると無視されます。反射は無視されません。
{
"hooks": {
"PreToolUse": [
{
"matcher": "mcp__steadybit__run_experiment",
"hooks": [
{
"type": "command",
"command": "node ~/.claude/hooks/block-prod-chaos.js"
}
]
}
]
}
}ブロック側のスクリプトは、実験仕様にproductionマーカーが含まれていないかチェックします。env: production、cluster: prod、namespace: prod-* のいずれかがペイロードに現れたら、理由をstderrに書いてexit 2で呼び出しを弾きます。これは少なくとも1回、私を救いました。LLMが会話の途中で「本番でも確認するために昇格させましょうか」と親切に提案してきた瞬間、MCPサーバーに届く前にhookが止めました。
同じhookは、SLOゲートが数値で宣言されているか、ブラストレディアスの段階が前回 +1 になっているかも確認します。マジックナンバーだけの仕様? ブロック。段階2を飛ばす? ブロック。ルールの形をそのまま反射に焼き直します。hooks 全般の使い方は Claude Code Hooks v2 — 25個のイベント にまとめてあります。
ガードレール3: MCPサーバー側のSLOロック。 3層目はプラットフォーム側です。Steadybit (HarnessでもKrknでも構造は同じ) では、実験設定に rollback_on 述語があり、プラットフォーム自身がリアルタイムでメトリクスを評価して判定します。エラーレートが30秒間 1% を超えたら、LLMやローカルのhookが何をしようと、プラットフォームが実験を停止します。3層のうち、LLMもローカルエージェントも両方が侵害された状態で唯一生き残るレイヤーです。同時に、最も忘れられがちなレイヤーでもあります。チームのSLOに関する意見をYAMLに書く必要があり、誰もそれを書きたがらないからです。書いてください。
便利なテスト: チームメンバーをランダムに1人選び、CLAUDE.mdとhooksファイルを渡して「悪意があるとして、productionに当たる実験を設計できますか?」と聞きます。答えが「CLAUDE.mdを編集すればイエス」なら、プラットフォームのSLOロックが捕まえます。答えが「hookを消せばイエス」なら、プラットフォームのSLOロックが捕まえます。3層は冗長ではなく、別々の壊れ方に対応しています。
3役分離 (観測者・戦略家・実行者) のパターンはカオスにきれいにマップします。CLAUDE.mdが戦略家 (ポリシーを定める)、hooksが観測者 (何が起きるかを捕まえる)、MCPサーバーが両者の下にいる実行者です。この層をまたいで一人格にしないことが、AIエージェントがうっかり全部を兼ねないための仕組みです。
Chaos Engineering 2.0: 4つの流れが収束する
カメラを引きます。2024年の review 論文 Chaos Engineering 2.0: A Review of AI-Driven, Policy-Guided Resilience for Multi-Cloud Systems (journal ページ) は、モダンなスタックを3つの柱で整理しています。実験を設計するAIプランナー、アプリケーションコードに触らないサービスメッシュレベルでの障害注入、ブラストレディアスとSLO規律を強制するポリシー駆動のガードレールです。同論文は、調査対象組織の89%がマルチクラウド運用であるとも報告しています。これらの障害モード (クラウド間DNSドリフト、IAMトークンライフサイクル不一致、リージョン固有のレートリミッタ) が実際に住んでいる環境です。
直近では ChaosEater (2025) という arxiv 論文が、完全にLLMオーケストレーションされたカオスサイクル (モデルが実験設計・実行・分析をポリシーガードレールの下で全部受け持つ) を提案しています。先ほどの4製品が歩いている方向の、研究側からの同じ歩み方です。
4つの流れが収束する (カオスエンジニアリング、可観測性、AI / LLM、プラットフォームエンジニアリング)。これはマーケティングの絵ではありません。私のstaging事故が乗っていた実際のワークフローです。カオスエンジニアリングが実験を提供しました。可観測性が90秒でSLO違反を検出するメトリクスストリームを提供しました。LLMが実験設計と、後にログのチェーンを読み解いて本番バグを特定する手助けをしました。プラットフォームエンジニアリング (Steadybit + hooks + CLAUDE.md) がブラストレディアスにproductionを含めないようにしました。
このうちどれか1つを抜くと、同じ話は違う結末になります。LLMなしなら、誰も実験4を提案しません (一見明らかに無謀に見えるからです)。可観測性なしなら、SLO違反の検出に数分かかります。ポリシーガードレールなしなら、「本番でも確認しましょう」が現実に起こります。意図的な実践としてのカオスなしなら、バグはもう半年見えません。
来週これを試す人へ
夜中の11時にstagingを殺さずに同じことを試したい人向けに、ハインドサイトでやり直すならこうする、をまとめます。
実験1だけ、単一namespaceで、ブラストレディアスをポッド10%にキャップして始めてください。最初のgreenは「ブラストレディアスを広げてよい」のシグナルであって、「勝った」のシグナルではありません。面白い実験は、システムが吸収できる境界の少し先で起きるやつです。
CLAUDE.mdとhooksは、MCPサーバーを繋ぐ 前 に書いてください。後でも、並行でもなく、前にです。新しいピカピカのおもちゃを手に入れた誘惑は「1時間遊んでからガードレールを足そう」です。その1時間が staging が死ぬ時間です。死んだ後はルールを書く忍耐が最小になる時間でもあります。
実行後のプロンプトは短くしてください。「何が失敗したか、どのSLOが違反したか、最も可能性の高い根本原因」で足ります。SLO違反のあとの長いプロンプトは、LLMを物語モードに引きずります。証拠モードのほうがほしいです、物語モードではなく。
カオスから得たポストモーテムの習慣を、AIコーディング全般に持ち込んでください。本記事が存在する理由は、私が90秒のインシデントから1ページのメモを通常のインシデントドキュメントと同じ形で残していたからです。そのメモがなければ、これは雰囲気のブログ記事になっていました。あったから、証拠1ピースあたり1段落と、同じ週に本番に着地した修正があります。
AIはどのSREよりも速くカオスを設計します。3つのガードレールがなければ、stagingも最速で殺します。3つを噛ませて初めて「半年見逃していたバグを見つける」が手に入ります。当番のSREの週末もちゃんと手に入ります。
本記事のソースは、Krkn-AI / Harness / Steadybit / Dynatrace の全景、Chaos Engineering 2.0、本番でカオスを回しつつニュースにならないための運用手法を14章でまとめたBookです。
カオスエンジニアリング: モダン分散システムのための実践ガイド
ハーネスシリーズの関連記事:
この記事は役に立ちましたか？