kotlin

Fusion360 MCPサーバー完全ガイド|公式コネクタ登場後のCAD自動化(2026年版)

Fusion360 MCPサーバーは、Claudeのような生成AIに自然言語で指示するだけで、Autodesk Fusion上に3Dモデルを作らせる仕組みです。2026年4月28日にはAutodesk公式のFusionコネクタも登場し、選択肢はコミュニティ製のサーバーと公式連携の二系統に分かれました。この記事では、MCPがClaudeとFusionをどうつなぐのかという仕組みから、公式とコミュニティ製の機能差、導入手順、実行できるCAD操作、そして量産設計で残る限界とセキュリティ要件までを一通り解説します。

目次

Fusion360 MCPサーバー活用に向けた選定と運用のまとめ

Fusion360 MCPサーバーは、ClaudeのようなAIに自然言語で指示してFusion上に3Dモデルを作らせる仕組みで、MCPという共通標準がAIとFusion APIの橋渡しを担います。2026年4月の公式コネクタ登場により、選択肢は「保証とデータ保護に強い公式」と「機能拡張の自由が利くコミュニティ製」の二系統に整理されました。業務・商用なら公式を軸に、個人検証や独自機能の追加ならOSSを、という用途起点の選び方が失敗を避ける近道です。

導入時は前提環境とアドイン登録・設定ファイル・疎通確認の順序を押さえ、つまずきは典型パターンから潰します。そのうえで、単純形状や派生設計はAIに任せ、量産アセンブリや製造性検証は人が担うという線引きと、ローカル実行・トークン認証・アクセス範囲管理というセキュリティの土台を運用ルールに落とし込めば、Fusion360 MCPサーバーを安全に設計の入口へ組み込めます。まずは試作用の複製で得意領域から試し、自社のワークフローに合うかを見極めることから始めてください。

Fusion360 MCPサーバーの仕組みとClaude連携の基本構造

はじめに、Fusion360 MCPサーバーが「何と何を、どうつないでいるのか」を押さえます。ここを理解しておくと、後述する公式コネクタとコミュニティ製の違いも、導入時のつまずきも判断しやすくなります。

AIとアプリ間の共通プロトコルとしてMCPが担う役割

MCP(Model Context Protocol)は、Anthropicが策定したAIモデルと外部アプリをつなぐオープン標準です。USBの規格のように「AI側」と「アプリ側」の接続方法を共通化する役割を持ち、AIごと・アプリごとに専用の連携を作り直さずに済みます。Fusionの場合は、このMCPを介してClaudeがFusionへ「スケッチを作る」「押し出す」といった指示を渡せるようになります。オープン標準であるため、ClaudeだけでなくCursorやClaude Codeなど他のMCP対応クライアントからも同じサーバーを利用できる点が、独自API連携との大きな違いです。

ClaudeからFusionまでをつなぐ4層構成の通信経路

コミュニティ製サーバーの典型構成は、Claude(MCPクライアント)→ MCPサーバー(PythonやNode.js)→ Fusionアドイン → Fusion APIという4層です。MCPクライアントとサーバーはstdioでやり取りし、サーバーとFusionアドインはlocalhost上のHTTP(例:ポート8080)やファイル経由で通信します。たとえばndoo製の「fusion360-mcp-bridge」は、この間を`fusion_execute`と`fusion_screenshot`という最小限の2ツールだけでつなぎます。層が分かれているのは、AIの言語処理とFusion内部の実行を切り離し、片方が変わっても全体を作り直さずに済むようにするためです。

adsk.*のFusion Python APIが造形を実行する仕組み

実際に立体を作るのは、Fusionに組み込まれたPython API(`adsk.core`や`adsk.fusion`などのモジュール)です。MCPサーバーから渡された指示は、最終的にこのAPIの呼び出しに変換され、スケッチ生成や押し出しが実行されます。Fusionは元々スクリプトやアドインでこのAPIを操作できる設計のため、MCPサーバーは「AIの指示をスクリプトに翻訳する層」として後付けで成立しています。つまりMCPサーバーは魔法ではなく、従来から存在したFusion APIを自然言語の窓口でくるんだもの、と捉えると挙動を予測しやすくなります。

