Claude Code の「ループ」設計入門：4つのループ型と使い分け

「ループを設計する」という言葉は便利ですが、実際には人によって指しているものが少しずつ違います。単にプロンプトを何度も投げることを指す場合もあれば、完了条件つきで Claude に任せること、あるいはスケジュール実行や自律的な反復処理まで含めている場合もあります。2026年7月7日、Claude Code チームは公式開発者アカウント @ClaudeDevs で、この曖昧さに答える解説ポスト（執筆: Delba Oliveira 氏）を公開しました。本記事はその内容を、Claude Code の公式ドキュメントで仕様面を補いながら整理します。

ループの定義 — 「停止条件が満たされるまで作業を繰り返すこと」

Claude Code チームは、ループを次のように定義しています。

On the Claude Code team, we define loops as agents repeating cycles of work until a stop condition is met.

（Claude Code チームでは、ループを「エージェントが停止条件を満たすまで作業のサイクルを繰り返すこと」と定義している）

そのうえで、ループを次の3つの軸で分類しています。

• どうやって起動されるか（トリガー）
• どうやって止まるか（停止条件）
• Claude Code のどの機能（プリミティブ）を使うか

元ポストは「すべてのタスクが複雑なループを必要とするわけではない。まずは最も単純な方法から始め、これらのパターンは選択的に使うべきだ」と釘を刺しています。以下、4つのループ型を順に見ていきます。

結論 — 4つのループ型と使い分け

ターンベースのループ — Claude Code の基本形

送信するプロンプト1つひとつが、手動のループを開始します。Claude は文脈を集め、行動を起こし、成果を確認し、必要なら繰り返し、最後に応答します。この一連の流れをエージェントループと呼びます。

図1: ターンベースのループ（エージェントループ）。Claude がタスク完了と判断するか、effort の予算が尽きたときに抜ける

たとえば「いいねボタンを作って」と頼むと、Claude はコードを読み、編集を加え、テストを実行し、動作すると判断したものを返します。そのあとの確認と次のプロンプトの作成は、ユーザーが手動で行います。

この検証の工程は、SKILL.md として手順を明文化することで改善できます。手動で行っていた確認手順をスキルとして記述しておけば、Claude はより多くの範囲を自力で、最後まで検証できるようになります。ポストが挙げる例は、UI変更を「編集が成功した」だけで完了と報告させず、開発サーバーを起動して実際に操作し、ブラウザのコンソールにエラーがないか確認し、Core Web Vitals を計測する、という手順をスキルとして定義するものです。Claude が結果を見たり測ったりできるツールやコネクタを持たせること、そして確認項目はできるだけ定量的にすることが、Claude の自己検証をしやすくするコツだとされています。

ゴールベースのループ（/goal） — 完了条件を渡して任せる

1回のターンでは終わらない作業もあります。特に複雑なタスクでは、Claude が反復できるほうがうまくいきます。/goal は「完了とは何か」を定義することで、Claude が反復し続ける期間を延長する機能です。

図2: ゴールベースのループ。評価者モデルが毎ターン条件を確認し、満たされなければ作業に送り返す

成功条件を定義しておけば、Claude は「これで十分か」をその場で判断してループを早期に打ち切る必要がなくなります。Claude が作業を止めようとするたびに、評価者モデルが設定した条件を確認し、ゴールが満たされるか、指定したターン数に達するまで作業に送り返します。公式ドキュメントによれば、この評価者は既定で Haiku など小型で高速なモデルが使われ、会話の記録に対してのみ判定を行い（自らツールを呼び出して確認することはしません）、評価にかかるトークンは主ターンの消費と比べて通常無視できる程度だとされています¹。

このため、通過したテストの数やスコアの閾値超えといった、決定的（deterministic）な条件が効果的だとされています。元ポストが挙げる例は次のとおりです。

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

時間ベースのループ（/loop・/schedule） — 定期実行で外部システムと連携する

エージェントの作業には、定期的に発生するものもあります。たとえば、毎朝 Slack のメッセージを要約する作業では、タスクの内容は同じで入力だけが変わります。また、PR がレビューコメントを受け取ったり CI が失敗したりするなど、外部システムに依存する作業もあります。こうした場合、一定間隔でチェックし、変化に反応するのが簡単なインターフェースになります。

図3: 時間ベースのループをクラウドへ移した例。トリガー・実行・レビューがすべて `/schedule` のルーチンとして完結し、ユーザーは最後にマージの判断だけを行う

/loop は、プロンプトを一定間隔で再実行するコマンドです。

/loop 5m check my PR, address review comments, and fix failing CI

元ポストは「/loop はユーザーのマシン上で動くため、それを止めればループも止まる。ルーチンを /schedule で作成すれば、ループをクラウドへ移せる」としています。公式ドキュメントで両者を比較すると、次の違いがあります²。

なお、元ポストは /schedule を「research preview」と付記しています。公式ドキュメントを見ると、セッション内で動く /loop や scheduled tasks は Claude Code v2.1.72 以降の機能として案内されています。一方で、Anthropic 管理のクラウド上で動く Routines については、現時点でも research preview と明記されています³。そのため、/loop とクラウド Routines は実行環境だけでなく、安定性の位置づけも分けて理解しておくのがよさそうです。

