🏁 はじめに（最終回）
ここまでの連載では、
- 🧩 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 | |
| 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 / 完 ✨