LLMはすでに天才——管理方法を変えるだけで性能が2倍になる理由

追加学習なし、新しいモデルも不要。AIの性能は「使い方」で決まる——そんな仮説を実験で裏付けた研究が注目を集めています。

この記事でわかること：

  • Mismanaged Geniuses仮説（MGH）が主張する内容と背景
  • 再帰型言語モデル（RLM）の仕組みとなぜ性能が上がるのか
  • 追加学習ゼロでLLMスコアを倍にした具体的な数値
  • pip install rlms で試せる実装方法

フロンティアLMは「天才」なのに、長い推論が苦手という矛盾

現在のフロンティアLM（GPT-5.2、Claude Sonnet 4.5など）は、IMOやIOIといった最難関の数学・競技プログラミング試験で人間のトップ層を超えるスコアを出せます。コードを書かせれば、多くのケースで人間のソフトウェアエンジニアを上回る品質で仕上げます。

ところが、その同じモデルが「長期にわたる反復推論」や「コンテキストを跨いだ情報の統合」では、途端にパフォーマンスが落ちます。直感的には奇妙な話です。難しい試験には合格するのに、長い文書を読みながら段階的に考え続けることがなぜ難しいのか。

MITのAlex Zhang、Zhening Li、Omar Khattabの3名は、この矛盾の答えは「モデルが弱いから」ではなく「モデルの管理方法が悪いから」にあると主張しています。これがMismanaged Geniuses仮説（MGH）です。

「管理方法が悪い」とはどういう意味か

現在のAIエージェントは、ほぼすべて人間が設計したスキャフォールド（骨組み）の上で動いています。ReActのようなフレームワークも、カスタムエージェントシステムも、設計者の直感をコードに落とし込んだものです。その結果、特定のタスクに特化した脆弱なシステムが大量に生まれています。

MGH仮説の核心は「LMは分解の仕方さえ正しければ、はるかに難しいタスクを解ける」という点です。人間が設計した分解ロジックは固定的で、モデルの実力を引き出せていない。言い換えると、AIはすでに十分な知識と推論能力を持っているのに、与えられた「作業手順」が狭すぎて本来の力が出せない状態にある、というわけです。

Claude CodeやOpenClaw、Hermesといったコーディングエージェントの成功は、この仮説を支持する間接証拠として挙げられます。これらはLM自身がタスクをサブタスクに分解し、サブエージェントに委任する仕組みを持っており、従来の単一LM呼び出しより大幅に複雑なタスクをこなせます。

RLMとは——LMがプロンプト自体を環境として扱う

MGH仮説が提示する具体的な解決策が、Recursive Language Models（RLM：再帰型言語モデル）です。

GitHub - alexzhang13/rlm: General plug-and-play inference library for Recursive Language Models (RLMs), supporting various sandboxes.
General plug-and-play inference library for Recursive Language Models (RLMs), supporting various sandboxes. - alexzhang1…
GitHub

通常のLM呼び出しは llm.completion(prompt, model) という形で、プロンプトは固定文字列として渡されます。RLMはこれを rlm.completion(prompt, model) に置き換え、プロンプトをREPL（コード実行環境）上の変数として扱えるようにします。

この変更により、LMは次のことができます。

  • プロンプトをコードで検査・スライス・加工する
  • 必要な部分を切り出して、自分自身や別のLMに再帰的にサブクエリを投げる
  • 各サブクエリの結果を受け取って統合し、最終回答をまとめる

コンテキストウィンドウを超える長さの入力に対しても、RLMは「読むべき箇所を自分で判断して分割し、並列または逐次で処理する」ことが可能です。モデル自体のパラメータは一切変わらず、推論時の「使い方」だけが変わります。

数字で見る成果——追加学習なしで性能が2倍

RLMの効果は、長文推論ベンチマークLongCoTでの結果が最も明確です。LongCoTは2,500の専門家設計タスクから成る長期推論ベンチマークで、リリース時にGPT-5.2で9.8%、Gemini 3 Proで6.1%という厳しい数値でした。

このベンチマークにRLMを適用した結果は以下の通りです。

  • Claude Sonnet 4.5 + DSPy.RLM: LongCoT-Miniで45.4%（RLMなしは2.6%）
  • GPT-5.2 + RLM: 38.7% → 65.6%（追加学習なし）
  • Qwen3.5-27B + DSPy.RLM: 22.18%（GPT-5.2の2倍以上）
  • Qwen3-8B + RLM: 0/507 → 33/507に改善（小規模モデルでも機能）

Claude Sonnet 4.5の45.4%という数値は、RLMなしの2.6%と比較すると約17倍の改善です。モデルのバージョンアップや追加学習なしにこの差が出るのは、推論スキャフォールドの設計が性能に与える影響の大きさを示しています。

さらに、長期記憶ベンチマークLongMemEvalではGemini 3 Flash + DSPy.RLMが87.2〜89.8%を達成。長文コンテキスト処理でも実績を積んでいます。

pip install rlms で試せる

RLMのリファレンス実装はAlexZhang氏のGitHubリポジトリで公開されており、4,000スター以上を集めています（2026年4月現在）。

pip install rlms

インストール後は以下のように呼び出せます。

from rlm import RLM

rlm = RLM(
    backend="openai",
    backend_kwargs={"model_name": "gpt-5-nano"},
    verbose=True,
)

print(rlm.completion("ここにタスクを記述").response)

AnthropicモデルやOpenRouter経由のモデルにも対応しており、既存のAPIキーを使って試せます。コード実行環境（サンドボックス）はDockerやModal、E2Bなど複数から選択可能です。ローカル環境での簡易実行も可能ですが、本番利用ではDockerやクラウドサンドボックスの使用が推奨されています。

DSPy（Declarative Self-improving Language Programs）との統合版DSPy.RLMも利用でき、RLMをDSPyのモジュールとして組み込んだより大きなパイプラインを構築できます。上述のベンチマーク実験の多くはDSPy.RLMを使って計測されています。

現時点の課題

RLMが万能かというと、まだ克服すべき課題もあります。

コストと処理時間が代表的な問題です。再帰的なサブ呼び出しが増えると、トークン消費と待ち時間が増大します。ナイーブな実装では処理時間が読めず、コストも予測しにくくなります。これは再帰の深さを制限したり、各サブコールに小さなモデルを使ったりすることで緩和できます。

もう一つの課題は、LMが「再帰的に考える」習慣を持っていない点です。コードとして再帰の概念は学習済みでも、自分自身のプロンプトを分解して別インスタンスに投げる行動は自然には出てきません。MIT OASYSチームは現在、RLMハーネス上での強化学習による後学習を進めており、モデルが正しい分解行動を学べるか検証中です。

まとめ

Mismanaged Geniuses仮説は「スケーリングが唯一の道ではない」という主張です。フロンティアLMはすでに高い能力を持っており、問題はモデルの賢さではなく、LMに渡すタスクの分解方法にある。RLMはその「管理方法」を改善する具体的な手法として、追加学習なしで顕著な性能向上を実証しています。

小規模モデル（Qwen3-8B）でも大幅な改善が得られる点は特に注目で、高価なフロンティアモデルに頼らずとも、スキャフォールドの設計で性能を引き上げられる可能性を示しています。