AIエージェントのCAD自動化にtext-to-cadが選ばれる理由

コーディングエージェントに実装を任せる流れが定着した一方で、機械設計の領域はなかなか同じようにいきません。LLM が出力できるのはテキストであり、設計の成果物として求められるのは寸法・公差・製造性を伴った STEP ファイル、つまり B-rep（境界表現）のソリッドモデルです。この隔たりがあるため、「エージェントに部品を設計させる」という発想は、実装支援に比べて一歩踏み出しにくい状態が続いてきました。

さらに厄介なのが、調べ始めた時点で名前が衝突している点です。「text-to-cad」という語で検索すると、GitHub 上の OSS と、Zoo（旧 KittyCAD）が提供する ML ベースの生成機能「Text-to-CAD」が混ざって出てきます。両者は名前が同じだけで、アプローチも評価軸もまったく異なります。どちらの話をしているのか分からないまま情報を集めると、採用判断の土台が崩れてしまいます。

この記事で扱う earthtojake/text-to-cad は、ML モデルが形状を直接生成する仕組みではありません。エージェントに build123d という Python の CAD ライブラリでモデルのコードを書かせ、その実行結果として STEP を得るという方式を取る、エージェント用スキル集です。成果物が Python ソースとして残るため、差分管理や再生成が効くという性質を持ちます。

AI CAD OSS と呼ばれる領域には、形状生成モデルから CAD ライブラリまで性格の異なるプロジェクトが並んでいます。本記事ではその中の 1 つである text-to-cad を対象に、公開ドキュメント（README / 各スキルの SKILL.md / 公式サイト）と GitHub 上の実測メタ情報に基づき、仕組み・12 種のスキル構成・類似 OSS との違い・採用前に確認したい制約を整理します。なお本記事はドキュメントベースの調査であり、インストールや動作検証は行っていません。生成されるモデルの精度や製造適合性といった実測が必要な評価には踏み込まず、「検討を先に進めるかどうかを判断するための材料」に焦点を絞ります。

AIエージェントのCAD自動化が難しい理由

テキスト生成と機械設計成果物のギャップ

ソフトウェア開発では、エージェントが出力するテキスト（ソースコード）がそのまま成果物になります。一方、機械設計で下流工程に渡すものは、加工業者が読む STEP ファイルや寸法入りの製作図です。これらは単なる見た目の形状データではなく、面・稜線・頂点の位相関係を保持した B-rep であり、寸法には「なぜその値なのか」という根拠が伴います。

LLM に「ブラケットを作って」と頼んでも、STEP の中身を直接書き起こさせるのは現実的ではありません。STEP は人が読み書きする形式ではなく、わずかな記述の破綻でも位相的に不正なソリッドになります。ここが、エージェント × CAD というテーマの出発点にある難しさです。

エージェント × CADの3つのアプローチ

この隔たりを埋める方法は、大きく 3 系統に分かれます。本記事ではこの 3 系統を比較軸として使います。

1. 形状生成型: ML モデルが B-rep を直接生成します。プロンプトから形状が返ってくる体験に近い方式です
2. GUI 遠隔操作型: FreeCAD や Blender といった既存アプリを MCP 経由で遠隔操作し、アプリの機能でモデルを組みます
3. コード生成型: エージェントにパラメトリック CAD の Python コードを書かせ、それを実行して形状を得ます

text-to-cad は 3 番目のコード生成型に位置します。どの系統が優れているかという話ではなく、「成果物をどこに残したいか」「既存のワークフローをどこまで変えられるか」で適合が変わります。この前提を共有したうえで、以下では text-to-cad の中身を見ていきます。

text-to-cadとは｜エージェントにCADを任せる12スキルのOSS

「スキル集」であることの意味

README は text-to-cad を次のように定義しています。「text-to-cad is a library of agent skills for generating, inspecting, sourcing, slicing, and handing off CAD and robot-description artifacts from local project files.」（earthtojake/text-to-cad README）

ここで押さえておきたいのは、対象が ローカルのプロジェクトファイルである点です。クラウドにプロンプトを投げて形状を受け取る生成 API ではなく、手元のリポジトリにあるモデルソースと出力フォルダを前提に、エージェントが読むべきワークフロー定義（スキル）を束ねたものという位置づけになります。公式サイトも「Give your agent CAD superpowers. 100% open source and free.」という一文を掲げています（text-to-cad 公式サイト）。

つまり text-to-cad 自体は、モデルでもサービスでもありません。エージェントに「CAD プロジェクトをどう扱うか」の規律を与えるドキュメント群と、それを支える Python パッケージ cadgen の組み合わせです。

リポジトリの基本情報

GitHub API で取得したリポジトリの実測値は以下のとおりです。

アーカイブ済みリポジトリやフォーク版を誤って評価してしまうケースがありますが、このリポジトリは archived=false / fork=false、つまりアーカイブされていない本家リポジトリです。ライセンスも MIT が明示されており、未設定ではありません。

数値の読み方として補足すると、スター 16,626 という規模に対し、公開日は 2026 年 4 月 22 日です。履歴がまだ約 5 か月しかない点は、採用判断の際に規模の数字とセットで見ておきたい事実です。この点はのちほど制約の整理であらためて触れます。

Zooの「Text-to-CAD」とは別物（同名混同の整理）

冒頭でも触れたとおり、「Text-to-CAD」という語は Zoo（旧 KittyCAD）の機能名としても流通しています。Zoo は独自言語 KCL と自社ジオメトリエンジンを持つ CAD アプリケーションを提供しており、その中の Text-to-CAD は ML モデルが B-rep を直接生成する仕組みです（Zoo Design Studio ドキュメント）。

一方の earthtojake/text-to-cad には、形状を生成する ML モデルは含まれていません。エージェントが Python のモデルコードを書き、それを実行して形状を得ます。前述の 3 系統で言えば、Zoo が形状生成型、text-to-cad がコード生成型です。検索結果でこの 2 つが混ざっていた場合は、まず「ML が形状を出すのか、エージェントがコードを書くのか」で切り分けると見分けがつきます。機能面の詳しい差分は、のちほどの比較で整理します。

text-to-cadの仕組み｜build123dとOpen CASCADEでSTEPを生成する流れ

ここが text-to-cad の中核です。README のバッジで明示されている技術基盤は、Python パッケージ cadgen、CAD ライブラリ build123d 0.11、CAD カーネル Open CASCADE 7.9（Python バインディング OCP）、Python 3.11 以上、Node.js 20 以上という構成です。CAD の演算そのものは Open CASCADE が担い、その上の Python API として build123d が使われ、エージェント向けの規約と CLI を cadgen が提供するという階層になります。

モデルは「デコレータ付きのPythonスクリプト」

CAD スキルの定義（SKILL.md）では、モデルを「引数を取らないデコレータ付き関数が build123d の形状を返す、素の Python スクリプト」と規定しています。スクリプト名と宣言する出力ファイル名のステムを揃える、という命名の約束もあります。SKILL.md に掲載されている最小例は次のとおりです。

from cadgen import build123d as bd
from cadgen import step

WIDTH = 40.0


@step(out="../STEP/bracket.step")
def bracket():
    body = bd.Box(WIDTH, 20, 6)
    body.label = "bracket"
    return body


if __name__ == "__main__":
    bracket()

python src/bracket.py

（出典: skills/cad/SKILL.md）

@step(out=...) というデコレータが「このモデルはどこに STEP を書き出すか」を宣言し、スクリプトを実行すると出力が再生成されます。STL / 3MF / GLB が必要な場合は @stl / @threemf / @glb をスタックして宣言するか、cadgen stl build STEP/bracket.step STL/bracket.stl のような単発のコマンドで変換します。

この形式の意味は、成果物の二重性にあります。STEP は生成物であり、真の原本は Python ソースです。寸法を変えたければ WIDTH を書き換えて再実行すればよく、変更履歴は通常のコードレビューと同じ土俵に乗ります。エージェントが編集する対象がテキストに収まっている、という点が設計の要です。

参照構文とビューワからの差分指示

