Fusion の MCP サーバーに Claude をつなぎ、クラウド上に散らかっていた実験装置のアセンブリを、会話だけで約半日かけて整理しました。フォルダ分けだけのつもりが、共有メンバーに部品が見えていなかった原因まで見つかりました。
対象は、ガラスの切削と穴あけに使う小型の実験装置です。結果を先に書きます。
- 3つのプロジェクトに散らばっていた約90ファイル(部品と図面)を、1つのプロジェクトの5フォルダに集約した
- アセンブリを「共通ベース」と「切削構成」「穴あけ構成」に分け、共通部分を直せば両方に反映される形にした
- 他プロジェクトへの参照をゼロにした(カメラと支柱まわりの4部品が該当)
- 元のアセンブリは一切壊さず、旧版として残した
自分で手作業していたら、参照関係を追うだけで何日かかかったと思います。この記事では、進め方と、うまくいった点・つまずいた点をそのまま書きます。
この記事でわかること
- Fusion の MCP サーバーで、クラウド上のフォルダやアセンブリをどこまで操作できるか
- 「共通ベース + 用途別の構成」にアセンブリを分け直す手順
- 共有メンバーに部品が見えなくなる原因(他プロジェクトへの参照)と直し方
- AI に CAD データを触らせるときに、安全に進めるための段取り
使った環境
使ったのは、Autodesk Fusion に入っている MCP サーバーと、Claude のデスクトップアプリです。追加のアドインは入れていません。
- Fusion 側:基本設定の「API」にある「Fusion MCP Server」にチェックを入れ、適用を押して有効にする。初期設定ではオフ
- Claude 側:デスクトップアプリから、同じ PC で動いている Fusion に接続する
- 注意:MCP サーバーは自分の PC の中だけで動くので、Fusion を起動したままにしておく必要がある
操作対象は Fusion のクラウドデータ(データパネルのプロジェクトとフォルダ)です。PC 内の普通のフォルダは対象外です。
整理前の状態
同じ装置の部品が、3つのプロジェクトにほぼ丸ごとコピーされていました。派生を作るたびにプロジェクトごと複製していたためです。
| プロジェクト | 中身 |
|---|---|
| 設計検討用 | 案①〜③の検討履歴。約200ファイル |
| 切削装置(メンバーに共有中) | 現行の部品と組立図。フォルダ分けなしで84ファイル |
| スピンドル検討用 | 穴あけ用の組立図と、既存部品のコピー約70ファイル |
困っていたのは次の3点です。
- どのファイルが最新なのか、自分でも即答できない
- 切削用と穴あけ用で組立図が別ファイルになっていて、共通部分を直すと2か所の修正が要る
- 切削用の組立図は、タイムラインを途中まで巻き戻した状態で保存してあった
最初の質問は「Fusion の MCP でフォルダの整理はできますか」というだけのものでした。
やったこと
方針は「共通部分を1つのデザインにして、用途別のアセンブリからリンクで参照する」です。これは Claude からの提案で、フォルダ分けもこの構成に合わせて決めました。
Fusion の MCP サーバーには「フォルダ整理」という機能はありません。ツールは4つだけで、実際の作業は「Fusion API の Python スクリプトを実行する」ツールを通して行われます。Claude がスクリプトを書いて流し、結果を読んで次の手を決める、の繰り返しでした。
流れは次のとおりです。
- 現状の読み取り:プロジェクト一覧、ファイル一覧、アセンブリのツリーとタイムラインを読み取り専用で取得
- 線引きの相談:どこまでを共通にするかを、部品の一覧を見ながら決める
- 共通ベースの作成:既存の組立図を別名保存し、構成別の部品を削除(33部品、ジョイント32個が残る)
- 参照先の修正:他プロジェクトを参照していた部品を、同じプロジェクト内のファイルに付け替え
- 構成アセンブリの作成:新規デザインに共通ベースをリンク挿入し、切削用・穴あけ用の部品を元と同じ位置に組み付け
- フォルダ分け:ファイルを5つのフォルダに移動し、移動後に参照切れがないかを確認
- 旧プロジェクトの後始末:名前に「【旧】」を付け、新しい側に無いファイルがないか差分を確認
最終的なフォルダは次の形です。
| フォルダ | 中身 |
|---|---|
| 01_共通ベース | 共通アセンブリ、自作部品と図面、複数の構成で使う部品 |
| 02_切削構成 | 切削用アセンブリと、刃物まわりの専用部品 |
| 03_穴あけ構成 | 穴あけ用アセンブリと、スピンドルまわりの専用部品 |
| 04_購入品 | ステージ、動力計、カメラ、ナット類 |
| 90_旧版 | 元の組立図と、使わなくなった部品 |
将来別のステージを使う構成が増えても、共通ベースを挿入したアセンブリを1つ足すだけで済みます。
自分では気づいていなかったこと
今回いちばん価値があったのは、整理そのものより、調べる過程で出てきた指摘でした。4つ紹介します。
共有メンバーに見えていない部品があった
共有しているプロジェクトの組立図の中で、カメラと支柱まわり3部品が、共有していない別プロジェクトのファイルを参照していました。自分の画面では普通に見えるので、まったく気づいていませんでした。
「共有範囲はどこまでですか」と聞いたとき、Claude は「メンバー情報は API から読めない」と断ったうえで、参照先のプロジェクトが違う部品を洗い出してきました。わからないことをわからないと言い、調べられる範囲で答えを出す、という動きです。
同じ名前なのに形が違う部品があった
支柱の3部品は、参照先を付け替える前に形状を比べたところ、新旧で体積と面の数が違いました。片方にだけ追加工が入っていたわけです。Claude はここで作業を止め、どちらが実機の形かを聞いてきました。黙って付け替えられていたら、図面とアセンブリが食い違ったままになるところでした。
「共通」のつもりの範囲に、共通でない部品があった
自分は「タイムラインのここまでが共通」と思っていましたが、その範囲の中で、動力計の取付板と材料の固定板が切削用と穴あけ用で別物でした。取付板は外形が 137×90 と 107×80 で、穴の数も違います。数字を並べた表を見て、小さいほうに統一すると決めました。
図面が付いているファイルと、使っているファイルが別だった
同じ名前・同じ形の部品が2つあり、アセンブリが使っているのは図面の付いていないほう、という組み合わせが4件ありました。形状が同一であることを確認したうえで、図面付きのほうに付け替えています。
うまくいかなかったこと
一発で通ったわけではありません。途中で何度かおかしな状態になり、そのたびに Claude が自分で気づいて直していました。これから試す人の参考になりそうなものを挙げます。
| 起きたこと | 原因 | 対処 |
|---|---|---|
| 日本語のファイル名で検索しても何もヒットしない | スクリプト内の日本語が送信時に文字化けしていた | 文字を Unicode エスケープで書くか、ファイル ID で指定する |
| カメラの参照先を変えたらレンズだけ床に落ちた | レンズの位置は親アセンブリ側で動かしたもので、付け替えで初期位置に戻った | 元のアセンブリから座標を読み、同じ位置に戻す |
| ジョイントを付けたらステージが原点に戻った | 子部品を個別に動かしても保持されない | 最上位のコンポーネントごと動かしてからジョイントを作る |
| 動力計が元より90°回っていた | 取付板を統一した結果、切削側で向きが変わった | どちらの向きにするかを人が決める |
| 平面ジョイントを5か所中1か所戻せなかった | 部品が傾いて付いていて、接する平面がなかった | そこだけ剛性ジョイントのままにする |
レンズの件は、画面のスクリーンショットを撮って見比べたことで見つかりました。数値のチェックだけでは「エラーなし」と出ていたので、見た目の確認を挟んでいたのが効いた形です。
また、MCP ではできなかったこともあります。プロジェクトのメンバー一覧は API から読めないので、共有範囲は Web 画面で自分で確認しました。
人が決めたこと、AI に任せたこと
作業の手はほぼすべて AI が動かしましたが、設計上の判断はすべて自分がしています。分担は次のようになりました。
| 自分が決めたこと | AI がやったこと |
|---|---|
| どこまでを共通にするか | 部品とジョイントの依存関係を調べて、線引き案を出す |
| 取付板をどちらに統一するか | 2枚の外形と穴の数を比べて表にする |
| 支柱はどちらの版が実機か | 新旧の体積・面数の違いを見つけて作業を止める |
| 動力計の向き | 向きが90°違うことを報告する |
| 判断のつかないファイルの行き先 | どこからも参照されていないファイルを一覧にする |
| ファイルの削除 | 削除はせず、旧版フォルダに集める |
安心して任せられた理由は、進め方にあります。
- まず読み取りだけで調べる。 最初の1時間ほどは何も変更せず、現状の把握と提案だけでした。
- 保存の前に確認を取る。 新しいファイルを作る、共有メンバーに見える変更をする、といった節目で必ず聞かれました。
- 元のファイルは触らない。 新しいアセンブリは別名保存と新規作成で作り、元の組立図は保存せずに閉じています。
- 変更のたびに照合する。 部品の座標を元と数値で比べ、タイムラインのエラーを確認し、スクリーンショットも見る、の3点セットでした。
- 形が違うものは勝手に入れ替えない。 同名ファイルは形状を比べ、同一なら付け替え、違っていればこちらの判断を待つ、という動きでした。
まとめ
CAD データの整理は、AI に手を動かしてもらい、人が設計判断だけをする形で十分に回りました。質問から完了まで、実作業は約5時間です。
効いたのは「速さ」より「調べ漏れの少なさ」でした。参照先のプロジェクト、新旧の形状の違い、図面と部品の紐づきは、人が1ファイルずつ開いて確かめるには数が多すぎます。そこを全件チェックしてくれたことで、気づいていなかった問題が表に出ました。
これから試す人へ、経験から言えることを挙げます。
- 最初に「何をしたいか」を目的で伝える。 「フォルダを分けたい」ではなく「共通部分をベースに派生を作りたい」と伝えたことで、構成そのものの提案が出ました。
- 実機を知っているのは自分だけ。 どちらの版が正しいか、どちらの向きで付けているかは、モデルからはわかりません。聞かれたら現物を見て答えます。
- 削除は最後に自分でやる。 不要に見えるファイルは旧版フォルダに集め、しばらく使ってから消すのが安全です。
- 共有しているデータなら、メンバーへの連絡を忘れない。 プロジェクト名やフォルダが変わるので、案内メールの文面も一緒に作ってもらいました。
将来、別のステージを使う構成が必要になったら、同じやり方で追加するつもりです。
関連記事
コメント