Claude Codeのループ、turn/goal/time/proactive をどう使い分けるか

こんにちは。

もるふぉです。

Claude Codeのループ、/loopと/goalしか使ってない、って人が意外と多いんですよね。

公式には4つに分類されていて、それぞれ得意な場面が違います。

全体像と選び方の判断フレームを整理します。

Claude Codeのループとは何か — Delba de Oliveiraさんによる定義

AnthropicのDelba de Oliveiraさん（Michael Segnerさんとの共著）が公開したブログ記事「Getting started with loops」で、Claude Codeのループが4つに整理されています。

この分類をベースに、選び方を実務目線でほぐします。

「停止条件が満たされるまで繰り返す」共通構造

4分類はどれも「Claudeがコンテキストを集めて、実行して、自己チェックして、必要ならもう一周する」という共通の骨格を持っています。

違うのは、誰がトリガーを引くか、何をもって停止するか、この2点だけです。

Claude Codeの4つのループ型と、それぞれが最も効く場面

Turn-based loops — ユーザーが手綱を持つ通常運転

普段Claude Codeにプロンプトを打っているとき、あれがturn-based loopです。

トリガーは人間のプロンプト、停止条件はClaudeが「完了」と判断した時点。

1〜数ターンで終わる標準的な作業に向いています。

コンテキスト整備・実行・自己チェックの1サイクルが、そのまま1ターン。

「Claudeに考えさせながら並走する」用途は、ほぼ全部これで足ります。

Goal-based loops（/goal）— 成功基準を渡して委譲する

/goalコマンドを叩くと、成功基準か上限ターン数のどちらかを満たすまでClaudeが自走します。

トリガーは人間、停止条件は「客観的に検証できるゴール」。

テストが通る、リンターが通る、指定した数値が閾値を超える、といった判定可能な条件に向いています。

turn-basedよりも一段委譲度が上がるぶん、成功基準の書き方がそのまま結果を決めます。

曖昧に書けば、曖昧なまま走ります。

Time-based loops（/loop・/schedule）— 時間と外部イベントに応答

/loopはローカルで動く周期実行、/scheduleはクラウド側に乗せて動かす周期実行（Routinesと呼ばれる仕組み）。

トリガーは時間または外部イベント、停止条件は指定した終了時刻や回数、あるいは条件成立です。

外部システムの監視、日次バッチのようなルーティン、GitHubのIssueが立ったら反応させるといった「継続して見張っておく」タスクに向いています。

Proactive loops — 人間が不在でも動くパイプライン

イベント駆動で自律的に回る、いちばん複雑度の高いループです。

トリガーは外部イベント、停止条件はワークフロー定義の中に埋め込む必要があります。

人間はリアルタイムでは介在しません。

依存関係のアップグレード、バグトリアージ、定期的なコード監査など、「作業内容がある程度パターン化されていて、失敗しても致命傷にならない」領域から入るのが安全です。

Claude Codeのループ使い分け — 判断フローと早見表

まず繰り返しかどうか。

次に検証可能な出口があるか。

最後に人間が近くにいるか。

この3点で4つのうちどれかに落ちます。

よくある選び間違い3パターン（/goal・/loop・proactive）

主観的な完了条件を/goalに設定して無限ループになる

「読みやすくして」「品質を上げて」といった主観的なゴールを/goalに渡すケース。

Claudeはゴール到達を判定できないので、何周でも回り続けます。

直し方は単純で、「テストが通る」「指定ファイルのカバレッジが80%以上になる」のように、検証可能な条件に落とし込むことです。

turn-basedで済むタスクに/loopを重ねてトークンを溶かす

1〜2ターンで終わる作業に、なんとなく/loopを被せてしまうパターン。

周期実行の必要が本当にあるか、自問してから使うのが正解です。

周期性がないなら、普通に会話ターンで済ませたほうがトークンも時間も節約できます。

/usageで消費量を眺めると、原因がだいたい/loopの乱用に集約されてます。

proactive loopを先走って停止設計が曖昧になる

「自動化したい」が先行して、失敗時にどう止めるかを詰めないままproactive loopを走らせるパターン。

人間が横にいない前提の仕組みなので、停止条件と例外時のフォールバックは、turn-basedの5倍くらい丁寧に設計する必要があります。

まずgoal-basedで手動運転して感触を掴んでから、proactiveに寄せると事故が減ります。

ループを安定させる4つの土台（Delba de Oliveiraさんの整理から）

コードベースを整えておく

Claudeは既存のコードから書き方を学習して真似します。

散らかったコードベースの上で走らせるほど、成果物も散らかります。

turn-basedでも影響しますが、/goal以上の委譲度で走らせるときに効き方が跳ね上がります。

Skillに検証ステップを組み込む

SKILL.mdの中に「実行後にテストを走らせる」「lintを通す」といった検証ステップを組み込んでおくと、Claude自身が自己チェックの拠り所を持てます。

goal-basedとproactive loopで特に効きます。

ドキュメントに触れる経路を用意する

社内のフレームワーク仕様や設計方針への参照をSkill経由で渡しておくと、判断の粒度が揃います。

長時間走るループほど「途中で判断を間違えない」ことが重要で、time-basedとproactive loopで大きく効きます。

別エージェントにレビューさせる

/code-reviewのような、別のClaudeにレビューさせる仕組みを噛ませると、書き手側の視界の狭さを補正できます。

proactive loopでは人間の目が入らないぶん、この設計がほぼ必須です。

どこから始めるか — turn-basedを基準に据える

いきなりproactive loopを組もうとして詰まる人が多いんですが、まずはturn-basedで手応えを確かめるのが正解です。

検証可能な出口が見えたらSkillに検証ステップを書き、テストで判定できる状態を作る。

そこまで来て初めて/goalに委譲します。

時間的な繰り返しが必要になったら/loopか/schedule、人手を挟まなくてもよくなったらproactive loop、という順で階段を1段ずつ上がると、停止条件の設計もトークン管理も自然と身につきます。