なぜあなたのエージェントは止まらないのか Image: AI generated

24/7の自慢

「エージェントを24時間動かしている。」

Xでよく見かける言葉だ。まるでエージェントを長く動かすほど多くの仕事をこなすかのように。まるで人が眠らなければより生産的であるかのように。

だが、この一文を前にして湧くのは感嘆ではなく疑問だ。

「なぜまだ終わっていないのか？」

止まれるシステムこそ健全なシステムである

527個の関数にテストを書く作業をエージェントに任せた。結果はこうだ。

自律エージェント:  40 / 527 完了後に「全部やりました」と宣言
CLIループ:        527 / 527 完走後に終了

CLIループは1時間かかった。24時間ではない。関数を一つ処理し、検証し、通過すれば次へ進み、すべて終われば止まる。このループの核心は速度ではなく、終了条件が機械的に定義されていることだ。

TODO → テスト作成 → カバレッジ測定 → PASS/DONE → 次へ → ... → すべて完了 → 停止

finite. measurable. monotonic. だから収束する。だから止まる。

止まれるということは弱点ではない。健全だという意味だ。

止まらない三つの理由

エージェントが長時間動くというのは、たいてい次の三つのうちのどれかだ。

1. 検証器が弱い

"looks good"
"seems better"
"more scalable"
"clean architecture"

こうしたものは収束基準ではない。主観的な判断だ。go testはpass/failを返すが、「clean architecture」は誰が判定するのか？ 別のLLM？ それは酔っ払った友人に「俺、酔ってる？」と尋ねるようなものだ。

実証がこれを裏づける。コード評価用のLLM審判は、意味が同じコードの表面的な変形にすら偏り、スコアが水増しされたり不当に削られたりし(Moon et al. 2025)、モデルは事例の58.19%で自分の答えを曲げて同調する(SycEval, Fanous et al. 2025)。「looks good」は正答性とは無関係だ。しかも弱い基準は止まらないだけにとどまらない — 測定を目標にすると測定が壊れ(グッドハートの法則; Manheim & Garrabrant 2018)、能力のある推論モデルは課題を正面から解く代わりに検証手続きそのものをハックする(Bondarenko et al. 2025)。

収束基準がなければ終わりはない。

2. 作業の境界がない

"コードベースを改善して"
"アーキテクチャをもっと綺麗に"
"最適化を続けて"

終了条件のない作業だ。人間の開発者でさえ、こうした目標では果てしなくさまよう。エージェントとて変わらない。「改善」は方向であって目的地ではない。

3. エントロピーが補正速度を上回る

最もよくあり、最も狡猾なパターンだ。

エージェントが修正しながら抽象化を追加する。間接参照を入れる。不要な一般化を作る。コードは「より良くなる」ように見えるが、実際には新たなエントロピーが、検証器が取り除く速度よりも速く増大している。

今日作った抽象化を → 明日また取り除き → 明後日また追加する

これは非単調最適化(non-monotonic optimization)だ。前に進んでいるように見えて、その場に留まっている。永久機関のように見えるが、エネルギーを消費しているだけだ。この場合のエネルギーはトークンである。

大規模な実証がこのドリフトを捉えている。Cursorの導入は短期的な速度を上げたが、静的解析の警告とコードの複雑度は持続的に増加し、この蓄積が長期的な速度低下の主因だった(He et al. 2025、807個のオープンソースリポジトリ)。AIが書いた30万件以上のコミットで導入された問題の22.7%が、最新バージョンまで技術的負債として生き残った(Liu et al. 2026)。補正がエントロピーに追いつかないのだ。

探索問題ではなく制約充足問題だ

ここで根本的な観点の違いが浮かび上がる。

「エージェントを長く動かせばより良い結果が出る」というのは、ソフトウェアエンジニアリングを**探索問題(search problem)**として見る視線だ。広い空間を長く探索すれば、より良い解を見つけられるだろうという期待。

だが、ソフトウェアエンジニアリングは本質的に**制約充足問題(constraint satisfaction problem)**だ。

  • 型が合っていなければならない
  • テストが通過しなければならない
  • カバレッジが充足されていなければならない
  • スキーマが一致していなければならない
  • リントルールを守らなければならない

これらの制約をすべて充足すれば終わりだ。「さらに探索」する必要はない。制約を定義し、充足させ、止まること。それがすべてだ。

コードはすでに**機械的に検証可能な領域(machine-checkable domain)**である。コンパイラ、型チェッカー、テスト、カバレッジ、リンター、スキーマ検証 — これらすべてが決定論的検証器だ。これらの検証器が存在するのに、なぜエージェントを果てしなく探索させるのか？

学習研究も同じ方向を指している。ユニットテストのような決定論的検証器を報酬として使えば — 検証可能な報酬(verifiable reward) — 開放型生成よりコードの正確性が高まる(CodeRL, Le et al. 2022; RLTF, Liu et al. 2023)。検証器は探索を狭める道具ではない。そもそもこの問題が探索ではなく充足であることを露わにする証拠なのだ。

