Claude Code インシデントレスポンス入門：devops-automation プラグインの `/incident` コマンドで本番障害を構造化対応する

Claude Code インシデントレスポンス入門：devops-automation プラグインの/incidentコマンドで本番障害を構造化対応する

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto

本稿では、Claude Code の公式プラグインdevops-automationに含まれる/incidentスラッシュコマンドについて解説します。本番環境でインシデントが発生した際、記録作成から重大度評価、チーム通知、診断情報の収集、対応統率、解決のドキュメント化、ポストモーテム設定までを、Claude が構造化された7ステップのワークフローとして遂行する仕組みを、実際のプラグイン構成（サブエージェント、スクリプト、フック、MCP）と合わせて詳しく紹介します。

1./incidentコマンドとは

devops-automation は、デプロイ、モニタリング、インシデントレスポンスをカバーする DevOps 自動化プラグインです。その中で/incidentは「本番インシデントを構造化された手順で処理する」ための専用コマンドです。

/incidentを実行すると、Claude は以下の7ステップのワークフローを順に実行します：

1. インシデントレコードを作成（インシデント記録の作成）
2. 重大度と影響範囲を評価（重大度・影響範囲の評価）
3. オンコールチームへ通知（オンコールチームへの通知）
4. 診断情報を収集（診断情報の収集）
5. 対応活動を統率（対応活動の統率）
6. 解決内容をドキュメント化（解決内容のドキュメント化）
7. ポストモーテムを設定（ポストモーテムの設定）

つまり、/incidentは単なる「障害を知らせる」コマンドではなく、障害のライフサイクル全体を構造化して扱うための入り口です。現場で慌ててアドホックに対応するのではなく、再現性のある手順で対応を進めることを目的としています。

2. インストールと前提条件

プラグインを利用するには、まず Claude Code（2.1 以上）と Kubernetes 環境が必要です。README のインストール手順は次のとおりです：

/plugin install devops-automation

Kubernetes クラスタへの接続設定も必須です：

export KUBECONFIG=~/.kube/config

このKUBECONFIGは、プラグイン付属の kubernetes-config.json で Kubernetes MCP サーバーに渡される環境変数としても利用されます：

{ "mcpServers": { "kubernetes": { "command": "npx", "args": ["@modelcontextprotocol/server-kubernetes"], "env": { "KUBECONFIG": "${KUBECONFIG}" } } } }

この MCP サーバーを介して、Claude はクラスタ内の Pod 状態やデプロイメントの状況をリアルタイムに参照できます。

プラグインに含まれる関連コンポーネント

/incidentは単独で動くわけではなく、以下のコンポーネントと連携します：

• スラッシュコマンド:/deploy,/rollback,/status,/incident
• サブエージェント:deployment-specialist,incident-commander,alert-analyzer
• MCP サーバー: Kubernetes 統合
• スクリプト:deploy.sh,rollback.sh,health-check.sh
• フック:pre-deploy.js,post-deploy.js

3. 7ステップのワークフローを詳解

ステップ1：インシデントレコードを作成

インシデント対応の第一歩は、発生事象を記録として残すことです。Claude がインシデントの起点となる情報（発生時刻、影響サービス、報告者など）を収集し、レコードとして体系化します。

ステップ2：重大度と影響範囲を評価

収集した情報をもとに、重大度（例：SEV1〜SEV3）と影響範囲（例：一部ユーザー／全ユーザー、特定リージョン／グローバル）を評価します。この評価は、後続の通知先や対応優先度を決める基準になります。

この評価作業の中核を担うのが、サブエージェント incident-commander です。このエージェントは以下を責務としています：

• 重大度評価（Severity assessment）
• チームの統率（Team coordination）
• ステータス更新（Status updates）
• 解決状況の追跡（Resolution tracking）
• ポストモーテムの進行（Post-mortem facilitation）

ステップ3：オンコールチームへ通知

評価結果に基づき、オンコール担当者やチームに通知を行います。通知は Slack などのチャネル経由で行われます（同一プラグインの/deployコマンドも最終ステップで「Slack でチームに通知」する構成になっており、通知をワークフローの一部として組み込む設計思想が共通しています）。

ステップ4：診断情報を収集

障害の原因を特定するため、システムの診断情報を収集します。ここで役立つのが、もう一つのサブエージェント alert-analyzer です：

• アラートの相関分析（Alert correlation）
• トレンド分析（Trend analysis）
• 根本原因の特定（Root cause identification）
• メトリクス可視化（Metric visualization）
• 問題の先取り検出（Proactive issue detection）

