こんにちは。メルカリで暗号資産交換業を提供しているメルコインCTOのpoohです。
この記事は、Mercari Advent Calendar 2025 の24日目の記事です。
メルカリグループ内で、CAST分析の取り組みが広がりつつあります。メルコインではすでに導入しており、他のプロダクトチームでも検討や試行が始まっています。
私はこれまで10年以上、SREとして障害対応やオンコール運用に関わってきました。 インフラ、SRE、データ基盤と領域は違っても、やってきたことは同じです。
障害が起きる。 振り返る。 再発防止策を考える。
それなりに真剣にやってきたはずなのに、 しばらくすると、よく似た構図の問題がまた起きる。
この違和感を、長い間うまく説明できずにいました。
再発防止は「サボられている」わけではない
最初に強調しておきたいのは、 多くの現場で再発防止はちゃんと考えられている、ということです。
- レビューで拾えたはずだった
- QAの観点が足りなかった
- 想定が甘かった
- 次はもう少し丁寧にやろう
どれも正論です。 真面目に向き合っている証拠でもあります。
それでも、思ったように再発防止が効かない。
これは意識や姿勢の問題ではない、と感じていました。
原因は、いつも「最後」に集まる
振り返りをすると、原因はどうしてもリリース直前や本番直前に寄りがちです。
QAで見落とした。 本番確認が足りなかった。
でも少し引いて見ると、違和感があります。
仕様を考えた人がいて、 実装した人がいて、 レビューした人がいて、 QA判断をした人がいる。
そのすべてを通り抜けて、 最後の工程だけを「根本原因」と呼ぶのは、無理がある。
この違和感に、はっきり名前をつけてくれたのがCAST分析でした。
Google SREが直面している「エラーバジェット0」の世界
CAST分析に興味を持った大きなきっかけの一つが、 Google SREが「エラーバジェット0のシステム」を前提に考え始めている、という話(The Evolution of SRE at Google)です。
SREの世界では、 エラーバジェットを使ってスピードと安全性のバランスを取ります。
一方で、Google自身が向き合っている現実もあります。
金融、規制対応、社会インフラ。 サービスが落ちてはいけない。 失敗が許されない。 それでも人が設計し、人が運用する。
today our products have losses that must never occur—error budgets of zero. The types of failures we need to prevent have evolved beyond what error budgets can effectively address.
現在では私たちの製品には絶対に発生してはならない損失、つまりエラーバジェットがゼロという状況が存在します。防止すべき障害の種類は、エラーバジェットが効果的に対処できる範囲を超えています。
エラーバジェットを持てないシステムでは、 「失敗は起きる前提でうまく付き合う」というモデルだけでは足りない。
その文脈で使われていたのが、CAST分析でした。
CAST分析は、問いを変える
CAST分析が前提にしている考え方は、とてもシンプルです。
障害は、誰かの判断ミスで起きたのではない。 その判断を「正しい」と思わせる状況が積み重なった結果として起きる。
だから問うべきなのは、
なぜその判断をしたのか。 なぜその選択が合理的に見えたのか。
結果を知ったあとに 「あの時こうすべきだった」と言うのは簡単ですが、 それは後知恵バイアスです。
CAST分析は、 当時の情報、制約、前提の中での合理性を丁寧に扱います。
実際のCAST分析は、こう進む（抽象化した例）
ここから、実際にメルカリで行っているCAST分析の一部を、 特定につながらない形で紹介します。
題材にしたのは、 既存のプロダクト施策に対する、ごく小さな運用変更でした。
変更内容自体はシンプルで、 「影響範囲は広いが、作業内容は限定的」 と判断されていたものです。
結果としては、 お客さまがサービスを正しく利用できない状態が一定時間続いてしまいました。
従来の振り返りだと、こうなる
普通に振り返ると、こう整理できます。
- 必要な設定の一部が更新されていなかった
- レビューやQAで気づけなかった
- 本番確認が十分ではなかった
事実としては正しい。 でも、ここから出てくる対策はだいたい同じです。
- チェックリストを作る
- レビューを強化する
- QAを必須にする
「もっとちゃんとやろう」で終わってしまう。
CAST分析で見えた構造
CAST分析では、原因を一点に絞りません。 システム全体の構造を見ます。
このケースで見えてきたのは、こんな状況でした。
- 過去は特定の設定だけ更新すれば問題なかった時代があった
- 仕様は段階的に変化していたが、手順や認識は更新されていなかった
- PM・エンジニア・QAがそれぞれ異なる前提をもとに判断していた
- PMが自分で設定や状態を確認する手段を持っていなかった
- システム上は「仕様通りの挙動」が続き、監視では異常と判定されなかった
誰かがサボったわけでも、 誰かが雑だったわけでもありません。
その構造の中にいれば、同じ判断をするのが自然 という状態ができていました。
出てきた再発防止策が、まったく違う
ここが、CAST分析の一番大きな違いです。
出てきた提言は、 「誰が気をつけるか」ではありません。
- 不正な設定の組み合わせは、そもそも保存できないようにする
- 状態を人に聞かなくても確認できる仕組みを用意する
- 「施策が意図通りに機能しているか」を直接捉える指標を持つ
- 深夜や休日の切り替えを原則避ける
- 「軽微な変更」の定義を、工数ではなく失敗時の損失で考える
すべて、 個人の注意力に依存しない改善です。これらの提言には従来実施してきたretrospectiveででたものもあります。網羅性ある振り返りができるというのがお気に入りです。
経営陣の視点で見たときの意味
このCAST分析が、 経営陣が読んだときに意味を持つ理由はここにあります。
- 現場の誰かを責める話にならない
- なぜその判断が起きたのかを、構造として説明できる
- 再発防止が「人の問題」ではなく「組織と仕組みの話」になる
- 同じことが別のプロダクトでも起こりうると理解できる
CAST分析は、 障害対応の手法というより、 プロダクト開発を安全にスケールさせるための考え方 だと感じています。
再発防止を、本当に機能させたいなら
もし、
振り返りをちゃんとやっているのに、 同じ構図の問題が繰り返される。 対策が注意喚起やチェックリストに寄っている。
そんな感覚があるなら、 CAST分析は一度きちんと調べてみる価値があります。
銀の弾丸ではありません。 でも、問いの立て方が変わります。
それだけで、 再発防止は少しずつ、 本当に機能し始めます。
CAST分析、 ぜひ一度触れてみてください。
参考資料
明日の記事は kimurasさんとYusakuさんです。引き続きお楽しみください。
