AIエージェントの自律ループ設計｜評価役・停止条件・コスト管理

自律ループ設計とは、人が毎回口を挟まずに、作る・評価する・直すをAIに繰り返させる仕組みの設計。

AIエージェントを自律で回すとき、成否を分けるのは3点に絞られます。出力を判定する「評価役」、暴走を止める「停止条件」、そして予算を守る「コスト管理」。この3つを設計に組み込めているかどうかが、本番で使えるループと、放置すると溶けていくループの分かれ目でした。Anthropicの Claude Code を作った Boris Cherny 氏は、公開イベント（Fortune）で自分の仕事の仕方をこう説明しています。

実際にプロンプトを出しているのは、別のClaudeだ。
出典: Fortune（2026年6月8日、Boris Cherny 氏の発言）

人が毎回指示を出すのではなく、あらかじめ設計した制御経路やAI自身の判断で、作る・評価する・直すを繰り返す。便利な一方で、放っておくと止まらない、間違いを量産する、コストが膨らむ、という難しさが同時に生まれます。この難しさは特定のツールに固有のものではなく、人の確認を挟まずに反復させる構成なら共通して現れます。ここを制御設計でどう抑えるかが本記事の中身です。

自律ループとは何か（単発プロンプトとの違い）

多くの人がAIを使うときは「1回頼んで、1回返ってくる」形です。プロンプトを打ち、返答を受け取り、気に入らなければ自分で打ち直す。次の一手を決めるのは常に人間側でした。

自律ループはこの構図を変えます。次の処理をあらかじめコードで決める構成もあれば、LLM自身に動的に決めさせる構成もあります。前者はワークフロー寄り、後者はエージェント寄りです。ただしどちらの構成でも、「何回まで回すか」「どこで止めるか」という外側の制御は設計側が持つのが基本です（本記事の停止条件と上限はこの外側の設計にあたります）。Anthropicはエージェントを「LLMが自らのプロセスとツール利用を動的に方向づけ、達成方法を自分で制御するシステム」と定義し、事前に決めたコード経路で編成される「ワークフロー」と区別しています。さらに公式は、エージェントを「環境からのフィードバックに基づいてループの中でツールを使うLLM」とも表現します。各ステップでツールの実行結果やコードの出力といった環境からの実測を得て、進捗を自分で評価しながら進む、という仕組みでした。

前提として押さえておきたいのが、Claude など一部のツールで「Skill」と呼ばれる仕組みとの関係です。Skill は再利用できる指示・知識・手順をまとめたもので、複数ステップの手順を丸ごと入れられますし、ツール側が状況に応じて自動で呼び出したり、別のコンテキストで実行したりもできます。つまりループと対立する概念ではなく、ループから Skill を呼ぶことも、Skill の中にループが入ることもあります。役割の違いを表にすると次のようになります。

ループ制御が足しているのは「反復（何度も回す）」と「その反復をどこで止めるかの管理」です。そして、これが価値と難しさの両方を生みます。人が毎回チェックしない前提だからこそ反復で伸ばせる余地がある一方、止め方や評価を設計し忘れると事故につながる、という構造です。

「作る→評価→直す」の輪と、人の役割が監督者に変わる点

ループの骨格は、ひとことで言えば「作る → 評価する → ダメなら直す」の輪です。作った成果物を見て「これでOKか」を判定し、ダメなら作り直させる。この輪を回すのがループの本体でした。

ここで人間の役割が変わります。毎回プロンプトを打つ依頼者から、ループ全体を設計し監督する立場へ。実際、Boris Cherny 氏はある日は数百、日によっては数千から数万のAIエージェントを同時に管理していると語っています。この規模では、人がClaudeに直接プロンプトを出すのではなく、Claude Code がサブエージェント（別のClaude）を持ち、実際にプロンプトを出すのも別のClaudeになります。人は輪の中で手を動かすのではなく、輪の外から仕組みを設計する側に回る、というわけです。

規模の話が示すもうひとつの現実が、コスト効果の大きさです。Cherny 氏は、JavaScript ランタイム Bun を Zig から Rust へ書き換えた事例を引き、人間のエンジニアチームなら約1年かかると見積もられた作業が実際には6日で終わったと述べています。ただしこれは特定の開発者が特定のコードベースで達成した事例で、同じ短縮が別のチームや別のコードベースで再現されるとは限りません。それでも、効き方が大きい場面ほど制御を誤ったときの損失も大きくなる。ここから先の設計が効いてきます。

ループの心臓は「評価役」の置き方

輪の中で一番大事なのは「作る役」ではありません。できあがりを見て合否を判定し、ダメなら作り直させる「評価役（evaluator）」です。人が毎回チェックしないぶん、ループ自身がダメ出しできないと、間違いをそのまま量産してしまいます。逆に評価役が機能していれば、反復によって出力を改善しやすくなります。ただし毎回きれいに良くなるとは限りません。前より悪くなる、良し悪しを行き来する、途中で頭打ちになる、いずれも起こります。改善幅とそれまでの最高スコアを追いながら、どこで切るかを後述の収束判定で決めます。

この構造は、Anthropicがワークフローの型として挙げる「evaluator-optimizer」に対応します。片方のLLMが生成し、もう片方が評価とフィードバックをループで返す形です。同社の分類では、制御を事前のコード経路で固定するこの形はワークフロー側にあり、LLM自身が進め方を決めるエージェントとは区別されています。実務の自律ループは、作る・評価する・直すの輪をコードで固定したうえで、その内側の判断をLLMに任せる形から始めるのが扱いやすい構成です。公式は、明確な評価基準があり、反復的な改善が測定可能な価値を生む場合にこのパターンが有効だとしています。ここで重要なのは「明確な評価基準」という条件。評価役が何を見て合否を出すのかが曖昧だと、ループは何度回しても収束しません。テストが通ったか、指定の形式を満たすか、スコアが閾値を超えたか、といった判定可能な基準を先に決めておくのが設計の第一歩でした。

作る役と評価役を分ける理由もここにあります。同じモデル系列を作る役と評価役の両方に使うと、自分や同系統の出力を高く評価する傾向が出ることがあります。役割を分離し、評価役には「粗探しをする」立場を明示的に与えることで、輪の中に緊張感が生まれます。ただし役割を分けて評価の観点を明確にできても、同じ基盤モデルに共通するバイアスまでは消えません。

ここで注意したいのが、評価は正しいものだと暗黙に前提されやすい点です。合否を決められるのは評価役だけではなく、テストの通過やスキーマ検証、ルールベースのゲート、人の承認を組み合わせることもできます。それでも評価役が主な合否判定を担う構成では、その基準がずれていると、ループは本来の目的ではなく、そのずれた基準を満たす方向へ最適化されます。必ずそこへ収束するとは限らず、退行や振動、頭打ちも起こります。それでも、誤った達成判定が発火すれば、問題のある成果物が「完成」として輪の外に出ていきます。反復回数が増えるほど、誤った基準を強化する機会も増えます。止まらない暴走は目に見えて分かりますが、誤って止まったループは成功と区別がつきません。評価役を置いたら、その評価役自体を疑う手立ても要ります。合否をテストの通過やスキーマ適合のように機械で判定できる形へ寄せる、通過した成果物を定期的に人が抜き取って確かめる、既知の良品と不良品を評価役に通して判定がぶれていないか確かめる——このあたりが実務的な打ち手です。

なぜ1体でなく複数視点の評価役を重ねるのか

評価役は1体で十分とは限りません。1つの視点だけでは見落とす欠陥があるからです。

Anthropicのプルリクエストのレビューは、ロジック・セキュリティ・性能といった異なる観点を持つ複数のClaude（ペルソナの違うチーム）に協働させ、ほぼ全てのバグを捕まえる運用をしていると報じられています。1体のClaudeに採点させるのではなく、視点の違う複数のClaudeに別々の角度で評価させる。セキュリティ担当のClaudeが見るものと、性能担当のClaudeが見るものは違うので、観点を分けるほど取りこぼしは減らせます。ただし同じモデルを使う以上、共通の盲点は重ねても残り、増やすほどの効き目は次第に鈍っていきます。

ただしこれには代償があります。同じレビューは「ほぼ全バグを捕まえるが、とても高価」だとされています。評価役を何重にも置くほどトークンを大量に投じることになるためです。だからこそ、次に扱う停止条件とコスト管理が、評価役の設計とセットで必要になります。評価の厚みと予算のバランスを、どこで折り合わせるかという問題でした。

停止条件の設計（達成・上限・収束と、人へ渡す出口）

ループは1回で終わりません。「完成」を定義しないと、止まらないか、あるいは無駄に回り続けます。Anthropicも、制御を保つために停止条件（例として反復回数の上限）を組み込むことを推奨しています。実務では止め方を1種類に頼らず、複数を組み合わせるのが定石です。

まず達成条件。評価役のスコアが閾値を超えた、テストが通った、といったゴール判定で止めます。ここが本来の「完成して終わる」出口でした。

次に上限。回数・トークン・時間に天井を設ける保険です。達成条件だけだと、ゴールに永遠に届かないケースで止まりません。上限は「望ましい終わり方」ではありませんが、これがないと暴走を物理的に止められない。利用上限やレート制限、自分で設定した予算の天井といった現実的な壁とも直結します。

さらに収束。2回連続で改善がなければ止める、という判定です。スコアが頭打ちになったのに回し続けても、トークンを消費するだけで成果が増えません。改善幅が閾値を下回ったら打ち切る設計が有効でした。

最後にエスカレーション。これは他の3つと並ぶ判定条件というより、止まった後の行き先です。収束したのにゴール未達のとき、同じエラーをN回繰り返したとき、上限に当たって未完成のまま止まったとき——どの止まり方でも人へ渡す先を決めておかないと、止まったまま放置されます。AIだけで解けない問題を延々と回させるより、人へ上げたほうが速い場面は多くあります。

収束判定とエスカレーションの引き際

この中で設計が難しいのが、収束とエスカレーションの引き際です。早すぎれば伸びしろを捨て、遅すぎればコストを溶かします。

収束の目安は、直近2回の改善幅がどちらも閾値を下回ったかどうか。この判定には少なくとも3回分のスコアが要ります。閾値を下回ったら「これ以上は費用対効果が悪い」と判断して止め、そこまでで最高点だった成果物を残します。エスカレーションは、収束したのにゴール未達、あるいは同じエラーを繰り返しているとき。AIが同じ壁に何度もぶつかっている状態は、追加の反復ではなく別の情報や人の判断が要るサインでした。ここを機械的に「N回同じ失敗で人へ」と決めておくと、無限リトライを避けられます。

コスト管理と暴走防止（ドリフトとスクリプトの使い分け）

自律ループのコストは、反復と並列で一気に膨らみます。1回の反復ごとにモデルを呼ぶため、消費トークンは反復回数とともに増えます。しかもやり取りの履歴を積んだまま渡す実装では、1反復あたりの入力も回を追うごとに膨らむので、伸び方は回数に比例よりきつくなります（毎回「最新の成果物と指摘だけ」を渡す設計にすれば、ほぼ比例に近づきます）。Anthropicも、エージェント型システムはより良いタスク性能のためにレイテンシとコストを引き換えにすることが多く、そのトレードオフが妥当かを開発者が慎重に検討すべきだとしています。

コストの捉え方について、Boris Cherny 氏の視点が参考になります。昔のAIサブスク料金と比べるのではなく、同じ作業をエンジニアがやったら幾らかかるかと比べろ、という考え方です。先ほどの Bun 書き換えのように、約1年と見積もられた作業が6日で終わる例もあり、人件費換算で見れば割に合う場面は多い。とはいえ、それは「成果が出れば」の話。成果を出さずに回り続けるループは、ただの浪費でした。

