Claude Codeのループ設計入門｜プロンプトをやめて自走させる4つの型と停止条件

「AIコーディングの上達＝プロンプトが上手くなること」だと思っていないだろうか。いま海外の開発者の間で主題になりつつあるのは、その先にある ループ設計——エージェントを自動で回し続ける「仕組み」の側を作る、という発想だ。火付け役のひとつが、米国時間2026年6月30日にAnthropicが公式ブログへ公開した「Getting started with loops（ループ入門）」という5分ほどの短いガイドである。7月6日には開発者向け公式アカウント @ClaudeDevs がこれをX Articleとして投げ、表示は数日で 260万 を超え、いいね約1.1万・ブックマーク約2.5万を集めた。刺さったのは、冒頭のこの一文だ——「いま『コーディングエージェントをプロンプトする』のではなく『ループを設計する』という話をよく聞くようになった」。

この記事は、その公式ガイドの中身を日本語で噛み砕く。「ループとは結局どういう仕組みなのか」「4つの型はどう使い分けるのか」「暴走させずに回すには何が要るのか」を、Anthropic公式ブログの一次情報を軸に、/goal・/loop・/schedule といった実在のClaude Code機能へ紐づけて整理する。抽象的な宣言で終わらせず、今日から試せる粒度まで降りていく。

いま開発者の間で起きている「プロンプトからループ設計へ」の転換

ガイドの著者はAnthropicの Delba de Oliveira 氏と Michael Segner 氏。冒頭で著者たちは、X上で「ループを設計する」という言葉が飛び交うわりに、その定義がバラバラで掴みどころがない現状を指摘する。そこで公式として、ループを次のように一言で定義した。

ループとは、停止条件を満たすまで作業のサイクルを繰り返すエージェントである。
原文：“loops as agents repeating cycles of work until a stop condition is met”（Anthropic — Getting started with loops, 2026-06-30）

この定義の肝は「停止条件を満たすまで」という部分にある。単発のプロンプトでは、作業が1往復するたびに「続けるか、やめるか」を人間が判断していた。ループはその判断ごと——つまり「もう1周いるか」の決定を——エージェントとシステムに委ねる。人間は毎ターン指示を出す運転席から降り、「いつ止まるか」「何をもって完了とするか」を設計する側へ回る。これが「プロンプトする」から「ループを設計する」への転換の正体だ。

参考までに、この移行を最も率直に言語化したのはClaude Codeの作者であるBoris Cherny氏だ。同氏はWorkOS主催のステージで「私はもうClaudeに指示を出していない。ループが実行されていて、それがClaudeに指示を出し、何をすべきか判断している。私の仕事はループを書くことだ」と述べている（この発言は公式ガイドそのものではなく、別の講演での言葉である点は区別しておく）。今回の公式ガイドは、その空気を「入門」として体系化したものだと位置づけられる。

補足しておくと、今回の発信元である @ClaudeDevs は、Anthropicが運営する開発者向けの公式アカウントだ（プロフィールに「Official updates for developers building with @ClaudeAI」とある）。個人の一開発者が「ループを設計しろ」と煽ったのではなく、モデルとClaude Codeを作っている当事者が、公式の立場から「入門」を示した——この点が今回の反響の大きさを説明している。ツールの作り手自身が推奨する使い方だからこそ、/goal や /loop といったコマンドは机上の概念ではなく、そのまま製品に実装された機能として語られている。

なぜいまこの話が加速しているのか。背景には、Claude CodeやCodexが /loop・/goal・スケジュール実行・worktreeといった「人が席を外しても作業を進める」道具を備えたことがある。回す力が手に入った瞬間、関心は「どう指示するか」から「回り続ける仕組みをどう設計するか」へ移る。当サイトでもこの流れは ループエンジニアリングとは何か で一次ソースを横断して整理しているが、今回の公式ガイドは、その概念をAnthropic純正の道具立てで「入門者向けに」落とし込んだ点に価値がある。

まず、単発プロンプト・cron・ループの三者を並べて、位置関係をはっきりさせておく。

表の右端が示すとおり、ループの特徴は「毎周、中で判断と検証が起きる」ことにある。「結局ただのwhileループでは？」という冷静な問いへの答えもここにある。仕組みとしてはwhileループに近い。だが回すたびにモデルが状態を解釈し、成果を検証し、次を決める——その非決定性と検証が挟まる点で、素朴な反復処理とは別物になる。

