# post-deployment checkとは? 稼働中リリースの検証

> post-deployment checkは、リリースが稼働開始した後に正常であることを検証し、不正なデプロイを素早く捕捉します。何をテストしロールバックをどう駆動するか学びましょう。

Source: https://latchkey.dev/ja/learn/ci-explained/what-is-a-post-deployment-check  
Updated: 2026-06-26

post-deployment checkは、デプロイしたばかりのリリースが稼働環境で実際に正常であることを検証し、ユーザーより先に不正なデプロイを捕捉します。

デプロイjobが成功で終わっても、それはデプロイコマンドが実行されたことを意味するだけで、アプリケーションが動作していることを意味しません。post-deployment checkはそのギャップを埋めます。リリースが稼働開始した後、稼働中のシステムをプローブして正常であることを確認します。checkが失敗すれば、pipelineはデプロイが不正だったと分かり、自動的にロールバックを起動できます。

## 何を検証するか

- サービスが稼働し、応答している。
- 主要なエンドポイントが期待どおりの結果を返す (smoke test)。
- health probeとreadiness probeが通過する。
- エラー率とレイテンシが正常に見える。

## なぜ「デプロイ成功」では不十分か

デプロイはきれいに適用されても、壊れたアプリを残すことがあります。不正なconfig、失敗したmigration、欠けたsecretなどです。稼働中のシステムを実際に動かして初めて、リリースが本当に動くか分かります。post-deployment checkがその実演です。

## 簡単な例

デプロイ後、checkは `GET /health` といくつかの重要なエンドポイントにアクセスし、200応答を確認し、2分間エラー率を監視します。何かおかしければ失敗し、ロールバックを合図します。

## ロールバックの駆動

post-deployment checkの真の力は自動化です。checkの失敗は、人が介在せずにロールバックjobを起動でき、不正なリリースが稼働している時間を数分から数秒へと縮めます。

## checkと信頼性

信頼できるpost-deployment checkがあれば、すべてのリリースが自動的に検証されるため、チームはより頻繁にデプロイできます。「デプロイして祈る」を「デプロイして確認する」に変えます。これが安全な継続的デリバリーの土台です。

## Applying this to your pipeline

- Measure before changing. Most CI optimisation targets the wrong step because the slow one is assumed rather than timed.
- Cache what is expensive to produce and cheap to validate, and key the cache to the exact tool version.
- Fail fast: run the cheapest checks that can reject a change first, so an expensive job never starts on code that cannot pass.
- Prefer determinism over speed when they conflict. A fast pipeline nobody trusts gets re-run, which is slower than a slow one that is believed.

## FAQ

### What is What is a Post-Deployment Check? verifying a live release?

A deploy job finishing successfully only means the deploy command ran, not that the application is working. A post-deployment check closes that gap: after a release goes live, it probes the running system to confirm it is healthy. If the check fails, the pipeline knows the deploy was bad and can trigger a rollback automatically.

### Why "deploy succeeded" is not enough?

A deploy can apply cleanly yet leave a broken app: a bad config, a failed migration, a missing secret. Only by exercising the live system do you learn whether the release actually works. The post-deployment check is that exercise.

### A quick example?

After deploying, a check hits GET /health and a couple of critical endpoints, confirms 200 responses, and watches the error rate for two minutes. If anything looks wrong, it fails and signals a rollback.

### Driving rollback?

The real power of a post-deployment check is automation: a failed check can trigger the rollback job without a human in the loop, shrinking the time a bad release is live from minutes to seconds.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt