ループエンジニアリング：Claude Codeのループ、ルーティン、ワークフロー

要約： Loop engineeringとは、エージェントに1ターンずつプロンプトを与えるのではなく、停止条件を満たすまで作業サイクルを繰り返させるための技法です。Claude Codeの開発者であるAnthropicのBoris Chernyは、自身のワークフローを率直にこう説明しています。「もうClaudeにプロンプトを与えることはありません。代わりにループを動かしています。Claudeにプロンプトを与え、何をすべきか判断するのはループです。私の仕事はループを書くことです」¹ Claude Codeには現在、さまざまな段階に対応するloop surfaceが一通り用意されています。/goal（別のモデルが条件の達成を確認するまで繰り返す）、/loop（ローカルで定期実行する）、公式Ralphプラグイン（約束が守られるまで反復する）、routines（クラウドcron）、そしてdynamic workflows（ClaudeがJavaScriptのオーケストレーショングラフを作成し、そのグラフ上で最大1,000のsubagentsを実行する）です。しかし、これらの機能のどれも本質ではありません。成否を支える中核は検証です。ループが収束するのは、テスト、grader model、pixel diff、machine checkなど、生成器の外部にあるものが「完了」と判定するときだけです。これを正しく設計すれば、ループの成果は積み重なります。設計を誤れば、非常に高価なランダムウォークに資金を投じることになります。このガイドでは、バージョン情報を明記しながらすべてのloop surfaceを解説し、Ralphパターンとその失敗モード、ループをグラフへ発展させるべきタイミング、検証の段階、コストと安全性を管理する原則、常設のエージェント群を運用する方法まで取り上げます。内容はClaude Code v2.1.234（2026年8月）時点のものです。

Loop Engineeringとは？

2年前まで、エンジニアはソースコードを手作業で書いていました。その後、人間のプロンプトをもとにエージェントがコードを書くようになりました。そして今、さらに1段上の変化が進んでいます。エージェントがエージェントにプロンプトを送り、人間は「何をプロンプトとして送るかを決めるシステム」を書くのです。Chernyは、この変化の大きさを率直にこう評価しています。「ソースコードからエージェントへの移行と同じくらい、loopsも重要で大きな一歩です。」²

彼の定義は、意外なほど平凡です。「Loopとは、基本的にClaude用としてローカルで実行されるcronジョブです。Routineも同じですが、こちらはクラウドで実行されます。」³ 一見すると奇抜に聞こえるこの手法——一晩中「数百、時には数千のエージェントを5時間、10時間、20時間稼働」させたり、⁴ Claude Codeを「6か月以上にわたり100% Claude Code自身で記述」したりすること⁴——も、少数の基本要素に分解できます。スケジュールまたは条件に応じて再実行されるプロンプト、反復の間も維持される状態、そして実行を終了させるチェックです。

Anthropicは2026年6月、この規律に名前を付けました。loopsとは「停止条件が満たされるまで、エージェントが作業サイクルを繰り返すこと」であり、「loopの出力品質は、その周囲にあるシステムによって決まる」としています。⁵ 本ガイドで扱うのは、まさにその周囲のシステムです。

2026年半ばに議論が急速に進展したため、用語の由来についても触れておきます。拡散された投稿ではChernyの造語とされることが多い「graph engineering」という用語は、AnthropicやChernyではなく、コミュニティによって生み出されました（Peter Steinbergerが7月18日に投稿した「まだloopsについて話しているのか、それとももうgraphsに移ったのか？」という発言を、Hamel Husainがさらに広めました）。⁶ 広く共有されている「当社のエンジニアの85%が……その方法こそgraph engineeringです」という引用は、第三者の投稿でしか確認できません。本ガイドの作成にあたり、彼の講演に関する一次記録（YC Startup Schoolでの対談、BloombergのOdd Lots、TechCrunchによるMeta @Scaleのレポート）を調査しましたが、該当する発言は見つからなかったため、未検証の帰属として扱ってください。彼の実際の手法がgraph状であることは確かです（オーケストレーターが実装・検証・修正を担うsubagentsを生成し、深さ5までネストします）。ただし、裏付けが取れている用語はloops、routines、workflowsであり、本ガイドでもこれらを使用します。

5分で試せるゴールデンパス

次の3つのコマンドで、単発のプロンプトからloopへ移行できます。

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud routine: runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

