49 時間ループの実録 — ループエンジニアリング、いよいよ v1.0.0 前夜【v0.39.1】

📖 はじめに — いよいよ完成が近い

共通ハーネス cts-harness は v0.39.1 になった。第 15 回で停止条件を機械の側に置き、第 16 回で止まった後の経路を設計し直し、第 17 回で費用の外枠を定額の上限に置いた。v1.0.0 のリリースは間近である。

その前に、1 つ確かめておきたいことがある。仕組みを並べた記事は書いてきたが、その仕組みの上で、実際にどれだけ長く回ったのか は書いていない。

本稿は、cts-ec で Claude Code と Codex を使って 49 時間続いた 1 本の開発セッションを、ループエンジニアリングの実例として記録する。良い数字も悪い数字も、セッション記録から数えたまま載せる。

先に結論を書く。

49 時間続いたのは、モデルが賢かったからではない。 会話が何度途切れても続きから再開でき、止まるべき所では起動前に止まり、人が戻るまで待てる構造があったからである。そして、人の発言の半分は、ループが自力では解けなかった場面に使われていた。

🕰️ 49 時間の時系列

① 上限待ち（10-02 14:30 〜 22:05）

セッションを開いた直後、オーナーは、利用枠が残っていないとして、テストも含めてすべて止めるよう指示した。22 時のリセットを待つ 7.5 時間は、何も動いていない。第 17 回で書いた「13 時間の停止」の後半にあたる。

② 無人の自走（10-02 22:05 〜 10-03 13:23）

リセット後、オーナーは 2 つの指示を出した。確認が必要なとき以外は止まらずに進めること。区切りまで終えたら、検証、push、MR の作成まで行うこと。

次にオーナーが発言したのは、翌日の 13:23 である。この約 15 時間、Lead（人が直接操作し、実装を指揮する主セッション）は、テスト作成のサブエージェントと Codex の実装 run を順に回し続けた。途中の 07:25 にコンテキストが一杯になり、要約から継続している。

③ 人の介入が集中した 8 時間（10-03 13:23 〜 21:26）

午後は、人の出番が続いた。

• 仕様の確認事項にオーナーが回答し、push を承認した
• 検証の起動前に、規模の検査が止めた。変更は約 18.5 万行、1,302 ファイル。理由つきで承認して進めた
• 検証の 1 回目は、引数の誤りで起動直後に止まった。消費は 0 トークンである。そのまま再起動しようとすると、進捗なしの検出が止めた。理由つきで承認し、3 回目で PASS した
• CI のパイプラインが失敗した。原因の切り分けと対処に、オーナーの発言が 11 回入った。このとき Lead のモデルは、Sonnet 5.5 から Fable 5.1 に上げられている
• MR がマージされた後、次のステアリングの内容にオーナーの訂正が入った。モデルは Opus 5.5 に切り替わっている

④ 2 度目の自走（10-03 21:26 〜 10-04 14:16）

オーナーは再び「止まらずに進める」指示を出した。ここから翌日の昼過ぎまで、オーナーの発言は数回しかない。

04:23、Lead は自分で予備の起床を予約し始めた。テスト作成のサブエージェント数名の完了を待つ間、完了通知が届かなかった場合に備えて、10 〜 30 分後に自分を起こす予約である。この予約が /loop として 22 回発火した。最後は、不要になった時点で Lead が自分でループを止めている。

12:16 にオーナーが最終ゲート、検証、push、MR 作成を承認した。規模の検査がもう一度止め（約 9 万行）、承認の後、全量レビューの検証ワークフローが PASS した。その後の小さな是正は、差分だけを見る検証ワークフローで再検証している。

⑤ 締めと引き継ぎ（10-04 14:16 〜 15:34）

文書の誤りと MR の説明をオーナーが指摘し、直した。MR がマージされた 2 分後、オーナーは「コンテキストが一杯なので、clear して resume で再開できるようにする」よう指示し、セッションは終わった。次のセッションは、5 分後に始まっている。

