Claude Code の /loop は「雑に回す」より、終わり方を決めて使う

Claude Code 公式アカウントが X Article で「Getting started with loops」を公開していた。いま X でよく見る「プロンプトを書くのではなく、ループを設計する」という話を、Claude Code チーム自身がかなり実務寄りに整理した記事だ。

この記事で言う loop は、エージェントが停止条件を満たすまで作業サイクルを繰り返すこと。Claude が文脈を集め、編集し、確認し、必要ならもう一度やる。その回し方を、何が起点になるか、何で止まるか、どの Claude Code 機能を使うかで分けている。

結論から言うと、/loop は「Claude を無限に働かせる魔法」ではない。記事全体の主張はもっと地味で、まず一番単純な形から始め、必要なときだけ /goal、/loop、/schedule、dynamic workflows を足していく、というものだ。

まず普通のプロンプトも loop として見る

公式記事では、普通にプロンプトを投げる作業も turn-based loop と呼んでいる。

ユーザーが「いいねボタンを作って」と頼む。Claude がコードを読み、編集し、テストし、動くと思う状態で返す。ユーザーが確認し、必要なら次のプロンプトを出す。これも、ユーザーが各ターンを指示する手動の agentic loop だ。

ここでの改善ポイントは、プロンプトを長くすることではなく、確認手順を skill に落とすこと。たとえば UI 変更なら、dev server を起動してページを開く、ボタンを実際に押す、前後のスクリーンショットを取る、コンソールに新しいエラーがないか見る、という手順を SKILL.md に書いておく。

Claude が自分で測れるチェックほど、ループは安定する。逆に「いい感じに確認して」だと、何を合格にするかが毎回ぶれる。

/goal は「終わり方」を渡す

1ターンで終わらない作業には /goal が向いている。公式記事では goal-based loop として、起点はリアルタイムの手動プロンプト、停止条件はゴール達成または最大ターン数だと整理している。

たとえば日本語なら、こう指定できる。

1
/goal ホームページの Lighthouse スコアを90以上にする。5回試して届かなければ止めて報告する。

元記事の英語例では、こう書かれている。

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

ポイントは、Claude に「どこまでやれば十分か」を判断させすぎないこと。Lighthouse 90点以上、テスト全通過、未対応レビューコメント0件のように、外から判定できる条件があると強い。

公式ドキュメントでも、/goal は完了条件を渡し、各ターンの終わりに evaluator model が条件を満たしたかを確認する仕組みとして説明されている。だから「ホームページをよくして」より「Lighthouse を90点以上にして、5回で止めて」のほうが loop として扱いやすい。

/loop は時間で起きる

書き方は3パターンある。日本語で書くなら、たとえばこうだ。

1
2
3
/loop 5m デプロイが終わったか確認する
/loop デプロイが終わったか確認する
/loop

/loop は time-based loop だ。指定した間隔で同じプロンプトを再実行する。PR確認なら、こういう指定になる。

1
/loop 5m PRを確認し、レビューコメントに対応し、落ちているCIを直す

公式記事の英語例では、こう書かれている。

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

これは「5分ごとに PR を確認し、レビューコメントに対応し、CI が落ちていたら直す」という使い方だ。外部環境の変化を待つ作業に向いている。CI、PRレビュー、デプロイ、キュー処理あたりだ。

ただし、/loop は手元のコンピューター上で動く。PCを落とせば止まる。セッションの外でも残したい定期処理なら、公式記事では /schedule で routine に移すと説明している。

逆に、いま自分で開いて確認できる画面変更には向かない。たとえばローカル開発中のページ表示、ボタンの見た目、文章の差し替えは、ブラウザを更新してその場で見ればいい。/loop が効くのは、CI、レビュー、デプロイのように「いま見てもまだ変わっていないが、数分後には変わるかもしれない」外部状態を待つときだ。

proactive loop は、複数の機能を組み合わせる

公式記事で一番重いのが proactive loop だ。これは人間がその場にいない状態で、イベントやスケジュールを起点に走る。バグ報告、issue triage、移行、依存関係アップデートのように、繰り返し発生し、作業内容がある程度決まっているものが対象になる。

記事では、次の組み合わせが例として出ている。

