拾闻対談 037｜27Bエージェント5体でFable 5に勝てるのか

開場小対談

拾聞：今日早朝、海外フォーラムでGitHubのプロジェクトについて話が広まっていました。そこでは、5つのQwen3.8-27Bのアイドルがチームを組み、LiveCodeBench Hardのトップ10問題でFable 5の単発呼び出しを破ったとあります。情報源はMemdoorのワークフロー例で、作者は50回の実行の完全な記録も公開しています。タイトルが大げさかどうかはともかく、この事実だけを見ても話す価値がありますか？

永亮：話す価値はありますが、「小さなモデルが大きなモデルを打ち負かした」という爽快な物語ではありません。本当に興味深いのは、既に検証済みのマルチアイドル手法をYAMLワークフローにまとめ、誰でもモデルや温度を変更し、承認プロセスを追加できた点です。これはGVS5Hの学術的な実装を、エンジニアチームがCIに直接取り込める部品に分解したようなものです。Fable 5が本当に打ち負かされたかどうかは、別途検討する必要があります。

Q1：この「打ち負かし」はどのように起こったのでしょうか？

拾聞：MemdoorのREADMEには明確に書かれています。最初の5回のパスで平均9.8/10、元の作者と同じモデル、同じヒントでの評価は9.6、Fable 5の単発呼び出しは8.0でした。このデータはどう解釈すればよいのでしょうか？

永亮：まず、その内容を明確にしましょう。Qwen3.8-27Bをマルチアイドルサイクルで実行しました：plannerが案を出し、2つのideatorが提案を出し、solverがコードを書き、managerがレビューを行い、さらにrepair workerがバグを修正します。各役割は新しいコンテキストであり、ディスク上のファイルを通じて通信します。5回のパスで平均9.8は、GVS5Hの元の作者自身の9.6よりわずかに高く、Fable 5のその10問題での単発呼び出しの8.0よりも大幅に高いです。

拾聞：つまり、モデル自体が強くなったのではなく、使い方が強くなったということですか？

永亮：そうです。Fable 5の8.0はGVS5Hの作者のファイルにある単発呼び出しデータから来ており、Memdoorが同じハーベスで再実行したものではありません。したがって厳密に言えば、「同じ問題セット、同じ条件下で、27BのマルチアイドルがFable 5の単発呼び出しよりも優れたパフォーマンスを示した」ということであり、「27BモデルがFable 5を全面的に超えた」というわけではありません。しかし、この差は十分に示しています：複数の小さなモデルをうまく組み合わせることで、特定のタスクでfrontierモデルを超えることができるのです。さらに覚えておくべきは、Memdoorがこの方法をYAMLワークフローにまとめたということです。つまり、planner、ideator、managerを自分のモデルや温度に置き換え、承認プロセスを任意のステップに挿入できます。これはエンジニアチームにとって、得点そのものよりも有用です。

Q2：モデルのサイズはもはや硬直的な基準ではないのでしょうか？

拾聞：ここ数年、業界では「モデルが大きければ大きいほど強くなる」というのが一般的です。しかし、このプロジェクトは、編成こそが新たな力になり得ることを示唆しています。同意しますか？

永亮：私は半分同意します。モデルのサイズは依然として上限を決定しますが、その構成によってその上限をどれだけ発揮できるかが決まります。Memdoorの例では、実際に効果的な要素は4つあります。第一に、分担です。各エージェントは短いタスクのみを担当し、コンテキストがよりクリーンになります。第二に、持続的な状態です。計画、ノート、現在の解決策などがファイルに記録され、各キャラクター間で全歴史をプリミティンに詰め込む必要はありません。第三に、複数回の検証です。マネージャーはコードだけでなく、テスト結果も考慮します。第四に、復元可能性です。YAMLワークフローには承認プロセスと断点続行機能があり、故障した場合は失敗したステップから続けて実行できます。

拾闻：Memdoorは「決定モデル」を使用してトークンを節約するとも言っていますが、これはどう解釈すればいいですか？

永亮：これは非常に実用的なエンジニアリングポイントです。通常のチャットモデルは、全ての会話履歴、ファイル内容、ツールの結果を一度に処理する必要があり、トークンのコストは線形に増加します。決定モデルは入力を一度処理し、どのツール、ファイル、コンテキストが必要かを決定し、必要な情報のみ大モデルに渡します。Memdoorのテストでは、一部のタスクで74％の入力トークンを節約できると述べています。マルチエージェントサイクルには特に重要です。各キャラクター間でファイルを繰り返し読み書きするため、フィルタリングを行わないとコンテキストが急速に膨張します。

