LongWoF-Bench：検証可能な長期ワークフロータスクにおける進化型手順ガイダンスの評価

第 1 章: はじめに

大規模なモデルでは、ロングコンテキストのモデリング、ツールの使用、およびコードの実行が向上するため、そのアプリケーションは、個別の質問応答から、一連の操作を必要とする複雑なシナリオまで拡張されています。たとえば、Markdown-to-Repository タスクでは、モデルは要件ドキュメントと既存のコードベースを読み取り、実装計画とタスク リストを作成し、コードを変更し、結果を検証するためのテストを実行する必要があります。ルール駆動型タスクでは、モデルは中間状態を維持し、複数ステップの推論を実行し、最終的にすべての制約を満たす有効な結果を返す必要があります。

これらのタスクを エンドツーエンドの長期ワークフロータスクと呼びます。形式的には、初期入力 $(x)$、実行可能な環境 $(E_0)$、制約セット $(C)$、および検証子 $(V)$ が与えられると、モデルは相互依存するアクション $a_1,a_2,\ldots,a_T$ のシーケンスを生成する必要があります。これらのアクションは状態遷移 $E_t=f(E_{t-1},a_t)$ を引き起こし、最終的に結果 $(y)$ を生成します。後のアクションが前のアクションによって作成された状態または中間成果物に依存し、成功が検証可能な終了条件 $V(x,E_T,y,C)=1$ によって一律に決定される場合、タスクはエンドツーエンドの長いワークフローになります。ここでの「長いワークフロー」とは、単なる入力長、出力長、または実行時間ではなく、段階間の依存関係と継続的に進化する状態を指します。

明示的な出力制約の下では、モデルは複数の依存する判断や操作を、プログラムやルールが正確に検証できる最終成果物に変換する必要があります。 「ワークフロー」は必ずしも外部ツールの呼び出しを意味するわけではありません。コードおよびエージェントのタスクでは、入力ファイルの読み取り、CLI コントラクトの遵守、指定された JSON/TXT アーティファクトの生成、および非表示のテストの通過が含まれる場合があります。数学およびルールのタスクでは、式の選択、境界の処理、ルールの優先順位の適用、および回答形式の正規化が含まれる場合があります。どのような場合でも、成功はタスクを理解することと、検証可能な成果物に一連の制約を正しく実装することの両方にかかっています。

この能力を検証するため、SkillsBench のプログラミングタスク (Li et al., 2026) と GuideBench のルール検索フレームワーク (Diao et al., 2025) を参照し、長いワークフローに共通するタスク形式と、複数の制約が組み合わさることで生じる難しさを整理して LongWoF-Bench を構築しました。778 件の検証済みタスクは、コード生成（code_generation）、数学的推論（math_reasoning）、ルール遵守（rule_following）、エージェント・オーケストレーション（agent_env_synth）の 4 種類をカバーします。コードではプログラム生成と非公開テスト、数学では厳密な短答と正規化、ルール遵守では優先順位と離散的判断、エージェント環境ではパッケージインターフェイス、複数の出力ファイル、pytest 形式の検証を重視します。共通のタスクマニフェスト、非公開評価器、厳密な採点手順により、異なるタスクを同じワークフロー完了の枠組みで比較できます。

このベンチマークは、次の 3 つの研究課題に対処します。

• RQ1: 現在のモデルは、クロストラックで機械検証可能な長時間のワークフロー タスクにおいてどの程度信頼性がありますか?
• RQ2: SkillやGeneなどの補助プロンプトはタスクのパス率やトークン消費にどのように影響しますか?
• RQ3: 手順ガイダンスから最も恩恵を受けるタスク タイプ、モデル タイプ、およびGene構築ソースはどれですか?

これらの質問は、タスクを独立して完了し、手順に関する知識を使用し、さまざまな支援方法の適用性とコストをトレードオフするモデルの能力を調べます。

