AIへの任せ方には4段階ある──Claude Code公式「ループ入門」を身近な例で読み解く¶

対象 / ポイント

対象: Claude Codeを単発の指示で使っていて、/goal・/loop・/scheduleの使い分けを整理したい読者。

ポイント:

ループは「停止条件まで作業サイクルを繰り返すこと」と定義できる
4類型は、チェック、停止判断、起動タイミング、指示そのものを順に手放す段階である
出発点は機能選びではなく、自分の仕事を検証手順として言語化できるかの棚卸しである

AIに仕事を任せる難しさは、プロンプトの書き方だけでは決まらない。むしろ詰まりやすいのは、どこまで任せ、どこで止め、どう確かめるかだ。

この記事の問いは、Claude Code公式ブログの4類型を、実務の委任設計としてどう使い分けるかである。

結論: 4類型は「任せ方の4段階」で読める¶

後輩に仕事を頼む場面を思い浮かべる。最初は成果物を毎回自分の目で確かめる。慣れてきたら「この基準を満たすまで自分で直して」と合格ラインだけを渡す。さらに進むと「毎朝これを確認して」と定例化し、最終的には「この業務はもう任せた」になる。

Claude Codeのループも、これと同じ構造で整理できる。 Claude Codeチームは2026年6月30日の公式ブログで、ループを「エージェントが停止条件を満たすまで作業サイクルを繰り返すこと」と定義した¹。「プロンプトではなくループを設計しろ」という言い回しが広がる一方で、肝心の定義は論者ごとにばらついていた。開発元自身が、そこへ共通の物差しを示した形だ。

同ブログはループを4類型に分け、起動のされ方、止まり方、使う機能、向くタスクで特徴づけている。この分類は「人間が何を手放すか」という一本の軸で読むと見通しがよい。

類型	手放すもの	例えるなら	主な機能
ターン制	成果物のチェック	毎回レビューする新人への指示出し	通常のプロンプト + 検証スキル
ゴール制	停止の判断	合格基準を渡し、差し戻しは仕組みに任せる	`/goal`
時間制	起動のタイミング	定例確認や郵便受けの定期確認	`/loop`・`/schedule`
プロアクティブ	指示そのもの	業務を丸ごと委任する	上記すべて + dynamic workflows

すべてのタスクに複雑なループが要るわけではない。公式ブログも、最も単純な解から始め、必要なときだけ高度なループへ進むべきだと釘を刺している¹。以降の各類型も、表の上から順に検討するのが基本線になる。

ターン制ループ──成果物を毎回チェックする¶

「いいねボタンを作って」とClaude Codeに頼む。 Claudeは、指示を受ける、コードを読む、修正する、テストを走らせる、結果を返す、というサイクルを1回転させる。人間はそれを確認し、次の指示を書く。

この一往復が、すでに最小のループである。 Claude Codeのドキュメントも、タスクを受けたClaudeが文脈収集、実行、検証を繰り返す流れをagentic loopとして説明している²。短いタスクなら、これで十分なことが多い。

新人への指示出しと同じで、ボトルネックは往復回数になる。往復を減らす鍵は、提出前のセルフチェックリストを渡すことだ。 Claude Codeでは、人間が手作業で見ていた確認手順をSKILL.mdに書き出せる³。

検証スキルの最小例

---
name: verify-ui-change
description: UI変更を完了報告する前に実行する検証手順
---

1. 開発サーバーを起動し、変更したページを開く
2. 追加・変更した部品を実際に操作する
3. ブラウザコンソールに新しいエラーがないことを確認する
4. 一つでも失敗したら修正し、手順1からやり直す

テスト合格数やスコアのように定量的なチェックであるほど、Claudeは自己検証しやすい。ここで書いた検証スキルは、次のゴール制ループでそのまま合格判定の材料になる。

ゴール制ループ──合格基準を渡す¶

ゴール制ループでは、人間が「もう一回」と言う仕事を減らす。校正を後輩に頼むと、本人の「もう大丈夫だろう」という感覚で作業が戻ってくることがある。合格基準を渡していないからだ。

「誤字ゼロになるまで。ただし見直しは5回まで」と伝えれば、止めるかどうかの判断が本人の感覚から基準に移る。 Claude Codeの/goalは、この仕組みをコマンドとして提供する。

/goal トップページのLighthouseスコアを90以上にする。5回で打ち切り。

公式ドキュメントによれば、/goalはセッション内のprompt-based Stop hookとして動く⁴。 Claudeが1ターンを終えるたびに、条件と会話ログが小さく速いモデルへ送られる。評価モデルが「未達」と判断すれば、その理由を次のターンの手がかりとしてClaudeへ返す。「達成」と判断すれば、ゴールはクリアされる。

有効なのは、テスト合格数、ビルドの終了コード、スコア閾値、空のキューのように機械的に判定できる基準だ。「いい感じに仕上げて」は評価モデルにも判定しにくい。回数や時間の上限は、暴走時の保険になる。

