2026年9月7日 月曜日
AI時短ラボ
研究· 約13

GEPAを飲み込んだ最適化基盤「synth-optimizers」──ホスト専用の探索アルゴリズム「GELO」を覗く

Synth Laboratoriesが公開しているsynth-optimizersは、共有Rustコアの上でGEPA(プロンプト反射進化)を動かすオープンソースプラットフォーム。同社が提唱する探索アルゴリズム「GELO」(Go-Explore in prompt space)はホスト専用(hosted-only)で、公開パッケージにローカル実行のコマンドは無い。

GEPAを飲み込んだ最適化基盤「synth-optimizers」──ホスト専用の探索アルゴリズム「GELO」を覗く
執筆・編集:
目次

3行まとめ

  1. synth-optimizers(PyPI名synth-optimizers)は、Synth Laboratoriesが公開しているオープンソースの「共有Rustオプティマイザ基盤」で、公式READMEは「言語非依存のタスク契約に対して探索アルゴリズムを実行する再利用可能なRustコア」と説明している。
  2. 現時点でサポートするアルゴリズムはREADME実測で3つ。GEPA(公開・ローカル実行可)、GELO(ホスティングのみ)、SFT(ホスティングのみ)で、GEPAだけが公開パッケージから直接gepa runのようにローカルで動かせる。
  3. GELOは「Go-Explore in prompt space」の略で、SKILL.mdによれば「LLM呼び出しごとにチェックポイントを作り、near-miss(惜しかった)事例やpre-achievement(目標達成の一歩手前)事例から部分的に再開して探索する」アルゴリズムだが、公開パッケージにはローカル実行コマンドが無い「hosted-only」の製品仕様だと明記されている。

synth-optimizersというプラットフォームの立て付け

Synth Laboratoriesが公開しているGitHubリポジトリsynth-laboratories/optimizersのREADMEは、冒頭で本プロジェクトを「AIアプリケーション向けの共有オプティマイザプラットフォーム──オープンソースのGEPAを言語非依存のタスク契約の上で動かすところから始まる」と紹介している。設計は3層に分かれている。

  • 共有プラットフォームコア: コンテナI/O、ワークスペース、キャッシュプロファイル、予算管理、テレメトリ、失敗時ハンドリング、再生可能な実行証跡(evidence)を扱う、再利用可能なRust製の基盤機構
  • アルゴリズム層: GEPAが最初の公開アルゴリズムで、将来的に別のアルゴリズムも同じプラットフォーム契約に乗せられる設計
  • 今日動くもの: GEPAはTOMLかGepaConfigで設定し、プロンプトの変更を提案・ロールアウト・採点し、パレートフロンティアを維持しながら検査可能な実行証跡を出す

READMEに掲載されているサポートアルゴリズム表を引くと、状態は次の通り。

アルゴリズム 状態 本リポジトリでの実体
GEPA(reflective prompt evolution) Supported(公開・ローカル実行可) rust/crates/synth_gepa/(Rustエンジン+サービス)、src/synth_optimizers/gepa.py(Python API)
GELO(Go-Explore in prompt space) Hosted submit(ホスティング経由のみ) src/synth_optimizers/gelo.pyGELO_HOSTED_SDK_CLI_SPEC.md
SFT(supervised fine-tuning) Hosted submit(ホスティング経由のみ) HostedOptimizerClient.submit_sft()

READMEは「GELOとSFTは公開パッケージの中ではホスト専用で、Synthのホスト型オプティマイザ基盤の上で動く」と明記しており、GEPAだけが唯一、手元の環境で完結できるアルゴリズムという扱いになっている。

GELOとは何か

GELOという名前は「Go-Explore in prompt space」の略で、Go-Exploreはもともと強化学習の探索手法として知られる考え方(有望な状態にいったん戻ってから探索を再開する)だが、SKILL.mdの説明によれば、GELOはこれをプロンプト空間の探索に応用したものだという。SKILL.mdは対象読者をエージェント(AIアシスタント自身)向けの運用ドキュメントとして書いており、次のように定義している。

GELO is hosted-only in the public package. (GELOは公開パッケージの中ではホスト専用である)