浪費の主因のひとつが「ドリフト」です。ループでは各ステップが前の出力に乗るため、初期の小さなズレが後工程で拡大していきます。最初の1手で少し方向がずれると、それを土台に次が積み上がり、10手後には大きく脱線している、という連鎖です。対策は2つ。ひとつは評価基準のカバー範囲を見直すことです。テストが通るかだけを見る評価役は、要件からの逸脱や設計方針のずれを検出できません。検出されない次元のズレは何度回しても残り、そのまま次の反復の土台になります。ドリフトは「評価役がいない」ときではなく「評価役が見ていない次元」で起きる、と考えるほうが実態に合います。もうひとつは、毎回同じ結果でよい決め打ちの処理を、AI判断ではなくスクリプトで固定することです。

固定できる工程をAIに毎回考えさせるのは、コストの無駄でありドリフトの温床でもあります。ファイルの読み込み、決まった形式への変換、定型のバリデーションといった「答えが毎回同じ」処理は、コードで書いてしまうほうが速く、安く、安定します。判断が要る部分だけAIに任せる、という切り分けが効いてきます。

なお、外部APIを長時間叩くようなループでは、タイムアウトと再試行、データ分割の設計も欠かせません。数MB規模の大きなレスポンスを1回で処理しようとすると、メモリと処理時間が膨らみ途中で落ちやすくなります。呼び出しに適切な再試行の設定を入れ、大きなデータは分割して流す。こうした地味な制御が、ループを止めずに回し続けるための土台になります。Claude Code を無人で回す際の死活監視やリトライ設計については、別記事で詳しく扱っています。

ループの基本構造を、概念イメージとして最小の擬似コードで示します。

# 自律ループの基本構造（概念イメージ）
def run_loop(task):
    result = agent.run(task)                       # 作る役
    scores = []
    best_result, best_score = result, float("-inf")
    for attempt in range(1, MAX_EVALS + 1):        # 上限（評価の回数）
        score, feedback = evaluator.check(result)  # 評価役が合否と指摘を返す
        scores.append(score)
        if score > best_score:                     # 過去最高の成果物を保持する
            best_score, best_result = score, result
        if score >= THRESHOLD:                     # 達成条件で止める
            return result
        # 2回連続で改善幅が閾値未満なら収束。2区間を比べるのでスコアは最低3件必要
        if len(scores) >= 3 and converged(scores):
            break
        if attempt == MAX_EVALS:                   # 最終評価の後に未評価の修正版を作らない
            break
        result = agent.revise(result, feedback)    # 直す
    # 最新版だけでなく、過去最高の成果物と履歴も渡す
    escalate_to_human(best_result=best_result, latest_result=result, scores=scores)
    return None

実際の実装ではモデル名や閾値、再試行の設定が加わりますが、輪の骨格はこの形です。上限・達成・収束・エスカレーションが、すべてこの短い枠の中に置かれている点を確認してみてください。

数百エージェント並列時の隔離とログ要約

数百から数千のエージェントを同時に回す規模になると、コストとは別に「安全」と「見通し」の課題が出てきます。

並列で回す構成では、各エージェントに独立した実行コンテキストと権限を与え、親には要約だけを返す形が要点になります。実装例として、Claude Code のサブエージェントは、各自が独立したコンテキストウィンドウ、独自のシステムプロンプト、個別の権限で動作し、親には要約（結果）だけを返します。この設計がまず解くのは、親のコンテキストが探索ログで埋まる問題です。親に残るのが要約だけになるぶん、以降のやり取りで毎回積み直される履歴が小さくなり、親側のトークンも膨らみにくくなります。一方で、新しいサブエージェントを起動するたびに親の会話履歴はそのまま引き継がれないため、必要な前提を取り直すコストが生じます。同じ前提を何度も共有するような作業では、総トークンがかえって増えることもあります。ただし既存のサブエージェントを再開する構成や、永続メモリを持たせる構成では、毎回まったくの初期状態から始まるとは限りません。コストで効くのは、探索のような下働きを安価で高速なモデルへ振り分ける部分です。大量に回すときは、探索の途中経過を親に流さないことと、下働きを安いモデルに寄せることを分けて設計すると、コンテキストと費用の両方が読めるようになります。

