Claude Codeでdeploy-checklistをリリース前に回す — engineeringプラグインの使い方
Anthropic配布のengineeringプラグインに入っているdeploy-checklistを導入し、マイグレーション・フィーチャーフラグ・CI・ロールバック条件をデプロイ前に洗い出す手順と、自社の手順に寄せる方法をまとめます。
deploy-checklistは、Anthropicが配布するengineeringプラグインに入ったスキルです。/deploy-checklist auth-service v2.3.0 のようにサービス名とリリース名を渡すと、デプロイ前・デプロイ中・デプロイ後・ロールバック条件の4ブロックからなる確認表を出します。
この記事では、プラグインの入れ方、確認表の中身、マイグレーションやフィーチャーフラグがあるときの頼み方、CIや監視ツールをつなぐと何が変わるかを順に扱います。確認表は「出して終わり」にすると形骸化しやすいので、チームの手順に寄せる方法にも触れます。
deploy-checklistは何を出すスキルか
リポジトリ上のスキル定義には、説明文として「リリース前の検証チェックリスト」と書かれています。使いどころとして挙がっているのは、リリースを出す直前、データベースマイグレーションやフィーチャーフラグを含む変更のデプロイ、本番投入前のCIと承認の確認、ロールバック条件の事前記録です。
引数は [service or release name] で、スキル本文の出力テンプレートは次の構成です。
| ブロック | 含まれる確認項目 |
|---|---|
| Pre-Deploy | 含まれる確認項目CIの全テスト合格 / コードレビューと承認 / 既知の重大バグなし / マイグレーションの検証(該当時) / フィーチャーフラグの設定(該当時) / ロールバック計画の文書化 / オンコールへの通知 |
| Deploy | 含まれる確認項目ステージングでの確認 / スモークテスト / 本番デプロイ(カナリアがあれば利用) / 15分間のエラー率・レイテンシ監視 / 主要なユーザーフローの確認 |
| Post-Deploy | 含まれる確認項目メトリクスが正常範囲か / リリースノート・変更履歴の更新 / 関係者への通知 / 関連チケットのクローズ |
| Rollback Triggers | 含まれる確認項目エラー率が[X]%を超える / P50レイテンシが[X]msを超える / [重要なユーザーフロー]が失敗する |
テンプレートの末尾にある「ロールバック条件」には、数値が [X] のまま置かれています。ここを埋めずに本番へ進むと、障害が起きた最中に「どこまで悪化したら戻すのか」を議論することになります。スキルの「Tips」にも、ロールバックの基準はデプロイの最中ではなく前に決める、という趣旨が書かれています。
公式ページ同士で説明が少し違う
プラグインのREADMEは、deploy-checklistを「テスト、変更内容、依存関係の確認、ロールバック計画の確認」を行うコマンドとして説明しています。一方、スキル定義の出力テンプレートに「依存関係」という項目はありません。READMEの一文は概要であり、実際に出る項目はスキル本文のテンプレートと、渡した文脈で決まると読むのが安全です。依存関係の確認が必要なら、後述のカスタマイズで自分から足します。
engineeringプラグインを入れる
READMEが示すインストールは、マーケットプレイスの登録とプラグインの導入の2行です。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install engineering@knowledge-work-pluginsセッションの中から入れるなら /plugin marketplace add anthropics/knowledge-work-plugins に続けて /plugin install engineering@knowledge-work-plugins です。Claude Codeのドキュメントによれば、セッション内の /plugin install はすぐには入れず、/plugin パネルで詳細を開き、スコープを選んでから確定します。反映には /reload-plugins が必要になることもあります。
このプラグインは、READMEの冒頭で、主にCowork向けに作られ、Claude Codeでも動くと説明されています。同じリポジトリにはほかの職種向けプラグインも並んでいますが、デプロイの確認に使うのは engineering ひとつです。
呼び出し名の注意
READMEの例は /deploy-checklist と書かれています。ただしClaude Codeでは、プラグインのスキルは /プラグイン名:スキル名 の形で呼ばれると説明されています。つまりClaude Codeでは /engineering:deploy-checklist が正式な呼び名になります。補完候補に /deploy-checklist が出ないときは、名前空間付きで入力してください。
常駐コストを確認してから入れる
有効にしたプラグインは、使わないセッションでも、Claudeが自動で呼べるスキルの名前と説明文が毎ターン文脈に載ります。deploy-checklistのスキル定義には、自動呼び出しを止める設定（disable-model-invocation）が書かれていません。つまり「リリースを出す」「マイグレーション付きでデプロイする」といった会話で、Claudeが自分でこのスキルを読み込む可能性があります。
自動で呼ばれたくなければ、プラグインごと無効にするか、権限設定の skillOverrides でユーザー呼び出し専用にする方法があります。入れる前の見積もりは、公式マーケットプレイス掲載のプラグインなら /plugin の詳細画面に「Context cost」として出ます。
実際の回し方
基本形は、サービス名とリリース名を渡すだけです。
/engineering:deploy-checklist auth-service v2.3.0スキルは、渡した内容に合わせて確認表を調整するとされています。定義には3つの例が載っています。
- 「フィーチャーフラグを使っている」と伝えると、フラグの検証手順が加わる
- 「データベースマイグレーションを含む」と伝えると、マイグレーション固有の確認が加わる
- 「APIの破壊的変更である」と伝えると、利用側への通知手順が加わる
実際に何が加わるかは環境と依頼文で変わるので、例えば次のように、変更の性質を最初の依頼にまとめて書きます。以下は依頼文の一例で、返ってくる確認表そのものではありません。
/engineering:deploy-checklist billing-api v4.1.0
- orders テーブルに NOT NULL 列を追加するマイグレーションを含む
- 新しい請求計算ロジックは feature flag で段階公開する
- レスポンスの一部フィールドを廃止する(破壊的変更)この3行は、定義にある3つの例（マイグレーション、フラグ、破壊的変更）をそのまま1回の依頼に重ねた形です。1回の依頼に重ねられるかは定義に明記がないため、反映されない項目があれば、出てきた表を見て「フラグ解除の手順も足して」と追加で頼めば足ります。
マイグレーション、フラグ、CI、ロールバックを事前に確認する
確認表の項目は、それぞれ「誰が・何を見て・合格にするか」が書かれていないと形だけになります。項目ごとに、依頼時に添えておくと表が実用的になる情報を表にしました。
| 項目 | 依頼に添える情報の例 | 合格の根拠にするもの |
|---|---|---|
| マイグレーション | 依頼に添える情報の例変更の種類(列追加・削除・型変更)、テーブルの規模、ロック時間の見込み | 合格の根拠にするものステージングでの適用ログ、戻し用マイグレーションの有無 |
| フィーチャーフラグ | 依頼に添える情報の例フラグ名、初期状態、段階公開の割合、切り戻し手順 | 合格の根拠にするものフラグ管理画面の状態、既定値 |
| CI | 依頼に添える情報の例対象ブランチ、必須ジョブ | 合格の根拠にするものパイプラインの最新実行結果 |
| ロールバック | 依頼に添える情報の例戻す判断者、戻す手段、許容する悪化幅 | 合格の根拠にするもの事前に決めたエラー率とレイテンシの閾値 |
スキルの出力に含まれる「ロールバック条件」の [X] を、サービスごとの実測値に置き換えるのが最も効果の大きい作業です。直近のエラー率やP50レイテンシを知らないまま「X%」を決めることはできません。次の節で触れる監視ツールの接続は、この数字を埋めるためにあります。
コネクタをつなぐと自動化される部分
deploy-checklistは、ツールがつながっていなくても動きます。READMEの表では、デプロイの確認表は単独なら「デプロイ内容を説明する」だけで使え、CI/CDとソース管理をつなぐと強化される、と整理されています。スキル定義が挙げるつながり先ごとの効果は次のとおりです。
| つなぐもの | スキル定義が書く効果 |
|---|---|
| ソース管理 | スキル定義が書く効果リリースの差分と変更一覧を取得し、全PRが承認・マージ済みかを確認する |
| CI/CD | スキル定義が書く効果ビルドとテストの状況を自動で確認し、デプロイ前にパイプラインが通っているかを確かめる |
| 監視 | スキル定義が書く効果現在のベースラインからロールバック条件の閾値を埋め、デプロイ後のメトリクス監視を準備する |
ここで注意したいのは、プラグインが最初から用意している接続先です。engineeringプラグインのコネクタ一覧では、CI/CDの欄の「含まれるサーバー」は空欄で、選択肢としてCircleCI・GitHub Actions・Jenkins・BuildKiteが挙げられているだけです。同梱の .mcp.json に入っているのは、Slack、Linear、Asana、Atlassian、Notion、GitHub、PagerDuty、Datadogなどです。
整理すると、次のようになります。
- ソース管理(GitHub)と監視(Datadog)は、同梱のサーバー設定をそのまま使える
- CI/CDは同梱されていないため、使っているCIのMCPサーバーを自分で追加する必要がある
- GitHub Actionsを使っていてGitHubのMCPサーバーでCIの状況まで読めるかは、プラグインの記載だけでは判断できない
CI/CDが未接続のときは、確認表の「CIの全テスト合格」を自動では埋められません。パイプラインの結果URLや直近の実行結果を依頼文に貼れば、その内容を前提に表を作れます。
自社の手順に寄せる
READMEによれば、プラグインは engineering/.claude/settings.local.json に次のような個人設定を置けます。
{
"name": "Your Name",
"title": "Software Engineer",
"team": "Your Team",
"company": "Your Company",
"techStack": ["Python", "TypeScript", "PostgreSQL", "AWS"],
"defaultBranch": "main",
"deployProcess": "canary"
}deployProcess に canary のようなデプロイ方式を書く欄があり、未設定なら対話で尋ねるとREADMEは説明しています。この設定ファイルをClaude Code側がどう読み込むかは、READMEの設定例以上の記載がありません。反映を期待しすぎず、確認表に出た内容で確かめてください。
プラグインの設定に頼らず確実に伝えるなら、リポジトリの CLAUDE.md に、確認表へ必ず含めたい項目を書いておく方法があります。次のようにまとめます。
## デプロイ前の確認(deploy-checklist に必ず含める)
- マイグレーションは expand → contract の順で分け、同じリリースで列を削除しない
- 本番デプロイは平日 15:00 まで。金曜と祝前日は出さない
- ロールバック条件: エラー率 1% 超が 5 分続く、または P50 が直近7日平均の 2 倍
- 依存パッケージの更新を含む場合は、lockfile の差分を確認項目に追加する上は一例です。時間帯の制限や、閾値の数字は各チームの値に置き換えてください。こうして固有の規則を置くと、スキルのテンプレートに載らない項目（上の例では依存関係の確認）を補えます。スキルは「一度カスタマイズして使い回す」ことを前提にしており、定義の「Tips」にも、スタックを伝えれば覚える、という趣旨があります。
本番を動かす権限とは分けて考える
確認表は、デプロイ自体を実行するスキルではありません。出力は確認項目のチェックリストで、デプロイを走らせる手順はテンプレートに含まれていません。逆に言えば、確認表を出したあとの本番反映を誰が行うかは別に決める必要があります。
Claude Codeに本番反映まで任せる運用にするなら、権限ルールで線を引けます。たとえば git push や特定のデプロイコマンドを確認付きにする、といった書き方です。本番デプロイの権限をどう絞るかはPaaS系MCPの本番デプロイ権限が各社の例で扱っています。AWSで構成の提案から承認付きデプロイまで進める流れは、Claude CodeでDeploy on AWSプラグインを使うの手順が参考になります。
チームでプラグインの利用範囲を絞りたい場合は、strictPluginOnlyCustomizationで、スキルやhooksをプラグイン経由に限定する設定を扱っています。
つまずきやすい点
/deploy-checklistが出ない: Claude Codeでは名前空間付きの/engineering:deploy-checklistで呼びます。インストール直後なら/reload-pluginsも試してください。- 確認表が汎用的すぎる: サービス名だけを渡すと、テンプレートそのままの一般的な表になりがちです。変更の性質(マイグレーション・フラグ・破壊的変更)を最初に書いてください。
- ロールバック条件が
[X]のまま: 数値を埋めるのは利用者側の作業です。監視ツールを接続するか、直近の指標を貼って埋めます。 - CIの合否が自動で入らない: CI/CDのMCPサーバーはプラグインに含まれていません。自分で追加するか、結果を貼り付けます。
まとめ
deploy-checklistは、デプロイ前後の確認項目とロールバック条件を一枚にそろえるためのスキルで、使い方はサービス名とリリース名を渡すだけです。効果が出るかどうかは、渡す文脈の具体さと、[X] を実測値で埋められるかにかかっています。CI/CDだけは同梱されないため、既存のパイプラインを使う場合は接続の手当てが先に要ります。まずは次のリリースで1回出してみて、表に載らなかった自社固有の項目を CLAUDE.md に足していく運用が現実的です。