これは何の論文か
この論文が良いのは、エージェントのログを「反省材料」で止めないところだ。失敗トレースを読んで運用ルールを足すだけだと、スキルや MEMORY はすぐ厚くなる。しかし厚くなったルールが、次の行動で本当に効いたかは別問題になる。
Socratic-SWEは、トレースをスキルにし、そのスキルから次のタスクを作り、実行で検証し、解答役を更新する。つまり、ログ、スキル、テスト、改善を一本の循環にしている。Codex スキルや learn-from-ログの運用を考える時、この見方はかなり直接使える。
特に重要なのは、スキルが単にプロンプトに追記される知識ではなく、次のカリキュラムを作る材料になっている点だ。良いスキルは、次に何を試すべきかを決める。ここまで含めてスキル 設計・運用 と見ると、個人AIアシスタントの改善設計が一段具体になる。
Socratic-SWEは、LLM-driven ソフトウェアエンジニアリングエージェントを自己進化させるために、過去の解決トレースを構造化エージェントスキルへ蒸留する論文である。コーディングエージェントの改善を、モデル単体の能力向上ではなく、トレース、スキル、タスク生成、検証、解答役更新のループとして扱う。
既存の synthetic タスク生成は、固定的な mutationや bug injection に寄りやすい。すると、今のエージェントが実際に苦手としている失敗パターンや、うまく直せた修復パターンから外れた課題が増える。Socratic-SWEは、エージェントが実際に残した成功・失敗トレースを読み、recurring failures と修復 パターンs を抽出する。
抽出された知識は、単なるログ要約ではなく、次に使えるスキルとして構造化される。そのスキルは、実リポジトリ上で 狙いを絞った修復タスク を作るために使われ、候補タスクは実行ベースの検証と解答役の学習段階に合わせる報酬 で選別される。
arXiv abstract によれば、SWE-bench Verified、SWE-bench Lite、SWE-bench Pro、Terminal-Bench 2.0で、同等 computeの self-evolving baselines を一貫して上回り、SWE-bench Verified では 3 反復 後に 50.40% に到達したと報告されている。
この論文は、ソフトウェアエンジニアリングエージェントの訓練と改善において、高品質なタスク供給がボトルネックになる問題を扱う。SWE エージェントは実用的な評価対象として重要だが、エージェントが学ぶべきタスクをどう作るかは難しい。
Socratic-SWE の発想は、エージェントがすでに解いた、または失敗したタスクのトレースに、次の学習タスクを作るヒントがあるというものだ。成功トレースには修復手順があり、失敗トレースには recurring 失敗がある。これらを捨てず、スキルとして再利用する。
何が問題だったのか
ソフトウェアエンジニアリングエージェントは、過去の成功や失敗から学べるように見える。しかし、実行トレースをただ要約してスキルにしても、次のタスクで本当に役立つとは限らない。
問題は、どの失敗パターンをスキル化し、どの修復パターンを次の訓練タスクへ変換するかである。汎用的な合成バグを増やすだけでは、解答役の現在の弱点や学習段階に合わない可能性がある。
Socratic-SWE が扱う問題は、過去トレースからスキルを蒸留し、そのスキルを使って狙いを絞った修復タスクを作り、実行結果でさらに更新する閉ループをどう作るかである。
既存の自己改善型コーディングエージェントでは、過去トレースを学習材料にする発想はある。しかし、どの失敗パターンをスキル化し、どの修復タスクを次に解かせるべきかが弱い。
Socratic-SWE は、トレースから構造化スキルを蒸留し、そのスキルで狙いを絞った修復タスクを作る。候補タスクを実行ベースで選び、解答役の学習段階に合わせる点が差分である。
提案手法の中身
まず解答役エージェントがソフトウェアエンジニアリングタスクを解く。ここで、成功、失敗、途中のツール利用、修復の試行、検証結果を含む実行軌跡が残る。
次に、その実行軌跡から recurring failures と修復 パターンs を取り出す。どの種類の変更でつまずいたか、どの観察やテストが修復に効いたか、どの手順が再利用できるかをスキルとして構造化する。
構造化されたスキルは、次の 狙いを絞った修復タスク生成に使われる。つまりスキルは、エージェントに読ませる知識であるだけでなく、弱点に合う新しい訓練タスクを作る 生成器の材料になる。
生成された候補タスクは、実リポジトリ上で実行可能か、検証できるかを実行ベースの検証でふるいにかける。ここで、見た目だけ plausible なタスクや検証不能なタスクを落とす。
さらに、解答役の学習段階に合わせる報酬 により、そのタスクが解答役の改善方向に合っているかを見る。単に難しいタスクではなく、今の解答役が学ぶ価値のあるタスクを残す。
最後に、選別されたタスクで解答役を更新し、新しい解答役がまた SWE タスクを解く。この更新後のトレースが次の反復の材料になり、スキルと curriculum が進化していく。
どうやって確かめたのか
評価では、SWE-bench Verified、SWE-bench Lite、SWE-bench Pro、Terminal-Bench 2.0 のようなソフトウェア修正・端末操作ベンチマークを使う。実際の失敗軌跡からスキルと練習課題を作り、反復後の解答役が改善するかを見る。
比較対象は、同程度の計算量を使う自己改善ベースライン、単純な合成タスク追加、Socratic-SWE の反復構成である。焦点は、タスクを増やすことではなく、失敗軌跡から次に練習すべき課題を作る点にある。
測る指標は、各ベンチマークの解決率、反復ごとの改善、同じ計算量のベースラインとの差である。
結果はどうだったのか
arXiv abstract では、Socratic-SWEが SWE-bench Verified、SWE-bench Lite、SWE-bench Pro、Terminal-Bench 2.0で、同等 computeの self-evolving baselines を一貫して上回ったと報告されている。
特に SWE-bench Verified では、3 反復 後に 50.40% に到達したとされる。これは、単発の合成タスク追加ではなく、トレースからスキルとタスクを更新し続けることが効いたという読みになる。
ただし、このページでは abstractと arXiv メタデータを中心に確認している。詳細なアブレーション、スキルスキーマ、評価設定の細部は、PDF 本文を精読してから扱うのがよい。
限界・注意点
- この論文を実務に移す時の核は、失敗ログをどの粒度でスキル化するかだ。抽象化しすぎると一般論になり、細かすぎると再利用できない。失敗パターン、修復パターン、検証方法、適用条件を分けて残す必要がある。
- もう一つの論点は、スキルからタスクを作る時の検証である。人間の反省メモなら『次から気をつける』で済むが、エージェントの改善ループでは、そのスキルが作ったタスクが本当に実行可能で、改善に効くかをゲートする必要がある。
- 個人AIアシスタント運用に引き寄せるなら、learn-from-ログの出力を MEMORY 追記で終わらせず、次に失敗しやすい代表課題、回帰テスト、スキル更新候補、拒否した更新候補に分ける設計が考えられる。
おい丸のようなエージェントにどう使えるか
おい丸のような作業支援エージェントでは、過去ログをそのまま要約しても次の改善にはつながりにくい。どの失敗パターンをスキルにし、どの修復練習へ変えるかを分ける必要がある。
Socratic-SWE 的に見るなら、ログ振り返りはスキル作成だけでなく、次に解かせる検証タスク作りにも使える。弱点に合う小さな修復タスクを作り、結果をまたスキル更新へ戻す流れが効く。
Q&A
この論文の中心問いは？
コーディングエージェントの過去トレースを、次のスキルと訓練タスクを作る材料として使えるか、という問い。
Socratic-SWE は何を自己進化させる？
解答役エージェントと、その解答役に合わせたスキル、狙いを絞った修復タスク、カリキュラムを閉ループで更新する。
トレース-由来エージェントスキルとは？
エージェントが過去に残した成功・失敗トレースから、繰り返す失敗や修復パターンを抽出し、次の行動やタスク生成に使える形へ構造化したスキル。
従来の synthetic タスク生成と何が違う？
固定的な変異やバグ注入ではなく、解答役の実際のトレースから弱点や修復手順を取り出し、それに合う 狙いを絞った修復タスク を作る点が違う。
なぜ実行ベースの検証が必要？
生成されたタスクが見た目だけ plausible でも、実リポジトリ上で実行・検証できなければ訓練に使いにくい。実行で候補をふるいにかけるために必要。
解答役の学習段階に合わせる報酬 は何のため？
候補タスクが今の解答役の改善方向に合っているかを評価するため。単に難しいタスクではなく、学習に効くタスクを残す。
結果として何が示された？
abstract では、SWE-bench Verified、SWE-bench Lite、SWE-bench Pro、Terminal-Bench 2.0 で同等 computeの self-evolving baselines を上回り、SWE-bench Verified では 3 反復 後に 50.40% に到達したと報告されている。
個人AIアシスタント運用にどう効く？
ログから MEMORY やスキルを追記するだけでなく、次の検証タスク、回帰テスト、reject buffer まで作る改善ループとして設計できる。
読む時に注意することは？
このページは abstractと arXiv メタデータを中心にした読書導線なので、スキルスキーマ、アブレーション、評価設定の詳細は PDF 本文で確認する必要がある。
関連する論点は？
SkillOpt、MUSE-Autoskill、SkillEvolBench、Counterfactual Trace Auditing が近い。スキルの生成、評価、更新、効果監査をそれぞれ補える。
関連する記事
- 関連して、自然言語スキルを検証しながら改善する、スキルの作成・記憶・管理・評価を回す、経験が手続きスキルに育つかを測る と並べるとよい。自然言語スキルを検証しながら改善する はスキルを 外部に置ける改善可能な状態として扱い、スキルの作成・記憶・管理・評価を回す はスキルのライフサイクル、経験が手続きスキルに育つかを測る は経験から 手順的スキルへ変わるかの評価を見る。
- 実装に落とすなら、既存のスキル更新ログから、失敗トレース、修復パターン、適用条件、検証タスク、reject reason を分けた小さな台帳を作るのが第一歩になる。
- 深掘りするなら、PDF 本文でスキルスキーマ、タスク generator、検証、対応づけ reward、各ベンチマークのアブレーションを確認する。