タイマーのように時間で止まるのではない。炊飯器のように、状態で止まる仕掛けだ。基準で止まる仕組みができたら、次は起動する側を手放す番になる。

時間制ループ──起動のタイミングを任せる¶

PRのレビューコメントやCIの失敗は、いつ届くか分からない。届くたびに人間が作業を中断して確認するのは、再配達の宅配便を待って何度も玄関を見に行くのに近い。それなら「見に行く仕事」そのものを渡せばよい。

/loop 10m PRのレビューコメントに対応し、CIが落ちていたら修正する

/loopは、指定した間隔でプロンプトを再実行する⁵。デプロイ監視、PRの見守り、長時間ビルドの確認のように、「いま見ても変化がないかもしれない」仕事に向く。セッション内で動くため、手元の作業文脈をそのまま使える。

ただし/loopは現在のCLIセッションに紐づく。セッションを閉じたり、新しい会話を始めたりすれば止まる。 PCを閉じても動かしたい仕事は、Anthropic管理のクラウド基盤で動くRoutinesに移す。 CLIからは/scheduleで、定期実行のroutineを会話的に作成できる⁶。

コスト面の原則は、確認間隔を監視対象の変化頻度に合わせることだ。 1時間に1回しか変わらないものを5分おきに見る必要はない。起動まで手放すと、残る最後の一枚は指示そのものになる。

プロアクティブループ──業務ごと任せる¶

プロアクティブループは、新しい単機能ではない。ここまでの部品を合成した運用パターンだ。公式ブログはバグ報告対応を例に、スケジュール、ゴール、検証スキル、dynamic workflows、auto modeを組み合わせる形を示している¹。

たとえば、次のような設計になる。

/schedule: 毎時、報告チャンネルを確認する
/goal + スキル: 見つかった報告を全件対応済みにする条件と検証手順を渡す
Dynamic Workflows: トリアージ、修正、レビューを複数エージェントに分担させる
Auto mode: 必要な権限の範囲で、許可待ちによる停止を減らす

プロンプトに落とすと、形はこうなる。

/schedule 毎時: #feedback チャンネルの新規バグ報告を確認する。
/goal 今回見つかった報告すべてがトリアージ・対応・返信済みになるまで止めない。
修正時はワークフローで3案を並行に作成し、審査役エージェントに批判的にレビューさせる。

見逃せないのは、修正案を作る側と審査する側を分けている点だ。生成と評価を分離すると、同じ前提に引きずられた自己採点を減らせる。コンビニの自動発注に近い。売れ行きを定期確認し、閾値で発注し、納品まで検品する仕組みを人間が設計し、あとは監督側に回る。

ただし前提は軽くない。 Dynamic workflowsは、Claudeが書いたJavaScriptで多数のサブエージェントを統括する仕組みであり、コードベース全体の監査、大規模移行、相互検証つき調査に向く⁷。公式ブログも、workflowは数百のエージェントを起動しうるため、大規模実行の前に小さな範囲で使用量を見積もるよう求めている¹。

品質とコストは仕組みで守る¶

任せる範囲が広がるほど、出力品質はプロンプトの気合いでは守れない。公式ブログは、ループの品質を支える周辺システムとして、コードベースの一貫性、検証手段、ドキュメントへの到達性、別エージェントによるレビューを挙げている¹。

失敗への向き合い方も変わる。その場で直して終わりにせず、原因をスキル、規約、チェックリストへ書き足す。「今回だけ直す」から「次の反復が自然に良くなる仕組みに刻む」へ移すことが、ループ設計の本体である。

コスト管理は、境界線の設計に集約される。

定型作業には小さく速いモデルを使い、判断が必要な箇所だけ強いモデルへ寄せる
完了条件と停止条件を具体的に書き、早すぎず遅すぎない着地点を与える
大規模実行の前に、対象の一部だけで小さく試す
手順が決まった作業はスクリプト化し、毎回推論させない
使用量は/usage、引数なしの/goal、/workflowsで確認する

ループは自律性を増やす技術ではある。だが実務上の価値は、むしろ境界を増やす技術にある。どこから先は自動でよいか、どこで止めるか、何を証拠に完了と呼ぶかを先に決めるほど、任せられる範囲は広がる。

まとめ──手放せる順番は決まっている¶

4類型は、並列の選択肢ではない。ターン制のために書いた検証スキルが、ゴール制の合格判定になる。ゴール制の完了条件が、時間制やプロアクティブの停止条件になる。

逆に言えば、検証手順を文章にできない仕事は、どのループにも乗らない。出発点は機能一覧ではなく、自分の仕事の棚卸しだ。人間がボトルネックになっている仕事を1つ選ぶ。検証を文章にできるか、完了を機械的に判定できるか、作業は定期的に発生するか、と問う。

答えがYesになった段まで手放す。小さく回し、詰まる箇所や行きすぎる箇所を観察して直す。 AIへの任せ方は、勘や期待値の問題ではない。チェック、停止判断、起動、指示をどの順に仕組みへ移すかという設計問題である。