LLM時代のCADを作ってみた──DSL→SDF→3MF→Bambu StudioまでRustだけで繋ぐ

TL;DR

• CAD を LOL DSL (自作) に置き換えてみた ── きっかけは Fusion 360 で挫折した個人的経験
• 今回作ったのは Rust から直接 .3mf を書き出し、Bambu Studio でそのまま印刷できるパイプライン (自作 crate alice-sdf + alice-lol + alice-bamboo)
• LLM から LOL DSL を生成する API も実装済み (alice_lol::bridge::generate_sdf_from_prompt)、本記事では Rust hand-code 版を使用
• 実例として IKEA SKADIS 互換ペグボード (300×300mm) を SDF DSL で生成 → resolution 256 設定で .3mf 184 MB (resolution 128 なら数十 MB) → Bambu Studio 投入まで実測
• LOL DSL の repeat_finite で穴パターンを 200+ node → 10 node 以下 に数式化 (1 回の SDF 評価は配置数 N に依存しない)
• SKADIS 自体の実プリントは未検証、同 pipeline の別モデル (shelf) は実印刷済み

3D プリンタは普及した。でも「自分でモデリングできる人」はまだ少ない。

Bambu Lab の H2D のような家庭向け 3D プリンタが普及して、印刷そのものはボタンを押すだけになりました

でも モデリングは相変わらず難しい:

• Fusion 360 は個人利用は無料だが 1 年ごとの認証更新、UI は業務用の複雑さ、operations 数十工程
• SolidWorks は license 費用が個人には現実的でない
• Blender で mechanical parts は sculpting 系のパラダイムが合わない
• 結果、多くの人は MakerWorld で他人が作った STL をダウンロードするだけ になり、自分の寸法に合わせた custom parts が作れない

私も IKEA SKADIS ペグボードを 壁ぴったりのサイズ で欲しかったが、純正は 36×56 / 56×56 / 76×56 の 3 択、MakerWorld の既製 STL は寸法・穴ピッチ・縁マージンを調整するには元 CAD が要る

そして私自身、Fusion 360 で挫折しました UI の学習コスト、認証更新の面倒さ、GUI 操作の反復 続きませんでした

だから CAD を覚える代わりに、DSL を作ることにしました それがこの記事で紹介する pipeline です

今回作ったもの

Rust から直接 .3mf を書き出し、Bambu Studio でそのまま印刷できるパイプライン

パイプライン全景: 書くのは Rust コード数十行 + LOL DSL テキストだけ、CAD ソフト・G-code 手書き・Slicer 自作は不要

CAD は開かない G-code は書かない Slicer 自作もしない 書くのは Rust コード数十行と LOL DSL テキストだけ

本記事は Rust で SDF エンジンを自作し、text-to-SDF を実装してきた一連の記録の到達点でもあります 前段の記事「Rust の text-to-SDF を CJK 対応したら、Grid Resolution は『設定値』ではなかった話」で SDF Grid Resolution を「契約」として扱う設計知見を書きました その延長線上で、SDF から .3mf を吐いて Bambu Studio に流し込む今回のパイプラインが動いています

この pipeline の core value: CAD を「人間が操作する GUI」から「LLM が生成する DSL」に置き換える

本記事で主張したいポイントは「CAD 学習を LLM が扱いやすい中間表現 (LOL DSL) の生成に置き換えた設計」 にあります SDF も 3MF export も業界既存技術ですし、DSL による 3D モデル記述自体は OpenSCAD / CadQuery / Grasshopper など先例があります この実装で重視したのは、その中でも grammar-constrained decoding で LLM が生成しやすい DSL 表面 を用意することです

core value は 2 点:

1. CAD ソフトを LOL DSL に抽象化した

CAD ソフトを直接 LLM に操作させるのは不安定 (Fusion 360 の内部 API を LLM に叩かせる等は現実的でない)

一方で LOL DSL のような明示的な中間表現を挟む ことで:

• LLM は自然言語 (「300×300mm SKADIS、標準ピッチ、fillet R2」) を受け取って LOL DSL のテキスト を生成すればよい
• LOL DSL は文法定義 (lol.gbnf) があるので grammar-constrained decoding で hallucination を排除できる
• 生成された LOL DSL text は parse_lol で 決定論的に SdfNode に変換 される

つまり LOL DSL は 「CAD の代わりに LLM が生成する中間言語」 として設計されている

2. 生成した LOL DSL を Bambu Studio まで一気通貫で流せる

LOL DSL → ALICE-LOL parse → ALICE-SDF SdfNode → Marching Cubes → 3MF → Bambu Studio → H2D の全工程が Rust コード数十行で書けて、生成 .3mf は Bambu Studio でそのまま開ける Slicer 自作も G-code 手書きも不要

