記事

障害対応でClaude Codeを使うときの安全な進め方

本番障害や緊急調査でClaude Codeを使うときに、二次被害を出さないための運用フローを整理します。ログ整理・原因仮説・暫定対応・恒久対応・コミュニケーションの5ステップ、本番に触れる前のセーフガード設定、コピペで使える依頼文テンプレートまで扱います。

本番障害の最中にClaude Codeを起動すると、「ログ整理が速い」「仮説出しが速い」というメリットの一方で、焦って依頼するとAIがrmを提案する／本番DBに繋ぐ／秘密情報をログ経由で読み込むといった二次被害が起きやすい状況になります。この記事では、障害対応にClaude Codeを使うときに守るべき5ステップと、事前に仕込んでおくセーフガード設定を整理します。スタックトレースの読ませ方そのものは「Claude Codeでスタックトレースを読ませてバグ原因を調べる方法」を参照してください。

結論：本番に触る前に「Claude Codeを起こす場所」を分けておく

障害対応中のAI利用は、操作を実行できる場所を限定し、AIには調査と仮説出しまでを任せるのが原則です。具体的には次の3つを先に決めておきます。

AIを起動する場所：本番サーバーへSSHした端末ではなく、ローカルの作業ディレクトリで起動する
AIに渡すログの範囲：本番ログ全体ではなく、症状に関係する範囲だけを切り出して渡す
AIに承認させない操作：Bash(kubectl delete *) Bash(rm *) Bash(curl *)などはdenyに固定

これらを障害発生時に決めるのは間に合いません。チームのCLAUDE.mdと.claude/settings.jsonに平時から書いておきます。チーム導入時の合意事項は「チームでClaude Codeを導入するときに最初に決めるルール」にまとめています。

ステップ1：障害発生直後の準備（最初の5分）

火が出ている最中にClaude Codeへ「直して」と頼むのが一番危険です。最初の5分は人間が以下を整えます。

影響範囲の暫定確認（どのユーザー／どの機能が落ちているか）
関連ログ・メトリクス・アラート画面のURLを1か所にまとめる
直前のリリース・デプロイ・設定変更を時系列で書き出す
Claude Codeを起動する場所をローカルの作業用リポジトリに固定する

この段階で**「本番サーバーに直接Claude Codeを起動しない」**ことが最大のポイントです。本番サーバー上で起動するとPATH上のコマンドを実行できてしまうため、AIがsystemctl restart等を提案する余地が生まれます。

ステップ2：ログの整理とAIへの渡し方

AIに渡すログは「全部」ではなく「症状に直結する範囲だけ」にします。ログ全文を渡すと、コンテキスト圧迫で精度が落ち、秘密情報も混ざりやすくなります。

grep -B 2 -A 30 'ERROR' /var/log/app/error.log | tail -200 > /tmp/incident.log

/tmp/incident.logのような短い切り出しを@incident.logで参照させると、AIが見るべき範囲が明確になります。Authorization・Cookie・X-Api-Key・接続文字列を含む行は事前に伏字化します。

sed -E 's/(Authorization|Cookie|X-Api-Key):\s*\S+/\1: [REDACTED]/g; s|postgresql://[^@]+@|postgresql://[REDACTED]@|g' /tmp/incident.log > /tmp/incident.safe.log

ログから秘密情報を除く具体的なルールは「Claude Codeに秘密情報を渡さないための実践ルール」で扱っています。

ステップ3：原因仮説出しはPlan Modeで複数案を出させる

実装に走らせず、まず仮説を出させます。Plan Modeを使うと、ファイル編集系のツールは封じられたまま読み取り系で調査・仮説出しに集中させられます。

claude --permission-mode plan

依頼文テンプレートの例です。

依頼：以下のログとアプリケーションコードから、5/13 09:42 ごろから発生した /api/orders エンドポイントの 5xx 急増の原因仮説を出してください。

## 入力
- @/tmp/incident.safe.log
- @apps/api/src/routes/orders.ts
- @apps/api/src/lib/db.ts

## 直前の変更
- 5/13 09:30 にデプロイした PR #4821（Sentry の SDK バージョン更新）
- 5/13 09:15 にスキーマ追加（orders.shipping_method カラム NOT NULL）

