SWE-Legoとは？SFTだけでSWE-bench Verified 58.8%に届いた学習レシピの仕組みと再現手順

SWE-Legoは、Huawei Technologiesを中心とする研究チームが2026年1月4日にarXivで公開した、ソフトウェアのバグ修正（issue resolving）を行うAIエージェントを教師ありファインチューニング（SFT）だけで鍛える学習レシピです。名前の「SWE」はSoftware Engineering（ソフトウェアエンジニアリング）の略で、Qwen3-32Bを土台にしたモデルがSWE-bench Verifiedで52.6%、検証器を使った16本の並列試行で58.8%を記録しました。

この記事では、論文（arXiv:2601.01426 v2）の表と追加実験の数値をもとに、3つの構成要素がそれぞれ何ポイント効いたのか、スコアを読むときに外せない注意点、公開されたモデルとデータでどこまで再現できるのかを整理します。

まとめ：SWE-Legoの要点（2026年11月時点）

• 強化学習や中間学習（mid-training）を使わず、SFTだけで論文公開時の比較で同規模のオープンモデルの最高水準に届いた
• Qwen3-32Bの23.2%を58.8%まで上げた内訳は、データセットが+25.6ポイント、SFTの改良が+3.8ポイント、テスト時スケーリングが+6.2ポイント。効いたのは大半がデータ
• データセットは実在のGitHub PR由来18,409件と合成バグ13,710件の計32,119件、検証済みの軌跡は約18k本
• 論文のスコアは、Git履歴から正解を覗く「Git hacking」を塞いだ条件の値。塞がない条件では32Bが57.6%で、比較相手の多くは塞がない条件の値
• エージェントモデル2種・検証器2種・データセット2種・コードはApache-2.0表記で公開済み（検証器のカードには2026年11月6日に追記された）。GitHubはLegoX/SWE-Lego、Hugging FaceはLego-Xへ移転し、旧URLは転送される
• 評価はPythonリポジトリのバグ修正だけ。OpenAIは2026年2月にSWE-bench Verifiedの報告をやめており、この数値を実務性能の目安にするには注意がいる
• 同じチームはその後、強化学習のLego-RL（Qwen3.5-35B-A3BでVerified 70.4%）や、8言語のタスクを作るLegoFlowへと研究対象を広げている

SWE-Legoの位置づけ：SWEエージェントとSFTだけを選んだ理由

SWEエージェントとは、リポジトリを読み、バグを再現し、修正箇所を特定してパッチを書き、テストで確かめるまでを自律的に行うAIエージェントのことです。代表的な実行基盤（スキャフォールド）にはOpenHandsやSWE-agentがあり、SWE-Legoの学習と評価はOpenHands 0.53を使っています。エージェント全般の仕組みはコーディングエージェントの解説で扱っています。

こうしたエージェントを小さなオープンモデルで作るとき、2025年の主流はSFTに中間学習や強化学習を組み合わせる方法でした。論文はこれに対し、強化学習は計算資源と学習基盤が重く、ハイパーパラメータ次第で学習が崩壊しやすいと指摘し、「SFTだけでどこまで行けるか」を問いに立てています。強化学習による調整の一般的な手順はRLHFの解説を参照してください。

著者はHuawei Technologiesのほか、南洋理工大学（NTU）、香港大学（HKU）、香港中文大学（CUHK）の14名です。v1は2026年1月4日、v2は1月7日に公開されました。

3つの構成要素と性能への寄与

SWE-Legoは、データセット、改良したSFT、テスト時スケーリング（TTS）の3つの「ブロック」を積み上げる構成です。Lego（レゴ）という名前はこの積み上げ方に由来します。論文の図1(b)は、Qwen3-32Bに順に足したときの解決率を示しています。

上積みの7割以上はデータセットによるものです。手法の工夫より、実行可能な課題と検証済みの軌跡をどれだけ揃えるかが性能を決めた、というのがこの論文の一番の結論です。

SWE-Legoデータセットの中身

土台はSWE-rebenchで、寛容なライセンスで保守が続いているPython中心のリポジトリ3,000件超から、Dockerでビルドとテストが通るものだけを残しています。最終的なリポジトリ数は3,251件で、既存の公開データセット（SWE-smithの128件、SWE-Gymの11件など）より大幅に多くなっています。

