OpenClaw x EvoMap: CritPt Physics Solver における体系的評価と進化分析レポート

1. エグゼクティブサマリー

本レポートでは、OpenClaw（EvoMap 統合、複数クラスの gene 進化対応）の CritPt Physics Solver におけるパフォーマンスについて、体系的なテストと振り返りを行いました。私たちの目標は、EvoMap が OpenClaw などの agent に対して、ドメイン知識の迅速な学習、より低コストでのドメインタスクの完了、そして高頻度で有効なワークフローを再利用可能なアセットとして定着させ、後続の拡張を支援できるかどうかを検証することです。

結論を一文で要約すると：この進化チェーンは「言語模倣者」から「物理シミュレーションエンジニア」への変革の技術ロードマップであり、スコア向上の主因は「より上手に話せるようになった」ことではなく、推論を実行可能なクローズドループにエンジニアリングし、そのループを段階的に再利用可能な gene/skill に固定化したことにあります。

2. CritPt Benchmark：実際に何を評価しているのか？

2.1 評価対象：研究レベルの物理推論における「デリバリーパイプライン能力」

CritPt Physics Solver のシナリオでは、「もっともらしい説明を書く」ことはタスク完了とは見なしません。重要なのは、スコア判定可能、実行可能、検証可能な結果成果物（通常はテンプレートに準拠した Python 関数出力）を納品することです。そのため CritPt のシステム評価は自然と以下の点に重点を置きます：

• モデリング：物理的仮説と制約を計算可能な数学構造に形式化できるか；
• 実装：安定して実行可能なコードを生成できるか（テキストのみではなく）；
• 検証：自己チェック/アサーション/境界テストにより明らかな物理的不合理を抑制できるか；
• 信頼性：複数回の実行で安定したデリバリーを維持できるか（偶然の1回の正解ではなく）。

2.2 二段階デリバリーパラダイム（Two-step formatted answering）

CritPt の重要な特徴の一つは「二段階デリバリー」です：第一段階では自由な推論を行い、第二段階では最終回答を所定の Python コードテンプレートに強制的に書き込みます（最終コードのみ提出、説明テキストの混入不可）。これにより自動採点とスケーラブルな評価が可能になります。

2.3 例題（説明用、実際の問題とは対応しません）

以下は構造的に同形の例示です：重要なポイントは「提出物が実行可能な関数である」ことであり、ナラティブテキストではないということです。

例題：浮動小数点数を最終回答として返す（第二段階ではコード出力のみ許可）。

def solve():
    import math
    L = 1.0
    g = 9.81
    T = 2.0 * math.pi * math.sqrt(L / g)
    return float(T)

3. テスト対象システムとバージョン進化（Beta -> v2.2）

システム進化を 5 つのフェーズに分割しました：Beta（v0.x）-> v1.0 -> v2.0 -> v2.1 -> v2.2（計画中）。全体のロードマップは、まず「判定可能な成果物パイプライン」を確立し、次に「修復/検証/物理的信頼性」をデフォルト戦略として段階的に固定化することです。

バージョン-遺伝子マッピングテーブル

クロスバージョンサポート遺伝子

3.1 Beta：オープンループ言語模倣フェーズ

Beta の重要な問題点：モデルは主に「テキストパフォーマンス」を行っており、安定した検証可能な成果物のアンカーポイントが欠如していました。

そのため、かなりのトークンを消費しても、回答が判定不能、フォーマット非準拠、または事実のハルシネーションにより失点しやすい状態でした。

評価結果から見ると、Beta ラウンドの精度は 0.00% であり、「回答できる」ことは「判定可能でスコアが得られる」こととイコールではないことを示しています。

3.2 v1.0 | 概念実証（The Innovation）：Text Generation -> Model-Based Reasoning

核心的飛躍：「直接答えを推測する」から「実行可能なコードと判定可能な結果の生成を優先する」へ。

主要な遺伝子は gene_gep_innovate_from_opportunity で、能力の重点は：

• 問題を実行可能な形式に変換；
• 純粋な言語的主観推論を実行結果で置換；
• 失敗と異常結果の基本的な区別（成功/失敗/利用不可）。

このフェーズの主な価値は「デリバリー可能」なベースラインの確立であり、一発で高精度を追求することではありません。

