icon: 🔁 slug: 18-loop-system card_desc: Daily Triage→人間承認→検証付き自律実行の全体像と、外部LLMレビューを組み込む理由

ループシステム（Loop Engineering） — 自律開発ループの全体像

Claude Code を「指示待ちの道具」から「毎日自走する開発パートナー」に変えるための仕組み全体を Loop Engineering と呼んでいる。個別の部品（cron・hook・スキル）の話は各章に譲り、本章は全体像と設計思想をまとめる。

全体フロー

朝6:07（自動）  Daily Triage 発火
                バックログ + 前回の引き継ぎ + 進行中タスクを収集
                → LLMが優先度判定 → today-tasks.md 生成 → Discord通知
       ↓
セッション開始   候補が自動表示される
       ↓
人間の承認      approve.py で番号選択（ここだけ手動・意図的なゲート）
       ↓
自律実行連鎖    run-task.sh: 実装用LLM → 検証用LLM（別プロセス・別コンテキスト）
                Stop hook: 検証OK → 次タスク自動起動 / NG → blocked停止・通知
       ↓
終了            全完了トースト or 人間へエスカレーション

自動と手動の境界

主要コンポーネント

現在地（2026-07-05 実測診断）

自分の環境を実測して採点した結果は 総合76/100。内訳: 候補生成90・cron基盤90・記録引き継ぎ90・実行連鎖75・失敗回復50・ドキュメント65。

得られた教訓は2つ。

1. 仕組みの完成と運用の定着は別物。 実行連鎖は実装・検証済みなのに、実運用の完走は1件だけだった。「承認して流す」という毎朝30秒の習慣が最後のピースになる。
2. ドキュメントは書いた瞬間から腐り始める。 「hookとして稼働中」と台帳に書かれた同期スクリプトが、実際は11日前からどこからも呼ばれていなかった（設定整理の際に登録が消え、それを検知するはずの検知器も同時に消えていた）。台帳は手書きせず、実登録から自動生成する方向へ移行中。

外部LLMレビューの組み込み（実証済みの知見）

ループの品質を支えるもう1つの柱が、設計・監査の成果物を別のLLMにレビューさせる運用。「最上位モデルが作った案なら不要では？」という疑問に対し、実測で答えが出た。

最高級モデルの監査・設計成果物へ外部LLMレビューを3回（計15指摘）実施した採否実績:

重要なのは次の3点。

1. 革新は来ない。死角の消し込みが来る。 新しいアーキテクチャはレビューからは出ない。出るのは「作者が自分の前提の内側で完結してしまった穴」。これはモデルの能力を上げても自己レビューでは消えにくい
2. 価値の源泉は賢さではなく視点の独立性。 レビュアーが作成者より賢い必要はない
3. 取捨する側の文脈力とセットでのみ黒字。 誤指摘（今回2割）は環境文脈の不足から生じる。文脈を持つ側が採否判定する前提を崩すと、逆に品質が下がる

正典ドキュメントの構成（迷子にならないために）

複数の文書がループを説明していると、どれが正か分からなくなる。役割を固定している: