CADノウハウをADRとして記録する：マルチモーダルLLMによる設計知識の構造化

1. はじめに：なぜCADのノウハウは消えやすいのか？

3D CADと3Dプリンターがあると、フルオーダーの自助具（アシスティブ・デバイス）の設計は比較的容易にできます。しかし、この設計をパラメトリックに再利用するためには、「なぜその寸法・形状にしたのか」というコンテキスト（文脈）が極めて重要になります。

例えば、

身体的根拠: 「前腕の長さに対して握り込みやすい寸法を算出」
構造・3Dプリント制約: 「C型スリットの繰り返し着脱に耐えるため、TPUでの最小肉厚を3.2mmに設定」
安全性・UI/UX: 「皮膚組織の損傷を防ぐため、接触縁にR2.5を付与」

といった情報です。

しかし、これらは設計者の頭の中やメモ書きに留まりやすく、FusionなどのCADデータ上には、固定化された数値、例えば 3.2mm という「結果」しか残らないことがあります。

その結果、別の対象者向けに再設計する際に、

パラメータ間の連動が失われる
設計根拠が分からなくなる
数値だけを変更して別の箇所との整合性が崩れる
過去の設計判断を再利用できない

といった問題が発生します。

そこで、ソフトウェア開発における ADR（Architecture Decision Record） の考え方をCAD設計に応用し、CADキャプチャ＋音声説明をマルチモーダルLLMで解析して、設計判断を構造化して記録するパイプラインを考えました。

目的はCADデータそのものを置き換えることではありません。

CADに残りにくい「設計判断」と「その根拠」を別の情報層として保存することです。

2. システム構成と全体フロー

設計者がCAD画面を見ながらマイクに向かって説明するだけで、設計判断をデータベースへ登録できる仕組みです。

[設計者]
    │
    ├── (1) CAD画面のスクリーンショット
    │
    └── (2) 音声説明
          │
          │  構造・トポロジー
          │  → 形状・ジオメトリ
          │  → フィーチャ
          │  → パラメータ
          │  → 根拠・制約
          ▼
     [Whisper / STT]
          │
          ▼
 [Vision対応LLM]
 [Structured Outputs]
          │
          │ 画像
          │ ＋
          │ 発話テキスト
          │ ＋
          │ JSON Schema
          ▼
    [JSON構造化データ]
          │
          ▼
 [人間によるクイック確認・修正]
          │
          ▼
       [SQLite]

ここで重要なのは、LLMに画像を「見せて判断させる」だけではなく、設計者の説明と画像を組み合わせて、設計対象を段階的に特定することです。Wisper/STTと書いていますが、スマホのAIアプリにカスタム指示を入れておいて、スクショから始めて音声認識させればJSONまで完成すると思います。

カスタム指示

# 役割と目的
あなたは3Dプリント自助具（アシスティブ・デバイス）のCAD設計ノウハウを抽出・構造化する専門のアシスタントです。
入力された「CADのスクリーンショット画像」と「設計者の説明テキスト（音声入力）」を分析し、SQLiteデータベースへダイレクトにINSERTできる精度の高いJSONデータを出力してください。

# 解析ルール（トポロジー先行解析）
設計者の説明は以下の順序で展開されます。画像とテキストを照合し、「ここ」「この部分」といった曖昧な表現や指示代詞を正確なCADフィーチャへマッピング・補完してください。
1. **トポロジー（全体構造の位相）**: 例「日の字型」「L字型」「円筒形」
2. **構成要素と接続関係**: 例「ベースプレートに半円プレートが垂直接合、三角リブで補強」
3. **詳細パラメータ・数値・根拠**: 例「Outer_Length = Hand_Length * 1.1」「たわみ防止のため4mm」

# SQLite DB スキーマ定義（厳守するデータ型）
出力するJSONは、以下のSQLite型定義に厳密に従ってください。

### 1. adr_records（ADR基本情報）
- adr_id (TEXT, 主キー): 例 "ADR-0025"
- device_category (TEXT, NOT NULL): 例 "Grasp_Assist", "Button_Hook"
- title (TEXT, NOT NULL): 簡潔で具体的なタイトル
- topology_type (TEXT, NOT NULL): 全体形状の位相（例 "日の字型（中央梁付き）"）
- target_condition (TEXT): 対象者の症状・身体特性（例 "脳卒中麻痺側（握力5kg未満）"）
- context (TEXT): 設計の背景や課題
- decision (TEXT): 採用した設計上の決定事項