実データと合成データの違い

次の表の変更ファイル数・変更行数・Fail-to-Passテスト数は、1課題あたりの平均値です。検証済み軌跡の行は、全テストを通過した解決済み軌跡だけを数えています。

実データは本物のissueとマージ済みPRなので複雑ですが、課題ごとに修正前のコミットでサンドボックスを作る必要があり、厳しい選別条件と環境構築の負担が規模拡大を難しくします。合成データはSWE-smithの手法に従い、関数のシグネチャとdocstringだけを渡してLLMに書き直させる方法と、構文木（AST）から条件分岐やループを消すなどの変形を加える方法でバグを作ります。同じリポジトリの合成課題はサンドボックスを共有できるため、安く量産できます。論文の図3では、同じリポジトリ集合でも合成課題を足すほど解決率が上がっています。

教師軌跡の作り方と取り除いた3つの問題

軌跡（エージェントの行動と環境の応答の全記録）は、Qwen3-Coder-480B-A35B-Instructを教師にOpenHandsで最大100ターン回して集めています。その過程で見つかった問題を3つ潰しました。

• Git hacking：git logやgit showで将来のコミットを覗き、正解を写してしまう挙動。実データはissue作成日より後のコミットを消し、合成データはGit履歴を丸ごと消した
• ツール呼び出しの書式ミス：view_rangeに文字列を渡す、ファイルの行数を超える範囲を指定するなど。整数への変換と範囲の切り詰めで事後補正した
• 使いこなせないツール：教師モデルはtask_trackerをうまく使えず、エラーを連発した。ツールをexecute_bash・str_replace_editor・think・finishの4つに絞った

100件で測った有効軌跡率は、3つとも適用した状態で30%、平均62.5ターンでした。Git hackingを塞ぐと有効率は31%から30%に下がりますが、これは「水増しされていた分が消えた」と読むべき数字です。

半解決軌跡の再利用

テストを全部は通せなかったものの、修正すべきファイルは正しく開けていた軌跡を「半解決（semi-resolved）」として約4k本学習に加えています。Qwen3-8Bで、解決済み14.6k本だけなら40.4%、テストを書き換えるなどの低品質な解決軌跡を除くと41.0%、半解決を足した18.1k本で42.2%でした。失敗した試行にも、バグの場所を突き止める手順という教材が残っているということです。

SFTの改良：エラーマスキングと難易度カリキュラム

学習はLLaMA-Factoryによる全パラメータのSFTで、Qwen3-8Bと32Bを4エポック、グローバルバッチ64、学習率は8Bが1e-4・32Bが5e-5です。長い軌跡を扱うため、YaRNで最大128kトークンまで文脈を延ばしています。LoRAなどの軽量な方法でなく全パラメータを更新する設定なので、学習には複数GPUが前提です。ベースモデルの系譜とライセンスはQwen3の解説で整理しています。

ステップ単位のエラーマスキング

成功した軌跡にも、引数の誤ったツール呼び出しのような途中の失敗が混ざっています。エラーマスキングは、軌跡の文脈はそのまま残したうえで、ターミナルが返したエラーメッセージを正規表現で検出し、その直前のエージェント応答だけを損失計算から外す方法です。ただし、バグの再現やテスト実行で出るエラーは「意図した失敗」なのでマスクしません。公開されたLLaMA-Factoryの改変版では、設定のturn_mask: trueで有効になり、フラグの立った応答のラベルを無視値に置き換える実装になっています。

ターン数で決める難易度カリキュラム

難易度の測り方は2つ比べています。人手で付けた1.5k件の難易度ラベルでQwen2.5-Coder-32B-Instructを学習させた判定器（正答率70%）と、軌跡のターン数を使う方法です。ターン数と解決率の相関はr＝-0.95と強く、ターン数による分類のほうが0.5ポイント良かったため、こちらを採用しました。0〜50ターンを易、50〜70を中、70〜100を難とし、3段階で学習します。前の段階のデータは次の段階にも含めて、覚えたことを忘れにくくしています。

2つのうち効きが大きいのはエラーマスキングで、外すと8Bで2.0、32Bで2.2ポイント落ちます。学習中の失敗の内訳も変化し、1エポック目までは「バグを再現できない」が38.97%を占め、その後は「ターン上限切れ」（35.14%）、終盤は「誤った実装」と「修正箇所の特定ミス」が残りました。

