text-to-cad：エージェントにパラメトリックCAD能力を与えるスキル集

背景と課題の所在

機械設計は今も GUI に依存している。技術者は CAD ソフトでスケッチを描き、拘束を付け、押し出しを行い、STEP ファイルを加工現場へ渡す。言語モデルは Python を書き、仕様書を読むことができる。しかし、そのような GUI の操作手順をそのまま再現することは難しい。実務上の問いは明快である。エージェントが自然言語の要求や部品の写真を、別の人が確認、変更、製造できる三次元モデルに変換できるか。

text-to-cad は設計上の明確な選択でこの問いに答える。モデルはソースコードそのものである。部品は build123d で書かれた Python ファイルであり、build123d は OpenCascade カーネルの上で動く Python 製の CAD ライブラリである。ファイルを実行すると成果物が生まれる。主な出力は STEP ファイルで、ソースが設計意図の記録となる。形状は差分比較、レビュー、再生成が可能な対象になる。

難しいのは生成よりも検証である。モデルはビューアで正しく見えても、穴の位置が違うことがある。そのためリポジトリは、測定、スナップショットによるレビュー、検証を独立したスキルとして扱っている。

コアアーキテクチャと技術原理

text-to-cad は単一のプログラムではなく、エージェント用スキルのライブラリである。CAD、step.parts、工学図面、DXF、URDF、SRDF、SDF、SendCutSend、DfAM チェック、DFM、G コード、Bambu Labs の 12 のスキルを含む。中心は CAD スキルで、ほかのスキルの多くはその出力を利用するか、同じ部品を別のツール向けに記述する。 バージョンは明示的に固定されている。スキルの requirements.txt は cadgen[snapshot] を 0.7.11 に固定する。README のバッジは build123d 0.11、Open CASCADE 7.9、Python 3.11 以上、Node.js 20 以上を示す。つまりエージェントは特定のカーネルと実行環境に依存する。固定によってチームは公開済みのリリースを再現できる。その代わり、アップグレードは手作業になる。

技術スタックは三層で捉えると分かりやすい。最上層では、エージェントが SKILL.md を読み、作業ごとに短い参照文書へ進む。中間層では、cadgen のコマンドラインツールと MCP サーバーが実行を担う。MCP サーバーは uvx で起動するため、初回実行時にランタイムがダウンロードされる。最下層では OCP バインディングが OpenCascade を Python に公開し、形状演算と STEP の読み書きを行う。 設計原則は、ソースファイルこそが真実であるという考え方である。SKILL.md は、書き出されたファイルを修正するのではなく、モデルのソースを編集して python で再実行するよう指示する。したがって変更は Python ファイルの差分として現れ、メッシュや STEP は派生した結果にすぎない。これはコードをレビュー可能にする考え方と同じであり、バージョン管理とも良く噛み合う。 配布も同じ論理に従う。Codex、Claude Code、Cursor、Grok Build 向けのプラグインがあり、スキルは npx skills add で導入できる。ホストごとにモデルの表示方法は異なるが、いずれも同じ cadgen パッケージを呼び出す。

実用性と検証結果

私はこのツールを導入せず、モデルも生成していない。本節の内容は、リポジトリの文書、設定、ディレクトリ構成から読み取ったものである。ここで述べるのは出力の測定結果ではなく、設計の読解である。 CAD スキルは四つの機能を挙げている。装飾された Python モデルから部品や組立体を作成・編集する。メッシュ用デコレータか単発の build コマンドで STL、3MF、GLB を書き出す。read_scene と scene.resolve により、保存済み STEP 文書の名前付き参照を解決する。Chromium を使い、外観と動きを確認するためのスナップショットを描画する。実務では四つすべてを使う流れが妥当である。モデルを生成し、書き出し、build123d のネイティブスクリプトで寸法を確認し、リリース前にスナップショットを見る。

文書には、本番利用で重要となる警告が二つある。第一に、バージョン移行が必要なモデルを移行しないままにすると、運動学、材料、アニメーションが静かに失われる。クラッシュより静かな損失の方が危険なので、チームは移行をパイプラインの明示的な工程にすべきである。第二に、Windows 11 でスマート アプリ コントロールが有効だと、署名のない OCP のホイールがブロックされ、DLL エラーでインポートが失敗する。リポジトリの回答は、この機能を無効にするか WSL で実行することである。Windows のみの環境を使うチームは、展開前に必ず試験すべきである。 導入時の実務上の注意がもう二つある。分析機能は利用者が許可するまで無効であり、DO_NOT_TRACK 変数でも無効にできる。プラグインからの導入では、初回起動時に uv を通じてローカルランタイムをダウンロードする。どちらも欠陥ではないが、組織のインストール手順には含めておくべきである。

業界への影響と今後の展望

このプロジェクトは完成品というより方向性を示している。CAD は、コード、テスト、バージョン管理によって制約できる工学資産になりつつある。すでに Python を書いている小規模なハードウェアチーム、ロボティクスのグループ、メイカーにとって、パラメトリック設計の敷居は下がる。 責任の所在も移る。モデル生成器がもっともらしい寸法を出すようになると、リスクは部品を描いた人から、それを検査する工程へ移る。この方法を採用するチームは、製造前に測定のゲートを設けるべきである。DFM、DfAM チェック、SendCutSend のスキルは、形状を信頼するのではなく製造ルールに照らして検査するという方向を示している。

ロボット記述のスキルは、フォーマット間の整合性という第二の問いを生む。URDF、SRDF、SDF は、異なる利用者のために同じロボットを記述する。CAD の形状、関節の制限、シミュレータのモデルを継続して一致させることは、未解決の工学課題である。一つのスキルライブラリにまとめた構成は妥当だが、整合性の確認は利用者の仕事として残る。 本スナップショット時点でスターは 16,697 個あり、関心の高さは明らかである。ただし関心は検証ではない。有用な証拠は、実プロジェクトにおける手戻り率、検査の合格率、納期の実測値である。本稿にはそのデータはない。読者はこのプロジェクトを、試す価値のある有望なインターフェースとして扱うべきであり、CAD ワークステーションを置き換える実証済みの手段とみなすべきではない。