3Dモデルを言葉で作りたい、ロボット記述ファイルを自動生成したい、スライスまで一気に通したい。そういう欲求を持ちながら、「どこから手をつければいいか」で止まっている人は少なくないかもしれません。text-to-cadは、そのワークフロー全体をAIエージェントのSkillとして整理したライブラリです。紹介だけでなく、設計の読み方も一緒に見ていきます。
どんなライブラリか
text-to-cadは、CAD・CAE・CAM領域のエージェントSkillを集めたPythonベースのライブラリです。スター数は14,000超で、ライセンスはMIT。テキストや画像の指示から3Dジオメトリを生成し、STEP・STL・3MFといった形式でエクスポートするCAD Skillを中核に、ロボット記述（URDF・SRDF・SDF）、2D図面（DXF）、Gコード生成、Bambu Labプリンターへの直接送信まで、12のSkillが縦に並んでいます。
インストールは npx skills add earthtojake/text-to-cad の一行で完了し、Codex・Claude Code・Grok Buildいずれかのエージェントへ各Skillが直接配備されます。想定するユーザーは、機械設計や製造系のパイプラインをAIで自動化したいエンジニアで、ロボティクスや積層造形に携わっている人にはより直接的に刺さる内容になっています。
設計でここが上手い
Skillの切り方が縦に深い
このライブラリの最大の特徴は、Skillを「横に広く薄く」ではなく「縦に深く」切っていることです。CADを生成するSkillと、生成したファイルをブラウザでプレビューするSkillは別に分かれています。off-the-shelfのSTEPパーツを検索するstep.partsも独立しています。さらにその下流として、積層造形の可否を確認するDfAM CheckとGコード生成、そしてBambu Labへの送信まで別Skillとして存在します。
この分割は冗長に見えるかもしれませんが、エージェントが呼び出すときの文脈的な負荷を小さく抑えるうえで理にかなっています。「CADを生成する」タスクに必要なコンテキストと「スライスしてプリンターに送る」タスクに必要なコンテキストは全く異なります。一つのSkillに全部詰め込むと、エージェントは毎回すべての仕様を読む羽目になります。分割されていれば、呼び出しが必要な部分だけを読めば済みます。
CAD→検証→出力の流れが自然につながる
ロボット記述ファイルのフローを例にとると、URDF（構造定義）→SRDF（MoveIt2用のプランニンググループ追加）→SDF（シミュレーター向けの世界定義）という順序が、それぞれ独立したSkillとして並んでいます。前のSkillの出力を次のSkillへ渡す形が想定されているため、エージェントがパイプラインとして組み合わせやすい構造になっています。DXFからSendCutSendへの入稿チェックも同じ思想で、生成と検証を別Skillに担わせています。
Implicit CADのような実験枠がある
Skillの一覧の中に、GLSL符号付き距離関数を使ったImplicit CADが「Experimental」として含まれています。本番のCADワークフローとは切り分けられた実験枠として存在しているのは、このライブラリが単なる完成品の配布ではなく、領域の開拓を継続的にやっていく意思の表れかもしれません。使う側も「実験的」と明示されていれば、プロダクション環境に誤って組み込むリスクを避けやすくなります。
こういう人に向くかも
ロボットのハードウェア試作を繰り返しているチームが、このライブラリを使うと何が変わるかを考えてみます。今までブラケットの設計変更のたびに設計者がFreeCADやFusionを開き、寸法を直し、STEPをエクスポートし、スライサーを起動していたとします。text-to-cadを導入すると、エージェントにテキストで変更指示を出すと、CAD Skillが形状を生成し、DfAM Checkが印刷可否を確認し、G-codeがスライスし、Bambu Labsが送信するところまで、コードを書かずに通すことができます。
一方、商用製品の最終図面や厳密な公差管理が必要な場面には、今のところ向かないと思います。生成された形状の精度をエンジニアが必ず確認するフローを挟む必要があり、完全自動化は難しいでしょう。プロトタイプと概念設計の速度を上げる道具として見るのが今の段階では適切です。
設計の良し悪しをどこで見るか
機能の単一性という観点から見ると、このライブラリはSkillレベルでは良く守られています。CAD Skillは「テキスト・画像からCADジオメトリを生成し、STEP/STL/3MF/GLBでエクスポートする」という役割に絞られています。ブラウザプレビューはCAD Viewer Skillに任せているため、同じSkillが複数の責務を持つ状況を避けています。ただし、ライブラリ全体として見たときに12のSkillは相当な規模で、導入後に全部を使いこなすまでの学習コストは小さくありません。「とりあえずCAD Skillだけ入れる」という運用ができるのかどうか、インストール後の依存関係をよく確認しておく必要があります。
ドキュメントの深度については、各SkillにSKILL.mdが付属していて、エージェントがSkillの仕様を読む形になっています。ただし、エンドユーザー向けの「このSkillでできること・できないこと」の境界線が、SKILL.md以外ではあまり明確に書かれていません。texttocad.devのドキュメントサイトがどこまで整備されているかは、実際に触れてみて確認する必要があります。
メンテナンスの継続性については、developブランチで開発が進んでいて、mainへのマージでリリースする形になっています。CIでテストが走っており、Discordコミュニティもあります。ただし、Jake氏一人のリポジトリである点は長期運用を考えるときに意識しておくべき点です。スター数が多いからといって複数のメンテナが存在するわけではなく、コントリビューションがどの程度活発かをIssue・PR履歴で確認しておくことをすすめます。
トークンの経済性という観点では、Skillが分割されているため、エージェントが一度に読み込む仕様の量が抑えられています。CADの生成だけが必要なときにロボット記述の仕様を毎回読まなくて済む構造は、コスト面でも合理的です。ただし、パイプラインで複数のSkillをチェーンする場合、エージェントがそれぞれのSkillを順番にロードするコストが積み上がります。ユースケースによっては、よく使うSkillだけを選んでインストールするほうが効率的な場合もあるでしょう。
自分が書くなら、どこを変えるか
一番気になるのは、各Skillの「検証フロー」の厚みです。DfAM CheckやSendCutSend向けの事前チェックは存在しますが、「エージェントが生成したCADジオメトリが意図した寸法になっているか」を自動で確認するSkillは見当たりません。設計者がCAD Viewerで目視確認するステップが想定されていますが、バッチで大量に生成するユースケースでは視覚的な確認が難しくなります。
もし自分でこの構成を組むなら、生成後にSTEPを解析してバウンディングボックスや主要寸法をJSON形式で返すLinting Skillを追加したいと思います。エージェントが生成→寸法確認→再生成のループを自律的に回せるようになれば、「だいたい合ってる」ではなく「指定した寸法の±0.5mm以内」という確認が自動化できます。現状の構成はSkillの流れとして美しいですが、フィードバックループがエージェント側に委ねられている部分が多いです。
導入を検討するときのチェック観点
導入前に確かめておきたいことをリストにします。
- CAD Skillが依存するPythonバージョン（3.11+）とcadquery等の依存ライブラリが、自分の環境で動作するか
- 使いたいSkillだけを選んでインストールできるか、あるいは全Skillが強制的に入るかを確認する
- STEP・STLのエクスポートで生成されるジオメトリの品質を、自分のユースケースで許容できるか。まずデモ動画で生成物を確認する
- ロボット記述（URDF/SRDF/SDF）が必要ない場合、そのSkillを除外してもパイプライン全体が機能するか
- Bambu Lab SkillはBambu Labのプリンターを持っていることが前提。他のプリンターへの送信は現時点でサポートされていない
- Jake氏のリポジトリであり複数メンテナではないため、IssueとPR履歴でアクティビティを確認する
- エージェントがプリンターへの直接送信まで行う場合、誤送信のリスクを考慮してドライランフラグの動作を事前にテストする
生成から出力までの距離感
text-to-cadが面白いのは、CADの生成を「スタート地点」と位置づけている点です。生成したジオメトリを確認し、off-the-shelfパーツを探し、図面に落とし、入稿チェックして、スライスして、プリンターに送る。その全工程にSkillが用意されています。一つのエージェントが持つにはやや重い構成ですが、チームで運用するときに「このタスクはこのSkillに投げる」という分業の構造がすでに整っているのは、長期的に使い続けるうえで価値があります。CAD生成に興味があるなら、まずCAD Skillと CAD Viewerの2つだけを動かしてみて、その出力の精度から判断するのが現実的な進め方ではないでしょうか。