非スレッドセーフなAPIをCustomEventで処理する設計

Fusion APIには「すべての操作をメインのUIスレッド上で実行しなければならない」という制約があります。一方でMCPサーバーからのHTTPリクエストは別スレッドで届くため、そのまま実行するとエラーや不安定動作の原因になります。これを避けるため、多くの実装はFusionのCustomEventの仕組みを使い、外部から来たリクエストをいったんメインスレッドの処理待ち行列(タスクキュー)に積み、順番に実行する設計を採用しています。導入後に「コマンドが時々失敗する」「順序が乱れる」といった症状が出る場合、この非同期処理まわりが原因のことが多く、実装の成熟度を見極める判断材料になります。

自然言語の指示がAPI呼び出し列へ変換される処理フロー

処理の流れは、①利用者が「角を5mm丸めた50mmの立方体を作って」と入力 → ②Claudeが意図を解釈し、MCPツール(create_sketch、extrude、filletなど)の呼び出し列に変換 → ③サーバー経由でFusionのAPIが順に実行 → ④画面に形状が現れる、という4ステップです。重要なのは、Claudeが「3D空間のどこに何を置くか」を取り違えると、寸法は正しくても位置がずれた形状ができる点です。複数の実装が座標系や基準面の扱いを説明書(CLAUDE.mdなど)に詳しく記述しているのは、この空間把握の誤りを減らすためです。

2026年公式コネクタ登場で一変したFusion×AI設計の現在地

2026年春に状況は大きく動きました。これまで有志のGitHub実装が中心だったFusion×MCPの世界に、Autodesk公式の連携が加わったためです。ここでは事実関係と、それが設計者にとって何を意味するかを整理します。

2026年4月28日の公式Fusionコネクタ発表で変わった点

2026年4月28日、AutodeskとAnthropicは、MCPを通じてClaudeがAutodesk Fusionへ直接接続できる公式コネクタを発表しました。これにより、Fusionサブスクリプションを持つ設計者・エンジニアは、作りたいものを自然言語で説明するだけで、Claudeがその手順をFusion内で実行し、モデル作成・形状変更・ファイル書き出しまで行えるようになりました。発表は単独ではなく、Adobe Creative CloudやBlenderを含む複数の連携と同時に公開され、エンジニアリングとAIの両コミュニティで大きな反響を呼びました。これまでは自己責任の有志ツールしか選択肢がなかったことを思えば、公式の保証が付いた点が最大の変化です。

Autodesk AI Assistantと公式コネクタの役割分担の違い

混同しやすいのが、Autodesk自身が同じ2026年4月に提供を始めたAI Assistantと、今回の公式コネクタの関係です。AI AssistantはAutodeskがPD&M(製品設計・製造)製品群向けに提供する内蔵型のアシスタントで、自社の業界特化モデルと組み合わせて設計・製造ワークフローを支援します。一方の公式コネクタは、外部のClaudeをFusionに接続する窓口です。AutodeskのJeff Kinder氏(PD&Mソリューション担当EVP)は、フロンティアモデルと自社の業界特化モデルを組み合わせる方針を示しており、両者は競合ではなく補完関係にあると位置づけられます。用途に応じて「内蔵アシスタント」と「外部AI連携」を使い分ける、という理解が実態に近いです。

Text-to-CADが設計プロセスの前段で果たす位置づけ

公式コネクタの核心は、Text-to-CAD(テキストから形状を生成する)という考え方です。ブラケットやハウジングの派生形状を手作業で何度も作り直す代わりに、設計意図を言葉で伝えてClaudeに手順を実行させます。位置づけとしては、製品開発の「アイデアから製造可能な出力へ」という流れの最前段、つまりコンセプト出しや初期形状づくりに効くという見方が定着しつつあります。逆に言えば、後段の詳細設計や検証は依然として人の領域であり、Text-to-CADは設計全体を置き換えるものではなく、入口を速くする道具だと捉えるのが妥当です。

公式コネクタ利用に必要なFusionサブスクリプションの前提

公式コネクタを使うには、有効なAutodesk Fusionのサブスクリプションが前提となります。Fusionは個人利用向けに無償枠や30日間の体験版が用意されていますが、公式コネクタを業務で本格利用する場合は商用ライセンスの確認が欠かせません。なお製品名は「Fusion 360」から「Autodesk Fusion」へ整理されており、検索される「Fusion360」と公式表記の「Fusion」は同じ製品を指します。ライセンス形態や利用規約は変更されることがあるため、導入判断の前に必ずAutodeskの最新情報を確認してください。

Blender等9連携と同時公開された背景にある狙い

Fusionコネクタは、Blenderなどを含む合計9つの連携の一つとして公開されました。Blender側ではPython APIを通じてシーンの解析やスクリプトによる一括変更が例示されており、AnthropicはBlenderプロジェクトへ資金提供も行っています(当初の開発基金パトロン参加は、2026年5月に単発の寄付へ変更されました)。この「設計・制作ツール群へのAI接続を一斉に広げる」動きは、特定ソフトの囲い込みではなく、MCPという共通規格でクリエイティブ/エンジニアリング領域全体に橋を架ける狙いを示しています。Fusionだけを見るのではなく、CAD・3DCG・デザインツールが横並びでAI接続されていく潮流の一部として捉えると、今後の方向性を読みやすくなります。

公式コネクタとコミュニティ製MCPサーバーの機能差と用途別の選び方

選択肢が二系統になったいま、最初の検討ポイントは「公式コネクタとコミュニティ製サーバーのどちらを使うか」です。それぞれ強みが異なるため、用途から逆算して選ぶのが失敗しないコツです。

提供主体とサポート体制で見る公式とOSSの根本的な差

最大の差は提供主体です。公式コネクタはAutodeskとAnthropicが提供し、同社のプライバシー・セキュリティ・製品標準に沿って保護される一方、コミュニティ製はKevinZhao-07氏やJoe-Spencer氏ら有志が公開するOSSで、多くが「概念実証であり製品ではない」と明記しています。サポートや動作保証を重視するなら公式、最新の実験的機能や改変の自由を取るならコミュニティ製、という線引きが基本になります。業務での安定運用を求める組織ほど、提供主体の責任範囲を最初に確認すべきです。

対応操作数とカスタマイズ性で比較する両者の機能範囲

機能の広さも判断材料です。コミュニティ製には、たとえばMisterbra氏の「fusion360-claude-ultimate」のように84以上のCADツール(押し出し・回転・ロフト・パターン・シェル・ねじ・各種エクスポート等)を備えた多機能なものもあります。下表は両系統の傾向を整理したものです。

比較観点 公式コネクタ コミュニティ製サーバー
提供主体 Autodesk/Anthropic 有志開発者(OSS)
動作保証・サポート 公式標準に準拠 原則自己責任・保証なし
利用前提 Fusionサブスクリプション Fusion+自前セットアップ
対応操作の例 モデル作成・変更・書き出し 実装により数十種類規模も
カスタマイズ性 限定的 コード改変で自由に拡張可
導入の手軽さ 比較的容易 環境構築の手間が大きい

表は傾向であり、コミュニティ製は実装ごとに対応操作数も成熟度も大きく異なります。導入前に各リポジトリのツール一覧と更新状況を確認してください。

商用利用・社内データ管理で公式が優位になる判断基準

商用案件や社内の設計データを扱う場面では、公式コネクタが優位になりやすいです。判断基準は明確で、①取引先や自社の規程で「保証のないツールの使用」が制限されているか、②扱うデータに機密設計が含まれるか、③障害時に問い合わせ先が必要か、の3点です。これらに一つでも該当するなら、自己責任前提のOSSより、Autodeskの製品標準に沿う公式コネクタを軸に検討するのが無難です。逆にこれらに該当しない個人の試作なら、公式にこだわる必要はありません。

独自ツール追加でコミュニティ製を選ぶべきケース

一方で、コミュニティ製が向くのは「公式にない操作を自分で足したい」ケースです。たとえばmycelia1氏の実装は`execute_code`で任意のPythonコードをFusion内で実行でき、特定業務に特化したマクロやバッチ処理を組み込めます。社内の定型設計を自動化したい、研究目的でAPIの限界を試したい、といった場合は、コードを改変できるOSSの自由度が効きます。ただし改変にはFusion APIの知識が必要で、不具合時も自力対応が前提になる点は織り込んでおく必要があります。

