Loop の設計パターンで大事になる条件設計

ClaudeDevs が出した「Loop の設計パターン」の記事が勉強になったのでシェア

重要なのは「プロンプトを書く力よりも、起動条件・停止条件・検証条件を設計する力が大事になる」こと

ループとは何か 停止条件が満たされるまで、エージェントが作業サイクルを繰り返すこと。

ただプロンプトを投げるのではなく、 ・いつ始めるか ・いつ止めるか ・どう検証するか ・どのタスクに使うか を設計するのが重要。

ループの種類

1. ターンベースのループ 普段のチャット形式の依頼で、短い作業や探索向き。 改善するには、SKILL.md に検証手順を書いて、Claude 自身がブラウザ確認・スクショ・console確認・パフォーマンス確認までできるようにする。

2. ゴールベースのループ /goal 明確な完了条件があるタスク向き。 例:「Lighthouse スコアを90以上にする。最大5回まで試す」

成功条件と試行回数の上限を決めておく。Claude が途中で「これで十分」と勝手に止まるのを防ぎ、条件達成まで反復させられる。

3. 時間ベースのループ /loop ・/schedule 定期的に同じ作業をさせるループ。 例：「5分ごとにPRを確認して、レビューコメントやCI失敗に対応して」

/loop はローカルPC上で動くので、PCを落とすと止まる。クラウドで動かす場合は /schedule を使う。

4. プロアクティブなループ 人間が毎回指示しなくても、イベントやスケジュールで自動実行されるループ。 例：Slack のバグ報告を定期チェック、Issue をトリアージ、修正、レビュー、返信 必要なら複数案を並列 worktree で試すのも有効。

/schedule、/goal、Skill、Dynamic Workflows、Auto Mode などを組み合わせて、長時間の自動処理を作るイメージ。

コード品質を保つには？ ループは便利、ただ放置すると品質が落ちる可能性もある。 重要なのは以下 ・コードベースをきれいに保つ ・ Claude が自己検証できる Skill を用意する ・最新ドキュメントにアクセスできるようにする ・別エージェントにコードレビューさせる ・失敗したら、その場の修正だけでなく、次回以降の仕組みに反映する

トークン使用量を抑えるには ・小さいタスクに複雑な loop を使わない ・成功条件と停止条件を明確にする ・大規模実行前に小さく試す ・決定論的な作業はスクリプト化する ・必要以上に短い間隔で実行しない ・/usage や /workflows で使用量を確認する

https://x.com/suna_gaku/status/2074269384974176372