ループ設計＋レビュー は何をしますか？
前提. LLMはフィードフォワードシステムです。プロンプトを入力→トークンを出力し、ターンをまたいで「目標に向かって進む」組み込みの仕組みはありません。LLMをあたかも目標指向システムのように振る舞わせるには、その周りにフィードバックループを巻く必要があります。このスキルは、そのループを正しく記述し、暴走しないようにレビューするのに役立ちます。
使用する／しない場合
使用する場合:
- 繰り返し行うタスクを、何度も実行するエージェントに任せたい（作成→テスト、テスト→修正、修正→検証…）。
- すでにループがあり、それがスピンしたり、ごまかしたり、誤った答えを最後まで実行してしまうのが心配な場合。
使用しない場合:
- 1回限りのタスク→単に実行するだけ。ループで包む必要はありません。
- 単純なタイマー／ポーリング→
/loopを使う。設計は不要。 - ループアーキテクチャをどのように配線するか（パイプライン→DAG、長期実行のリカバリ）→それはメカニズムレイヤーです。
autonomous-loops/continuous-agent-loopを参照。このスキルは「目標が正しいか、暴走しないか」のみを扱い、メカニズムを再説明しません。
レッドラインの前提：2レベルのフィードバック
| レベル | 誰が所有するか | 何をするか |
|---|---|---|
| 実行（低） | 機械／エージェント | 「リテラルな目標からどれだけ離れているか」を測定し、ゼロにする。機械はここで強い。 |
| 判断（高） | 人間 | 「この目標自体が正しいか、変更すべきか、停止すべきか」を決定する。機械は自分のループの外に出て目標を疑問視することはできない。 |
サーモスタットは「26°Cからどれだけ離れているか」をフィードバックできますが、あなたが熱を出していて28°Cにしたい場合、26が正しい目標かどうかを判断できません。ただひたすら26を目指すだけです。「今日は何度に設定するか」は常に人間の判断です。 判断／承認／最後のスイッチを機械に委ねる＝高レベルのフィードバックを取り除くこと＝誰も疑問を持たない目標に向かって、機械は速く、激しく全力疾走する→誤った出力。
アクション1 — ループを書く（5ステップ）
ステップ0 · まず減算：そもそも構築すべきか？（4条件ゲート、1つでも外れたら拒否）
① タスクが毎週以上に繰り返される ② 検証が自動化可能 ③ トークンバジェットが許容できる ④ エージェントが実際に実行して結果を見るツールを持っている
1つでも外れる→ループを構築しない；手動または別の方法で行う。
ほとんどの人が止まるのは「ループを書けるか」ではなく、「自分のリポジトリがループに値するか」です。ループに値するリポジトリには、調整ベースライン（ゴールデンサンプル／上流合計）＋テスト＋lintガードがあります。ループに値しないリポジトリは、ループによってエラーが増幅されるだけです。
ステップ1 · 機械判定可能な目標を定義する（難しい部分—ループの成否はここにかかっている）
ループ全体は比較器の「もう終わったか？」に依存します。比較器が機能するには、終了条件が機械でyes/no判定可能でなければなりません。
- 悪い例：曖昧（「良くする」「もっとシャープに書く」）→比較器が判断できない→決して通過しない（スタックしてリトライし続ける）か、推測する（ランダムに通過/ブロック）。
- 良い例：判定可能（「96個すべての単体テストが成功し、かつ変更リストが作成される」、「モジュール02のフィールドが入力され、pytestが成功し、ビジネスロジックが変更されていない」）→一度のチェックで決着する。ループはクリーンに収束する。
5点目標フレームワーク:
- 完了基準が機械検証可能であること。
- 境界条件が完了基準と共に定義されている（「やってはいけないこと」）— Goodhart対策。境界がない＝ごまかす許可証。
- 失敗時のフォールバックがある— リトライ上限N＋超過時に人間にエスカレーション。
- 目標が階層化されている。
- 完了基準にはアサーションよりも調整（reconciliation）を優先する— 自身のアサーションよりも先に、外部事実（ゴールデンサンプル／上流合計／財務照合／プラットフォームバックオフィス数値）にアンカーする。「すべてのテストが成功」は操作可能（アサートを緩める、モックを偽装する、例外を飲み込む）。「リファレンスとのdiff < 0.01」は操作不可能。
セルフチェック: ドメインを知らない人に目標を読んで聞かせる。その人は1つのコマンドを実行して完了したかどうかを言えるか？言えないなら、十分に判定可能ではありません。やり直し。
ステップ2 · ループタイプを選ぶ
| タスク | ループタイプ（サイバネティクス） | 停止方法 |
|---|---|---|
| 明確な「完了」テストがある（完了まで書き続ける／画像バッチ処理など） | サーボ（/goalスタイルの閉ループ） | 目標到達で停止 |
| エンドポイントがなく、状態を維持し続ける必要がある（在庫アラート／定期ヘルスチェック） | レギュレータ（/loopスタイルのサーモスタット） | 決して停止しない；変化があったときだけ動作（不感帯がノイズを抑制） |
| 周期的にサンプリングし、条件で停止する（PRがCI成功するまで監視） | 終了条件付きレギュレータ | 終了条件が成立したら停止 |
| 「何かを時間通りに確実に行う」必要がある | 上記を/scheduleでラップ | cronで起動 |
経験則：明確な「完了」テスト→サーボ；維持が必須でエンドポイントなし→レギュレータ；「時間通りに」→レギュレータをスケジュールでラップ。
ステップ3 · スケルトンを選ぶ
メンテナンス型（既存のものを世話する）→ ドキュメント駆動ディスパッチ。 ループは「タイマーで固定のチェックを実行する」ではなく、「タイマーでドキュメントを読み、ドキュメントが変更された場合にのみディスパッチする」 です。ドキュメントはタスクキュー＋ステートマシン＋人間インターフェースです。 3つの規律：① 問題カラムは人間のみ書き込み、結果カラムはループのみ書き込み、状態は一方向に進み決してロールバックしない；② 終了コードは最終的（スクリプトがexit 1と言ったら、スクリプトが勝つ）；③ 状態は「検証待ち」までしか進まない— 「完了」セルは人間だけが反転させる。 ループはワーカーであり、承認担当者ではない。
グリーンフィールド型（スクラッチから構築）→ 計画／構築／判断、3つの役割。
| 役割 | 行うこと | キー |
|---|---|---|
| 計画 | 目標を仕様＋判定可能な受入条件に分解 | 受入条件はスクリプトで判断可能でなければならない |
| 構築 | 仕様に従って書く | 受入条件を変更してはならない |
| 判断 | 受入を独立して実行；合格→停止、不合格→不合格理由を構築に返す | 独立＋決定論的 |
3つの鉄則（すべて判断にかけている）：① 判断は独立していなければならない— 構築と同じエージェントではない（自分の宿題を自分で採点すると常に点数が膨らむ）；② 決定論的ルール— pytest／調整diff／型チェック／diffであり、「良さそうに見える」では決してない；③ 構築は通過するために受入条件を編集してはならない。3回リトライ失敗→人間にエスカレーション。
ステップ4 · ダンピングを追加する（振動／暴走対策）
リトライ上限、ハードストップ、人間による最後のスイッチ操作＝ダンピング。ダンピングのない負のフィードバックは振動する（ラルフ・ウィガム・ループ：その場でスピンし、トークンを消費）。
ステップ5 · 3段階で展開する（初日から完全自動化しない）
① 一度手動で実行する（「判定がどのように決定するか」を正確に述べることを強制される）→ ② スキル／Claude Codeサブエージェントに固める（メインのClaudeがループし、計画/構築/判断をディスパッチ）→ ③ cronで完全自動化する。
アクション2 — ループをレビューする（チェックリスト＝5つの障害モード）
ループを各行に当てはめてください。1つでも当てはまる＝このループは誤作動する；差し戻す。 これら5つはネガティブな経験則（注意点）であり、ポジティブなルールよりも価値があります。
| # | 障害モード（どのように壊れるか） | レビュー質問（当てはまる＝レッド） | 抗体 |
|---|---|---|---|
| 1 | 目標が正しい美辞麗句→スピンし、金を燃やす | 終了条件は機械でyes/no判断できるか？それとも「うまく管理する／良くする」のようなものか？ | 判定可能な結果条件に置き換える（アクション1・ステップ1） |
| 2 | 「検証」が「良さそうか確認」と書かれている→エージェントは自信を持って「問題ない」と言い、停止する | 判断者が被告人自身か？検証は「良さそうに見える」か決定論的ルールに依存しているか？ | 調整＋終了コードルール＋独立した判断者 |
| 3 | （最悪）「すべてのテストが通過」だけをゲートにしている→エージェントがテストを削除する | 境界（「やってはいけないこと」）はあるか？それとも完了基準だけか？ | 完了基準**＋境界**を一緒に（Goodhart抗体） |
| 4 | エージェントが途中で質問することを前提にしている→質問しない。誤った答えを最後まで実行する | 「実行時のみ明確化」ポイントはあるか？ | すべての明確化を事前に完了させる；起動前に一度決着させる |
| 5 | 肥大化したCLAUDE.md＋古いメモリ→ループが速く回るほど、エラーが増える | 依存しているドキュメント／メモリは新鮮か？誰がそれらを維持しているか？ | 階層化メモリ＋定期的なlint |
さらに3つのレッドライン（1つでも違反＝自動化禁止）:
- 判断は人間が保持すること。 承認／「完了」セルは人間が反転させる。ループは承認担当者ではない。
- 責任は移譲しない。 失敗を許容できないもの（間違ったPRをマージする／間違ったものを公開する／資金を誤配分する）→ 自動的にその権限を渡してはいけない。
- 直感に反する警告。 ループが「自己改善／自己ルール書き換え」であればあるほど、必要な人間のレビューは厳格になる（ルールを何に書き換えたか確認するため）— 緩くはならない。機械は事後の介入には速すぎるため、人間の判断は行動の前（ハードゲート）になければならず、事後パッチとしてではない。
実例 — 「夜間グリーンキーパー」ループのレビュー
毎晩実行され、失敗しているテストを修正するループがあるとします。
- ナイーブな目標: 「すべてのテストを成功させる。」→ ステップ1のセルフチェックに失敗：これは障害モード#3の餌です。
- 判定可能な目標（修正後）: 「すべてのテストが成功かつテストファイルの削除や弱体化がないかつカバレッジが低下していないかつ変更リストが作成されている。」境界が完了基準と共に定義されました。
- タイプ: リトライ上限3のサーボ（ステップ2＋ステップ4）。
- スケルトン: 計画/構築/判断 — 判断者は独立してCIを実行するものであり、修正エージェント自身ではない（ステップ3）。
レビューチェックリストを実行すると、ナイーブなバージョンが見逃していたものをキャッチします：
- #3 該当 → ナイーブな「全テスト通過」では、エージェントが失敗するテストを削除して「成功」することが可能。境界「テストファイルの削除/弱体化なし」で修正。
- #2 該当 → 修正エージェントが自分の修正を自分で判断すると、自分を通過させてしまう。「判断者＝独立CI、決定論的」で修正。
- #4 該当 → 修正が曖昧な場合、エージェントは午前2時に止まって質問しない。推測でコミットする。事前明確化で修正：曖昧な修正は人間に任せられ、推測はされない。
- レッドライン → ループはPRを作成するが自動マージはしない。人間が最後のスイッチを操作する（責任は移譲されない）。
ナイーブなループとレビュー済みループの違いは、4行の制約だけです。そしてそれが、「削除されたテストスイートで目を覚ます」か「クリーンなPRで目を覚ます」かの違いです。
一行まとめ
ループを書く上で難しいのは「ループが書けるか」ではなく、機械が調整できる目標を定義することです。判定可能で、境界があり、調整ベースであること。制御器は決定論的かつ外部でなければならず、判断と基準は人間が保持すること。システムはエントロピーへと向かうので、維持すること。 ループは、すでに考え抜いた人にのみ報酬を与える。ループがあなたの代わりに考えてくれると期待すると、それは喜んで間違った考えを、あなたと一緒に、大規模に実行する。
系統：ウィーナーの2レベルフィードバック（The Human Use of Human Beings, 1950）による判断/実行分割とレッドライン。プラン/ビルド/ジャッジパターンはAnatoliのLoops explainedとAddyのLoop Engineeringによる。 メカニズムレイヤー（ループアーキテクチャの配線方法）：
autonomous-loops/continuous-agent-loopを参照。このスキルはメカニズムを再実装しません。目標定義と暴走防止のみをカバーします。