拾闻：それは、将来frontier APIを購入する際のコストパフォーマンスが低下するという意味ですか？

永亮：状況によります。タスクが短く、コンテキストが浅く、遅延に敏感な場合、単回のfrontier呼び出しが最も効率的です。タスクを複数のサブタスクに分割したり、複数回のイテレーションが必要だったり、監査やローカル実行が必要な場合、「決定モデル + 複数のワーカー + 持続的なワークフロー」がより経済的です。将来的には、エンジニアチームはモデルのプリミティンに固執するのではなく、パイランス設計により近い形になるでしょう。

Q3：コスト計算はどうやっていますか？ローカルモデルは本当にコストを節約できますか？

拾闻：MemdoorはBYOKとローカルモデルを強調しており、Ollama、llama.cpp、vLLMなどが対応できます。GVS5Hの原論文でも、コストがfrontierの9分の1に下がると述べています。これは信頼できるのでしょうか？

永亮：Memdoorの実験はOpenRouter上で行われており、ローカルマシンではありません。50回の有効な実行には35.79ドルがかかり、16回の中断や修正にかかった合計は38.77ドルでした。平均単回コストは0.39ドル、平均実行時間は40分、最長は4時間でした。ローカルのvLLM FP8を使用すると、著者は単一のGPUで問題なく実行できると述べています。したがって、ローカルではAPI呼び出し料を節約できますが、ハードウェア、電気代、運用コストを支払う必要があります。

拾闻：つまり、個人開発者でも自宅で実行できるということですか？

永亮：理論上は可能です。MemdoorはOllama、llama.cpp、vLLM、LM Studioをサポートしており、自社のjanisゲートウェイも利用できます。フォーラムで、Bonsai 2で量化した後、Qwen3.8-27Bが一般的なゲーム機で50 token/sの速度で動作するという報告がありました。HNのコメントには「Fable 5レベルのエンコーディング性能は、適切なハーベス設計さえあればローカルで実現可能だ」とあります。しかし、2つの問題があります。1つは量化によって推論の品質が損なわれるかどうか、もう1つはマルチエージェントリアルーチングの待ち時間です。ローカルでエージェントを動作させるのは速いかもしれませんが、5つのエージェントが連続して実行され、ファイルの読み書きやテストを加えると、全体の時間が増大します。

拾闻：では、frontier APIと比べてどうでしょうか？

永亮：frontier APIはトークンベースで課金されますが、利点は柔軟性と速さであり、機械にこだわる必要がありません。ローカルモデルは一度のハードウェア投資で、コストの限界が低いです。例えばQwen3.8-27Bを考えると、Bonsai 2で量化した後、一般的なゲーム機で50 token/sの速度で動作することができ、これは個人開発者や小規模チームにとって魅力的です。しかし、Memdoorの今回の実験では、マルチエージェントリアルーチングが最長4時間続きました。もしローカルのGPUが遅ければ、体験感は大きく損なわれます。コストは請求書だけで判断するのではなく、時間、複雑さ、障害率も考慮する必要があります。

Q4：タイトルにある「beats」にはどれだけ割引を適用すべきでしょうか？

拾闻：先ほど、割引を適用するように注意していましたね。具体的な注意点は何ですか？

永亮：1つ目、サンプルは最初の10問だけです。GVS5Hの論文では100問ですが、Memdoorは最初の10問のみを行っており、代表性に限界があります。2つ目、汚染の問題です。これら10問は2025年3月末から4月初旬のコンテストの問題であり、Qwen3.8-27Bの訓練データには既に出会っている可能性が高く、著者も「汚染を排除できない」と明確に述べています。3つ目、Fable 5は同じ環境で再実行されていないため、データはGVS5Hの著者のファイルから取得されており、ハーベスの違いを排除できません。4つ目、マルチエージェントの時間コストは非常に高く、中央値は40分、最長は4時間です。これは単一の呼び出しとは全く異なります。5つ目、OpenRouter上の異なるホストの精度は不明確であり、著者のローカル環境ではFP8 vLLMを使用していますが、クラウドでは異なる可能性があります。