これらと通常のプロンプトとの違いは、表面的なものではなく構造にあります。それぞれに再実行ルール（条件、時刻、cron）があり、さらに停止ルールが必要です。本ガイドの残りの内容は、この2つのルールを信頼できるものにするための方法を扱います。

コアloopと唯一のルール

すべてのエージェントシステムは同じ内側のサイクルで動作します。AnthropicのAgent SDKドキュメントでは、これをコンテキストを収集する → アクションを実行する → 作業を検証する → 繰り返すと定式化しています。⁷ Claude Code自体のプロセスもloopです。プロンプトを評価し、ツールを呼び出し、結果を読み取り、ツール呼び出しのない応答になるまで繰り返します。⁸

Loop engineeringでは、その内側のloopをさらに外側のloopで包みます。そして、この分野の信頼できるあらゆる情報源で示されている、絶対に譲れない1つのルールを継承します。

作業を行うエージェントに、その作業を評価させてはいけません。

• Anthropicの/goalドキュメント：「完了したかどうかは、作業を行ったモデルではなく、新しいモデルが判断します。」⁹
• Anthropicのharnessデザインに関する記事：「作業を行うエージェントと、それを評価するエージェントを分離することは、この問題への強力な対策となります。」¹⁰
• 実務者が見落としがちな点について、Chernyはこう述べています。「検証はおそらく、ほとんどの人が正しく実践できていない要素のなかで、最も重要なものです。」³ ElectronからSwiftへの2週間の書き換えを指示した実例では、次のように述べています。「Macの仮想マシンでElectronアプリを実行してスクリーンショットを撮り、それをピクセル単位で確認してください。Swift版と比較し、完了するまで止めないでください。」³

理由は倫理ではなく、仕組みにあります。「完了しましたか？」と尋ねられたモデルには、自分の作業を肯定的に評価するバイアスがあります。また、自信に満ちたトランスクリプトによって、モデルが判定する終了条件を説得し、早すぎる「完了」を引き出せてしまいます。¹¹ テストスイート、コンパイラー、ピクセル差分、回答に利害を持たない新しいモデルなどによる外部検証だけが、この影響に耐えられるシグナルとなります。

自律性の階梯

Claude Codeのloopサーフェスは、「もう一度Enterキーを押す」段階から「人がいなくても動く」段階までの階梯を形成します。リングが上がるたびに自律性が増す一方、検証の負担も大きくなります。

（このリングの枠組みは、この領域を独立した立場から最も明快に整理したpardel.devの2026年7月の分類に基づきます。¹¹）

この階梯で守るべき原則は、問題を解決できる最も低いリングから始め、そのリングの検証が機能すると証明できた場合にのみ上へ進むことです。チェック可能な条件を明示できない/goalは、まだroutineとして実行できる段階にありません。

Loopサーフェスの詳細

（本ガイドでは、loopサーフェス自体を扱います。Claude Codeガイドは、設定、権限、hooks、MCPを網羅したCLIの完全な参照資料です。Agent Architectureガイドでは、harnessの各コンポーネントをどのように組み合わせるかを解説しています。loopsは、この両方の上で実行するものです。）

/goal — evaluator-optimizer loop

/goal <condition>は、条件が成立するまでClaudeに作業を続けさせます。「各ターンの終了後、小型で高速なモデルが条件の成立を確認します。成立していなければ、制御をユーザーへ戻す代わりに、Claudeが次のターンを開始します。」⁹ 評価モデル（デフォルトではHaiku）は、yes/noとその理由を返します。Claudeは、その理由を次のターンの指針として利用します。ヘッドレスでも動作し、claude -p "/goal ..."を実行すると、loopが完了するまで処理が続きます。

設計上の注意点として、条件には「コードがきれいである」のような願望ではなく、「テストに合格する」「エンドポイントが200を返す」「TypeScriptエラーが0件になる」といった観測可能なものを指定してください。検証条件が曖昧では、loopに進むべき方向を示せません。また、モデルが判定する条件は、自信に満ちたトランスクリプトによって合意へ誘導される可能性があります。そのため、機械的なチェックが存在する場合は、必ず/goalと組み合わせましょう。¹¹