そもそもループとは何か ― 「1周」を分解する

「停止条件を満たすまでサイクルを繰り返す」と言われても、その「サイクル1周」で何が起きているのかが見えないと設計はできない。公式ガイドとClaude CodeのAgent Loopドキュメントを踏まえると、1周はおおむね次の4ステップに分解できる。

①今の状態を観測し、②次に何をするかを決め、③実行し、④結果を検証する。そのうえで「もう1周いるか」を停止条件に照らして判定し、必要ならまた①へ戻る。ポイントは、この輪の出口に必ず停止条件が置かれていることだ。停止条件のないループは止まらないか、根拠なく止まる。「回す」設計は同時に「止める」設計でもある、というのがガイド全体を貫く思想である。

料理にたとえると分かりやすい。cronは「タイマーが鳴ったらレシピの次の手順を読み上げる」機械だ。手順は固定で、鍋の中がどうなっていようと同じことを言う。ループは「味見をして、しょっぱければ水を足し、まだ硬ければもう少し煮る」料理人に近い。毎周、状態（味・火の通り）を確かめ、次の一手を選び直す。仕上がり（停止条件＝「この味になったら火を止める」）が満たされるまで、その小さな判断を繰り返す。ループが「台本の再生」ではなく「小さなエンジニアリング工程」だと言われるのは、この意味においてだ。

この「観測→思考→行動」を交互に折り返す構造は、いまに始まった発想ではない。原子的な源流は2022年の論文 ReAct（arXiv:2210.03629）にある。ReActは、言語モデルに「推論（reasoning）」と「行動（acting）」を交互にやらせることで、外界の観測を取り込みながらタスクを進める枠組みを示した。公式ガイドの言う「1周」は、このReActのループに「検証」と「停止条件」を明示的に足したものと読める。つまりループ設計は、真新しい魔法ではなく、研究が示してきた反復構造を、Claude Codeの /goal や /loop という日常の道具に落とし込む作業なのだ。この歴史的な文脈は ループエンジニアリングとは何か でReflexionなどの後続研究まで含めて整理しているので、理論の背骨を辿りたい人はそちらを参照してほしい。

この「1周」の粒度を押さえておくと、次章の4つの型がすっと理解できる。型の違いは、この1周のうち「どこまでを人が握り、どこからをエージェントに手渡すか」の線引きにほかならないからだ。

4つのループ型 ― Turn / Goal / Time / Proactive

公式ガイドの核心は、ループを4つの型に分け、人間の関与が減る順に並べたことだ。著者たちはこの並びを「hand off（手渡し）」の連続として描く。チェック → 停止条件 → トリガー → プロンプト と、人間がやっていた仕事を1つずつエージェントへ手渡していく階段だ。まず全体像を図で掴む。

Turn型 ― 人が毎ループに居る

最も基本的なのがTurn型だ。ユーザーがプロンプトを打ち、Claudeが作業して、完了したと判断したら止まる。人間が毎回「次はこれ」と指示する、いわば会話の延長にあるループである。ここで委譲されているのは「チェック（検証）」だ。たとえば「UI変更を確認してから完了と報告して」という検証手順を SKILL.md に書いておけば、Claudeはその手順に沿って自分の成果を確かめる。人間はまだ運転席に居るが、検証だけはエージェントに任せ始めている段階だ。

Goal型 ― evaluatorに「止めていい？」を採点させる

Goal型からが「ループ設計」の本番になる。/goal コマンドで成功条件を渡すと、Claudeが作業を止めようとするたびに evaluator（採点役）モデル がその条件を照合する。満たしていなければ差し戻し、満たすか、あるいは指定したターン数の上限に達するまで回り続ける。公式が挙げる例はこうだ。

/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
（ホームページのLighthouseスコアを90以上にする。5回試したら打ち切り）

ここで委譲されたのは「停止条件」だ。人間はもう「まだ？もう1回やって」と言わなくてよい。「90以上、5回まで」という条件を一度渡せば、あとはevaluatorが「止めていいか」を判定する。ガイドは「チェックが定量的なほど、Claudeは自己検証しやすい」と述べる。Lighthouse ≥ 90 のように機械的に測れる基準は、「なんとなく良い感じ」という曖昧な判断よりはるかにループと相性がよい。

