AIエージェントのループはなぜ止まらないのか — a16zに学ぶ「収束する停止条件」の設計

エージェントは「終わり」を知らない

「朝起きたら、昨夜動かしたエージェントがAPIコストを$300分消費していた」——AIエージェントを実務で触り始めたエンジニアなら、こういったヒヤリ体験を一度は経験しているのではないでしょうか。

実はこれ、エージェントが「壊れている」わけではありません。AIモデルは原理的に無限に生成し続けられます。止まらないのはデフォルト挙動なのです。

この記事で先に結論をお伝えしておきます。「完了」はAIが判断するものではなく、システム設計が生み出す判定である——これがエージェント設計の根本命題です。

本記事を読むと、以下の3点が理解できます。

• AIエージェントのループが止まらない構造的な理由
• a16zが提唱するループを収束させるための4つの設計要素
• 明日から実務に使える停止条件の設計パターン

AIエージェントの「ループ」とは何か

そもそもエージェントループの構造

AIエージェントが自律的に動くとき、その内側では「観察 → 判断 → 行動 → 再観察」という反復が起きています。チャットで1ターン質問して返答をもらう体験とは根本的に異なります。決定的な違いは「自分で次の入力を作る」という点です。

ユーザーがトリガーを引いた後、エージェントは自分で状況を読み、ツールを呼び出し、その結果をもとに次の判断を下します。この自律的なフィードバックループが、長時間稼働を可能にすると同時に、「いつ終わるのか」を曖昧にする原因でもあります。

プロンプトエンジニアリングからループエンジニアリングへ

2026年、エンジニアリングコミュニティに一つの概念転換が起きました。GoogleのAddy OsmaniとClaude CodeのエンジニアBoris Chernyが「ループエンジニアリング」という言葉を定着させたのです。

Chernyはこう表現しています。「もうClaudeにプロンプトを打たない。Claudeに指示するループを走らせている」

この言葉が示す本質は明快です。

• プロンプトエンジニアリング：1ターンの賢さを最大化する技術
• ループエンジニアリング：1000ターンの信頼性を設計する技術

設計の関心が「賢い出力を引き出すか」から「いかに収束する挙動を作るか」へとシフトしました。

なぜ今この論点が重要なのか

コーディングエージェントが実用段階に入り、人間の監視なしで長時間タスクを実行できるようになってきました。それに伴い、失敗のコストが変質しています。以前の失敗は「変な回答が返ってきた」で済みましたが、今の失敗は請求書に直結します。止め時の設計が、純粋な技術課題からビジネスリスク管理の問題に昇格したのです。

a16zが示すループ収束の4要素

a16zは「Knowing When to Stop — The Art of Making a Loop Converge」の中で、ループを収束させるために必要な4つの要素を整理しています。

① 目標状態の定義 — 「改善して」では収束しない

最も根本的な要素です。エージェントが「完了した」と判断するためには、完了状態が機械判定可能な形で定義されていなければなりません。

「UIをもっと良くして」という指示ではループは終わりません。「Google Lighthouseのパフォーマンススコアを90以上にして」と言えば、達成の瞬間がシステムとして観測できます。

目標状態の表現手段として有効なのは、テストスイート、形式仕様、性能制約の数値です。曖昧な目標は無限ループの最大の原因と言っても過言ではありません。

② 現状の観察可能性 — 出力ではなく構造を見せる

「今どこにいるか」をエージェントが正確に把握できないと、改善の方向性が定まりません。

テキスト出力だけを見せても差分は取れません。コードのdiff、DOMツリー、SVGのパス情報など、構造化された現状へのアクセスが必要です。観察できないものは改善できない——これは単純ですが、実装時に見落とされがちな原則です。

③ 局所的な編集能力 — 実務で最も難しい部分

目標と現状が把握できても、編集の粒度が粗すぎると収束が妨げられます。

「特定の関数1つ」を修正できるか、それともリポジトリ全体を書き直してしまうか——この差は致命的です。全体の書き換えは、前のイテレーションで得られた改善を上書きしてしまいます。これでは収束するはずのループが、改善を打ち消し合う振動状態に陥ります。

実務では、ファイルの部分編集ツールやAST（抽象構文木）操作の精度が、収束速度に直接影響します。ツール設計が「局所的な編集能力」を左右するのです。

④ 停止ルール — 外部条件による終了トリガー

そして最後にして最重要の要素が停止ルールです。

テストのパス、制約の充足、閾値スコアの到達、人間の承認——これらは外部条件によるトリガーです。停止の判断をモデル自身に委ねてはいけません。モデルは「まだ改善できる」と判断し続けることができるからです。

「編集可能性 × 検証可能性」フレームワーク

タスクは4象限に分類できる

a16zのフレームワークを実務に落とし込む際、「編集可能性」と「検証可能性」の2軸でタスクを分類すると有用です。

                高検証性
                    ↑
    コード          |    テキスト（評価基準あり）
    （最も収束）    |
←───────────────────┼───────────────────→
低編集性            |                高編集性
    画像生成        |    UI設計
    （最も困難）    |
                    ↓
                低検証性

コードタスクは高編集性・高検証性を兼ね備えており、最もループに適した領域です。テストが自動化されていれば、達成の瞬間を客観的に判定できます。

一方、画像生成は低編集性・低検証性の典型で、収束が最も難しいタスクです。「少し違う」という差分を数値で取ることも、ピクセル単位で修正することも容易ではありません。

収束しにくいタスクを収束させる発想の転換

重要なのは、タスク自体を変えるのではなく表現を変えるという考え方です。

画像生成をループ化したいなら、SVGやBlenderのシーン定義として扱います。XMLやPythonスクリプトであれば差分を取れ、パラメータを数値で修正できます。高編集性・高検証性の象限へ移行できるのです。

文章生成タスクであれば、評価ルーブリックと構造化アウトラインを用意することで検証可能性を高められます。

自分のタスクを診断するチェックリスト：

• イテレーション間で差分を機械的に取れるか
• 合否を自動判定できる評価手段があるか
• 全体を書き直さず部分修正できるか

3つすべてにチェックが入れば、そのタスクはループに適しています。

停止条件の実践的な設計パターン

停止条件の3類型

実際の開発現場では、以下の3類型を必ず並置することがベストプラクティスです。

1. 完了判定（成功条件）

目標状態に達したことを示す判定です。目標テストの連続パス、全サブタスクの完了、閾値スコアの到達がこれに該当します。

2. リソース上限

成功しなかった場合に備えた安全弁です。最大イテレーション数、ツール呼び出し回数、実行時間、トークン予算のいずれかで上限を設けます。

3. 回復不能エラー（エスカレーション）

同一の失敗を3回繰り返したら人間に制御を戻す——このルールは非常に有効です。また、同じ編集を繰り返す「振動状態」を検出した時点で強制終了するロジックも加えるとよいでしょう。

ガバナンス設計の3層モデル

停止条件の設計は、以下の3層で構造化すると管理しやすくなります。

ハード・ガバナンス（物理的上限） 絶対に超えてはいけない最大ステップ数を設定し、緊急停止スイッチを用意します。他の条件がすべて機能しなかった場合の最終防衛線です。

バジェット・ガバナンス（経済的上限） トークン消費量を動的に監視し、予算に応じて動作を変える制御です。消費ペースから残イテレーション数を動的に計算する実装が有効です。

セマンティック・ガバナンス（意味的監視） 反復パターンや行動の内容を解析し、異常を検知します。「同じファイルに同じ変更を3回加えている」「生成結果のdiffがゼロになっている」といった状態を検出したら止める設計です。

実装イメージ（擬似コード）

max_iterations = 50
token_budget = 100_000
consecutive_failures = 0

while True:
    result = agent.step()

    # 1. 完了判定（成功条件）
    if result.tests_passing and result.score >= TARGET_SCORE:
        break

    # 2. リソース上限
    if agent.iteration >= max_iterations:
        raise MaxIterationsExceeded()
    if agent.tokens_used >= token_budget:
        raise BudgetExceeded()

    # 3. 回復不能エラー（エスカレーション）
    if result.failed:
        consecutive_failures += 1
        if consecutive_failures >= 3:
            escalate_to_human(result)
            break
    else:
        consecutive_failures = 0

    # 振動状態の検出
    if agent.is_oscillating():
        escalate_to_human(result)
        break

