本番インシデントの対応中に、開発者が並行して新しい push やリトライを実行し、CI/CD キューが積み上がることがあります。対応に無関係なビルドがコンピューティングリソースを消費し続ける、インシデントの原因となったコード変更が別ブランチ経由でさらにデプロイされる、といったリスクが生じるケースです。
CircleCI は 2026 年 2 月に、新規パイプラインの起動とワークフローの再実行をブロックする機能「Block all new work」を一般公開しました。本記事では、この機能の概要、設定方法、インシデント対応フローへの組み込み方、および現時点での制約を紹介します。
Block all new work とは
Block all new work は、組織レベルまたはプロジェクトレベルで新規パイプラインの作成とワークフローの再実行を停止する設定です。インシデント対応中やメンテナンスウィンドウ中に、意図しないビルドの実行を防止できます。
この設定を有効にすると、新規パイプラインの実行とワークフローの再実行が強制停止されるようになります。ただしすでに実行中のワークフローは停止されません。なお、手動でのパイプライン実行を試みると「Permission denied.」のエラーが表示されます。
Block all new work はあくまで新規の起動をブロックするものであり、進行中の処理には影響を与えません。「意図しないデプロイやビルドジョブを実行しないように、パイプライン全体を緊急停止する機能」のようなイメージですね。
Block all new workを設定する
Block all new work は、組織またはプロジェクト単位で設定できます。
組織レベルで設定する場合
組織全体のすべてのプロジェクトに対してブロックを適用します。
CircleCI Web App のサイドバーから Org を選択し、Advanced タブを開きます。
ページをスクロールし、Block all new work from starting for this organization トグルを有効にします。
プロジェクトレベルで設定する場合
特定のプロジェクトのみにブロックを適用します。
CircleCI ダッシュボード のサイドバーから Projects を選択し、Project Settings に移動します。その後、 Advanced タブを開きましょう。
ページをスクロールし、Block all new work from starting for this organization トグルを有効にします。
ブロックを解除するには、同じトグルを無効に戻します。
組織レベルとプロジェクトレベルの使い分け
状況に応じて適切なスコープを選択してください。
| 場面 | 推奨スコープ |
|---|---|
| 本番インシデントで、影響範囲が複数プロジェクトにまたがる | 組織レベル |
| メンテナンスウィンドウ中に全ビルドを停止したい | 組織レベル |
| 特定サービスのみリリースを一時停止したい（他は継続） | プロジェクトレベル |
| 障害調査中の特定リポジトリのみブロックしたい | プロジェクトレベル |
組織レベルでブロックすると、すべてのプロジェクトが対象になります。影響範囲が不明な初動段階では、プロジェクトレベルから適用して段階的に拡大する方法が安全です。
Config Policy との違い
CircleCI の Scale プランでは、Config Policy を使ってパイプラインの実行条件を制御できます。
こちらでもパイプラインを停止させることは可能ですが、インシデント発生時などの緊急対応については、Block all new work 機能を使うことをお勧めします。
| 比較項目 | Block all new work | Config Policy |
|---|---|---|
| 利用可能なプラン | プラン制限の記載なし | Scale プランのみ |
| 設定方法 | Web App の UI トグル操作 | Open Policy Agent（Rego）によるポリシー記述 |
| 主な用途 | インシデント時の一時的な全面停止 | 恒常的なガバナンスルールの適用 |
| 対象範囲 | 新規パイプライン全体 | ポリシーで定義したルールに違反するパイプライン |
Block all new work は緊急時に UI から即座に適用できる一時的な停止手段です。一方でConfig Policy は組織のセキュリティポリシーやコンプライアンス要件を恒常的に適用するためのガバナンスツールです。そのため両者は補完関係にあり、用途に応じて使い分けてください。
インシデント対応フローへの組み込み方
Block all new work を、既存のインシデント対応フロー（ランブック）に事前に組み込んでおくことで、対応時の判断コストを下げられます。
以下は一般的な組み込み例です。
- インシデントの影響範囲を特定する
- 影響するプロジェクトまたは組織全体に Block all new work を適用する
- 進行中のワークフローの扱いを判断する（完了まで待機 or 手動キャンセル）
- 原因調査・修正作業を実施する
- 修正確認後、Block all new work を解除してパイプラインを再開する
Block all new work は進行中のワークフローを停止しません。インシデントの原因となったコード変更を含むワークフローが実行中の場合は、APIやダッシュボードから手動でキャンセルする必要があります。
Audit Log での操作確認
Block all new work の適用・解除操作は、CircleCI の Audit Log に記録されます。Audit Log のリクエスト（CSV ダウンロード）は全プランで利用可能です。
プロジェクトレベルで Block all new work を操作すると、project.settings.update アクションとして記録されます。以下は、筆者の検証環境で Block all new work を操作した際の Audit Log の抜粋です。
| occurred_at (UTC) | action | actor | target | payload (settings) | metadata |
|---|---|---|---|---|---|
| 2026-03-25 06:22:18 | project.settings.update | github: hidetaka | practice-vite-app | feature_flags.drop-all-build-requests |
via: session-key |
| 2026-03-25 06:22:40 | project.settings.update | github: hidetaka | practice-vite-app | feature_flags.drop-all-build-requests |
via: session-key |
| 2026-03-25 06:22:49 | project.settings.update | github: hidetaka | practice-vite-app | feature_flags.drop-all-build-requests |
via: session-key |
操作者（actor）・対象プロジェクト（target）・タイムスタンプ（occurred_at）が記録されるため、ポストモーテムでのタイムライン再構築に利用できます。metadata の via: session-key は、Web UI からの操作であることを示しています。
ランブックに Block all new work を組み込む際は、事後の Audit Log 確認ステップもあわせて追記しておくと、振り返りの精度が上がります。
現時点の制約
Block all new work を運用へ組み込む際に、把握しておくべきポイントが１点あります。
API からの操作は現時点でサポートされていない
Block all new work の設定はダッシュボードからのみ操作可能です。API v2 の Project Settings エンドポイント（PATCH /project/{project-slug}/settings）のスキーマには2026/03時点で含まれておらず、組織レベルの設定を操作する API エンドポイントも存在しません。
そのため、PagerDuty や Opsgenie などのインシデント管理ツールからの自動トリガーや、Terraform による IaC 管理などへの対応が難しく、担当者が手動で操作する必要があることに注意しましょう。
ランブックにこの機能を組み込む場合は、手動オペレーションであることを前提に手順を設計してください。設定画面への直接 URL をランブックに記載しておくと、深夜のインシデント対応時にも迅速にアクセスできます。
API 対応に関するフィードバックは CircleCI Discuss または Canny から送ることができます。
まとめ
Block all new work は、インシデント対応やメンテナンス時に新規パイプラインの起動を即座に停止できる機能です。組織レベルとプロジェクトレベルの 2 段階で設定でき、UI のトグル 1 つで完結します。進行中のワークフローには影響を与えません。
一方で、API からの操作が現時点でサポートされていないため、自動化フローへの組み込みには制約があります。この機能をランブックに組み込む場合は、手動オペレーションを前提とした手順設計が必要です。
次のステップ
- 設定画面を確認する: サイドバーの Org > Advanced または Project Settings > Advanced を開き、Block all new work トグルの場所を確認してください
- テスト環境で動作を検証する: テスト用のプロジェクトでトグルを有効にし、push や手動実行がブロックされることを確認してください。特に、ブロック解除後の挙動（VCS イベントの再発火有無）を確認しておくと、本番運用時の安心材料になります
- ランブックに追記する: 既存のインシデント対応手順書に、Block all new work の適用・解除手順と設定画面の URL を追記してください