個人検証か業務利用かで分かれる選定の判断フロー

迷ったときは、次の順で判断すると整理できます。まず用途が「個人の学習・試作」か「業務・商用」かを分けます。業務なら公式コネクタを第一候補にし、保証とデータ保護を優先します。個人の検証で、かつ独自機能や深いカスタマイズが目的なら、対応ツールが多く更新の活発なコミュニティ製リポジトリを選びます。さらに「プログラミングを伴う改変をするか否か」で、改変するならOSS、自然言語操作だけで十分なら公式、と枝分かれさせると、選定の軸がぶれません。

Fusion360 MCPサーバーで実行できるCAD操作と設計ワークフロー

続いて、実際にどんな操作をAIに任せられるのかを具体的に見ていきます。できることの輪郭がつかめると、自分の設計業務のどこに組み込めるかが見えてきます。

スケッチ・押し出し・フィレットなど基本造形コマンド

最も安定して動くのが、基本的な造形操作です。多くの実装が次のようなツールを標準で備えています。

  • create_sketch:XY・YZ・XZ平面へのスケッチ作成
  • draw_rectangle/draw_circle:寸法や半径を指定した図形の描画
  • extrude:スケッチ断面を押し出して立体化
  • fillet/chamfer:エッジの丸め・面取り

「角を5mm丸めた50mmの立方体を作って」のような一文で完結する指示は、これらのコマンドの組み合わせとして確実に実行されます。まずはこの範囲から試すと、AIの挙動を把握しやすくなります。

回転・ロフト・スイープを使う中級モデリング操作

基本操作に慣れたら、回転体(revolve)、ロフト(loft)、スイープ(sweep)といった中級操作に進めます。回転はプロファイルを軸まわりに回して円筒や容器を、ロフトは複数断面をつないで滑らかな遷移形状を、スイープはパスに沿って断面を走らせてパイプやハンドルを作ります。これらは「断面」と「経路・軸」という二つの要素を正しく指定する必要があり、基本操作より指示の曖昧さが結果に響きます。意図どおりにならない場合は、断面の位置と向きを言葉で明示し直すと改善することが多いです。

STL・STEP・F3Dへのエクスポートと3Dプリント連携

作ったモデルは、用途に応じた形式で書き出せます。3DプリントならSTL、他CADとのデータ受け渡しなら中間フォーマットのSTEP、Fusionでの作業継続ならネイティブのF3Dが基本です。たとえば「このモデルをSTLで書き出して」と指示すれば、エクスポート処理までを一連の会話で完結できます。AIにモデリングから出力まで任せられるため、簡単な治具や試作部品を「説明する→印刷用データができる」という流れで素早く回せる点が、3Dプリント用途での実用的な利点です。

パラメータ駆動でブラケット形状を量産する実務例

設計現場で効果が出やすいのが、パラメータ駆動の派生設計です。たとえば取付穴の間隔・板厚・全長を名前付きパラメータとして定義しておき、「板厚を3mmから5mmに、穴間隔を40mmに変えて」と指示すれば、同系統のブラケットを数値違いで素早く展開できます。手作業なら寸法変更のたびにスケッチを編集する工程を、会話で置き換えられるわけです。レビューでも、こうした単純なパラメトリック変化や反復モデリングはAIの得意領域として評価されています。定型部品のバリエーション出しは、最初の導入対象として有力です。

ビューポートのスクリーンショットによる視覚的検証

操作系だけでなく、確認系のツールも重要です。ndoo氏の実装の`fusion_screenshot`のように、現在のビューポートをPNG画像として取得できる機能を持つサーバーがあります。これによりClaudeは、自分が作った形状を画像として「見て」、意図とずれていないかを確認しながら修正を重ねられます。前述のとおりAIは3D空間での位置取りを誤りやすいため、この視覚的フィードバックの有無は、複雑な形状を任せる際の成功率を左右する実務上のチェックポイントになります。

Claude DesktopとFusionをつなぐMCPサーバー導入手順と設定要点

