blender-agent-benchmark

Blender Agent Benchmark

自律的な判断、エビデンスを記録する頻度、長時間タスクの継続方法について、各タスクで一度、共通の実行ガイダンスを読んでください。

タスク、モデル、推論量、制限、Blender のビルド、評価者を同じにして変更を測定してください。エージェントの自然な振る舞いを維持してください。

同梱のランナーは、--agent codex（デフォルト）または--agent claude-codeでテスト対象のエージェントを選択します。Claude Code からランナーを起動しても、選択は変わりません。記録されたエージェントの CLI、指定したモデル、観測されたモデル識別子を報告してください。ランナーを起動したホストから推測してはいけません。

ベンチマークの整合性を保つ

1. 条件ごと、反復ごとに分離されたディレクトリを作成します。
2. エージェントが見つけられる場所に、もう一方の条件のコード、レンダー、メトリクス、想定される修正を残さないでください。
3. プラグイン条件でプラグインを明示的に呼び出す場合を除き、ユーザー向けのタスクプロンプトは同一にします。
4. プラグインなしのベースラインにはcodex exec --ignore-user-configを使用します。
5. プラグイン条件では、新しい呼び出しで固定されたプラグインディレクトリを使用します。デフォルトはランナーを含むプラグインです。--skill-rootで別のスナップショットを選択できます。
6. CLI バージョン、モデル、推論量、Blender のビルド、所要時間、ツール呼び出し、失敗、出力ハッシュを記録します。
7. 生成後に出力を評価します。非公開の評価基準の詳細をエージェントに漏らさないでください。

フィクスチャ、採点、比較に関する主張を変更する前に、references/methodology.mdを読んでください。 オプトインのscenesスイートとgame_charactersスイートでは、それぞれ独立したホールドアウトを含む3つのタスクが追加されます。 作成したカメラのエビデンス、レンダーのみの成果物、変形チェックについては、シーンとキャラクターのプロトコルを読んでください。 新しいスイートの設計や他の Blender ベンチマークから評価手法を取り入れる際は、references/open-source-benchmark-landscape.mdを読んでください。 references/validated-results.mdは、プラグインの記録済み検証結果を確認する場合にのみ読んでください。ベンチマークの提出物を生成している間は読まないでください。

迅速な開発サイクル

別のフル生成スイートを実行するのではなく、保存済みの失敗エビデンスをもとに改善を始めてください。対象を絞った1回の修正には、デフォルトで5分の実時間予算を設定します。

1. 既存の保存済みアセットから、最も影響の大きい視覚的な欠陥を特定します。
2. そのアセットの永続化されたソースと入力を、新しい修正用ディレクトリにコピーします。元のアセットと画像は修正前の状態として保持します。
3. 選択したモデルを使って、ソースを1回ローカルで修正します。影響を受けた領域以外の良好なプロポーション、シルエット、マテリアル、ディテールを維持します。ゼロからアセットを再構築したり、数値チェックを満たすために単純化したりしないでください。
4. 1回再生成し、blender_render_evidenceを使って関連する固定ビューを2つ、解像度256で要求します。修正前後で同じ明示的なプレゼンテーションとフレーミングの入力を使用します。画像を開き、必要に応じてフルサイズのビューを確認します。
5. 結果を確認し、指摘された欠陥と、仕上がりが損なわれていないかをチェックします。実験で別のモデルを明示的に指定している場合にのみ、別のモデルを使用します。修正による視覚的な改善が見られない場合は、元の状態を維持します。経過時間、ソースの正確な変更内容、未解決の弱点を記録します。

これは修正の実演であり、モデルの一般的な能力向上を示すエビデンスではありません。入力に変更がない場合は、既存の決定論的なメトリクスを再利用してください。編集後に影響を受ける技術テストを実行し、保持する候補に対しては、エクスポート／マルチビューのゲートを一度だけ実行してください。ゼロからの生成の反復や、複数の独立した評価者による評価は、リリースレベルの能力に関する主張、または明示的な要請がある場合に限ります。小規模な修正を、無人で何時間も続くキャンペーンにしないでください。

スイートを実行する

Astra では、--profile astra（モデル gpt-6-astra、推論強度 medium）を指定します。 sol、terra、luna プロファイルは、同じ推論強度でそれぞれ対応する GPT-5.6 モデルを選択します。明示的な --reasoning は、モデルではなく推論強度を上書きします。 再現可能な比較には、明示的なプロファイルまたは --model を使用してください。configured default を使う実行はモデルが固定されないため、探索的なものです。

実験は分けてください。まず Astra で旧スキルと改訂版スキルを比較し、次に改訂版スキルを固定して Astra／Sol／Terra／Luna で比較します。フィクスチャ、有効な推論強度、Blender のビルド、制限、権限、評価器は固定してください。既存の非回帰ゲートではモデルの一致が必要です。モデルをまたいだ結果はモデルの比較を示すものであり、スキルの改訂による改善の証明ではありません。過去の結果ラベルを Astra に置き換えたり、モデルとスキルを同時に変更した結果を、どちらか一方だけに起因するものとしたりしないでください。

scripts/run_benchmark.ts を使用します。

bun "<skill-root>\scripts\run_benchmark.ts" `
  --suite quick `
  --mode baseline `
  --output "<run-root>\baseline"

bun "<skill-root>\scripts\run_benchmark.ts" `
  --suite quick `
  --mode plugin `
  --output "<run-root>\plugin"

まずスモークタスクでハーネスを検証します。全般的な能力向上を主張する前に、代表的なタスクを少なくとも3つ選び、実行を繰り返してください。

ランダム化されたブラインド多視点評価には scripts/compare_runs.ts を使用します。エージェントを再実行せずに、スコアラーの変更後に決定論的スコアを再計算するには scripts/rescore_run.ts を使用します。

過去との回帰比較には full を維持してください。より広いカバレッジによって従来の比較がひそかに変わらないよう、環境、プロシージャル生成、リギング／変形、シミュレーションの難易度が高いタスクには、オプトインの challenge スイートを使用します。

静的なキャラクターの形状、ウォークサイクル、表情の組み合わせ、液体の注ぎ動作、布のドレープには quality を使用します。2視点画像からの再構成には、--reference-dir とともに reference を使用します。これらのスイートでは、評価対象のモーションとベイクの前提条件が追加されますが、目視レビューに代わるものではありません。入力の仕様と制限については、品質スイートのプロトコルを参照してください。明確化の評価は、インテークケースを使って別途行ってください。完全に仕様が指定されたアセットのフィクスチャでは、意図的に追加質問が禁止されているため、明確化の質は測定できません。

bun "<skill-root>\scripts\run_benchmark.ts" `
  --suite challenge `
  --mode skills `
  --condition-label revised-plugin `
  --output "<run-root>\revised-challenge"

challenge スイートには、360フレームの移動する炎と必須の15秒 MP4 を含む、独立したポートフォリオ品質のランプタスク realistic_fire_lantern_showcase も含まれています。このタスクのみを、オプトインの反復ワークフローで実行します。

bun "<skill-root>\scripts\run_benchmark.ts" `
  --suite challenge `
  --tasks realistic_fire_lantern_showcase `
  --mode skills `
  --condition-label cached-iterative-fire-lantern `
  --skill-root "<installed-plugin-directory>" `
  --output "<run-root>\fire-lantern"

このフィクスチャでは、lamp_fire_15s.mp4、iteration_review.json、24 fps で作成およびエクスポートされた1～360フレームのアクション、6視点の証拠、サンプリングされた炎のフレームが必要です。ランナーは、PATH 上の ffprobe、または設定されている場合は FFPROBE_EXECUTABLE を使って、動画の長さ、フレームレート、フレーム数を検証します。

意図的に飽和しにくくした統合タスクには、オプトインの gauntlet スイートを使用します。環境、編集可能なプロシージャル生成コンベア、リギングされたロボット、シミュレーション由来のカプセルの動き、決定論的アニメーション、マテリアル、ライティング、エクスポート、修復前後の証拠を、ひとつの因果関係のあるシーンに組み合わせています。

bun "<skill-root>\scripts\run_benchmark.ts" `
  --suite gauntlet `
  --mode skills `
  --condition-label candidate-gauntlet `
  --output "<run-root>\candidate-gauntlet"

gauntlet の提出物は、ブラインド評価者を3人以上使って比較してください。比較レポートには、このタスクの verifiedScores が含まれます。内訳は、決定論的スコアが60％、タスク固有の視覚基準が25％、幅広い多視点品質が15％です。ハードゲートに失敗した場合、結果は49点が上限になります。重要な基準の過半数を失った場合は84点、いずれかの基準の過半数を失った場合は94点が上限です。決定論的スコアが満点で、すべての基準に全評価者が合格と判定し、すべての視覚的側面で例外的なスコアを得ることができなければ、99点が上限になります。この仕組みにより、部分点を取りやすくしながら、指標を攻略するだけでは飽和に至らないようにしています。

各タスクには、カテゴリが明示された視覚基準が設定されています。ブラインド評価者は、両方の候補について各基準に回答する必要があります。これらの合格率は、全般的な美的側面や決定論的スコアとは分けて扱ってください。

非対話型の Codex は、承認が必要な MCP ツール呼び出しをキャンセルします。MCP の条件をテストする場合は、比較するすべての条件に --bypass-approvals を渡し、ベンチマーク用ディレクトリを分離してください。MCP の条件だけに、より広い権限を与えてはいけません。 scripts/benchmark_mcp.ts --asset <path> --output <new-dir> を使用して、MCP トランスポートが直接 CLI 評価と同じ決定論的な指標を返すことを検証します。結果が同等であることは、トランスポートの正しさを証明するものであり、モデリング品質の向上を示すものではありません。

比較条件

ランナーはプロセス単位の CLI 引数を使って、グローバルプラグイン、メモリ、ホストのスキルエントリ、自動的なプロジェクト指示の注入を無効にしつつ、明示的にプロンプトで指定したスナップショットスキルと MCP は維持します。ユーザー設定は編集しません。--ignore-user-config だけでは、ホストのスキルを分離できません。キャンペーンを開始する前に、インストール済み CLI でこれらの制御が機能することを確認してください。未対応のスイッチや、Windows で引数リストが大きすぎる問題は、ベンチマーク生成を開始する前に解決する必要があります。

Codex の WebSocket が繰り返しアイドル状態で失敗する場合は、両方の生成器と compare_runs.ts で --codex-transport http を使用します。このプロセス単位のプロバイダーは既存の OpenAI ログインを維持し、HTTP Responses ストリーミングを選択します。グローバル設定は編集しません。デフォルトは auto です。プロベナンスにトランスポートを記録し、中断されたトレースはインフラストラクチャ障害として保持したうえで、両方を新しいディレクトリで再起動してください。トランスポートによる復旧は、モデリング品質の向上ではありません。

固定したプラグインでの実行では、ユーザー設定を無視し、選択したスキルをパスから読み込みます。skills_mcp モードでは、ランナーがそのスナップショットの mcp/server.ts を bas_benchmark として明示的に起動し、ツール一覧を確認して、ソースフィンガープリントとともに記録します。エージェントのトレースで、新しいツールが実際に使われたことを確認してください。利用可能なツールが一度も呼び出されていない場合、そのツールのモデリング上の利点は立証できません。エージェントのイベントと stderr は実行中に書き込まれ、無人監視用の PID 記録も作成されます。作業を再開する前に、プロセスと最終プロセス記録を確認してください。

評価が完了するまで、評価対象の識別情報はメモリ上に保持してください。条件の対応関係を記したファイルを評価者の作業ディレクトリに置かないでください。比較ペア間で同じ評価者モデルと推論の強度を使い、選択したモデルを明示的に記録してください。

以下の評価軸は分けて扱ってください。

• 実行／エクスポートの妥当性；
• プロンプトおよび構造への準拠；
• ジオメトリ／ゲーム対応性；
• 仕上げプロファイルへの準拠。洗練された滑らかな外観と、明示的なローポリの意図を含みます；
• UV、シェーディング、仕上げ、マテリアル、テクスチャ、プレゼンテーションの各指標；
• マルチビューの視覚品質；
• 物理的な妥当性；
• 該当する場合のアニメーション品質；
• コンテキスト／エクスポートの正確性；
• 時間、ターン数、ツールの失敗、コスト。

重み付けスコアを使う前に、ハードゲートを適用してください。較正されていない絶対的な美的スコアより、条件を伏せたペアワイズの視覚レビューを優先してください。評価者間で A／B 画像の順序をカウンターバランスし、評価者ごとの対応関係を保持してください。三角形数が少ないことを理由に、最終アセットがブロックアウトのように見える問題を相殺してはいけません。

現行プラグインと改訂版を比較する場合は、実行ごとに異なる --condition-label の値を指定し、compare_runs.ts --require-non-regression を実行してください。グローバルで有効になっているプラグインではなく、チェックアウト済みまたはインストール済みのプラグインの正確なリビジョンに各実行を固定するには、--skill-root <plugin-directory> を渡します。このゲートは、ベースラインのペアが不足している場合、ハードゲートの条件が失われた場合、タスク単位の自動スコアが少しでも低下した場合、条件を伏せた視覚評価で過半数が劣る場合、または重要な視覚基準が「過半数が合格」から「過半数が不合格」に変化した場合に失敗します。新しいチャレンジタスクでの改善を、過去のスイートでの後退と相殺してはいけません。

保存済みのより大きなベースラインに対して修復済みの一部タスクを比較するには、compare_runs.ts --tasks <comma-separated-task-ids> を使用します。意図的に除外したベースラインタスクを、証拠の欠落として扱わずに済みます。

反復

1. 失敗した指標、レンダリング、動画、トレースを調べます。
2. 他のケースにも応用できるワークフロー上の欠陥を 1 つ特定します。
3. 関連するスキル、決定論的ツール、または MCP のインターフェースを必要最小限だけ変更します。
4. 同じタスク範囲を再実行します。
5. 変更を採用する前に、ホールドアウトタスクを実行します。

フィクスチャの答えを明かしたり、通常のモデリング動作を損なったりするベンチマーク専用の指示は、残さないでください。