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

ループ同じ処理の繰り返し、または一連の作業サイクルのこと。プログラミングではfor文等の繰り返し構造、開発では「計画→実装→検証」の反復サイクルを指すシステム（Loop Engineering） — 自律開発ループの全体像

Claude Code を「指示待ちの道具」から「毎日自走する開発パートナー」に変えるための仕組み全体を Loop Engineering と呼んでいる。個別の部品（cronクロン。Linuxで「毎日6時」「30分ごと」等の定期実行を予約する仕組み。予約実行の登録表（crontab）に書いて運用する・hookClaude Codeの特定のタイミング（ツール実行前後・セッション開始時等）で自動処理を差し込む仕組み。「保存前にチェック」「終了時に記録」等を機械的に強制できる・スキルClaude Codeで「特定の作業手順」をパッケージ化したもの。SKILL.mdに手順を書いておくと、対応する場面でAIがその手順を読み込んで従う。経験を再利用する仕組み）の話は各章に譲り、本章は全体像と設計思想をまとめる。

全体フロー

朝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割）は環境文脈の不足から生じる。文脈を持つ側が採否判定する前提を崩すと、逆に品質が下がる

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

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