hdknr blog
戻る

Claude Codeチーム公式ガイド「ループ設計」を読み解く — Turn-based から Proactive まで4段階の委譲

はじめに

X（旧Twitter）で、こんな投稿が話題になった。

「ループ設計しろ」って言われるたびにXで調べて余計混乱してる人、これ読んでほしい

Claude Codeチームがエージェントループのガイドを公開した

「停止条件を満たすまでエージェントが作業サイクルを繰り返すこと」をループと定義していて

ループを4種類に分類 ・Turn-based（手動で1ターンずつ） ・Goal-based（/goalで完了条件を指定） ・Time-based（/loopや/scheduleで定期実行） ・Proactive（イベント駆動で自律実行）

ループの出力品質を向上させるための注意点やトークンの使用管理まで網羅されている

— nogu（@_nogu66）

「エージェントにループを設計させる」というフレーズは最近よく見かけるが、人によって定義がバラバラで話が噛み合わないことが多い。この投稿が紹介しているのは、Claude Codeチーム自身が公開した公式ガイド Getting started with loops（2026年6月30日公開、Delba de Oliveira / Michael Segner 著）だ。

このガイドは「ループとは何か」を定義した上で、実務で使う4種類のループを整理し、それぞれの品質管理・コスト管理の方法まで踏み込んで解説している。本記事では、このガイドの内容を実例つきで詳しく読み解く。

「ループ」の定義

ガイド冒頭では、まず現状への違和感が語られている。

「ループを設計しろ」という話がいま盛んだが、Xで『ループとは何か』を突き止めようとすると、バラバラな答えに行き当たる

その上でClaude Codeチームは、ループを次のように定義する。

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

そして各ループタイプを次の4つの軸で分類する。

  1. 何によってトリガーされるか（Triggered by）
  2. どう停止するか（Stop criteria）
  3. Claude Codeのどの機能（プリミティブ）を使うか
  4. どんなタスクに向いているか

ガイドは冒頭でこうも釘を刺している。「すべてのタスクが複雑なループを必要とするわけではない。まずは最もシンプルな解決策から始め、これらのパターンは選択的に使うこと」。ループ設計は目的ではなく手段、という前提が最初に置かれている。

4種類のループの関係を図にすると、次のようになる。

Claude Codeが定義する4種類のループ(Turn-based、Goal-based、Time-based、Proactive)を、トリガー・停止条件・用途とともに左から右へ委譲の度合いが強まる順に並べたフロー図

1. Turn-based loop — 手動で1ターンずつ

もっとも基本的なループで、Claude Codeを普段使っているだけで自然に発生しているものだ。

ガイドはこう説明する。「プロンプトを送るたびに、あなたが各ターンを指示する手動ループが始まる。Claudeはコンテキストを集め、行動し、成果を確認し、必要なら繰り返し、応答する。これをエージェントループと呼ぶ」。

例として挙げられているのは「いいねボタンを作って」という依頼だ。Claudeはコードを読み、編集し、テストを実行し、動作すると思われるものを返す。そして人間が手動でその成果を確認し、次のプロンプトを書く——これがTurn-basedループの基本形になる。

改善のコツ: 検証をスキル化する

Turn-basedループの質を上げる鍵は、人間による確認手順を SKILL.md としてコード化し、Claude自身が最後まで自己検証できるようにすることだとガイドは述べる。「Claudeが結果を見たり、測定したり、操作したりできるツールやコネクタを含めるべきだ。チェックが定量的であるほど、Claudeの自己検証は容易になる」。

ガイドが示す具体例が以下だ。

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.
If any step fails, fix the issue and rerun from step 1 — do not hand back partially verified work.

「UIの変更を、編集が成功したというだけで完了と報告してはいけない」という一文から始まり、開発サーバーの起動、実際の操作、コンソールのエラー確認、Core Web Vitalsの計測までを手順化している。これをスキルとして持たせることで、Claudeは人間のレビュアーがやるのと同じ手順を自分で踏めるようになる。

2. Goal-based loop — /goal で完了条件を指定する

ガイドはこう述べる。「1ターンでは足りないことがある。特に複雑なタスクではそうだ。エージェントは反復できるときの方が上手くいく」。そこで /goal を使い、「完了とは何か」を定義することでClaudeが反復し続ける期間を延ばせる。

仕組みの核心は評価モデル（evaluator model）にある。

成功基準を定義しておけば、Claudeは『これでもう十分か』を自分で判断して早期に打ち切る必要がなくなる。Claudeが停止しようとするたびに評価モデルがその条件を確認し、ゴールが満たされるか、定義したターン数に達するまで作業に差し戻す

だからこそ「テストの通過数」や「一定のスコア閾値のクリア」のような決定論的（deterministic）な基準が効果的だとガイドは強調している。曖昧な基準では、Claudeが「これで十分」と早々に判断してしまうリスクがあるからだ。

具体例:

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

（ホームページのLighthouseスコアを90以上にする。5回試して達成できなければ停止する）

なお /goal を引数なしで実行すると、現在までの試行回数とトークン使用量を確認できる。これは後述するコスト管理の章でも触れられている。