v2.1.234では、loop自体を堅牢にする2つの変更が加えられました。認証の失効、クレジット残高の枯渇、コンテキストオーバーフローなど、回復不能なエラーでターンが終了した場合、goalは処理を続行できないセッションに対して有効なまま残るのではなく、通知とともに自動解除されるようになりました。また、バックグラウンドタスクを待つ状態が30分以上続いた場合、Claudeは無期限に待機せず、タスクの状況を確認します（しきい値はCLAUDE_CODE_GOAL_CHECKIN_MINUTESで調整でき、0にすると従来の無期限待機に戻ります）。³³

/loop — ローカルでの反復実行

/loop [interval] <prompt>は、スケジュールに従ってプロンプトを再実行します。固定間隔（/loop 5m check the deploy）、自己調整（観測結果に基づいてClaudeが次の待ち時間を決定）、または組み込みのメンテナンス処理を実行する引数なしの/loopを使用できます。内部ではCronCreate/CronList/CronDelete（5フィールドのcron、セッションあたり50タスク、7日後に失効）とMonitorツールが使われています。Monitorツールは、バックグラウンドスクリプトをポーリングする代わりに、その出力をストリーミングします。¹² Cherny自身が紹介した例は、次のとおりです。「/loopですべてのPRを見守ってください。ビルドの問題を自動修正し、コメントが届いたらworktreeエージェントで修正してください。」¹³

重要な制約として、/loopはセッション内でのみ動作します。ターミナルを閉じるとloopも終了します。ノートパソコンを閉じても動かし続けるためにあるのがroutinesです。

Ralphプラグイン — promiseが守られるまで反復する

Anthropic公式のralph-wiggumプラグインは、コミュニティで好まれてきた力技のパターンを製品化したものです。Stop hookがClaudeによるセッション終了を遮り、プロンプトを再投入することで、モデルが同じセッション内で継続的に反復します。/ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>"で開始し、/cancel-ralphで中止します。READMEでは、--max-iterationsが「主要な安全機構」であると明記されています。完了を示す文字列の完全一致は、いつまでも成立しない可能性があるためです。¹⁴

Dynamic workflows — Claudeがgraphを書く

Dynamic workflowsは、Claude Code v2.1.154（2026年5月）で導入され、Anthropicが2026年6月2日に公開したローンチ記事で詳しく解説されました。これは概念上、最も大きな飛躍です。「Claudeは、その場で独自のharnessを作成し、目の前のタスクに合わせて構築できるようになりました。」¹⁵ タスクを説明する（あるいは単に「workflowを使って」と指示する）と、ClaudeがJavaScriptオーケストレーションスクリプトを作成し、ランタイムがバックグラウンドで実行します。agent()は、任意でJSONスキーマの出力を持つsubagentを生成します。pipeline()は項目を複数のステージに通し、通常のawait、loops、条件分岐が制御フローを担います。「workflowでは、計画がコードになります……loop、分岐、中間結果はworkflowスクリプト自体が保持するため、Claudeのコンテキストに入るのは最終回答だけです。」¹⁶

制限と構成は次のとおりです。同時実行できるエージェントは16体、1回の実行では最大1,000体（「暴走するloopsを防ぐ」ため）で、実行途中にユーザー入力はできません。.claude/workflows/に保存したスクリプトは、再利用可能なスラッシュコマンドになります。また、エージェントの結果がキャッシュされるため、実行を再開できます。¹⁶ 代表的なトポロジーはfan-out / refute / convergeです。独立した探索役を動かした後、各発見を反証するよう指示した敵対的な検証役に渡し、回答が検証に耐えるまで反復します。ローンチ時に目玉として紹介された成果は、Bunの535,496行に及ぶZigコードベースをRustへ移植した事例です。Jarred Sumnerの説明によると、64体の並列エージェントを使い、11日間（2026年5月3日〜14日）で100万行を超えるRustコードベースを生み出しました。¹⁵

Agent teams — ピア型graph

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1の背後にある機能です（v2.1.32、2026年2月からリサーチプレビュー）。チームリーダーと複数のメンバーが、「それぞれ独自のコンテキストウィンドウで独立して作業し、互いに直接コミュニケーションを取ります」。subagentツリーではなくピア型graphとなっており、依存関係を持つ共有タスクリスト、ファイルロックによる担当確保、エージェントごとのメールボックスを通じて調整されます。Hookによって強制されるquality gates（TaskCompletedの終了コード2でブロック）により、メンバーが「完了」とする前に機械的なチェックが挟まれます。¹⁷

