pai-design-workbench は、モデルの物理的な推定を小さな評価で測っています。ブラケット 1 つと実測済みの参照点 1 つを与え、モーター軸でのたわみが板厚・幅・高さに対してどのようなべき乗則で変わるかをモデルに答えさせ、その指数をホールドアウトのソルバー結果と比べます。リポジトリの commit 70330e2 には実モデルによる 1 回分の評価記録があり、中央値誤差 0.114、最大誤差 0.321、Spearman 0.95 で 3 項目とも基準を満たしましたが、高さの指数は実測の傾向と符号が逆でした。本記事では、この評価がモデルの出力をコードではなくデータに限定する仕組み、数値とベースラインの読み方、そして合格後もソルバーが最終的な根拠であり続ける理由を説明します。
本記事は commit 70330e2 に固定した 3 つのファイル、評価記録 docs/evidence/physics-eval.json、評価スクリプト scripts/eval-physics-solver.ts、要件表 docs/REQUIREMENTS.md（[O]、プロジェクト自身の記述）に基づきます。記録は保存済みの開発時評価 1 回分であり、本サイトはスクリプトの実行もモデルの呼び出しも行っておらず、数値も再現していません。同じリポジトリで CFD ケースを AWS Batch に載せる方法は、本サイトの 固定版の OpenFOAM ケースを AWS Batch で実行する：ハッシュ照合、2 つのメッシュ、ローカルとの抗力係数比較 で扱いました。本記事のテーマは別で、モデルの推定とソルバー結果との差です。
評価が問うこと：参照点 1 つと指数 3 つ
スクリプトのプロンプトは、機械エンジニアとしてこのブラケットのモーター軸でのたわみがパラメーターに対してどうスケールするかを予測し、JSON オブジェクト 1 つだけを返すようモデルに求めます。
{"thicknessExponent": a, "widthExponent": b, "heightExponent": c, "rationale": "<= 600 chars"}指数の意味はプロンプトに書かれています。deflection = d_ref * (t/t_ref)^a * (W/W_ref)^b * (H/H_ref)^c で、d_ref は実測の参照たわみ、t・W・H はそれぞれ板厚・幅・板の高さです。プロンプトは、板の曲げ、側縁のリブ、荷重の入る位置から推論するよう指示し、指数を [-6, 6] に制限しています。モデルが見る材料は、タスクのワークスペースにある README.md（ブラケットの説明）と reference.json（参照点）で、どちらもそのままプロンプトに埋め込まれます。
記録上のタスク名は agentforge examples/pai-workbench/eval/tasks/estimate-bracket-deflection で、9594430 でマージされたと注記されています。要件 F17 はこれを「eval/ でモデルの物理推定を測る」項目としています。
モデルが返すのは数値であり、コードではない
この評価の要は、モデルの出力が常にデータだという点です。記録は経路を「scripts/eval-physics-solver.ts → NoteFlow bounded executor（shared ledger、1 attempt、no retry）。モデルは指数を JSON で返し、コードは一切実行されない」と記しています。スクリプトでは次のようになっています。
- 制御された実行器（bounded executor）経由でモデルを呼び出し、有効なエンジンプロファイルのうち最初の 1 つだけを使います（
enabledProfiles(config).slice(0, 1)）。タイムアウトは 60 秒です。要件 F3 は実モデル呼び出しに主・予備・第 2 予備の 3 段階があると記していますが、ここでは 1 段目しか使わないため、評価結果はこのプロファイルにのみ対応します。 - 実行器が
doneを返さない場合や回答がない場合、スクリプトはエラーを投げます。再試行はしません。 - 回答の最初の
{から最後の}までを切り出し、zod で検証します。3 つの指数は [-6, 6] の数値、rationaleは文字列でなければなりません。プロンプトは理由を 600 文字以内とするよう求めていますが、検証では 2,000 文字まで受け付けます。 - 3 つの数値を固定テンプレートに埋め込んで
estimate.mjsを書き出します。これはreference.jsonを読み、上のべき乗則で推定値を返します。モデルが書いた文章が実行可能なコードになることはありません。 - 別に、状態ディレクトリ配下の
eval/<id>.jsonに記録を書きます。内容はエンジン情報、3 つの指数、各試行のプロファイルと状態です。
スクリプト冒頭のコメントによると、タスクのワークスペースで基盤の評価ハーネスから次のように実行されます。
node examples/pai-workbench/eval/run.mjs --command "node --env-file=<wb>/.state/demo.env --import tsx <wb>/scripts/eval-physics-solver.ts"<wb> は workbench のチェックアウト先です。run.mjs は本記事が依拠するファイルに含まれていないため、ホールドアウトデータをどう読み、3 つの指標をどう計算するかはここでは確認できません。スクリプト自体が生成するのは estimate.mjs と上の記録だけです。このコマンドには AgentForge のタスクディレクトリと利用可能なモデルプロファイルも必要ですが、提供された資料にはそれらのバージョンや導入手順が書かれていません。したがって workbench のコミットを固定しても、実行環境全体は固定されません。
保存された結果：3 つの指標と 3 つのベースライン
記録の確認時刻は 2026-10-03T17:35:00Z、エンジンは provider kiro、engineVersion 2.27.1、model claude-opus-5.5 です。modelEvidence フィールドは acp_advertised で、モデル名はエンジンが ACP で自己申告した識別情報であり、独立に確認されたモデルの来歴ではありません。モデルが答えた指数は t：-2.6、W：+1.2、H：+0.8 でした。
| 指標 | モデル | しきい値 |
|---|---|---|
| 中央値誤差（median） | 0.114 | 0.15 |
| 最大誤差（worst） | 0.321 | 0.35 |
| 順位相関（Spearman） | 0.95 | 0.9 |
| 判定（passed） | true | — |
記録にはしきい値の数値だけがあり、比較の向きは書かれていません。要件 F17 は同じ結果を「中央値誤差 11.4 %、最大 32.1 %、Spearman 0.95、合格」と記しています。誤差は小さいほど、順位相関は高いほど良いと読めば、3 項目ともしきい値の範囲内です。Spearman が見るのは推定値と実測値の順序が一致しているかだけで、値の差の大きさは見ません。
記録には性質の異なる 3 つのベースラインも並んでいます。
| ベースライン | t | W | H | 記録上の結果 | 読み方 |
|---|---|---|---|---|---|
| fixtureSolution | -2.5 | 0.7 | 0 | 中央値 0.011、最大 0.192、Spearman 1.0 | タスク付属の固定解で、新たなモデルの試行ではない |
| pureThinPlate | -3 | 0 | 0 | 中央値 0.145、最大 0.354、不合格 | 薄板の剛性が t³ に比例することだけで推定。中央値は 0.15 以内、最大は 0.35 を超える |
| leastSquaresOnHeldOut | -2.35 | 0.72 | -0.37 | スコアなし | ホールドアウトデータそのものへの当てはめ。上限であり、公正な比較相手ではない |
薄板ベースラインは基準の役割をよく示しています。「板の剛性は t³ に比例する」という教科書的な関係 1 つだけで中央値誤差はしきい値に近づきますが、最悪点が超えてしまい、不合格になります。最小二乗の行は評価が予測させる答えそのものを使っており、記録も上限にすぎないと明記しています。その指数はホールドアウトデータの傾向の要約としては使えますが、モデルとスコアを比べる対象にはなりません。
基準を満たしても、すべての傾向が正しいとは限らない
記録自身の読みはこうです。モデルは厚さと幅の傾向の向きを正しく捉えた（t^-2.6、W^+1.2 で実測への当てはめの +0.72 より大きい）が、高さの傾向は符号を誤った（+0.8、当てはめは -0.37）。ここでは、高い板と深いリブの組み合わせのほうが軸の位置で剛性が高いということです。記録の結論は「基準は満たしたが、決めるのは依然としてソルバーである」です。
モデルの理由（rationale）には、50 mm のレバーが 60 N を面で約 3 N·m のモーメントに変えること、固定の 31 mm ボルトパターン、板剛性 D が t³ に比例することなどが挙げられています。これらはブラケットに関するモデルの推論であり、本記事ではその数値を確認していません。記録も評価しているのは指数だけで、理由が正しいかどうかは評価していません。説明と確認可能な結果を分けて扱う点は、本サイトの モデルの説明を元のロボット録画と照合する：Robot Reel の review-claims で示せること で説明を not_assessed とする考え方と共通です。
高さの符号の影響を見るため、指数を使って手計算してみます。これは本サイトが式から行った仮定の計算であり、測定結果ではありません。1 回に 1 つのパラメーターだけを参照値の 1.2 倍にし、他は変えません。記録にはホールドアウト点のパラメーター範囲が示されていないため、1.2 倍がその範囲内にあるとは限りません。
| このパラメーターだけ 1.2 倍 | モデルの指数によるたわみの変化 | ホールドアウトへの当てはめ指数による変化 |
|---|---|---|
| 板厚 t | 1.2^-2.6 ≈ 0.62、約 -38 % | 1.2^-2.35 ≈ 0.65、約 -35 % |
| 幅 W | 1.2^1.2 ≈ 1.24、約 +24 % | 1.2^0.72 ≈ 1.14、約 +14 % |
| 板の高さ H | 1.2^0.8 ≈ 1.16、約 +16 % | 1.2^-0.37 ≈ 0.93、約 -7 % |
厚さでは両者が近く、幅では向きが同じで大きさが異なり、高さでは向きが逆です。3 つの集計指標だけを見ていると、この逆向きの傾向は表に出ません。記録には点ごとの誤差がないため、集計指標がなぜしきい値内に収まったのかについて、本記事は推測しません。こうした推定で設計の方向を選ぶ場合、たとえば板を高くしてたわみを減らそうとすると、モデルは誤った助言をすることになります。これは要件 F7 の流れと一致します。AI は推定付きのシードを出すだけで、最後はソルバーの実測と正式な再確認で決まります。
答えをエージェントの手の届かない場所に置く
評価に価値があるのは、評価される側が答えを見られない場合だけです。提供された資料から言えるのは次の点です。
- プロンプトにあるのはブラケットの説明と参照点 1 つだけで、ホールドアウトのソルバー結果は含まれていません。
- スクリプトはこの呼び出しのために、状態ディレクトリ配下に権限
0o700のeval/<id>ディレクトリを新たに作り、それを実行器に渡します。タスクのワークスペースは渡しません。実行中にエンジンが他のファイルを読めるかどうかは、提供された資料には書かれていません。 - モデルの出力は範囲の限られた 3 つの数値と理由だけで、実行可能な
estimate.mjsはスクリプトがテンプレートから生成します。 - スクリプト自体はスコアを計算しません。コメントによれば、基盤の評価ハーネスがタスクのワークスペースでこれを呼び出します。
以上を踏まえた本サイトの提案です（編集部の推奨であり、プロジェクト文書の規定ではありません）。ホールドアウトデータと採点コードはエージェントのワークスペースや読み取り可能なパスの外に置き、独立したハーネスに読ませること。エージェントには範囲が限られ検証可能なデータだけを返させ、実行するものは信頼できるテンプレートから生成すること。1 回の実行につき試行は 1 回とし、失敗も含めて各試行の状態を残すこと。最小二乗の行が示しているのも同じことで、推定する側がホールドアウトデータを見られるなら、その「スコア」は当てはまりの良さにすぎず、推論能力については何も語りません。
制約と注意点
- これは保存された開発時評価 1 回分で、試行も 1 回だけです。本サイトは再実行も独立した再現もしていません。時期やエンジンのバージョンが違えば、また同じモデルの別の回答でも、結果は変わりえます。
- モデル名はエンジンの自己申告（
acp_advertised）であり、モデルの来歴を独立に証明するものではありません。 - 採点コード
run.mjs、ホールドアウトデータとその点数、各パラメーターの範囲、誤差の正確な定義は、本記事が依拠するファイルにはありません。しきい値の向きの読み方は要件表の記述に基づいています。 - fixtureSolution はタスクの固定解で、新たなモデルの試行ではありません。leastSquaresOnHeldOut はホールドアウトデータそのものに当てはめたもので、上限にすぎません。
- この評価に合格しても、モデルが一般的な物理の理解を持つこと、確実に外挿できることは示されず、物理的な安全性とも関係しません。要件表は「シミュレーションを物理的な検証とみなすこと」を対象外としています。記録はホールドアウトデータを「実測」（measured）と呼んでいますが、どのソルバー、どの設定で得たものかは提供された資料に書かれておらず、本記事はこれを実物の測定による証拠とは扱いません。
- 実行器の「shared ledger」は提供された資料に名前が出てくるだけで、内容の説明はありません。本記事では推測しません。
