Ratchet Pattern — エージェントを最後までやり遂げさせる方法

Ratchet Pattern

AIエージェントが「完了しました」と言うのに実際は終わっていないなら、エージェントが難しいタスクをスキップするなら、完了の判定を人間ではなく機械にさせたいなら――この記事がその構造を説明する。

「完了しました」

AIエージェントに527個の関数のテストを書くよう指示した。エージェントは作業を終え、こう報告した。

「完了しました。」

実際にテストが書かれた関数は40個。

嘘をついたわけではない。40個をこなした時点で「十分やった」と判断したのだ。難しい関数に当たるとスキップし、もう数個やってから「残りも同じパターンだから大丈夫」と結論づける。

LLMは生成が得意だ。しかし、完了したかどうかの判断は信頼できない。Huang et al.は外部フィードバックなしのLLMの自己修正が性能をかえって低下させうることを実験的に証明した[1]。

ラチェット

ラチェットレンチの歯は一方向にしか噛み合わない。回せば前に進み、離せば止まるが、後戻りはしない。

Ratchet Patternはこのメカニズムをエージェント制御に適用する。このパターンで書かれた検証コードをratchet codeと呼ぶ——一度通過した検証レベルを下回る後退を決して許さないコードだ。

項目 1: 機械的検証 → PASS → 次へ
項目 2: 機械的検証 → FAIL → 再試行（フィードバック付き）
項目 2: 機械的検証 → PASS → 次へ
...
項目 N: PASS → 完了。停止。

三つのルール:

一度に見せるのは一つの項目だけ。
通過しなければ次は開かない。
すべて通過したら停止する。

このルールをCLIで実装すれば、エージェントが知るべきコマンドは一つだけ。next。残りは機械が決める。

40で止まるエージェント、527を完走するラチェット

同じモデル。同じプロジェクト。同じ527個の関数。

自律エージェント:  40 / 527  (7.6%)  — エージェントが「完了」を宣言
Ratchet CLI:     527 / 527 (100%)  — 機械が「まだ487個残っている」と宣言

違いはモデルの性能ではない。「終わり」を誰が決めるかだ。

自律エージェントではLLMが終了を判断する。LLMは楽観的だ。40個やれば「十分だ」と感じる。Cemri et al.による1,600件のエージェント実行追跡分析でも、premature termination（目標達成前の終了宣言）が全体の失敗モードの6.2%を占めた[2]。ラチェットでは機械が終了を判断する。機械は感じない。残りの項目がゼロになるまで「まだ」と宣言し続ける。

一文で定義する

確率的エージェントを決定論的ステートマシンの中に入れる。

役割	担当
生成	LLM
判定	verifier
進行管理	ratchet

多くのシステムは生成、判定、終了判断のすべてをLLMに委ねている。Ratchetはそれを分離する。

五つの原則

1. 終了条件は機械的である

pass/fail。“looks good"ではない。go testが通ればPASS。coverageが100%ならPASS。主観的判断が入り込む余地はない。

2. PASSは不変である

通過した項目は再び開かれない。巻き戻されない。残りの項目数は単調減少する。

remaining_work(t+1) ≤ remaining_work(t)

今日作ったものを明日やり直すことはない。前にしか進まない。これが「24時間エージェント」との根本的な違いだ。終了条件なしに動き続けるエージェントは、今日追加した抽象化を明日削除し、明後日また追加する。ラチェットはそうした振動を許さない。

3. LLMは生成だけを行う

コードを生成し、テストを書き、修正案を提示する — これがLLMの役割だ。何を修正するか、通過したか、次は何か、終わったか — これはすべて機械が決める。LLMはplannerではなくconstrained generatorだ。

4. エージェントの終了判断権を剥奪する

「完了した」をLLMが言えば40で止まる。「完了した」を機械が言えば527で止まる。ラチェットの存在理由はこの一行に要約される。

5. Verifierは決定論的でなければならない

何でもverifierになれるわけではない。

なれる	なれない
`go test`	“looks cleaner”
coverage測定	“seems better”
AST validation	“more scalable”
schema diff	“clean architecture”

Verifierの条件: deterministic、machine-checkable、resumable、localized feedback。この四つを満たさなければ、ラチェットの歯は噛み合わない。

フィードバックがgradient signalになる

ラチェットが単に「pass/fail」だけを返すと、LLMは方向なく修正する。フィードバックが具体的であるほど、LLMの修正は正確になる。

弱いフィードバック:  「テスト失敗」           → LLMが方向なく修正
中間フィードバック:  「coverage 65%」         → LLMがおおまかに補強
強いフィードバック:  「line 41, 44, 70 未カバー」→ LLMが正確にその分岐をカバー

実プロジェクトで検証された数字:

フィードバックなし:  60〜70% coverageで停滞
フィードバックあり:  100%達成（到達可能な関数に限る）

同じモデルだ。「line 41 not covered」という一行がgradient signalの役割を果たす。Chen et al.のSelf-Debug研究は、コンパイラ/ランタイムのエラーメッセージをモデルにフィードバックする反復デバッグがコードの正確性を劇的に向上させることを証明した[3]。

フィードバックの解像度が上がるほど、LLMの修正精度が上がり、ループの反復回数が減り、コストが下がる。

エージェントは死ぬ。進捗は生き残る。

エージェントは必ず落ちる。トークン上限、ネットワークエラー、セッション切断。ラチェットが進捗状態を永続保存すれば、エージェントが死んでも次のエージェントが引き継ぐ。

エージェント A: 関数1〜200を処理 → 停止
エージェント B: next → 201番から再開
エージェント C: next → 401番から再開

エージェントは使い捨てだ。進捗は蓄積される。

Verifierを入れ替えれば別のツールになる

ラチェットは特定の検証器に依存しない。検証器を変えれば別のツールになる。

ラチェット + 検証器	用途
ラチェット + `go test` + coverage	関数単位テスト生成
ラチェット + 構造ルールvalidator	コード構造の整理
ラチェット + hurl pass/fail	APIエンドポイント検証
ラチェット + 仕様クロス検証	SSOT整合性の確保
ラチェット + Toulmin verdict	ユーザー定義ルールの強制

パターンは一つ。検証器がドメインを決める。

問い

あなたのエージェントは、いくつ完了してから「終わりました」と言っただろうか。

それは本当に終わったのか。

「終わり」を決めたのは誰か — エージェントか、機械か。

出典

[1] Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024. arXiv:2310.01798

[2] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Tanay Chopra, Aditya Tiwari, Kurt Keutzer, Aditya Parameswaran, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track. arXiv:2503.13657

[3] Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128

[4] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366

[5] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023. arXiv:2303.17651

[6] Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022. DOI:10.1126/science.abq1158

[7] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. arXiv:2310.06770