Routines — ノートパソコンを閉じても動き続けるloops

routineとは、「プロンプト、1つ以上のリポジトリ、一連のコネクターからなる、保存済みのClaude Code設定です。一度パッケージ化すれば、Anthropicが管理するクラウドまたは独自のセルフホスト型ランナーで自動実行されます。」¹⁸ 組み合わせ可能なトリガーは3種類あります。cronスケジュール（最短1時間間隔）、APIによる起動（POST .../routines/{id}/fire）、GitHubイベントです。/scheduleまたはclaude.ai/code/routinesから作成できます。実行は承認プロンプトなしで自律的に進みます。だからこそ、ドキュメントにある次の注意事項が極めて重要です。実行ステータスが緑でも、「プロンプト内のタスクが成功したことを意味しません。実行結果を開いてトランスクリプトを読み、Claudeが実際に何をしたのか確認してください。」¹⁸

Anthropicでは、自社のコードベース全体を対象に「毎日おそらく20〜30件のroutines」を実行しています。内容はデッドコードの削除、テストカバレッジの改善、実験的機能のリリースなどです。³

支える機能群

Background subagents（v2.1.198以降はデフォルト）は、委任した作業をコンテキストの外で進め、/agentsパネルから監視できます。Cross-session messaging（v2.1.224）は、SendMessageを通じて独立したセッションをメッセージパッシング型graphへ変えます。そのセキュリティ原則は参考に値します。別のセッションから届いたメッセージは「ユーザーの同意として扱われることは決してありません」。¹⁹ Self-hosted runners（v2.1.224、Team/Enterprise）は、クラウドセッションとroutinesを独自のマシン上で実行します。組織規模のエージェント群を支える基盤となる機能です。²⁰

Ralph Pattern

この手法に最初にたどり着いたのはコミュニティでした。2025年7月、Geoffrey Huntleyは、この手法を『ザ・シンプソンズ』のキャラクターにちなんで命名したエッセイを公開しました。Ralphは文字どおり、次のようなものです。

while :; do cat PROMPT.md | claude-code ; done

— 公開時の1行をそのまま引用すると、1つのリポジトリで反復ごとに1つのタスクを実行し、毎回新しいコンテキストを使います。反復間の状態はファイルシステム上の仕様ファイルと進捗ファイルで引き継ぎ、テストやlintを「backpressure」として機能させます。²¹ 同じ構造を現代的なヘッドレス形式にしたものが、シェルループ内で実行する claude -p "$(cat PROMPT.md)" です。これは本質的に、Anthropic自身のCコンパイラー用harnessが実行していたものと同じです。²³ Huntleyが報告した成果（5万ドルの契約に相当するMVPを297ドル分のトークンで実現したこと、ハッカソンで一晩に6つのリポジトリを構築したこと）には、同じくらい明確な限界もありました。対象はグリーンフィールド開発に限られ、プレースホルダーや重複実装が繰り返し発生する失敗パターンとなり、「LLMsはオペレーターの技能を映す鏡である」とされています。

Anthropicはエンジニアリング資料でこの名称を一度も使っていませんが、このパターンは今や2つの形で公式の原則となっています。2025年11月の長時間稼働エージェントに関するエッセイでは、まさにこの構造が推奨されています。初期化エージェントが機能一覧と進捗ファイルを作成し、その後はコンテキストウィンドウごとに新しいコーディングエージェントを起動して、「進捗メモのファイルとgitのコミットログを読むことからセッションを始める」というものです。²² また、2026年2月のCコンパイラープロジェクトでは、16個のClaudeエージェントを並列で稼働させました。Nicholas Carliniの説明では、「Claudeを単純なループに入れるharnessを構築した」とされています。ファイルベースのタスクロックと同期レイヤーとしてのgitを使い、約2,000セッション、約2万ドルで、およそ10万行のRustコードを生成しました。²³ このエッセイにある検証についての一節が、このパターンの理論を端的に表しています。「タスクのverifierがほぼ完璧であることが重要です」

