【ITニュース解説】Git-Powered History in FreeCAD Transforms Design-to-Print Pipelines

ある精密部品製造企業で、複雑なロボットアームの設計が最終段階にあった。このロボットアームは180以上の部品で構成され、特に肩関節の45mmの穴の直径はサーボモーターのハウジングと正確に合致する必要があった。週の終わりに、主任設計者は新しいモーターの仕様に合わせて、この穴の直径を47mmに変更し、「shoulder_joint_revB.FCStd」という名前で更新されたFreeCADファイルを保存した。彼はそのファイルをSTEP形式でエクスポートし、「最新版なのでこれを使ってください」という件名でCNCプログラマーと試作工場に電子メールで送った。しかし、プログラマーは既に2日前に「shoulder_joint_v3_final.STEP」という添付ファイルを受け取っており、それを最新版と誤解して開いてしまい、古い設計図に基づいて工作機械のプログラムを作成してしまった。

機械加工されたアルミニウム製のハウジングが組み立て現場に届くと、サーボモーターを取り付けようとしたところ、全く合わないことが判明した。この不一致は、アーム全体が部分的に組み立てられ、機能テストが実施された後に初めて発覚した。部品は認定された航空宇宙グレードの材料から製造され、機械工場は既に厳しいスケジュールで稼働していたため、チームは合計3つのハウジングを廃棄し、材料を再発注し、作業を再プログラミングしなければならなかった。この遅延は顧客への納期を2週間も遅らせる結果となり、企業は材料費と特急加工費の両方を負担することになった。この問題の根本原因は寸法変更自体ではなく、すべての下流工程の利用者がモデルの単一で信頼できる最新の状態を使用していることを保証するメカニズムが存在しなかった点にあった。

手動によるファイル命名規則や電子メールでの配布は、まさにこのような種類の失敗を引き起こす。エンジニアたちは日常的に「final」「rev2」「for review」「do not use」といったファイル名を作成するが、これらのラベルは、一度ファイルが作成者のワークステーションを離れると、その意味が強制されることはない。異なる受信者はそれぞれ異なるファイルを所有する可能性があり、誰がどのバージョンをいつ開いたのかを示す監査証跡も存在しなかった。このような規模のプロジェクトでは、単一のパラメータ変更が結合面、クリアランスチェック、応力解析モデルに影響を及ぼすため、共同作業者や電子メールのスレッドが増えるごとに、バージョンの衝突の可能性が急激に高まった。

この問題を解決するのが「History Workbench」である。これは、設計ソフトウェアであるFreeCADの内部にバージョン管理システム「Git」の機能を直接組み込むことで、上記の曖昧さを排除する。History WorkbenchがFreeCADプロジェクトフォルダ内でGitリポジトリを管理し、FreeCADファイルや関連する資産へのすべての変更をファイルシステムレベルで追跡する。これにより、デザイナーは使い慣れたFreeCADのインターフェース内で、パラメトリックな作業の完全な履歴を維持できる。プロジェクトフォルダ全体が管理の単位となるため、アセンブリ、図面、サポートスクリプトもすべて同じタイムラインを共有する。

History Workbenchは、Gitの基本的な操作をコマンドライン入力なしで、専用のパネルを通じて提供する。ユーザーは変更されたファイルを選択し、ワンクリックでステージングエリアに移動させ、平易な言葉でコミットメッセージを書き、その時点のスナップショットを記録できる。すべての保存がコミットとなり、タイムスタンプ、作成者、そしてオプションで「45mmから47mmへの変更」といった内容を説明するメッセージが記録される。内蔵の差分表示機能は、3Dモデルとフィーチャーツリーの両方で穴の変更をハイライト表示し、コミット履歴はどのファイルの状態が最新であるかを明確に提供する。これにより、試作工場は最新のコミットから生成された正しいSTEPファイルを受け取り、不一致や部品の廃棄、それに伴うスケジュールとコストの超過を防げる。

設計者はモーターの改訂のために軽量なブランチを作成し、レビュー後にそれをメインの設計にマージし、更新されたリポジトリをプッシュできたはずだ。History Workbenchは、ブランチマネージャーパネルを通じてGitスタイルのブランチ機能をFreeCADインターフェース内に直接統合している。これにより、エンジニアは現在のジオメトリ状態から新しいブランチを簡単に作成し、元の設計に影響を与えることなく、新しい変更をモデリングし続けられる。変更が承認されれば、視覚的な差分表示を経て、成功した修正をメインブランチにマージする。

History Workbenchは、設計ミスを減らすだけでなく、生産プロセス全体を効率化する。FreeCADモデルが設計環境を離れて製造へ移行する際、ファイル状態のわずかな曖昧さが、高価な再加工サイクルを引き起こす可能性がある。History WorkbenchはGitを直接FreeCADのワークフローに統合することで、設計者はプロジェクト全体の正確なスナップショットをタグ付けまたはコミットできる。これにより、STEPやSTLといった製造用ファイルのエクスポート前に、常に「正しく動くことがわかっている」状態のデータを確保し、問題発生時には「既知の良好なコミット」に瞬時にロールバックして再生成できるため、欠陥のあるリビジョンが出荷されるのを防ぐ。

さらに、このGit統合は、リリースパッケージとともに監査可能な変更ログを提供する。各コミットメッセージは、寸法の調整、機能の追加、材料の変更といった判断の根拠を明確に文書化し、差分表示はどのボディや制約が変更されたかを正確に示す。製造業者は中立形式のファイルだけでなく、リポジトリ履歴から生成された簡潔な要約を受け取れるため、バージョンに関する問い合わせが不要となる。すべての変更にはタイムスタンプと作成者の属性が付与されるため、曖昧さが解消される。

History WorkbenchのGit基盤は、複数のエンジニアが同じFreeCADアセンブリを同時に編集することを可能にする。各ドキュメントは共有リポジトリ内でバージョン管理された成果物として扱われ、エンジニアは個別のタスクのために軽量なブランチを作成できる。各コミットはファイル全体をロックするのではなく、変更されたフィーチャーツリーとパラメータ値のみを記録するため、チームメンバーはローカルで作業を続けられる。その後、ブランチがプッシュされると、マージ操作はファイルレベルで2つの履歴を比較し、異なるフィーチャーのみを表示するため、チームは結合結果を受け入れる前にレビューできる。

History Workbenchは、FreeCADの組み込みアドオンマネージャーを通じて数分で導入できる。ツールメニューからマネージャーを起動し、「History Workbench」を検索してインストールするだけである。FreeCADを再起動すると、新しいワークベンチが利用可能になる。既存のFreeCADプロジェクトを開き、「リポジトリを初期化」するボタンをクリックするだけで、プロジェクトのバージョン管理が開始される。ワークベンチは独自のGitバイナリをバンドルし、リポジトリ作成を自動的に処理するため、外部コマンドライン操作は不要だ。これにより、フィーチャーの編集、制約の変更、スプレッドシートの更新を記録するコミットログが追加され、全てのパラメトリック履歴が保持される。

このように、FreeCADとGitを統合するHistory Workbenchは、設計の初期段階から製造、そしてその後のメンテナンスに至るまで、製品開発のライフサイクル全体を通じて、設計データの整合性を保ち、共同作業の効率を高め、最終的な製品の品質と信頼性を向上させる。設計から生産への移行がスムーズになり、手動によるファイル引き渡しが不要となり、すべての関係者が同一で監査可能な真実のソースに基づいて作業することが保証されるため、設計と製造のサイクルが短縮され、品質が向上する。