筐体をAIに設計させる — OpenSCADとText-to-CADでパラメトリックな箱を作る

基板を別のものに載せ替えるたびに、筐体をゼロから作り直している。寸法をひとつ変えたいだけなのに、CAD の履歴を遡って全部やり直しになる——AI CAD 筐体 設計が解こうとしているのは、この繰り返しの無駄だ。箱の形は、突き詰めれば「いくつかの数値から導かれる直方体と円柱の集合」でしかない。ならば数値を変数にして、形をコードで書けばいい。本記事では、実際に手持ちの LLM でパラメトリックな基板筐体を3世代にわたって生成し、各世代で何が正しく、何が破綻していたかを記録した。結論を先に言えば、AI はコードの構造化には強く、幾何の整合性には弱い。

検証水準について先に明記する。本記事で扱うコードは、OpenSCAD でのレンダリングを実行しておらず、印刷も行っていない。検証は生成コードの机上レビューと、寸法の導出式を Python で再計算した算術検算までである。したがって「動いた」「うまく刷れた」という主張は一切していない。書けるのは、コードを読んで分かることと、計算して分かることだけだ。

基板が変わるたびに筐体を作り直している

GUI の CAD で筐体を作ると、寸法は形状の中に埋め込まれる。スケッチの拘束、押し出しの距離、穴の位置。どれも履歴の中に散らばっていて、「基板の取付穴ピッチ」という一つの概念が、モデルの4か所に別々の数値として存在している。

この構造の何が問題か。基板を変えたときに、4か所すべてを正しく直さなければならない。一つでも取りこぼせば、印刷してから気付く。そして人間は、必ず取りこぼす。

コード CAD の発想は逆だ。寸法をファイル冒頭の変数として1か所に集め、形状はそこから計算で導く。取付穴ピッチを書き換えれば、ボスの座標も、蓋のネジ穴も、外形寸法も、すべてが連動して動く。手で直す箇所はゼロになる。この構造そのものが、OpenSCAD × LLM 実践 2026（2026-07-18 公開）で示したコード CAD の本質的な利点である。

そしてコードなら、LLM が書ける。ここに今の面白さがある。

何を変数にするか — 実測値と設計判断を分ける

コードを書かせる前に、設計者がやるべきことがある。変数の分類だ。

筐体の寸法パラメータは、性質の違う2種類に分かれる。ひとつは実測して決まる値。基板の外形、取付穴のピッチ、裏面突起の高さ、コネクタの開口中心の高さ、ケーブルの太さ。これらは現物を測らなければ分からず、検索しても出てこない。もうひとつは設計判断で決める値。壁厚、クリアランス、フィレット半径、面取り量、リップの隙間。こちらは指針や自機のゲージ結果から決める。

この2つを、コードの中で明示的に分けておく。実測値のブロックと、設計値のブロックを別にする。理由は3つある。第一に、基板を変えたとき触るのは実測値のブロックだけになる。第二に、素材を変えたとき触るのは設計値のブロックだけになる。第三に、そして最も重要なことに、AI に「ここは埋めるな」と示せる。実測値の欄に AI がそれらしい数字を入れてしまうのが、この作業で最も危険な失敗だからだ。

プロンプトにもこの構造を書き込む。「実測値と設計値をコードの冒頭で分けて宣言し、それぞれにコメントで由来を書いて」と指定するだけで、返ってくるコードの質は変わる。

分類には副次的な効果もある。実測値のブロックは、そのまま採寸のチェックリストになる。基板を前に「この8項目を測ればいい」と分かっている状態で作業できるのは、思いのほか大きい。3Dプリントの筐体づくりで最も時間を食うのは、実は測り直しに戻る往復だからだ。何を測るべきかがコードから逆に決まる、という順序は覚えておく価値がある。

第1世代 — プロンプト1本で出てくるもの

最初のプロンプトはこうした。「基板寸法・取付穴ピッチ・壁厚・クリアランスを冒頭の変数にした2ピースの基板筐体を OpenSCAD で。ボスは4隅にループ配置、側面にコネクタ開口。」

返ってきたコードは、構造としてはよくできていた。パラメータが冒頭に並び、導出寸法が計算式で書かれ、ボスの配置は入れ子のループで書かれている。

