ループエンジニアリング：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.312（2026年10月）時点のものです。

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 scheduled task (formerly a 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月の分類に基づきます。¹¹）

リング3とリング5の間には、ローカルの選択肢が1つあります。Desktopスケジュールタスクは、セッションを開いていなくても自分のマシン上で実行されます。実行間隔は、Claudeが設定する場合は最短1分（フォームから設定する場合は最短1時間）です。ドキュメントでは、「ローカルのファイルやツールにアクセスする必要がある場合」にこれを使うよう案内しています。¹²

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

Loopサーフェスの詳細

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

/goal — evaluator-optimizer loop

/goal <condition>は、条件が成立するまでClaudeに作業を続けさせます。「各ターンの終了後、モデルが条件の成立を確認します。まだ満たされていないとモデルが判断すると、制御をユーザーへ戻す代わりに、Claudeが次のターンを開始します。」⁹ 内部的には、「/goalは、セッション単位のプロンプトベースのStop hookを包むラッパー」です。そのため、hooksが無効な環境（disableAllHooks、またはマネージド設定のallowManagedHooksOnly）では使用できません。評価モデルは設定済みの小型で高速なモデルで、短い理由を添えて次の3つの判定のいずれかを返します。⁹

ヘッドレスでも動作し、claude -p "/goal ..."を実行すると、loopが完了するまで処理が続きます。

設計上の注意点として、条件には「コードがきれいである」のような願望ではなく、「テストに合格する」「エンドポイントが200を返す」「TypeScriptエラーが0件になる」といった観測可能なものを指定してください。検証条件が曖昧では、loopに進むべき方向を示せません。また、モデルが判定する条件は、自信に満ちたトランスクリプトによって合意へ誘導される可能性があります。そのため、機械的なチェックが存在する場合は、必ず/goalと組み合わせましょう。¹¹ ドキュメントもこの限界を明言しています。評価モデルは「コマンドを実行したりファイルを独自に読んだりしないため、Claude自身の出力で示せる形で条件を書いてください」。⁹ 停止ルールも条件の中に含めましょう。or stop after 20 turnsのような節も、条件の他の部分と同じように判定されます。条件は最大4,000文字まで指定できます。Claudeがツールを使わずに評価モデルへの応答だけを数ターン続けた場合、Claude Codeはloopを停止し、goalを設定したまま制御をユーザーに戻します。⁹

失敗時の処理はv2.1.234で初めて強化され、³⁴ 現在ではターンが失敗するあらゆるケースに対応しています。

デスクトップアプリやクラウドセッションなどのホストが認証情報を管理している場合、認証に失敗してもgoalは有効なまま残ります。アクセスはホスト自身が復旧するからです。また、バックグラウンドの作業を待つ状態が続くと、Claudeは30分後に状況を確認し、その1時間後に再び確認し、以降は2時間ごとに確認します。ユーザーのプロンプトとプロンプトの間に開始するアイドル時の確認は最大3回です（最初の間隔はCLAUDE_CODE_GOAL_CHECKIN_MINUTESで設定でき、0にすると確認と自動再試行が無効になります）。⁹

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

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

重要な制約として、/loopは実行中のClaude Codeプロセスの中で動作します。「タスクが実行されるのは、Claude Codeが実行中かつアイドル状態のときだけです。」終了すればタスクは実行されなくなります。セッションをバックグラウンドに移せば、ターミナルがなくてもloopは動き続けます。--resumeまたは--continueで再開すると、CronCreateでスケジュールしたタスクは復元されますが、自己調整型の/loopは復元されないため、もう一度実行してください。¹² セッションより長く続ける必要がある作業について、ドキュメントは3つのサーフェスを比較しています。¹²

マシンの電源が切れていても実行すべき作業には、クラウドスケジュールタスクを使います。

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

Anthropic公式のralph-loopプラグインは、コミュニティで好まれてきた力技のパターンを製品化したものです。anthropics/claude-plugins-officialリポジトリでは、2026年1月6日にAnthropicが「法務上の指針に従って」ralph-wiggumから名称を変更して以来、ralph-loopという名前になっています。2026年10月26日には、claude-codeリポジトリが古くなった独自のralph-wiggumのコピーを削除し、そのマーケットプレイスは公式リポジトリからralph-loopをインストールするようになりました。そのため、「既存のプラグインIDは引き続き機能します」。¹⁴ 仕組みは次のとおりです。Stop hookがClaudeによるセッション終了を遮り、プロンプトを再投入することで、モデルが同じセッション内で継続的に反復します。/ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>"で開始し、/cancel-ralphで中止します。READMEでは、--max-iterationsが「主要な安全機構」であると明記されています。完了を示す文字列の完全一致は、いつまでも成立しない可能性があるためです。¹⁴ すべてのStop hook loopの根底には、harnessの制限が1つあります。「hookがツール呼び出しを挟まずに8回連続で停止をブロックすると、Claude Codeは次のブロックを無視してターンを終了します」（上限はCLAUDE_CODE_STOP_HOOK_BLOCK_CAPで引き上げられます）。²⁹ これによって終了するのは進捗の止まったloopです。ツールを呼び出し続けるRalph loopは終了しないため、反復回数の上限は依然として重要です。

Dynamic workflows — Claudeがgraphを書く

Dynamic workflowsは、Claude Code v2.1.154（2026年5月）で導入され、Anthropicが2026年6月2日に公開したローンチ記事で詳しく解説されました。これは概念上、最も大きな飛躍です。「Claudeは、その場で独自のharnessを作成し、目の前のタスクに合わせて構築できるようになりました。」¹⁵ タスクを説明するか、「workflowを使って」と指示するか、キーワードultracodeを含めると、ClaudeがJavaScriptオーケストレーションスクリプトを作成し、ランタイムがバックグラウンドで実行します。このスクリプトでは、agent()が任意でJSONスキーマの出力を持つsubagentを生成し、pipeline()がリスト内の項目ごとに1つずつ実行し、parallel()が一連の処理を同時に実行します。通常のawait、loops、条件分岐が制御フローを担います。/effort ultracodeはさらに踏み込み、Claudeが「セッション内の実質的なタスクすべてについてworkflowを計画」します。こうしたセッションは、「無効にした状態で同じ作業をする場合より早く、セッションまたは週の上限に達します」。¹⁶ 「workflowでは、計画がコードになります……loop、分岐、中間結果はworkflowスクリプト自体が保持するため、Claudeのコンテキストに入るのは最終回答だけです。」¹⁶

制限と構成は、ドキュメントによると次のとおりです。¹⁶

.claude/workflows/に保存したスクリプトは、再利用可能なスラッシュコマンドになります。Claudeが実行を再開すると、保存済みのエージェント結果から再開します。ただし、失敗したエージェントは「再実行され、スクリプトがその後に開始するすべてのエージェントも、完了済みのものを含めて再実行されます」。また、実行途中でバックグラウンドに移したり終了したりした実行は「自動的には続行されません」。¹⁶

代表的なトポロジーはfan-out / refute / convergeです。独立した探索役を動かした後、各発見を反証するよう指示した敵対的な検証役に渡し、回答が検証に耐えるまで反復します。Anthropicは現在、その実例を提供しています。組み込みの/deep-research workflowは、「質問について複数の観点からWeb検索を展開し、見つけた情報源を取得して相互に照合し、各主張について投票したうえで、相互照合に耐えなかった主張を除外した出典付きのレポートを返します」。検証役が確認できなかった主張については、「レポートはその主張を反証済みとして数えるのではなく、未検証として記載します」。¹⁶ ローンチ時に目玉として紹介された成果は、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月にリサーチプレビューとして追加。現在のドキュメントでは「Agent teamsは実験的機能であり、デフォルトでは無効です」とされています）。チームリーダーと複数のメンバーが、「それぞれ独自のコンテキストウィンドウで独立して作業し、互いに直接コミュニケーションを取ります」。これはsubagentツリーではなくピア型graphであり、依存関係を持つ共有タスクリスト、ファイルロックによる担当確保、エージェントごとのメールボックスを通じて調整されます。Hookによって強制されるquality gatesにより、メンバーが「完了」とする前に機械的なチェックが挟まれます。TaskCompletedの終了コード2は完了をブロックし、TeammateIdleの終了コード2はメンバーに作業を続けさせます。¹⁷ 有効にする前に知っておくべき動作が2つあります。agent teamsが有効な間は、「Claudeが名前を付けたsubagentはメンバーとして起動するため、依頼していなくてもチームが形成されることがあります」。また、「メンバーは、ユーザーに代わって権限プロンプトを承認したり、同意を与えたりできません」。¹⁷

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

クラウドスケジュールタスク（旧称routine）とは、「プロンプト、1つ以上のリポジトリ、一連のコネクターからなる、保存済みのClaude Code設定です。一度パッケージ化すれば、自動的に実行されます」。実行環境は、Anthropicが管理するクラウドインフラストラクチャ、または組織のセルフホスト環境です。¹⁸ 名前を変えると支障が出る箇所には、旧称が残っています。Webアドレス（claude.ai/code/routines）、/scheduleの別名である/routines、そして/fire APIパスです。組み合わせ可能なトリガーは3種類あります。スケジュール（定期実行の場合は最短1時間間隔、または指定時刻での単発実行）、APIによる起動（POST .../routines/{id}/fire）、GitHubイベントです。/schedule、Desktopアプリ、またはclaude.ai/code/routinesから作成できます。実行のセッションは、自動モードが利用できない場合を除き、自動モードで開始します。分類器が各アクションを許可またはブロックし、自動モードでもプロンプトが表示されるアクション（askルール）や、ブロックが繰り返された場合などには、実行が停止して待機します。だからこそ、ドキュメントにある次の注意事項が極めて重要です。実行の結果が示すのは「セッションがどう終了したかであり、プロンプトに記述した作業をClaudeが完了したかどうかではありません。実行を開いてトランスクリプトを読み、何が起きたかを確認してください。」¹⁸ 9月以降の2つの修正が、このギャップが現実のものであることを示しています。v2.1.286までは、クラウドセッションが一度も開始されなかった実行がSucceededと表示されていました。またv2.1.302までは、実行が「クラウドセッションが予期せず停止した後にCompletedと表示」されていました。³⁶ 同じリリースでは、途中で失敗した実行が最初から再実行される問題も修正されました。この問題は「同じレポートを2回投稿するなど、作業を重複させる可能性がありました」。起動される作業を冪等にしておくべき理由がここにあります。³⁶

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

支える機能群

Background subagents（v2.1.198以降はデフォルト）は、委任した作業をコンテキストの外で進め、/agentsパネルから監視できます。Cross-session messaging（v2.1.224）は、SendMessageを通じて独立したセッションをメッセージパッシング型graphへ変えます。そのセキュリティ原則は参考に値します。別のセッションから届いたメッセージは「ユーザーの同意として扱われることは決してありません」。¹⁹ Remote Controlに接続したセッションからは、別のマシン上のセッション（v2.1.225以降）やクラウド上のセッションにも届きます。loop間の待機には、notify_when_idle入力（v2.1.236以降）³⁶を使うと、このマシン上のセッションに、次にアイドル状態になるか終了したときに1回だけ通知するよう依頼できます。Claude Codeは「監視対象のセッションでターンを開始したりトークンを消費したりせずに」購読します。¹⁹ Self-hosted runners（v2.1.224、Team/Enterprise）は、クラウドセッションとクラウドスケジュールタスク（旧称routines）を独自のマシン上で実行します。組織規模のエージェント群を支える基盤となる機能です。²⁰

Ralphパターン

この手法を先に実践していたのはコミュニティです。2025年7月、Geoffrey Huntleyは『The Simpsons』の登場人物にちなんでこの手法を名付けたエッセイを公開しました。Ralphは文字どおり、次のコードです。

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

— これは公開されたとおりの1行です — 1つのリポジトリを対象に、反復ごとに1つのタスクを処理し、毎回新しいコンテキストで開始します。反復間の状態はファイルシステム上の仕様書と進捗ファイルで引き継ぎ、テストとlintを「バックプレッシャー」として使います。²¹ 現在のヘッドレス形式では、シェルのループ内で claude -p "$(cat PROMPT.md)" を実行します。これは本質的に、Anthropic自身のCコンパイラ用harnessが実行していたものと同じです。²³ Huntleyが報告した成果（5万ドルの契約案件のMVPをトークン費用297ドルで実現したことや、ハッカソンで一晩に6つのリポジトリを構築したこと）には、同じくらい明確な制約も添えられていました。新規開発に限られること、プレースホルダーや重複した実装が繰り返し発生すること、そして「LLMは運用者のスキルを映す鏡です」という点です。

Anthropicは技術資料でこの名称を使っていませんが、このパターンはすでに2度、公式の指針として示されています。2025年11月の長時間稼働エージェントに関するエッセイでは、まさにこの構成を推奨しています。初期化用エージェントが機能一覧と進捗ファイルを作成し、その後はコンテキストウィンドウごとに新しいコーディングエージェントが「進捗メモのファイルとgitのコミットログを読んでセッションを開始します」。²² また、2026年2月のCコンパイラプロジェクトでは、16個のClaudeエージェントを並列で実行しました。Nicholas Carliniは「Claudeを単純なループで動かすharnessを作りました」と説明しています。ファイルによるタスクのロックと同期層としてのgitを使い、約2,000セッション、約2万ドルで、約10万行のRustコードを生成しました。²³ このエッセイにある検証についての一文が、パターン全体の理論を表しています。「タスクの検証器がほぼ完璧であることが重要です」。

新しいコンテキストが1つの長いセッションより有効な理由は、セッションのコンテキストが埋まるにつれて性能が低下するからです。実践者の間では、意図からのずれが生じ始める目安は約10万トークンとされています。さらに、コンテキスト圧縮による要約では情報が失われ、誤りまで確信に満ちた文章に書き換えられてしまいます。²⁴ 毎回新しいエージェントを起動してファイルで状態を引き継ぐRalphの設計は、この両方を回避します。（公式プラグインのセッション内ループでは、利便性と引き換えにこの利点の一部を手放しています。長時間の実行では、外部に状態を保持するヘッドレス形式のほうが、引き続き有効なパターンです。）

このパターンの失敗談からも学べます。ある実践者が、曖昧なプロンプトと max_iterations: 0 を指定してプラグインを実行しました。この値は無効化ではなく、無限を意味します。その結果、Claudeは同じ確認質問を自分自身に1,966回繰り返し、Stop hookがそれ以降のすべてのメッセージを横取りしました。²⁵ 反復回数の上限は必須です。

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

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

必要な基盤が小さい順に、グラフの選択肢を挙げます。

1. 動的ワークフロー — 依存関係をJavaScriptの制御フローで表現します。同期のための待ち合わせを設けるのは、その段階でそれまでの結果がすべて必要な場合だけです。Anthropicが挙げる構成には、ファンアウトと統合、反証による検証、生成と絞り込み、トーナメント（「異なるアプローチで同じタスクに取り組むN個のエージェントを起動」し、その後で結果を2つずつ比較評価します）、完了までの反復があります。¹⁵
2. エージェントチーム — 依存関係を追跡する共有タスク一覧を設けます。リーダーがプランモードの間に起動されたメンバーは、承認を求めて計画を送り、Claude Codeがそれを自動的に承認します。リーダーが計画をレビューするのは、実行中のインプロセスのメンバーをプランモードに切り替えた（Shift+Tab）場合だけです。グラフはコードではなくデータとして表現されます。¹⁷ このパターンに関わる既定の設定が1つ変わりました。最初の変更はv2.1.233です。³⁴ タスク追跡ツール（TaskCreate、TaskGet、TaskUpdate、TaskList、TodoWrite）は現在、「Opus 4.7、Sonnet 4.6、Haiku 4.5、およびそれ以前のモデルでのみデフォルトで利用可能」で、このデフォルトのセットはv2.1.268以降に適用されます。³⁸ これらのツールを持たないエージェントは「共有タスク一覧の代わりにメッセージで連携します」。¹⁷ つまり、現行モデルの通常のローカルセッションでは、オプトインしない限りタスク一覧は存在しません。バックグラウンドセッションとクラウドセッションでは、どのモデルでもツールが提供されます。³⁸ オプトインするには、CLAUDE_CODE_ENABLE_TODO_TOOLS=1、--allowedTools TaskCreate、またはこれらのツールを指定した--toolsリストを使います。エクスポートした環境変数は分割ペインのメンバーには届かないため、そうしたメンバーにツールを与えるには、claude --settings '{"env":{"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自身はこの発展過程を、2026年7月にAnthropicを通じて公開したAI導入の段階という階段で体系化しています。承認制（エージェント0個）→ 支援型（約1個）→ 並列型（約10個）→ 監督下の自律型（約100個。この段階では「ほとんどのエージェントを起動するのは人間ではなくClaudeです」）→ AIネイティブ（1,000個以上）という流れです。これに添えた助言は、「各段階で…次のボトルネックを見つけて取り除き、次に必要なガードレールを整備する必要があります」というものです。²⁸

検証エンジニアリング

ここまでの内容は、すべて基盤の仕組みです。この節こそがプロダクトの本体です。

Anthropicが示す段階的な強化策は、現行のベストプラクティス文書では、1つのヒントから始まります。「Claudeが実行でき、合否が返ってくるものを与えてください。それさえあれば、Claudeは自力で作業を続けられ、ユーザーが見守る必要はありません。」そこから段階は、Claudeが判断する段階からharnessが強制する段階へと進みます。プロンプトの1行（run the auth tests after, and keep going until they pass）→「毎ターン後に別のモデルが会話と照らし合わせて確認する」/goalの条件。これは「長時間のバックグラウンド実行で重要です。そうした実行では、項目がまだ残っているのに、Claudeが進捗の要約でターンを終えることがあるからです」→ Stop hook。これは「Claude Code（harness）によって強制されるため、型チェックに合格するかブロックの上限に達するまで、ターンは終了しません」→「コードを書いていない人による」レビュー。/code-reviewは「会話を一度も見ていない新しいsubagentで差分をレビューします。コードを生み出した推論に左右されません」。²⁹ これに付随する証拠の原則は、「Claudeに証拠を求めてください。実行したコマンドとその出力、またはスクリーンショットです」というものです。「見ていなかったセッションについては、それが手元にある唯一の証拠でもある」からです。²⁹ この段階がかつて最後に置いていた敵対的な反証は、現在ではワークフローのドキュメントに移っており、その例のプロンプトはワークフローに「報告する前に、各発見を敵対的に検証する」よう求めています。¹⁶

同じ文書は、あらゆる指示を、Claudeが判断するものとClaude Codeが強制するものに分類しています。そのうち3つの行が、ループの停止、予算、マージのルールにあたります。²⁹

無人で動くループには、すべての行で右側の列の項目が必要です。誰もそれを書かなければ、ループにあるのは左側の列だけです。この文書は、プロンプトの習慣も1つ退けています。「keep going, loop until done, don’t be lazy」のような行は、「停滞を解消するより、過剰な作業を引き起こす可能性のほうが高く」、「誰も見ていない実行では、/goalまたはStop hookがそれを強制します」。²⁹

3種類のフィードバックは、Agent SDKのエッセイで示されています。ルールに基づくフィードバック（「出力に対するルールを明確に定義し、どのルールに違反したかと、その理由を説明します」。これが最も優れた形式です）、視覚的フィードバック（スクリーンショット、ピクセル差分）、そして評価者としてのLLM（曖昧な評価基準を使う方式で、Anthropicの言葉では「一般に、あまり堅牢な方法ではありません」）です。⁷ この順に優先しましょう。実際に機能する決定論的なチェックは、意見を述べる評価者に勝ります。

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

テストの健全性。 Anthropicの長時間稼働エージェントに関する指針には、こうあります。「テストの削除や編集は許容されません。機能の欠落や不具合を見逃すおそれがあるためです」。²² ループは仕様の抜け道を突き、見えているテストには合格しても、その背後にある意図を満たさないことがあります。そのため、検証器そのものを、検証対象のエージェントから保護する必要があります。

経路ではなく成果を評価します。 評価に関するエッセイでは、「エージェントがたどった経路ではなく、生み出した成果を採点してください」と述べています。客観的に判定できるものにはコードによる採点を、評価基準に沿った判断にはモデルによる採点を使い、さらに評価の妥当性を調整します。「多くの試行の会話記録と採点結果を読まなければ、採点器が適切に機能しているかはわかりません」。³¹

議論の大半が見落としている区別が、もう1つあります。ループ内のすべてのチェックが決定論的なら、そのループにモデルは一切必要ありません。 タイムスタンプを比較してずれを監視する仕組み、リンクチェッカー、ビルドの監視役は、定期実行するシェルスクリプトで実現できます。トークン消費はゼロ、1回の実行は数秒で、完全に再現可能です。モデルを使うループは、判断が必要な反復のために取っておきましょう。最も安いループは、モデルを一度も呼び出さないループです。

コストと安全性を管理する規律

ループエンジニアリングに対するコミュニティからの最も強い反論はコストです。失敗事例の報告も、それを裏づけています。subagents を生成するバグで5分間に400万トークンを消費した例、一晩のループで数千ドルを使った例、利用上限に「予想よりはるかに早く」達した例があります。³² ただし、そうした制約の1つは変わりました。v2.1.234以降では、claude.ai の利用上限がリセットされると、セッションが自動的に続行されます（autoContinueAtUsageLimit設定。/config → 「Continue automatically at usage limit」で無効にできます）。³⁴³⁷ ただし、その適用範囲は限られています。「自動続行は、claude.aiのサブスクリプションでサインインした対話セッションではデフォルトで有効です」。週ごとの上限など、「24時間以上先のリセット」については、Claude Codeが自動的に待機を開始することはありません。Claude Codeを終了すると待機も終わります。また、「バックグラウンドセッションと-p実行」では、Claude Codeは「待機をまったく提示しません」。これはヘッドレスRalphとclaude -p "/goal ..."にも当てはまります。³⁷ 条件を満たすセッション内では、ループもこれに従います。一時停止した/goalはリセット時に再開し、⁹ v2.1.271以降は、ワークフローの実行もエージェントを失敗させずに上限の解除を待ちます（1回の実行につき最大2回）。¹⁶ 開いたままの対話セッションにとどまる夜間のループは、上限を乗り越えられるようになりました。一方、ヘッドレスやバックグラウンドセッションで動くループは、依然として上限で停止します。そのため、以下の予算管理はますます重要になります。こうした経験から生まれた規律は、それぞれ実装済みの制御手段に対応しています。

最後の行は、独立した段落で説明する価値があります。最も積極的に取り組む実践者が安全を保つ方法だからです。プルリクエストを影響範囲の境界にしましょう。 Chernyの常駐バックグラウンドエージェントは、一方がアーキテクチャを継続的に改善し、もう一方が重複する抽象化を探して、人間からの指示なしにPRを提出します。² レビューなしにマージされるものはありません。最悪でも「未マージのブランチ」が残るだけの常時稼働ループなら、積極的に動かせます。mainに書き込むループでは、そうはいきません。クラウドスケジュールタスクは、これをデフォルトとして備えています。「プロンプトで別のブランチへのプッシュを指示しない限り、Claudeはclaude/で始まるブランチに作業をプッシュします」。実行がどこにプッシュできるかは、GitHubのブランチ保護やルールセットが決めます。¹⁸ ループは段階的に昇格させましょう。まずは観測のみ（報告は行い、書き込みは行わない）で始め、何事もない実行を重ねて信頼を得てから、変更を提案する段階へ進みます。その際は、実行順序の証明（「検証が新しいマーカーを返した後にのみパージを実行する」）と、影響範囲を網羅した宣言を、スケジュールを設定する前に文書化します。この昇格経路の経済性は、検証が安く済む領域でループは強みを発揮するで扱っています。無人で実行できる範囲を決めるのは、ループの構築ではなく検証のコストです。

ループへの入力は、どれも同意になりません。 文書化された4つのルールが一致しています。別のセッションからのメッセージは「ユーザーの同意として扱われることは決してありません」。¹⁹ メンバーは「ユーザーに代わって権限プロンプトを承認したり、同意を与えたりできません」。¹⁷ クラウドスケジュールタスクで起動されたプロンプトは「実行中のアクションに対する承認や同意として機能できません」。API経由の起動で送られたテキストは「信頼できないデータであることを示す<routine-fire-payload>ブロックに包まれて届きます」。¹⁸ そして自動モードでは、ワークフロースクリプトがagent()に渡すプロンプトは「ユーザーからの依頼として扱われません」。「Claude Codeは、それをスクリプトが算出したテキストとして扱う」からです。¹⁶ このルールを自分のループにも取り入れましょう。機械が生成したテキストはデータであり、承認は人から得るものです。

最も根本的な反論はコストではなく、レビュー能力の限界です。ループは、人間が十分にレビューできる速度を超えてコードを生成します。³³ 気の利いた解決策はありません。できるのは、適用範囲を正直に見定めることだけです。無人ループを使うべきなのは、検証を機械的に行える領域に限られます。検証できないなら、リリースしないことです。

対照実験が示す harness の構成要素

このガイドも含め、harness に関する助言の多くは、本番環境で1つずつ変更を加えてきた実践者の経験に基づいています。UMass Amherst、Emory、UNC Charlotte、Zoomによる2026年9月の研究では、これを条件を統制して検証しました。実験専用の harness を用意し、「実行ループを固定したまま、計画、行動空間、コンテキスト管理の3要素を変化させ」、SWE-Bench VerifiedとTerminal-Bench 2.1上で、「5種類のコンテキスト管理戦略、4段階のコンテキストウィンドウ予算、計画と行動空間を対象としたアブレーション実験にわたる、条件を対応させた176設定」を実行しました。使用したのは、Nemotron-3の3サイズとMistral-Medium-3.5-128Bという、重みを公開している4モデルです。³⁵ 著者らの言葉で示された4つの知見は、次のとおりです。

• 「コンテキストウィンドウの予算が厳しくなるほど、コンテキスト管理の価値は高まります。その効果の大部分は、コンテキストの容量超過による失敗を防ぐことから生まれます。」
• 「LLMによる要約の前にルールベースの省略処理を行う戦略が、コンテキスト管理戦略の中で総合的に最も高い効率を示します。一方、省略した内容を復元可能にしても、モデルがほとんど使わない仕組みが増えるだけで、精度は向上しません。」
• 「計画は、能力の低いモデルでは精度を支える役割を果たしますが、能力の高いモデルでは精度をほぼ変えずにコストを削減する役割へと変わります。」
• 「事前定義されたツールは、bashの扱いが不得意なモデルの性能を向上させます。一方、bashを使いこなせるモデルは、bashのみのインターフェースでも効果的に動作し、特にコマンドライン中心のタスクでコストを大幅に削減できます。」

私の解釈では、このうち3つがループエンジニアリングに直接関係します。コンテキスト管理は、容量超過への備えです。長時間稼働するループでは、ウィンドウの予算を管理し、要約に入る前に大量のツール出力を省略すべきです。また、モデルが使わない情報呼び出しの仕組みは、構築を省けます。能力の高いモデルにとって、計画は精度を上げる手段というより、コストを調整する手段です。高性能なモデルを使うループに計画フェーズを追加する前に、知っておく価値があります。そしてbashのみで得られた結果は、exec/modelの分離を1段上のレベルで示しています。実行主体に十分な能力があれば、行動を大きな単位にまとめて回数を減らすほど、コストは下がります。ただし、留意点は研究自体が示しています。対象は4モデル、2つのベンチマークで、harness も実際に提供されているエージェントではなく実験用に構築されたものです。そのため、結果は方向性として応用すべきであり、設定値としてそのまま移せるわけではありません。³⁵

複数のループを運用する

ループエンジニアリングが最終的に目指すのは、単独のループではなく、常設のループ群です。運用が安定すると、次のような形になります。

• 仕様をファイルにします。 各ループは、名前、階層、スケジュール、目標、検証手段、使用可能なツール、予算、タイムアウトを記した、バージョン管理された仕様です。対象のリポジトリ内に置きます。同じ手動チェックを3回入力したら、仕様にします。Anthropicは、この考え方を小さな形で提供しています。loop.mdファイルが引数なしの/loopの組み込みプロンプトを置き換え、ファイルへの編集は次の反復から反映されます。¹²
• 2つの階層を設け、実績に応じて昇格させます。 観測ループは何でも読み取れますが、書き込み先は専用の報告ディレクトリに限られ、すぐにスケジュールを設定できます。実行ループは外部の状態を変更するため、実行順序の証明、影響範囲の宣言、作成者とは別の検証者が必要です。これらはスケジュールを設定する前に文書化します。ループは観測から始め、実績を積んで昇格します。
• exec/modelを分離します。 決定論的なチェックはスクリプトとして実行し（トークン消費ゼロ、1〜2秒）、モデルを使うループは判断が必要な場面に限定します。ループ群の日々の稼働確認は、コストゼロにもできます。
• 報告の契約を定めます。 チェックごとに1行、PASS|FAIL <check>: <reason>の形式で、日付付きの報告ファイルに追記します。一目で把握できるPASS行を定義できなければ、そのループはまだ準備不足です。集約用のループが各ループの報告を読み、人間が読む量を30ページから1ページにまとめます。
• 基準値を自己更新させます。 優れたドリフト監視は、ガイド自身に記録されたタイムスタンプやロックファイル自身のハッシュなど、監視対象の成果物から期待値を導きます。成果物を更新すれば監視側も更新されるため、更新を忘れかねない別の正本を持たずに済みます。
• 持続するスケジュールを使います。 ローカルのループ群は、OSのスケジューラー（launchd、cron、systemd timers）からランナースクリプトを呼び出して実行するか、マシンを起動したままにできるならDesktopスケジュールタスクで実行します。クラウドのループ群にはクラウドスケジュールタスク（旧称ルーティン）を使います。セッションに紐づくループ（/loop）は、その場にいる間の作業か、バックグラウンドに移したセッションで使うものです。¹²

これが、Chernyの「私の仕事はループを書くことです」を具体化した姿です。人間の仕事は、チェック、検証手段、予算を定義し、報告を読むことへと移ります。

最初に構築する価値のある2つのループ

ループ群をゼロから始めるなら、すぐに元が取れるループが2つあります。どちらも、このサイト自身の harness で実績があります。

ゲートループ — 公開するあらゆる成果物に、作成者と検証者を分ける仕組みを適用します。過去のラウンドの記憶を持たない新しい評価者が、明示された基準に照らして成果物を採点します。挙げられた指摘をすべて反映し、別の新しい評価者が再採点します。基準に達するか、厳格に定めたラウンド数の上限に達すると、ループは停止します。15本の記事を集中的に制作する中で運用して得た教訓は2つあります。修正が新たな欠陥を生む場合があること（あるラウンドでの修正によって数値の出典が誤って記され、次のラウンドの評価者が発見しました）、そして評価者はどちらの方向にも間違うことです。正しい主張を自信満々に「訂正」した評価者もいたため、具体的な修正は適用前に出典で確認します。判断の拠り所は検証者ではなく、出典です。

保守担当ループ — 実行階層への入口です。1回の実行につき、客観的に検証できる小さな修正を1つだけブランチ上で行い、テストが通ってからPRを作成します。ループ自身は決してマージしません。安全を保つルールは2つです。曖昧なものは修正せず、指摘にとどめます（最初の監督付き実行では、検出器の誤検知を正しく見送りました）。また、mainに既存の不具合があれば、そのように報告し、ループの差分には決して取り込みません。

ループ群の運用で取り入れる価値のある工夫が、もう1つあります。無人で動くモデルループにセッションリースを設け、同じリポジトリで対話セッションが動いている間は、実行を延期します。1つのチェックアウトに2つの書き込み主体がいれば、いずれコミットが入り混じります。リースを設けることで、ループが人間に譲る仕組みを構造的に保証できます。

よくある質問

ループエンジニアリングとは何ですか？

ターンごとにプロンプトを与える代わりに、停止条件を満たすまでAIエージェントに作業のサイクルを繰り返させる手法です。エンジニアの仕事は、プロンプトを書くことから、ループを設計することへと移ります。設計するのは、再実行のルール（条件、スケジュール、イベント）、反復間で引き継ぐ状態、検証手段、予算です。Anthropicが2026年6月にこの分野を命名しました。Claude Codeでは、/goal、/loop、Ralphプラグイン、クラウドスケジュールタスク（旧称ルーティン）、動的ワークフローという形で利用できます。

Ralphループとは何ですか？

Geoffrey Huntleyが2025年7月に命名した、総当たり型の自律実行パターンです。シェルのwhileループ内でClaude Codeを実行し、各反復で新しいコンテキストに同じプロンプトを渡します。反復間の状態は進捗ファイルとgitで引き継ぎ、テストが進行に歯止めをかけます。Anthropicは、Stop hookを介してセッション内で反復する公式のralph-loopプラグイン（2026年1月にralph-wiggumから改称）を提供しており、主な安全機構は--max-iterationsです。

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

要件を満たす最も小さな範囲の仕組みを選びましょう。独立した評価者が条件の達成を確認するまで反復するなら/goal <condition>、Claude Codeのセッションが実行されている間に定期実行するなら/loop <interval> <prompt>、完了宣言まで1つのタスクを反復するなら/ralph-loop、自分のマシンなしでcron実行されるクラウドスケジュールタスクを作るなら/scheduleです。ヘッドレス実行では、シェルループ内でclaude -pを実行し、外部チェックを組み合わせるのが古典的な形です。

ループはプロンプトを置き換えますか？

プロンプトはなくなるのではなく、置き場所が変わります。ループの仕様に1度書けば、ループがそれを繰り返し実行します。さらに、動的ワークフローや、Chernyの「実際には別のClaudeがプロンプトを出しています」という言葉に見られるように、タスクごとのプロンプトを統括エージェントが書く場面が増えています。人間の専門技能としてプロンプト作成に取って代わるのは、検証の設計です。機械や新しいモデルが確認できる条件を定めます。

Claude Codeのループ、ルーティン、ワークフローはどう違いますか？

ループ（/loop）は、ローカルのClaude Codeセッション内でスケジュールに従ってプロンプトを再実行し、そのプロセスが終了すると実行されなくなります。バックグラウンドに移したセッションでは動き続けます。クラウドスケジュールタスク（旧称ルーティン）は、同じ考え方をクラウド基盤で実行できる形にしたものです。cron、API、GitHubのイベントをきっかけに起動し、ノートPCは不要です。ワークフローは、1回の実行における処理の統括を表すグラフです。Claudeが書くJavaScriptスクリプトが、最大1,000の subagents を生成して連携させ、ループや分岐はコンテキストではなくコードで管理します。

エージェントループにはどれくらいのコストがかかりますか？

正直なところ、「ゼロから破産しかねない額まで」で、その差を生むのは設計です。決定論的な監視は、スケジュールに従って動くスクリプトなので、コストはかかりません。モデルループは反復ごとに課金されます。上限を設け（--max-iterations、--max-budget-usd）、効果が薄れた時点でループを止められるよう成果を観測可能にし、あらゆる上限を厄介な制約ではなく停止ルールとして扱いましょう。一晩で数千ドル、数分で400万トークンといった失敗事例には、共通の根本原因があります。外部の停止条件がなかったことです。

ループをグラフに変えるべきなのはいつですか？

並行作業に依存関係が生じたときです。あるタスクが別のタスクの出力を必要とする場合や、2つのエージェントが同じファイルを変更する場合が該当します。ループは1つのリポジトリと1つの目標を扱います。グラフ（動的ワークフロー、エージェントチーム、外部のオーケストレーター）は、依存関係に応じた順序、ファイルの担当確保、マージの規律を加えます。グラフへ移行するのは、実際に衝突が起きてからにしましょう。構造を追加すると、可観測性の確保や設定にコストがかかります。

変更履歴