3.3 v2.0 | 強化フィードバック（Enhanced Feedback Loop）：Self-Correction クローズドループ修復

核心的飛躍：ランタイム失敗を監督信号に変換し、Run -> Error Signal -> Retry/Fix のクローズドループを形成。

主要な遺伝子は gene_gep_repair_from_errors で、能力の重点は：

• 失敗イベントの構造化記録；
• 最小限の変更による反復修復；
• 複数回の試行による「提出可能率/判定可能率」の向上。

このフェーズの改善の焦点は依然として「デリバリー率と判定可能性」であり、問題ごとの一発命中ではありません。

3.4 v2.1 | ロバストネスプッシュ（Robustness Push）：「動く」から「より安定、より強力」へ

v2.1 フェーズは戦略と実行効率の相乗的最適化を体現しています。

デリバリー能力を維持しながら、複雑な問題に対するカバレッジと解法の深さが継続的に向上し、評価精度は 17.14% に上昇しました。

これは進化メカニズムがもはや「局所的なバグ修正」だけでなく、全体的な解法品質と収益構造の最適化を開始したことを示しています。

3.5 v2.2 | 最高スコアフェーズ（Best-Score Stage）：「正しく計算する」へ

v2.2 は現在最高の評価精度 18.57% を達成しました。

• 評価側：timeout_rate=0、server_timeout_count=0（採点タイムアウトなし）；

これはシステムがピークスコア能力を持っていることを示しており、次のステップはこの高スコア能力を「高スコア + 安定性」のデュアルエクセレンス能力にさらに固定化することです。

4. 結果と診断：トークン軌跡、コスト指標、「学習されたパターン」のシグネチャ

4.1 コストとトークンの指標

上図のコスト軸はデフォルトで対数スケールを使用し、$0.81 のデータポイントが原点付近に圧縮されるのを防いでいます。線形に切り替え可能。コスト指標：回答生成に必要なトークンのみを考慮（thinking + final answer）。

4.2 トークンは先に上昇してから下降：明示的推論から暗黙的プロシージャ化へ

トークンが先に上昇してから下降する現象が観察されました。これはエンジニアリングシステムにおける「あるパターンを学習した」典型的なシグネチャです：システムは「明示的推論（書き出す）」から「暗黙的プロシージャ化（カプセル化と再利用）」に移行します。この軌跡は「モデルがより上手に話せるようになった」のではなく、「推論が実行可能なクローズドループにエンジニアリングされた」ことを意味し、高頻度のクローズドループが段階的に再利用可能なアセットに結晶化されています。

さらに、トークンの変動は「明示的に展開されるプロセスコスト」を反映しています：初期段階ではワークフローが応答に書き出され（長い）、後期段階ではワークフローが skill/gene に固定化され、自然言語でスキャフォールディングやトライアル＆エラーログを毎回繰り返す必要がなくなるため、可視トークンは減少しますが、内部プロセスはより信頼性が高くなり、スコアは実際に上昇し続けます。

5. 公式評価パイプライン（再現可能、監査可能）

本セクションでは、スコアが公式評価パイプラインから得られたものであり、ローカルの自己計算ではないことを明確にします。

5.1 Submission 生成（Generation）

各問題に対して実行可能な Python コードセグメント（generated_code）を生成し、問題 ID ごとに submission JSON ファイルとして書き出します。パスは：

• results/generations/<RUN_ID>/submissions/<challenge>/<problem_id>.json

バッチ生成コマンド：

bash scripts/run_generation.sh

5.2 公式採点への提出（Grading）

公式採点スクリプトを使用して <RUN_ID> の submissions をバッチとして Artificial Analysis の CritPt 評価 API に提出します。サーバーは accuracy/timeout 等の指標を返し、ローカル側はレスポンスの保存のみを担当します。提出前に環境変数 CritPt_API_KEY を準備する必要があります（採点スクリプトは .openclaw/.env から読み取ります）。

提出コマンド：

bash scripts/run_grading.sh <RUN_ID>

レスポンスファイルの保存パス：

• results/evaluations/<RUN_ID>/aggregate_report.json

5.3 レスポンスフィールドの解読（数値の「読み方」）

aggregate_report.json の一般的な主要フィールド：

• total_files_found：スキャンされた submission ファイル数
• total_submissions_loaded：正常にロードされた submission 数
• failed_to_load：ロード失敗リスト（空は全て読み取り可能を意味）
• summary.accuracy：正解率（0~1 の割合、パーセントではない；パーセント換算には x100 が必要）
• summary.timeout_rate：タイムアウト割合
• （場合により）judge_error_count：採点エラー数（一般的な原因は、生成コードが実行不能/関数がテンプレートに非準拠/説明テキストの混入等）

{
  "timestamp": "2026-02-16T11:59:30.909403",
  "total_files_found": 70,
  "total_submissions_loaded": 70,
  "failed_to_load": [],
  "summary": {
    "total_submissions": 70,
    "accuracy": 0.18571428571428572,
    "timeout_rate": 0,
    "server_timeout_count": 0
  },
  "metrics": {
    "accuracy": 0.18571428571428572,
    "timeout_rate": 0,
    "server_timeout_count": 0,
    "judge_error_count": 1
  }
}

6. なぜ CritPt を主要ベンチマークに選んだのか（Math500/AIME ではなく）

CritPt を主要ベンチマークとして選択した理由は、OpenClaw+EvoMap の差別化された能力をより強く増幅できるからです：ツールチェーンのクローズドループ、エンジニアリングのロバスト性、検証可能な物理的有効性、監査可能で再利用可能な進化アセット。Math500/AIME は補完的な検証とリグレッションテストにより適しています。

7. Skill / Knowledge / Gene：アセット化の説明（「なぜトークンが節約されるのか」）

外部への説明では、「知識--スキル--遺伝子」のエンジニアリング三層抽象化の使用を推奨します：

• Knowledge（知識）：事実と制約の集合（公式、常識的境界、ツール動作のパターン）；
• Skill（スキル）：実行可能なプロセスモジュール（モデリング、求解、Traceback 修復、アサーション注入、次元チェック等）；
• Gene（遺伝子）：意思決定バイアスとワークフローオーケストレーション（いつどのスキルをトリガーするか、順序、閾値、停止条件）。

これら三者のアクションチェーン：Knowledge が正確性の根拠を提供 -> Skill が根拠を実行可能なアクションに変換 -> Gene がアクションをデフォルト戦略と再利用構造にオーケストレーション。直接的なエンジニアリング上の利点の一つは「可視トークンの減少」です：大量の反復的なスキャフォールディング、トライアル＆エラー、説明的な自己証明がデフォルトワークフローに内部化され、外部には最終的な判定可能成果物のみが出力されるため、「より短い出力だがより高い安定性/スコア」という軌跡シグネチャが現れます。

8. 付録：生成プロンプト（記録保存）

レポートに記録された生成プロンプト（原文のまま）：

Use as many relevant internal skills and strategies as possible.
Think deeply, verify intermediate assumptions, and aim for the best possible final answer.
You may use available tools only when they improve correctness.
Return only final Python answer code with no markdown fences.
If a code template is provided, fill the template directly.

f"Problem ID: {task.problem_id}",
f"Problem type: {task.problem_type}",

"Problem statement:",
task.problem_description.strip()

9. 進化タスクの設計

主目標：accuracy の最大化
副目標：timeout_rate / judge_error / fallback / generation_failed の最小化

データパス（以下のパスを使用する必要があります）：
1) 問題データ（タスク分布の理解用）：
CritPt/data/public_test_challenges/json/Challenge_*.json

2) 過去の公式評価結果：
results/evaluations/*/aggregate_report.json

3) 過去の生成サマリー：
results/generations/*/run_summary.json

4) 過去のスコアサマリーテーブル（優先読み取り）：
/analysis/scoring/scoring_runs.csv

報酬計算式（formula_version=v1）：

定義：
acc = accuracy
to = timeout_rate
jer = judge_error_count / max(total_submissions,1)
gfr = gen_failed / max(gen_total_tasks,1)
fbr = gen_fallback_count / max(gen_total_tasks,1)

主報酬：
R_main = 100 * (0.88*acc - 0.06*to - 0.03*jer - 0.01*gfr) - 5*fbr

安定性報酬：
R_stability = 100 * (0.6*(1-gfr) + 0.4*(1-fbr))

総報酬：
R_total = 0.85*R_main + 0.15*R_stability