これらに答えるために、次の 3 つの条件下で、同じタスク、実行環境、および非表示の評価器で複数のモデルを評価します。補助コンテキストなし (no_context）、事前定義されたタスクマニュアル（Skill）、および経験から得られる手順プロンプト Gene (Wang et al., 2026)。Skillでは、ワークフロー、インターフェイスの使用法、ルール実行手順、および一般的な落とし穴について説明します。 Gene は構造化フィールドを使用して、タスク パターン、適用性シグナル、実行戦略、プリフライト チェック、および重要な制約を表します。Geneは、検証に合格したモデルの軌跡から構築されるか、成功した軌跡が存在しない場合は参照ソリューションによって提供される教師信号から構築されます。すべての補助資産は漏洩監査を受けるため、回答やその他の重要な情報がプロンプトに漏洩することはありません。 3 つの条件の下で厳密な合格率とトークンの使用を比較し、結果をタスク タイプ、モデル タイプ、およびGeneソースごとにグループ化します。

この実験により、3 つの主な発見が得られました。まず、最も強力なモデルである Opus 4.8 でさえ、補助コンテキストがなければ厳密な合格率は 20.2% にすぎず、現在のモデルでは依然としてこれらの長期ワークフロータスクを確実に完了できないことがわかります。第二に、手続き上の支援はパフォーマンスを向上させますが、その利点とコストは形式によって異なります。全体として、Gene は Skill よりも少ないトークンでより効果的なタスク ガイダンスを提供します。第三に、利点は均一ではありません。タスクの種類、モデルの機能、およびGene構築ソースによって大幅に変化します。したがって、手続き型知識の価値は、それがモデルとタスクの両方にどの程度適合するかによって決まります。

この報告書は、これらの質問に対応する 3 つの貢献を行っています。

• まず、エンドツーエンドの長期ワークフロータスク用の統合ベンチマークを構築します。 LongWoF-Bench は、778 個の検証可能なタスクを含む 4 つのタスク タイプをカバーし、非表示の評価器と厳密な出力ルールを使用してすべてのタスクの完了を測定します。
• 次に、構造化された補助プロンプトとして Gene を導入して実装します。より完全なSkill マニュアルと比較して、Gene はより短く、より監査可能なフィールドで手順のエクスペリエンスを表します。定義された進化プロセスの下で、強力なモデルの実行フローから最も価値の高い情報を抽出し、その情報を補助プロンプトとしてパッケージ化します。これにより、通常の長いプロンプトからの支援が、比較および分析できる実験条件に変わります。
• 3 番目に、補助コンテキストなし、Skill、Geneという 3 つの条件をモデルとタスク トラック全体で体系的に比較します。迅速な支援がなければ、Opus 4.8 でさえ厳密な合格率は 20.2% にとどまっており、ベンチマークが依然として困難であることが確認されています。進化したGeneは、長時間にわたるワークフローのタスクを解決するためにSkillよりも価値があり、トークンの消費量が少なくなります。

第 2 章: LongWoF-Bench の構築

2.1 ベンチマークタスクの設計

2.1.1 エンドツーエンドの長期ワークフロー タスクの構築

LongWoF-Bench のコア タスク ユニットは、公開タスク仕様、成果物スペース、および非表示の検証器で構成されます。

公開仕様 $(S)$ は、初期入力 $(x)$、実行可能な環境 $(E_0)$、および制約セット $(C)$ を提供します。成果物空間 $\mathcal{Y}$ はモデルが提出しなければならないものを記述しており、$(V)$ はモデルから隠蔽された検証器です。モデルは相互依存する一連のアクション $a_1,\ldots,a_T$ を実行し、環境を $(E_0)$ から $(E_T)$ に駆動し、最終的な成果物 $y\in\mathcal{Y}$ を生成します。 $V(x,E_T,y,C)=1$ の場合、タスクは成功します。

アダプティブ クルーズ コントロール システムのオーケストレーション コードを構築するようにモデルに要求する LongWoF-Bench タスクを考えてみましょう。その仕様 $(S)$ には、車両パラメータ ファイル、150 秒のセンサー データ、クルーズ、追従、緊急ブレーキ モードのインターフェイスとパフォーマンス要件が含まれています。その成果物スペース $\mathcal{Y}$ には、PID コントローラー、クルーズ コントロール システム、シミュレーターのコード ファイルと、調整結果、シミュレーション データ、分析レポートが含まれています。モデルはコントローラーとモード切り替えロジックを実装し、PID パラメーターを調整し、完全なシミュレーションを実行し、すべての成果物の一貫性を保つ必要があります。

非公開検証器 $(V)$ は、ファイルの存在といくつかの追加プロパティをチェックします。送信されたクラスをインポートして呼び出し、シミュレーションを再実行し、制御モード、インターフェイス、出力形式を検証し、立ち上がり時間、オーバーシュート、定常状態誤差、安全な車間距離、加速限界などのパフォーマンス測定をチェックします。また、PID パラメータを変更し、それに応じてシステムの動作が変化することを確認します。これにより、機能している制御システムとハードコードされたシミュレーション出力が区別されます。

したがって、構造的に完全なプログラムや表面的にもっともらしいプログラムだけでは不十分です。最終コードとすべての派生成果物は、合わせて $V(x,E_T,y,C)=1$ を満たす必要があります。

この定義は、ベンチマーク タスクの許可基準も設定します。まず、タスクには、プロンプト、アクセス可能な入力、呼び出し可能なインターフェイス、または出力命令を通じて、モデルがタスクを解決するために必要な情報を取得できる記述可能な公開仕様が必要です。第 2 に、結果が主観的な採点に依存しないように、タスクは機械による実行または正確な一致をサポートする必要があります。第三に、評価者はモデルに表示される情報と非表示の情報を分離する必要があります。モデルは、プロンプト、入力ファイル、アクセス可能なパッケージ インターフェイス、出力プロトコル、および関連する条件下で注入されたSkillまたはGeneを確認できます。隠されたテスト データ、正解、内部検証ロジック、参照ソリューション、または評価者のみが利用できるプライベート定数を参照してはなりません。この境界は、後の比較を公平にするために必要です。

2.1.2 LongWoF-Bench ワークフロー トラック

現在の LongWoF-Bench リリースには、778 個の検証済みタスクが保持されています。 4 つの評価トラックの違いは次のとおりです。

トラックはさまざまな種類の成果物を生成しますが、いずれもモデルが公開仕様の制約を検証可能な結果に変える必要があります。コードとエージェントのエラーは、プログラムの実行とファイルのチェックを通じて発生します。数学とルールの失敗は、回答の正規化と完全一致によって現れます。共有フレームワークにより、これらの違いが 1 つの集計スコアに消えることがなくなり、後の分析でどのタスクが外部の手順ガイダンスに最も依存しているかが明らかになります。

2.1.3 LongWoF-Bench タスクの合成

タスクは「公開プロンプトと非表示の評価」設計に従っています。事前定義されたシードから開始して、各タスクはモデルに表示される task.md 目的、入出力形式、利用可能なデータについて説明します。タスク ディレクトリには、テスト データ、リファレンス ソリューション、非表示のゴールド出力、および自動エバリュエーターも含まれています。正式な評価中、モデルはパブリック プロンプトと、割り当てられた条件に対する補助コンテキストのみを受け取ります。応答またはプログラムが生成されると、非表示のエバリュエーターがそれを実行し、出力を比較し、合格したかどうかを記録し、トークンの使用量を測定します。したがって、ベンチマークは、モデルが複数の選択肢の回答を記憶しているかどうかではなく、複雑なルール、データ処理、コード実行、書式設定の制約の下で実際にタスクを完了できるかどうかを測定します。

従来の単一フォーマットのベンチマークとは異なり、LongWoF-Bench はエンドツーエンドの成果物が機能するかどうかを一貫して尋ねます。コードとエージェント プログラムを実行する必要があります。数学とルールの答えは、厳密な形式に基づいて解析および照合する必要があります。 3 つの条件すべてが同じタスクと検証者に直面するため、後の実験では、補助コンテキスト、Skill、およびGeneを使用せずに公正に比較できます。モデルに提供される補助情報のみが変更されます。

2.2 補助プロンプトの構築: SkillとGene

複雑なワークフローにおける失敗の多くは、モデルに関連する知識がすべて欠けているためではなく、適切な実行プロセスを一貫して呼び出すことができないために発生します。データを読み取ることはわかっていても、出力プロトコルを見落としている可能性があります。ルールは理解していますが、優先度の高いオーバーライドを最初にチェックできません。あるいは、境界条件がデフォルトの戦略を無効にすることに気づかずに、共通のアルゴリズムを選択することもあります。失敗する正確なステップは事前には分からないため、タスクの実行では、支援として提供できる真に有用な 手続き上のエクスペリエンス が得られる必要があります。

新しい補助プロンプト、GEP プロトコルに基づく Gene (EvoMap, 2026a) を導入します。従来のSkillとは異なり、Skillは事前定義されたタスクマニュアルに似ていますが、Geneは成功した実行から抽出された手順エクスペリエンスに似ています (EvoMap, 2026b)。Skillは、タスクの実行前に定義される人間が作成した補助ドキュメントであり、モデルの実行プロセスに適応することはできません。 Gene は、タスクの実行中にモデル自体が Gene ルールに従って蒸留される手順の経験を要約します。

Geneには別の目的があります。すべての背景情報を網羅するものではありません。代わりに、検証された成功パスを構造化された手順プロンプト (問題のパターン、戦略が適用されるタイミングを示すシグナル、重要な実行ステップ、プリフライト チェックが必要な境界、送信前に必要なチェック) に圧縮します。この実験のGeneは 2 つのソースから得られます。 1 つは、タスクの検証に合格した成功したモデルの軌跡です。もう 1 つは、成功した軌跡が存在しない場合に使用され、参照ソリューションによって提供される教師信号から抽出されます。前者は、実際の成功から抽出された経験を最も直接的に表しており、別の長いマニュアルを作成する代わりに、実行パスを変更した部分を保持します。

2 つのプロンプトは異なる方法で合成されます。

• Skill は、タスクの種類、推奨プロセス、インターフェイス ルール、一般的な落とし穴、出力要件をカバーする、かなり完全なタスク マニュアルです。このベンチマーク バージョンでは、Skillは主にタスク構築および参照ソリューション資料の書き直しであり、その後に監査が続きます。したがって、それらは、公共のプロンプトのみから生成される市場スタイルのSkillではなく、強力な指導条件となります。
• Geneはより短く、成功体験から圧縮された実行プロンプトとして理解できます。モデルが公開プロンプトと検証者のフィードバックを使用して合格ソリューションを見つけると、その軌跡からGeneが抽出されます。最初の試行が失敗すると、次のロールアウトが変化します。モデルは、切り詰められたパブリック タスク、その前の試行、およびサニタイズされた実行フィードバックを受け取り、修正されたソリューションを生成します。このプロセスは、検証者が合格するか、ロールアウト予算がなくなるまで繰り返されます。探索が成功しない場合、現在のパイプラインは参照ソリューションからの蒸留に戻ります。

簡単な例を考えてみましょう。タスクでは、食品加工ラインの残留リスク ルールを使用して、「ひまわりとゴマのペースト」を製造した後の機器の洗浄アクションを選択するようにモデルに求めます。問題は、出力形式ではなく、ルールの順序付けです。どちらの成分も種子であり、均質なペーストに同時加工されます。モデルは、最大リスク スコアを計算してしきい値にマッピングする前に、免除の優先順位を適用する必要があります。

事例はその違いを示しています。Skillは完全なプロセスを提供し、例外を省略しないようモデルに警告しますが、重要な優先順位の決定は依然としてモデルに任せます。 Gene は、2 つの強力なモデルの失敗後に学習した修正を、より困難な実行順序に圧縮します。 最初に、ゴマ アレルゲンの追加料金が最高リスクに直接追加されないように、共処理の免除を適用します。次に、免除後の最大スコアを取得し、それを中間層にマップします。 Gene は単なる短いマニュアルではありません。最もエラーが発生しやすいステップとその正しい順序を、1 回の実行で利用できる手順ガイドに変換します。

したがって、Skill は静的命令を提供し、Gene は圧縮された実行戦略を提供します。Skillは道しるべであり、Geneはすでに通過した道です。 3 つの実験条件を正確に定義できるようになりました。

• no_context パブリック プロンプトのみを使用してエンドツーエンドの完了を測定します。
• with_skill は、モデルが比較的完全だが静的なタスク記述を使用できるかどうかを測定します。
• with_gene モデルが、成功体験や教師のシグナルから得られた、より短く、より構造化された手順ガイドを使用できるかどうかを測定します。

第 3 章: 実験結果

3.1 実験設定と統計的定義

778 LongWoF-Bench タスクで 7 つのモデルを評価します。セット内容は127個 agent_env_synth, 341 code_generation, 151 math_reasoning、159 rule_following タスク。すべてのモデルは次の 3 つの条件下で実行されます。

• no_context: モデルはパブリック プロンプトのみを受け取ります。
• with_skill: 公開プロンプトは、現在のタスクの完全なSkillによって補足されます。
• with_gene: パブリック プロンプトは手続き型Geneによって補完されます。

主な指標は厳密なタスクの合格率です。タスクは、すべてのチェックポイントが合格し、ベリファイアが戻った場合にのみ合格としてカウントされます。 passed=true。トークンコストは、入力トークン、出力トークン、および記録可能な思考トークンの合計です。

Geneソースによって 4 つの評価セットを区別します。

この実験でGeneを構築するために使用されたモデルは Claude Opus 4.8 です。 進化戦略は、思考レベルを固定して従来の温度係数を変更するのではなく、ロールアウト試行全体で思考努力を弱いものから強いものへと増加させます。強力なモデルは、まずパブリック タスクを解決します。失敗後は、最大 3 回のロールアウトで、サニタイズされた検証者のフィードバックを使用してソリューションを修正します。 1 つのロールアウトが実際に検証器を通過するとすぐに、その成功した軌跡からGeneが抽出されます。

3.2 全体的な実験結果 (RQ1: クロストラック、機械検証可能な長期ワークフロータスクにおける現在のモデルの信頼性はどれくらいですか?)

次の表は、Opus-evolved サブセットに関する完全な結果を報告します。下 no_context、最も強力なモデルである Claude Opus 4.8 は、タスクの 54.8% のみを通過します。他のモデルの範囲は 31.7% ～ 47.6% です。したがって、最良のモデルであっても、支援なしで 1 回実行すると、タスクのほぼ半分が失敗します。現在のモデルは、これらのクロストラックの機械検証可能なワークフローを単独で確実に処理することはできませんが、依然として補助プロンプトの恩恵を受けています。

毎 with_opus_gene ここでの結果は、参照回答の書き換えではなく、Claude Opus 4.8 によって生成された検証済みの実際の実行軌跡から抽出された Gene を使用しています。 Opus Gene は、テストされたすべてのモデルにおいて明らかに Skill を上回っています。成功したモデル探索を通じて学習したプロセスをGeneが圧縮すると、下流モデルは完全な記述Skillよりも確実にそのプロセスを使用できます。

私たちは、Gene構造の影響と成功した進化の影響を分離するために対照的な分析を実行します。残りの参照抽出タスクでは、結論が逆転します。一般的に、GeneはSkillよりもパフォーマンスが劣ります。この結果は、回答関連情報を単に圧縮するだけでは利点が得られないという解釈を強化します。これは、成功した実行プロセスを再利用可能な手順ガイダンスに抽出する進化した戦略から生まれています。プロンプト圧縮だけではなく、進化したプロセス構造がゲインを生み出します。

3.3 トークンコスト分析 (RQ2: SkillとGeneはパス率とトークンの使用にどのように影響しますか?)

この実験では、Opus 4.8 が同じタスクを解決する 2 つの方法を比較します。

• 従来の強力なモデルの探索: 有能なモデルはタスクを試行し、失敗後にサニタイズされた検証者のフィードバックを読み取り、1 回の試行が成功するまで許容制限まで再試行します。これがベースラインです。
• EvoMap Gene支援実行: 強力なモデルのエクスペリエンスから抽出されたGeneは、任意のモデルで使用できる手続き型コンテキストになります。 with_gene 試み。合格率はGeneなしよりもはるかに高く、トークンの消費量はマルチラウンド探索よりも大幅に低くなります。これが私たちのモードです。

このセクションは重要です input_tokens + output_tokens + thoughts_tokens。 Claude Opus 4.8 の場合、プロバイダーの出力トークンにはすでに思考が含まれているため、「思考を含む出力」は回復可能な完了側の合計を示します。マルチラウンド ベースラインは、通過軌跡を検出する解決/変換ロールアウトで使用されるトークンのみをカウントします。後のGene蒸留コストは含まれません。

Conventional multi-round exploration:
252 tasks
  -> Round 1 solve, thinking off
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 2 mutate, thinking low
     -> pass: distill Gene
     -> fail: sanitized verifier feedback
  -> Round 3 mutate, thinking high
     -> pass: distill Gene

Total: 404 model calls, 252 verified successful trajectories

Single-round Gene reuse:
252 tasks + Opus Genes
  -> one with_gene_opus attempt per task
  -> 252 model calls, 200 passed tasks

この評価セットには、複数ラウンドの探査中に最終的に検証された軌道を生成したすべてのタスクが含まれています。以下の最初の行は、従来のマルチラウンド プロセスをシミュレートしており、1 コールの合格率ではありません。残りの行は、対応する補助条件を使用した同じタスクのワンショット解決を報告します。

この表は、次の 4 つの直接的な結論を裏付けています。

1. no_context 使用するトークンが最も少ないように見えますが、252 個のタスクのうち 138 個だけを渡します。大量の手順情報を破棄しながら、コンテキストを保存します。
2. Skillによりパス数が 138 から 161 に増加しますが、トークンの総数は 803,099 に達します。静的な作業マニュアルは役に立ちますが、必ずしも経済的であるとは限りません。
3. Opus Gene は 1 ラウンドで 200 個のタスクを通過しますが、これはSkillより 39 個多く、使用するトークンの数は 79,619 個少なく、9.9% 削減されます。
4. Opus のマルチラウンド探索と比較すると、1 ラウンドのGene再利用によりコールが 404 から 252 に減り、152 の探索コールがなくなり、総トークンが 1,333,968 から 723,480 に減少し、45.8% 削減されます。

Gene のトークン効率は、プロンプトが短いことだけから得られるものではありません。これにより、失敗のフィードバック、修正手順、および最終的に成功したワークフローが、複数ラウンドの探索から注入可能な手続き型記憶に変換されます。後のモデルは、ゼロから試行錯誤を始めるのではなく、結果として得られる実行戦略を受け取ります。 Gene はプロンプトに答えを入力しません。これにより、当初は複数回の試行が必要だった実行パスが、再利用可能なプロシージャ コンテキストとして利用可能になります。

3.4 タスク タイプ別の Opus Gene とSkill (RQ3: どのタスク タイプ、モデル タイプ、および Gene ソースが手順ガイダンスから恩恵を受けるか?)

Opus によって進化した 252 のタスクをタイプごとに分割すると、より詳細なビューが生成されます。 4 つのグループには 64、62、30、および 96 のタスクが含まれており、合計 252 になります。したがって、これらの表には進化したGeneのみが記載され、参照抽出されたGeneは除外されます。 Opus Gene は、エージェント環境とルールに従って最も一貫した利益をもたらしますが、コードと数学はターゲット モデルにより強く依存します。

agent_env_synth (64 タスク)

コード生成 (62 タスク)

数学推論 (30 タスク)

rule_following (96 タスク)

の上 agent_env_synth, Opus Gene は 7 つのモデルすべてでSkillを上回り、+15.6 から +29.7 パーセントポイントの増加がありました。環境タスクには依然としてパッケージの動作、複数のファイル、テスト制約が必要ですが、成功の軌跡から抽出されたインターフェイスと実行順序により、省略が一貫して削減されます。

ルール遵守も 7 つのモデルすべてで +2.1 ～ +22.9 パーセント ポイント向上しました。ルール タスクの失敗の多くは、プロンプトを読めないことが原因ではなく、優先順位、オーバーライド、等価境界、または離散オプション制約の一貫性のない処理によって発生します。 Gene はこれらの手順チェックを明示的に行い、モデルが正しい決定に達するのを支援します。

コード生成は混在しています。 Sonnet、Gemini Flash、Qwen Coder は Gene の恩恵を受けています。 Opus、Gemini Pro、Qwen 3.5 はわずかに減少しました。 MiniMax は変更されません。圧縮された手順ガイダンスはインターフェイスとワークフローの省略を減らすことができますが、常により完全なSkillを置き換えるとは限りません。効果は、ターゲット モデルが 2 つの形式のコンテキストをどのように使用するかによって異なります。

数学的推論には最も注意が必要です。オーパス 4.8 は 43.3% から 83.3% に上昇します。 Gemini Pro と 0% の 2 つのモデルは変更されません。 Sonnet、MiniMax、Qwen 3.5 は減少しました。短答式の数学は、正確なシンボリック実行、境界計算、および解答の正規化に大きく依存します。手順のガイダンスは方法を提案できますが、計算に代わることはできず、一部のモデルの注意をそらす可能性があります。

これらのトラックレベルの結果は、LongWoF-Bench が複数のトラックにまたがる理由を説明します。集計スコアは支援が役立つことを示しますが、どのタスク フォームが利益をもたらし、どこに問題が残っているかを明らかにするのはトラック レベルの分析のみです。

3.5 共通の進化した重複: ジェミニGeneとオーパスGene

Gemini Gene と Opus Gene の進化したタスク セットは同一ではないため、それぞれを独自の完全なセットで比較することは無効になります。代わりに、両方によって進化した 180 のタスクを使用します。この重複に関しては、Opus Gene が Gemini Gene よりも一貫して強力であり、Gene オーサリング モデルの機能が、結果として得られる Gene の使いやすさに影響を与えることを示しています。

3.6 ケーススタディ

ケース 1: コード生成 / T0161、ドリルホール アッセイの合成

タスク。 地球科学パイプラインは以下を読み取ります。 collars.csv そして assays.csv。アッセイ行には、重複する深さ間隔や、次のような検出下マーカーが含まれる場合があります。 '<0.01'。プログラムは次のことを行う必要があります: (1) 変換する <x の中へ x/2; （２）重なり合う深度間隔を相互に排他的なセグメントに解決する。 (3) これらのセグメントを深さ 0 から 0 までの固定 2 メートルのビンに再合成します。 max_depth; (4) を計算します。 alteration_index 各ビンごとに; (5) 各ホールの計算 mineralization_score プロスペクト全体の中央値を超える複合 Au/Cu 値の合計として、中央値はデータセット内の 2 メートルの複合材料ごとに計算されます。

従来のプロセスとオーパスがどのようにGeneを進化させたか:

• ロールアウト 1 (解決) → FAIL (pass_rate=0.875)。 Opus は「後の間隔が優先」ルールで重複を解決しました。重複する場合は、後の行が前の行を上書きします。
• ロールアウト 2 (変異) → FAIL (pass_rate=0.875)。 Opus は同じ規則を維持し、NaN の処理のみを強化しました。オーバーラップテストはまだ失敗しました。
• ロールアウト 3 (変異) → PASS (pass_rate=1.0)。 Opus はオーバーラップ セマンティクスを変更しました。後の間隔を優先させる代わりに、セグメントをカバーするすべての間隔の値を平均し、それらのセグメントを長さで重み付けして 2 メートルのビンに入れました。これは、予想される合成セマンティクスと一致し、合格しました。

このブレークスルーは意味論的なものでした。重複するアッセイ間隔は上書きされるのではなく平均化される必要がありました。それがGeneによって捉えられるのです。

進化したGene (T0161.json、ペイロード):

{
  "type": "Gene",
  "summary": "Build a geoscience/interval pipeline that cleans below-detection markers, resolves overlapping depth intervals, composites into fixed-length bins, and emits per-row and per-entity aggregate CSVs.",
  "category": "innovate",
  "signals_match": [
    "drillhole assay compositing",
    "below-detection limit markers like '<0.01'",
    "overlapping depth intervals to mutually exclusive segments",
    "fixed-length 2-meter downhole composites",
    "alteration index / mineralization score formulas",
    "prospect-wide median threshold aggregation",
    "--input/--output directory CLI with named CSV outputs",
    "length-weighted interval averaging"
  ],
  "strategy": [
    "Parse CLI --input/--output dirs; read collars and assays CSVs by exact column names; create output dir with makedirs(exist_ok=True).",
    "Clean value columns: convert '<x' strings to x/2 (half detection limit), '>x' to x, blanks/'na' to NaN, else float; coerce depth columns to numeric.",
    "Per hole, resolve overlaps: collect breakpoints from all from/to bounds, for each adjacent segment use midpoint to find covering intervals and average their values into one exclusive segment.",
    "Composite into exact fixed-length bins from 0 to max_depth (ceil(max_depth/len) bins); for each bin length-weight each value by overlap length with segments, divide by total weight, NaN if none.",
    "Compute per-bin derived index per given formula guarding zero/NaN denominators; write one CSV with hole_id, bin from/to, and index using the required header order.",
    "Compute dataset-wide medians across ALL bins for threshold columns; per hole sum bin values exceeding their respective medians for the score and take per-hole max values; write the summary CSV with exact headers.",
    "Verify both output files exist, column names/order match the contract, and every hole appears even with empty or missing assays."
  ],
  "preconditions": [
    "Medians for scoring must be computed across the full composited dataset, not per hole.",
    "Bins must span exactly 0..max_depth and exist for holes with no assay coverage (values NaN).",
    "Overlap resolution must produce mutually exclusive segments before any compositing aggregation.",
    "String/NaN/empty assay cells must be sanitized before numeric ops to avoid type errors."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gene なしの Gemini Pro: 失敗しました。 Gemini の resolve_overlaps は間隔を並べ替え、次の間隔の開始時に前の間隔を切り捨てました。これは、重複する値を破棄する「トリム、結合しない」方法です。

prev = resolved[-1]
if row['depth_from'] < prev['depth_to']:
    if row['depth_from'] > prev['depth_from']:
        prev['depth_to'] = row['depth_from']   # trim only; discard overlap contribution
    else:
        resolved.pop()
resolved.append(row)

結果は、 FAIL:L2_prospect_summary_adv_overlap - Mismatch in mineralization_score for key ('H003',): got 0.0, expected 202.0。オーバーラップ処理により、スコアを押し上げる要因が取り除かれました。

Gemini Pro with Gene: 合格。 Gene の「ブレークポイントを収集し、カバー間隔を平均し、長さで重み付けしてビンに入れる」戦略に従って、Gemini はブレークポイント セグメントを構築し、カバー間隔ごとに平均して、セグメントを 2 メートルのビンに長さで重み付けしました。

boundaries = sorted(set(hole_assays['depth_from']).union(hole_assays['depth_to']))
for seg_from, seg_to in adjacent_pairs(boundaries):
    covering = hole_assays[(hole_assays.depth_from <= seg_from) & (hole_assays.depth_to >= seg_to)]
    seg_data[col] = np.average(vals[valid], weights=w[valid])   # average, not overwrite

Gene がなければ、モデルはデフォルトで一般的な間隔マージ ヒューリスティック「後で勝つ / 前の間隔をトリミングする」になりました。妥当に見えますが、アッセイの合成には間違っており、削減されます。 H003の石化スコアがゼロになります。 Opus は、2 回のロールアウトの失敗を通じて、正しい規則は長さ加重平均であることを学びました。 Gene は Gemini にその正確な規則を与え、最初の試行で正しく合成できるようにしました。

ケース 2：rule_following / T0659、緊急ディスパッチコード

タスク. 屋内での家庭内騒乱、対象者が 包丁 (刃物) を所持、目に見える怪我は無し、地理位置情報が ちょうど 5 ZDU 離れていることを考慮した 911 シナリオを想定して、dispatch_omega、dispatch_sigma、dispatch_theta、および dispatch_zeta から正しいディスパッチ コードを選択します。この決定は、距離としきい値の比較 (正確に 5 がカットオフを超えているか) と **武器/負傷の優先順位 ** (負傷のない武器が存在する場合、負傷のない武装レベルにマッピングされます) という 2 つの相互作用するルールによって決まります。

従来のプロセスとオーパスがどのようにGeneを進化させたか:

• ロールアウト 1 (解決) → FAIL (pass_rate=0.667)。 Opus はコミットを拒否し、ルール テーブルが欠落していると主張し、プレースホルダー dispatch_omega を発行し、選択が検証できないと述べました。
• ロールアウト 2 (突然変異) → 失敗 (pass_rate=0.667)。 オーパスは、距離のしきい値に関係なく武器が反応をエスカレートさせたと推論して、dispatch_theta を選択しました。これにより、事件が過度にエスカレートしました。無傷の降格は無視され、境界距離がエスカレーションのトリガーとして扱われました。
• ロールアウト 3 (変異) → パス (pass_rate=1.0). Opus は優先順位を正しく適用しました。ちょうど 5 ZDU は厳密にはしきい値を超えないため、距離エスカレーションはトリガーされません。負傷のない武器は、無傷武装層にマッピングされます。 dispatch_sigma.

進化したGene (T0659.json、ペイロード):

{
  "type": "Gene",
  "summary": "Select a dispatch/response code by applying weapon and injury precedence rules combined with a strict ZDU/distance threshold comparison, emitting an exact two-line ANSWER/ANALYSIS contract.",
  "category": "other",
  "signals_match": [
    "dispatch code selection",
    "threshold comparison on distance units (ZDU)",
    "rule precedence for weapon-involved incidents",
    "ANSWER and ANALYSIS exact two-line output",
    "weapon present but no visible injuries",
    "911 / emergency dispatch scenario",
    "choose one of several action tokens",
    "case-insensitive exact-match grading"
  ],
  "strategy": [
    "Extract every decision factor from the prompt: weapon present?, injuries present?, distance value, and the exact stated threshold.",
    "Apply the threshold as written: treat 'exactly equal' as NOT exceeding unless rule says >= (strict vs non-strict matters most for boundary values).",
    "Resolve precedence order: injury-tier > armed-no-injury > distance-only codes; pick the highest-priority rule whose conditions are fully satisfied.",
    "When a weapon exists but injuries are explicitly denied, choose the armed-but-no-injury tier, not the injury escalation or plain distance code.",
    "Map the satisfied rule to its corresponding code token and verify it is one of the allowed options.",
    "Emit exactly two lines: 'ANSWER: <token>' then 'ANALYSIS: <one paragraph ≤80 words citing the rule>', with no extra output or whitespace lines."
  ],
  "preconditions": [
    "Confirm whether the boundary value triggers escalation (strict > vs >=) before deciding distance effect.",
    "Verify the chosen token is spelled exactly as an allowed option for case-insensitive exact match.",
    "Ensure precedence (weapon/injury rules) overrides distance-only codes when both apply."
  ],
  "constraints": { "max_files": 1, "forbidden_paths": [".env", "secrets", "credentials"] },
  "validation": []
}

Gene なしの Gemini Pro: 失敗しました。 Gemini は武器を過度にエスカレートし、境界を誤って処理し、dispatch_theta を選択しました。

ANSWER: dispatch_theta
ANALYSIS: ... because the subject is exactly 5 ZDU away ..., the threshold comparison for a weapon-related incident indicates dispatch_theta ...

これは、オーパスがロールアウト 2 で犯した 同じ 間違いです。無傷のダウングレードを無視しながら、境界距離と武器をより高い Tier が必要なものとして扱っています。

Gemini Pro with Gene: 合格

ANSWER: dispatch_sigma
ANALYSIS: ... a bladed weapon with no visible injuries at exactly 5 ZDU ... under the rule precedence, the combination of weapon and close distance ... no active injury indicates the dispatch_sigma code.

このタスクには、厳密な境界と非厳密な境界 (しきい値をちょうど 5 つ「超えます」か?) と **優先順位 ** (負傷 > 負傷なしの武装 > 距離のみ) という 2 つのよく知られた罠があります。 Opus が収束する前と同様に、ノーコンテキスト モデルは両方で失敗しました。Geneは両方のルールを明示的に示しています。ルールに記載がない限り、平等を超えないものとして扱います。 >=、および傷害のエスカレーションではなく、無傷武装層への傷害が否定された状態で武器が存在することをマップします。したがって、Gemini は優先順位を正しく適用し、 dispatch_sigma.

2つのケースに共通すること

どちらのケースでも、もっともらしいデフォルトのヒューリスティックが、タスク固有の契約に反して失敗しました。

• T0161：後の区間が前の区間を上書きすると扱い、重複部分の寄与を失いました。
• T0659：武器があれば常に対応を強化すると判断し、負傷なしの降格規則と厳密な距離しきい値を見落としました。

Opus は各ケースで修正規則を特定するまでに 2～3 回の rollout を要しました。進化した Gene はその規則を数行の strategy と preconditions に圧縮し、Gemini が最初の試行から正しい規則を適用できるようにします。

コードのケースでは反復デバッグと大規模な書き直しを、ルールのケースでは優先順位と境界条件の誤りを減らしました。これは手順ガイダンスが探索コストを下げる仕組みを示しますが、すべてのタスクで同じ効果が得られることを意味しません。

参考文献

• Diao, L., Xu, X., Sun, W., Yang, C., & Zhang, Z. (2025). GuideBench: Benchmarking Domain-Oriented Guideline Following for LLM Agents. ACL 2025, 11361-11399.
• EvoMap. (2026a). GEP Protocol Deep Dive: Genetic Engineering for AI Agent Self-Evolution.
• EvoMap. (2026b). Agent Skill vs GEP Gene: The Fundamental Divide Between Tools and Evolution.
• Li, X., et al. (2026). SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks. arXiv:2602.12670.
• Wang, J., Ren, Y., & Zhang, H. (2026). From Procedural Skills to Strategy Genes: Towards Experience-Driven Test-Time Evolution. arXiv:2604.15097.