「ループを積め」は本当に有効か？ローカルLLMでエージェントループの効果を検証する

AIエージェントの設計において、「ループ構造」が新たな注目を集めています。従来の単発実行型プロンプトから、Writer（生成）→ Reviewer（レビュー）→ 修正というサイクルを繰り返す手法が「Loopcraft: The Art of Stacking Loops」として提唱され、SNS上で議論を呼んでいます。

このアプローチは、Richard Suttonの「Bitter Lesson」（計算リソースとスケーリングが重要）をもじった「Salty Lesson」（ループを積め）として語られており、構造的な反復が性能向上の鍵だと主張しています。

今回取り上げる投稿は、この理論を鵜呑みにせず、**ローカル環境のgemma-4-12bモデルで実測検証を行った**貴重な事例です。コード生成タスクを使い、RTX 5060 Ti 16GB環境でllama-serverを活用した実践的な検証は、多くの開発者にとって参考になるでしょう。

エージェントループの基本構造は以下の通りです：

1. **Writer（生成フェーズ）**: LLMが初期のコードや文章を生成

2. **Reviewer（評価フェーズ）**: 同じまたは別のLLMが生成物を批評・問題点を指摘

3. **修正フェーズ**: レビュー結果を元に生成物を改善

4. **反復**: 2〜3を必要なだけ繰り返す

このアプローチの理論的根拠は、人間の創作プロセスの模倣にあります。プロの作家やエンジニアは初稿をそのまま提出せず、何度も推敲・改善を重ねます。LLMにも同様のプロセスを組み込めば品質が向上するはずだ、という仮説です。

投稿者はgemma-4-12b（Q4_K_M量子化モデル）という比較的小規模なモデルで検証を行いました。これは重要なポイントです。GPT-4のような大規模モデルではなく、**一般的な開発者が手の届く環境**で実験している点が実用的価値を高めています。

従来手法との比較分析

ループ構造を従来のプロンプト技術と比較すると、明確な差異が見えてきます：

**Chain-of-Thought（CoT）との違い**

CoTは「思考過程を段階的に出力させる」手法ですが、ループは「成果物を反復改善する」点で異なります。CoTは単一実行内の内部構造の工夫であり、ループは複数回の実行による外部的な改善サイクルです。両者は競合ではなく、組み合わせることで相乗効果が期待できます。

**ReActパターンとの関係性**

ReAct（Reasoning + Acting）は観察→思考→行動のサイクルですが、これは外部ツールとの対話が前提です。一方、Loopcraftは同じLLM内または複数LLM間での対話に焦点を当てています。つまり、ReActが「環境との対話」なら、Loopcraftは「自己との対話」です。

メリットと注意すべき制約

**明確なメリット：**

**critical な注意点：**

適用範囲の見極め

ループ構造が特に有効なのは以下のケースです：

1. **明確な評価基準がある場合**: コード生成（文法エラー、テスト通過）、翻訳（流暢性）など

2. **反復改善の余地が大きいタスク**: 創作的な文章、複雑なロジックの実装

3. **時間的余裕がある場合**: リアルタイム応答が不要で、品質を優先できる状況

逆に不向きなのは：

1. **即時性が求められる対話**: チャットボットなど

2. **評価基準が曖昧なタスク**: 感性的な判断が必要な創作

3. **コスト制約が厳しい場合**: APIコストや計算リソースが限られている

検証における本質的課題

投稿者の実験で最も重要なのは「**本当に良くなるのか？**」という根本的な問いです。ここには測定上の難しさがあります：

これらの疑問に答えるには、定量的な評価指標（パスレート、実行時間、コード品質スコア）と定性的な分析の両方が必要です。

1. シンプルなWriter-Reviewerループを実装する

まずは2ステップの基本形から始めましょう：

# 疑似コード
code = llm.generate("Pythonで素数判定関数を書いて")
review = llm.generate(f"以下のコードをレビューして改善点を指摘：\n{code}")
improved_code = llm.generate(f"以下のレビューを反映してコードを改善：\n{review}\n\n元のコード：\n{code}")

この3ステップで、既にループの基本効果を体感できます。重要なのは、Reviewer用プロンプトに「具体的な改善点を3つ挙げる」などの明確な指示を入れることです。

2. 終了条件を設定した反復ループを作る

無限ループを防ぐため、終了条件を設けます：

max_iterations = 5
for i in range(max_iterations):
    review = get_review(code)
    if "問題なし" in review or "excellent" in review.lower():
        break  # レビューがポジティブなら終了
    code = improve_code(code, review)

または、外部ツールによる検証を組み込みます：

while not passes_tests(code) and iterations < 10:
    errors = run_tests(code)
    code = llm.generate(f"以下のエラーを修正：\n{errors}\n\nコード：\n{code}")
    iterations += 1

3. ログを取って効果を測定する

各ループの出力を保存し、品質の変化を追跡します：

results = []
for iteration in range(3):
    output = generate_and_review(prompt)
    results.append({
        'iteration': iteration,
        'output': output,
        'score': evaluate(output),  # 自動評価関数
        'timestamp': time.time()
    })

# 結果を可視化
for r in results:
    print(f"Iteration {r['iteration']}: Score {r['score']}")

これにより、「本当に改善しているか」を客観的に判断できます。スコアが横ばいならループ回数を減らし、コストを削減する判断も可能です。

「Loopcraft」のような新しい手法が登場したとき、理論的な魅力に惑わされず、**実測データで検証する姿勢**が重要です。今回の投稿者のように、手元の環境で実験し、定量的な結果を得る取り組みこそが、AI活用を前進させます。

ループ構造は万能ではありませんが、適切な場面で正しく実装すれば、ローカルの小規模モデルでも大規模モデルに迫る性能を引き出せる可能性があります。あなたのユースケースで試し、データを取り、継続的に改善していく——それが2026年のAIエンジニアリングの基本姿勢です。

この情報は @mskbhd さんの投稿を参考にしています。