3. Time-based loop — /loop と /schedule で定期実行する

ガイドの説明はこうだ。「反復的なエージェント作業もある。タスクは同じで、入力だけが変わるケース――たとえば毎朝Slackメッセージを要約するような作業だ。また別の作業は外部システムに依存していて、それに対応するシンプルな方法は一定間隔でチェックし、変化に反応することだ。たとえばコードレビューを受けたり、CIが失敗したりするPRのようなケース」。

このような用途向けに /loop が用意されている。「/loop を使うと、一定間隔でプロンプトを再実行するようにClaudeの実行をトリガーできる」。

具体例:

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

（5分ごとにPRを確認し、レビューコメントに対応し、CIの失敗を修正する）

重要な注意点として、ガイドは次のように書いている。「/loop はあなたのコンピュータ上で動くので、あなたがそれを止めればループも止まる。/schedule でルーチンを作れば、ループをクラウドに移すことができる」。つまり /loop はローカル実行、/schedule はそのクラウド常駐版という位置づけになる。

4. Proactive loop — イベント駆動の自律実行

Proactiveループは、これまでの3つのプリミティブに加えて、auto mode やdynamic workflows（研究プレビュー）のような他のClaude Code機能を組み合わせて構成される。ガイドが示す「フィードバック対応」の実例では、次の4要素が組み合わされている。

  1. /schedule（研究プレビュー） — 新しい報告をチェックするルーチンを走らせる
  2. /goal — 完了の定義と、それを検証する手順（スキル）を用意する
  3. dynamic workflows — 各報告をトリアージし、修正し、レビューするエージェントをオーケストレーションする
  4. auto mode — 権限確認で止まらずにルーチンが動き続けるようにする

これらを組み合わせた実例が以下だ。

/schedule every hour: check #project-feedback 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.

（1時間ごとに #project-feedback チャンネルのバグ報告を確認する。今回見つかったすべての報告がトリアージ・対応・返信されるまで止まらない。バグ修正の際は、並列worktreeで3つの解決策を探索し、judgeエージェントに敵対的にレビューさせるワークフローを使う）

この一文だけで、スケジュール起動・ゴール駆動の停止条件・並列worktreeでの複数解探索・judgeモデルによるレビューという、これまで解説してきた要素がすべて組み合わさっているのが分かる。

ループの出力品質を保つには

ガイドは「ループの出力品質は、その周りのシステムに依存する」としたうえで、設計時に意識すべき点を挙げている。

さらに、個別の失敗を直すだけで終わらせず、システム側を改善することが推奨されている。「個々の結果が基準を満たさなかったとき、その場限りの修正で止めず、今後すべての反復のためにシステムへ組み込むことを試みる」。つまり一度きりの修正で終わらせず、スキルやドキュメントの更新としてフィードバックすることで、ループ全体の質が底上げされていく。

トークン使用量の管理

ループはコストと直結する。ガイドは「ループにははっきりした境界が必要」だとして、次のポイントを挙げている。

まとめ表とループの選び方

ガイドの締めくくりとして提示されているのが、4種類のループを一望できる表だ。

ループ手放すもの使うタイミング使う機能
Turn-basedチェック探索中・意思決定中カスタム検証スキル
Goal-based停止条件完了の姿が分かっている/goal
Time-basedトリガー作業がプロジェクト外でスケジュールに沿って発生する/loop、/schedule
Proactiveプロンプトそのもの作業が反復的かつ定型化されている上記すべて＋dynamic workflows

段階が進むごとに、人間が手放す範囲が「チェック → 停止条件 → トリガー → プロンプトそのもの」へと広がっていく構造になっている。

ガイドは最後にこう締めくくっている。「ループを始めるには、すでにやっている作業を見て、自分がボトルネックになっているタスクを1つ選び、どの部分を手放せるか考えてみてほしい。検証手順は書けるか？ ゴールは十分に明確か？ 作業はスケジュールに沿って届くか？」。そして「アイデアが決まったらループを実行し、どこで停滞するか・どこでやり過ぎるかを観察し、遠慮なく改善を重ねてほしい」と結ばれている。

おわりに

「ループを設計する」という言葉が指すものは1つではなく、Turn-based・Goal-based・Time-based・Proactiveという4段階の委譲の度合いとして理解すると整理しやすい。どれも万能ではなく、タスクの性質に応じて選ぶべきものであり、ガイド自身も「まずシンプルな解決策から」と繰り返し釘を刺している。

ループの話をするときは、「どうトリガーされ」「何を根拠に止まり」「何を人間から手放しているのか」の3点を確認すると、話が噛み合いやすくなりそうだ。

より詳しい情報は、Claude Codeの公式ドキュメントにある並列実行・/loop・/schedule・/goal・dynamic workflowsの各ページを参照してほしい。

前の記事
Karpathyが語るAgentic Workの未来：Claude Tag・Opus 4.8・Fable 5から読む「AI同僚」時代
次の記事
自律システムはなぜ自分の欠陥に気づけないのか — Claude Code で自律システムを作るときの5つの教訓