Time型 ― トリガーをスケジュールに手渡す

Time型は、起動そのものを時間に委ねる。ローカルなら /loop、クラウドなら /schedule を使い、一定間隔でループを起こす。止まるのはユーザーが取り消すか、タスクが完了したときだ。公式の例はこうだ。

/loop 5m check my PR, address review comments, and fix failing CI
（5分ごとに、自分のPRを確認し、レビュー指摘に対応し、落ちているCIを直す）

ここで委譲されたのは「トリガー（起動）」だ。人間が「そろそろPR見て」と声をかけなくても、5分ごとにループが自分で立ち上がる。外部システム（PRの状態、CIの成否）を監視し、変化に反応して働く。反復作業や監視系のタスクが主戦場になる。

Proactive型 ― プロンプトそのものを手渡す

最後のProactive型は、人が居ない状態で自走し続ける。/schedule（起動）と /goal（停止条件）とskills（検証手順）とworkflows（並列化）を組み合わせ、トリガーも停止も実行も、すべてエージェント側に置く。ここで委譲されるのは「プロンプト」——つまり「次に何をやらせるか」という意思決定そのものだ。公式が示す合成例は、この型の到達点をよく表している。

/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.
（毎時 #project-feedback のバグ報告を確認。今回見つけた全報告をトリアージ・対応・
返信し終えるまで止まるな。バグ修正時は、3案を並列worktreeで探索するworkflowを使い、
judgeに敵対的レビューをさせる）

バグトリアージ、大規模なコード移行、依存関係の定期更新——「定常的で、形が決まっている」作業ストリームがProactive型の主戦場だ。各タスクはゴールを満たせば終わり、ルーティン自体は無効化するまで走り続ける。人間の出番は例外時だけになる。ただし、複雑さと引き換えにコストと事故のリスクも最大化するのがこの型でもある。そこで次に、暴走させないためのガードレールを見る。

generatorとevaluator ― ループ設計の心臓部

4つの型を貫いて効いてくる設計原則が、作る役（generator）と採点役（evaluator）を分けることだ。Goal型の /goal はこれを最も明快に体現している。作業するClaude（generator）とは別に、成功条件を照合するevaluatorが立ち、generatorが「終わった」と言うたびに「本当に？」と検算する。自分の成果を自分で採点させると、バグを生んだ盲点のまま甘い自己評価が通ってしまう。役を分けることは、その自己採点バイアスを断つための線引きだ。

この「採点役」を機能させる鍵が、公式が繰り返すルーブリック（採点基準）の定量化だ。「良いUIかどうか」を主観で判定させるのは難しいが、「devサーバを起動し、ページを開き、ボタンを押し、コンソールにエラーが出ず、Core Web Vitalsが基準内」なら機械的に判定できる。ガイドはこの発想を verify-frontend-change という検証skillの例で示している。要約するとこうだ——「UI変更は、編集が成功しただけで完了と報告してはならない。人間のレビュアーがやるように、①devサーバを起動してページを開く、②実際に操作して変化を確認する、③コンソールに新しいエラーがゼロか見る、④パフォーマンスを監査する。どこかで落ちたら直して①からやり直す」。

検証手順を SKILL.md に「コード化された文脈」として書き出しておけば、それは実行をまたいで生き残り、evaluatorの採点基準として何度でも使える。ループの強さは中央のモデルの賢さよりも、この「何をもって良しとするか」を言語化した周辺の設計で決まる。スキルの書き方そのものは Claudeのスキル徹底解説 にまとめているので、検証skillを組む際の入口として合わせて読んでほしい。

ケースで見る：Lighthouse 90を「ループ」で達成する

抽象論だけでは掴みにくいので、公式の例をそのまま1周ずつ追ってみる。/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. を打った瞬間、ループはこう回り始める。

1. ① 観測：まずホームページの現在のLighthouseスコアを測る。仮に72だったとする
   
2. ② 決定：スコアを落としている要因（巨大な画像、レンダリングをブロックするJS、未圧縮のフォント等）のうち、最も効く一手を選ぶ
   