この 2 点によって、「CAD を人間が GUI で操作する前提」を崩し、「LLM が DSL を生成する前提」に置き換えられる可能性 が開ける

デモ題材の選定: なぜ SKADIS を選んだか

SKADIS ペグボードは、この記事の主人公ではなく「CAD 不要を証明する題材」です

SKADIS を選んだ理由:

• パラメトリック (寸法 / ピッチ / 縁マージン / cutout / fillet が数値で決まる) = SDF 数式で表現しやすい
• CAD で作るのが面倒だが、需要は高い (壁ぴったりのサイズで欲しい人は多い、MakerWorld でも人気カテゴリ)
• 穴が数十個並ぶ繰返しパターン = repeat_finite のような DSL 数式化の恩恵が目に見える

この記事で扱わないこと

• ALICE-SDF / ALICE-LOL / ALICE-Bamboo の内部実装詳細
• SKADIS ペグボード自体の実プリント写真 / print time / 材料消費量の実測 (別記事で追記予定)
• 他社 3D プリンタとの比較 / Bambu Studio 自体の使い方詳細
• SDF で表現しづらい形状 (トポロジ複雑な自由曲面 / スキャンデータ由来 mesh 等)
• LLM で LOL DSL を書かせる workflow の実演 (API 実装済み、実演は別記事予定)
• 3D プリンタ初心者向け GUI の実装 (Phase 2 構想、記事末尾のモックのみ掲載)

§Tech-1 ALICE-SDF (crate) と ALICE-LOL (DSL) の役割分担

SDF (Signed Distance Function) = 各点から表面までの符号付き距離を返す関数 (内側は負、表面は 0、外側は正)、mesh は等値面 (SDF = 0) から Marching Cubes で生成 詳細は wikipedia や Inigo Quilez の distfunctions 参照

役割分担:

つまり SDF は Rust で数式手書きするのではなく、LOL DSL で書く (Rust hand-code / lol! proc-macro / (Phase 2) LLM 生成 のいずれか)

§Tech-2 SKADIS ペグボードを LOL DSL で書く

~/ALICE-Bamboo/examples/skadis_sdf.rs 抜粋 (単純化版):

use alice_bamboo::formulas::{self, PrintParams};
use alice_bamboo::{export_to_3mf, lol_to_sdf, validate_build_volume, PrinterSpec};

fn main() {
    let params = PrintParams::bambu_h2d();

    let panel_w = 300.0_f32;
    let panel_h = 300.0_f32;
    let panel_t = formulas::skadis::THICKNESS;
    let peg_w   = formulas::skadis::PEG_W;
    let peg_h   = formulas::skadis::PEG_H;
    let pitch   = formulas::skadis::GRID_PITCH;           // SKADIS 標準 40mm
    let offset  = formulas::skadis::GRID_OFFSET;

    let lol = build_skadis_optimized(
        panel_w, panel_h, panel_t,
        peg_w, peg_h, pitch, offset,
        params.skadis_edge_margin().ceil(),
        params.skadis_outer_frame(),
        params.skadis_cutout_w_max().min(26.0),
        params.skadis_cutout_h_max().min(16.0),
        params.fillet_stress(),
        2.5, 1.35,
    );

    let sdf = lol_to_sdf(&lol).expect("parse");
    validate_build_volume(&sdf, &PrinterSpec::H2D_SINGLE).expect("build volume");
    export_to_3mf(&sdf, "skadis_panel_300x300_sdf.3mf", 256).expect("3mf export");
}

repeat_finite = 繰返しを SDF 評価時まで遅延させる

Fusion 360 の Linear Pattern や OpenSCAD の for loop も、内部で繰り返しをある程度抽象化しています ただし多くの実装では 抽象化のあと最終的に N 個の primitive がデータに実体化 されます SKADIS 300×300mm 標準ピッチだと数十個の穴が展開されて全部 mesh 化対象になる

今回の LOL DSL では、繰り返しを SDF 評価時まで遅延させることで、配置数に依存しない評価を実現しています repeat_finite(pitch, offset, count, primitive) は SDF 評価時に modulo で近傍セルの primitive 距離を計算 するので、ノード 1 個で全 cell を表現できる:

[Before] union tree で穴を全部展開          [After] repeat_finite で数式化

union                                        repeat_finite(pitch, offset, count,
 ├ box (cutout  0)                            box)  ← 1 node
 ├ box (cutout  1)                              │
 ├ box (cutout  2)                              │  評価時に modulo で
 ├ box (cutout  3)                              ▼  近傍 cell の box までの
 ├ ... 数十個                                 ┌─┬─┬─┬─┐  SDF 距離を返す
 └ box (cutout N)                             ├─┼─┼─┼─┤
                                              └─┴─┴─┴─┘
