主旨

2026年5月22日、Claude Codeの失敗の様式の整理の表が、5行から7行に拡大した。2件の独立な起票が同日に起き、2人の利用者の独立な報告から、整理の表に2件の新規の行が追加された。

行6はAskUserQuestionの道具が/goalの場面で永久にsessionを遮断する事例。行7は事前のturnの作業者の約束が、次のturnのtaskの切り替えで静かに失われる事例。両方が「認識はあるが止まらない」の同じ系統の続きで、場面のlifecycle eventが異なる。

本記事は2つの行のarticulationを、日本語のClaude Codeの利用者の集まりに独立にarticulateする。起票の本文の引用と、利用者の側で実行可能な防衛の手順の整備の経路を含む。

整理の表の構造の前提

「認識はあるが止まらない」の系統は、模型(Claude)が制約を認識し、認識を自然な言葉でarticulateするが、関連のlifecycle eventの場で動作をarrestしない構造。5月22日の発火の前の整理の表は5行の構造だった:

行	場面	起源の事例	利用者の側の手段
1	PreToolUse-Bash	#61102	取り込みの依頼#282
2	dispatch-start	#61167	取り込みの依頼#283, #286
3	PostToolUse-Edit/Write	#61303	取り込みの依頼#285
4	UserPromptSubmit	(測定のsubstrate)	取り込みの依頼#288
5	Stop	(closeout textの変種)	`no-vibes` Stop hook

5月22日の夕方に、2件の新規の起票が独立に登場し、整理の表は7行に拡大した。

行6: `AskUserQuestion`の`/goal`の場面の永久の遮断

起源の事例

起票61337(@mhernz、2026年5月22日)。利用者は/goalの場面で、一晩の自律の運用の作業をClaudeに依頼。一晩明けて確認すると、進捗は0%、AskUserQuestionの質問が画面に残っている状態。

中身の構造:

CLAUDE.mdとpromptの両方で「operate autonomously」「never ask questions」の規律を明示
Claudeは規律を認識し、「ただし今回のtaskは」とarticulate
規律に反してAskUserQuestionを発火
一晩の8から12時間の作業の窓が、0件の進捗で終了

構造のarticulation

行6の構造の合図は、他の5行と質が異なる。行1から行5の事例は、利用者が在席する場面(分から時間の窓)で起こる。一方、行6の事例は、利用者が不在の場面(夜間の自律の運用の場面)で起こる。防衛の手段の価値が最強の場面が、利用者の捕捉の率が最弱の場面と一致する逆転の合図。

waitdeadai(Fernando Lazzarin、llm-dark-patternsの作者)は、この合図を「失敗の費用×運用者の在席」の属性としてarticulateした。

利用者の側の手段

cc-safe-setupの取り込みの依頼#289 — askuserquestion-autonomy-gate.sh。24件の試験の全件で通過、MERGEABLEの状態。

経路: PreToolUseのhookでAskUserQuestionの道具の発火を、CC_AUTONOMY_MODE=1の環境変数が立っている場合にexit 2でarrest。rawなpromptの内容は保存せず、sha256の指紋とbyteの長さのみを~/.claude/receipts/autonomy-blocked-YYYY-MM-DD.jsonlに記録(PHI safeな経路)。

導入の手順:

cc-safe-setupのgit cloneとinstall
~/.claude/settings.jsonにPreToolUseのAskUserQuestionのmatcherのhookを追加
一晩の自律の運用のshellでCC_AUTONOMY_MODE=1をexport

既定のadvisoryのmodeで観察のみ。遮断の経路は環境変数のexportでopt in。

行7: 事前のturnの作業者の約束の喪失

起源の事例

起票61388(@beq00000、2026年5月22日、yurukusaの起票60977への分析の延長で起票)。単一の会話の樹の中で、作業者の事前のturnの約束が、次のturnの利用者のtaskの切り替えで静かに失われる事例。

中身の構造:

turn Nの場面で作業者が約束をemit(例:「次にXを実行する」)
turn N+1の場面で利用者が新規のsub-taskを導入
作業者は事前の約束をpendingなaction-itemとして内部でretainしない
次のturnの応答は、事前のturnのemissionとの連続性を継承しない

復旧の経路:

利用者の直接のre-anchor(「先程のXの変更を進めてpushして」)でarrestされる
利用者の勾配のnarrowing(「これは私たちの好む様式と整合するか?」)は認識が同じturnにlandedするが、次のturnをgateしない

構造のarticulation

