claude-howto で学ぶ DevOps Automation プラグインデプロイ・監視・インシデントレスポンスを束ねる Claude Code 自動化ガイド【免费下载链接】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本記事は、本リポジトリの 日本語版プラグイン解説ドキュメント を軸に、同梱されているスラッシュコマンド、サブエージェント、スクリプト、フック、MCP 設定の実ファイルを読み解きながら、「開発チームが日常的に使える DevOps 自動化プラグイン」の全体像と内部実装を解説します。読み終えると、/deploy/rollback/status/incidentの 4 コマンドを起点に、デプロイ前検証からポストデプロイの健全性確認までを 1 つのプラグインとして組み立てる仕組みを理解し、自チーム向けに同型のプラグインを自作できるようになります。DevOps Automation プラグインが解決するものdevops-automation は、Claude Code の**プラグインPlugin**という拡張機構で実装された「デプロイ監視インシデントレスポンスの自動化パッケージ」です。Claude Code のプラグインは、スラッシュコマンド・サブエージェント・MCP サーバー・フックという複数の拡張機能を 1 コマンドで導入できる梱包形式で、プラグイン全体の概念整理は 07-plugins/README.md に mermaid の構成図付きでまとめられています。日本語版 README が掲げる機能は次の 5 点です。自動デプロイAutomated deploymentsロールバック手順Rollback proceduresシステム健全性の監視System health monitoringインシデントレスポンスのワークフローIncident response workflowsKubernetes 連携Kubernetes integrationつまり「本番環境へ安全に出す」「壊れたら戻す」「今どの状態かを常に把握する」「障害が起きたら構造的に対応する」という、DevOps 運用の基本サイクル全体を Claude Code の会話インターフェースの中に閉じ込めることが、このプラグインの狙いです。インストールと必要要件インストールプラグインは Claude Code のプラグイン管理 UI から導入します。/plugin install devops-automationインストール後、日本語版ドキュメントの必要要件は次のとおりです。Claude Code 1.0 以上※対応する英語版 README では Claude Code 2.1 と記載されており、プラグイン機構そのものは v2.1 系で拡充されています。どちらを基準にするかは利用中の Claude Code バージョンと照合してくださいKubernetes CLIkubectlクラスタへのアクセス設定導入されたプラグインはスラッシュコマンドサブエージェントスクリプトフックMCP サーバーとして即座に利用できます。なお 07-plugins/README.md によれば、プラグインの構成を変更した場合の再読込は/reload-plugins、開発中の動作確認はclaude --plugin-dir ./path/to/pluginが利用できます。Kubernetes への接続設定日本語版 README の「設定」セクションでは、Kubeconfig の場所を環境変数で明示する方法が示されています。export KUBECONFIG~/.kube/configこの環境変数は後述の Kubernetes MCP サーバー設定にも引き渡されるため、プラグインを動かすセッションでは必ず設定しておきます実装の詳細は「Kubernetes MCP サーバー」セクション参照。同梱コンテンツの全体像devops-automation は 5 種類の拡張要素を束ねています。実際のディレクトリ構成英語版が i18n の原本で、07-plugins/devops-automation/ に配置は以下のとおりです。07-plugins/devops-automation/ ├── README.md # プラグインの説明本記事の題材 ├── agents/ # サブエージェント定義 │ ├── deployment-specialist.md │ ├── incident-commander.md │ └── alert-analyzer.md ├── commands/ # スラッシュコマンド定義 │ ├── deploy.md │ ├── rollback.md │ ├── status.md │ └── incident.md ├── hooks/ # デプロイ前後フック │ ├── pre-deploy.js │ └── post-deploy.js ├── mcp/ │ └── kubernetes-config.json # Kubernetes MCP サーバー設定 └── scripts/ # 実処理スクリプト ├── deploy.sh ├── rollback.sh └── health-check.sh各要素と役割を表にまとめます。カテゴリ同梱物役割スラッシュコマンド/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デプロイ後処理「コマンドユーザーへの入口」「サブエージェント判断・作業の委譲先」「スクリプト実際のシェル処理」「フック自動実行の安全弁」「MCP外部システムの生情報」という役割分担になっています。スラッシュコマンドの使い方と内部定義基本の使い方日本語版 README より# ステージングへデプロイ /deploy staging # 本番へデプロイ /deploy production # ロールバック /rollback production # ステータス確認 /status # インシデント対応 /incident/deployと/rollbackは環境名staging/productionを引数に取り、/statusと/incidentは引数なしで起動します。/deployが実行するワークフローcommands/deploy.md は frontmatter にname: Deploy/description: Deploy application to production or stagingを持ち、本体プロンプトとして次の手順を定義しています。デプロイ前チェックを実行Run pre-deployment checksアプリケーションをビルドBuild applicationテストを実行Run tests対象環境へデプロイDeploy to target environmentヘルスチェックを実行Run health checksSlack でチームに通知Notify team on Slack「ビルド→テスト→適用→確認→通知」という一連の工程を、ユーザーがstagingかproductionを指定するだけで Claude が順番に実行します。/rollbackが実行するワークフローcommands/rollback.md は「直前の安定バージョンへ戻す」ことに特化した手順です。前回のデプロイを特定Identify previous deploymentロールバック先が健全であることを確認Verify rollback target is healthyロールバック手順を実行Execute rollback procedureヘルスチェックを実行Run health checksチームに通知Notify team/rollback productionの実行時は、この 5 ステップが scripts/rollback.sh の実行と組み合わされますスクリプトの詳細は後述。/statusが実行する健全性チェック日本語版 status.md は「全サービスにわたってシステムの健全性を確認する」コマンドで、次の 6 項目を確認します。Kubernetes Pod のステータスを照会データベース接続を確認API のレスポンスタイムを監視エラー率をレビューリソース使用率を確認全体の健全性を報告このうち Pod 数や API の死活確認といった機械的な部分は scripts/health-check.sh が担い、Claude はその結果に統計的な視点レスポンスタイム、エラー率、リソース使用率を加えて解釈する構成です。/incidentが実行するインシデント対応日本語版 incident.md は「構造化されたインシデントレスポンスのワークフロー」を起動します。インシデントレコードを作成重大度と影響範囲を評価オンコールチームへ通知診断情報を収集対応活動を統率解決内容をドキュメント化ポストモーテムを設定障害対応はパニックになりがちですが、「記録→評価→通知→診断→統率→文書化→振り返り」を順序立てて実行するよう設計されており、実際の対応の進行役は後述のincident-commanderサブエージェントが務めます。サブエージェントによる役割分担プラグインには 3 つのサブエージェントが定義されており、いずれも 07-plugins/devops-automation/agents/ 配下の Markdown ファイルが本体です。frontmatter でtoolsを絞り込むことで、不必要な権限を与えず専門作業に集中させています。deployment-specialistデプロイ作業担当日本語版 deployment-specialist.md の定義は次のとおりです。--- name: deployment-specialist description: あらゆるデプロイ作業を担当する tools: Read, Write, Bash, Grep ---得意領域として挙げられているのは以下です。ブルーグリーンデプロイカナリアリリースロールバック手順ヘルスチェックデータベースマイグレーションつまり「単純に kubectl を叩く」のではなく、ゼロダウンタイムのリリース戦略や DB マイグレーションを含む高度なデプロイ判断を任せる役割です。incident-commanderインシデント統括担当日本語版 incident-commander.md はtools: Read, Write, Bash, Grepを持ち、以下を管理します。重大度の評価チーム調整ステータス更新解決状況の追跡ポストモーテムの取りまとめ/incident実行中は、このエージェントが「司令塔」として対応を一元管理します。alert-analyzer健全性解析担当日本語版 alert-analyzer.md はtools: Read, Grep, Bash書き込み権限を持たない読み取り主体のエージェントで、以下を実施します。アラートの相関分析トレンド分析根本原因の特定メトリクスの可視化問題の予兆検知実装の中核シェルスクリプトを読み解くスラッシュコマンドやサブエージェントは「何をするか」を定義する層で、実際の kubectl 操作は scripts/ 配下の Bash スクリプトが実行します。deploy.sh — デプロイ自動化scripts/deploy.sh の全体は次のとおりです。#!/bin/bash set -e echo Starting deployment... # Load environment ENV${1:-staging} echo Target environment: $ENV # Pre-deployment checks echo ✓ Running pre-deployment checks... npm run lint npm test # Build echo Building application... npm run build # Deploy echo Deploying to $ENV... kubectl apply -f k8s/$ENV/ # Health check echo Running health checks... sleep 10 curl -f http://api.$ENV.example.com/health echo ✅ Deployment complete!実装上のポイントは 4 点あります。set -eいずれかのコマンドが失敗した時点で即座に終了し、壊れた状態を放置しない安全設計です。環境引数のデフォルト値第 1 引数$ENVの既定値はstagingです。つまり引数なしで実行しても「まずはステージングに試す」安全な挙動になります。デプロイ対象は環境別マニフェストkubectl apply -f k8s/$ENV/と、環境名に対応したディレクトリの Kubernetes マニフェストを適用します。デプロイ後のヘルスチェックsleep 10の待機後にcurl -f http://api.$ENV.example.com/healthを叩き、-fにより HTTP エラーなら失敗扱いで終了します。実際の環境ではapi.environment.example.com/healthを自前の API エンドポイントに読み替えます。rollback.sh — ロールバック自動化scripts/rollback.sh は、Kubernetes の標準機能であるrolloutを活用します。#!/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を実行します。スクリプトは直前リビジョン番号を取得して表示しますが、実際の巻き戻しはundo直前へ戻るに任せています。kubectl rollout status deployment/app -n $ENVでロールバックが完了するまで待機してからヘルスチェックへ進むため、「戻した後に実は壊れていた」状態を検知できます。/rollback productionを実行した場合、このスクリプトはproductionを$ENVとして受け取ります。health-check.sh — 健全性チェックユーティリティscripts/health-check.sh は、/statusの機械的確認部分を担うユーティリティです。#!/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 21; 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 API はcurl -sfサイレント失敗時エラーによる HTTP 死活確認、データベースは PostgreSQL 標準のpg_isready、Pod はkubectl get podsの結果から Running 数を集計して「3/3 ready」のような形式で出力します。この 3 段階API / DB / Podのチェックが、README のサンプル出力にある Pods: 3/3 readyの土台です。フックデプロイ前後の安全装置フックは「コマンド実行の前後で自動的に走る処理」で、devops-automation ではデプロイの前後を挟む 2 つの Node.js スクリプトが hooks/ に配置されています。pre-deploy.js — デプロイ前検証hooks/pre-deploy.js は、デプロイを始める前に環境前提条件を検証します。実装の要点は次のとおりです。const { execSync } require(child_process); // kubectl がインストールされているか try { execSync(which kubectl, { stdio: pipe }); } catch (error) { console.error(❌ kubectl not found. Please install Kubernetes CLI.); process.exit(1); } // クラスタに接続できているか try { execSync(kubectl cluster-info, { stdio: pipe }); } catch (error) { console.error(❌ Not connected to Kubernetes cluster); process.exit(1); }which kubectlで CLI の有無を、kubectl cluster-infoでクラスタ接続の可否を検証し、どちらかが失敗すればprocess.exit(1)で即座に中断します。「kubectl が無いクラスタに繋がっていない」のにデプロイだけ進んでしまう事故を、実行前に防ぐフェイルファスト構造です。post-deploy.js — デプロイ後処理hooks/post-deploy.js は、デプロイ完了後に「Pod が本当に立ち上がったか」を確認します。// Wait for pods to be ready console.log(Waiting for pods to be ready...); try { execSync(kubectl wait --forconditionready pod -l appmyapp --timeout300s, { stdio: inherit }); } catch (error) { console.error(❌ Pods failed to become ready); process.exit(1); } // Run smoke tests console.log(Running smoke tests...); // Add your smoke test commands herekubectl wait --forconditionready pod -l appmyapp --timeout300sで、ラベルappmyappの Pod が 300 秒以内に Ready 状態になるまで待機します。タイムアウトすると失敗として終了し、続けてスモークテストを実行する余地コメントで拡張ポイントを明示も用意されています。Kubernetes MCP サーバークラスタを会話の中で参照するプラグインは mcp/kubernetes-config.json により、Kubernetes 情報へアクセスするための MCP サーバーを定義しています。{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }npxでmodelcontextprotocol/server-kubernetesを起動し、その環境変数として${KUBECONFIG}前述のexport KUBECONFIG~/.kube/configで設定した値を渡しています。この MCP サーバーにより、Claude はデプロイ進捗の監視や Pod 状態の取得を「シェルを叩く」だけでなく、MCP ツール経由で構造化された情報として参照できます。日本語版 README のワークフローにある「Kubernetes MCP 経由でデプロイ進捗を監視」という記述は、まさにこの設定ファイルが実行主体です。エンドツーエンドのワークフロー例日本語版 README の「ワークフロー例」セクションでは、/deploy productionを実行した際の一連の流れが示されています。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この 6 ステップを、ここまで解説した実ファイルと対応づけると次のようになります。ステップ内容対応する実装1デプロイ前フック実行kubectl とクラスタ接続の検証hooks/pre-deploy.js のwhich kubectl/kubectl cluster-info2deployment-specialist サブエージェントへ作業委譲agents/deployment-specialist.md3deploy.sh スクリプト実行scripts/deploy.sh の lint → test → build →kubectl apply4Kubernetes MCP 経由でデプロイ進捗を監視mcp/kubernetes-config.json のserver-kubernetes5デプロイ後フック実行Pod 待機とスモークテストhooks/post-deploy.js のkubectl wait6デプロイ結果のサマリー提示上記の実行結果を集約つまり、ユーザーが/deploy productionと 1 行打つだけで、①事前検証 → ②専門エージェントへの委譲 → ③実スクリプトの実行 → ④MCP によるリアルタイム監視 → ⑤事後検証 → ⑥結果報告、という安全なパイプラインが動作します。サンプル結果のPods: 3/3 readyは scripts/health-check.sh が集計する形式と同じ表現です。プラグイン運用の要点まとめ最後に、このプラグインを実際に運用・拡張する際の要点を整理します。入口と実行を分離するユーザーが触るのは/deploy/rollback/status/incidentの 4 コマンドだけ。判断はサブエージェント、機械的な処理は Bash / Node スクリプトという階層が、プラグインを読みやすく保守しやすくしています。安全弁をフックで挟むデプロイの「前」に環境前提を検証し、「後」に Pod Ready とスモークテストを挟むことで、失敗を早く検知できます。環境変数で接続先を一元管理KUBECONFIGを設定すれば、フック・スクリプト・MCP のすべてが同じクラスタを参照します。プラグインを導入するセッションでは最初にexport KUBECONFIG~/.kube/configを実行してください。自チーム向けに流用する本プラグインの構成commands/agents/scripts/hooks/mcp/は、devops-automation 固有のものではありません。07-plugins/README.md の「DevOps Plugin」の例でも同型のディレクトリ構成が示されており、デプロイ対象やヘルスチェック先のエンドポイントを自社環境に置き換えるだけで、同じ設計パターンを再利用できます。本記事の題材となった日本語版ドキュメントのフッターには、「最終更新 2026-04-24、Claude Code バージョン 2.1.119、対応モデル Claude Sonnet 4.6 / Claude Opus 4.7 / Claude Haiku 4.5」と記載されています。英語版と併せて 日本語版プラグイン README と 英語版プラグイン README を読み比べると、同型プラグインのローカライズ運用i18n 付きの翻訳バージョンを別ディレクトリに保持する方式も併せて学べます。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/9 13:28:06 · 阅读 1.2k claude-howto で学ぶ DevOps Automation プラグイン：デプロイ・監視・インシデントレスポンスを束ねる Claude Code 自動化ガイド
claude-howto で学ぶ DevOps Automation プラグインデプロイ・監視・インシデントレスポンスを束ねる Claude Code 自動化ガイド【免费下载链接】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本記事は、本リポジトリの 日本語版プラグイン解説ドキュメント を軸に、同梱されているスラッシュコマンド、サブエージェント、スクリプト、フック、MCP 設定の実ファイルを読み解きながら、「開発チームが日常的に使える DevOps 自動化プラグイン」の全体像と内部実装を解説します。読み終えると、/deploy/rollback/status/incidentの 4 コマンドを起点に、デプロイ前検証からポストデプロイの健全性確認までを 1 つのプラグインとして組み立てる仕組みを理解し、自チーム向けに同型のプラグインを自作できるようになります。DevOps Automation プラグインが解決するものdevops-automation は、Claude Code の**プラグインPlugin**という拡張機構で実装された「デプロイ監視インシデントレスポンスの自動化パッケージ」です。Claude Code のプラグインは、スラッシュコマンド・サブエージェント・MCP サーバー・フックという複数の拡張機能を 1 コマンドで導入できる梱包形式で、プラグイン全体の概念整理は 07-plugins/README.md に mermaid の構成図付きでまとめられています。日本語版 README が掲げる機能は次の 5 点です。自動デプロイAutomated deploymentsロールバック手順Rollback proceduresシステム健全性の監視System health monitoringインシデントレスポンスのワークフローIncident response workflowsKubernetes 連携Kubernetes integrationつまり「本番環境へ安全に出す」「壊れたら戻す」「今どの状態かを常に把握する」「障害が起きたら構造的に対応する」という、DevOps 運用の基本サイクル全体を Claude Code の会話インターフェースの中に閉じ込めることが、このプラグインの狙いです。インストールと必要要件インストールプラグインは Claude Code のプラグイン管理 UI から導入します。/plugin install devops-automationインストール後、日本語版ドキュメントの必要要件は次のとおりです。Claude Code 1.0 以上※対応する英語版 README では Claude Code 2.1 と記載されており、プラグイン機構そのものは v2.1 系で拡充されています。どちらを基準にするかは利用中の Claude Code バージョンと照合してくださいKubernetes CLIkubectlクラスタへのアクセス設定導入されたプラグインはスラッシュコマンドサブエージェントスクリプトフックMCP サーバーとして即座に利用できます。なお 07-plugins/README.md によれば、プラグインの構成を変更した場合の再読込は/reload-plugins、開発中の動作確認はclaude --plugin-dir ./path/to/pluginが利用できます。Kubernetes への接続設定日本語版 README の「設定」セクションでは、Kubeconfig の場所を環境変数で明示する方法が示されています。export KUBECONFIG~/.kube/configこの環境変数は後述の Kubernetes MCP サーバー設定にも引き渡されるため、プラグインを動かすセッションでは必ず設定しておきます実装の詳細は「Kubernetes MCP サーバー」セクション参照。同梱コンテンツの全体像devops-automation は 5 種類の拡張要素を束ねています。実際のディレクトリ構成英語版が i18n の原本で、07-plugins/devops-automation/ に配置は以下のとおりです。07-plugins/devops-automation/ ├── README.md # プラグインの説明本記事の題材 ├── agents/ # サブエージェント定義 │ ├── deployment-specialist.md │ ├── incident-commander.md │ └── alert-analyzer.md ├── commands/ # スラッシュコマンド定義 │ ├── deploy.md │ ├── rollback.md │ ├── status.md │ └── incident.md ├── hooks/ # デプロイ前後フック │ ├── pre-deploy.js │ └── post-deploy.js ├── mcp/ │ └── kubernetes-config.json # Kubernetes MCP サーバー設定 └── scripts/ # 実処理スクリプト ├── deploy.sh ├── rollback.sh └── health-check.sh各要素と役割を表にまとめます。カテゴリ同梱物役割スラッシュコマンド/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デプロイ後処理「コマンドユーザーへの入口」「サブエージェント判断・作業の委譲先」「スクリプト実際のシェル処理」「フック自動実行の安全弁」「MCP外部システムの生情報」という役割分担になっています。スラッシュコマンドの使い方と内部定義基本の使い方日本語版 README より# ステージングへデプロイ /deploy staging # 本番へデプロイ /deploy production # ロールバック /rollback production # ステータス確認 /status # インシデント対応 /incident/deployと/rollbackは環境名staging/productionを引数に取り、/statusと/incidentは引数なしで起動します。/deployが実行するワークフローcommands/deploy.md は frontmatter にname: Deploy/description: Deploy application to production or stagingを持ち、本体プロンプトとして次の手順を定義しています。デプロイ前チェックを実行Run pre-deployment checksアプリケーションをビルドBuild applicationテストを実行Run tests対象環境へデプロイDeploy to target environmentヘルスチェックを実行Run health checksSlack でチームに通知Notify team on Slack「ビルド→テスト→適用→確認→通知」という一連の工程を、ユーザーがstagingかproductionを指定するだけで Claude が順番に実行します。/rollbackが実行するワークフローcommands/rollback.md は「直前の安定バージョンへ戻す」ことに特化した手順です。前回のデプロイを特定Identify previous deploymentロールバック先が健全であることを確認Verify rollback target is healthyロールバック手順を実行Execute rollback procedureヘルスチェックを実行Run health checksチームに通知Notify team/rollback productionの実行時は、この 5 ステップが scripts/rollback.sh の実行と組み合わされますスクリプトの詳細は後述。/statusが実行する健全性チェック日本語版 status.md は「全サービスにわたってシステムの健全性を確認する」コマンドで、次の 6 項目を確認します。Kubernetes Pod のステータスを照会データベース接続を確認API のレスポンスタイムを監視エラー率をレビューリソース使用率を確認全体の健全性を報告このうち Pod 数や API の死活確認といった機械的な部分は scripts/health-check.sh が担い、Claude はその結果に統計的な視点レスポンスタイム、エラー率、リソース使用率を加えて解釈する構成です。/incidentが実行するインシデント対応日本語版 incident.md は「構造化されたインシデントレスポンスのワークフロー」を起動します。インシデントレコードを作成重大度と影響範囲を評価オンコールチームへ通知診断情報を収集対応活動を統率解決内容をドキュメント化ポストモーテムを設定障害対応はパニックになりがちですが、「記録→評価→通知→診断→統率→文書化→振り返り」を順序立てて実行するよう設計されており、実際の対応の進行役は後述のincident-commanderサブエージェントが務めます。サブエージェントによる役割分担プラグインには 3 つのサブエージェントが定義されており、いずれも 07-plugins/devops-automation/agents/ 配下の Markdown ファイルが本体です。frontmatter でtoolsを絞り込むことで、不必要な権限を与えず専門作業に集中させています。deployment-specialistデプロイ作業担当日本語版 deployment-specialist.md の定義は次のとおりです。--- name: deployment-specialist description: あらゆるデプロイ作業を担当する tools: Read, Write, Bash, Grep ---得意領域として挙げられているのは以下です。ブルーグリーンデプロイカナリアリリースロールバック手順ヘルスチェックデータベースマイグレーションつまり「単純に kubectl を叩く」のではなく、ゼロダウンタイムのリリース戦略や DB マイグレーションを含む高度なデプロイ判断を任せる役割です。incident-commanderインシデント統括担当日本語版 incident-commander.md はtools: Read, Write, Bash, Grepを持ち、以下を管理します。重大度の評価チーム調整ステータス更新解決状況の追跡ポストモーテムの取りまとめ/incident実行中は、このエージェントが「司令塔」として対応を一元管理します。alert-analyzer健全性解析担当日本語版 alert-analyzer.md はtools: Read, Grep, Bash書き込み権限を持たない読み取り主体のエージェントで、以下を実施します。アラートの相関分析トレンド分析根本原因の特定メトリクスの可視化問題の予兆検知実装の中核シェルスクリプトを読み解くスラッシュコマンドやサブエージェントは「何をするか」を定義する層で、実際の kubectl 操作は scripts/ 配下の Bash スクリプトが実行します。deploy.sh — デプロイ自動化scripts/deploy.sh の全体は次のとおりです。#!/bin/bash set -e echo Starting deployment... # Load environment ENV${1:-staging} echo Target environment: $ENV # Pre-deployment checks echo ✓ Running pre-deployment checks... npm run lint npm test # Build echo Building application... npm run build # Deploy echo Deploying to $ENV... kubectl apply -f k8s/$ENV/ # Health check echo Running health checks... sleep 10 curl -f http://api.$ENV.example.com/health echo ✅ Deployment complete!実装上のポイントは 4 点あります。set -eいずれかのコマンドが失敗した時点で即座に終了し、壊れた状態を放置しない安全設計です。環境引数のデフォルト値第 1 引数$ENVの既定値はstagingです。つまり引数なしで実行しても「まずはステージングに試す」安全な挙動になります。デプロイ対象は環境別マニフェストkubectl apply -f k8s/$ENV/と、環境名に対応したディレクトリの Kubernetes マニフェストを適用します。デプロイ後のヘルスチェックsleep 10の待機後にcurl -f http://api.$ENV.example.com/healthを叩き、-fにより HTTP エラーなら失敗扱いで終了します。実際の環境ではapi.environment.example.com/healthを自前の API エンドポイントに読み替えます。rollback.sh — ロールバック自動化scripts/rollback.sh は、Kubernetes の標準機能であるrolloutを活用します。#!/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を実行します。スクリプトは直前リビジョン番号を取得して表示しますが、実際の巻き戻しはundo直前へ戻るに任せています。kubectl rollout status deployment/app -n $ENVでロールバックが完了するまで待機してからヘルスチェックへ進むため、「戻した後に実は壊れていた」状態を検知できます。/rollback productionを実行した場合、このスクリプトはproductionを$ENVとして受け取ります。health-check.sh — 健全性チェックユーティリティscripts/health-check.sh は、/statusの機械的確認部分を担うユーティリティです。#!/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 21; 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 API はcurl -sfサイレント失敗時エラーによる HTTP 死活確認、データベースは PostgreSQL 標準のpg_isready、Pod はkubectl get podsの結果から Running 数を集計して「3/3 ready」のような形式で出力します。この 3 段階API / DB / Podのチェックが、README のサンプル出力にある Pods: 3/3 readyの土台です。フックデプロイ前後の安全装置フックは「コマンド実行の前後で自動的に走る処理」で、devops-automation ではデプロイの前後を挟む 2 つの Node.js スクリプトが hooks/ に配置されています。pre-deploy.js — デプロイ前検証hooks/pre-deploy.js は、デプロイを始める前に環境前提条件を検証します。実装の要点は次のとおりです。const { execSync } require(child_process); // kubectl がインストールされているか try { execSync(which kubectl, { stdio: pipe }); } catch (error) { console.error(❌ kubectl not found. Please install Kubernetes CLI.); process.exit(1); } // クラスタに接続できているか try { execSync(kubectl cluster-info, { stdio: pipe }); } catch (error) { console.error(❌ Not connected to Kubernetes cluster); process.exit(1); }which kubectlで CLI の有無を、kubectl cluster-infoでクラスタ接続の可否を検証し、どちらかが失敗すればprocess.exit(1)で即座に中断します。「kubectl が無いクラスタに繋がっていない」のにデプロイだけ進んでしまう事故を、実行前に防ぐフェイルファスト構造です。post-deploy.js — デプロイ後処理hooks/post-deploy.js は、デプロイ完了後に「Pod が本当に立ち上がったか」を確認します。// Wait for pods to be ready console.log(Waiting for pods to be ready...); try { execSync(kubectl wait --forconditionready pod -l appmyapp --timeout300s, { stdio: inherit }); } catch (error) { console.error(❌ Pods failed to become ready); process.exit(1); } // Run smoke tests console.log(Running smoke tests...); // Add your smoke test commands herekubectl wait --forconditionready pod -l appmyapp --timeout300sで、ラベルappmyappの Pod が 300 秒以内に Ready 状態になるまで待機します。タイムアウトすると失敗として終了し、続けてスモークテストを実行する余地コメントで拡張ポイントを明示も用意されています。Kubernetes MCP サーバークラスタを会話の中で参照するプラグインは mcp/kubernetes-config.json により、Kubernetes 情報へアクセスするための MCP サーバーを定義しています。{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }npxでmodelcontextprotocol/server-kubernetesを起動し、その環境変数として${KUBECONFIG}前述のexport KUBECONFIG~/.kube/configで設定した値を渡しています。この MCP サーバーにより、Claude はデプロイ進捗の監視や Pod 状態の取得を「シェルを叩く」だけでなく、MCP ツール経由で構造化された情報として参照できます。日本語版 README のワークフローにある「Kubernetes MCP 経由でデプロイ進捗を監視」という記述は、まさにこの設定ファイルが実行主体です。エンドツーエンドのワークフロー例日本語版 README の「ワークフロー例」セクションでは、/deploy productionを実行した際の一連の流れが示されています。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この 6 ステップを、ここまで解説した実ファイルと対応づけると次のようになります。ステップ内容対応する実装1デプロイ前フック実行kubectl とクラスタ接続の検証hooks/pre-deploy.js のwhich kubectl/kubectl cluster-info2deployment-specialist サブエージェントへ作業委譲agents/deployment-specialist.md3deploy.sh スクリプト実行scripts/deploy.sh の lint → test → build →kubectl apply4Kubernetes MCP 経由でデプロイ進捗を監視mcp/kubernetes-config.json のserver-kubernetes5デプロイ後フック実行Pod 待機とスモークテストhooks/post-deploy.js のkubectl wait6デプロイ結果のサマリー提示上記の実行結果を集約つまり、ユーザーが/deploy productionと 1 行打つだけで、①事前検証 → ②専門エージェントへの委譲 → ③実スクリプトの実行 → ④MCP によるリアルタイム監視 → ⑤事後検証 → ⑥結果報告、という安全なパイプラインが動作します。サンプル結果のPods: 3/3 readyは scripts/health-check.sh が集計する形式と同じ表現です。プラグイン運用の要点まとめ最後に、このプラグインを実際に運用・拡張する際の要点を整理します。入口と実行を分離するユーザーが触るのは/deploy/rollback/status/incidentの 4 コマンドだけ。判断はサブエージェント、機械的な処理は Bash / Node スクリプトという階層が、プラグインを読みやすく保守しやすくしています。安全弁をフックで挟むデプロイの「前」に環境前提を検証し、「後」に Pod Ready とスモークテストを挟むことで、失敗を早く検知できます。環境変数で接続先を一元管理KUBECONFIGを設定すれば、フック・スクリプト・MCP のすべてが同じクラスタを参照します。プラグインを導入するセッションでは最初にexport KUBECONFIG~/.kube/configを実行してください。自チーム向けに流用する本プラグインの構成commands/agents/scripts/hooks/mcp/は、devops-automation 固有のものではありません。07-plugins/README.md の「DevOps Plugin」の例でも同型のディレクトリ構成が示されており、デプロイ対象やヘルスチェック先のエンドポイントを自社環境に置き換えるだけで、同じ設計パターンを再利用できます。本記事の題材となった日本語版ドキュメントのフッターには、「最終更新 2026-04-24、Claude Code バージョン 2.1.119、対応モデル Claude Sonnet 4.6 / Claude Opus 4.7 / Claude Haiku 4.5」と記載されています。英語版と併せて 日本語版プラグイン README と 英語版プラグイン README を読み比べると、同型プラグインのローカライズ運用i18n 付きの翻訳バージョンを別ディレクトリに保持する方式も併せて学べます。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考