ループエンジニアリングの停止条件は止まった後から設計する

📖 はじめに — 3 日で撤回した停止条件

🔄 2026-09-26 追記: 本文は v0.33.1 時点の記録である。その後の v0.33.2〜v0.36.0 と、2026-09-13〜26 に cts-ec で回った実 run を反映した再採点と訂正を、該当箇所に日付つきで追記した。訂正が 1 つある。「上限 3 と進捗なし検出の deny はまだ観測していない」は、公開の時点で既に誤りだった。

前回は、共通ハーネス cts-harness の v0.32.0 で、ループエンジニアリングの停止条件をすべて機械の側に揃えた記録だった。周回上限、進捗なし検出、run 単位の出力トークン予算、停止理由コード。AI 自身に「もう止まってよいか」を判断させる箇所をゼロにした、と書いた。

そのうちの 1 つ、予算超過で run を止める仕組みは、3 日後の v0.32.3 で撤回した。

きっかけは、発火したらその後どうなるのか、というオーナーの問いだった。答えを書き出してみると、止まった後に人が取れる手が無かった。止めた run は最初からやり直すしかなく、同じ差分なら同じ場所でまた止まる。守るはずのクレジット（モデルの利用枠。本稿では出力トークンで測る）を、止めることで燃やす形になっていた。

本稿は、その 3 日間と、承認をクレジットを使う前に置き直した経緯、そして置き直した仕組みが実際に発火し、測られ、同じ日のうちに次の修正へつながるまでを記録する。先に結論を書く。

停止条件は、止まった後に人が何をして push まで進むかを先に書いてから置く。 その経路が無い停止は、安全弁ではなく、クレジットを燃やす装置になる。

🚨 何が間違っていたか — 止めた後の経路が無い停止条件

v0.32.0 の予算停止は、workflow の stage 境界で出力トークンの累計を読み、上限 300k を超えていれば reviewer と finalizer を起動せずに FAIL で抜ける設計だった。止める判定は決定論で、AI の判断は入らない。前回の記事の主張どおりである。問題は、止めた後にあった。

欠陥	何が起きるか
再開経路が無い	再 run は preflight から全部やり直しになる。予算のカウンタも run ごとに 0 へ戻る
上限を上書きできない	上限は workflow の定数で、引数で変えられない。同じ差分なら同じ場所でまた止まる
範囲を減らせない	profile=final は merge-base からの全量レビューが規則なので、利用側に「範囲を絞る」逃げ道が無い

3 つが重なると、大きい差分の final run は「3 回燃やして、4 回目に周回上限の承認で通す」ことになる。止めるたびに、止めるまでに使ったトークンが無駄になる。

もう 1 つ、見落としていた事実がある。run 1 本の中には暴走が無い。 tdd-team の Dynamic Workflow（以下 DW）は agent の数が固定で、stage は 1 本道だ。トークンが膨らむのは run の中ではなく、run を何度も起動し直す周回の側で、そこは v0.32.0 の周回上限（PC-ROUNDS）が起動前に止めている。予算停止は、PC-ROUNDS と役割が重なったうえで、害だけを足していた。

発覚は、cts-ec の大きな final run（80 バッチ分に相当する全量レビュー）を起動する直前だった。実害が出る前に見つかったのは、発火後の経路を問われたからである。

🛠️ 直し方 — 承認をクレジットの前に置く

オーナーは、止めたあとに push まで進めない停止は停止条件として役に立たないと判断し、「警告で知らせ、承認を得て進め、push まで届ける」形に改めるよう指示した。v0.32.3 はその指示を 2 つの変更で実装した。

1. 予算は計測と警告だけにする

stage 境界の検査は残し、超過しても止めない。log に警告を出し、summary に budget-exceeded と、最初に超過を見た境界 budget-exceeded-at を記録する。run は finalizer まで走り、marker は解消され、push できる。上限 300k は、止めるための値ではなく、校正用の目安として残した。

停止理由コードの語彙にあった budget は、helper 側に互換のため残し、workflow からは出さない。

2. 大きい run は起動前に承認させる — PC-SIZE

止める場所を、クレジットを使う前に移した。precheck に新しい検査 PC-SIZE を足した。

merge-base（origin/main と HEAD）起点で、コード範囲の変更行数を数える。追跡済みファイルの追加行と削除行、未追跡ファイルの全行を合計する
目安 DW_MAX_DIFF_LINES = 10000 行を超えたら、hook が起動を deny する。reviewer は差分の全量を読むので、run 1 本のクレジットは行数に比例するためだ
承認は --approve-size --reason "<理由>" の 1 コマンドで、理由は必須。周回台帳に承認行が残る
承認は「行数 @ merge-base」を fingerprint にして、行数が変わるまで有効。是正で行数が変われば、もう一度承認を求める
承認後は最後まで走り、push まで行く。起動回数は、これまでどおり PC-ROUNDS が見る

目安の 10,000 行は、校正前の見積もりである。2026-09-07 に実測すると、当時の cts-pos のステアリングが 28,254 行、cts-ec のステアリングが 39,622 行で、どちらも承認の対象になった。大きい run では必ず一度立ち止まる、というオーナーの意図どおりの結果である。precheck は通過のたびに実測の行数を表示するので、数 run 分が溜まったら目安を校正する。

同じ版に入れる

当初、harness 側では予算停止の撤回だけを先に出し、PC-SIZE は別件として改めて承認をもらう段取りにしていた。利用側の大きい run が迫っていたので、最小の復旧を優先したつもりだった。しかしそれは、指示された挙動を後回しにすることでもあり、オーナーの判断で PC-SIZE は同じ v0.32.3 に含めた。

残した設計原則

この一件から、harness には次の原則を残した。

停止条件を足すときは、止まった後に人が何をして push まで進むか を先に書く
その経路には、再開の手段、承認の 1 コマンド、既に使ったトークンを無駄にしない仕組みの 3 つが要る。どれかが欠ける停止は入れない
承認は、クレジットを使う前に置く。途中で止めて再走させる設計は採らない

前回の記事で「ループ設計の 6 要素」を揃えたとき、要素の形は揃っていたが、止まった後の経路は設計していなかった。停止条件の数を揃えることと、停止条件が機能することは別だった。

🔥 初発火の実録 — 2026-09-12、承認 4 回

PC-SIZE が初めて発火したのは、v0.32.3 のリリースから 5 日後の 2026-09-12、cts-ec の約 4 万行の branch だった。周回台帳は marker の解消と同時に消える設計なので、記録は利用側のセッション記録から起こした。時刻は JST である。

承認	変更行数	ファイル数	承認理由（要約）	DW 起動	結果	出力トークン
13:25	39,789	404	初回 push 前の final run	13:27	FAIL	158,635
14:48	40,246	409	1 回目 FAIL の是正を反映した後	14:49	RUN_PASS	148,904
15:34	40,609	412	push 時のテスト対応検査の是正を反映した後	15:34	RUN_PASS	160,872
17:15	40,614	412	frontend の不安定なタイムアウトの是正を反映した後	17:15	RUN_PASS	89,604

4 回とも、deny から 10 秒〜3 分余りで理由つきで承認され、その数秒〜2 分余り後に DW が起動している。是正のたびに行数が変わり、承認をやり直している。行数が変わるまで有効、という設計どおりの挙動である。 承認の理由は台帳に残り、オーナーの裁定回数の計装にもなっている。

その夜、同じ cts-ec の約 1 千行の branch（740 行、904 行、1,007 行）では、PC-SIZE は緑のまま通した。発火したのは、立ち止まるべき大きい run だけだった。

