ループを始める

 (x.com/ClaudeDevs)
13 ポイント 投稿者 GN⁺ 4 시간 전 | まだコメントはありません。 | WhatsAppで共有
  • コーディングエージェントに毎回プロンプトで指示する方式から、停止条件が満たされるまで作業サイクルを繰り返すエージェント運用パターンへ移行中
  • Claude Code チームはループを、トリガー方式、停止方式、使用する primitive、適した作業タイプの4つの基準で分類
  • 主なループの種類は Turn-based、Goal-based、Time-based、Proactive の4つ
  • すべての作業に複雑なループが必要なわけではなく、最も単純な解法から始め、必要に応じてパターンを適用
  • ループの出力品質は周辺システムに左右されるため、コード品質の維持とトークン使用量の管理が重要

ループの定義と分類基準

  • Claude Code チームはループを、停止条件が満たされるまで作業サイクルを繰り返すエージェントと定義
  • ループ分類の4つの基準を提示
    • どのようにトリガーされるか
    • どのように停止するか
    • どの Claude Code primitive を使うか
    • どの種類の作業に最も適しているか
  • 複雑なループが常に必要なわけではなく、単純な解法を優先したうえで、パターンを選択的に使用

Turn-based ループ

  • ユーザープロンプトでトリガーされ、Claude が作業完了を判断するか、追加の文脈が必要になった時点で停止
  • 定期プロセスやスケジュールに属さない短い作業に適している
  • 管理方法は、具体的なプロンプト作成と skills を活用した検証改善によりターン数を減らすこと
  • すべてのプロンプトは、ユーザーが各ターンを指示する手動ループを開始し、これを agentic loop と呼ぶ
    • Claude が文脈収集 → アクション実行 → 作業確認 → 必要に応じて反復 → 応答
    • 例: like ボタン作成を依頼すると、コードを読み、編集し、テストを実行して結果を返し、その後ユーザーが手動で確認して次のプロンプトを書く
  • 検証ステップは、手動手順を SKILL.md としてエンコードすることで、Claude が自ら確認できる範囲を広げられる
    • 結果を見て測定したり操作したりするためのツール・コネクターを含める必要がある
    • 定量的な検証ほど自己検証しやすい

  • SKILL.md の例 (verify-frontend-change)

    • UI 変更を完了と宣言する前にエンドツーエンドで検証するルール
    • 編集が成功しただけで完了報告することを禁止し、人間のレビュアーのように検証
      • dev サーバーを起動後、編集したページをブラウザで開く
      • 変更要素を直接操作（ボタン・入力・トグルをクリック）し、状態変化を確認し、前後のスクリーンショットを取得
      • ブラウザコンソールで新規エラー・警告がゼロであることを確認
      • Chrome Devtools MCP でパフォーマンストレースを実行し、Core Web Vitals を監査
    • ステップが失敗した場合は修正後に1段階目から再実行し、部分的な検証状態で返さない

Goal-based ループ (/goal)

  • リアルタイムの手動プロンプトでトリガーされ、目標達成または最大ターン数到達で停止
  • 検証可能な終了基準を持つ作業に適している
  • 管理方法は、具体的な完了基準と明示的なターン上限の設定、「5回試行後に停止」
  • 1ターンでは不十分な複雑な作業では、エージェントは**反復（iterate）**すると性能が向上
  • /goal で完了状態を定義すると、Claude は「十分によいか」を自分で判断して早期終了しない
    • Claude が停止を試みるたびに evaluator モデルが条件を確認し、目標達成または指定ターン数到達まで再作業
    • 合格したテスト数、特定のスコアしきい値など、決定論的な基準が有効
  • 例
    • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Time-based ループ (/loop と /schedule)

  • 指定された時間間隔でトリガーされ、ユーザーによるキャンセルまたは作業完了（PR のマージ、キューが空になるなど）で停止
  • 反復作業や外部環境・システムとのインターフェースに適している
  • 管理方法は、間隔を長めに設定するか、時間ではなくイベントベースで反応すること
  • 一部の agentic な作業は反復的で、作業内容は同じで入力だけが変わる。例: 毎朝 Slack メッセージを要約
  • 外部システムに依存する作業は、各間隔で確認し、変更に反応する形でインターフェースする。例: コードレビューや CI 失敗が発生する PR
  • /loop はプロンプトを間隔ごとに再実行する
    • /loop 5m check my PR, address review comments, and fix failing CI
  • /loop はユーザーのコンピューター上で実行されるため終了すると止まるが、/schedule で routine を作り、クラウドへ移行できる