### 2. adr_parameters（CADパラメータ・連動ロジック一覧）
※配列オブジェクトとして出力
- feature_name (TEXT): 対象のフィーチャ名（例 "中央クロスビーム", "固定プレート"）
- param_name (TEXT, NOT NULL): CAD内の変数名・項目名（例 "Beam_Thickness", "Hole_Diameter"）
- formula_or_value (TEXT, NOT NULL): 数式または指定数値（例 "Hand_Length * 1.1", "4.0mm"）
- evaluated_value (TEXT): 実際に算出された数値（例 "3.2mm"）
- rationale (TEXT): 算出根拠・トレードオフの理由（例 "荷重時のたわみを防ぐ断面二次モーメント確保"）

### 3. adr_print_configs（3Dプリント・製造条件）
- material (TEXT, NOT NULL): 使用素材（例 "PETG", "TPU_95A", "PLA"）
- print_orientation (TEXT): 積層方向・配置（例 "Bed_Flat_Y", "Vertical_Z"）
- min_wall_thickness (REAL): 最小肉厚（数値のみ, 例 3.2）
- infill_percentage (INTEGER): 充填率％（整数値のみ, 例 30）

# 出力フォーマット制約
1. 返答は純粋なJSONオブジェクトのみを出力してください。
2. Markdownの前後説明文（「はい、出力します」など）は一切不要です。
3. 言及がなかった任意項目は null としてください（ただしREALやINTEGER型への文字列混入は不可）。

# 出力JSONテンプレート
{
  "adr_records": {
    "adr_id": "ADR-0001",
    "device_category": "",
    "title": "",
    "topology_type": "",
    "target_condition": null,
    "context": "",
    "decision": ""
  },
  "adr_parameters": [
    {
      "feature_name": "",
      "param_name": "",
      "formula_or_value": "",
      "evaluated_value": null,
      "rationale": ""
    }
  ],
  "adr_print_configs": {
    "material": "",
    "print_orientation": null,
    "min_wall_thickness": 0.0,
    "infill_percentage": 0
  }
}

3. 「構造・トポロジー先行説明」による参照対象の明確化

マルチモーダルLLMにCAD画像を渡しても、

「この肉厚が3mmで……」

という説明だけでは、画像内のどのオブジェクトやフィーチャを指しているのか判断しにくい場合があります。

そこで、設計者の発話順序を、

構造・トポロジー
        ↓
形状・ジオメトリ
        ↓
構成要素・フィーチャ
        ↓
パラメータ
        ↓
根拠・制約

に統一します。

ここでいう「トポロジー」は、単なる外観ではなく、構成要素同士の接続・包含・隣接などの構造関係を指します。

例えば、

装具
├── 外形フレーム
│   └── 中央梁
├── 固定プレート
│   ├── 三角リブ
│   └── M4穴
└── 接触面

のような構造です。

一方、

外形：8の字型
長辺：120mm
短辺：60mm
R：20mm
肉厚：3.2mm

は形状・ジオメトリやパラメータに属します。

この区別によって、CAD画像と音声説明との対応付けを行いやすくします。

発話の標準フォーマット

順番	段階	発話例	LLM・Vision側の役割
1	構造・トポロジー	「ベースプレートに対して固定プレートが垂直に接合し、三角リブで補強しています。」	構成要素と接続関係を把握する
2	形状・ジオメトリ	「全体形状は8の字型で、中央に梁があります。」	各構成要素の形状・位置を把握する
3	フィーチャ	「固定プレートにM4用のバカ穴を1つ配置しています。」	CAD上の具体的なフィーチャを特定する
4	パラメータ	「外形長辺は `forearm_length * 1.1` で連動させます。」	対象フィーチャと数値・数式を対応付ける
5	根拠・制約	「中央梁はたわみを防ぐため4mmにしています。」	設計判断と根拠を記録する

この順番は、人間同士が設計を説明するときにも自然です。

まず「何がどこにつながっているか」を説明し、次に「どんな形なのか」、その後で「どの寸法なのか」を説明します。

これにより、LLMにとっても、数値をどの対象に紐付けるべきかという参照解決（grounding）を行いやすくなることが期待できます。

4. SQLiteのデータベース設計

蓄積されたノウハウを後から、

特定の症状・用途向け
特定のフィラメント向け
特定の構造向け
特定の肉厚基準
特定の設計パラメータ

などの条件で検索・抽出できるようにします。

設計判断の基本情報、パラメータ、3Dプリント条件を分離して管理します。

-- SQLiteでは接続ごとに外部キー制約を有効化する
PRAGMA foreign_keys = ON;

