AIは3Dモデルを作れるのに、CAD設計データは作れない
最近は、テキストや画像から 3D モデルを生成できる AI が増えています。
実際に試してみると、見た目としてはかなり自然な 3D モデルが出てきます。
今回は Meshy を使って、ワイヤレスマウスの 3D モデルを生成してみました。

Meshy で生成したマウスの 3D モデル
入力したプロンプトは以下です。(精度が良いため英語を採用)
A modern wireless computer mouse, ergonomic product design, smooth white top shell, black base, textured black side grip, metallic scroll wheel, small orange side buttons, hard-surface 3D asset, clean studio lighting, neutral background
モダンなワイヤレスコンピュータマウス、人間工学に基づいた製品デザイン、滑らかな白い上面、黒いベース、質感のある黒いサイドグリップ、メタリック調のスクロールホイール、小さなオレンジ色のサイドボタン、硬質素材の3Dアセット、清潔感のあるスタジオ照明、ニュートラルな背景
生成されたモデルを見ると、かなりマウスらしい形になっています。
3D アセットとして見るなら、十分に実用的なレベルだと感じました。
すると、こう思うかもしれません。
「AI はもう 3D モデルを作れる。なら 3D CAD 設計も近いのでは?」
ただ、ここには大きな落とし穴があります。
見た目として 3D モデルが成立していることと、CAD の設計データとして使えることは別です。
以前書いた「AI は絵を描けるのに、CAD の線は引けない」という記事では、画像として正しく見えることと、CAD 図面として使えることは別だ、という話をしました。https://zenn.dev/0xliclog/articles/fd193ac074be51
3D では、この問題の現れ方が変わります。
2D では線がつながっていない、不要な線分がある、といった問題でした。3D では、部品がどう分かれているか、内部構造があるか、設計履歴を持っているか、といった問題になります。
見た目として自然な 3D モデルと、製造を前提にした CAD データは別物です。
AI 生成の 3D モデルの実体は三角面メッシュ
先ほどのモデルをワイヤー表示にすると、構造が見えてきます。

同じモデルをワイヤー表示したもの
画面左上を見ると、トポロジーは「三角面」と表示されています。
フェイス数は 1,176,833、頂点数は 587,929 です。
つまり、このモデルは大量の三角形で表面形状を表現したメッシュモデルです。

拡大すると三角面で構成されていることがわかる
通常表示では、滑らかなマウスのように見えますが、CAD のように「上カバー」「下ケース」「ホイール」「基板」「ネジ穴」などが設計要素の単位で分かれているわけではありません。
もちろん、これは Meshy の生成結果が悪いという話ではありません。
自然言語のプロンプトから、ここまでマウスらしい形状が生成されるのはかなりすごいです。
ただし、これはあくまで「見た目としてマウスに見える 3D モデル」です。
ゲームや映像、アニメーション、Web 表示などで使う 3D アセットとしては強力ですが、製造や設計変更を前提にした CAD データとは役割が違います。
たとえば、このようなメッシュを CAD に取り込んだとしても、すぐに設計変更しやすいデータになるわけではありません。幅を少し変える、ホイール部分だけ修正する、ネジ穴位置を調整する、といった操作は、パラメトリックな CAD モデルのようには扱えません。
見た目の形状は持っていても、設計意図や部品構成を持っているわけではないからです。
Fusion のサンプル CAD と比べる
次に、Fusion に用意されているマウスのサンプル CAD を見てみます。

Fusion のサンプル CAD データ
外観だけを見ると、こちらも同じように「マウスの 3D モデル」に見えます。
しかし、上部カバーを非表示にすると違いが見えてきます。