また、プラグイン付属の health-check.sh は、API・データベース・Kubernetes Pod の3系統を一括でチェックできる診断スクリプトです：

#!/bin/bash echo "🏥 System Health Check" echo "====================" ENV=${1:-production} # Check API echo -n "API: " if curl -sf http://api.$ENV.example.com/health > /dev/null; then echo "✅ Healthy" else echo "❌ Unhealthy" fi # Check Database echo -n "Database: " if pg_isready -h db.$ENV.example.com > /dev/null 2>&1; then echo "✅ Healthy" else echo "❌ Unhealthy" fi # Check Pods echo -n "Kubernetes Pods: " PODS_READY=$(kubectl get pods -n $ENV --no-headers | grep "Running" | wc -l) PODS_TOTAL=$(kubectl get pods -n $ENV --no-headers | wc -l) echo "$PODS_READY/$PODS_TOTAL ready" echo "===================="

実行例：

./health-check.sh production # 出力例： # 🏥 System Health Check # ==================== # API: ✅ Healthy # Database: ✅ Healthy # Kubernetes Pods: 3/3 ready # ====================

デフォルト環境はproductionで、第1引数で切り替えられます。curl -fやpg_isreadyの終了コードで健全性を判定している点がポイントです。

ステップ5：対応活動を統率

診断結果に基づき、実際の復旧作業（ロールバック、再デプロイ、スケール変更など）を統率します。ここでincident-commanderが中心となって対応をコーディネートし、必要に応じて同一プラグインの/rollbackや/deployコマンドと連携します。

たとえば、デプロイ起因の障害であれば rollback.sh を使って前回の安定版へ切り戻す流れになります：

#!/bin/bash set -e echo "⏪ Starting rollback..." ENV=${1:-staging} echo "📦 Target environment: $ENV" # Get previous deployment PREVIOUS=$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk '{print $1}') echo "🔄 Rolling back to revision: $PREVIOUS" # Execute rollback kubectl rollout undo deployment/app -n $ENV # Wait for rollback echo "⏳ Waiting for rollback to complete..." kubectl rollout status deployment/app -n $ENV # Health check echo "🏥 Running health checks..." sleep 5 curl -f http://api.$ENV.example.com/health echo "✅ Rollback complete!"

kubectl rollout historyで直前のリビジョンを特定し、kubectl rollout undoで復元、rollout statusで完了を待ち、最後にヘルスチェックまで実行する、という一貫した流れになっています。

ステップ6：解決内容をドキュメント化

復旧後、発生した事象・原因・対応内容をドキュメントとして残します。これは再発防止のための重要な資産であり、incident-commanderの「Resolution tracking」責務とも対応しています。

ステップ7：ポストモーテムを設定

最後に、チームメンバーが集まって振り返る**ポストモーテム（事後検証）**のセッションを設定します。incident-commanderの「Post-mortem facilitation」がここに対応し、根本原因の再検証と再発防止策の策定を行います。

4. 実行フローの全体像

プラグインの README にある例（/deployの場合）から、コマンド実行時の Claude の動き方は以下のように想定できます：

User: /deploy production Claude: 1. Runs pre-deploy hook (validates kubectl, cluster connection) 2. Delegates to deployment-specialist subagent 3. Runs deploy.sh script 4. Monitors deployment progress via Kubernetes MCP 5. Runs post-deploy hook (waits for pods, smoke tests) 6. Provides deployment summary Result: ✅ Deployment complete 📦 Version: v2.1.0 🚀 Pods: 3/3 ready ⏱️ Time: 2m 34s

/incidentも同様のパターンで動きます。フックやスクリプトの実行、サブエージェントへの委譲、MCP によるクラスタ監視を組み合わせて進行します。

5. まとめ

/incidentコマンドは、本番インシデント対応を「記録 → 評価 → 通知 → 診断 → 統率 → 文書化 → ポストモーテム」という構造化されたワークフローで進めるための入口です。バックエンドでは：

• incident-commander（統率とポストモーテム）
• alert-analyzer（診断情報の分析）
• health-check.sh（API・DB・Pod のヘルスチェック）
• kubernetes-config.json（Kubernetes MCP 接続）

といったコンポーネントが連携し、アドホックな対応ではなく再現性のあるインシデントレスポンスを実現します。

なお、このプラグインは Claude Code 2.1 以上が必要で、kubectlのインストールとクラスタアクセスの設定が前提です。環境が整っていれば、/incidentと入力するだけで、Claude が障害対応の進行役となってくれます。

【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto