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