DSPyの裏側で動く最適化エンジン「GEPA」──強化学習より少ない試行でプロンプトを進化させる仕組みを読む

3行まとめ

1. GEPA（Genetic-Pareto）は、プロンプトやコード、エージェント構成など「テキストで表現できるパラメータ」を、LLMに実行トレース（エラーメッセージや推論ログ）を読ませて診断・修正提案させる形で進化させる、オープンソースの最適化フレームワーク。
2. GitHub公式READMEは、DatabricksでのOpen-source model + GEPAがClaude Opus 4.1を上回った事例（コストは90分の1）や、GRPOなど強化学習に対して「100〜500回の評価 対 5,000〜25,000回超」という試行回数の比較を公開している。
3. DSPyフレームワークにはdspy.GEPAとして組み込まれており、2026-07-15公開のv0.1.4では「マルチプロポーザル並列生成」機能が追加された。この機能はRFC #329として起票され、実装者による5回のレビューラウンドを経て取り込まれている。

GEPAは何をする仕組みか

GEPAはPythonパッケージgepaとして配布されているオープンソースの最適化フレームワークで、公式GitHubリポジトリのREADMEは「プロンプト・コード・エージェントアーキテクチャ・スケジューリングポリシー・SVGなど、測定できるものなら何でも最適化できる」と説明している。強化学習や勾配ベースの手法が実行トレースを単一のスカラー報酬に圧縮してしまうのに対し、GEPAはLLM自身にエラーメッセージやプロファイリングデータ、推論ログを含む実行トレースの全体を「読ませ」、候補がなぜ失敗したのかを診断させた上で、targeted fix（的を絞った修正）を提案させる。この反射（reflection）・変異・パレート効率選択の反復によって、少ない評価回数で高性能な変種を進化させる、というのが公式の設計思想だ。

READMEが挙げる「Key Results」の数値は次の通り。

これらはいずれもGEPA公式READMEおよびリンク先の外部ブログ記事（Databricksブログ等）に基づく数値で、筆者はGitHub API経由でREADME本文をcurlして確認したのみで、Databricksブログ側の実験条件までは検証していない。

DSPyとの関係

READMEは「DSPyの中でGEPAを使うのが最も強力な使い方」だとして、dspy.GEPAオプティマイザとしてのコード例を掲載している。

import dspy

optimizer = dspy.GEPA(
    metric=your_metric,
    max_metric_calls=150,
    reflection_lm="openai/gpt-5",
)
optimized_program = optimizer.compile(student=MyProgram(), trainset=trainset, valset=valset)

単体でもgepa.optimize()から使え、READMEのクイックスタート例ではAIME数学問題のsystem promptをGPT-4.1 Miniで最適化し、正答率が46.6%から56.6%（+10ポイント）に向上したという結果が示されている。

RFC #329本文には、num_parallel_proposals > 1時の内部アルゴリズムも5ステップで記載されている：①候補プールとreflection LMプールから(候補, reflection_lm)のペアをN個選ぶ、②各ペアでreflect()を呼び新しいテキストと拡張LMを得る、③子候補をバッチ評価する、④受理基準を適用する、⑤受理された子を候補プールに、拡張LMをLMプールに追加する。並列化できるのは②のLM呼び出し部分のみで、他はGEPAのコア側では逐次実行され、並列処理自体はアダプター側に委ねられている、と説明されている。

v0.1.4で何が変わったか──RFC #329

GEPAのリリース履歴（GitHub Releases API実測）を見ると、v0.1.0が2026-02-19、直近のv0.1.4が2026-07-15に公開されている。v0.1.4のリリースノートは「reflection-LMプロトコルとバッチベースの並列プロポーザル」を「プロジェクト開始以来もっとも大きなプロポーザル機構の変更」と位置づけ、これがRFC #329（Phase 1・Phase 4）として起票され、コントリビューター@Benzhang2004氏がPR #369として実装、5回のレビューラウンドを経て取り込まれたと明記している。

具体的には、これまで1反復につき1つの候補プロンプトしか提案・評価できなかったところを、sampling_strategy=（SingleMutationSamplingがデフォルトで従来通りの挙動、SameParentSampling(n)・IndependentSampling(n)・PxNSampling(p, n)が新規追加）で複数の候補を同時にサンプル・評価できるようにし、selection_strategy=（AllImprovementsがデフォルト、BestImprovement・TopKImprovements(k)も選べる）でどの改善をプールに残すかを制御できるようになった。デフォルト設定は「以前の挙動を完全に再現する」ようリプレイテストで固定されている、とリリースノートは説明している。

論文はICLR 2026にOral採択されている

arXiv掲載の論文（2507.19457、v2は2026年2月14日改訂）のAbstractを確認すると、READMEの数値の裏付けとなる、より精緻な比較結果が書かれている。

Across six tasks, GEPA outperforms GRPO by 6% on average and by up to 20%, while using up to 35x fewer rollouts. GEPA also outperforms the leading prompt optimizer, MIPROv2, by over 10% (e.g., +12% accuracy on AIME-2025).

（6つのタスクにわたり、GEPAはGRPOを平均6%、最大20%上回り、使用するロールアウト数は最大35分の1で済む。GEPAはまた、当時最有力のプロンプト最適化手法MIPROv2を10%以上上回る（例：AIME-2025で+12%の精度））

つまりREADMEの「35倍速い」は論文本文の数値と一致するが、精度面では「平均6%・最大20%の改善」というのが論文の主張で、README単体の「90倍安い」ほど単純な話ではない。また論文はICLR 2026にOral（口頭発表）として採択されており（arXivのComments欄に「Accepted to ICLR 2026 (Oral)」と明記）、著者はLakshya A Agrawal氏を筆頭に17名。査読付き学会での採択という点は、GEPAが単なるOSSプロジェクトの自己申告ではなく、学術的な査読を経た手法であることを示す材料になる（各著者の所属・肩書きは本記事では未確認）。

「90倍」の数字は検証できなかった

READMEが掲げる「90倍安い」という数値は、GEPA公式ではなくDatabricksブログという外部発信元の実験結果へのリンクであり、この記事ではDatabricksブログ本体まではcurlで開いておらず、実験条件の妥当性は検証できていない。論文本体（arXiv）が主張する数値は「GRPO比で平均6%・最大20%の精度改善、最大35倍少ないロールアウト」「MIPROv2比で10%以上の精度改善」であり、こちらは査読付き論文の記載として確認できた。筆者はGitHub上のREADME・リリースノート・RFC #329・arXiv Abstractの本文をcurlで取得して数値と経緯を確認したが、実際に手元でgepa.optimize()を動かして数値を再現する検証はしていない。日本語圏でのZenn記事検索では「GEPA」という文字列自体はヒットするものの、中身は無関係な「MessagePack」関連記事ばかりで、Genetic-Pareto最適化としてのGEPAを扱った日本語記事は見当たらなかった。

関連記事

• プロンプトエンジニアリングは死んだのか、という議論を読む
• プロンプトエンジニアリング入門