ここからは実際の導入です。コミュニティ製サーバーを例に、つまずきやすい順序と設定の要点を押さえます。なお具体的な手順は実装ごとに異なるため、必ず使用するリポジトリの最新READMEを正本としてください。

Fusion・Python 3.10以上・MCPクライアントの前提環境

多くのコミュニティ製サーバーは、Autodesk Fusion本体、Python 3.10以上、そしてClaude DesktopなどのMCP対応クライアントを前提とします。Fusionは個人利用なら無償で導入でき、Pythonはサーバー本体の実行に使います。クライアントはGUIのClaude Desktopのほか、コマンドラインのClaude Code、Cursorなども選べます。最初に「自分が使うクライアントは何か」を決めておくと、後の設定ファイルの書き方が一意に定まり、迷いが減ります。

Shift+SからアドインをFusionに追加する具体的手順

Fusion側では、MCPと通信するためのアドイン(またはスクリプト)を登録します。代表的な手順は次のとおりです。

  1. Fusionで「ユーティリティ」→「スクリプトとアドイン」を開く(ショートカットはShift+S)
  2. 「+」ボタンから「デバイス上のスクリプトまたはアドイン」を選ぶ
  3. リポジトリのアドイン用フォルダ(例:FusionMCP)を選択する
  4. 一覧に表示されたら選んで「実行」、必要に応じて「起動時に実行」をオンにする

ここで重要なのは、ファイル単体ではなくフォルダごと追加することです。スクリプト本体とマニフェスト(.manifest)が同じフォルダに揃っていないと起動に失敗するため、登録対象のフォルダ構成を必ず確認してください。

claude_desktop_config.jsonへのサーバー登録設定

Claude Desktopを使う場合は、設定ファイルにMCPサーバーを登録します。WindowsとmacOSで場所が異なります。

記述例(実際のパスやコマンドは実装に合わせてください):

{ "mcpServers": { "fusion360": { "command": "uvx", "args": ["fusion360-mcp-server", "--mode", "socket"] } } }

設定ファイルの場所は、Windowsが %APPDATA%\Claude\claude_desktop_config.json、macOSが ~/Library/Application Support/Claude/claude_desktop_config.json です。編集後はClaude Desktopを再起動しないと反映されない点に注意してください。

uvxやpipでのサーバー導入とpingによる疎通確認

サーバー本体は、PyPIで公開されているものならuvxでリポジトリを取得せず直接起動でき、そうでなければpip install mcp等で依存を入れてから動かします。たとえばclaude mcp add fusion360 -- uvx fusion360-mcp-server --mode socketのように登録する実装もあります。導入後はまずクライアントから`ping`ツールを呼び、{"pong": true}が返るかで接続を確認します。形状を作り始める前にこの疎通確認を挟むことが、原因切り分けを楽にする定石です。

接続できないときに確認する典型的なつまずき所

つながらないときに見るべき箇所は、ほぼ決まっています。代表的な失敗パターンは、①Fusionが起動していない、②アドイン側のHTTPサーバーが動いておらず「started on port 8080」等のログが出ていない、③設定ファイルのパスやコマンドの記述ミス、④編集後にクライアントを再起動していない、⑤フォルダではなくファイル単体を登録してしまった、の5つです。また押し出しはスケッチ断面が前提のため、「先にスケッチを作ったか」も初歩的な確認点です。上から順に潰すと、多くの接続不良は解消します。

製造・設計現場でMCPに任せられる範囲と量産設計で残る限界

導入の話に続けて、現実的な期待値を握っておきます。ここを誤ると「思ったほど使えない」と感じやすいため、得意と不得意を正直に整理します。

単純形状とパラメトリック変化で安定する得意領域

AIが安定して結果を出すのは、一文〜二文で説明できる単純形状と、寸法違いのパラメトリックな派生です。矩形の筐体、円筒状のハウジング、簡単なブラケットなどは、寸法を理解し、特徴を論理的な順序で適用して、おおむねきれいな形状が得られると評価されています。コンセプトの素早いモックアップや、定型部品のバリエーション展開といった用途では、現時点でも十分に実用的です。まずはこの得意領域から業務に組み込むのが、投資対効果の高い使い方です。