3種の停止条件をwhileループ内で並置することで、それぞれがバックアップとして機能します。

経済的現実：止め時はコスト設計で決まる

改善は逓減する

エージェントのイテレーションと改善量の関係は、ログ曲線を描きます。最初の数回のイテレーションで成果の大半が生まれ、それ以降は改善が急速に小さくなります。

a16zがLighthouseテストで実施した実験では、67%のトークン消費がゼロ改善に費やされていたという結果が出ています。また、暴走したエージェント1体が気づかれるまでに$50〜$500のAPIコストを消費するケースも報告されています。

「どこまでやるか」を先に決める

この逓減の現実を踏まえると、「品質をどこまで高めるか」ではなく「予算から止め時を逆算する」という発想が合理的です。

例えば「このタスクにトークン10万個を使う」と決めたうえで、そのバジェット内で達成できる最高品質を目指す。目標スコアの設定より先に、コスト上限の設定を行う——この順序の逆転が、実務での暴走防止に有効です。

よくある疑問（FAQ）

なぜAIエージェントは自分で止まれないのか？

完了の判断は「作業」ではなく「判定」です。判定には外部の基準（テスト、スコア、人間の確認）が必要であり、それを設計するのはシステム側の責任です。モデルは「まだ改善できる」と感じ続けることができるため、自律的な停止は期待できません。

ループが止まらないのはエージェントが壊れているから？

違います。停止ルールが設計されていないことが原因です。止まらないのはデフォルト挙動であり、エラーではありません。

コーディングタスクはループに向いている？

最も向いているタスクの一つです。テストスイートが整備されていれば、達成の瞬間を自動判定できます。差分も取りやすく、部分修正も可能——4要素をすべて満たしやすい領域です。

画像生成やUI作成はループ化できない？

できます。ただし、タスクの「表現形式」を変える必要があります。SVGやBlenderシーンとして扱うことで編集可能性を高め、評価ルーブリックを用意することで検証可能性を高めます。

停止条件を厳しくしすぎると品質が落ちない？

トークン予算やイテレーション上限を設けることで、改善の余地を残したまま停止することはあります。しかし逓減曲線を考えれば、上限を超えた追加イテレーションで得られる品質向上はわずかです。コストと品質のバランスは、上限の設定ではなく目標スコアの調整で行うべきです。

次のステップ：ループからグラフへ

ループとは1つのエージェントが繰り返し行動することです。次の段階では、複数エージェントが分業・協調する「グラフ」構造が主流になります。

マルチエージェントのシステムでは「どのノードで止めるか」「どのエージェントからエスカレーションするか」という問いがさらに複雑化します。しかし本質は変わりません。ループを収束させられない設計者は、グラフも収束させられません。ループの設計を習得することは、より高度なマルチエージェント設計への直接的な足がかりになります。

まとめ：明日から実践する3ステップ

本記事の内容を行動に落とし込むために、明日から実践できる3ステップを提示します。

1. 目標状態を機械判定可能な形に書き直す　「改善して」を「テストが全パスした状態」「スコアが90を超えた状態」に変換する。
2. 3類型の停止条件を必ず並置する　完了判定・リソース上限・エスカレーションの3つをセットで設計し、どれか1つだけに頼らない。
3. 逓減曲線を前提に、トークン予算から止め時を逆算する　品質目標より先にコスト上限を設定し、バジェット内での最善を追う。

エージェント設計とは、賢さを足す仕事ではなく終わりを定義する仕事です。

ループが止まらないことに気づいた日が、真のエージェント設計者になる出発点です。

参考リンク

• a16z: Knowing When to Stop — The Art of Making a Loop Converge
• The AI Agent Loop: Architecture and Failure Modes [2026] — Atlan
• Loop Engineering Guide 2026 — AI Builder Club
• ループエンジニアリングとは？ — hexabase
• AIエージェントの無限ループを防ぐ：トークン・ガバナンス実装パターン
• Loop Engineering: A Guide for Engineers — Medium
• ループエンジニアリング入門 — fd-x.co.jp