ベンチマーク：エージェントによるCAD作業におけるCadQuery対OpenSCAD

ModelRiftはプラットフォーム上のすべてのモデルに対してOpenSCADを生成します。その選択は時々再テストする価値があるため、コードファーストCADの最も信頼できる代替手段であるCadQuery（OpenCascade B-repカーネル上のPythonライブラリ）との比較テストを実施しました。質問は狭いものでした。「誰も見ていない状態で、AIエージェントが正確で印刷可能で機能的な部品を生成するために、どちらのツールを駆動できるか？」手書きでどれだけ快適かは考慮しませんでした。6つのエージェント、3つのタスク、2つのツール。結果として生成されたすべてのSTLは、どちらのツールも信頼しないパーサーによってチェックされました。6つの部品すべてが印刷可能でした。能力は、回答の退屈な部分であることが判明しました。両者が分岐するのは、失敗の仕方です。最も難しいタスクは、両方のツールで解決されました。左がOpenSCAD、右がCadQueryです。 セットアップ すべての6回の実行は、Claude Opus 5（1Mコンテキスト）を介してClaude Codeによって駆動されました。各セルは、同じモデルを継承した個別の汎用サブエージェントとして実行され、それらの間にはクロス・トークはありませんでした。セルごとに1つのエージェントなので、以下のスプレッドの一部はツール間の違いではなく、エージェントのばらつきです。ツールバージョンは、Python 3.14上のCadQuery 2.8.0と、MシリーズMac上のOpenSCAD 2026.06.12でした。OpenSCAD側は、私たちが公開し社内で使用しているエージェントスキルであるopenscad-skill上で実行されました。これは、ファイルとバージョンの命名、レンダリング・検査・修正のQAループ、CLIプレビュー用のカメラプリセット、断面デバッグ、およびCustomizer構文をカバーしています。CadQueryについては、そのスキルを操作ごとに移植し、同じ構造を維持し、OpenSCADに相当するものがないものだけを置き換えました。CadQueryにはCLIレンダラーがないため、移植には小さなオフスクリーンレンダラーが必要であり、CSGステータスラインの代わりにB-rep妥当性メトリクスが導入されました。両方のファイルには同じ3Dプリンティング設計ルール、壁厚、クリアランス、オーバーハングが適用されたため、どちらの側も相手が持っていないアドバイスを与えられることはありませんでした。ファイルサイズは、OpenSCADが12.4 KB、CadQueryが13.1 KBでした。1つの非対称性が残りました。CadQueryファイルにはAPIチートシートが含まれていますが、モデルはすでにOpenSCAD構文をよく知っているため、OpenSCADファイルには必要ありません。これは構文面でCadQueryに役立ちますが、ジオメトリ面では何も影響しません。各エージェントは12バージョンに制限され、成功を偽造しないように指示され、すべての失敗を正確なエラーテキストとともに報告することが義務付けられました。それらは無人で実行されました。私たちはエージェントの言葉を鵜呑みにしませんでした。最終的なSTLはすべて、ファイルから直接読み取り、三角形数、バウンディングボックス、体積、水密性、非多様体エッジ、境界エッジ、反転した面、接続されたコンポーネントを報告するパーサーを通過しました。これは、後述の理由により、私たちが予想していたよりも重要であることが判明しました。 3つのタスク タスクごとに両方のエージェントは、ツール固有のヒントなしで同じテキストを受け取りました。簡単なタスクT1は、壁に取り付ける棚のL字型ブラケットでした。90度のプレート2枚、厚さ4mm、三角形のガセット2つ、フラットヘッドネジ用の皿穴（90度、ヘッド直径9mm）2つ、プレーン穴2つ、外側の垂直コーナーにR3、内側のコーナーにフィレットR4、サポートなしで印刷可能。 T2は、50 x 26 mmのPCB用の2ピースのスナップフィットエンクロージャーに難易度を上げました。壁厚2mm、片側クリアランス0.4mm、M2ポスト4本、USB-C cutout 9.5 x 3.5 mm、周囲にクリアランス0.2mmのリップと機能するスナップを備えた別個の蓋、5つのベントスロット。2つの部品は実際にフィットする必要があります。T3は難しいタスクでした。六角フランジ（フラットで30mm）、実際のヘリカルスレッド（長さ12mm）、3つのバーブ（ID 12mmホース用）を備えた25mm長のバーブ、および8mmのスルーチャンネルを備えたM24x2ねじ込みホースバーブアダプター。仕様では、積み重ねられたリングは明確に禁止されていました。スレッドは真のヘリカルジオメトリである必要がありました。 結果 T1 OpenSCAD T1 CadQuery T1 T2 OpenSCAD T2 CadQuery T2 T3 OpenSCAD T3 CadQuery T3 バージョン 2 3 8 5 1 3 コード行数 103 135 220 266 150 172 ツールが生成したエラー 14 0 0 1 11 0 サイレントに間違ったジオメトリ 0 0 5 3 0 1 エージェントの壁時計 461 s 562 s 1058 s 909 s 542 s 935 s エージェントのトークン 77 k 89 k 138 k 139 k 82 k 119 k ジオメトリ再計算 12 ms 1.56 s 16 ms 1.93 s 43 ms 1.95 s 最終STL判定 クリーン クリーン クリーン クリーン クリーン クリーン 3つのタスク全体で合計: OpenSCAD: 11 バージョン, 473 行のコード, 25 エラー, 5件のサイレントに間違ったジオメトリ, 2061秒の壁時計時間, 297kトークン CadQuery: 11 バージョン, 573 行のコード, 4 エラー, 4件のサイレントに間違ったジオメトリ, 2406秒の壁時計時間, 347kトークン 「クリーン」とは、水密性、単一の接続コンポーネント、非多様体エッジまたは境界エッジゼロ、z=0上に配置され、書き込んだツールによって報告されたものではなく、ファイルから測定されたことを意味します。イテレーション数は、それぞれ11バージョンで同一でした。努力の広範な形状も同様でした。違いは、各エージェントが遭遇した問題の性質です。 T1: 簡単なブラケット 両方とも正しく、内側のコーナーから表示されており、ガセットが見えています。目に見える違いは解釈です。仕様ではガセットのサイズとインセットは開いたままになっていました。4つの外側のコーナーを丸めることで、2つの世界のモデルが明確に分離されます。OpenSCADは2Dプロファイルを押し出して、操作はソリッドがどのように組み立てられたかを気にしません。CadQueryは最初に4つのエッジに名前を付ける必要があり、名前付けが難しい部分です。OpenSCADは最初の試行で正しいジオメトリをコンパイルし、2バージョンで完了しました。CadQueryは、実行時間の約3分の1を単一のエラーに費やしました。.fillet(3.0)がBRep_API: command not doneで失敗しました。このメッセージは、エッジも半径も特定しませんでした。エージェントは手動で二分して原因を発見する必要があり、それは算術演算であることが判明しました。2つのR3フィレットは、厚さ4mmの壁に収まりません。 T2: フィットする必要がある2つの部品 両方のエージェントは、クリアランスの積み重ねから同じ54.8 x 30.8 x 25.0 mmのボックスを導き出しました。ここでCadQueryのパラメータチェーンがその価値を発揮しました。リップの深さを変更すると、リム、プレート、スロット、溝、バーブがすべて一緒に移動しました。なぜなら、各寸法はタイプミスではなく派生されたものだからです。このような寸法チェーンは、優れたパラメトリックUIがユーザーに公開するものと同じであり、私たちは「Building a better OpenSCAD customizer」でそれについて書きました。CadQueryにはCustomizerに相当するものがないため、定数ブロックが唯一のパラメータインターフェースです。より興味深いのは、各側がフィットをどのようにチェックしたかです。OpenSCADは、人が読むための数値を印刷します。CadQueryはアサートし、アサートが偽の場合、ビルドは停止します。 unattended generationでは、そのギャップが物語の大部分を占めます。OpenSCADは8バージョンを必要としたのに対し、CadQueryは5バージョンで済みました。そしてその8バージョンのうち3つは、設計ではなくブーリアン衛生（接線面や共面からのスリバーのクリーニング）に使われました。 T3: 本物のスレッド 難しいタスクは最大の波乱を引き起こしました。OpenSCADは1バージョンで完了し、最初のコンパイルで正しく、43ミリ秒で、ライブラリなしでした。OpenSCADにはスイープ操作がないため、エージェントはヘリックスを生の頂点と面の算術演算として記述しました。1つの4点ISOプロファイル、1回転あたり96セクション、単一のポリヘドロンとして出力されます。このコードには一切のガードレールがありません。巻き順を間違えると、ツールは何も言いません。エージェントは、コードを一行書く前に、古典的なスレッドの罠を先回りしました。ISO歯は正確に1ピッチを占めるため、連続するルートフラットは共面になり、和集合が悪くなります。それはスイープを沈めました。