設計作業では「この面を 2mm 深くしたい」のような、既存形状の一部を指した指示が頻発します。text-to-cad はこれを参照構文で扱います。SKILL.md によると、STEP/assembly.step#o1.2.f7 のような参照は「ある特定の保存済みドキュメント内のジオメトリ」を指し示します。解決の手順は次のコードで示されています。

from cadgen import read_scene

scene = read_scene("STEP/assembly.step")
selection = scene.resolve("STEP/assembly.step#o1.2.f7")
face = selection.shape()  # owned native geometry, in document world coordinates
print(selection.ref, face.area)

（出典: skills/cad/SKILL.md）

read_scene で保存済みドキュメントを開き、scene.resolve() で参照を解決すると、ドキュメントのワールド座標系におけるネイティブジオメトリが得られます。面積などの測定もそのまま行えるため、「指示された面がどこなのか」をエージェントが曖昧さなく特定できる構造になっています。

付属の CAD Viewer の Quick Edit は、この参照構文を前提にしたメモを返します。SKILL.md の記述では、メモは「要望」に加えて File:（対象ドキュメント）、References:（1 行 1 参照）、ビュー上に描き込みがあれば Sketch: <path>（マークアップ入り PNG）という形式を取り、スキル側には「モデルを変更する前にスケッチを見ること」が指示されています。GUI 上の選択を、エージェントが読めるテキストの指示に変換する導線だと捉えられます。

注意点として、数値参照は「その保存リビジョン」に属するものとされています。モデルをリビルドした後は再度開いて選択し直す必要があり、曖昧なファイルやラベルの間で推測してはならない旨も明記されています。

再現性と検証を縛るルール

エージェントに設計を任せるとき、最も気になるのは「静かに壊れた成果物が出てこないか」という点でしょう。SKILL.md はこれに対して、かなり踏み込んだ規律を課しています。公開ドキュメント上で確認できる主なものを挙げます。

• 単位と姿勢の既定: 単位はミリメートル、XY 平面と +Z を既定とし、タスクやプロジェクトで別の慣習が指定されない限りこれに従います。物理部品は閉じた正体積のソリッドを優先します
• 再現性の確保: ジオメトリを追跡されない時刻・乱数・環境変数・作業ディレクトリに依存させてはならないと規定されています。ビルドが開くファイルはすべて入力として扱います
• 出力の自己参照禁止: モデルが自身の出力を自身の入力として読むことは禁じられています
• 仮定の記録: 寸法やインタフェースが不明な場合は、モデル化と検証に必要な仮定を記録します。結果に実質的な影響がある場合は、不足情報について確認を求めます
• 検証と引き渡し: STEP 出力は read_scene または read_step で保存済みアーティファクトを検査します。単位・閾値・選択ジオメトリ・未検証の要件は報告が求められます。そして「A failed computation is not a pass.（計算が失敗したことは合格ではない）」と明記されています
• 失敗時の手順: エラーの診断には Repair loop とバージョン移行のリファレンスを読みます

探索的なチェックはプロジェクトの tmp/、再利用するチェックは checks/ に置き、モデルソースや生出力のフォルダの外に保つことも指示されています。さらに 2D DXF は $dxf スキル、ロボット記述は URDF / SRDF / SDF の各スキルに委譲する、という責務分離も明示されています。

これらは「エージェントが暴走しないための仕組み」ではなく、「設計の成果物を検証可能な状態に保つための規約」として読むのが適切です。採用を検討する際は、この規約が自チームの設計プロセスと矛盾しないかが判断材料になります。

12スキルの役割分担｜CADから図面・DFM・G-codeまで

README のスキル表には 12 種のスキルが並びます（公式サイトのスキル一覧）。羅列すると多く見えますが、設計・ロボティクス・製造の 3 グループに分けると役割分担が把握しやすくなります。

設計系スキル

中心にあるのは CAD スキルで、ここが 3D 部品を所有します。図面と DXF は CAD が作った形状を下流に渡すための変換・出力に位置し、step.parts は「自分で作らずに既製品を探す」ための検索です。SKILL.md が「名前のついた購入可能な部品が必要なときは、プレースホルダを作る前に $step-parts を検索すること」と指示しているとおり、存在する部品を再発明しない導線が組まれています。

ロボティクス系スキル

ロボット記述ファイルは、形状そのものよりも「リンク構造・関節のリミット・慣性」といった記述の正しさが問われる領域です。これを CAD スキルとは別のスキルに分けることで、エージェントが読むリファレンスを必要な分だけに絞る設計になっています。CAD の SKILL.md にも、URDF / SRDF / SDF は対応するスキルを使う旨が明記されています。

製造・出力系スキル

このグループの存在が、text-to-cad の輪郭を特徴づけています。設計で終わらず、製造前の検査（DFM / DfAM Check / SendCutSend）からスライス、プリンタへの送信までが同じスキル集の中に含まれています。とくに DFM について README が「measured evidence and the cited rule behind every finding」と書いている点は、レビュー結果の扱い方として注目に値します。測定値と引用ルールを伴う指摘は、人がレビューする際に追検証できるためです。

自プロジェクトに必要なスキルを見極めるには、このグループ分けを使うのが実務的です。設計データの生成だけで足りるのか、図面 PDF まで必要か、製造前検査やスライスまで同じ土台で回したいのか、ロボット記述も扱うのか。必要な範囲に対して過不足がないかが、採用判断のひとつの軸になります。

導入方法の選択肢｜Skills CLIとプロバイダ別プラグイン

導入経路は Skills CLI とプロバイダ別プラグインの 2 系統があります（公式サイトのインストール案内 / プラグイン一覧）。以下は README の記述を整理したもので、実行結果の報告ではありません。

Skills CLIでの導入と更新

README が推奨経路として挙げているのは Skills CLI です。

npx skills add earthtojake/text-to-cad

（出典: earthtojake/text-to-cad README）

ここで見落としやすいのが、更新も同じ add を使うという点です。README は「Use the same command to update.」と太字で書き、その理由を明示しています。add はパッケージを再取得して既存のインストールを上書きするため、既存スキルの更新と新リリースで追加されたスキルのインストールを同時に行います。一方 npx skills update はロックファイルにすでにあるスキルだけを更新するため、新しいスキルを静かに取りこぼします。リリースでスキルが追加される前提のリポジトリであるため、この差は無視できません。

もう 1 点、どちらのコマンドも上流で退役したスキルを削除しません。不要になったものは npx skills remove <skill> で明示的に外す必要があります。README の例では、退役した cad-viewer スキルは CAD / DXF / ロボット記述の各スキルに統合されており、古い単独インストールは削除するよう案内されています。

インストール元については、README は main ブランチからのインストールまたはクローンを案内しており、各スキルの requirements.txt が公開時点の cadgen リリースを pin していると説明しています。フィクスチャ集である models/ はスキルの利用には不要とされています。

プロバイダ別プラグインとCAD Viewer

Codex / Claude Code / Cursor / Grok Build には、プロバイダ固有のプラグインインストールが用意されています。README によると、いずれも main からインストールされ、リポジトリのルートに各ホストのマニフェストが置かれています。運用上の注意点として押さえておきたいのは次の点です。

• Codex はバージョン条件がある: リポジトリルートのプラグインを解決できるのは Codex 0.142.0 以降です。それより古いバージョンではプラグインが静かにスキップされ、codex plugin list にも現れません。また、マーケットプレイス名が text-to-cad から earthtojake に改称されているため、以前に追加していた場合は古いものを削除する必要があります
• Cursor はクローン配置: ~/.cursor/plugins/local/text-to-cad にクローンし、.cursor-plugin/plugin.json が読まれます。更新はそのフォルダで git pull を行います
• Grok Build は Claude のマニフェストを読む: Grok 専用のプラグインマニフェストは存在しません
• uv が前提になる: プラグイン経由では CAD Viewer が付属し、これは uv を通じてローカルで動作します。uv のインストールが必須で、プラグイン導入後に初回起動で pin されたランタイムがダウンロードされる旨が説明されています

Claude Desktop については、プラグインではなく MCP サーバーとして設定する形になります。README は設定例として次の JSON を掲載しています。

{
  "mcpServers": {
    "cad": { "command": "uvx", "args": ["--no-config", "--from", "cadgen==0.7.11", "cadgen", "mcp"] }
  }
}

（出典: earthtojake/text-to-cad README）

この設定例では cadgen==0.7.11 が pin されています。README は、uvx が最初にダウンロードしたバージョンを保持するため、更新する際は設定を最新リリースに書き換えてアプリを再起動する必要があると説明しています。uvx が見つからない場合はフルパス（which uvx の結果）を指定する、という案内もあります。ここは一度設定したら放置されやすい箇所なので、更新運用を決めておく価値があります。

ビューワの見え方はホストごとに異なります。Codex アプリではサイドバーの CAD とスレッド横の CAD タブ、Claude Code ではアプリビューを表示できる環境では会話内のビューワーカード、ターミナルではブラウザで開くリンク、Claude Desktop ではチャット内のビューワーカードという形が README に記載されています。

類似OSSとの違い｜Zoo・FreeCAD MCP・build123dとの比較

ここからが選定の本題です。以下の比較表のスター数・ライセンス・最終更新は、GitHub API で取得した実測値です。

観点別に並べると、性格の違いがより明確になります。

ML生成型（Zoo）との違い

KittyCAD/modeling-app は Zoo Design Studio の本体で、独自言語 KCL と自社ジオメトリエンジン、アプリ内蔵のエージェントを備えた CAD アプリケーションです（Zoo Design Studio ドキュメント）。同社の Text-to-CAD は ML モデルが B-rep を直接生成する機能であり、「プロンプトから形状が返る」という体験の中心にあります。

text-to-cad にはこの ML 生成モデルがありません。したがって、「自然言語から形状そのものを生成させたい」という要件に対しては、評価対象が Zoo 側になります。逆に「生成されたコードを人がレビューし、パラメータを調整しながら設計を進めたい」のであれば、Python ソースが原本として残る text-to-cad のほうが前提に合います。名前が同じであるために同一カテゴリとして比較されがちですが、実質的には別の問いに答えるツールだと捉えるのが実態に近いです。

GUI遠隔操作型（FreeCAD MCP / Blender MCP）との違い

neka-nat/freecad-mcp は FreeCAD の MCP サーバーで、Claude Desktop などから FreeCAD の Python API を操作します。ahujasid/mcp-for-blender（旧 blender-mcp）は Blender を同様に操作するコミュニティプラグインです。

この方式の性質は、既存アプリの能力をそのまま使える点にあります。すでに FreeCAD や Blender を中心に業務が回っているなら、ワークフローを変えずにエージェント操作を足せます。一方で、アプリの常駐が前提になり、成果物はアプリ内ドキュメントの状態に依存します。

text-to-cad はアプリ非依存で、成果物は Python ソースと出力ファイル（STEP / STL / DXF など）です。GUI を前提にしないため既存の操作習慣は活かせませんが、CI での再生成やコードレビューといったソフトウェア開発の作法を持ち込みやすくなります。なお Blender MCP はメッシュ・クリエイティブ 3D 寄りの領域を対象とするため、B-rep と製造工程を扱う text-to-cad とは守備範囲自体が異なります。

CADライブラリ単体（build123d / CadQuery）との違い

gumyr/build123d は、text-to-cad が内部で使っている Python の CAD プログラミングライブラリです。つまり競合ではなく基盤であり、README のバッジでも 0.11 が明示されています。CadQuery/cadquery は同じ Open CASCADE 系の Python パラメトリック CAD フレームワークで、こちらは人が書く前提で設計されています。

「build123d を直接使えばエージェントにコードを書かせられるのではないか」という疑問は自然です。書かせること自体は可能です。差があるのは、スキル定義・参照構文・検証規律・CLI といった周辺の整備です。先ほど見たように、単位と姿勢の既定、再現性のための依存禁止事項、保存済みアーティファクトの検査、仮定の記録といった規約が SKILL.md として与えられています。この規約が不要（あるいは自チームで既に確立している）なら、ライブラリ単体のほうが構成は単純になります。逆にゼロから規約を整備するコストを避けたいなら、text-to-cad はその部分を肩代わりする存在だと位置づけられます。

ライセンスの違いにも触れておきます。text-to-cad 本体は MIT ですが、基盤の build123d は Apache-2.0、CadQuery は GitHub 上のライセンス判定が NOASSERTION です。依存関係のライセンスは個別に確認する必要があります。

採用前に確認したいtext-to-cadの制約

ここでは「後から気づくと痛い順」で、公開ドキュメントに記載されている制約を整理します。

実行環境の前提

もっとも影響が大きいのは Windows 11 の Smart App Control です。README の説明によると、cad / dxf / urdf / srdf / sdf の各スキルが依存する CAD カーネルは Open CASCADE の Python バインディング OCP であり、その wheel には署名されていないネイティブモジュールが含まれます。Windows 11 の Smart App Control は未署名のネイティブコードをブロックするため、これが有効な環境（新規インストール時の既定）では、すべての cadgen コマンドと import build123d が ImportError: DLL load failed while importing OCP で失敗します。イベントビューアには CodeIntegrity › Operational の Event ID 3077 として記録されます。

回避策は Smart App Control を無効化するか、WSL 上で CAD スキルを実行するかの二択です。Smart App Control にはアプリ単位の例外が存在せず、一度無効にすると Windows を再インストールしない限り再度有効にできない旨も README に明記されています。さらに、この wheel は cadquery-ocp プロジェクトがビルドしているため、署名は text-to-cad 側で対処できる範囲ではないと説明されています。Windows 環境が主戦場のチームでは、この 1 点が採用可否を左右し得ます。

診断については、cadgen doctor <skill-dir> がスキルのパッケージ pin と CAD カーネルの状態を確認し、Smart App Control によるブロックを検出した場合はその旨を示すとされています。インストールや OCP のロードエラーに遭遇したときの最初の確認先になります。

実行環境の前提として README のバッジが示しているのは Python 3.11 以上と Node.js 20 以上です。加えて、プラグイン経由で CAD Viewer を使う場合は uv が必須になります。CAD スキルの SKILL.md では、スナップショット機能に Chromium が必要であることも示されています。

ライセンスと依存の外部性

text-to-cad 自体のライセンスは MIT です。一方で、形状演算を担う build123d は Apache-2.0、その下の Open CASCADE は別プロジェクトであり、OCP の wheel も先述のとおり cadquery-ocp プロジェクトのビルド成果物です。

ここから読み取れるのは、CAD カーネル側の問題（ビルド・署名・バージョン互換）は text-to-cad の管理範囲外になるという構造です。上流で変更が入れば影響を受けますし、上流に起因する問題は本リポジトリでは解決できません。これは欠陥ではなく、CAD ライブラリを使う以上は避けられない依存の形ですが、「どこまでが本リポジトリの責任範囲か」を把握しておくと、トラブル時の切り分けが速くなります。

プライバシーとテレメトリの扱い

匿名の利用統計について、README は送信内容と制御方法を具体的に記載しています。CAD アプリ（プラグインの cad サーバー）とブラウザビューワ（cadgen viewer）は、ランダムなインストール ID、各種バージョン、OS とエージェントアプリ、各 CAD ツールの呼び出し回数とビューの利用頻度、表示した各ファイルの一方向コードとフォーマット（ファイル数を数えるためで、識別のためではない）を送信し得るとされています。サーバー側では各リクエストの IP アドレスから国別のインストール数を週次・月次の合計としてのみ集計するとされています。

重要なのは、ファイル名・パス・内容・プロンプトは送信しないと明記されている点、そして 既定ではオフで、どちらかのアプリの初回プロンプトで許可するまで送信されない（オプトイン）という点です。後から変更する場合は、各アプリの設定の「Share anonymous usage data」、uvx cadgen analytics on|off、またはエージェントに依頼して無効化する方法が案内されています。DO_NOT_TRACK=1 を設定しておけばオフが維持されます。詳細はプライバシーポリシーに記載されています。

企業環境で設計データを扱う場合、テレメトリの既定値と抑止手段が明文化されているかは確認項目になりやすい箇所です。この点は README とプライバシーポリシーで追える状態になっています。

メンテナンス状況をどう読むか

GitHub 上の実測値をもう一度並べます。スター 16,626、フォーク 1,726、Watch 88、未解決 Issue 29 件、公開日 2026-04-22、最終更新 2026-10-04 です。最終更新が調査日と同日であることから、開発は活発に動いている状態だと読み取れます。一方で、履歴は約 5 か月しかありません。

この組み合わせをどう評価するかは、採用するチームの要件次第です。スターとフォークの数は関心の広がりを示しますが、長期運用の安定性を保証するものではありません。また、スター数に対して Watch 数が 88 と小さい比率であることも、関心の性質を読む手がかりになります。ここでは良い・悪いの断定は避け、「活発に更新されているが、長期運用の実績はまだ蓄積途上である」という事実として提示します。長期の安定性を必須条件とするプロジェクトでは、このギャップを埋める判断材料（自社でのバージョン固定方針など）が別途必要になります。

text-to-cadの採用が向くチームと向かないチーム

ここまでの事実を、判断軸の形に落とします。

採用の検討を進めやすいケース

• 設計成果物を Git で差分管理し、レビューや再生成をソフトウェア開発と同じ作法で回したい場合です
• Codex / Claude Code / Cursor / Grok Build のいずれかをすでに業務で使っており、同じ環境に設計のワークフローを足したい場合です
• 設計だけでなく、製造前の検査（DFM / DfAM Check / SendCutSend）やスライス、プリンタ送信まで同じ土台でつなげたい場合です
• ロボット記述ファイル（URDF / SRDF / SDF）も扱い、形状と記述を同じプロジェクトで管理したい場合です
• エージェントに設計を任せる際の規約（単位・再現性・検証）を自前で整備するコストを避けたい場合です
• Linux / macOS / WSL が主な実行環境になっているケースです

別の選択肢を先に検討したほうがよいケース

• Windows 11 で Smart App Control を無効化できず、WSL も利用できない運用ルールがあるケースです
• GUI 中心の設計ワークフローを変えたくない場合です（FreeCAD MCP のほうが前提に合います）
• ML モデルによる形状生成そのものを求めている場合です（Zoo の Text-to-CAD が候補になります）
• 長期の安定運用実績を必須条件にしているケースです（公開から約 5 か月という履歴の短さが制約になります）
• CAD の規約と検証フローを自社で既に確立しており、build123d や CadQuery を直接使う構成で足りる場合です

いずれのケースも、最終的な判断には自社環境での検証が必要です。本記事はその検証に入る前段として、どの軸で評価すべきかを整理したものです。

まとめ

本記事の要点を整理します。

• earthtojake/text-to-cad は ML による形状生成サービスではなく、エージェントに CAD のワークフローを与える 12 種のスキル集です。対象はローカルのプロジェクトファイルです
• アプローチはコード生成型で、build123d 0.11 と Open CASCADE 7.9 を基盤に、デコレータ付きの Python モデルから STEP を生成します。成果物の原本が Python ソースとして残ります
• SKILL.md が単位・再現性・検証・仮定の記録といった規約を明示しており、「計算が失敗したことは合格ではない」という引き渡し基準まで規定されています
• カバー範囲は設計に留まらず、図面 PDF・DFM / DfAM 検査・スライス・プリンタ送信まで含みます
• 導入前の確認点として、Windows 11 の Smart App Control による OCP のロード失敗、Python 3.11+ / Node.js 20+ / uv の前提、更新に npx skills update ではなく add を使う必要がある点が README に明記されています
• リポジトリはアーカイブもフォークもされていない本家で、ライセンスは MIT、スター 16,626・フォーク 1,726・未解決 Issue 29 件、最終更新は 2026-10-04 です。一方で公開は 2026-04-22 であり、履歴は約 5 か月です

繰り返しになりますが、本記事は README・各スキルの SKILL.md・公式サイト・GitHub API の実測値に基づく整理であり、インストールや動作検証は行っていません。採用を決める段階では、自社の実行環境と設計プロセスに照らした検証を別途行ってください。

関連情報

設計自動化や AI エージェントを活用した開発体制の構築をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。