安全面では、自律で回すほど人間の確認が挟まらないため、隔離環境（サンドボックス）で動かし、不正な指示に強い最新のモデルを使い、「何を任せ何を人に残すか」の線引きを決めるのが定石です。全自動イコール安全ではありません。Anthropicは、全ての権限確認をスキップする --dangerously-skip-permissions を「ほとんどの状況で危険」とし、より安全な auto mode ですら「慎重な人間レビューの置き換えにはならない」と明言しています。実際、auto mode の権限判定分類器についてAnthropicは、見逃しを拾うために過剰行動のケースを厳選した52件の評価セットで偽陰性率17%、実際の内部トラフィックでは偽陽性率0.4%という数字を公表しています。前者は難しい例を集めた試験での値なので実運用の見逃し頻度そのものではなく、後者は正当な操作をほぼ止めないことを示す値。母集団が違うので、同じ土俵の表裏として読むものではありません。それでも、この52件の評価セットでは17%を見逃しており、少なくともこの試験では見逃しがゼロではありませんでした。Anthropic自身も、高リスクな作業について「慎重な人間レビューの置き換えにはならない」と明言しています。

ループを観測する（observabilityの観点）

評価役と停止条件をどれだけ丁寧に設計しても、それらが本番で正しく効いているかは、観測しないと分かりません。ループはブラックボックスになりやすい。中で何が起きているかを見えるようにする仕組みが、observability（可観測性）です。

何を見るべきかを先に決めておきます。各ステップの入力と出力、反復回数、消費トークン、そしてエスカレーションの頻度。反復回数が想定より多ければ収束条件が甘い、トークンが跳ね上がっていればどこかで暴走している、エスカレーションが多発していれば任せる範囲が広すぎる、といった診断が、これらの信号から読み取れます。設計した停止条件が机上の空論になっていないかを、実データで確かめる作業でした。

本番のエージェントループを可視化するために、LLM・エージェント専用の可観測性（トレーシング・監視・評価）プラットフォームが存在します。代表例として、LangChain製の商用ツールである LangSmith、オープンソースの Langfuse（ee ディレクトリを除き MIT ライセンス、自己ホスト可能で、OpenTelemetryにネイティブ対応、LLM-as-judge評価を内蔵）、そして同じくオープンソース（MITライセンス）で自己ホストもできる AgentOps が挙げられます。それぞれ役割や提供形態が異なるため、自己ホストしたいのか、既存のコード資産と合わせたいのかで選び方が変わってきます。各社とも無料枠を用意していますが、具体的な料金やプランは変動するため、導入前に各公式ドキュメントで最新の内容を確認してください。ツールの詳細な比較は本記事の範囲を超えるので、ここでは「ループが正しく回っているかを観測する」という観点での位置づけに留めます。

まとめ

自律ループを本番で回せるかは、作る役の賢さより「判定できるか・止められるか・予算を守れるか」で決まります。評価役の合否基準を先に言語化できていないループは、何度回しても収束しません。基準がずれたまま言語化されている場合はもっと厄介で、ループは本来の目的ではなく、そのずれた基準を満たす方向へ最適化されます。止め方は達成条件だけに頼らず、回数・トークンの上限を最初に置くのが暴走への一番の保険。改善が止まったら収束で切り、同じ壁を繰り返すなら人へ上げる。この2つの引き際を数値で決めておくと、無駄な反復も無限リトライも避けられます。コストは反復回数とともに増え、履歴を積む実装ではそれ以上に膨らむので、答えが毎回同じ工程はスクリプトに固定し、判断の要る部分だけAIに残す。設計した停止条件が実際に効いているかは、反復回数・消費トークン・エスカレーション頻度を観測して確かめます。