3. ③ 実行：その一手を当てる。画像を遅延読み込みにする、などの修正を実際に書く
   
4. ④ 検証：もう一度スコアを測る。85に上がったとする
   
5. 停止判定：evaluatorが「90以上か？」を照合する。85なので未達 → generatorへ差し戻し、①へ戻る。次の一手（フォント最適化など）を試す

これを繰り返し、スコアが90を超えたら停止する。あるいは「5回試したら打ち切り」の上限に達したら、そこで止めて結果を報告する。ここで効いているのは、停止条件が 90以上 という測れる数字である点だ。もし停止条件が「見た目が速そうになったら」だったら、evaluatorは何を基準に差し戻せばいいか分からず、ループは早すぎる自己満足で止まるか、永遠に回り続けてしまう。ルーブリックを定量にすることは、単なる好みではなく、ループが収束するための必要条件なのである。

暴走させない ― コストと品質のガードレール

ループ設計で最も現実的なリスクは、止まらないループがトークン代を焼き尽くすことだ。公式ガイドは「入門」らしく、派手な自律運用の前に、地に足のついたガードレールを並べている。要点を整理する。

そして、使ったリソースは可視化できる。公式は使用量の確認手段として3つのコマンドを挙げる——/usage（skills・subagents・MCPの内訳）、/goal（ターン数とトークン数）、/workflows（エージェント単位の使用量）だ。回す力を持つなら、いくら使ったかを見る手段もセットで持て、というわけだ。この「止め方・上限・可視化」の思想は、当サイトの ループエンジニアリング解説 が「3つのハードガード（反復上限・差分チェック・スペンドキャップ）がなければ、それはループではなく開いた請求書だ」と警告した論点と、そのまま重なる。

品質面のガードレールも実務的だ。公式は、コードベースを綺麗に保てばClaudeは既存パターンに倣う、検証をskillに書いて基準を明文化する、フレームワークやライブラリのドキュメントにアクセスしやすくしておく、レビューは新しいコンテキストの別エージェントにやらせる（バイアスが少ない）、そして結果が失敗したらその直し方をシステムに刻んで次のイテレーションに活かす、と説く。いずれも「一度きりの成功」ではなく「回すほど良くなる仕組み」を作るための助言だ。自己修復するループの具体例は PlaywrightでE2Eを自己修復させるループ が参考になる。

なかでも「レビューを別エージェントにやらせる」という一点は、地味だが効き目が大きい。作ったエージェントに自分のコードをレビューさせると、生成時の思い込みをそのまま引きずって「問題なし」と結論しがちだ。新しいコンテキストで立ち上げた別のエージェントは、main側の推論に影響されず、素の目でコードを読める。前章のgenerator/evaluatorの分離は、停止条件の採点だけでなく、コードレビューの粒度でも同じ原理で効く——「作る主体と評価する主体を分ける」ことが、ループの信頼性を底上げする共通の設計原則なのだ。

もうひとつ、公式ガイドが「入門」として慎重に扱っているのが、人間の監督をどこまで外すかだ。ガイドには、実行そのものを手放す「auto mode」や、数百のエージェントを並列で走らせる「dynamic workflows」が登場するが、これらはリサーチプレビュー（実験的機能）として紹介されている。つまり、完全な無人運転は「できる」段階ではあっても「いきなり全面的に任せる」ものとしては書かれていない。Proactive型でも、各タスクはゴールで終了し、人間の出番は例外時に残る設計になっている。回す力が強くなるほど、「どこで人間に戻すか（エスカレーション）」を明示的に設計しておくことが、事故を防ぐ最後の砦になる。

日本の開発現場でループ設計をどう始めるか

ここまでの型とガードレールを、日本の開発チームがどう使い始めるか。結論から言えば、「反復する・検証できる・価値がある」の3条件を満たす作業からだ。この3つは、当サイトのループエンジニアリング解説でも「タスクがループ向きかを仕分ける3つの問い」として整理した観点で、公式ガイドの精神とも一致する。

具体的な入口としては、翻訳待ちIssueの消化、Renovate/Dependabotが上げた依存更新PRの取り込みとテスト修正、レビュー指摘の反映などが挙げられる。いずれも「反復・検証可能・価値あり」を満たしやすい。もう少しイメージを具体化すると、たとえば次のような割り当てになる。