/schedule で新しい報告を定期確認する
/goal で、その回の完了条件を決める
skill で検証手順を書く
dynamic workflows で複数案を並列に試す
auto mode で許可待ちを減らす

たとえば、1時間ごとにフィードバックチャンネルを確認し、その回で見つかった報告をすべて triage し、必要なら修正し、返信まで行う。バグ修正時は3つの解決策を別 worktree で試し、別の judge agent に厳しく見てもらう。そういう大きな loop だ。

ここまで来ると、単なるコマンドではなく運用設計になる。強いモデルだけで殴るより、安いモデルで振り分け、判断が必要なところだけ強いモデルに回すほうが現実的だという話も出てくる。

品質は loop の外側で決まる

公式記事で一番大事なのは、loop の出力品質は Claude 単体ではなく、その周囲の仕組みで決まるという部分だ。

まず、コードベースが汚いと Claude はその汚さをなぞる。既存パターンや命名、テストの置き方が整っているほど、Claude もそこに寄せやすい。

次に、Claude が自分で検証できる道具を持っているか。テスト、ブラウザ操作、ログ確認、スクリーンショット、Lighthouse、MCP、社内ドキュメントへの導線。人間が毎回やっている確認を skill に落とすほど、turn-based loop でも time-based loop でも品質が上がる。

さらに、別エージェントによるレビューも推奨されている。作業した本人と同じ文脈を持つ agent は、自分の推論に引っ張られやすい。新鮮な文脈の reviewer に見せるほうが、見落としを拾いやすい。

1回の失敗を直すだけでなく、その失敗を次回以降どう防ぐかを skill やチェックに戻す。loop の改善は、個別バグ修正よりそこに意味がある。

token を燃やさないための境界線

loop は便利だが、放っておくと token を燃やす。公式記事では境界線をはっきり引けと言っている。

小さい作業に複数 agent や dynamic workflows は要らない。成功条件と停止条件を具体的にする。大規模に回す前に小さく試す。決定的に処理できる部分はスクリプトにする。監視間隔は、実際に対象が変化する頻度に合わせる。

特にスクリプトの話は実用的だ。毎回 Claude にPDFフォームの埋め方を推論させるより、skill にフォーム入力スクリプトを同梱して、それを実行させたほうが安いし安定する。

使用量を見る道具もある。/usage は skill、subagent、MCP ごとの最近の使用量を分けて見られる。/goal を引数なしで打つと、ここまでのターン数と token 使用量が見える。dynamic workflows なら /workflows で各 agent の使用量を見て、必要なら止められる。

どう使い分けるか

公式記事の整理を、自分用に圧縮するとこうなる。

loop の種類	手放すもの	使う場面	使う機能
Turn-based	確認手順	探索や判断が中心	custom verification skills
Goal-based	停止条件	何をもって完了か決まっている	`/goal`
Time-based	起動タイミング	外部の変化を待つ	`/loop`, `/schedule`
Proactive	プロンプト全体	定型の仕事が継続的に来る	上記全部 + dynamic workflows

最初にやるなら、いきなり proactive loop ではなく、普段自分がボトルネックになっている作業を1つ選ぶのがよさそうだ。確認手順だけ skill にできるか。完了条件を /goal にできるか。外部待ちなら /loop にできるか。定期的に来るなら /schedule にできるか。

このブログ運用ならどう使うか

このブログで言えば、常時起動しているローカル Hugo server の確認に /loop は使わない。ファイル更新で勝手に反映されるので、確認URLを開けば済む。

一方で、GitHub issue を順に消化する作業には /goal が合う。たとえば「open issue を古い順に1件処理し、記事化、Xキュー更新、commit、push、issue close まで終えたら完了。情報が足りなければ止まる」といった条件だ。

PRレビュー待ちや CI 待ちなら /loop が合う。

1
/loop 5m 最新の GitHub Actions を確認。成功したら成功とURLを報告して停止。失敗したらログを読んで原因を要約し、直せる範囲なら修正して停止。

このくらいなら、時間で起きる意味がある。

Claude Code の loop 設計は、強いプロンプトを1回書く話ではない。何を手放すのか、次にいつ起きるのか、何が見えたら止まるのかを決める話だ。そこまで書いて初めて、プロンプトではなく運用になる。

参考

この記事は Codex GPT-5 が執筆しました。