Claude Code でループを使いこなす：入門ガイド

現在、「コーディングエージェントにプロンプトを送る」のではなく「ループを設計する」ことについて多くの議論が行われています。X（旧Twitter）で「ループ」とは一体何なのかを調べてみると、複数の異なる定義に行き当たります。

Claude Code チームでは、ループとはエージェントが停止条件を満たすまで作業サイクルを繰り返すことと定義しています。そして、以下の基準に基づいて、いくつかの異なるタイプのループを分類しています。

• どのようにトリガーされるか
• どのように停止するか
• どの Claude Code プリミティブが使用されるか
• どのタイプのタスクに最も適しているか

ここでは、主要なループの種類、それぞれの使用ケース、そしてトークン使用量を管理しながらコード品質を維持する方法について説明します。すべてのタスクに複雑なループが必要なわけではありません。まずは最もシンプルな解決策から始め、これらのパターンを選択的に使用してください。

ターンベースのループ

• トリガー: ユーザープロンプト。
• 停止条件: Claude がタスクを完了した、または追加のコンテキストが必要だと判断する。
• 最適な用途: 定期的なプロセスやスケジュールに含まれない、短いタスク。
• 使用量管理方法: 具体的なプロンプトを作成し、スキルを使用して検証を改善し、ターン数を削減する。

送信するすべてのプロンプトは、あなたが各ターンを指示する手動ループを開始します。Claude はコンテキストを収集し、アクションを実行し、作業を確認し、必要に応じて繰り返し、応答を返します。これをエージェンティックループと呼びます。

例えば、「いいね」ボタンを作成するよう Claude に依頼します。Claude はあなたのコードを読み、編集を行い、テストを実行し、うまくいっていると判断した結果を返します。その後、あなたは手動で作業を確認し、次のプロンプトを作成します。

手動の確認手順を SKILL.md にエンコードすることで、検証ステップを改善できます。これにより、Claude が自身の作業をエンドツーエンドでより多く確認できるようになります。これには、Claude が結果を見て、測定し、操作できるようにするツールやコネクタを含める必要があります。チェックが定量的であればあるほど、Claude は自己検証を容易に行えます。

例えば、SKILL.md ファイルに次のように指定できます。

1---
2name: verify-frontend-change
3description: UIの変更をエンドツーエンドで検証してから完了と宣言する。
4---
5
6# フロントエンド変更の検証
7編集が成功したという理由だけで、UI変更を完了として報告しないでください。人間のレビュアーと同じ方法で検証してください。
8
91. 開発サーバーを起動し、編集したページをブラウザで開く。
10
112. 変更箇所に直接操作を行う。新しいコントロール（ボタン、入力フィールド、トグル）の場合：クリックして、期待される状態変化を確認し、変更前後のスクリーンショットを撮る。
12
133. ブラウザコンソールを確認する：新しいエラーや警告がゼロであること。
14
154. Chrome Devtools MCP を使用して、パフォーマンストレースを実行し、Core Web Vitals を監査する。
16
17いずれかのステップが失敗した場合は、問題を修正してステップ1から再実行してください — 部分的に検証された作業を戻してはいけません。

ゴールベースのループ (/goal)

• トリガー: リアルタイムの手動プロンプト。
• 停止条件: 目標達成、または最大ターン数に達する。
• 最適な用途: 検証可能な終了条件があるタスク。
• 使用量管理方法: 具体的な完了条件と明示的なターン数の上限を設定する。「5 回試行したら停止」。

特に複雑なタスクの場合、1 ターンだけでは不十分なことがあります。エージェントは反復できるほうがパフォーマンスが向上します。/goal を使用して完了の定義を指定することで、Claude が反復を続ける期間を延長できます。

成功基準を定義すると、Claude は「十分に良い」と判断してループを早期に終了する必要がなくなります。Claude が停止しようとするたびに、評価モデルが条件をチェックし、目標が達成されるか、事前に定義されたターン数に達するまで、Claude を作業に戻します。

これが、合格したテストの数や特定のスコアしきい値をクリアすることなどの、決定論的な基準が非常に効果的である理由です。

例：

1/goal ホームページのLighthouseスコアを90以上にする、5回試行したら停止。

タイムベースのループ (/loop と /schedule)

• トリガー: 指定された時間間隔。
• 停止条件: ユーザーがキャンセルするか、作業が完了する（PR がマージされる、キューが空になるなど）。
• 最適な用途: 定期的な作業、または外部環境/システムとの連携。
• 使用量管理方法: より長い間隔を設定するか、時間ではなくイベントに基づいて反応する。

エージェントによる作業の中には、定期的に発生するものがあります。タスクは同じままで、入力のみが変更されます。例えば、毎朝 Slack メッセージを要約するなどです。また、他の作業は外部システムに依存しており、シンプルな連携方法の一つは、一定間隔でチェックし、変更に反応することです。例えば、コードレビューを受け取ったり、CI が失敗する可能性がある PR などです。

このような場合、/loop を使用して Claude を実行できます。これは、一定間隔でプロンプトを再実行します。例：

1/loop 5m 私のPRを確認し、レビューコメントに対処し、失敗しているCIを修正してください

