第4章: 終わりを誰が決めるのか ── 停止条件の三本柱
朝、コーヒーをいれながらターミナルを覗くと、エージェントが止まっていた。
昨晩、リファクタを一晩中まわすつもりで claude を起動して、寝てしまったやつだ。
最後の画面にはこう書いてある。
Reached max_turns (38). Stopping the agent loop.仕事は終わっていない。 38 ターン目までに何が起きたかをログから追うと、エージェントは 30 ターン目あたりからずっと同じ関数を行ったり来たりしていた。 このまま止めなかったら、おそらく朝までずっと回っていた。
止まったのは、LLM が「終わった」と思ったからではない。 ハーネス側に仕込んであった上限が、外から肩を叩いた からだ。
ループの始め方より、終わり方 のほうが、エージェントの体感を決める。 この章では、その「終わり方」を三本柱で解剖する。
4.1 そもそも、エージェントはなぜ “勝手に止まれる” のか
第3章で見たとおり、think → act → observe を繰り返すだけなら、原理的には 無限に回せる。 ハーネスは「もう一度 think を呼ぶか、抜けるか」を毎ターン判断しているだけだ。
ここで素直な疑問が湧く。
ハーネスは、何を見て「抜けよう」と決めているのか?
答えは思ったよりシンプルで、ハーネス自身は ほとんど判断していない。 判断のほとんどは、LLM に任されている。
具体的には、LLM が tool_use ブロック(道具を呼ぶ命令)を含まない応答を返したら、ハーネスは「あ、終わったんだな」と理解してループを抜ける ── これが基本路線だ。
エージェントの停止は、原則として「LLM 自身が “もう道具を呼ばない” と決めた瞬間」に起きる。 だが LLM の判断は完全ではないので、ハーネス側の上限 と 人間の介入 が必ずバックアップとして要る。 この三本柱が、ループの終わり方をかたちづくる。
ここから、三本柱を順に見ていく。
4.2 第一の柱 ── LLM 自身の自然停止
最も基本の停止経路。
LLM がそのターンの応答で、tool_use ブロックを 一つも含まない、ただのテキスト を返した瞬間にループが抜ける。
具体的には、こういう応答が出たら止まる。
全部のテストが緑になりました。
空配列の境界条件を src/parser.ts の 42 行目と 67 行目で修正しています。Read も Edit も Bash も呼んでいない、純粋な文章だ。
ハーネスは「もうこのエージェントは “話し終えた”」と解釈する。
強み ── LLM 自身が文脈を全部見たうえで、人間に近い「終わったな」感覚で抜けられる。うまく機能すれば、ぴたっと止まる。 弱み ── 判断ミスをそのままループの病として被る。
自然停止が裏目に出る二つの故障(第10章で詳述)
- 早すぎる終了: テスト 1 回で「だいたい直しました」と止まる、3 ファイル頼んだのに 1 ファイルで「完了です」と返す、検証なしで「実装しました」と宣言する
- 止まれない病: 同じファイルを 30 回 Edit してテストは落ち続ける、失敗を観測しているのに同じ手を繰り返す
どちらも LLM の “終わり” 判断が外れている、という同じ設計の表裏。第10章で 三大病 のひとつとして正面から扱う。
つまり、自然停止だけに頼った設計は、両方の事故が起きうる。 だから第二、第三の柱が要る。
4.3 第二の柱 ── max_turns の上限
ハーネスが持つ、強制的な打ち切り装置。 「1 つのユーザー依頼に対して、最大 N 回までしか think を回さない」と決めておく。 N に達した瞬間、LLM がどんな状態でもループを抜ける。
max_turns (max steps)1 つのユーザー依頼に対して、think-act-observe サイクルを最大何回まで回すかの上限。 ハーネスが持つ安全装置 であり、LLM の判断とは独立に効く。 小さすぎると複雑なタスクが途中で打ち切られ、大きすぎると暴走に弱くなる ── 設計判断の塊。
これは LLM の自然停止が 失敗したとき の最後の砦だ。 無限ループに突入したエージェントを、外側から強制的に止める。
設計判断としては、N をどの値にするか がそのままハーネスの性格になる。
| N の傾向 | 強み | 弱み |
|---|---|---|
| 小さい (例: 10〜20) | 暴走しても被害が小さい、課金が読みやすい | 複雑タスクが途中で切られる |
| 大きい (例: 100 以上) | 長いタスクをやり通せる | 暴走したときの被害が大きい(時間・お金・コード) |
| 無制限 | 人間が気付くまで回る | 致命的に危ない、特にクラウド常駐型(第2章) |
歴史的には、AutoGPT 系 OSS の黎明期に「無制限デフォルト」で無限ループ事故が多発したことが教訓として残っている。現代のエージェントが必ず内部上限を持つのはこの記憶の上にある。
max_turns は “賢さ” のためではなく “暴走しないため” の設計。 1 つの判断ミスが N 回分の連鎖事故にならないように、ハーネスが事前に切っておく予算線だ。
「LLM が賢くなれば max_turns は不要になるはず」と思いたくなるが、現実はその逆。 強力になるほど、暴走時の被害も大きくなる ので、上限の重みはむしろ増している。
4.4 第三の柱 ── 人間の介入 (HITL)
最後に、人間 が止める経路。
ターミナルで Esc を押す、別の指示を投げる、承認プロンプトで “No” と答える ── 形はいろいろあるが、本質は同じだ。
HITL (Human in the Loop)ループの中に 人間の判断点 を組み込む設計。ループは原則として自走するが、特定のタイミングで人間に伺いを立てる、または人間がいつでも割り込める導線を持つ。第10章で本格的に扱う。
具体的な顔ぶれを並べると、こうだ。
- 割り込み ──
Escキーで進行中のループを止める(Claude Code、Codex CLI) - 承認プロンプト ── 危険な道具(
Bash、Writeなど)の実行前に「実行しますか?」と聞く - 計画段階での承認 ── 実行に入る前に計画フェーズを挟み、人間が OK を出してから手を動かさせる仕組み(Claude Code の Plan mode が代表例。第9章で詳述)
- Pull Request レビュー ── 変更を一気にコミットせず、PR にまとめて人間がマージ判断する
人間介入の “効きやすさ” は、第2章 2.5 で見た ハーネスの居場所 に強く依存する。手元 CLI とエディタ拡張は Esc や UI で即座に効くが、クラウド常駐型は専用 UI 越しでしか触れないので 後手に回る(プロダクト別の対応は付録A 参照)。だからクラウド常駐型ほど、計画段階の承認や明示的な承認ゲートが重要になる。
4.5 三本柱を 1 枚に並べる
ここまでを 1 枚にまとめる。
- ① 自然停止 は基本路線だが、LLM の判断ミスをそのまま被る
- ② max_turns は暴走の最終防衛線。だが本来やるべきタスクを切ってしまうこともある
- ③ 人間の介入 は最も柔軟で正確だが、人間の集中力に依存し、居場所が遠いほど効きにくい
三本柱は 互いに補い合う関係 にある。どれか一本に頼り切る設計は、ほぼ確実にどこかで事故る。
4.6 プロダクトごとの “終わり方” の重心
同じ三本柱でも、どの柱に体重をかけるか がプロダクトごとに違う。 手元 CLI 中心の Claude Code や Codex CLI は ③ 人間介入の導線を厚く、Cursor は差分プレビューを HITL の主役に置き、Devin は ① + ② に頼って長時間自走、Aider は git コミットを停止単位に据える。 停止戦略の重心はプロダクトで違う(具体的な比較は付録A の比較表を参照)。
手元にいる人は強い。 Claude Code が「ちょっとせかせかと承認を求めてくる」と感じるのは、人間がそばにいることを前提に、人間介入を 積極的に活かす設計 をしているから。
逆に Devin が「ときどき豪快に脱線する」と言われるのは、人間が手元にいないので 自然停止と max_turns に頼らざるを得ない から。距離が遠ければ、止め方も変えるしかない。
ターン内の道具数は停止判断を変えない1 ターンで複数の道具をまとめて呼べる「並列ツール呼び出し」も、停止は ターン単位 で判断されるという原則は変わらない。1 応答に道具が 3 つ並んでいても、ハーネスはその応答に道具呼び出しが含まれているかどうかしか見ていない。並列呼び出しの設計判断そのものは第6章で詳述する。
4.7 結局、誰が終わりを決めているのか
最後に、本章の問いに正面から答える。
ループの終わりを決めるのは、3 人の合議制 だ。
- LLM が「もう道具を呼ばない」と思えば、自然に止まる
- ハーネス が「N ターン回したのでもう止める」と思えば、強制的に止まる
- 人間 が「もう止めて」と思えば、外から止められる
三者のうち誰の声が通りやすいかは、ハーネスの設計と居場所で決まる。 そして、誰の声が一番不安定かといえば、ほぼ確実に LLM だ。
私はこの章を書きながら、自分のチームのレビュー文化を思い出した。 新人が「直しました」と言ってきたとき、シニアが「テストは流した?」と聞く。 これはまさに、新人の自然停止判断を、シニアという ② の上限が確かめている構図だ。
エージェントの設計でも、同じことが要る。 LLM の “終わりました” を、無条件で信じてはいけない。 ハーネスや人間が、その声に 疑いの目 を向ける構造を、設計の中に必ず一本入れておく。
第10章では、この「疑いの目」を HITL という設計パターンとして正面から扱う。
この章の振り返り
- ループ停止の経路は 三本柱: 自然停止 / max_turns / 人間介入
- ① 自然停止 ── LLM が道具を呼ばない応答を返した瞬間に抜ける(基本路線)
- ② max_turns ── ハーネスが持つ強制上限。暴走の最終防衛線
- ③ 人間介入 ──
Esc、承認、Plan mode、PR レビュー。HITL の総称 - 一本だけに頼ると事故る。三本そろってはじめて、安全に止まれる
- プロダクトごとに 重心 が違う ── Claude Code は介入厚め、Devin は長時間自走前提
- 「早すぎる終了」と「無限ループ」は同じ設計の表裏 ── 第10章で本格的に扱う
この章で読めるようになるツイート / ブログ
- 「Claude Code がテストを 1 回流して “直りました” と止まる問題」 → ① 自然停止の早すぎ問題。三本柱のうち ① だけに頼った結果と読める
- 「
max_turnsを引き上げたら無限ループに突入してクラウド請求がえらいことに」 → ② を緩めると、暴走時の被害がそのまま大きくなる典型例 - 「Cursor で
max_turnsを上げたまま放置したら、朝起きたら勝手にコミットが 12 個積まれてた」 → ② を緩めるだけでなく、③ の人間介入をどう仕込むか(承認ゲートやレビュー)もセットで設計しないと、緩んだ ② がそのまま事故になる、と読める
次章からは第Ⅱ部に入り、ループに渡される 「道具」 の側に視点を移す。 LLM はテキスト機械なのに、どうやって「Read を呼べ」のような構造化された命令を出すのか ── function calling の正体を解剖する。