🔧 私のLoop Engineering運用ガイド

はじめての方は、まず「やさしい入口」(start.html) から読むのがおすすめです(3-5分で概要を掴めます)。

概念を学ぶ — ではなく、毎日どう回すか

姉妹ページ『ループエンジニアリング教科書』が「ループエンジニアリングとは何か」を学ぶ概念中心の教科書なのに対し、本ページは自分のClaude Code環境で実際に毎日どう運用するかの具体手順を整理した私用ガイド。Daily Triage朝6:07にAIがバックログ等から当日タスク候補を自動生成する仕組みメタループ（Loop Engineering・Phase1〜3.1 完了済の現行システム）の、朝の自動発火から人間承認・自律実行連鎖・停止までを時系列で追う。

原本: SSOT 00_SYSTEM/共通ルール/自律開発ループ.md（139行）／ Phase4（OSS Issue自律ループ復活）完了後の2026-06-29整理

📖 概念教科書（ループエンジニアリングとは） ⚡ Claude Code Guide（機能詳細） 📋 タスク経緯ログ（auto-loop の実行記録） 📚 ガイド集

全体像

毎朝 Daily Triage がバックログ・handoff前回セッションの文脈を次に渡す引き継ぎメモ・🟢進行中タスクからその日のタスク候補を自動生成し、人間が承認すると、実装→検証の連鎖が自律的に回る仕組み。

Daily Triage（朝6:07自動）→ today-tasks.md 生成
  ↓
人間承認（approve.py）→ state.json 登録・最初のタスク起動
  ↓
自律実行連鎖: run-task.sh（実装+検証）→ next_issue.py（Stop hook・次タスク起動）
  ↓
全完了 or blocked で停止通知

Daily Triage（朝6:07自動）バックログ＋手付タスクをAIが集めてリスト化

↓

人間承認（approve.py）どれをやるか人間が選ぶ・唯一の関与ポイント

↓

自律実行連鎖run-task.sh（実装+検証）→ next_issue.py が OKで次へ/NGで停止

なぜこのループを組む？ 人間が毎朝バックログを読み直しタスクを選ぶのは時間がかかる。AIに「候補選び」と「実装・検証の連鎖」を任せ、人間は「どれをやるか」の承認だけを出せばよくなる。これがLoop Engineeringの核心。

第1部 1日の流れ

daily-triage.sh --notify-discord が cron（renew-crons.shcronジョブを再登録して永続化する（durableジョブは7日で期限切れするため定期更新）経由で永続化）で発火する。人間は何もしなくてよい。

何が起きるか（4ステップで順に）

材料集め: バックログ未完了タスクの一覧表。SSOTの「バックログ.md」が正典（タスク一覧）＋ handoff（前回の引き継ぎ）＋ 🟢進行中タスクactive-sessions.mdで他セッションが占有中のタスク。重複着手を防ぐため候補から除外（他セッション作業中）を集める
優先度判定: Claude（GLM）が「今日やるべき順」を判定し、~/.claude/state/today-tasks.md に書き出す
自動/手動の振り分け: 各タスクに markertoday-tasks.mdで自動実行可か手動かを区別する印（印）を付ける − (repo: 名前) なら自動実行可・(手動) なら人間対応
通知: Discord webhookDiscordの特定チャンネルにメッセージを自動送信する仕組み。通知先のURL で結果を送る（未設定なら警告だけ）

SessionStart hookセッション開始時に発火する仕掛け。handoff読込等を自動化（load-obsidian-log.shSessionStart hook本体。セッション開始時にhandoffとtoday-tasks.mdを読み込む）が today-tasks.md当日のタスク候補リスト（優先度順・marker付き）。daily-triage.sh が生成を表示する。人間が候補を確認するだけ。

python3 approve.py で実行するタスクを番号選択する。ここが唯一の人間の関与ポイント（承認ゲートAIが勝手に実行しないよう人間がGOを出す唯一の関所）。

承認ゲートの挙動

(手動) marker 付き・repo が実在しないタスクは自動除外
実在 repo のみキューへ（Phase3.1: per-task repoタスクごとに対象リポジトリを紐付ける方式。多repo混在キューに対応で多 repo 混在キューに対応）
state.jsonループの進行状態（active/current/pending/completed/blocked）を記録するファイル。停止再開の要に pending / current を登録
最初のタスクが run-task.sh実装＋検証を別プロセスで回す実行スクリプト。current.repoを読んで対象repoで実行でバックグラウンド起動

人間が承認した後は、完全に自律的に回る。

run-task.sh（実装 + 検証）

実装 claude（git commit まで）→ 検証 claude（別プロセス・ch8 分離）。検証結果を verify-result.txt検証プロセスが書き出す OK/NG の判定結果ファイル。next_issue.py が読んで次タスク起動を制御に OK / NG で書き出す。

Stop hookClaude終了時に発火する仕掛け。ここで次タスクを起動する → next_issue.py（次タスク起動）

