07.【FCMD】 FreeCADもLaTeXもKlayoutも同じだった ― Full Code設計の共通構造

tags: 機械設計 CAD FreeCAD LaTeX Klayout RTL Git

🏁 はじめに（最終回）

ここまでの連載では、

🧩 FreeCAD を コード主導 で使う話
🔀 GUI とコードをどう分業するか
🔍 Git で「差分が意味を持つ設計」にする話

をしてきました。

最終回では、
少し視点を引いて 一つだけ言い切ります。

💡 FreeCADも、LaTeXも、Klayoutも、RTLも
やっていることは全部同じだった

という話です。

難しい理論はありません。
Qiita向けに 構造だけ を整理します。

🔑 Full Code設計で一番大事なこと

いきなり結論です。

🧱 成果物を直接いじらず、
生成元（コード）だけを編集する

これだけです。

❌ 図面を直接直さない
❌ PDF を直接修正しない
❌ GDS を直接編集しない

👉 「元になるコード」だけを修正する。

これをやっているかどうかが、
Full Code設計かどうかの境界線です。

🛠 FreeCADの場合

😵 よくあるGUI設計

スケッチを修正
寸法を手で直す
「前はどうだったっけ？」になる

👉 差分が追えない
👉 設計意図が消える

✅ コード主導の場合（03〜06）

設計コード（.py / Spreadsheet）
        ↓
FreeCADで形状生成
        ↓
STEP / 図面

🟢 正は コード
👀 CADは 表示と確認
🔄 変更は コード差分

👉 Gitでレビュー可能
👉 何度でも再生成できる

📄 LaTeXの場合

これは一番分かりやすい例です。

design.tex
    ↓
pdf

🟢 .tex が正
📄 .pdf は生成物
✏ 修正は .tex に戻る

誰も

「PDFを直接直そう」

とは言いません。

👉 FreeCADも本来これと同じ構造です。

🧬 Klayout（半導体レイアウト）の場合

Klayout でも同じです。

.ly / .py
    ↓
GDS

❌ GDSを直接編集しない
🟢 生成スクリプトが正
🔍 差分は .ly / .py

👉 ルールが残る
👉 派生設計が楽

⚙️ RTL（Verilogなど）の場合

RTL設計も全く同じです。

design.v
    ↓
netlist / layout

🟢 .v が設計の正
🧱 ネットリストは生成物
🔍 差分レビューはコード

👉 成果物を直したら負け
という世界です。

🧩 全部まとめると、構造は一つ

道具は違いますが、
構造は完全に同じです。

分野	🟢 正（SSOT）	📦 生成物
FreeCAD	Python / Spreadsheet	STEP / 図面
LaTeX	.tex	PDF
Klayout	.ly / .py	GDS
RTL	.v / .sv	netlist

👉 正はコード
👉 成果物は毎回生成

✅ Full Code設計かどうかの判定基準

実務で迷ったら、これだけ見れば十分です。

🔧 修正するとき、どこを直す？
- ❌ PDF / CAD / GDS
- ✅ コード
♻ 成果物は消しても復元できる？
🔍 差分は Git で見える？

YES なら、
その設計は Full Code です。

⚖ すべてをコード化する必要はない

ここは誤解されやすいので書いておきます。

🎨 見た目の微調整
🧪 最後の詰め
⏱ その場限りの検討

まで 無理にコード化する必要はありません。

重要なのは、

🧠 あとで理由を説明したい部分だけをコードにする

ことです。

💪 なぜこれが「強い」のか

🔁 設計変更が差分になる
🗣 レビューが成立する
🤝 引き継ぎが楽
❓ 「なぜこうなったか」が残る

これは自動化の話ではありません。

👉 設計を資産として扱えるかどうか
という話です。

🏁 おわりに（最終回）

本連載で言いたかったことは、
最初から最後まで一つです。

🏗 設計とは、
成果物を作ることではなく、
生成ルールを残すこと

FreeCADでも、LaTeXでも、Klayoutでも、RTLでも、
やっていることは同じです。

もし今後、

「CADもコードで管理しよう」
「PDFはCIで生成しよう」

という話を聞いたとき、

それが
設計を楽にするのか、壊すのか
を判断する基準として、

このシリーズが役に立てば幸いです。

✨ Full Code Mechanical Design / 完 ✨