エージェントのプロンプト・ツール・スキルを「失敗トレースから」自動改善するcap-evolve──held-out評価で+58.3%の実測値

3行まとめ

1. cap-evolveは、AIエージェントの「システムプロンプト」「ツールの実装コード」「MCPツール表面」「スキルパッケージ（SKILL.md一式）」を、自前の評価（eval）に対して自動最適化するPython製OSSツール。公式READMEは「重みでなく、エージェントが“読む”ものを最適化する」と位置づけている。
2. 各改善候補はgitコミットとして記録され、held-out（未見）のテスト分割で有意に上回った場合のみ採用する「val-only significance gate」を核に据えている。README公開のベンチマーク表では、τ²-bench airlineのheld-outテストで30.0→47.5（+58.3%）という結果が、コミット済みの実行アーティファクト付きで示されている。
3. Claude Code・Codex・Gemini・Cursor・Copilotなど主要コーディングエージェントホストに対応し、APIキー不要のデモ（toy_calc）で仕組みを2分で試せる設計になっている。

何を最適化するツールか

cap-evolveは「エージェントの評価トレースから学ぶ」ことを核にしたPythonパッケージ（cap-evolve-core、CLI名cap-evolve）で、READMEは対象読者を「すでに評価（eval）を持っているエージェント開発者」と定義している。最適化できる対象はREADMEの一覧表で次の4種類が挙げられている。

これらは単独でも、[system-prompt, tools]のように組み合わせても最適化対象にできる。

仕組み

READMEに掲載されているパイプライン図は次の流れを示している。

プロンプト・ツール・MCP・スキル
  → 評価を実行
  → 失敗を診断
  → 候補を生成
  → 検証ゲート（採用 or 却下、却下は診断に戻る）
  → git管理された最良候補
  → 最終評価とレポート

READMEによれば、各反復は「現在のベスト候補」「その失敗トレース」「タスクごとの影響（前回の編集が何を壊し何を直したか）」「過去の試行履歴」を受け取り、大胆で複数箇所にまたがる候補を1つ提案し、val分割で評価し、ゲートが採用したかどうかを記録する。採用判定は「val分割のみでの有意性ゲート（Δ > k・SE）」で、test分割は封印されており1回しかスコアリングされない、とREADMEは明記している。

実測されている数値

READMEは各結果を「fit metric（held-outなし）」または「held-out（最適化器が見ていないIDでtestを1回だけスコアリング）」とラベル付けした上で、次の表を公開している。

README自身が「apples-to-apples（横並び比較できる）リーダーボードではない」と注記しており、外部のツール最適化研究（EvoTool論文・arXiv:2603.04900など）との位置関係は別ドキュメントdocs/COMPARISON.mdに切り出されている。RH-SWE-benchの行についても、README内で「このベンチマークだけはリポジトリにコミットされた実行アーティファクトが無い」と明記されており、他の行（コミット済みアーティファクトと突合可能）とは信頼度が異なる、と自己申告している。

「同じ候補を5回測っただけで5.6ポイントの差が出た」というノイズの実測

docs/RESULTS.mdには、τ²-bench airlineでの実行ログが実行回ごとに詳しく記録されている。特に目を引くのは、5回目の試行でようやく最初の改善が採用されるまでの経緯だ。ここでは、直前4回の試行がすべて「何も採用しない」で終わった原因が、最適化アルゴリズム自体の弱さではなく、測定・採用判定の仕組み側にあった4つの不具合だったと詳細に検証されている。

その1つが「同一の候補を5回測定しただけで生じるブレ」の実測だ。バイト単位で完全に同一の候補を、ラウンドごとに同じ30タスク×3試行で再測定した結果は次の通り。

平均0.669・標準偏差0.021、再測定だけで5.6ポイントの開きが出ている。5回目の測定では「対照群（何も変えていないコピー）」が実行全体で最も高いvalスコアを記録した、ともドキュメントは記している。ドキュメントは「このベンチマークでは、1ラウンドのデルタが約5ポイント未満なら、それはノイズと区別がつかない」と結論づけ、その後採用された実際の改善が+8.9ポイント（測定されたノイズの標準偏差の4.3倍＝4.3 SD）だったからこそ信頼できる、という基準を示している。

見つかった4つの不具合のうち1つは「回帰ベト（regression veto）」で、taskごとの退行が1件でもあれば候補を却下する仕組みだったが、上記のバイト同一コピーの再測定でも4件の「退行」が検出されてしまい、この仕組み自体がノイズを退行と誤認していたことが判明した。もう1つは、並列度を上げすぎたことで292/300件のロールアウトがタイムアウトし、valスコアが「0.0067」という数字が、何もアラートを出さずにそのまま採用判定に使われていたという不具合だった。これらはいずれも「オプティマイザが弱い」ことではなく「測定基盤にバグがあった」ことが原因で、修正後にテストで固定されている、とドキュメントは記している。

DSPy・GEPA・promptfooとの機能比較、外部研究との数字は「並べているだけ」

docs/COMPARISON.mdには、DSPy・GEPA・promptfooとの機能比較表がある。

同じドキュメントには、EvoTool（arXiv:2603.04900）や「Evolutionary Context Search」という外部研究の数字も並べた表があるが、見出しに自ら「NOT apples-to-apples（横並び比較ではない）」と明記している。

"The Evolutionary Context Search +23.3% figure is referenced in cap-evolve issue #46; its primary-source citation is still to be confirmed — treat it as unverified until a reference is added here."

（「Evolutionary Context Search」の+23.3%という数字は、cap-evolveのissue #46で言及されているものだが、一次情報源の引用はまだ確認されていない。ここに出典が追加されるまでは未検証として扱うこと）

自分たちに有利に見える他研究の数字を、出典未確認のまま「参考」として載せつつ、その場で「まだ検証していない」と自己申告している。EvoToolについては「元のτ-Bench（Yao et al., 2024）を評価しており、cap-evolveが使うτ²-Benchとは異なる、より難しいベンチマークなので、行同士は直接比較できない」とも明記されている。ドキュメント末尾には「Last reviewed: 2026-07-13」という最終レビュー日も記載されていた。

封印テスト・有意性ゲートの実装保証

docs/HONEST_EVAL.mdには、数値の信頼性を担保する4つの仕組みがコードレベルで説明されている。①シード固定・凍結された分割（make_splitsでタスクを決定的に分割し、splits.jsonに一度だけ書き込む）、②封印されたテストセット（RunDir.consume_test()がtest_usedフラグを立て、2回目のアクセスにはTestSealErrorを発生させる）、③valのみでの有意性ゲート（Δ > k・SEという基準で、単にΔ > 0ではなく標準誤差のk倍を要求する。理由は「探索はノイズを増幅する装置であり、十分な数の候補をふるいにかければ、一番良く見える候補はただの“運”になるから」）、④分散の実測（1タスクあたりの試行回数が1回の場合、pass@2のような未測定の指標を「0.0」と誤って埋めず、そもそも欠損として扱う）。

ゲートには4つのモードがある。

試してみた範囲

筆者はcap-evolveのAPIキー不要デモtoy_calcの手順（pip install ./core→bash examples/toy_calc/run.sh）をREADME上で確認したが、Anthropic有料APIの新規消費が絡む検証は本記事執筆のルール上見送っており、実際にリポジトリをcloneしてこのデモを走らせる検証まではしていない。README記載の期待挙動は「seedプロンプトがvalで0.0、最適化後プロンプトがゲート通過してtestで1.0」というモデル呼び出し無しの決定論的デモであり、これ自体は数値の検証ではなく「パイプラインが動く」ことの確認用サンプルだとREADMEに明記されている。

第三者による独立再現は見つからなかった

• 上記の数値はすべてcap-evolve開発元自身が公開しているもので、第三者による独立再現をこの記事のために探した範囲では見つけられなかった
• RH-SWE-benchの行はREADME自身が「コミット済みアーティファクトが無い」と注意書きしており、他の行と同じ確度で扱うべきではない
• docs/RESULTS.mdは2,000行を超える実行ログで、本記事ではτ²-bench airlineでの「5回目で初めて採用」という経緯を中心に紹介しており、それ以外の実行（RH-SWE-bench・SkillsBenchでの詳細ログなど）までは網羅的に読み込んでいない
• 「Evolutionary Context Search」の+23.3%という数字について、cap-evolve側が「未検証」と自己申告している通り、本記事でもこの数字の一次情報源（issue #46の先）までは追跡していない
• Anthropic有料APIの新規消費が絡む検証（実際にtoy_calc以上のデモを走らせる、自分のリポジトリで最適化を回す等）は本記事執筆のルール上見送っている
• Zenn記事検索では「cap-evolve」という文字列自体の日本語記事はこの記事作成時点で見当たらなかった

関連記事

• DSPyの裏側にある「GEPA」を読む
• MCP（Model Context Protocol）とは