拾闻：フォーラムのコメントはどう思いますか？

永亮：Hacker Newsでも、最初の10問はすでに飽和している可能性があると指摘されています。LiveCodeBench Hardも古いです。また、Qwen3.8-flash-nextのテストを期待する声もあります。なぜなら、flash-nextは多くのエンコーディングタスクで27Bよりも速く、強力だからです。著者自身も、プロンプトや温度を調整することで、10点満点を得る可能性があると認めています。これは、結果がパラメータに敏感であり、一つの固定されたレシピではすべてのケースに適用できないことを示しています。また、次のようなコメントがありました。「5つの27Bが5つのFable 5を上回ることができるでしょうか？」という質問は非常に的を射ています。なぜなら、真に公平な比較はマルチエージェント対マルチエージェントであり、マルチエージェントの小さなモデル対単一の呼び出しの大規模モデルではないからです。

拾闻：では、「5つの27BがFable 5を打ち負かした」というタイトルは、宣伝のためのものですか？

永亮：特定の文脈では事実ですが、一般的な結論とは程遠いです。これはプロジェクトの再現と方法の検証に近く、選択ガイドに書き込めるような結論ではありません。読者として、「beats」という表現を「限定条件下での比較可能性を示した」と理解しますが、「全面的な超克」とは考えていません。

Q5：第一線のエンジニアにとって、この出来事から得られる最大の教訓は何ですか？

拾闻：最後の質問ですが、もしこれが真実で拡張可能であれば、一般のエンジニアにとって何を意味しますか？

永亮：私たちの仕事の焦点が「コード書き込み」から「ワークフロー設計と受け入れ基準設定」へと移行することを意味します。過去2年間はpromptエンジニアリングに力を入れていましたが、これからはタスクを検証可能なステップに分割する方法、エージェント間の協力プロトコルを設計する方法、承認の門とロールバックポイントを設定する方法に焦点を当てます。Memdoorのワークフローには学ぶべき点がいくつあります：YAMLでステップを定義し、独立したステップを並行して実行し、失敗したステップを再試行でき、重要なステップには人的承認を加え、結果をディスクに書き戻すことでコンテキストに全て詰め込まないようにします。

拾闻：この変化はチーム構造にどのような影響がありますか？

永亮：最も直接的な影響は、「AIを使ってコードを書く」能力が希少なスキルではなく、「エージェントフローを設計する」能力が重要になることです。以前は高度なエンジニアの価値は複雑なアルゴリズムを書き出す能力にありましたが、今はどの問題が単一エージェントに適しているか、複数エージェントが必要なか、どのステップが人的承認が必要かを判断する能力が重要です。チーム内にはワークフロー設計者やエージェントレビュー担当者といった新しい役割が生まれます。管理者にとっては評価指標も変わる必要があります。コード行数だけでなく、プロセスの安定性、再現可能性、エラーの回復能力も考慮する必要があります。

拾闻：では、将来的にはエンジニアがコードを書く必要はなくなるのでしょうか？

永亮：そうではありません。しかし、「コード書き込み」はより小さなステップになり、より大きな価値は問題を定義し、プロセスを分解し、受け入れ基準を設計することにあります。かつてDevOpsが運用と開発を結びつけたように、今ではエージェントワークフローが要件分析、コード生成、テスト検証、人的承認を一連のプロセスとして連携します。将来、エンジニアの核心能力は、より美しい関数を書き出すことではなく、ビジネス問題をエージェントが実行可能なフローチャートに変換することかもしれません。

拾闻：試してみたいチームにどのようなアドバイスがありますか？

永亮：まずは自分の実際のコードタスクから始めて、ベンチマークの数字で選択を決めないようにしてください。具体的なバグ修正や再設計のタスクを取り上げ、MemdoorやGVS5Hの方法で実行し、時間、トークンコスト、正確率を記録してください。同時に、受け入れ基準を明確に設定する必要があります。例えば、単体テストは必ず通過し、人的レビューも通過しなければなりません。そうでないと、複数のエージェントが自分自身を閉じ込める可能性があります。最後に、ローカルモデルを無料の食事券として扱わず、ハードウェア、量化精度、推論の遅延も考慮に入れましょう。チームがローカルGPUの運用経験がない場合は、OpenRouterのようなBYOKソリューションから始める方が現実的です。

---

署名：永亮