1つの長いセッションよりも新しいコンテキストが優れている理由は、セッションのコンテキストが埋まるにつれて有効性が低下するためです。実務家の共通認識では、精度がぶれ始めるしきい値は約10万トークンとされています。また、compactionによる要約は情報を失う言い換えであり、誤りを自信に満ちた文章へと覆い隠してしまいます。²⁴ Ralphの、新しいエージェントを起動してファイルで状態を引き継ぐ設計なら、どちらの問題も回避できます。（公式プラグインのセッション内ループは、利便性のためにこの利点の一部を手放しています。長時間の実行では、外部状態を使うヘッドレス形式のほうが依然として堅牢です。）

このパターンの失敗例も示唆に富んでいます。ある実務家が曖昧なプロンプトと max_iterations: 0 を指定してプラグインを実行しました。これは無効化ではなく、無限を意味します。その結果、Claudeは同じ確認質問を1,966回繰り返し、Stop hookが以降のすべてのメッセージを乗っ取りました。²⁵ 反復回数の上限は必須です。

ループがグラフになるとき

単一のループでは、各反復が独立しているか、厳密に順番どおり実行されることを前提とします。並列作業に依存関係が生じた瞬間、つまりタスクBがAの出力を必要とする場合や、2つのエージェントが同じファイルを編集する場合には、自由形式のループ同士が衝突します。そこで必要になるのが、依存関係の配列を持つタスクリスト、ファイルの占有、マージ規律といった明示的な構造です。ループ対グラフという議論の本質は、1つのリポジトリと1つの目標にはループを使い、順序付けが必要な並列作業にはグラフを使うということです。²⁶

グラフの選択肢を、必要なインフラが少ない順に並べると次のようになります。

1. 動的ワークフロー — 依存関係をJavaScriptの制御フローで表現し、ある段階がそれ以前の結果をすべて本当に必要とする場合にのみバリアを設けます。Anthropicが挙げるトポロジーは、ファンアウトして統合、敵対的検証、生成して選別、トーナメント（「異なるアプローチで同じタスクを試みるN個のエージェントを起動」し、その後ペアごとに判定）、完了まで繰り返すループです。¹⁵
2. エージェントチーム — 依存関係を追跡する共有タスクリストと、計画を承認するリードを使います。グラフはコードではなくデータです。¹⁷ このパターンでは、デフォルト設定が1つ変更されています。v2.1.233以降、タスクツール（TaskCreate/Get/Update/List、TodoWrite）は、Opus 4.8、Sonnet 5、Fable 5、およびそれ以降ではデフォルトで無効です。ドキュメントには、Taskツールを持たないエージェントは「共有タスクリストの代わりにメッセージで連携する」と明記されています。そのため、現行世代のデフォルト設定では、タスクリストが通知なく存在しない状態になります。復元するには CLAUDE_CODE_ENABLE_TODO_TOOLS=1 を設定します。³³
3. 外部オーケストレーター — コミュニティによるスケールアウト手法です。Steve YeggeのGas Townは、gitを基盤とする「beads」のDAGに対して20〜30個のClaude Codeインスタンスを実行します（本人によれば17日間で7万5,000行のGoを生成しましたが、高度なオペレーター技能を要する「大食いの資金消費装置」でもあります）。²⁷ claude-flow/Ruflo（約3万1,000スター）は、スウォームをqueen/worker階層で包みます。LangGraph形式のエンジンは、ノード内にClaude Codeを配置し、その上に型付きステートマシンを構築します。

Cherny自身は、この発展過程をSteps of AI Adoptionという段階モデルとして体系化し、2026年7月にAnthropicを通じて公開しました。Gated（エージェント0個）→ Assisted（約1個）→ Parallel（約10個）→ Supervised autonomy（約100個、「ほとんどのエージェントは人間ではなくClaudeによって起動される」段階）→ AI-native（1,000個以上）という流れです。併せて示された助言は、「各段階で次のボトルネック群を見つけて分解し、次のguardrails群を整備する必要がある」というものです。²⁸

検証エンジニアリング

ここまでの内容は、すべて配管にすぎません。このセクションこそがプロダクトです。

Anthropicの段階的な強化策を、現行のベストプラクティスドキュメントに沿って示します。まず、合否を判定できるものをClaudeに与えると、「ループは自動的に閉じます」。次に、別の評価者が再確認する /goal 条件を使います。その次に、「決定論的なgate」としてStop hookを設けます。最終的には、「検証subagent、または独自の検出結果を確認する動的ワークフローで、新しいモデルに結果への反証を試みさせます。これにより、作業を行ったエージェント自身が採点することを避けられます」。²⁹ これに伴うevidenceの原則は、「成功を主張するのではなく、Claudeにevidenceを示させる」ことです。