良いループの条件

良いエージェントループは五つの段階で閉じる。

1. 作業定義    — 何を達成すべきか (機械的に判定可能な目標)
2. 範囲制限    — 一度に一つの単位 (関数、エンドポイント、ファイル)
3. シンボリック検証  — 決定論的ツールがpass/failを判定
4. 収束        — 通過すれば次へ、失敗すればフィードバックとともに再試行
5. 終了        — 残りの項目がなければ停止

この構造でLLMは3番(生成)だけを担う。残りはすべて機械が行う。とりわけ**「終わり」を機械が決める**ことが核心だ。LLMに終了判断を任せれば、40/527で「全部やりました」と聞かされることになる。

実験も同じ方向だ。LLMに自己批判(self-critique)を付けると、推論・計画課題で性能はむしろ崩壊し、外部の健全な検証器を付けたときにのみ大きく向上する(Stechly et al. 2024)。外部フィードバックのない内在的な自己修正は失敗するか、ときには修正後にかえって悪化する(Huang et al. 2023)。終了をLLMに任せないことには理由がある。

creative writingとコードは違う

一つの例外がある。すべての領域がこうとは限らない。

文章、マーケティング、デザイン — これらの領域は検証器が弱い。「この文は良いか？」を機械的に判定できない。こうした領域では長い探索が意味を持ちうる。エージェントが複数の変形を生成し、人が選ぶやり方だ。

だがコードは違う。コードはすでに決定論的検証器で満ちた世界だ。この世界での長時間の彷徨(wandering)は探索ではなく漂流(drift)である。

問い

あなたのエージェントは今、何時間動いているのか？

それは収束しているのか、それとも漂流しているのか？

止まれるのか？

止まれるのなら、なぜまだ止まっていないのか？

関連記事

さらに読む (外部)

  • Designing agentic loops — Simon Willison. 明確な成功基準と通過するテストスイートがあってこそ、エージェントループは自ら検証して止まる — この記事の建設的な対をなすもの。
  • Building Effective Agents — Anthropic. コーディングがエージェントに理想的な理由は、解答が自動化されたテストで検証可能だからだ — 決定論的検証器が停止信号になる。
  • Termination logic is the underrated design problem in agentic AI systems — Glen Rhodes. 核心となる設計判断はより良いモデルではなく測定可能な終了条件であり、流暢な出力が非収束を覆い隠す「confidence laundering」を警戒する。
  • Harness engineering for coding agent users — Birgitta Böckeler, Thoughtworks. 信頼性はモデルではなく決定論的ツール(computational controls)のハーネスから生まれる — AIベースの推論的制御と区別する。
  • Reward Hacking in Reinforcement Learning — Lilian Weng. 「測定が目標になると、もはや良い測定ではない」 — 弱い検証器を報酬として使うときにプロキシをゲーミングするメカニズムの技術的整理。
  • Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma. 入力トークンが積み重なるほど出力が劣化する — 追加・削除・再追加を繰り返すループが自己修正ではなく自己強化になる機械的な原因。
  • Vibe Coding Will Destroy Your Codebase (But You’re Probably Not Doing It) — Ariel Perez. AIは既存のrigorを増幅する — 低いrigorでは混沌を加速するという、エントロピーが補正を追い越す現象の実務的視点。

出典

終了判定 · 自己検証の限界

  • Stechly et al. “On the Self-Verification Limitations of Large Language Models on Reasoning and Planning Tasks” (2024, arXiv:2402.08115)
  • Huang et al. “Large Language Models Cannot Self-Correct Reasoning Yet” (2023, arXiv:2310.01798)

LLM-as-judge · 自己批判の不信頼性

  • Gu et al. “A Survey on LLM-as-a-Judge” (2024, arXiv:2411.15594)
  • Moon et al. “Don’t Judge Code by Its Cover: Exploring Biases in LLM Judges for Code Evaluation” (2025, arXiv:2505.16222)
  • Fanous et al. “SycEval: Evaluating LLM Sycophancy” (2025, arXiv:2502.08177)

ドリフト · AIコードの複雑度増加

  • He et al. “Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects” (2025, arXiv:2511.04427)
  • Liu et al. “Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild” (2026, arXiv:2603.28592)

検証可能な報酬 · 検証器ベースのコード生成

  • Le et al. “CodeRL: Mastering Code Generation through Pretrained Models and Deep Reinforcement Learning” (2022, arXiv:2207.01780)
  • Liu et al. “RLTF: Reinforcement Learning from Unit Test Feedback” (2023, arXiv:2307.04349)

報酬ハッキング · 仕様ゲーミング

  • Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
  • McKee-Reid et al. “Honesty to Subterfuge: In-Context Reinforcement Learning Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
  • Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
  • Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)