1 本目の FAIL は、reviewer の出力が表の列数の契約に合わなかったためで、予算とは関係が無い。結果だけを見れば、4 本とも 300k の手前で終わっていて、v0.32.0 のままでも予算停止は踏まなかった。ただ、踏むかどうかは起動するまで分からない。この日の 4 本は、分からないまま燃やすのではなく、行数を見て承認してから燃やす順番で流れた。

📊 使用量を測った — 7 run のうち 54% は PASS の後だった

v0.32.3 の適用後、cts-ec の 2 本の branch で 7 run の出力トークンが揃った。

branch	run の流れ	出力トークン
約 4 万行	FAIL → PASS → push 時にテスト対応検査が block → テスト追加で証跡が古くなる → PASS → 不安定なタイムアウトを是正 → PASS	158,635 → 148,904 → 160,872 → 89,604
約 1 千行	PASS → PASS → PASS	104,609 → 120,382 → 105,948

1 run あたりの出力トークンは約 9 万〜16 万。目安の 300k は、止めない目安として妥当 と確認できた
7 run の合計は約 89 万で、そのうち PASS の後にもう一度走らせた 4 本が 476,806、全体の約 54% を占めた
ただし、その 4 本のうち 2 本は新しい指摘を出していて、純粋な無駄ではない

PASS の後に run を回し直す原因は 2 つあった。

push のときにしか走らない検査があった。 テストとコードの対応を見る hook が pre-push にしか配線されておらず、ゲート台帳に載っていなかった。そのため、起動前にゲート台帳の決定論ゲートがすべて緑かを見る PC-GREEN の対象外で、DW が PASS した 3 分後に push で初めて落ち、その是正が証跡を古くした
PASS 後の軽い是正でも、run を丸ごと回し直す必要があった。 ハーネスには「軽微な指摘の是正後は DW を再 run しなくてよい」という運用規則があった。一方で CI は「証跡のコミット以降にコード変更が無いこと」を要求する。コードに触る是正をすれば必ず証跡が古くなるので、規則と CI が両立していなかった

🔁 回して、観測して、同じ日に直した

2026-09-13 には、cts-ec のある DW が 4 回起動してようやく PASS した。4 回目までかかった理由をオーナーに問われ、harness 側で内訳を分解した。

起動	結果	何が起きたか
DW1	PASS	—
—	—	PASS 後にコードを是正
DW2	FAIL	証跡と是正を同じ commit に束ねたため、前回の証跡からの差分が 0 になり、レビュー基点の検査で落ちた
DW3	FAIL	preflight の agent が ACTIVE.md の先頭リンクを読み違えて落ちた。さらに、この経路では lock が解放されず、手で削除した
DW4	PASS	—

7 run の分析と、この 4 起動の内訳は、そのまま 3 件の課題として起票され、同じ日のうちに 2 つの版で塞がれた。

版	塞いだもの	どう塞いだか
v0.33.0	PASS 後の是正が run の丸ごとやり直しを強制する	`profile=amend` を新設。前回 PASS した証跡のコミット以降の差分だけを、reviewer 1 体で再レビューして証跡を作り直す。差分が 0 の起動（DW2 の型）は、起動前の PC-AMEND が 0 トークンで止める
v0.33.0	push 時にしか走らない検査が起動前の対象外	テスト対応検査をゲート台帳に登録し、PC-GREEN が DW の前に落とすようにした
v0.33.1	agent が ACTIVE.md を読み違える（DW3 の型）	起動前 precheck が決定論で検証済みの値を `--print-active` で 1 行出し、agent はそれを転記するだけにした。機械が確かめた値を LLM に読み直させない
v0.33.1	起動後の preflight 検査で落ちたとき lock が残る	lock を取得済みなら、handoff の agent 1 体が解放する
v0.33.1	証跡と是正を同じ commit に束ねると、CI の時間の検査をすり抜ける	CI と push hook が、証跡に記録されたレビュー対象のハッシュを証跡コミットの tree から再計算して突き合わせる。束ねた commit は赤になる