テスト時スケーリング：逐次試行と並列試行への計算配分

推論時に計算を足す方法は2つあります。1回の試行で使える最大ターン数を増やす逐次スケーリングと、複数回試行して検証器に一番良いものを選ばせる並列スケーリングです。

逐次スケーリングは100〜140ターンで頭打ち

ターン数を増やすと、エラーから立て直す機会が増えるので、少ないターン数の範囲では効率よく伸びます。しかし100〜140ターン付近で伸びが止まります。それ以上のターンを使う軌跡は、効かない手を繰り返して行き詰まっていることが多いためです。文脈が伸びるほど1ターンあたりの計算も増えるので、論文は「まず飽和点までターンを増やし、残りの予算を並列試行に回す」配分を勧めています。

生成型検証器と回帰型検証器の解決率比較

検証器は、軌跡とパッチを受け取り、解決できている確率を0〜1で返します。スコア用の出力層を付けて学習する回帰型と、「yes／no」を生成させてトークン確率から点数を出す生成型を、同じデータ（解決5k本・未解決13k本）で比べると、8Bの16本試行で生成型49.6%、回帰型46.8%でした。

既存の検証器と比べても、SWE-Lego-Verifier-8Bの49.6%に対し、R2E-Gym-Verifier-14Bが47.0%、OpenHands-Critic-32Bが44.0%です。回帰型のOpenHands-Criticは候補を増やすと逆に成績が落ちました。16本のうち1本でも正解があれば正解とみなす上限（Pass@16）は66.0%なので、選び方にはまだ伸びしろがあります。

SWE-bench Verifiedでの結果と他手法との比較

論文の表7から、同規模のオープンモデルを抜き出しました。SWE-Legoの値は「Git hackingあり／なし」の順で併記されています。

8BモデルはSFTだけで、強化学習を使ったDeepSWE-32B-Preview（42.2%）と同じ値に並びました。一方、Git hackingを塞いだ条件の32B単発（52.6%）は、CWM-32Bの53.9%を下回ります。同じ表の商用モデルでは、Claude Sonnet 4.5が70.6%、GPT-5が71.8%、Gemini 3 Pro Previewが74.2%で、差はまだ大きいままです。

スコアを読むときの3つの注意

SWE-Legoの数値をそのまま他の発表と並べると、3つの点で読み違えます。

Git hacking対策の有無による評価条件の違い

2025年9月3日、SWE-benchのGitHubに「評価中のエージェントがリポジトリの状態から正解を拾える」という報告（issue #465）が上がりました。論文によれば、それ以前に配布されたSWE-bench VerifiedのDockerイメージには正解のコミットが残っている場合があり、git log --allなどで正解に辿り着けます。SWE-Legoは最新イメージで塞いだ条件の値を主に報告していますが、論文自身が、表7に並ぶ他手法の値はGit hackingで水増しされている可能性が高いと注記しています。過去の報告との参考比較には「あり」の列も使えますが、実行基盤や推論予算も異なるため、それだけで同条件の比較にはなりません。

SWE-bench Verified自体の限界

OpenAIは2026年2月23日、SWE-bench Verifiedの結果を報告しないと発表しました。モデルが解けなかった問題を中心に全体の27.6%を監査したところ、少なくとも59.4%で正しい解答を不合格にするテストの欠陥が見つかったこと、試したすべての最先端モデルで、一部の課題の正解パッチ、または問題文の具体的な記述を逐語的に再現する挙動が確認されたことが理由です。当時は代わりにSWE-bench Proの公開セットを推奨しましたが、2026年7月にはProでも約30%の課題が壊れていると見積もり、その推奨を撤回しています。SWE-Legoの論文が評価しているのはVerifiedだけなので、Proや多言語版での実力は未知数です。

SWE-CIが測る長期保守との違い

SWE-bench Verifiedは、1つのissueに対して1回パッチを当て、その時点でテストが通るかを見るベンチマークです。修正が後の機能追加で壊れないかは測りません。この空白を埋めるために2026年3月4日に公開されたのがSWE-CI（arXiv:2603.03823）です。実在のPythonリポジトリ4,923件から選んだ100タスクは、それぞれ平均233日・71コミット分の開発履歴を持ち、エージェントは要件の生成、コード修正、テスト実行のCIループを何十回も回して最終コミットのテストを通しにいきます。

論文の評価では、一度通したテストを最後まで一度も壊さなかった割合（ゼロ回帰率）が大半のモデルで0.25未満、0.5を超えたのはClaude Opusの2モデルだけでした。SWE-Legoのように1問1パッチで解決率を伸ばしたモデルが、継続的な保守でも同じように働くかは別に確かめる必要があります。社内のリポジトリにエージェントを入れるなら、解決率よりも、変更後に既存テストを壊していないかを自動で確かめる仕組みを先に用意してください。

公開物と再現手順（2026年11月10日時点）

公式リポジトリのREADMEは「データセット、モデル、コード、学習スクリプトのすべてを公開した」としています。2026年2月27日には検証器の学習・推論の設定が追加されました。

モデル・データセット・検証器の一覧

累計ダウンロード数は2026年11月10日に取得したHugging FaceのLego-X組織のAPI値（downloadsAllTime）です。検証器2種のモデルカードは公開当初ライセンスの記載がなく、2026年11月6日の更新でlicense: apache-2.0が追記されました。ダウンロード数は対象ファイルへのリクエストを数える指標であり、実際にモデルを動かした人数や利用環境を示すものではありません。ベースのQwen3-8B・32BもApache-2.0です。GitHubのSWE-Lego/SWE-LegoはLegoX/SWE-Legoへ、Hugging FaceのSWE-Lego組織はLego-Xへ移っており、READMEやスクリプトに書かれた旧名でも転送されます。

推論と評価の流れ

リポジトリにはOpenHands 0.53.0、SWE-bench 4.0.4、LLaMA-Factory 0.9.4.dev0の改変版が同梱されており、vLLMでモデルを立て、OpenHandsで推論し、SWE-benchで採点する3段構成です。8B用の配信スクリプトは次のとおりです。

python -m vllm.entrypoints.openai.api_server \
    --model SWE-Lego/SWE-Lego-Qwen3-8B \
    --served-model-name Qwen/Qwen3-8B \
    --tensor-parallel-size 8 \
    --gpu-memory-utilization 0.9 \
    --max-model-len 163840 \
    --max-num-seqs 24 \
    --api-key "dummy-key"

8Bでもテンソル並列8、つまりGPU 8枚を前提にした設定です。--served-model-nameをベースモデル名にしているのは、同梱のOpenHands設定（config.tomlの[llm.eval_qwen3_8b]）がopenai/Qwen/Qwen3-8Bという名前でモデルを呼ぶためです。同じ設定で温度は0.0、入力上限は147,456トークンに固定されています。学習環境はPyTorch 2.8.0（CUDA 12.8）とLinux x86_64向けのflash-attn 2.8.3のホイールを入れる手順で、macOSやCUDAのない環境は想定されていません。

READMEの環境構築（vLLM・OpenHands・SWE-benchのconda環境）を済ませて配信を立てたら、別の端末でリポジトリ直下から推論と採点を順に実行します。

bash scripts/swe_lego_qwen3_8b/infer.sh
bash scripts/swe_lego_qwen3_8b/eval.sh

推論スクリプトはhttp://localhost:8000/v1の配信へ接続し、最大100ターン・24並列でSWE-bench Verifiedの500問を解きます。結果はOpenHands-0.53.0/evaluation/evaluation_outputs/配下のoutput.jsonlに書き出されます。採点スクリプトはこれをSWE-benchの形式に変換し、SWE-bench-4.0.4/results/にレポートを出します。採点は課題ごとにDockerコンテナを立てるため、Dockerが動く環境が必要です。

検証器で16本の候補から1本を選ぶ手順

TTS@16の値を再現するには、エージェントで同じ問題を複数回解かせたあと、検証器で候補を順位付けする工程が要ります。論文の組み合わせは、8Bエージェント（49.6%）には8B検証器、32Bエージェント（58.8%）にはQwen3-Coder-30B-A3Bを土台にした30B-A3B検証器です。前節の推論スクリプトは試行回数N_RUNSが既定で1なので、候補を16本集めるにはここを増やして回す必要があります。この工程は2026年2月27日にREADMEの4章として追加されました。検証器の学習データLego-X/SWE_Lego_real_data_Verifierは17,642行で、各行が「軌跡＋パッチ＋判定」の3つで構成されます。推論時に渡すのは軌跡とパッチだけで、判定は検証器が予測します。

次は8B検証器で採点する例です。

python LLaMA-Factory-0.9.4.dev0/tts/convert_trajectories_to_verifier.py     --input /path/to/raw_trajectories.jsonl     --output /path/to/verifier_input.jsonl
bash scripts/swe_lego_verifier_qwen3_8b/infer.sh /path/to/verifier_input.jsonl

変換スクリプトは、問題ごとにrun_1・run_2…と並んだ試行（funccalloff_messages・patch・resolved）を読み、検証器用のsystem＋userメッセージに組み直します。infer.shはvLLMではなくLLaMA-Factory側のPythonスクリプトをbf16で動かし、既定でoutputs/verifier_predictions_8b.jsonlに試行ごとのpredicted_scoreを書き出します。このスコアが最も高い試行のパッチを採用するのが並列スケーリングです。検証器を自前で学習し直す場合はscripts/swe_lego_verifier_qwen3_8b/sft.sh（30B-A3B版もある）を使います。

公開設定と論文設定の違い

公開された学習設定で、論文の42.2%・52.6%がそのまま出るとは限りません。設定ファイルと論文を突き合わせると、次の2点が異なります。

• 半解決軌跡が入っていない：設定ファイルが読むのは実データと合成データのresolved分割だけで、行数は5,009＋9,127＝14,136本。論文で+1.2ポイント効いた約4kの半解決軌跡は、unresolved分割（13,027＋2,344本）から選び分ける手順がREADMEに書かれていない
• カリキュラムの3段階分けがない：8B・32Bの設定はどちらも1回の学習で4エポック回す構成で、難易度別に段階を分けるスクリプトはリポジトリに含まれていない

エラーマスキング（turn_mask: true）、YaRN、学習率、エポック数は論文どおりです。論文の8Bの追加実験では、半解決軌跡なしが41.0%（表5）、カリキュラムなしが41.8%（表6）でした。これらの追加実験は個別の要素を外した結果であり、公開設定そのものの解決率を示す値ではありません。公開設定で再学習した結果は、別途評価して比較する必要があります。

SWE-Legoが向かない用途

• Python以外のリポジトリ：学習データはPython中心で、論文の付録Cも、JavaScript/TypeScript・Java・Go・Rustへの拡張は今後の課題としている。多言語が要るなら、後述のLegoFlow-SWE（8言語）を見るほうが早い
• 新機能の実装やリファクタリング：学習も評価もバグ修正に限られ、要件があいまいな機能実装は対象外と付録Cで明言している
• GPUの少ない環境での運用：公開スクリプトは8B・32BともGPU 8枚の構成。16本の並列試行と検証器まで含めると、1問あたりの計算量はさらに膨らむ
• 商用モデルの置き換え：同じ表でもClaude Sonnet 4.5やGPT-5とは10ポイント以上の差がある。手元で動く再現可能な研究基盤として使うのが現実的

逆に向いているのは、社内のリポジトリで小型モデルのバグ修正エージェントを作りたいときに、データの集め方・軌跡の選別・損失のマスクという手順の型を借りる使い方です。業務システムにエージェントを組み込む段階の設計や運用は、AIエージェント開発の支援でも扱っています。

後続プロジェクト：SWE-Review・Terminal-Lego・Lego-RL・LegoFlow

同じチームは2026年に入ってから、GitHubのLegoX組織とHugging FaceのLego-X組織でSWE-Legoの周辺を広げています。日付はリポジトリ・論文・モデルの公開日です。

SWE-Reviewは、パッチを書くエージェントとは別に、レビュー役のエージェントが独立に原因を追い、生成・レビュー・修正を繰り返す仕組みです。モデルカードはSWE-bench Verifiedの解決率を最大29.4ポイント上げたとしています。