verify-result.txt検証プロセスが書き出す OK/NG の判定結果ファイル。next_issue.py が読んで次タスク起動を制御を判定し、次タスクへ遷移させる。

検証結果	遷移
`OK`	`completed` に記録・pending から次タスクを current に昇格して起動
`NG`	`blocked` に記録・停止（Phase3 では即停止・Phase4-B でリトライ厳密化予定だが実測0失敗で YAGNI 後回し）

全タスク完了 → Windows トースト「dev-cycle 完了」
検証 NG 等 → blocked・active: false で停止通知（人間エスカレーション）

第2部アーキテクチャ・コンポーネント

なぜ状態を state.jsonループの進行状態（実行中/待機/完了/blockers）を記録するファイル。停止再開の要に記録する？ ループは複数プロセス（実装・検証・次タスク起動）にまたがる。メモリだけでなくファイルに「今どのタスク・待機群・完了/blockers」を書き込んでおくことで、停止しても再開でき、次タスク制御が状態を読むだけで済む。

全コンポーネントは ~/projects/claude-config/scripts/auto-dev/ 配下。

コンポーネント	役割
`daily-triage.sh`	Triage 発火エンジン（Claude判定呼出・today-tasks.md 生成・Discord通知）
`daily_triage.py`	バックログ/handoff収集・LLM判定・repo付与（`validate_repo()` 実在チェック二重防御）
`approve.py`	人間承認ゲート・`select_queueable()` で manual除外・state.json 登録
`run-task.sh`	実装 + 検証（別プロセス）・`current.repo` を読んで対象 repo で実行
`next_issue.py`	Stop hook 発火・`verify-result.txt` 判定・completed/blocked 遷移・次タスク起動

キー	意味
`active`	ループ生存フラグ（false で即終了）
`current`	実行中タスク（`repo` は per-task・真実のソース）
`pending`	待機中タスク群（多 repo 混在可）
`completed` / `blocked`	各タスクの `repo` を記録

Phase3.1 で top-level repo_path は廃止。per-task repo が真実。

第3部運用

# 手動で Daily Triage 実行（通知なし）
bash ~/projects/claude-config/scripts/auto-dev/daily-triage.sh

# 承認（候補選択 → state.json 登録・最初のタスク起動）
python3 ~/projects/claude-config/scripts/auto-dev/approve.py

# state.json 確認
cat ~/.claude/state/state.json

# テスト（claude-config/scripts/auto-dev で）
python3 -m pytest -q

症状	原因・対処
承認時に today-tasks.md が変わる	別セッションが daily-triage.sh を実行した可能性。承認直前に再読 or タイムスタンプ確認（Phase3.1 残課題・根本対応は別タスク）
検証 NG で停止	`blocked` を確認・手動で修正後、`active: true` + pending 追加で再開
cron 期限切れ	durable ジョブは7日で自動削除。`renew-crons.sh` で再登録

Loop Engineering 導入前に使っていた方式。Phase4（OSS Issue自律ループ復活）で別途再設計済み。

方式: CronCreate（durable・毎時）で gh issue list のオープンIssueを自律実装（ブランチ作成→実装→テスト→PR）
現状: start.sh --auto 廃止 → Phase4 で fetch_issues.py/set-mode.sh/auto-loop-config.yaml + ハイブリッド承認ゲート（manual/auto）・単一 auto-loop ラベル・max3 安全装置で復活（60テスト passed）

📎 詳細は概念教科書の第3部（自分の環境マップ）を参照

第4部外部LLMレビューを運用ループに組み込む

設計・監査など作者バイアスが乗る成果物は、作った本人（LLM含む）がレビューしても死角が残る。設計者は自分の前提の内側では完結した論理を組めてしまうため、モデルの能力を上げても自己レビューではこの穴は消えにくい。2026-07-05〜06に最高級モデルの監査・設計成果物へ別LLMのレビューを3回（計15指摘）実施し、採否を全件記録した実測がこの根拠になっている。

レビュー指摘の内訳	件数
致命的な穴の検出（設計テーマ自体の見落とし）	1
優先度の再重み付け・有用な盲点追加	5
ホスト側の改善を誘発（触媒）	2
妥当性の確認（安心材料）	4
誤指摘（却下）	3

運用ルールは3つ。

革新は期待しない — レビューから新アーキテクチャは出ない。出るのは「死角の消し込み」。それで十分黒字（採用率6割・致命穴1件/回のオーダー）
価値の源泉は賢さでなく視点の独立性 — レビュアーが作成者より賢い必要はない
採否判定は必ず文脈を持つ側がやる — 誤指摘（2割）は環境文脈の不足から生じる。鵜呑みにすると逆に品質が下がる。環境固有の制約（無人cron・2層構造等）はレビュー依頼文に明示する

📎 全体像は Claude Code ガイド第18章「ループシステム」参照