採らなかった案もある。PASS 後の是正を「Lead（実装を指揮するセッション）が証跡に追記すれば時間の検査を満たす」ことにする案は、作った本人が自分の成果を採点する穴を再び開けるので採らなかった。「証跡は必ず単独の commit にする」案は、レビュー済みのコードと証跡を同じ commit に置く通常の流れを壊すので、ハッシュの再計算を選んだ。

観測から修正までが、同じ日に閉じた。 前回の採点表で「データが溜まるのを待つだけ」と書いた 12 番の基準に、初めて実績が付いた。

📏 Anthropic の基準で再採点する

前回の記事で、Anthropic の公式ブログ「Loop engineering: Getting started with loops」から 12 項目の基準を抜き出し、✅ 機械で成立、🔌 配線済み・未起動、🧭 設計判断が要る、の 3 段階で採点した。v0.32.3〜v0.33.1 で判定や根拠が動いた行だけを載せる。

#	Anthropic の基準	前回	今回	根拠
1	ループとは、停止条件が満たされるまで作業サイクルを繰り返すこと	🧭	🧭	`profile=amend` で再試行の範囲を差分に絞れるようになったが、起動するのは人。「途中で止めて再走させる設計は採らない」「承認はクレジットの前に置く」という原則が決まった。無人の再試行を増やすより、人の承認を起動前に置くことが先に決まった形で、「どの型を無人で再試行するか」はまだ決めていない
2	成功条件と停止条件を明確に定義する	✅（未発火）	✅	PC-SIZE が発火し、deny と承認が 4 回記録された。周回上限 3 と fingerprint 一致による deny は、まだ観測していない
4	決定論的な作業にはスクリプトを使う	✅	✅	根拠を補強。precheck が検証済みの値を `--print-active` で渡し、agent に読み直させない
8	部分的にしか検証していない成果を返さない	✅	✅	根拠を補強。CI が証跡のハッシュを証跡コミットから再計算し、レビューしていない是正が push に乗る経路を塞いだ
10	使用量をレビューする	🔌	🔌	7 run の実測で目安 300k を校正した。run 単位の総トークンの集計だけ未配線
12	ループを回し、結果を観測し、設計を改善する	🔌	✅	4 起動の観測と 54% の分析が、同じ日に v0.33.0 と v0.33.1 の修正になった

集計は ✅ 9、🔌 2、🧭 1 になった。前回の ✅ 8、🔌 3、🧭 1 から、12 番が ✅ に移った。

12 番を ✅ にしたことには注記が要る。前回の定義では ✅ は「機械で成立」だった。12 番の中で機械が担うのは計測と記録で、観測の分析、起票、採否の裁定は人とエージェントが行っている。それでも ✅ としたのは、この基準が問うているのが仕組みの自動化ではなく「回して、観測して、直す」という実践そのものであり、その実績が出たからである。

🔄 2026-09-26 追記 — v0.33.2〜v0.36.0 で数え直す

🔄 2026-09-26 追記: 上の表は v0.33.1 時点の再採点である。その後の 13 日間で harness は 5 版（v0.33.2 / v0.34.0 / v0.35.0 / v0.35.1 / v0.36.0）進み、cts-ec には停止条件の発火と、その後の人の動きが記録に残った。判定が動いた行と、判定は変わらないが根拠が「設計」から「実測」へ変わった行を載せる。数字は harness の CHANGELOG と、cts-ec のセッション記録・証跡ファイル・台帳から起こした。時刻は JST である。