module bosses() {
    for (sx = [-1, 1], sy = [-1, 1])
        translate([sx * hole_pitch_x / 2, sy * hole_pitch_y / 2, 0])
            boss();
}

この4行が、GUI で4つの穴を手作業で配置する作業を置き換える。ピッチを変えれば座標は自動で追従する。狙いどおりだ。

外形の導出も筋が通っていた。内寸は基板寸法にクリアランスを両側分足したもの、外形は内寸に壁厚を両側分足したもの。電子工作の筐体を3Dプリントで作る（2026-08-03 公開）で述べた「内側から外へ」という順序が、そのままコードの構造になっている。

ここまでは合格だ。問題はこの先にある。

第1世代を机上でレビューする

生成されたコードを一行ずつ読み、設計として成立しているかを検査した。見つかった問題は6つある。

ボスの根元にフィレットがない。円柱と底板が直角に接続されており、応力集中の起点になる。設計指針としては必須の要素が、指示していないという理由だけで抜け落ちていた。

蓋がない。「2ピースの筐体」と指定したのに、生成されたのは本体だけだった。プロンプトの一部が無視されている。

コネクタ開口の位置が固定されている。開口は外形の中央に置かれており、基板上のコネクタが実際にどこにあるかという情報が入る余地がない。パラメトリック化の目的からすると、これは致命的だ。

開口高さの基準が間違っている。コメントには「底面から」と書かれているが、実装では内部床面からの高さになっていた。しかも本当に必要なのは、基板の裏面を基準とした高さである。コメントと実装と要求が、三者三様にずれていた。

開口に面取りがない。エレファントフットで入口が狭くなる問題への対処が入っていない。

宣言した変数が使われていない。取付穴径を変数として宣言しているのに、ボスの下穴径は別の変数で独立に指定されていた。両者に関係式がないため、片方を変えてももう片方は動かない。変数として「それらしく」並んでいるだけで、パラメトリックになっていない。

この6つ目が、AI 生成コードの典型的な落とし穴である。見た目はパラメトリックだが、実際には連動していない。読まなければ気付けない。

第2世代 — 6つの指摘を反映させる

指摘を伝えて再生成させた。第2世代では6項目すべてが反映され、加えて設計上正しい方向の変更も入った。

導出部は、実測値から計算する形に整理された。

boss_h     = back_clear + boss_margin;
boss_pilot = hole_d - 0.25;
board_z    = floor_t + boss_h;
port_z     = board_z + port_cz_board;

セルフタップ用の下穴をネジ径から 0.25mm 引いて求める式は、3Dプリント ねじ 完全ガイド 2026（2026-07-22 公開）や筐体設計の一般指針にある値そのものだ。開口の高さも、基板裏面の Z を経由して計算されるようになった。基準面の概念がコードに入ったことになる。

ボスのフィレットは、円錐のスカートを重ねる近似で実装された。真の R ではないが、応力集中を緩和するという目的は果たす。蓋も生成され、リップとグルーブによる合わせ面が付いた。

構造としては、実用の入口に立ったように見えた。

第2世代にも残っていた不具合

しかし、読み進めると新しい問題が見つかった。

面取りの抜き形状が、壁の外側に置かれていた。座標変換を追うと、面取り用のソリッドは壁の外面より外側の空間に配置されており、壁と交差していない。つまり、この面取りは何も削っていない。コードには面取りの処理が存在するのに、形状には現れない——最も発見しにくい種類の不具合である。

面取り量が幅と高さで不均一だった。拡大率で指定していたため、幅方向と高さ方向で削れる量が違う。0.5mm の面取りを指示したはずが、実際には辺によって 0.25mm から 0.43mm の間で変動する計算になる。

ボス外径の式が概念を混同していた。ネジ穴の周囲に穴径1個分の肉厚を確保するという指針を実装しようとして、クリアランス穴の径とセルフタップ下穴の径を取り違えていた。値としては近いので実害は小さいが、式の意味が通っていない。

いずれも、コードとしては正常に動く（構文エラーにならない）。設計として間違っているだけだ。この種の誤りは、コンパイラも実行環境も教えてくれない。