Proactive ループ

  • イベントまたはスケジュールでトリガーされ、リアルタイムの人間の介入はない
  • 各作業は目標達成時に終了し、routine 自体はユーザーが停止するまで実行される
  • バグレポート、Issue 分類、マイグレーション、依存関係アップグレードなど、よく定義された反復作業フローに適している
  • 管理方法は、routine をより小さく高速なモデルへルーティングし、判断が必要な部分だけに最も強力なモデルを使うこと
  • 上記 primitive と auto mode、dynamic workflows（research preview）などを組み合わせて、長時間実行されるループを構成

  • フィードバック処理構成の例

    • /schedule（research preview）で新規レポート確認 routine を実行
    • /goal で完了を定義し、skills で検証方法を文書化
    • Dynamic workflows で各レポートの分類・修正・レビューエージェントをオーケストレーション
    • Auto mode で権限確認なしに routine を実行
    • 統合プロンプト例: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

コード品質の維持

  • ループの出力品質は周辺システムに左右されるため、システム設計が重要
  • コードベースを清潔に保つ: Claude は既存コードベースのパターンと規約に従う
  • 自己検証手段を提供: skills でチーム基準の「よい状態」をエンコード
  • ドキュメントへのアクセスを容易にする: フレームワーク・ライブラリのドキュメントには最新のベストプラクティスがある
  • コードレビュー用の second agent を使う: 新しい文脈を持つレビュアーはバイアスが少なく、メインエージェントの推論に影響されにくい。組み込みの /code-review skill または Github 用 Code Review を活用
  • 個別の結果が基準未満の場合、個別 Issue の修正にとどまらず、システム自体を改善するようエンコード

トークン使用量の管理

  • ループには明確な境界が必要であり、次の原則を適用
  • 適切な primitive・モデルを選択: 小さな作業にはマルチエージェントやループは不要。一部の作業には安価で高速なモデルを使う
  • 明確な成功・停止基準を定義: 完了状態を具体化し、早すぎずに到達できるようにする
  • 大規模実行前にパイロット: dynamic workflows は数百のエージェントを生成可能なため、小さな範囲で先に使用量を測定
  • 決定論的な作業にはスクリプトを使用: 手順を推論するよりスクリプト実行のほうが安価。例: PDF skill がフォーム入力スクリプトを提供し、毎回コードを再生成する代わりに実行
  • 必要以上に routine を実行しない: 監視対象の変更頻度に間隔を合わせる
  • 使用量を確認: /usage は skills・subagents・MCPs 別の使用量を分析し、引数なしの /goal は現在のターン数とトークン使用量を表示、/workflows は各エージェントのトークン使用量を表示し、いつでも停止可能

始め方

  • ループ種類別の要約
    • Turn-based: 検証（check）を委任。探索・判断時に使用し、カスタム検証 skills を活用
    • Goal-based: 停止条件を委任。完了状態が分かっているときに使用し、/goal を活用
    • Time-based: トリガーを委任。プロジェクト外部からスケジュールで作業が発生するときに使用し、/loop・/schedule を活用
    • Proactive: プロンプトを委任。反復的でよく定義された作業のときに使用し、上記すべてと dynamic workflows を活用
  • 始めるには、すでに行っている作業を見直し、自分がボトルネックになっている作業を1つ選んで、委任できる部分を判断
    • 検証チェックを書けるか
    • 目標は十分に明確か
    • 作業はスケジュールで届くか
  • アイデアが浮かんだらループを実行し、詰まる箇所や過剰に実行される箇所を観察する。反復的な改善を恐れないこと

関連記事

まだコメントはありません。

まだコメントはありません。