deployment-engineer

deployment-engineer スキルの概要

deployment-engineer が実際にしてくれること

deployment-engineer は、CI/CD とリリース計画に特化した支援スキルです。ゼロから曖昧に指示するよりも、実用的なデプロイワークフローを短時間で形にしたいチームに向いています。単に「パイプラインを書く」だけではなく、デプロイ作業を予測しやすい段階に分け、環境ごとのロールアウト手順、検証チェック、ロールバックの考え方、最低限のオブザーバビリティ要件まで含めて整理してくれるのが本質です。

このスキルを導入すべき人

この deployment-engineer スキルは、次のような用途で支援が必要な開発者、プラットフォームエンジニア、DevOps 担当、AI エージェント利用者に適しています。

• 最初のデプロイパイプラインを立ち上げたい
• 環境ごとのリリース手順を標準化したい
• 実装前にデプロイ計画を作りたい
• CI/CD 設定とあわせてデプロイ手順書や運用ドキュメントも整えたい

特に、ステージの順番、ロールアウト時の安全性、デプロイ後の確認項目を手探りにせず、エージェントにそのまま使える叩き台を作らせたい場合に有効です。

向いているジョブ例

次のような目的なら deployment-engineer を使う価値があります。

• 「build・test・deploy を行う GitHub Actions を整備したい」
• 「staging と production 向けのデプロイ計画を作りたい」
• 「ロールバック手順と検証ステップを入れたい」
• 「Kubernetes デプロイの基本形と監視チェックを用意したい」
• 「運用 runbook に必要な章立てが揃っているか確認したい」

汎用プロンプトとの違い

deployment-engineer の強みは、何より構成の良さにあります。リポジトリには以下が含まれています。

• SKILL.md に段階的な CI/CD パターン
• README.md にデプロイ戦略の前提や考え方
• パイプライン、Kubernetes、監視に関する実用的な参照ドキュメント
• デプロイ計画を生成・検証する補助スクリプト

そのため、単発の YAML をなんとなく出させる「CI/CD 書いて」という依頼よりも、繰り返し使えるデプロイ成果物を作りたい場面で deployment-engineer のほうが役立ちます。

これだけでは解決しきれないこと

これは、特定プラットフォーム向けにそのまま使える完成済みデプロイ基盤ではありません。すべてのクラウド、secret manager、artifact registry、ロールバック機構に深く対応したベンダー固有ロジックが入っているわけではないため、特に次の点は自分たちのスタックに合わせて調整が必要です。

• クラウド認証
• 環境ごとのシークレット管理
• マイグレーションの実行順序
• トラフィック切り替え
• インフラプロビジョニングの詳細

deployment-engineer スキルの使い方

deployment-engineer のインストール方法

agent-playbook コレクションからインストールします。

npx skills add https://github.com/zhaono1/agent-playbook --skill deployment-engineer

エージェント環境がリポジトリからのスキル探索に対応している場合は、スキルフォルダをそのまま保持してください。隣接する参照資料やスクリプトも一緒に読める状態にしておくと、deployment-engineer をより活かせます。

最初に読むべきファイル

最短で全体像をつかみたいなら、次の順番で読むのがおすすめです。

1. skills/deployment-engineer/SKILL.md
2. skills/deployment-engineer/README.md
3. skills/deployment-engineer/references/pipelines.md
4. skills/deployment-engineer/references/monitoring.md
5. skills/deployment-engineer/references/kubernetes.md
6. skills/deployment-engineer/scripts/generate_deploy.py
7. skills/deployment-engineer/scripts/validate_deploy.py

この順番なら、まずスキルの適用範囲を把握し、その次にデプロイの基本パターン、最後に補助テンプレートやスクリプトまで自然に追えます。

このスキルに渡すべき入力

deployment-engineer は、「CI/CD を作って」のような抽象的な依頼だけだと力を発揮しきれません。運用上の制約や前提を具体的に渡すほど、出力品質が上がります。特に有効なのは以下です。

• リポジトリの種類と言語
• build command と test command
• デプロイ先: VM、Kubernetes、serverless、container platform
• 環境: dev、staging、production
• ブランチ戦略
• artifact の出力形式と registry
• secret の扱い方
• health checks と smoke tests
• rollback に求める条件
• migration 要件
• 稼働率や変更可能時間帯の制約

これらがないと、エージェントは汎用的なパイプラインの骨組みしか出せないことが多いです。

曖昧な要望を強いプロンプトに変える

弱いプロンプト:

Set up deployment.

より良いプロンプト:

Use the deployment-engineer skill to create a GitHub Actions CI/CD pipeline for a Node.js service.
Context:
- Branches: develop -> staging, main -> production
- Commands: npm ci, npm test, npm run build
- Artifact: Docker image pushed to GHCR
- Runtime: Kubernetes
- Need stages for lint, test, build, security, deploy-staging, deploy-production
- Require smoke tests, rollback steps, and monitoring checks
- Include environment-specific secrets placeholders
- Output:
  1. workflow YAML
  2. deployment plan markdown
  3. list of required repo secrets
  4. assumptions and risks

後者が機能しやすいのは、対象プラットフォーム、環境ごとの流れ、期待する成果物が最初から明示されているためです。

deployment-engineer の典型的な進め方

実務では、次の流れで使うと扱いやすいです。

1. まず deployment-engineer にデプロイ方針と前提条件を草案化させる
2. その内容をもとに pipeline YAML や deployment plan ドキュメントを生成させる
3. 出力を実際のリポジトリ構成やデプロイ先と照合する
4. 組織固有の認証、secrets、ロールアウトルールを追加する
5. deployment plan の構成を検証する
6. 先に staging で詰めてから production に広げる

このように段階を踏むと、見た目は整っているのに本番では使えない YAML をいきなり生成してしまうリスクを減らせます。

runbook が必要なら補助スクリプトを活用する

このリポジトリには、見た目以上に実用性の高い 2 つのスクリプトが含まれています。

デプロイ計画テンプレートを生成:

python skills/deployment-engineer/scripts/generate_deploy.py \
  --name my-service \
  --env production \
  --owner platform-team \
  --output deploy-plan.md

生成した計画を検証:

python skills/deployment-engineer/scripts/validate_deploy.py \
  --input deploy-plan.md

バリデータは ## Overview、## Preconditions、## Steps、## Verification、## Rollback、## Observability といった必須セクションの有無を確認します。そのため、主目的が CI/CD 自体ではなく、リリース手順書の質を揃えることでも、この deployment-engineer 導入には十分価値があります。

参照資料をうまく使うコツ

参照ファイルは長くないので、読み物というよりチェックリストとして使うのが効果的です。

• references/pipelines.md: ステージ順と fail-fast の考え方
• references/monitoring.md: デプロイ後に確認すべきシグナル
• references/kubernetes.md: 基本的な deployment manifest の骨組み

おすすめの使い方は、出力の各パートについて「どの reference を根拠にしたか」をエージェントに明示させることです。レビューが速くなるだけでなく、どこにスタック固有の追記がまだ必要かも見えやすくなります。

GitHub Actions 向けに使うなら相性が良い依頼

SKILL.md に GitHub Actions の例が含まれているため、deployment-engineer は GitHub ネイティブなワークフローを求める場面で特に強みを出しやすいです。たとえば次の観点を明示して依頼すると効果的です。

• ブランチごとの trigger
• needs を使った job の依存関係
• artifact の upload/download
• environment protection gate
• 本当に必要な場合だけ matrix build
• deploy job の実行条件
• 必要な secrets の一覧
• rollback や manual approval に関する注記

これは、リポジトリ内で最も具体的な根拠が示されている範囲に沿った使い方です。

導入時につまずきやすいポイント

導入が止まりやすい理由は、だいたい次の 3 つです。

1. クラウド固有まで含めた完全なデプロイシステムを期待してしまう
2. 環境情報を十分に渡していない
3. validation と deploy-plan のレビューを飛ばしてしまう

対策としては、deployment-engineer を「デプロイ設計を早めるための支援ツール兼テンプレート集」と捉え、プラットフォーム固有の実装は意図的に後から足す運用にするのが現実的です。

実務上の制約とトレードオフ

deployment-engineer については、期待値を次のように持つのが適切です。

• CI/CD の構造化には強い
• デプロイ計画書の作成にも有用
• プロバイダ固有の深い実装には踏み込みが浅い
• 特殊なインフラ構成より、標準的な Web サービスのリリースフロー向き
• 長期運用の自動化より、パイプライン初期作成の支援に向いている

主な課題が Terraform module の設計やクラスター全体のプラットフォームエンジニアリングにあるなら、このスキル単体では抽象度が高すぎる可能性があります。

deployment-engineer スキル FAQ

deployment-engineer は初心者にも向いている？

はい。ただし、少なくとも自分のアプリの実行環境とデプロイ先を理解していることが前提です。deployment-engineer は、ゼロから指示するより安全な出発点を与えてくれますが、生成された workflow を使う前に、secrets、インフラ権限、ロールアウト前提は必ず自分で確認する必要があります。

AI に直接 CI/CD を書かせるより良い？

多くの場合、再現性の面ではこちらのほうが有利です。素のプロンプトだと、rollback、observability、verification、ステージ順序といった重要要素が抜け落ちがちです。deployment-engineer はそれらを出力の基本形に織り込んでくれるため、特に generate_deploy.py と validate_deploy.py を組み合わせると安定感が増します。

deployment-engineer は GitHub Actions 専用？