#	Anthropic の基準	前回	今回	根拠
10	使用量をレビューする	🔌	✅	前回「未配線」と書いた総トークンの集計を、v0.36.0 が配線した。Codex（実装・調査・設計案の下書きを担う側）の run が終わるたびに、Codex のセッション記録から入力・キャッシュ・出力・推論・ターン数を読み、台帳 `codex-usage.tsv` へ 1 行、日次の累計、1 run 300 万トークン超の警告（止めない）を機械で出す。cts-ec では 09-26 に台帳へ 2 行（168 万・247 万）が入った。使用量の観測が版の判断を 2 回変えたことも、実績になった。①共有設定のモデルが黙って `gpt-5.6-sol` から上位の `gpt-6-astra`（単価 2.5 倍）へ書き換わり、cts-ec の実装 16 run が 6 日間そのまま走っていたのを実測で見つけ、v0.35.0 で `codex exec` の前に設定のモデルを期待値と突合して止める検査を置いた。実行後の banner に記録はあったが、誰も突合していなかった。記録は検出ではない。②09-19〜25 の Codex 消費が前週の 9 倍（6.4 億トークン）になった原因を分解すると、単価でも effort でもなく、run の本数（1 日 14 → 58）と 1 run の重さ（中央値 30 万 → 434 万）で、クレジットの 63% はキャッシュ入力だった。v0.36.0 で調査の既定モデルを `gpt-5.6-sol` から 1 段下の `gpt-5.6-terra`（入力の単価は sol の半分）へ下げた。調査 15 run はクレジットの 26% を占め、その 9 割は既定の sol で走っていたので、同じ週の構成なら全体で 13% の削減になる見込みである。実装のピン（sol）は据え置いた。実装は消費の 71% を占めるが、未計測で落とすと出戻りで返る。台帳に調査の run はまだ無く、削減の実測はこれからだ。注記: Claude 側の agent は今も出力トークンだけを記録しており、入力とキャッシュは測っていない。12 番と同じ理由で ✅ とする
2	成功条件と停止条件を明確に定義する	✅	✅	注記を訂正する。「上限 3 と fingerprint 一致による deny は、まだ観測していない」は、本稿を公開した 09-13 20:52 の 3 時間前（17:08）に cts-ec で最初の deny が出ていたので、公開の時点で誤りだった。09-13〜23 の 11 日間で、進捗なし（fingerprint 一致）の deny が 9 件、上限 3 到達が 1 件、`--approve-round` による理由つきの承認が 11 回。いずれも起動前なので、消費は 0 トークンである。09-26 には、起動直後に agent 1 体が環境を検査する層 2 preflight が、plugin の版数と配布済みスクリプトの版数の不一致（検査 AT-14）で run を止めた。消費は約 1.2 万出力トークン。v0.33.2 で直した handoff が lock を解放し、次の起動は手作業なしで通った。「止まった後の経路」が機械で用意された、最初の実働である
4	決定論的な作業にはスクリプトを使う	✅	✅	根拠を補強。検証済みの値を LLM に読み直させない型が 2 つ増え、どちらも実 run で確かめた。preflight の CLI 版数は `claude --version` の 1 行転記にした（v0.33.2。自由記述だった間に agent がモデル名を書き、偽の FAIL を出していた）。`--print-active` の転記は 09-26 の run で成立し、preflight の errors は AT-14 の 1 件だけだった
5	仕事に合ったプリミティブとモデルを選ぶ	✅	✅	根拠を補強。モデル選択の規則が docs から機械検査へ移った（v0.35.0、10 番の①）。v0.36.0 は調査の既定モデルを sol から terra へ 1 段下げ（10 番の②・見込み −13%）、段別の推奨表とスクリプトを一致させた。既定で `-m` を渡すので、共有設定のモデルが書き換わっても調査は影響を受けない。v0.34.0 はレビュー側の上位モデルを Opus 5.5 へ上げたが、「切替後の数 run で出力トークンと出戻りを基準線と比べ、悪化すれば戻す」という規則つきである。09-26 の final run は 17.4 万出力トークンだった。基準線の 10.5 万〜15.9 万は差分が小さい run の値なので、まだ比べられない
8	部分的にしか検証していない成果を返さない	✅	✅	根拠を補強。証跡が正当な変更を赤にする穴を 2 つ（rename を含むレビューの証跡が commit 後に必ず無効になる、証跡ファイルの移動で錨がずれる）、被覆から漏れる穴を 1 つ（証跡の後に main を取り込むと、main 経由で入った削除が予定範囲から消える）塞いだ（v0.33.2、v0.35.1）。09-26 の cts-ec は final → amend → amend の 3 run で証跡を毎回単独の commit にし、被覆は 834 → 835 → 848 件と伸びた
9	学びを次の周回へ組み込む	✅	✅	根拠を補強。v0.33.1 で足した「層 2 FAIL 後の lock 解放」は、helper 側の語彙に停止理由が無く、出荷以来一度も動いていなかった。cts-ec の報告で見つけ、直すと同時に「workflow が渡す停止理由 ⊆ helper の語彙」を契約テストに固定した（v0.33.2）。逆向きの学びも 1 つ。PC-SIZE は 09-12〜26 に 10 回発火して 10 回とも承認され、判断を一度も変えていない。09-26 に PC-SIZE の計測を賢くする改修案が出たが、「そのチェックは過去に判断を変えたか」を数えて見送った。判断を変えないチェックは足さない
12	ループを回し、結果を観測し、設計を改善する	✅	✅	根拠を補強。同日修正が 3 回増えた。09-23（cts-ec の報告 3 件 → v0.33.2）、09-24（cts-ec の報告 → v0.35.1）、09-26（消費の観測 → v0.36.0）