🧱 長時間ループを支えた 6 つの仕組み

1. 状態を、会話ではなく文書に持つ

49 時間の間に、コンテキストの圧縮が 8 回起きた。そのうち 4 回は、会話が一杯になって要約から継続している。それでも作業が続いたのは、進捗がタスクリストとステアリング文書にあり、会話の記憶に頼っていないからだ。最後の「clear して resume」も、同じ仕組みの上にある。

ただし、弱点も出た。オーナーは、タスクリストの更新漏れを続けて 3 回指摘している。文書が状態の正本である以上、更新が遅れると、再開の起点がずれる。

2. 止まるべき所では、起動前に止まる

どれも、検証のトークンを使う前に止まっている。第 16 回の原則「承認はクレジットを使う前に置く」が、そのまま動いた形である。

3. Codex の run を小さく切る

実装 run は 93 本あり、10 月 3 日以降の 32 本は 45 分の打ち切りつきで起動されている。1 つの巨大な run にまとめず、小さな run を並べる。この運用は cts-ec が先に始めたもので、ハーネスは v0.39.0 で「編集するファイルの宣言を必須にし、多すぎれば起動前に止める」検査として共通化した。

4. 完了通知を主に、起床を予備に

サブエージェントの完了は、通知で Lead に届く。/loop による起床は、通知が届かなかった場合の保険として置かれた。間隔は 10 〜 30 分、中央値は 20 分である。短い間隔で状態を見に行き続ける使い方ではない。

5. モデルを難しさで切り替える

長い時間を回すのは Sonnet で、難しい判断のときだけ上のモデルに上げている。切り替えたのは人である。

6. 差分だけを検証する

PASS の後の小さな是正には、前回 PASS した時点からの差分だけをレビューする、軽い検証ワークフローを使った。全量レビューの 3 本が 9.5 万 〜 14 万出力トークンだったのに対し、差分レビューは約 2.8 万だった。第 16 回で「PASS 後の再 run が消費の 54% を占める」と測り、v0.33.0 で入れた仕組みが、数字で効いている。

🧑‍✈️ 人は何をしていたか — 40 回の発言の内訳

49 時間で、オーナーの発言は 40 回あった。内容で分類すると、次のようになる。

設計どおりの介入、つまり方針、承認、仕様の回答は、合わせて 17 回である。残りのうち 21 回、全体の半分は、ループが自力では解けなかったか、間違えた場面 に使われていた。

• CI の失敗（11 回）: パイプラインの失敗が続き、原因の切り分けが進まなかった。人が実行環境の側を調べて、解決している。コードの外側にある問題は、ループの手に余った
• 訂正（10 回）: 最も重かったのは、外部サービスへの書き込みを伴う実機確認を、計画に入れていたことである。オーナーが止め、ステアリングを通して禁止した。ほかに、文書の事実誤認、タスクリストの更新漏れ、MR の説明の不備があった

無人の区間が 15 時間あった、というのは事実である。同時に、人が戻った後の 8 時間に介入が集中した、というのも事実である。ループは人の判断を置き換えていない。人が判断する場面を、まとめている。

📏 Anthropic の基準で再採点する

第 15 回から、Anthropic の公式ブログ「Loop engineering: Getting started with loops」の 12 項目で採点を続けてきた。前回（第 16 回の 9 月 26 日の追記）の集計は ✅ 10、🔌 1、🧭 1 だった。✅ は機械で成立、🔌 は配線済みで未起動、🧭 は設計判断が要る、である。

集計は ✅ 11、🧭 1 になった。🔌 は無くなった。

11 番の ✅ には注記が要る。動いたのは、1 つのセッションの中で完了を待つための /loop である。月次の確認や四半期の棚卸しのような定期作業を、/schedule に載せて人のいない時間に回す使い方は、まだ始まっていない。基準の前半「time-based ループで回す」は実績が付いたが、「定期作業を」の部分は道半ばである。

