Skip to content
Published on

ループ設計 — 無限ループと早すぎる諦めの間

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

同じ呼び出しを40回繰り返したエージェント

再試行上限のないハーネスで、エージェントが存在しないファイルを40回連続で読もうとした記録を想像してみてください。構成した例ですが、組み立ては現実的です。失敗が例外文字列のまま返ってくるのでモデルは原因を知らず、原因を知らないので同じ試行を繰り返し、上限がないので誰も止めません。反対側の失敗もあります。再試行が0のハーネスは、一時的なネットワークエラー1回で、終えられたはずの課題を捨てます。

ループ設計の目標は、この2つの崖の間に道を通すことです。どれだけ再試行するか、何を根拠に止まるか、詰まったらどこへ上げるか。3つとも、コードとしてデプロイされるハーネスの決定です。

ループはハーネスの心臓です

Anthropicのエージェント構築ガイドの区分を借りると、エージェントとは、モデルが環境からのフィードバックを根拠に次の行動を自分で決めるシステムです。ステップを予測できない開かれた問題に使えという勧めも、コストが膨らみ誤りが蓄積しうるという警告も、理由はループにあります。ツール呼び出しの結果は毎ステップ、現実の根拠を提供しますが、その根拠をどう消費するかはハーネスが決めます。

同じガイドは、最大反復回数のような停止条件を明示せよと勧めます。当たり前の助言に聞こえますが、運用が壊れるのはだいたいこの当たり前の層です。ループの自由度が大きいほど、止まるルールがシステムの安全弁になります。

再試行上限：0も無限も答えではない

再試行は、失敗の種類によって価値が変わる買い物です。一時的な失敗なら数回の再試行が安く課題を救い、構造的な失敗ならどんな再試行も金の無駄です。問題は、モデルがその区別を自力でできないときです。第3回で扱った失敗の返し方がここで再登場します。原因と代替案が返ってくるハーネスでは再試行は別経路の探索になり、例外文字列だけが返ってくるハーネスでは再試行は同じ失敗の買い直しになります。

だから順序が重要です。失敗の返し方を直す前に上限だけ上げると、より高いコストで同じ場所を回るループが手に入ります。上限そのものは、課題の変動性に合わせて低く始め、根拠ができたときだけ上げるのが安全です。

停止条件の3系統：固定ステップ、目標チェック、確信度

止まるルールは大きく3系統です。固定ステップは決めた回数で終えます。実装はタダで予算も予測できますが、終わった課題を握り続けたり、終わっていない課題を手放したりします。目標チェックは止まる条件をコードで書きます。テストが通ったら、成果物がスキーマを満たしたら終了。ループは漏れなくなりますが、目標を検証可能な形で書けなければならないという前払いコストがあります。確信度停止は、どれだけ確信しているかをモデルに尋ね、その値で止まります。

MAX_STEPS = 20  # 課題の複雑さに合わせて調整

for step in range(MAX_STEPS):
    action = model.next_action(context)
    if action.kind == "finish":
        if goal_check(workspace):  # 停止条件はコードで書く
            break
        context.add("goal_check 失敗: テストが2つまだ赤いです")
        continue
    context.add(run_tool(action, retries=3))
else:
    escalate("ステップ上限に到達", summary=context.progress_note())

3系統は排他的ではありません。実務で安全な組み合わせは、目標チェックを主たる停止条件にし、固定ステップを外側の安全弁として置くことです。

確信度ベース停止の落とし穴

確信度停止は魅力的です。目標をコードで書く必要がなく、速くて安い。落とし穴はまさにそこにあります。自己申告の確信度は検証ではなく発話であり、モデルは自信を持って間違えられます。その場合、ループは誤答を抱えたまま正常終了します。失敗が記録に失敗として残らない、いちばん質の悪い失敗です。

確信度を使うなら、役割を変えるのが安全です。停止信号ではなくルーティング信号として。確信度が低ければ、より安い検証をもう一周回すか人間に上げるトリガーとして使い、停止そのものは検証可能な目標チェックに決めさせます。確信は参考資料であって、審判ではありません。

エスカレーション：詰まったら終了、ではなく

停止条件が発動したのに課題が終わっていないなら、次の行き先が必要です。どこにもなければ、ここまでの進行がそのまま蒸発します。行き先は2つです。ひとつは人間です。このとき価値は質問の具体性から生まれます。「詰まりました」ではなく「AとBのどちらのスキーマが正しいですか」のように、進行の要約と選択肢を添えて上げてこそ、人間のひとつの回答がループを再び回します。もうひとつはサブエージェントです。汚れたコンテキストを捨て、きれいなウィンドウで下位問題だけを解き直させるのですが、第2回で見たようにトークンコストが大きい手段です。

Anthropicのマルチエージェントシステムの回顧は、この層の失敗を具体的に並べます。単純なクエリへの過剰投資、終わらない検索、重複作業。処方もループ側です。課題の複雑さに労力を比例させ、委任するときは目標と出力形式と課題の境界を明示すること。エスカレーションは例外処理ではなく、ループ設計の正規部品です。

実際に練習する

ハーネスエンジニアリングRPGのティア3「ループ設計」がこの記事の演習です。再試行なしから上限なしまで4段階の再試行ポリシー、3つの停止条件、3つのエスカレーションを組み合わせると、確信度停止が安く勝つシナリオと、自信を持って間違えるシナリオの両方に出会います。

参考資料

  • Building effective agents — Anthropic, 2024-12-19 — 環境フィードバックで自走するシステムというエージェントの定義、開かれた問題に使えという勧め、コストと誤りの蓄積への警告、最大反復回数のような停止条件を置けという助言がこの記事にあります。
  • How we built our multi-agent research system — Anthropic, 2025-06-13 — 単純なクエリへの過剰投資、終わらない検索、重複作業といったループの失敗例と、課題の境界を明示せよという処方がこの記事にあります。
  • 冒頭の40回繰り返しの話と本文のループのコードは、説明のために構成したものです。
Discuss on Twitter • View on GitHub