集計は ✅ 10、🔌 1、🧭 1 になった。動いたのは 10 番だけである。

変わらない行にも、書くことがある。

1 番（🧭）は変わらない。 無人で再試行する型は決めていない。決めていないことの代償も、記録に残った。09-22、cts-ec は push 前に final を 9 回起動した（完走 7、環境要因の失敗 2。うち 1 回は文書だけの是正で、run 自体が不要だった）。消費は利用側の記録で約 447 万トークン。上限 3 は marker（レビュー待ちの印）ごとに数えるので PASS のたびに 0 へ戻り、9 起動のうち deny に当たったのは 3 回で、3 回とも理由つきで承認された。機械は止めた。人が回した。停止条件は「回してよいか」を人に問う装置であって、人の判断の代わりはしない
6 番（✅）の根拠は言い換えが要る。 前回の根拠に書いた pilot アーム（A/B）は v0.23.0 で撤去済みで、大規模 run の前に立ち止まる現行の仕組みは PC-SIZE と承認である。10 回とも承認された、ということは、立ち止まりはするが分割はしていない、ということでもある
11 番（🔌）は変わらない。 /loop と /schedule は起動していない。v0.36.0 の申し送りにある「1 日回して前日と比べる」も、今は人が読んでいる

🔭 それでも「完成」と書かない理由

前回の記事は「「完成」の 1 語は、初回発火の実録のために取っておく」と書いた。本稿はその初回発火の実録だが、まだ「完成」とは書かない。

発火したのは承認ゲートで、上限で止まった run ではない。 PC-SIZE は起動前に立ち止まらせて、承認で進ませる検査である。周回上限 3 や進捗なし検出で機械が run を止めた記録は、まだ無い。しかも周回台帳は marker の解消と同時に消えるので、過去に発火していたかを後から確かめる手段も無い（2026-09-26 追記: この 2 文は誤りだった。進捗なし検出の deny は本稿の公開 3 時間前に cts-ec で初めて発火しており、その後 09-23 までに 9 件、上限 3 到達も 1 件を数えた。周回台帳は消えるが、利用側のセッション記録に precheck の出力が残るので、初発火の実録と同じ方法で復元できる。数え直しは上の再採点の追記に書いた）
「修正 → 再試行」は、今も人が回している。 amend で再試行の範囲は小さくなったが、起動は人である。今回決まった原則は、無人の再試行を増やすことより、人の承認をクレジットの前に置くことを優先している（2026-09-26 追記: 09-22 には cts-ec が deny を 3 回とも理由つきで承認して越え、push 前に final を 9 回起動した。機械は止めたが、人が回した。「完成」と書かない理由の重心は、1 番からこの 2 番へ移った）
time-based と proactive のループは、まだ回していない。 定期作業を /loop や /schedule に載せる段階は、前回の「今後の課題」のままである

