重みが公開されている小さなモデルでも、役割を分けて何回も呼べば、最上位のモデルに並べるのか。Persis Capital の研究チームが出した論文 GVS5H では、Qwen3.8 系のモデルを複数立ち上げて共有のファイルで連携させると、難しいプログラミング問題の正答率が Claude Fable 5 を上回りました。費用は Fable 5 の 9% です。10 月 25 日に Hacker News で 1 位になり、31 日には別の開発者が自作ツールの Memdoor で同じ方式を再現しています。数字の出し方には注意点も多く、開発者からは疑問の声も出ています。
背景と文脈
コーディングの性能では、Claude Fable 5 のような最上位のモデルと、手元の GPU で動く公開モデルの間に大きな差がありました。差を縮める方法は、これまで主に追加の学習でした。GVS5H は学習をし直さず、モデルの呼び方だけを変えます。
論文の題は GVS5H: Zero-Shot Self-Orchestration with Ledger-Based Control for Improved LLM Coding Performance で、8 月 27 日に初版、9 月 21 日に改訂版が arXiv に載りました。GVS5H は「Gorilla vs. 5 Humans（ゴリラ対 5 人の人間）」の略で、強い 1 体と協力する 5 体を比べる題名になっています。
評価に使ったのは LiveCodeBench（競技プログラミングの問題を公開日ごとに集め続けている、コード生成のベンチマーク）です。その中で最近の難しい問題 100 問を選び、1 回の解答で正解する割合（pass@1）を比べました。新しい問題を使うのは、モデルが学習中に答えを見ていた可能性を減らすためです。
技術/ビジネス面
仕組みの中心は、会話の履歴ではなくファイルでやりとりすることです。同じモデルを毎回まっさらな状態で呼び出し、計画・メモ・今の解答をディスク上のファイルに書かせます。次に呼ばれた側はそのファイルを読んでから仕事をします。論文はこれを台帳（ledger）による制御と呼んでいます。会話の記録から解析したところ、問題を小分けにしたことと、ファイルに残した情報が引き継がれたことが効いていました。
11 のモデルで試した結果、正答率は最大で 25.6 ポイント上がりました。Qwen3.8-27B（270 億パラメータの公開モデル）は、1 回呼ぶだけだと 66.8% でした。チームにすると 92.4% になりました。著者の README では、この結果は GPU 1 枚で動かしたものとしています。Qwen3.8 Flash Next をチームにした場合は 93.0% で、Fable 5 を 1 回呼んだときの 90.4% を超えました。この構成の 1 問あたりの費用は、Fable 5 の 9% です。
どのモデルでも上がったわけではありません。論文の要旨には、変わらなかったモデルや、かえって下がったモデルもあったと書かれています。Opus 5 は前の版の仕組みを使い、OpenRouter 経由で 1 回だけ回した数字なので、ほかと同じ条件では比べられません。
Memdoor での再現は、開発者の guregodevo 氏が team-solve として公開しました。プログラムは書かず、YAML ファイル 8 つで流れを組んでいます。計画を立てる役、別々の考え方で解き方を出す 2 役、解答を書く役、テスト結果を見て直し方を指示する役、直す役の 6 役です。テストの実行と最終判定は、モデルではなくスクリプトが行います。
開発者として試すなら
数字を並べると次のようになります。論文は 100 問、Memdoor は最初の 10 問を 5 回ずつ解いた結果で、問題の数が違う点に注意してください。
| 構成 | 結果 | 出どころ |
|---|---|---|
| Qwen3.8-27B を 1 回呼ぶ | 66.8% | 論文（100 問） |
| Qwen3.8-27B のチーム | 92.4% | 論文（100 問） |
| Qwen3.8 Flash Next のチーム | 93.0%（費用は Fable 5 の 9%） | 論文（100 問） |
| Fable 5 を 1 回呼ぶ | 90.4% | 論文（100 問） |
| Memdoor の team-solve（Qwen3.8-27B） | 10 点満点で平均 9.8 | Memdoor（10 問） |
| 論文の著者の仕組み | 平均 9.6 | 同じ 10 問 |
| Fable 5 を 1 回呼ぶ | 平均 8.0 | 同じ 10 問（著者のデータ） |
Memdoor の README によると、1 回の実行は中央値で 40 分、0.39 ドルでした。50 回分の合計は 35.79 ドルです。モデルは手元ではなく OpenRouter で動かしています。試すときの手順は次のとおりです。
curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter # 鍵なしで手元のモデルを使うなら memdoor connect local
git clone --depth 1 https://github.com/guregodevo/memdoor
mkdir -p ~/.memdoor/workflows
cp -r memdoor/examples/workflows/team-solve ~/.memdoor/workflows/
mkdir my-problem && cd my-problem
cp -r ../memdoor/examples/workflows/team-solve/sample/* .
memdoor workflow run team-solve --wait1 行目はネットから取ってきたスクリプトをそのまま実行するので、先に中身を読んでおくと安心です。Ollama で手元のモデルを使う場合、文脈の長さ（一度に読めるトークンの量）を初期値の 4K から 32K に広げないと動きません。論文の著者のコードは GitHub の GVS5H にあり、uv と各社の API キーで動きます。コードは MIT ライセンス、論文と実行データは CC BY 4.0 です。
自分の問題に使うには、問題文の task.md と、入力と期待する出力の組を tests フォルダに置きます。この方式はテストが通るかどうかで成功を判定するので、正解をテストで書ける作業に向いています。画面の見た目や仕様があいまいな作業には、そのままでは使えません。
失敗の例も README に残っています。ある問題では、指示役が間違った反例を作り、正しいプログラムをチームで書き直してしまいました。ほかの問題でも、正しいプログラムが 2 回上書きされ、あとで戻っています。小さなモデルを何回も呼ぶ分、ひとつの判断ミスが次の役に引き継がれやすくなります。
これからどうなるか
結果をそのまま受け取るには条件があります。Memdoor の README は、問題が 2025 年春のコンテストのもので、学習データに入っていた可能性を否定できないと書いています。Hacker News のコメントでは、vikramkr さんが LiveCodeBench Hard はもう古く、満点近くまで解かれていると指摘しました。jbellis さんは、安いモデルの群れは 1 つのベンチマークに合わせて調整しやすいが、ほかの作業に広げるのは難しいと書いています。
それでも、手元の GPU で動く 27B のモデルが、呼び方を変えるだけで 66.8% から 92.4% まで上がった点は、開発の現場でも使えます。社外に出せないコードを扱うチームは、最上位のモデルの API を使えない場面があります。テストがそろっている修正作業なら、公開モデルをチームとして組み、CI（コードを変えるたびに自動でテストやビルドを回す仕組み）の中で動かすやり方が現実的になってきました。
ただし時間はかかります。Memdoor では 1 問に 40 分ほどかかっていて、すぐに答えがほしい対話的な使い方には向きません。夜のうちにまとめて回す使い方なら、費用の差が効いてきます。
まとめ
論文 GVS5H は、同じ小さなモデルを役割ごとに呼び分け、ファイルで情報を引き継がせるだけで、難しいプログラミング問題の正答率を最大 25.6 ポイント上げました。Qwen3.8 Flash Next のチームは 93.0% で Fable 5 の 90.4% を上回り、費用は 9% でした。Memdoor の再現でも同じ傾向が見られましたが、問題数は 10 問と少なく、学習データに問題が入っていた可能性も残ります。テストで正解を確かめられる作業から試すのが確実です。
参考リンク
- GVS5H: Zero-Shot Self-Orchestration with Ledger-Based Control for Improved LLM Coding Performance（arXiv）
- slee-persis/GVS5H（GitHub）
- Memdoor team-solve（GitHub）
- Hacker News のコメント欄
アイキャッチ画像: Photo by Mark König on Unsplash