3種類のフィードバックは、Agent SDKのエッセイで説明されています。ルールベースのフィードバック（「出力について明確に定義されたルールを設け、どのルールに違反したか、なぜ違反したかを説明する」最良の形式）、視覚的フィードバック（スクリーンショット、ピクセル差分）、LLM-as-judge（曖昧なルーブリックであり、Anthropicの言葉では「一般に、あまり堅牢な手法ではない」）です。⁷ この順番で優先してください。実在する決定論的なチェックは、意見を述べるjudgeより優れています。

収束条件。 ループについて最も鋭く批判的に論じたYoko Liの2026年8月の分析では、収束に必要な要件を4つに絞っています。定義された目標状態、観測可能な現在状態、正確な局所編集、そしてgeneratorの外部にある停止ルールです。計測を伴う実験で覚えておくべき数字は67%です。リターンが対数的に低下したことをループに知らせる仕組みがなかったため、ループが消費したトークンの67%は改善をまったく生みませんでした。³⁰ 予算上限は単なるコスト管理ではなく、最後の手段となる停止ルールでもあります。

テストの完全性。 Anthropicの長時間稼働エージェントに関する原則には、「テストを削除または編集することは許容されません。機能の欠落や不具合につながる可能性があるためです」とあります。²² ループは、隠れた意図を満たしていなくても目に見えるテストだけを通すなど、仕様を攻略しようとします。そのため、verifierそのものを、評価対象のエージェントから保護する必要があります。

経路ではなく成果を採点します。 evalsのエッセイでは、「エージェントがたどった経路ではなく、生成したものを採点する」こと、客観的な項目にはコードベースのgraderを、ルーブリックにはモデルベースのgraderを使うこと、そしてキャリブレーションを行うことが推奨されています。「多くの試行におけるトランスクリプトと採点結果を読まなければ、graderが適切に機能しているかどうかは分かりません」。³¹

さらに、議論の大半で見落とされている重要な区別があります。ループ内のすべてのチェックが決定論的なら、そもそもループにモデルを入れるべきではありません。 タイムスタンプを比較するdrift watcher、リンクチェッカー、ビルドsentinelなどは、スケジュール実行するシェルスクリプトで十分です。トークン消費はゼロ、実行時間は数秒で、完全な再現性があります。判断が必要な反復にだけ、モデル駆動のループを使いましょう。最も安価なループは、モデルを一度も呼び出さないループです。

コストと安全性の規律

ループエンジニアリングに対するコミュニティ最大の反論はコストです。事後分析にも、その懸念を裏付ける事例が並んでいます。subagentを起動するバグによって5分間で400万トークンを消費した例、一晩のループで数千ドルを費やした例、使用量上限に「予想よりはるかに早く」到達した例があります。³² その障壁の1つは、その後変化しました。v2.1.234以降、セッションはclaude.aiの使用量上限がリセットされると自動的に再開します（/config → 「Continue automatically at usage limit」で無効化できます）。以前なら上限到達時に停止していた夜間ループが、利用枠の時間帯が切り替わると再開するようになりました。そのため、以下の予算管理は以前にも増して重要です。³³ こうして確立された規律は、それぞれ実装済みの制御機能に対応しています。

最後の行は、それだけで1つの段落を割く価値があります。これこそが、最も積極的な実務家が安全性を保つ方法だからです。プルリクエストを影響範囲の境界にします。 Chernyが常時稼働させているバックグラウンドエージェントは、1つがアーキテクチャを継続的に改善し、もう1つが重複した抽象化を探します。人間による指示なしでPRを提出しますが、レビューを経ずにマージされることはありません。² 最悪の場合でも「マージされていないブランチ」が残るだけの常時稼働ループなら、積極的に実行できます。mainへ直接書き込むループでは、そうはいきません。ループは段階的に導入してください。まずは観測専用（レポートのみで書き込みなし）から始め、問題のない退屈な実行を重ねて信頼を獲得し、その後に変更を提案する段階へ進めます。その際は、順序の証明（「新しいmarkerが検証で確認された後にのみpurgeを実行する」）と、網羅的な影響範囲の宣言を、スケジュールの設定前に文書化してください。この段階的な導入方法の経済性については、検証コストが低い領域でループが勝つ理由で詳しく扱っています。無人実行できる対象を決めるのは、ループの構築コストではなく検証コストです。

