Stopを押しても、
仕事は止まらない

AIエージェントに作業を任せていると、途中で止めたくなる場面があります。

このときチャットのStopボタンを押すと、応答の生成は止まります。ところが、その会話が起動したGitHub Actions、cron、deploy、DBマイグレーションは、多くの場合そのまま走り続けます。

結論は次のとおりです。

チャットの停止と、外部processの停止は別の操作です。

そして、停止の状態は1つではありません。取り消しを要求した状態と、取り消しが確定した状態と、観測できない状態を別々に持ち、観測できない状態は安全側へ倒します。

Incident Card

INCIDENT:
チャットのStopと、外部で走っているprocessの停止を同じ操作として扱っていた

SYMPTOM:
会話を止めたあともworkflow、cron、deployが進み、最終状態を誰も観測していない時間が生まれた

FALSE_ASSUMPTION:
Stopを押せば、その会話が起動した作業も一緒に止まる

ROOT_CAUSE:
会話の停止、取り消しの要求、取り消しの確定、観測、巻き戻しが1つの状態として扱われていた

IMMEDIATE_FIX:
会話を止めたあとも、起動済みjobのterminal stateを取り直すまで作業を完了扱いにしない

SYSTEM_FIX:
NOT_DISPATCHED / RUNNING / CANCEL_REQUESTED / CANCEL_CONFIRMED / SUCCEEDED / FAILED / UNKNOWNを別状態として持ち、UNKNOWNをfail-closed側へ倒す

REMAINING_RISK:
取り消し要求が届いたことと、副作用が発生していないことは別。巻き戻しはさらに別の操作である

会話を止めても、外へ出た仕事は走り続けた

観測できた事実は次のとおりです。

• 会話を止めても、起動済みのGitHub Actions runは進みます
• vercel.jsonのcronは会話と無関係に発火します。/api/cron/jobs-tickなど複数のジョブが10分間隔で登録されています
• 本番系workflowはconcurrency.cancel-in-progress: falseのため、あとから別のrunを投げても割り込みで止まりません
• 会話が終わったあと、terminal stateを誰も観測していない時間が生まれます

止まったのは会話の生成だけでした。外部システムの状態は、会話の有無とは独立に進みます。

誤った前提：Stopは1つの操作である

Stopボタン、会話終了、workflow cancel、deploy cancel、migration cancel、rollbackを同義に扱っていました。実際には、止まる対象も可逆性も違います。

この表の下2行が重要です。deployとmigrationは、途中で止めても「元に戻る」わけではありません。止めた地点までの副作用は残ります。

根本原因：停止を1つの状態として持っていた

停止を「止めた／止めていない」の2値で扱うと、次の3つが同じ値へ潰れます。

1. 取り消しを要求したが、届いたかどうかは未確認
2. 取り消しが提供側で確定した
3. 状態を観測できない

3つ目が最も危険です。観測できないことを「たぶん止まった」と読むと、実際には走り続けているprocessの上で次の操作を始めます。

その場の対処：terminal stateを取り直すまで完了にしない

会話を止めたあとに行う最小の手順を固定しました。

1. この会話が起動した外部processを列挙する
2. 各processのstateを提供側APIから取り直す
3. terminal state（SUCCEEDED / FAILED / CANCEL_CONFIRMED）に到達したものだけ完了とする
4. 取り直せないものはUNKNOWNとして記録する
5. UNKNOWNが1件でもある間、次のmutationを始めない

「会話を閉じたので終わりです」とは報告しません。閉じたのは会話であって、processではありません。

仕組みへの変換：7つの状態で停止を扱う

CANCEL_REQUESTEDとCANCEL_CONFIRMEDを分けることが要点です。要求を送ったことは、こちら側の事実です。取り消されたことは、提供側の事実です。この2つを1つにすると、要求を出した時点で止まったものとして扱ってしまいます。

操作側は次の4つへ分けます。

STOP(conversation)   -> 会話の生成だけを止める。外部processへは何も送らない
CANCEL(process_id)   -> CANCEL_REQUESTED へ遷移させる。確定はしない
OBSERVE(process_id)  -> terminal state を取り直す。停止後も続ける
ROLLBACK(target)     -> 前進を戻す別operation。承認と証拠を要求する

if state == UNKNOWN:
    TREAT_AS = RUNNING_OR_APPLIED
    MUTATION = NOT_PERFORMED

observation：停止を決めても、観測は止めない

停止したあとに観測をやめると、そのprocessは「止めたつもり」のまま記録から消えます。観測は、停止の判断とは独立して続けます。

このリポジトリでは、Stopそのものが終了ではなく検査点として実装されています。.claude/settings.jsonのStopには3つのhookが登録されており、そのうち.claude/hooks/autonomous-stop-guard.mjsは、agentが自分で実行できる待機・確認・後片付けをユーザーへ返して終わろうとする停止を拒否します。

同じhookは、background taskのうちcompleted、failed、cancelledのいずれでもないものをactiveとして扱います。走っているものがある状態は、終了状態ではありません。

rollback：停止と巻き戻しは別操作

止めることと戻すことを同じ操作に見せると、事故が起きます。