🧾 まとめ

v0.32.0 の予算停止は、止める判定こそ決定論だったが、止めた後に push まで進む経路が無く、守るはずのクレジットを燃やす形だった。3 日後の v0.32.3 で撤回した
代わりに、予算は計測と警告だけにし、起動前の PC-SIZE で大きい run に理由つきの承認を求めるようにした。承認はクレジットを使う前に置く
PC-SIZE は 2026-09-12 に cts-ec の約 4 万行の branch で初めて発火し、deny と承認を 4 回記録した。小さい branch では発火しなかった
7 run の実測で目安 300k を校正し、PASS 後の再 run が出力トークンの約 54% を占めることが分かった
翌日の 4 起動の観測が、同じ日のうちに v0.33.0（amend、テスト対応検査の台帳登録）と v0.33.1（検証済みの値の転記、lock 解放、証跡ハッシュの再計算）になった
Anthropic の基準で再採点すると ✅ 9、🔌 2、🧭 1。上限での機械停止は未観測で、再試行は人が回すので、まだ「完成」とは書かない
2026-09-26 追記: v0.33.2〜v0.36.0 で数え直すと ✅ 10、🔌 1、🧭 1。使用量のレビュー（10 番）が、Codex 側の総トークン台帳で機械に乗り、その観測から調査の既定モデルを sol から terra へ下げた（見込み −13%・実測はこれから）。上限と進捗なしの機械停止は 10 件を観測し、人が承認で越えた 9 起動も観測した。だから、まだ「完成」とは書かない

ループエンジニアリングの停止条件は、止める条件より先に、止まった後の経路から書く。 止めることが目的なのではない。クレジットを守り、出荷まで届けるために止める。

📚 シリーズ記事（ステアリング駆動開発・応用編）

第I部: クロスファミリー検証（全 6 回）

本編終章

クロスファミリー検証の最終型 — 自分で正しさを測り直す

運用実録

現在地と事業展開

「最高品質ですか？」に Yes と答えないハーネス
二度の「1か月」を繰り返さない — 技術的負債から育てる AI 駆動開発ハーネス【サービス化への現在地】
ステアリング駆動開発を、ループエンジニアリングで包む — 人の注意力で止めるから、機械の停止条件で止めるへ【v0.32.0】
3 日で撤回した停止条件 — ループエンジニアリングは「止まった後」から設計する【v0.33.1】（本記事）
月 5 万円の定額で 24 時間ループを回す — サブスクの上限を最外周の停止条件にする【v0.39.1】
49 時間ループの実録 — ループエンジニアリング、いよいよ v1.0.0 前夜【v0.39.1】

ステアリング駆動開発を、ループエンジニアリングで包む — 本稿の前編。停止条件層の導入と、Anthropic の基準による最初の採点
「最高品質ですか？」に Yes と答えないハーネス — 効かない機構を測って捨てる、という撤回の作法の原点
二度の「1か月」を繰り返さない — 実案件の欠陥を共通規範へ戻す学習ループ。本稿の同日修正はその実例

参考リンク（2026-09-13 時点で確認）

Loop engineering: Getting started with loops（Anthropic 公式ブログ、2026-06-30） — 再採点の基準の出典（2026-09-26 に再確認。12 項目の抜き出しに漏れは無かった）
Keep Claude working toward a goal（Claude Code 公式ドキュメント） — /goal の停止判定と進捗なし停止

3 日で撤回した停止条件 — ループエンジニアリングは「止まった後」から設計する【v0.33.1】