プロンプトで3D CADを作るということ — メッシュとB-rep、そして制約条件というボトルネック

• はじめに — Show GNに上がったCAID、そして「製造に使うな」という自白
• メッシュとB-repは別物である
• パラメトリックという言葉の本当の意味 — フィーチャーツリーと制約solver
• 現在のツールが実際にしていること
• ベンチマークが語る限界
• 今日実際に役立つ場所
• エンジニアが依然として必要な場所 — 公差、DFM、加工性
• おわりに — メッシュを作ることと部品を作ることの間の距離

はじめに — Show GNに上がったCAID、そして「製造に使うな」という自白

GeekNewsのShow GNにプロンプトで3D CADモデルを生成するツールCAIDが投稿されました。作った人の問題意識は明確です — 頭の中にある形状とメカニズムを表現するにはCADツールの機能を覚え数百回クリックしなければならないことが、ハードウェア設計のボトルネックだというものです。

動作方式も簡明です。自然言語で望む形状を入力するとLLMがコードを生成し、3Dモデルがレンダリングされ、パラメータを調整できます。STEPとSTLで書き出します。フランジ、Lブラケット、ヒートシンクの三種類はあらかじめ検証済みのテンプレートなのでLLMを経由せず、自由プロンプトだけがAI経路を通ります。

興味深いのは作った人自ら明かした限界です。寸法を自動検証できず、製造可能性 — 公差、DFM制約、CNCやミリングの観点からの加工性 — を判断できず、検証済みプロトタイプにすぎず出力物をそのまま製造に使ってはいけないということです。

この告白がこの分野全体の状態を正確に要約しています。そしてなぜそうなのかはCADがどんなデータ構造なのかを見れば即座に分かります。

メッシュとB-repは別物である

「3Dモデルを生成した」という一文は二つのまったく違う結果を指す可能性があります。

メッシュは三角形のリストです。頂点座標と三角形のインデックス、それだけです。曲面は存在せず多角形で近似されます。直径20ミリの円柱は実際には三十二枚ほどの平面で、本物の円柱ではありません。テキストからメッシュを生成することは今よくできます — 拡散モデルと3D生成モデルが数十秒で作り出します。

B-repは位相グラフです。面があり、面は解析曲面(平面、円柱、トーラス、NURBS)の上に載っており、面同士は稜線で出会い、稜線は頂点で出会います。直径20ミリの円柱は半径10というパラメータを持つ円柱面一つです。STEPファイルが持つのがこれで、機械CADが扱うのもこれです。

この違いが実務でどう現れるか見てみます。

# 同じブラケットを二つの方式で表現した場合

メッシュ(STL):
  vertex 12.000 0.000 5.000
  vertex 11.951 1.111 5.000
  ...  (穴一つが三角形64枚で近似される)
  -> 「この穴の直径は?」  答えられない。点群から逆算する必要がある。
  -> 「直径を8から10に」  全体の再生成が必要。
  -> ドリル加工指示の生成不可。穴という概念自体がない。

B-rep(STEP):
  CYLINDRICAL_SURFACE('', axis_placement, 4.0)
  -> 「この穴の直径は?」  8.0ミリメートル。
  -> CAMソフトウェアが円柱面を認識してドリルサイクルを生成。
  -> ただしSTEPは結果の形状だけを持つ。どう作ったかは残らない。

最後の行が重要です。STEPはB-repを持ちますがフィーチャーツリーは持ちません。 だから「STEPで書き出せばどんなCADでも編集できる」という言葉は半分だけ正しいです。面を押したり引いたりする直接編集はできます。しかし「このブラケットの厚みパラメータを5から8に変えて残りを自動で合わせろ」はできません。その関係がファイルに存在しないからです。

パラメトリックという言葉の本当の意味 — フィーチャーツリーと制約solver

機械CADがパラメトリックだと言うとき、意味するのは二つの層です。

第一層はスケッチ内の制約です。 2Dスケッチに線と円を描いた後、平行、垂直、接する、同心、対称といった幾何条件と寸法をかけます。この条件群は連立方程式になり、幾何制約solverがこれを解きます。ユーザーが寸法一つを変えると、solverが再び回り残りの要素の位置を再計算します。

第二層はフィーチャーツリーです。 スケッチを押し出し、その結果に穴を開け、稜線にフィレットを入れる順序が記録されます。パラメータが変わるとこの順序を最初から再生(replay)します。

ここでLLMベースの生成がぶつかる壁が三つあります。

制約solverは充足可能性問題です。 条件をかけすぎないと形状が自由度を残したまま浮き(under-constrained)、かけすぎると互いに矛盾して解けません(over-constrained)。人間もここでよく詰まります。モデルが自然言語からこのバランスを取った制約集合を抽出することは、形状を描くこととはまったく違う種類の作業です。そして失敗が静かです — solverは解けるものの意図と違う解を選ぶ場合がよくあります。

フィーチャー再生は壊れやすいです。 フィレットは特定の稜線を参照しますが、前段階のパラメータが変わってその稜線が消えたり分裂したりするとフィレットが失敗します。CAD業界で古くからある問題で、固有の名前まであります。LLMが生成したツリーはこの脆さを考慮しないため、パラメータを少し変えただけで再生が崩れるモデルが出やすいです。

空間推論が弱いです。 Hacker Newsに上がったText-to-CADの議論でこの指摘が繰り返されています。ある人はLブラケットのベンチマークで補強リブが穴を覆ってしまうことを指摘し、位置計算がきちんとできているのか疑問視します。別の人は正確に望む形状を記述するのに要する労力が手でCADを描くのと匹敵し、効率の論拠が崩れると指摘します。そしてパラメトリックなフィーチャーツリー内の制約解決の複雑さは事実上手つかずのまま残っているというのが、そのスレッドの共通した結論です。

現在のツールが実際にしていること

今この分野にあるアプローチを整理するとこうなります。

いくつか触れておくべき点があります。

コードを中間表現として使うアプローチが現状最も堅牢です。 text-to-cadハーネスはbuild123dを使い、その下はOpenCascadeカーネルです。LLMが形状を直接生成する代わりに、パラメトリックモデルを作るPythonコードを書きます。この構造の利点は明確です — コードがそのままフィーチャーツリーであり、gitでバージョン管理され、パラメータは変数であり、失敗すればスタックトレースが出ます。観測可能性が確保されます。

# コードとしてのCADが堅牢な理由: 意図がテキストとして残る
from build123d import *

THICKNESS = 5.0
HOLE_D    = 8.0
EDGE_MARGIN = HOLE_D * 0.75   # 穴の縁の最小肉厚を関係式として固定

with BuildPart() as bracket:
    with BuildSketch() as base:
        Rectangle(60, 40)
    extrude(amount=THICKNESS)
    with Locations((20, 0)):
        Hole(radius=HOLE_D / 2)
    fillet(bracket.edges().filter_by(Axis.Z), radius=3)

# ここでHOLE_Dを12に変えるとEDGE_MARGINが連動して動く。
# この関係はSTEPファイルには残らない。コードにのみ残る。

この例が同時に問題も示しています。filletが参照する稜線集合はフィルタで選ばれますが、前段階の形状が変わって該当稜線が消えると、静かに別の稜線に適用されるか失敗します。コードとして書いてもフィーチャー再生の脆さはそのまま残ります。

SGS-1は方向が違います。 Spectral Labsが2025年9月に公開したこのモデルは構造化されたCAD(B-rep)生成を目指す最初の生成モデルを標榜します。画像やメッシュを入力として受け取り編集可能なSTEPを出すので、リバースエンジニアリングの自動化とアセンブリ文脈内での新規部品生成が主な用途です。75枚の複雑なCAD画像でGPT-5とHoLa BRep比で成功率の優位を示したと述べています。開発チームが認める限界は複雑曲面、有機的構造、非常に薄い形状、完全なアセンブリです。Hacker Newsの反応にはかなりの懐疑がありました — 実際に使ってみたCADユーザーが寸法エラー、失敗した穴、ずれたフィーチャーを報告し、「簡単に編集可能」という表現に疑問を呈しました。

ベンチマークが語る限界

2026年5月に公開されたText2CAD-Benchがこの状態を数値で整理しています。600のキュレーションされた例を四段階の複雑度(L1からL4)に分け、各例に二つのスタイルのプロンプトを付けました — 非専門家が記述するように書いたものと、専門家が手続き的に書いたもの。この二重プロンプト設計は良い判断です。ユーザーのCAD習熟度が結果にどれだけ影響するかを切り分けて見られるからです。

結論は予想可能ですが有用です。汎用LLMもドメイン特化モデルも基本形状では合理的に動作するが、複雑な位相と高度なフィーチャーでは性能が急激に落ちます。 つまり性能曲線がなだらかに下がるのではなく、ある地点で崩れます。

これは直感とも合います。箱に穴を開けるのはプロンプトからパラメータをいくつか抽出する問題です。しかし複数のフィーチャーが互いを参照し、曲面が接線連続でつながり、薄い壁が崩壊してはならない形状は制約充足問題であり、それは言語モデリングとは違う種類の計算です。

今日実際に役立つ場所

悲観的にだけ読む理由はありません。今確実に価値を出している用途があります。

初稿。 白紙から始める代わりに、それらしい形状を一つ受け取っておいて直すのは実際に時間を節約します。特に標準的な部品 — フランジ、ブラケット、ヒートシンク、ハウジング — は形の変動幅が狭いので生成品質が良いです。CAIDがこの三種類をあらかじめ検証済みテンプレートとして置いたのも同じ判断に見えます。

部品ライブラリ検索。「M8ボルト4本が入る90度アングルブラケット」を自然言語で入力して既存ライブラリから探すのは、生成するよりずっと簡単で安全です。検証済みの部品を再利用するからです。生成モデルの本当の価値は形状を作ることより形状をインデックス化し検索することにあるかもしれません。

コードとしてのCADとエージェントワークフロー。 コーディングエージェントがパラメトリックCADコードを書き、レンダリングされた画像を見て自ら直すループが実際に機能します。text-to-cadスレッドのユーザーたちが単純な形状でこの反復改善がうまくいくと報告しています。興味深い実装の詳細が一つあります。このハーネスはSTEPファイルに位相のサイドカーを作り、モデルがファイル全体をロードせずにB-rep情報を読めるようにします。コンテキスト予算の中で形状を扱おうとする試みです。

リバースエンジニアリング。 メッシュやスキャンデータをB-repに変換する作業はもともと半自動で退屈な作業でした。SGS-1が狙う場所です。結果を人間が検収するという前提のもと、白紙から作るより検証負担が小さいです。

共通点が見えてきます。検証コストが低いか、人間がすぐ目で確認できるか、失敗しても取り消しやすい場所で価値が出ます。

エンジニアが依然として必要な場所 — 公差、DFM、加工性

CAID開発者が正直に列挙した三つが、まさに自動化されていない領域です。

公差とはめあい。 穴の直径8ミリという数字はそれ自体では何の意味もありません。8H7なのか8H11なのか、軸とゆるいはめあいなのかきついはめあいなのかによって部品が組み立てられるかどうかが決まります。そして公差は形状から導かれるものではなく機能的意図から出てきます。この軸が回転すべきなのか、固定されるべきなのか、熱膨張を吸収すべきなのかを、モデルはプロンプトになければ知りようがありません。複数部品にまたがる公差累積解析はさらに別の話です。

DFM。 射出成形なら抜き勾配と均一な肉厚が必要で、3軸ミリングなら工具が届かない内側の角とアンダーカットが問題になり、板金なら曲げ半径と最小フランジ長が制約です。同じ形状が工程によって製造可能だったり不可能だったりします。プロンプトに工程が明示されても、モデルがその制約を形状生成中に満たす保証はありません。

加工性検証。 工具のアクセス性、段取り回数、固定方法 — これは形状だけを見ても判断できず、工場の設備リストを知る必要があります。

そしてもう一つ、あまり言及されませんが重要なものがあります。意図の記録です。 よく作られたCADモデルは形状だけでなくなぜその形状なのかを含みます。どの寸法が機能的に重要で(だから公差が厳しく)、どれが任意に決めたものか。この情報があってこそ6か月後に別の人が安全に修正できます。生成されたモデルはすべての寸法が同じように任意に見えるという特性があり、これは保守コストとして返ってきます。

おわりに — メッシュを作ることと部品を作ることの間の距離

この分野を見るとき最も役立つ問いを一つだけ残すとすればこれです。このツールの出力は編集可能なフィーチャーを持っているのか、それとも結果の形状だけなのか。

• メッシュだけが出るなら可視化とプリント初稿用です。機械設計パイプラインには入れません。
• B-rep(STEP)が出るならCADに持っていって直接編集はできます。しかしフィーチャーツリーがないのでパラメータ一つを変えて再生成することはできません。
• パラメトリックコードが出るなら本物のパラメトリックです。ただしコードが壊れやすい参照を含む可能性があり、その脆さは人間が見なければなりません。

そしてそのどれも公差、DFM、加工性の代わりにはなりません。Show GNに投稿されたツールの開発者が「製造に直接使うな」と書いたのは謙遜ではなく正確な技術的記述です。形状を作ることと部品を作ることの間の距離は、これまでこの分野が縮めてきたものよりまだずっと遠いです。