LLM-in-the-loopとは｜LLMループ3類型と無限ループ対策

LLM-in-the-loopとは、最適化や改善のループの内側に大規模言語モデル（LLM）を「評価する人」「案を出す人」として組み込み、人手で回していた試行錯誤を自動で回し続ける設計を指します。ただし「LLM ループ」という言葉は文脈によって別のものを指すため、まず何のループの話なのかを切り分けないと議論が噛み合いません。この記事では3つのループを整理したうえで、OPROやAlphaEvolveといった実際に成果が測定された手法、最小実装コード、そして現場で最も痛い「ループが止まらない」問題の止め方までを扱います。

まとめ

「LLMのループ」はエージェントループ（思考→行動→観察を繰り返す実行の輪）、LLM-in-the-loop（最適化ループの評価者・生成者としてLLMを置く輪）、Human-in-the-Loop（人が承認・修正で介入する輪）の3つに分かれます。このうちLLM-in-the-loopは、目的関数を数式で書けないタスク（プロンプト、コード、デザイン、文章）で効きます。Google DeepMindのOPROは人手設計プロンプトをGSM8Kで最大8%上回り、AlphaEvolveはGoogleのデータセンター運用で全社計算資源の0.7%を回収しました。一方でループはコストと暴走のリスクを持ち込むため、反復上限・無改善打ち切り・コスト上限の3点を最初に決めておくのが実務上の必須条件です。

LLMのループが指す3つの意味

「LLM loop」で検索したときに出てくる話題は、実は次の3系統が混在しています。設計会議で最初に合わせるべきはここです（なお、社内向けLLMの開発・運用サイクルをベンダーが「LLM Loop」という独自のサービス名で呼ぶ用法もあり、技術用語としての以下3つとは別物です）。

エージェントループ：思考・行動・観察を繰り返す実行の輪

AIエージェントの実行モデルであり、LLMが次の行動を決める（Thought）→ツールを呼ぶ（Action）→結果を読む（Observation）を、タスクが終わるまで繰り返します。ReActに代表されるこの形は、ループの各周回でLLMが「呼び出される側」です。改善対象はエージェントの振る舞いそのもので、ツール定義や停止条件の設計が主戦場になります。DSPyのように宣言的にモジュールを組む枠組みでは、この輪自体がフレームワーク側に実装されており、ネイティブツール呼び出しを前提とするReActモジュールのように実装が更新されていきます。

LLM-in-the-loop：最適化ループの評価者・生成者としてのLLM

こちらは最適化アルゴリズムが主役で、LLMはその内側の部品です。従来なら数値の目的関数と探索アルゴリズムで回していたループの「案を出す」「良し悪しを付ける」工程をLLMが担います。決定的な違いは、評価も生成も自然言語で記述できる点にあります。「読みやすい文章」「押しやすいボタン配置」のように微分できず数式にも落ちない目的でも、LLMなら判断を返せるため、ループが回せるようになります。後述するOPRO（arXiv 2309.03409）はこの型の代表例で、勾配を持たないプロンプト文字列を探索対象にしています。

Human-in-the-Loopとの役割分担

人が承認・修正で介入するHuman In The Loopは、LLM-in-the-loopの対抗馬ではなく上位のガードレールです。LLMは1周を秒単位で何百回でも回せますが、責任を取れません。したがってループの内側は自動、ループの外側の採否は人間という分担が現実解になります。医療・与信・人事のように誤判定の代償が大きい領域では、LLMの評価をそのまま採用せず、上位候補だけを人間のレビューに回す設計にします。

LLM-in-the-loop最適化の構成要素｜提案者と評価者の2役

ループ内でLLMに与える役割は、突き詰めると「提案者」と「評価者」の2つだけです。どちらか一方だけを置く構成も成立します。

提案者としてのLLM：OPROが示した効き目

Google DeepMindのOPRO（Optimization by PROmpting）は、最適化問題を自然言語でLLMに説明し、これまでの解とそのスコアをプロンプトに詰めて「もっと良い解を出せ」と要求する手法です（arXiv 2309.03409、ICLR 2024採択）。勾配は一切使いません。論文はプロンプト最適化を主戦場とし、OPROが見つけた指示文が人手設計のプロンプトをGSM8Kで最大8%、Big-Bench Hardのタスクで最大50%上回ったと報告しています。つまりLLMは、過去の試行と点数さえ見せれば探索の方向を推測できます。

評価者としてのLLM：LLM-as-a-Judgeの精度とバイアス

スコアを付ける側にLLMを置くのがLLM-as-a-Judgeです。MT-BenchとChatbot Arenaの研究（arXiv 2306.05685）では、GPT-4の判定が人間の好みと80%超で一致し、これは人間同士の一致率と同水準だと報告されています。評価者として実用に足る精度です。ただし同じ論文が、提示順で勝敗が動くposition bias、長い回答を高く付けるverbosity bias、自分（同系列モデル）の出力を贔屓するself-enhancement biasを明示しています。順序を入れ替えて2回評価する、文字数を評価軸から外す、生成モデルと評価モデルを別系列にする、といった対策をループに織り込んでください。

最小構成のLLM-in-the-loop実装（Python・約20行）

OPRO型のループは、20行程度で骨格が書けます。要は「履歴つきプロンプトで案を出させ、評価し、上位だけを次の周回に持ち越す」だけです。以下は疑似コードで、llm・evaluate・no_improvementは自前実装に差し替えて使います。

# llm / evaluate / no_improvement は自前実装（疑似コード）
SEED = "ステップごとに考えて答えてください"     # 初期案。空履歴だと提案の手がかりが無い
history = [(SEED, evaluate(SEED))]          # (candidate, score) の履歴

for step in range(MAX_STEPS):
    # 1. 提案：これまでの上位案とスコアを見せて、より良い案を書かせる
    top = sorted(history, key=lambda x: -x[1])[:5]
    prompt = "\n".join(f"案: {c}\nスコア: {s:.3f}" for c, s in top)
    candidate = llm(PROPOSE_TEMPLATE.format(examples=prompt))

    # 2. 評価：正解データがあるなら実測、無ければ LLM-as-a-Judge
    score = evaluate(candidate)          # 例: 検証セットの正答率
    history.append((candidate, score))

    # 3. 停止：無改善が続いたら打ち切る（後述の暴走対策）
    if no_improvement(history, patience=5):
        break

best = max(history, key=lambda x: x[1])[0]

評価関数evaluateを検証セットの正答率にすれば客観指標での最適化、LLMの採点にすれば主観的な目的の最適化になります。プロンプト最適化を自分で書かずに済ませたい場合は、この輪をフレームワークとして実装したDSPyを使うと、最適化器を差し替えるだけで同じことができます。改善の指針を自然言語の反省文としてループに戻す設計は、Reflection Agentの考え方と地続きです。

成果が測定されたLLM-in-the-loopの実例

「理屈は分かるが本当に効くのか」に対する答えは、すでに検証可能な数字で出ています。

AlphaEvolve：LLMを進化計算の変異オペレータにする

Google DeepMindが2025年5月14日に公表したAlphaEvolveは、Gemini FlashとGemini Proにコードの改変案を書かせ、自動評価器が採点し、成績の良いものを次世代の親に選ぶ進化的ループです。人手のアイデア出しをLLMに置き換えた、LLM-in-the-loopの最大規模の実例といえます。公表された成果は具体的です。

注目すべきは、50超の数学問題のうち更新できたのは20%という数字です。残り8割はすでに人類が到達済みの水準を再発見したにすぎません。LLM-in-the-loopは「探索を安く大量に回す」ことに強く、魔法のように未知を生むわけではない、と読むのが妥当です。

GEPA：強化学習より少ない試行で上回る

GEPA（arXiv 2507.19457、2025年7月投稿・2026年2月改訂）は、実行トレースを自然言語で振り返らせてプロンプトを進化させる手法です。論文は強化学習のGRPOを平均6%・最大20%上回りながら、必要なロールアウト回数は最大35分の1だったと報告しています。プロンプト最適化器のMIPROv2に対しても10%超（AIME-2025で+12%）の優位を示しました。ここがLLM-in-the-loopの経済的な急所で、勾配計算を伴う学習ループに比べ、言語による反省は圧倒的に試行回数が少なくて済みます。

ループが暴走する条件と、確実に止める設計

LLMのループで実際に事故が起きるのは、精度ではなく停止条件です。エージェントが目的を見失い、意味のないツール呼び出しを延々と繰り返してAPI請求だけが膨らむ——「llm 無限ループ」で検索される事象の正体はこれです。設計時に次の3つの上限を必ず外側から与えてください。