第3世代と、そこで見つかった幾何の破綻

第3世代でこれらを修正し、さらに蓋の締結手段として四隅にインサート座を追加させた。コードは3世代で最も整理され、変数の依存関係も通っている。

そこで、導出式を Python に写して数値を検算した。生成されたコードを読むだけでは分からないことがある——特に、複数の部品が空間で衝突しないかは、座標を計算しないと判定できない。

結果はこうだった。基板 85 × 56mm、クリアランス 0.5mm で内寸は 86 × 57mm。ボスは外径 7.85mm でピッチ 58 × 49mm の位置に、蓋の締結柱は外径 10mm で内壁から柱の半径だけ内側、つまり中心座標（38, 23.5）に配置される。

ここで2つの問題が数値として現れた。

第一に、ボスと締結柱の隙間が 0.130mm しかない。中心間距離 9.055mm に対し、半径の和が 8.925mm。数学的には接触していないが、0.4mm のノズルで印刷すればこの2つは確実に融合して一つの塊になる。設計意図としては別部品のつもりが、造形上は連結される。

第二に、より深刻な破綻がある。締結柱が基板の占める空間の内側に立っている。柱は X 方向 33〜43mm、Y 方向 18.5〜28.5mm の範囲を占めるが、基板は X ±42.5mm、Y ±28mm まで広がっている。つまり柱と基板は同じ場所を取り合っており、この筐体に基板は入らない。

さらに計算を進めると、柱を基板の外側に逃がすには内寸を 106 × 77mm まで広げる必要があることが分かった。現状の 86 × 57mm から、両方向に 20mm 拡大するということだ。これは「数値を微調整する」話ではなく、筐体の設計方針そのものを選び直す話である。柱を外に出して箱を大きくするのか、底面からネジを打つ構成に変えるのか、側壁に柱を寄せるのか。この判断は AI にはできない。要求が何かを知っているのは人間だけだからだ。

検算をスクリプトにする — AIの出力を機械で殴る

この破綻を見つけたのは、目視ではなく計算である。ここに再現性のある手法がある。

生成されたコードの導出式を、そのまま検証スクリプトに写す。そして、部品どうしの中心間距離と半径の和を比較する、部品の占有範囲と基板の外形を比較する、といった幾何的な整合性を機械的に判定させる。

d = math.hypot(hole_pitch_x/2 - post_x, hole_pitch_y/2 - post_y)
rsum = boss_od/2 + post_od/2
print("OVERLAP" if d < rsum else f"clear by {d-rsum:.3f} mm")

数行のスクリプトが、読むだけでは絶対に気付けない 0.130mm を教えてくれる。しかもこの検算は、パラメータを変えるたびに再実行できる。基板を別のものに載せ替えたとき、干渉が発生していないかを一瞬で確認できるということだ。

パラメトリック設計の本当の価値は、ここにある。形が変数から導かれているなら、その形が成立しているかどうかも変数から判定できる。設計と検証の両方を、同じ数値から自動化できる。GUI の CAD では、こうはいかない。

もちろん、OpenSCAD でレンダリングすれば干渉は目で見える。だが目視は、見た角度でしか判定できない。数値の検算は、見えない場所も判定する。両方あるのが理想で、少なくとも検算は無料である。

この検証スクリプトは、一度書けば筐体ごとに使い回せる。判定項目を足していけば、自分の設計基準がそのままコードとして蓄積されていく。壁厚が下限を下回っていないか、ボスの周囲に必要な肉厚があるか、開口が壁の縁に近すぎないか。3Dプリントの設計指針として頭の中にある知識を、実行可能な形で外に出しておくということだ。人間の注意力に頼る品質管理は、疲れている日に破綻する。機械に任せられる部分は任せたい。

Text-to-CAD はどこまで来ているか

コード CAD 以外の道も確認しておく。自然言語から直接 CAD データを生成する系統だ。

Text-to-CAD 入門 2026（2026-07-13 公開）とZoo Text-to-CAD 実践 2026（2026-07-14 公開）で扱ったとおり、この系統はメッシュではなく B-Rep（境界表現）を出力する点で、生成メッシュ系とは根本的に違う。STEP で出てくるなら、機械 CAD に持ち込んで編集でき、寸法も測れる。筐体のような幾何的に単純で寸法精度が要る部品には、本来向いた方向性だ。