主体的ループ（proactive loops） — 上記の組み合わせ

ここまでのプリミティブに加え、auto mode や dynamic workflows といった Claude Code の他機能を組み合わせることで、長時間にわたる作業を1つのループへ構成できます。dynamic workflows は Claude が書く JavaScript スクリプトで多数のサブエージェントをオーケストレーションする機能で、公式ドキュメントによれば Claude Code v2.1.154 以降・全有料プランおよび Anthropic API 等で利用できます⁴。

たとえば、届いたフィードバックに対応する場合、元ポストは次の組み合わせを挙げています。

• /schedule — 新しい報告がないか確認するルーチンを実行する
• /goal — 完了の定義と、それを検証する手順をスキルとして文書化する
• dynamic workflows — 各報告のトリアージ・修正・レビューを行うエージェントを指揮する
• auto mode — 許可を求めて作業を止めることなくルーチンを実行する

これらをまとめると、次のようなプロンプトになります。

/schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

コード品質を保つには

ループの出力品質は、それを取り巻く仕組み次第だとされています。設計時に考慮すべき点として、元ポストは次を挙げています。

• コードベース自体を整理しておく: Claude は既存のパターンや規約に従う
• Claude 自身が作業を検証できる手段を与える: 何をもって「良い」とするかをスキルとして明文化する
• ドキュメントに手が届くようにしておく: フレームワークやライブラリの最新のベストプラクティスを参照できるようにする
• コードレビューには別のエージェントを使う: 新鮮な文脈を持つレビュアーはバイアスが少なく、メインエージェントの推論に引きずられない。組み込みの /code-review スキルや GitHub 向けの Code Review が使える
• 個々の結果が基準に満たないときは、その場しのぎで直すだけでなく、以降のすべての反復のために仕組み自体を改善することを試みる

トークン消費を管理するには

ループのトークン消費を管理するには、明確な境界を設けることが重要だとされています。

• 作業に見合ったプリミティブとモデルを選ぶ: 小さな作業に複数のエージェントやループは不要。より安価で高速なモデルで済むタスクもある
• 成功条件と停止条件を明確に定義する: 「完了」が何かを具体的にすることで、Claude はより早く（ただし早すぎずに）解にたどり着ける
• 大規模実行の前に小規模で試す: dynamic workflows は数百のエージェントを生成しうる。まず作業の一部で消費量を測る
• 決定的な作業にはスクリプトを使う: スクリプトの実行は、手順を推論しながら進めるより安価。たとえば PDF 操作のスキルには、毎回コードを再導出させるのではなく、実行するだけのフォーム入力スクリプトを同梱できる
• 必要以上の頻度でルーチンを実行しない: 監視対象が変化する頻度に間隔を合わせる
• 使用量を確認する: /usage はスキル・サブエージェント・MCP別の直近の使用量を、引数なしの /goal はここまでのターン数とトークン消費を、/workflows は各エージェントのトークン消費を表示し、いつでもエージェントを停止できる

はじめの一歩

元ポストは、4つのループ型を次のように要約しています。

ループを始めるには、すでに行っている作業の中から、自分がボトルネックになっているタスクを1つ選び、どの部分を手放せるかを問うとよいとされています——検証のチェックは自分で書けるか。ゴールは十分明確か。作業はスケジュールに沿って発生するか。方針が決まったら、実際にループを動かし、どこで止まるか・どこでやり過ぎるかを観察し、遠慮なく調整していくことが勧められています。

まとめ

• Claude Code チームは、ループを「エージェントが停止条件を満たすまで作業のサイクルを繰り返すこと」と定義し、トリガー・停止条件・使用する機能の3軸で4種類に分類しています
• ターンベースはプロンプト1つが単位で、Claude が完了と判断するかで止まります。検証を SKILL.md として明文化すると自己検証の範囲が広がります
• ゴールベース（/goal）は完了条件を渡し、評価者モデル（既定は小型で高速なモデル）が毎ターン条件を確認します。決定的な条件ほど効果的です
• 時間ベース（/loop・/schedule）は一定間隔での実行です。/loop はローカルのセッションに紐づき、/schedule で作成するクラウド上の Routines はマシンを起動しておく必要がありません。ただし Routines は現時点でも research preview と明記されており、/loop とは安定性の位置づけが異なります
• 主体的ループは上記に auto mode や dynamic workflows を組み合わせ、人がリアルタイムで介在しない反復業務を構成します
• すべてのタスクに複雑なループが必要なわけではなく、最も単純な方法から始めることが推奨されています

参考

• Getting started with loops — @ClaudeDevs on X（2026年7月7日、執筆: Delba Oliveira 氏） — 本記事の主たる出典。掲載図版はすべて同ポストからの引用（作図: Anthropic）
• Keep Claude working toward a goal — Claude Code Docs
• Run prompts on a schedule — Claude Code Docs
• Automate work with routines — Claude Code Docs
• Orchestrate subagents at scale with dynamic workflows — Claude Code Docs