■ 1. 主張の背景
- AIコーディングにおけるパラダイムシフトとして「エージェントに直接プロンプトを入力することをやめ、代わりにエージェントへのプロンプトを自動化するループを設計すべき」という主張が広まっている
- Peter Steinberger: 「コーディングエージェントにプロンプトを入力するのではなく、エージェントにプロンプトを与えるループを設計すべきだ」
- Claude Codeの作者であるBoris Cherny: 「もはやClaudeにプロンプトを入力しない。ループが動いており、そのループがClaudeにプロンプトを送っている。自分の仕事はループを書くことだ」
- プロンプトエンジニアリングが不要になるのではなく、作業レベルがコードを書くことからコードを書くシステムを書くことへと一段階上昇する
■ 2. ループとは何か
- ループとは以下の4つの処理を行う小さなプログラム:
- コーディングエージェントへのプロンプト送信
- エージェントの出力の読み取り
- 完了判定
- 未完了の場合、エラーや次のステップを含む再プロンプト
- 開発者はループの中でプロンプトを入力し続けるのではなく、ループそのものを記述し、モデルはループが呼び出すサブルーチンとなる
- 基本的な形状: 目標設定 → 実行 → チェック → エラーフィードバック → チェックが通るまで繰り返す
■ 3. 「ループ」の5つの意味
- ReAct（2022年）: 最初の研究パターン。思考・行動・観察を繰り返す
- AutoGPT（2023年）: 自己プロンプト型のゴールループ。停止条件の欠如で有名
- ralph loop: 反復間で意図的にコンテキストをリセットし、エージェントが自身の履歴に埋もれないようにする
- /loop と /goal: ケイデンスと完了条件がエージェントに組み込まれ、ターン間でステートを保持する
- オーケストレーション: 1人の作者が多数のエージェントをファンアウトし、GitHub・Slack・チャットを読み取り次に何を作るかを判断する
■ 4. ループを構成する6つの要素
- トリガー: スケジュール、Webhook、ファイル変更、PRラベルなど、手動操作なしにループを開始する仕組み（これがループを「手動の繰り返し実行」と区別する）
- 隔離: エージェントごとのプライベートなgit worktreeにより、並行実行する複数エージェントがファイルを上書きし合うことを防ぐ
- 書き出されたコンテキスト: 規約・ビルド手順・プロジェクト固有のルールを毎回エージェントが読み取れる場所に保持する（省略するとループは毎回ゼロからプロジェクトを推測する）
- ツールへのアクセス: イシュートラッカー・CI・データベース・チャットへのコネクタにより、ループがPRを作成し、チケットを紐付け、結果を投稿できるようになる
- 第2エージェントによる検証: 出力を評価する別のワーカーを、出力を生成したエージェントから独立させる（モデルが自身の成果物をレビューするとほぼすべてを合格とするため）
- ディスク上のステート: 会話外に存在するMarkdownファイル・ボード・キューなど。モデルはランの間に忘れるが、ファイルは忘れない
■ 5. 具体例: PRベビーシッター
- 動作概要:
- トリガー: 15分ごと
- スコープ:
agent-watchラベルが付いたオープンPR- アクション: CIが決定論的な理由でRedならば1回の修正を試みる。mainが移動していたら1回リベースする
- 予算: PRあたり修正試行1回、5分、変更ファイル10件
- 停止条件: CI Greenまたは予算枯渇後、人間に通知
- 同様の構造を活用できる用途:
- CIヘルス: 30分ごとに失敗ランを署名でクラスタリングし、同一根本原因の複数RedPRをまとめて提示
- デプロイ検証: プッシュ後にエンドポイントを確認し、200レスポンスと期待コンテンツを確認してユーザーより先に異常を検出
- フィードバッククラスタリング: 30分ごとにコメントを収集し、テーマでグループ化して各クラスタを担当ファイルやドキュメントにマッピング
■ 6. Claude Codeにおける /goal の活用
/goalはセッション内コマンドとして動作し、検証可能な完了状態を設定するとその状態が真になるまでターンを繰り返す- 優れた /goal の仕様に必要な4要素:
- 求める最終状態
- 達成を証明する根拠
- エージェントが破ってはならない制約
- 許容される作業量の予算
- 動作フロー:
- 完了条件を設定（例:
/goal tests in test/auth pass）- エージェントが1ターン作業（編集・テスト実行・結果提示）
- 評価者（高速モデル）がトランスクリプトを読み「達成」か「未達」かを判定
- 未達なら次のターン、達成ならゴールがクリアされ実行停止
- 信頼性を高める制御:
- チェックを測定可能にする（テスト結果・終了コード・ファイル数など。「良くする」はゴールにならない）
- 実行を制限する（「20ターン後に停止」などを付加する）
- autoモードと組み合わせて無人実行し、早期終了には
/goal clearを使用- 評価者はコーダーと異なるモデルを使用可能であり、モデル選択がアーキテクチャ上の意思決定となる（計画・実行・評価・ビジョンレビューを異なるモデルに割り当て可能）
- 適用場面: APIマイグレーション、リファクタリング、イシューバックログ処理、evalループ
■ 7. 複数ループの無人実行
- Chernyが提示するOpusを自律的に何時間も動かすための5ステップ:
- 権限を自動承認し、ツール呼び出しのたびに停止しないようにする
- 動的ワークフロー（Ultracodeをプロンプトに投入）で多数のエージェントへのファンアウトを実現する
/goalまたは/loopでセッションを継続させる- クラウド（デスクトップまたはモバイルアプリ）で実行し、ラップトップを閉じてもセッションを維持する
- エンドツーエンドの自己検証手段を与える（Web向けにChromeのClaude、モバイル向けにシミュレータMCP、バックエンド向けにライブサーバー）
■ 8. オーケストレーション製品としてのcrabfleet
- Peter Steinbergerが開発した「crabfleet」（OpenClawプロジェクト）はループをプロダクトとしてパッケージ化したもの
- 主な特徴:
- ボード上のカード: タスクがプロンプト・GitHubイシュー・PRから作成され、todo→実行中→人間レビュー→完了と移動する
- 耐久性のある実行: ハートビートつきの追跡実行により、ラップトップを閉じても継続する
- エージェントがエージェントを生成: サンドボックス内で子セッション起動・メッセージ送信・トランスクリプト読み取り・サマリー更新が可能
- ループがインフラとして成熟した結果、キュー・耐久実行・ファンアウト・人間レビューゲートが手作業スクリプトではなく設定項目となっている
■ 9. コストの考え方
- ループ内ではコストはトークン数ではなくループの反復回数に依存する
- 最適化すべき指標:
- 反復回数が予算の単位（同じモデルで2倍ループするモデルを安いと判断しない。タスクあたりのコストで測定する）
- 検証器の精度が最も重要（緩い完了チェックは、壊れた成果物で早期終了するか、完了済み作業を繰り返すかのどちらかで両方が反復全体を無駄にする）
- 早期失敗がコスト管理（連続失敗の上限がないループは最終的にアカウントを枯渇させる。停止条件はコードベースと同様に請求を守る）
■ 10. ループを使うべきでない場面
- 1回限りの編集: 1パスで完了できるならループはオーバーヘッドにすぎない
- スコープ未定義または探索的な作業: 「なぜユーザーが離脱しているか調べる」には合格条件がなくループが収束しない
- 安価な自動チェックが存在しない作業: 唯一の検証者が人間の目であれば、人間は依然としてループの中にいる（先にチェックを構築するか手作業で対応する）
■ 11. 失敗モードとリスク
- 検証負担が人間に残る: ループはレビューできる速度より速くコードを書くため、差分を読むのをやめれば作業を排除したのではなく先送りしただけになる
- 理解ギャップの拡大: 自分が書いていないコードを吸収できる速度より速く出荷すると自身のシステムモデルが劣化し、次のインシデント時にその負債が顕在化する
- 緩いチェックによるサイレントドリフト: 弱い検証器は毎反復ごとに「テスト通過だが間違っている」成果物を通過させ、ループが生産的に見えながら問題を拡大する
- これらはループへの反論ではなく、ループを設計するエンジニアの重要性がより高まる理由である
■ 12. 自分のループを構築する手順
- 繰り返し可能なタスクを1つ選ぶ（PRのベビーシッティング・CI修正・デプロイ検証など、ルーティン作業から始める）
- スコープを絞る（「バグを修正する」ではなく「billing webhookのバリデーションを修正する。触れるのはapp/api/billingとlib/billingのみ」とする）
- 予算と停止条件を設定する（最大試行回数・最大実行時間・最大ファイル数・最大費用・連続失敗の上限。無人実行中のループは無人でミスも犯す）
- 独立した検証器を追加する（コードを書いたエージェントは完了の最悪の判定者であるため、別のサブエージェントが成果物を評価する）
- ケイデンスで実行する（インターバルに /loop、スケジュールにcron、ライフサイクルポイントにフック、ラップトップを閉じても継続するためにGitHub Actions）
- メモリをディスクに保持する（モデルはランの間に忘れるため、ステートはコンテキストウィンドウではなくMarkdownまたはボードに保存する）