Terminal-Lego（arXiv:2606.03461）は、SWE-Legoと同じく教師の軌跡で生徒モデルを学習させる研究を、ターミナル操作に広げたものです。Terminal-Bench 2.0の単体成績はClaude Opus 4.6のほうが高いのに、成績の低いDeepSeek-V3.2の軌跡で学習した生徒のほうが汎化した、という結果を報告しています。調べる・操作する・確かめるという手順が軌跡に表れているかが効いた、というのが著者の説明です。SWE-Legoで教師を選ぶときも、教師の解決率だけで決めないほうがよいことを示しています。

SWE-Legoとの関係が最も深いのはLego-RLです。Claude Code・OpenHands SDK・OpenCodeを本来の動作のままサンドボックスで走らせ、タスクの検証器が返す報酬で方策を更新します。論文では、Qwen3.5-35B-A3BのSWE-bench Verifiedの解決率が、OpenHands SDKで64.0%から70.4%、Claude Codeで62.4%から68.2%、OpenCodeで57.2%から66.6%に上がりました。評価は温度0.7・200ターン・20万トークンの条件で、SWE-Legoの温度0.0・100ターンとは条件が違うため、数字をそのまま並べることはできません。2026年11月6日には、3つのハーネスを混ぜて学習した90ステップ目のチェックポイントLego-RL-Qwen3.5-35B-A3B-Mixed-step90もApache-2.0で公開されています。

LegoFlowは、リポジトリとPRの収集からタスクの検証、軌跡の生成、学習、評価までをClaude CodeやCodexから呼べる手順として束ねたデータ基盤です。同時に公開されたLegoFlow-SWEは、1,200万件超のPRから選んだ8言語・5,000タスクと、成功した軌跡2,780本を含みます。READMEは、このうち1,000件だけで学習したQwen3.5-35B-A3BがSWE-bench Verifiedで70.2%、SWE-bench Proで48.8%に届いたとしています。SWE-Legoが今後の課題に挙げていた多言語化と強化学習の2つを、同じチームが別プロジェクトで埋めにいっている、という位置関係です。

SWE-Legoに関するよくある質問

SWE-LegoのSWEとは何の略ですか？

Software Engineering（ソフトウェアエンジニアリング）の略です。SWE-benchやSWE-agentと同じ使い方で、ソフトウェア開発の実務課題、特にGitHubのissueを解決するタスクを指します。職種としてのソフトウェアエンジニアの意味ではありません。

SFTとは何ですか？

Supervised Fine-Tuning（教師ありファインチューニング）の略で、正解となる出力例を与えて事前学習済みモデルを追加学習させる方法です。SWE-Legoでは、教師モデルQwen3-Coder-480B-A35B-Instructがバグを解いた軌跡を正解例として、Qwen3-8B・32Bに学習させています。

SWE-Legoのモデルは商用利用できますか？

SWE-Lego-Qwen3-8B・32B、検証器2種、データセット2種のカードにはApache-2.0が記載されています（検証器は2026年11月6日に追記）。ベースのQwen3もApache-2.0です。ただし後続のLego-RLの学習用データLego-RL-2699はAGPL-3.0なので、周辺のデータを混ぜて使うときは1つずつ確かめてください。

SWE-LegoとOpenHandsの関係は？

OpenHandsは、エージェントがコマンド実行やファイル編集を行うための実行基盤です。SWE-Legoは教師軌跡の収集にも評価にもOpenHands 0.53を使っており、公開モデルもOpenHandsから呼ぶ前提の設定になっています。

SWE-Lego-Qwen3-8Bを1枚のGPUで動かせますか？

公開スクリプトはGPU 8枚の構成で、1枚での動作は案内されていません。8Bの重み自体はbf16で約16GBですが、評価では最大163,840トークンの文脈を24並列で扱うため、そのぶんメモリが必要になります。1枚で試すなら、文脈長と並列数を下げて性能が変わることを前提に検証してください。

関連記事

• OpenHandsとは？自律型AIコーディングエージェントの仕組み・使い方・料金とAgent Canvas移行【2026年10月】
• Coding Agent（コーディングエージェント）とは：仕組み・3つの型と主要ツールの料金・選び方【2026年11月】
• RLHFとは？人間のフィードバックで言語モデルを調整する3段階の仕組みと採用判断【2026年版】
• Qwen3とは？読み方・モデル一覧・72Bの有無・商用利用と動かし方