🤖
AIに3Dモデルを作らせる前に、私たちは「形状の言葉」を揃えなければならない

2026/05/25に公開
 0. はじめに「生成AIを使えば、メカ設計もそれなりに自動化できたりするのでは？」
最近、ChatGPTが、Geminiが、Claudeが、と生成AI界隈はその進化を褒め称えるような記事が多数投稿されています。

その記事を読みながら、冒頭の想いが私の中で蓄積されたので、この連休はその思索の時間にあてがうことを考えました。

使ったツールとしては、Pythonで3Dモデルを生成できる build123d です。これを使って、いくつか小さな実験をしていました。
build123dは、Pythonコードで3Dモデルを生成できる、CAD-as-code系ライブラリの一つです。

出典：　https://build123d.readthedocs.io/en/latest/
目指しているのは、単に

「AIにCADモデルを描かせること」

ではありません。
もう少し大きく言えば、要求から形状へ、形状から検証へ、検証から製造指示へとつながる、メカ設計の一連の流れをデータとして扱えるようにしたい。
たとえば、次のような流れです。
製品への要求事項を定義する。
その要求を、メカ要件へ分解する。
さらにAssy要件、部品要件へ落とす。
そこから各部品の3D形状を生成する。
各部品に対して必要な基準面とそれに紐づく公差を設定する。
必要機能（強度成立性、組立性、干渉有無）を検証する。
後工程への流通のために必要な形式（STEPファイルなど）に変換する。
最後に、各種検証結果をエビデンスとしてレポートとしてまとめる。
STEPファイルとは、CAD間で3D形状データをやり取りするためによく使われる中間ファイル形式で、STandard for the Exchange of Product model dataの大文字部分から名付けられました。

出典：　ISO 10303 - Wikipedia
私が考えているのは、メカ設計における暗黙知を、こうしたデータの流れの中に少しずつ載せていくことです。
要するに、設計者の頭の中にある「こうすれば成立するはず」という判断を、誰かに説明できる形に変えていきたい。
私の言葉で言えば、ArtをContractにしていく試みです。

 1. 題材：iPhone 17e用スマホスタンド最初の題材として選んだのは、iPhone 17e用のスマホスタンドでした。
なぜスマホスタンドなのか。
理由は単純です。誰でも使い方が分かるから。
スマホを置く。
見やすい角度で支える。
滑り落ちないようにする。
充電できるようにする。
机の上で倒れないようにする。
このくらいなら、メカ設計に詳しくない人にも想像しやすい。
一方で、実際に設計しようとすると、意外と単純ではありません。
スマホを何度で立てるのか。
下端をどの面で受けるのか。
画面手前側にどの程度の爪を立てるのか。
Qi充電器を背面から当てるには、どこを空ける必要があるのか。
USB-Cケーブルは、横置き時に左右どちらからでも挿せるのか。
背面のカメラやボタンをホルダに干渉させないようにどうするか。
剛性を出すための背面リブは、どこにどのように配置すべきか。
つまり、スマホスタンドは一見簡単そうに見えて、形状、機能、干渉、支持、荷重、見た目が絡み合う題材です。
これは、生成AIとメカ設計の関係を試すにはちょうどよいと思いました。





イメージしていた完成形のモデル（トライメトリック）






イメージしていた完成形のモデル（６面視）


 2. iPhone 17eの参考モデル作り最初に行ったのは、iPhone 17eの参考モデルを作ることです。
ここでは意匠を完全再現するのではなく、スマホスタンドとの関係を見るための参照モデルとして作りました。
座標系は、次のように決めました。
+Xは左から右。

+Yは手前から奥。

+Zは重力方向と逆向き。
iPhone単体モデルでは、長手方向をZ軸、短手方向をX軸、厚み方向をY軸としました。
そこに、カメラ、フラッシュ、USB-Cポート、Qi参照領域、サイドボタン、電源ボタンなどを、簡易的に追加していきました。
この段階でもいくつか失敗はありました。
たとえば、カメラやQi参照領域が本来とは逆の面に出てしまったり、ディスプレイ面の扱いが逆になったりしました。
これは、3D CADにおける座標系やスケッチ平面の法線方向を、会話だけで扱っていたことによるミスです。
ただし、ここは比較的修正可能でした。
座標系を明確にし、どの面が画面側で、どの面が背面側なのかを定義する。カメラやフラッシュは背面から押し出す。USB-Cポートは下端面から切り欠く。ボタンは側面から押し出す。
このように、CADの一般的なモデリング手順に沿って整理した結果、iPhone 17eの参考モデルはそれなりに形になりました。





iPhone 17e参考モデル

問題は、その次です。

 3. スマホスタンド本体設計の対話の指示で、急に怪しくなった次に、スマホスタンド本体の形状を作ろうとしました。
条件は、かなり具体的に決めていきました。
iPhone 17eは横置きにする。長手方向を左右方向に倒す。右回転でも左回転でも成立させる。支持角度は机面から75度。下端受けバーは横一文字。受け面の奥行は4〜8mm。初期値は6mm。画面手前側のリップは2mm、最大3mm。背面支持は左右2本のリブ。リブ中心間隔は100mm。リブ幅は10mm。リブ高さは65mm。底板奥行は60mm。底板幅は135mm。受け面とリブは「イ」の字のような形状にする。
文章だけを見ると、かなり設計仕様が詰まっているように見えます。
しかし、実際に形にしようとすると、すぐにズレが出ました。
私が「爪」と言ったとき、私が狙っていた形状は、スマホが手前に滑り落ちないようにする小さな立ち上がりでした。しかし、生成AI側では、その言葉が「スマホを支える下側の受け部」そのものとして扱われてしまいました。