.github/workflows/deploy-signal-production.ymlは、deployが成功した時点で境界を記録します。Step SummaryにはState: DEPLOYEDと対象SHAが書かれ、続けて「後続jobはpost-deploy verificationであり、そこでの失敗はこのdeploymentを取り消さない」と明記されています。

つまり、workflowが赤くなっていても本番は更新済みという状態が正しく存在します。赤いworkflowを「未反映」と読んでblind rerunすると、二重の反映を起こします。

巻き戻しは専用のworkflowです。.github/workflows/production-rollback.ymlは、新しいコードを一切出さない復旧専用の経路として分けられています。実行には確認文字列の入力が要り、main以外からは動きません。さらに、入力された戻し先を信用せず、Vercelからmetadataを取り直して素性を検証します。

戻せるのは、source commitがorigin/mainの履歴にあり、かつ過去に本番として配信されたdeploymentだけです。未マージのPreviewへ「rollback」できるなら、それは復旧ではなく迂回です。

割り込みで止められない設計もある

すべてのprocessを「あとから来たものが古いものを殺す」形にはしません。本番系のworkflowはconcurrencyのcancel-in-progressをfalseにしています。

新しいrunで古いrunを止めてよいのは、途中で止まっても外部状態が壊れない検査系だけです。本番deployとrollbackは同じsignal-productionというconcurrency groupで直列化し、本番DBマイグレーションはproduction-db-migrationという別のgroupで直列化します。いずれも割り込みでは止めません。

groupを分ける理由は、deployとmigrationが互いを待つ必要がないためです。同じgroupへ入れると、片方の実行がもう片方を待たせます。止めない設計と、待たせない設計は別々に決めます。

migrationについても、.github/workflows/production-migration.ymlは手動実行専用で、確認文字列と、適用するつもりのmigration番号の入力を要求します。実際の未適用と食い違えば中止します。止める設計より前に、始める条件を絞っています。

再利用できる停止操作の対応表

止めたいものごとに、使う操作と確認すべきterminal stateが違います。

このうち、下2行は「止める」ではなく「戻す」に分類されます。混ぜないでください。

Evidence

適用限界

• 状態名はNetsujoの運用語です。提供側APIの状態名とは1対1で対応しません。移すときは対応表を作ってください。
• 停止によって削減できた事故件数や時間は未計測です。この記事は状態分離と観測手順が存在する状態までを扱います。
• ここで扱うのはGitHub Actions、Vercel、DBマイグレーションを前提とした構成です。実行基盤が変われば、観測できる状態も変わります。
• concurrencyの設定は「割り込みで止まるか」を決めるだけで、手動cancelを禁止するものではありません。

残るリスク

• 取り消し要求が届いたことと、副作用が発生していないことは別です。CANCEL_CONFIRMEDでも部分適用は残りえます。
• UNKNOWNをfail-closedにすると、実際には終わっている作業で待ちが発生します。観測経路の可用性がそのまま運用速度に効きます。
• 巻き戻せる範囲は、過去に本番として配信された履歴に依存します。履歴に素性の記録がなければ、戻し先として選べません。
• cronのように会話と無関係に走るprocessは、停止設計の対象から漏れやすい位置にあります。列挙の抜けは設定では防げません。

まとめ

Stopは会話の生成を止める操作です。外部processを止める操作ではありません。

STOP(conversation)
+
CANCEL(process) -> CANCEL_REQUESTED
+
OBSERVE(process) -> CANCEL_CONFIRMED / SUCCEEDED / FAILED / UNKNOWN
+
ROLLBACK(target) は別operation
+
UNKNOWN は fail-closed

止めたい対象を先に列挙し、対象ごとに操作と確認すべき状態を決めます。観測できない状態を「止まった」と読み替えないことが、この設計の中心です。

よくある質問

Stopを押したのに処理が進んでいるのはなぜですか

Stopは会話側の操作であり、起動済みの外部processへは何も送らないためです。GitHub Actionsのrun、cron、deployは、それぞれの提供側で独立に動きます。止めるには、対象ごとの取り消し操作を別に実行します。

workflowをcancelすれば、本番は元に戻りますか

戻りません。cancelは残りのstepを止めるだけで、実行済みstepの副作用は残ります。本番へ配信済みの場合、必要なのはcancelではなくrollbackです。Netsujoでは復旧専用のworkflowを分け、確認文字列と戻し先の素性検証を要求しています。

赤いworkflowは、本番が未反映という意味ですか

そうとは限りません。deploy jobが成功したあとにpost-deploy QAが失敗した場合、本番は更新済みでworkflowは赤くなります。反映の有無はworkflowの色ではなく、配信済みdeploymentと対象SHAで判断します。

状態が観測できないときはどうしますか

UNKNOWNとして記録し、実行中または適用済みの側へ倒します。次のmutationは始めません。観測できないことは、止まっていることの証拠にはなりません。

すべてのjobを割り込みで止める設定にすべきですか

検査系だけにしてください。途中で止まっても外部状態が壊れないものは、新しいrunで古いrunを止めても問題ありません。本番deploy、migration、rollbackは同じconcurrency groupで直列化し、割り込みでは止めない設定にしています。