「良いプロンプトの書き方」を追いかける時期は、もう終わっている——という話を前回書いた。今回はその具体化。Claude Codeチーム自身が出した「ループ」の分類と、実践者Addy Osmaniが整理した5つの構成要素を突き合わせ、「毎回のプロンプトを工夫する」から「繰り返しの仕組みを設計する」への切り替え方を見る。
Claude Code公式が定義する4種類のループ（トリガー・停止条件・向くタスク別）と、Addy Osmaniの5つの構成要素（自動化・隔離・知識・連携・検証）を並べた一覧。自分のタスクをどのループ設計に当てはめるかを判断できるようになる。
Claude Codeチームは「ループ」を、エージェントが停止条件を満たすまで作業サイクルを繰り返すことと定義している。1回のプロンプトで完結する作業と何が違うのか——それは「何をもって終わりとするか」を先に設計しておく点にある。
そしてAddy Osmaniはこう言い切る。「プロンプトが上手いかどうかは、もうそれほど重要じゃない。大事なのは、そのプロンプトを勝手に投げてくれるループをどう組み立てるか」。CodexとClaude Codeは、名前は違えど同じ5つの部品を既に持っている、というのが彼の主張だ。
| タイプ | トリガー | 停止条件 | 向くタスク |
|---|---|---|---|
| ターンベース | ユーザーのプロンプト | タスク完了 or コンテキスト不足 | 短期・単発タスク |
| ゴールベース（/goal） | リアルタイムの手動プロンプト | ゴール達成 or ターン上限 | 検証可能な終了基準があるタスク |
| 時間ベース（/loop, /schedule） | 指定した時間間隔 | 手動キャンセル or 作業完了 | 定期作業・外部システム連携 |
| プロアクティブ | イベント/スケジュール（人不在） | 各タスク終了時・ルーチンは継続 | バグ報告の分類、依存関係更新など定型業務 |
ここで大事なのは、タスクの性格が先に決まっていて、それに合うループ種別を後から選ぶという順番だ。「とりあえず/loopで回す」のではなく、終了条件が明確に検証できるタスクなら/goal、定期実行そのものが目的なら/scheduleというように選び分ける。
公式は「大規模実行の前に小さくパイロットする」「/usageで消費を監視する」ことも推奨している。
CodexとClaude Codeは、呼び名は違っても同じ5部品を既に持っている。
スケジュール通りに実行されるタスク。Claude Codeでは/loopやcron、GitHub Actionsで実現する。
複数エージェントが並行作業する際の衝突防止。Claude Codeではgit worktreeで実現し、各エージェントに独立した作業ディレクトリを与える。
プロジェクト固有の知識をSKILL.md形式で文書化しておく。エージェントが毎回ゼロから学び直す手間を減らす。前回の記事で扱ったスキル運用そのもの。
MCPベースの接続で、課題管理ツールやSlack等の外部サービスと統合する。エージェントが実環境で自律的に動けるようにする部品。
コードを書くエージェントと、それをレビューするエージェントを分離するモデル。公式の「独立したコードレビュー」推奨とも一致する。
2つの整理は、同じ地図を別角度から描いている。公式の4分類が「いつ・何をきっかけに回すか」の設計で、Addyの5部品が「その中身をどう組み立てるか」の設計。両方を知っておくと、自分のタスクを迷わずどちらかに当てはめられる。
git worktreeを使う。出典: Claude Blog — Getting started with loops ／ Addy Osmani — Loop Engineering