## 出力
- 仮説を 3〜5 個、優先度順に
- 各仮説について：直接原因、上流原因、検証方法、影響範囲、ロールバック可否を一文ずつ

## 制約
- このセッションでは実装も本番接続もしない
- 仮説に挙げる修正候補も、提案だけにとどめる
- ログにある個人情報は復元しようとしない

Plan Modeで仮説を5個出させ、人間が**「優先して検証すべきもの」を1つ選ぶ**運用にします。AIに優先度を決めさせない、というのが重要なポイントです。

ステップ4：暫定対応と恒久対応を切り分ける

仮説のうち最有力なものが固まったら、暫定対応と恒久対応を分けて進めます。暫定対応は「血を止める」処置で、恒久対応は「原因を直す」処置です。AIに同じセッションで両方任せると、片方の対応がもう片方を上書きすることがあります。

区分	目的	例	Claude Codeに依頼する範囲
暫定対応	影響を止める／縮小する	フィーチャーフラグOFF・ロールバック・キャッシュ無効化	コマンドの整理と差分プレビューまで
恒久対応	原因を直す	バグ修正・スキーマ修正・テスト追加	別ブランチでPR作成まで

暫定対応の実行は人間が行います。Claude Codeには、たとえば「ロールバック手順を順序付きでまとめてください」「フィーチャーフラグをOFFにする依頼を関係チームに送る文章を書いてください」のように、整理と文章化に絞って任せます。

ステップ5：コミュニケーションと記録

障害対応の半分はステークホルダーへの連絡と、ポストモーテムです。Claude Codeに任せやすい部分でもあります。

依頼：障害ステータス更新を以下の3パターンで作ってください。

1. 社内向け（Slack #incident）：状況・対応中の人・暫定対応の進捗・次の更新時刻
2. ユーザー向け（Status Page）：影響を受けている機能・現時点で分かっていること・回復見込み
3. 役員向け（要点）：影響範囲・原因の方向性・ビジネスインパクト・追加リソース要請

## 制約
- 確定していない情報は「調査中」と書く
- 個人情報・APIキー・ログの生データは含めない
- 各文 100 字以内

依頼文の基本構造は「Claude Codeに伝わるプロンプトの基本構造」を参照してください。

平時に仕込んでおくセーフガード設定

障害発生時に焦らないために、平時から.claude/settings.jsonに次を入れておきます。

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(kubectl delete *)",
      "Bash(systemctl *)",
      "Bash(docker rm *)",
      "Bash(aws *)",
      "Bash(gcloud *)",
      "Bash(curl *production*)",
      "Read(./.env*)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr merge *)"
    ]
  },
  "defaultMode": "default"
}

セキュリティ全体の整理は「Claude Codeを使うときのセキュリティチェックリスト」で扱っています。

やってはいけないことリスト

障害対応中、AIに任せてはいけない代表例です。

本番サーバーへSSHしたターミナルでClaude Codeを起動する
本番DBに直接クエリを投げる依頼を出す
--permission-mode bypassPermissionsを「速いから」という理由で使う
ログ全文を伏字化せずそのまま渡す
「全部直して」「いい感じに復旧して」のような曖昧な丸投げ
仮説検証を飛ばして「修正PR出して」と頼む
AIが提案した暫定対応コマンドを差分を見ずに実行する

「いい感じに直して」が失敗する理由は「Claude Codeでやりがちな悪い依頼文と改善例」で詳しく扱っています。

ポストモーテムでのClaude Code活用

障害が落ち着いた後、ポストモーテムの作成にもClaude Codeを使えます。事実関係の時系列化、影響範囲の数値化、再発防止策の候補出しは得意領域です。一方で「責任の所在」「組織的な原因」「人間の判断ミス」の部分は、AIに評価させずチームで議論します。

依頼：以下の障害対応ログから、ポストモーテムの「事実関係」と「再発防止策の候補」のドラフトを作ってください。

## 入力
- @incident-2026-05-13.md（時系列メモ）
- @postmortem-template.md（社内テンプレ）

## 制約
- 個人の責任には言及しない（システム・プロセスの観点で書く）
- 確定していない事実は「[要確認]」を付けて区別する
- 推測した数値はその旨を明記する

## 出力
- テンプレに沿った Markdown
- 再発防止策は 3〜5 個、コスト × 効果でラベル付け