/loop は自分のコンピュータ上で実行されるため、コンピュータの電源を切ると停止します。/schedule を使用してルーチンを作成することで、ループをクラウド上に移動できます。

プロアクティブループ

• トリガー: イベントまたはスケジュール。リアルタイムの人間の介入なし。
• 停止条件: 各タスクは目標が達成されると終了する。ルーチン自体は、ユーザーがオフにするまで実行され続ける。
• 最適な用途: バグ報告、課題トリアージ、移行、依存関係のアップグレードなど、明確に定義された作業の定期的なストリーム。
• 使用量管理方法: ルーチンをより小型で高速なモデルにルーティングし、最も高性能なモデルを判断が必要な場面に使用する。

上記のプリミティブは、自動モードや動的ワークフロー（研究プレビュー）などの他の Claude Code 機能と組み合わせて、長時間実行される作業のためのループを構成できます。

例えば、受け取ったフィードバックを処理するには、以下を使用できます。

1. `/schedule` （研究プレビュー）を使用して、新しいレポートをチェックするルーチンを実行する
2. `/goal` を使用して完了の定義を指定し、スキルを使用して検証方法を文書化する
3. 動的ワークフローを使用して、各レポートをトリアージ、修正、および修正内容をレビューするエージェントを調整する
4. 自動モードを使用して、ルーチンが許可を求めて停止することなく実行されるようにする

これらを組み合わせると、プロンプトは次のようになります。

1/schedule 毎時: project-feedbackチャンネルでバグ報告をチェックしてください。/goal: この実行で見つかったすべての報告がトリアージ、処理、および応答されるまで停止しないでください。バグを修正するときは、ワークフローを使用して、パラレルワークツリーで3つの解決策を検討し、判定役に adversarially にレビューさせてください。

コード品質の維持

ループの出力品質は、それを取り巻くシステムに依存します。システムを設計する際のポイント：

• コードベース自体をクリーンに保つ: Claude はコードベースにすでに存在するパターンと規則に従います。
• Claude が自身の作業を検証する方法を提供する: スキルを使用して、あなたとあなたのチームにとって「良い状態」とは何かをエンコードします。
• ドキュメントに簡単にアクセスできるようにする: フレームワークやライブラリのドキュメントには、最新のベストプラクティスが反映されている必要があります。
• コードレビューに別のエージェントを使用する: 新しいコンテキストを持つレビュアーは、偏りが少なく、メインのエージェントの推論に影響されません。組み込みの /code-review スキルまたは Github 用の Code Review を使用できます。

個々の結果が基準を満たさなかった場合、個々の問題を修正するだけで止まらず、将来のすべての反復のためにシステムを改善する方法をエンコードするようにしてください。

トークン使用量の管理

トークン使用量を管理するには、ループに明確な境界を設定する必要があります。

• ジョブに適したプリミティブとモデルを選択する: 小さなタスクに複数のエージェントやループは必要ありません。一部のタスクは、より安価で高速なモデルを使用できます。
• 明確な成功基準と停止基準を定義する: 完了の状態を具体的に定義することで、Claude がより早く（しかし早すぎずに）解決策に到達できるようになります。
• 大規模実行の前にパイロットテストを行う: 動的ワークフローは数百ものエージェントを生成する可能性があります。まずは作業のごく一部で使用量を測定してください。
• 決定論的な作業にはスクリプトを使用する: スクリプトを実行する方が、手順を推論するよりもコストが低くなります。例えば、PDF スキルは、Claude がコードを再導出する代わりに毎回実行するフォーム入力スクリプトを提供できます。
• 必要以上に頻繁にルーチンを実行しない: 監視対象の変更頻度に間隔を合わせてください。
• 使用量を確認する: /usage コマンドは、スキル、サブエージェント、MCP ごとの最近の使用量を表示します。引数なしの /goal は、これまでのターン数とトークン使用量を表示します。/workflows は各エージェントのトークン使用量を表示し、いつでもエージェントを停止できます。

はじめに

まとめると、以下のようになります。

ループ

委任するもの

使用する場面

使用する機能

ターンベース

確認作業

探索中、または判断が必要な場合

カスタム検証スキル

ゴールベース

停止条件

完了の状態が明確な場合

/goal

タイムベース

トリガー

プロジェクト外でスケジュールに基づいて作業が発生する場合

/loop

、

/schedule

プロアクティブ

プロンプト

作業が定期的で明確に定義されている場合

上記すべて、および動的ワークフロー

ループを使い始めるには、すでに行っている作業に注目してください。自分がボトルネックになっているタスクを1つ選び、どの部分を委任できるかを検討してください。検証チェックを書けますか？目標は十分明確ですか？作業はスケジュールに沿って届きますか？

アイデアが浮かんだら、ループを実行し、どこで停滞するか、どこで過剰にリーチするかなどの結果を観察し、反復することを恐れないでください。

詳細については、Claude Code のドキュメント（エージェントの並列実行、ループ、スケジュール、ゴール、動的ワークフロー）をご覧ください。

この記事は @delba_oliveira によって執筆されました。