最初から数千エージェントを目指す必要はありません。作る役と評価役を分けた小さなループを、回数上限付きで一度回してみる。評価役の効き方とトークンの増え方が体感でき、そこから収束やコストの調整に進めます。

よくある質問

Q. 自律ループとAIエージェントは何が違う？

重なりの大きい言葉ですが、同じではありません。Anthropicは、事前に決めたコード経路で組む「ワークフロー」と、LLMが自ら進め方を決める「エージェント」を区別しており、後者を「ループの中でツールを使い、環境からのフィードバックで進捗を評価するLLM」と定義しています。自律ループは作る・評価する・直すの反復構造そのものを指す言葉で、その制御をコードで固定すればワークフロー寄り、LLM側に委ねればエージェント寄りになります。

Q. 自律ループのコストはどう考えればいい？

過去のサブスク料金と比べるのではなく、同じ作業を人がやったら幾らかかるかで比べる考え方が本記事で紹介した視点です。本文で挙げた Bun 書き換えのように、約1年と見積もられた作業が6日で終わる例もあり、人件費換算なら割に合う場面は多い一方、成果を出さずに回り続けるループはただの浪費になります。消費トークンは反復回数とともに増え、履歴を積む実装ではそれ以上に膨らむ点は前提に置いてください。

Q. 全部AIに任せる自動運転は安全？

全自動イコール安全ではありません。隔離環境（サンドボックス）で動かし、何を任せ何を人に残すかの線引きを決めるのが定石です。Anthropicは全権限確認をスキップする設定を「ほとんどの状況で危険」とし、安全寄りのauto modeでも人間レビューの代わりにはならないと明言しています。auto mode の権限分類器についてAnthropicは、過剰行動のケースを厳選した52件の評価セットで偽陰性率17%、実トラフィックでは偽陽性率0.4%と公表しています。前者は難しい例を集めた試験の値なので実運用の見逃し率とは別物ですが、見逃しがゼロではないことは示されています。

Q. ループの観測にはどんなツールがある？

LLM・エージェント専用の可観測性ツールがあり、本記事ではLangSmith、オープンソースのLangfuse、AgentOpsを挙げました。自己ホストしたいのか、既存のコード資産と合わせたいのかで選び方が変わります。

Q. 評価役の判定が間違っていたらどうなる？

ループは本来の目的ではなく、その間違った基準を満たす方向へ最適化されます。必ず収束するとは限らず、退行や振動も起こりますが、誤った達成判定が発火すれば問題のある成果物が「完成」として出ていきます。合否を決められるのは評価役だけではないものの、評価役が主な判定を担う構成ほどこの影響は大きくなります。止まらない暴走と違って外からは成功に見えるぶん、こちらのほうが見つけにくい失敗です。合否を機械で判定できる形に寄せる、通過した成果物を人が抜き取って確かめる、既知の良品と不良品を評価役に通して判定のぶれを確かめる、といった手立てを併せて置きます。

参考資料

• Anthropic: Building Effective Agents（エージェント定義・evaluator-optimizer・停止条件）
• Claude Code 公式: Subagents（独立コンテキスト・要約返し）
• Anthropic: How we built Claude Code auto mode（権限分類器の偽陰性17%／偽陽性0.4%の測定条件）
• Fortune: Anthropic’s Boris Cherny says there are days he manages tens of thousands of AI agents at once（管理する規模／プロンプトを出すのは別のClaude）
• Fortune: The head of Claude Code hasn’t ‘written a line of code by hand’ in 8 months（Bun 書き換えの1年→6日／複数ペルソナのPRレビュー／コストの比較対象）
• LangSmith 公式: Observability
• Langfuse 公式リポジトリ（オープンソース／OpenTelemetry対応）
• Wataoka et al.: Self-Preference Bias in LLM-as-a-Judge（評価役が自分に近い出力を高く評価する傾向）
• Pombal et al.: Self-Preference Bias in Rubric-Based Evaluation of Large Language Models（同一モデル・同一モデル系列への評価バイアス）