いいえ。ただし、ソース内で最も明確に文書化されているのは GitHub Actions の例です。ほかの CI システムでも、deployment-engineer を使って汎用的なパイプライン段階、deployment plan、Kubernetes のロールアウトメモ、監視チェックリストを下書きすることは可能です。とはいえ、構文の落とし込みは自分で調整する前提になります。

deployment-engineer は Kubernetes デプロイにも使える？

はい。リポジトリには references/kubernetes.md があり、基本的な deployment skeleton が示されています。manifest の叩き台を作ったり、ロールアウト構造を説明したりするには十分ですが、本番レベルの ingress、autoscaling、secrets、policy 制御まで単独でまかなえる内容ではありません。

deployment-engineer を使わないほうがよいのはどんなとき？

次のようなものが必要なら、deployment-engineer は見送ったほうがよいです。

• クラウドベンダー固有の完成済みデプロイフレームワーク
• そのまま使える高度な progressive delivery ツール
• 深い infra-as-code オーケストレーション
• 組織固有のコンプライアンスロジックがすでに埋め込まれた仕組み

そうしたケースでは、スタック特化のツールチェーンや社内プラットフォームテンプレートのほうが重要になります。

このスキルはリリース安全性の向上に役立つ？

はい、直接というより間接的に役立ちます。含まれている deployment plan の構成は、preconditions、verification、rollback、observability を重視しています。そのため、「パイプラインは書けたが、実際に安全にデプロイできるか分からない」という失敗を減らす助けになります。

deployment-engineer スキルを改善する方法

一般論ではなく、デプロイ事実を渡す

deployment-engineer の出力を良くする最も確実な方法は、最初に具体情報をまとめて渡すことです。

• 正確な build/test command
• 環境名
• デプロイトリガー
• artifact の種類
• 承認要件
• smoke-test の endpoint
• rollback の発動条件

運用モデルが具体的であるほど、結果は汎用テンプレート寄りではなく実用寄りになります。

出力はレイヤーごとに要求する

最初から「全部出して」と頼まないほうがうまくいきます。おすすめの順番は次の通りです。

1. deployment plan
2. pipeline stages
3. 具体的な CI config
4. secrets と環境変数の棚卸し
5. verification と rollback のチェックリスト

この順番ならレビューしやすく、前提のズレにも早い段階で気づけます。

前提・不足情報・抜けを明示させる

追加すると効果が高い指示は次の一文です。

List assumptions, missing inputs, and production risks before writing the final pipeline.

この一文だけでも deployment-engineer の実用性が上がりやすいのは、デプロイ作業が失敗しやすいのは auth、migrations、state、observability など境界条件の部分だからです。

pipeline YAML を信用する前に runbook を検証する

生成した plan には付属の validator を使うか、同等のチェックをエージェントにさせてください。rollback や observability の章が欠けている deployment plan は、実装側も同様に不完全であるサインです。

環境別プロンプトで出力を改善する

ひとつの汎用依頼にまとめるのではなく、環境ごとに分けて依頼すると精度が上がります。

• staging: 速いフィードバック、smoke tests、seeded data の扱い
• production: 承認、変更可能時間帯、rollback、アラート監視

このほうが、単一の統合 workflow より現実的な deploy ロジックになりやすいです。

よくある失敗パターンを監視する

deployment-engineer でよくある失敗は次の通りです。

• production deploy に承認制御がない
• migration 戦略が抜けている
• サービス実態に合わない generic な health check
• staging と production の間に artifact promotion 戦略がない
• 監視の助言が広すぎて実行に落ちない

これらが見えたら、YAML を直し始める前にプロンプト側を修正してください。

レビュー可能な secret と権限モデルを先に出させる

実務では、次のような改善プロンプトが有効です。

Before generating the pipeline, identify required secrets, tokens, environment protections, and least-privilege permissions.

これは特に重要です。というのも、このリポジトリが示しているのは構造であり、組織ごとの認証モデルそのものではないからです。

監視を実際の成功条件に結びつける

監視リファレンスでは request rate、error rate、latency、logs、alerts に触れています。deployment-engineer の出力を実戦向けにするには、それらを自分たちのサービスに結びつけて指示してください。

• どの dashboard を見るか
• どの threshold が重要か
• deploy 後にどれくらい観測するか
• verification に失敗した場合、誰に page するか

こうすることで、汎用的な observability が、デプロイ可能性を判断するための具体的な verification に変わります。

staging の実測結果を次の改善に使う

最初の出力を得たら、実際の結果を次の入力に戻してください。

• failed job logs
• deploy にかかった時間
• flaky tests
• smoke test failures
• 足りなかった env vars

deployment-engineer ガイドは、推測ベースで 2 回目を回すよりも、staging で観測した事実を踏まえて改善するほうがはるかに効果的です。