IVYXON
記事一覧に戻る
一般Tips上級📖 Reference

障害起きたらどうするんだっけ?Claudeに聞いてRunbook作らせたら超ラクだった

Claude Codeに障害復旧手順書(Runbook)を作らせて、いざという時の焦りをなくす方法を紹介するよ。

2026年6月1日7分で読めます

みんな、サービス運用してるといつか来るのが「障害」だよね。その時になって「えっと、どうするんだっけ?」ってパニクるの、マジでしんどい。そんな時に頼りになるのが障害復旧手順書、通称Runbookだよ。

でも、Runbook作るのって、めちゃくちゃ手間じゃない?サービスの全体像から具体的なコマンドまで、全部手書きなんてやってられない。

そこで、Claude Codeの出番だよ! 僕らはClaude CodeにRunbookを作らせて、いざという時にサッと使えるようにしてるんだ。

一番雑な投げ方

まずはこれだけで試してみて。

俺のサービスの障害復旧手順書をコマンド込みで作ってくれ。

これだけで、Claude CodeはRunbookの基本的な構成と、一般的なサービスで必要になるであろう確認コマンドの案をざっくりと出してくれるよ。マジで動くからビビる。

もうちょい具体的に投げるパターン

これだけじゃ物足りない?だよね。もっと質の高いRunbookが欲しいなら、もうちょいヒントをあげるんだ。

構成情報と目標を伝えるパターン

自分のサービスがどんな構成で動いてて、どのくらいの時間で復旧したいのか、っていう概要を教えてあげるんだ。

俺たちのサービスはCloudflare WorkersでNext.jsアプリを動かしてて、バックエンドはSupabaseを使ってる。
RTO(目標復旧時間)は30分、RPO(目標復旧時点)は24時間以内が目標なんだ。
このサービス向けの障害復旧手順書を、具体的な確認コマンドとか復旧ステップ込みで作ってほしい。

Claude Codeは、この情報をもとに、CloudflareやSupabaseに特化したコマンドや、障害レベルに応じたRTOの提案までしてくれることがあるよ。

既存の情報をたたき台にするパターン

もし既に何かしらのメモや古いRunbookがあるなら、それをたたき台にしてもらうのが最強だよ。

今、こんな感じのDR Runbookがあるんだけど、これを元にもっと実践的なコマンドと具体的な復旧手順を拡充してくれない?特にWorkersとSupabase周りの障害対応を厚くしたいんだ。

# DR Runbook(障害復旧手順書)

## 目標指標
RTO: 30分以内
RPO: 24時間以内

## インフラ構成
ユーザー → CDN → Workers(Next.js)
         ↓
         Supabase (PostgreSQL, Auth, Storage)

## 1. 障害レベル判定
L1: 全面ダウン (Workers/Supabase両方)
L2: 部分障害 (DB接続不可, Auth障害)
L3: 機能劣化 (一部機能のみ影響)

こうすることで、Claude Codeは既存の情報を理解しつつ、より詳細で実行可能なコマンドや手順を追加してくれるんだ。まさに「かゆいところに手が届く」ってやつだね。

実践例 / 実録

僕らが実際にどうやってRunbookを作って運用してるのか、実録形式で紹介するよ。

まず、僕らは上記「既存の情報をたたき台にするパターン」で、サービス構成と目標、ざっくりとした障害レベル判定の情報をClaude Codeに投げたんだ。

投げたらこうなった!

  1. Runbookの全体像と詳細化: Claude Codeは、まずRunbookの構成を提案してくれた。障害レベル判定も、L1からL4まで細かく定義してくれて、それぞれ影響範囲やRTOの目安まで提示してくれたよ。

  2. 確認コマンド集の生成: 次に「確認コマンドも欲しいんだけど」って伝えたら、具体的なコマンドを吐き出してくれたんだ。 例えば、サイトの死活確認にはcurl -sI https://your-app.com/api/health | head -5みたいなコマンド。Supabaseの接続確認にはAPIキー入りのcurlコマンド。もちろんAPIキーの部分は[REDACTED]になってて、「ここには自分のAPIキーを入れてね」ってしっかり注意書きがあったのは助かった。

  3. メンテナンスモードの切り替え手順: さらに「障害中にサービスを一時停止するメンテナンスモードの切り替えってどうやる?」って聞いたら、Cloudflare WorkersのSecretを使った具体的なコマンドを教えてくれたんだ。

    # メンテナンスモード ON
    npx wrangler secret put MAINTENANCE_MODE <<< "true"
    
    # メンテナンスモード OFF
    npx wrangler secret delete MAINTENANCE_MODE
    

    WorkersはSecret変えるだけで即反映されるから、これはマジで便利だったね。

  4. 具体的な復旧手順のステップ化: そしてメインの復旧手順。「Cloudflare Workersが落ちた場合」と「Supabaseに障害があった場合」の2パターンで、それぞれ取るべき行動と具体的なコマンドをステップバイステップで出してくれた。

    例えばWorkers障害なら、まずは「最新の修正をコミット&pushしてCI/CDで再デプロイを試す」みたいな基本的なところから、「それでもダメなら過去の安定版に戻す」といったリカバリープランまで、コマンド付きで教えてくれたんだ。

この出力結果をそのままMarkdownファイルとして保存して、チームの共有ドキュメントに入れてるよ。これで、いざ障害が起きても、みんな焦らずに対応できるようになったんだ。

つまずきポイント

Claude CodeにRunbookを作らせる時に、いくつか「あ、これ気をつけないと」って思ったことがあるから共有するね。

  • APIキーやトークンは手動で置き換え: 当然だけど、Claude Codeは僕らの機密情報を知らないから、[REDACTED]YOUR_API_KEYみたいなプレースホルダーで出してくる。そこは自分でちゃんと実際の値に置き換える必要があるよ。うっかりそのまま実行しないように注意して。

  • 環境変数名やSecret名は確認する: Claude Codeは一般的な名前で提案してくることが多いけど、自分の環境で使ってる環境変数名やSecret名と違うことがある。その場合は、自分の環境に合わせてコマンドを修正してね。

  • Runbookは生き物!定期的なレビューが命: 一度Claude Codeに作らせたら終わりじゃないよ。サービスって常に進化してるから、構成が変わったり、新しい機能が増えたりするたびに、Runbookも古くなるんだ。 だから、定期的に「今のサービス構成とこのRunbook、合ってる?」とか「新機能追加したんだけど、障害対応の手順に何か変更ある?」ってClaude Codeにレビューさせて、常に最新の状態を保つのが超重要だよ。僕らは2ヶ月に1回くらい見直すようにしてる。

  • コマンドは必ずテスト環境で試す: Claude Codeが出してくれたコマンドは、論理的には正しいはずだけど、それが本当に自分の環境で期待通りに動くかは別問題。特に復旧系のコマンドは、本番環境でいきなり実行する前に、必ずステージング環境や開発環境でテストしてから使ってね。