最も根深い問題はコストではなく、レビュー能力です。ループは、人間が意味のあるレビューを行える速度を上回る勢いでコードを生成します。³⁴ 巧妙な解決策はありません。必要なのは、適用範囲について正直になることだけです。無人ループを使えるのは、検証を機械的に行える領域に限られ、それ以外では使うべきではありません。「検証できないものは、リリースしてはいけません」。²⁹

フリートの運用

loop engineeringの到達点は、1つのloopではなく、常設のフリートです。このプラクティスが安定すると、次のような形になります。

• 仕様をファイルとして管理。 各loopは、名前、tier、スケジュール、目標、verifier、許可されたツール、予算、タイムアウトを定めたバージョン管理対象の仕様であり、そのloopが支えるリポジトリに置かれます。同じ手動チェックを3回入力したなら、仕様に昇格させるべきです。
• 2つのtierと、実績に基づく昇格。 Observe loopは何でも読み取れますが、書き込めるのは自身のレポートディレクトリだけで、すぐにスケジュールできます。Act loopは現実の環境に変更を加えるため、順序付けの証明、影響範囲の宣言、そしてmakerとは別のverifierが必要です。これらはスケジュールを作成する前に記述します。loopはobserveとして開始し、実績を積んで昇格します。
• execとmodelの分離。 決定論的なチェックはスクリプトとして実行し（トークン消費はゼロ、所要時間は1〜2秒）、model loopは判断が必要な処理に限定します。フリートの日々の稼働確認には費用をかけずに済みます。
• レポートの規約。 チェックごとに1行、PASS|FAIL <check>: <reason>という形式で、日付付きのレポートファイルへ追記します。一目で把握できるPASS行を定義できないなら、そのloopはまだ準備不足です。digest loopがフリートのレポートを読み込むようにすれば、人間が確認するのは30ページではなく1ページで済みます。
• 自己保守型のベースライン。 優れたdrift watcherは、監視対象の成果物そのものから期待値を導き出します。たとえば、ガイド自身に記録されたタイムスタンプや、lockfile自身のハッシュです。これにより、成果物を更新すればwatcherも更新され、更新を忘れやすい第2の情報源を持たずに済みます。
• 継続性のあるスケジューリング。 ローカルのフリートでは、runner scriptを呼び出すOSスケジューラー（launchd、cron、systemd timers）を使用し、クラウドのフリートではroutinesを使用します。セッションに紐づくloop（/loop）は、立ち会いながら進める作業向けです。

これは、Chernyの「私の仕事はloopを書くことだ」という言葉を具体化したものです。人間の仕事は、チェック、verifier、予算を定義し、レポートを読むことへと移っていきます。

最初に構築する価値がある2つのloop

フリートをゼロから始めるなら、すぐに元が取れるloopが2つあります。どちらも、このサイト独自のharnessで実証済みです。

gate loop — 公開するあらゆる成果物に対するmaker-checkerです。新しいevaluator（それまでのラウンドの記憶を持たない）が明示的な基準に照らして成果物を採点します。指摘された項目をすべて修正し、別の新しいevaluatorが再採点します。基準に達するか、厳格なラウンド上限に達した時点でloopは停止します。15本の記事を扱ったスプリントから得た現場の知見は2つあります。修正によって新たな不具合が生じることがあり（あるラウンドの修正で数値の出典を誤って帰属させ、次のラウンドのevaluatorがそれを検出しました）、さらにevaluatorはどちらの方向にも誤ります。あるevaluatorは正しい主張を自信満々に「訂正」したため、具体的な修正内容は適用前に出典で検証します。checkerが権威なのではなく、出典こそが権威です。

groundskeeper — act-tierへの入口です。1回の実行につき、客観的に検証できる小さな修正を1つだけブランチ上で行い、テストが成功してからPRを作成します。loop自身がマージすることはありません。安全性を保つルールは2つです。曖昧なものはすべて修正せず、フラグを立てます（最初の監督付き実行では、detectorの誤検知を正しく修正対象外と判断しました）。また、mainに以前から存在する失敗はその旨を報告し、loopのdiffへ取り込むことはありません。