ただし、筐体の設計で必要になる「実測値との突き合わせ」は、どちらの系統を選んでも人間の仕事として残る。自然言語で「Raspberry Pi 5 が入る箱を」と頼めば箱は出てくるだろうが、その箱の取付穴ピッチが公式図面と一致しているかは、こちらが確認しなければ分からない。生成手段が変わっても、検証の責任は移らない。

実務的には、両者を排他的に選ぶ必要もない。外形の意匠や全体のプロポーションを自然言語で素早く出させ、寸法精度が要る部分（ボスの座標、開口の位置、合わせ面）はコードで組む、という混成もありうる。重要なのは、どの部分の寸法を誰が保証しているかを、自分で把握しておくことだ。生成手段を混ぜたときに最も起きやすい事故は、「どこかで誰かが確認したはず」という思い込みで、実際には誰も確認していない寸法が残ることである。

逆に、生成メッシュ系（テキストや画像から直接メッシュを作る系統）は、筐体には向かない。寸法を数値で指定できず、平面が平面として出てこないからだ。この使い分けはAI 3D設計 完全ガイド 2026（2026-07-19 公開）で整理した地図のとおりである。

分業の結論 — AIは形を書き、人間は寸法を保証する

3世代の生成を通して見えた分担は、かなり明確だ。

AI が得意なこと。コードの構造化、変数の宣言とコメント、ループによる反復配置、モジュール分割、指摘への追従。第1世代から第3世代への改善は速く、指摘した項目はすべて反映された。ボイラープレートを書く速度は、人間の比ではない。

AI が苦手なこと。幾何の整合性。座標変換が意図どおりに効いているかの検証。複数部品の空間的な衝突判定。そして、設計要求の中身。「基板が入る箱」という要求が、柱の配置によって満たされなくなることに、AI は気付かなかった。

AI にできないこと。現物の実測。あなたの基板の裏面突起が何ミリ出ているか、あなたのプリンターが穴をどれだけ縮めるか、あなたが使うケーブルのオーバーモールドが何ミリ太いか。これらは世界のどこにも書かれていない。

この分担は、Claudeを3Dプリント設計に活用する（2026-08-01 公開）で確認した構図とも一致する。モデルが強くなっても、現物の情報を持たないという制約は変わらない。強くなったのは、こちらが与えた情報を形にする速度のほうだ。

まとめ — パラメトリック化の価値は再利用にある

AI CAD 筐体 設計の現在地を整理する。

手持ちの LLM に OpenSCAD のコードを書かせれば、パラメトリックな基板筐体は数分で出てくる。実測値のブロックと設計値のブロックを分けるようプロンプトで指定すれば、構造の質は上がる。3世代の反復で、フィレット、蓋、コネクタ位置の変数化、基準面を経由した高さ計算、面取り、インサート座までは到達した。

一方で、生成コードには読まなければ気付けない誤りが混じる。宣言しただけで連動していない変数、壁の外に置かれて何も削っていない抜き形状、辺によって量が変わる面取り。そして最終世代では、締結柱が基板の占める空間に立つという幾何の破綻が残っていた。ボスとの隙間は 0.130mm、柱を基板の外へ出すには内寸を 86 × 57mm から 106 × 77mm へ広げる必要がある——これは検算して初めて見えた数字である。

だからこそ、導出式を検証スクリプトに写して機械的に干渉を判定する運用を勧めたい。形が変数から導かれているなら、成立判定も変数からできる。この二重化が、パラメトリック設計の本当の利得だ。

そして繰り返しになるが、本記事のコードは机上確認と算術検算までしか行っていない。レンダリングも印刷もしていない以上、「刷れば入る」とは書けない。書けるのは、計算で分かったことだけである。この線を引くことが、数値を扱う記事の最低条件だと考えている。

次は、ここまでの内容を用途別の逆引きとして統合する。作りたいものから材料と方式を引ける地図を用意したい。関連する設計技術の全体像は3Dプリント 実用品 設計ロードマップ 2026（2026-07-26 公開）にまとめてある。

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.