既存の複雑モデル読み取りで生じる精度と理解の壁

逆に苦手なのが、既にある複雑なモデルの読み取りと理解です。レビューでは、Claudeのコネクタは基本的な形状をテキストから生成できる一方、既存モデルを読み解いたり、アセンブリ全体の構造を理解したりすることはできないと指摘されています。ゼロから単純形状を作るのは得意でも、他人が作り込んだ設計の意図をくみ取って続きを正確に編集する、という用途には現状そのまま乗せにくいのが実情です。既存資産の改修を任せたい場合は、過度な期待は禁物です。

量産アセンブリと製造性検証で人手が残り続ける理由

量産を見据えた本番のアセンブリや、製造性(その形状が実際に作れるか)の検証は、依然として人の判断が必要な領域です。公差の積み上げ、部品間の干渉、加工方法との整合といった検証は、単に形状を生成する能力とは別物だからです。あるレビューが「CADは速くなっても、ボトルネックは同じ」と表現したように、形状づくりが高速化しても、その妥当性を保証する工程は残ります。AIは下流の検証まで肩代わりしないという前提で、役割を割り当てるのが安全です。

対応CADがFusionに限られる適用範囲の制約

適用範囲の制約も見落とせません。Fusion向けのMCPサーバーやコネクタは、当然ながらFusion以外のCAD(SolidWorks、Inventor、CATIAなど)には使えません。社内で複数のCADを併用している場合、「Fusionの分だけAI化される」状態になり、全社的なワークフロー統一にはつながりにくい点に注意が必要です。導入時は、自社の設計データがどのCADに集中しているかを確認し、Fusionが主力でない環境では効果が限定的になりうると見積もっておくべきです。

AIに任せる工程と人が判断する工程の線引き基準

これらを踏まえた線引きの基準はシンプルです。「言葉で完結し、間違っても作り直せばよい工程」はAIに任せ、「間違いが量産・コスト・安全に直結する工程」は人が判断する、という分け方です。具体的には、初期形状の生成・派生・試作データの書き出しはAI側、最終寸法の確定・製造性レビュー・アセンブリ整合の確認は人側に置きます。この境界をチーム内で明文化しておくと、便利さに引っ張られて検証を飛ばす事故を防げます。

ローカル実行とトークン認証で固めるFusion MCPのセキュリティ要件

最後に、業務利用で必ず検討すべきセキュリティの論点です。Fusion MCPは設計データという機微情報を扱うため、仕組みのどこに守りが効いているかを理解しておく必要があります。

localhost通信で外部に出ないローカル実行という前提

コミュニティ製サーバーの多くは、MCPサーバーとFusionアドインの通信をlocalhost(同じPC内、例:127.0.0.1:8080)に閉じています。設計データそのものを外部サーバーへ送らずにPC内で処理が完結する構成は、機密性の観点で安心材料になります。ただし「localhostで閉じている」のはサーバーとFusion間の話であり、AIモデルへ送る指示文や文脈に何が含まれるかは別問題です。どの情報がAI側に渡るのかを、利用するクライアントの仕様で確認しておく必要があります。

トークン認証ファイルによる不正アクセス遮断の仕組み

同一PC内とはいえ、ローカルのHTTPサーバーは他プロセスからもアクセスされうるため、認証を設ける実装があります。たとえばndoo氏のブリッジは、秘密トークンを~/.fusion-mcp-secret(パーミッション600)に保存し、有効なトークンを持たないリクエストには401 Unauthorizedを返します。これにより、想定外のプロセスがFusionを勝手に操作することを防ぎます。導入するサーバーがこうした認証を備えているか、トークンファイルの権限が適切かは、業務利用時のチェック項目に入れておくとよいでしょう。

execute_code系ツールが持つ任意コード実行のリスク

強力さゆえに注意が要るのが、`execute_code`のような「任意のPythonコードをFusion内で実行する」ツールです。柔軟な自動化を可能にする反面、AIが生成したコードがそのまま実行されるため、想定外の操作やファイル書き換えが起こりうるリスクを内包します。重要な設計ファイルを開いたまま無検証で任意コードを走らせるのは避け、作業用の複製で試す、実行内容をログで確認する、といった運用上の歯止めが現実的な対策になります。便利な機能ほど、実行範囲を意識して使うことが大切です。