-- 1. ADR基本情報テーブル
CREATE TABLE adr_records (
    adr_id TEXT PRIMARY KEY,
    device_category TEXT NOT NULL,
    title TEXT NOT NULL,
    topology_type TEXT NOT NULL,
    target_condition TEXT,
    context TEXT,
    decision TEXT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 2. Fusionパラメータと連動ロジックテーブル
CREATE TABLE adr_parameters (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    adr_id TEXT NOT NULL,
    feature_name TEXT,
    param_name TEXT NOT NULL,
    formula_or_value TEXT NOT NULL,
    evaluated_value TEXT,
    rationale TEXT,
    FOREIGN KEY(adr_id) REFERENCES adr_records(adr_id)
);

-- 3. 製造・3Dプリント制約テーブル
CREATE TABLE adr_print_configs (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    adr_id TEXT NOT NULL,
    material TEXT NOT NULL,
    print_orientation TEXT,
    min_wall_thickness REAL,
    infill_percentage INTEGER,
    FOREIGN KEY(adr_id) REFERENCES adr_records(adr_id)
);

LLMから出力されるJSONは、データベースと完全に同じ構造にする必要はありません。

例えばLLMでは、

ADR
 ├── parameters[]
 └── print_config

という人間にもLLMにも扱いやすい階層構造を維持します。

その後、DB登録処理で、

Nested JSON
      │
      ▼
   ETL処理
   ├── adr_records
   ├── adr_parameters
   └── adr_print_configs

という形で正規化して保存します。

5. LLMの入力と構造化出力（JSON Schema）

LLMのAPI呼び出し時には、Structured Outputsなどの機能を利用して、出力形式をJSON Schemaで定義します。

ここで非常に重要なのが、LLMに設計根拠を勝手に補完させないことです。

例えば設計者が、

「中央梁はたわみを防ぐため4mmにした」

としか説明していない場合、

「断面二次モーメントを確保するため」

という、もっともらしい技術的説明をLLMが勝手に追加してはいけません。

同様に、

forearm_length * 1.1

という式が提示されても、その「1.1」という係数の理由が発話されていなければ、LLMは理由を推測してはいけません。

したがって、

「設計者が明示した事実」と「LLMが推論した情報」を分離する

ことを基本ルールとします。

LLMへの入力プロンプト例

System:
これから3Dプリント自助具の設計を説明するので、解析して記録してください。
供給された「CADのスクリーンショット」と「設計者の音声テキスト」を組み合わせ、設計の意図・構造・トポロジー・形状・パラメータ・根拠を抽出して指定のJSONスキーマで出力してください。

以下の原則を守ってください。

設計者が明示していない数値や設計根拠を推測しない。

推測できない項目は null とする。

設計者が明示した根拠と、LLMが推論した内容を混同しない。

CAD画像だけから寸法値を推定しない。寸法値は設計者の発話またはCADから明示的に取得できる場合のみ記録する。

設計者の音声テキスト：

「これは肘関節の亜脱臼抑制のための装具です。基本形状は8の字型で、楕円の外枠に対して中央に梁が渡っている構造です。まず装着者の前腕の長さ forearm_length を測定しておきます。外形の長辺は forearm_length に1.1を掛けて連動させます。中央の梁の厚みは4mm。これはたわみを防ぐため。ベースプレートには半円状の固定プレートが垂直に接合していて、三角リブで補強しています。固定プレートにはM4用のバカ穴として径4.5mmを1つ開けます。素材はTPU。すべてのエッジは面取り1mmを施します。」

LLMが出力するレスポンス例

{
  "adr_id": "ADR-0025",
  "device_category": "Assistive_Device",
  "title": "肘関節の亜脱臼抑制のための装具",
  "topology_type": "8の字型フレーム（中央梁付き）",
  "target_condition": "肘関節の亜脱臼抑制",
  "context": "装着者の寸法に合わせて外形を可変化し、中央梁によってフレームの変形を抑制する。",
  "decision": "外形寸法を採寸値と連動させ、中央梁の厚みを4mmとする。固定プレートにはM4用のバカ穴を配置し、全エッジに1mmの面取りを施す。",
  "parameters": [
    {
      "feature_name": "外形フレーム",
      "param_name": "Outer_Length",
      "formula_or_value": "forearm_length * 1.1",
      "evaluated_value": null,
      "rationale": "設計者が指定した連動式。係数1.1の設計根拠は発話からは特定されていない。"
    },
    {
      "feature_name": "中央梁",
      "param_name": "Beam_Thickness",
      "formula_or_value": "4.0mm",
      "evaluated_value": "4.0mm",
      "rationale": "たわみを防ぐため。"
    },
    {
      "feature_name": "固定プレート",
      "param_name": "Hole_Diameter",
      "formula_or_value": "4.5mm",
      "evaluated_value": "4.5mm",
      "rationale": "M4用のバカ穴として指定。"
    },
    {
      "feature_name": "全エッジ",
      "param_name": "Edge_Chamfer",
      "formula_or_value": "1.0mm",
      "evaluated_value": "1.0mm",
      "rationale": "設計者が全エッジへの面取り1mmを指定。"
    }
  ],
  "print_config": {
    "material": "TPU",
    "print_orientation": null,
    "min_wall_thickness": null,
    "infill_percentage": null
  }
}

この例では、設計者が説明していない print_orientation や min_wall_thickness などは null としています。

これは重要なポイントです。

「分からない」ことを正しく分からないまま保存することも、設計知識の記録では重要な情報だからです。

6. この手法導入によるメリット

1. 記録コストの大幅な低下

キーボードでMarkdownを手入力する代わりに、CAD画面をキャプチャし、CADを見ながら1〜2分程度説明するだけで、構造化されたADRを生成できます。

設計者は文章を書く必要がなく、

「ここはこういう構造で、この寸法はこういう理由で決めています」

と説明するだけです。

2. 「なぜこの数値なのか」のブラックボックス化を防ぐ

CADファイルには、

Hole_Diameter = 4.5mm
Beam_Thickness = 4.0mm

という結果は残っても、

なぜ4.5mmなのか？
なぜ4.0mmなのか？

までは残らない場合があります。

ADRとして、

パラメータ
    ↓
設計判断
    ↓
根拠

を記録しておけば、後から設計を変更するときにも判断材料になります。

ただし、ここでもLLMによる推測を混入させないことが重要です。

3. パラメータ依存関係を再利用できる

例えば、

forearm_length
       │
       ▼
Outer_Length
       │
       ▼
Outer_Frame

という関係を記録しておけば、

Outer_Length = forearm_length * 1.1

という設計ルールを別の設計にも再利用できます。

単なる寸法値のコピーではなく、設計者が意図したパラメータ間の依存関係を保存できることがポイントです。

4. Fusion Script / Pythonアドインとの連携

SQLiteから、

Outer_Length = forearm_length * 1.1
Beam_Thickness = 4.0mm
Hole_Diameter = 4.5mm

といったパラメータを取得し、FusionのUser Parameters APIなどへ流し込むことで、モデルを自動的に可変更新する仕組みに発展させることもできます。

さらに進めれば、

過去のADR
    ↓
類似設計を検索
    ↓
設計ルールを抽出
    ↓
新しい対象者の寸法を入力
    ↓
CADパラメータ生成
    ↓
モデル更新

という設計支援システムにも発展できます。

7. ADRから「設計知識ベース」へ

この仕組みの本質は、CADファイルをデータベース化することではありません。

CADには主に、

形状
寸法
拘束
フィーチャ

が保存されます。

一方、ADRには、

なぜその形状にしたのか
なぜその寸法にしたのか
何と何が連動しているのか
どの条件で成立するのか
どの制約を考慮したのか

を保存します。

つまり、

              CAD
               │
       ┌───────┴───────┐
       │               │
    設計結果          設計判断
       │               │
    Geometry          Rationale
    Feature           Constraint
    Parameter         Dependency
       │               │
       └───────┬───────┘
               ▼
          設計知識ベース

という構造になります。

ここまで来ると、ADRは単なる「設計メモ」ではなく、CAD設計を再利用するための知識レイヤーとして機能します。

8. おわりに

自助具や福祉用具のような、対象者ごとに寸法や形状を調整する必要があるハードウェア設計では、CADモデルだけを再利用しても十分ではありません。

重要なのは、

「何を作ったか」だけでなく、「なぜそう作ったか」を再利用できること

です。

そこで、ソフトウェア開発におけるADRの考え方をCADに適用し、

CADキャプチャ
    +
設計者の音声説明
    ↓
マルチモーダルLLM
    ↓
構造化JSON
    ↓
人間による確認
    ↓
SQLite

というパイプラインを構築します。

さらに、

構造・トポロジー
        ↓
形状・ジオメトリ
        ↓
フィーチャ
        ↓
パラメータ
        ↓
根拠・制約

という順番で設計を説明することで、CAD画像と設計者の発話との対応関係を明確にできます。

最終的には、過去のCADモデルを単純にコピーするのではなく、過去の設計判断そのものを検索し、新しい設計に再利用することが可能になります。

CADに残りにくかった設計者の経験を、検索可能な構造化知識として蓄積する。

この方法は、自助具に限らず、治具、機械部品、筐体、3Dプリント部品など、「設計理由を次の設計でも使いたい」分野全般に応用できる可能性があります。