= 200+ node                             = 10 node 以下 (1 回の SDF 評価は配置数 N に依存しない)

「繰り返しを書く」構文自体は他の CAD / DSL にもあります このパイプラインの特徴は 評価戦略を「評価時遅延」に変えられる こと 評価は必要な瞬間だけ実行され、それも近傍セル数個の SDF 計算で済む = 1 回の SDF 評価は配置数 N に依存しない (Marching Cubes 全体では セル数 × 評価時間 = O(セル数) だが、その 1 回あたりが定数で済む)

Marching Cubes で mesh 化する段階でも、この 1 回定数評価が効いてくる (grid の各セルで SDF を 1 回評価するだけで済み、事前に N 個の primitive を全部載せなくてよい) 大きな配置数を扱う設計で恩恵が出やすい

§Tech-3 3MF 出力 → Bambu Studio → build volume 検証

resolution 256 (XYZ 各軸 256 分割 Marching Cubes = 256³ ≈ 1670 万セル) で export_to_3mf すると skadis_panel_300x300_sdf.3mf = 184 MB が生成される 大きいが Bambu Studio は問題なく開く (表面近傍だけがメッシュ化される、出力サイズは形状に依存、実運用では resolution 128 = 数十 MB で十分な場合が多い)

生成した .3mf を Bambu Studio で File > Import > Import 3MF → プリンタ (H2D) 選択 → 素材選択 → Slice → Print default で通せるモデルなら最低限 3 clicks (実運用では 配置 / ノズル / AMS / サポート / レイヤ高さ も適宜確認)

Bambu Studio で skadis_panel_300x300_sdf.3mf を Import した直後 プリンタ (H2D) の build plate 上に配置される 右下 object metadata: Size 300 × 300 × 5 mm / Volume 234,628 mm³ / Triangles 91,420 (これが 184 MB の中身)

SKADIS 300×300mm ペグボードのプレビュー 標準ピッチで数十個の cutout が配置されている

Bambu Lab H2D シングルノズルの build volume は 公称 325×320×320 mm / 安全マージン込み 315×310×315 mm (各辺 5mm) validate_build_volume(&sdf, &PrinterSpec::H2D_SINGLE) で SDF の bounding box が volume を超えたら実行時 error 返却、Bambu Studio 投入前に fail-fast

§Tech-4 何を省略できたか

残る手作業 = Bambu Studio の GUI 操作 (default で通せるモデルなら最低限 3 clicks)

注: 「CAD 不要」は 対象形状を SDF で記述できる範囲において である 自由曲面モデリング / トポロジ複雑なオーガニック形状 / スキャンデータ由来 mesh 等は SDF DSL の守備範囲外

§Tech-5 pipeline は別モデルで実証済み (SKADIS 自体の実プリントは未検証)

主題の SKADIS ペグボード自体は本記事執筆時点で Bambu Studio 投入まで実測、実プリントは未検証

一方で 同じ alice-bamboo pipeline で作った別モデル (shelf) は実印刷済み、下記が実物写真:

写真: alice-bamboo pipeline で LOL DSL → SDF → 3MF export → Bambu Studio → H2D で印刷した shelf、床に置いて使用中

論理関係を厳密に:

• 同じパイプライン (LOL DSL → ALICE-LOL parse → ALICE-SDF SdfNode → .3mf → Bambu Studio → H2D → 実物) で 別モデル (shelf) は実印刷済み
• 本記事の SKADIS も同じ生成・出力経路を利用している
• ただし SKADIS 自体の実印刷は未検証 (shelf で実証されたのは pipeline の各段階が繋がることであり、SKADIS が問題なく刷れることまでは保証しない)

SKADIS 自体の実プリント検証は別記事で追記予定

§Tech-6 未検証事項

• SKADIS ペグボードの実物写真 / print time / 材料消費量 → 別記事予定
• PLA-CF / PETG-CF など強度重視素材での撓み実測
• 他 SKADIS accessory (フック / ボックス / 棚) との組合わせ
• 複数枚並べて壁を埋める場合の panel 間ジョイント設計
• Phase 2 の GUI + LLM (テキスト入力から .3mf 生成) の実装 → 別記事で企画予定

現状と今後

現在 (実装済み):

• Rust → LOL DSL → SdfNode → .3mf → Bambu Studio (本記事のパイプライン、shelf で実プリント実証済み)
• LLM → LOL DSL → SdfNode → .3mf (CLI で動作、examples/prompt_to_sword.rs) ── LLM 経由でも 3MF まで通せる

今後:

• GUI 追加: テキスト入力欄から LLM 経由で SKADIS 生成 → Bambu Studio 自動起動 → Print、想定 UI モック:

┌─────────────────────────────────────────────┐
│  ALICE-Bamboo GUI  (今後、実装前)           │
├─────────────────────────────────────────────┤
│                                             │
│  何を作りますか?                             │
│  ┌─────────────────────────────────────┐   │
│  │ 300×300mm の SKADIS を作って         │   │
│  │ フックを 20 個、右上に「ALICE」ロゴ │   │
│  │ 厚み 5mm                             │   │
│  └─────────────────────────────────────┘   │
│                                             │
│         [   生成   ]                        │
│                                             │
├─────────────────────────────────────────────┤
│  ↓ 内部処理 (自動)                          │
│  LLM → LOL DSL → SdfNode → .3mf            │
├─────────────────────────────────────────────┤
│  ✅ 生成完了 (184 MB)                       │
│                                             │
│  [ Bambu Studio で開く ]  [ ダウンロード ]  │
│                                             │
└─────────────────────────────────────────────┘

ここまで実装すると対象読者が 3D プリンタ初心者 / Bambu Lab ユーザー / MakerWorld ダウンロード派 / Fusion 360 挫折者 まで大きく広がります 現状は CLI までは動くので、GUI を被せるフェーズになります

教訓

• CAD 学習の壁は、書ける言語 + 数式で回避できる (SDF で表現可能な形状に限る、SDF DSL の学習コストは別途ある)
• repeat_finite のような 1 回の SDF 評価が配置数 N に依存しない 設計は、LOL DSL で繰り返しを SDF 評価時まで遅延させることで実現している (Fusion Linear Pattern や OpenSCAD for loop も抽象化はするが、多くの実装では最終的に N 個の primitive がデータに展開される点が異なる)
• Bambu Studio の GUI 側は default で通せるモデルなら最低限 3 click で回せる、細部詰めたければ通常の Bambu Studio 操作で対応
• 実装資産は Rust コード数十行 + Cargo.toml + LOL DSL テキスト だけ、生成 .3mf は都度捨てて OK
• LLM が DSL を生成するワークフローも実装済みであり、このパイプラインはその利用も想定して設計している ── CAD の GUI 操作を LLM の DSL 生成に置き換える経路が既に開けている、これが 3D プリント民主化に向けた 1 つの方向性ではないかと考えている LLM が CAD のボタンを押すのではなく、LLM が文法の決まった DSL を生成する GUI 自動操作でも CAD API ラッパーでもない、DSL を中間表現にした設計です

補足: LLM 連携も実装済み

LOL DSL は LLM から生成することもできます:

• alice_lol::bridge::generate_sdf_from_prompt = 自然言語 → LOL DSL → SdfNode の 1 call API (feature llm-bridge)
• lol.gbnf による grammar-constrained decoding (hallucination を排除)
• LOL DSL 生成 → SdfNode 生成まで実装済み
• 実行 example: examples/prompt_to_sword.rs

本記事では Rust hand-code 版を使っています LLM 経由で SKADIS を生成するデモは別記事で紹介します:

• 「Claude / GPT に SKADIS の LOL DSL を書かせてみた」 (LLM 生成 workflow の実演)
• 「Fusion 360 で挫折した人のためのフルスタック企画」 (GUI + LLM を組み合わせた対象読者拡大の実装記録)

参考

ALICE-* crate 群 (本パイプライン本体)

• ALICE-SDF (SDF 実装 + mesh 化 + GPU shader transpile): https://github.com/ext-sakamoro/ALICE-SDF
• ALICE-LOL (SDF DSL、proc-macro + runtime parser): https://github.com/ext-sakamoro/ALICE-LOL
• ALICE-Bamboo (3D プリント統合パイプライン): https://github.com/ext-sakamoro/ALICE-Bamboo

外部ツール

• Bambu Lab H2D: https://bambulab.com/en/h2d
• Bambu Studio: https://bambulab.com/en/download/studio
• IKEA SKADIS: https://www.ikea.com/us/en/cat/skadis-pegboards-45266/

関連記事 (シリーズ)

本記事は Rust で SDF エンジンを自作してきた一連の記録の一部です:

• Rust の text-to-SDF を CJK 対応したら、Grid Resolution は「設定値」ではなかった話 (2026-07-25 公開、SDF Grid Resolution を「契約」として扱う設計知見)

ライセンス

• alice-sdf: MIT (Python wheel 経由) / Rust crate は AGPLv3
• alice-lol: MIT OR Apache-2.0 (llm-bridge feature 有効化で AGPL-3.0-or-later が派生)
• alice-bamboo: AGPL-3.0-only
• 商用 3D プリントサービス組込 / 商用 SaaS 統合は個別相談 ([email protected])