手順としては、いきなり無人のProactive型に飛ばないことだ。まずGoal型（/goal）で「条件を満たしたらちゃんと止まる」を体験し、停止条件を書く感覚を掴む。次にTime型（/loop）で「間隔で自動起動する」を試し、最後にProactive型へ——と、委譲を1段ずつ進めるのが安全である。日本語の現場でよくある落とし穴は、停止条件を「良いドキュメントになったら」のように主観で書いてしまうことだ。前章のとおり、evaluatorが機械的に判定できる基準（テスト・型・リンク切れの有無など）に翻訳できるかを、着手前に一度立ち止まって確認したい。翻訳や文章生成のように成否が測りにくいタスクは、「用語集との突き合わせ」「文字数・見出し数の充足」といった測れる代理指標を停止条件に据えると、ループに乗せやすくなる。

「暴走が怖い」という感覚は、むしろ正しくループ設計に向いている。怖い人ほど、停止条件・上限・可視化から先に設計するからだ。回す前に「どこで止まるか」を決める——この順序を守れば、ループは無謀な賭けではなく、地に足のついた自動化になる。ちなみに、ここで触れた /schedule や workflow をチームで束ねて運用に載せる話は、ループエンジニアリング・ツールキット や Claude Code ベストプラクティス に踏み込んだ整理がある。

まとめ ― 増幅器としてのループ

Anthropic公式の「Getting started with loops」は、X上でバラバラに語られていた「ループを設計する」という言葉に、公式としての定義と道具立てを与えた。ループとは停止条件を満たすまで作業サイクルを繰り返すエージェントであり、Turn型・Goal型・Time型・Proactive型の4段階で、人間はチェック→停止条件→トリガー→プロンプトを1つずつエージェントへ手渡していく。その心臓部にあるのは、作る役と採点役を分け、採点基準を定量化することだ。そして「回す」設計は、同時に「止める」設計でなければならない。

見落としてはならないのは、ループが賢さを生み出す魔法ではない、という点だ。ループは、人間が「何をもって完了とするか」に込めた判断を増幅する装置である。良い停止条件・良い検証を込めれば良い成果が増幅され、雑な基準を込めれば雑な成果が大量に増幅される。だからこそ、/goal に渡す条件や SKILL.md に書く検証手順の質が、そのまま成果を左右する。公式ガイドが最後に「恐れずに何度も練り直せ（Don’t be afraid to iterate on it）」と促すのは、この増幅器のチューニングこそが「ループ設計」の実体だからだろう。

誠実に付け加えれば、「ループを設計する」という言葉自体はまだ過渡期にあり、その輪郭は書き手ごとに揺れている。だが今回のガイドが価値を持つのは、その揺れる言葉に対して、モデルとツールを作る当事者が「停止条件を満たすまで繰り返すエージェント」という素朴な定義と、4つの型という実務的な地図を与えた点にある。定義が定まらないうちから道具（/goal・/loop・/schedule）が先に手に入っているのが、いまの局面の面白いところだ。

「プロンプトが上手いこと」が上達のゴールだと思っていた人にとって、これは静かな路線変更だ。上達の先にあるのは、より良い一文を書くことではなく、より良いループを設計すること——そしてその第一歩は、驚くほど小さい。今日、実際に測れる小さな目標をひとつ選び、/goal を一度打ってみる。エージェントが自分で検証し、条件を満たすまで回り、そして「ちゃんと止まる」のを一度見れば、「プロンプトからループ設計へ」という言葉が、抽象論ではなく手触りのある実感に変わるはずだ。

参照ソース

・Getting started with loops（Claude 公式ブログ / Delba de Oliveira・Michael Segner, 2026-06-30）
・@ClaudeDevs — X Article 投稿（Anthropic公式・開発者向け, 2026-07-06）
・How the agent loop works（Claude Code / Agent SDK Docs）
・Firecrawl（Hiba Fathima）— Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops
・Boris Cherny — Acquired Unplugged presented by WorkOS（YouTube, t=705s）
・ループエンジニアリングとは何か（AI Heartland 解説）
・ループエンジニアリング・ツールキット（AI Heartland 解説）