上部カバーを非表示にすると、内部構造が確認できる
内部には、基板、ホイール、筐体、ネジ穴、ボタンなどの部品があります。
左側のブラウザにも、Base、Middle、Top、Wheel などの構成要素が並んでいます。
つまり、これは単に「マウスっぽく見える形」ではありません。
どの部品で構成され、どのように組み合わさっているかの情報を持った CAD データです。
言い換えると、見た目の外形だけでなく、「どの部品が、どの役割を持って、どのように組み合わさっているか」までの情報が含まれています。
CAD では、単なる三角形の集合ではなく、面やエッジ、ソリッドなどの形状情報としてモデルを扱います。履歴を持つパラメトリックな設計データであれば、後から形状の変更もできます。
見た目の 3D と、設計できる 3D は違う
3D 生成 AI は、見た目を作るのが得意です。
前述のマウスも、形状だけを見るとかなり自然で、3D アセットとしては十分に成立しています。
一方で、CAD 設計では見た目だけでは足りません。
たとえばマウスを設計するなら、次のような情報が必要になります。
- 外装の肉厚
- 上下ケースの分割
- ホイールの軸
- ボタンの可動範囲
- 基板の配置
- ネジ穴やボス
- 嵌合構造
- 部品同士の隙間や公差
- 部品同士の干渉
- 後から寸法を変更できる構造
AI 生成モデルにこれらが全くない、と言いたいわけではありません。
ただ、少なくとも今回のような 3D 生成 AI の出力は、CAD 設計データとしてそれらを明示的に持っているわけではありません。
見た目としてマウスに見えることと、製造を前提に設計されたマウスであることは別です。
なぜ 3D は作れるのに、CAD の設計データは作れないのか
ここで疑問になるのは、記事の冒頭にも出てきた
「AI が 3D モデルを作れるなら、CAD モデルも作れるのでは?」 という点です。
この違いを考えるうえで重要なのは、生成している対象と、生成方法の違いです。
まず、「LLM」「画像生成 AI」「3D 生成 AI」は、どれも一般的には「AI」と呼ばれます。
しかし、これらはいずれも扱っているデータや出力の性質が全く違います。
| 種類 | 代表例 | 主な出力 | 得意なこと |
|---|---|---|---|
| LLM | GPT、Claude、Gemini など | テキスト・コード | 文章・コード・手順 |
| 画像生成 AI | DALL·E、GPT Image、Imagen など | 2D 画像 | 自然な画像生成 |
| 3D 生成 AI | Meshy、Tripo、Hunyuan3D など | 3D モデル・メッシュ | 自然な 3D 形状生成 |
画像生成 AI や 3D 生成 AI は、見た目として自然な形を直接生成します。
一方で、CAD 設計を AI に行わせる場合は少し事情が違います。
現時点では、CAD の設計データを直接生成する専用モデルというより、LLM が CAD ソフトの API やコマンドを順番に呼び出して形状を作る、という構成になりやすいです。
つまり、3D 生成 AI が見た目の形状を一気に整えるのとは違い、CAD では「操作の履歴」を正しい順番で積み上げていく必要があります。
たとえば、マウスの CAD モデルを作るなら、
- スケッチを作成し、寸法を指定する
- 押し出しやフィレットで形状を作る
- 部品を分割し、ネジ穴やボスを配置する
- 内部構造を作る
- 干渉しないか、必要隙間が取れているかを確認する
といった操作を、順番に積み上げる必要があります。
途中の操作順を間違えたり、必要な要素を作り忘れたり、後の操作に必要な参照を失ったりすると、最終的な CAD モデル全体が破綻します。
見た目の 3D モデルであれば、多少形が曖昧でも「それっぽく見える」ことで成立する場合があります。しかし CAD では、寸法、拘束、部品構成、履歴、内部構造など、一つの操作で考慮すべき情報が多く、それを正しい順序で積み上げ続ける必要があります。
この違いがあるため、AI が 3D モデルを作れるようになったからといって、そのまま CAD 設計も簡単にできる、とは言えないのが現状です。
コードで CAD を定義するアプローチ
ここまで、3D 生成 AI のメッシュモデルと CAD 設計データの違いを見てきました。
では、別のアプローチはないか。
一つの方向として、プログラムで形状を定義する CAD があります。
OpenSCAD や CadQuery といったツールでは、コードを書いて 3D 形状を作ります。
Zoo が提供する Text-to-CAD のように、自然言語から CAD コードを生成する試みもあります。

OpenSCAD 公式サイトより引用
コードベースの CAD は、LLM との相性が良い面があります。
以前の記事で、LLM は1次元にトークンを順に書く機械なので、CAD の空間的な整合性を保つのが構造的に苦手だという話をしました。これは 2D だけでなく 3D でも同じことがいえます。
コードベースの CAD でも順に書く点は同じですが、座標を1本ずつ指定するのではなく、「この形状を押し出す」「ここにフィレットをかける」といった意味のある操作の単位でコードを書けます。LLM が苦手な空間的な整合性を CAD エンジン側に任せられる分、相性が良いということです。パラメータを変数として持てるため、寸法変更にも対応しやすい構造です。
ただし、現時点でこのアプローチが実務の製品設計を置き換えるのは難しいと考えています。
たとえば、マウスのような曲面主体の形状を考えてみます。
GUI の CAD なら直感的に操作できる自由曲面でも、コードで同じ曲面を記述しようとすると手間が大きくなります。さらに、数百点を超える部品で構成される大規模なアセンブリをコードだけで管理・把握するのは現実的ではありません。
既存の設計資産の問題もあります。
多くの企業には、長年蓄積された CAD モデル、テンプレート、部品ライブラリ、社内ワークフローがあります。それらをすべて捨ててコードベースの CAD に移行するコストは非常に大きく、技術的な優劣だけで判断できる話ではありません。
コードで CAD を定義するアプローチは、AI と CAD の接点として興味深い方向です。
ただ、それが今すぐ実務の設計を変えるかというと、まだ距離があるのが現状だと思っています。
おわりに
AI で 3D モデルを作れる時代にはなってきました。
実際、Meshy で生成したマウスは、見た目としてはかなり自然でした。
ただし、それはそのまま「AI が CAD 設計できるようになった」という意味ではありません。
3D 生成 AI が作るのは、多くの場合、見た目を表現するためのメッシュモデルです。
一方で CAD は、現実に作るものを扱うための設計データです。
見た目の 3D と、設計できる 3D は違います。ただ、3D 生成 AI の進化は非常に速く、CAD との間にある壁の手前まで AI が来ていること自体は大きな変化です。
また、コードベースの CAD のように AI との接点を探る動きはすでにありますが、実務の製品設計に届くにはまだ距離があります。AI が 3D を作れるようになった今、次に重要になるのは、その先にある設計データとの壁をどう越えるか、だと思っています。