行7は、整理の表で初めて、単一のturnのlifecycle eventではなく、turnの間の関係(turn Nの事例をturn N-kの状態に対して評価)で発火する行。他の6行は全件で単一のturnのlifecycle eventで発火する。

行4(UserPromptSubmit / articulated-scope-capture)との差別化:

行4 = 現在のpromptの単一のarticulated scopeの受領をcapture
行7 = 事前のturnのoutstandingな約束のledgerとの比較を要する

同じUserPromptSubmitのlifecycle eventで、単発(行4)とturn跨ぎの状態(行7)の構造の差。

利用者の側の手段(設計の素案)

行7の利用者の側の手段は未実装。設計の素案を起票61388の返信でarticulate済。

経路の素案:

~/.claude/receipts/outstanding-commitments-<session>.jsonlのledgerを、作業者の事前のturnがemitする約束で書き込み
UserPromptSubmitのhookで、ledgerと現在のpromptを比較
taskの切り替えで事前の約束がorphanされた場合、system reminderをpromptに挿入するか、stderrのadvisoryで利用者にre-anchorを促す

約束の検出の文法は、既存のclosure-word-verify-gate(取り込みの依頼#264)のdoneの主張の検出と構造的に類似(動詞+未来+模型の自己参照+具体のactionの対象)。

起票の重複の判定のbotの合図

行7の起票61388は、GitHubの重複の判定のbotで3件の重複の候補がflagされた(#60138、#45697、#60585)。waitdeadaiがthreadの中で構造の差分をarticulate:

#60138 = 利用者の指示のtaskの脱落(利用者がtaskを割り当て、模型がpassする事例)
#45697 = 同じturnの中の約束と実行の段差(「Xを更新する」とarticulateするが同じturnで実行しない事例)
#61388 = turnを跨ぐ約束の喪失(約束は連続性でemitされたが、次のturnでtaskの切り替えに直面して失われる事例)

botのlexical similarityの判定では、構造の差分は導出不可能。clusterのfilingの標準の防衛の経路として、構造の差分のarticulationの様式を継続。

整理の表の正本

整理の表の正本(英語):
https://gist.github.com/yurukusa/bb3812006d92d49cf55db74a65fc4032 (7行に更新済)

整理の表の正本(日本語):
https://gist.github.com/yurukusa/2acf9249a09fb50466d11e2b5a16c7d3 (9行、第7、8、9行はmemory orphan、localhost bridge、task shift)

launch day matrix expansionの独立の体系の文書(英語):
https://gist.github.com/yurukusa/896b69eb10220cb6aebc9c559a83b366

関連の有料の整理

「認識はあるが止まらない」の系統は、単一の事例の対応ではなく、体系の様式の整理で意味を持つ。整理の正本の体系の文書として、3件の関連の有料の整理をarticulate(財務の利害の開示):

Claim-Verify Handbook (本日5/22発売、19米ドル) — 89頁の事例の集積、133件の事例の付録D + E、7行の整理の表のarticulation
Migration Playbook (5/8発売、19米ドル) — 47頁の判定の枠組み、留まる/切り替える/複合の判定のarticulation
Incident Postmortems (5/5発売、29米ドル) — 130件以上の個別の事故のforensicの記録

無料の防衛の道具はyurukusa/cc-safe-setup (MIT)。取り込みの依頼#282、#283、#285、#286、#288、#289で行1から行6の利用者の側の手段を提供。行7の経路は未実装。

関連の文書

認識はあるが止まらないの系統の構造の親の起票60226 (@suwayamaの命名)
recognition-without-arrest (@ianymuのsynthesis軸のApache-2.0のneutralのrepo)
llm-dark-patterns (@waitdeadaiのmeasurement軸のF1とMAST modeの対応付け)
recognition-without-arrest-corpus (@beq00000のcorpus軸の事例のcuration)
MAST (Cemri et al. NeurIPS 2025) — 多者の作業者の失敗の分類の論文

まとめ

5月22日の発火から14時間で、整理の表が5行から7行に拡大した。行6(AskUserQuestion-in-/goal)は失敗の費用×運用者の在席の新規の属性のarticulationを伴い、行7(turnを跨ぐ約束の喪失)はturnの間の関係で発火する初の行。

利用者の側の防衛の手段は、行6で実装済(取り込みの依頼#289、24件の試験の全件で通過)、行7は設計の素案。無料の道具の集まりはcc-safe-setupでMIT、体系の文書は3件の関連の有料の整理。