私の指示と生成AIの解釈（爪）

私が「下端受け部」と言ったとき、私はスマホの下辺を受ける横方向の連続した部材をイメージして指示を出しました。しかし、生成AI側では、それが足の下の左右に広がった横方向の連続した部材のイメージを与えてしまっていました。





私の指示と生成AIの解釈（下端受け部）

細かな話を挙げればきりがありませんが、これらのズレは、思っていた以上に根深いものでした。

 4. 「会話として合っている」と「形状として合っている」は違うこの実験で一番大きかった気づきは、ここです。
会話としては合っているように見えても、形状として合っているとは限らない。
人間同士の会話でも、実は似たようなことは起きます。
設計レビューで「ここにリブを追加しておいて」と言ったとき、言われた側が想像しているリブと、言った側が想像しているリブが違うことがある。
「ここは逃がして」と言ったとき、その逃がしが、面を削ることなのか、開口を設けることなのか、そもそも配置を変えて干渉しないようにすることなのか、認識がズレることがある。
ただ、人間同士の場合は、図面や3Dモデルを見ながら、「いや、そこじゃなくて、こっちの面のことです。」「ああ、この出っ張りではなく、手前側の小さい壁のことですね。」と補正できます。
しかし、生成AIとの会話では、この補正が想像以上に難しい。
なぜなら、AIは言葉を処理しているものの、設計者が3Dモデルを見たときの着目点を、同じように共有しているわけではないからです。
先程の事例でもそうです。

「この青丸のところ」

と画像で示しても、人間が見ている構造的な意味と、

AIが画像上で拾っている特徴点が必ずしも一致しているとは限らない。
ここに今回の難しさがありました。

 5. 問題はコード生成能力ではなかった最初は、build123dのコードを書けば何とかなると思っていました。
Pythonで形状を作る。STEPで書き出す。必要なら形状データからPythonで強度検証をする。
この流れ自体は、十分に可能性があります。
しかし、途中で分かりました。
本当に難しいのは、コードを書くことではありません。
本当に難しいのは、

人間が頭の中で見ている形状の意味を、AIが扱える言葉に変換すること

でした。
たとえば、メカ設計者は3Dモデルを見た瞬間に、無意識にいろいろなことを読み取っています。
この面は基準面。
この出っ張りは保持のため。
この凹みは干渉防止のため。
この開口はケーブル接続用。
この角度は見やすさと安定性の妥協点。
この形状は荷重を底板へ逃がしている。
この形状は製造性の考慮結果。
こうした読み取りは、ほとんど暗黙知です。
その暗黙知を、生成AIにそのまま渡そうとしても無理があります。
なぜなら、AIにとって「リブ」「爪」「受け面」「逃がし」「保持」「イの字形状」といった言葉は、まだ具体形状と一対一で結びついていないからです。

 6. 自動設計AIをいきなり作るよりも先にすること今回の実験を通じて、少し考え方が変わりました。
最初は、生成AIとbuild123dを使って、要求から3D形状を自動生成することを考えていました。
もちろん、それ自体は最終的な目標です。
しかし、いきなりそこへ行くのは他にブレイクスルーしなければ行けない壁があります。
それが、形状と言葉を対応づける仕組みです。
つまり、形状語彙ライブラリです。
ここでいう形状語彙ライブラリとは、単なる用語集ではありません。
「爪」という言葉に対して、説明文だけがあるのでは不十分です。
実際の3D形状。
六面図やスクリーンショット。
どの面が機能面なのか。
どのソリッドがその形状語彙に対応するのか。
その語彙をどのようにbuild123dの形状指示につなげるか。
そこまで含めて、初めて「形状語彙」と呼べるのだと思います。

 7. 形状語彙が揃わないと、設計自動化は進まない今回のスマホスタンド設計で分かったのは、会話だけでは形状が安定しないということです。
これは生成AIの限界というより、そもそも人間側の言葉が、形状に対して十分に定義されていない、一意に定まらないという問題でもあります。
人間は普段、図面、3Dモデル、過去の経験、製造方法、製品の使われ方を総合して会話しています。
だから多少言葉が曖昧でも成立する。
でも、AIと一緒に設計するなら、その曖昧さをそのままにはできません。
「爪」とは何か。
「受け面」とは何か。
「背面支持リブ」とは何か。
「イの字形状」とは何か。
「Qi逃がし」とは何か。
「USB-Cアクセス空間」とは何か。
これらを、3D形状と対応づけて定義する必要があります。
つまり、生成AIにメカ設計をさせる前に、まず人間が使っている形状の言葉を、AIが扱える形に翻訳しなければならない。
ここが、今回一番大きな学びでした。

 8. 今回のまとめ今回の実験では、iPhone 17e用のスマホスタンドを題材に、生成AIとbuild123dを使ってメカ設計の自動化を試みました。
iPhoneの参考モデルまでは、環境構築に試行錯誤しながらも形にできました。
しかし、スマホスタンド本体の形状に入ったところで、会話だけでは形状の認識が合わないことが分かりました。
その原因は、コードではありません。
原因は、形状と言葉の対応が曖昧だったことです。AIに3Dモデルを作らせる前に、私たちは「形状の言葉」を揃えなければならない。
これが、今回の結論です。
次回は、この問題をどう解くかを考えます。
STEPファイルを読み込み、人間が重要なソリッドや面に意味ラベルを付ける。それをAIが読める形に変換する。そして、形状語彙ライブラリとして蓄積する。
つまり、次に必要なのは、いきなり自動設計AIを作ることではなく、形状と言葉を結びつけるための小さな実験です。
その話は、また後日書いていきます。