1 番の 🧭 にも注記が要る。残っているのは実装ではなく、裁定である。検証が止まった後の再試行を無人にするのか、人の承認に置き続けるのか。Anthropic の原典は、人が各ターンを指揮する手動のループも型の 1 つに数え、すべての作業に複雑なループが要るわけではないとしている。だから、どちらに決めても基準から外れない。決めた時点で、1 番は ✅ になる。その裁定は、次回に扱う。

🔭 v1.0.0 までに残っているもの

1. 1 番の 🧭 を決める。 無人で再試行する型を作るのか、作らないと決めるのか。どちらも決定であり、どちらに決めても Anthropic の基準から外れない。決めれば ✅ になる。今回の記録は、「人の承認を起動前に置く」形で、49 時間のセッションが成り立つことを示した
2. v0.39 を利用側に配って、発火を測る。 このセッションは v0.38.0 の上で走った。編集ファイルの宣言と内側の打ち切りは、配布後の実測がまだ無い。当社の方針は「発火で測る」である
3. 人の訂正を減らす。 訂正と指摘の 10 回のうち、タスクリストの更新漏れのように機械で検出できるものは、検査に移す
4. 定期作業を /schedule に載せる。 11 番の注記を外すための残りである

v1.0.0 の条件そのものと、その達成の報告は、次回に書く。

🧾 まとめ

• cts-ec で、1 本の開発セッションが 49 時間続いた。実際に動いていたのは約 37 時間で、Codex の実装 93 本、サブエージェント 93 回、検証 4 本 PASS、MR 2 本マージまで進んだ
• 続いた理由は、状態を文書に持つこと、起動前に止まること、run を小さく切ること、完了通知と予備の起床、モデルの切り替え、差分だけの検証の 6 つである
• コンテキストの圧縮は 8 回起きたが、作業は続いた。最後も clear と resume で次のセッションに引き継いだ
• オーナーの発言は 40 回。その半分は、CI の失敗対応と訂正だった。ループは人の判断を置き換えておらず、判断する場面をまとめている
• Anthropic の基準での集計は ✅ 11、🧭 1。/loop が実際に回り、未起動の項目は無くなった。残る 🧭 は実装ではなく裁定で、決めれば ✅ になる

いよいよ、完成が近い。 残る 🧭 は裁定 1 つ、測り残しは配布後の発火である。「完成」の 1 語は、v1.0.0 の回まで取っておく。

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

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

1. 総論 — マルチ LLM の 2 系統と見取り図
2. 裏取り編 — +18.1pt 論文の検証
3. 設計編 — finder/verifier 分業と逆順禁止
4. TDD×ハーネス編 — テスト保護と三層ゲート
5. 実装編 — Claude Code の中から Codex を動かす
6. モデル戦略編 — ティア割当と「買うか組むか」

本編終章

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

運用実録

8. CI テスト 29 分 → 5.6 分 — 検証エンジンの平時運用
9. GPT-5.6 sol 切替 — もう一つのデフォルト追従
10. 遊休 90% の枠に仕事を振る — Codex 上流調査と verifier バッチ化
11. ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布
12. 69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角

現在地と事業展開

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

関連記事

• 月 5 万円の定額で 24 時間ループを回す — このセッションを回した費用の側。定額の上限、2 つの枠、モデルの使い分け
• 3 日で撤回した停止条件 — 起動前の承認と、差分だけの検証の出所
• CI テスト 29 分 → 5.6 分 — 平時の 1 タスクが検証エンジンの上を流れる実録。本稿はその長時間版にあたる

関連用語

• ループエンジニアリング — エージェントを回すループそのものを設計する手法
• ハーネスエンジニアリング — ループが繰り返し起動する対象となる制御レイヤー
• コンテキストエンジニアリング — 圧縮と継続の前提となる、コンテキストの設計

参考リンク（2026-10-04 時点で確認）

• Loop engineering: Getting started with loops（Anthropic 公式ブログ、2026-06-30） — 再採点の基準の出典
• Keep Claude working toward a goal（Claude Code 公式ドキュメント） — /goal と /loop の違い