• 反復上限：1タスクあたりの最大周回数（MAX_STEPS）。到達したら結果の良否にかかわらず打ち切る。
• 無改善打ち切り：スコアが一定周回（上のコード例ではpatience=5＝5周）連続で更新されなければ終了。探索が平坦域に入った合図で、これ以上回してもコストだけが増える。
• コスト上限：累積トークン数・料金の閾値。ループを常駐させる構成では、これが唯一の最終防衛線になる。

ここで推奨しない対策もはっきり書いておきます。同じ文言の反復が出るからといって repetition penalty や temperature を上げて回避しようとするのは筋が悪い。生成の多様性を犠牲にして出力品質を落とすうえ、ツール呼び出しの循環（同じ検索を繰り返す種類の暴走）にはそもそも効きません。暴走はサンプリングの問題ではなく制御フローの問題なので、ループの外側でカウンタと予算を握るのが正解です。加えて、履歴をそのまま積み上げるとコンテキストが膨張して判断が鈍るため、直近n周だけを残す、または要約して圧縮する運用も併せて必要になります（Context Engineeringの領域です）。

LLM最適化とベイズ最適化・強化学習の使い分け

最後に、LLM最適化（LLM-in-the-loop）を使うべきでない場面を明示します。目的関数が数値で明確に定義でき、評価が安価に繰り返せるタスク——ハイパーパラメータ探索や連続値のパラメータチューニングでは、ベイズ最適化のほうが速く、安く、再現性があります。LLMに数値探索をさせる合理的な理由はありません。

LLM-in-the-loopが勝つのは、探索空間が自然言語やコードで表現され、目的が言語でしか書けないタスクです。プロンプト、指示文、コード、UI文言、記事構成といった対象では、そもそも勾配もカーネルも定義できないため、従来手法は土俵に上がれません。両者は競合ではなく守備範囲が違います。GEPAが強化学習と比較されているように、境界領域では試行回数あたりの改善量で選ぶことになります。

よくある質問

LLM-in-the-loopとHuman-in-the-Loopの違いは何ですか？

ループの内側で判断を下す主体が違います。Human-in-the-Loopは人間が評価・承認・修正を担当し、LLM-in-the-loopはその判断をLLMに置き換えます。実務では排他ではなく、内側の試行錯誤をLLMに任せ、最終的な採否を人間が握る二重構造にするのが一般的です。

LLMが同じ回答を繰り返す無限ループはなぜ起きますか？

エージェント構成では、LLMが目的の達成を判定できずに同じツール呼び出しを再試行し続けることが主因です。サンプリングパラメータの調整で抑え込もうとすると出力品質が落ちるため、反復上限・無改善打ち切り・コスト上限をループの外側に置いて強制終了させる設計にしてください。

LLM-in-the-loop最適化はどんなタスクに向きますか？

目的関数を数式で書けず、候補が言語やコードで表現されるタスクです。プロンプト最適化、コード改善、文章やUI文言の改善が典型で、OPROはプロンプト最適化で人手設計を上回り、AlphaEvolveはコード最適化で計算資源0.7%の回収という実績を出しています。数値パラメータの探索はベイズ最適化の担当です。

LLM-as-a-Judgeの評価スコアは信頼できますか？

MT-Benchの研究ではGPT-4の判定が人間の好みと80%超で一致し、これは人間同士の一致率と同水準です。ただし提示順・回答の長さ・自己贔屓によるバイアスが確認されているため、順序を入れ替えて複数回評価する、生成側と評価側で別系列のモデルを使うといった補正を前提に組み込んでください。

エージェントのループ回数はどれくらいに設定すべきですか？

公式に定まった推奨値はありません。実務上は、タスクの想定手順数から逆算した余裕分（経験則として2〜3倍程度）を上限に置き、無改善が続いた時点で早期終了させる形が扱いやすくなります。上限値そのものより、上限に達した場合に結果を捨てるのか途中経過を返すのかを先に決めておくほうが、運用時のトラブルを減らせます。

関連記事

• LLM-as-a-Judgeとは何か？大規模言語モデルを評価者として用いる新手法の概要
• AI開発の現場で不可欠なHuman In The Loopの定義と導入が加速する背景
• Reflection Agentとは？仕組みと基本的な概要の解説
• DSPyとは何か？宣言的AIソフトウェアフレームワークによる新しいLLMプログラミング手法の概要とメリット
• DSPy ReActV2とは｜ネイティブツール呼び出し前提の新ReActモジュール【2026年版】