「per-LLM-call checkpoint creation, async rollout contracts, achievement ladders, resume semantics, checkpoint retention/eviction」といった用語が並び、LLM呼び出し1回ごとにチェックポイントを作成し、非同期のロールアウト契約、達成度のはしご(achievement ladders)、チェックポイントの保持・破棄ポリシーといった仕組みで探索を制御している様子がうかがえる。ただし、これらの詳細ドキュメント自体はリポジトリ内のsrc/synth_optimizers/docs/gelo/というバンドルHTMLドキュメントを指しており、今回はSKILL.mdの説明文以上には踏み込んで確認していない。

顧客が実行する際のプロダクトルールは「locked」(固定)と明記されており、HostedOptimizerClient.submit_geloまたはsynth-optimizers gelo submitというホスト経由の呼び出し以外に、GEPAにあるようなgelo runというローカルコマンドは存在しない、とSKILL.mdは繰り返し強調している。

SKILL.mdの「Mental Model」節は、GELOの探索を4段階のレーンとして整理している。

  1. Full-scope lane:新規(または再開された)ロールアウトが、ポリシーLLMの意思決定ポイントごとに「チェックポイント」を生成する
  2. Data miner:チェックポイントに、前向きな「near-miss(惜しかった)」「pre-achievement(目標達成の一歩手前)」というラベルを付ける
  3. Theme lane:部分的なロールアウトがテーマ別チェックポイントから再開し、verifierがサブゴールの進捗を採点する
  4. Consolidation lane:マージされたプロンプトが新規のフルロールアウトで評価され、best_baseは対になった新規のエビデンスがある場合のみ昇格する

SKILL.mdはこの仕組みの核心を「LLM呼び出しごとのチェックポイントが無ければ、GELOは『余計な手順が増えただけのGEPA』に成り下がる(Without per-LLM-call checkpoints, GELO degrades to "GEPA with extra steps.")」と表現しており、GELOの独自性がGEPAの反射進化エンジンに、Go-Explore流のチェックポイント・再開機構を重ねている点にあることをうかがわせる。SKILL.mdはさらに、環境コンテナ側が満たすべき機能を3段階のTier(A: フレッシュなロールアウトのみ、B: 非同期+per-LLMスナップショット+再開ルート対応、C: B+メタデータ対応で「本番のフルフライホイールに必須」)に分類している。

なお、SKILL.md内には「6月26日のGELOローンチプロモ」(campaign id: gelo_free_72h_20260626)という記述があり、対象組織は申請から72時間、ホスト型Go-Exploreのproposer利用料が無料になるキャンペーンが実施されたことが分かる。この日付から、GELOという名称の製品が少なくとも2026年6月26日には公開されていたことが読み取れる。

GEPAとの関係

GEPA自体は独立したオープンソースプロジェクト(別記事で詳述、GEPAとは何かを参照)だが、synth-optimizersはそのGEPAをRust実装として取り込み、同じプラットフォーム基盤の上でGELOやSFTと並べて動かす構成になっている。arXiv:2507.19457のabsページを直接確認したところ、GEPA論文は「Accepted to ICLR 2026 (Oral)」と明記されており、査読付き国際会議で口頭発表採択された論文であることが分かる。アブストラクトによれば、GEPAは6タスクの評価で強化学習のGRPOを平均6%・最大20%上回り、ロールアウト数は最大35分の1で済んだとされ、既存のプロンプト最適化手法MIPROv2との比較でも10%以上上回った(AIME-2025では+12%)という。README冒頭の「Links」節でもこの論文が「GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning」というタイトルで明示的にリンクされている。

GitHub REST APIで直接取得したリポジトリメタデータによれば、作成日は2026-04-23、直近のpushは2026-08-29、最終更新(updated_at)は2026-08-21、Star数は8、Fork数は0、Watch数は8。作成から4ヶ月あまりで継続的に更新が続いているプロジェクトであることが分かる。またリポジトリのdescriptionフィールドには「GEPA and GELO optimizer runbooks, SDKs, and hosted optimizer surfaces for Synth.」と記載されており、GEPAとGELOの両方がこのリポジトリの主要な役割であることが公式説明からも読み取れる。

ライセンス表記はREADME末尾にあるが、LICENSEファイルは無い