取り入れる価値があるフリート運用上の工夫が、無人のmodel loopにsession leaseを与えることです。同じリポジトリで対話型セッションがアクティブな間は、実行をすべて延期します。1つのcheckoutに対して2つのwriterが動けば、いずれcommitが交錯します。leaseを設けることで、仕組み上、loopが人間に作業を譲るようになります。

よくある質問

loop engineeringとは何ですか？

AI agentにターンごとにpromptを与えるのではなく、停止条件を満たすまで作業サイクルを繰り返させるプラクティスです。engineerの仕事は、promptの作成からloopのデザインへと移ります。具体的には、再実行ルール（条件、スケジュール、イベント）、反復間で保持する状態、verifier、予算を設計します。Anthropicが2026年6月にこの分野を命名しました。そのClaude Code上の実装手段には、/goal、/loop、Ralph plugin、routines、dynamic workflowsがあります。

Ralph loopとは何ですか？

Geoffrey Huntleyが2025年7月に命名した、力技による自律実行パターンです。shellのwhile loop内でClaude Codeを実行し、反復ごとに新しいcontextで同じpromptを与えます。進捗ファイルとgitが各pass間の状態を引き継ぎ、テストがbackpressureとして機能します。Anthropicは公式のralph-wiggum pluginを提供しており、Stop hookを通じてセッション内でloopを実行します。主な安全機構は--max-iterationsです。

Claude Codeをloopで実行するにはどうすればよいですか？

用途に合う最も低いringを選びます。別のevaluatorが条件の達成を確認するまで反復するなら/goal <condition>、セッションを開いている間に定期実行するなら/loop <interval> <prompt>、完了を約束するまで1つのタスクを反復するなら/ralph-loop、マシンを起動していなくてもcronで実行されるクラウドroutineを作成するなら/scheduleです。headless環境では、外部チェックを組み合わせてshell loop内でclaude -pを実行するのが古典的な方法です。

loopはpromptingに取って代わりますか？

promptがなくなるわけではなく、置き場所が変わります。loopの仕様に一度記述すれば、loopがそれを繰り返し実行します。さらに、dynamic workflowsやChernyの「promptingを行うのは、実際には別のClaudeだ」という考え方では、orchestrating agentがタスクごとのpromptを作成する場面が増えています。人間の技能としてprompt作成に代わるのは、verification designです。つまり、マシンや新しいmodelが確認できる条件を明文化することです。

Claude Codeにおけるloop、routine、workflowの違いは何ですか？

loop（/loop）は、ローカルセッション内でスケジュールに従ってpromptを再実行し、セッションの終了とともに停止します。routineは、同じ考え方をクラウドインフラ上で実行できるようにパッケージ化したものです。cron、API、またはGitHubのイベントをトリガーとして実行され、ノートパソコンは必要ありません。workflowは、1回の実行におけるオーケストレーショングラフです。Claudeが作成するJavaScript scriptによって最大1,000のsubagentsを起動して調整し、loopや分岐をcontextではなくコード内に保持します。

agent loopにはどのくらいの費用がかかりますか？

率直に言えば「ゼロから破滅的な額まで」であり、違いを生むのはデザインです。決定論的なwatcherは、スケジュール実行されるスクリプトなので費用がかかりません。model loopは反復ごとに課金されます。上限（--max-iterations、--max-budget-usd）を設け、効果が逓減した時点でloopを停止できるよう、成果を観測可能にしてください。また、上限は不便な制約ではなく、停止ルールとして扱います。一晩で数千ドル、数分で4M tokensといった失敗事例には、外部の停止条件がなかったという共通の根本原因があります。

loopをgraphに移行すべきタイミングはいつですか？

並列作業に依存関係が生じたときです。たとえば、あるタスクが別のタスクの出力を必要とする場合や、2つのagentが同じファイルを変更する場合が該当します。loopは1つのリポジトリと1つの目標を扱います。一方、graph（dynamic workflows、agent teams、外部orchestrators）では、依存関係に基づく順序付け、ファイルのclaim、マージ規律が加わります。実際に競合が発生してからgraphへ移行しましょう。追加される構造には、observabilityとセットアップのコストが伴います。

変更履歴