hdknr blog

エージェントループ設計（4種類のループ）

Claude Code チーム公式ガイドが定義する『停止条件を満たすまでエージェントが作業サイクルを繰り返す』ループの4分類。Turn-based / Goal-based / Time-based / Proactive を委譲の度合いで整理する

概要

Claude Code チームが公開した公式ガイド「Getting started with loops」（2026年6月30日）は、ループを「停止条件が満たされるまで、エージェントが作業サイクルを繰り返すこと」と定義し、実務で使う4種類に分類した。段階が進むごとに人間が手放す範囲が「チェック → 停止条件 → トリガー → プロンプトそのもの」へ広がる。ガイドは「すべてのタスクが複雑なループを必要とするわけではない。まずシンプルな解決策から」と繰り返し釘を刺している。

詳細

4種類のループ

ループ手放すもの使うタイミング使う機能
Turn-basedチェック探索中・意思決定中の短いタスクカスタム検証スキル
Goal-based停止条件完了の姿が分かっている/goal
Time-basedトリガー作業がプロジェクト外でスケジュールに沿って発生/loop、/schedule
Proactiveプロンプトそのもの反復的かつ定型化された業務上記すべて＋dynamic workflows

出力品質を保つ

コードベースを綺麗に保つ／Claude が検証できる手段を与える／ドキュメントに手が届くようにする／コードレビューは別エージェント（新鮮なコンテキストでバイアスが少ない）に任せる。個々の失敗はその場の修正で終わらせず、スキルやドキュメントの更新としてシステム側へ組み込む。

トークン管理

適切なプリミティブとモデルを選ぶ／明確な成功・停止基準／大規模実行前のパイロット／決定論的作業はスクリプト化／必要以上に頻繁に回さない。使用量は /usage・引数なし /goal・/workflows で確認する。

停止条件は測れても収束しない

停止条件が「測れる」ことと、ループが「収束する」ことは別の話である。GMO ペパボの「指摘ゼロになるまで回すレビューループ」は、件数を正しく数えられたのにゼロにならなかった。収束しないループは原因で 3 つに分かれる。

壊れ方症状原因対策
① 止まらない上限まで回り続ける停止条件を機械が Yes/No で判定できない数値や文字列一致に落とす＋反復上限
② 嘘で止まる未達なのに「完了」作る役が自分で採点している採点役（evaluator）を分ける（maker-checker）
③ 振動する直すたびに新しい指摘停止条件に選んだ量に不動点がない不動点のある量を選ぶ

Ralph Wiggum プラグインは完了判定を <promise> タグの中身と --completion-promise の文字列リテラル比較まで落とす。合言葉も --max-iterations も無いと文字どおり無限に走る。反復上限とコスト上限は、収束設計というより収束に失敗したときの火災報知器である。

不動点とは、もう 1 周かけても状態が変わらない点。停止条件を選ぶときの本当の問いは「その条件を満たした状態にもう 1 周かけて、条件は満たされたままか」になる。テスト全緑・型エラー 0 件・Lighthouse ≥ 90 には不動点があり、レビュー指摘ゼロには無い。収束は次の 3 つを満たすときだけ期待できる。

  1. 判定器が決定的か（LLM を判定器にするとここが崩れる。ペパボの実測では指摘の約半分がノイズと的外れ）
  2. 判定器の出力が次の修正の入力になっていないか（レビューは直した箇所が次の観測対象になる）
  3. 条件を満たした状態にもう 1 周かけても満たされたままか

非決定的な判定器しか使えないタスクの逃げ道は 3 つ。

収束しないと分かっているループに要るのは収束条件ではなく止め際の設計である。関係ないリファクタをしない、設計判断が要る指摘は直さず報告する、テスト失敗のリトライは 3 回まで、20 ファイル超のスコープは中断、5 ラウンドで強制終了——どれも「どこで人間に返すか」の線引きになっている。

1 周の中で収束しないなら、収束の対象を周をまたいだ同じ失敗の再発回数に移す手もある。失敗を errors.md などに記録し、同じカテゴリが 3 回出たら CLAUDE.md に再発防止策を書く。再発回数は対策を書けば減ったまま戻らないので、こちらには不動点がある。優先度を frequency × impact × preventability の掛け算で付けると、頻度が低くても重大で防げるものが浮上する。

関連ページ

ソース記事