結論：SaaSの障害対応にClaude Codeを入れるなら、最初に狙うべきは「本番を触る自動復旧」ではなく、runbook、ログ調査、再現手順、修正PR、事後レビューを同じ型にそろえることです。
- 要点1：Claude Codeは公式ドキュメント上、機能開発・バグ修正・開発タスク自動化を支援するコーディングアシスタントとして位置づけられています。障害対応では、その力を「調査と変更の標準化」に使うのが安全です。
- 要点2：権限設計は導入の中心です。公式セキュリティ文書では、デフォルトは読み取り中心で、編集・テスト・コマンド実行には明示的な許可が必要と説明されています。
- 要点3：この記事の事例は想定シナリオです。実測ベンチマークではなく、SaaSチームが導入設計を検討するための実装パターンとして読んでください。
対象読者：Claude CodeをSaaS運用、SRE、バックエンド保守、障害対応フローに入れたいエンジニア、EM、PM。
今日やること：まずは直近3件の障害メモを集め、Claude Codeに「原因・検知・暫定対応・恒久対応・未解決リスク」の5項目へ整理させる検証から始めてください。
事例区分：想定シナリオ。本記事は、SaaSの障害対応を題材にしたモデルケースです。特定企業の実測成果や、非公開案件の成果数値ではありません。Claude Codeの公式ドキュメントと、一般的なSRE運用の考え方をもとに、導入時に再現しやすい設計手順として整理しています。
障害対応にAIを入れる話になると、つい「AIが自動で直してくれる」方向に期待が寄りがちです。正直、その発想のまま本番環境へ入れるのは危ないです。障害対応は、コード修正だけでなく、検知、影響範囲の確認、顧客連絡、ロールバック、監査、事後レビューまでつながる複合業務だからです。
一方で、Claude Codeが得意な領域はかなりはっきりしています。コードベースを読み、関連ファイルをたどり、ログやIssueの文脈から変更案を作り、テストやPRの形に落とすことです。つまり、障害対応のなかでも「人間が判断する前の整理」と「人間が承認した後の実装」に強い。
この記事では、SaaSのAPI障害を例に、Claude Codeを障害対応へ導入する5手順を解説します。過剰な自動化ではなく、権限を絞りながら、チームの対応品質を安定させる実装パターンです。関連する既存事例として、CI/CD自動修復をClaude Codeで実装する5手順や、SaaSのCSヘルススコアをClaude Codeで作る事例もあわせて参照すると、開発側と顧客対応側の接続が見えやすくなります。
1. SaaS障害対応でClaude Codeに任せる範囲を決める
最初に決めるべきなのは、Claude Codeに何を「させるか」ではなく、何を「させないか」です。障害対応では、便利さよりも境界線が重要です。特に本番データ、顧客情報、課金処理、認証基盤に関わる領域では、AIエージェントが出した提案をそのまま実行する設計は避けるべきです。
Claude Codeの公式概要では、コードベース全体を理解し、複数ファイルやツールをまたいで、機能開発・バグ修正・開発タスク自動化を支援するツールとして説明されています（参照：Claude Code Overview、参照日: 2026-05-25）。この説明からも、障害対応では「本番操作の代理人」ではなく「コードと手順の共同編集者」として使うのが自然です。
想定シナリオでは、B2B SaaSのバックエンドチームが、APIの応答遅延と一部500エラーに対する初動を標準化することを目的にします。対象は、ログの読み取り、関連コードの特定、再現テスト、暫定対応案、恒久対応PR、事後レビュー文書です。本番DBへの直接接続、障害告知の自動送信、ロールバックコマンドの自動実行は対象外にします。
| 領域 | Claude Codeに任せる | 人間が承認する |
|---|---|---|
| 検知 | アラート文面とログの整理 | 障害判定、優先度、顧客影響 |
| 調査 | 関連ファイル、最近の差分、再現条件の候補出し | 真因の確定、暫定対応の採否 |
| 修正 | テスト追加、修正PRの初稿、レビュー観点の作成 | マージ、リリース、ロールバック判断 |
| 事後対応 | ポストモーテム草案、runbook更新案 | 対外説明、再発防止策の優先順位 |
この切り分けにしておくと、Claude Codeの出力が外れても事故につながりにくくなります。AIの導入で一番怖いのは、最初から「便利そうだから全部任せる」ことです。障害対応のような高リスク業務では、読み取り、整理、草案作成、テスト生成、PR作成の順に範囲を広げるほうが安全です。
2. 権限設計：読み取り中心から始める
Claude Code導入で一番ハマりやすいのが権限設計です。公式セキュリティ文書では、Claude Codeはデフォルトで厳格な読み取り中心の権限になっており、ファイル編集、テスト実行、コマンド実行など追加の操作が必要な場合は明示的な許可を求めると説明されています（参照：Claude Code Security、参照日: 2026-05-25）。
この設計思想は、障害対応と相性が良いです。なぜなら障害対応では、最初の数十分に「何が起きているか」を正しく把握することが最も重要だからです。Claude Codeには、いきなり修正させるより、まず情報を整理させます。たとえば、監視アラート、直近のデプロイ差分、関連ログ、Issue、過去の類似障害を読み、仮説を3つに分けてもらう形です。
また、Claude Codeの設定にはスコープの考え方があります。公式設定ドキュメントでは、Managed、User、Project、Localなどの設定スコープが説明され、チーム共有の権限やフック、MCPサーバーなどはProjectやManagedで管理できるとされています（参照：Claude Code settings、参照日: 2026-05-25）。障害対応用途では、個人の気分で許可コマンドが変わる状態を避けるため、プロジェクト単位で設定を明文化するのが現実的です。
# 例：障害調査で許可しやすい読み取り系コマンドの考え方
# 実際の設定は組織の規程に合わせて調整してください
- git log --oneline --since="7 days ago"
- git diff origin/main...HEAD
- rg "対象エラーコード" app/ tests/
- npm test -- --runInBand 対象テスト
- pytest tests/path/to/test_file.py
逆に、本番操作、外部APIへの書き込み、顧客データのエクスポート、認証情報の表示、課金・決済に関わる操作は、Claude Codeの許可コマンドに入れないほうが安全です。Claude Codeは強力ですが、責任主体はあくまでチーム側です。公式セキュリティ文書でも、提案されたコードやコマンドをレビューする責任はユーザーにあると説明されています。
3. 障害対応runbookをClaude Codeで構造化する
障害対応の最初の実装対象としておすすめなのがrunbookです。runbookとは、障害が起きたときに誰が、どの情報を見て、どの順番で判断するかをまとめた手順書です。ここが曖昧だと、AIを入れても混乱が増えます。むしろ、曖昧な手順をAIが高速に拡大してしまうことすらあります。
Claude Codeには、過去の障害メモ、Issue、Slackに転記した調査ログ、ポストモーテム、関連コードを読ませ、runbookの欠落を洗い出させます。ポイントは、最初からきれいな文章を書かせるのではなく、項目をそろえさせることです。検知条件、影響範囲、一次対応、二次対応、ロールバック、連絡先、再発防止の7項目に固定すると、後から比較しやすくなります。
プロンプト例です。Claude Code上で実行する前提ですが、組織の機密情報や個人情報を含むログはそのまま投入しないでください。
直近の障害対応メモと docs/runbooks/ を読み、API 5xx 障害のrunbookを改善してください。
出力は以下の順番にしてください。
1. 現在のrunbookに足りない項目
2. 既存手順の曖昧な表現
3. 初動10分で確認すべきログとダッシュボード
4. 人間の承認が必要な操作
5. docs/runbooks/api-5xx.md への修正案
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。このプロンプトで大事なのは、「修正してください」だけで終わらせていない点です。足りない項目、曖昧な表現、初動で見るべき情報、人間承認が必要な操作を先に列挙させています。これにより、Claude Codeの出力がドキュメント修正だけでなく、運用設計のレビューにもなります。
runbook更新では、内部リンクも有効です。たとえば、障害原因がCI/CDの壊れたデプロイにある場合は、CI/CD自動修復のClaude Code実装事例を参照し、デプロイ前チェックと障害後チェックを接続します。顧客影響の確認が必要な場合は、CSヘルススコアの整理事例と接続し、障害対応と顧客対応を分断しない設計にします。
4. ログ調査と再現手順を分けて扱う
障害対応でよくある失敗は、ログを眺めながら同時に修正案を考えてしまうことです。人間でも混乱しますし、AIでも同じです。Claude Codeに依頼するときは、「ログ調査」と「再現手順」と「修正案」を分けます。この分割だけで、レビューしやすさがかなり変わります。
たとえばAPIの一部エンドポイントで500エラーが増えている場合、最初の依頼は修正ではなく、観測事実の整理に限定します。どのエンドポイントで、どの時間帯に、どのリクエスト条件で、どの例外が発生しているのか。ここを構造化できないまま修正PRに進むと、たまたまテストが通るだけの変更になりがちです。
logs/sample-api-error.log と app/api/ 以下を読み、修正案はまだ出さずに調査メモだけ作成してください。
調査メモは以下の形式にしてください。
- 観測された事実
- まだ仮説に過ぎないこと
- 再現に必要そうな入力条件
- 追加で確認すべきログ
- 影響範囲を判断するために人間が見るべき指標
数字と固有名詞は、根拠（ファイル名・行番号・ログ行）を添えてください。次に、再現テストを作らせます。ここでも「直して」ではなく「失敗するテストを書いて」と指示します。テストが先にあると、Claude Codeの修正案をレビューしやすくなります。これはTDDの基本でもありますが、AIエージェント導入時には特に効きます。AIが出した変更が正しいかどうかを、人間の感覚だけで見るのは危ないからです。
上の調査メモを前提に、まず失敗するテストだけを追加してください。
本番コードは変更しないでください。
テスト名には、再現条件が分かる名前を付けてください。
テストが失敗する理由を、ファイル名と行番号つきで説明してください。
不足している情報があれば、最初に質問してから作業を開始してください。ここまで来て、ようやく修正案に進みます。Claude Codeに修正させる場合も、変更範囲を絞ります。関連ファイル全体を自由に変更させるのではなく、テストで再現できた箇所、影響が限定された関数、設定ファイルの差分に限定します。レビュー観点も同時に出させると、チームのコードレビューが楽になります。
5. GitHub Actions連携でPR運用に乗せる
障害対応の修正PRをチーム運用に乗せるなら、GitHub Actions連携も検討できます。公式ドキュメントでは、Claude Code GitHub ActionsはPRやIssueでの@claudeメンションにより、コード解析、PR作成、機能実装、バグ修正を支援できると説明されています。また、コードはGitHubのrunner上に留まるという説明もあります（参照：Claude Code GitHub Actions、参照日: 2026-05-25）。
障害対応では、Issueを起点にする設計が扱いやすいです。アラートから自動でIssueを作る場合でも、Claude Codeに直接本番操作をさせるのではなく、Issue上で調査観点と修正PRの初稿を作らせます。これなら、既存のレビュー、CI、承認フローに乗ります。
GitHub Issue 例：
Title: API /v1/invoices で特定条件の500エラーが増加
Body:
- 発生時間: 2026-05-25 09:10 JST 以降
- 影響: 一部テナントの請求書一覧API
- 添付: サンプルログ、直近デプロイSHA、関連ダッシュボードURL
- 依頼: @claude まず原因候補と再現テスト案を出してください。修正PRは人間の確認後に進めます。この運用の良いところは、Claude Codeの出力がIssueとPRに残ることです。障害対応では、後から「なぜその判断をしたのか」を追えることが重要です。チャットだけで進めると流れてしまう文脈も、Issue、PR、テスト、レビューコメントに分ければ監査しやすくなります。
一方で、GitHub Actions連携にも注意点があります。公式手順ではGitHub Appのインストール、リポジトリ権限、ANTHROPIC_API_KEYなどのSecrets設定が必要です。つまり、導入前にリポジトリ単位の権限と秘密情報の扱いを決めておく必要があります。障害対応は急ぎの場面で使うため、平時に設定と訓練を済ませておくことが大切です。
6. 修正PRのレビュー観点を固定する
Claude Codeが作ったPRをレビューするとき、通常のコードレビューだけでは足りません。障害対応PRには、再現性、影響範囲、ロールバック、監視、顧客影響、再発防止という観点が必要です。レビュー観点を毎回人間が思い出す運用だと、忙しい時間帯に抜けます。
そこで、PRテンプレートにClaude Code向けのチェック項目を入れておきます。Claude Codeには、修正コードだけでなく、このテンプレートを埋めさせます。空欄が残る場合は、その理由を明記させます。AIに「分からないことを分からないと書かせる」設計が、障害対応ではかなり重要です。
このPRの説明文を、以下の障害対応テンプレートで作成してください。
- 何が起きたか
- どのログ・テストで再現したか
- 修正したファイルと理由
- 影響範囲
- ロールバック方法
- 追加した監視・アラート
- 未解決リスク
- 人間レビューで特に見てほしい点
不明な項目は推測で埋めず、「未確認」と書いてください。ここで「未確認」を許容するのがポイントです。AI出力の危険は、もっともらしく空欄を埋めてしまうことです。障害対応では、未確認のまま進めてよい項目と、未確認なら止める項目を分ける必要があります。たとえば、再現テストが未確認なら修正PRはレビュー止まり。顧客影響が未確認なら対外説明は保留。ロールバック方法が未確認ならリリース不可、というようにルール化します。
| レビュー項目 | Claude Codeの支援 | 承認者 |
|---|---|---|
| 再現テスト | 失敗テストと修正後テストの追加 | 担当エンジニア |
| 影響範囲 | 関連コード・テーブル・API利用箇所の候補出し | EM / SRE |
| 監視 | 追加すべきログ、メトリクス、アラート条件の草案 | SRE |
| 顧客影響 | 影響調査に必要な観点整理 | CS / PM / 責任者 |
7. ポストモーテムを更新し、次の障害に備える
障害対応の最後にClaude Codeが効くのは、ポストモーテムとrunbookの更新です。障害が収束した直後は、チームの記憶が一番新しい一方で、疲れていて文書化が後回しになりがちです。ここをClaude Codeに支援させると、次の障害対応の品質が上がります。
ただし、ポストモーテムは責任追及の文書ではありません。何が起きたか、検知が遅れた理由、意思決定が詰まった箇所、次に変える仕組みを残すための文書です。Claude Codeには、PR、Issue、ログ、Slackから転記したメモをもとに草案を作らせ、人間が事実関係と表現を確認します。
今回のIssue、関連PR、runbook差分を読み、ポストモーテム草案を作成してください。
責任追及ではなく、仕組みの改善に焦点を当ててください。
構成は以下です。
1. 概要
2. タイムライン
3. 検知できたこと
4. 検知できなかったこと
5. 暫定対応
6. 恒久対応
7. 再発防止アクション
8. 未確認事項
事実と推測を必ず分けてください。この草案から、次のrunbook更新につなげます。Claude Codeには「今回の障害から、docs/runbooks/に追加すべき手順を3つ提案して」と依頼します。これにより、障害対応が単発の消火で終わらず、ドキュメント、テスト、監視、運用ルールに蓄積されます。
【要注意】よくある失敗パターンと回避策
失敗1：本番操作まで一気に任せる
❌「障害が起きたら原因を調べて直してデプロイして」
⭕「ログ整理、再現テスト、修正PR草案まで。マージとリリースは人間が承認」
なぜ重要か：Claude Codeは強力な開発支援ツールですが、障害対応では誤操作のコストが大きいです。本番操作、顧客連絡、ロールバック判断は、承認フローを分けるべきです。
失敗2：権限設定を個人任せにする
❌「各エンジニアが便利なように許可コマンドを増やす」
⭕「プロジェクト設定または管理設定で、読み取り・テスト・編集範囲を明文化する」
なぜ重要か：障害対応はチーム運用です。人によって許可コマンドが違うと、手順の再現性が落ちます。設定スコープを使い、共有ルールとして管理するほうが安全です。
失敗3：ログ調査と修正を同時に依頼する
❌「このログを見て直して」
⭕「まず観測事実と仮説を分けて。次に再現テスト。最後に修正案」
なぜ重要か：原因が曖昧なまま修正すると、別の不具合を入れるリスクがあります。Claude Codeに段階を分けて依頼すると、人間がレビューしやすくなります。
失敗4：AIの説明をポストモーテムにそのまま貼る
❌「Claude Codeがこう説明したので原因はこれです」
⭕「ログ、差分、テスト、監視データを根拠に、人間が原因を確定する」
なぜ重要か：ポストモーテムは監査と再発防止の資料です。AIの要約は便利ですが、事実関係の最終確認はチームが行う必要があります。
導入ロードマップ：5手順で始める
手順1：直近の障害メモを3件だけ集める
最初から全社展開しないでください。直近の障害メモを3件だけ集め、検知、原因、暫定対応、恒久対応、再発防止の項目に分けます。この時点ではClaude Codeにコード修正させず、文書構造の統一に使います。
手順2：runbookのひな形を作る
docs/runbooks/配下に、API 5xx、DB遅延、外部API障害、認証エラーなどの基本テンプレートを作ります。Claude Codeには、既存コードと過去メモを読み、各テンプレートの確認項目を提案させます。
手順3：読み取り中心の権限で検証する
最初の検証では、git log、git diff、検索、テスト実行などに限定します。外部APIへの書き込み、本番DB接続、Secrets表示、デプロイコマンドは含めません。権限は便利さより事故防止を優先します。
手順4：再現テストからPR作成へ進める
障害対応の修正は、いきなり本番コードを書かせるのではなく、失敗するテストから始めます。再現テスト、最小修正、レビュー観点、ロールバック方法を1つのPRにまとめると、レビューの品質が安定します。
手順5：ポストモーテムをrunbookへ戻す
障害が終わったら、Claude Codeにポストモーテム草案とrunbook更新案を作らせます。人間が確認し、次に同じ障害が起きたときの初動が短くなるように手順を更新します。
実装スタックの例
想定シナリオでのスタックは以下です。実際の導入では、社内規程、監査要件、データ分類、開発フローに合わせて調整してください。
- Claude Code：ターミナルまたはIDEでの調査、テスト作成、PR草案作成
- GitHub Issues：障害チケット、調査ログ、Claude Codeへの依頼窓口
- GitHub Actions：PR上の自動化、CI、Claude Code Actionの検証環境
- docs/runbooks/：障害種別ごとの手順書
- tests/：再現テストと回帰テスト
- 監視基盤：既存のAPM、ログ、メトリクス、アラート。Claude Codeには読み取り用に転記したサンプルだけを扱わせる設計も有効です。
Claude CodeのCLIリファレンスには、セッション開始、パイプ入力、会話再開、権限関連のオプションなどがまとまっています（参照：Claude Code CLI reference、参照日: 2026-05-25）。障害対応の標準運用に入れる前に、チームでよく使うコマンドと禁止するコマンドを洗い出しておくと、導入後の迷いが減ります。
FAQ
Q1. Claude Codeで障害対応を完全自動化できますか？
A. いいえ。Claude Codeはログ整理、再現手順作成、修正案、PR作成を支援できますが、原因判断、顧客影響の確定、リリース承認は人間の責任で行う設計が安全です。
Q2. 最初に任せるべき作業は何ですか？
A. 読み取り中心の作業です。runbookの差分整理、過去インシデントの分類、ログ調査メモの構造化、テスト観点の洗い出しから始めると、権限リスクを抑えられます。
Q3. 本番環境のコマンドを実行させてもよいですか？
A. 原則として推奨しません。本番操作は人間の承認、監査ログ、限定された手順、ロールバック計画を前提にしてください。少なくとも初期導入では、本番操作をClaude Codeの許可範囲に含めないほうが安全です。
Q4. GitHub Actions連携は必要ですか？
A. 必須ではありません。まずはローカルまたはIDEでrunbookと再現テストの支援から始められます。PR運用に乗せたい場合、GitHub Actions連携を検討すると、IssueとPRに履歴を残しやすくなります。
Q5. セキュリティレビューでは何を見ればよいですか？
A. 読み取り範囲、編集可能なディレクトリ、実行可能なコマンド、Secretsの扱い、外部サービス連携、承認者、監査ログを確認してください。Claude Codeの設定スコープと権限設計を、チームの運用ルールに落とし込むことが重要です。
まとめ：今日から始める3つのアクション
- 今日やること：直近3件の障害メモを集め、Claude Codeに「観測事実」「仮説」「未確認事項」「次回runbookへ追加する項目」に分けさせる。
- 今週中：docs/runbooks/にAPI 5xx、外部API障害、DB遅延のテンプレートを作り、読み取り中心の権限で検証する。
- 今月中：再現テスト、修正PR、ポストモーテム、runbook更新までを1回の演習として回し、どこを人間承認にするか明文化する。
Claude Codeは、障害対応を「AIに丸投げする」ための道具ではありません。むしろ、属人化しがちな調査、修正、レビュー、事後対応を、チームで再現できる型にそろえるための道具です。最初は地味に見えますが、runbookとテストが整うほど、次の障害対応は落ち着いて進めやすくなります。
あわせて読みたい：
- CI/CD自動修復をClaude Codeで実装｜5手順 — デプロイ前後の自動チェック設計に近い事例です。
- SaaSのCSヘルススコアをClaude Codeで作る — 障害後の顧客影響整理と接続しやすい事例です。
- 物流WMS連携をClaude Codeで自動化 — 外部システム連携時のデータ整形と通知パイプラインの参考になります。
Claude Codeの業務導入を検討しているチームは、まずは小さな障害対応演習から始めるのがおすすめです。Uravationでは、開発チーム向けのClaude Code導入設計、runbook整備、AIエージェント運用ルールづくりを支援しています。ご相談はお問い合わせフォームからどうぞ。
次回予告：次の記事では、Claude Codeを使った「監査ログレビューと権限棚卸し」の実装パターンを取り上げます。障害対応と同じく、読み取り中心から始めると成果が出やすい領域です。
補足：チーム内で決めておく運用ルール
Claude Codeを障害対応に入れる前に、チーム内で最低限の運用ルールを決めておくと安全です。ここでは、実装よりも運用設計を優先します。AIエージェントは、ルールが曖昧なままでも動けてしまいます。だからこそ、実行できることを増やす前に、実行してよい条件、止める条件、承認者、記録場所を決める必要があります。
まず、障害対応の区分を決めます。たとえば、調査フェーズ、暫定対応フェーズ、恒久対応フェーズ、事後レビューの4つです。調査フェーズでは、Claude Codeは読み取りと整理に限定します。暫定対応フェーズでは、変更案は出してもよいが、本番反映は不可。恒久対応フェーズでは、テスト付きPRの初稿まで。事後レビューでは、ポストモーテムとrunbook更新案の草案まで、というように分けます。
次に、データ分類を決めます。ログには個人情報、顧客識別子、社内ID、課金情報が含まれることがあります。Claude Codeに渡す前に、どの種類のログなら利用できるか、どの情報はマスクするか、どの環境で扱うかを明文化します。特にSaaSでは、テナントIDやメールアドレスの扱いを軽く見ないほうがよいです。
最後に、演習を行います。本番障害が起きてから初めてClaude Codeを使うのではなく、過去の障害を題材に30分の机上演習をします。Claude Codeに調査メモを作らせ、人間がレビューし、runbookを更新する。この流れを一度でも経験しておくと、本番時に「何を頼めばよいか」が見えます。
この補足の目的は、Claude Codeの導入を遅くすることではありません。逆です。最初に安全な枠を作ることで、チームが安心して使える範囲が明確になります。安全な範囲が明確になれば、現場のエンジニアは迷わず使えます。
参考・出典
- Overview – Claude Code Docs — Anthropic（参照日: 2026-05-25）
- Security – Claude Code Docs — Anthropic（参照日: 2026-05-25）
- Claude Code settings – Claude Code Docs — Anthropic（参照日: 2026-05-25）
- Claude Code GitHub Actions – Claude Code Docs — Anthropic（参照日: 2026-05-25）
- CLI reference – Claude Code Docs — Anthropic（参照日: 2026-05-25）
著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。生成AI・AIエージェントの業務導入、開発チーム向け研修、AI活用設計を支援。X（@SuguruKun_ai）で実務向けのAI活用を発信しています。
