27BモデルでSWE-benchを伸ばす発想

SWE-bench Verified のような実コード修正ベンチマークを見ると、どうしても「どのモデルが強いか」に目が向きがちです。ですが、今回の fltech.dev の記事で本当に面白いのはそこではありません。Qwen3.5-27B を追加学習なしで使い、TTS@8 で 74.8% を達成したという結果以上に、「モデル単体の賢さ」ではなく「エージェント・評価・選抜・引き継ぎ・検証を含むハーネス設計」がどれだけ効くかをかなり具体的に示している点が重要です。この記事では、その内容をもとに、なぜ 27B という比較的小さいモデルでもここまで到達できたのかを整理します。

本質はモデル性能ではなくハーネス設計

記事で一番伝えたいメッセージは明確です。SWE-bench のようなベンチマークでは、訓練だけでなく、エージェントと評価系を含むハーネスエンジニアリングが同じくらい重要だ、ということです。ここでいうハーネスとは、単に推論を呼ぶラッパーではなく、複数 run の候補生成、FAIL_TO_PASS / PASS_TO_PASS による検証、最終パッチの選抜、フェーズ遷移、共有ファイル、引き継ぎ、再試行制御までを含む実行基盤そのものを指します。

つまり、27B モデルが突然 70% 超えの問題解決能力を持ったというより、27B モデルをどう使えば OSS issue 修正という複雑タスクで力を出せるかを、かなり丁寧に設計した結果として読むべきです。

8本の候補生成と選抜が効いている

今回の構成は、1回の生成で最終解を決める方式ではありません。Qwen3.5-27B による 8 runs の候補を生成し、その後で simple weighted pass-rate に基づいて最終提出パッチを1本選んでいます。ここで使うのが TTS@8 という考え方です。

この設計が重要なのは、探索と選抜を分離していることです。単発の run では、たまたま良い修正に当たるかどうかに引っ張られます。しかし複数候補を作って比較すれば、

• 候補の多様性を持てる
• 回帰を起こしていない修正を選びやすい
• 単一モデルでも全体性能を押し上げられる

という利点が出ます。ここは「より大きいモデルを使えば勝てる」という発想とかなり違います。

フェーズ分割と共有資産がループを防ぐ

記事の中で特に良いのは、ISSUE_REPRODUCT、TEST_SYNTHSIZE、CODE_LOCALIZE、TEST_LOCALIZE、CODE_FIX、VERIFY_PATCH、ISSUE_CLOSE、FINAL_REPORT といったフェーズ分割をかなり明示しているところです。これは単なる整理ではなく、エージェントが途中で迷走したり、同じ探索を繰り返したりするのを防ぐ仕組みとして効いています。

さらに /_share/ 配下にメモ、再現スクリプト、テスト、trace ログ、handover を残し、会話履歴だけに頼らない構成にしているのも重要です。長いタスクでは、モデルの文脈保持だけに頼るとすぐ破綻します。共有ファイルを前提にしておけば、同一フェーズの圧縮や引き継ぎをしても、再現・検証・修正の状態を失いにくいです。

このあたりは、まさに「コーディングモデル」ではなく「コーディングシステム」を作っている話です。

27Bでここまで行けるのは、今後の実装現場にも効く

今回の 74.8% という数字自体も強いですが、それ以上に意味があるのは、229B 未満のローカル LLM として SOTA 級の位置に来ている点です。これが示すのは、「強い実装システムを作れば、巨大モデル一辺倒でなくても戦える」ことです。

これは研究ベンチマークだけの話ではありません。現実の開発現場でも、

• どのフェーズで何をやらせるか
• どこで再現テストを作るか
• どこで修正候補を比較するか
• どうやって文脈を圧縮して引き継ぐか

を設計したほうが、単に最大モデルを叩くよりコスト効率が良い場面はかなり多いです。

今回の記事は、そのことをかなり具体的に示している良い例でした。特に @yuma_1_or さんも著者陣に入っているこの事例は、「モデルを替える」より「ハーネスを作る」ほうが効く場面があることを強く示しています。元記事は fltech.dev のエントリ なので、SWE-bench やエージェント型コーディングの実装に関心がある人は、本文もかなりおすすめです。これからの勝負は、モデル単体の IQ ではなく、ハーネス込みでどこまで安定した問題解決システムを作れるかに移っていると感じます。