GitHub REST APIで直接取得したリポジトリメタデータでは、licenseフィールドは依然としてnullだった。一方でREADME.mdの末尾には「## License」という見出しがあり、本文はひとこと「Apache-2.0」とだけ書かれている。ところがLICENSELICENSE.mdLICENSE.txtLICENSE-APACHENOTICEのいずれをリポジトリ直下にcurlで直接リクエストしても404が返ってきた。つまり、README上では「Apache-2.0」という具体的なライセンス名が明示されているのに、GitHubのライセンス自動検出(GitHub API・リポジトリ上部のライセンスバッジ)が参照する実体のLICENSEファイルは存在しない、というねじれた状態にある。GitHub側のライセンス表示や、licenseフィールドを見て自動判定するツール類は、この状態だと「ライセンス不明」としか認識できない。README本文の記述を信頼するならApache-2.0で運用されていると読めるが、リポジトリ直下に正式なLICENSEファイルが無い以上、再配布や改変の可否を判断する際はREADMEの一文だけに頼らず、Apache-2.0の全文が別途どこかで明示されるまで留意しておくべき状態だ。

GELOの性能について分からないこと

GELOの実際の探索性能(GEPAと比べてどの程度効率が良いか、どんなタスクで使われているか)を示すベンチマークや事例は、今回curlで取得したREADME・SKILL.mdの範囲には見当たらなかった。ホスト専用の製品であるため、外部の第三者が独立に検証したレポートも見つけられていない。筆者はsynth-optimizersを手元にインストールして動かす検証はしておらず、この記事はGitHub上の公開ドキュメントの記述をそのまま紹介したものにとどまる。Zenn記事検索では「GELO」はヒットするが、中身は無関係な「CHANGELOG」系の記事ばかりで、本記事が扱う意味でのGELOに関する日本語記事は見当たらなかった。

関連記事

シェア: ポスト はてブ

出典・参照資料

AIニュースの解説を動画でも

YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。

コメント

まだコメントはありません。最初のコメントを書いてみませんか?

AIについて聞きたいことはありますか?

質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。

質問箱を見る →

新しい記事をメールで受け取る

AIの新しい発表を、出典付きで整理して届けます。

関連記事

DSPy 3.3.0の実験機能「Flex」「ReActV2」──プロンプトでなくプログラムの構造そのものをGEPAに最適化させるの記事画像
研究09.07読了12

DSPy 3.3.0の実験機能「Flex」「ReActV2」──プロンプトでなくプログラムの構造そのものをGEPAに最適化させる

出典 ─ DSPy 3.3.0 Release Not
DSPyの裏側で動く最適化エンジン「GEPA」──強化学習より少ない試行でプロンプトを進化させる仕組みを読むの記事画像
研究09.06読了10

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

出典 ─ gepa-ai/gepa README(Gi
「FreeToken」とは何か──ワークステーションGPU1枚で753BのMoEモデルを動かす、帯域適応型の推論システムの記事画像
研究09.07読了13

「FreeToken」とは何か──ワークステーションGPU1枚で753BのMoEモデルを動かす、帯域適応型の推論システム

出典 ─ FreeToken: Efficient E
拡散言語モデルは『やり直させる』と自分の答えの信頼度が分かる──PDCという検証手法の記事画像
研究09.07読了12

拡散言語モデルは『やり直させる』と自分の答えの信頼度が分かる──PDCという検証手法

出典 ─ Prefix-Denoising Consi
ARC-AGI-3のBest@1を30%から95.5%に押し上げたPrime Agent──「コンテキストを変数として扱う」RLMという考え方の記事画像
研究09.07読了14

ARC-AGI-3のBest@1を30%から95.5%に押し上げたPrime Agent──「コンテキストを変数として扱う」RLMという考え方

出典 ─ PrimeIntellect-ai/prim
NCCLに頼らないallreduce──SGLangがBlackwell世代のFlashInfer MNNVLワークスペースを使い回す最適化の記事画像
研究09.07読了16

NCCLに頼らないallreduce──SGLangがBlackwell世代のFlashInfer MNNVLワークスペースを使い回す最適化

出典 ─ sgl-project/sglang v0.
SGLangが「allgather+scatter」を1回のall-to-allに統合──DeepSeek-V4-Proのデコード時間が320μsから169μsにの記事画像
研究09.07読了15

SGLangが「allgather+scatter」を1回のall-to-allに統合──DeepSeek-V4-Proのデコード時間が320μsから169μsに

出典 ─ sgl-project/sglang v0.
「LLMRouter」とは何か──「どのAIに投げるか」を選ぶ仕組みを、16種類以上まとめて比較できる基盤の記事画像
研究09.06読了10

「LLMRouter」とは何か──「どのAIに投げるか」を選ぶ仕組みを、16種類以上まとめて比較できる基盤

出典 ─ LLMRouter: Unified Inf