プロンプトから「ループ設計」へ——Claude Codeチームが定義するAIエージェント運用の4類型

「エージェントにプロンプトを書く」のではなく「エージェントが回すループそのものを設計する」。Anthropic の Claude Code チームが公開したこのガイドは、公開直後から急速に広がり、表示は275万を超えた。だがこれは小技集ではない。AI エージェントの仕事が、その場の思いつきの指示から"設計対象"へと産業化していく——SITION が追い続けてきた構造転換の、最も実務的な一断面である。彼らが定義する4つのループ類型と、それを支える品質・トークンの設計原則を、ひとつの構造として読み解く。

■ 「ループ」とは何か——回り続ける仕事の単位

Claude Code チームの定義はシンプルだ。ループとは「停止条件を満たすまで、エージェントが作業サイクルを繰り返すこと」。彼らはこれを、何が起動するか(トリガー)、何が止めるか(停止条件)、どの機能単位(プリミティブ)を使うか、どんなタスクに向くか——という軸で分類する。

見落としがちなのは、あなたが送るプロンプト一つひとつが、すでに小さなループを起動しているという事実だ。Claude は文脈を集め、動き、自分の作業を確認し、必要なら繰り返し、そして応答する。彼らはこれを「エージェンティック・ループ」と呼ぶ。「いいねボタンを作って」と頼めば、コードを読み、編集し、テストを走らせ、動くと判断したものを返してくる。ループは新機能ではない。すでにそこにあるものを、意識して設計するかどうかの話である。

■ 人が指揮するループ——ターンベースとゴールベース

最も基本が「ターンベース・ループ」。トリガーはユーザーのプロンプト、停止条件は「Claude が完了、または追加の文脈が必要と判断したとき」。短く、定常業務ではない作業に向く。質を上げる鍵は検証にある。手動でやっている確認手順を SKILL.md として書き出せば、Claude は自分の作業をより広く自己検証できる。ガイドの例は明快だ——UI 変更を「編集が成功したから完了」で返すな。開発サーバーを立ち上げ、実際にクリックし、前後をスクリーンショットし、コンソールにエラーが増えていないか確かめる。検証が定量的であるほど、エージェントは自分で自分を採点できる。

一度のやり取りで足りないとき効くのが「ゴールベース・ループ」(/goal)。「完了とは何か」を先に定義することで、Claude が「これで十分か」を勝手に判断して早期に止まるのを防ぐ。Claude が止まろうとするたび、評価役のモデルが条件を照合し、満たすまで——あるいは決めた試行回数の上限に達するまで——差し戻す。だから「テストが何本通ったか」「スコアが閾値を超えたか」のような決定的な基準ほど強い。ガイドが挙げる例はこうだ:「/goal ホームページの Lighthouse スコアを90以上にしろ、5回試したら止まれ」。停止判断を、人ではなく基準に手渡す。

■ 人が離れるループ——時間ベースとプロアクティブ

タスクは同じで入力だけが変わる「繰り返し」がある。毎朝の Slack 要約、レビューや CI の付いた PR の追跡。こうした反復には「時間ベース・ループ」(/loop, /schedule)。「/loop 5m 私の PR を確認し、レビュー指摘に対応し、落ちた CI を直せ」のように、一定間隔でプロンプトを再実行する。/loop は自分の PC で走るので、切れば止まる。クラウドへ移してルーティン化するなら /schedule だ。

その先が「プロアクティブ・ループ」。トリガーはイベントかスケジュール、リアルタイムに人はいない。各タスクはゴールを満たせば終わり、ルーティン自体は止めるまで走り続ける。バグ報告、issue トリアージ、マイグレーション、依存更新のような「よく定義された仕事の流れ」に向く。ここで先のプリミティブが合成される——/schedule で定期チェックし、/goal で完了を定義し、スキルで検証手順を書き、ダイナミック・ワークフローで「トリアージ→修正→レビュー」のエージェント群を編成し、auto mode で許可を求めず走らせる。ガイドの合成例はこうだ:「毎時 project-feedback チャンネルのバグ報告を確認。今回見つけた全報告がトリアージ・対応・返信されるまで止まるな。修正時は3つの解法を並列 worktree で試し、判定役に敵対的レビューをさせろ」。(なお /schedule やダイナミック・ワークフローは執筆時点で research preview 扱い。)

■ ループの質を決めるのは「まわりのシステム」

ガイドが繰り返す核心はここだ——ループの出力の質は、その周りのシステムで決まる。挙げられる要点は4つ。

・コードベース自体を清潔に保つ。Claude は既存のパターンと規約に従う。土台が汚れていれば出力も汚れる。

・Claude に自分の作業を検証する手段を与える。「良い」の基準をスキルとして書き起こす。

・ドキュメントに手が届くようにする。最新のベストプラクティスはそこにある。

・レビューは別のエージェントにやらせる。新鮮な文脈を持つレビュアーは、本体エージェントの推論に引きずられずバイアスが少ない。/code-review が使える。

そして最も重要な一文がこれだ——「個々の結果が基準を満たさないとき、その個別の問題を直して終わりにするな。それをルールに取り込み、以後すべての反復のためにシステムを改善しろ」。一度きりの修正で終わらせず、システム側の規約へ昇華させる。この一手間が、自動化を長く回すための背骨になる。

■ トークンという制約——「どこで止めるか」の経済学

最後の軸はコストだ。ダイナミック・ワークフローは数百のエージェントを生む力を持つ。だからループには明確な境界が要る。ガイドの原則はこうだ。

・仕事にプリミティブとモデルを合わせる。小さなタスクに複数エージェントは要らない。速く安いモデルで足りる仕事もある。判断が要る所にだけ最上位モデルを充てる。

・成功と停止の基準を明確にする。「完了」の像がはっきりするほど、Claude は早く——ただし早すぎず——たどり着く。

・大規模実行の前に試走する。まず小さな一切れで使用量を測る。

・決定的な作業はスクリプトにする。手順を推論させるより、走らせる方が安い。

・必要以上の頻度でルーティンを回さない。監視対象が変わる頻度に間隔を合わせる。

使用量は /usage(スキル・サブエージェント・MCP 別)、/goal(引数なしでターン数とトークン量)、/workflows(各エージェントのトークン量・途中停止も可)で可視化できる。設計とは、止め時の経済を握ることでもある。

■ 結び——問われるのは「どこを手放すか」

ガイドの締めくくりは、拍子抜けするほど地に足がついている。「あなたが既にやっている仕事を見よ。自分がボトルネックになっているタスクを一つ選び、どの部分を手放せるか問え。検証チェックは書けるか。ゴールは十分明確か。仕事はスケジュールで届くか」。

「ループ設計」とは、大掛かりな自動化を最初から組むことではない。自分が詰まっている一点を見つけ、そこだけをエージェントに手渡す——検証を、停止条件を、トリガーを。回し、どこで止まりどこで行き過ぎるかを観察し、恐れずに手を入れる。

プロンプトの巧拙を競う時代は、静かに終わりつつある。次に問われるのは、回り続ける「ループ」を人がどう設計するかだ。AI の仕事は、指示から設計へ、職人技から工学へと移る。その変化は、いま個人の開発者の机の上で起きている。

■ 一次ソース ・@ClaudeDevs(著: @delba_oliveira)「Getting started with loops」2026年7月7日 https://x.com/ClaudeDevs/status/2074208949205881033