公式コネクタが準拠するAutodeskのプライバシー基準

公式コネクタは、何にアクセスしどう使うかを利用者が制御でき、Autodeskの既存のプライバシー・セキュリティ・製品標準に沿った保護が適用されると説明されています。自己責任前提のOSSと比べ、データの取り扱いに一定の枠組みが約束されている点は、組織での採用判断において明確な優位です。とはいえ規約や保護範囲は更新されうるため、機密性の高い設計を扱う前に、最新の利用条件とアクセス権限の設定を自社のセキュリティ方針と突き合わせて確認することをおすすめします。

社内設計データを扱う際のアクセス範囲の管理方針

運用面では、AIがアクセスできる範囲を必要最小限に絞る方針が基本です。具体策としては、機密プロジェクトのファイルは別環境で扱う、AIに渡すのは試作・検証用の複製に限定する、誰がどの設定でコネクタを使えるかを管理する、といった切り分けが挙げられます。前述のトークン認証やローカル実行はあくまで技術的な土台であり、最終的にどのデータをAIの作業対象に含めるかという運用ルールこそが、情報漏えいを防ぐ要になります。導入と同時に、この管理方針をチームで取り決めておきましょう。

Fusion360 MCPサーバーに関するよくある質問

最後に、Fusion360 MCPサーバーの導入を検討する際によく挙がる疑問をまとめました。選定や運用の判断材料として活用してください。

Fusion360 MCPサーバーは無料で使えますか?

コミュニティ製のMCPサーバー自体はOSSとして無償で公開されているものが多く、ソフトウェア料金はかかりません。ただし接続先のAutodesk Fusionが必要で、個人利用の無償枠や体験版はあるものの、業務利用では有償のサブスクリプションが前提になります。また2026年4月に登場した公式コネクタの利用にも、有効なFusionサブスクリプションが必要です。つまり「サーバーは無料でもFusion側の費用は別」と考えておくのが正確です。

公式コネクタとコミュニティ製はどちらを選ぶべきですか?

用途で判断するのが基本です。業務・商用利用や社内の機密設計を扱うなら、Autodeskの製品標準に沿った保護とサポートがある公式コネクタが無難です。一方、個人の学習・試作で、独自ツールの追加やコードの改変といった自由度を求めるなら、対応操作が多く更新の活発なコミュニティ製サーバーが向きます。「保証とデータ保護を取るか、カスタマイズの自由を取るか」が分岐点だと考えてください。

プログラミングの知識がなくても導入できますか?

公式コネクタは比較的容易に使い始められ、自然言語での操作が中心のため、深いプログラミング知識は必須ではありません。一方コミュニティ製は、Pythonの実行環境を整え、設定ファイルを編集し、Fusionにアドインを登録する作業が必要で、最低限のコマンドライン操作には慣れている方が安心です。さらに独自機能を足したい場合はFusion APIの知識も求められます。まずは自然言語操作だけで完結する範囲から始めるのがおすすめです。

既存のFusionファイルもAIで編集できますか?

実装によっては既存ファイルを開いて形状を追加・変更できるものもありますが、過度な期待は禁物です。レビューでは、AIは単純形状の新規生成は得意でも、既存の複雑なモデルやアセンブリの構造を読み解いて正確に編集することは苦手だと指摘されています。簡単な形状の追記なら実用域ですが、作り込まれた設計の改修を任せるのは現状では難しく、編集対象は試作用の複製で試すなど、慎重に運用するのが安全です。

Fusion以外のCADでもMCPサーバーは使えますか?

Fusion向けのMCPサーバーやコネクタは、Fusion専用です。SolidWorksやInventor、CATIAなど他のCADには、それぞれ対応した別の連携が必要になります。なおMCP自体はオープン標準で、Blenderなど他ツール向けのコネクタも同時期に公開されているため、ソフトごとに対応状況は広がりつつあります。複数CADを併用している場合は、主力ソフトがどれかを踏まえて、AI化できる範囲が部分的になりうる点を見込んでおきましょう。

資料請求

RELATED POSTS 関連記事